2015-01-04

columnizeを使ってみた[Ruby][irb][Gem]

あけましておめでとうございます！

新年一発目はライトな話題から...

今回はcolumnizeというgemを触ってみてあったら便利な時もありそうだなーと思ったので備忘録として。

<a href="https://github.com/rocky/columnize">rocky/columnize</a>

rocky/columnize · GitHub

どんなgem？

このgemは簡単に言うと配列の中身を見やすく整形してくれるgemです！

デバッグ時などに便利そうなgemですね。

pryでもirbでも問題なく使えたので、そのあたりと組み合わせると幸せになれるかも？

ちなみにgemを知ったきっかけは BestGems -- Ruby Gems Download Ranking をぼーっと見ていて目に止まったからです！

いや〜このサービスは便利＋見ていて楽しいですねｗありがとうございます！

ちなみにこのcolumnizeはtotalランキング122位でした。

インストール

gem columnize

こちらをGemfileに記述してbundle install --path vendor/bundleするか、gemに直接インストールしてしまいましょう。

おしまいです:)

使い方

早速使ってみます。

columnize_sample|⇒ bundle exec irb
irb(main):001:0> require 'columnize'
=> true

requireしてあげることでcolumnizeが有効になります。

当たり前ですがpryを用いてbinding.pry等を行うときは、requireをbinding.pryする以前にrequireしておいてあげればそのまま使用することが可能です。

irb(main):002:0> a = (1..10).to_a
=> [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
irb(main):003:0> a.columnize
=> "1  2  3  4  5  6  7  8  9  10"

columnizeをrequireするとarrayにcolumnizeというメソッドが生えるようになります。

実行すると上記の様に配列が文字列に展開されたような形になります。

この展開の方式をオプションによって変えて、それをputsで表示することで配列をフォーマットしてよしなな形で見れるようにしよう、というのがcolumnizeの趣旨です。

irb(main):004:0> puts a.columnize :displaywidth => 10
1  5   9
2  6  10
3  7
4  8
=> nil
irb(main):005:0> puts a.columnize :displaywidth => 20
1  3  5  7   9
2  4  6  8  10
=> nil

:displaywidthオプションをつけると表示文字列の一行あたりの最大文字数を指定することが可能です。

ちょっとわかりにくいかもしれませんが、例えば一つ目の例での:displaywidth => 10だと、１行あたり10文字まで表示できる状態でいい感じに表示してくれます。このいい感じにっていうのがなかなか賢いですね！2 6 10の並びは8文字ですが、10を指定してもこの様に表示してくれます。

:displaywidth => 20を指定すると、先ほどまでは10文字の制限があって表示できなかった2 4 6 8 10(14文字)を表示できるようになるわけです。

(ちょっと挙動がわかりにくいのは内緒な)

irb(main):006:0> puts a.columnize :arrange_array => true, :displaywidth => 20
[1, 2, 3,  4, 5, 6,
 7, 8, 9, 10]
=> nil

:arrange_array => trueを指定すると、配列の形で吐き出してくれます。

irb(main):007:0> g = %w(bibrons golden madascar leopard mourning suras tokay)
=> ["bibrons", "golden", "madascar", "leopard", "mourning", "suras", "tokay"]
irb(main):008:0> puts g.columnize :displaywidth => 15
bibrons   suras
golden    tokay
madascar
leopard 
mourning
=> nil

中身が文字列でもOKです。

irb(main):009:0> puts g.columnize :displaywidth => 19, :colsep => ' | '
bibrons  | mourning
golden   | suras   
madascar | tokay   
leopard 
=> nil

:colsep => <区切り文字として利用したい文字列>とすると、それで列の間を区切ってくれます。レイアウトをそのままにしたい場合はcolsepの文字数分displaywidthの値を上手く増やす必要があります。(このへんももう少しよしなにできたらなおよさそう)

irb(main):062:0> puts g.columnize :displaywidth => 19, :colsep => ' | ', :ljust => false
 bibrons | mourning
  golden |    suras
madascar |    tokay
 leopard
=> nil
irb(main):063:0> puts g.columnize :displaywidth => 19, :colsep => ' | ', :ljust => true
bibrons  | mourning
golden   | suras   
madascar | tokay   
leopard 
=> nil

:ljustオプションによって左揃えかどうかを選択できます。デフォルトはfalseに設定されています。

irb(main):011:0> Columnize.columnize(a)
=> "1  2  3  4  5  6  7  8  9  10"
irb(main):012:0> puts Columnize.columnize(a, :displaywidth => 10)
1  5   9
2  6  10
3  7
4  8
=> nil

クラスメソッドとして呼ぶことも可能です。

ちなみにputsしないで見てみるとこんな感じです。

irb(main):071:0> g.columnize :displaywidth => 18, :colsep => ' | ', :ljust => true
=> "bibrons  | suras\ngolden   | tokay\nmadascar\nleopard \nmourning"

終わりに

実データっぽいものをサクッと扱いたいときなどに知っていると楽ができそうだなぁという印象のgemでした！

今回の物は割りと有名そうでしたが、このようにいろんなパッと出会ったgemを触ってコードも読んでみたりするのも楽しそうだなと感じました！

gem reading習慣の機運？ｗ

2014-12-28

TravisCIを使ってRubyプロダクトをCIしてみた[TravisCI][Ruby][Rspec][Github]

年内最後の記事の予感ｗ

今回はずっと名前だけは知っていたのですが手はつけずだったTravisCIを触ってみたのでメモ。

結論から言うと超絶楽ちんにCIできたのでpublicなプロダクトでは積極的に使っていこうと思いましたｗすごい楽ｗ

今回はCIについては説明は省きます〜。おググりくださればと思いますmm

Travis CI - Free Hosted Continuous Integration Platform for the Open Source Community

デザインもとてもシンプルで綺麗です:)

