study」カテゴリーアーカイブ

帯広のIT勉強会と今後の展望

おがた (@xtetsuji) です。

このブログ記事を書いている2015年6月現在から数ヶ月前のお話になってしまうのですが、2015年初頭に地元にいたときに、いくつかのIT勉強会に参加しました。

勉強会自体は小規模かつ実験的なものだったのですが、軽く感想や展望を書いておこうと思います。

続きを読む

Mishima.pm#1 に参加してきました #mishimapm

おがた (@xtetsuji) です。

タイトルの通りですが、2014年7月12日(土曜日)に静岡県三島市で行われた「Mishima.pm#1」に参加してきました。

他の参加者の方々のブログエントリより:

当日の発表順とスライドへのリンク:

静岡へ遠出、そして久々の新幹線

当日は中野駅から東京駅まで行って新幹線に乗ることにしました。中野駅周辺で朝に用事があったのと、Googleマップにそうサジェストされたから。数年ぶりの新幹線、乗り方すら分からない感じになっています。

モバイルSuicaで中野駅の改札をくぐってしまったので、東京駅で新幹線カウンターにいかないといけないというのも勉強になりました。東海道新幹線も三島駅もJR東日本ではなくJR東海の管轄なのでそういうことなんですね。そんなことも知らなくてアタフタしてしまいました。

新幹線の乗車券

新幹線の行き先表示

三島駅

無事、予定していた時間内に三島駅に到着できました。

静岡の風景に癒やされた

三島駅から会場まで、15分くらい歩くのですが、その間の光景は穏やかで、東京23区内のバタバタした雰囲気から解放された感覚に、心が落ち着くようでした。通勤時間が短いならこういうところに住んだほうが心穏やかになるだろうなぁ。

静岡は結構好きで、学生時代から社会人になってからも何回か来たことがあるのですが、来る食べに発見がありますね。横に長いので各地の特色もある。今回は勉強会メインで観光地巡りとかをする時間はありませんでしたが、また時間を取って来たいなと思わされました。

会場まで歩くので精一杯で、写真は撮っていませんでした。

会場到着から開会

20分ほど前に到着したら、既に @dokechin さんが会場設営をしていました。軽く挨拶。

開会から10分ほど、自己紹介タイムでした。10人。既に顔を知った人が多かったのですが、@dokechin さんに呼ばれて参加した地元の方や、群馬からやってきたという方もいて、参加者の多様性は良い感じでした。

@yusukebe さんのトーク「とある Perl Monger の働き方」

今回、JPA講師派遣制度を利用してやってきたゆーすけべーさん (@yusukebe) こと和田裕介さんが、トップバッターで1時間トークでした。色々なテーマがあがったのですが、@dokechin さんのリクエストがあったようで、ビジネス面にフォーカスした話になりました。ゆったりめで、いつもゆっくり聞けないけど、起業から今に至るまでの話から、そこから得られた考え方などを語られていました。詳細は公開されているスライドを見るとわかるかと思いますが、色々と示唆に富んでいて面白いトークでした。

とあるPerl Mongerの働き方

確かにPerlで働きたいと思っても間口はそれほど広くはない、だけど今もCGIで…なんてところは、表に出てこないだけで大量にあるわけで、そういうところのコンサルタントみたいなところに食い込んだりして自ら仕事を作って、そしてそういう部分をどんどんモダンに改善していくというのも良い活動だよなぁって思わされました。

非同期の話題が多かった今回のトーク

@yusukebe さんのトークのあとは、休憩を挟んで各人のトークとなります。詳細は上記のトーク一覧を参照ください。

特に際立っていたのは、非同期関連のトークが多かったこと。

とはいえ、私もトークする人の一人で、何を話そうかと思っていたのですが、@dokechin さんが自身のブログ等でも非同期関連に興味を持たれていて、今回もその話をするらしいとうことを知って、それにぶつける形でマルチタスクの基礎といった話をしてみました。後でトークを聞いてみたら、どうも先日のPerlBeginnersで私がトークした「そのsleep、ちょっと待った!」が発端だったようで、色々つながっているなぁと思わされました。

私の場合、最近は仕事に忙殺されていて、プライベートであまり新ネタがないというのもあったりしたのと、Perlをあまり知らない人も参加されるらしいということで、forkなどの古典的なマルチタスク処理から解説した基礎的な話を入れてもいいかなと思ったのもありました。@__papix__さんなどの他の人のトーク内容を見ても「これは非同期関連の話を入れてくるなぁ」とは思っていました。期せずして裏テーマが「非同期」になったのは、@dokechinさん的にもよかったんじゃないかなと勝手に思っています。Mojo::IOLoop、以前から存在は知っていましたが、私も今度Mojoliciousでコードを書いた時に使ってみたいと思いました。

私のトークの後がLTタイムだったのですが、全体的に時間が押していたのと、会場が17時までだったこともあって、LTはナシで撤収となりました。自分の発表、ちょうど20分にまとめたんですが、もっと巻けば良かったかもしれません。

懇親会

懇親会は駅近くの「大衆居酒屋 凸凹」というところでした。

大衆居酒屋凸凹

急遽、懇親会の参加人数が増えて、6人席に9人座ることになったのですが、やればなんとかなるもので、それほど窮屈さもなく座ることができました。

まだ空が明るい17時過ぎから乾杯。三島の大衆居酒屋凸凹で乾杯

飲み放題の値段も静岡価格なのか結構安くて、飲んで食べて3000円でした。

プログラムの話やらYAPCの話やら、Perlの話を中心に話が弾んで、とても良い懇親会でした。

途中で、LTができなかった@mackee_wさんと@ytnobodyさんがMacをかかげて居酒屋LT。写真は@mackee_wさんこと、まこぴーさん。

まこぴーさんの居酒屋LT in 三島

氏のトークもAnyEventで、やっぱり非同期キタ!って思いました。以前から様々なプログラム言語を操る若手のホープでしたが、最近はGolangで書いた自作ツールで非同期をPerlから追いだそうという話でした。某人気アプリのクローンの今後にも期待です。

@ytnobodyことあずまさんのトークも、QRコードというガラケー時代を生き抜いた人にとって興味深いコミュニケーションツールをいかに綺麗に生成するかといったトークがとても興味を引いていました。QRコードという題材ひとつでもここまで掘り起こせるのはあずまさんならではといった感じでした。

あいかわらず @__papix__ さんが @yusukebe さんに愛されていて、写真を撮られたり仲睦まじい感じに和みました。@__papix__ 氏、Perl入学式の校長などで活躍中ですが、年長者から愛される力もあって羨ましい限りです。

その後

飲み放題の時間制限や、店が混雑していたことから、20時ごろにお開き。

一部の人達は、途中で温泉に入っていこうと盛り上がっていて実際に向かったようなのですが、私は疲れに疲れてしまっていて、湯あたりとかしそうだなと思ったので、まっすぐ帰ることにしました。駅まで歩いて行くなかで、お祭りの予行演習なのか和楽器を鳴らしている集団をいくつか見かけたり、良い風情に気分が良くなりました。

電車の待ち時間が結構あったので、改札前で @dokechin さん達と立ち話。よい #1 になりましたね、五反田でまた飲みましょうね、三島いいですよね、通勤なければ住みたいですとか、そんな話をしていました。

三島駅、ギリギリJR東海エリアなので、東京へ向かうときはSuicaでくぐっちゃダメなんです。うっかりそれをしそうになって、慌てて窓口でチケットを買いました。

三島→東京山手線内

行きの新幹線とは違い、2時間東海道線に揺られながら、疲れ果てて品川駅までほとんど眠っていました。でも充実した一日だった〜。

まとめ

2013年12月11日のMishima.pm#0には行けませんでしたが(詳細は私のスライドの冒頭を参照してください)、今回は無事行けました。本当、行けてよかったと心から思えました。また数カ月後に行われることを期待して、次回も時間を空けてぜひ行きたいと思いました。今度はもっとゆっくりと旅程を組んで、観光っぽいことも含めて三島を堪能できればいいな。

Yokohama.pm#11 に参加してきました #yokohamapm

おがた (@xtetsuji) です。

2014年5月25日(日曜日)に横浜で行われたPerlの勉強会「Yokohama.pm#11」に参加してきました。

ブログを書くのが6月末と遅くなってしまったのですが、今回のイベントは有意義だたので、多少遅れても記録として書いておきたいなと思った次第です。あとYokohama.pmと自分との振り返りも書いてみたくなったこともあります。

Yokohama.pmについてと、直近のYokohama.pmについて

