フライパンとmagsafe2コンバータを書いました

家のフライパンが痛んできたので、奥さんが気にいっていた北陸アルミのフライパンを買いました。

今使っていたのは結構長いこともったので、これも長く使えるといいなー。

あとは、毎日PCとアダプタを持ってかえっていたのですが、部屋を見まわしたら文鎮化しているMacBookPro(mid2009)があったのでmagsafe2コンバータを購入してQoLを向上させました。荷物が軽くなってめっちゃ快適です。AmazonよりApple Storeのほうが安かったのでこちらで。

MagSafe - MagSafe 2コンバータ - Apple Store(日本)

第6回 コンテナ型仮想化の情報交換会@東京 に参加してきました

昔LXCで遊んでいたことあるんですが、最近Dockerを本格的にいじりはじめてから、このあたりの知識の足りなさを感じていたので、最近のナウいトピックを知りたいと思って参加してきました。

というかんじなので、理解できていない、間違っている部分が多々あるかと思いますので、ここ違うんじゃない?というところがある方はぜひ下のコメント欄でも、ブコメでもいいので教えていただけると喜びます。

資料などは 第6回 コンテナ型仮想化の情報交換会@東京 - connpass からどうぞ。

Cluster Schedulerの紹介

GoogleのOmega(OSSではない)というCluster Schedulerの論文を中心に、Cluster Scheduler の分類と歴史、Googleがなぜ新しいスケジューラを開発しているのか、その問題意識などをまとめたという感じでしょうか。Cluster Schedulerってなんぞ?というところからでしたが、なんとなくわかった気になれる内容でした。

クラスタリングスケジューラが管理するジョブの種類はバッチジョブとサービスジョブがあって、Googleの場合だと

  • 割合からするとバッチジョブが全体の80%
  • リソース面ではサービスジョブが全体の50-80%を利用する

というような状況らしく、これらをより効率よくスケジューリングするために新しいスケジューラを開発しているとのこと。ジョブの特性を考慮してスケジューリンするような仕組みが、既存のものでは実現できないという風に読んだのですがあってますかね…

Debian GNU/kFreeBSDにおけるJail構築を試してみた

Debian/kFreeBSD という FreeBSDカーネルの上で動くDebianでJail環境を構築してみたという話。

debootstrap という最小のディレクトリツリーをダウンロードできる便利コマンドを知れたし、それはDockerでも使ってるんだよーというTwitterを見てんなるほどーという感じでした。

で、Debian/kFreeBSD でJail環境を作るメリットとしては、

  • カーネルがFreeBSDなのでFreeBSDのコンテナが動く
  • もちろんDebianも動く
  • Crossdebootstrapでクロスコンパイル環境を作ることもできる

というあたりらしいです。なるほどー。

今日から触れる Solaris Zones 入門

Solarisと言えば、大学の教授が「サーバと言えばSolarisでしょ」と言い初めてSPARCマシンを突然購入して押し付けられたけど何もできずに、数週間後にLenovoのサーバを買ってもらってDebianを入れていた記憶が思い出されます。

それはそれとして、SolarisにもZoneというコンテナ技術があって、オラクルのサイトからVirtualBoxのVMをダウンロードすればなんと無料で試すことができます。

リソース管理機能を使ってコンテナにも関わらず物理CPUをわりあてたりできるとのこと。

Solarisは、ものすごく古いバージョンでコンパイルしたバイナリも新しいOSでちゃんと動くそうで、そういう古いバイナリの実行環境を隔離するためにZoneが使われたりするらしいです。

OpenVZ Update

個人的なベストトークでした。

https://stats.openvz.org にOpenVZを使っているユーザの統計情報があつまっていて、これは自動で送られるようになってるんですかね?Gentooが4位というのがびっくりしました。

OpenVZはオープンソースだったものの、実際はParalles Clound Serversからのバックポートが多くて、関係者以外はコントリビュートしにくい状況だったそうです。それを一変させようと、OpenVZのソースコードとPCSのソースコード(の一部)をマージして公開するよ宣言があったとのこと。

