Whole My Life Catalogue

最近また使い出した MySQL をもっときっちり使えるようになりたいなあ、ということで「Webエンジニアのための データベース技術[実践]入門」を手に取ってみました。

松信さんの本を初めて読みましたが、とても分かりやすいですね。他の著作も読みたくなりました。

本書はタイトルに「入門」と付いていますが、データベースを扱う人であれば読めば何かしら得られるモノがある本です。MySQL 使ってるなら尚更ですね。

データベース技術はもちろんですが、適切な技術を選択するためにどういう考え方をすべきか、という点でとても参考になりました。

本書には、大小さまざまな課題や疑問(と明快な回答)が出てきます。

• データベース技術とは何か、それはどういった技術的課題を解決してくれるのか
• RDBMS の各機能（インデックス、トランザクション、レプリケーション、パーティショニング）はそれぞれ何を解決するためにあるのか
• SSD はどういった課題を解決するために適用すべきか
• バックアップはなぜ必要か
• NoSQL が台頭してきた背景は何か

こういった疑問は日々の仕事の中でおざなりになってしまうこともあります。一人の力量では疑問が解消できないことも多いです。そういった取りこぼしてしまいそうな知識を体系的に理解するきっかけになる本です。

ソースハッキングや大規模運用事例でのトラブルシューティングを通して、超一流の DBA である筆者の思考の流れを追体験できる点もおもしろいです。

運用トラブルは恐ろしいですが、運用トラブル時に何も出来ない人になるのはもっと恐ろしいですよね。そんなエンジニアにならないように基礎を抑えていきたいところです。

Permalink | Leave a comment  »

早いもので福岡に引っ越して一ヶ月が経過しました。

まったく知らない土地に住むのは初めてのことなので、しばらく住んでみた印象をまとめます。

今回は住んでみて特に気に入った二点について書いてみます。

• 移動時間が短い
• 人のつながりが濃い

他にも色々あるのですが(ゴミ収集が夜とか)、また別の機会に。

移動時間が短い

自分は福岡市中央区といういわゆる都市部に住んでいますが、何をするにも便利です。 福岡はコンパクトな都市を標榜していますが、その恩恵を最も受けられるエリアだと感じます。

例を挙げると、

• 天神のデパート群まで徒歩5-10分
• Apple Store まで徒歩10分
• ジュンク堂まで徒歩10分
• 野球場(ヤフードーム)までバスで15分
• 新幹線(博多駅)まで徒歩15分 (バス・電車で5分)
• 空港まで電車で10分
• 港までバスで10分 (そのまま釜山や近隣のリゾート地にも行ける)

といった感じです。

東京のような大都市では様々な施設が点在せざるを得ないため、上記の条件を満たすエリアはありませんよね。それぞれの施設は首都と同等の規模は望めませんが、全てがあるというのは便利さに直結してます。

自分は通勤時間もバスで20-30分と短く、通勤ラッシュとは無縁です(一ヶ月働いてまだ電車に二回しか乗ってません)。

この良い意味での街の「狭さ」は快適です。都会に住みたいけどちょっとした移動で乗り物に乗るのはちょっと、という自分の性格にあってます。

実際、Web 系企業が福岡に支社を作る理由の一つに「エンジニアのライフスタイルに合っている」というのがあるそうです。確かに適度に都会で適度に自然があり移動もラク、というのは少なくとも自分には合っています。

人のつながりが濃い

福岡のエンジニア・コミュニティはとても濃いし、活発です。自分の場合は Web 系のコミュニティしか知りませんが、そこに限った話ではなさそうです。

そして優秀なエンジニアさんもとても多いです。先日開催されたチューニンガソン Vol.3 では10位以内の半数が福岡会場だったようです。凄い!!

勉強会も多種多様にやってますし、どれも徒歩圏内でやっていて懇親会の事を考えるととても素敵です。

自分も三回ほど勉強会に参加してみました。

• WebSig
• Python勉強会
• イケテルGit勉強会

それぞれ勉強会のテーマはバラバラだったりするのですが、けっこう参加者が被りますw

また、知らない人同士でも名刺交換したり懇親会で話したりすると共通の知人が判明するということも頻繁にありました。

