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

多重下請けではエンジニアが育たないという話を前回のブログで引用していたのですが、そもそも多重下請けではまともなソフトウェアは開発できないんではないかという気持ちになりました。 多重下請けでは、上位受け会社の「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

ま、このくらい知っておいてもらわないと&とりあえずこんだけ知ってればだいたいの処理が書けるクラス・インタフェースをまとめてみました。2024年版。 詳しく知りたい人は「プロになるJava」を！ java.lang.Class java.lang.Exception <- new java.lang.Integer java.lang.Object <- new java.lang.Runnable java.lang.String java.lang.System java.lang.Thread java.nio.file.Files <- new java.nio.file.Path <- new java.io.InputStream java.io.InputStreamReader java.io.BufferedReader java.io.OutputStream java.

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

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

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

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

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

コミュニティノート、案の定暴走している。 どんな改悪、利用制限よりも大きくTwitter*1を壊してるんじゃなかろうか。 ※ 2024/3/12追記 コミュニティノートの、「追加の背景情報が必要ない理由を説明するノート」がうまくまわって、初期に見られた正義の暴走のようなノートは表示されないようになってきています。 コミュニティノートは、多数派に有利な仕組みです。 「コミュニティノートでは、さまざまな視点を持つユーザーにとって役に立つノートが特定されます」 となっていますが、多数派であればさまざまな視点を持つユーザーが確保しやすく、逆に少数派は視点が収束する傾向があるので不利になります。 そのため、なんらかの不満をもっているけどその不満を表明して言葉にするとだいたい間違っているという層には非常に居づらくなっています。 「間違ったツイートをしなければいい」のような発言をみかけるけど、裏を返せば

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

研修がはじまるという画像でサーブレット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年

ちょっと前に「配列中のすべての要素が条件を満たすかどうか判別する関数で、空の配列は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 ぼくのところには

やっぱGPTを仕組みから勉強したい、という本をいくつか見つけたのでまとめておきます。 まず理論的な概要。 機械学習からニューラルネットワーク、CNNでの画像処理、トランスフォーマーでの自然言語処理、音声認識・合成、そしてそれらを組み合わせたマルチモーダルと章が進むので、理論的な概観を得るのにいいと思います。 最初は数式が多いのだけど、Σをfor文だと思いつつ、定義が説明文中に埋まってるPerlよりたちが悪い記号主体言語だと思えば読めるけどめんどくさいので飛ばしても問題ないと思います。 深層学習からマルチモーダル情報処理へ (AI/データサイエンスライブラリ“基礎から応用へ” 3) 作者:中山 英樹,二反田 篤史,田村 晃裕,井上 中順,牛久 祥孝サイエンス社Amazon で、もういきなり作る。 トークナイザーから全部つくっていきます。TensorFlowでBERTをつくってGPT2をつくる

ChatGPTのおかげで非エンジニアでもコードが書けるようになるということを多くの人が言ってますが、すでにエンジニアである人にあてはめると、ChatGPTのおかげで専門分野以外のコードでも書けるようになるということで、つまりすべてのエンジニアがフルスタックになるってことじゃないかと思います。 ChatGPTにコードを書いてもらうと毎回びっくりする いや、ちょっとJavaで袋文字の描画ってどうやるんだったかなーと思ってChatGPTに問い合わせたら、ほぼ完全なコードをリテイク1回で生成したんですね。 こいういうコードが出きました。createGlyphVectorとか知らんわ！ // 文字の縁取り g2d.setColor(Color.BLACK); g2d.setStroke(new BasicStroke(5)); // 縁取りの太さを調整 g2d.draw(font.createGly

2010年代前半にKotlinが2011年、TypeScriptが2012年、Swiftが2014年、Rustが2015年と、新しいプログラミング言語が立て続けに発表されていましたが、そこを最後にみんなが話題にするような言語は出てきていません。 なんでだろうと、思いつく要因をあげてみます。 ※ 追記2023/5/11 わざとなのか「みんなが話題にするような」を無視してツッコミ入れてる人いるのだけど、言い換えれば「新しい言語が出てもみんな話題にしない」という話です。 プラットフォーム用の言語が出そろった Kotlin、TypeScript、Swift、Rustが2010年代前半に出てきましたが、これはJVM(Android含む)、ブラウザ、Appleデバイス、ネイティブといった代表的プラットフォームでほどほどの言語が出そろったということではないかと思います。 結局のところプログラミング言語は

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

ChatGPTで文章を要約したり口調を変えたりゲームのルールを教えてゲームを遊んだり、みんな いろいろな使い方や楽しみ方をしていると思います。 中にはプログラミングにあまり縁のない人も多くいます。 これ改めて考えると、自然言語でコンピュータを操作指示できるようにしたということで、インパクトすごいと思います。 たとえばこんな感じで、口調の調整を行っている人はよくみかけますね。 これ、よく考えるとコンピュータの挙動を調整しているわけですよね。 ここでは「以降は語尾に「ンゴ」をつけてください」と指示しているだけで、この指示にはまったくプログラミング知識が使われていません。 しかも「何か質問あるンゴか？」のように疑問形の形を調整してくれていますね。適切に「！」も入れて、「ンゴ」で終わらせることに何を求めているかもくみ取ってくれています。これをプログラミングで実現しようとするとかなり大変です。 RP