PCSは3つのモジュールから構成されるんですが、その中のストレージ部分は商用アドオンのまま、他の部分はほぼマージするそうで、大胆な戦略だなーと思いました。

で、マージされる部分にはコンテナとハイパーバイザの両方を透過的に扱うための仕組みも含まれるそうで、数週間前にはOpenVZ上でDockerコンテナが動いたとのこと。

さらにOpenVZのlibctとlibcontainerが統合されることがDockerConで発表されていて、それによってDockerはCRIUが利用できるようになり、OpenVZはDockerコンテナが動くようになるというメリットがあるそうです。(CRUIについてはあとのLTで)

スライドの18枚目が衝撃で、libcontainerがカーネルとコンテナの間を橋渡しするので、lxcもDockerもvzctlもできるようになる、と。

ただ、まだマージは今がんばってやってるところなので乞御期待。

LXC Update

LXC 1.1ではCRUI(まだでた!)よる新機能が入ったのと、initにsystemdが使えるようになったとのこと。

ほかには、LXDというREST APIの受け口ができて、LXCコマンドでリモートのコンテナも操作できるようになったそうです。

LT3本

Amazon ECS

まだプレビュー版なので、申請してしばらく待つと使えるようになるそうです。

試してみた系の記事がいくつかあるから、それをやってみて雰囲気を掴んでみるのよさそうとのこと。

ノートPCにOpenStack

Ubuntu OpenStack Installerを使えばスペックさえあればノートPCでOpenStackが!

プロビジョニングにはJujuとMAASというを使っているそうなのですが、まったく知らなかったのであとで見てみようと思いました。

CRIU

OpenVZでも話に出ていたCRIUですが、コンテナのプロセスをダンプ、リストアする仕組みだそうで、これを利用してライブマイグレーションが実現できるようになるとのこと。

コンテナのライブマイグレーションができるようになると、可用性と集約率が向上するので、DockerコンテナでCRUIが使えるようになると夢が広がる感じでした。

おわりに

正直、なにもわからなかったらどうしようと思いながら参加したのですが、それなりに理解できるところもあり、次に勉強するべきポインタも沢山見付けられたのでよかったです。

スタッフの皆さん、登壇者の方々、会場を提供してくださったIIJさん、ありがとうございました。

Rubyの洋書を読む会「Working with Ruby Threads」

火曜日はRubyの洋書を読む会の日。今年に入ってからは The Pragmatic Bookshelf | Working with Ruby Threads を読んでいます。

今日はGILをもうちょっと詳しくという感じで、別にいじわるをしたくてGILを導入しているわけではなくて、これに私たちのプログラムが安全に実行できて、レースコンディションに関わる複雑なバグが起きないようにしてくれているんだよ、という話でした。

IO待ちになったスレッドはGILを勝手に開放するってのは当たり前なんだろうけどなるほどなーと思いました。

メンテナブルJavaScriptとテスタブルJavaScript

JavaScript関連の積読を2冊ほど消化しました。

どちらも、(少し前の時代の)JavaScriptという言語では、

  • メンテナブル、テスタブルなコードとはどういうことか
  • それらを評価する方法
  • サポートするツール

というあたりがまとまっていて、リーダブルコードやJavaScript:The Good Partsが頭に入っていると、スムーズに理解できそうな内容でした。

ただ、括弧書きにしている通り、特にツール類は一時代前のものが多いので、2015年ならどうだろうと読み替える必要はあるでしょう。

メンテナブルJavaScript

前半はJavaScript:The Good Partsをより実践的にしたような内容で、良いパーツはわかったんだけど、実際に書こうとするとうまく書けないという人には参考になりそうな内容でした。

個人的には10章あたりからが面白かったですね。

JavaScriptにおけるエラーの考え方、テスタブルJavaScriptにも繋がるオブジェクトの結合度、ブラウザ判定を例とした特徴検出と特徴推定など、なかなか興味深い内容でした。

ツールについては、前述の通りちょっと古いので、最近のナウいツールに読み替えたほうがよさそうです。

テスタブルJavaScript