やはり街がコンパクトな点が関係してるのか、人付き合いも自然と濃密になりやすいようです。みんな近所に住んでると何かあっても集まりやすいし、ちょっと遅くなっても大丈夫だからなんでしょうかね。

もともと東京では下北沢近辺に住んでいて、その理由が人付き合いの濃さが生む居心地の良さにありました。そういう点では自分向きな土地だなあと感じています。福岡市中央区も都市部とはいえ航空法規制で高いビルがないし夜は屋台がたくさん出ていて、なんだかアットホームな雰囲気があります。

まとめ

自分が知ってる福岡=福岡市中央区、という感じなのでかなり偏りのある内容なのを断っておきますが、とても住みやすい街です。程良く都会で人付き合いもあり街のサイズが自分にはちょうど良い、というのがポイントなんだろうと思います。

ソフトウェア・エンジニアに優しい街、というのがまずは一ヶ月住んでみての感想です。

参考になる記事

実際に住む前にこちらの記事も参考にさせていただきました。

• 明星和楽 福岡市の目指すデジタルコンテンツの街
• ITエンジニアは、福岡で3倍幸せになる☆
• 福岡のデザイナーとプログラマーがコミュニティで仲が良い理由を考えてみた
• 福岡に来て知った事

Permalink | Leave a comment  »

三月に入ってから Python を書いてます。

開発環境は相変わらずの tmux + zsh + vim のターミナル族です。 tmuxinator という tmux のセッション管理ツールを導入したら、なかなか快適になったので紹介します。

セッション管理って具体的に何をしてくれるのかというと tmux の window や pane の状態を yaml に設定することで、自分のお気に入りの window, pane のレイアウトに半自動で復元してくれる、という感じです。

ローカルでも tmux や screen を好む人は皆そうでしょうけど、window と pane の配置に拘りがあると思います(1番は各種ログ、2番は zsh と console、3番はエディタ、みたいな)。でも開発機はなんだかんだ頻繁に再起動せざるを得ない。これまでは毎度手動で「いつものレイアウト」を作っていたのが、tmuxinator を入れると半自動でレイアウトを組んでくれるようになるのですね。素晴らしい。

Django + VirtualEnv 環境の作り方はこちらのブログエントリを参考にしました。

欲を言うと以下もサポートすると素敵かなあ、とか感じました。

• rbenv のサポート (rvm はサポートしてる)
• pane ごとのコマンドの pre 実行のサポート (pane を開く毎に workon を自動実行させたい)
• 細かいレイアウトのサポート(今は微妙な調整は手動で行ってる)
• 現在のセッションの yaml へのエクスポート(よくばりすぎかw)

欲望の赴くままに色々書きましたが、最新版の v.0.5.0 の機能だけで十分にライフチェンジングです。

多言語で複数プロジェクトを兼務してるような、アタマの切り替えが大変な方には特にオススメです。 tmuxinator で Hyper Polyglot 時代も乗り越えていきましょう。

なお、screen 派の貴方には Screeninator というのがあるそうですよ。

Permalink | Leave a comment  »

2月29日付で株式会社アイスタイルを退職します。現在は有給消化中です。

今後は家庭の事情で東京を離れて福岡で働くことを決めています。

人生のほとんどを杉並区と世田谷区で過ごした自分にとって福岡という地はまったくの新天地です。月並みですが不安と期待で胸いっぱいな感じです。当然ですが楽しんでいこうかと思ってます。

アイスタイルでは2年10ヶ月働きました。化粧品クチコミサイトのアットコスメを中心とした Web 企業ということで、これまでのキャリアの中でも経験のない華やかな時間だった、と感じています。

ティム・オライリーの "Data is next intel inside." という言葉通り、アイスタイルの持つ「ビューティフル・データ」（真の意味でのビューティフル・データですねw）は今後より強力な武器となってくるものと感じます。会社の今後の発展を遠いような近いような九州の地から見守らせていただきます。

福岡行きを決意したのが去年の9月で、出発までの期間も短かかったこともあって直前まで色々バタバタしました（明日引越ですw）。快く送り出してくださった皆様ありがとうございました。感謝の一言です。本当に自分は幸せ者としか、それしか言えません。

