カテゴリー別アーカイブ: perl

YAPC::Asia Tokyo 2014 が始まります #yapcasia

10年間くらい仕事と趣味でPerlプログラマーをしている、おがた (@xtetsuji) です。

件名の通りですが、YAPC::Asia Tokyo 2014 が2014年8月28日(木曜日)の夜の前夜祭から3日間にかけて行われます。

続きを読む

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を始めとした豊富な経験が聞けたりと、非常にお得な「エンジニアのオフ会」なので、中央線沿線に住んでいるエンジニアの人は土曜日暇であればぜひオススメしたいです。次回も予定が空いていれば参加します。

なんだか2014年はアクティブに活動していけそう

おがた (@xtetsuji) です。

当時それ以前から悪運続きではあったのですが、2010年にどうしようもない転職エージェントに出会ったところで人生どん底に落ちてしまい、はいあがるために2011年7月から一転してオープンな活動を始めるまで大変な時期を過ごしたっていうことは何度も書いたり話したりしました。

2012年と2013年のYAPC::Asia Tokyoへの大舞台登壇や、2014年2月の転職などを経て、ようやく色々な活動が軌道に乗りつつあります。

今現在進行形でやっている活動や、これからやりたいことを含めて、2014年も半分近く過ごしたので振り返ってみたいと思います。共感してくれて一緒に活動してくれる仲間募集中ですまた、かなり長いエントリなので、時間のない人は大きな文字だけ流し読みして「あとで読む」にぶち込んでいただければ幸いです

このエントリは2014年5月に書かれましたが、しばらくのあいだは加筆する予定です。

時間がある人向けの参考エントリ:

Perl入学式の運営側に入りました

3年目を迎えたプログラミング言語Perlの初心者向け勉強会「Perl入学式」、今まで2013年度のサポーターをやらせてもらっていたのですが、2014年度はより運営に近い形で参加しています。2014年度からはサポーターだけでなく、勉強会の運営方法の議論だったり、資料作成だったり、一部の講師だったりをさせてもらっています

これからもPerlを軸に、幅広い活動をしていこうと思っているのですが、Perl入学式は初心者に向けてアプローチできる絶好の場であります。しかも毎月定期的に行われている。たとえ手弁当でもそこで得られるものは自分にとって大きいと思い、色々と手を上げて作業させてもらっています。大変だけど、最初からこれをやっていた人も無報酬でやっていたわけで、コミュニティ発展のために自分も力になりたいと思った次第です。

これについては色々と盛りだくさんなので、興味があれば以下の記事を読んでみてください。

PerlBeginnersの共同運営者になりました

これもPerlの勉強会なのですが、PerlBeginnersという勉強会の共同運営者になりました。

今までは @ytnobody さんが一人で主催をして全てを一人でやっていたのですが、#12の懇親会のときに色々と大変だという話を聞いて、運営チームを立ち上げて複数人体制で運営をしていくことになりました。

ほぼ隔月で約2年間続けられたわけですが、当日 @ytnobody さんが突発的な仕事だったり病気だったりになった場合に主催できないという属人的危険性をはらんでいました。2年続けてきて、だいぶ多くの人に知られて定期的に20人程度の人は来るようになった勉強会になった今、そういう不安定な状況を解消しようと運営チームが立ち上がりました。今まで予定した日時に開催出来ていたことは、@ytnobody さん一人でやっていたことを考えると「運が良かった」とすら言えると思います。その辺の冗長化も考えた運営チーム発足となりました。

運営チームと言っても、現状は主宰者の @ytnobody さんと私の二人体制ではありますが、今後様子を見つつ徐々に増やしていこうと考えています。

2014年5月23日に新体制初の #13 を行いましたが、ちょうどというか @ytnobody さんが仕事で来られるかどうかわからない状況だったので、私が会場を開ける担当となりましたが、今回は @ytnobody さんの仕事が無事に終わったので事なきを得たのでした。こういう状況のための運営チームといっても過言ではありません。

執筆業へ進出したい

私には書籍を書くという夢があります。これ、実は水面下で良いお話をいただいていて、もしかしたら今年あたりに共同執筆者という形ですが実現できるかもしれません。私の頑張り次第である部分も大きいのですが。夢は言えば叶う方向に向かうものなんだなぁと思わされます

1冊書いたら満足とは思っていませんし、今後も人の役に立つアウトプットはしていきたいので、どんどんインプットもして、それに応じたアウトプットをしていきたいと思っています。

とかく、文章を書くというのは時間のかかるものです。このブログを書くのだってゆうに数時間はかかっています。1000文字以上のそれなりの品質の文章を書くというのは、多くの人にとってそれなりの時間がかかるものだと思います。

ブログ等といった広義の執筆も続けていくつもりではありますが、これからは電子書籍かなと思っています。自分自身もKindle PaperwhiteKindle Fire HDXを買って読書と書籍に対する概念が変わりました。紙の書籍はとてもあたたかみのある良いものではありますが、保管場所は有限です。特に東京での保管コストは高いと言わざるをえないでしょう。

今後、電子書籍はどんどん普及していくことでしょう。それに伴って、紙の書籍よりも出版障壁の低い電子書籍への出版も増えていくものと思われます。私もその流れに乗って電子書籍で自分の知識を出版していきたいと考えています。もちろん「電子書籍だから値段も内容も妥協」なんてことはしないつもりです。

とはいえ紙の書籍や雑誌へは一度は書いてみたいですね。もう5月末ではありますが、今年中に実現できるよう、邁進していきたいです。

新たな勉強会の立ち上げや、教育事業をやりたい

ここ最近はPerlの勉強会がブームです。色々な新規勉強会が告知され、既存のも含めて告知されるとすぐに定員が埋まってしまいます。

Perl入学式in東京も五反田の会社であるガイアックスさんが毎回会場など全面的にサポートしてくださっていますが、特に五反田界隈のPerl企業がとても元気です。

  • Gortanda.pm
  • 五反田Perl
  • Yokohama.pm (最近になって不定期開催から定期開催になった)
  • Hachioji.pm (毎月の飲み会勉強会)

最近はPerl入学式つながりで、時間があるときにPerl入学式の「卒業生」の方と中野で会って個人レクチャーをしたりしています。

そういう話を他の勉強会の懇親会でしたら「Nakano.pmを作ればいいじゃないですか」と言われたりしました。確かに「もくもく会」的なものでもいいから、隔週でやるのも悪くないかなと思って、実際に中野駅周辺で会場探しなどを始めています

ここまで来ると、Perlにこだわるのも、それにこだわらない活動をするのもアリだなーと感じています。Perlをやることを目的として楽しむことも大切だと思いますが、私達は人生の何らかの目的を持っていて、それを実現するための手段を日々探しているものです。それを実現するための一つの手段がPerlであり、また別の目的を実現するためにはPerl以外の手段が必要な場合もあります。

中には「金を払ってでもマンツーマンで個人レッスンを受けたい」という需要もあるようです。cyta.jpなどがそういう人とのマッチングサービスを行っていて、家庭を持っている人に比べて自由な時間の多い独身の自分は、そういうところでお金をもらって人にモノを教えるのも悪く無いと思いました。世の中、金で人の時間を買ってでもいいから深く学びたいという人だっているという需要に答えることは悪くないと思っています。cyta.jpには登録したのですが、登録審査の面接に行けていない状況です。こういう審査が厳格だというのは好感が持てますね。

手弁当や無報酬でコミュニティに尽くすことも大事なのですが、自分を安売りすることだけはやめたほうがいいと思っています。無報酬コミットも、最終的には自分の名声を高めたり、教えた人が業界をめぐりめぐって間接的にでも自分の利益になるかもしれないと考えて行動することが大事なんじゃないかなと思います。そうじゃないと持続的に活動できない。

私が住んでいる中野区などの自治体と協力できないかとか考えたりもして、実際に中野区の課に電話をしたりと行動に移したりもしているのですが、電話ではあまり良いアクションはもらえていません。中野区には「中野アフターシックス」という中野区役所の若い意欲的な職員の勉強会があるらしく、テーマが自分の考えているものに近い時に出てみようと機会をうかがっています。政治思想云々に関わらず、今後自分の住んでいる街を良くしていくためにも、行政との関わりを増やしていくことは悪いことではないはずです。これは特に既婚者や子供を持った家庭であればなおさらではないでしょうか。

また中野区に新しく誘致された大学のキャンパスとの連携も出来ないかと考えています。明治大学が中野セントラルパークにキャンパスを新設して、そこに理工学部が併設されていることを考えると、若い優秀なIT人材の拠点としても中野区は有力な一つじゃないかと思っています。まだ実際にアプローチはしていませんが、明治大学には一度アプローチしてみたいと思い、手元で準備をしたりしています。

また会社主催の勉強会も出来そうな雰囲気で、期待していますし、そのために細々とネタを貯めています。最近は社内勉強会も盛んで、個々人が業務で忙しくて定期的な開催はできていない状況ではありますが、その成果が社内から社外へ何らかの形で出していこうという事を会社の役員が課題として持っているところは、非常に頼もしく思っています。この会社に転職できてよかったと素直に思えるポイントです。

純粋数学の勉強会をやりたい

私は数学科出身です。最近はプログラミング活動ばかりで数学からは遠ざかってしまったのですが、たまにやってみると面白い。もっと数学へ時間を割いて、数学の楽しさを再び体験したいと考えています。

どうせなら多くの人で数学の楽しさを享受できないものかと、とりあえず夢を声に出すメソッドで「純粋数学の勉強会というものをやりたい」と言っていたら一部から期待されているらしく、これの実現も模索しています。こうやってブログに書くのも夢を声に出すメソッドの一環です。

会場探しに関しては、上述のように中野区にアクションをかけたり、大学へのアクションを模索したりしています。またPerlBeginnersの共同運営者になって、主宰者である @ytnobody さんから会場を借りるテクニックというのも学べて、本当にありがたいと思わされます。

数学の勉強会は、統計学などの実用に近い勉強会は社会人向けで幾つか行われているようです。そういうのも大切ではあるのですが、自分がやってみたいのは、どちらかというと業務や社会の役に直接は役に立たないけど非常に示唆にとんで興味を駆り立てられる数学というものです。具体的なテーマを言えば「素数」とか

私は功利主義やお金を稼ぐことに対することへの大切さも身を持って体験しているのですが、行き過ぎた功利主義への反論というか皮肉も大好きで、よく「それってなんの役に立つんですか」といった質問に対して「何の役にも立たないんですよ」と笑顔で言って楽しむことが多いです。とかく数学科なんかに進学したら、当時超就職氷河期と言われた時代、外野はそういう質問ばかりするわけです。完全に慣れました。というかそんなことを言ったら、大学の学問なんてどれも実利になるかと言われたらどれも変わらないでしょう。私も「残念ながら数学の整数論といった分野も、現代のコンピュータ時代の暗号化理論の中で最重要分野となってしまいました」と皮肉を込めて何度も言っていました。大学生に学問の功利主義的質問をする人は「大学行くくらいなら職業専門学校に行った方がいい」って素直に言ったほうがいいです、本当に。

整数論の話が出ましたが、数学科時代、そんなに整数論に興味はありませんでした。というか整数論の研究室が最も難しいと言われていたことや、数学に興味を持ったのは高校2年の微分積分論からだったので、微分積分論を包含した解析学の研究室へ進むことになりましたが、やっていたことはフーリエ積分の概念を拡張して完全に代数学として抽象化したものをやっていて「代数学やりたいと思わなかったんだけど…」というのが正直な感想でした。逆に整数論の研究室に進んだほうが、素数の分布を調べたりするのに重要な関数の積分を使ったりといったことをするので「素数の理論に興味あるし、整数論の研究室に行けばよかったかも」とも思いました。とはいえ、解析学の研究室の教授は日本でも有名な数学者で、非常に勉強になった大学院2年間であったことは事実です。

