満足せる豚。眠たげなポチ。:コンソールアプリケーション用 Ruby フレームワーク SimpleConsole を使ってみた
Ruby の用途が、 業務アプリをばりばり開発！ とかではなくて、 仕事をするなかでちょっと困ったり面倒だったりするときのツール という位置づけな自分にとって、書いているコードはいくつかオプションを指定してコンソールで走らせてやれば終了するようなものがほとんどを占めている。 そうすると、かなり毎度同じような内容を書いていたりして、DRY じゃないなー（けど、自分しか使わないようなのが多いし、ま、いっかー）と感じていた。 そうこうするところに、SimpleConsole というコンソールアプリ用のフレームワークの紹介を読み、「これで解決するんでない？」と期待を持ったので試してみることにした。 SimpleConsole って何？ 紹介をざっと読む限りだと、SimpleConsole は、 オプションの解析とバリデーションを自動でやってくれる Controller と View を簡単に作成
満足せる豚。眠たげなポチ。:優れたハッカーによるSIは本当に理想図なのか
Life is beautifulさんの ソフトウェアの仕様書は料理のレシピに似ている 知的労働者には「組織を移る力」がある を読んでの感想。 あと、併せて読んだ話は下の二つ。どこかで話が重なる部分があるかも。 浮ついた「ギーク」への説教（※老害注意） プログラマとして 産業としてのSIerについて語りたいのか、プログラミングスタイルについて語りたいのか。それはさておくとしても、少なくとも誰のために何を作る話をしているのかははっきりしないと意味がないんじゃないかと思います。 もちろん、一般論としてのプログラミングスタイルとしてどちらがより優れたものが作れるのかなんていうのは議論するまでもないです。 ただ、その上でスケールしやすいパッケージ系のソフトウェアビジネスについての話なのか、それとも儲けの上限が決まっていて一人一殺形式だからスケールしにくいSIビジネスについての話なのか、というのはは
満足せる豚。眠たげなポチ。:決まらない仕様には「仕様の仕様」を出そう。（あるいは要件と仕様と設計の話）
「設計者の発言」さんの「ユーザがなかなか仕様を決めてくれないって？」をとても興味深く読みました。 「ユーザがなかなか仕様を決めてくれないんです」という悩みをじつによく聞く。（略）問題はどちらかといえば設計者の側にある。 で始まるこのエントリでは、設計者がユーザの反応を見ながら提案内容をどんどん修正し最終案としてまとめるという、「インタラクティブなやりとり」が必要という主張がされています。 ただ、この話は仕様決めと要件定義をごちゃまぜにしている部分があるように思います。たしかに実際に作業を進める上では、この二つがフェーズとして重なることもよくあります。ただ、少なくともエンジニアの頭の中では明確に切り分ける必要があると思っています。 そして、このエントリで言われる「インタラクティブなやりとり」が必要になるのはどちらかというと要件定義の時です。ユーザの目的に沿ったシステムをイメージしてもらうため
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
