Rustが再評価される:エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...
Sustainable Security Requirements with the ASVS Josh Grossman provides a brief overview of what the ASVS is, but takes a closer look at balancing trade-offs and prioritizing different security requirements. Josh shares how to make the process repeatable and how to implement it as part of your own organization's requirements process.
原文(投稿日:2012/05/25)へのリンク DRYは重複とそれに伴うメンテナンスの問題を軽減するものだが、誤用すると密結合を生み、可読性を損うおそれがある。教訓:ソフトウェア開発原則は、ほかの原則やパターン、プラクティスを考慮して適用しなくてはならない。 DRYは Don’t Repeat Yourself の略語であり、Andy Hunt氏とDave Thomas氏が書籍「The Pragmatic Programmer: From Journeyman to Master」(邦訳:「達人プログラマー―システム開発の職人から名匠への道」)で最初に言及したソフトウェア開発原則だ。その原則はこう述べている。 知識のあらゆる部分はそのシステムにおいて単一で、曖昧さのない、信頼できる表現でなくてはならない。 ここでHunt氏は重複による負の影響と、それゆえにDRYを利用することの重要性を強調
Sustainable Security Requirements with the ASVS Josh Grossman provides a brief overview of what the ASVS is, but takes a closer look at balancing trade-offs and prioritizing different security requirements. Josh shares how to make the process repeatable and how to implement it as part of your own organization's requirements process.
原文(投稿日:2012/04/23)へのリンク Microsoft は新たな Branching and Merging Guide のドラフト版をリリースした。表向きの対象は TFS ユーザだが,アドバイスの大部分はソース管理プロバイダに関係なく適用可能だ。まずその基本概念を紹介しよう。 ブランチとマージを扱うほとんどのガイドラインと同様に,すべてのブランチの親の役割を持つメインブランチが存在する。 "trunk" として知られることが多いが,Microsoft ではこれを MAIN と呼ぶ。MAIN には DEVELOPMENT と RELEASE という2つの主要ブランチがある。 最初のガイダンスでは開発ブランチ(DEVELOPMENT) について取り上げている。内容は比較的簡素で,基本的には企業のチームや機能の構成方法に帰着する,というものだ。ただし前のバージョンから継続している独
原文(投稿日:2011/11/30)へのリンク Yammerの従業員であるCoda Hale氏がScalaの商用ベンダであるTypesafe社へ送ったメールがYCombinatorとGitHubのgist経由でリークした。メールによれば、Yammerは複雑さや性能面を鑑みて、基盤のインフラをScalaからJavaへ戻すそうだ。 YammerのPR部門のShelley Risk氏によればこのメールはCoda Hale氏の個人的な意見であり、Yammerの公式な見解ではないとのことだ。このリーク後、Coda Hale氏は自身の考えをhttp://codahale.com/the-rest-of-the-story/で表明している。氏はこのメールはDonald Fischer氏(Typesafe社のCEO)からのフィードバックの要請に答えたもので、移行を示唆するツイートを補足したものだと説明して
原文(投稿日:2010/03/03)へのリンク 開発者ならだれもが、自分のコードに最低一行はコメントを書いているはずだ。コメントをたくさん書いて、コードをもっとわかりやすくしようとする人もいる。この記事では、コードにコメントを書くときに使われるプラクティスを集めてみた。 Seattle Area Alt.Net グループのメンバらが、コードにコメントを書く必要性やプラクティスについて議論した。Kelly Leahy氏は、一目瞭然のわずかなコメントが散りばめられているようなコードが好みだ。コメントは「コードを変更したときに取り残されてしまうことが多く」、「不正確なノイズをシステムに取り込んでしまうだけ」だと考えているためだ。 (コメントを書くということは)多くの人にとって個人的なことですが、私はコメントをかなりスリムにするよう気を配っています。というのも、コードを変更したときに、コメントが取
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く