YAGNI[1] (You aren't gonna need it[2][3]) とは、エクストリーム・プログラミング(XP)から生まれた原則であり、「プログラマは、それが実際に必要となるまで機能を追加しない方が良い」というものである[4]。直訳すると「あなたはそれを必要でなくなるだろう」、意訳すると「そんなの必要ないって」などという意味で、他の表現として"You aren't going to need it" (YAGTNI) [5][6]や"You ain't gonna need it"[7]というものもある。 XPの共同創設者であるロン・ジェフリーズ(英語版)は、「それが実際に必要になったときに実装するべきあって、必要になると予見したときに実装するべきでない」と述べている[8]。ジョン・D・カーマックは、「将来の要件やアプリケーションを考慮して設計することが、トータルでプラスに
目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードを食べながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。
仕事や趣味でコードを書いているとき、設計をしているときに難所に出くわすことがあります。 そんなときに僕が意識的に心がけていることを紹介します。 もっと良い方法があったらぜひ教えてください。→皆様。 難所に出くわす前に「もうすぐ難所だな」と気づいているときは、すでに冷静な状態で心構えができています。 この場合はきちんと対処ができることが多いです。 何度も考えがループしていたり、難しすぎて他の事に逃避しているときは集中力がないか、難所にさしかかっているサインなので、難所の場合は以下の5つを順番に試しています。 絵を描く 人に言葉にして説明する 思考の流れをテキストにする 散歩する 次の日に持ち越す 絵を描く 設計やコーディングに関して、分かっていることを絵や図にあえて描いてみます。 分からないところは箱を描いて中に? とでも書いておけば良いです。 絵を書く過程で、自分がどこが分かっていないかが
IT ConversationsでRuby on Railsの作者デービッド・ハンソンが2008年5月にRailsConfでおこなった講演が配信されている。そして、以下でも聞ける。 RoRの思想についての言及が冒頭にあるが、大部分は開発者の身の処し方についての講演である。その部分の概要は以下の通りである。 RoRは他のフレームワークや開発手法に比べて生産性について依然として優位性があり、RoRを使って開発していると「余剰開発力」を享受できる。しかし、その状態は永遠には続かない。遅かれ早かれ以下のどれかが起こるから。 他の言語/フレームワークがRoRを凌駕する RoRを凌駕する新たなフレームワークが登場する RoRがメインストリームになる 幸い、どれもすぐには起こりそうになく、RoRでの開発はまだしばらく生産性の点で有利である。その優位性によって生ずる余剰開発力をいかに活用すべきだろうか。も
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は7月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
2007年06月07日 Google のソフトウェア・エンジニアリング Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」 Google の研修 入社して最初の 3ヶ月は本社(Mountain View)で研修 研修中は、メンターがついて「Google での開発の仕方」を学ぶ 内部ウェブ・サイトで社内共有ライブラリの使い方などを説明する動画があるので、それで自習 Google のプロジェクト・チーム 開発拠点は米国、スイス、オーストラリア、インド、日本など 場所とプロジェクト・チームは関係なく、プロジェクト・チームが拠点をまたがることは普通。世界中の拠点全部合わせて、一つの Google エンジニアリング・チーム 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同
Have you ever heard of SEMA? It’s a fairly esoteric system for measuring how good a software team is. No, wait! Don’t follow that link! It will take you about six years just to understand that stuff. So I’ve come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. With all the time you save, you can go
Joel Spolsky ジョエル・スポルスキ 翻訳: Fukushige Erika 福重 永里香 翻訳チェック: Takeda Toshiyuki 武田俊之 9.8.2000 SEMAについて聞いたことがある?かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った!そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。 ジョエル・テスト ソース管理システムを使っているか? 1オペレーションでビルドを行えるか? 毎日ビルドを行うか? 障害票データベースを持っているか? 新
○明治、大正、昭和初期の利根川水運時代の面影を残す料理旅館。 ・・・観光、ビジネス、合宿などのグループ宿泊に最適です。 水郷・佐原、香取、鹿島、神栖、銚子方面の拠点としてご利用ください。 先日、JRの車内誌に「旅館の作法」というエッセイが載っていました。「・・温泉にいくのなら、作法など余計な心配のない、格安の、家族だけで経営しているような、気の置けない旅館が良い。・・」当館は、そんな部類の宿だと思います。 ○「光明石の湯」 ・・・光明石(天然鉱石)を使用した準天然温泉。広い浴室に「適温」と「やや熱め」の二つの湯船。地元香取地区の檜を切り出して湯船の傘木に使いました。檜の香りでとてもリラックスできます。 ○バリアフリーをめざします ・・・車椅子の方でも使える広いトイレ、エレベータと廊下、浴室も広くとるなど、今後、さらに充実につとめます。環境にやさしいクリーンエネルギーも導入しま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く