私と同世代に中島さち子さんという数学者がいます。現在の本職はジャズピアニストですが、日本人女性として初めて数学オリンピックで金メダルを受賞したり、高校生当時から論文や数学書を書いたりといったすさまじい人でした。高校生向けの数学雑誌などでそういう活躍を見て、当時数学に興味を持っていた高校生の私は衝撃を受けたものです。そんな中島さち子さんも、私が大学院を卒業する頃には研究活動を聞かなくなり、結婚して子育てをしているという話を聞いていたのですが、そんな彼女もここ数年になってまた数学活動を再開したという話を聞きました。比較にならないすごい人ではあるのですが、ブランクを経てもまた数学という活動をやる姿勢に、大いに感銘を受けたことは事実です。

誰もが中島さち子さんのような天才にはなれませんが、近づこうと頑張ることは自由です。中島さち子さんも素数の学問の一つである「ゼータ理論」を主に業績としています。そんなことを考えながら、我々一般の社会人も素数を研究したっていいじゃないかと、現在やり方などを模索している最中です。

ラジオなどの音声媒体への進出したい

エンジニアの世界では情報の提供方法が時代とともに変わってきています。一時期流行ったポッドキャストという手法が、今エンジニアの世界で脚光を浴びています。

非常に著名なエンジニアであるTatsuhiko MiyagawaさんによるRebuild.fmから始まり、riywo’s Podcast職質テックトークといったポッドキャストが続々と登場しました。最近ではボケてで有名なオモロキのCTOでJPA理事でもある和田裕介さんによるDandy.fmなどが躍進しています。

実は職質テックトークの第3回に出演させてもらったりして、ポッドキャストに出演するという夢は叶えられたのですが、実際にポッドキャストを立ち上げたり、もっと別のポッドキャストの番組に出演したりといったこともやっていきたいと考えています。そのためにも、自分のしゃべりをより聴きやすくするといったトークの技術も磨いていきたいと日々意識しています。

自分の声って録音したカセットテープを聴いても鳥肌が立つのですが、大学時代のアルバイト仲間に「おがた君って声やしゃべり方がNACK5の長谷川雄啓に似ているよね」って言われて、「えっ、こんな声でもラジオでDJできるの?」って思ったというか思い上がった経験があります。実際、自分の声の良し悪しって自分では判断できないもので、大人気の声優さんも当時は自分の声が嫌いだったりとかっていうことはザラにあることらしいです。みなさんも自分の声を録音して聞くのが苦手という人は多いのではないでしょうか。

しゃべるのは好きで、内容は置いといても延々としゃべっていられる自信はあるので、ポッドキャストとはいわず、実際にFMやAMで電波をとばしているラジオ局で番組を持ってDJをやってみたいという夢を持っています。それも、前述の大学時代のアルバイト仲間に言われた言葉がキッカケなような気もします。そして2011年から勉強会やカンファレンスで人前で時間制限を設けてトークをすることに慣れてきたこともあるでしょう。

エンジニア向けのポッドキャストに出演して語れるトーク力や技術力を磨くこともそうですが、ラジオのDJであったり、もっとラジオという媒体にコミットできればなーとも思っています。最近ではテレビの視聴率低下という話は聞きますが、ラジオといった音声媒体は今だからこそ可能性が広がっている部分もあります。

エンジニア向けポッドキャストの流行も、iPhoneがいつでもどこでもポッドキャストを回収できるようになったというソフトウェア的・ネットワーク回線的な要素も強いでしょう。また、radikoらじる★らじるといったインターネットを通じたFMやAMのリアルタイム配信も始まって、ラジオの新しい時代が来ている感じがします。

最近、コミュニティFM「練馬FM」の開局を目指している練馬放送の関係者と偶然お会いして、支援は惜しまないという話をしたところ、そのあたりでも話が進みつつあります。すでにあらゆるプロによってDJという枠は埋まっているらしいですが、ラジオという媒体を伸ばしていく活動はしていきたいと考えています。

ピアノと作曲をやりたい

小学生の頃からクラシック音楽が好きで、今でも毎日NMLでクラシック音楽を聴き漁っているのですが、ピアノと作曲をやることが昔からの夢でありました。

作曲自体は、中学時代から楽理の書籍を買ってリコーダーの曲を作曲したりしていたのですが、和声というものに対する理解が進まず、そのための第一歩としてピアノを習いたいと考えています。ピアノ曲自体への興味は、クラシック音楽全体の中ではそれほどないのですが、作曲ツールや楽理解析ツールとしてのピアノを学びたいと考えています。

私はベートーヴェンを心の底から尊敬しています。私も交響曲という芸術で自分を表現したいという夢があります。死ぬまでに一曲は交響曲を書きたい。え、ゴーストライターに書かせればいいって?サムラゴーチの話は後述するから

歩けばコンビニと歯医者と美容室だらけの日本ではありますが、ピアノ教室もそこら中にあります。ただ、どこに行くかという決定打が無いのです。このあたりも音楽に携わっている人に紹介してもらおうと、日々おすすめの教室を聞いて回っている最中です。そんな中で二胡のおすすめの教室は聞いたのですが、二胡をやるかどうかは迷い中です。

あとは部屋を片付けて電子ピアノを買うだけです。部屋の片付けは大変ですが、電子ピアノの投資はグランドピアノほどではなく、ちょっとしたパソコンを買う程度です。

嘘をつく人の研究

よく「人間観察が好き」という人がいます。そして「人間観察が好きとかいう人、ちょっとキモい」という意見もあったりして、面白いなぁと思います。「人間観察が好き」って女性に多いと思うのですが、「音楽が好き」くらい他愛もない主張で、社会人になったら誰もが初対面の人に対して「こいつカルト宗教やねずみ講やってないよな」って警戒するのが普通だと思っています。別に性善説・性悪説は別として。

私は田舎出身で田舎丸出し状況大学生だったので、カルト宗教に軟禁されるところからからエウリアンや高額商法に閉じ込められるところ、ねずみ講の勧誘までひと通り体験しています。性悪説と言ってしまうと極端ですが、人間観察というよりもその対象人物が関わるに足る危険人物ではない最低ラインを越えているかという観察は社会人は普通にするものだと思っています。

危険人物に共通しているのは、自分の領域に引き込むために「嘘をつく」ことです。危険人物でなくとも嘘をつく人というのはそこら中にいて、上述のような経験を経て、私は嘘をつく人の心理を研究することが大好きになりました特に社会を震撼させるような嘘をつく人の心理は超大好物です。騙された側の出方というのも興味深い。今からこれをテーマに社会学の大学に入学したいくらいです。

昔から最近まで、社会を震撼させるような嘘をつく私の研究題材となったのは以下の三人です。

特に旧石器捏造事件は熱中して、実際に「遺跡」に行ったり、藤村新一に会って話をするにはどうすればよいか考えたくらいです。

佐村河内守については、事件以前から交響曲HIROSHIMAの存在は知っていたのですが、無調音楽が嫌いだということと、(後の嘘だとわかる)聴覚障害などを商業主義にし過ぎだろうと敬遠していました。CDが回収騒ぎとなってしまった今となってはCD買っておけばよかったと思いました。NMLで配信してくれないかな。私の尊敬しているベートーヴェンを冒涜してくれた人として、後世まで「世間を震撼させた嘘をついた人」「私の尊敬しているベートーヴェンを冒涜した人」として徹底的に研究しようと思います。

そんな長年の研究(?)でわかったのは、嘘をついてもバレる、嘘をついてもいいことがまるで無い、ということでした。当時ゴッドハンドとして名声を得ていた藤村新一も、実際は葛藤を抱えながら不安とともに生活していたことは、のちになって明らかになることです。

私は時々不眠になって朝起きられない体質にあるのですが、そういう時、会社には遅刻の理由として、正直に寝過ごしたと言うことにしています。拡大解釈すれば体調が悪いと言えないこともないのですが、それは言っても遠因であって、本当に体調が悪いときにオオカミ少年になる可能性があるからです。

一時は不眠で通院していて睡眠薬を処方されていた時期もあるのですが、今は不眠は脱しました。とはいえ朝早起きが苦手なのは子供の頃からなので、体質といった部分もあるでしょう。今は処方された薬の副作用で昼夜を問わず眠くなるので困ったものです。正直に理由をいうことによって自分を律することが出来て、また薬の副作用に対する耐性も出来て、最近は遅刻もしなくなりました。

お金を稼いで節約して、好循環を築きたい

前述のように手弁当や無報酬でイベント運営に協力したりしていますが、自分の中長期的な人生を俯瞰した時に、持続的な活動をするためにはお金を稼ぐ必要もあると考えています。職業プログラマーとして会社勤めをしていますが、終身雇用制が瓦解した今は、明日に何が起こるかわかりません。いつかは地元に帰りたいとも考えているので、今の会社と相思相愛だから大丈夫…という話でも無いのです。同じような状況の人は少なくないのではないでしょうか。

個人的に活動するといっても、サーバ代であったり交通費であったり、時間をコストに換算しなくても直接かかってくる費用というものはあります。せめてそういうものが相殺されるくらいの収入が定期的に入る状態をまず作り、あわよくば会社の収入に頼らずとも生活できるくらいのお金が入るような体制が築ければ良いと考えています。

最近では副業といったものの是非であったり法律的根拠の皆無な点を説いた記事を見かけます。会社員としての仕事を真っ当にこなしていることを前提にすれば、私は副業については賛成な立場です

前職は規約で副業を禁止している会社だったのですが、「私はAmazonでアフィリエイト収入を月に数百円もらっているが、そのために書いたブログ記事なども副業になるのか」と聞いて回っても、偉い人から管理部署まで、答えられる人がいませんでした。「小銭だから大丈夫じゃない?」という発言は答えになっていません。同僚の「確定申告しなくちゃいけなくなったら副業と言われそうだよね」という発言が一番的を射ていましたが、労少なく儲かってしまって確定申告をする羽目にになったら副業だと言われて活動を禁止されてしまうのでしょうか。本当よくわかりません。私も調べては見たのですが、労働関係の法律で副業禁止に対する法的根拠が明確に関連付けられるものは無いように思えました。これは前職退職の多くの遠因の一つです。

「エンジニアが収入アップするには転職しか無い」というのは多くの場所で事実になっているように思えます。会社に長く勤続しても、エンジニアという職種では大きな収入アップは望めない場合が多い。その割に、優秀な人は高給で引き抜こうとするので、エンジニアの収入アップは転職という手段に限られると揶揄される一面は良くない風潮だと思えます。

とかく年収という話はタブー視されていますし、私も蜘蛛の巣を突くような議論をしたくはないので意識的に避けてはいるのですが、個々人が本職を含めた生活全般でもっと所得アップできる仕組みづくりはしないといけないと考えています。それが年収を暴露する風習を作ることで実現できるか、今の私には分かりません。

私達30代が60歳になった時には確実に年金制度は崩壊しています。年金とは積立制度ではなく、現在の老人世代に払う費用であり、それは平均年齢が60歳から70歳だった高度経済成長期だからこそなりたつ制度でした。少子高齢化時代ではすでに年金制度は崩壊していると断言してしまってもよいことは長妻昭に聞かなくてもすぐに分かります。正直、今の国家や老人をないがしろにしてもいいというのであれば、国に年金を払うことをやめて、個人積立年金を契約したほうがいいのです。正直、残念なことに、ないがしろにされても仕方がないような尊敬に値しない老人が最近増えているように思えます。可能な限り年金制度維持のために税金を払って行きたいとは思っていますが、こういう老人がさらに増えるのであれば、老人優遇の政治に反旗を翻す意味でも、労働者世代は根底から考え直す必要があるかもしれません。

数十年後、年金制度が崩壊している中でどう生活をするか、この話はそういう中長期的な人生プランへの疑問提起でもあるのです。

健康とそれに対する投資を惜しまない

私は病気がちで、昨年2013年の12月に胃潰瘍で入院したり、色々な病院へ通院しています。

