OpenPNE3のインストール　その１ ～symfony導入からOpenPNE3導入まで～

手順に従ってやればすんなりインストールできました。
特に難しい作業は必要ありませんでした。

OpenPNE3 はフレームワークとして symfony を使っているようですが、symfony って、いろんな作業をコマンドラインから行うんですね。
データベースの初期化なんかもコマンドラインから一発で行えて楽チンでした。

次に、10月17日に作成された以下の記事を元に Apache で実際に動かしてみました。

OpenPNE3のインストール　その2 ～ブラウザからのアクセス～

上記の記事では Apache の設定ファイルにてバーチャルホストを追加して動かしているのですが、手元のマシンで同じようにやろうとすると Apache を起動するときに以下のようなエラーが出ました。

なんですかこのエラー。

なんかよくわからないのでバーチャルホストはやめて以下の設定で動かすことにしました。

「Alias /sf /usr/share/php/data/symfony/web/sf/」のパスは環境によって異なります。
ブラウザから見るには「http://localhost:8080/」にアクセスします。

ちょっとずつソースを解読していくつもりです。

講師: amachang

JavaScript は遅い遅いといわれているけど
ベンチマーク取ってみると Rerl とか Ruby 並みの速度
遅いのは DOM 関する処理

DOM 関連の処理を分解してみると、

1. コンポーネントとの通信
2. DOMノードの追加
3. スタイルの再計算
4. レイアウトの再計算

となる。

1 コンポーネントとの通信
XPConnect や COM との通信
IE が特に遅い
無駄なプロパティアクセスを減らすと良い
変数に入れるなどして

2 DOMノードの追加
ノードに「変更されたフラグ」が立つ
「parent.appendChild(child)」とすると parent と child にフラグが立つ

（DOM に対する処理をすぐに実行するのではなくて後でまとめてやるためにマークを付けとく、みたいな感じですかね。）

3 スタイルの再計算
スタイルの再計算が行われるタイミングを把握しておく必要がある
スタイルの再計算はどんな時に行われるか

1. 変更フラグが立っているノードがあるまま JavaScript が終了した
2. 変更フラグが立っている状態でスタイルの再計算が必要な処理を行った
   offsetWidth プロパティの値を取得したり

処理の順番を意識する必要がある
スタイルの再計算が行われるエレメントを意識する必要がある
子ノードとか下にあるエレメントとかもスタイルの再計算が行われる

4 レイアウトの再計算
要素の幅、高さ、位置の計算がここで行われる
激しく重い
→ 親ノードにも影響を及ぼすことがあるので
基本、スタイルの再計算に気をつけていればいい

プロファイラのデモ
各メソッドの実行時間とか、呼び出し回数なんかが簡単に調べられる
（safari 4 にはプロファイラが搭載されるらしい）

質疑応答
Q: 再計算のタイミングを知るには
A: Webkit をデバッガで起動。ログを仕込んだりして調べる。

Q: Webkit のソース解読 Tips
A: Webkit IDL ファイルを見ると良い

ギークなお姉さんができるまで

講師: べにぢょ (アルカーナ株式会社), purprin (エスカフラーチェLLC)

メモ取ってません。。
個人的にはあまり興味がわかない内容でした。
ただ、べにぢょさんがどんな人なのか見てみたかったんです。。
purprin さんの話がもうちょっと聞けたらよかったかもしれません。

『JavaからRubyへ』・アンド・ナウ

講師: 角谷 信太郎 (株式会社永和システムマネジメント), 高井 直人, 和田 卓人

EJB から Rails の流れの裏にどのような歴史があるのか、というようなお話
ちょっと僕にはうまくまとめられる自信がないというか、以下の記事に書かれていることがそのものずばりな感じなので、そこから一部を引用してお茶を濁すことにします。

JJUG CCC 『JavaからRubyへ』・アンド・ナウ を聞いてきました - yuum3のお仕事日記

新しい技術が次々と現れるIT業界ですが、新しい技術はある日突然に発明された訳ではなく、そこには歴史や必然があります。

Ruby on Rails も 天才プログラマーの DHH がある日突然発明したわではなく、前世紀(^^)にオブジェクト指向というソフトウェアの革新があり、そのムーブメントに集まった人たちの中から、デザインパターン や リファクタリング 、テスト駆動開発、アジャイル開発 などの手法が生まれました。また、それを実線することを広めた「達人プログラマー」のなどの影響のもとに Ruby on Railsは生まれているのです。そういう意味でDHHは天才というようり歴史に学び、それを統合した秀才型の人だと思いました。