こっちはかなりツールと細かいコードの書き方に寄っていて、時代と個人の趣向に結構依存しそうな内容だと感じました。

今読むなら、それらの詳細から一歩引いて「ソースコードの定量的な評価の方法」として見ると、コードメトリクスからテストカバレッジ、テストコードの分類などきれいにまとまっているのでおすすめです。

特によかったのは「高いカバレッジの値は誤解を招きますが、低い値は明らかに問題を示しています」というカバレッジに対する考え方ですね。

どちらかと言えばメンテナブルJavaScriptがおすすめ

筆者は二人ともYahoo!のフロトンエンドエンジニアとして大規模なライブラリの開発、メンテナンスをしていたということもあり、でてくるコードはYUIの内部のコードだったりとかなり実践的な内容にはなっていますが、いかんせん時代の流れがはやすぎますね。

テスタブルJavaScriptは今読む必要はないかなと思いますが、メンテナブルJavaScriptは今でも参考になるところは多いなーという印象です。

特に、最初に書いたようにJavaScript:The Good Partsやリーダブルコードは読んだけど、実際どうすんのよ、というところに手が届く数少ない本だろうと思いました。

散髪ログ

前回は12月だったのでちょうど2ヶ月くらい。 今回は息子と一緒にいってきた。

いつもは席がけっこう離れるんだけど、空いてたので隣で。トーマスを見ながら静かに切られていた。

バレンタイン

今年も手作りのおかしでした。おいしゅうございました。(この写真とは別に、あまったパイ生地でアップルパイが作られていました)

boot2dockerのIPがVPNのネットワークとかぶってしまった

家に帰ってVPNを繋いでboot2dockerでコンテナを作ろうとしたら、以下のような感じでエラーになってしまっていました。

$ docker build .
Sending build context to Docker daemon
FATA[0032] Post https://192.168.59.103:2376/v1.16/build?rm=1&t=: dial tcp 192.168.59.103:2376: i/o timeout

VPNを繋いだときだけ問題がおきるのと、IPアドレス帯を見てみたところこれはかぶっちゃってるかなーと思い traceroute 192.168.59.103 してみるとビンゴ。VPNのネットワークに吸い込まれていました。

boot2dockerのIPを変える方法は、boot2docker/boot2docker-cli の configration にあるように boot2docker config の結果をファイルに落としてから変更すればよさそうな雰囲気。

実際やってみると、ネットワークの設定は変更してVMの再起動では当然ダメで、VirtualBoxのホストオンリーネットワークを消してから boot2docker delete > boot2docker init として作り直す必要がありました。(自分でホストオンリーネットワークを変更してもいけると思いますが)

IPの設定回りを以下のようにざっくりと変更したところ、VPNを繋いでいても問題なく動くようになりました。めでたしめでたし。

...
HostIP = "172.16.59.3"
DHCPIP = "172.16.59.99"
NetMask = [255, 255, 255, 0]
LowerIP = "172.16.59.103"
UpperIP = "172.16.59.254"
...

幼稚園の発表会を見てきました

息子の幼稚園で発表会があるとのことだったので、今月付与されたばかりの有給を利用して参加してきました。

ダンスや歌、劇など30分ちょっとくらい見てました。

最後に先生も言っていたけど、1年前は入園式で静かに座っていることもできなかった子供達が、これだけできるようになるのは本当に集団生活と先生様々というかんじ。

あと1年、元気に過ごしてくれるといいな。

(運動会ほどは動きがないので写真もそれなりに撮れたような気がします)

SCRUM MASTER’S NIGHT! VOL.7 に参加してきました

午前中は有給をとって息子の発表会を見て、夜はスクラムマスターじゃないけどこれに参加してきました。

テーマ選びでは Regional Scrum Gathering Tokyo 2015: Schedule の 「Scrum or not?」 というパネルディスカッションのテーマを決めるというやつにしました。

ファシリテータは川口さんで、出てきた意見の分類の仕方と流れの作り方はさすがだなーいう感じでした。