私の業界ではそう多くないようですが、働き盛りの男性は病院嫌いだったり自分が病気認定されるのを嫌う人が多く、病院受診をしなかったりするケースが結構あるそうです。そういう人が、突然大病を患って一気に亡くなってしまうという話も聞きます。

私はライフログが趣味で、自分に関するあらゆるデータを数値化したいという趣味があります。そういう意味でも病院は結構好きな方で、風邪でもすぐに病院に行ったりするくらいです。もちろん、痛いのは嫌だし未だに注射されるのは嫌なのですが、ちょっと体に異常があったら病院に行こうとするタイプではあります。「健康な人」が保険金泥棒と揶揄する典型的な人ですね、私って。

胃潰瘍入院のときも、「ちょっと内科に行ってみるか」と気軽な気持ちで行ったら、救急車で運ばれて緊急入院となったくらいです。大量出血で突然倒れて死ぬ可能性も十分あったということは後で聞かされました。何か体に異変を感じたら病院に行くことはとても大切なことです

最近は UP24 by Jawbone という、iPhone/Android端末とBluetooth通信をして、歩数や就寝を管理してくれるデバイスを購入しました。自分の行動が数値化されるだけで嬉しいのですが、歩かなかったり睡眠時間が足りなかったりした場合にアドバイスしてくれたりする機能がお気に入りです。一人で生活をしているとどうしても生活リズムが乱れがちになりますが、こういうアドバイザーがいるのは良いと感じます。この機械、1万6千円くらいしたのですが、健康への寄与を考えたらかなり安い投資だと思って買ってしまいました。まぁ、胃潰瘍の入院費用がそれの10倍位しましたからねぇ…。

UP24については1ヶ月使ってみて色々使い方がわかってきたので、別記事で書きたいと思います。

部屋の片付けと良質な作業環境とノマドワーキングを整備したい

部屋が散らかっています。冒頭の話になりますが、2010年からやる気が起こらなかったからなのと、最近は土日に勉強会などの予定がてんこ盛りで、時間がないからです。

カフェ巡りは好きなので、そういうわけでカフェで作業をしたりといったノマドワーキングでお茶を濁しているのですが、本格的に部屋を片付けようと思っている次第です。ちょっと今の状況だと来客呼べない。

キーワードとしては、自炊、料理教室、効率的な洗濯環境、断捨離といったところでしょうか。年始に書いたブログ記事にもそんなことが書かれていました。

ノマドワーキングについても、部屋を片付けたあとでも「別の場所で作業をする効果」というのはあると思っています。近所のカフェなどの営業時間などを把握したり、趣味の延長線上で新規開拓をしたりといったことをしていきたいなと思いました。

今まで目を向けてこなかった語学や経営といった勉強

YAPC::Asia Tokyoでは、毎年海外から著名なゲストが来るのですが、英語を聞いたり話たりすることに臆病になってしまい、結局交流できずといったことが続いていました。そんなことをとある人に話したら結構怒られてしまい、ダメだなぁと思った次第です。せっかく著名な開発者が海外から来ているのに、つたない英語でもいいから話さないと本当にもったいない。とかく日本人全般的にそういう傾向にあるようで、海外からきたゲストは結構ぼっちになっていて、そんなぼっち気味の海外ゲストを誘導したりする英語に堪能な方は、もっと日本の開発者はつたない英語でも積極的に話せばいいのにと思っておられるようです。本当にそう。反省しかできない。英語教室に通うかどうかわからないですが、英語を聞くことや話すことへの抵抗を無くして、今年は世界を広げます。あわよくば日本を飛び出して世界で働きたい。声に出すと夢が叶うメソッドです。

また、経営といったものも勉強したいと考えています。元々は先日祖父に言われたことで、詳細は割愛しますが、その話がごもっともだと思ったからです。

前の会社では、経営陣がコロコロ変わって、とある時期には実質的な経済犯罪といったことが行われたこともありました(上場企業なのでこれは公開情報です)。その後も経営不振が続いたり、経営が理解できればもっと発言に説得力が持てたんじゃないかと今になって思います。経営への参画は別として、平社員でも経営を監視する眼力は必要であると思わされました。

幸い今の会社は業績も好調ですが、経営への理解をすることは、自分の仕事がどのようにマネタイズされているのかといった意識を持つことにもなって良いことでしょう。

どうやって経営を勉強するかは悩みどころです。経営者セミナーに行けば莫大な金を取られるでしょう。書籍を買って学ぶとしても、玉石混交そうでどれから手をつけていいか分からない状況です。何かオススメの経営学習方法があれば教えていただけると幸いです。

結婚はしないんですか?

これ、今も祖父に言われるんですよね。一回この質問をされて親親戚の前で相当不機嫌になったことがあって、祖父以外の親親戚は聞かなくなりましたが、祖父だけはしぶとい。

そんな、くじ引きみたいな感じで女性とペアを組んで結婚できるほど現代は手軽じゃないんですよ。とかくメディアは虚構のような恋愛観を女性に振りまいて、統計人口的に多い男性のほうが不利な状況を生んでいます。

高度経済成長期を生きた今の老人は軽々しく結婚できるだろといいますが、あれは戦争直後で男性人口が減っていたのと、誰もが企業に入れて年功序列と終身雇用の中でお金をもらえたので、結婚のハードルというものが実質なかったからです。

今はテクノロジーが発展した平和でエキサイティングな世の中でありますが、そういった今の老人世代が体験した結婚へのハードルが低い時代ではありません。むしろ、男性人口が増え、働いても所得は増えず、メディアが発達したために虚構のような恋愛観に感化された女性が冗談のようなハードルの上げ方をしている時代です。

これは江戸時代中期と同じような様相なんですよね。江戸時代中期は太平の世となり、統計的に男性人口が増えていきます。また戦もなくなり、徳川幕府の方針によって取り潰される藩も出てきて武士を失業した浪人というのも出てきます。そうでなくても参勤交代などで藩の財政は圧迫され、武士の収入は上がる余地がありません。特に江戸といった地域では圧倒的に男性人口が高かったようです。これも現代の東京人と似たようなものでしょうか。なので、江戸時代に結婚できない男性というのは珍しくなかったようです。江戸時代でさえそうだったんですから、今の若者世代が責められても困りますよね。

エンジニア界隈でも女性エンジニアの人口を高めていこうとしています。少子高齢化でエンジニアに限らず今後どの職種でも人材不足を起こすことでしょう。エンジニア業界でも、女性を取り込むことでエンジニア不足の解消を図ろうとしているのです。数的に男性優位になりがちなエンジニアコミュニティ、女性エンジニアの増加にいやらしい考えを持つ人も少なからずいるようですが、私は今後職業選択の上であらゆる職業で男性女性という区別はなくなっていくのではないかと考えています。男性の所得だけでは生活できないという負の側面もありますが、女性の社会進出が増えていき、多くの職種が男女均等になり人数的に平滑化していくことでしょう。それは素直に喜ばしいことだと思います。

そうなったときに考えるのかですって?それはあと10年くらい先の話でしょう。

私は老若男女といった視点で人を見ていません。そこにいる人は老若男女関係なく人として素晴らしいかどうかという価値観しかない。その素晴らしい人がたまたま女性で、たまたま未婚で、たまたま私に好意を持って男女の関係で付き合うことができればそうするし、そうでない場合には何もしないといった単純かつ明朗な価値観しか私は持っていません。「喉は渇いても下水は飲むな」とはよく言ったもので、今の時代、無理して結婚しても「腹を壊す」ことは心得ておいたほうがいいと思います。特に高度経済成長期を生きた老人は。

ここでは私が独身であるという表明をしていますが、私は仮に女性と付き合っても、仮に結婚しても、そのステータスは隠すと思います。まぁ結婚式とかは女性先導のイベントなので、そこで多くの人に広まってしまう可能性はあるかもしれませんが、個人的に男女関係や結婚の話は年収くらいタブーでもいいと思います。というか男女関係の話って酒場で話すと面白いけど、公で話されているとイライラするというのが年収の話と共通なのは、私が高給取りではなく独身だからでしょうか

上述のように様々な活動をしていく上で、今後今まで以上に多くの人と出会うことになるでしょう。というか多くの人と出会って自分を成長させていきたいと思っています。そんな中で出会いの確率というのも微量ながら上がっていくのではないでしょうか。それくらいしか私は祖父にいう言葉がありません。

私自身、結婚したいとか女性と付き合いたいという欲求が他人と比べて少ない人なんだなというのは、他の男友達と話していて感じることです。ただ、女性と付き合いたい、結婚したいという欲求の高い友人知人には成就してもらいたいという気持ちはあるので、どのようにすると出会いが生まれて男女は惹かれ合うのかということは、常日頃から考えています。それが自分に活かされるかは別として。なんだか思考が「お見合いおばさん」になっている感じもするのですが、人間の感情を数値化したいというライフログ的・数学者的価値観が根底にあるからなのかもしれません。

すべての活動はつながってゆく

最近電車通勤していて目にとまる「男子との“三角関係”を解く“公式”は/大塚食品 マッチ、マッチピンク「青春と数学」編」の車内広告を見ていて面白かったのですが、恋愛に方程式や公式がないのは、恋愛が一階述語論理で記述できないからです。では高階述語論理を導入すれば恋愛が記述できるのか、冗談でそういう勉強会をやってもいいかもしれません。それにはHaskellがちょうどよいでしょうか。プログラムや数学といった活動につながりますね。

カフェ巡りは趣味ですが、行きつけのカフェが出来て、そこの店主と知り合いになって仕事以外の女性の知人が増えつつあります。特に深い知り合いでもなく、一度きり会ってFacebookで友人申請をする程度ですが、その女性の趣味傾向で、自分の男性の知人の中と合いそうな人がいたら、積極的につなげていきたいと考えています。

とある私の北海道の友人は行きつけの酒場で生き生きしているので、どうすればそんな生き生きできるのかと聞いたら「ここが自分のホームだからだ」と言いました。また、他の居酒屋では普通にしているとも。私にとってのホームは、前述のカフェなのかもしれません。慣れ合いの場を作れという意味ではありませんが、自分の活動の軸足、ホームを作ることは大切なことだと感じます。

ピアノの世界は数的に女性優位の世界なので、ピアノを習えば出会いの一つもあるでしょう。私は交響曲を作曲したいだけで特に出会いに期待はしていないのですが、もしかしたら祖父が喜んでくれるイベントがあるかもしれません。

手弁当や無報酬で行ってきた各種勉強会も、運営側に入ってみると内部では「属人性を解消していきたい」とか「実費くらいは捻出できないと継続的な活動ができなくなる」といった問題点を抱えていることを知りました。でもできれば参加者からはお金をとりたくないというのはどの勉強会でも一緒で、儲けるというか「赤字を出さない」ためにはどうすればよいかというのは、まさに経営的思考だったりします。

ラジオやポッドキャストでは、著作権フリーの楽曲が求められています。特にポッドキャストで歌を歌ったりすると、ジャスラなんとかが大金をふんだくりに来たりすることもあるそうです(私の収録のときにも「歌を歌わないでください」と注意されました)。私は作曲活動をすることで、他愛もないけど色々な状況で使える使用権フリーなBGMも作曲していきたいと考えています。それはポッドキャスト界隈やコミュニティFM界隈を盛り上げていきたいといったところにもつながります。そうした積み重ねが、芸術としての「私の交響曲」につながっていけばいいなと感じます。

何が危険で何が安全なのか、嘘をつく人の研究をもとにして、勉強会などで知り合った多くの人を危険な目に合わせないために、自分が身につけた情報発信力で啓蒙していきたいと考えています。とかく、参加している勉強会の性質上、Perlを仕事に活かしたいというビギナーの方から相談を受けることが時々あります。私が2010年に出会ったような、(嘘というよりは)ダブスタに満ち溢れた最悪の転職エージェントといった人売りを頼ることはさせない、そういう活動は啓蒙していきたいです。技術力との折り合いが付けば、私の職場や、他のマッチする職場への斡旋もやぶさかではありません。転職エージェントとは違い、私に法外な対価は要りません。

