ITはもう面白くなくなってますね。 技術が面白いときには、いろいろ新しいものが出て性能あがったりできることが増えたりします。調べたらどんどん新しいものが出てくるし、新しいものもたくさん作るし、面白い。ですが、IT技術は一通り出そろって、成熟期に入っています。そうすると新しい技術に出会うことも新しいものを作ることも減っていきます。その結果、いままでの変化のあった状況を知っていれば、つまらんってなりますね。 ※2024/8/24 追記 言いたいことをまとめると、IT素振りのネタ探しに苦労するようになったよねってことです。 結局のところITというのは新しいハードをどう動かして社会に実装していくかというものなので、新しいハードが出ないとどうしようもないのです。けれどもだいたい飽和してしまった。 雑にいえば、これまで1980年くらいにBASIC搭載8bitパソコンが普及するとBASICプログラミング

「設計書」というのは、作るものの構造を抽象的に表現したものと言うことができます。 ただ、ソフトウェアの抽象化の仕組みはプログラミングコード自体に備わっているので、ソフトウェア生成可能な抽象的表現というのはコード表現ができるはずですね。コードで表現しておくと、整合性のチェックとかも行いやすいです。 でも、コードではない「詳細設計書」というものが一部業界には必要とされているので、その「詳細設計書」というのは実際はなんなのか考えてみます。 ※ 最初はタイトルは「設計書」としてましたが、話を限定するため「詳細設計書」に変更しました。 追記：納品物に関する記述を追加しました。 表現を変えたコーディング ソフトウェア生成可能な抽象的表現というのはコード表現ができるわけですが、文字で表記する必要もなく、ダイアグラムで表現することもできますね。 代表的なのがER図やクラス図で、これは文字表現との相互変換が

いわゆる「ソフトウェア設計書」が設計ではなく、ソースコードが設計であるという話。 随筆です。考えマトメ中なので、ツッコミはそのあたり踏まえていただければ。 追記：ブコメに「設計の定義は？」とあったので末尾に追加しています。 追記(2024/8/15)：設計書ってなんだろう？というのも書いておきました。 ソフトウェアの「設計書」とはなんなのか - きしだのHatena このエントリで書いたのですけど、もうすこしちゃんと。 建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？ - きしだのHatena このエントリでは次のように書いています。まあ、これで全てではあるのだけど。 「建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです」 あと「継続的デリバリーのソフトウェア工学」からの抜粋。 「継続的デリバリーのソフト

建築では多重下請けでやれてるのに業務システムでだめなのはなぜ？という質問がブコメであって、似たような話もいくつか見かけたのですが、建築などの施工図面に相当するのはソースコードで、建築現場で多重下請けでやってる作業は、ソフトウェアだと(でも？)ビルドです。なのでソフトウェアでは自動化されています。 もしも業務システムの納品物が、バベッジの階差機関のような歯車を組み合わせた機械式の計算機で、ビル一棟分に歯車をつめこんで組み立てて納品するというようなことになれば、多重下請けで分業してビルドするのが最もよい方法ということになると思います。 追記 「継続的デリバリーのソフトウェア工学」では、「ソフトウェア開発を選んだ私たちがバカでない限り、私たちにとっての製造とは、ビルドボタンのクリックです」とあります。橋梁建設を例に、物理的な製造・生産との違いが説明されています。 継続的デリバリーのソフトウェア工

多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。 多重下請けでは、上位受け会社の「SE」が「設計」を行い、下位受け会社の「PG」が実装を行うという役割分担があります。というか、今回の話はそういう役割分担がある多重下請けを前提とします。 そうすると、設計というのは会社間をまたがった契約文書であり、発注のための作業指示書であるということになります。ソフトウェア開発で本質的に必要な文書というよりは、ビジネス構造によって必要になったビジネス文書です。ちなみに派遣ではなく業務委託のはずなので詳細な作業指示になってはいけないのもポイントです。 ※余談ですが「設計は必要である」という人の話をきいてみると、必要なのは実装のための設計ではなく保守のためのドキュメントということがほとん