Yokohama.pmはよくあるPerlの集まりである「地域.pm」の一つなのですが、以前は年一回くらいしか勉強会が開催できていませんでした。直近といえる数年間を列挙すると以下の様な感じ。

  • #7 2011年05月13日
  • #8 2011年11月18日
  • #9 2012年10月19日
  • #10 2014年02月21日
  • #11 2014年05月25日

#10 開催前に、主催側で「年一回も開けていない状況が続いているから、運営体制を変えてやっていこう」というやりとりがあったらしく、@yusukebe さんがリーダー、@mackee_w さんが副リーダーとして、3ヶ月おきくらいに開催していこうという流れになったようです。

私のYokohama.pmとの出会いは #8 を Ustream で観て、こりゃ勉強になると思ったのがきっかけだったようです。

そして実際に #9 に行きました。

#9 について書いた自分のブログ記事は無いようです。

そういえば #9 で、高校時代の後輩である @acidlemon 氏と再会したんでした。あの時は本当に驚きの出会いの場でしたね。向こうはこちらをTwitterでフォローしていて私がここにいるということを知っていたようですが、私のほうは全然知らなかったのでした。

そして #10 はプロントでのビール片手のオシャレ開催。#10 は本当に良い会場で、オシャレカフェが好きな自分にとって、ビールやピザなどの食べ物飲み物も振る舞われるという快適空間でした。感想エントリを書いていたので、そちらをご参照ください。

そして今回の #11。だいたい #10 から #11 は3ヶ月の間隔で、ちょうどよい間隔での開催が軌道に乗り始めた感があります。

2013年11月29日には「Yokohama.pm – 2013年ちょっと早い忘年会」という飲み会が催されたらしいのですが、私は当日は PerlBeginners#11 のほうに行っていたようです。

日曜日の勉強会という形式

今までは平日夜であったり土曜日夜という開催でしたが、今回のYokohama.pm#11はIT系勉強会があまり狙わない日曜日の夜というところを狙ってきました。これも主催者側の意図らしく、「平日夜が良いという人もいれば都合が悪い人もいる。そしてその逆もいる。参加者層を日曜開催ということで変えてみたかった」とのことでした。

今回のYokohama.pm#11のざっくりとしたタイムテーブル

本当にざっくりとしていて

  • 前半は @songumu さんによる1時間のライブコーディング
  • 後半は事前応募なしの会場挙手制のLT

という感じでした。

会場到着から開始まで

私は新江古田駅近く在住なのですが、横浜までは一度練馬駅まで行って、そこから副都心線と東急に乗り入れる電車に乗ると一本なのです。本当に副都心線で楽になりました。昨年のYAPC::Asia Tokyo 2013の会場も日吉駅近くの慶應義塾日吉キャンパスだったので、この電車が非常に便利でした。

練馬駅から横浜駅まで一本練馬駅にて。

18時に開始だと思っていたので急いで行ったものの、18時は開場で、開演は18時30分からなのでした。17時58分くらいに会場のビルに行って、会議室の入口で鍵が開いていないぞとかやっていました。一度一階に降りたら顔なじみの開催者のみなさんがやってきて、あぁそういうことかって思った次第です。

前半のライブコーディング

ライブコーディングというのは、その名の通り生(ライブ)でコーディングをしていくこと。音楽でいうところの即興演奏に近いものがあるでしょうか。普段は出来た完成形を発表しているプログラマですが、作る最中というものはどういうものなのかという興味もあって、時間が割ける場所では時々行われる催しです。今回はつい先日FA宣言をした @songmu さんがライブコーディングを行いました。

最初は「1時間ではCPANモジュールを作って上げるところまでいけない」とのことだったのですが、そこは@songmuさんの力で、Acme::BeerSushiをフルスクラッチから書くところから、CPANへアップするところまで、1時間で乗り切ったのはすごかったです。

今回書いたモジュールはビールと寿司の絵文字2つだけでプログラミングが書けるという、いわゆるBrainfuck系のお遊び言語を作るというものでした。本人曰く「これだけCPANモジュールをアップしていて、まだAcmeモジュールを作っていなかった」とのこと。今回、それが果たされる形になりました。

非実用的なモジュールではありますが、開発の流れ自体はテストからコーディングから公開まで、非常に参考になるものばかりでした。第一線の開発者によるノウハウがライブで映しだされて観られる機会って早々無いので、会場も食い入る様に見ていました。

私も流れるような操作を理解するのに一所懸命であまりメモを取っていません。録画があって後日公開されるらしいので、それに期待しましょう。

後半のその場募集のLT

メモとっていませんでした。

ライブコーディング同様、動画を撮っていたっぽかったので、それを期待しましょう。

懇親会

近所の居酒屋でした。

一部、横浜の家系ラーメンに行ってしまって30分くらい待っても帰ってこなかったので、もうこないのかってなっていました。

テーブルが2つに分かれていて、奥のテーブルで頼んだ注文も全部前のテーブルに吸い取られる事件が発生して、自分を含めて奥のテーブルの人達はお通しと最初の飲み物以外何も来ないという怪奇現象に悩まされました。奥のテーブルで腹減った状態が1時間位続いていて、これなら家系ラーメン食べに行けばよかったと思ったくらい。

ここはエンジニアの面白いところで、タッチパネル式注文機がテーブルを特定しているのかということを解析にかかります。実際のところ「テーブルは区別できる」という結論に至ったわけですが、それでもまだ前のテーブルに注文を無造作に持ってくる店員を大声で読んで「この状況をみて何かおかしいと思わない?」ってつい店員に強い口調で聞いてしまいました。怒ったわけじゃないけど、数年ぶりに店員に苦情言った。空腹は精神の平穏を乱してしまってダメですね。

その後、料理もちゃんと前と奥のテーブルできちんと区別されて配膳されはじめて(やっぱり区別できるじゃん!)ようやく奥のテーブルにも平安が戻ったところで、家系ラーメンに行った人が戻ってきました。どうも相当な時間並んで、さらに相当な時間注文で待たされたらしい。奥のテーブルで起こっていた珍事を知らない人たちが、飲み物を注文し、ようやく到着した食べ物を食べるという平和な光景でした。世界を良くしていくためには誰かが何か行動しないといけないし、後世の人は知らず知らずのうちにその恩恵を受けているという縮図的なものを見た感じでした。

話も弾んで、23時過ぎに店を出て各自帰宅となりました。

まとめ

日曜日の夜開催という点、主催者側の「平日夜や土曜夜という参加者層を変えたい」という狙いは大いに当たったと言えるものでした。

ただ、個人的に日曜日の夜だと月曜日が厳しい…。横浜近郊に住んでいれば良いのですが…。その辺は無理せず、参加できるときに参加するというスタイルがいいかなと思いました。

#8 でUstreamを見て行きたいと思った勉強会。今回も生放送ではないですが録画は後日公開される予定らしいので、行けなかった方はそれを待ちましょう。きっとエキサイティングなトークの数々が見られるはずです。

Hachioji.pm#41 に参加してきました #hachiojipm

おがた (@xtetsuji) です。

2014年6月21日に行われたHachioji.pm#41に参加してきました。

私のATNDのイベント参加ページを見てみると最近はHachioji.pm結構常連なんですが、あまりレポートらしいレポートを書いていなかったので、今回からは短くても書こうと思いました。他の勉強会のブログ記事でもそうなんですが、すぐ書かないともう書かないという法則もあるので、すばやく書く人を見習っていきます。あ、あと、思い出せたら#40以前も振り返りたいと思います。

とりあえず、お約束の居酒屋LTでトークした資料をアップしました。今回のテーマが「セッション」だったので、先日開催したガラケーイベントの余韻が冷めていなかったこともあって、ガラケー時代のセッションの昔話をしてきました。

18時開催なんですが、いつもHachioji.pmが行われる土曜日は慌ただしかったり疲れていたりで、遅刻の常連なんですよね。今回は前日金曜日に朝まで飲んでいたこともあって、起きたら17時で現地到着が20時30分くらいでした。私のために主催の@uzullaさんがLT開始を待っていてくれていたりと、お気遣いさせてしまいました。今度は18時から参加できるようにします。

内容としては、Hachioji.pm自体がゆるい会なので、飲み屋でお酒を飲みながら最近のトレンドを話たりする感じです。今回もそう。Yoというアプリが流行っていたので、なんか参加していない人にHachioji.pm参加者達でよってたかって投稿したりしていました。

私のYoアカウント名はxtetsujiです。でもこのアプリもClick Clickerくらいの鮮度なのかなとか思ったり思わなかったり。こういう流行りものは出てすぐに飛びついて一瞬楽しんだもの勝ちなのかもと最近は思います。

他の方々の参加ブログ記事も参考になります。

