scribeFireとamazlet

複数エントリを投稿すると</div>が削除されてしまい、HTMLがくずれてしまう。
amazletを使う場合はbloggerのダッシュボードで投稿すれば問題ない。

YAPC::ASIA2009 買い物

プロダクティブ・プログラマ -プログラマのための生産性向上術

posted with amazlet at 09.09.12

Neal Ford
オライリージャパン
売り上げランキング: 62183

おすすめ度の平均:

Javaに偏っているのが -1
気軽に読めて役に立つ、中級？ソフトウェア開発者向けの良書

Amazon.co.jp で詳細を見る

リファクタリング・ウェットウェア ―達人プログラマーの思考法と学習法

posted with amazlet at 09.09.12

Andy Hunt
オライリージャパン
売り上げランキング: 4985

おすすめ度の平均:

この手の本に食傷された方に…
学ぶための遊び
全ての学習者が読んで実践するための本
まとめ本

Amazon.co.jp で詳細を見る

Head Firstソフトウェア開発 ―頭とからだで覚えるソフトウェア開発の基本

posted with amazlet at 09.09.12

Dan Pilone Russ Miles
オライリージャパン
売り上げランキング: 74901

おすすめ度の平均:

開発プロセスなどの具体性をもっと欲しかった
怒りは理解力の足を引っ張ります。

Amazon.co.jp で詳細を見る

Head First Statistics

posted with amazlet at 09.09.12

Dawn Griffiths
オライリージャパン
売り上げランキング: 36745

Amazon.co.jp で詳細を見る

デザイニング・ウェブナビゲーション ―最適なユーザーエクスペリエンスの設計

posted with amazlet at 09.09.12

James Kalbach
オライリージャパン
売り上げランキング: 17846

おすすめ度の平均:

タイトルに偽り無し
よくまとまってる

Amazon.co.jp で詳細を見る

YAPC::ASIA2009 LT

キーワードだけ

• nginx
• Mojo
• Gtk2::Notify
• Lingua::*
• Flash XML-Socket
• curl

YAPC::ASIA2009 hatena bookmarks

日本では大きいほうだが、GoogleやYahoo、Amazonに比べれば小規模
30万ユーザ、400万セッション/月、1,600万URL/4,700万ブックマーク
->あるテーブルの件数が3億!

ハードウェアリソース
エントリ3.0GB、ブックマーク5.5GB、タグ4.8G、HTML zlib圧縮で200GB
Webサーバー10台、検索70台

コード量
12万ステップ、業務ロジックが45,000ステップ、1200モジュール

人的リソース
9名体制　マネージャ1、エンジニア3+3、デザイナ1+1

各機能の実現方法
・本文テキスト抽出ライブラリ HTML::ExtractContent
本文テキストの判断方法、句読点が多い場合本文の可能性が高い（スコアをあげる）
８，９割は適切に判断。１，２割が失敗

・全文検索機能
全登録文書からの検索にはPFIのSedueを利用
個人の登録ブックマークからは、転置インデックス方式を用いて
N-Gramと形態素解析でヒューリスティックス
Array::Gap、Lux::IO

Naive BaysよりはCompletement Naive Bays

TheSchwartz様サマ

Web+DB Vol.49よろしく

YAPC::Asia 2日目 「はてなブックマークのシステムについて」 - naoyaのはてなダイアリー

YAPC::ASIA2009 Mala

AnyEventとCoroのお話
WebHooks->サービス間のリアルタイム連携
イベント駆動プログラミングのWeb版ともいえる
PubSubHubBub->分散型のpingといえる
これを使ったストリーミングAPIを開発中。近日公開予定。
ただし非同期対応のアプリケーションサーバーが必要
Apache NG
lighttpd OK

YAPC::ASIA2009 endeWorks

スピーカーは33rpmさん
牧大輔さんの会社
開発サーバーはもってない。個人のPCで開発
Test::FITesque
Apache+FCGI
daemontoolsでプロセス監視

Catalystを使用して開発。でもModelは使用していない。
もちろんMoose使用
RegistryモジュールがDIコンテナ

複数行の検索結果をキャッシュする場合
全データを保持するのではなく、PKの配列をキャッシュする。

pixis使ってます。
pixisはJPAサイトで使われている技術

YAPC::ASIA2009 Day2 DeNA