3/1 からは新天地での業務になります。まずはさまざまな環境の変化を楽しんでいこうと考えています。

単なる個人の国内の引越とそれに伴う転職のお知らせと言えばそうなんですがw、少し丁寧に書いてみました。

今後は福岡のエンジニアライフやコミュニティについても、東京の事情も曲がりなりにも知る者としてブログにも書いていこうかな、と考えてます。

Permalink | Leave a comment  »

Path の魅力

最近 Path をよく使っている。 UI と UX のよく練られたモバイルネイティブの Facebook、というのが第一印象だったけど、使い込むうちにこれは SNS じゃないな、画期的なサービスかもしれないな、と感じるようになってきた。

About に書いてあることを読めば、ブログにする必要もないのかもしれないけど、一応個人的な体験も踏まえて Path の良さを語ってみる。

デフォルト非公開の心地良さ

Path に上げた情報はデフォルトでは Public にならず友人同士でのみ共有される。更に共有された写真や動画は友人は保存できない(保存ダイアログが出せるけど保存できない。Android だとどうなんだろう？)。この安心感のおかげで Twitter や Facebook だとアップに躊躇していた顔入りの写真や動画も Path だと上げている。

情報共有できない心地良さ

Path は URL がリンクにならない。また入力がモバイルに限定されているので、ブラウザで見ていた情報を気軽に共有することも出来ない。つまり Web の情報を共有するツールとしては全く向いていない。

しかし、この制約のおかげで自分に関することだけを共有する姿勢が出てくる。結果的にノイズが減って親密な空間が生まれる。何より見ていて疲れにくい。

Public についての疑問

Path では Public という概念は他サービス連携という形で実現される。Thought を Twitter に連携したり 4sq で位置情報や写真を共有したり。

連携自体はなるべくサービスにある機能で実装しようという考えで作られている。例えば写真を Facebook 連携すると Facebook のアルバムにポストされたり、Thought を Twitter や Facebook で連携するとそれぞれ tweet や Status Update としてポストされる。4sq の写真にも対応している。この設計思想は Path 側が原則プライベートであることを考えると納得がいくのだけど、連携先のサービスに無い機能については path.com ドメインの URL で共有される。 このページに関して一つ疑問がある。それは Seen(閲覧履歴) や Emotions も Public になってしまう点だ。プライバシーに気を使っている Path なのに本人の情報じゃない Seen や Emotions が Public になるのはなんだか片手落ちのように感じる。せめてログイン状態じゃない場合は表示してはいけない情報だと思う。なんでなんだろう。仕方ないので不本意だけど Twitter 連携はあまり利用しないようにしている(写真は pic.twitter.com、位置情報は位置情報付きツイートになってくれれば良いんだけど、それだと Path 自体が広まりにくくなるジレンマが)。

まとめ

Path は仲が良い友人、家族、恋人と一緒に使うことを前提としたサービスで、もはや大衆メディア化してる SNS や共有に使うには面倒なメールの中間にあたるサービス。ホント、ここまで家族に使ってもらいたいと感じたサービスは初めてかも。逆に従来の SNS のノリでフレンド申請しちゃうと共有できる写真や動画が制限される状況になって Path の良さに気付けないのかもしれない。

Permalink | Leave a comment  »

2011年

久々に更新。年初らしいエントリを書いてみる。

2009年は転職と結婚、2010年は息子の誕生と個人的に激動だったここ数年、やっと落ち着いてしたいことでもして過ごそうという考えていた2011年。 社会全体が激動だったこともあり、落ち着いて過ごすことは出来なかったなあ、というのが実感。

そんな状況でいくつかやれたことというと以下の二点に集約される。

• Scala
• 地域コミュニティ活動

Scala

2010年末からちょこちょこ手を付けていた Scala を本格的に始めた。

前半はScala スケーラブルプログラミング、通称コップ本の輪講に費した。輪講自体はこれまでもアジャイルプラクティス、Implementation Patterns、Webを支える技術を経験していたが、未経験の言語を学習する際にも効果的な方法だと認識できた。これはコップ本自体が題材として優れていたことも大きい。