GoやDartやGroovyなど、GoogleやAndroid周辺言語が話題でした。Goはとにかく有用性が理解されて次のフェーズに進んでいるし、Android界隈でも開発効率などでGroovyを採用したり、Kotlinと言ってみたり、Google自体もJavaリスク(というかOracleリスク)を避けたいという思いもあるんじゃないかという仮説が立てられたりと盛り上がりました。世間の盛り上がりの割には、Swiftはキーワードとしてチラッと出ただけで特に話題にも上がらなかった感じ。

今回は、@__papix__ 氏が @uzulla さんとGotanda.pmの懇親会の流れからの再度の老害vs若者のプロレスをして(というか巻き込まれて)、無理やり「老害滅ぼしてこ」とか言いながらポーズを取らされたりして撮影会になっていたのがハイライトでした。ちょうど23時近くなって帰ろうとしていたころの出来事。本当に楽しい。

若い人が活躍するこの業界では、mod_rewriteやガラケーの話をしている私も老害なのかもしれませんが、それでも害にならない年長者としてこれからも若い人を支援していきたいですね。なんというか自分が老害になったら、いっそのこと若い人に滅ぼして欲しいくらいです。

若い人といえば、ついにWEB+DB PRESS Vol.81(2014年6月24日発売)で商業誌デビューした@moznion氏も元気そうでなによりでした。今号も面白い連載が目白押しっぽいです。

私のトークの中で「mod_rewriteを使ってディレクトリに見せかけた左側セッションを環境変数に入れる」という古風な手法を紹介したものの、これには決定的にまずい点があったのですが、時間や面倒だったりで省いたので、ここで補足。

環境変数に入れたセッションIDは、環境変数なわけでプロセス単位で保持されるわけです。あの単純なmod_rewriteだけだと、そのままpreforkしたプロセスが次のリクエストを処理した時にURLにセッションがない匿名アクセスだと、環境変数にセットした値が上書きされることもなく消されることもないので、ダメなんですよね。匿名アクセスは無くて全部に対してセッションを配るという実装だったり、もうちょっとmod_rewriteを工夫して左側セッションがない場合に当該環境変数をカラにするという設計であれば大丈夫です。

本来であればリクエスト単位で保持すべきデータはApache noteを使えという話になるのですが、PHP(mod_php)であればapache_note関数で読めるけどPHPならビルトインのセッションを使うよってなるし、CGIであればnoteを読む方法がたぶんないので、結局環境変数に頼る感じだったんですよね、2006年頃のPerl CGI期では(PSGIとPlackは2009年登場です)。自分の場合は、mod_perlで高速化していたPerl CGIのエミュレート環境(Apache1.3だとApache::Registry)だったので、2008年くらいの案件では自分のしていることを理解した上で、$cgi->r->notes->get(‘session’) とかやっていました($cgiはCGIのインスタンス)。

あと、同じApacheでVirtualHostを切るなりして違うサイトとか管理ページでも同じセッションの枠組みを利用している時に色々と混濁してしまう点にも注意しなきゃならなかったりします。一度それで痛い目を見たなと後で思い出しました。2014年にもなってこの仕組みを使う人はあまりいないとは思いますが、この場で補足しておきました。満足。

Hachioji.pmは面白いし気軽だし、@uzullaさんのPHPを始めとした豊富な経験が聞けたりと、非常にお得な「エンジニアのオフ会」なので、中央線沿線に住んでいるエンジニアの人は土曜日暇であればぜひオススメしたいです。次回も予定が空いていれば参加します。

「シニアエンジニアによるガラケー大戦回顧録」というイベントを開催した話 #garake_kaikoroku

10年弱ガラケーでウェブ開発をしていた おがた(@xtetsuji) です。

2014年6月8日に「シニアエンジニアによるガラケー大戦回顧録」というイベントを開催させていただきました。

最初は「3人くらい集まってワイワイとガラケー時代のことを語れればいいな」くらいに考えていたら、2万人くらいフォロワーがいる人にRTされて、その日一日中iPhoneが震えっぱなしでした。意図に反して、人によっては悪ふざけと取られて批判されるかもしれないという内容だったので、自分もその日一日中震えっぱなしでした。

結果的にATNDのページには相当のブクマやLikeがついて、一人反響に驚いていました。

めちゃくちゃバズったガラケー大戦回顧録

ネットの人もジョークがわかってくれる人がほとんどで安心しました。まぁ「近寄ってはダメだ」とか言ってくれる人も良い人です。

「まだ有効なNDA等には注意してくださいね」といったことは周知しつつも、バッドノウハウとか闇とかアレすぎて、文脈すっ飛ばしてブログに書くと色々問題がありそうなネタばかりだったので、以下では詳細までは書いていません。気になる方は実世界で私をつかまえてこっそり聞いてください。問題ない範囲でお話します。

かなり面白い人々が集まった

参加者は、@kaz_hiramatsu さん以外は実際の面識がほとんど・全くない人ばかりでした。

日本のC++の第一人者として有名な江添亮さんが参加することになったとき、多くの人に「江添さん来るけど大丈夫なんですか?」って言われました。ネットでは怖い人だと思われているのかな。本人のブログで信念を持った文章を書いているからなのかもしれません。でも実際に会ってみたら、頭の回転が凄まじく早い、口や手といったI/Oも相当早いけど頭の回転のほうが遥かに早くてすごい、という人でした。ダメなものはダメと断罪する人だったけど、怖い人ではなかったですよ。物凄い人であったことは事実で、また一人そういう人に会うことで自分もしっかりしなきゃと思わされて、とても良い経験でした。

メールで問い合わせを頂いた上で参加くださった方ともお会いして、楽しい話ができました。

当時貴重なガラケー向け情報サイトke-tai.orgを運営していて、今はインフィニットループの代表取締役である@keitaiorgこと松井さんも、札幌から参戦していただきました。Hokkaido.pmですれ違ったことはあったのですが、実際に挨拶をして名刺交換をしたのは今回が初めてでした。

会場に選んだ「レストラン・スカイキャロット」について

三軒茶屋のランドマークタワー「キャロットタワー」の上階にある「レストラン・スカイキャロット」を会場にしました。とても眺めが良かったです。

電話で10名予約をして席が用意されたのですが、電話予約の時から噛み合わないやりとりを何度もしていたら、店を出るときに意外なことを言われて、やっぱりなーとか思いました。私は悪くなかったんですが、私達が結果的に得をしたのか損をしたのか、ちょっと書けない。

なんか枝葉のことまで書けないことだらけの会すぎて困る…。会の実際の内容も含めて、実情を知りたい人は私を捕まえてこっそり聴いてください。大事なことではないのですが、二回言いました。

集合

主催が遅刻するわけにいかないので、とりあえず13時までに会場に向かいます。ちょっとギリギリかなと思っていたのですが、なんとかたどりつけました。

一人、キャロットタワーに興奮します。

会場に到着して予約名を言ったら、既に江添さんがいらっしゃいました。初対面。

続々と人が集まってきます。松井さんは札幌から直行で遅れるとあった通り、しばらくは松井さん以外の9人で食事をしつつ歓談。

私の個人名刺入れがドラクエ2のROMカセットのデザインのやつだったので、最初がドラクエ2の設計に関する話から始まるところ、シニアエンジニアっぽい感じです。

その後、松井さんも合流して10人揃います。揃って食事しつつ歓談。

話題いろいろ

「Tomcatが動かないことが発覚して、急遽シェルスクリプトから標準入力を読んでJavaのコマンドラインに与えるJava CGIを…」といった話がでて、「え?Java CGI?」と会場が驚きに包まれたり…。あんまりガラケー関係ない話ではありますが、ガラケー時代のサーバサイド技術の混沌期を感じさせる話題です。これはツイートしていいって言われたのでツイートしました。誰が言ったかはヒミツ。

終始、江添さんトークがすごかった。ドワンゴの今からC++に関することまで。エンジニアやエンジニア経験のあった人は楽しめただろうけど、それ以外の人を置いてきぼりにしてしまったかなとか、主催者として後で不安になったりしたくらいでした。

その他にも個別に書けない(書く許可を取っていない)話題をいくつもいただけて、主催者として非常に楽しめたイベントでした。

トークと、私が考える過去からの教訓からより良く学ぶ方法

事前トークを募集したのですが誰もいなかったので、結果的に私のトークだけでした。発表したかったけど、雰囲気がわからず準備できなかったという人はいました。発表といっても、特にプロジェクターとかはなく、大きな文字のスライドをノートパソコンに写してかかげて見せる形式。少人数だからできる形式ですね。

これもまた、ちょっと文脈無視では公開できない内容なのですが、せっかくなので一枚見せます。モザイクだらけですけど。

スライドよりクリスタルタワー、モザイク入り

