rubyTweettravis-blink1これは何?blink(1)という、USB接続で発光するガジェットをhmskさんからいただいたので、遊びでつくってみたgemです。指定したgithubのプロジェクトについて、TravisCIの結果を発光して通知してくれるものです。CIが実行中のときは黄色で点滅、テストに失敗したときは赤色で点滅、テストが通ったときは緑で発光します。動作の様子はこんなかんじ。テスト失敗時テスト成功時blink(1)がおもしろいのは、プログラマブルに発光できること。色や点滅時間など、ことこまかく調整できるので、任意のイベントの通知として発光させることが可能になります。いろんな言語からblink(1)のAPIを叩くクライアントがあるのですが、rubyだとrb-blink1がひとまずよさそう。travis-blink1でも内部で利用しています。させるには、これだけでOK。remoteの結果から、TravisCIの状態を監視。katsuma/itunes-clientなんかのように「ユーザ名/プロジェクト名」を指定すればOKです。雑感blink(1)は、できることがシンプルなので、すぐに試せるのはいいですね。天井からぶら下げるなどして、hueみたいに照明代わりにしみても楽しそうです。/TweetTokyuRubyKaigi07でitunes-clientの発表をしました。Rubyを使わずにiTunesを操作していいのは小学生までですよね!!1あと、スライドの中でいろいろ動画をいれていたのですが、それもあわせて公開しておきます。FISHMANSの人たちを紹介してもらったのですが、何か僕で手伝えることがあれば、、というわけでサイトのフルリニューアルを手伝わせていただきました。FISHMANS今回利用した技術としてはフロントエンドmiddlemanmiddleman-blogHamlSassFoundationバックエンドSinatraインフラさくらのVPSnginxunicornunicorn-worker-killerコード管理github(のプライベートレポジトリ)な、感じ。今回、このリニューアルでいろいろハマったところや工夫できたことがあったので、もろもろまとめたいと思います。CSSフレームワーク以前のサイトは、PCでの閲覧のみ意識していたような作りになっていたので、スマホ(というかタッチデバイス)への対応が一番の要件でした。レスポンシブ対応のCSSフレームワークを選ぶか、、と思って選定に入りました。検討したのはこんな感じ。KickStartPureCSSフレームワークは似たものが乱立していてさてどうするか。思ったのですが、こんな基準で選びました。サイズが小さいスマートフォンに最適化されたUIが標準で用意フレームワークに依存したマークアップを強要されないBootstrapは1.が引っかかってやめました。あと、デフォルトの見た目が「いかにも」な感じになるのでもうちょっとシンプルで単純なスタイルが欲しかったこともあって利用はヤメ。Foundationは全体的にバランスがいいのですが、メニューまわりのマークアップがちょっと複雑なので保留に。最終的には利用することにしたのですが、正直いまだにメニューまわりにクセがある印象なので、そんなに強くオススメできません。Skeltonはシンプルでいいんだけども2の観点で見ると、自分でスタイルいじるのは最低限に抑えたかったので、全然スマホサイトっぽい感じがしなかったのでヤメ。KickStartはすごく単純なマークアップで一番最初は利用していたのですが、メニューまわりのデフォルトの見た目がまったくスマホサイトっぽくない感じだったので途中でヤメました。Pureはフォント周りのスタイルは一番好きなのですが、マークアップにpure-*とフレームワーク依存のclassやdata属性を強要されるのがどうにもシックリこなかったのでヤメ。ベストなものは無いこれだけ乱立してるCSSフレームワークだから、さすがにグッとくるものがあるだろう。思い込んでたのですが、正直いまだにグッとくるものは見つかってません。Foundationを消去法的に利用しましたが、デフォルトのリストUIの見た目はあまりグっとこなかったので、結局いろいろベースとなるスタイルは自分で用意しました。クックパッドで利用しているSaraフレームワークは、このへん見た目的にもマークアップ的にも、相当使いやすくなっていると実感できたので、SaraがOSSで公開されてれば。(チラッチラッ)と何度も思った次第です。考えると、これだけCSSフレームワークが乱立するのもやはり一周回って理解できるわけで、みんな痒いところに手を届かせるために「俺の考えた最強CSSフレームワーク」を作ろうとするんでしょうね。middlemanフロントエンドの基盤はmiddlemanにするのは最初から決めていました。オリジナルのサイトはベースはPHPで実装されていて、チケット管理ページなど動的ページが一部あるものの、ユーザに見える部分はほぼ全てのページが静的な情報なため、PHPのメリットはレイアウトをDRYに書ける、というところに留まっていそうでした。middlemanは最終的に静的なページを出力しつつ、haml/slimなどのテンプレート言語assetパイプラインLiveReloadなどのツールがすぐ使えるので、最近のRailsで開発するような感覚で開発を進めることができるのが大きなメリットです。実際今回触った感想としてmiddlemanは大正解でした。今後も数ページだけのサイトだったらmiddlemanを利用しない理由は無いんじゃないかな、と言えそうです。Sinatra1点を除いては、と言ったのは動的なページが出てきたときの対応です。middlemanはそもそも静的サイトジェネレータなので、動的なページなんて入れようとするほうが悪いのですが、いかんせん必要なものは必要です。今回もイベントのチケット予約に1ページだけ必要でした。ロジックはシンプルなのでSinatraで完結できれば。安易に思っていたのですが、いかんせん事例がほとんどありません。milddeman公式サイトにももちろん載っていません。唯一であろうヒントはmiddleman作者のThomasさんのコードの断片。要するにconfig.rbに特定のパスだけSinatra::Baseにリクエストを処理させる方法です。「開発時はいいけどリリース時はproduction環境にどうやって載せるんや。」と悩んでたのですがnginxで特定のパスへのリクエストだけUnicorn(で動かしたSinatra)へリクエストを流すようにすればなんとかなりそうかも?と思ってトライ。このへんのインフラ全然触ったことなかったのでハマりましたが、なんとかかんとかできました。開発時はこんな感じにしてます。buildするとminifyやgzip化されたHTMLファイルがbuildディレクトリにできるので、リリース時はこの中身をまるっとrsync。nginxも基本このファイルを直接返します。appはSinatraの実態。endこいつをconfig.rbから呼び出しておく。serverで手元でサーバを起動すると/ticketsのリクエストだけSinatraでハンドリングすることができます。app/config.ru開発時は利用しないのですが、productionではUnicornで利用するために必要です。プロセスの再起動はいい感じのタイミングにお願いしたいので、unicorn-worker-killerに任せてます。TicketReservationproduction環境こんなかんじのディレクトリツリーにしてます。appへrsyncして、appのコードを変更したときのみUnicornを再起動させています。nginxconfig.rbでの設定と同じような感じで設定します。/ticketsへのリクエストだけをUnicornを利用するようにします。基本的な構成は以上なのですが、その他にも細かいとこにもいろいろハマりました。一応メモがてら残しておきます。今回ブログのコンテンツのURLを、SEOを意識してタイトルをパス名に入れたURLにしました。2014春」まであと1ヶ月!!」ディレクトリと、その直下にindex.htmlを作っているだけですが、buildしてrsyncするとアクセスできず404が。ディレクトリ名がバグっておかしなものになっている模様。日本語が悪い??と思いきや、アクセスできるページもある。1文字づつ削って、問題の切り分けをするとどうやら「まであと1ヶ月」の「で」が悪い模様(!)なんだこりゃ。思いきやUTF8-Macのエンコーディングに起因する話な模様。rsyncでOK)iconvオプションをつければ良い。Found」問題Likeボタンはそれなりに何度も設置しているつもりなのですが、今回はogpの設定をして、DeveloperページのDebuggerで見て情報が正確に設定されているにもかかわらず。Found」が出る、という謎現象に悩まされました。pdxの記事で全く同じものがあったのですが、向こうでは「IPv6を無効にしたらどうにかなったよ」と言ってる一方、僕の方では無効にしても全く変化なし。}}にしていたのですがdata-hrefの指定がどうも間違っていいた模様。日本語がパスに含まれてるのを気にしてURLエンコードしていたのですが、まさかそれが足を引っ張っていたとは。(ドキュメント見てもURLエンコードについて特に何も書いて無さそうなのですが。)まとめ久々にゼロの状態からインフラ、DB、アプリケーションの実装まで全部実装したのですが、いい勉強になりました。インフラ面は現職ではセットアップ周りを自分ですることはここ数年ほとんどなかったので、仕組みを理解するいい機会になったと実感しています。middlemanは相当使いやすく便利な一方、少しでも凝ったことをしようとするとハマるポイントも割りとあるので、改めて別途エントリをまとめるなり、プラグイン系へ修正PR投げるなりして貢献したいと思います。