タグ

ブックマーク / postd.cc (6)

  • Lispのアイデア | POSTD

    Lispと聞くと、冷蔵庫のような大きいサイズのコンピュータや、大文字のアルファベット文字列や括弧の並びといったような過去の時代のことが頭に浮かびます。そう、非常に多くの括弧。何故、オブジェクト指向プログラミングの作成者たちは、そんなにもLispの アイデア に魅了されるのでしょうか。そしてまた、アイデアとされるプログラミング言語というものは、どうやったら説明できるでしょうか。こうしたことを教えてくれなかったコンピュータ科学の教育を責めるべきでしょうか。 Lispは、John McCarthyが書いた Recursive Functions of Symbolic Expressions and Their Interpretation by Machines, Part I という論文によって、初めて世界に登場しました。その中で、McCarthyはプログラミングに新しい多くのアイデアを導入

    Lispのアイデア | POSTD
    cervino
    cervino 2017/02/11
  • 型付けを活用してテストを減らす:静的型を使ったTDD Part 1 | POSTD

    私はテスト駆動開発(TDD)について、Kent Beckの著書『 Test-Driven Development By Example 』(邦訳『テスト駆動開発入門』)で学びました。これは大変優れた入門書で、TDDにますます関心を持つようになった私は、さらにSteve FreemanとNat Pryceの著書『 Growing Object-Oriented Software, Guided by Tests 』(邦訳『実践テスト駆動開発:テストに導かれてオブジェクト指向ソフトウェアを育てる』)を読みました。このも私のお気に入りです。 ただし、両書には弱い部分もあります。現代の静的型システムがテストを補ったり、場合によっては置き換えたりできるかもしれないことには、全く触れていないのです。このようなを読んだだけでは、”typing”(型付け)と聞いてもキーボードの”タイピング”のほうを考

    型付けを活用してテストを減らす:静的型を使ったTDD Part 1 | POSTD
  • 関数型プログラミング入門 | POSTD

    多くの関数型プログラミングに関する記事が教えてくれるのは、抽象的な関数型のテクニックです。つまり関数合成やパイプライン、高階関数などです。この記事では違います。ここでは、プログラマが毎日書く、命令型で非関数型のコードの例を示し、それを関数型の形式へ書き換えます。 最初のセクションでは、短いデータ変換のループを取り上げ、map関数やreduce関数に書き換えていきます。2つ目のセクションではより長いループを取り上げ、ユニットに分解し、それぞれのユニットを関数型に書き換えます。3つ目のセクションでは、連続した長いデータ変換のループを関数型のパイプラインに分解します。 ここではPythonでの例を取り扱います。というのも多くのプログラマはPythonを読むのは簡単だと思っているからです。多くの例では、mapやreduce、パイプラインなどの多くの言語に共通する機能を例示するため、Python的な

    関数型プログラミング入門 | POSTD
  • GoogleがWebでのSHA-1の利用停止を急ぐ理由 | POSTD

  • 多くの若きプログラマたちが学ぶべきこと | POSTD

    私はこの7年半、 Ronimo でプログラミングを学ぶ多くのインターン生を指導し、様々なタイプの大学生や大学院生を見てきました。彼らのほとんどには、共通して言える学ぶべきことがあります。特別なテクニック、アルゴリズム、数学、あるいは特定の形式についての話だと思う人もいるかもしれません。もちろんそれも必要ですが、中心的なものではないと私は考えます。彼らが主軸として学ぶ必要があるのは、自己統制力です。常に可能な限り読みやすいコードを書き、開発中の変更により秩序がなくなってきた時にはきちんとリファクタリングを行い、使用されていないコードを除去し、コメントを追加することができるという力です。 プログラミングのインターン生を指導する際、この話にほとんどの時間をかけます。上級のテクニックでもなければエンジンの詳細についてでもなく、概ね彼らにより良いコードを書かせることに主眼を置きます。いつもインターン

    多くの若きプログラマたちが学ぶべきこと | POSTD
  • 開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | POSTD

    “なぜ納期を守れなかったのだろうか?” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は当に開発者の仕事が遅いせいでしょうか? Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと(S、M、L、XL)、また種類ごと(ストーリー、テスト、バグ)に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目:開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目:変動があるのは、ほとんどがチケットが開始される前(SomedayからBacklogまで)の段階です。これは、関係者が仕様を理解して作業の優先順位

    開発者の仕事が遅いわけではない!納期が遅れるホントの原因 | POSTD
    cervino
    cervino 2015/01/29
  • 1