このイベント、「8年前の今日」にガラケー開発で貴重な体験をしたネタを「供養」するために開催したというネタばらしでした。スライドの一部分をファイナルファンタジーIIIのストーリー仕立てにしたら、これもドラクエ2と同様にシニア世代にうけたようで良かったです。

当時は本当に大変だったけど、3年6年と年月が経つにつれ、当時の関係者と当時を振り返って笑えるようになりました。そして8年の時を経た今、同じ失敗を繰り返さないよう、一見ネガティブと思われることもポジティブに変えて、こういうことはどんどん共有したほうがいいんじゃないかなという私からのメッセージでもありました。

話題としての失敗っていうのは、そういう文脈を伝えられなかったり伝えづらい文章の形で公開してしまうと、どうしてもネガティブなものと捉えられられて、本来伝えたい過去からの教訓というものが霞んでしまうんですよね。こういうのをポジティブな文脈に替えて誤解なく伝えられるのは、実際に顔を合わせて話をすることしかないんだよなーとは、よく思うところです。

ネットには成功体験記事は多いけど失敗体験記事が少ないのは、恥を公開したくないといった側面の他に、どうしても読み手にネガティブな印象を与えてしまうからじゃないかと思っています。勉強会や懇親会といった場でなら失敗談であるとか技術の廃れといったことを聞けるのは、このネット時代であってもリアルに出会える場所が重要であることを物語っていると思います。

「ネガティブ良くない、ポジティブに行こう」というのには大賛成なのですが、失敗談から学ぶときに一見ネガティブととられかねない話題は避けては通れないと思っています。ガラケー開発の闇も同様。ガラケー開発の闇ほどではないものの、今もスマートフォンの断片化などが問題になっています。そういうものもポジティブに変えて考えていこう、この会にはそういうテーマも根底に設けたつもりです。

ちなみに昔ほど今の開発現場の闇が深くないと考えられる理由として、ガラケー時代以降の勉強会文化によって横の情報連携が活発になったこと、昔よりもはるかに開発現場のツールチェーンが進化したことなどが挙げられていました。

NDAというものの影響がはるかに大きいガラケー開発の世界

江添さんも直近のブログで指摘してくれていましたが、勉強会文化が普及しなかったり横の情報連携が停滞したりといった要因は、やはり巷でNDAと呼ばれている秘密保持契約によるものが大きいなと感じました。

それは「発売日・正式リリース日までの口外を禁ずる」といったAppleやGoogleがよくやる期間限定タイプの最近よくあるパターンなものではなく、ほぼその技術が存在し続ける限り恒久的に続くNDAを結ばなくてはならないものです。ハードウェア的なものは理解できなくはないとしても、ソフトウェア的なことに関してもことごとくNDAの世界が広がっているのがガラケー開発の世界でした。

絵文字の世界も闇が深いです。ガラケーから外部SMTPサーバへ絵文字入りメールを出すと、いわゆる「ゲタ」(〓)になることは有名な話ですが、特別な申請を経てキャリア側の特別な許可が下りることでこれを回避することができます。そうでなければGmailやYahoo!メールの挙動を説明することはできませんし、3キャリア(WILLCOMやE-MOBILEも入れるともっと?)間での絵文字の相互運用を説明することはできません。

観測事実として、絵文字には各キャリア統一テーブルが存在するのです。とはいえ、実際に絵文字を「統一」したのはUnicodeコンソーシアムに働きかけたGoogleやAppleでした。実際に3キャリアの下で統一された絵文字コードはこのUnicodeではありません。もしそうであれば、ドコモなどを差し置いてGoogleが申請する道理もないですし、GoogleはドコモとのNDA違反をすることになります。すなわち観測事実として、NDAを結んでいない人が知らないテーブルが存在するのです。私は前職でこのテーブルについて偶然知り得てしまったのですが、これは各キャリアとのNDAが今も有効なので当然ながら今回も話すことができませんでした。

日本のガラケーキャリアが閉鎖的な絵文字テーブルを運用している間に、GoogleやAppleは標準化を提案し、美味しいところを持って行って主導権を握るのです。

これは絵文字の例だけではありません。AndroidであったりiPhoneであったりといったスマートフォンのエコシステムと比較したガラケーの世界は、似たり寄ったりの話ばかりです。GoogleやAppleが好きか嫌いか国粋主義者か否かは別として、日本のガラケーキャリアがガラパゴスと揶揄されるゆえんがわかる話ではないでしょうか。

「公式サイト」という言葉も生んだガラケー業界。公式サイトになるためには、それなりの体裁をなした企業が溜池山王(ドコモの本社があるところです)に何度も通わなければならず、一度作った公式サイトの企業間譲渡も制限されるといった不自由さ。そりゃ、どこにも出向かず、お金さえ払えば、たとえ無名の個人だってウェブからアプリをアップロードして全世界展開させてくれるGoogle(Android)やApple(iPhone)に飛びつくに決まっていますよね。公式サイトの課金手数料もNDAだと思うので書けませんが、それよりもはるかに高いと言われる30%というGoogleやAppleに払う手数料も、実際に参勤交代をすることもなく、日本だけでなく世界展開させてくれると思えば安いものです。ガラケー全盛末期の時代はキャリアのトップサイトより影響力を握ったソーシャルゲームプラットフォームに載せるために、キャリアの手数料にソーシャルゲームプラットフォームの手数料も更に上乗せされた額が乗ったわけです。この流れは、公式サイトやソーシャルゲームプラットフォームをすっ飛ばしてGoogle PlayやAppStoreに直接載せるという今の「パズドラモデル」を推進させる流れにもなったように思えます。

今後のガラケー

スマートフォンが使いづらい、スマートフォンの料金体系が高いといったことを嫌う一定層から、今またガラケーが支持を集めています。会の参加者も、私を含めてガラケーとスマートフォンの二台持ちという人も見受けられましたが、そういう人であってもガラケー開発のノウハウは記憶をたぐり寄せるという、いにしえの技術になってしまっています。ke-tai.org の松井さんでさえもです。

しばらくは一部の愛用者からのガラケーの支持も続くとは思いますし、ガラケーが完全になくなることは今後数年は無いとは思いますが、今後はガラケーとスマートフォンの内部的な垣根はどんどんなくなっていって、外側をガラケーに似せた「ガラスマ」が進化し、適切な料金プランとともにガラケー愛好家に浸透していって、根底のガラケー開発の知識はほぼ過ぎ去った知識と言える時代もそう遠い未来ではないのではないかと思えます。

会の終了後

13時から始まったこのイベント、17時に予定通りお開きとなりました。

会計を済ませて、少しみんなで三軒茶屋の名所を散策。

二次会っぽいものに行く人は残り、そうでない人は解散という流れ。5名が帰路につき、5名が残りました。

二次会は居酒屋。とはいえ昼食はしっかり食べているし、アルコールは飲まなかったものの飲み物も結構飲んでいたので、皆さん数杯飲んで満足。

ここでは江添さんのC++話が炸裂しました。

レトロゲームやネトゲの話にもなったのですが、どんなゲームも結局一年くらいで飽きるし、一番のクソゲーであり最もプレイ時間が長い「現実」というゲームに投資しておいたほうが良いと満場一致したのが面白かったです。

21時頃解散。

まとめ

「江添劇場」はすごかったです。C++へ興味湧きます。

二次会にも来てくださった @halmatch さんは、ゲーム業界寄りの話も含めて興味深い話題を色々と提供してくれて、また会って話をしてみたいと思いました。他の勉強会などの集まりとかでつながりが持てると嬉しいです。

予想外に多くの人に注目はされたこのイベント、コメントで「行きたい」という人も多く見受けられ、それに対して江添さんが冗談まじりに「ドワンゴで大規模に勉強会形式でやりますか?」と振られたものの、みんなで「逆に大規模にやったら、発表者出てくるのか…?」といった心配事もあったり、なかなか性質が難しいイベントだなと思った次第です。この規模だからアットホームに各人の真意が正しく伝わって、過去から学んでポジティブに行こうという認識が持てたけど、人が多かったどうなるんだろうとか…。大きな会場が提供されて自分が主催をするとしても、誤解の無い進行は難しいだろうなって感じはします。2012年に一度行われた「失敗カンファレンス」も、今になって概要を見ると、扱いづらい話題を扱った難しいイベントだったんだなと思わされます。

普段はPerlの勉強会ばかりに行くので、そこでは顔見知りの人と話せて楽しいという反面、新しい人との出会いが最近少なかったので、今回のイベントは主催者ながら本当に刺激的でした。

