Stable DiffusionのGUI、NMKD Stable Diffusion GUIが動かなかったのだけど、SettingsでCUDA Deviceを指定したら動いたのでメモ
1.7.2をインストール
https://nmkd.itch.io/t2i-gui
でも、Generateを押すと「応答なし」になってしまった。Visual C++ライブラリとかそういうめんどいやつかと思ったんだけど、Open Stable Diffusion CLIをしても固まるので、少しためした。
SettingsのCUDA DeviceをAutoではなくGPU0にしたらうごいた。
まあ、それだけなんだけど、ネットに放流しておくと役にたつことがあるかな
ついでにWaifu Difussionも試した。
https://huggingface.co/hakurei/waifu-diffusion
いい感じ
Java2DデモというのはJava 5までJDKに添付、Java 8までは別途ダウンロードで提供されていたJava2Dのデモです。
Java2D Demo!#java #java2d pic.twitter.com/jAMih8ep9j
— きしだൠ(K1S) (@kis) 2022年12月9日
久しぶりに動かそうと思ってJava 5をインストールして、demo/jfc/Java2D/Java2Demo.jarをダブルクリックしてもローディングで止まってました。
Java 5はOracleのアーカイブから。
https://www.oracle.com/jp/java/technologies/java-archive-javase5-downloads.html
Java 8向けはこちら。こっちのほうが余計なJDKのインストール不要なのでいいですね。
https://www.oracle.com/java/technologies/java-archive-misc-downloads.html
ソースもあるので開いて動かそうとしてみると、sun.java.image.codecとかの非標準APIが使われていてコンパイル通りませんでした。(Java 8ではImageIOに変わってるので修正不要。DemoImagesの修正だけでいいです)
ということで、java2d.demos.ImagesパッケージのJPEGFlipを編集します。
importをコメントアウトして。
//import com.sun.image.codec.jpeg.*;
JPEGCodecを使ってるコードをImageIOに置き換えます。
ByteArrayOutputStream out = new ByteArrayOutputStream(); //JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(out); //JPEGEncodeParam param = encoder.getDefaultJPEGEncodeParam(bi); //param.setQuality(1.0f, false); //encoder.setJPEGEncodeParam(param); //encoder.encode(bi); ImageIO.write(bi1, "jpeg", out); //FileInputStream in = new FileInputStream(file); ByteArrayInputStream in = new ByteArrayInputStream(out.toByteArray()); //JPEGImageDecoder decoder = JPEGCodec.createJPEGDecoder(in); //bi1 = decoder.decodeAsBufferedImage();
ところでパッケージ名が大文字始まりなんですよね。違和感
それと、画像リソースの読み込みでこけてローディングが止まるので、java2d.DemoImagesのコードを書き替えます。
// URLClassLoader urlLoader = (URLClassLoader)cmp.getClass().getClassLoader(); // URL fileLoc = urlLoader.findResource("images/" + name); URL fileLoc = DemoImages.class.getResource("/images/" + name);
これで動くはず。
まあ、書き換えなくてもJava5でそのまま動かせばいいのだけども。
「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。
12/24発売！クリスマスプレゼントです
大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ！という内容です。
ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開発の話がぜんぶできる」みたいな幻想をもってしまったんじゃないかと。
なので「オブジェクト指向からの脱却」ではなく「オブジェクト指向神話からの脱却」になっていて、オブジェクトでぜんぶやれる(オブジェクトがないと何もできない)という神話から脱却しようぜって感じですね。
なので「じゃあオブジェクト指向の次は？」というのも、「そもそもナントカ指向でやっていけるって発想をやめい！」となります。
まあ、このあたりの話をちゃんと書いた感じ。
オブジェクト指向 カテゴリーの記事一覧 - きしだのHatena
コードの指針として言うと、オブジェクトは全部同質ではなく、少なくともエンティティ、コントロール、バウンダリのような区分ができて、エンティティはデータを持つだけなのでメソッドの引数にコントロールやバウンダリを取らないとか、コントロールは処理をもつだけなので状態をもたず関数のまとまりになってレイヤーをつくるとかの話をしてます。
バウンダリは状態遷移を管理しつつ実装を切り替えるので継承をベースにするオブジェクト指向がハマります。GUIが流行ったのでオブジェクト指向が流行って、GUI部品はバウンダリなのでその特性がソフトウェアパーツ一般の特性と勘違いしてしまったのがオブジェクト指向が神話になる要因だったかもなぁ。
あと、「オブジェクト指向」としてわざわざ話すのであれば「オブジェクト指向」固有の話にならないと実務的な意味がないので、「うまくソフトウェアを作る手法」でオブジェクトがからまないんだったらソフトウェア工学を見ればいいし、「ナニカにメソッドを呼び出す(メッセージを投げる)ならオブジェクト指向だ！」「ソフトウェア全部オブジェクトだからオブジェクト指向で！」みたいな話は、結局実際にはオブジェクトに依存しないそこに適した技法で考えることになるよね、と。
そういう話をするために、クラスとか継承とかの説明を丁寧にやってるので、「オブジェクト指向やりたい！」という人にもいいと思います。
ということで、そういう考え方もできるな、くらいに読んでもらえれば。
最後に、スペースがなかったので入らなかった、みんな大好きイヌネコクラスの図を載せておきますね。
ChatGPT、すごいですね。
Javaは素晴らしいという歌も作ってくれます。すばらしい。
Java素晴らしいという歌を作ってもらいました。https://t.co/Dx94koO2ti pic.twitter.com/E4tWK5FbeM
— きしだൠ(K1S) (@kis) 2022年12月1日
プログラミング関係ではいろいろ助けになりますね。
基本的なコードの生成や、その解説までやってくれます。
SimulaとかAIDAとか古い言語のサンプルコード作るのが便利でした。
ぐぐってもなかなかコード例が出てこない言語のサンプルコードを見るのに便利 pic.twitter.com/JbDACwO9zU
— きしだൠ(K1S) (@kis) 2022年12月2日
正規表現はおそらく専用処理で解析してる気がします。
ただ、「123_45678world.md」はマッチしますね。
こんな感じで、ChatGPTは微妙なウソを織り交ぜてきます。
線形合同法のコードも書いてくれますね。
実行結果も出してくれる！
と思ったけど、modulesが2**16だと65535より大きい数字は出ないはずなんで、なにかおかしいですね。むしろ、この数字どうやって出したんだろう？逆にすごい。
これも、List.of(1, 4, 2, 3)はList<Integer>になるのでstream()はIntStreamではなくStream<Integer>を返すのでmax()は使えませんね。
実際にはmax((n, m) -> n - m)などとする必要があります。
こういう、ちょっと見たらそれっぽいけど間違ってるという回答がちょくちょくあります。
ChatGPTでの回答をStack Overflowに投げまくる人がいるようで、問題になっています。
こんな感じですかね
これなんかも、たしかにスズカサーキットで130Rは一番難しいと言われていますが、右カーブではなく左カーブです。
難しい理由も間違っているし、スズカコーステイクってなんだって感じですね。
特に「スズカコーステイク」というものが「無い」ということを確認するのはとても難しいです。
こんな感じで、ChatGPTは非常にそれっぽくウソを織り交ぜてくるので、かなり気をつける必要があります。ウソはウソと見抜ける人じゃないとChatGPTを使うのは難しい。ただ、ネットのウソは論理が怪しかったり意図がすけてみえたりでウソっぽさが出るんですけど、論理は正しく前提が間違っていて悪意もないので、文章だけからはウソがわからず非常に難しいです。
レトロゲームはだいたいニトロプラスが作ってることになったり。
ChatGPTの中でニトロプラスが謎のゲーム会社になっているｗ pic.twitter.com/OTltH2XI14
— きしだൠ(K1S) (@kis) 2022年12月2日
ChatGPTのベースになっているGPT3が、大量のデータをもとに文に続く言葉を推定しているだけである以上は、正確性を出すというのは非常に難しいんじゃないかと思います。
なので、ChatGPTを使うのには正解のない創作系がとてもいいです。「ChatGPT職人の朝は早い」という物語つくってくれました。
あと、登場人物とかを考えてもらうのがとてもいいです。
名前も考えてくれます。ポリコレ的にどうかという感じになってますが。
主人公とのエピソードとか
事件も考えてくれる！
ということでみんなもChatGPTで物語つくろう！
追記：発言には「知らんけど」をつけてもらうのがいいと思う。知らんけど
JJUG CCC 2022 Fallで「Javaの入門が終わったら何の勉強をすればいいの？」という内容で発表を行いました。
基本的なものが作れるようになったけども、イマイチプログラムが組めないというときに、何を勉強すればいいかをまとめました。
入門が終わって作りたいものがあれば作っていきましょう、業務で言われたものが作って行こう、でもなんだかちゃんとしたものが作れないな、もっとちゃんとしたものを作りたい、次のステップに進みたいというときに勉強していく感じです。
資料はこちらです
とりあげた本についてまとめておきます。
フレームワークは入門でやってる前提です。Java入門書「プロになるJava」ではJavaの基本から簡単なDB操作、Spring Bootまで取り上げてます。
まず最初に、ユーザーは直接的にはコンピュータに載ったプログラムを動かすことでサービスを体験するので、プログラマが直接ユーザーと関わることはないし、プログラムですら直接使われるわけではありません。
そこでプログラムがどのように動いて、そしてそのプログラムをどのように作るか、そのために全体としてどういう知識が必要になるか、というイメージを持つことが大切です。
このエントリではいろいろな本を取り上げますが、どのような分野が必要になるかを把握して、本屋さんに行って自分のレベルに合う本を選ぶのがいいのではないかと思います。
何を作るにしても必要になるプログラミングの基本です。作りたいものを作ればいいとコメントがありますが、ここで取り上げている基礎を勉強すると「作りたいもの」自体のレベルもあがっていくと思います。
ここで取り扱う内容はコンピュータサイエンス、計算機科学といった分野としてまとまっています。つまり、コンピュータサイエンスをまんべんなくやりましょう、という話なんですが、それっぽいタイトルの本にだいたいまとまっています。
ただ、コンピュータサイエンスというタイトルの本は細かく正しく書かれていて分厚く読みにくかったりするので、応用情報技術者試験の本が読みやすいです。ただし、受験対策ではなく内容理解のための本が大事です。しかし受験対策のほうが人気がある。
高橋麻奈さんの本がオススメなのですが、受験対策には向いていないので紙版は出なくなっていますね。Kindle Unlimitedで読めるので、サービス利用者は追加の課金なしに読めます。
資料とは順番違いますが、先にプログラミング言語を。
プログラマが直接関わるのはプログラミング言語を利用して書くソースコードです。
入門書はとにかく動かせるようになることに主眼が置かれるので、細かい条件や背景などは省略されがちです。けれども入門が終わったらもう少し突っ込んだ解説が必要になります。
Javaでは「Java本格入門」を挙げています。
ただ、もっと突っ込んだ勉強をしようとするときに、言語仕様などを読む必要が出てきますが、言語仕様を読むためには「プログラミング言語」というものがそもそも何かということを知っておく必要があります。
そこで入口として、命題論理、述語論理などの論理学から、ラムダ計算、型付ラムダ計算という流れで勉強するのもいいかと思います。
そして、型理論です。「型システム入門」という本がありますが、あまりオススメしません。型理論を本格的に勉強するには必ず読まないといけない本ですが、広く勉強する一部としては専門的すぎます。
そこで「プログラミング言語の基礎知識」をおすすめします。この本は「型システム入門」のダイジェストのような本で、たったの176ページ！ただし、３行読むのに1時間かかったりします。
先にコンパイラを作ってみるというのも手です。「ふつうのコンパイラをつくろう」ではJavaCCを使ったパーサーをもとにx86コードを出力するコンパイラを作っています。ただ、ネイティブコンパイルするものではなく、インタプリタだけ作ってもいいと思います。
プログラミング言語がわかったら、次はプログラムを実行する環境です。
Javaであれば、JVMがどのように動くか、特にJITとGCについて理解しておく必要があります。「Javaパフォーマンス」にはそのあたりがよく説明されています。チューニングの話まで進むと難しくなっていきますが、概要の説明はそんなに難しくないです。
OSもプロセスまわりは把握しておいたほうがいいけど、「入門コンピュータ科学」での説明くらいでいいかな。
読むならこのあたりを。仮想化やコンテナまで触れられてます。
プロセッサについては「プロセッサを支える技術」を挙げていたけど、より範囲の広い「コンピュータアーキテクチャ技術入門」がいいかもしれない。コンピュータの処理を理解するために、パイプラインやキャッシュといった仕組みは知っておく必要があります。
機会があれば、FPGAでハードウェアをいじくってCPUを作ったりすると、コンピュータが動くイメージの解像度がかなり高くなります。
サービスを構築するときに、いろいろな役割のサーバーが必要になります。その中でもリレーショナルデータベースは重要なので、ちゃんと勉強しましょう。
まずは正規化などのテーブル設計を確認しておきましょう。
また、リレーショナルデータベースがどのように動くかというのは、NoSQLデータベースにも応用ができるので、ひととおり知っておくといいです。
この本はMS SQLサーバーの仕組みですが、大枠はどのRDBMSでも同じなのと、ここまで読みやすくデータベースの仕組みを解説した本も他にないので、読んでおくといいです。
資料にあげてたRDBMS解剖学は絶版で中古も高い・・・
あとは「ソフトウェアアーキテクチャの基礎」に運用も含めて細かく解説されています。
サーバーを構築して複数のコンピュータを連携させると、必ずネットワークで通信します。
「ネットワークはなぜつながるのか」には、イーサネットや光ケーブルといった物理層やTCP/IPなど通信プロトコルがまとまっているので、一度読むといいです。
「プロになるJava」ではソケット通信でHTTPクライアント・サーバーを構築するサンプルを載せているので、実装してみるといいと思います。
プログラムを動かす環境を理解して、プログラムが書けたとしても、それをコンピュータに載せなくてはユーザーは使えません。
そこで、プログラムをコンピュータ上に配置するデプロイの作業が必要になります。
いまではソースコードから実行ファイルを作成してサーバーに配備する手順は複雑化しているので、自動化が大切です。そして、作ったものをなるべく早く使ってもらってフィードバックを得る必要も出ているということで継続的インテグレーション(CI)という考え方が必要になります。
また、作ったプログラムを公開するときには、プログラムが変な動きをしないかどうか確認する必要があります。このような作業をテストといいます。ユニットテストで自動化することも大事ですが、そもそもテストというのはどういう作業かということも知っておく必要があります。
「プログラミングに数学は必要か？」のような議論が起きたときに、「物理シミュレーションを組むなら微分積分必要だろうけどアプリケーションによるのでは？」のような話をする人がいますが、離散数学はコンピュータの動作の基礎でもあるため、アプリケーションによらず必要です。離散数学は、とりあえずどういう内容を扱っているかを確認しておくといいと思います。
集合や論理に関しては、「論理と計算のしくみ」で扱われているので、そちらを見てください。
論理については野矢先生の本を見ておくのもいいですね。論理はプログラミングにとどまらず全ての事柄について、正しく考えるために必要です。
また、グラフ理論も重要なのでちゃんと勉強しておくほうがいいですが、この本は物語になっていて読みやすいです。
ソート、探索といったアルゴリズム、そしてアルゴリズムの設計法も大切です。
指摘があって確認したのだけど、データ構造やグラフといった話題を扱っているこちらのほうがいいかも。
アルゴリズムに関してはトレーニングも大切なので、LeetCodeのeasy問題をひたすらやっていくとかも大事です。
https://leetcode.com/problemset/algorithms/?difficulty=EASY&page=1
計算可能性の話は、「数学ガール/乱択アルゴリズム」をおすすめします。
物語の冗長性がまだるっこしい人はこちらを。
「計算理論の基礎」は絶版か・・・
あと、「プロになるJava」では、プログラムの複雑さを分解して順に練習していくというサンプルをやっています。知る限り他にはないアプローチなので、難しい処理が書けるようにならないという人は、Javaではない言語ででも書いてみるのもいいと思います。
さて、プログラムやコンピュータの動きが把握できたとしても、ユーザーがやりたいことを実現できなければ意味がありません。
その入口になるのは、ユーザーの要件をまとめる要件定義です。「はじめよう！要件定義」は読みやすくよくまとまっていておすすめです。
要件が固まったらそれをシステムに実装できるよう詳細化を行う必要があります。そのための手法としてDDDが定番になっていますが、エリック・エヴァンスの本は「そのエピソードに２ページ要る？」みたいなのが多くて読むのがつらいので、最初はこのあたりを読むのがいいと思います。
あと、DDDは具体的な作業どうするん？というのがわかりにくいので、ICONIXというユースケースとロバストネス図を基本にした分析手法を知っておくといいかもしれません。
業務システムの場合は、業務知識の概要があるといいです。
Webサービスにしても販売管理、流通管理、生産管理などは裏側で必要になることが多いです。
開発プロセスとしては、いまやアジャイルが当たり前になっていますね。
「カイゼンジャーニー」はひとりから始めてチームにアジャイルプロセスを浸透させていく話で、読みやすく実用的でいいです。
同じ著者たちの「いちばんやさしいアジャイル開発の教本」は、アジャイルについてもっと知りたい場合にいいと思います。
また、いまは共同作業にGitHub(or 代替サービス)が不可欠です。GitHubよくわからんな人は、よこなさん、しょぼちむさんの本を読んでおきましょう。
勉強することが、とにかくたくさんありますが、期限が決まっているわけではなく10年15年かけて勉強していけばいいので、じっくりゆっくりやっていけばいいと思います。
最初にあげた絵を地図として、いつか全部わかるようになろうという意思をもって日々いろいろやって少しずつでも近づいていけば、そのうちいろいろわかるようになっていると思います。
前のブログで、「適当に言ってるだけ」「分析がちょっと雑」というコメントがついていた。
でも物事を適当じゃなく言ったり雑ではない分析をするには、最初に適当に言ってみることや、雑な分析を出してみることが大切だと思う。
まず、人に読ませる前提で書き下ろすことが思考の整理につながる。
そして、具体的に思考を形にすることで、それに対するフィードバックが得られる。
「くだらない」というコメントが付くことでも、「このテーマに期待している人がいる」ということがわかる。そうすると、もう少しちゃんと考えてみるか、ということにもつながる。
そうやって、思考というのはフィードバックを得ることでどんどん形が作られていく。
自分だけではなく、他の人もこのエントリを見て何か別の意見を書くかもしれない。コメントもそういった意見のひとつだし、そこから考えを広げていく人がいるかもしれない。
思いついたけど詳細は他の人に考えてもらいたいような内容を書いておくと、興味をもった誰かが、自分が書くよりもすばらしい記事を書いたりする。
幸い、技術系のブログでは否定的な意見にしても ちゃんと記事の内容をふまえたものばかりで、個人攻撃のようなコメントがつくことはないので、ブログを書くことのデメリットはほとんどない。
ということで、考えたことを公開することは、自分やその周辺の思考の向上につながるので、適当でも雑でも内容がないようなものでも出していくのがいいんじゃなかろうか。
ところで、この本には、人の脳はだれかに向けて言葉を考えるときに より活性化するというようなことが書かれています。
次のように、推論=思考は社会的にやるべきという話がいろいろな視点でまとめられてて面白いです。
人間は、 他人に自分の考えを納得させたり、他人から騙されたりしないように進化しました。言い換えると、推論は社会的な活動であり、そのように行われるべきなのです。
Twitterを買収したイーロン・マスクが週80時間勤務に備えろといって、それができないなら退職という話をした結果、エンジニアを含め社員の多くが辞めたという話がでてます。
https://jp.reuters.com/article/twitter-departures-idJPKBN2S806D
イーロン・マスクとしては、Teslaのようにハードに働く少数精鋭のチームを作りたいようです。
9.3/ 優秀な小規模チームを作るのが大事だと行っていて、TeslaのAutopilot AIチームにいる150人のエンジニアは競合の3,000人のエンジニアチームに勝っているとイーロンは語る
— Tetsuro Miyatake (@tmiyatake1) 2022年11月11日
ただ、TeslaやSpaceXは製造業で、たとえばSpaceXならロケットを安く確実に作るというように、作るものは基本的に決まっているプロダクトで、要求が超シビアな中でどのように作るかが問題になるのでそれがハマる面があるんではないかと。
SNSは作るものは決まっておらず、市場を見ながら自分たちで作るものを決めていく必要があります。要求も自動運転車やロケットのようには高くありません。
※末尾に追記で3社のミッションについてを挙げています。
あとTwitterのような巨大サービスは、イーロン・マスクの言うような超優秀な精鋭だけで運用するのは難しく、そこそこ優秀な多くのエンジニアが必要になる傾向があります。規模の大きいサービスでは必ず障害が発生します。少数の精鋭だけだと、日々発生するトラブルの対応に追われて機能開発ができなくなります。
そうすると、同じエンジニアリングの哲学を適用するのは難しい気がします。
追記 2023/2/27 残念ながらここに書いたとおりになっている気がします。
イーロン・マスクの要求に応えるためTwitterのシステムアップデートが必要だが社員をクビにしすぎたせいで「死のスパイラル」に陥りつつある - GIGAZINE
追記 2023/5/29 スペースの担当が3人しかいなくて大統領選出馬表明にトラブル
Twitterスペースでの大統領選出馬表明が失敗したのは「イーロン・マスクが100人いた担当者を解雇しまくって3人まで減らしたから」という指摘 - GIGAZINE
以降は投稿当日の追記
追記
ところで、くだらない記事だというコメントついてますが、こういうエントリ書いてますね。
くらだないブログエントリの素晴らしさについて - きしだのHatena
さらに追記(19:50)
考えまとまってないなぁとか、特にたいしたこと書いてないなぁとか躊躇してブログ書かずTwitterだけで終わってたら、はてブのコメントに書かれてるような視点は得れなかったわけです。
そして追記(21:30)
たとえばTeslaのミッションは「太陽光発電で動く電気自動車を広めて持続可能な社会を作る」、SpaceXのミッションは「人類を多惑星化する」「火星や他の惑星に人を送り込めるこれまでにないパワフルな打ち上げロケットを作る」です。
これらを実現するために必要なことのすべてがわかるわけではないけど、「品質のよい電気自動車を安く作る」「ロケットエンジンの出力をあげる」などは必要かつ目的に近づきます。
一方で、Twitterのミッションは「世界に関するもっとも正確な情報源になる」と言っていますが、そのために何が必要か、なにを作れば近づくかはよくわかりません。候補は挙げれても、TeslaやSpaceXのようにハッキリと納得できるものにはならないと思います。
https://twitter.com/elonmusk/status/1589413653190938624
これがTeslaやSpaceXで作るものが決まっていて、Twitterで作るものが決まっていないという話が表す事柄です。
実際にElon Muskも「これから変な機能をたくさん追加するだろう。そしていいものは残すし、ダメなものはすぐ消す」みたいなことを言ってます。
また追記(23:30)
ブログは議論のたたき台で、とりあえず出していろいろ意見もらって、こうやって追記していい感じにまとめていくのがいいと思ってます。
ついでに追記(11/20 12:30)
ブログは議論のたたき台ってことをまとめた