YET ANOTHER GREEN IT

講師: 和田 卓人, 角谷 信太郎 (株式会社永和システムマネジメント)

ライブコーディングのデモンストレーションをやっていました（なので文章に起こすの難しい。。）。

Java 界隈では以前から開発手法に関する議論が盛んでした。
ペアプログラミングとかテスト駆動開発その中から生まれた手法です。
（手法というか命名することによって広く認知されるようになったというか）

ペアプログラミング
ペアプログラミングとは、二人でプログラミングする手法です。
一台のマシンを使ってコーディングします。
なので同時には作業できません。
ペアプログラミングの何がいいかというと、仕様やプログラム等の情報を二人で共有できることです。
開発と平行してコードレビューも行える、というふうにもとらえることができます。
いいことずくめですね。
ただ、二人の相性が合ってないとやりづらいと思います。
あとは、それぞれが使っているエディタが違うとか、キー配列が違うとかいうことがあると面倒なことになります。
そんなにいいことずくめでもないですね。

テスト駆動開発
テスト駆動開発とは、実際に動くコードを書く前にテストコードをまず書いて、その後にそのテストに対応する実装部分のコーディングを行っていく手法です。
（わかりにくい文章ですみません）
例えば、あるライブラリを使おうと思った場合、そのライブラリのテストケースを作ります。
こういうメソッドを呼び出したらこういう結果が返ってくるだろう、という情報をテストケースとして残していく感じです。
テストケースを書くのはなかなか面倒ですが、ちゃんと作っておけば後で修正を行ったりする際に非常に役に立ちます。
（って、僕は最近あんまりテストケース作ってませんが。。）

Agileは現場に適用できるのか？　～オンナだらけのパネル・ディスカッション～

講師: 片山 智咲子 (Java Edge), きたむら (日本XPユーザグループ), 柳本芙友子 (要求開発アライアンス)

パネル・ディスカッションってメモ取ったり記事にまとめたりするの難しいですね。。

なにかこう、釈然としないディスカッションでした。
アジャイルという言葉の意味が人によってまちまちだなぁ、とすごく思いました。

片山智咲子さんの意見が地に足がついている感じで良かったです。
アジャイルとかあまり気にせず、常に問題の本質をとらえようとしているように見えました。

java-jaプレゼンツ・第十一回 第2回チキチキ JJUG だよ全員集合 ライトニングトーク大会

省略

（おもしろかったです）

技術者の給料は昔に比べると上がっている
それに比べて計算機にかかるコストは年々安くなっていってる
人間が働くよりも計算機に働かせた方が高効率で生産性も上がる
コンピュータリソースを使い倒すべき
しかし、多数のマシンを使い倒すのは難しい
・自動テスト
・コードの品質検査
・ワークフロー管理
など
よいツールを使わないと生産性は上がらない

（そこで）

Hudson

Java で実装された CI サーバー
（CI とは継続的インテグレーションの意味）
（参考: 継続的インテグレーション）
→多くのプロジェクトで使われている
→人間間の無駄なコミュニケーションを減らす
→あたかも新たなチームメンバーのようにせっせと働いてくれる→執事のよう
→オープンソース→誰でもコミッタになれる

基本機能
→ソースコードをリポジトリからチェックアウト
→ビルド
→結果を記録

デモ
→簡単に動かすことができる
（ユーザーインターフェイスがとても良くできてる印象を受けました）

自動テスト
→テストに非常に時間がかかるようになってくる
→テストは並列化しやすい
→複数のマシンで同時にテストを走らせることができる
→比較的用意にセットアップできる

感想

個人的にはこの講演が一番良かったです。

Java って基本、コンパイルしないと動かないんですね。
すべてのソースをコンパイルして最終的な成果物を作り上げる作業をビルドというんですけど、そのビルドが結構手間なんですね。
あと、最近のシステム開発のトレンドは、テストケースをたくさん書きましょう、まず最初にテストケースを書きましょうみたいな流れになってます。
テストケースというのは自動テストで動かす個々のプログラムのことです。
通常、ビルドした後に自動テストを行うんですけど、それにはものすごく時間がかかるのが普通です。
システムが大きくなるとテストの数も膨大になってきます。
テストに何時間もかかる、なんてこともざらにあるようです。