インストール

...そんなものはなかった←

強いて言えばプロダクトに.travis.ymlというファイルを設置するくらいです。あとはcliなgemもあるので必要に応じて入れれば使えますがなしでもOKです。

使えるようにするまでの数ステップ

Githubにリポジトリをpush

GithubにCI対象のリポジトリを作成/pushしておきます。

ちなみにpublicならばTravis CIの使用は無料、privateだと有料になる課金形態です。

Travis CIにログイン

TravisCIにログインです。新規登録なんてないです。カジュアル。

Githubのアカウントでのログインを行えば終了です！

f:id:shiro_goma:20141228011527p:plain

CI対象のリポジトリを選択

Githubのアカウントを用いたログインを行ったので、TravisCIとGithubが紐付きました。

ここからCIする対象のリポジトリを選んでいきます。デフォルトは全てのリポジトリのCI設定はoff(CIしない)になっています。

右上の自分のアイコンから、"accounts"メニューを選択します。

f:id:shiro_goma:20141228011520p:plain

そうすると、次のようなページに遷移します。

f:id:shiro_goma:20141228011807p:plain

ここに自分のGithubのリポジトリが一覧となって表示されているので、CIしたいリポジトリを選択していきます。

f:id:shiro_goma:20141228011504p:plain

今回は僕は"travis_sample"リポジトリのみを有効にしました。

これで画面的な設定はおしまいです！本当に短い！

対象のリポジトリに設定ファイルを置く

対象のリポジトリのプロダクトルートに、.travis.ymlというファイルをおきます。

今回は言語はRuby、テストライブラリはRspecを使用しているので、以下の様な設定ファイルを準備しました。

language: ruby
rvm:
  - 2.2.0
script: bundle exec rspec
gemfile:
  - Gemfile

このあたりの記述方法は、サイト内のDocsに載っているので参考にしてください。

Travis CI: Travis CI Documentation

設定ファイルの検証を行うこともできますので活用してみてください。

Travis CI: Validate your .travis.yml

これで設定自体はおしまいです！

これだけでリポジトリにpushされる度に自動的にテストが走り結果がTravisCI上で確認できたり通知が来たりするようになりました！超簡単！

TravisCI上からCI状況を確認する

ここまでやってきた設定だけでいろいろな情報が確認可能です。

最新のビルド状況や、

f:id:shiro_goma:20141228011453p:plain

全体のビルド履歴、

f:id:shiro_goma:20141228011413p:plain

Pull Requestごとのビルド履歴、

f:id:shiro_goma:20141228011429p:plain

ブランチごとのビルド履歴、

f:id:shiro_goma:20141228011443p:plain

といったような情報がコミットがpushされたりPull Requestが発行されたりと各フックポイントに触れる度にビルドを勝手にしてくれます。

もちろん設定に応じてmasterブランチだけCIを有効にすることも可能です。

READMEでよくみるあいつを表示する

f:id:shiro_goma:20141228013549p:plain

こいつですね。これもTravis CIによるものです。超簡単に出せます。

f:id:shiro_goma:20141228013818p:plain

f:id:shiro_goma:20141228013843p:plain

このフォーム内の文字列をREADME.mdに記述するだけ。

# TravisCIによるビルド状況

