YAPC::Asia 2014にレポータとして参加してきました
今年も去年に引き続きgihyo.jpのレポータとして参加させていただきました。下記公開されていますので是非ブクマなどしていただけると嬉しいです。
- 前夜祭: http://gihyo.jp/news/report/01/yapcasia2014/0000
- 1日目: http://gihyo.jp/news/report/01/yapcasia2014/0001
- 2日目: http://gihyo.jp/news/report/01/yapcasia2014/0002
レポータについて
レポータ自体は今回で3回目ですが初めて英語セッションも担当できたのは個人的にはチャレンジでした。単に同時通訳++なんですが。。。でもいざやってみるととりあえずスライドだけ写真にとって残しておけばセッション中それほどメモとれなくてもなんとかなるのは発見でした。*1
いつも人手不足で声をかけていただく形で参加させていただいているのですが人気セッションでもプレス席確保してもらえて最前列で聞けるので興味あるかたは来年もあれば是非応募してみてください*2。私もPerlは仕事で使ってはいますが文章を書くということについては素人ですし、今回はプログラミング未経験の方も参加されてPerl入学式をレポートされたりもしているので日本語が読み書きできればだれでもできると思います。
開場について
今年も昨年に引き続き慶應義塾日吉キャンパスでしたが駅近で開場もコンパクトなので移動が楽なのは良かったです。ネットワークも快適でした。同時通訳++。コーヒーも両日頂きましたし、二日目は貸し切りHUB無料ビールもいただけて最高でした。ただ多目的ホールは立ち見が多くて少し気の毒だったかなと。。。
セッションについて
印象にのこったセッション
- 「hrhm.info」 自分も仕事中のメインBGMはDream Theaterな程度にはメタルは好きなので。HM/HRの違い「ボーカルがモテるのがHRでギターがモテるのがHM」の説明が秀逸だった。発表者の方は懇親会にもいらっしゃったようなので最近のオススメとかお尋ねすればよかったけど非コミュ力を全力で発揮してしまい声かけらなかったのが心残り。。。
- 「wri.pe」メモとるためにHerokuで月2万払っているというのは良い意味でcrazyだなぁと。でもアプリ開発以外のところで手こずると萎えるのは確かなのでそれ以外のところをお金で解決してると思えばありなのかも。むしろこれぐらい投資した方が本気になれてよいかもしれない。
- 「Perl meets Real World 〜ハードウェアと恋に落ちるPerlの使い方〜 」 Raspberry PiとArduinoは興味はあったものの違いもよくわからないので試せてなかったのが違いもわかって個人的にはすごくためになりました。とりあえずRaspberry Piクックブック( http://www.oreilly.co.jp/books/9784873116907/ )を買って帰った。
- 「DBIx::Class - what is it and what is it good for?」なつかしい。最近はTeng使っているけどResultSetとかJoinとかたまに欲しくなるし*3自分が使ってた頃*4よりだいぶ進化している印象をうけたので久々につかってみたくなりました。
- 「ウェッブエンジニアのためのローレベルプログラミング」 ハードウェアつながりでこちらも興味深く聞かせていただいた。プレゼン上手い。ローレベルといっても自分はC言語ぐらいでいいやという感じだったけどカジュアルにARMアセンブラから入るのがすごい。それでWEBアプリ作ってみようとは思えないけどRasPi買って必要になったら臆せずアセンブラも試して見たいとは思う。
- 「Dockerで遊んでみよっかー」名前はよく聞くけど全く触ったことはなかったので揮発性のあるコンテナであるという話など基礎がわかってよかった。とりあえずセッション聞きながらvagrantとVirtualBoxまではインストールしたけれど、プロダクション環境でつかうにはまだ課題が多いそうなので個人的にはしばらくは遠目にウォッチという感じかな。
- 「Google BigQuery で DWH 構築 」最近hiveで集計したりしているけど何がつらいってちょっとしたクエリでも数十秒とかかかって、せっかちな自分は待ってる間に他のことしてたら忘れてて戻ったら結果間違っててやりなおしで全然進んでないみたいなのがよくあるので数秒で返ってくるとなる捗りそうだし試してみたい。
- 「Plack for Fun and Profit (But Mostly Profit)」MasonとかClass::DBIとかレガシーなシステムを作りなおすのではなく活かしながら複数のpsgiアプリを組み合わせて再構成した話。つくりなおしたいって思うことは多いけど、既存資産をいかしつつビジネス的に現実的な判断をしていく姿勢は見習わないといけない。
- 「Mobile Application Development for Perl Mongers [ninjinkun x gfx] 」まさに納得しない機能は作りたくないタイプの人間なのでユーザテストに参加するというのは実践したい。あとReactive Programmingも調べてみたい。
- 「キーノート」 受託開発が楽しいという言葉を聞いた時最初「え？」って思ったけど、技術面やビジネス面でもチャレンジングな案件を選べるようになれば楽しそうだということがわかった。ただそうなるには自分に突出した技術と世間で認められるだけの実績がないと難しいだろうからすぐに真似できる話ではない。が目指したい姿ではあるので、目標として意識しつつ日々精進していけたらと思いました。
ng-mtg#4 AngularJS 勉強会
AngularJS 勉強会( http://atnd.org/event/E0021975/0 )に参加してきました。
AngularJS @naoya_ito さん
- jsフレームワーク、最近githubのスター数１位
- MVW (Model View Whatever)
- MVV◯とか議論するのは時間の無駄
- AngularJSそのものを理解するのがいいと思う。
- AngularJSの特徴
- HTMLそのものがテンプレート
- 双方向データバインディング
- HTMLを変えると$scopeの値がかわる
- $scopeのオブジェクトの値を変えるとHTML側の値が変わる
- 典型的な双方向バインディング。{{name}}がng-model="name"の内容を表示。inputをいじるとnameが変わる
<input type="text" ng-model="name"> <p>Hello {{name}}</p>
- ２つの特徴によって・・・
- アプリ側はDOMの構造を知らない
- jQueryやBackbone.jsだとアプリ側がDOM構造を知っている。 $('#button-id button').on('click', function() {});
- HTMLからアプリを掴みにいく
- HTML構造の変更に強い
- HTMLそのものがテンプレート
- アプリ側を知らなくてもDOMの構造を変更できる
- アプリ側から見た目を動的に変えたいときは？
- nShowやngClassを使ってHTML/CSS側で。ロジックでDOMの構築はしない
- ふりかえり Angular JSでの開発の流れ
- AngularJSの「制約」
- HTMLにロジックはかけない
- ロジック側からDOMを操作しにいけない
- コントローラの責務範囲は特定のHTMLブロックに限定
- 双方向バインディングによりコードが少なくなる
- Angular JSの機能(いくつか抜粋)
- リモートのJSONデータもバインド(ngResouce)
- フィルタ(ng-modelでバインとしたモデルで、ng-repeatをフィルタ)
- Form Validation
- Directives ng-bindやng-modelなどを自分で作れる
- 再利用可能なモデルに(services) テスト書きやすくなる。DIによってテストがしやすい
- Angular JS雑感
- Angular JSのDI
- $scope, $route, $resource, ....
- function定義を文字列としてパースしてDIしているので、引数名は注意
- Angular JSのDI
- Angular JS得意・不得意
- 不得意
- グラフィック系
- DOMいじる系
- ゲーム
- Angular JSの印象
- 軽く動かすまでは簡単
- 本格的に使おうとすると学習コストが高い
- GruntとかYeomanなど周辺ツール知識も必要に
- 強い制約と少ないコード量は複数人開発に向いていると思う
- Angular JSもやもや例
- まとめ
- HTML拡張と双方向データバインディング
- HTMLの変更に強よい
- 高いテスタビリティ
OnsenUIについて
- OnsenUIとは
- なぜ作られたか
- モバイルアプリの開発プラットフォームとしてHTMLで簡単にUI作れるようにしたい
- jQuery Mobileのメリットとデメリット
- OnsenUIの特徴
- Directiveで作られた独自タグをHTMLに書くだけ
- ぬるぬる動く(UXを重視)
- CSSを利用したなめらかなアニメーション
- テーマ機能
- Font Awesome(iconライブラリ) http://fontawesome.io をサポート
- OnsenUIのこれから
- UIBuilderの提供
- Webコンポーネントを公開・共有できる仕組み
- AdobeのTopcoatチームと共同で開発
- githubでapacheライセンスで公開 (https://github.com/OnsenUI/OnsenUI)
実戦! AngularJS (@sakatamさん)
- プロジェクトについて
- 開発期間３ヶ月
- ECサイトのリニューアル
- Mobile first
- システム構成＆人員構成
- なんでAngularJS?
- GiltのメインプロダクトはBackbone.jsベース
- Backbone.jsは柔軟性が高い反面、コード品質がばらつく
- モジュールベースの開発を強制
- DI/Module, APIのmock化が可能
- Directiveによる画面の部品化
- コントローラが薄くなる
- 開発フロー
- 1-3week 開発基盤づくり
- 4-5week チーム展開
- 6-12week 実開発
- 基盤づくりに時間をかけた。ファイル構成やビルドプロセスを整備
- DI/モジュールの概念理解
- Directiveをハンズオンで理解
- 開発イテレーション
- 実戦投入Tips
- 階層化されたモデル・データの状態管理
- viewと直結しないモデルの状態をどう管理するか？
- Google Groupsでも議論になっているが明確な答えなし
- モデルを浅くして問題回避
- $routeScope.$broadcast
- 大域ジャンプ
- 便利だけに中毒性ある。DIの意味なくなるので注意
- 仮引数のMinify対応
- リクエスト数の肥大化
- アプリ本体＆ビュー
- httpコストが高いモバイルサイトは注意
- ビルド時にバンドルする。webmakeとか。angular-templateでviewをバンドル
- APIの設計を工夫
- SEO/Crawler対策
- UserAgent判別して、PhantomJSでサーバサイドレンダリング
- 杞憂だったこと
- Two-way Bindingによるレスポンス悪化( 変数のwatchをループで監視しているが大丈夫だった )
- 遅延ロードによるレイアウト崩れも問題なし
- AngularJS本体のサイズ。１回ロードされれば問題なし
- 階層化されたモデル・データの状態管理
- まとめ
- ほどよい制約・モジュール化の強制
- Frontendエンジニアの底上げも
- チーム開発には向いている
目指せ脱初心者！あなたの知りたかったAngularJS ( @agektmr さん )
- 最初は超簡単だけど、いろいろやり始めると難しい
- ユーザの悩み
- ドキュメントが英語
- Angular Wayがあるっぽい
- 日本語の情報が少ない( Angular Ninjaとか出てきたけど )
- 相談相手がいない
- ドキュメントがわかりにくい。リファレンスはそろっているがどっから追えばいいのかわからない
- みんなで相談だ
- angularでDOMを弄りたいときはどうしたらいいの？
- ファイルを扱いたい
- angular.element(this).scope().load(this) ? これはいけてない。
- そこで登場するのがdirectiveだが、ハードル高い
- directive
- linkがあればDOMの操作はできる
- angularJSはjqLiteを内蔵しているので、bindなど簡単な操作はjQueryを使わなくてもいい。
- restrict: 'A'とすると、attribute, 'C'にするとクラス、'E'にするとタグになる
- angularで既存ライブラリとか使うのってあんま向いてないんでしょ？
- controller間で変数をまたぐには
- directiveには親子関係があり、子から親の変数は見れる
- CSS Flexbox Please ! 本家の人が修正してくれたコード ( http://demo.agektmr.com/flexbox/ )
- valueというのを使う。必然性はなさそう。普通の変数で共有してもいいとおもう。
- webコンポーネント
- http://www.polymer-project.org/ web componentsをエミュレートしてくれる
- directiveは将来的にpolymerに置き換わる予定
LT
AngularJS始めました ( @Tkashiro さん )
- ターゲット、始めたばっかの人、始めようと思っている人
- Social Counter
- 勉強方法 - ひたすら模写
- http://egghead.io/
- 有料・無料あわせて70個ぐらいの動画
- todomvc.com
- いろんなフレームワークでTodoアプリ
- angular-ui.github.io
- http://ngmodules.org/
Coffee ScriptとAngularJS ( @ntaoo さん )
- CoffeeScript
- Less typing, Bad readability
- Simple, 安定
- Class based OOP
- Angular with coffee script sample.
- html5mode(true)にすると楽しい
PHPとAngular JS ( @yando さん )
DirecviteにngAnimateをつけよう
- ロード angular.module("mainModule", ["ngAnimate"]);
- ng-repeatなどとあわせてclassで指定
- 自作のDirectiveにもアニメーション設定可能
- $animateで設定
「mixi Engineers' Seminar #2」参加メモ
開発者のためのiPhone⇔Androidアプリ移植のポイント
赤松洋介さま（サイドフィード株式会社）
http://www.slideshare.net/yoski/iphoneandroid-8455306
- TwitCastingやっている
- 会場参加者：iPhone開発者1割、Android開発者3割
- 今日の資料はiPhoneからAndroid開発の流れ
- Androidへの不安
- 画面作成面倒、遅い、端末依存、Java遅い
- 移植の手段
- 結論 コード移植
- 準備
- ActivityとIntentの勉強
- Layout XML ここだけ本読んだ（AndroidアプリUIデザイン＆プログラミング http://www.amazon.co.jp/dp/4822284476/)
- Activity - View Controller
- Activity間の呼び出しは難しいので、iOSでController間の呼び出しをしていると苦労する
- Inteface Builder
- 座標固定に注意
- ソースコード移植
- Objective-C -> Java変換ツール
- 正規表現で作成
- Point
- JavaとObj-Cで共通の物も多い
- NSString => String
- リソース移植
- 変換ツールを作成
- 表示文字列はすべてリソース化。%@ -> %1$s
- 画像など
- ファイル名に-が使えない
- @2xアイコンはdrawable-hdpiに
- 国際化対応はAndroidの方が簡単。フォルダ名を-jaとかするとよい
- ひたすら猿作業で移植
- よかった点
- ソースコードが統一できる
- バグが猛烈に少ない
- ソースコードが統一できる
- 良くない点
- 気づいたこと
- Design
- はまったとこ
- Memory管理
- Out of memory !
- バイナリ周り。unsignedがない。Big Endian
- Memory管理
- 共通コード
- 端末の設計思想
- メニューボタンと戻るボタン
- 反省
- メニューがあるのでツールバー隠す＞たくさんクレーム来た
- ユーザには設計思想を押し付けるな
- テスト環境
- 端末依存
- コードは正しくてもアプリは動かない
- 毎月Android端末買いたしてます
- それでも、ドキュメント豊富。yanzm女神
- 審査
- まとめ
質疑応答
- Q. Objective-CからJavaに移植するときの正規表現って何パターンぐらい作ったのか？
- A. 作ったのは20パターンぐらい。YES/NOをtrue/falseに変換とか、-(void)をvoidにするとか
Windows Phone 7 アプリケーション開発概要
高橋忍さま（日本マイクロソフト株式会社）
- まだ出てないけど・・・
- ユーザのためのスマートフォン
- メトロデザインフレームワーク
- ライブタイル、ハブ
- ライブタイルにプッシュ通知で情報更新できる。現在の気温とか運行情報とか。
- パノラマインタフェース。横長の巻物のような画面
- ハードウェア
- WVGA800x480、4ポイントマルチタッチ、CPU世代、5つのセンサー、500万画素以上の内蔵カメラなど厳しく規定
- これらにより、13端末ほどでているが、ほとんど機種依存は心配しなくて良い
- Windows Phone 7 アプリケーションプラットフォーム
- Silverlight
- XAML/イベント駆動型アプリ
- PCとの共有
- Silverlight4がベース
- xna
- 開発環境
- Visual Studioで。開発環境は全て無料。ダウンロードで提供
- Expression BlendでUIデザイン
- Windows Phone Develper Toolsで全て提供される
- デバイスエミュレータ
- 場合によっては実機より速い
- gpsのテストも出来る（外歩きまわらなくてもいい！）
- Expression Blend
- PhotoshopやIllustratorっぽい
- psdを直接インポート出来る
- Silverlight
- Marketplace
- トライアルができる
- トライアルだったらという判定がAPIでできる
- 24000本(6/29現在)
- APP Hub
- アプリケーション管理
- アプリケーションの申請プロセス
- Appleと同様
- だいたい2,3日で公開される
- 開発者登録は$99/1年
- 品質面のテストもしてくれるので、質のいいテスターを雇ったと思えば安い
- 70%収入シェア
mixi x Androidの深イイ話
藤崎友樹さま （株式会社ミクシィ）
- たんぽぽグループ
- エンジニアの時間をムダにしない。フレームワーク開発など
- 2010年末 Android向けアプリケーション「mixi」の提供を開始
- 開発の経緯
- 連絡先連携のデモが評判に
- 2010年10月
- Androidプロジェクト発足
- 開発環境
- Jenkins(旧Hudson)
- 開発要員
- mixi for Androidの紹介
- ネイテイブアプリ開発に求められること
- スマートフォン向けWeb開発との違い
- フロントエンド＋ブラウザ自体の開発
- ネイティブ機能の開発
- ブラウザ自体自分で作る
- Web上の画像をダウンロードして表示
- 6kバイトの画像を3Gでダウンロードすると1〜6秒からかかる
- スマートフォン向けWeb開発との違い
- Android: 非同期処理は大前提
- メインスレッドを止めない
- 非同期処理を簡単にする道具
- AsyncTask
- IntentService
- キャッシュも欲しい
- 毎回取得は困る
- 自分で作れ！
- java.util.concurrent.Executor !
- 既存ライブラリあった。Droid-Fu: WebImageView
- キャッシュがあふれる。調べると嘘 Expires
- ネイティブ機能の活用
- ネイティブクライアント
- 見せ方を変えるだけではない
- サービスの再考も必要（プッシュ）
- Webの延長とは考えない
- 現状の「スマートフォン開発」
- 書ける
- GUIプログラミング
- イベントドリブンなコード
- マルチスレッド
- GUIプログラミング
- 念頭に置く
- ライフサイクル
- 空間効率
- 時間効率（バッテリー）
- やってみないとわからないことだらけ
- まとめ
- 「スマートフォン」にできること
- 生活をかる
- 概念を変える
質疑応答
Q. プッシュサービスでプロフィール画像が変わった際にキャッシュをクリアするという使い方はありか？
A. 今のところは予定はない。
Q. 端末や、対応するバージョンの方針は？
A. 最初はOSのバージョンだけ。2.2以上で作っていたが、当時まだメインが2.1だったため、2.1もサポート対象とした。対応機種はそれほど意識していない。
Q. テストは何機種ぐらい実施したか？
A. マーケットで使われている機種がわかるので、上位機種をいくつか選んでテストしている
「Titanium Mobileで始めるiPhone / Androidアプリ開発」のメモ
参加したメモです。
- 発表資料 http://public.iwork.com/document/ja/?d=Titanium_Mobile_Workshop_2011_47_02_47_25.key&a=p40748949
- サンプルソース https://github.com/masuidrive/TitaniumSamples
- Titanium Mobileで作られているアプリ
- Titanium Developer
- iPhone環境構築
- Android環境構築
- トラブルシュート
- 同じコードでもiPhoneとAndroidで見た目が違う
- Titanium Mobileではそれぞれのプラットフォームのネイティブの部品が使われる
- KitchenSink
- デモアプリケーション
- Titanium Mobileのアーキテクチャ
- Native OSの上にJavaScriptインタプリタを動かしている。Obj-Cなどにコンパイルしているわけではない
- FAQ
- アプリの作り方
- 1window == 1source
- Window間で独立したContextにより、複数人で同時につくる時に便利
- 共有変数はTi.App以下にぶら下げる
- Window間の共有は苦手
- single context
- AJAXに近い形
- 変数は全体で共有
- 1window == 1source
- Titanium MobileはWEB系の技術者がスムーズに移行出来るように意識して設計されている
- Feedの取り扱い
- 見た目がだいぶ違う
- Pull to refreshでKitchenSinkを検索
- OSはTitanium.Platform.osnameで判定
- ロジックだけ共通化して、iPhone/AndroidそれぞれのUIを作る。
- 各プラットフォーム毎にチューニングが必要だが、いいかえれば各プラットフォームらしいアプリが作れる
- 先にiPhoneでひと通り作って、Android作成時にリファクタリングするのが効率が良い
- 経験的に7〜8割はコードを共通化できる
- デバッグ
- アニメーションテクニック
- 標準のアニメーションを組み合わせて凝ったアニメーションも作れる
- MogSnapの「食べたい」とか
- Modern JavaScrtip
- Titanium MobileではJavaScript1.6をサポート
- CommonJS, JavaScriptのオブジェクト指向, 非同期処理とクロージャ, Deferred
- Ti.IncludeよりCommonJSのrequireの方がオススメ
- この辺のModern JS勉強会もやりたい。[twitter:@masuidrive]などウォッチしてください
- イベント処理
- Deferredいいよ！非同期処理を書くときに階層が深くならない
- 資料
- 公式ドキュメントはまだイマイチ
- titanium-mobile-doc-ja
- [twitter:@appcelerator_ja]
- http://tidocs.com
- KitchenSink https://github.com/appcelerator/
- WebDB + PRESS Vol.61 発売中
- gihyo.jp http://gihyo.jp/dev/serial/01/titanium
- ぐぐる！賞味期限は３，４カ月なので注意。それより古いのはお腹を壊します。
- Stackoverflowなど
質疑応答
- Q. jQueryのUtilityなどを正式に対応する予定は？
- A. eachとかmapとかはJS1.6の機能でできる。HTTPの通信部分をサポートする予定はない。同じような方法で通信できるモジュールがあったと思う
- Q. Androidに実機転送できなくなる
- A. USBを挿し直す。本体を再起動する。build/以下を消してから実行すると結構な確率で入る。あるいはAndroid側のUSBデバッグを一度解除してからつなぐといい。
- Q. JSとネイティブを交互に行き来してもパフォーマンスはでるのか？
- A. 十分でる。実際にコミックビューアの部分では、ビューアの部分はネイティブ実装して、速度のいらない部分はJSでというのがよい
「全文検索エンジンgroongaを囲む夕べ #1」参加メモ
参加メモ:http://atnd.org/events/9234
全文検索エンジンgroongaについて
発表者: (有)未来検索ブラジル 末永 匡 a.k.a. グニャラくん
- 全文検索エンジンSenna
- 2チャンネル検索のために作った
- Sennaの特徴(1)
- groonga *1
- groongaの特徴
- MyISAMに依存しない
- 単体で動作
- 文書情報の保存：カラムごとに保存
- key-valueストアを並列に並べたイメージ
- ベクターカラム(multiValued)
- カラムの値として配列を保存できる
- テーブルカラム
- カラム値として、他のテーブルの行、もしくはその配列を保存できる
- groonga単体で全文検索可能
- プロトコル: HTTP GET, memcachedバイナリ, 独自、MessagePack(未実装)
- クエリ言語
- JavaScriptライクな文法
- 結果はJSON(P)/XML/CSV
- その他の特徴
- ドリルダウン（ファセット）
- ジオサーチ（地理情報検索）
- サジェスト（検索キーワード候補の提案)
- ドリルダウン
- ジオサーチ
- サジェスト
- ユーザの検索クエリログを収集
- 上記ログを収集し、おすすめのクエリを提案する
- 今収集するところは自分で作らないといけない。将来的には自動にできるかも。
- 提案、訂正、補完
- SQL経由で使いたい
- groongaストレージエンジン = MySQL + groonga
- textsearch_groonga = PostgreSQL + groonga
- あとの発表おたのしみに
- 複数プロセスでの利用
- 複数スレッド・プロセスで共有可能。更新時はロックされる
- MySQLで更新、groongaデーモン経由でHTTPで検索
- 分散構成
- 直接のソリューションは現在ない -> アプリケーション側で頑張る
- Spider/VPエンジンなどと組み合わせればできるのではないかと考えている
- 使い方 http://groonga.org/docs/
- 導入事例
- 注意点
- 64bit専用
- ファイルディスクリプタMAXあげる
- カラムごとに１ファイル
- ネットワークサーバも兼用
- 可変長カラムの空間効率には改善の余地がある
- まとめ
- groongaの特徴
- Q&A
- Q.分散構成について。Spiderとの連携はどういう構成になるか？
- A.Spiderの後ろにいるInnoDBをgroongaストレージエンジンに置き換える感じ。
- Q.インデックスの分散はどうするの？
- A.分散はSpiderが担当。groongaは分散されていることを意識しない。Spiderがわけたようにインデックスができあがる
- Q.groonga自体が堅牢でも、ライブラリやOSの問題で異常終了したケースが想定される。その場合、InnoDBのような復旧システムはあるか？
- A.更新中はいつ落ちても壊れるようになっているｗ ロックフリーな更新のために諦めている。元データは別で持っておくのが良いと思う。
- Q.バインディングはどの程度？
- A.作りたいけど手が回ってない。Rubyは結構できがいい。開発者募集中。HTTP経由ならどんな言語からでも簡単に使える
- Q.データのオンラインバックアップは
- A.更新してなければcpという素晴らしいコマンドで！ｗ データのダンプ機能は持っている
- Q.Sennaでファイルサイズが問題になっているがgroongaはどうか？
- A.Sennaに比べて文書情報を保存する分ファイルサイズは大きくなる。転置インデックスのサイズはそれほど変わらない。
Ruby/groonga (rroonga/ActiveGroonga/Racknga) について
発表者: (株)クリアコード 須藤功平 (すとうこうへい)さん
- 趣味：フリーソフトウェア開発
- RSS Parser （Ruby標準添付)
- Rabbit プレゼンソフト http://www.cozmixng.org/~rwiki/?cmd=view;name=Rabbit
- Cutter C言語テストフレームワーク
- milter manager
- ラングバプロジェクト 語感だけで意味はない
- http://groonga.rubyforge.org/
- 使いやすい検索システムを手早く、簡単に
- 全文検索システム
- rroongaの紹介
- groonga APIレイヤー
- Rubyらしさ重視
users.select do |record| record.name =~ "mo" end
-
- クエリ重み付け
record.match(query) do |target| # titleにマッチしたらスコア100, descriptionにマッチしたらスコア10 (target.title * 100) | (target.description * 10 ) | (target.content) end
-
-
- block内は一回だけ評価されるようにしている
- rroongaをインストールするとgroongaも自動で入る
-
- 利用シーン
- 利用例
- るりまサーチ: rroonga + Rack
- http://rurema.clear-code.com/
- ChupaText: 目標
- ChupaRuby
- HTTPインタフェース（予定）。テキスト抽出Webサービス
- gemでインストールできるが、ChupaTextはインストールされない（ChupaTextのインストールは大変）
- ActiveGroonga
- Rails3 用groongaモデル
- 実装はrroonga + ActiveModel
- ActiveGroonga::Base
- rake groonga:*
- マイグレーション、バリデーション、リレーション
- racknga
- いれ場所こまった便利な物をいれている
- Q&A 聴き逃した。。。。
MySQL + groonga (groongaストレージエンジン) について
発表者: 住商情報システム(株) 池田徹郎さん
- groongaストレージエンジンとは
- Tritonnのコンセプト
- MySQLで全文検索を使えるようにする
- MySQLのビルドインは、半角スペースで文章が区切られる言語圏のみ。日本語、中国語などがだめ
- MySQLユーザのためのもの
- 簡単に・シンプルに使えるもの
- 安定して・安心して使えるもの
- Tritonnのアーキテクチャ
- Tritonn patchの規模
- parser /execution layer 19ファイル、899行のパッチ
- myisam storage engine 32ファイル、1306行のパッチ
- MySQLの規模
- 2393ファイル
- 160万行 原稿用紙８万枚相当
- これだけの規模のソースにパッチを当てるのは大変。
- Tritonnの品質向上スキーム
- MyISAM依存による限界
- MySQLで全文検索を使えるようにする
- groongaストレージエンジンのコンセプト
- 公開場所 http://mroonga.github.com/ など
- Tandem構成
- MySQL with groonga storage engineで作ったファイルを、rroongaや、groonga HTTP Serverから読み書きできる
- 仮想カラム
- 従来からのORDER BY LIMIT問題
- 100万件のレコードから先頭の100件だけ取りたい場合
- 検索条件とorder byで指定しているものが複合インデックスでマッチすると非常に早く動くが、そうでない場合遅い
- インデックスでマッチしない場合、ヒットした大量レコードを全部読み込む処理が走る。これが遅い。キャッシュが足りないと他のキャッシュが追い出される
- データを読んだ上でscore値に用いてソート
- Row IDをもとにしたランダムアクセス。場合によってはここがほとんどを占める場合もある。
- ORDER BY LIMITの高速化
- ストレージエンジンからクエリの情報が取れる
- 全文検索＋スコア取得＋ソート＋LIMIT適用
- LIMIT指定件数のみレコードの読み取る。ここが高速化されると大幅に早くなる
- スコアに基づくROWIDソート
- ROWIDしていによるレコード読み取り(LIMIT 100)
- その他実装済の高速化機能
- カラムの刈りこみ
- COUNT高速化
- 大規模分散検索対応
- Spider Storage Engineとの連携で対応を予定している
- Current Development Status
- 2010/11/29 ver0.4 alpha released
- 近々betaになるかも
- 開発者募集
- [twitter:ikdttr]まで
MroongaとSpiderのコンビネーション（予定）
発表者: 斯波健徳さん
- スコアソートでの全文検索
- レンジパーティション条件でのソート
- order by c1なら、c1が小さいパーティションから検索して、結果が指定した件数に揃った段階で返す
- パーティションの分割条件に沿った絞り込み
- ここで質問。これらはまだ実装できていません。どれぐらいできて欲しいですか？
- 会場挙手半数以上。頑張りますｗ
- Q&A
- Q.最初scoreをつくっていなくて、後からつけたい場合は？
- A.現状alter tableをサポートしていないので、create table時に作るしかない。ゆくゆくは対応予定
- Q.他のテーブルとJOINした場合など、取得件数がたりなくなるケースなどは？
- A.まだjoinには対応できていない。エンジン側で高速化ロジックが使えるかどうかを判定して、データが取得できないリスクがある場合は高速化ロジックを使わないなどの対応が考えられる
- Q.複数カラムにまたがる全文インデックスの対応予定は？
- A.groonga自体のマルチカラムインデックス対応が行われていない。groonga本体が対応すればgroongaストレージエンジンも対応する予定。
- Q.NULL値を入れたら0になった
- A.groongaではサポートできていない。設計時にはNULL値いらない方針だった？MySQLから使うにはあったほうがいいので再検討
- Q.groongaストレージエンジンで、ベクターカラムのサポート予定は？
- A.MySQLで持っているデータとのマッピングが難しいので、今のところノーアイデア
- Q.mroongaという名前は使わないの？
- A.時々使っている。別名として使ってください。
PostgreSQL + groonga (textsearch_groonga) について
発表者: フォルシア(株) 板垣貴裕さん
発表者資料：http://www.slideshare.net/ItagakiTakahiro/textsearch-groonga-v01
- textsearch_groonga
- バージョン0.1をリリース
- PostgreSQL 8.3, 8.4, 9.0, 9.1dev
- groongaなるべく新しいもの
- 基本的な検索機能をサポート
- 組み込みのtextsearch
- textsearch_ja -> 組み込み機能 + Mecab
- 追加インデックス・アクセス・メソッド
- textsearch_ja 固有名詞やカタカナ連語の検索漏れが怖い
- SennaとPostgreSQLはもともとは相性がよかった -> PostgreSQL8.3の機能HOT更新と相性が悪いことが判明
- Sennaは文書削除時にももとの文書が必要だったため
- PostgreSQLの拡張インタフェース
- インデックスを拡張可能
- やれることは限定的だが、拡張は容易。必要なのはハンドラ関数１０個程度
- トランザクション管理は本体に任せられる
- 使い方
- インストール
- ソースからビルド。PGの開発用ヘッダ、ライブラリをインストール。makeで自動的にPGXSが使われる
- データベースへの登録が必要 psql -f ...
- インデックス作成
- create index idx on t bl USING groonga (doc)
- 検索
- スコアリング
- 行を識別するシステム列,tableoid, ctidを使って特定の行のスコアを取得
- 行が更新されていると結果が0になることがある
- インストール
- textsearch_senna vs textsearch_groonga
- ToDoと今後
- LIKE演算子のサポート
- textsearch_sennaで意外に人気の機能。LIKE "%foo%"とかでつくってしまった遅いアプリを後から救う
- groongaにも機能はあるみたい？
- UNIGRAM, BIGRAM, TRIGRAMの使い分けは？
- 英数字も文字単位でインデックスするには？
- PostgreSQLとの相性の向上
- 適切なスコアを返すには？
- DROP INDEXでgroongaデータも削除するには？
- PostgreSQLハンドラにamdropを追加する？
- トランザクションログと連携するには？
- クラッシュリカバリは難しいかも
- 標準SQLで仕様化されたストレージ・エンジン
- PostgreSQL9.1に向けて開発中
- groonga DBを、表として参照可能
- 行志向のPG表と、列志向のgroonga表の使い分け
- 標準SQLに含まれているのは参照処理のみ
- この辺ができたらproongaを勝ち取りたい *2
- LIKE演算子のサポート
- まとめ
- Q&A
- Q.groongaのデータモデルとRDBMSのデータモデルはあわないので、フル実装は難しい。groongaを最大限に活かすのか、RDBMSの機能を残すのかどちらの方針か？
- A.Postgresはmulti valueに対応する配列型を持っている。型サポートに関してはPostgresはフルサポート出来る見込み。
- A.groongaストレージエンジンはMySQLから使えるのがうれしい。MySQLで頑張れるところはできるだけ頑張る。MySQLで頑張れ無いところはTandem構成で頑張る。UDF(User-Defined Function)を使いまくる。UDF動作するタイミングがレコード１件毎なので、その範囲ではいろいろ頑張れる
- A.なにしてもいいなら、何でもしますよw 要望があれば頑張ります
- Q.ORDER BY LIMIT, JOINしたときの問題にたいして、groongaからの解決案は？
- A.Sphinx - MySQLのプロトコルを受け取って、自前で全文検索結果をかえすものがある。そういうことをやればいろいろ頑張れるかも。
- A.MySQLの場合はJOINのときは各テーブルに分解されて呼ばれる。ただストレージエンジンではもとのSQLが取れるので、頑張ればできるかもしれない。今後の課題として少しずつ制限を解除していきたい
- A.Postgresの対応は、地理情報検索でN近傍検索ができるようになる見込み。テキスト検索のスコアを、あるスコアからの距離として返すことで、LIMIT処理を一般化できるかも。
- Q.性能限界は？
- A.インデックスもデータ量も、容量が重要。１テーブルに30bitレコードしか保存できない
LT 三日で作るGroonga関数
[twitter:hotpepsi]さん
発表者資料：http://www.slideshare.net/firewood/groonga
- filterで呼べる関数を作る
- しょぼいサーバでスループットを上げたい
- 更新中も処理をとめたくない
- 親子関係を持つテーブルから子のテーブルを探したい
- 具体的には商品(1), 在庫・価格(n)
- SQLの場合、JOINしてDISTINCT ? groongaの場合素直にできない
- 親のIDでドリルダウンすれば２度引きで可能
- 子テーブルで検索する
- 重複するキーをfilterで捨てる
- filterで使える関数を自作する
- 自作の関数
- 引数として親のキーを取る。
- 格納済かどうかを返す
- 雛形
- testになるstrlen.cを参照して書く
- とりあえずproc.cに登録
- 正式なやり方
- configure.ac
- autoreconf
- 大変なので省略
- 手抜き
- Makefile.in
- .SUFFIXESに.ccを追加
- CCLD g++に書き換える
- groonga関数意外と簡単につくれます
第４回Solr勉強会
第２回から３回目の参加。
http://atnd.org/events/9458
1.Lucene Revolution 参加報告
Basis Technology 平賀一昭 (日本支社)さま, 黒坂輝彦(サンフランシスコ支社)さま
- Lucene Revolutionとは
- Lucid Imagination社主催によるLucene/Solrに関するユーザ会議
- Lucid Imagination社
- LuceneとSolrの商用利用促進のために設立
- コミッタが多数参加
- エンジニア向けトレーニング
- BASISさん主催
- Solrアプリケーション開発３日間コース
- 「Solr勉強会で聞いた」で10% Off !
- 本年度中に申し込みで20% Off!
- Lucene & Solr User Conferenceについて
- ハイアットハーバーサイド（ボストン空港のすぐそば）
- ダウンタウンは遠い。カンファレンスに集中しろって？
- 会場の様子
- ４箇所くらいでセッション
- ホールでは朝食、コーヒー、クッキー
- http://www.lucidimagination.com/events/revolution2010
- Lucene/Solrロードマップ
- 各々のコミッタがやりたいことを主張しているだけ？
- Solr Cloud、大規模処理、リアルタイムが大筋の方向性っぽい
- TwitterでのLuceneの活用
- A Billion Queries Per Day１日１０億クエリー
- MySQLからLuceneへ以降
- Luceneの索引周りを改変している模様
- かなりマニアックな内容
- 1000 tps (tweets/sec) => 80M tweets/day
- 12,000 qps => 1G queries/day
- tweetから10秒latency( tweet後検索できるようになるまでの時間)
- tweetから1秒いないにindexing
- 最新のつぶやきを最初に表示したい 索引項目中のdoc listの後ろからスキャン
- 全部検索しないで途中でうちきり
- LUCENE-2329前 postingListはクラスオブジェクトを指していた。オブジェクトの生成が必要で効率が悪い->三つのArrayに分割して効率があがった。Lucene4.0で出てくる？
- docIdとpositionを別々に持っていた。Twitterは文字数が少ないのでpositionは１バイトでよい。docIDを24bit、positionを8bitで表現 > ひとつのintに押しこむ
- Lock-freeアルゴリズム（スレッド間の同期でロックを使わない)
- volatile変数ひとつを使って、スレッド間の同期をとる話
- Java言語規約を深読み。volatile変数の処理順？が決められている
- 実際はJVM内でロックしている気もする
- Solr 3.1とその後
- LuceneとSolrサブプロジェクトの合併
- 次期リリースはSolr 3.1 (Solr 1.5ではなく)
- 現在trunkにあるのは、Solr 4.0になる？
- Solr 3.1新機能
- 拡張DisMaxパーサー。Luceneパーサの構文をサポート。例外をおこらなくするのが目的だった。それを教科。Boostは加算のみだったのが積算で出来るようになる
- 空間・地理検索。緯度経度情報をもとに検索
- 結果のグループ化／フィールドたたみ込み（collapsing)。グーグルの同じサイト内の検索結果をまとめるやつ。任意のフィールドでまとめることができる
- ファセット機能改善。ピボットとして指定されたフィールドによってさらに再分割できる。数値の範囲も指定できる
- Solr Cloud。シェーディングするときにホスト名を羅列しないでよくなる
- 柔軟な索引（？）
- LucidWorks Enterprise
2.SI向けパッケージ製品でのSolr利用と事例紹介
(株)NTTデータ イントラマート 清彰宏さま [twitter:@seikun]さん
- ちょっとだけ会社紹介
- intra-martという開発基盤パッケージ製品を開発
- 以上！
- 謝辞
- 素敵なTシャツとか配れません
- パンフレット用意してません＞社長すいません
- Solrを利用した製品の話( IM-ContentsSearch )
- intra-martの機能
- IM-ContentsSearch
- Solrの利用について
- 専用スキーマを設定
- 事例紹介
- 社内の共有ファイル3TBを社内システム(intra-mart)から全文検索したい
- 頑張って上司を口説いた＞「やりましょう」
- Solrでの開発は楽しかった・・・・が苦しい道のりの始まりだった
- 基本的な設定など
- 形態素解析
- 定期的にipadicのユーザ辞書を更新（品番・品名・特殊な略称などへの対応）
- ActiveDirecotyとの権限情報の連携
- jcifsで接続して権限情報を取得
- intra-martのグループに専用ツリーを作成
- ADの権限をバッチで同期
- 検索クエリに反映される
- 独自でクローラを開発
- 索引化対象の詳細な設定が可能
- クロール時の苦労話
- データセンタに共有ディスクはない＞ファイルは拠点ごとにある
- データセンタの外向き帯域は？？>15Mbps
- 対象ファイルは3TB
- 全部クロールするのに２０日の計算（帯域全部使ったとして）
- 100M以上のファイルは文書数の2%なので対象外(データの40％を削減）
- お客様の現地でのクローリング1.2T/1.8Tできた
- のこり４日でクロールできる。＞初期移行可能に
- これから
- 本番運用開始から５ヶ月経過
- しめ(SIでの)
- Q&A
3.Field Collapsing/Result Groupingについて
(株)シーマーク 大谷純さま
- Field Collapsing / Result Groupingの概要
- SQLでいうdistinctやgroup byのような機能
- SOLR-236としてJIRAに登録
- Solr 1.4.1時点で正式にサポートされていない
- Field Collapsing(SOLR-236)について
- Solr1.4.1にSOLR-236-1_4_1.patchを適用
- QueryComponentの代わりにCollapseComponentを利用
- 動作
- 検索にヒットするドキュメントセットを取得
- 取得したドキュメントセットをcollapse.fieldの値をもとにHashMapを利用してグループ化
- 残念ながらtrunkに採用されず。今後メンテナンスされない可能性大
- Distributed Searchを利用できるのはいいところ。Result Groupingは対応していない
- collapse.fieldにmultiValuedのフィールドは指定できない
- Result Grouping (SOLR-1682 => trunk) について
- trunkのSolrに利用( Solr 4.0 ) Solr 3.1からいける？
- QueryComponentの機能として実装されているため設定不要
- グループ化を行うために２回の検索
- 検索にヒットするドキュメントセットの中のトップグループのドキュメントを取ってくる
- クエリーの結果が同じもの、関数の結果が同じ物など、いろいろグループ化できる
- troup.query=age[20 TO 39]などができる
- Distributed Searchは未対応
- 総グループ数が不明
- multiValuedフィールドでのグループ化は未対応
- SolrJも未対応
- 結論
- Result Groupingの実装を待てる場合は待つ
- 今すぐ使いたければField Collapsingを利用
- 利用しない手を考えるのが現状は妥当かも
4.全文検索エンジンgroongaについて
(有)未来検索ブラジル 末永 匡さま [twitter:@tasukuchan]さん
- プロローグ
- 人に歴史あり -> groongaにも歴史あり
- 全文検索エンジンSenna
- groonga
- 文書の情報も保存。単体で全文検索可能。MySQLにもMyISAMにも頼らない -> 高速な更新を活かせる
- 文書情報の保存：カラムごとに保存 key-valueストアを並列に並べたイメージ
- ベクターカラム(multi valued)
- (例)タグ
- テーブルカラム
- カラム値として、他のテーブルの行、もしくは配列を保存できる。1対Nのデータを扱える
- 単体で全文検索可能
- ネットワークサーバとして起動。HTTP GET, memcached, 独自プロトコル、MessagePackも予定
- HTTP経由では管理ツールが利用出来る（phpMyAdminみたいなもの）
- クエリ言語
- JavaScriptライクな文法（自前パース）
- 結果はJSON(P)/XML/CSV
- コマンドライン
- groongaライブラリ。C言語、Ruby
- その他の特徴
- ドリルダウン(ファセット)
- ジオサーチ(地理情報検索)
- サジェスト(検索キーワード候補)
- ドリルダウン
- ジオサーチ
- サジェスト
- ユーザの検索クエリログを収集。変換途中も含めて全て収集
- 上記ログを解析し、おすすめのクエリを提案
- 提案「全文検索」-> 「grooonga」
- 訂正「gloonga」-> 「groonga」
- 補完「gro」-> 「groonga」
- SQL経由で使いたい
- groongaストレージエンジン。MyISAMそのものを置換
- textsearch_groonga PostgreSQLのインデックス拡張
- 現在開発中
- 複数プロセスでの利用
- 複数スレッド・プロセスで共有可能
- MySQLで更新しつつ、groongaデーモン経由でHTTP検索。参照ロックフリー
- ドキュメント
- 導入事例
- groongaとSolr
- まとめ
- groongaは、Sennaの特徴である「高速な更新」を新に実現するために書かれた全文検索エンジンである
- ためしにつかってみて
- 2010/11/29に勉強会やります。次バージョンリリースします
- http://atnd.org/events/9234
- Q&A
- Q.KVSの場合シーケンシャルな扱いが苦手。range scanなどはうまくいく？
- A.KVSと固定長と可変長のものをわけている。固定長のものはシーケンシャルな扱いはうまくいく。トランザクションをサポートしていないので、range検索しているときに違うものが入ってくることはある。
- Q.大規模なデータに対するものと、拡張性はどうか
- A. 参照が大規模な場合は、MySQLエンジンをちゃんとかけば、MySQLレプリケーションが使える。更新が多い場合はシェーディングが必要。Spiderストレージエンジンなどと組み合わせて高速な更新ができる想定
- Q. Tokenize機能は？
- A. bi-gramとmecabが入っている。bi-gramで1文字検索も高速にできる
LT: Solrの重複uniqueKeyの扱い
ECナビ春山さん
- 単一のshardの場合はないが、複数shardの場合で重複する場合がある
- QueryComponent.javaで処理されている
- uniqueKeyの重複を検出したら、最初に見つかったものが結果に入る。以降は処理しない
- uniqueKeyを重複させたい場合
- 一部の文書だけ頻繁に更新したい
- 最新情報の反映（価格、在庫など)
- 更新は重たい
- 更新用のデータ数の小さいshardをつくる
- shardの名前の大小で優先順位をつける
- timestampNoフィールドで優先順位をつける
- 作ってみた
- https://github.com/haruyama/solr
- 実装はちょー適当
- 一部の文書だけ頻繁に更新したい
YAPC::Asia Tokyo 2010にgihyo.jpさんのレポータとして参加させていただいた
id:hirataraさんのお誘いにより、10/14〜10/16の間YAPC::Asia Tokyo 2010(http://yapcasia.org/2010/)に技術評論社さんの「YAPC::Asia Tokyo 2010スペシャルレポート」(http://gihyo.jp/news/report/01/yapcasia2010)レポータとして参加させていただきました。個人的な感想を書いておこうと思います*1
担当したセッション
以下のレポートを担当させていただきました*2
これらのセッションに関する文責は私にあります。誤植などありましたらコメントなりTwitter( [twitter:@usuihiro] )宛なりでご指摘いただけると助かります。出来る限り早急に修正させていただきます。
10/14 前夜祭
- sugyanさん「Ark」
- tokuhiromさん「Amon」
- スペシャルゲスト対談
10/15 1日目
- Kazutake Hiramatsuさん「Modern Perl Web Development on Amazon EC2」
- Tokuhiro Matsunoさん 「モダンな Perl5 開発環境について - Modern Perl5 Development Environment - 2010年代を生きのびる Perl5 活用術」
- Hiroki DaichiさんInside Mixi - ソーシャルネットワークを支える技術
- Lyo Katoさん「DataPortability and SocialWeb Protocols」
- Jiro Nishiguchiさん「Write Good Parser in Perl」
- Seiji Haradaさん「mixi チェックインの裏側」
- keroyonnさん「非同期タスクの通知処理 with Tatsumaki」
- 吉見 圭司(walf443)さん「Webサービスのページング処理について」
10/16 2日目
- gfxさん「How Xslate Works - The next generation's template engine」
- overlastさん「Perl で自然言語処理」
- cho45さん「映画にでてくるハッカーになりたい」
- kazuhoさん「perl-casual特別企画 Unix Programming with Perl」
- 「perl-casual特別企画 PMグループディスカッション」
- 横山 彰子さん「perl-casual特別企画 Perlをするとこんないいことあったよスペシャル」
- Yusuke Wadaさん「perl-casual特別企画 NoSQLで作るTwitter解析サービス」
- sugyanさん「perl-casual特別企画 とある自社サービスの運用事例」
- Tatsuhiko Miyagawaさん 「Keynote - The Tale of Plack」
下書き
前夜祭は練習も兼ねて大体下書きしましたが、信頼のhirataraブランド*3で全て公開されているので省略します。
1日目以降はセッションがかぶってないので私担当分をさらしておきます。(結構間違ってそうなので消すかも・・・）
http://d.hatena.ne.jp/usuihiro1978/20101015/p1
http://d.hatena.ne.jp/usuihiro1978/20101016/p1
感想
- 誘われたときにIRCにて
hiratara:「感想文がかければいいですよ」
usuihiro:「小学校の宿題の読書感想文とか提出したことありません(ｷﾘｯ」
というやりとりをしたのですが、上記の通り文章く自信がないので結構疲れました。。。
- とはいえ楽しかった。イベントに行っても寝落ちしちゃったりして勿体無いないなぁと思うことがよくあるけど、レポート書かないといけないとなると必死でメモらないといけません。そのために真剣に聞くので結果的に得るものも多くて有意義だったと思う。
- 書く加減で悩んだ。やはりgihyo.jpの名を冠してレポートするわけなので、あまり個人的なことを書き過ぎるのも良くないだろう。草とか使うのもおかしいし言い回しに気を遣う。かといってスライドの丸写しだと発表者のものを参照したほうが正確だし、淡々と書きすぎるのも価値がない気がして結構悩んだ。内容についても細かすぎるのもあれだし、かといってはしょり過ぎるのもよくないし。エッセンスを抜き出して綺麗にまとめるのがいいんだろうけど、それがまた難しい。この辺については書き終わった今もこれでよかったのかはわからない。本当はもっと口頭で話されたこととか、会場の雰囲気とか伝えられるとよかったんだろうけど、スライドのメモで必死であまりそこまで伝えられなかった。今後の課題ですね
- 雰囲気を伝えるのは難しい。cho45さんの発表とか相当おもしろかったけど、字面だと伝わらない。miyagawaさんの発表も相当感動的だったけど、あんなレポートで申し訳ないなぁとか。力量不足を痛感しつつ、精進するしかないですね
- やっぱり次は発表者になりたいと思ったとか思わないとか
- id:hirataraは偉大だった*4
最後に
感想のところでは苦労ばかり書いていますが、本当に参加してよかったと思っていますし感謝しています。最後に貴重な機会をもたらしてくれたid:hirataraさん、perlに関してなんの実績もない私をレポータとして受け入れていただいた技術評論社の高橋さん、このような素晴らしいイベントを提供してくださったYAPC関係者の皆様に感謝いたします。本当に有難うございましたm(_ _)m *5