この連休はなんだかSIerについて考えることが多かったのですが、そういうことを考えると、なぜアメリカのソフトウェアが強いのかがわかってきた気がします。 まず、もちろんSIerの技術力が低いといっても技術力が高いSIerもいるわけで、とくにこのブログを見てる人だと技術力の高い側にいる人が多いと思います。 けれども、DX白書2023によればSIerのIT人材というのは75万人いて、技術力の高い人はその一部で、多くは技術力の低い側にいるんじゃないでしょうか。 https://www.ipa.go.jp/publish/wp-dx/gmcbt8000000botk-att/000108046.pdf 2014年、ちょうど10年前に、プログラマはSIerと自社サービスで2分化するんではないかというブログを書いていますが、そのまま現実になった形です。 プログラマ業界の二分化 - きしだのHatena

オブジェクト指向の本では「自転車をモデリングしてみましょう」「鳥をモデリングしてみましょう」ということが、どういうシステムで使うか規定せずによく書かれています。 けれども、モデリングではどういうシステムで使うかということが大事で、それを決めずにモデリングを考えても意味がありません。モデリングすべきはモノではなくシステムのプロセスです。 よく、オブジェクト指向では現実をモデリングするのようなことが言われますね。 例えば鳥が鳴くとして、その一種であるニワトリをどうモデリングするか、ということを考えるとします。 そうすると、まず void 鳴く() { print("コケコッコー"); } のようなメソッドを考えるのですけど、コケコッコーとうまく鳴けるのは鳴き慣れたニワトリです。そのため、鳴くメソッドにカウンターを用意してどんどんうまくコケコッコーになるようにしたくなります。 いや、そもそも、コ

あいかわらず掛算の順序の話がもりあがってるようなのだけど、コーディングルールの話なんだから計算の定義の話をしても徒労だよなと思いながら見ていた。 で、ちょっと教育指導要領解説を見てみたのでまとめる。 学習指導要領解説の記述 「【算数編】小学校学習指導要領（平成29年告示）解説」では次のようになっています。順序は表現のときの問題で、計算では交換則を使っていいとなっています。 被乗数と乗数の順序は、「一つ分の大きさの幾つ分かに当たる大きさを求める」という日常生活などの問題の場面を式で表現する場合に大切にすべきことである。一方、乗法の計算の結果を求める場合には、交換法則を必要に応じて活用し、被乗数と乗数を逆にして計算してもよい。 このPDFの115ページ。 https://www.mext.go.jp/content/20211102-mxt_kyoiku02-100002607_04.pdf

この文章みてください。 オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかはオブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな…… 「またお前、オブジェクト指向の話をしてるのか」と思ったかもしれませんが、2010年

報道ヘリがうるさくて救助の邪魔になるという話はどう広まったのか、というのを調べてみていたのでメモ そもそもとして「報道ヘリがうるさくて救助の邪魔になる」ということなんてあるのか、という話は、1995年1月17日の阪神淡路大震災にさかのぼる。 震災後6日後に収録されたと言われる1月27日放送の「パペポTV」で上岡龍太郎が次のような発言をしていた。 取材陣のヘリコプターがあの被災地の上を飛び回るでしょう。あの爆音のために、生き埋めになってる人に外からどんなに声かけても、その人たちの声が爆音のために聞こえない 救助の邪魔になるという話 以外にも、被災者から「自分が見せ物にされている」というような苦情もあったようだ。救助ヘリの邪魔になる高度を飛ぶようなこともあったらしい。 これは実際に問題だったようで、その後1997年に日本民間放送連盟から「航空取材ガイドライン」が出されて、報道ヘリがある程度の高