肝心のパネルのテーマは(この通りになるかどうかはおいておいて)、各社大規模にスクラムを導入しているけど、最初の導入過程から、レイトマジョリティへの対応、プロセスの効果や評価の方法、そして今後の事へと、特に前半はかなり興味深い内容になりそうでしたので、みなさん Regional Scrum Gathering Tokyo に行きましょう!

結構早めに終わったので、他のテーブルを眺めたり、一緒にいった @kurotaky のお悩み相談テーブルにjoinしたりしてわいわいやっていました。

懇親会ではsushi的なものもあり、DeNA様ありがとうございました!

ハンドメイドマーケット minne でバーンといくぞ!!1

会社の決算説明会でいろいろと発表になったようです。

GMOペパボ、異例の「利益ゼロ」予想 ハンドメイド市場「minne」拡大へ積極投資 - ITmedia ニュース

諸事情でスーツを持っていないために会場には行けなかったのですが、 USTのチャンネル を見ながらTwitterを見たりしていました。

こういう体験は初めてだったので、個人的にはとてもよい経験ができたと思っています。

というわけで、今年は ハンドメイドマーケット | minne(ミンネ) でバーンといくので、ビッグウェーブにのっかりたい人、その裏でしっかり売上利益をあげいかないといけないサービスを支えたいエンジニア、両方とも絶賛募集中なのでぜひご応募ください!

みんなで恵方巻を食べた

オフィスに大量の恵方巻がデプロイされていたのでみんなで食べました。

家に帰ってからは、申し訳程度に息子と豆まきをしたのでした。

幼稚園では鬼役の先生とかがいたのかなーと聞いてみたら「鬼の面が置いてあって、終わったら持っていかれた」という証言をしていた。なるほど。

入門docker - ローカルでビルドしたバイナリが入らないように注意しよう

本日の私の生産性を著しく低下させた件について共有させていただきます。

とあるフロントエンドアプリケーションを動作させるためのDockerコンテナを作っていたのですが、Dockerfileをこんな感じにしていたんです。

FROM dockerfile/nodejs-bower-grunt

...

ADD package.json /app/
RUN npm install

ADD bower.json /app/
RUN bower install --allow-root

ADD . /app/

...

ちょっとこみいった事情があったのでonbuildではないのですが、手元の環境でbuildしたイメージを実行しようとしても grunt imagemin:dist でエラーになってしまう。しかし、リモート(具体的には mookjp/pool の中)だとその部分は動いている。(その先が動かなかったのでデバッグしたかった)

エラーメッセージでググっても npm cache clean しろとか、apt-get で入れてる optipng を消せとか言うので docker run -i -t {imagename} /bin/bash していろいろやっていたら、./node_moduels 内にある optipng の実行ファイルが壊れており、ADD . /app/node_modules がローカルのものに上書かれていることにようやく気付いたのでした…

手元で node_modules を消してbuildしたら無事動くものができあがったのでした。つらい。

みなさんもローカルで docker build するときはバイナリが入らないように注意しましょう…

2015/01に読み終えた本

正月に、2015年1月に読んだ本をブクログでふりかえる - delirious thoughts を真似て書いてみようと思っていたのを月末に思いだしたのでした。

今月は3冊…意識の低さよー。

アジャイルソフトウェア要求を結構読み込んでいたというのあるけど、もうちょい時間を作りたいですね。

shucreamの本棚 (shucream) - ブクログ

AEP読書会 第十六章「ベロシティの見積もり」

第十六章「ベロシティの見積もり」 - AEP読書会 | Doorkeeper

2015年1回目でした。今回はGMOグループからも何人か来ていて、これも藤村さんのリクルーティング活動のおかげか!? と、私もがんばろうと思いを新たにしました。

今回のテーマの「ベロシティ」ですが、私自身あまりうまく使えないなーと悩んでいたところ、ディスカッションの中でいいヒントを貰えました。

ベロシティ上げて欲しい人、安定させたいチーム

PO(やマネージャ)としては当然できることが多くなるほうがいいので「ベロシティを上げるにはどうしたらいいか」という話になります。

一方で、開発チームとしては中期の見通しを立てるために「ベロシティを安定させたい」と思っています。