このようにして、ビルドという作業は人間にとってどんどん面倒くさいものになっていきます。
だったらそのためのツールを作って全部自動化しちゃえばいいじゃん、という考えから生まれたのが Hudson なのです。

Hudson というツール自体もすごいのですが、講師である川口さんの「コンピュータリソースを使い倒せ」という考えには非常に共感できました。
無駄な作業をそれとわかりつつも愚直に繰り返してたり、ってことを意外とやってるんですよね、人って。
コンピューターにできることはコンピューターにやらせるべきです。

講師: 丸山 不二夫 (早稲田大学)

えーっと、いろんな方面の話が次から次へと出てきてついていくのが若干大変でした。。
消化しきれてないです。

ムーアの法則の終焉
ムーアの法則がいずれ終わりをむかえるそうです。
情報1bitを蓄えるのに必要な電子の数を考えるとそれは必然だそうです。
（多分その先は量子コンピュータとかの世界になるんですかねぇ ＞ suzuki くん）
計算すると、ムーアの法則は2010年くらいに限界に達してしまうらしいです。
ムーアの法則の最後を飾るのがモバイルデバイスなのではないか、というふうに考えていてるそうです。

マルチコア
（気づいたらマルチコアとかの話になってました。話の展開早すぎ。。）
今やマルチコアの時代。
PCに搭載されるCPUの数はどんどん増えていく。

ネットワーク
ネットワークの進化がコンピュータの進化を上回る。
通信速度がどんどん速くなってる。
→サーバーをつなげてスケールアップするための基礎となる。
マシンの内部バスよりもネットのスピードの方が速くなったらどうなるか。
→そうなるとコンピュータは今の形であることをやめるだろう。
→新しい「分散」の可能性。

Cloud
インターネットCloud
→SOA、Web2.0
→これらはCloudの予兆であった
すべては Google から始まった
→Google はインフラを持っていた
インフラがすべてである
→Microsoft, Google, Amazon →ちゃんとしたインフラを持っている
サービスや情報がCloudからくるという考え方
→Cloudの実体はリアルなインフラである

スケールアップかスケールアウトか
Google
→スケールアウトするシステムを作り上げた
Cloud サービスの巨大化が寡占化を招く
Google は世界第四位のコンピューターメーカー（へ〜）

Multi-tier
アプリケーションサーバの層で分散してもDBがボトルネックに
→分散メモリーキャッシュを使う

Cloud上のデータサービス
リレーショナルデータベースもいずれ時代遅れになる
→キー・バリュー型へ

Google App Engine
いずれJavaに対応するだろう
→そうなるとビジネス分野に入ってくるはず
プログラムの作り方が変わってくるだろう
O/Rマッピングも過去のものになるかもしれない
→もともとインピーダンスの違うものをくっつけようとする技術
→キー・バリュー型へ

Cloudとの連携が切り開くAndroidの可能性
（やっとAndroidの話）
オープンソースの可能性
→携帯のオープン化の動きは非常に重要である
携帯市場は巨大
→デジタルデバイドの終焉をもたらすかもしれない
→アフリカの成長率が著しい
→コミュニケーション手段の重要性

携帯の機能を好きなデバイスにポーティングできる
→これはすごいこと
（携帯電話を自分で作れるようになる？）

新しい市場の可能性
→日本の強みを活かせるんじゃないか
→ハード、ソフト、コンテンツ、それぞれの分野で

感想

話の展開が速くてついていくのが大変でした。
お腹いっぱいです。

レスポンスヘッダーの「Last-Modified」と以前ダウンロードしたローカルマシン上のファイルのタイムスタンプを比べてるっぽいです。

ちなみに、「-S」スイッチを付けるとレスポンスヘッダーの情報が出力されます。

参考:
GNU Wget 1.9 Manual: タイムスタンプ

Web サイトのスクリーンショットを作成するためのコマンドラインツールを作りました。
XUL アプリケーションです。
コマンドラインからプログラムを実行するだけで簡単に Web サイトのスクリーンショットが作成できます。

更新履歴

2008.10.10

Web ページを表示した後に2秒待つように修正しました。

ダウンロード

xul_web_screenshot-ver_1.tar.gz

必要なもの

• X.org or Xvfb
• xulrunner 1.8 or later

使い方

例えば、「http://kono.d4k.net/blog/」のスクリーンショットを作成したい場合は以下のようなコマンドを実行します。

「-type」オプションを付けることで画像フォーマットを指定できます。

以下が実際にこのツールを使って作ったスクリーンショットです。