[![Build Status](https://travis-ci.org/gomachan46/travis_sample.svg?branch=master)](https://travis-ci.org/gomachan46/travis_sample)

おしまい。

今回は使っていませんが以下のツールを使うとテストのカバレッジを出すことも可能です。

<a href="https://coveralls.io/">Coveralls.io - Test Coverage History and Statistics</a>

Coveralls - Test Coverage History & Statistics

まとめ

とりあえずこの記事を書く時間の方が数倍長いくらいには導入が簡単でした！本当素晴らしいです。

積極的に使っていこうと思えるツールでした:)

2014-12-19

チームでSymfony2を半年使って感じたメリット・デメリット[PHP][Symfony2]

この記事はSymfony Advent Calendar 2014 19日目の記事です。

はじめに

今年新卒として配属されてからエンジニア4人のチームで半年ほどSymfony2を使って開発をしてきて、Symfony2で良かった(メリット)と感じた所や、こういう時辛いねー(デメリット)と感じた所がいくつか見えてきたので、まとめようと思います！

使おうかどうか迷っている人などの参考になればと思います。

メリット

まずはメリットから。良い所がたくさんありました！

部品の再利用性が高い

Symfony2は本当に疎結合に徹底した思想だなと感じました。 Symfony2はいわゆる「フルスタックフレームワーク」のイメージが強いですが、その他のプロダクトにもぶちこめるほどのパーツ単位のものが組み合わさってフルスタックな形を実現しています。

なので、そういったSymfony2が提供しているコンポーネントのごく一部を組み合わせて作成した機能なら例えSymfony2を使っていない他のプロダクトでもその機能を移植可能な時もあったりします。

そういった再利用性が高いのはとても素晴らしいメリットだなと感じました。

利用者が多いが故に神Bundleが転がっている

有名なフレームワークなだけあって、とても強力なプラグイン的ポジションのBundleが既に豊富に作成、公開されています。

これらを用いることで不要な車輪の再発明は抑えられ、開発スピードを上げることができますし、利用者も多いので枯れ方も良い感じになっています。

<a href="http://qiita.com/ochi51/items/7c56dc8ecdeb69449370">Symfony2 - The 30 Most Useful Symfony Bundles - Qiita</a>

Symfony2 - The 30 Most Useful Symfony Bundles - Qiita

や

<a href="http://knpbundles.com/">Discover 2450 bundles for Symfony2 | KnpBundles</a>

Discover 2450 bundles for Symfony2 | KnpBundles

を見ると使えそうなBundleがゴロゴロしているので、ニーズに合わせてがんがん使ってみると良いと思います。

個人的なお気に入りは doctrine/DoctrineMigrationsBundle · GitHub で、デフォルトのDoctrineの提供するマイグレーション機能をより便利にしてくれる素晴らしいBundleなので、是非使ってみてください。

あと、Advent Calendar 16日目に公開されていた

<a href="http://www.karakaram.com/symfony2-alice-bundle">[Symfony] AliceBundleで自動テストのfixtureをyml化しよう</a>

[Symfony] AliceBundleで自動テストのfixtureをyml化しよう | karakaram-blog

にて紹介されていたAliceBundleも使っています。便利なので上記記事を読みながら是非使ってみてください！

ファンクショナルテストが書きやすい

Symfony2はデフォルトでクローラー等込み込みのテスト用Clientを提供してくれています。これを用いることによって割と素直にファンクショナルテストを書くことができます。

詳しくは以下が参考になると思います。

テスト | Symfony2日本語ドキュメント

型がしっかりついているので追いやすい

Symfony2に従っていくと、自然とほんのりJavaの匂いを感じる型が意識されたコードになっていきます。

PHPの動的な型を生かしつつ型の恩恵も自然と受けられるようになっていくので良いです。

PhpStormを使っているとジャンプ機能など更に型の恩恵を受けやすくなっていくので一石二鳥といったところでしょうか。

フレームワークのソースが読みやすい

プロダクトの規模もクラス数も尋常じゃないですが、型+PhpStormのおかげもあってか「なにしてるんだここ...」とか「処理が追えない...」みたいな詰まり方はこの半年ではそこまで多くない印象でした。コード自体もしっかりと保守されているのが伝わります。

これは使いはじめる前までとは印象がかなり違った部分だなぁと思っていて、使うまでは「Symfony2は巨大すぎてどこで何が起きているかまるでわからなくなりそうだ...」みたいなイメージだったのですがそうでもなくて良かったです。

イベントが多く用意されているので差し込みやすい(知らないときつい)

Symfony2の使わないとなかなか知られざる超強力な武器だなと感じた点として、EventListener層が確立されている点が挙げられます。

requestやresponseやExceptionといった様々なイベントが用意されていて、それらが起きたことを検知してほげほげ処理ができる機構が備わっています。

これがとても便利で、いろんなところにフックポイントが存在するので、例えばユーザ認証といったものをいちいちControllerに書くのではなく、Controllerに達する前のEventで処理してしまうのです。

こうすると再利用性は高いですしController内は汚れず綺麗。素晴らしいですね！

また貫通してきた全例外をひっつかまえる、なんてこともEventListenerで簡単に行えるので、ログを残したりメールを飛ばしたりしてから死んでもらう、みたいなのも一箇所に集約できるので各例外発生ポイントで無理に例外をcatchすることもなくスッキリできます。

この辺りにイベント周りの情報が掲載されています。

内部構造 | Symfony2日本語ドキュメント

フォームの構成を自由にカスタマイズし易い(出したいものだけを出したりできる。)

Symfony2ではTypeという簡単に言うとフォームに載せる要素の選別を行うクラスがあります。

ここで柔軟に出し分けを行うことができるので、「テーブルのこのカラムは出したくない」といったニーズに簡単に答えられます。

また、実際に描画をする際にも、フォームのラベルだけを表示したり、エラーだけ表示したり、といった様に表示するものを小分けにもできるので、デザインの調整なども可能です。

そこまで凝ったviewを作るようなプロダクトではなかったのも有るかもしれませんが、シンプルに使えるのでなかなか使い心地は良かったです。

プロファイラーの助けがあるためデバッグし易い

Symfony2はプロファイラーというデバッグツールがついていて、これが非常に使い勝手が良かったです。

投げられるクエリやクエリ数もわかりますし、そのクエリのexplainなども画面上から簡単に確認できます。

また、2.4以降からはFormの情報もProfilerに乗るようになり、どんなinputだったかだったりどんなバリデーションにひっかかったとかもすぐわかります。

エラーログもProfilerから確認できるので、いちいちログをあさらなくても大丈夫だったりしてとても気が利いていました。

Symfony2のアップデートスケジュールがしっかりしている。

機能面ではないのですが、実践登用する上でのメリットになるなぁと強く感じたのがサポート期間です。

使ってたのにいきなり仕様が大変更されたつらい！みたいな状態になると笑えませんよね。

そこでSymfony2はサポート期間をはっきりと明記しています。

リリースプロセス | Symfony2日本語ドキュメント

上記リンクのリリースプロセスを初めから考慮出来るので計画的なアップデートを行うことが可能です。

この手厚いフォローは業務で使うとなると嬉しいのではないかなぁと感じました。

Bundleも含めカスタマイズをし易い(Symfonyがデフォルトで用意している)

完成品に見えるBundleも、実は継承して一部だけ上書き、みたいな芸当ができます。

便利な機能をあやかりつつここだけはプロダクトにfitさせたい、みたいなこともできて便利です。

バンドルの継承を使って既存のバンドルのパーツを上書きする方法 | Symfony2日本語ドキュメント

DQL使っているので、保守性は高い

少し癖があって(癖というかMySQLに慣れていると〜がない！つらいみたいな)ハマったりしますが、DQLで書いておけばもしDB変えるとなっても大丈夫なので、強くはなります。

Bundleという概念があるため依存関係を把握し易い(相互依存は明らかにおかしいと判断できる)

Bundleをいくつか組み合わせてアプリケーションを作っていくので、自然と基底Bundleみたいなのを作りたくなってきます。(共有できる再利用性の高いものをいれておくBundleとか)

たとえば汎用的なAというBundleの中で、Aを用いて機能を作っていっているBというBundleが使われていると、相互依存となって、使われ方がおかしいのがすぐ分かります。

レビュー時なども、ファイルのuseを見れば依存関係がまずいことになっていないかはすぐにわかります。

こういったように依存関係のピラミッドが見えやすくなっている構成は間違いを生みにくいメリットになるなぁと感じました。

コンテナを利用していることで依存性の解消が簡単

Symfony2はサービスコンテナを提供してくれていて、クラス間の依存関係をよしなに解消してくれてから取り出すことが可能になっています。

このようにコンテナを利用すると自然とDIするというレールに乗っかってくるので、差し替えが非常にしやすくなりテスト時など助かります。

DIしていく思想に慣れるとだいぶ使いやすくていいなぁと思いました。

PhpStormとの連携がイケてる

これはSymfony2というよりPhpStormの話になりそうですが、とにかくSymfony2とPhpStormの相性が抜群に良いです。

Symfony2を書くときは確実にPhpStormを使う方が幸せになれると思います。(賢いジャンプ機能やサービスコンテナ、twig、Symfony2の提供するコマンドの補完等々幅広くサポートが効いています)

コードリーディングの時だけでもいいので使ってみると便利さが伝わるかと思います。

デメリット

次につらみ成分の紹介です。そこはこうすれば上手く立ち回れるよっていうのがあれば教えていただけたら助かります！

レールがないぶん、外注する時のルールを伝えるのが大変(自由にできすぎる)

Symfony2は「部品置いておいたから後は好きに使って」と言ったイメージで、かなり自由に作ることができます。

その分、チーム開発の際はメンバー内のルールが固まってこないと、色々な記法で書かれた色々が点在する形になってカオスになってきてしまいます。

なので走りながらでもいいと思うのでチームでの共通認識を持ってレールを敷いていく必要ががあるなぁと感じました。

また、これがデメリットとして顕著にでたのが外注時で、ちゃんと依頼を投げる前にレールを敷いて置かないと好き勝手にかかれたSymfony2プロダクトができてしまいます。(もちろんコーダーのスキルにもよりますが)

散らばらないように、いくつかSymfony2から出されたレールの敷き方の選択肢から、チームで１つの解答をしておく必要があると思いました。

共通部品が出来上がるまではコード書く量が多い

中盤以降は再利用が出来る所が増えてきてスピードが乗ってきた(というか普通は落ち始めるところがあまり変わらない)のですが、やはりいかんせん初期はSymfony2が提供してくれている便利なコンポーネント群の存在に気が付かなかったり、型を意識した結果ファイル/クラス/コード量が増えて実装に時間がかかる、といったフェイズがありました。

また、Symfony2が採用しているDoctrineは薄めのORMを積んでいて、それが薄いためテーブル内レコード数のカウントも手実装をしなくてはなりません。

このあたりも実装してしまえば次からは早いのですが初期のコストとしてかかってきて少しつらいねーという話がでました。

管理画面を自作せざるを得ない

今回携わったプロダクトの性質上、というのもあったかもしれませんが管理画面は結局自作する方向になりました。

sonata-project/SonataAdminBundle · GitHub という管理画面作成用のBundleもあったのですが、学習コスト及び変更時につらみがありそうだ、というところで使用する選択をとりませんでした。

もう少し取り回しの良い軽いAdminBundleがあればいいなぁと感じました。(とはいえ主観ですしSonataをゴリゴリ使ってもいないので説得力にかけます)

interfaceでの型縛りのため、実体が見えづらい

思想上interfaceをよく使うのですが、これを使うようになると確かに利用者側はそのinterfaceだけ知っていれば良いのでより疎結合な良い感じに実装することが出来るのですが、PhpStormでジャンプした時にInterfaceに飛んでしまう、といった様に実体が良くも悪くも隠れてしまって開発効率が落ちます。

interfaceをimplementsしているものから見たい実体を選んで飛びなおすことはできるのですがやはり手間取りました。

キャッシュ問題にはまりやすい

Symfony2あるあるのハマりどころとしてあげられるのが「キャッシュ問題」だとおもいました。

設定にもよりますが何から何までキャッシュして動かすので、ソースコードを修正したり設定ファイルを修正したりしてもそのままでは動作が変わりません。

なのでそういった変更の度にキャッシュが絡んできてしまいたまに思わぬ落とし穴にハマってしまったりしました。

とはいえでその作成される巨大キャッシュのおかげでフルスタックの中ではパフォーマンスが良いフレームワークとなっているので、仕方ないとは思っています。

テンプレートのカスタマイズがちょっと辛い

Symfony2はデフォルトのテンプレートを提供してくれています。

そのデフォルトのテンプレートの一部を修正してcssを当てはめたりということが可能です。

フォームのレンダリングのカスタマイズ方法 | Symfony2日本語ドキュメント

一部分を割とシンプルに拡張できてとても素晴しいのですが、そのデフォルトのテンプレートはSymfony2のバージョンに依存します。

つまりバージョンを上げると、仕様がゴリッと変わっていることもあります。

仕様が変わっているところに対して古いバージョンのテンプレートにもとづいて拡張した部分があるとすると、その部分は仕様変更に追従できずバグってしまいます。

そのためメンテナンスコストがかかりはじめてしまい少し辛そうに思いました。

おわりに

色々箇条書きでガーッと書いてみましたが、使用感は個人的にはとても良かったです！

これからも引き続き使っていって見たいと思います。

2014-12-12

ターミナルで遊べる音ゲー作ってみた

この記事はVOYAGE GROUP エンジニアブログ Advent Calendar 2014の12日目の記事です！

こんにちは！@gomachan46です。

VOYAGE GROUPの新卒エンジニアとして日々楽しみながらお仕事しております。

社内にて密かに活動を続けている音ゲー部の部長をやっております！

少し前にVOYAGE GROUP エンジニアブログ : あなたにおすすめするたった一つの最高のキーボードとかいうエントリを上げたところ、社外の方からも「音ゲーの人だよね？」とわかってもらえるようになりました。

さて、今回はちょっとした休憩中でもさっと~~お仕事をしていると見せかけて~~「ターミナルでプレイできる音ゲー」を作ってみようと思います！

もちろんこの間紹介したキーボードでもプレイ可能です:)

