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

JTC、つまりJapanese Traditional Companiesのことですが、英文法チェッカーが「Traditional Japanese Companiesでは？」みたいな指摘をしてきたり、TJCのほうが正しいという話がありますね。 英語の文章でどのような語順で出てくることが多いか数えてTJCのほうがいいのではとしているブログもありました。 けれども、ここでJTCというのは、次の日経記事にあるよう「上意下達の企業文化や硬直的な組織運営を皮肉る際に使われます」という言葉です。 JTC（Japanese Traditional Company）とは？　古い企業体質、変革を模索 - 日本経済新聞 英語でTraditional Japanese Companiesが正しいというには、それが古い企業体質を皮肉る文脈で使われている必要があります。けれどもそんな文脈はほとんどないんじゃないか

用語は形式的なものではなく感覚的なものであることをお断りしておきます。 言語・フレームワーク・プラットフォーム まず最初に触れるものでとっつきやすい。何か使えないことには話になりません。多くの人が、勉強というとまずここ。 何かすでにつかえる人が新しく勉強することは、生産性をあげない。そのプラットフォームを初めて採用するときの準備が減らせる。どちらかというと仕事の選択肢を増やす感じですね。 深く知ることは、最適なコードを書きトラブルを減らしトラブルが起こったときの対策も早くなるので、生産性があがります。ただ、ある程度の深さ以降は生産性への寄与度がさがるので、その点では深くまで勉強する必要はありません。 プロダクトの使い方なので、プロダクトの寿命が勉強成果の寿命です。実際に使わないものの勉強は無駄になるし、使われなくなったら無駄になる。寿命もそう長くないです。 「プログラマは勉強してもすぐ使わ

ここまでのあらすじ 我々の住むソフトウェア業界は、SI、サービス・パッケージ、ユーザー企業という大小３つの大陸にわかれ、時々いさかいがありながらも平和に暮らしていた。 そして、我々の住む世界とは別に、同規模の技術者が暮らす、組み込み業界という世界の存在も知られていた。 組み込み業界は、存在はすることは確かなのだが技術者の姿は見えず、そのプロダクトの存在も、わかるものにしかわからないのであった。 我々は、組み込み業界と交信できる唯一の手段、C言語を使って、その世界の住人と交信するしかなかった。 しかしあるとき、FPGAという次元ホールをみつけたワカモノ達が、組み込み業界に迷い込んでしまう。ワカモノ達の前に立ちはだかる屈強な組み込み技術者。彼らの前にワカモノたちは、あるものは倒され、あるものは捕らわれ、そして、命からがら表の世界に逃れてきたワカモノも「べり・・・ろ・・ぐ・・・」というナゾの言葉

24日の土曜日に、「きしだのはてなのあれってどうなの勉強会」やってきました。 【東京】きしだのはてな勉強会 〜「きしだのはてな」のあれってどうなの〜 - 日本Javaユーザーグループ | Doorkeeper んで、あいかわらずその場にいないと意味がわからない資料ができあがりました。 きしだのはてなのあれってどうなの勉強会 運営のmegascusさんは 思ったよりもきしださんの人気が薄かったのか人が集まりませんでした。 【東京】きしだのはてな勉強会 〜「きしだのはてな」のあれってどうなの〜をやってきた - 水まんじゅう とは書いてますが、内容もなにか具体的にわからない、参加費3000円、そしてPlay勉強会とかぶる(時間的にはかぶってなかったようだけど)という中で21人集まってもらえたのは、なかなかありがたいことだなーと思いました。 運営のmegascusさんと岡澤さん、おつかれさまでした

研修がはじまるという画像でサーブレットJSPの本が並んでて、サーブレットを最初に勉強させるのをやめてあげてほしいと思った話。 オブジェクト指向もそうなんだけど、現状で使わなくなっているにもかかわらず情報更新がされずオブジェクト指向やサーブレットJSPが教えられ続け本が売り続けられるという現状がある。 でももうさすがに変わってほしさ。 ただ、JSPはそこまで悪くないので、サーブレットで話を進める。(ただし、サーブレットが動かない環境ではJSPは動かない) 使われていない まず、いまの案件の多くがSpring / Spring Bootになってて、サーブレットをさわるということは少ない。 2020年のJetBrainsの調査ではこんな感じ https://blog.jetbrains.com/ja/idea/2020/10/a-picture-of-java-in-2020-ja/ 2021年

前回のエントリで、プログラマの業界が労働集約的なものと知識集約的なものにわかれてきているという話を書きました。 プログラマ業界の二分化 - きしだのはてな 前のエントリでは労働集約的なものと知識集約的なものに完全にわかれているように書きましたが、もちろん完全に労働集約的であったり完全に知識集約的であったりすることは少なく、どのような組織でもある程度は両方の性質をもっています。知識集約的な性質の強いSI会社というのもあります。 ただ、SIに労働集約的な、サービスに知識集約的な性質が強くなる傾向はあると思います。 また、知識集約的であればよくて労働集約的であればダメということもありません。労働集約的なSIでありながら良い会社というのもあります。 という断りをいれておかないと、SIで労働集約だからといって全部ひとからげにするなという、労働集約的なSIでありながら良い会社方面から鋭利なマサカリが飛

