タグ

2014年1月8日のブックマーク (5件)

  • コードを理解できない人間がソフトウエアの記事を書く怖さ

    数年前、他社のプログラミング雑誌を書店で立ち読みしていたとき、その雑誌の編集後記を見て違和感を覚えました。「私はコードは全く理解できないが、間違っていそうな個所は編集者の勘でわかる」と書いてあったのです。「それはおかしいんじゃないか」と思いました。 好意的に解釈すれば、自分にはできないプログラミングができる執筆者に対する尊敬の念が、このような文章になったのかもしれません。編集者としての感覚を誇りたい気持ちもあったのでしょう。たしかに、編集業務の経験が長ければ、「何かがおかしい」という勘で誤りを発見できることがたまにあります。しかし、技術的な誤りをすべて勘で見つけられるわけがありません。 掲載するコードの内容が正しいかどうかをチェックするのは、プログラミング雑誌の編集者にとって重要な仕事の一つです。意味がわからない箇所があれば筆者に確認するべきでしょう。コードがわからないのは恥じるべきことで

    コードを理解できない人間がソフトウエアの記事を書く怖さ
    atotto
    atotto 2014/01/08
    「知らないことについて、深く考えることはできません」
  • bzrは死につつある。Emacsは移行しなければならない

    bzr is dying; Emacs needs to move Emacsのソースコードは、Bazaarでバージョン管理されてきた。しかし、Bazaarは分散バージョン管理システムとしては、Gitに敗北したし、もはや死につつある。Eric S. Raymondは、Emacsは他のバージョン管理システムに移行しなければならないと書いている。 私がこの投稿をしている理由は、バージョン管理システムとその周辺ツールのエキスパートとしての責務であって、この議論に参加したいがためではない。 bzrバージョン管理システムは死につつある。ほとんどの点で、もはや死んでいる。dev listは死んでいるし、Canonicalのほとんどの内部プロジェクトはbzrを捨ててgitを使っているし、古参開発者の一人が、なぜbzrが失敗したかについて書いている: http://www.stationary-trave

    atotto
    atotto 2014/01/08
    そか、emacsはbzrなのか
  • ペアリング対コードレビュー: 開発者文化の比較

    前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって

  • Go言語のMapの仕組みをマクロ視点で見てみる - ワザノバ | wazanova

    http://www.goinggo.net/2013/12/macro-view-of-map-internals-in-go.html1 comment | 0 pointsWilliam KennedyがGo言語のMapの仕組みについて、なぜデータ順がランダムになり、かつ効率的で処理が早いのかを、図解しています。 Creating and Using Maps まずmapをつくりvalueを保存するところから見てみよう。 // Create an empty map with a key and value of type string colors := map[string]string{} // Add a few keys/value pairs to the map colors["AliceBlue"] = "#F0F8FF" colors["Coral"] = "#FF

  • “RESTful Web APIs”の前半部を気合いを入れてまとめてみた

    「RESTful Web APIs」を読んでいます。現在は第7章までを読み終わったところです。第7章の終わりに前半部の総まとめをするような箇所がありましたので、ここで自分なりに理解した内容をまとめておきます。 RESTful Web API「RESTful Web Service」の後継 「RESTful Web APIs」はその前書き(Preface)で触れられているように2007年に出版された「RESTful Web Service」の正式な後継にあたります。「RESTful Web Service」では、ウェブサービスのアーキテクチャについてSOAPなどに対する望ましいあり方としてRESTが提唱されました。結果として、RESTアーキテクチャは一般的に認められるようになりました。 ハイパーメディア 「RESTful Web APIs」は、「RESTful Web Servuce」後の状