Hatena::ブログ(Diary)

haru01のめも このページをアンテナに追加 RSSフィード

2013-10-27

[] オープンデザイン

ソフトウェアエンジニアにとっては、

オープンソースの考え方が、その後他分野にどのような影響を与えているかが読み取れる本。

3Dプリンターの活動背景なども書いてある。

ユーザ参加型やユーザ主導型の共創も含まれる。

ものづくりのあり方がだいぶ変わってきているんだね。




追記:読んでるうちにだんだんわからなくなってきた。

2011-04-24

断片と全体

断片と全体

断片と全体

前半を再読。言語と思考の機能に興味がある人ならおすすめです。


今回は、art,good の語源をたどることで、数学、芸術、科学が分かれる以前の時代の思想を推測し、これらの共通についての話に目が止まった。

数学は論理的の整合性のfit感、芸術は感情・感性のfit感、科学は理論と観察結果・実験結果のfit感を求めている。


「適合(fit)」が重要なキーとなる。

ただし、現代においては,数学、芸術,科学で、なにを善(good)として、どのように適合を求めるかについては、断片化ている。


この本を読んでいるうちに、ソフトウェア開発の文脈の置ける、善(good)、適合(fit)その断片化を思い浮かべた。

(何度か思い浮かべ、何度か書こうとしているテーマ。)


DDD

開発者とドメインエキスパートが対象領域ついての理解の fit感を深めようとしている。概念と実装の fit感(対象領域の語彙を使って、意図の明確なコードになっているか?)を深めようとしている。

そのために、会話やモデル作成や実装を繰り返す。

Customer Testing

。。。。

Clean Code、Developer Testing

開発者がソフトウェアをつくる際の fit感(読みやすいか?/修正しやすいか?/テストしやすいか?) を深めようとしている。そのために、Clean Codeの定石を利用したり, テストを書いたり、リファクタリング実施等をおこなう。

ユーザビリティ/UX

ユーザがソフトウェアを使用する際の fit感(目的を達成できたか?/心地よく使えたか?)を深めようとしている。

そのために、UIパターンを活用したり、ユーザビティティテストを実施したりする。

QCD & S

QCD & S の fit感(必要十分な品質を満たしているか?/予算内か?/納期遵守しているか?/必要十分なフィーチャセットであるか?)を深めようとしている。そのために、スコープ調整したり、価格交渉したり、リリース時期を整えたり等の調整を行う

チームビルディング

。。。。

アーキテクト

複数のステークホルダーの。。。。

オープンソースの利用

。。。。


ソフトウェア開発のコンテキストの境界に絞っても、何を 善として、どのように適合性を深めていくかについては、いくつかのアプローチで断片化しており、全体をつかむのは、なかなか難しいテーマだ。

ポジションがプログラマ向けなら、Clean Code を『メタファ』にして、DDDやユーザビリティやQCD & Sやチームビルディングが『善』としている『基準』かをうまく説明できるのでは、淡い期待を昔持ったことはある。。。


『基準』という言葉についても 『断片と全体』で語源の話が出てきて,使い方が、昔と現在では異なっているという興味深い話が出てくるが、ここらでやめておこう。

2011-01-15

キノコ本のジュンク堂のトークセッション

だらだら書いておく。



レビューの種類の話が印象に残った。

xチェックイン前
パッチ - オープンソース界隈で流行っているらしい。修正パッチに対してコメントを入れるツールとか.レビューフィードバックが後回しになりがち。
機能トピックブランチ切ってマージ前にレビュー。大きくなるとしんどい-
リリース 大きくなるとしんどい 次回リリースはがんばりましょういになっちゃう。。。

あと Webプログラマーの動機みたいなのが少し聴けた。「いいね」少なくとも2つ軸がある。

サービスを世に出してユーザに使ってもらって「これ、いいね」と言ってもらえるのが嬉しいのと、

書いたコードをレビューの際に、開発者同士の仲間内で「すげーだろう」「いいね」と言い合うのが楽しいみたいな話。

キノコ本でも レビュー、ペアプロの心がけの話がいくつか出ていたのが記憶に残っている。

レビューする側が、レビューされる側を攻撃するような形に陥らないようにと、

ベテラン側が辛抱強く、新米側が気後れする事なくコミュニケーションをとること、みたいな話。

番号は忘れてしまった。


よいライブラリやフレームワークは、言語を超えてアデアが伝播する話が印象に残った

Rack の元ネタは Python 系と聞いた。知らんかった。

今日の話を聞いて、もう少し、ソースコードを読む時間、習慣を持った方がいいのかなと思った。

プログラマが知るべき97のこと

プログラマが知るべき97のこと

2008-10-25

最近のお仕事をして

最近、技術面で、いろいろ思う。

技術的なアーキテクト|リーダーを名乗るのであれば、フレームワーク等のプロダクトの数ある中から、トレードオフを判断して、適切なものを選択出来る必要がある。欲しい機能が実装されているかわからないのであれば、英語のサンプルや仕様書を読んで、ラーニングテストを書ける必要がある。

動かないのであれば、英語メーリングリストやバグトラック等で同じ問題が上がっていないかを調べる必要がある。英語で質問メールをなげる必要がある。オープンソースプロダクトであれば、テストとソースを読む必要がある。

単に実装されていなくて、実装できそうであれば、書き直すことが出来る必要がある。

これらが、素早く的確に実行できる必要がある。


あぁ、確実にできていないなぁと、思う訳で。実行できても、リードタイムが長い。

海外のエンジニアだと上のスキルが普通のことのようにみえるから怖い。


本を読むように、ソースコードを読む習慣は、エンジニアとしてやっぱ必要だなぁと、

書いとけば、ソースコードを読む率が上がるかな。

2008-10-17

ユビキタス言語の候補

ユビキタス言語を目指しているのが色々乱立している感がする。


ごじゃごちゃさせてみる。OO派なら、DDDにみられるドメインモデルだろうか。動作するソフトウェアを大切に考えるなら,Product CodeとSpec Codeとデモであろうか。論理的な美しい、賢いを大切にする派なら仕様書を全面にだすだろうか。とあるデザイナであれば、ペルソナをだしてくるだろう。ある特定の建築系ならパタンランゲージだろう。経理関係派なら測定可能なお金を軸に。リーンのムダ取り派なら時間を軸を。もっと根本的にロジカルシンキングをだしてくるところも在るだろう。これに対抗する派は感情とかストーリーとか。意味論とか考えだすと、プリミティブな身体的メタファとかが出てくるか。マーケティング派なら顧客の視点を共通の語彙として強く主張するだろう。ラーニング派は、直接的な会話のレシピで共通の語彙を形成する過程のメタレベルでせめてくるか。オープンソースプログラマ派なら、直接会話の閉鎖性よりも、ネット上でログが残りOpenになるWeb上の英語メールのアーカイブとかパッチなのかな。何か他にもいろいろ在りそう。