この連休はなんだか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

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

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

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

小さい簡単なシステムでも、工夫次第で追っ手から逃れることができるという良い例が目の前にある。 とりあえず、手法として取り入れやすいものをあげておこう。 ドキュメントは残さない 基本です。手がかりを与えてはいけません。 ドキュメントにうそを混ぜる 契約上ドキュメントを作らざるを得ない場合、実際とは違う記述を織り交ぜておきましょう。その場合でも、全体像がわかるようなドキュメントは書かないこと。 単純な処理でもテンプレートメソッドパターンなどを使って複数のクラスに分散させる 複数のクラスを見る必要があるため見通しがわるくなり追っ手から逃げやすくなる。さらに、一部の変更がどこに影響があるかわかりにくくなるため、変更も行いにくくするという効果がある。 ちょっとした処理は15行ルールの名の下、メソッドを分割する このとき別のクラスにメソッドを置くようにすると、さらに効果的。上から下に順に読めばいいよう

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

MidjourneyやStable Diffusionのような画像生成AIが出たりChatGPTが出たりで、Web3で騒いでいたところがAIに移行した感じあります。 Google Trendsだと、生成AIは完全にWeb3を抜いています。 メタバースも抜いたところ。 ChatGPTは圧倒的です 実際にニュースどうなってるか見てみると、Web3に関するニュースは4月以降は出ていないです。 ５月に一件あるのは、AI規制の話をWeb3の人が話したというもので、Web3の記事ではないです。5月はあと3日残ってるけど、そんなになさそうな気が。 3月には「Web3本格採用」のような記事が多いことを考えると、突然死のようにも見えます。 朝日新聞、INTERNET Watch、ITmediaエンタープライズ、日経xTech IT, エレキでのWeb3記事件数は次のような感じ。 去年6月に盛り上がって漸減傾

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

ChatGPTなんかの大規模言語モデルが言葉を生成しているときに、どういう反応が起きているのか気になりますよね。きっと気になる。 ということで、手元で動かせる言語モデルのニューラルネット各層での出力を表示してみました。 GPTにはGPTブロックが複数あって、それぞれのブロックが２層のニューラルネットレイヤを持っています。 モデルを読み込んだあとでこういうコードを動かしてニューラルネットの出力の二乗を足していきます。 for idx, elm in enumerate(model.transformer.h): elm.ln_1.index = idx * 2 elm.ln_2.index = idx * 2 + 1 elm.ln_1.old_forward = elm.ln_1.forward elm.ln_2.old_forward = elm.ln_2.forward def new_

ChatGPTが思いがけずいろいろなことを人間より賢くやっているのを見てシンギュラリティという言葉を使う人が増えたように思いますが、逆に、シンギュラリティは来ないのではという思いを強くしています。 まず、この文章でのシンギュラリティがなにかという話ですが、レイ・カーツワイルが「シンギュラリティは近い」の1章の終わりで「さあ、これが特異点だ」といっている特異点、そのシンギュラリティです。 シンギュラリティは近い―人類が生命を超越するとき 作者:レイ・カーツワイルNHK出版Amazon この特異点は単にAIが人間より賢くなるというだけではありません。人間より賢くなるだけだと、便利な道具が増えるだけなので、大騒ぎするほどの変化は起きません。人の仕事を奪うといっても、蒸気機関ほどでもないですね。印刷機などと並んで、人の生活を変える転換点にすぎず、ただひとつの点をあらわすシンギュラリティには なりま

ChatGPTが話題ですが、そういうのをおうちで動かしたいですよね。 ということで、おうちで動かしやすくて割と会話ができるChatRWKVを試してみます。 ChatGPTは実装は公開されておらず手元で動かすことはできません。けど、サービスがたまに落ちてたりするので手元で動かせるなにかがあると安心ですね。何より、こんな変な技術を手元で動かしたい。 そこで手元で動かせるLLMとしてFlexGenが話題になりましたが、それでも強力なGPUが必要です。 https://github.com/FMInference/FlexGen そして低リソースで動かせる実装としてAlpaca.cppなんかも出ましたが、そこまで賢くない感じ。 https://github.com/antimatter15/alpaca.cpp そこに現れたのがChatRWKVです。一般のご家庭の8GB VRAMのGPUで動かせつ

クオリアというのは、たとえば赤い色をみたときに、それがカラーコードとして同じであっても、リンゴの赤と血の赤で想起される「赤らしさ」が違うよね、そのそれぞれの「赤らしさ」とは？みたいな話です。 それがChatGPTの挙動と対応づけれるんではないだろうか、と。 ※ クオリアを解明できるという話ではありません もしくは、「りんご」と言ったときにあの赤い果物の直接的なイメージだけではなく「こないだ食べたのはちょっと固かった」だとか「スーパーで300円で並んでた」だとか「皮をむくのがめんどかった」だとかいろいろ想起されることも含めた「りんごらしさ」のことです。 正確にいえば、何かの単語や物体を意識したときに「らしさが生まれること」をクオリアと呼んでるんだと思います。 そいういうクオリアというのが結局なんなのか、というのが問題になってると思うのだけど、ChatGPTを見るとなんとなくクオリアというのが

「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を３つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が