オブジェクト指向言語の話をするときに便利なように、Javaを中心にプログラミング言語をまとめてみました。 Javaに影響与えるか、Javaから影響を受けるか、という感じですね。 Simula オブジェクト指向はここから始まったと言われています。 クラス、オブジェクト、継承、仮想関数(多態)といった、オブジェクト指向の基本要素が備わっていました。 ただし、「オブジェクト指向」という言葉は生まれていません。 Smalltalk Simulaから発想を得て「オブジェクト指向」という言葉を生んだのはアラン・ケイでした。 しかし、モデルとしてはSimulaとは異なりメッセージングを主体としたものでした。また、アラン・ケイの「オブジェクト指向」はプログラミングのパラダイムだけではなく、人がコンピュータをどのように扱うかというメタファであり、ダイナブックというハードウェアやそのユーザーインタフェースを含

先日のJJUG CCC 2023 Fallの懇親会でクソコードを研究しているという学生がいたのだけど、クソコードの研究は難しいという話をした。 人工的にクソコードを再現しても、あの野生のクソコードのクソさには全く足りないわけで。 トルストイが言うように「すべてきれいなコードは互いに似通っているが、クソコードはそれぞれにクソの趣を異にしているものである」なので、なかなか「これがクソコード」のように類型化するのも難しい。 典型的なクソコードを書いてみても、なんだかきれいなクソコードができてしまう。 クソコードはネットに出回らないので、資料の収集もまた難しい。ネットにないということは、ネットの情報に基づいている「AI」もホンモノのクソコードには触れていないことになる。 クソコード収集サイトをつくっても、実際のクソコードは業務固有処理も含まれるので、掲載できる形に整理していくと本来のクソさが薄れて

ChatGPTが画像対応して、画像からいろいろなコードが生成できて楽しいことになっていましたが、同じようなことをおうちで動かせるLLaVAが出ていたので試してみました。 GPUはVRAM 12GBあれば十分、8GBはギリギリという感じ。 LLaVA-1.5 先週、LLaVAのバージョンアップ版、LLaVA-1.5が出てました。 🚀 LLaVA-1.5 is out! Achieving SoTA on 11 benchmarks, with simple mods to original LLaVA! Utilizes merely 1.2M public data, trains in ~1 day on a single 8-A100 node, and surpasses methods that use billion-scale data. 🔗https://t.co/y0k