極論を言うと、初学者の Scala 学習の最善策はコップ本を1ページも飛ばさずに精読することだと思うようになった。必然性を感じさせる章構成が素晴らしい。

輪講の記録はGoodreadsに残した。

コップ本については夏ごろにも社内の有志で再読したので、同じ本を二回精読するという貴重な体験が出来た。

Scala 自体は黎明期を終えて普及期に入ってくる言語だと確信しているが、会社組織全体で導入するには学習コストや多様性の高さが仇になりやすいのかもしれない。ただ、モナドや型クラスなど、これまで机上でしか縁のなかった概念を動く形で触れる機会を作ってくれるし、今後の技術トレンドも取り込んでいるバランスの取れた素晴らしい言語だと思う。

Scala は周囲のサポートもあって一年を通して使い続けられた。今後、仕事で使う機会も増えてくることを期待しているし、また使う機会を自ら作り出したいと思う言語だ。

地域コミュニティ活動

下北沢在住のエンジニア数名で、月一回のコミュニティ活動を実施した。

きっかけは何気ないツイートで、近所の初対面同士でそれぞれの友人含め四名で始まった。

震災の関係で出来ない月が一度だけあったけど、ほぼ毎月の開催。内輪ノリで成果のないゆるふわな集まりだけど、リラックスして議論が出来る心地良い空間になっている。

コミュニティ運営と呼べるほどのものでは無いのだけど、やってみないとわからないことはたくさんある。

例えば、会場の値段。 いつも利用していた北沢タウンホールの男女共同参画センターらぷらすは団体登録すれば活動コーナー(8名程度)は無料、24人会議室は240円、45人会議室は800円で四時間程度利用できる。これは貸会議室やコワーキングスペースに較べればかなり格安なんじゃないかと思う。自習コーナーもあるし、毎日夜10時までやっているし、ネット回線もあるし、プロジェクターも貸してくれるし。ホントに自治体の施設はちゃんと調べて利用しようと思った。

コミュニティの継続性についても、最初は色々きっちりやろうとしすぎてたような気がする。でも、だんだん初対面同士が仲良くなってくると場所取りと集合時間さえ設定すれば、それぞれのネタを持ち寄って勝手に話しが盛り上がる場所になっていった。

ちょっとだけ度胸を出してみんなが集まったおかげで、奇跡的に良い関係を築くことができた。月に一度タウンホールに集まる皆様には不思議な縁を感じている。濃いメンツばかりで話していて楽しい。

2011年の総評

ふりかえってみて、例年以上に精神的に辛い時期もあった年だったけど、一つのテーマを継続的にやり続けることでどうにか乗り切ってきたんだなあと気付いた。結局身に付くのは継続できたことだけ、ということも再認識できた。

あと自分は家族の支えでどうにか成り立ってるんだなあ、と強く実感した一年だった。

2012年の目標

2012年はどんな一年にするか。実はやることはもうある程度まとまってるけど、もうちょっと一段落してから文章にしようと思う。

挑戦と変化の多い一年になりそうなのはわかっているので、そんな中で以下の言葉を自分の中の標語としていきたい。

"Remain orderly in your life
 so you can be free and chaotic in your work."
(生活を整然とすることだ、そうすれば、仕事は自由で混沌としていられる)

今年もよろしくお願いします。

Permalink | Leave a comment  »

Scala アプリケーションの設定ファイルをどの形式で記述しようかと調べたら Twitter 製の util-eval が良い感じだったので紹介する。

util-eval とは

util-eval は Scala コードをインタープリター的に評価するライブラリ。Scala コードを動的に読むことで設定ファイルとして利用することを目的としている。

Scala コードを設定ファイルとすることは YAML, JSON, properties と比較して下記の利点がある。

• 強い型付けとコンパイラのチェックを受ける。コンパイルできない場合は例外を吐いてくれる。
• Scala コードなので強力な言語機能やライブラリの恩恵を受けられる

リポジトリ

• github
• maven.twttr.com

2011.07 現在、github より Maven の方がバージョンが進んでいる。Twitter 社は全体的に github より Maven リポジトリの方が更新が早いみたい。ここは是非 github のコードも同期してもらいたいところ。

sbt 設定