DeNAはもともとbiddersをJava+Oracleでシステムを作っていた
今ではPerlによるサービス　mbga.jp mbkr.jpを筆頭にいろいろ
理由は、開発速度、可読性が思ったよりよかったから。
MobaSiFをオープンソース化したが、いろいろ突っ込みがある
「大勢で使う割には自由度が高すぎる、テストしてなさすぎ」
携帯向けメール配信にmobamailを作ったけど、商用SIELLAと合わせ技で運用

トピックとしてmbga.jpのオープン化。
mixiアプリケーションのような課金モデル
モバゲーAPI公開
9/10デベロッパーサイトオープン
10/5フォーラム開催　パートナー受付開始

「作ったものをたくさんの人に使ってもらいたい」という思いをエンジニアをはじめみんなで共有
（これ大事だよな。）

開発方針
一筆書き文化：再利用、汎用性の設計に時間をかけるよりは開発速度を重視

YAPC::ASIA2009前夜祭

キーワードだけ

• HTML5
• HTTP::Engine
• 全裸
• http://www.oswd.org
• Q4M
• Twib
• Plack
• Noe

照明調整が下手ですみませんでした。

三越ライオン像

今NHKで紹介されていたのですが、三越のライオン像には必勝祈願の像らしいです。
仕事に行き詰ったら、こっそり跨ってこようと思います。

三越ライオン像の意味？ - “あっキ－ンの気の向くままに!”

このライオン像は、“必勝祈願の像”として、誰にも見られずに背にまたがると念願がかなうと言い伝えられ、特に受験生の間に人気があります。

YAPC::Asia Tokyo 2009

今年も参戦予定
京都じゃないのか。

YAPC::Asia Tokyo 2009 - Japan Perl Association運営ブログ

長らくお待たせいたしましたが、YAPC::Asia Tokyo 2009のスケジュールが正式に決定いたしました！今年のYAPC::Asia Tokyoは9月10日および11日に開催されます。9日は前夜祭として短めのセッションを行う予定です。

本年のYAPC::Asiaも東京工業大学様のご厚意により、大岡山キャンパスで開催される予定です。

バービーボーイズリマスター盤

そんなに違うのか。
買っちゃおうかな。

バービーボーイズ完全復活への道

今、「Freebee」を聴きながらブログ書いてまず。

この音、やっぱ凄く良くなっています。感激ひとしお。もし、皆さんがバービーのオリジナルアルバムのCDをお持ちでしたら、連休中に一杯聴いておきましょう！一番好きなアルバムを聴き込むのもいいと思います。そして、5/27の発売日になったら、すぐにリマスター盤を1枚でも買って、それを同じプレーヤーで聴いてもよう！

いまみちともたか ima_gene_box 書斎頁

バービーのオリジナルアルバム計6枚の
リマスタリングされたCDは
自分が責任を持って立ち会ってナニしている。
でも改変したりルール違反はしちゃないし
これが最後の音質調整作業、そして
自分はまだ耄碌もしちゃないです、はい。

Google site

http://springframework.jpのサイトの様子が変わっていることに気がついた。
今までのWikiスタイルから様変わりしているようだ。どうやらGoogle サイト　とやらを利用している。

Googleのホスティングサービスなのか？
自分が持っているサイトを移行できるかどうかはもう少し調べてみないと。
とりあえずメモ代わりに。

サイト

生産性

引用した記事では「生産性」という語を「コードの量」として使用しています。
だいたいの場合において、この「生産性」という言葉は「量」を表します。
同じ結果を得るにしても、使用する言語やフレームワークによってコードの量は変わってきます。
最終的に言語やフレームワークを学習して仕上がったコードが２、３行だったとしても
学習のコストもかかるわけで、そのときの「生産性」とは何をあらわすのでしょうか？
アウトプットまでの時間？やっぱり結果としてのコード量？
そろそろ、数字で表せない言葉を使って議論するのをやめにしませんか？


ぼくがLLのひとに「ガツン」と申し上げたこと - ひがやすを blog

追記:コメントにも書いたけど、あの場では、仮にということで、Javaのほうがコードの量が多いという話にしましたが(そうでないと話がかみ合わないので)、実際は、フレームワークレベルだと、例えばRails(Ruby)とSeasar2(Java)を比べてもそんなに生産性(書く量は2割くらいはSeasar2のほうが多いかもしれないけど)は変わらないと思いますよ。

jsugのrss

なぜなのかはわからないのですが、JSUGのRSSを
GoogleReaderで読もうとすると、
2008年7月22日以降のエントリが表示されない。
Rodさんとの飲み会の話とか見落としていました。

これからはこまめに見るようにします。

Japan Spring Framework User Group | Google グループ

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