色々な活動をすることで、土日も忙しい日々を送っていますが、逆にリズムが保てるというメリットもあります。以前まで平日の睡眠時間を削って土日に眠り続けるという生活をしていましたが、そういうのはやめて、平日も土日もあまり差がない睡眠時間にしようとしています。なぜ人間は睡眠を取らないといけないのかという医学的な結論は出ていないそうですが、所定の睡眠時間を取らないと多くの人は健康を損なうという事は裏付けられています。UP24を買って睡眠を数値化出来た今、ようやく良いリズムが出来て、それが今の私の活動意欲につながっているのだと思います。

長い文章でしたが、いい年齢になった今さらながら色々な方面で頑張って行きたいと考えています。何事も始めるのに遅すぎることはない。協力してくれる方や仲間も募集しています。今後の私の活動にご期待ください。

二項演算子の間の空白の意味

おがた (@xtetsuji) です。インフラ志望で10年以上前にオープン系IT業界に入ったのですが、今では当時やろうとも思わなかったウェブプログラマーをして生活しています。

今回はタイトルの通り、二項演算子の間の空白の意味。コードレビューがある文化の人達はこういう議論をしたことがあるのかな。私はそういう文化がほとんどなかったので、単に持論を持っているだけでして、今回はその持論を書いてみようかなと思ってブログを書き始めました。Qiitaに書こうかなと思ったんですが、エッセーに近いのでたまにはプログラム的話題をこっちにも書いてみようかなと。

事の発端

先日、会社でJavaScriptの初心者向け研修が行わていて、自分は参加対象じゃなかったのですが、講師の話が漏れ聞こえてきました。「あぁ、基礎的なことをやっているんだな」って感じでしたが、講師が言った「イコールは代入です。イコールを代入に使ってしまったので数学的な比較はイコールイコールになりました」とか、そうだよねぇって聴いていたわけなんですが、一つ漏れ聞こえてきた解説で気になったことがありました。

「イコールの両端の空白は見やすさのためです」

いや、それは半分正しくても、本当の意図はそこじゃないんじゃないの?と。

演算子の優先順序

演算子には優先順序があります。JavaScriptにも当然ながら演算子の優先順序があります

私は、空白や空白類文字がこの演算子の優先順序や結合力を惑わしてはいけないし、それを表現するようになっているべきと思っています

空白が表現する演算子の優先順序

一番簡単な例は、加減乗除でしょう。足し算や引き算よりも掛け算や割り算のほうが優先順位が高くて、左から計算される(評価される)ことは中学までに習うことで、誰もが知っていることです。

2980円のものを買って消費税がかかったんだけど1000円の割引クーポンを持っていたとしましょう。

2980 * 1.08 - 1000

こういう計算式を書くのが普通で、普通に左に掛け算があるから左から計算しても大丈夫だと思うでしょう。ただ、こう書くとどうでしょう。

2980 * 1.08-1000

マイナス記号の両方に空白がありません。普通のプログラム言語では二項演算子の前後の空白についてはあまり気にされませんし、まさに見やすさ以外の意味はないのですが、あたかも「くっついているほう」が先に計算されると、油断している時や心が弱っている時に勘違いしてしまうと思いませんか?

これは誰もが知っている二項演算子の簡単な例ですが、もし普段あまり使わない二項演算子の組み合わせでこれをやられて惑わされたとき、あなたは正しい判断ができるでしょうか。

Perlにも演算子の優先順序がありますが、空白で惑すことはいくらでもできます。

my $result = 2 * 3 ** 5

2に3の5乗をかけているのですが、空白が等しく入っているので、べき乗演算子 “**” の優先順位が掛け算演算子より高いことに気づかない人は惑わされるでしょう。一番良いのはカッコを使って明示的に優先順位を表すことですが、プロジェクト内で比較的自明な場合は空白のありなしで結合力の強弱を表すことが暗に行われることもあると思います。これは簡単な例なので良いのですが、カッコだらけになって見づらくなるという意見もあるので、なかなか悩ましいです(Lispをしこたまやっていると、カッコが見えなくなるというプログラマ的進化を遂げられるらしいのですが)。

my $result = 2 * 3**5;

PerlでもJavaScriptでも、代入演算子 “=” の優先順序は非常に低いのです。なので、より優先順序の高い比較結果の真偽値を入れるということもできます。

var bool = x == y; // x == y の真偽値を bool に入れる

あれ、でもなんだか見づらいですね。カッコを入れるか、”==” の両端の空白を無くすか、色々なやり方があると思います。私も個人で書くプログラム、GitHubやCPANで公開するプログラム、社内プロジェクトで書くプログラムで、書き方をわけるかなーとは思います。

単項演算子や三項演算子

今回の話とはあまり関係ない話ではありますが、三項演算子 ” ? : ” の優先順位は、CやC系の言語やPerlでは「右結合」なのですが、PHPでは「左結合」なの、それを知らないとネストした三項演算子でハマる可能性があるので気をつけたほうがよいです。というかPHPでネストした三項演算子は(たとえカッコを付けて順序を明示しても)書かないほうがいいとすら私は思っています。C系の言語の普通の常識で読めないから。

単項演算子は二項演算子より高い優先順位を持っているケースがほとんどなので、少なくとも私自身は、文法上不必要な空白を入れて離す書き方をするのはケースバイケースかなと思っている派です。Perlでも、組み込み関数に見えるものが実際は単項演算子やそれと同等の優先順位だったりする場合があって、その場合には優先順位が高くなります。たとえば ref とか scalar とか。JavaScriptでもtypeofなどがこれに当たるのかな。これは英単語のキーワードなので、変数と空白一つを挟んで書く必要があったり、そのほうが自然な場合がありますが(Perlだとシジルがあるからくっつけて書けてしまう場合もあるかもしれないけど、なんか気持ち悪い)、あまり詳しくない人とソースコードを共有する場合には、明示的にカッコを付けて書くほうがよいかもしれません。

よくあるのは、否定演算子 “!” が変数とくっついていると見づらいから離す書き方。演算子の性質上、離して書いてもあまり大勢に影響がない場合が多いのですが、結合力を惑わさないように、私は否定演算子 “!” と変数を離して書かない派です。見づらいという意見には確かに同意しています。特にPerlのようにシジルがつく場合はそう。各エディタのシンタックスハイライトでどうにかしてほしいものですね。

まとめ

というわけで “=” の両端に空白を入れることの大きな意味は、代入演算子 “=” が大抵のプログラム言語の二項演算子としての優先順位でも最下位かかなり最下位に近いところにいるから、という、持論のお話でした。

たぶんプログラマの数だけ意見あるところではあると思いますが、あくまで一人のプログラマーの一つの持論ということで軽く考えていただければと思います。もし参考になったら幸いです。

Perl入学式 #1 に参加してきました #Perl入学式

おがた (@xtetsuji) です。

2014年4月26日(土曜日)に行われた「Perl入学式in東京#1」に参加してきました。サポーターや講師側での参加です。

カレンダーを見ると、昨年度(2013年度)の「in東京#2」からサポーターとして参加していたのですが、今まで参加したというブログ記事を書いていなかったなーと思って、ちょっとでも感想を書いてみようと思った次第です。

昨年度のPerl入学式もサポーターとしてだいたい毎回参加していて、そこで得られた様々な人との貴重な出会いや知見などもまとめたいと思ってはいるのですが、それはまたの機会にします。長くなりそうだから。昨年度は本当に貴重な体験でした。

今回はサポーターだけでなく、より運営側に近い側で作業させてもらい、資料作成や後半の講義まで行いました。特に資料作成は想像以上に大変で、これを前2年間、校長を含む数人だけで回していたことを考えると、もっと運営側にコミットして助けていかないとなーと思った次第です。

Perl入学式の歴史

適当なことを書いているかもしれませんが、だいたいこんな感じです。

  • 2012年度に大阪で @__papix__ 校長がプログラミング初心者向け勉強会として開始。当時は毎月合計12回のペースだったらしい。
  • 2013年度は大阪の他に東京でも行われる。毎月から隔月合計6回のペースになり、in東京では各月の次月は同じ内容を話す「補講」が行われて、用事で来られない人向けの体制となった。当時大学院生である @__papix__ 校長が自腹で毎月大阪から上京していたというのは結構驚かれる話。
  • 2014年度はJPAの支援も受けつつ、福岡でも開催され、東京・大阪・福岡という三大都市での開催となる。この最初の「Perl入学式 in東京 #1」が先日2014年4月26日にありました。

そういえば今回、Perl入学式とは…といった部分のスライドも自分が書いたんでした。途中からサポーターで入った自分が書いてもいいものかなと思いながら書きましたが、校長チェックは通ったので、大きく間違ったことは書いていなかったと思います。

Perl入学式の体制

前年度までを踏襲して、今年度も以下のような感じになっています。

  • 講師:in東京であれば、だいたい @__papix__ 「校長」。他の都市は別途校長に依頼された人が担当する
  • 運営:グループウェア上で開催日時や会場の議論をしたり、資料を書いたりする人達
  • サポーター:当日会場内をまわって分からない人の個別サポートをする人達
  • 受講生:来てくださる方々

講師も運営もサポーターも有志で結成されていて、原則的に手弁当でやっています。また、パソコンを持ち込んでもらう必要がありますが、受講者(生徒)の皆さんの参加費は無料です(懇親会費は有料です)。パソコンを持ち込んでもらうのは、パソコンの貸出の手間やコストというよりも、学習環境を持ち帰って自習してもらいたいという考えのほうが先立っています。

運営・サポーターは何を目的に毎月手弁当で無料勉強会をやっているのか疑問に思う人もいるかもしれませんが、だいたいの人達がPerlコミュニティの促進だったり、Perlプログラマの育成といったことに大きな興味を持って集まっているわけです。とかくPerlは古いと揶揄されることも多い中、学びやすい言語であることも確かで、そういうことを伝えていきつつ、Perlの雇用促進までつなげていければいいなという感じ。これは私が思っていることで、運営・サポーターの人によって若干の考え方の違いはあるかもしれないけど、だいたい似たようなものでしょう。

今回私が担当したこと

前述ですが、今回は前年度のサポーター以上に踏み込んだ活動をさせてもらいました

  • 資料作成:後半部分を担当
  • 講義:後半部分の一部を担当
  • サポーター

後半の資料、半分くらいは昨年の資料をベースに2014年版として書きなおしただけなのですが、新たに書き起こす部分が校長から指示されていて、それを書き過ぎないように気をつけながら書いたものの、結構書きすぎて当日(4月26日)は30分オーバーしてしまったという感じです。

時間は常に気にしていたのですが、私の壇上でトークする経験って長くてせいぜい20分程度で、2時間の長丁場の時間見積もりができていなかったのは反省点ですね。

当日のお話

例年、1回目は環境構築から入ります。後々システムPerlを汚さないようにユーザPerlを作ることと、そのためにMac/Linuxでビルド環境を用意することを教えます。

だいたい人の集まりを待つので、13時を少し過ぎたあたりから開始。

自分は前年度の1回目を知らなかったのですが(顔を出し始めたのは2回目から)、これがなかなか大変。一歩間違えると、生徒さんの私物のパソコンの環境を壊したりしかねないのでハラハラものです。

MavericksからのMacは環境構築が楽なほうですが、それでもみんなが一斉にXcodeのダウンロードをしたらネットワークが詰まるということで、ここは次回の補講での課題となりました。

Windowsの人にLinux環境を作ってもらうという部分、今年度はUSBメモリによるブートできるUbuntuを使った方法も紹介したのですが、前年度同様にVMwareを使った方法も一緒に解説して、サポートコストが倍近くになったのは大変でした。結局、USBメモリによるブートの方法は、慣れていなくて会場で対応が疎かになってしまったのは反省点でした。