0.10.x 系で取得した。build.sbt に下記を追記。

resolvers += "T repo" at "http://maven.twttr.com/"

libraryDependencies += "com.twitter" % "util-eval" % "1.10.1" withSources()

末尾の withSources() ついては 次の節にまとめてみた。

sbt の withSources() について

sbt は dependency の末尾に withSources() を付けると update タスクで $HOME/.ivy2/cache/groupId/artifactId/srcs 以下に source-jar を取得してくれる。これを利用すれば IDE から参照したりできて良い感じになるのかな？と思ったのだけど、どうも上手くいかなかったので格闘の記録を一応残しておく。

sbteclipse 1.2 で eclipse タスクに with-sources オプションが追加された。 これを使えば withSource() で取得した source-jar と関連付いた .classpath を生成してくれるのかと推測したら、どうも違った。

with-sources オプションを付けると再度リポジトリから source-jar を取得し。$HOME/.ivy2/cache/groupId/artifactId/jars 以下に source-jar を保存し、.classpath の sourcepath 属性と関連付ける。これで、問題なく source-jar を IDE から覗けるようになるんだけど、本来なら再度 source-jar を取得せずに srcs 以下に既にある source-jar を参照してもらいたいような気がする。この辺りの挙動がバグなのかどうなのか理解できていない。まあ関連付け自体は成功したので、オーケーとしている。

なお IDEA の sbt 統合である sbt-idea でも似たような関連付けは実装されているらしい。

色々書いたけど実は Scala は Vim で書くのに慣れちゃったので、Eclipse にある程度入門できたら、また Vim に戻ろうかなあとか揺れている。

Configgy との関係

Scala のコンフィグレーション・ライブラリは Configgy という独自フォーマットのライブラリがこれまでポピュラーだったらしい。ロギング関連の機能も持っているとか。

ただ、Configgy 本家の README にもあるように今後は Configgy は廃止していって util-logging と util-eval に徐々に役割を移していく考えのようだ。

しかし、util-eval に限らず Twitter 製のライブラリは基本的に Scala 2.9 対応をしていない。対して Deprecated なはずの Configgy は 2.9 対応したブランチを持っている、というちょっと微妙な構図になっている。

github に最新のコードがあがっていれば folk して 2.9 対応すれば良いってことになるんだけど、現状だと Twitter 社の対応に期待するという感じになってしまっている。

Scala 2.9 での動作

上記のような事情もあるが、util-eval を 2.9 で使えるか試してみた。ivy の設定ファイル 上では対応バージョンは 2.8.1 となっているが、2.9 でも特に問題なく使えた。あくまで、たまたま動いた、という事なんだろうけど、今回はまあいいかな。

雑感

util-eval の Typesafe な設定ファイル、という考えは Scala らしいし、しっくりくる。 設定ファイルは、リソースパスの通った jar, war にも置けるし、ファイルシステムにも置けるので問題も少ない。

その他感じたことをまとめ。

• Twitter 製ライブラリは 2.9 対応していないので注意。今後どうなっていくのだろうか？
• Twitter ライブラリの現状を追うなら maven.twttr.com を見るのが吉。でも github のミラーは最新に同期にしててほしいな。
• sbt の Build.scala も Scala コードの設定ファイル、という似た者同士なので、内部に似たような仕組みを持っているのかなー、とか思った。sbt.compiler.Eval あたりなのかな？

Permalink | Leave a comment  »

最近、ソーシャル・ニュース・アグリゲーターみたいなサービスが色々出てきたのでちょこちょこ試してる。そのうち気に入った二つのサービス、Flipboard と Summify を紹介する。

試してるサービス

• Flipboard
• Summify
• paper.li
• News.me
• Deja

繰り返しになるけど、お気に入りは Flipboard と Summify。

しばらくして paper.li と News.me は使わなくなった。 paper.li は、Twitter 連携の設計が微妙にスパムっぽい通知になってて印象を下げてしまってる感じ。

News.me はトライアルで使ったけど iPad 版が有料な割には他サービスとの違いが見出せなかった、という理由。

Deja はインターフェースがかなり素敵だけど、初代 iPad だとちょっと重い。あと Vimeo をアグリゲートしてくれないのが残念。