このイベントや続編の開催などに興味のある方、ぜひとも私をリアル世界でつかまえてこっそり聞いてくださるか、Twitterで #garake_kaikoroku ハッシュタグをつけてツイートしてくださると嬉しいです。

これからも様々な経歴を持った方々と様々な場所でお会いして学んでいきたいです。よろしくお願いします。

第6回 Twitter API勉強会に参加してきました #twtr_hack

こんにちは、「情報はなるべくオープンな場所に」をモットーにTwitterを活用している おがた (@xtetsuji) です。

先日、4月24日になりますが、「Twitter API勉強会」に行ってきました。今回からタイトルに回数が入らなくなりましたが、前回が第5回なので、今回は第6回ということになります。毎月月末開催の活発な勉強会の一つです。

私は今回を含めて3回連続の参加。前回は(グダった)トーク(Slideshare)をしましたが、今回は純粋に聴衆側として参加してきました (今回のfoursquareチェックイン)。

前回同様、公式サイトは無いようですが、Zusaarのイベント開催ページや、Togetterのまとめがあります。

今回の会場は、前々回(第4回)に行われた御茶ノ水のデジタルハリウッド東京本校さんでした。

デジタルハリウッド東京本校の中

Twitter API利用規約 5月のAPI改訂

最初のトークは、@yusukeyさんによる2012年5月12日に変更されるとアナウンスがあったAPIのお話。

このトークは多くのTwitterを使ったサービスの開発者に興味深い事柄ですが、幸いなことにSlideshareで公開してくださっています(2012年5月14日のAPI改訂 概要Twitter API利用規約概要)。また@yusukeyさんによるブログ記事「第6回Twitter API勉強会を開催いたしました – ビデオ・スライドまとめ #twtr_hack」にてこのトークを含む当日のビデオがとスライドがまとめて観られます。

大きく分けていくつかのセクションに分けて解説をされていました。

  • Rules of Road
  • I. Twitter Content
  • II. Principles
  • III. Twitter Functionally in your Service
  • IV. Commercial Use
  • V. Other Legal Terms

とりあえず「II. Principles」を読んでおけばOKだそうです。憲法のようなもの。

詳細は、上記リンクからたどってください。以下は自分の手元のメモより。

「I. Twitter Content」のメモ。

  • Twitterの利用規約の上になりたつ。
  • Twitterロゴ使ってよい(というか公式の鳥アイコン”Larry”を使ってほしい)
  • 事前の書面での許可なしにTwitter API自体、またはそこから取得したデータの販売、貸与、サブライセンス、再配布することは不可。
  • アフィリエイトとか有償サービスを作るのはいいけど「APIから取ってきたデータ自体」を販売するのは不可

「II. Principles」のメモ。

「憲法のようなもの。これを読んでおけばひとまずOK」

  • ユーザを驚かせない
  • ユーザが意図しないタイミングでのツイートやフォローなどを行わない
  • スパム行為の禁止
  • ユーザプライバシーの尊重
  • 削除したツイートの保管などはしてはならない
    魚拓のようなサービスはダメ
  • Be a good partner to Twitter
    常識的に考えて

「III. Twitter Functionally in your Service」のメモ。

  • どのアカウントで入ったのか、わかるように

「IV. Commercial Use」のメモ。

  • ユーザの体験を損ねない、サービスはタイムラインの外側に構築する。
  • バナー広告をタイムライン内に配置してはいけない
    バナーはバナーとわかるように
  • タイムライン近くに配置したバナー広告は明確に別れている必要がある。ツイートに見せかけた広告表示は禁止。ちなみに広告とわかるツイートはOK
  • 逆にツイートをさせて広告をさせるというのは規約としてはアリ。フォロワーの多い人に商品宣伝をしてもらったりはアリ。ツイートに見せかけた広告はダメということ。

「V. Other Legal Terms」のメモ。

  • TwitterはいつでもTwitter APIやTwitterコンテントへのアクセスを遮断する権利を持つ
  • Twitterは将来Twitter APIや規約、ディスプレイガイドラインを変更する権利を持つ

これはよくある免責事項のようなものですね。いちおうポリシーとしては1ヶ月前までには変更はアナウンスされるとのことです。

