例えば, Singleton を避ける | Born Too Late
この記事は TDD Advent Calendar jp: 2011 の 14 日目です. 前日: TDD戦略 -TDDを導入し進化させる方法- #TDDAdventJP (@kyon_mm さん) 翌日: TDDに対して思っていること (@gab_km さん) この記事の概要 TDD で開発することで設計上の問題点に気づきやすくなる Singleton はグローバル変数である Singleton の使用はできる限り避けるべきである テスタビリティを意識しよう TDD では, 原則としてユニットテストを書いてから実際のコードを実装します. なので, 自然と「テストのしやすさ (テスタビリティ)」を意識して実装することになります. そして, TDD においては一般的に, テスタビリティを意識することで, 設計が改善されるとされています. オブジェクト指向には難しい概念がたくさん登場します.
アジャイル導入コンサルタントという名前でスクラムだけを導入しようとする人は死ねばいいのにと思った - 水まんじゅう2
この文章中で表現されるアジャイルとはアジャイルソフトウェア開発宣言に沿ったものとします。 なぜか定期的にアジャイル開発をしようとしている人を食い物にしようとしている人のお話を聞くので。 タイトルですべてです。それ以上のことはない。 スクラムはアジャイルな開発を実現するためのプラクティスではあるけれども、スクラムをしてもアジャイルになるわけではないという事実。 それだけなのですが。 今まで見たり聞いたりしてきたアジャイルの失敗例 突き詰めると以下の二つではないかと思っています。 設計ができない 失敗ができない 設計ができない アジャイルだから設計書を作らなくてもよいよね。という人たちはいまだにいるらしい。 設計書という体裁では不要の場合もありますが、設計は必要です。 思いつく限り書き上げると以下の通り。 プロダクトオーナー(お客さん)との合意形成のため 全体で何を作るのかを明確化するため 必
設計と実装の狭間で - 急がば回れ、選ぶなら近道
・現状 ・・・相変わらず溝は埋まっていません。希望の星と目されたDSLは現時点ではかなりの不発弾に近い感じで、設計系クラスターはあまり元気がないですね。翻って見れば、設計と実装が最も近かった時代は、なんのことはなくて、自分も含めて（懐古趣味の老人を除いた）皆さんが毛嫌いするCOBOL＋汎用機の時代だったかもしれないという意見すら出る惨状です。あの時代以降、 UMLが登場し、まさに銀の弾丸状態で、それ以降Unified Processやら何やらが、インフルエンザの如く流行りました。ま、その延長上に今のアジャイルまでの流れがあるわけですが、気がついてみれば、これほど設計と実装が離れてしまった時代もないという状態になってしまっています。・・・設計と実装の狭間は、相変わらず埋まっていない気がします。 ここへ来て、実装技術の多様化は、カンブリア紀を思わせる拡大の一途になっています。開発環境のみならず
【インタビュー】クックパッドのUIデザイナー：「エンジニアの仕事が０を１にする仕事なら、デザインは1を100にする仕事 」 | Startup Dating
Startup Datingでインタビュー連載を始めてみることになりました。さて連載の初回は、2011年に新卒としてクックパッドに入社し、現在UIデザイナーとして活躍する片山育美さん（@monja415）。片山さんが現職に就くまでの道のりや、クックパッドのUIに関する考え方、片山さんが手がけた具体的なUI改善の事例やヒントなどをたっぷりお伝えします。 美術大学で勉強、もともと職人になりたかった もともと絵を描くのが好きだし得意、高校のときから職人になりたいと思っていたと話す片山さん。美術大学に進学し、ファイン系とデザイン系でデザイン系を学ぶことを選択。ファイン系とは、絵画や彫刻などいかにも“アート”というもの。ファイン系が芸術だから、どこか自分の中で完結してしまうところがある。でも、職人って誰かのために技術を使える人なんじゃないか、と。情報デザイン学科を専攻し、サービスデザインやUXと言わ
suicaは実はたまに落ちている - 紅茶屋くいっぱのあれこれ日記
suicaのサーバーはみんなの知らないところで、実はたまに落ちているそうだ。 だがシステムが止まることはない、計算上センターは3日ぐらいは止まっていても大丈夫だそうだ。 だからサーバーが落ちたなどとニュース沙汰になることは殆ど無い。 suica開発陣頭指揮をされていたかたが、その実績をまとめてと頼まれ、博士論文にしたそうだ。 suicaの実例を述べるだけだと技術論文になってしまうので、一般化して論文を書きあげたそうなのだが、審査に携わった専門家の人達はそんなものが動くわけないだろうといったらしい。しかし現実問題としてsuicaは動いてしまっている。 本人いわく、だってそれで動いちゃってるんだもん。だそうだ。 実装は時として奇妙に見えるかもしれない。 フィールドには神がいる。 …その意や、なんで落ちても大丈夫かなどはまた後ほど。 スイカのセミナー 昨日はスイカのセミナーだった。 JR東でスイ
堅牢なコーディングルールを策定する方法(2) - 都元ダイスケ IT-PRESS
いやー、なんか怖い人（笑）が見てるようだ。突っ込み激しそうぜよｗ さて、前回言っていた「判断ロジック」についての答えは各自考えてみただろうか？ 各方面の反応を見ると「1〜4どれでしょうか*1」という問いにすり替わっちゃってる気がするけど、テーマは「1〜4を決めるロジックを考えてください」なんだ。書き方悪かったもしれんｗ まぁつまり、昨日のエントリの時点では1〜4どれでもないのですよ。判断ロジックがないので。 というわけで本題。アプリケーションレベルでのバグとは「実際の挙動が仕様と違うとき」ですね。挙動があるべき姿(=仕様)と違う時にそいつバグとするのが妥当です。そしてそれはコードレベルでも同じ基準で良いんじゃないでしょうか。 じゃあ、仕様とは何か。Javadocコメントですよ。Javadocがないとバグの定義さえもできないんです。だから口酸っぱくJavadoc書けとｗ*2 まぁつまり「Ja
「ふたり暮らしのお部屋」グランプリ！
※ご応募頂いた画像は、審査のうえ掲載させて頂いております。 ※画像をクリックすると、拡大画像とコメントをご覧頂けます。
ガタがあるからうまくいく - レジデント初期研修用資料
先週の日曜日には、熱を出した子供さんが100人近く来た。休みが明けて、外来が始まって、 もちろん「それ以上」を覚悟していたのだけれど、外来は、平和なままだった。 インフルエンザはたしかに流行しているんだけれど、パンク寸前の休日外来は、 みんな「休みだから」病院に来てたわけで、「熱が出たから」病院に来た人は、実は案外少なかった印象。 遊びが減ってこうなった 社会から「遊び」要素が減って、平日にみんな、休めなくなった。 土日をずらして営業していた病院というのもあって、一時期はうまく機能していたんだけれど、結局みんな止めてしまった。土日外来の収益自体はよかったのだけれど、世の中が土日休みで回ってるから、役所とか学校とか、「平日」を要求する場所がシビアになって、スタッフに子供ができると、組織が瓦解しちゃうんだという。 世の中の遊びが減って、しわ寄せが、緊急避難装置的な場所に集まって、結果として、救
努力は報われないほうがいい - レジデント初期研修用資料
現在進行形ですごい状態にある人を見て、「僕も頑張ってああなるんだ」なんて、 その人と同じ場所を目指して頑張るのは、危険なことだと思う。 何かの間違いがあって、頑張ったその人の成功を許してしまった業界は、その時点で詰んでしまうから。 劣化コピーが承認を求める 同じ方法論で頑張った人は、どうあがいたってオリジナルの劣化コピーにしかなれないものだから、 そういう人は、ものすごく頑張る。頑張った人が、「頑張り」に見合った承認を求めると、 世代を重ねるごとに、「頑張り」のコストはどんどん上がって、そこはたぶん焦土になる。 業界のどこかで「すごい」を観測したのなら、その人と同じやりかたを重ねるのではなく、 「もっと簡単にあそこに到達するにはどうすればいいんだろう」なんて考えないといけないし、 それでも「頑張り」以外の答えが出ないなら、「すごい」その人たちがいなくても何とかなるように、 仕事のやりかた自
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
神様のまずい設計 - レジデント初期研修用資料
人間の体はよくできているけれど、ライフスタイルが変化すれば、やっぱり「設計」は古くなる。 胃を切った人は元気 「メタボ検診」の悪影響で、病院に健康診断の患者さんが大挙して、一時大変だった。 普段病院に来ないような人達をたくさん診察して、「胃を切った人は元気だよね」なんて、 医局で話題になった。 今70歳ぐらいになる人達が若かった頃は、胃潰瘍の治療といったら「手術」だった。 当時はまだ、開業した人達も手術してたから、今だったら薬を飲むだけで済むような人が 片端から手術を受けて、胃を切除された。 胃を切られた人は、食べられないから太れない。やせた人が来て、お腹を見ると手術跡があって、 「これは昔、潰瘍で」なんて教えていただく。診察して、後日血液検査を見ると、みんな正常値。 こんな人が何人か続いた。 サンプルは偏っているし、観察者の主観でしかないから、この事実にはまだなんの意味もないけれど、 「
ドキュメントとして何を書くか？
僕の考えは、以下のような感じ。 (1) ドキュメント（設計書だろうが仕様書だろうが）は、「誰に何をどう伝えるべきか」を考えれば、何を揃えればいいかは自然と決まってくる。そして、誰が読んでも意味がないと判断されるドキュメントは意味がないので書かない。 (2) 「基本設計書」や「詳細設計書」や「外部設計書」や「内部設計書」という言葉があるが、肝心なのは「誰に何を伝えるか」であり、伝えたいことや認識あわせの単位でドキュメントが作られればそれでいい。それらをまとめて「○○設計書」とするかどうかは、顧客がそうしたければ好きにすれば良い（そこまでやる義務は開発側にはないと思う）。 (3) アーキテクトの仕事は、各作業者が何をしたらいいか迷うことなく作業ができるように「決めごとをしていくこと」。その決めごとは、すべてドキュメント化されるべきであり、そのためには「誰に何をどう伝えるべきか」を考えていけば、
自分の言いたいことを上手に伝える事ができますか？情報伝達に必要な２つの力 - モチベーションは楽しさ創造から
情報を伝えるには、抽象的に話をする力と具体的に話をする力の２つが必要になってきます。 抽象的な話と、具象的な話。どちらの方がインパクトがあるでしょうか？ 答えは、具体的な話。 なんとなく、理解はできていたのですが、約１年間ブログを自分で書いてみて、ブクマという数値が見える化されてみると、この事が実感できました。 このエントリを書いている時点で、１４９６４ブクマがあるのですが、人気のエントリを上から見ると、上位のほとんどは「具体的なエントリ」です。具体的エントリとは、マニュアル的であったり、ポイントのみを示す形のエントリ。すぐに、使う事がイメージできるようなエントリ達です。 逆に不人気なのが、抽象的なエントリです。考え方や概念、コンセプトなどを書いたエントリは不人気。抽象的な事を、多くの人に「なるほど」と思わせるのは、難しいものです。まだ、私に抽象的な内容を訴えるだけの文才が追いついてないの
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
ダイコン時代の設計手法 - ひがやすを技術ブログ
スタラジで、本来話したかったことをまとめておきます。 最初はユースケースからスタートします。 本当は、RFPをユースケースに落とすという工程が 前工程にあります。 ユースケースの粒度について神経質になると 失敗します。 画面系ならいくつかの関連のある画面をまとめたものが 1つのユースケース。 ものすごく狭い言い方をするとメニューから呼ばれる 関連のある画面群が1つのユースケース。 帳票系なら1つの帳票が1ユースケース。 バッチ系なら関連するジョブをまとめたジョブネットが 1つのユースケース。 ユースケースを状態とサービスに分離します。 サービスはステートレスです。 状態は永続的な状態とプレゼンテーション層における一時的な状態に わかれます。 永続的な状態はER分析され、エンティティ(JavaBeans)にマッピングされます。 ここでは、UI層における一時的な状態を サービスから切り離し、サ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
イミュータブルデータモデル(入門編)
sonson.jp