Flipboard は朝刊代わり

Flipboard は iPad アプリの完成度が高いので、朝刊代わりに読んでみていて、割とちゃんと習慣になってる。ついでに Hacker News も購読に入れてナナメ読みしてる。

使ってて惜しいのが、たくさんのアカウント(Facebook, Twitter, GReader, LinkedIn, Instagram)と連携してるけど、それを横断的に見る機能が無いところ。

後述の Summify はそれぞれのアカウントを横断した情報を元に一つの「まとめ」を生成する。探さずにパーソナライズされたニュースを読みたい自分にはこっちの方が読みやすい。

あと、Flipboard は iPad の Instagram ビューアーとしても一番良いと密かに思ってる。

Summify の iPhone App は素敵

Summify は最近 iPhone App が出たばかりで、これの出来がすごい良い。元になってる発言が追いやすいので、それが出来ないメール版や Web 版はすっかり見なくなってしまった。

あとは地味だけど重要な特長として、記事のチョイスや並び順の納得感がとても高い。どういうスコアリングなのかわからないけど素晴らしい。OPML をインポートしたりできるから、この情報も使われているのかな？

記事が気に入らない場合も、ある程度ゆるい感じのカスタムも可能で、クリックしたり、Dislike ボタンを押したり、特定の人物をキュレーターから外したりして、興味を伝えることで、次号以降の内容に反映される仕組みになっている。

色々完璧な Summify だけど、どの UI も連続的に読むのには向いていなかったり、動画再生は元ページに行く必要があったりして、ダラ読み用途には iPad App の登場が待たれる感じになっている。

まとめ

Flipboard と Summify がおすすめ。特に Summify。

両者のアプローチの違いは設計思想の違いなのかな、と感じる。

Flipboard はデザイン指向でソファに座って雑誌を読むような体験ありき、Summify はアルゴリズム指向で読者にとって最適なニュース選びを重視してる、と勝手に思ってる。

あと、リアルタイム性はこの手のサービスではそれほど重要じゃない気がする。毎日決まった時間に質の高いまとめが来る、というのが良いんだと思う。そういう意味だとリアルタイム性を重視している Flipboard, Deja はちょっと違うカテゴリーのサービスなのかもしれない。

Following や Friends がキュレーションしたニュースをアルゴリズムでまとめる、というのが、人間の編集と機械編集の融合という感じで、なかなか熱い分野だと思う。ニュース以外でも応用できそう。例えば写真とか。Google+ というキュレーションのソースも増えたし、どんどん変化していくんだろうな。

Permalink | Leave a comment  »

Permalink | Leave a comment  »

第 4 回に参加して以来の Scala 勉強会第 9 回に行ってきた。 9/1 から毎週欠かすことなく実施しているのだから主宰の @kaigaiengineer 氏には頭が下がります。 @cpp_akira さんの「Scalaがもたらす言語の進化」はスライドが素晴らしい内容。Scala = マルチパラダイム言語、という言葉が納得感があります。定数式が弱い、という Java も併せ持つ欠点を scalac で解消できたら、意外と携帯アプリ言語として伸びる可能性がある、という話がなかなか興味深い感じでした。 @uchida75cm さんと @kaigaiengineer さんの発表は制作物を現場でコードレビューをするような状態で、最近忙しさにかまけてコード書いてなかった自分には非常に刺激になりました。 以下、雑感。

• C++ の Boost が Scala に移植されたら、という話で盛り上がってた。Boost ってそんなにスゴいのかあ。
• D 言語がいろいろスゴいらしい
• Haskell のパターンマッチと Scala のパターンマッチの差異が知りたくなった
• やっぱ中置構文って好きなヒト多いな
• 左結合、右結合が固定されるとカッコが増える、ていう一連の議論があまり理解できていない
• BNF ベースのパーサーコンビネーターがあるコトを知った ((Scala プログラミング入門にあった気がするが、よく理解できていなかったのかな))
• そのうち懇親会出てみたい

Permalink | Leave a comment  »