会場であるガイアックスさんの会場が先日最新鋭になったことで、環境構築の部分では、最初は1つの内容を投影していた2つのスクリーンを突然分けて、Mac編とLinux/Windows編で別進行となって、Mac側は急遽@tsucchiさんが壇上に立って講義をするという校長の無茶ぶりが面白かったです。そのために校長は、Macの人とLinux/WIndowsの人を最初から会場の真ん中で二分して座らせていたというのには、会場の設備を最大限に利用した良いアイデアだなぁと思った次第です。

2時間かけて環境構築を完了。15時からの後半は、校長が冒頭に話をしたあとは私のターンです。

とはいえ、スライドのビルドの方法を聴いていなかったのは段取りが悪かったと反省しています。Perl入学式用に魔改造(?)されたImpress.jsとは…。これも補講までになるべくプレーンな環境に近づけたいなと思いました。

私の書いた資料で私が壇上に立って、Perlの歴史やPerlでできること、そしてワンライナーからエディタを立ち上げて最初のプログラムを書くところまで話したのですが、資料の盛り込み過ぎだったり、講義の段取りが悪かったりで、結局30分オーバーとなってしまいました。色々反省点多い…。

運営・サポーターの人達と、懇親会に参加するために残った受講生の皆さんと会場の片付けをして、18時前に会場を後にしました。

懇親会

五反田のガイアックスさんでPerl入学式を開催したときのお約束 「居酒屋北海道 五反田店」。今回もそこでした。

色々と大変だった分、ビールがうまい。そして居酒屋北海道、食事もうまい。

今回初参加の受講生の方々や、いつものサポーターの方々と歓談をして、22時前には解散しました。

参考

「校長」として日々手弁当で講師をしている@__papix__さん、そしてJPAの理事として2014年度からPerl入学式の事業化に向けて尽力している@yusukebeさんが参加されている回のポッドキャスト「職質テックトーク」(by @moznion)を聴いてみると、Perl入学式についての思い、そしてPerlの様々な話題を聴くことができます。時間があればどうぞ。

今後の開催日程など

今回と同じ内容を行う「in東京 #1 補講」は、5月最終土曜日である2014年5月31日の予定です。また、in福岡#1が2014年5月10日、in大阪#1が2014年5月17日の開催となっています。

開催日程や詳細は公式ウェブサイトやTwitter @Perl_Entranceでアナウンスされるので、興味のある方はぜひチェックしてみてください。

Perlや他のプログラム言語、それを使ったテキスト処理やウェブ開発に興味があるけれど、プログラム言語を学ぶ取っ掛かりが見つからなくて…といった皆さんの参加を、運営・サポーター一同、お待ちしています。

MacBookやLinuxノートパソコンのバッテリー残量をウォッチしてImKayacでiPhoneに通知を送るPerlプログラムを作ったら地味に便利だった

仕事と個人で合計MacBook Air 3台に囲まれている おがた (@xtetsuji) です。

最近は複数のMacBook Airに囲まれている生活をしているのですが、現状バッテリーは自宅も会社も一つしかコンセントに繋いでいないという状況でなんとかなっています。ひとえにMacBook Airのバッテリーが持つから。一方の充電が完了したら、もう一方に充電ケーブルをつなぎ替えるだけで良いんです。当然ながら製品購入時に付いてくるものや予備で買ったものも含めて、ACアダプタは複数持ってはいますが、電源を挿す口が近くに足りていなかったり、会社に予備を置くのが面倒とか、そんな背景があります。

とはいえズボラな性格なので、こっちのバッテリーに充電してそのまま放置していたら、あっちのバッテリー残量がピンチということも結構あります。そこでMacBook Airのバッテリー残量を定期的に監視して、必要に応じて手元のiPhoneにプッシュ通知してくれるプログラムが欲しいと思って、思うままにサッと書いてみました。それが思いのほか便利だったので、せっかくなのでブログでご紹介してみようと思って記事を書いてみた次第です。

必要なのはPerlです。できればシステムPerlではなくユーザPerlが良いでしょう。モジュールはコアモジュール以外ではAnyEvent、Cocoa::Growl (存在する場合) 、WebService::ImKayac::Simple に依存します。Cocoa::GrowlはMacにしか対応していないし、WebService::ImKayac::Simple は最近登場したモジュールなので、Debian/Ubuntu のパッケージにもなっていません。そういうことを考えるとやはりユーザPerlを作る必要がありますが、そのあたりはPerlbrewやplenvの記事に譲りたいと思います。

やっていること自体は単純なので、最近のPerlのコアのみでも、もしくはシェルスクリプトでも頑張れば書くことはできると思います。

デーモン化とかは全然考えていないプログラムで、”&” でバックグラウンドに回して使う系のコマンドです。個人ユースのプログラムは面倒なので無闇にデーモン化しないというのが個人的な趣味なだけです。デーモン化が好きな方はApp::Daemonなどを使って改造していただくか、nohup や disown などを使ってください。詳細はプログラム内のPODを見てみてください。

標準ではホームディレクトリに WebService::ImKayac::Simple の設定ファイルが “.imkayac.yml” という名前で存在する必要があります。当然ながらiPhoneでImKayacのアプリをダウンロードして登録している必要があります。設定ファイルの書式は WebService::ImKayac::Simple のドキュメントを参考にして下さい。

上記のようなお膳立てでバックグランドジョブとして起動すると、バッテリー残量を10分おきにウォッチして、20% 50% 80% を上回ったり下回ったりした場合にImKayacで通知を送信します。また現在のバージョンでは、Cocoa::GrowlがインストールされていればGrowlでの通知も行い、要らないかもしれませんがお節介にも標準出力にも出してくれます。また充電が100%になったときに満充電になったこともお知らせしてくれます。監視のインターバルやバッテリー残量のしきい値の数々は、コマンドライン引数で変更可能です。詳細はプログラム内ドキュメントを参照してください。

こんな感じで通知が来ます。便利。

battery-watchdの通知の様子

適切なGitHubのリポジトリがあれば入れようかと思ったんですが、どこに入れてよいかわからない書き捨てプログラムとなってしまったので、とりあえず現状のものを $VERSION = “0.01” としてGistに貼りました。

Linuxラップトップでも acpi コマンドでバッテリー残量を取得することが可能なので、それにも対応してみたつもりですが、現状Linuxラップトップが手元になかったので、この部分のコードはテストしていません。レポートお待ちしています。

まだ作りたてなので、色々と不具合のようなものがあるでしょう。レポートお待ちしています。

適切なリポジトリやパッケージ化の続報があれば、随時追記しています。要望ありましたら、Twitter @xtetsuji などにお気軽にお知らせください。

#!/usr/bin/env perl
# xtetsuji by 2014/04/19

our $VERSION = "0.01";

use strict;
use warnings;
use utf8;

use AnyEvent;
use Config;
#use Cocoa::Growl ':all';
use File::Basename qw(basename);
use Getopt::Long ();
use WebService::ImKayac::Simple;

use constant HAVE_COCOA_GROWL => eval {
    require Cocoa::Growl;
    import  Cocoa::Growl ':all';
    1;
};

if ( !HAVE_COCOA_GROWL ) {
    # Cocoa::Growl の無い環境ではとりあえず何もしないコマンドとして定義しておく
    *growl_register = sub {};
    *growl_notify   = sub {};
}

use constant APPLICATION_NAME => basename($0);
use constant GRAPH_DOWN       => -1;
use constant GRAPH_UP         =>  1;
use constant GRAPH_RELAX      =>  0;
use constant OSNAME           => $Config{osname};

my $p = Getopt::Long::Parser->new(
    config => [qw(posix_default no_ignore_case auto_help)]
);
$p->getoptions(
    'watch-percents=s'        => \my $watch_percents,
    'imkayac-config=s'        => \my $imkayac_config,
    'interval=i'              => \my $interval,
);

our $DEFAULT_INTERVAL = 600;

growl_register(
    app => APPLICATION_NAME,
    #icon => '',
    notifications => [qw/info/],
);

my $IMKAYAC_CONFIG_FILE = $imkayac_config || "$ENV{HOME}/.imkayac.yml";

if ( !-f $IMKAYAC_CONFIG_FILE ) {
    die qq(ImKayac config file "$IMKAYAC_CONFIG_FILE" is not found\n);
}

binmode STDOUT, ':utf8';

my @watch_percents = (20, 50, 80);

if ( $watch_percents ) {
    @watch_percents = split /,/, $watch_percents;
    if ( grep { !/^\d+$/ } @watch_percents ) {
        die "watch-percent option specify comma separated digits.\n";
    }
}

#chomp(my $hostname = `hostname`);
my $hostname = $Config{myhostname};

my $previous_percent = get_remaining(); # initialize

my $cv = AnyEvent->condvar;

my $im = WebService::ImKayac::Simple->new($IMKAYAC_CONFIG_FILE);

my $notify_callback = sub {
    my $response = shift;
    print $response . "\n"; # DEBUG?
    growl_notify(
        name => 'info',
        title => APPLICATION_NAME,
        description => $response,
    );
    $im->send(APPLICATION_NAME . ": " . $response . " ($hostname)"); # ok either flagged utf-8 or not.
};

my $timer = AnyEvent->timer(
    after    => 10,
    interval => $interval || $DEFAULT_INTERVAL,
    cb       => sub {
        my $current_percent = get_remaining();
        my $response = '';
        # process...
        for my $key (@watch_percents) {
            if ( my $res = graph_direction( $previous_percent => $current_percent, $key ) ) {
                if ( $res == GRAPH_UP ) {
                    $response = "${key}% を上回りました。現在${current_percent}%です。";
                }
                elsif ( $res == GRAPH_DOWN ) {
                    $response = "${key}% を下回りました。現在${current_percent}%です。";
                }
            }
        }
        if ( $previous_percent != 100 && $current_percent == 100 ) {
            $response = "満充電されました。";
        }

        if ( $response ) {
            $notify_callback->($response);
        }

        # reinitialize
        $previous_percent = $current_percent;
    },
);

$cv->recv();

sub get_remaining {
    if ( OSNAME eq 'darwin' ) {
        return get_remaining_mac()
    } elsif ( OSNAME eq 'linux' ) {
        return get_remaining_linux();
    } else {
        die "Unsupported your architecture yet\nPlease contact to \@xtetsuji by Twitter if you want to use this program!\n";
    }
}

sub get_remaining_mac {
    my $pmset = `pmset -g ps`;
    my ($percent) = $pmset =~ /(\d+)%; /;
    return $percent;
}

# 追加してみたけどまだ試していない
sub get_remaining_linux {
    my $acpi = `acpi -b`;
    my ($percent) = $acpi =~ /(\d+)%, /;
    return $percent;
}
# see: http://polamjag.hatenablog.jp/entry/2013/10/23/125843

sub graph_direction {
    my ($prev, $cur, $thr) = @_;
    if ( grep { !/^\d+$/ } ($prev, $cur, $thr)  ) {
        require Carp;
        Carp::croak "graph_direction error. ($prev, $cur, $thr)";
    }
    if ( $cur < $thr && $thr < $prev ) {
        return GRAPH_DOWN;
    }
    elsif ( $prev < $thr && $thr < $cur ) {
        return GRAPH_UP;
    }
    else {
        return GRAPH_RELAX;
    }
}

=pod

=head1 NAME

battery-watchd - battery watcher and observer for Mac and Linux laptop

=head1 SYNOPSIS

 battery-watchd &

=head1 OPTIONS

=head2 --watch-percents

 battery-watchd --watch-percents=5,10,15,20

Specify watch percents separated by comma.

=head2 --imkayac-config

 battery-watchd --imkayac-config=/path/to/config.yml

Specify your ImKayac config file path.

Default path is "$ENV{HOME}/.imkayac.yml".