「アプリ/サービスローンチチェックリスト」のメモ

  • 自動化されたツイートがいつ行われるのかユーザが明確になっている
  • フォローは自動化されていない (商品名をさけんだ人を自動フォローとかはダメよ)
  • 急激なフォローは行わない
  • アンフォローは自動化されていない
  • ツイート/DMの自動化寄稿にはリミッターがある(1日1000ツイート、250DM、特に@ツイート、URL入りツイートに注意)
  • ディスプレイ、商標ガイドラインを守っている
  • 広告はタイムラインとは明確に区別できるようになっている
  • むやみにツイートを永続化していない
    ユーザがツイートの削除をできるように、またはsite streamで削除ツイートは消えるように
  • 固定アカウントから@ツイートをする場合は利用者に事前フォローをさせている (http://cp.redbull.jp/tweet の例)
  • 恐れずローンチしてください
  • 万が一アプリ/アカウント凍結されたらお問い合わせ https://support.twitter.com/forms
  • 組織的にチェックしたいデベロッパ向け情報
    dev.twitter.com – Twitter API利用規約
    support.twitter.com – レートリミット
  • …;などなど

「5月のAPI改訂」の概要メモ。

  • Twitter APIは2006年から互換性を保ってきた
  • 一部はTwitterのスケーラビリティに支障
  • 新旧APIで新しいAPIデベロッパーが混乱
  • いったん一区切りしましょう。

具体的なAPI改訂については、一覧 https://dev.twitter.com/docs/deprecations/spring-2012 を参照するか、上記スライドorビデオを参照いただけると分かると思います。メモの転記に疲れた?いや、ここは開発に関わる部分なので公式に近い情報を当たって欲しいという理由です(言い訳?)。

当然の流れかと思いますが、今後のTwitter APIはJSON中心になっていき、今回でAtom形式のエンドポイントが無くなります。今後、XML形式も無くなるかもしれない、とのお話もありました。

Twitter  Internationalization

@kn さんによるTwitterの国際化のお話。

現在のTwitterは28ヶ国語。50万人のボランティアが翻訳をしているそうです。その翻訳の受理の流れなどを解説してくださいました。

twiccaについて

twiccaの作者 @R246 (アオヤマテツヤ)さんによる、AndroidのTwitterクライアント「twicca(ついっか)」の話。

もともとはPHPやJavaScriptやももクロ(?)等のサーバサイドエンジニアだったそうですが、Android初期のTwitterクライアントのあまりの出来の悪さに「つい、カッ」となってつくったのが「twicca」だそうです。「当時はJavaとか知らなかった」という発言もありましたが、「つい、カッ」となった勢いはすごいなと思いました。

ネタが無いので、Twitterで「twiccaについて聞きたいこと」というツイートを流してみたとのこと。

twiccaを開発しようと思ったのは2009年7月当時、満足いくTwitterクライアントがなかったから。前段のお話です。

twiccaではユーザに「色」を割り当てることができるのが特長。クラスタごとに色分けをしたりすることで、タイムライン上の視認性をあげることができる。これは大事なツイートを見逃さないためのツイートなので「カラーラベルのご利用は計画的に」とのこと。

バックアップ/同期を実装しない理由→クラウド同期がかっこいい→クラウド同期ができない理由→サーバ料金を賄えない。

「twiccaサポーターズ」というのがあるそうで、twiccaの開発支援プログラムのようです。シェアウェアではないけど、twiccaを金銭面で応援したい人のための制度。目立つ告知はしていないそう。これに参加するとアプリ内の「twiccaについて」に名前が掲載されるらしい。「twiccaは儂が育てた」と言ってよいそうです。

「例の脆弱性」JVN#31860555 についてもお話がなされました。

「お金を積まれたら売る?」という質問には「売りません」とハッキリ発言。「サポーターズが居る限り」。カッコイイ。

最後にtwiccaアイコンの変遷を解説されて終わりました。

私も寝かせているAndroid端末があるので、ぜひそれでtwiccaを使ってみたいと思いました。

LT: 女子中高生とTwitter4J

@i2key さん。リクルート(MTL?)の中の人。

「 マイクロコンテンツ化」という仮説を打ち立てて「3文字の絵文字」で情報を伝達できないか、というサービス「さんもじ絵文字できもち伝わる!Happy Balloon」の紹介をされました。

これはタイトルからも分かるようにネタLTの傾向もあって、動画のほうが場の面白さの雰囲気があるので、時間に余裕のある方は動画のほうをご覧いただくと良いと思います

返信と@ツイートの仕様変更と提案

@tkawa (川村徹) さんによる、返信と@ツイートのTwitter仕様に対する提案のお話。

真面目なお話でしたが、個人的にこれはかなり有意義なトークでした。返信というメタデータと、返信と扱われるか扱われないか現状曖昧な「@ツイート」の仕様について、もっと明確に良い方向になっていって欲しいと思わされました。

詳しくは当該スライドをご覧いただくといいかと思います。

dotcloudによるすぐ始めるtwitter webアプリ開発

@yut148 さんによるdotCloudを使ったウェブアプリ開発のお話。クラウドを大量に使っているゲーム会社 or エンタテインメント会社に所属して、普段はPHPやPythonを使う方らしいです。

dotCloudを使えばとりあえずドメイン名は振られるので、Twitterのアプリ開発に必要なドメイン名を確保することができるとのこと。それに最初はFree!

Freeアカウントの制限は「登録できるアプリは2つまで」「ディスク容量」とのこと。

dotCloudはPHPやPythonだけでなく、様々な言語の様々な環境が選べるので、今後PaaSの環境として要注目かもしれません。2サービスまでなら無料で作れますし、より複数のサービスを作るのであればディレクトリ構成を工夫したりすることでやりくりできるらしいです。

@yut148 さんは本当にdotCloudが好きな方なようで、dotcloudユーザ会(仮称)を作って活動をしはじめているとのことです。

「困ったら@yut148 に質問送っていただければベストエフォートで答えるよ。」という心強いお言葉も。

私も以前、無料だったのでdotCloudにアカウントを登録したっきり使っていなかったので、これを機会に今度時間を作っていじってみたいと思いました。

最後に

情報源

今まで一通りAPIやったので、次回は「Twitter API勉強会」から違う名前に衣替えをする予定だそうです。名前募集中。

  • 名称変更「Twitter API勉強会」→「Twitter Hack(仮)」
  • 次回開催:5月末、6月末、7月末

スピーカー常に募集中!

懇親会

今回は貸し会議室での「立食パーティ」形式ではなく、会場すぐ近くの居酒屋での開催となりました。

当初自分が懇親会に申し込んだ時には定員割れになって開催されないのではないかと危惧していましたが、駆け込みで多くの方が参加されて、居酒屋の予約席は満席状態になりました。

第6回Twitter API勉強会の懇親会「ももや」

 

「ももや」店内の料理の風景

 

Twitter API勉強会といいつつ、私の席ではTwitterの話よりもコンピュータ昔話に花が咲いていた気もしますが、それもまた一興でしょう。

定期的にTwitter開発の旬な話が聞けたり、著名なTwitterクライアントの作者の方のお話が聴ける、この勉強会。非常に有意義でして、私もかれこれ3回の参加をしていますが、今後も予定と体調が許す限り、参加して勉強させていただきたいと思いました。

Hachioji.pm#15 に参加してきました #hachiojipm

こんにちは、最近は積極的に勉強会の類に参加してみようとしている おがた (@xtetsuji)です。

いつもブログが遅筆ですみません。記事を書いている段階では一週間前の2012年3月24日に行われた「Hachioji.pm#15」に参加させていただきました。私は中野区在住で八王子駅まで片道1時間弱。移動の負担は首都圏的感覚だとそれほどでもなかったです。

東京在住なのに、地元が北海道という縁でHokkaido.pmには2回参加+トーク発表をしたものの、今回初めて関東圏の地方.pmに参加させていただきました。まぁ、YAPC::Asia Tokyoは2007年から行っていますが、地方.pmのような大規模でないイベントのほうが各人の交流がしやすくていいなとは、Hokkaido.pmの参加のときから思っていました。その思いを膨らませて、今回Hachioji.pmに思い切って初参加した次第です。

このイベントの前の朝から夕方までに行われていた「Like a ハッカソン」は参加してみたかったものの、あまり体調が良くなくて長く作業すると疲れが出て後日に響いてしまうコンディションだったため、興味はあったのですが今回の参加は遠慮させていただきました。

参加前に参加要件を見ていたのですが、「一枚LT」とか聞いたこともないものが要件にあったりして、検索してみたら「模造紙でプレゼン」とか出てきたりして、文房具店に行く時間も無いし一枚に自己紹介と課題である「スマートフォン」の話をどう書けばいいんだろうとか、いろいろ考えてしまって結局準備をせずに向かったのですが、模造紙云々はどなたかのネタらしく、みなさん普通にプレゼンテーションアプリケーションを使った数枚のスライドのプレゼンテーションをされていました。

「Like a ハッカソン」とは違い、本イベントである「Hachioji.pm#15」自体は、どちらかというと飲食店に集まって飲み食いしながら技術のお話をするというのがメインのようで、お酒が入った状態でざっくばらんに最近の技術動向について情報交換ができる、気軽な場所でした。

「Like a ハッカソン」を含めた「Hachioji.pm#15」の詳細は、Hachioji.pmのブログ記事やそこからリンクされたページを参照していただけると、私の記事より良いものがあります。

個人的にざっくばらんな会話で感じたのは、一人でネット上の情報を見ていても「流行り」はたくさん流れてくるけど、「廃り」といったことは実際に対面でお話をして動向のお話をしないと見えてこないということでした。確かにネットで「廃り」を宣言したりすると、その作者やそれの愛用者の目にとまったときにdisられたとか反感を買うので書きづらい部分はあるんだと思います。今回も「jQuery UIはダメだね」とか、それぞれの方々の思う「廃り」の印象のお話が聞けて面白かったです。

初参加で一人八王子までやってきて、会場のペルー料理店MISKYに「こんばんは〜」と入ってきたのですが、ネット上で存じていた方や、YAPC::Asia Tokyoでお会いした方(@ytnobodyさんとか)もいらっしゃって、向こうはこちらの顔なんて覚えていないだろうなと思いつつも、空気を読まず「いやー、お久しぶりです」とか言って場に馴染もうとしてみました。

初参加なのに30分くらい遅刻をしでかした私でしたが、その後に遅れて@maka2_donzoko さんがやってきて、課題の「スマートフォン」に引っ掛けて「すあま」と「本」を持ってきました (参考: ご自身によるブログ記事)。すあま、あまり馴染みのないお菓子でしたが、かなり美味しかったです。自分好み。

すあま

いただいた すあま の写真。美味。

「まかまかさん」こと@maka2_donzoko さんは、PerlのAcmeモジュール同人誌「Acme大全」やPerlモジュールを題材にしたカードゲーム「Parumon」の作者でもあります。YAPC::Asia Tokyo 2011で「Acme大全」は購入できたのですが、売り切れで入手できなかった「Parumon」を、なんとこの場で売ってくださいました!ありがとうございます、まかまかさん!

Parumon

「Parumon」は、Hokkaido.pmの何名かが購入をして、プレイ風景をリアルやネットで見たりしていたのを指をくわえて羨ましがっていた状態だったので、非常に嬉しかったです。会社でもちょうど3月に開発者が一名入社してPerlの勉強をしてもらっているところなので、教材としても使っていきたいです。

飲み食いが一段落したところで、皆さんの「1枚LT」が開始されることになりました。詳しくは上述のリンクに譲りますが、みなさんタイトルの「1枚」とかお題の「スマートフォン」に縛られないLTを繰り広げられて、これでいいんだって感じました。皆さんのお話はどれも興味深いものばかりでした。

Hachioji.pm#15の開催者である@uzullaさんがとても精力的な方で、そこから繰り広げられる話の数々を拾うだけで、とても有意義でした。PHPerを何度も自称しながら、それなのにPerlイベントを主催しているとか、ジョークも数々。楽しかったです。

本当にいろいろな話題が出て、すべてを拾いきるのも、ここで思い出して書くのもなかなか大変なのですが、スマートフォン向けのjQuery互換軽量JavaScriptモジュールzepto.jsは本当に名前も知らなかったので、jQueryで作ったスマートフォン向けサイトをzepto.jsで置き換えできないか、考えてはじめています。また、スマートフォン開発に詳しい方が数名いて、Androidアプリ内課金の大変さを説いていたのも印象的でした。私も最近Android アプリ内課金案件を抱えていたので、もっと詳細を聞いておけばよかった、とも後で思ったのでした。

その他は、上述のHachioji.pm自身による記事からたどっていただけると、興味深い話題が多かったことがわかると思います。

「Like a ハッカソン」もそうですが、予定や体調が許す範囲で、次回以降の「Hachioji.pm」にもぜひ参加してみたいと考えています。まだまだ新参者感が抜けない私ですが、Hachioji.pmの皆さん、今後ともよろしくお願いします。

第5回 Twitter API勉強会に参加+発表してきました #twtr_hack

こんにちは、「最近の主戦場はどこ?」と聞かれたら「Twitter」と答えるでしょう、 おがた (@xtetsuji) です。

先日、3月21日になりますが、「第5回 Twitter API勉強会」に行ってきました。前回「第4回」から二度目の参加になります。

公式サイトは無いようですが、情報をTogetterにまとめてくださった方がいらっしゃいましたので、タイムテーブルやスライド資料などはコチラからご参照ください。

前回の私の感想ブログの締めくくりで「機会があればPerlのTwitterライブラリについて発表してみようかなと思いました。」と書いたのですが、今回のタイムテーブルの10分LTに自分のアカウント名が登録されているではありませんか。「いつか発表したい」→「次回発表する」の流れにちょっとビックリ。

[tweet https://twitter.com/xtetsuji/statuses/172637481408282625]

そういえば前回「第4回」で、こんなやり取りがあったのでした。まさか本当に「第5回」で発表になるとは…。

「Twitter API勉強会」は月1回の活発な勉強会で、準備期間は1ヶ月もありません。まぁ、結局スライドは前日の深夜に徹夜気味に作ったのですが…。当日いらっしゃった方々、内容もさることながら、発表がグダってしまって本当に申し訳ありません。練習不足でした。スライドの内容の補足等については後述します。

前回の会場は御茶ノ水のデジタルハリウッドさんでしたが、今回は渋谷の「ハロー会議室」というところでした。

ハロー会議室

広々とした会議室でしたが、私はちょっと遅刻してしまったので、最初は後ろのほうに座って聴講していました。その後、トークの隙を狙って前の方に進出していきましたが…。

Twitterの日本語検索、ハッシュタグについて

最初のトークは、急遽タイムテーブルが変更になって、Twitterの国際化等に携わっている@keita_fさんによる「Twitterの日本語検索、ハッシュタグについて」。

資料も公開されていない半分オフレコっぽいトークだったので、どこまで感想を述べていいかちょっと分からないのですが、浅い範囲で手元のメモに書かれている興味深かった項目としては

  • Lucenceを使っている
  • Twitterは50もの言語をサポート
  • ツイートの言語判定はJavaで実装。UTF-8文字列を各種ローカル文字コードにエンコードしてみて失敗するかどうかでチェック(結構コストがかかりそうなトライアンドエラーで検出するとは意外でした)。西欧の文字列はn-gramでチェック。
  • 2つ以上の言語が混じっている場合の苦労
  • 絵文字(emoticon)の取り扱い
  • Unicode Alphabetの取り扱い
  • 形態素解析にはGomoku、西欧の文字列は独自実装。
  • テキスト処理のオープンソース化を https://github.com/twitter/commons/ 以下にしていっている

といったところでした。

@keita_fさんは、あのティコリンク(t.co短縮URL)の実装にも関わっている人らしく、どちらかというとそちらの方で色々と質問したかったのですが、時間が無かったのと懇親会にいらっしゃらなかったので、そちらについてはほとんど話を聞けませんでした。

声をかけて一つお話をしたのは「ティコリンクの識別子(スラッシュの後の文字数)は8文字ですが、Twitterには日々膨大なURLが投稿されているので、あれが9文字になる日は来るんですか?」というつまらない(?)質問をしてしまった(とっさに思いついたのがそれだった)のですが「じきにそうなる日も来るでしょう」という回答でした。実際、Twitter APIからはティコリンクを展開したURLの情報も乗ってくるので、そちらを見れば各種実装が8文字を想定する必要すらないので、他愛も無い質問だったなぁと思います。

交流タイム

最初のトークが終わった後は、恒例の交流タイム。今回は学生さんの参加が少なかったようですが、周囲の社会人の方とどんなお仕事をされているのかとか、どういった興味でここに来たのかといった話で盛り上がりました。ここで後ろの席から前の席へ移動。

ランチタイム共有サービス「昼会」のご紹介

次のトークは@setomitsさんによる「昼会」のご紹介。デジタルガレージの中の方です。

なぜTwitterかという話から。最初は(デジタルガレージが業務提携を結んでいた)LinkedInのOAuthを使ったログインを検討していたらしいです。ビジネスランチ的な何か?そこは普及度を考えてTwitter OAuthに変更したとのこと。

開発は、Google App Engine(GAE)上でTweepyというAPIを使って開発しているとのこと。Pythonですね。

ユーザへの通知に自分へのDMを使用しているとのことですが、ユーザから「自分から自分にDMが来るのは気持ち悪い」「スパムかと思った」「アカウントを乗っ取られたかと思った」といった意見があったとのこと。でも開発者に話をすれば実装上「まぁこうするだろうね」といった感じで折り合いが着いた(?)ような感じです。Zusaarでも登録ユーザへの連絡はユーザ自身へのDM(ひとりごとみたいな感じ)で実現していますし、同種の考えのサービスは多いようです。

既存のサイトのOAuthの利用について、いちいち新しくユーザー登録をしなくて良いのは良いとのこと。

トラブルもあって、ログイン出来ないということはサービス開始前やサービス開始直後に頻発していた模様。原因追及できず、一切のAPIコールができない状態が続いたようです。

昼会の開発から8ヶ月、色々な発見があったようです。昼会というサービス自体で新しい出会いがあったこともあるようですが、昼会の敷居が意外に高いこともあったとか。確かにサイトを見ても中々昼会の予定が入っていない。質疑応答で「夜会もやったほうが…」というジョーク質問がありましたが「ドメインhirukai.jp取ってしまいましたし…」とのことでした。

昼会の開発体制は最初3人。開発1人、デザイナ1人、企画交渉1人。最小編成ですね。

質問はGAEコストにも波及して、改定前は数千円/月だったのが改定後に数万円/月になってヤバいと思い、APIのコール周り等のコストを見なおして、改定前くらいの価格まで押さえ込めたとのこと。GAEのコスト改定はニュースにもなっていましたが、桁が違ってくるほどの値上げだったんだなと思いました。

この後はLT。

Twitter 4 contact

@inda_re さんの「Twitter 4 contact」。問い合わせフォームをTwitterで作ってしまおうという発想は面白かったです。資料もPHPで作られたプログラムも公開されているので、導入しようと思えばすぐにでも導入できそうです。発想の面白さと、LTならではのウケ狙いの上手さに感服です。

PerlのTwitterモジュールについて

これは@xtetsuji によるトーク。5分や20分の経験はあったのですが、10分LTというのは初めてで、どれくらいの分量でトークしていいか分からないまま、練習不足というかほとんど練習をせずにのぞんでしまったために、非常にグダってしまい申し訳ありませんでした。

前回、学生さんが多かった事を念頭に置いて「半分くらいはPerl自体の環境導入をやったほうがいいのでは」と思って資料を作ったのですが、今回はほとんど学生さんがいない(居たとしても既にスキルある方ばかりな)状況だったので、ちょっと構成に失敗したかなぁ、といったところです。

結局のところ、PerlにもStreaming APIをいじれるAnyEvent::Twitter::Streamというモジュールがあって、手軽にプログラムが書けるんだよといったところが伝わればよかったかなと思います。

以下、資料です。

デモプログラムで登場した twitter-stream-search.pl は、自分自身がテレビ番組(アニメとか)の実況をコンソールで tail -f のように流し見しつつ、あとで録画したものを観るときにそのストリームの詳細がログの様になっていて欲しい、と思い立って30分くらいで書いたプログラムです。今も便利に普段使いしています。仕事のプログラムは書くのに何時間も掛かるのに、人は私利私欲があればものすごい速度でプログラムが書けるんだと思った瞬間でした。AnyEvent::Twitter::Streamの導入さえ成功してしまえば、後は比較的簡単に使い始められるのも特長としています。

ここからは発表から蛇足になりますが、AnyEvent::Twitter::Streamも万能ではないようで、まだできないこともあります。最近Streaming APIで開始されたgzip圧縮にも対応していないようです。あと、上流でHTTPストリームが切られた場合の再接続アルゴリズムも実装されていないようです(Squid経由で接続してSquidを再起動させれば簡単に再現できる)。前回の勉強会の時にJava Hackerに囲まれて話をしたときに「TwitterのStreaming APIを正確に実装しているのはTwitter4Jしかない」という話がありましたが、まさにそういうことなのかもしれません。Twitter4Jの作者であり、このTwitter API勉強会の主催者である@yusukeyさんに、懇親会でその辺のお話をうかがってみると、再接続アルゴリズムは実装も確認も大変とのこと。Perlに貢献するべく、AnyEvent::Twitter::Streamにパッチでも当ててみようかとも思ったのですが、作者がPerl界の大御所過ぎて、どうしていいかちょっと悩みますね。でしゃばり過ぎとか言われそう。

twitter-stream-search.pl は Date::Format と Date::Parse に依存していますが、Perl-5.10以上を最初から要求しているのだから、Perl-5.10からコアモジュール入りしたTime::Pieceを使えば不要な依存関係を減らせると後で思ったのでした。これは気が向いたら直します。Date::Format も Date::Parse も cpanm で簡単に導入できるので、それほど深刻な問題ではないと思いますけどね。

KotlinでもTwitter4J

@ngsw_taro さんによるトーク。KotlinというJavaベース(?)のプログラム言語があるようですね。そのKotlinからTwitter4Jを使おうというトーク。結局デモは失敗してしまいましたが、後日Kotlinから投稿したツイートがあったので、それでデモが成功(?)ということになった感じでしょうか。

LT中に紹介された、お手軽開発環境 http://kotlin-demo.jetbrains.com/

Java界隈にはGroovyとかJRubyとか、その上に乗る言語がたくさんあって面白いですよね。Twitterの勉強会なのに、Javaを見直すきっかけが多い勉強会でもあります。

懇親会

渋谷の外を移動して、今回も貸しスペースでのオシャレな場所で懇親会がありました。

(写真撮ってくるの忘れた…)

今回初めて出席された方と色々な話で盛り上がったり、前回トークをした方へ質問をしてみたり、有意義な時間が過ごせました。勉強会中だとなかなか質問したり交流したりといったことが苦手な日本人でも、酒が入るとその辺結構いけるものなんですね。酒が入った後にコードを書いたりできるかどうかは別として、初顔合わせや顔見知りの人と雑談する上で、お酒と貸切の静かな(勉強会関係者以外がいない)場所はうってつけの場所でした。

今回は発表者側に立ったこともあって、声をかけて下さる方もいて、発表者効果さまさまだなと思った次第です。用意は大変ですが、発表者として壇上に立つと、私のような知らない人に声をかけるのが苦手な人も話しに花が咲いて、非常に良い経験でした。

月1回の勉強会に、資料の用意がなかなか大変なこともあって、しばらくは発表者側にはまわらないとは思いますが、次回発表する際には低層の話ではなく、PerlとそのTwitterモジュールを使って書いた何らかのウェブサービスを紹介できればと思いました。体調が許せば、次回も聴講者として懇親会も含めて参加したいです。

第4回 Twitter API勉強会に行ってきました #twtr_hack

こんにちは、日々Twitterで情報収集やテレビ実況を楽しんでいる おがた (@xtetsuji) です。

(とりあえずアップします。今のところ、もう少し加筆予定です at 2012/02/27)

先日、2月23日になりますが「第4回 Twitter API勉強会」に行ってきました。

公式サイトは無いようです。上記ZussarのURLのタイムテーブルより。

  • 19:00〜19:40 @yusukey 「Webサイト向けAPI」
    参考図書: Twitter APIポケットリファレンス
    (書いてある内容+αを話すだけでお持ちでなくても大丈夫です)
    http://bit.ly/twtr-ref
  • 19:40〜19:50 グルーブに分かれて簡単に自己紹介
  • 19:50〜19:55 デジタルハリウッドよりご挨拶
  • 19:55〜20:35 @twtrfk 「Virtua Fighter5 Final ShowdownのTwitter連動機能について」
  • 20:35〜21:00 LT
    @kimukou_26 「TwitterSphere of Twitter4J」
    @making「Twitter Bootstrap入門」
    @bina1204 「ApiDemos of Twitter4J for Android」

こんな感じでした。

今回足を運んだきっかけは、2012年1月28日に行われた「第3回Twitter研究会」のUstreamをたまたま観ていて面白かったことです。「Twitter研究会」は年1回の行事とのことで、特にそのUstreamで興味をひいたTwitter4JとTwitter APIについての @yusukey さんのトークで知った「Twitter API勉強会」は頻繁に行われている、というのがきっかけでした。しかも @yusukey さん主催。

今回初参加となりましたが、迷うことなくZussarで懇親会を含めて参加申し込みをして、「Twitter APIポケットリファレンス」を事前に購入して会場に向かいました。

詳細なメモは取っていないので、ざっくりとした感想をつらつらと書いていこうと思います。

まず @yusukey さんのお話。前述の「第3回Twitter研究会」でのお話とそれほど大差ないお話でしたが、生で聴くのはまた違いますね。とても面白かった。ちなみに @yusukey さんはTwitter社の中の人であり、JavaライブラリのTwitter4Jの作者でもあります。

座るときに机の左側に座るように指定されたのですが、これが「グループに分かれて簡単に自己紹介」の時に、左側が社会人で右側が学生だという仕掛けだとわかります。学生と社会人の交流を促進する、面白い仕掛けだなぁって思いました。もっとも、私の隣にいた学生さんは、起業をしている学生さんで、半分社会人みたいな方でした。後ろ席の方ともコミュニケーションを取ったりしましたが、皆さんいい人達ばかりで話題に花が咲きました。

前回と会場が変わって、今回はデジタルハリウッドさんが会場を提供してくれたということでしたが、意外に駅から近くて、Wi-Fiも貸してくれて、とても広くて快適な会場でした。一瞬入学したくなったくらい。

第4回Twitter API勉強会のデジタルハリウッド会場の様子

交流タイムも終了して、次はSEGAの中の人 @twtrfk さんによる「Virtua Fighter5 Final ShowdownのTwitter連動機能について」。ゲームセンターの機器と直接Twitter連携しないで別途サーバを用意する等といったお話。サーバ側はLinux/C/C++/Javaだそうで、Linuxの上にWebSphereとDB2を載せているとのこと。SEGAのシステムはIBMと懇意なのかなぁと思ったり。大企業のシステムにしては、テーブル構造や処理ロジックの詳細等、突っ込んだ話が多くて、大いに興味をそそられました。「部内SNSであるAmitterというのを作ってデモをした」「Twitterのテストアカウントをテストだと分からないように地道に100個作った」(Twitterの規約では連番アカウントはグレーなんですね)といった面白い話も聴けました。部内SNSを作ってしまってデモとは見習いたい開発パワーですね。最後の方はマーケティングとして、初音ミクさんのお話等が盛りだくさん。ちょくちょく格闘ゲーム全般は触っているのですが、久々にバーチャファイターをやり込んでみたくなりました。マーケティングに乗せられてしまいました。

LTで特に印象に残ったのは@makingさんによる「Twitter Bootstrap入門」でした。@makingさん曰く「CSSフレームワーク」。以前から名前は聞いていましたが、ここまで簡単なものとは。あまりに簡単にTwitterライクなおしゃれなデザインが作れるので、他との差別化が難しいといった新たな難題が出てくるくらいだそうです。社内ツールに色付けをする使い方とかに良いなぁと思いました。

その後、懇親会のため移動。指定された場所に行ったら雑居ビルのようなところで一瞬不安になりましたが、会場である部屋の中は非常におしゃれで、これまた居心地が良い空間でした。

第4回Twitter API勉強会の懇親会会場の様子

懇親会でもそうだったのですが、全体的にJava Hackerの人口の多いこと多いこと。発表もJavaずくし。懇親会で話しかけた人が開発者だったらほぼ確実にJava Hackerという状況。まぁ、@yusukeyさん自体がJavaのTwitter4Jライブラリの作者で、その人徳で人が集まっているということも大きいのかもしれません。Perlしか書けない私に、なんとなくJavaも書いてみようかなと思わせるくらいの空気感。良い人だらけで、居づらいということは全く無く、どことなく自分から見た異文化を垣間見たようで楽しい空間でした。

しかし、Java Hackerの中でPerlのお話をすると「CGI(ry」「Perl6(ry」といった話を振られて、ちょっと困る場面もあったり…。PerlというかLLの外側の業界の人から見たPerlって、今も初心者がCGIを書くための言語という感じなんでしょうね、やっぱり。LL全般に言えることですが、Perlも日々相当進化しています。私が追いきれないくらいに。ここは「日本Perl改造計画」に期待したいです。

「PerlにはTwitterのStreaming APIを仕様通りに実装しているモジュールは無い」といった話をどなたからかうかがったのですが、AnyEvent::Twitter::Streamにも何か欠陥があるのでしょうか…。普段使いしていて大きな問題は無いのですが…(Proxy等にHTTPストリームを切られたときに再接続しない問題があるんだなということは最近把握しました)。

著者サイン!懇親会で機会をうかがって @yusukey さんからサインを頂きました。嬉しかったです。

Twitter APIポケットリファレンスにサインをもらった

Java以外の他の言語の発表も募集しているというお話だったので、機会があればPerlのTwitterライブラリについて発表してみようかなと思いました。発表をするかしないかは別として、次回も時間が許せばぜひ出席してみるつもりです。