例えば「写経」という言葉を避けてみる。 - 西尾泰和のはてなダイアリー
サイボウズ式「続・エンジニアの学び方」の第5回が公開されました。この回では、小崎さんが「どうしてコードを読もうと思ったのか」と、コードを読むために新しい言語を学ばなければいけない場合に「どうやって学ぶか」を聞きました。 ところで、小崎さんは自分の学び方を「写経」と読んでいて、僕もこの用語は自然に理解できるのですが、公開後のTwitterの反応を見ていると「写経と呼ぶことが嫌」もしくは「仏教での写経の印象で、内容を勘違いしている」という事例がいくつも見つかりました。 プログラミングの学習法としての「写経」という言葉は色々な書籍で使用されています。例えば「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」の70ページでは「まず写経することから始めた」というエピソードが紹介されています。また「改訂新版 コンピュータの名著・古典100冊」の99ページでは「技術書の内容にそって深い
妻に公開鍵暗号を教えてみた - 西尾泰和のはてなダイアリー
何気なく放送大学をつけていたら公開鍵暗号の話をしていた。 妻「この話、何度聞いてもわかんないのよね」 僕「え、どこがわからない？どこまではわかってる？」 妻「平文はわかるけど、鍵を共有するとか秘密にするとか、署名するとかがよくわからない」 僕「あー、鍵に例えているのが逆効果なのか」 「鍵」をNGワードに指定 僕「じゃあ『鍵』という言葉を使わずに説明してみよう。暗号って『平文を暗号文に変換する方法』で伝えたい文章を暗号文に変えて送り、受け取った人はそれに『暗号文を平文に戻す方法』を使って元の文章を得るわけだ。その目的は、途中の通信文が敵に取られたりしても通信の内容がバレないようにするため。」 妻「うん」 僕「昔の暗号化の方法は、片方の方法がわかるともう片方の方法も分かった。例えば『アルファベットを後ろに1個ずつずらすと平文に戻せます』って教えてもらったら、『なるほど、前に1個ずつずらせば暗号
gitをテキトーに使って生産性を向上したユースケース - 西尾泰和のはてなダイアリー
バージョン管理とかgitとかが「おおげさでめんどくさいもの」だと思う人は多い。でも、それは生産性向上のチャンスを逃していると思う。特に業務として多人数で開発している人たちの「変更前にはまずトピックブランチ」というやり方が、それはそれでよい方法なんだけど、いかにもめんどくさそうで尻込みさせてしまうのではないか。 先日の日曜日に、テキトーなgitの使い方をして、とても役に立ったのでユースケースとして報告しておこう。ただし、若干特殊な環境なのでここでやった方法が直接そのまま皆さんの所で使えるとは限らないが。 まず環境の説明。プロジェクトは「次の日曜日、新感覚シューティングゲームを展示します」で紹介している、テーブル型ディスプレイで動くシューティングゲーム。メインは @tokoroten で、ソースコードをバリバリ変更している。土曜日にとりあえず動くところまでは行った。改善点は山積みだ。使える時間
そろそろ例のプロジェクトについて言及するか - 西尾泰和のはてなダイアリー
以前、とあるシステムのソースコードを読む機会があったのだけどあまりにひどかった。あのひどいコードでまあまあまともに動いているというのが逆に信じられない。今日昼ご飯を食べながら少し話していたのだけど意外と知られていないようなので、話せる範囲でいかにひどいのか説明してみようと思う。 まず、ソースコードが大雑把に見積もって3750万行あるのだけど、その中でまともに機能しているコードは3%しかない。10分の1程度のソースコードで同程度の機能を実現しているシステムもあるのでほんとあのシステムのコードはゴミだと言っても過言じゃない(*1) プログラマとしてはなんでそのプロジェクトはそんな状態になってしまったのか気になるところだけども、まあ多くのプロジェクト同様、真相を知る人は誰もいない。でもまあ、実際に機能しているコードのコピーみたいなものがあちこちに散らばっていることからしてコピー＆ペーストが盛んに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