音ゲーとは

簡単にいうとリズムに合せて作成された譜面の通りにボタンを押して遊ぶゲームです。

f:id:shiro_goma:20141212053111p:plain

作ってみる

今回作るのに使ったものはざっと以下の通りです。

Burn
afplay
Karabiner

Burnとは

remore/burn · GitHub

8bit風なゲームをRubyで簡単に作ることができるようになるフレームワークです！

Rubyist Magazine - 8-bit風ゲームをつくるフレームワークburnの紹介こちらを読んでいただけるとどんなものかわかるかと思います。

このBurnは以下の2種類の方式で8bitゲームを作成することができます。

:rom mode ROMを作成してブラウザにてゲームを楽しめるようになります。
:telnet mode telnetによってターミナルにてゲームを楽しめるようになります。

今回は何が何でも「ターミナルで音ゲーがしたい！」ので、後者の:telnet modeで実装をしました。

afplayとは

Mac OSにデフォルトで入っている音楽再生コマンドです。

Burnの:telnet modeだとどうにも上手く音声が再生されなさそうなので、今回はこちらのafplayコマンドを併用して音ゲーを作ってみました。

demo

こんな感じです！(音楽は諸々を考えて無しにしました)

ターミナルでプレイできる音ゲー作ってみた - YouTube