Scala を遊ぶ!会 第2回 に行ってきた。仕事の都合で30分遅刻した。 今回のテーマは Scalatra。元々は Step Framework という名前だったが名前が被っていたため Scala + Sinatra = Scalatra というネーミングになったらしい。 事前に Scalatra をインストールするために sbt というビルドツールを使ったんだけど、これが何だかわかんなかった。パッケージのインストール以外にも色んな機能があった。テストの実行、scaladoc の生成、REPL、jetty の起動などなど。 後半、質問タイムになったときに sbt が一体何なのかがわからない、というような質問をしたんだけども、@takiuchi さんが、IDE で開発したくない人にとって使えるツール、というような事を言っていて、なるほど、と目から鱗が落ちた。確かに autotest っぽくも使えるし、自分みたいなターミナル好きのためのツールなのかな、と理解した ((sbt がホントに simple かはさておき))。 Scalatra はハンズオンで、色々サンプルが動くところまで持っていくことに成功。Scalatra 自体はかなりシンプルに書けて良いんだけど、起動時に web.xml に色々書いたりする点で Sinatra に較べるとかなり複雑かな、という印象を受けた。Java の負の遺産 (この場合は Servlet API)をそのまま引き継いでいる印象 ((Maven も複雑そうで近寄っていない))。Play Framework はその辺りの Java から起因する複雑性をうまく隠蔽してくれているらしい。第3回に期待。 勉強会に参加する度に感じていたが、コップ本読まずに色々やっていると、かえって遠回りになってしまい時間がもったいないなと感じたので近日中に入手して読み進めようと思う。あと予習と準備をしておくことと、会に遅刻しないように仕事のスケジューリングをちゃんとせねば。と、妙にマジメに締めてみる。

Permalink | Leave a comment  »

もう10日も前の話だけど、10月16日に楽天テクノロジーカンファレンス 2010 に行ってきた。 以下のセッションを聴かせてもらった。

• 特別講演
• 基調講演「グローバル・エンジニア」
• HTML5 とその先にある Web of Data
• MessagePack Project
• 「クラウドコンピュータ」の経済学

Permalink | Leave a comment  »

とりあえず Google Reader への反映が速くなるのを確認したいところ。 Twitterfeed が PubSubHubbub に対応してるらしいので、それについては設定できたら後で書く。

Permalink | Leave a comment  »

Scala を遊ぶ!会に行ってきました。 会場のカフェ・ミヤマの会議室は、Wi-Fi 完備で、店内からは完全に独立した一室で勉強会にはとても向いた場所ですね。通常の店内も Wi-Fi のあるお店の中でも屈指の落ち着いた空間な気がします。 今回は、第1回ということで First Steps to Scala で、文法のおさらいと REPL の使い方をハンズオンで学習しました。Collection の挙動が全然理解できてないんだなーというのに気付けたのが収穫でした。こういうのは本読むだけじゃ気付きませんね。 会のお題にもなっている Play Framework に踏み込むのは第3回からになりそうですが、パッと見は Rails ライクで、個人的には取っ付きやすそうな印象を受けました。Play 自体は基本的には Java で書かれていて、Scala Module を持っているので、アプリケーション部分は Scala で書ける、というコトみたいですね。Java と Scala がシームレスに混在してるところに Scala という言語の独特さを感じます。 参加者のどなたかが、Play 本体も Scala 化を進めている、というお話をされていたので確認してみたところ、1.1RC1 のリリースノートにはっきり書いてありました。Java を Scala にリファクタリング、という発想がおもしろい。 あと終了間際の話で Scala hack-a-thon's Documentation の存在を知ることが出来たのも収穫でした。力作なんで時間つくってじっくり読み進めたいと思います。 同じ渋谷で毎週水曜日に Scala 勉強会も開催されています ((こちらは第4回に参加しました。レポートなしですいません。また参加します！))。そう負担にならない距離で毎週刺激を受けながら勉強できるのはサボりがちで物覚えの悪い自分にとって非常に助かるし、ここまで良い条件が揃う機会はまたとないので可能な限り参加するようにしていきたいところです。

Permalink | Leave a comment  »

Permalink | Leave a comment  »