This file format is YAML format. See below CONFIG FILE SYNTAX section.

=head2 --interval

 battery-watchd --interval=600

Specify watching interval seconds.

Default may be 600 seconds. You confirm it by following command.

 grep DEFAULT_INTERAVAL `which battery-watched`

=head1 CONFIG FILE SYNTAX

You can give a battery state by ImKayac.
So you have to tell this program ImKayac setting.
This program gives ImKayac setting file of YAML file.
It syntax is same as L<WebService::ImKayac::Simle>'s format.

Setting file's path is below "--imkayac-config" section.

=head1 DEPENDENCIES

L<AnyEvent>,
L<Cocoa::Growl>,
L<WebService::ImKayac::Simple>,
and some Perl5 core modules.

=head1 COPYRIGHT AND LICENSE

Copyright (C) 2014 by OGATA Tetsuji

This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.

=cut

WWW::PushoverをCPANで公開しました

おがた (@xtetsuji / PAUSE: OGATA) です。

WWW::Pushover というモジュールを CPAN で公開しました。2014年4月15日現在のバージョンは、初期バージョンの0.01です。Mac OS X のクリップボード監視モジュールAnyEvent::Mac::Pasteboard以降、久々にCPANにモジュールをアップロードしました。

これはPushoverという海外のスマートフォン向けプッシュ通知サービスへのインターフェースです。もともとWebService::Pushoverというモジュールがあったのですが、重量級のモジュールをいくつも使っていたのと、PushoverにあるAPIでサポートしていないAPIが一部あったので、Perl5.14以降のコアモジュールだけで事足りるようなものを作りたくて、ずいぶん以前に作ったものをアップロードした次第です。

今回は Minilla の minil コマンドでひな形を作って作業していたのですが、念のためと FAKE_RELEASE=1 minil release をした後からおかしな状況になってしまい、結局 minil build したものを PAUSE の管理画面からアップロードするなど、混乱してしまいました。そのせいか、2014年4月15日時点でsearch.cpan.org/~ogata/metacpan.org/author/OGATA の一覧に WWW::Pushover が出てこないとか色々あってどうしたものかなと思ってはいるのですが、ひとまず cpanm WWW::Pushover と打つことでインストールはできるようです。このあたりは、次にPerlの勉強会に行った時にでもCPAN Authorの方に質問してみようかと思っています。頼れる人がいるの大事。

CPANにアップロードしたいものの色々な理由で踏ん切りがつかずGitHub止まりになっているモジュールはいくつもあるのですが、今後多くの人に有用なものは少しずつCPANにアップロードしていきたいと考えています。まだまだCPANへのアップロードは不慣れな点が多いのは、場数を踏んで解消していきたいところです。

英語ですが、ドキュメントにも書いてある通りいくつかの注意点があります。

  • Pushoverのスマートフォンアプリは、買い切りの有料アプリ
  • WWW::Pushoverを使うためには現状ログインをして自分専用の「アプリ」を作ってAPIキーを発行する必要がある

後者に関しては利用者の利便性のためにAPIキーを同梱しようか結構悩んだのですが、現時点では同梱していません。そのあたりはドキュメントにも書いてある通りです。

「日本だとImKayacがあるだろう」という意見もあるのですが、さすが有料のPushoverは高機能で、例えば以下の点がImKayacより優れているポイントでしょう。

  • Pushoverは通知のサウンドを選べる
  • Pushoverは通知の優先度を選べる
  • PushoverにはiOS版だけでなくAndroid版もあるし、iPadにもユニバーサルアプリ対応している
  • …その他色々

ImKayacは無料です(有料版もあります)が、ちょっと通知ごとにサウンドを替えてみようかなとか、AndroidユーザでImKayacを使えなかったユーザへの、もう一つの選択肢になるのではないでしょうか。

ちなみにAndroidには他にもプッシュ通知系アプリもあってAPI公開されているものもあるので、そのAPIラッパーも暇があったら書いてみたいと思っています。

最近の私とmod_perlとの関わり

おがた (@xtetsuji) です。

以前からこのブログにも書いていますが、2011年からコミュニティ活動を始めて、各地のPerlの勉強会や、2012年と2013年のYAPC::Asia Tokyoでmod_perlのトークを頻繁にしてきたからか、今も「mod_perlといえば@xtetsuji」とか「モドパール神」とかたまに言われます。恐れ多い。

新年度になって振り返りの余裕もできたので、最近の私とmod_perlとの関わりを書いてみたいと思っています。

今の業務でmod_perlは全然使っていないし使う予定もない

1月末に退職して2月初めに転職したことをご報告したのですが、現在の職場はPerlの会社ではあるものの、mod_perlは使っていません。それなのに、よく採用していただけたなと、ありがたい限りです。

前職でも案件が入れば必要に応じて書くという感じだったので、年がら年中mod_perlのコードを書いていたというわけではありませんでしたが、今の会社では入社から今まで2ヶ月の間、mod_perlとの接点は当然ながら全くありません。

以前のエントリにも書きましたが、数社面接を受けて、mod_perlを使っている会社から不採用で、mod_perlを使っていない会社から内定をもらうという事実が人生のネタみたいなものでした。

今の職場で配属された部署では、以前からの案件ではCGI(SpeedyCGI)上に乗った独自フレームワーク(OSSにもなっているけど、ほぼほぼ自社フレームワーク)。新しい案件ではモダンにNginxをリバースプロキシ役として前面に立たせて、Plack+Starletに載せたAmon2改造フレームワークを使って開発しています。

エンジニアの上司や偉い人もしばしば「mod_perlは使う予定もないからねー」と言っています。適材適所なので、使わせてくれと言ったことはないし、現状うまくいっているので良い感じなんですが、なんか私がmod_perlの人と思われているようで、mod_perlの話が出るとそんなことを言われます。

個人的な開発環境ではApacheとmod_perlは現役

個人ではというと、借りているVPS(さくらのVPS)では、ウェブサーバはApache2.2+mod_perl2という構成で動かしていて、何か込み入ったことをやりたいと思ったときには、時々mod_perlハンドラを書いたりしています。

OAuthを使ったサービスを作るためのスクラッチはmod_perlハンドラだと面倒だったので、Mojolicious::Liteを使ったりしています(面倒だったのでApacheのmod_proxyでリバースプロキシさせました)。会社がAmon2寄りとはいえ、Mojoliciousも使ったりしているのは、Mojoliciousの可搬性を個人的に気に入っているからです。

自宅サーバでは今もApache1.3が動作しています。過去の環境を意図的に残す意味で、わざとやっている部分もあるんですが、そこでmod_perl1のハンドラを書いたりすることもあります。

実際に個人的に作りたいサービスもあるのですが、MojoliciousとAmon2を作る対象物に応じて分けて使って、小さいものはmod_perl (PlackのPlack::Handler::Apache2) で動かしたいと考えています。なぜって、ログを見るのが簡単だから。

先日業務で、NginxからPlack+Starletへリバースプロキシして、plackupはSupervisorで起動するっていうのをやったんですが、もうデバッグ時にログを見るのが大変でした。何かあったときに、Nginxのログ、Plackのログ、Supervisorのログがあって、どれを見ていいものかとか、なかなか戸惑いました。慣れの問題だったり、あとアプリケーション仕様のURL設計が難儀だった(これは私が設計したものではないです)ってのもあるんですが、ミドルウェアが増えるとログも増えて大変だなーと思った次第です。個人レベルで小さなウェブサービスを作るのであれば、ミドルウェアを不必要に・扱いきれないほど多くする必要はないかなと感じています。Apacheなら堅牢だし。

前職でmod_perlを突き詰めていた理由

前職でmod_perlを劇推ししていたのは、自分がmod_perlが好きという他にも、インフラ部署がほとんどのミドルウェアの使用を許可しないという理由があったからでした。それは退職エントリにも書いたのですが、彼らの言い分は「ミドルウェアが多くなればなるほど監視対象が増えて自分らの仕事が増える」ということらしい。まぁごもっともではあるのですが、memcachedとか既に市民権を得ているようなミドルウェアまで危険視されて入れさせてくれなかったのは、自分のキャリア的に多様な経験を積む機会を奪われたとしか言いようがありません。結局memcachedのようなものもmod_perlで書きました。それならOK!

世間でmod_perlを必要としている人もいる

先日PerlBeginners#12に参加したときに、「会社でインフラを担当している」という方からmod_perlの質問を受けました。やはりmod_perlにもまだ一定の需要はあるんだと感じました。

私だって転職活動時にmod_perlを使っている会社を聞きつけたりもしたくらいですから、好きか嫌いかは別として、使っている会社や使おうとしている会社があるというのはわかります。

前述の通り「ミドルウェアが集約されて簡潔な構成になる」「監視対象のデーモンや永続プロセスの類が減る」といったことをメリットとして捉えてApache+mod_perl構成を取る会社もあるだろうし、そういう選択もあるんじゃないかなーと思います。静的ファイルはフロントエンドに立たせたNginxが出力して、動的な画面はバックエンドのPlackが…といった構成は、中小規模の開発(漠然としていますが)であれば、それほど求められないと思います。古いもの=悪、新しいもの=善、の構図は全ての文脈で当てはまるとは言えないでしょう。

私にできることはmod_perlの活きた知識を残すこと

幸か不幸か、mod_perlの活きた知識だけは頭の中にたまっているので、そういったmod_perlをこれから使っていく人のために情報を出していったりコンサルタントをしていったりしたいと考えています。

Twitterアカウント @mod_perl_info がありますが、あまり活動をしていません…。とりあえずその辺りから活動を初めて、mod_perl関連の文章の翻訳などをしていければと思っています。英語が得意なわけではないのですが、mod_perl自体の知識があるので、翻訳兼監訳的な立ち位置で翻訳作業ができるかなと考えています。とはいえ今は時間がない。

なんとなくまとめ

前職で10年間Perlをやっていた半分以上はApacheのmod_perlを突き詰めて研究して、それ以外のサーバやミドルウェアはほとんど(少なくとも)業務では触りませんでした。というか最後のほうは触らせてすらくれませんでした。

なので「Perl歴10年くらいです」といっても、mod_perl以外の知識が全然無いというある種面白いPerlプログラマーなのですが、そういった私を重宝してくれるPerlの勉強会や職場があることに本当に感謝しています。

今の環境で学んでいる「新しいこと」も伸ばしていきつつ、それもまたブログやトークの形などでフィードバックしていければと思っています。それと同時に、mod_perlの知識も「生き証人」として、後世の人に分かりやすい形で残していければいいなと、強く願って実行に移そうとしています。

こんな私に要望などがありましたら、遠慮無くどんどんリクエストしてくださると嬉しいです。

PerlBeginners#12 に参加してきました #perlbeginners

おがた (@xtetsuji) です。

2014年3月21日に行われた「PerlBeginners#12」に参加してきました。

今回は2月に転職して最初のPerlBeginnersだったのですが、今の会社の同僚の方とインターンの方々と一緒に行くという感じでした。

毎回人が足りないといった理由でトークしたりしていているのですが、今回はトークする人も当初から多かったし、環境が変わってトークする資料作りする余裕もなかったということもあって、トークはしないで聴く側に回ることにしました。

場所は水天宮駅近くの「日本橋公会堂」

今回はUstream無し

とはいえ前回に引き続きUstream配信をしようと思っていたのですが、当日の会場が建物の内側にある会議室で全然電波が入らなかったこともあって、Ustreamは断念。

当日のタイムテーブル

当日のタイムテーブルは結果的にこんな感じになりました。

ビギナーズという名前に相応しい程度の難易度が維持できているのも特徴でしょう。

詳細は割愛しますが、少し撮影した写真から。今回は iPhone 5 をテザリング用に入口近くに置いておいたので、Nexus 5での撮影です。Nexus 5を撮影用に使ったのは初めてだったのですが、ちょっと iPhone 5 より画質が悪いなって感じました。