これはターミナルですよ〜telnetですよ〜←

プレイに当たって困ったこと

telnetなのでEnterを押さないとユーザのキーボード入力が送信されない

ユーザのキーボード入力を有効にしなければ音ゲーができないので、有効にするのですが、telnetなので情報を送信するためには「送信したいキー+Enter」を押さないと送信したいキーの情報が送信できません。

これでは4分のリズムでも8分で叩かなきゃいけないという鬼畜な感じになってしまいます。

そこで、Karabinerを用いて特定のキーのみ「押された直後にEnterを押す」設定を施しました。

Karabinerでは独自のキー設定に際してはprivate.xmlというファイルを編集する必要があるのですが、以下のようにしました。

<?xml version="1.0"?>
<root>
  <item>
    <name>otoge_burn</name>
    <identifier>private.otoge_burn</identifier>
    <block>
      <autogen>
        __KeyToKey__
        KeyCode::Q,
        KeyCode::Q,KeyCode::RETURN
      </autogen>
      <autogen>
        __KeyToKey__
        KeyCode::D,
        KeyCode::D,KeyCode::RETURN
      </autogen>
      <autogen>
        __KeyToKey__
        KeyCode::R,
        KeyCode::R,KeyCode::RETURN
      </autogen>
      <autogen>
        __KeyToKey__
        KeyCode::F,
        KeyCode::F,KeyCode::RETURN
      </autogen>
      <autogen>
        __KeyToKey__
        KeyCode::U,
        KeyCode::U,KeyCode::RETURN
      </autogen>
      <autogen>
        __KeyToKey__
        KeyCode::J,
        KeyCode::J,KeyCode::RETURN
      </autogen>
      <autogen>
        __KeyToKey__
        KeyCode::I,
        KeyCode::I,KeyCode::RETURN
      </autogen>
      <autogen>
        __KeyToKey__
        KeyCode::K,
        KeyCode::K,KeyCode::RETURN
      </autogen>
    </block>
  </item>