参考にしたページ

以下のページが非常に参考になりました。

Latest topics > ウィンドウ全体を覆い隠してゴニョゴニョするためのライブラリを作った - outsider reflex
Latest topics > フォルダの指定で相対パスと絶対パスの両方の指定に対応する - outsider reflex
SCRAPBLOG : canvas要素によるWebページのスクリーンショット保存機能

Ruby1.9 の現状と今後

講師: 高橋征義

• 1.9 で大きく変わる部分
• YARV
  VM 化
• M17N
  マルチリンガライゼーション
• yugui さんがリリースマネージャに
• BTS（バグトラッキングシステム）の導入
  Redmine を使用。メーリングリストと連携できるようにしているらしい。
• miniunit
• ユニットテストライブラリ
• Ruby1.9 から標準添付されるらしい
• その他
• 文字コードまわりでまだ仕様がゆれてる？

kono メモ

Ruby 1.9 での大きな変化の一つに、文字列自体が文字コードの情報を持つようになる、っていうのあります。
それによって、文字コードに関する作法が今までとはかなり違ってくると思うので初めは戸惑いそうです。
もう一つの大きな変化は VM 化ですね。
ベンチマークによると、かなりの部分で 1.8 に比べて速くなっているみたいです。

今年のクリスマスあたりにバージョン 1.9.1 をリリースすることを目指しているそうです。

Plone が開く CMS 新時代

講師: 山本 烈

• Plone とは
• CMS（コンテンツマネジメントシステム）
• Zope をベースにしている
  （Zopeは、プログラミング言語Pythonで書かれた、オブジェクト指向ウェブアプリケーションサーバ、もしくはWebアプリケーションフレームワークである。by Wikipedia）
• Plone 3
• 去年リリースされた
• 新世代（らしい）
• Ploen の特徴
• 多言語対応
• 権限
  ユーザーや、グループに対して細かく権限を割り当てることが可能
• コンテンツの管理機能
• 履歴管理
• 承認フローみたいなものを作れる
• コンテンツが編集されたとき等に行うアクションを決められる（メール送信したりとか）

kono メモ
あんまり突っ込んだ内容の話はなくて、基本的なところ（使い方とか、事例とか）の話が中心でした。
CMS と一口にいってもいろいろあると思いますが、plone で一通りのことはできそうだなぁ、という印象を受けました。
多言語対応に関してはすごいと思いました（普通に使う分には多言語とかあまり意識することはないかもしれまんせんが）。
ただ、python っていうのがネックになる気がしました。
日本だと python を使ったことも見たこともない人が結構いると思うので、かなり抵抗を感じるだろうなと。
あっち（欧米）ではかなり使われてるみたいなんですけどね。

その他の CMS と比較して plone はどのへんが優れているのか、という話をもうちょっと聞きたかったなぁ、と思いました。

CodeIgniter 〜 2008年大躍進のPHPフレームワーク

講師: 天野（日本CodeIgniterユーザ会）

CodeIgniter の紹介ですね。
プレゼン資料を発見したので貼り付けておきます。

kono メモ
CodeIgniter って GET パラメータを扱えないとばかり思ってました。
なので、「GET パラメータが使えなくて困ったことはないですか？」って質問してみたんですけど、使えるようにできるそうです。

あ、そういえば最近 IBM の developerWorks にこんな記事がありました。
CodeIgniter 入門

テンプレートファイルは webapp ディレクトリ以下にあります。
マイホームのテンプレートは webapp/modules/pc/templates/h_home.tpl です。
このファイルを直接編集すればそれがすぐにマイホームに反映されて目的は達成されるのですが、普通はそういうやりかたはしません。
ソースに手を入れたい場合は、webapp_ext ディレクトリ以下に同じ名前のファイルを作成して、そっちをいじるようにします。
そうすることで、OpenPNE のバージョンアップの際に webapp 以下のファイルが変更されても影響を受けないようになります。

まず、webapp_ext ディレクトリを用いてのカスタマイズを機能させるために OpenPNE の設定を変更します。
以下のようにして config.php に定義されている USE_EXT_DIR に true をセットします。

次に、webapp/modules/pc/templates/h_home.tpl をコピーして webapp_ext/modules/pc/templates/h_home.tpl というファイルを作ります。
そして、webapp_ext/modules/pc/templates/h_home.tpl のファイルの先頭に「hoge」という文字を追加して保存します。
すると、マイホームに「hoge」が表示されると思います。