ここに歪みがあって、こじれてしまうと見せ掛けのベロシティ(完了条件をごまかしたり、過剰見積をしてベロシティが上がったように見せる)にチームが走ってしまったら元も子もないので、今までは「ベロシティは安定させるもの」というスタンスをとってきました。

ベロシティはチームの限界近くまで上がって安定する

ディスカッションの中では、ベロシティは無限に上がり続けることはないが、チームの限界近くまで上げて安定させるべき、という話がでてきました。

そう聞くと当然のことなんですが、回りの状況や、私自身が開発チームに近い場所にいるせいもあって「今だって一生懸命やってるよ」という気持ちが強かったんですよね。

でも、開発チームが工夫や調整、仕組みの改善を精一杯やってるか?って言われると、過去のプロジェクトを見ても胸をはって言えるプロジェクトってあんまりないし、そういう面では甘えもあったのかな、って。

スクラムマスターの役割

Scrumの根っこ というスライドに「責任から逃さないのがSM」という言葉があって、こういう表現の仕方は考えたことなかったな、とハッとしたのでした。

「ベロシティを上げろ」という人には「安定させるものなんです」、開発チームには「どうやったらもっと早く進めるか」という二枚舌でいくのがいいんだなという自身が得られたので、今回もよい読書会でした。

デザイン作業の見積りと計画

夕方からプロジェクトの残作業棚卸しをしていて、@shikakunが見積りを計画に悩んでいたので、相対見積りやタイムボックスの考え方について話していました。

最初は私達プログラマがどうやっているかを説明していたのですが、話していくうちに「これ職種関係ないじゃん」ということに気付いて、それなりにいい話になったような気がします。

  • 明確なゴールがあるものや完了条件が明確、イメージしやすいものは相対見積りで考える
  • スパイクや調査タスクなど、完了条件が曖昧だったり、作業量を見積るの困難なものはタイムボックスで考える
    • タイムボックスの半分くらいで相談するタイミングを入れておく

長期的なプランニングを考えるときは、それらをえいやっと足して計画をたてればいいし、イテレーションプランニングでは相対見積りを時間見積りにざっと変換して、タイムボックスのタスクと合わせて計画していけばよいです。

計画は最初に立てて終わりではなく、現実に合わせて変えていける、計画し続けることが非常に大切です。その為には、がちっと引かれたガントチャートよりは、相対見積りと絶対値の見積りをうまく組合せた「直近の計画は詳細に、長期計画はざっくりと」というアプローチがとれる、いわゆるAEPスタイルがすごくいいなーと思っています。

もちろんプロジェクトの性質や状況はありますが、普通の人が普通にソフトウェア開発をするのであれば、「計画通りに進めること」よりも、プロジェクトを通した学習によって起こる「変化を受け入れること」ができる計画やプロセスを採用したほうが、メンバーのモチベーションの面でもメリットが大きいと主観ですが感じています。

こんな話を10分くらいしていたんですが、そういえばうまく見積りと計画ができたのか聞いていなかった…

Request Spec で HTTP HEADER を勝手につける gem を作った

kenchan/rspec-default_https_header です。

APIサーバの Request Spec を書こうと思ったときに、毎回 OAuth のトークン設定したり、 CONTENT_TYPE: 'application/json' とか付けるのは人間のやることではないので、もうちょっと簡単にできるようにしました。

最初は r7kamura/rspec-request_describer がいいかなと思ったんですが、ちょっと枠組みがエクストリームな感じなので、最初から導入したりえいやっと書きかえるならよかったんですが、もうちょっとゆるめのやつが欲しかったのです。

  • Q. テストがないようですが?
  • A. すみません…テスト書いたらリリースしてWeb日記書こうと思ったんですが、うっかり社内のプロダクトに入れてしまったので書いちゃいました。

わりと便利だと思うのでよかったらお使いください。

mookjp/pool を Ubuntu 14.04 上で動かす

話題の mookjp/pool をなんとか使いたいと思って、社内の仮想環境上で動かしてみました。

