TL;DR プログラムは「下から組む方法」と「上から組む方法」がある プログラムを組む時は少しずつテストしながら組む はじめに なにかゼロからプログラムを組むとします。そのプログラムのアルゴリズムや、何をやるべきかはなんとなくわかっているけれど、どこから手をつけてよいかがわからず、ChatGPTに全部書かせて、その後修正できずに困る、という事例を何度か観測しています。 プログラムをゼロから書くのは慣れが必要です。プログラムをゼロから書く場合、小さな部品を一つ一つ作っていって、最後にそれらを組み上げる「下から書く」方法と、「こういう関数が必要であるはず」と外枠から書いていって最後に中身を埋める「上から書く」方法があります。その一般論を論じるのは私の能力を超えるため、以下では「下から」と「上から」の例を挙げて、その「気持ち」を説明してみようと思います。言語はなんでも良いですが、ここではPyth

IBMのBookMasterでは、デフォルトを"vanilla"、特別な設定を"mocha"と呼んでいたらしい。 http://web.archive.org/web/20211224091337/ftp://public.dhe.ibm.com/printers/products/dcf/samples/B2H.HTM 「Chapter 6. Caveats and restrictions (what's supported and what's not!)」に以下の記述がある。 Conditional sections (.cs) and BookMaster's "vanilla" DVCF macros (.CONFIG and .WHEN) are supported, but not BookMaster's "mocha" DVCF macros (e.g. .USING,

はじめに 大学の講義ノートをいくつかGitHubで公開しています。 講義ノートをMarkdownで書いてGitHubで公開、というのをしばらく続けて、いろいろノウハウが溜まったので共有してみようと思います。 大学の講義ノートをどうするか問題 昔から大学の講義ノートを公開する人は結構多いです。最初期は、LaTeXで書いてPDFで公開することが多かったように思います。これはこれで良いのですが、基本的にはダウンロードして印刷して読む前提であり、ウェブで気軽に読める形ではありませんでした。その後、LaTeX2HTMLを使って、LaTeXファイルをHTMLに変換して公開するケースが増えました。これによりウェブで講義ノートが気軽に閲覧できるようになったのですが、いかにも「LaTeX2HTMLを使って変換しました」という外観になるのと、(少なくともデフォルトでは)レスポンシブではなく、スマホ非対応になる

TL;DR ((((printf("Hello World\n")))))みたいに関数をたくさんの括弧で囲むとコンパイラが死ぬので気をつけましょう。 はじめに 以前、printfに4285個アスタリスクをつけるとclang++が死ぬという記事や、GCCに27958段ネストした関数を食わせると死ぬという記事を書きました。 特に、printfにアスタリスクをたくさんつける記事では、clang++がわりとすぐ死んだのに対して、g++は5万個とかつけても大丈夫でした。一般に、コンパイラが死ぬ系のコンパイラいじめは、再帰でスタックを使い切るタイプのものが多く、LLVMよりもGCCの方が頑健という印象です。 さて、C++では、括弧を無駄につけることができます。例えば、

はじめに 実験や数値計算などでエラーバーがついているグラフをよく使いますが、見ていると「ん？」となるグラフをよく見かけます。いくつか例を挙げて見ましょう。 ケース1 例えばこんなグラフがあったとします。 何かが時間に対して指数関数的に減衰していることを表しているようです。僕は発表でこういうグラフを見かけたら「ん？」と思います。 一方こちらのグラフは、少なくともエラーバーの付き方はまともです。 ケース2 もし、観測値のそれぞれに独立なノイズが乗っているのであれば、エラーバーは、観測回数を増やせば減っていくはずです。観測回数nに対して、物理量の推定値とエラーバーがどうなるかを表したグラフでこんなものがあったとします。 試行回数nを増やすにつれて、平均値は0.5に収束し、さらにエラーバーも小さくなっています。一見それっぽく見えますが、僕はこのグラフを見たら「ん？」と思います。 一方、こちらも同様

はじめに Gitのインデックスの中身、Gitのブランチの実装に続く、Gitの中身を見てみようシリーズです。Gitが管理するオブジェクトの種類や中身について見てみます。基本的にはPro Gitの10. Gitの内側をまとめなおしたものです。 オブジェクトの種類 Gitは、内部でファイルやコミットを「オブジェクト」として.git/objects以下に保存しています。オブジェクトには以下の4種類があります。 blobオブジェクト： ファイルを圧縮したもの。ファイルシステムの「ファイル」に対応 treeオブジェクト： Blobオブジェクトや別のTreeオブジェクトを管理する。ファイルシステムの「ディレクトリ」に対応 コミットオブジェクト： Treeオブジェクトを包んだもの。コミットのスナップショットに対応するTreeオブジェクトに、親コミット、コミットメッセージなどを付加する タグオブジェクト：

TL;DR 技術記事を書いて公開してくれる人は貴重な資源なので、なるべく潰さないように大事にしましょう。 はじめに プログラムを書いてて、なにかわからないことがあれば検索すると思います。すると、世の中にはごく少数の役に立つ記事と、大多数の役に立たない記事があることがわかるでしょう。その役に立つ記事を求めてネットの海をさまよっていると、「あれ？またこの人の記事だ」と思うことがよくあるでしょう。C++の言語仕様を調べてると「あの人」の、Vim関連を調べていると「あの人」の、Go言語なら「あの人」の記事を見つけることでしょう。逆に言えば、ある程度限定された分野において、体系だった知識があり、わかりやすい記事を書いてくれる人というのは極めて貴重な人材ということになります。 しかし、そんな「つよつよエンジニア」も、はじめから強かったわけではありません。当然のことながら新人時代があり、よくわかっていな