そういえば、去年から雑なジョギングを始めている。
バスが間に合わなそうで走ったときに、ちょっと走れなすぎてヤバいなと思ったので、走るという行為をたまにやっとこうと思ったのがきっかけ。
その程度のモチベーションなので、何キロも走ったりとかせず、家のまわりのブロックを一周するくらいにした。
そうすると、距離にして700m弱で、準備をして部屋からでて走って戻っても10分かからない。
テキパキやれば5分ちょいくらい。
数キロ走ろうとして30分とかかかってしまうと走るタイミングを考えてしまうけど、5分で終わるとなると思いついたときに走ってくればいいのでやりやすい。ぼくでもできる。
やはり、継続したいことは5分で終わるようにするべき。
ということで週に1-2回くらい思い出したように走ってる。
やらないよりはマシという程度に健康になった気がする。やらないよりはマシなのでいいのだ。
報道ヘリがうるさくて救助の邪魔になるという話はどう広まったのか、というのを調べてみていたのでメモ
そもそもとして「報道ヘリがうるさくて救助の邪魔になる」ということなんてあるのか、という話は、1995年1月17日の阪神淡路大震災にさかのぼる。
震災後6日後に収録されたと言われる1月27日放送の「パペポTV」で上岡龍太郎が次のような発言をしていた。
取材陣のヘリコプターがあの被災地の上を飛び回るでしょう。あの爆音のために、生き埋めになってる人に外からどんなに声かけても、その人たちの声が爆音のために聞こえない
救助の邪魔になるという話 以外にも、被災者から「自分が見せ物にされている」というような苦情もあったようだ。救助ヘリの邪魔になる高度を飛ぶようなこともあったらしい。
これは実際に問題だったようで、その後1997年に日本民間放送連盟から「航空取材ガイドライン」が出されて、報道ヘリがある程度の高度を保つようになっている。
よりよい放送のために | 一般社団法人 日本民間放送連盟
なので、現在ではマスコミのヘリはそこまで邪魔になるような高度を飛んでないはず。
にもかかわらず、いまネットでそういう話が流れるのは、2016年に上記の番組がYouTubeにあげられて、その書き起こしがネットに広がったというのが影響していそう。
もちろんそこには航空取材ガイドラインの話は出てこないので、「今でも邪魔な報道ヘリの飛ばし方をしている」というような印象をもって広まった。
それがいまだにTwitterで語り継がれてる、というそういう状況だと思われる。
※ 追記 2024/1/6 長崎県の轟峡遊歩道での件が「反例」として貼られてるけど、ガイドラインで報道ヘリの基準高度が600-700m以上くらいに決まってるものの(具体的な数字は見当たらず)、標高200mということで報道ヘリとの距離が平地より近くなったんじゃなかろうか。 あと、ドローンは電波がそれほど届かないので操縦者が直下まで出向かなければならず、災害時に飛ばすのには向いてないですね。
今年読んで面白かったマンガをまとめておきます。
アニメがヒットしてるフリーレン、最近やってた黄金郷編がめちゃよかった。
フリーレンはエルフを主軸にしたマンガではあるけど、基本的にはフェルンの物語なので、人間の時間軸で話が進みます。
一方で「転生してハイエルフ」はエルフの時間軸で話が進むので、宿屋の女の子が、次に会う時には大きくなっているということが当然のようにあります。
エルフのように生きるのがどんなことかということを書こうとしてる感じ。
貧しい農村に生まれて召喚スキルを使ってちょっとずつ認められていくという話。
召喚獣がかわいい。
最初のちょっとしたエピソードもぜんぶ伏線になっていて、そういうことだったのかとなっていくのがいいです。
貴族の家を追い出されるけど、付与術で無双していくという追放もの。
追放した貴族が没落していくざまぁものでもあるのだけど、その没落しかたが他にない感じでおもしろい。
ニーナがかわいい。
宇宙船が事故にあって地球型の惑星に不時着して冒険者になるという話。
かなり面白いのだけど、原作に追いついているようで、続きが出るのか心配。
イギリスの貧しい農家の女の子とその従者がアメリカにわたってゴールドラッシュに沸く西部を目指すという話。
なんかがんばったらどうにかなる感じがいい。
ラブコメ。
だけどドタバタしてるだけじゃなくてみんないろいろ考えていてよい。
登場人物みんないい人。
今年買ってよかったものまとめ
テフロンのはがれたフライパンを惰性で使い続けていたのだけど、餃子やいてもはがれないし、タマゴを炒めるとくっつきまくりで気になっていた。
で、インターネッツぽちぽちやってるときに、なんとなく買ったら、やっぱり新しいフライパンはよかった。
オリーブオイルとニンニクと塩だけのパスタがおいしすぎてよく作っている。
もらいものの電子レンジをずっと使ってたのが壊れたので買いなおし。
あっためれればいいので、一番やすいのを買った。
そしたら、キッチンタイマー機能があって、便利につかっている。
アナログのキッチンタイマーはあるのだけど、1分や2分は計りにくくて、電子レンジのタイマーを使うとちゃんと計れるので、紅茶を煎れるときの時間をちゃんと調節できるようになっておいしく紅茶が飲めている。
ただ、扉をあけると電源が入る仕様なのだけど、1秒弱ほどのラグがあって、そのラグの間にボタン操作するとフリーズして電源抜き差ししないと復帰しないというバグがあって「SHARPの開発りょく～」とか思ったりしている。
ちいさいギターアンプ。
アンプもってなくてマルチエフェクタからPC用のオーディオインタフェースにつないでヘッドフォンで聞くというのをやってたのだけど、音を出したい、けどあまり音量も出したくないというので買ってみた。
スマホと接続していろいろエフェクトを調節できる。小さい割に出力が5Wなのでそれなりに大きい音も出るけど、小さい音がきれいに出るのがいいところだと思う。
ざつに机の上に置けるサイズなので、適当にギターをつないで弾いたりしてる。便利。
Jupyter for JavaというのがInfoQで紹介されていたので試してみました。
Java News Roundup: JDK 22, Spring CVEs, Liberica JDK, JDKMon 21, Jupyter for Java, Gradle 8.5
Jupyter notebookでJavaを使うためのいろいろをまとめたGitHub organizationらしい。
https://github.com/jupyter-java
やってみたのがこれ。
ということでGoogle colabでJavaを使う手順 pic.twitter.com/afn4dbDyT9
— きしだൠ(K1S) (@kis) 2023年12月6日
まずGoogle Colabを開く
https://colab.research.google.com/
で、「ノートブックを新規作成」
ここで「ノートブックの設定」を見てみる。
「ランタイムのタイプ」にPython 3とRだけある。まだJavaは使えないことを確認。
とりあえずJavaのバージョン確認。11が入ってる。
17とか21が使いたければ、aptでインストールを。
Jupyter for Javaのページの「Installing in online Jupyter notebooks」の4行をコピー
https://github.com/jupyter-java
こんな感じになってる。
![[Ademe] コンプレッションウェア セット メンズ](https://m.media-amazon.com/images/I/41PUCmvzM-L._SL500_.jpg "[Ademe] コンプレッションウェア セット メンズ")
!pip install jbang
import jbang
jbang.exec("trust add https://github.com/jupyter-java")
jbang.exec("install-kernel@jupyter-java")
貼り付けて実行
30秒くらい待つと「ランタイムのタイプ」でJavaが選べるようになる。
そうするといろいろとJavaっぽいものが動かせるようになる。
%mavenでMavenリポジトリからのライブラリインストールもできる。
%maven org.knowm.xchart:xchart:3.5.2
ので、こんなこともできる。
import org.knowm.xchart.*; double[] xData = {0.0, 1.0, 2.0}; double[] yData = {2.0, 1.0, 0.0}; XYChart chart = QuickChart.getChart("Sample Chart", "X", "Y", "y(x)", xData, yData); BitmapEncoder.getBufferedImage(chart);
こうなる。
実行環境としてはIJavaがインストールされるので、ノートブック上の使い方はこちらを。
https://github.com/SpencerPark/IJava
オブジェクト指向言語の話をするときに便利なように、Javaを中心にプログラミング言語をまとめてみました。
Javaに影響与えるか、Javaから影響を受けるか、という感じですね。
オブジェクト指向はここから始まったと言われています。
クラス、オブジェクト、継承、仮想関数(多態)といった、オブジェクト指向の基本要素が備わっていました。
ただし、「オブジェクト指向」という言葉は生まれていません。
Simulaから発想を得て「オブジェクト指向」という言葉を生んだのはアラン・ケイでした。
しかし、モデルとしてはSimulaとは異なりメッセージングを主体としたものでした。また、アラン・ケイの「オブジェクト指向」はプログラミングのパラダイムだけではなく、人がコンピュータをどのように扱うかというメタファであり、ダイナブックというハードウェアやそのユーザーインタフェースを含むものでした。
Smalltalkは、そのような思想でコンピュータを扱うための環境として開発されました。
ここでSmalltalkに関しては3つのバージョンを分けていますが、これは「オブジェクト指向」の源流としてのSmalltalkを扱うときに、バージョン間の変遷が重要になるからです。
メッセージングのオブジェクト指向によるコンピューティングを実現するために開発された最初のバージョンはSmalltalk 72ですが、Smalltalk-76ではSimulaのオブジェクト指向のようなクラスや継承を取り入れています。
そして、Smalltalk-80として商用化され現場のプログラマが使うようになったのですが、このバージョンに関してアラン・ケイは「Smalltalk-80は私の手を離れ、Lisp好きの影響を強く受けてた」のようなことを言ったようです。
https://matz.rubyist.net/20060608.html
また、エンドユーザーではなく開発現場のプログラマが使うようになったことを「Smalltalkの死」とも表現しているようです。
https://sumim.hatenablog.com/entry/20060612/p1
つまり、商用化され広く開発で使われるようになったSmalltalkを「アラン・ケイのオブジェクト指向を実現する言語」というのはあまり適切ではないということです。
C++のオブジェクト指向とSmalltalkのオブジェクト指向は違うといわれることがありますが、GoFの「デザインパターン」がSmalltalkで整理され出版されるときにC++に書き直されたことからわかるよう、両者とも同じ問題が発生し同じく継承を使った解決方法をとることになるくらい似ていたということになります。
C++はCにSimulaのクラスを導入したものです。
詳しくはこちらの本に。
JavaはC++をベースにしたように言われますが、実際にはObjective-Cの後継です。Objective-CにC++の構文を載せた、というのが適切だと思います。
インタフェースはObjective-Cのプロトコルであり、クラスが大文字はじめ、メソッドやフィールドは小文字という命名規約もObjective-Cと同様です。
Objective-CはCにSmalltalkのオブジェクト指向を持ってきたものなので、Javaのオブジェクト指向もSmalltalk由来と言えます。
JavaがC++ではなくObjective-Cの流れであるという話は、Javaの開発者のひとりであるPatrick Naughtonのメールのアーカイブに。
https://web.archive.org/web/20110713014816/http://cs.gmu.edu/~sean/stuff/java-objc.html
クラス、インスタンス、オブジェクトという用語の区別に悩んだことはないでしょうか？「クラスのオブジェクト」と言ったとき、クラスを表すオブジェクトなのかクラスがインスタンス化されたオブジェクトなのか、そもそもこの説明なにいってるかようわからん、になったりしてないでしょうか。
そこで、Smalltalkからオブジェクト指向の発想をえつつ「全部オブジェクトでええやん、新しいオブジェクトを作るときには、プロトタイプになるオブジェクトをコピーすればええやん」という考えのもとSelfという言語ができました。
To make a new object in SELF, an existing object (called the prototype) is simply cloned (shallow-copied)
https://dl.acm.org/doi/pdf/10.1145/74878.74884
そして、インターネットが流行ったときにブラウザの中でプログラムを動かしたいなーとBreandan Eichを呼んできてSchemeを動かさせようとしたところ、当時話題になっていたJavaに似せる必要があるということでSelfのプロトタイプベースのオブジェクト指向を取り込みつつJavaの見た目とライブラリをかぶせてJavaScriptができあがりました。
ライブラリをそのまま移植したため、java.util.Dateの2000年バグまでもってきてしまったと後悔していますね。あとプリミティブも。
JavaScript誕生の話はこちら
https://brendaneich.com/2008/04/popularity/
C#へと至る道も長いですね。
まずWindows用にDelphiという開発環境がありました。これはPascalという言語にオブジェクト指向をのせたObject Pascalという言語を使っていました。VBのような開発環境ですが、VBよりかなりいいという評判に。
そして、Delphiと同じことをC++でやれるようにと、C++Builderが開発されました。このとき、ボタンのイベントハンドラを登録するときに関数ポインタにイベントの受け取りオブジェクトも結び付ける必要があったため、__closureという拡張が行われています。
さて、そんなところにJavaが流行ってきました。MicrosoftとしてはJavaでWindowsアプリを作れるようにしたい、そこにDelphi/C++Bulderの開発者であるAnders Hejlsbergが、Borlandの開発環境部門廃止で会社を追い出されたので、Javaを拡張してJ++を作ってもらったのでした。この拡張は、C++Builderの__closureをJavaに持ってきたもので、delegateと呼ばれました。
しかし、Write Once Run Anywareを掲げてJavaを作っていたSun Microsystemsはそんな独自拡張を許すわけもなく。
http://web.archive.org/web/20040404002128/http://java.sun.com/docs/white/delegates.html
ということでMicrosoftはJavaを離れ、C#という独自言語を作ったのでした。
PHPはPHP/FIをもうちょっとちゃんとしてPHP3になったときに流行りました。 そして用途が広まるときにZend社が入ってある程度しっかりしたものにしつつ、オブジェクト指向を取り入れたのがPHP4です。このとき、Javaが超流行ってたため、PHPのオブジェクト指向はJavaの機能を再現した感じになっています。
ScalaはJavaの資産を利用しつつ関数型をとりこんで実用的に仕上げた言語です。
Kotlinは歴史の積もったJavaをリセットして現代的につくりなおした言語といえます。
SwiftはObjective-Cの代替として現代的につくりなおされた言語ですね。
と、そんな感じでまとめてみました。
※補足 RubyやPython、RustやGoについては、この図にいれてもどこからも線が引かれないか、「オブジェクト指向の機能あるんだからSimulaかSmalltalkの影響は受けとるやろ」程度のつながりになってそんな面白くないなーとなって載せてないです。GoはCに、RustはC++につなげて「代替したい」くらいの関係に・・・(あとJavaとつなげて「反面教師」ってやるか)
あと、いろいろ掘り出せば際限ないので、Tiobe index20位、せめて50位に入る程度にメジャーなものってやるとGroovyやClosureは外れて・・・。オブジェクト指向の話としてそんなに発展もないし。
※追記 2023/11/27 SmalltalkからSelfに線を引きました。
※追記 2023/11/27 GoとかRustとかKotlinとかSwiftとか、2010年くらいからの言語の場合、「この機能はこの言語由来、この機能はこの言語由来」というのではなくて、成熟したプログラミング言語開発の中でトータルでバランス考えながら設計した、という感じがあるので、言語相関図の中での線がひきにくい気もします。なので、KotlinやSwiftはベースのプラットフォームからの線はひけるけど、その他の部分については「現代化」としてます。
先日のJJUG CCC 2023 Fallの懇親会でクソコードを研究しているという学生がいたのだけど、クソコードの研究は難しいという話をした。
人工的にクソコードを再現しても、あの野生のクソコードのクソさには全く足りないわけで。
トルストイが言うように「すべてきれいなコードは互いに似通っているが、クソコードはそれぞれにクソの趣を異にしているものである」なので、なかなか「これがクソコード」のように類型化するのも難しい。
典型的なクソコードを書いてみても、なんだかきれいなクソコードができてしまう。
クソコードはネットに出回らないので、資料の収集もまた難しい。ネットにないということは、ネットの情報に基づいている「AI」もホンモノのクソコードには触れていないことになる。
クソコード収集サイトをつくっても、実際のクソコードは業務固有処理も含まれるので、掲載できる形に整理していくと本来のクソさが薄れて、ただの拙いコードになったりする。
ウンコード・マニアというサイトを教えてもらったけど、普通に拙いだけか、単に文化が違うとか見慣れない記述とかいうのも多い。
これなんかは、完全に本来のクソさが薄れてしまってますね。
[Java] 不動の精神-ウンコード・マニア
クソコードは、足りない技術力、足りない納期、足りなかったら怒られる仕様に歴史が積み重なって醸成されるものだと思う。
知識はないが仕様は満たさないといけない、納期はせまるというところに、窮鼠猫を噛むかのように生み出される創造力というのがある。
例えば文字列をソートするためにその名前でファイルを作ってファイル一覧をとってくる、というような、「なぜそれが書けてqsortが呼び出せないんだ！」みたいなことが稀によくある。これは「Windowsプログラミング入門」みたいな本にファイル操作APIは載っているんだけど文字列操作のC標準関数は載ってないみたいなところから発生しがち。これだけなら制約下の廃スキルエンジニアもネタで書きがちだけど、クソコードにはナチュラルに難読化がかかっている。
ともかく、クソコードでは想像を超えた発想力というのが発揮されていることが多く、なかなか人工的には作れないのであった。
また歴史の積み重ねにより難しいことをやってるように見えてx=xをやってるだけということもある。
値を加工する、仕様変更でさらに加工する、仕様変更でもう少し加工する、最後の仕様変更がなかなか難しいががんばって加工する、よくみたら元の値に戻ってるように見えるが怖くて触れない。
安易に削除してみると、目立たないように施された例外値の補正が外れてバグる。
こういう年月をかけて醸し出されたクソコードというのも、やはり再現は難しい。
こういったクソコードでの難読化、昔まとめていたな、と思ったら、これはもう18年前・・・
追っ手から逃れるシステム - きしだのHatena
JJUG CCCではこのイベントを発端としてクソコード談義が始まったのでした。
11/28-12/4でオンラインです。興味あるかたは是非。
Javaソースコードを読み、技術的負債の数値化に向けて和田卓人氏(@t_wada)と語ろうー複数日程 - connpass
まあ、未来人から見ればいま書かれてるコードはだいたいクソコードかクソコードの種なわけですが・・・
ちなみに、文中の「すべてきれいなコードは～」は、米川正夫版をベースにしました。
追記: ブコメにある「画期的な国産検索エンジン」はこちらの記事
HOWS「ISSEI（イッセイ）」 | 日経クロステック（xTECH）
