QCon Tokyo 2009 雑感

QCon Tokyo 2009を通じでの雑感など。

まつもとさんの講演で考えさせられたのは、
システム作りはどういうものなのかということです。
僕が考えるシステム作りは家作りに近い。
設計図（コード）だけではその良し悪しは判断できず、
住んで（使って）みて初めてわかるということ。
たとえば、３人で住む家を作るのに、
マンションを建てるような設計や技法は不要ですが、
３世代住宅を建てる際には、バリアフリーは必要です。
アパートを建てるのに宮大工は不要です。
住み続けるためにはメンテナンスが必要です。
人が住まなくなった家は（使わなくなったシステムは）すぐに駄目になります。
建築物に例えると、第三者が使うとか、保守が必要という観点が抜けてます。
そういう意味では、家作りのほうがしっくりくると思います。

来年への期待
スタッフの方々お疲れ様でした。
また来年も開催されることを期待します。
来年はまた違う技術が台頭していることでしょう。

QCon Tokyo 2009 おまけ Nabeatsu

こう書いてみた

package sample;
import java.util.regex.Pattern;
public class Nabeatsu {
    private String number;
    private int ahoNumber;
    public Nabeatsu(String number) {
        this.number = number;
        this.ahoNumber = 3;
    }

    public Nabeatsu(String number, String ahoNumber) {
        this.number = number;
        this.ahoNumber = Integer.parseInt(ahoNumber);
    }

    public String play() {
        StringBuffer buf = new StringBuffer();
        for (int i = 1; i < Integer.parseInt(this.number) + 1; i++) {
            buf.append(guess(i) == true ? "AHO" : (new Integer(i).toString()));
            buf.append(" ");
        }
        return buf.toString();
    }

    private boolean guess(int number) {
        if (0 == number % this.ahoNumber) {
            return true;
        }
        return Pattern.compile(
                ".*" + (new Integer(this.ahoNumber).toString()) + ".*")
                .matcher(new Integer(number).toString()).matches();
    }

    /**
     * @param args
     */
    public static void main(String[] args) {
        Nabeatsu nabeatsu = new Nabeatsu(args[0]);
        System.out.println(nabeatsu.play());
    }

}

QCon Tokyo 2009 Day2 Spring in a changing world - Rod Johnson

A changing world

業界の変化
IBMのSun Microsystems買収の噂
OracleのBEA Systems買収

大事なのは技術の変化
従来のJ2EEの失敗
簡潔な解決策の要求->Agile
世界的不況

フォレスタリサーチによれば"Lean Software"の必要といわれている。

Lean Softwareとは
シンプル
無駄を省こうという考え方
開発者が必要としている（牽引している）

開発者の力が強くなってきた
開発者は使用するオープンソースの選択だけでなく開発に参加するようになった。
オープンソースがJ2EEの問題点を指摘し解決してきた
経営者の開発者への依存度が高くなってきている


シリコンバレーはもはやRULEではない。
シリコンバレーで金融アプリケーションを作っている人はいない。

old leader IBM, BEA
today's leader Spring, tomcat


IBMのSun Microsystems買収では何も解決しない
Java EE 6は失敗に終わるだろう


What is Spring
POJOプログラミングを可能にするフレームワーク
どうやって＝＞DIやAOPおよびPortable Service Abstractionを提供する。


What next
SpringはEJBの複雑さを軽減させている
ほかにも有効な解決策がある。Zend, Ruby on Rails, Django

Javaの生産性をあげる全体像を誰も考えていない。
統合された全体像が必要
オイルショック時のAMの車グレムリンにならないように

Javaはオープンソースとして一企業に引っ張られたくはありません。


Springの動向

Build, Run, Manageの３点から統合ビジョンを提供する

Buildの内容
Rails, Grails, Groovy

