ESPer2008行ってきた
次の日に用事があって前日に上京することになったので、何かイベントがないかとIT勉強会カレンダーで探したところESPer2008を発見しました。前日でも人数が上限に達していなかったので助かりました。
想像以上に刺激的な話が聞けて、個人的に特に面白かったのは小野さん、ゆーすけべーさん、ひげぽんさんの話でした。
ということで以下まとめ。
グリーンITのすすめ -未踏的アプローチに向けて-（加藤和彦PM 筑波大学大学院システム情報工学研究科）
- 普段、PCを置いてある部屋やひざの上のノートPCや無線アクセスポイントなどで暑い思いをしているのではないか？
- 未踏的にこの熱を減らすことはできないか？
- 京都議定書は日本に不利にできているかも
- グリーンITの3つの可能性
- 人やモノの移動の効率化（ITによる）
- 産業活動の生産性向上（ITによる）
- 機器のエネルギー効率の向上（ITそのもの）
- サーバ統合、クラウド化、SaaS化など
- RAIDはCO2の排出量が多い → MAID（メイドさんではない）
- 年間電力消費が減っても、それに対する投資がその100倍では･･･ → 費用対効果を考えた対策が必要
未踏のPMの方です。前期採択0件なので後期に予算を全力投入でき、採択件数も多くなりそうとのことですので、グリーンITで未踏に応募してみるのもよいかもしれませんね。
HDDが安価になったことで、SBMとかミニブログの情報をクローリングするタイプのサービスが増えている昨今ですが、ちょっと資源を無駄にしているよなー、とか思ってしまいます。
省電力、熱対策はサーバを運用するなら考える必要がある話ですが、仮想化のようなソフトウェアアプローチは面白いと思いました。
パッケージベンチャーの立ち上げ（小野和俊さん 株式会社アプレッソ）
- http://blog.livedoor.jp/lalha/ （ブログ）
- http://twitter.com/lalha （Twitter）
- 作ったソフトウェアとか
- 日本のIT業界はSIが多数を占め、パッケージベンダーは非常に少ない
- 売り上げ曲線のタイムライン(成功ケース)
- SI ･･･ リスクはないけどブレークしにくい
- サービス ･･･ マネタイズに時間がかかる
- パッケージ ･･･ 比較的マネタイズが容易かつブレーク可能
- 起業のHowToについては総務省の資料が秀逸
- http://www.soumu.go.jp/s-news/2008/080307_3.html
- 実体験を基にした生々しい情報が書いてある
- 立ち上げはこれで大体OK
- ブログ/Twitterがプログラマ同士をつなげる時代
- 履歴書のより、その人の日常を知ることができる
- 小野さんの会社でも何人か採用実績有
- パッケージベンダーのビジネスの収益構造
- ライセンス
- メンテナンス
- 通常、15％〜20％の年間メンテナンス料
- これをもらわないとおかしい
- 使い続けてくれるお客さんがどの程度出てくるかが鍵
- ちゃんとつかってくれればそのお金で新しいプロダクトを作ることができる
- パッケージベンダーのフェーズ
- ソフトウェア開発フェーズ
- ソフトウェアの完成がゴール
- 資金が穴の開いたバケツのように減っていく
- 苦しくても受託開発と言う｢禁断の果実｣に手を出さない
- ソフトウェアラウンチフェーズ
- ソフトウェアの販売がゴール
- 軌道に乗るのが先か、資金が尽きるのが先か
- 顧客の視点：いつつぶれるかわからない弱小ベンチャーのパッケージを採用して大丈夫か
- 製品そのものより個人の技術力を信用してもらうことが重要
- メンテナンスフェーズ
- ソフトウェアのデファクトスタンダード化・ブランドの確立がゴール
- 製品出荷後に見つかった問題への対応コストは事前に問題を検知できた時の数倍から数十倍
- 4期：新規ソフトウェア開発フェーズ
- 二本目の柱を確立する
- 集金エンジン、キャッシュカウを確立
- ソフトウェア開発フェーズ
- 永遠の中級者
受託開発を｢禁断の果実｣と言っていたのが興味深かったです。確かに受託は売り上げを上げるには手っ取り早い手段ですが、そこに人的資源を割いてしまうと自社製品の開発がおろそかになってしまいます。受託を受けた知り合いの会社が結局SIになってしまったり、消えていってしまったりと言う話がリアルでした。
永遠の中級者の話は、パッケージだけじゃなくてWebやそのほかのUIを持つソフトウェア全般に言えることだと思います。この辺を意識していないとどちらかに偏ったものになってしまいがちな気がします。
いつの間にか社長になっていた〜未踏と社長と開発と〜（ゆーすけべーさん 株式会社ワディット）
- http://yusukebe.com/
- http://twitter.com/yusukebe
- 修士卒業後、ニートになる予定が気づいたら社長になっていた
- 未踏で採択されたもの：音楽でつながってコミュニケーションを行うソフトウェア→どうみてもLast.fmです。本当に(ry
- Last.fmに負けて、サービスにできなかったという悔しさ→これがいい経験になった
- 株式会社ワディット：和田のITだから
- 一年ぐらい仕事がない → 開き直って｢迎合するようなのはやめよう｣
- ｢面白いものを作って日記（ブログ）で発信していこう｣
- エロギーク宣言
- 07/9/29
- erogeek is not geek
- エロを促進する技術
- エンジニアの勉強会に行くとお世話になってますといわれる
- すると仕事が振ってきた
- エロギークというブランディング
- タブーっぽいアダルト業界
- おおっぴらにする
- エロという尽きない欲求
- 積極的にこちらから出向くような営業は必要なくなった
- これをウェブプレゼンスドリブンマネッジメントと呼んでいる
- ウェブで発信している内容に沿った自分しかできない受託開発
- Subversion + IRC で鎌倉にいながらも渋谷の人たちと開発できる
- おまけ：シエスタの薦め ･･･ 朝が2度来る
- 経験がとにかく足りないので将来のために泥のようにコードを書く
ブログ/Twitterを書いて、サービスを公開して、というようなセルフブランディングは積極的に行っていきたいところ。
おおっぴらに｢エロサイト作ってるよ！｣と言うことで、この分野に関してものすごいブレークスルーをしていると思いました。
パフォーマンスチューニングの基礎の基礎（ひげぽんさん サイボウズラボ）
- Mosh ･･･ Shemeのインタプリタ
- Mona ･･･ OSSのOS
- こんな経験ありませんか？
- いくらチューニングしても早くない
- 森に迷い込んでしまった
- 早くするのに大幅変更いるけど、ちゃんと早くなるかわからん
- なんかわかんないけど早くなった
- 問題点：方法論がいまいち浸透していない
- やってはいけないこと
- パフォーマンスを後回しに
- ×リリース直前にチューニングすればいいや
- 最悪の場合どうしようもなくなる
- 速度を計測しない
- ここがいかにも遅そうだから
- memcachedにキャッシュしよう
- インライン展開しよう
- インラインアセンブラにしよう
- プログラマは謎の直観力で遅いところを見つけるけど、結構な確率で外れる
- ここがいかにも遅そうだから
- 小さなパフォーマンスのために良いデザイン、機能性、柔軟性を壊しては駄目
- memcached → コード量が増える、コード本来の目的がぼんやりするなど
- インライン展開 → build時間が増える、インターフェースが読みづらくなる
- パフォーマンスチューニングにはコストとリスクがある
- パフォーマンスを後回しに
- チューニングを開発プロセスに
- 開発→測定→チューニングというサイクル
- 最初 ･･･ ゴールを決める
- 開発 ･･･ パフォーマンスのことは考えず、良いデザイン良いコードに集中！高速化できそうな箇所はコメントにメモする
- 計測 ･･･ 短いサイクルで計測する → 遅くなったら一つ前の開発が悪い
- チューニング ･･･ 目標を満たしていなければ行う
- 開発→測定→チューニングというサイクル
- 測定
- 環境構築
- 初期の環境構築で効率が変わる
- 本番環境に近い形で
- 記録と参照
- 過去のデータを保持してレポジトリに入れる
- どのチューニングがいい成績を出したのかがわかりにくい
- グラフを描く
- グラフで一目瞭然
- 遅いところはどこか？の道具
- プロファイラ
- プロファイラがない場合は
- ストップウォッチ
- ログ
- プロファイラ実装
- VMでは普通のプロファイラが使えない
- プロファイラを作ろう
- 一定の間隔で実行を割り込み
- そのとき何してたかを記録
- 環境構築
- おまけ：Shibuya.lispを立ち上げ
- 10/18にteck talk
DJ Player for iPhone（星野厚さん 株式会社ニューフォレスター）
分子計算支援システムWinmostarの開発とTencubeの起業（千田範夫さん テンキューブ研究所）
- Winmostar分子計算ソフトの開発
- サルでもできるMO計算
- 量子化学計算などの小難しい計算を簡単にできるように
- 機能向上をして専門家も使うツールとして
- 得意な言語はFORTRAN
- 計算化学系のテーマは未踏では非常に少ない
- 千田 = 1000 = 10 ^ 3 = テンキューブ
- 商標登録に8ヵ月半で17万円
- アカデミックフリーのものがWebmostarは定番ソフトになってきている
- Tencube/VMを商用版として10万円ほどで
- 雑誌に取り上げられたけど広告がナニでアレだったので会社では自慢できなかった
- グリーンIT
- 分子計算で物性の予測や合成方法の提案、分析データの解析など
- 軽い、簡単、きれいの3Kで
- アカデミックフリーでデファクトスタンダードを目指す
- DelphiからFortranの外部プログラムを呼び出している
定年で会社を退社された世代の方ですが、まだまだ現役と言うのがすごいです。
計算化学のようなソフトウェアだと確かになかなか売れなそうなものですが、アカデミックで無料に提供すると言うのはいい方法ではないでしょうか。
ところどころに挟む笑いの部分が非常にうまいプレゼンだと思いました。
事典検索システムCycloneの展開（藤井敦さん 筑波大学大学院）
- 研究内容の紹介：自然言語を中心とした計算機科学と情報学
- 時点検索サイトCyclone（ http://cyclone.slis.tsukuba.ac.jp ）
- Webから見出し語と説明を収集し体系化・多様な検索機能
- 今回のテーマ
- Cycloneのその後
- 画像との統合、自動予約、特許への応用など
- NEDOで採択
- 背景
- 知的な想像の成果を活用して国際京省力を強化する動きがある
- 特許=知的財産権の一つ
- 特許情報に内在する知識を体系化できれば学術や産業における価値が高い → 特許情報を用語辞典として活用する検索システムを構築
- なぜ特許情報から用語辞典を作るのか？
- Webになく特許情報には存在する用語があるから
- 提案するシステムの機能
- アンケート調査による評価 → 49％が良いと回答 → 既存の検索システムと比較してなら結構良い値ではないか？
- 数字が具体的に出るところが特徴
学術機関の人らしい発表でした。
システムのところどころで使っている技術は、個人的には非常に興味のある話でした。
ライトニングトーク
Webjigを用いたWebサイト最適化の提案（木浦さん NAIST）
- 趣味で人工衛星の開発をやっている
- ニコニコオーケストラをやっている
- Webサイトを作った人は見た人がどう感じたのか知りたいが、質問しても正直な感想は聞けない → ソフトウェアで解決！
- Webjigの開発
- Webサイトに埋め込まれたJSコードがユーザの行動を分析
- どのように使われたかアニメーションで可視化
- JSで動的に変化するサイトにも対応
- 現在使ってくれる人募集中
縁があってESPerの前に昼食をご一緒しました。
面白そうなソフトなのでshuugi.inとかkouna.ruとかで使ってみたいですね。
固有表現、メタデータ抽出が切り拓くマッシュアップ応用の世界（野村さん メタデータ）
Asiajinでみるエンジニアの海外進出方法（新井さん メロートーン）
- Asiajin ･･･ 日本のIT業界を英語で紹介するブログ
- 日本→海外の流れを作ろう！
- 現状
- RSS購読者1660名
- ライター8名
- TechCrunchライターも所属
- 面白いネタやニュースリリースなどをご送付ください
- 10月14日 アジア発共同ウェブカンファレンスがあるので是非ご参加ください
秋元さんがデブサミ2008で話していた内容と大体いっしょだったと思います。
なにかサービスリリースするときは連絡したいと思いました。
FireMobileSimulatorについて（堀川さん MTI）
- http://d.hatena.ne.jp/thorikawa
- FireMobileSimulator ･･･ 携帯向けサイトテスト用のFirefoxアドオン
- 主な特徴
- 端末のHTTPヘッダを一括で設定可能
- UID・端末製造番号などの送信も可能
- 絵文字
- GPS
- OSSとして公開する予定
- 端末をたくさん持たなくていい → グリーンIT
今月の頭ぐらいにたしかホッテントリに記事が上がっていた記憶があります。
これでMobaSiFの挙動を試してみたいとか思いました。
XUIではじめる携帯コンテンツ制作（大澤さん ネイキッドテクノロジー）
- 携帯コンテンツは見た目がダサいめんどくさい
- モバイルRIAプラットフォーム｢Colors｣ ･･･ 従来の携帯電話で話しえなかったAjaxっぽい携帯コンテンツを
- 利用方法
- XUIライブラリのバインド
- XUI属性の記述
- TwitterクライアントやFlickrクライアントを作成
- 開発に参加してくれる人を募集中。特にiPhone開発やってみたい人
会場でのデモはかなりすごかったです。
どうやって実現しているのかを知りたいと思いました。
RCMSとmixGroup（加藤さん ディバータ）
- RCMS ･･･ Relational Contents Management System
- 関連性を扱えるCMS
- CMSとしてのほとんどの機能を実装済み
- SaaSのみで提供
- 利用サイト合計で1500万PV/月
- CMS：フォルダで管理
- RCMS：メタデータで管理
- 特徴
- データの定義に拡張性を
- 詳細同士の関係をリンクで表現
- メイン情報が大きく一つとサブ情報が周りに少なめに
- 収益モデル
- RCMS本体 湯量版 初期費用4万 月額1万
- RCMSプラットフォーム提供によるライセンスフィー
- カスタマイズモジュールの開発
- デザイン制作費
- mixiのOpenIDを利用したものを作成
- 一晩で作ったことが評価
- 今後はいろいろなAPIに対応する予定
- GoogleAppEngineなどがライバルと思っている
｢海外事業化支援事業｣（米国）報告（神島万喜也さん 情報処理推進機構）
- 未踏でグローバルなビジネス展開を希望する開発者に対し、米国における事業化を支援する事業を実施
- あくまで支援で渡米費用などは参加者の自腹
- 未踏をどうやって英語でどう表現する？ → ネイティブの人に聞いてみた
- そこで
- The MITOH
- The Super Creator
- 海外事業化支援事業
- JETROP_BIC ･･･ 2年間無償でオフィスを借りれるインキュベーション施設
訪問した企業の中には占い感覚で唾液でDNA鑑定して結果を返すベンチャーとかいろいろあって面白そうです。
日本から突然海外に出てもネットワーク形成は確かに難しそうなので、よい試みだと思いました。
全体的な感想
未踏なので話のスタートはソフトウェアなのですが、ビジネスとしてのソフトウェアの話はなかなか聞けないので非常に面白い集まりでした。
懇親会には用事があったので参加できませんでしたが、もっと詳細な話が聞きたいプレゼンが多かったです。
あと、今回聞いてて思ったのは、画像の多いプレゼンは聞くほうはわかりやすいけどメモを取る方は大変だということでしたｗ
Wicketでmeta要素などの値を扱う方法
<meta wicket:id="meta" name="description" />
こういう要素をWicketで扱う場合にはLabelを用いると以下のようになります。
Label meta = new Label("meta"); meta.add(new SimpleAttributeModifier("content", "コンテント内容")); add(meta);
しかしながら、出力されるとき以下のようになってしまいます。
<meta content="コンテント内容" name="description"></meta>
これは(x)html的によろしくないです。
こういう場合はWebComponentクラスを使うのがよいようです。
WebComponent meta = new WebComponent("meta"); meta.add(new SimpleAttributeModifier("content", "コンテント内容")); add(meta);
こうするとvalidなHTMLで表示することが出来ます*1。
<meta content="コンテント内容" name="description"/>
*1:本当は/の前に一つスペースがほしいのですが。
はてなインターンと初めてのPerl
というわけで、現在はてなサマーインターンに参加中です。
インターン期間も半分が過ぎ、いよいよ佳境に入っていくわけでありますが、このエントリで話したいことは、Perlについて。
ご存知のようにはてなではPerlを使ってサービスが実装されていますが、私はこのインターンが決まるまでまったくPerlを触ったことがなく、たまに見かけるPerlのコードを見かけては、$@%など記号が多くてよくわからない言語だと思っていました。一方で、Plaggerなどが代表的なCPANモジュールという他の言語にはない魅力があったので兼ねてから勉強したかった言語でもあります。
んで、インターンが始まってから2週間、毎日というわけではありませんが、Perlに触れてきて、それなりに自分で書きたいものが表現できるようになってきたので、今現在のPerlへの感想について。
前提
私の母国語はJavaで経験は大体3年ぐらい。
作ったものはWeb関連のものが多い。
PHPやPythonやJavascriptも必要に応じて少々。
リャマ本とアルパカ本を読んだ
インターンに参加が決まったのが7月の22日で、そこでPerlの基礎的なことは勉強してくるようにとのことでしたので、このあたりを参考にして、あわててAmazonで本を買いました。
『初めてのPerl』と『続・初めてのPerl』はインターンが始まるまでに読んでおきたかったのですが、ちょうど｢こうなる。｣のリリースと期間が重なっていたので、サービスの不具合修正やアップデートと平行しまい、『初めてのPerl』は読めたのですが、続のほうはリファレンスの話までしか読めませんでした。
個人的に面白かったのは、elsifというつづりについての注釈です。
実際、彼は「別の綴りとしてelseifも使えるようにすべきだ」という提案には、反対しています。「もしeをもう一個持つ綴りを使いたければ、それは簡単なことだよ。ステップ1---自分で言語を作る。ステップ2---それをみんなに使ってもらう。」とLarryは言っています。
http://www.amazon.co.jp/%E7%B6%9A%E3%83%BB%E5%88%9D%E3%82%81%E3%81%A6%E3%81%AEPerl-%E6%94%B9%E8%A8%82%E7%89%88-Randal-L-Schwartz/dp/4873113059
はてなインターンで必要なPerlの知識ですが、他の言語である程度プログラムを書いている人なら、練習問題をやることを含めてこの2冊を読んでいれば、なんとかついていくことができると思います。逆に、他の言語をいくつかやっている人のほうが、カリキュラム的には楽しいかも。
とはいえ、実践的なコードを書かなければコーディングは上達しませんので、この辺りは実際にカリキュラムの中で毎日書くことで現在も勉強させていただいています。
Perlに触れての感想
Perlの変数は大きく分けて3種類で、スカラ・配列・ハッシュで、それぞれ変数名の前に$・@・%を付けます。覚えることが少し多いと感じることもありましたが、順番に書けることが増えていくので、それほど苦痛ではありませんでした。
『初めてのPerl』ではファイル操作についてかなり多く話を割り振っているので、純粋にWebアプリを作りたい人だとこの辺は退屈に思うかもしれません。
ただ、実際にサービスを運営していると定期的に実行するファイルの文字列操作スクリプトが必要になってくることは結構あります。その辺はEclipseを使って書くJavaだとあまりお気軽に書けないところでもあるので、個人的には言語としてファイル操作に特化した記法や性質を持っているところが面白く、また便利に感じられました。
はてな社内ではオブジェクト指向が推奨されているので、Javaで慣れ親しんでいるクラス設計自体はそれほど難しくなかったのですが、実際に開発する際のディレクトリ構成やサブルーチンへのメソッドの渡し方などは慣れるまで結構かかりました。
リファレンスの重要性の把握
リファレンスの使い方がなんとなくわかってきたのは、はてな社内製のMoCoというO/RマッパーやRidgeというWebフレームワークを触り始めて。
サブルーチンに値を渡すときに、他の言語と同じ感覚でやっていてハマることが何度かありました。Perlだと引数は配列として渡されるので、配列やハッシュをうまく渡すにはリファレンスを活用する必要があります。フレームワークのサブルーチンへの値の渡し方を見て、「なるほど、Perlではこういう風にリファレンスを使って渡すのか！」と合点がいきました。
OOでのデリファレンスの仕方に慣れてきたのもこの辺りです。
優れたインターフェース設計を見ることで、Perlっぽいサブルーチンがかけるようになってきました。
Perlの気に入ったところ
ハッシュ周りの処理記法と正規表現が良いです。
RubyなりPythonなりPHPなりを触ったときにも思ったのですが、ハッシュ（連想配列）が手軽に使えるので、引数に使ったりクラスの代わりに使ったりといろいろ汎用性があります。JavaだとHashMapというクラスにしてしまったので、汎用性が上がった分、上記のスクリプト言語のようにお手軽に使うのは難しくなってしまっています。
あとやはり正規表現が強力なところはよいですね。
Perlのイケてないと思ったところ、違和感を覚えたところ
まず気になったのが、use strictやuse warningsやmyについて。これらは必ず書くことが推奨されるので、慣れれば気にならなくなるのですが、デフォルトで有効にしていればよいのに、と知ったときに思いました。この辺は古いバージョンとの互換性を保つためでもあるのだろうし、Perl自体の言語思想も何かあるのでしょうかね。
もう一つは、サブルーチンでの引数の受け取り方。
sub hoge { my($self, @arg) = @_; ...... }
のようにPerlでは書くのですが、最初は使いにくく感じました。慣れてくると柔軟に引数を受け取ることができることもわかってきたので、必ずしもいけてないとはいえないですけどね。
あと、forやifが後置できることや、mapなどの順序のあたり。
# @listの中身をprintする print $_ foreach @list; # シュワルツ変換（比較的重い処理を前処理してからソートを実行する） # 一番下のmapから実行される @sorted = map{$_->[0] } sort{$a->[1] cmp $b->[1]} map{ [ $_, hoge $_ ] } @data;
基本的に上から下へ左から右へという実行順序に慣れていると、少し戸惑います。一行でかけるので書くほうとしては書きやすいし、知っていれば間違うこともないのですが、場所によってはコーディング規約で禁止してるところもありそう。
はてなでPerlを学んだことのメリット
最初の一週間ははてな内でしかPerlerに触れていなかったので、Perlerの人は皆今風な書き方をしているような錯覚をしていたのですが、8月10日に行われたkansai.pmでの「続・脱KENT様方式」*1のプレゼンを聞いてハッとしました。当然のことですが、Perlを書く人にもピンからキリまでいて、一つのplファイルにべた書きでサブルーチンの一つもなくてグローバル変数使いまくりな人もいるわけです。
自分自身も独学でPerlをやっていたとしたら次に読んだのは適当なCGIの本だったかもしれないですし、そこで今風なPerlの書き方が学べたかどうかはあやしいです。
そういった意味で、はてなの中のプログラマの方に指導をしてもらって、実際に模範回答のコードも読む機会が得られるということが、Perlを学習効率の高速化の起爆剤となっているのだと思います。テストについても言及されていて、プログラムを書く上で本質的に重要なところがうまくピックアップされています。
あと、大規模データを扱うプログラムをPerlで書いたりしたのも、Perlでメモリを意識するきっかけになってかなり勉強になりました。Perlだと普通にクラスを使って書くとメモリを食いまくるので、必要なところだけをクラス化して、大量のデータはハッシュや配列などをプリミティブなまま持っておくのがよいようです。
終わりに
現在の環境では後々の運営を考えると、Perlで書いたコードを本番で運用するということはないのですが、今後は最初のプロトタイプを作るうえではPerlで書くのが良いかなと思っています。
Perlで書くことに慣れてきて、言語自体が好きになってきたこともありますが、やはりCPANモジュールの豊富さが一番の要因です。煩わしい部分をライブラリでラッピングして、やりたいことに集中できると生産性も上がりますし、ソースコード自体を参照できるということも大きな利点です。
そういった意味で、次に学ぶことはCPANの有効利用方法ではないかと思っています。
関連エントリ
*1:まだ資料は公開されていないようなので、http://www.azurestone.org/text/contents/#STDA20080810前回のものはhttp://d.hatena.ne.jp/azurestone/20080602/1212343947です。
第一回Wicket勉強会で話してきた
今月の1日に開催された第一回Wicket勉強会で先日リリースした予測コミュニティ｢こうなる。｣話してきました。
Wicket勉強会はid:t_yanoさんが主催で行われたJavaのWebフレームワークの一つであるApache Wicketについての勉強会です。
会場はXarts株式会社さんにお借りしました。面白そうなことをやっている会社だったので、時間があったら社員さんとお話がしてみたかったですけど残念。
｢こうなる。｣ではWicketを使っているので、実際に開発する上で困ったことなどについてを話しました。
以下は発表資料です。
Wicketはこうなる！ 予測コミュニティ「こうなる。」のご紹介
発表で取り上げたWicketのURLの話題については以下で以前記事で書いているので、興味があったら参照してみてください。
- WicketのURLをcoolにする - public static void main
- RestartResponseExceptionでリダイレクトしない件 - public static void main
話してみての感想
こういうパブリックな技術系の勉強会で発表会をしたのは初めてだったので、LTだったのに結構長くなってしまったりと反省することは結構あるのですが、いい経験ができました。
課題としては一回ぐらいは会場を笑わせるということでしたが、うまく出来ていたでしょうか？
話してみて思ったことは、話す側はテンションが話しているうちにテンションが上がってくるので割と楽しく話せるのですが、逆に周りが見えなくなってきて突っ走りすぎてしまいがちになるかな、ということでした。
勉強会経由で｢こうなる。｣に興味を持ってもらった人も何人かいるようでうれしく思っています。
勉強会の発表のメモと感想
WicketとAjax（id:t_yano）
- 例のみんな大好きなサービスを150行で作るぞ
- Wicketはセッションでページの状態を保持する
- 全てメモリ上に持つわけではなく、最新のもの以外はセカンドレベルキャッシュに置かれバージョン管理される
- クラスタリングを行うと、セッションが同期されている間はキャッシュも同期されるが、サーバが落ちてしまうと同期されない→これはWicketの領域の問題ではない
- WicketのコンポーネントとAjax
- 課題
- エレメントの追加が苦手
- DOMのidと相性が悪い
- Wicketのバージョン1.4m3でTwitterもどきを作成
- wicket:removeタグで必要のないHTMLを表示しなくできる → ただのHTMLとしてファイルを見ることができる！
Wicketの説明としては非常にわかりやすかったです。
セカンドレベルキャッシュのあたりの話はほとんど理解していなかったので参考になりました。
会場から、｢Swingの概念を意識して作ってるっぽいけど、EventListenerがないよね｣という質問。内部的にはListenerを持っているらしくて、一部は公開されているらしいのでそれをいじることもできるようです。
Wicket as Meta-Framework（たけうち（chimera）さん）
ComponentResolverを使ったComponentの自動解決方法についての話が非常に面白かったです。
ただWicketの理念的にはどうなのよ？ということで若干宗教論争に。
コード書く量が減ってもそれが見通しが良いプログラムになるとは限らない、という発言が会場からあったのですが、Wicketを書いてるとなるほどなあ、と感じられました。
Wicketは拡張ポイントが多いということがわかったので、Wicketをいろいろいじってみたくなるプレゼンでした。
Wicketによる運用事例（gishiさん）
- 大学の技術部の方の発表
- 大学だと一回作って終わりじゃなくて、仕様変更が多い
- StrutsやJSFをつかって開発していたけど教育コストや変更要求に耐えられなくなった
- 特に大学生が開発に関わっていると結構な周期で人員が入れ替わるので大変
- id:mdgwさんからWicketを教えてもらって使ってみた。
- Wicketを使って幸せになりました
- 教育コストの削減
- 開発期間の削減
- 残業時間が130時間から60時間に！
Wicketを使っていると、リリース後に修正するのが非常に楽なのは感じていて、HTMLファイルやコンポーネント単位での分離が行われているので、ここを変えたらどこに影響がでるのかわからない！という状況がほとんど発生していません。
そろそろ｢こうなる。｣について一言言っておくか。
ちょうど一週間前の23日に、私が開発に参加している予測コミュニティ｢こうなる。｣のリリースを行いました。今日レイアウトを修正したので、是非アクセスしてみてください。
URLはhttp://kouna.ru/とサービス名と一緒なので、覚えやすいのではないかと思います。
｢こうなる。｣を作った理由
もともと、研究室で次期衆議院選挙の予測市場のshuugi.inというサービスを提供していて、そこの経験を生かしてさまざまな事象に対して予測ができるサービスを作りたい、というのが出発点でした。
しかしながら、提供する側としてはもっと多くの人に利用をしてもらいたいのですが、予測市場は仕組みが少し難しいので参加の敷居が少し高くなってしまいがちです。そもそも、予測をするということがユーザにとって楽しいのか、という疑問もありました。
そういった懊悩を払拭してくれたのが、群衆の叡智サミット2008でのパネラーの方々のお話やブログの記事などのやりとりでした。
ユーザ同士の取引の繰り返しというフィードバックによって、みんなが無意識に思っていることが数値化できるのであればとても面白いサービスになるのではないかと現在では思っています。
参加者同士が予測を通じてコミュニケーションを行い、互いに未来のことを考える力を高めあっていけるサービスになっていければ、そして得られた結果が群衆の叡智として多くの人にいい意味で影響を与えていければなあと思います。
｢こうなる。｣の特徴
- 自分の興味のある事象についての予測を立てることができる
- もともと合った株取引に近い仕組みのトレード方式に加えて、競馬のようなベット方式、実験的なシンプル方式を選択可能
- 予測への参加度合いによって増加するKP（こうなるポイント）によって立てられる予測の数が決定される
- Twitterのようなミニブログに似たコメント機能
- コメントに対する｢参考になった｣ボタンでのフィードバック
ユーザのホームページでは、自分の参加している予測でのコメントとウォッチ対象となっているユーザのコメントを参照することができます。
Twitterでいうフォローを｢ウォッチ｣という名前にしたのは、ユーザ同士が｢お前観測範囲狭いな｣という会話ができればというid:youzakaによる発案です。
あと、Twitterでkounatterというユーザを作って情報を発信していますので、お気軽にフォローしてください。
今後の予定
利用方法がわかりにくいとの指摘があるので、その辺りの改善をまずやっていきたいと思っています。
あと、一部の情報はRSSで現在提供しているのですが、どこかの偉い人がPost APIのないサービスはクソだといっていたので、近いうちにAPI提供をしたいと思います。
Wicket勉強会で話すよ！
｢こうなる。｣はJavaで開発されており、プレゼンテーション部分にWicketというフレームワークを利用しています。
今週の金曜の8月1日に開催される第一回Wicket勉強会でサービスの紹介と開発時に気づいたことなどについてLTで話す予定です。参加される予定の方はよろしくお願いします。
勉強会自体は会場の収容人数をオーバーしている状態なので、新しく参加することは出来ないのですが、発表資料のほうは後でアップできればと思っています。
そんなわけで、今後とも｢こうなる。｣をよろしくお願いします。
class属性に値を上書きせずに追加するBehaviorを作った
WicketでHTML要素の属性を変更するには、AttributeModifierかSimpleAttributeModifierを使います。
しかしながら以下のようなHTML要素のクラス属性に関してはそのまま変更しては問題があります。
<p wicket:id="hello" class="body description">ここが変わります。</p>
new Label("hello", "こんにちは").add(new SimpleAttributeModifier("class", "message"));
この場合表示されるHTMLは以下のようになります。
<p class="message">こんにちは</p>
他の属性と違いclass属性の場合、元の値に加えて新しい値を追加したいという場面はかなり多いのではないでしょうか。
Javadocsを見た感じでは、こういう用途に特化したクラスはありませんでした。
【追記】AttributeAppenderというクラスがあるそうで、このクラスを使えば上記の処理が実現できます。
new Label("hello", "こんにちは").add(new AttributeAppender("class", new Model("message"), " "));
SimpleAttributeModifierの場合は以下のようにonComponentTagをオーバーライドしてやることで、値を上書きせずに追加させることが出来ます。
new Label("hello", "こんにちは").add(new SimpleAttributeModifier("class", "message"){ @Override public void onComponentTag(Component component, ComponentTag tag) { tag.put(getAttribute(), tag.getString(getAttribute()) + " " + getValue()); } });
ただ毎回オーバーライドするのも面倒なので、AbstractBehaviorクラスを継承したclass属性の値の追加に特化したクラスを今回は書いてみました。
public class AddClassAttributeModifier extends AbstractBehavior{ private static final long serialVersionUID = 1L; private String value; public AddClassAttributeModifier(String value){ this.value = value; } @Override public void onComponentTag(Component component, ComponentTag tag) { tag.put("class", tag.getString("class") + " " + value); } }
以下のように使うとclass属性に値を追加できます。
new Label("hello", "こんにちは").add(new AddClassAttributeModifier("message"));
この記事を書いていて思ったのですが、style属性とかでも使う気がするので、どの属性を変更するか指定できたほうがいいかもしれません。
RestartResponseExceptionでリダイレクトしない件
Wicketでページを遷移させる方法としてsetResponsePageメソッドがあるのですが、全ての処理が終わった後の遷移先の指定なので、たとえば、ログインしてからアクセスしてほしいページなので処理を中断してログインページに飛ばしたい、という状況のときには少し不便です。
ちなみに、setResponsePageで書くとしたら以下のような感じ。
setResponsePage(LoginPage.class); return;
RestartResponseExceptionで遷移させる
これに対する解決策として、RestartResponseExceptionをthrowする方法があります。
RestartResponseExceptionのコンストラクタで、遷移したい先を指定してやります。
throw new RestartResponseException(LoginPage.class);
RestartResponseExceptionだとリダイレクトされない
で、ここまではいくつかのサイトで解説してあったのですが、RestartResponseExceptionを使ってページを遷移させると、なぜか遷移前のページのURLのままになってしまいます。
挙動としてはフォワードのような動きをしており、どうやればきちんとリダイレクトできるかわからなかったのですが、「http://d.hatena.ne.jp/t_yano/20070626/1182882962」で紹介されているsetRedirect(false)の動作に近いものを感じたので、以下のように書き直したところ、うまくリダイレクトしてくれました。
setRedirect(true); throw new RestartResponseException(LoginPage.class);
どうやらRestartResponseExceptionを利用するとsetRedirect(false)として実行されるようで、以下に書くのと同じ挙動をするようです。
setRedirect(false); setResponsePage(LoginPage.class); return;
setRedirect(false)の応用
RestartResponseException（setRedirect(false)）でPageクラスを指定すると、URLが変化せずフォワードのような動作*1をすることがわかりました。
たとえばログイン前とログイン後で同じURLでも劇的に表示するものが変化するようなページを作りたい時があると思います。
このRestartResponseExceptionを利用すれば、URLを変化させることなくログイン後には別のPageクラスを表示することが可能になります。
というか、もしかしたらこういう使われ方を想定してのものなのかな？
*1:正確にはhttp://d.hatena.ne.jp/t_yano/20070626/1182882962を参照してください