ペパボの社内用サーバは mizzy/maglica というツールを使って管理されてるんですが、まだCoreOSは実績がなかった気がするので、dockerが一番まともに動くであろう Ubuntu 14.04 上でチャレンジしたところ無事動いたのでした。

だいたいは、READMEにあるamazon linux用の手順でよくて、

  • dockerとgitをapt-getで入れる
  • dockerの実行ファイルをREADMEの手順通りに最新版にする
  • scripts/init_host_server を実行する

というだけでとりあえず動きました。(2015/01/20現在)

社内ではCIにDroneを使っているプロジェクトがいくつかあるので、まずはその辺から使えるようにしていこうかと。

prevs.io - Your environment, just one click のエンタープライズ用がでるのはまだまだ先だろうから、社内でカジュアルに使える環境があると便利なんじゃないかと思っています。

Dockerの周辺技術はぜんぜんキャッチアップできていなかったので、ちょうどいい機会だからいろいろ勉強しよう。

福岡出張の記録

ペパボではエンジニアの評価面談を技術基盤チームでやっているので福岡まで行ってきました。

1日目

ちょうどお昼に到着する飛行機だったので、まずはまぐろ料理紀文 (まぐろりょうりきぶん) - 天神/魚介料理・海鮮料理 [食べログ] というところで黒鉄火丼なるものを頂いた。

海苔の下はネギトロ的なやつなんだけど、めっちゃ山葵がきいてたけど美味しかった!あと、血合を煮たやつが無限に食べれて、これもめっちゃ旨かった。

夜は各自という感じだったので、行ってみたかった一人モツ鍋のお店 元祖博多麺もつ屋 - 天神南/もつ鍋 [食べログ] に。

最初から麺が入っていることもあって、焼酎1杯とこれでお腹いっぱいでした。カウンター8席だけなんだけど、味が2種類あるので2人できて分けてる人もいて、それもよさそうだなーと思ったのでした。

2日目

お昼は 天ぷらのひらお 天神店 - 天神/天ぷら [食べログ]

写真忘れたけど、説明する必要はないですよね。おいしかった。

夜は本気の鮨ということでかなり警戒していたんだけど、予約できなくて別のところに。

あんちぽさんの「面白いところと普通のところどっちがいい?」に満場一致で面白い方となったところ、 河太郎 中洲本店 (かわたろう) - 中洲川端/魚介料理・海鮮料理 [食べログ] だった。

呼子のイカ、初めて食べたけどこれはやばい。

3日目

お昼は 博多ごまさば屋 - 赤坂/居酒屋 [食べログ]

福岡のランチのおいしいところはなにかが無限に食べれるところが多くて、ここでは南蛮漬みたいなのが食べ放題でこれも旨かった。

夜は福岡メンバーと 海鮮食堂 すいか - 赤坂/居酒屋 [食べログ] というところでわいわいと。このお店、ぐるなび - 海鮮食堂 すいか(大名/魚料理) の写真がめっちゃ残念なかんじなんだけど、ふつうに美味しかった。いわしの梅揚げおすすめ。

その後は、二次会で近くのバーで3時くらいまで。おつかれさまでした…

4日目

お昼はpinkoさんとちんさつさんと スリランカ料理レストラン 不思議香菜ツナパハ&東方遊酒菜ヌワラエリヤ でカレー。

なにやらめっちゃ辛いということだったんですが、まぁせっかくだからと普通の辛さ(?)のやつを。たしかにかなり辛いけど、ココナッツカレーひさしぶりだったのでおいしかったです!

まとめ

御飯のことしか書いてませんが、面談では初めましての人もたくさんいて、いろいろなお話を聞けてよかったです。

掃除&片付け

領収書とか保証書とかなんかいろいろ入っている押入れの中を全部出して一掃しました。

5、6年前に買った家電の保証書とか、賃貸契約書とか、数年前から放置されている常備薬とかいろいろでてきたのであった。

無いと思っていた精密ドライバーとか、ガムテープとか、コロコロの替えとか、だいぶ有益なものも発掘できたのでよかったよかった。

奥さんの実家にご挨拶行って一回休み