</root>

これでキーを押すだけで送信できるという状態を擬似的に作ることができ、快適なプレイになりました！

音ズレ

やはり最後まで悩まされたのが処理落ちによる音ズレで、機構としてひたすらBurnを用いた音ゲー関連の処理を1フレーム毎処理を行いつつ、別プロセスでただafplayを実行しているだけなので、Burn側が少しでも重くなるとだんだんとずれていきます。つらいｗ

まとめ

ソースは闇を抱えていますがこちら

ターミナルでやろうとすると恐ろしく制約が入りますが、やっぱり夢があって楽しい！✌('ω'✌ )三✌('ω')✌三( ✌'ω')✌

とりあえずターミナルの割にヌルヌル動いてくれたので大満足です。

この調子で色々夢のあることをやれたらいいなぁと思っています！

明日は新卒研修時にもお世話になった@TachibanaKaoruです！楽しみですね！

2014-11-09

tmuxinatorで快適なtmux生活を！[tmux][tmuxinator][Ruby]

以前からものは知っていて気になってはいたのですがやっと使えてとても便利だったのでまとめようと思います。

なお、tmuxに関しては今回の記事としてはおいておくこととします。使ったことが無い方は是非使ってみてください！便利です。

tmuxinatorとは

tmuxinator/tmuxinator · GitHub

tmuxinatorは、簡単にいうと「好きなtmuxの画面構成をいつでも瞬時に構築できるようにする」ツールです。

これさえあればいつでもすぐに自分にとって最適な画面分割にできますし、加えてコマンドの実行までできます！素晴らしいです。

早速導入してみましょう。

インストール

インストールには以下のコマンドを叩きます。

$ gem install tmuxinator

これでインストール自体はおしまいです！

簡単な設定

エディターの設定