Manageの内容
tcServer(based on tomcat）, dmServer(modulable application server)

年末にはクラウドコンピューティングに対するSpringのアプローチの発表がある。
来月Spring Euroで何らかの発表がある。

http://www.springframework.org/
http://www.springsource.com/

QCon Tokyo 2009 Day2

http://qcontokyo.com/tokyo-2009/

Rod Johnsonがお目当て。
丸山先生の話は興味深い。資料は手に入らないものか。

QCon Tokyo Day 2 Opening
長尾達也(コンポーネントスクエア)
Floyd Marinescu(C4Media)
ホスト：河村嘉之、平鍋健児、中台高宏

General Session 1
クラウドの技術的な特徴について
講演者：丸山不二夫

General Sessin 2
Spring Today and Tomorrow
講演者：Rod Johnson

クラウドをプログラミング - プラットフォームとしてのインターネット
講演者：Gregor Hohpe
Author of Enterprise Integration Patterns

大規模ウェブサイトのベストプラクティス －eBayでの事例－
講演者：Randy Shoup
eBay Architect

ザ・パワーシフト ～ サード・リアリティ
講演者：森正弥
楽天技術研究所 所長

パネル・ディスカッション「エンタープライズ・ソフトウエア開発の動向」
モデレータ：Floyd Marinescu
Author of EJB Design Patterns, InfoQ and QCon Co-founder
パネリスト：QCon Tokyo 講演者

QCon Tokyo 2009 Day1 現場のITアーキテクトが知っておくべき10のこと - あるいは、技術が分かるPMが知っておくべき10のこと 鈴木雄介

自分用のメモです

http://www.slideshare.net/yusuke/10-things-it-architect-should-know?type=presentation


１．ITアーキテクトとは
何故必要か
要件と技術が複雑になっている
この状況を整理する人が必要

でも開発リーダでは無い
利害関係者のバランスを取る
作ることのリスクが高い

立ち位置が微妙
作る人でも使う人でもない
考えたことが誰にも理解されない
自分の立ち位置を自分で見つける
好みという信念が大事
こういうのは難しいけれど楽しいことでもある

IBMの認定試験がある
アーキテクトがアーキテクトを選ぶ

PMとアーキテクト
Good managers do the things right.
Good leadership does the right things.
マネージャとは複雑さに対応する人
リーダーシップとは変革を起こす人

PMはお母さん的、ITアーキテクトはお父さん的
どちらも大事、どちらも必要



２．アーキテクチャとは
定義がいろいろ

内圧（作ること）と外圧（使うこと）のバランスを360度でとった結果
きれいな円になっているか
要因にチーム構成、スケジュールも含んでいい
作れないアーキテクチャに意味は無い
圧力を発見する力が必要

デザインの輪郭

posted with amazlet at 09.04.10

深澤 直人
TOTO出版
売り上げランキング: 16571

おすすめ度の平均:

じわり、じわりと
夜寝る前に、ふと手に取りたくなる本
何度も読むと良くなってくる
じわじわと感じてくる本
生きることを大切に、そして丁寧に。

Amazon.co.jp で詳細を見る

ソフトウェア品質モデル　JIS X 0129-1

プロセス品質 ==影響==> 内部品質 ==影響==> 外部品質 ==影響==> 利用時の品質
　　　　　　 <==依存             <==依存           <==依存

ソフトウェアの外側はどこか

ユーザが真に評価するのは利用時の品質だけ
だからUIは重要

「クエリーの実行速度3秒短くするよりも3秒待ってもらうUIを作ること」
この視点が大事
利用状況を知ることも大事


３．PMとアーキテクチャ
PMBOKの定義
トヨタのマネジメントはなぜうまくいくのか
自動車の基本的なアーキテクチャは100年間変わっていない
過去の積み重ねの歴史
PMの精度を高めるためにはアーキテクチャの概念は必須

環境としてのアーキテクチャ
人は指示されても動けない
監視の仕組みが必要
いい加減を許容する空気が漂うプロジェクトはだめ

割れ窓理論
NYのジュリアーニ市長がとった犯罪対策
割れた窓を放置しない
小さい犯罪を取り締まることで大きな犯罪の発生を防ぐ

環境の要素を改善することで成功に導く（？）

アーキテクチャには知性がある
アーキテクチャにはプロジェクトの環境として機能する
人が環境に従ってしまうことの重みを考える


４．いろんなことに興味をもつ
ファシリテーション、コーチング、ロジカルシンキング
デザイン、建築、ビジネス

５．さいごに
現場に合わせて悩み、考えることが大事
答えは自分で見つけるしかない


今年をITアーキテクト強化年間にしたい。

QCon Tokyo 2009 Day1 General Session 2 ビューティフルコード まつもとゆきひろ

自分のためのメモ書きです。

おそらくオープンソースカンファレンス2009での内容とたぶんにかぶっているのかも。
http://d.hatena.ne.jp/LukeSilvia/20090207/p1

コードは工業製品では無い
コードは設計である

車でいえばデザイン
触ってわかるものがないと良し悪しの判断ができない
ソフトウェアにも名作、駄作がある

コードは実用品である

実用に供してナンボ
「用の美」　目的に合致しつつ美しいこと

コードは読み物である
コードは人を感動させる

どういうときに感動するか
パワー　できないものをできるようにする
効率　アルゴリズム
O記法　データ量に応じた計算量

O(1)
O(n)
O(n * log(n))
O(n ^ 2)

Rubyにもあった。吉田さんのパッチによりRubyは文字コード非依存
perl, pythonは内部でunicodeで保持している。
rubyはM17N。

ブルックスの法則（人月の神話）
「遅れているプロジェクトに人を投入すると、そのプロジェクトはもっと遅れる」


簡潔さは力なり
"succintness is power" by Paul Graham

まつもとさんは言語オタク
そのまつもとさんの考察
「言語はより抽象的に記述する方向に進化している」
ブルックスの生産性不変の法則
本質に集中
実行可能擬似言語（アルゴリズム説明のサンプル記法）



冗長の排除
DRY
コピーして作るとバグもコピーされる


例
class User < ActiveRecord::Base
end
動的にエンティティを定義

手抜きは美しくない
苦労を見せびらかすのは粋じゃない
水鳥のように・・・水面は優雅に、水中は足をバタバタ

シンプルは美しい
シンプルとは何か
現実は複雑だ
人の心も単純じゃない
単純さの罠がある
ソリューションが単純になることがゴール
システムが単純だとヒューマンプロセスが複雑（？）
ヒューマンプロセスが単純だとシステムが複雑（？）
人間にフォーカスして考える
バランスが大事　唯一の正解はない


外面の美
人間がどう感じるか
時代・前提によって変化する

内面の美
コードに内在

コードはアートだ
製品ではなく作品だ
したがってコードを書く人は
歯車ではない　作業員でもない
でも納期があり、顧客がいて、チームで動く

自覚や自発が必要だ

美しいコードとは何か
理解に基づいたコード
人間（内面）
機械（外面）

「理解」が鍵


大きな誤解
ソフトウェア工場という考え方
シンプルは善
アーティストは仕事にならない


まとめ

    * コードは美しい
    * コードはアートだ
    * プログラマはアーティスト

そういう自覚が大事


技術者としての夢
一生楽しく生きたい
楽するために努力する
あと３０年から４０年ぐらいはプログラムの開発をしていきたいな
一日一回はコードを読んだり書いたりする（プログラマ養成ギブスみたいなもの）

プログラミングの楽しさは変わらない

Enjoy Programming

4/11追加
よくまとめられている記事があったので

「ソフトウェアは工業製品ではない」、Rubyのまつもと氏が講演 － ＠IT

QCon Tokyo 2009 Day1 General Session 1 ドメイン固有言語 －その役割－ Martin Fowler

自分のためのメモ書きです。

スピーカーはMartin Fowlerさん
詳しくはつぎのURLにあるらしいのでそちらを。
http://martinfowler.com/dslwip/
http://martinfowler.com/dslwip/UsingDsls.html


DSLとしてはmake, ant, SQL, HQLがあります。

たとえば日常の動作を表現する。
次に、ステートマシンとして表現する
次に、クラス図に展開します。
次に、コードで表現します。

このコードでの表現の欠点その１
ステートマシンを表現していることがわかりにくい
コードは見て何をしているかわからなければならない　

このコードでの表現の欠点その２
コンパイルが必要になる

コードをXMLで表し欠点その２を解決
DSL(Ruby)で記述し欠点その１を解決

DSLは昔はlexとyaccで作っていた。


DSLの分類
１．External DSL
using lex and yacc
すっきり
UNIXコミュニティ
XMLはExternal DSLです。
Passiveなデータ記述言語

２．Internal DSL
使用ホスト語の制約を受ける
without parser
ex lisp

APIとの違い
Java code->コマンドクエリ型
Fluent APIメソッドのチェーン


DSLとは
定義
a computer programming language of limited expressiveness focused on particular domain

言語であり
コンピュータプログラミング可能
限定された表現（それが強み）
限定された領域


位置づけ
DSL script -- parse --> semantic model -- generate optional --> code

新しい視点・考え方
Lanugage Workbenches

MS DSL Tools
Meta Edit+
xtext(Eclipse plugin)
intentional
MS Oslo
projectional Editing


本は来年の中頃出す予定

QCon Tokyo 2009 Day1

QCon Tokyo 2009 - Home

聴講した講演は次のとおり

QCon Tokyo Day 1 Opening
長尾達也(コンポーネントスクエア)
Floyd Marinescu(C4Media)
ホスト：細川努、角谷信太郎、中台高宏


General Session 1
ドメイン固有言語 －その役割－
講演者：Martin Fowler(Loud-mouth on Object Design)


General Sessin 2
ビューティフルコード
講演者：まつもと ゆきひろ(Creator of Ruby)


Open Webの進展とその今後
講演者：Dylan Schiemann
Dojo toolkit co-founder and committer


Amazon Web Services in Action
講演者：Jeff Barr
Amazon evangelist


現場のITアーキテクトが知っておくべき10のこと  -  あるいは、技術が分かるPMが知っておくべき10のこと
講演者：鈴木雄介
日本Javaユーザー会幹事


アーキテクトの審美眼
講演者：萩原正義
マイクロソフト株式会社ソフトウェアアーキテクト

WWAN

どうりでVAIOのWWANが使えなくなっていたわけだ。
アップデートプログラムのご案内