一回休みでした。

レジェンド花金

給料日の金曜日で社長のケンタロさんの誕生日会ということでレジェンド花金でした。

相変わらずエンジニアの人たちと最近どうっすかとか、評価面談どうでしたか、みたいな話をしていたような。

若者分を補給できたのでよかったかな。

評価面談

ペパボでは半期毎に評価面談があるので、上長であるあんちぽさんと30分ちょっとおしゃべりをしました。

評価制度そのものは ペパボのエンジニア評価制度をパワーアップした ー deirious thoughts から変わっていないので、3つのポイントについて半年どうでしたか?という感じで進んでいきました。

技術基盤チームという特定のサービスに依存しないチームに所属しているので、実際に売上をあげている各事業と、そのユーザにどういう影響を与えられたのかが説明しにくいという話をしたら、「技術基盤チームにいるってことはそのロジックをちゃんと説明できないといけないよ」というコメントをいただいて、おっしゃる通りがんばりますという気持ちになりました。

あとは、去年やれなかったこととか、今思えばこうしたらよかったとか、今年はこういうのがんばりたいとか、そういう話をして終わり。

またすぐ2015年上期の目標をたてないといけないのだけど、これやったらすごいという目標をやりきれるようにがんばろう。

pplogのGemfileを眺めて気になったやつ

pplogのGemfile - pblog が公開されていたので眺めながら、気になったやつを調べてみました。

garb

Google Analytics API の Ruby クライアント。管理画面とかで使ってるんですかね。

数値だけもってきて他のメトリクスと合わせて表示できると便利そうなのであとで試してみよう。

inuicon-rails

なんだこれ?と思ったらWeb Font!!!

便利だ。

dekiru

便利なヘルパーの集合。dekiru/controller_additions.rb at master · mataki/dekiru が便利そうでした。

uuidtools

大体の場合は singleton method SecureRandom.uuid でよいと思うのですが、なにかの事情で使わないといけなくなったときのために覚えておきます。

brakeman

本日のスターしてたわー大賞。お仕事のアプリにも使ってみよう。

おわりに

ちょっと古いけど IdobataのGemfile もどうぞ。(更新されたりしないかな?)

難しい問題を簡単に解くということ

を大切にしている。

現実世界の問題をシステムを作って解決するということは、その問題はコストをかけて解決する価値のある難しい問題であるということだろう。

しかしながら、難しい問題をそのまま難しい方法で解決するのであれば、日本語が理解できてプログラムさえ書ければ誰でもできるのである。

「難しい問題を簡単に解く」というのは、単にライブラリを使うというだけではない。

難しい問題というのは、大抵の場合一様に難しさが広がっているわけではなく、多数の簡単な問題とごく一部分の難しい問題の集合となっている。

この一部分の難しい問題を見極めるのが重要である。その問題を難しい問題としているポイントさえわかればあとはどうとでもなる。

技術力で捻じ伏せることもできるだろうし、交渉によってその問題をなかったことにすることだってできるかもしれない。(馬鹿正直に作るだけが仕事ではない)

「こんなコードでよかったのか」と思わせたら勝ちだと思う。

ということを、消費税や代引手数料の計算ロジックのレビューをしながら思ったのであった。ポエム終わり。

Railsを読むぞ #2

今日は core_ext/array/* の残り。

active_support/core_ext/array/extract_options.rb

引数の最後のHashを抜き出すいつものやつですね。 Hash#extractable_options? も一緒に定義していて、Hashのサブクラスでextractされないようなものを作れるようになってるそうな。なるほどー。

active_support/core_ext/array/groups.rb

in_groups_ofin_groups 似てるけどだいぶ違う。 in_groups のほうがロジックは大分難しいんですね。

active_support/core_ext/array/prepend_and_append.rb

aliasを定義してるだけ。

active_support/core_ext/array/wrap.rb

おなじみ Array.wrap 。いつもお世話になっています。

to_ary に反応してもnilが変えってくることを考慮して、

elsif object.respond_to?(:to_ary)
  object.to_ary || [object]

となっているのはなるほど感ありますね。