ソフトウェア開発の真の問題点は、コードを書くことではなく、問題の複雑さの管理にある - YAMDAS現更新履歴
www.oreilly.com オライリー・メディアのコンテンツ戦略部門のバイスプレジデントであるマイク・ルキダスの文章だが、彼が数週間前、「コードを書くことが問題なのではない。複雑さをコントロールすることが問題なのだ」というツイートを見かけた話から始まる。彼はこれに感心したようで、これから何度も引用すると思うので、誰のツイートか思い出せればいいのにと書いている（ご存じの方は彼にご一報を）。 件のツイートは、プログラミング言語の構文の詳細や API が持つ多くの関数を覚えることは重要じゃなくて、解決しようとしている問題の複雑さを理解し、管理することこそが重要だと言ってるわけですね。 これは皆、覚えがある話だろう。アプリケーションやツールの多くは、最初はシンプルである。しかも、それでやりたいことの80％、いやもしかしたら90％をやれている。でも、それじゃ十分ではないと、バージョン1.1でいく
Makefileを自己文書化する | POSTD
私たちのプロジェクトではいつも、非常に長い Makefile を使用して、インストールやビルド、テスト、デプロイメントの処理を自動化しています。ターゲット名はほとんど標準化されていますが（ make install 、 make deploy ）、中には説明が必要なものもあります（ make run-dev 、 make restart-api ）。そして、詳細なmakeターゲットを追加するほど、それらの処理内容をテキスト形式で大量に記載しなければなりません。私たちのプロジェクトでは通常、このような文書を README ファイルに書いています。 しかしCLI（コマンドラインインタフェース）を用いる場合は、主に自己文書化ツールを使っています。 make と打つだけで、利用可能なコマンドとその説明が一覧表示されたら便利だと思いませんか？ それを実現するのは、実はとても簡単です。まずは各ターゲッ
for文のforはなぜforなのか? - yapattaのブログ
よく考えるとプログラミング言語で当たり前に使っているfor文のforは不思議な命名だ。 他のループで使う、whileやloopは繰り返しをする意味が含まれるからまだわかる。一方forは個人的なイメージではあるがループに関する意味は無さそうだ。 という感じになぜforなのか疑問が湧き上がってきた。 そこで今回はfor文のforはなぜforになったのかを調べてみた。 因みに一番最後に結論が書かれているので結論だけ気になる方は最後だけ見て頂けたら。 この結論は著者のyapattaの推論も含まれている。何か反論、意見があったら気軽にコメントして欲しい。自分が気づかなかったポイントを知れたら面白い。 まずforに一応ループ周りの意味が含まれるか辞書で調べてみた。自分がただforという単語に反復的な意味が含まれていることを知らなかったという可能性もある。 ejje.weblio.jp 10番目の意味で
書き捨てるためのRust - Qiita
はじめに Rustは「きちんとしたプログラムを書く時にはいいけど、書き捨てのプログラムを書くには向いていない」と言われることがあるようです。「一般論としては全くその通り」と思う一方で、自分自身を振り返ってみると、これまでPythonで書いていたような書き捨てに近いプログラムも全部Rustで書くようになっています。 なぜ書き捨てのプログラムもRustで書くのかを考えてみると 最初は書き捨てだと思っていても、手直ししながら使い続けることは意外と多い コンパイラが割と多くのエラーを捕捉してくれるのでデバッグの時間が短くて済む 記述量の多さはエディタの補完があってあまり気にならない といったあたりが理由になっています。 そうはいってもRustがいろいろと面倒な言語であることには違いないので、書き捨てるときは普段のRustプログラミングとは少し違った書き方をした方がより早く書けるのではないかと思いま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Rustのパターンっぽいやつメモ
言語処理100本ノック 2020 (Rev 2)