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

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

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

「オブジェクト指向神話からの脱却」というあおり気味タイトルの特集をWEB+DB PRESS vol.132で書きました。 12/24発売！クリスマスプレゼントです WEB+DB PRESS Vol.132 作者:きしだ なおき,加藤 尋樹,斉藤 洸紀,牟田 裕太郎,吉澤 政洋,朝日 リナ,鈴木 僚太（うひょ）,川島 義隆,五十嵐 進士,末永 恭正,佐藤 雄太,吉井 健文,牧 大輔,西山 和広,吉田 花春,古川 雅大,岡林 大,池澤 春菜,和田卓人,日高 正博,はまちや2,竹原技術評論社Amazon 大まかには、「オブジェクト」でソフトウェアをぜんぶ考えるということに無理があったので、パーツそれぞれ適したやりかたでやっていこうぜ！という内容です。 ソフトウェアを切り出したときのパーツとしてのオブジェクトの特性が同質であるという暗黙の前提があって、だから「オブジェクトの話をすればソフトウェア開

定期的にオブジェクト指向disを書いてしまってるのだけど。 とりあえずオブジェクト指向の話をすると定義が人によって違いすぎるので、改めてここでの定義を書いておくと 、基本的にはOMTの「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」 に従うのですが 「1990年に流行りソフトウェア開発のすべてを飲み込み、いまとなっては人それぞれ定義が違って技術的議論に使えなくなった、主にオブジェクトを基本単位としてプログラムを整理するやりかたを指すマーケティング用語」 という感じです。 ほとんどの場合で人によってオブジェクト指向の指す範囲が違いすぎて、技術的知見の共有には使えなくなっています。でも、いずれの定義にしろオブジェクトを基本単位にするというのは重要ではないかと。 ソフトウェアの組織化の単位としてオブジェクトを使うというのが大事で、データの搬送に構造体代

某所でオブジェクト指向についていろいろ書いたのでまとめておく。 問題意識としては初学者がなにかというと「オブジェクト指向できるようになりたい」のようなことを言うけどそこまでの優先順位でがんばるものではないんでは、というところです。 まず前提として、オブジェクト指向は1980-2000年くらいに流行って発達したものの、それ以降は時代にあわせた進歩はしていない20年以上前の技術ってのがあります。 そのころは今だとCPUのキャッシュにも満たないようなメモリをやりくりしてプログラムを書く必要があったので、オブジェクト指向はメモリ上のデータをコピーすることなくうまく使いまわせるようなプログラム技術になっています。 そしてオブジェクト指向にはそこから目だった更新はなく、タイトルに書いたように、カメラがやっとついたくらいのガラケーのような古い技術という感じがします。 オブジェクト指向について、アプリケー

この10年間のプログラミングの変化、というのが流れてきたのだけど、個人的にはクラウド、型推論付き静的型、リアクティブかなぁという風に思ってます。 クラウド(とスマホ) 2008年にGoogle App Engineが出たり、最初のHadoopサミットが行われたり、ちょうど10年前に始まったとも言えるクラウドは、すでに流行ではなく常識になっています。 いまや、クラウドを考えずにシステムを組むということはないんじゃないでしょうか。 スマホもこの10年で広まり、端末にUI、データはクラウドということも当たり前になっています。 40%の視聴率をもった紅白で視聴者が同時投票するようなことも、AWSを使って危なげなく行えるようになっていますが、10年前にこのようなサービスをたった4時間だけ行うということはなかなか考えにくいもので、実現できるのも限られたベンダーだけだったと思います。けれどもいまではそれ

Daggerってありますよね。コンパイル時に依存性を解決するのでパフォーマンス的に有利なDIコンテナです。 https://google.github.io/dagger/ 依存関係の不備がコンパイル時にエラーになって発見できるのも、実行時にエラーが出たときの修正の難易度が高いAndroidアプリにはありがたいということで、Androidでよく使われてるようです。 基本的なオブジェクトの定義 I have a pen. public class Pen { @Override public String toString() { return "ペン"; } } I have an apple. public class Apple { @Override public String toString() { return "アッポー"; } } Ohh!!! Apple Pen!!! p

DIコンテナ使ってるけど、アノテーションってなんなの！って聞かれて、作ってみたらわかるよと答えてみたので、自分でも作ってみました。 よくわかった。 「DIコンテナ使うと何がいいの？」ということも、作ってみるとわかります。あと「DIって何がいいの？」に関しては、「DIはちょっとコードを書くのが楽になるだけで、それだけあっても仕方ない、大事なのはコンテナ」と答えるようにしてますが、コード比率からもそれがよくわかります。 続編としてWebフレームワークも作っているので参考まで。 作って理解するWebフレームワーク - きしだのHatena まずはコンテナを作る とりあえず1ソースの状態で。 こんな感じで、管理する型を登録できるようにします。 static Map<String, Class> types = new HashMap<>(); static void register(String