アマチュア驚き屋のきしだです。 ChatGPTが画像入力に対応するよという話があって、来週くらいに使えるようになるかなーと思ったら、もう使えるようになってました。 で、写真から「カレー食べてる男の人です」くらいを言えるイメージで試してたら、なんかふつうに画面設計やクラス図からコードを書いていてびっくりしてしまいました。 まあ、起きたらこういうのが来てたわけですね。 で、まあ試してみて「あぁ、いままでのマルチモーダルよりちゃんと画像認識してるなー」くらいに思ったわけです。 で、NetBeansでの画面設計を読ませてみたらこう。 こういうコードが生成されました。 import javax.swing.*; import java.awt.*; public class SimpleForm { public static void main(String[] args) { JFrame fr

ChatGPTによるメンバーで構成された仮想のソフトウェア会社にシステム開発を行ってもらうChatDEVが結構おもしろかった。 ChatDEVは、ChatGPTによってCTOやプログラマー、レビュアー、テスターといった役割をもつエージェントをやりとりさせることでソフトウェア開発を自動化しようという試みの実装です。 https://github.com/OpenBMB/ChatDev アイデアは論文にまとまっていて、こちらで概要が翻訳されています。 [LLM 論文]アプリ全自動開発"ChatDev"の日本語訳｜すめらぎ 使い方としては、とりあえずClone git clone https://github.com/OpenBMB/ChatDev.git そして依存モジュールのインストール cd ChatDev pip3 install -r requirements.txt あと、OpenA

鈍器が届いたんですよ。 カード履歴みてたら昨日13,200円の見覚えのないAmazonからの請求があって、「本でもなさそうだしAmazon見ても履歴ないし謎い」とか思ったら宅急便がきて。。。 まあ、注文してた「コンパクトデータ構造」が来てたわけだけど。 asin406512476X:detail 予約したのが6/16で直近の履歴を見てもなくて、そして今日が発売日なので昨日決済されて発送された、ってことらしい。 紙が固めでめくりやすい。というか、めくるのが楽しい。変なデータ構造がいっぱい載ってるのもよい。図も多いので、絵本みたい。内容的には読むの大変そうだけど、落ち着いてゆっくり読めば大丈夫そう。 内容としては、圧縮した状態でいろいろ操作ができるデータ構造を考えようぜ、という感じ。 Wikipediaだと「簡潔データ構造」の項目を見ると載ってる。 と思ったら、こういう本があった。 簡潔データ

OpenAIのFunction Callingが出たときに、GPTを使って自然言語でツールを操作するというのをやったんだけど、この程度にGPT使う必要なくない？という感じもしたので、GPTなどLLM使わずに実装してみました。 LLM使わずに実現できることはLLM使わないほうがよさげ。 前回のブログ、これです。 こんな感じで動くようになっています。 ツールのテキスト操作にGPTなんかいらんかったんや！ サクサク動くわ。 pic.twitter.com/JAD3grWJGx— きしだൠ(K1S) (@kis) 2023年7月1日 GPT4使ったときはこんな感じ OpenAIのFunction Callingでツール操作を試すやつ、GPT-4だとかなり文脈を理解してくれるし、位置関係も結構ただしく扱ってくれる。しかし遅い。 pic.twitter.com/nkijZpcnP6— きしだൠ(K1S

先週、OpenAIから、APIでの返答に関数呼び出しのパラメータを返してくれるFunction Callingが発表されました。 試してみると結構たのしかったのでまとめてみます。 解説動画はこちら youtu.be とりあえず、こんな感じ。 OpenAIのFunction Callingでツール操作を試すやつ、GPT-4だとかなり文脈を理解してくれるし、位置関係も結構ただしく扱ってくれる。しかし遅い。 pic.twitter.com/nkijZpcnP6— きしだൠ(K1S) (@kis) 2023年6月19日 用意したのは３つの関数。 set_position(id, left, top) set_size(id, width, height) set_color(id, color) で、その割に、「中央に」だとか「隣に」だとか、コンテキストを踏まえて座標などを計算して関数を呼び出して

ちょっと前に「配列中のすべての要素が条件を満たすかどうか判別する関数で、空の配列はTrueを返すべきかFalseを返すべきか」のような話が話題になってました。 まあこれは「Trueを返す」が答えなわけですが、では「配列中の最大値を返す関数で空の配列の場合は何を返すか」が気になりました。 「配列中のすべての要素が条件を満たすかどうか判別する関数」について言えば、簡単に言えばこんな感じ。 まず、配列のすべての要素が偶数であるかどうか判別する関数を考えます。 void main() { int[] data = { 23, 44, 12, 98, 5 }; System.out.println(allEven(data)); } boolean allEven(int[] data) { for (int n : data) { if (n % 2 != 0) return false; } r

前のブログでも紹介したのだけど、ChatGPTプラグインのローリングアウトが始まって使えるようになっていて、結局みんな使うのはこの3つくらいかなーとなったので、まとめておきます。 前のブログはこれ。 Bardも世の中のサービスぜんぶGoogle製と思ってるらしい - きしだのHatena 同時に使えるのは3つまでのようだけど、他のプラグインはアメリカの不動産情報など日本からは使いづらかったり、作ってみたレベルだったりなので、結局この３つに落ち着くかなーという気がします。 WebPilot これは手放せなくなります。Web記事を読み込んでくれるプラグイン。 ChatGPTには「この記事を要約して」しか入力しなくなりそう。 このエントリを要約してもらっています。 大規模言語モデルの「脳波」が反応してる部分を壊すとどうなるか試した - きしだのHatena ※ 追記 15:21 ぼくのところには