パールビジナーズ?

まさかの「パールビジナーズ」。

PBパールビジナーズ

予約の際に聞き間違えたとかでしょうか。

基調講演 by @dokechin

基調講演の冒頭より、@dokechin さん。この写真だと白バックで飛んでしまって見えないですが、スライドのキャラクターは娘に書いてもらったとのこと。資料公開に期待しましょう。

PB基調講演の様子

もともと、Mojoliciousを使って色々なサービスを作って公開している@dokechinさん。「テストではまったお話」は Test::More の is 関数の内部で悩んだという話など。

この辺りのブログ記事が発端でしょう。

このあとのビギナーズセッションでもNYTProfの読み方について質問したりといったやりとりが続きました。

ビギナーズセッションより

ビギナーズセッションの中で、仕事で主にインフラを担当されているという方からmod_perlについての質問が出て、なんか会場の雰囲気から私が回答する感じになって、少し語らせてもらいました。

最近のmod_perlはApacheやPerlの最新版に対応していない部分はあるのですが、Perlの後方互換性の高さから、特に理由がなければ最新版の一つ前を使うという方針でも問題無いのではないかといった話。また、RHEL7ではApache2.4採用の兼ね合いから、Apache2.4にまだ対応していないmod_perl2がコアモジュールから排除されてしまったことへの注意点などをお話させていただきました。ただ、mod_perlの開発は他の mod_{プログラミング言語} の開発と比べても昔も今も活発に行われているほうなので、心配ある方はmod_perlのSubversion http24開発ブランチをウォッチしたりしてみると良いかなと思います。

mod_perl で何か質問がありましたら、@xtetsuji にお気軽に質問ください。応えられる範囲でお答えします。

YAPCでやりますと言ったものの出来ていないmod_perl系の活動もそろそろやらんきゃなぁと思った次第です。あと、自分が自己満足でネットに書いた記事が実際に読まれて参考にされているということに少し驚きました。今は少し私生活に余裕が無い感じですが、これから少しずつ自分が持っている情報を出していければと思った次第です。

@maka2_donzoko さんがいらしていて、「Acme大全2013」の宣伝をしていました。あの書籍は良書なので、1500円のもとは取れると思います。

LT

LTは @__papix__ さん、@tsucchi さん、そして主宰の @ytnobody さん、最後に飛び入りで @magnolia_k_ さんがお話されました。コード無しの精神論(スピリチュアルトーク)から、コードを交えた解説まで、バランスが良かった印象でした。

@__papix__ さんが語っていた話は、コミュニティやオープンに活動しようと思いつつできない人が恐れていることが杞憂であることを突いた、良い指摘だったと思います。ネットの向こうにいるプロのプログラマの人達は、ほぼみんな業界を良くしていこうという優しい人達ばかりです。変なコードを公開しても優しく指摘してくれたり直してくれたりすることが多いので、それだけでも勉強になると言って良いでしょう。

@tsucchi さんのお話では、異常な努力のもとに成り立っているモジュールの紹介がありましたが、一時期誰もが使ったCGI.pmの中身の異常さは語り尽くせないものがありますね。また、SQLなどのパーサ系のバッドノウハウ満載モジュールも、中身を見てその異常な努力に驚愕することがあったり…。そういう異常な努力の上に出来たモジュールを使わせてもらうことは良いとしても、自分自身が異常な努力をすることは、時間的にも健康的にも良くないなと感じました。時には自分自身が率先して異常な努力をしないといけないことも人生の中にありますが、そういうときのために普段は体力を温存して普通の勉強をしてレベルアップしていったほうがいいと思います。

以下のまとめが的を射ているなと思いました。どうしても難しい処理にたいして難しいコードを書いてしまうときはきっとあるけど、簡単な処理を難しく書くことはやめてほいたほうがよい。

  • 難しい処理をしているときに難しいコードを書いてしまうのはしょうがない
  • 簡単な処理を難しく書いてしまっていないか

メールの仕様も深く立ち入っていくと尋常ならざる複雑さになっていくといった話の中で触れられたYAPC::Asia Tokyo 2011 での RJBS氏によるトークは以下です。

主宰でもある @ytnobody さんのお話では「べからず」のお話。氏が今まで指摘されてきた色々な「クールではない」点について一つずつ解説したお話でした。これも時代によって変わる価値観ではありますが、一頃に比べてだいぶ落ち着いたPerl界隈では、今もしばらくはこの価値観で行って問題はないと思います。

こういうプロ同士の実践の中から題材に上がる情報が生で聴けるのも、PerlBeginnersのような勉強会の魅力ですね。

飛び入りLTをした @magnolia_k_ さん、brewっぽいビルドツールをCPANで公開したりといったアクティブな方。今回も、自分が使ってバグを踏んだモジュールの作者に、英語で意見を送ったりパッチを送ったりということを臆することなくやっても意外と大丈夫なんだよといったことを語って私を含めた聴衆を勇気づけていました。良い話。

懇親会

木曜日とはいえ、次の日は春分の日で祭日だったため、期せずして「週末」となってしまい、ただでさえ居酒屋が少ない水天宮駅周辺で居酒屋難民になってしまいました。

とはいえ、多少さまよって店を見つけて入ることができました。3500円で2時間飲み食い放題はお得でした。

確か8人集まりました。懇親会でディープな話が聴けるのも、こういった勉強会の醍醐味。

各人の最近の業務やPerlとの関わりとか、次回に向けてどうするかとか、色々な話で盛り上がりました。

次回は5月あたりになりそうな予感。PerlBeginners#13も楽しみです。

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

おがた (@xtetsuji) です。

2014年2月21日に行われた Yokohama.pm#10 に参加してきました。

Yokohama.pm#10 の看板

参加といっても、今回は完全に聴講する側で、しかも少し遅れて会場入りしたのですが、なかなか楽しめるイベントでした。

 

PRONTOでのYokohama.pm#10の風景

ビール片手に立食パーティーなYokohama.pm#10

というわけで結局、終始メモを取ることができなかったのですが、実際に発表が行われている場所で雰囲気を感じ取ったり、来ていた知り合いの方々と懇親したり、飲んだり食べたりができたり、色々と有意義な勉強会となりました。

私の2013年12月の入院の心配をしてくれる人がいたりと、色々と挨拶してくださる方も結構いて、本当ありがたい限りです。

本トークも色々と参考になりましたが、LTのトークの内容も良かったです。後日の資料公開が期待されます。

本来であれば自分のメモをまとめたものをブログ記事に載せているのですが、今回はメモが無いので、雰囲気だけ伝える感じ。その代わり、Togetterに参加者の関連ツイートをまとめました。

都心から来ている人も結構多くて「横浜遠い」という話も結構聞こえたのですが、Yokohama.pmですからまぁ横浜ですよね。それでも昔に比べれば副都心線でかなりアクセスが良くなったので、また開催されるならぜひ行きたいです。今回は1年ぶりくらいの開催だったようですが、今後は数カ月おきに開催していくという話なので、期待したいです。

日本語のperldocを検索する便利なショートカット

おがた (@xtetsuji) です。

Perlの良い点は、コンソールで perldoc コマンドを使うことで、オフラインでも迅速に組み込み関数やモジュールのドキュメントを見ることができることです。そしてそこに書いてあるSYNOPSISを真似ればとりあえずモジュールが使えるという点。この仕組みはPerlの長い歴史の中でずっと続いている良い点だと思います。

でも出てくるドキュメントはたいてい英語なんですよね。Perlを10年書いてきてPerlのドキュメントの英語に慣れたとはいえ、時々は日本語で読みたいもの。PHPやRubyはどうなんだろうと調べてみると、だいたいはウェブ上に日本語ドキュメントがあって、それを閲覧する形のようです。

Perlにもperldoc.jpという日本語perldocが読めるサイトがあります。

このサイト、パスの最初に組み込み関数やプラグマやモジュール名を入れると、それが存在すれば適切なパスにリダイレクトをしてくれるという嬉しい機能があります。

FirefoxやGoogle Chromeなどのアドレスバーや検索ボックス(オムニボックス)でURLにキーワードを渡して検索ができる機能があるブラウザの場合、これを利用してperldoc.jpのドキュメントを素早く検索することができます。

Google Chromeの場合はアドレスバー(オムニボックス)に chrome://settings/search と入力して設定画面を開き「検索エンジンの管理」というボタンを押します。右上の設定検索を利用すると楽でしょう。

この次に一番下にある「新しい検索エンジンを追加」で

  • 新しい検索エンジンを追加: perldoc.jp
  • キーワード: perldocjp (ここはお好きなキーワードで)
  • 検索キーワードの代わりに…: http://perldoc.jp/%s

と設定して追加をします。%s 部分に検索キーワードが入るという感じです。これはFirefoxでも同様です。

こうすることで、検索エンジンとして設定したキーワードをアドレスバー(オムニボックス)に入れた後にスペースかタブを押すと、検索キーワードの入力を促されます。例えば「LWP::UserAgent」と入力してLWP::UserAgentの日本語ドキュメントが表示されたら成功です。

perldoc.jpが単純な仕組みで検索結果を表示してくれるので、コマンドラインアプリケーションからURLを構築して、CUIやGUIのブラウザで検索結果を表示するということも簡単にできるでしょう。色々と応用が可能です。

これで便利な日本語perldocライフが過ごせますね。

DebianでPerlのDB_Fileモジュールのインストールに失敗した時の対処法

おがた (@xtetsuji) です。

cpanmでLiBotを入れようとしたらDB_Fileモジュールが入らないとエラーが出たので、~/.cpanm/build.log をみたら「db.hがない」といったエラーが出ていました。

サーバはDebianだったので、UbuntuなどのDebian系OSであれば同じ方法でいけると思いますが、以下の方法でdb.hを配置することができるようです。

$ sudo apt-get install libdb-dev

このapt-getが無事終わったら、cpanm で DB_File モジュールが入ります。

検索したら、他のサイトでは「手作業でtarボールを落としてきて…」とか書かれていて「Debian系ではそこまでする必要はないんじゃ」と思ったので手元で試行錯誤したら上述の方法でうまくいったというメモでした。apt-cache search berkeleydb して出てきたパッケージの中からもっとも有力そうなものを入れたらたまたまうまくいったというだけですが。

よく確認していませんが、perlbrewやplenvではない「システムPerl」を使う場合であれば、Debian の libmldbm-perl パッケージで DB_File モジュールが入るようです。ただ、LiBotのような新しめのモジュールはパッケージとして提供されていないので、ユーザPerl環境を作るか、cpan2deb (dh-make-perl) コマンドを使うなりして自分だけのCPAN配布パッケージのDebianパッケージを作る必要があるでしょう…が、この作業はPerlモジュールの依存関係が深くなればなるほどしんどい…。個人用途で縛りのない環境であれば、ユーザPerl環境を作るほうが楽な時代でしょう。

さて、本題のLingrで遊ぶ作業の続きでもしようかな。

参考:

Hokkaido.pm#11 に参加してきました #hokkaidopm

おがた (@xtetsuji) です。

2013年12月28日に行われた Hokkaido.pm#11 に参加してきました。

※参加ブログ記事やスライドURLなどについては、公開されたりしたら都度追加していきます

いつも参加ブログ記事を書くのが遅いので今回はすぐに年内に…。本当は他にも出席したものの、まだ参加ブログ記事を書いていないイベントが結構あるのですが、それは年末年始休暇にまとめて書こうと思います。

参加者の方々によるブログ記事 。

場所は、今回は東札幌駅近くの産業振興センターではなく、札幌駅の北の札幌エルプラザというところでした。ここはHokkaido.pm Casualを毎月催しているところ。

今回も13時30分開始でした。勝手が分かっていて、一度Hokkaido.pm Casualに出席して札幌エルプラザに行ったこともあるので、比較的迷わず行けました。吹雪結構大変だったけど。

自分主導でUstreamをやってみた