簡単ですね。

吉武 茂 さんのお話

Google Chrome をかなり意識してる感じでした。
オープンソースのブラウザがたくさん出てきているなかで、Firefox はどういう方向に進んで行くべきか、というような話。

以下、プレゼンのメモです。

------

firefox のブランディングが難しくなってきた

ソフトウェア開発のジレンマ
効率的に組織を運営していくにはどうしたらよいか。
=> 「Nobody knows anything.」（全てを知っている人は、誰もいない）

google の技術陣はやっぱりすごい。
（超えられない壁…）
=> そんな中でも Mozilla はがんばっている

現在のブラウザ状況
=> それぞれ方向性がまったく違う

Mozilla はソフトウェア開発組織として "Chaordic system" を目指す
=> Charod: chaos + order
（このあたりから話が抽象的に…）
=> カオスの形成は不可避だが…
=> あえて許容
=> 秩序も最低限必要

------

吉武さんの話は正直つかみどころがない感じがしました。
たぶん話が大きすぎて僕には理解しづらかったんだと思います。

浅井 智也 さんのお話

Firefox がどのように進化してきて、今後さらにどのように進化していくか、という話。

以下、プレゼンのメモです。

Firefox 2

• ブラウザの革新をリード

Firefox 3

• アプリケーションプラットフォームへ
• 史上最速
• メモリ効率の向上

Firefox 3.1

• タブ切り替えで縮小プレビュー
• 全タブの一覧表示と検索
• スマートロケーションバーの改善
• HTML5 の実装
• audio、video タグ
• ドラッグ＆ドロップ
• ダウンロードフォント => CSSにフォントを埋め込めるようになるらしい
• script タグで読み込むスクリプトの遅延評価
• ドラッグ＆ドロップ

• CSS
• メディアクエリー

• JavaScript
• 新 JavaScript エンジン
• JSON のネイティブサポート
• ワーカースレッド API => マルチスレッド的な処理が書けるらしい

• デモ
• CSS で文字を斜めにできる
• 拡大縮小回転ができる
• video や audio を操作できる。canvas 上に配置できる
• アニメーションが簡単に作れる
• ブラウザ上での JavaScript による画像の加工。処理スピードが早い

• デスクトップの置き換えへ

感想

Firefox 3.1 のデモが非常におもしろかったです。
HTML と JavaScript だけで Flash と同等かそれ以上の機能を提供することが可能になっていきそうな雰囲気です。

あと、11月16日（日）に Firefox Developer Conference っていうのがあるらしいです。
多分僕は行きます。

担当: ヒューレット・パッカード株式会社
講師: 伊藤 康史

前にいた会社で Hadoop を調べている人がいて個人的に気になっていたので聞きにいってみました。
Hadoop とか、そもそも分散ファイルシステムってなんなんでしょう。
ものすごくざっくり説明すると、大量の PC を使って、巨大なファイルや大量のデータを扱うための技術です。
グーグルの検索エンジンのバックエンドの仕組みがそんな感じになってます。
大量の PC でデータを保持し、それを大量の PC を使って効率よく処理します。
Hadoop というのは、グーグルが研究して編み出したその技術をオープンソースで実現しようというものです。
Google が作ったのと似たようなシステムをオープンソースで作ってるわけです。
これを使うと Google みたいに大量のデータを大量の PC で処理することが可能になります。
しかし、いまいち何に活用するのか想像できませんよね。
活用事例と以下のようなものが紹介されていました。

A3 - Amazon
    製品検索インデックス、数百万件/日の分析処理
Facebook
	内部ログや次元データの保存、レポートや分析用情報源、機械学習
… など、多数
    http://wiki.apache.org/hadoop/PoweredBy

なるほど、規模の大きなサイトになってくると普通のマシンじゃデータをさばけなくなるんでしょうね。

Hadoop が実際にどういう仕組みで動いているのかはいまいちよくわかりませんでした。
よくわからないというか、実感がわきませんよねぇ、こういうスケールの大きなアーキテクチャって。
ちゃんと理解するためには実際に自分で構築して動かしてみる必要がありそうです。

なんでヒューレット・パッカードの人が分散ファイルシステムの話をしていたかなんですが、分散ファイルシステムって大量のハードウェアを使うわけですよね。
そうするとその管理・運用が結構大変になってくるわけです。
そのためのソリューションを HP がご提案しますよと、そういうわけです。

参考リンク:
http://hadoop.apache.org/