エディターを用いるため、環境変数をexportしておきます。

$ export EDITOR='vim'

シェルの設定

まずはtmuxinator用のディレクトリを作成します。

$ mkdir ~/.tmuxinator

shellに応じた設定ファイルを https://raw.githubusercontent.com/tmuxinator/tmuxinator/master/completion/ からダウンロードして、shellに反映させます。

zshの場合、以下のようにします。

$ export SHELL='zsh'
$ wget https://raw.githubusercontent.com/tmuxinator/tmuxinator/master/completion/tmuxinator.zsh
$ mv tmuxinator.zsh ~/.tmuxinator/
$ echo 'source ~/.tmuxinator/tmuxinator.zsh' >> ~/.zshrc

ここまで出来たら、インストールは完了です。次のようにコマンドを実行すると、インストールが正常にできているかどうかをチェックすることができます。

$ mux doctor

Checking if tmux is installed ==> Yes
Checking if $EDITOR is set ==> Yes
Checking if $SHELL is set ==> Yes

全部Yesになっていれば準備OKです！

使ってみる

いよいよ実際に使ってみましょう。

tmuxinatorのプロジェクトを作成する

次のコマンドを実行すると、tmuxの設定をひとまとめにするプロジェクトを新規作成することができます。

$ mux new [プロジェクト名]

例えば、

$ mux new sample

としてみます。

実行するとまずエディタが立ち上がりますが、一旦そのままcloseしましょう。

エディタが編集しようとしたものがtmuxinatorのプロジェクト設定ファイルで、~/.tmuxinator/sample.ymlとして保存されています。

このファイルを好きなように編集すれば好きな様にtmuxを操ることができます！

プロジェクト設定ファイルを編集する

設定ファイルを編集するには、以下のコマンドを実行します。

mux open sample

まぁ普通にエディタで開いてもOKです。

# ~/.tmuxinator/sample.yml

name: sample # プロジェクト名を記述します
root: ~/ # rootディレクトリの指定します

# Optional tmux socket
# socket_name: foo # tmuxのソケットの指定が必要な場合に使用します

# Runs before everything. Use it to start daemons etc.
# pre: sudo /etc/rc.d/mysqld start # tmuxinator実行時に実行するコマンド群を記述します。複数行でも大丈夫です！
# pre:
#   - hoge
#   - fuga
#   - foo
#   - bar

# Runs in each window and pane before window/pane specific commands. Useful for setting up interpreter versions.
# pre_window: rbenv shell 2.0.0-p247 # pre: のwindowやpaneを開く直前バージョンです

# Pass command line options to tmux. Useful for specifying a different tmux.conf.
# tmux_options: -f ~/.tmux.mac.conf # tmuxコマンドを実行するときにオプションを設定しておくことができます

# Change the command to call tmux.  This can be used by derivatives/wrappers like byobu.
# tmux_command: byobu # 呼び出されるtmuxコマンドを変更することができます。 tmuxではなくbyobuを使いたいときなどに使用します。

windows: # ここの下にwindowの設定を並べていきます。
  - editor: # windowに名前を付けます
      # tmuxのlayoutを指定できます。(ex. main-vertical、tiled)
      # tmuxのlist-windowコマンドで表示された数値をコピペることでの指定でもできます (ex. 8b89,238x56,0,0{118x56,0,0,0,119x56,119,0,5})
      layout: main-vertical
      panes: # ペイン分割を行います。各ペインに対してそれぞれ好きなコマンドを実行できます！
        - vim # vimを実行したり、
        - guard # guardを実行したり。
  - server: bundle exec rails s # 2つめのwindowの設定を書きます。 ペイン分割等がなければそのまますぐにコマンドをかけばおしまいです。
  - logs: tail -f log/development.log # 3つめ。

このような設定項目があるので好きなtmuxの設定にしていきます。終わったら保存して終了。

tmuxinator発動

プロジェクト設定ファイルの編集が終わったらいよいよ起動です！

$ mux sample

このコマンドを実行すると先ほど書いたプロジェクト設定ファイルを元にしてtmuxが立ち上がり、いつでも好きなレイアウト&実行してほしいコマンドが全て実行されたtmuxが手には言います！！

立ち上がった時はめちゃくちゃ便利！と思うこと間違いなしです:)

終わりに

tmuxinatorはちょっと使い方を覚えるだけでめちゃくちゃ便利になるので相当助かります。例えば

仕事用プロジェクト
趣味用プロジェクト
複数台サーバ用プロジェクト

などといった様にプロジェクトを分けたりするとより捗るかな、と思います。

list-windowの値を用いる事によって複雑なペイン分割にも対応できているのはすごく嬉しいですね。

tmuxinatorで、快適なtmux生活を！

2014-10-10

