Saturday, August 01, 2009

三越ライオン像

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

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



Tuesday, July 14, 2009

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は
自分が責任を持って立ち会ってナニしている。
でも改変したりルール違反はしちゃないし
これが最後の音質調整作業、そして
自分はまだ耄碌もしちゃないです、はい。


Sunday, June 21, 2009

Google site

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

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

サイト


Sunday, June 14, 2009

生産性

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


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



Sunday, May 03, 2009

jsugのrss

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

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

Japan Spring Framework User Group | Google グループ


Saturday, April 11, 2009

QCon Tokyo 2009 雑感

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

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

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

Friday, April 10, 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の3点から統合ビジョンを提供する

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


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

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

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

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

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

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



2.アーキテクチャとは
定義がいろいろ

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

デザインの輪郭
デザインの輪郭
posted with amazlet at 09.04.10
深澤 直人
TOTO出版
売り上げランキング: 16571
おすすめ度の平均: 4.5
4 じわり、じわりと
5 夜寝る前に、ふと手に取りたくなる本
4 何度も読むと良くなってくる
5 じわじわと感じてくる本
5 生きることを大切に、そして丁寧に。


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
動的にエンティティを定義

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

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


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

内面の美
コードに内在

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

自覚や自発が必要だ

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

「理解」が鍵


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


まとめ

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

そういう自覚が大事


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

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

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があります。

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

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

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

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

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


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

2.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


本は来年の中頃出す予定


Thursday, April 09, 2009

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が使えなくなっていたわけだ。
アップデートプログラムのご案内


Sunday, March 15, 2009

git

最近はgitなんですね。


clmemo@aka: Git 本を注文しちゃった
最近、バージョン管理ソフトの git が楽しくてしょうがない。で、日本語の解説本がないかと探しているんだけど見つからない。
Git Cheat Sheet 日本語版 | textdrop

Friday, February 27, 2009

「なんでもいい」とエンドユーザに言われたら

これはエンドユーザがよく言うなぁ。
彼女とエンドユーザの扱いは一緒かもしれない。

「なんでもいい」とエンドユーザに言われたら
  1. 「なんでもいい」とは「勝手にやっていい」という意味ではないことを肝に銘じる
  2. EJB、ハイスペックはフレームワークは避ける
  3. 付加価値を提供する
  4. アフターサービスを保障する
  5. 困ったときは現行にあわせる



「どこでもいい」と彼女に言われたら

  1. 「どこでもいい」は、どこでもいいという意味ではないことを肝に銘じる。
  2. 揚げ物の店、ボリューム自慢の店は避ける
  3. 付加価値のあるお店を選ぶ
  4. デザートが美味しい店
  5. 困ったときはイタリアン



Thursday, February 26, 2009

文章がわからない

強制による教育のすすめかたが「教師としての職業倫理」に読みとれてしまうので、添削。

同氏は、子供の納得のもとに教育をすすめるという「教師としての職業倫理」が強制によって打ち砕かれているとし、


砕かれた教師の倫理/「日の丸・君が代」強制 精神科医が証言/東京地裁
同氏は、強制によって子どもの納得のもとに教育をすすめるという「教師としての職業倫理」が打ち砕かれているとし、「家族や自分の命を失うのと同じぐらいの喪失」だと説明。

Sunday, February 15, 2009

1234567890 Day

1234567890 Day

こんな楽しそうなイベントがあったなんて知らなかった。

perl -MTime::localtime -e "print ctime(1234567890);"


4/12追記
UNIX time が「1234567890」になる - スラッシュドット・ジャパン
本家タレコミからリンクされているLinux Pro Magazineで紹介されているように、Perl Script「perl -e 'print scalar localtime(1234567890),"\n";' 」で自分の地方時における時間を知ることができる。


# スクラムマスターを雇う時に聞いてみるとよい47個の質問

  # スクラムマスターを雇う時に聞いてみるとよい47個の質問 スクラムマスターへの質問というPDFがあるので、回答してみた。 定期的に自分の回答がどう変わっていくのか楽しみだ。 Scrum Master Interview Questions: Free Download of...