自宅で役割のなくなったiPhone 4sがあったので、前回のPerlBeginnersのときにそれにUstreamアプリを入れてUstreamをしてみました。一人でも見てくれれば御の字と思っていたら、数人から反響があって、やってよかったなと思ったので、今回のHokkaido.pmでは、私が名乗り出て、この形式のUstreamをやってみることにしました。幸いHokkaido.pmのUstreamアカウントは随分前から存在していたので、それを利用しました。録画もあります。

前回のPerlBeginnersは短時間イベントなので気付かなかったのですが、iPhoneのUstreamアプリの最大連続録画時間は3時間(180分)ということを知らず、途中でぶった切られています。ちょうど自分が発表する前後でした。

Ustreamは3時間まで

 

ちょうど3時間(180分)寸前でいったん録画が切れているのが分かりますが、そういう事情です。録画が残されていたことが幸いでした。ばらく気づかず、タイミングが悪かった。皆さんもiPhoneのUstreamアプリで長時間ライブ配信をするときには気をつけてください。

いちおう休憩中はオフレコの雑談もあるだろうということで、画像はブルースクリーンを移しつつ、マイクはオフにするという対応をしました、これはこれで良かったかなと思います。3時間以内に収めつつ、収録時間を少し細切れにするとよいんだなというのが今回の教訓でした。

録画は3時間超(13時30分〜17時頃まで)の長丁場ですが、ダラダラ閲覧すると雰囲気が分かっていいかなーと思います。@yusukebeさんの40分トークなど、見所も多かったので、自分の見たいところだけを見るのも良いと思います。

今回はUstream業や会場入りが遅かったことや体調不良などもあり、バタバタしていてメモが疎かです。他のスピーカーの方がスライドを公開したりしたら、随時情報を更新していこうと思います。

13:40~14:00 「今年書いたPerlコードの振り返り」 by @akiym さん

akictfの話から。

特にMac関連のCocoaモジュールが豊富な @akiym さん。私も結構お世話になっています。

  • AnyEvent::SKKServ
  • Cocoa::NetworkChange
  • Regex::VerbalExpression

Cocoaモジュールの作り方について。なぜ「Cocoaのモジュールを書くのか」という問いについては、CocoaのAPIに触りたいからとのこと(高速化ではない)。Perlを使って、Macアプリを使わずにMacの機能にアクセスしたいだけだし、単体モジュールにして言ったほうがみんなが幸せだとtypesterさんがいっていた、とのこと。

最近では「XSUBで書けるようになったので超絶便利」であり、革命とのこと。Cocoa::GrowlやCocoa::Skypeは面倒なことをしているそう。xsubppが…。

MinillaでXSモジュールを作成する場合には minil new -p XS Module して、builder_MyBuilder.pm を作成してminil.tomlを編集。あとは *.xs にゴリゴリと書いていって、makeすると.mが生成される。

Cocoaモジュールは、普通のXSと同じように書けるそうです。Cocoa→Perl、Perl→Cocoaのデータ変換に気をつければいいだけ。それ以外はただのXS。どうやればいいんだ…というときには@typesterさんや@soh335さんを参考にすればよいとのこと。

Mac::Keyboard::LED というモジュールを作った話。Caps Lockを光らせることが出来るやつ。通知に良いかもしれません。

後半はベータバージョンであるPerl5.19の話。hash slice sytaxやpostfix dereferencingなどの便利記法を紹介したあとに、CGI.pmが正式にdeprecatedされた話や、削除されたモジュールの一蘭などを紹介。ようやくCPANPLUSが無くなった。時代ですね。

最後に、ウェブアプリケーションの設計についての、聴衆への質問の投げかけ。

Amon2を使っている理由は単なるコンテキストマシーンであるというところから、Bootstrap3.0対応、Kolon対応が良いという話、Rooter::BoomやTengを使っているという話の後で、Modelというものは何なのかという問いかけでトークが終わりました。質疑応答が盛り上がったものの、MVCにとらわれすぎてはいけないという結論に至ったような気がします。

14:00~14:20 「Hokkaido.pm #11」 @__papix__ さん

自称「どこにでもいる大学生」、@__papix__ さんが大阪から遠路はるばるやってきました。今回はフェリーらしい。

今回のHokkaido.pmのテーマである「今年作ったもの」というのにふさわしく、いくつかの業務・私的に作った作品を紹介していました。

  • Facebook API 変更自動確認ツール Kaopan (これはインターン先の会社で作ったそう)
  • シンフォギア (今のところ自分用スライド公開ツール)

Kaopanは結構便利そうなので、会場からも公開を期待する声が多く聞かれました。

シンフォギアは「Amon2+Teng+SQLite+Text::Markdown::Hoedown」という構成で2日で作ったとのこと。今までの積み重ねと先人の苦労があって2日という短期間で作成できたというのは本人の弁。

先の @akiym さんの話に続いて、MVCについての話も触れられましたが、やはり「とらわれすぎてはいけない」という話。DBはModelとして扱うというよりもDB名前空間で別物として扱うスタイルだということが語られました (このあたりちょっとメモが怪しいかも)。

14:30~14:50 「Hokkaido.pm寿司x11」 @moznionさん

今年の流行語は「DevOps」という話からはじまり、協調を提案する話へ。

その後、TestとDocumentの関わりについて触れ、「DocumentからTestを生成する」アプローチと「TestからDocumentを生成する」アプローチの二種類を比較。 「SYNOPSIS重要」としつつも、「DocumentとTestを同居させる」という結論に。

後半は「TestからDocumentを生成する」というアプローチにフォーカスしてJSON APIのテストを書くとそれのドキュメントを自動生成してくれるautodocの紹介や、Test::JsonAPI::Autodocモジュールの紹介などをされました。

多岐に渡る活躍の中でもとりわけテストや品質管理に造詣が深い @moznion さんのトークでした。トークやスライドのテンポも面白く、Ustream録画やスライドは要必見です。

14:50~15:10 「」 @charsbarさん

翻訳家の@charsbarさんが余っている20分枠に急遽登壇。

最初はCPANTSなどの品質管理系の話から始まりました。

その後、本業である翻訳業の中で手間だったラテン語の辞書を引くためにMojoliciousアプリケーションを書いた話などが印象的でした。

最近編集(?)を手がけた「世界の名酒事典 2014年版」の紹介などもありました。興味深い。手広いです。

最後に、WindowsのiTunesで英語の勉強などで歌詞をブラウザでリアルタイム表示させたいといった要望を手軽にかなえるために書いたというウェブアプリケーションをご紹介。これはMojolicious Advent Calendar 2013でも紹介されていた記事のデモでした。MojoliciousとWebSocketの組み合わせ。これもまた興味深かったです。

15:20~16:00 「今年見たPerlコミュニティそしてこれから」 @yusukebe さん

講師派遣は無かったのですが、今回メインとなった40分トークを飾ったのが、最近JPAの理事に就任された@yusukebeさんのトークでした。

技術的なことよりも、それを支える方法であるとか、盛り上げるアイデアだったりといった展望について熱く語られたトークでした。スライド公開後のネットでの反響もかなりあったようです。スライドも公開されていますし、Ustreamにも録画がありますので、ITエンジニアコミュニティに興味のある人であれば、元気がもらえるスライド・トークでしょう。私が書いたメモを公開するより、このスライドをテンポよくめくっていったほうがよく雰囲気が分かると思います。興味があればUstream録画も見るとよいといった感じです。

今回の名言「PerlMongerよ、旅に出よ!」は、Perlプログラマだけでなく、全てのOSSに携わるITエンジニアに言えることではないでしょうか。数学などの頑張れば一人で出来る学問でさえ、ネットを使ってみんなで協力するだけでなく、学会発表や研究交流のために各地に旅費を払って行くわけです。場所が変わって、そこで得られる知見といったものは何にも代えがたいものがあるでしょう。私も関東圏と北海道のみが活動圏だったので、今後は西や南のほうや海外へ、出来る限りもっと積極的に足を運びたいと感じました。

16:10~16:30 LT

今回のLT、最初は応募が少なかったのですが、結果的に飛び入りが多くて活況となりました。

まずトップバッターは飛び入り参加の @itrysd さん。ギターの音を奏でられる本格的なウェブサイトを作ったそのデモは、なかなか興味が惹かれるものがありました。本公開が待ち遠しいです。

@techno_neko さんの「本当にあったGrepが遅い話」は、耐久テストのような問題が出されて、なかなか面白い感じでした。非常に疎な配列の作成が新しいPerlであれば実行可能であるという結論は、なかなか興味深かったです。

次は私のトークでしたが、その話は後ほど。

再び登場 @__papix__ さんによる「Hokkaido.pm#11 Lightning Talk」。今年書いたモジュールを色々列挙。@moznionさんが「成果を横取りされた」と言っていたのが面白かったです。Acme::SuddenlyDeathが今年2013年とは…。随分前のことだと思っていたので、意外に2013年は長かったのかなぁとも思いました。貴重な感覚です。

@onagatani さんによるAWSの紹介。スカイアークがAWSを主導していること、とても興味深かったです。

@aloelight さんの「今年書いたPerlのコード」は本格的なモジュールがいくつも出てきて驚愕しました。Tamanegiは興味深いですね。公開を楽しみにしています。

※LTのメモが疎かだったので、順番などが狂っている可能性があります。

私のLTについて

今年作ったもの2013」と題して発表させてもらいました。スライドも公開済みです。

実際2013年は色々あってあまりPerlのプログラムを書かなかったのですが、APIラッパーの類や、書き捨てスクリプトであったり、そのあたりを含めて紹介させていただきました。他の人が発表している本格的なものに比べて見劣りするなぁとは思いましたが…。

特に今年は、12月11日から12月24日まで胃潰瘍で入院をしていて、今回の Hokkaido.pm#11 にも出られるかどうかというギリギリの感じでした。Twitterに同報通信的に状況を報告していったのですが、同情をもらおうとかそういう意図は全く無かった(詳しくは「入院中、そして伝えたいこと少し」を参照)ものの、意図せず色々なITエンジニアの方から心配をしていただき、2011年7月のHokkaido.pm#5から開始したコミュニティ活動によって「作った」というよりも「豊穣された」温かいコミュニティにトークの中で感謝をしたかったということがあります。

とはいえ、ディスプレイトラブルであったり、ちょうど180分のUstreamトラブルであったり、久々にハマった発表だったので、なんかそのあたりを落ち着いて話すことが出来なかったのが心残りでした。

ご心配くださった方、お見舞いに来て下った方、本当にありがとうございました。

懇親会

今回もすすきのへ移動しての開催でした。札幌駅近くだったので、今回は30分ほど歩いて移動することに。入院していたこともあって、久々に長時間歩いたので結構疲れましたというか汗をかきました。

鍋料理、お腹に優しくてとても助かりました。移動できない狭さだったので多くの方との交流はなかなか難しかったのですが、それでも近くの席の人達と盛り上がれました。

二次会

@onagatani さんが大好きな活イカのいる、いつものあの場所でした…がシケで活イカはいませんでした。

少し人数が減って、多くの方との交流がより弾みました。@onagatani さんともようやく二次会でゆっくり話すことができて満足。

その後

大体Hokkaido.pmの三次会は@onagataniさんが大好きなラーメンで締めるのが通例なのですが、病み上がりでラーメンのような脂っこいものが食べれないことなどもあって、行きませんでした。噂では、@onagatani さんと @jamadam さんの二人でラーメンに行ったようです。

まとめ

久々のHokkaido.pmだったなーという気がします。Casualが毎月開催されているのでそちらに比重が置かれてしまう感じもありますが、北海道外からの参加者も集めて大々的に出来るHokkaido.pm本会というのも趣がありますし、私も大好きな北海道に行く口実ができてとても良いです。噂では、また3ヶ月に一度くらいのペースで次回が開催されるらしいとのことで、大いに期待したいところです。