phpDocでarrayの中身を明示する[PHP][PHPDoc]

軽いTips共有を。

皆さんPHPDoc、書いてますでしょうか？

IDEとかだと特にジャンプ力や補完等もより効くようになるしそもそも親切なコードになると思うので割と積極的に書くようにしています。

今回はそのPHPDocがらみで知った小ネタのご紹介です。また、今回はPHPDocではなくphpDocumentor前提な話で行こうと思います。あしからず。

phpDocumentor - PHPDocに代わるAPIドキュメント自動生成ツール - Do You PHP? このあたりが参考になるかと思います。

まぁしばしば配列を引数に取ったり変数に格納したりしたい場合がありますよね。

そういう時、今までは

<?php

/** @var array $hoge */
$hoge = [1,2,3,4,5];

//とか

/**
  * @param array $hoge
  * @return array
  */
public function fuga(array $hoge)
{
    return $hoge;
}

とか書いていたのですが、これだとarrayの中身はなんだよってなりがちです。

実はphpDocはこの悩みを一応サポートしていて、次のようにかけます。

<?php

/** @var int[] $hoge */
$hoge = [1,2,3,4,5];

//とか

/**
  * @param int[] $hoge
  * @return int[]
  */
public function fuga(array $hoge)
{
    return $hoge;
}

参考: http://www.phpdoc.org/docs/latest/guides/types.html#arrays

地味によく遭遇するので、使ってみると良いかもしれません:)

2014-09-25

EC on Rails！Spree使ってみた[Rails][Ruby][Spree]

RubyでECサイト作るとしたらどんな流れになるんだろうなーと興味本位で調べて行ったらSpreeというECサイト構築用フレームワークが見つかったので試してみました。

Spreeって？

Rails上で動くECサイト構築用フレームワークです。

spree/spree · GitHub

日本ではまだまだあまり事例がないようですが、海外では人気があるとのこと。

日本だとメガネ通販(眼鏡・めがね)のOMG(オーマイグラスィズ)さんが使われているとのことです。

使ってみる

githubのREADMEを見つつ、インストールしてみます。

前もって、環境としてImageMagickが必要との事なので、入れておきます。

まずはRailsプロジェクトを作成。

rails new myway -T -d mysql --skip-bundle

とかで。

Gemfileに以下の2つのgemを追加。

gem 'spree', github: 'spree/spree', branch: '2-3-stable'
gem 'spree_auth_devise', github: 'spree/spree_auth_devise', branch: '2-3-stable'

spree本体のgemと、spreeの認証周りのgemを入れます(spree_auth_deviseは入れなくても本体は動く)

そしてbundle install！

bundle exec --path vendor/bundle

これで一式gemが入ったら、次のコマンドでspreeをrailsプロダクトにインストール。

bundle exec rails g spree:install --migrate=false --sample=false --seed=false

DBマイグレートやseed生成、サンプルデータインサートを回避したければこのコマンドを叩く。

回避した上でやれたければ次のように叩く。

bundle exec rake railties:install:migrations
bundle exec rake db:migrate
bundle exec rake db:seed
bundle exec rake spree_sample:load

また、

At this point, if you are using spree_auth_devise you will need to change this line in config/initializers/spree.rb:

とあるので、config/initializers/spree.rbを以下のように編集する。

Spree.user_class = "Spree::LegacyUser"

から、

Spree.user_class = "Spree::User"

へ。

サーバ起動。

bundle exec rails s

立ち上がったサーバー(自環境だとlocalhost:3000)にアクセスしてみる。

f:id:shiro_goma:20140925000903p:plain

！？

も、もうなんかそれっぽいものができてる...！

更にlocalhost:3000/adminにアクセスすると...？

f:id:shiro_goma:20140925001704p:plain

ログイン画面が出て...？ログインすると...？

f:id:shiro_goma:20140925001725p:plain

ひっ...なんか管理画面っぽいものが...！

もうちょっとデザインとか手を入れたらそのまま稼働できそうな勢い...

いきなり出来過ぎて紹介しきれていないですが、フロント側の画面的にはすでに商品選択->クレジットカード決済もしくは現金払い選択->住所入力->配送手続き完了といった一連の流れがすでに出来るようになっています。

カート機能も実装済み。

恐ろしい...

管理画面側も注文情報管理、商品情報管理、売上レポート管理、サイト情報設定管理、プロモーション管理(クーポン)、ユーザ管理といったECサイトっぽい機能がもうひと通り揃っています。

とりあえずコードに一切触れずにこんな展開になったので何がなんだかといった感じですが、理解できれば非常に強力なことはよくわかりました。

spreeのコードは./vendor/bundle/ruby/version/bundler/gems/下に置いてあるので、じっくり読んでいきたいと思います。

とりあえず今回はここまで。ひとまず感動いたしましたmm