ITmedia News：Twitterもランクイン、「2007年のベストサイト50」
TIMEが選ぶ2007年のベストサイトは、グルメサイトChow.com――同誌は今週、「2007年ベストサイト50」を発表した。 1位に輝いたのは、CNET傘下のグルメサイトChow.com。ビデオやブログ、レビュー、レシピ情報など食に関する情報を掲載している。 2位はWebサイト構築サービスのWeebly.com。ドラッグ＆ドロップで簡単にWebページを作成できる。 3位はビデオ検索サイトBlinkx.comと子供のためのチャリティープロジェクトを紹介し、ビジターが好きなプロジェクトに寄付できるDonorsChoose.org。5位には、eBayによる買収が決まったコミュニティー型お勧めサービスStumbleUpon.comが入っている。 このほかベスト50には、音楽SNSのLast.fm（11位）、CD交換サイトLala.com（13位）、無料動画配信サービスJoost.com（40位
Unit Testの書き順(3)
書き順を守っていると、expectedとinputの所にそのテストの本質が書かれます。 本質が分離されていると良い事は幾つかあります。 保守がしやすい、というのがそのうちの一つです。 まず、読みやすい。 expectedとinputを読むだけでテストの内容が理解出来る為、コードを読む必要はほとんど無くなります。 英語で説明的に書かれている為、他人の作ったUnit Testを一通り理解するのも圧倒的に楽です。 テストのinputとexpectを読めば一通りテスト対象のクラスの仕様も分かります。 Mockのsetup等手順が大きくなればなるほどテストの可読性は落ちますが、そこがexpectやinputと分離されていると、全て読まなくてはいけない場合でもだいぶ楽になります。 また、本質はあまり変更されません。 コンストラクタの引数が変わったり、テストに必要な何かが変わる事はあり得ますが、inpu
Unit Testの書き順(2)
Unit Testを書く時に書き順を固定する一番のメリットは、考えなきゃいけない事を減らす事です。 最初の真白な状態からテストを書くのは、結構難しい作業です。 特にテスト対象がまだ分かっていない時に、突然スラスラとテストが書けるか、というとなかなか難しい。 そこで真白な状態から書かなくてはいけない範囲を、テスト全体からexpectedとinputの数行に絞る訳です。 expectedとinputはそれなりに同時に考える場合が多いのですが、それでもテスト全体を書く事に比べるとずっと考える事は少なくて済みます。 expectedとinputが書き終われば、そこから先は単純作業です。 実際、VSのUnit Testの自動生成を普段から使っていれば、この形に近い状態まで生成してくれる事がわかると思います。 これはつまり、機械的にできる作業だ、という事です。 また、変数にするのは自分の考えを整理する
Unit Testの書き順(1)
私が概ね全てのお仕事コードにUnit Testをつけるようになって、だいたい3年になります。 Testabilityという物に高い意識を持つようになった期間とだいたい一致している為、Unit Testを書くという事自体のキャリアもまだ3年です。 プログラムを書くという事だともうすぐ10年になりますが、Unit Testはようやく素人の域を脱した程度の所です。 まだまだそんなレベルではありますが、それでも3年続ければ3年続けただけの物もあります。 その一つとして、Unit Testの書き順という考え方があります。 Unit Testを書く時に、最初に何から書くでしょうか？ 私は expectedの変数 inputの変数 その他 という風に書きます。1と2は入れ替わる事もあります。例を挙げましょう。 function Adder() { return {add: function(a, b)
masuidrive on rails » Blog Archive » プロジェクトの始まりはTracから
そんなわけで、プロジェクトの始まりはTracから。これがないと仕事が始まりません。 Tracが一番良いわけでも無いんだけど、日本語マニュアルがあるところと、ユーザが多いことから、subversionとの連携スクリプトなどが多数公開されているところが、選択理由です。 Railsベースでも複数、プロジェクト管理ソフトが出てきているので、どれか良い物に育ってくれると嬉しいなと思っています。 さて、tracのインストール方法はwebで沢山見つかるので、それを参考にインストール。 Tracは初期設定でも十分使いやすいんですが、チケット登録で担当者をドロップダウンリストにするために設定を変更します。 tracの設定ファイル conf/trac.iniの下記の項目を変更してください。 [trac] default_charset = utf-8 # 文字コードはUTF-8で [ticket] restr
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
Buildr
What is Buildr?NewsNotices What is Buildr? Buildr is a build system for Java applications. We wanted something that’s simple and intuitive to use, so we only need to tell it what to do, and it takes care of the rest. But also something we can easily extend for those one-off tasks, with a language that’s a joy to use. And of course, we wanted it to be fast, reliable and have outstanding dependency
ソフトウエア開発に役立つマインドマップ
ソフトウエア開発は，コーディングやテストばかりではありません。顧客との打ち合わせやエンドユーザーとの会話，さらには開発者同士のミーティング，ブレインストーミング，仕様の構想といった「アイデア」と「コミュニケーション」に本質がある活動がたくさん含まれています。マインドマップは，このような柔らかな人間活動をビジュアルにうったえることでサポートする発想法であり図解法です。この連載記事では，話題の書籍『ソフトウエア開発に役立つマインドマップ』（右図）から，すぐに使えるマインドマップの利用法を抜粋してお伝えします。 目次 ・第1回 マインドマップって何？ --- 注目技術の理由と特徴 ・第2回 議事録と会議ナビ --- チームの合意をすばやく作れ！ ・第3回 ブレインストーミング --- 広がるアイディアをつかまえろ！ ・第4回 ロジカルシンキング --- 概念を分類・整理しよう！ ・第5回 まとめ
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
andore.com