php で API を複数回叩く処理があって、並列で捌けないかとちょっと調べたら curl 拡張モジュールの cURL Multi インタフェースを使えば良いらしいとのこと。早速使ってみた。 情報源は Yahoo! JAPAN Tech Blog。 最初はリンク先の情報を鵜呑みにして実装したところ、あまり速くならなかったし、CPU 使用率が妙に高い。どうも通信の完了を do-while で polling しているのがマズかったみたい。 下記エントリで curl_multi_select を使えば polling しないで済むコトを知ったので CPU 使用率も下がり速くなって効率的に実装できた。多謝。 http://techblog.ecstudio.jp/tech-tips/php-multi.html めでたしめでたし。にしても curl 拡張インタフェースって、ほとんど C のコード書いてるみたい。定数も山盛り。 ここまで来たら HTTP Pipelining を使って更なる効率化、と高みを目指したいところだったけど CURLMOPT_* は定数に無いし、 ((CURLMOPT_PIPELINING)) curl_multi_setopt も無いため少なくとも現時点では php では HTTP Pipelining は利用できないと判断して断念。 HTTP リクエストに限られているとはいえ、ふつうのスレッドが無い php で比較的シンプルに並列処理が可能なのは新鮮な驚きだった。意外とできる子なのね。WebAPI 使うケースは増える一方だし、なかなか重宝しそうで良い感じ。 9/30 追記: メモリ使用量についてもなかなか優秀な模様。 http://wb.cocolog-nifty.com/blog/2010/07/phpcurl_multi-p.html

Permalink | Leave a comment  »

東京電力の電気のシェイプアップカルテっていうサービスに申し込みました。 過去二年間分の電気代がグラフで確認できるサービスです。同契約の電気代の平均と比較ができるというのが良い感じです。当然無料です。 それにしてもこのサービスを発見したときは驚きました。なんでかと言うと過去に色々調べて電気代って Web で確認する方法は無いと自分の中で結論づけてたんですね。元々楽天マネーサービスでアグリゲーションできるサービスのひとつだったんですが、楽天のこのサービスのおかげで TEPCO の電気のシェイプアップカルテと東京ガスの my TokyoGas で各々の料金が Web で確認できるコトを知ることができました。TEPCO サイトでも相当わかりづらい所にあるし自分の周辺ではかなり知名度低かったのでもっとこのサービスの存在をアピールしてほしい感じです。 この手の Web 上で料金確認が出来るようになるサービスには大体登録してしまいますが、今の所メリットのみでデメリットは特に感じていません ((明細の郵送が不要になるものが増えればもっと良いんだけど))。 なんとなく利用中のこの手の他のサービスについても列挙してみます。

• 楽天カードのカード利用お知らせメール ((最近 iPhone App を出していてこれも良い感じ))
• 三井住友銀行電子メールお知らせサービス ((SMBC はスマートフォン対応に期待))

Permalink | Leave a comment  »

mixi Engineers' Blog を参考にして mixi チェックボタンを付けてみた。 以下、手順。

1. Developer 登録をする
2. Developer Dashboard から自分のブログを mixi チェック対応サービスに登録
3. mixi check for Wordpress をインストール
4. 2. で取得したチェックキーを Wordpress 管理画面から設定
5. Wordpress 管理画面の設置方法を参考にしてテンプレートを書き換えて mixi チェックボタンを設置

Permalink | Leave a comment  »

最近、Scala の勉強を始めている。 まずは概要を掴むために初心者向けな Scala プログラミング入門を読んだ。

• static がない
• パターンマッチの柔軟さ
• lazy val や名前渡しでの遅延評価
• コレクションライブラリが徹底してイミュータブル指向
• Actor は言語仕様と絡んだ機能ではなく純粋なライブラリだったのに驚き

• 束縛は一度きりであり、すなわちひとたび為された束縛は二度と変更できない。
• 四種類の束縛で既存のプログラミングを根底から捉え直す：値への束縛（val）、型への束縛（var）、式への束縛（def）、そして可能性の束縛（type）
• 関数とは要するに引数付き遅延評価式

• querulous (Twitter 謹製。MySQL ドライバ Only だけど他 DB 対応もどうにかなりそうな雰囲気)
• squeryl (Sequel が type-safe になった感じ?)
• より抽象レイヤで lift-record ってのがある？

Permalink | Leave a comment  »