| @技術/プログラミング

Go 言語でなにかやってみようと思っていたところ、先々週末くらいにアンチポップさんが gyo という、 Go 言語で Yo するやつを作ってたので、 gyo とそのサンプルコードを利用して gyowitter というのを作った。 Yo の MORYGONZALEZ が Yo を受け取ったら Yo を返しつつ Twitter に「また @wyinoue さんから Yo がありました。この人仕事してるんですかね?」とか Post するやつ。一部の異常者から10連続で Yo とか来て軽くうざいと思うことがあったので、 Twitter のこの人こんなに Yo してきて異常者ですよ、というのを知らしめたくて作った。

Go 言語、初めて書いてみたけど簡単なことしかしてないので大した感想述べられるほどは分からない。 JSON で設定ファイル書いてその内容を読み込む対応を昨日今日くらいでやってたんだけど、静的型付けなためか、読もうとする JSON がどういう構造になってるかを分かってないといけなくて、 Ruby とかだととりあえず parse したあと Hash にして好きに扱える感じだけど、読み込む前にどの階層のなんという key のバリューが map になってるとか配列になってるとか分かってないといけないのが窮屈に感じた。

コンパイルしたらバイナリが一つ出来てそれを置けばデプロイ完了(環境構築とかいらない)のは大変便利だと思った。 Mac で書いて Linux 用にクロスコンパイルして scp してデプロイ完了(Linux 側には Go インストールする必要ない)というのはスクリプト言語にはない感じなので新鮮だった。

ただビルドしたバイナリのサイズが結構でかくて、 gyowitter は大したことしてないけど 6MB くらいあって、細い回線でアップロードしようとすると結構つらい。

percol 流行ったときに会社で使ってる 3 年前の MacBook Pro (HDD のやつ)に入れて使ってみたらあまりにもレスポンス悪くて使うの諦めてたんだけど、 Go 言語版の peco を使い始めたら普通に使えて快適だったので、 Go 言語には夢がひろがりんぐな印象を持ってる。新しい言語勉強するの新鮮で頭が若返りするような感覚あるので引き続き勉強してみようと思います。

| @技術/プログラミング

US キーボードに使うようになってから、JIS キーボードでは単独で入力できるコロン(:)を打つときにシフトキー(Shift)押してないといけなくなった( Shift + の組み合わせでコロン : になる)。 .vimrc で : を入れ替える方法もあるらしいけど、なんとなく抵抗があってやってなかった。(Happy Hacking Keyboard Professional 2 を買った

それでよく起こるのが、ファイルを保存しようとしたときに Shit + を押してコマンドモードに入って w を押すと、 Shift が押されっぱなしの状態になっていて W となり保存できず警告メッセージが表示されてしまう現象や、終了しようとして Shift + ‘ => q したつもりが Shift + ‘ => Shift + q になっていて大文字の Q コマンドが実行されて Quickrun が実行されてしまう現象。プログラムを書いてるときにこういうのでつまずくとイラッとする。

:W:Q がそれぞれ小文字のコマンドと解釈されるようにすればいいわけなので、以下のように .vimrc に記述した。

" 大文字 W で保存
command W w
" Q で quickrun 実行しないように
command Q q

便利。

| @技術/プログラミング

hubot のことを "ひゅ〜ぼっと" と読むの、いけ好かない感じがする。たとえ GitHub の中の人が "ひゅ〜ぼっと" と読んでいたとしてもいけ好かない。 "ふぼっと" も芋っぽい感じがして好きになれない。 GitHub はジットハブという読み方が正しいのだから hubot は "はぼっと" なのでは?

| @技術/プログラミング

CleanRuby を途中まで読んだ。一年半前に DCI 流行って、その後会社(東京の方)でも流行ってたので、「乗るしかない、このビッグウェーブに」と思って買うだけ買って積ん読してた。正月くらいから本気出して読み始めた。まだ全部読み終わってないんだけど、 Day One にメモ走り書きしてあって良い話っぽいのが書いてあったのでメモする。

2014/01/23

Clean Ruby 読んでる。まだ最初の方だけど何となく DCI についてつかめてきた。 DCI 、つまるところ RSpec みたいな BDD の考え方を製品コードにも持ってきたものだと思う。「テストコードだけ実際にプログラムが利用されるときの文脈( context )とか反映してるのもったいなくね? これプロダクトコードにも反映させるべきでは?」みたいなノリだと思う。


2014/01/26

Clean Ruby、3章くらいまで来た。 DCI の考え方だいたい分かった。Methodless Roles とはつまり良い名前を付けるところ、というところにぐっと来た。Clean Code からの引用で、「良い命名をすることがコードを良くしないことはない」というのが良かった。

モデルにいろいろ書くな、という話も良かった。 Being と Doing を分けるというやつ。モデルは変更しない情報(データ)だけを保存する場所にして、データを変更したりする処理は別の場所に書くという考え方。

サインアップについて。ユーザーがサインアップするとき、ユーザー自身がサインアップすることもあれば管理者がユーザーの代わりにサインアップすることもある。同じ種類のデータを作ろうとしてるんだけど、システムの挙動は異なる。管理者がユーザーの代わりにサインアップするときには、管理者にメールで通知する必要はない、など。モデルにデータの変更処理まで書くと、別の文脈からデータ操作しようとするときに苦しい感じになる。

頑張って最後まで読みたい。

| @技術/プログラミング

Vimmabilityのなさ

TDD Boot Camp福岡で生まれて初めてペアプログラミングを経験した。自分のVimmabilityが思いの外低く焦った。書くの超とろいし、Rubyも全然分かってないしペア組んでもらった人に迷惑かけまくりな感じ。会社では誰もVimとか使ってなくてみんなEclipseとか秀丸使ってるし、周りにVimmerがいないので自分がどんなにしょぼいVim使いなのか気づいてなかった。

とりあえず今回、ペアを組んだ @mallowlabs さんに cw とか <数字>y とかを教えてもらった。あと

Vimでバックスペース使ったら負けだから

と言われてしまったのでバックスペースと矢印キーをなるべく使わずにプログラム書きたいと思います。でもTextMateとかCodaとか便利だからついつい使ってしまうんよね…。

プログラムが全然書けない

思ってたよりもプログラムができないことに気がついた。お題を与えられて、制限時間があるなかでコードを書いていかなければならない。しかもペアプログラミングなので一人でちんたら時間をかけて書くわけにもいかない。そしてやっぱ人に見られてると緊張する。Rubyの基本的なメソッドとかが分かってなくて教えてもらいながら書いてたけど、わからないと緊張してしまって頭が真っ白になって何も書けなくなる。いつもリファレンス本を片手にコードを書き捨てていたので、よくないなぁと思った。

というか、そもそも自分は仕事であまりコードを書いてないのだ。TDD Boot Campに来てる人たちはみんな公私ともにばりばりコードを書いててとても楽しそうだった。なんだかとても羨ましかった。

いろいろ考えないとなー、と思わせられた勉強会だった。

| @技術/プログラミング

シェルの履歴から適当に拾って

CONFIGURE_OPTS="--with-readline-dir=`brew --prefix readline` --with-openssl-dir=`brew --prefix openssl` --with-gcc=clang" rbenv install 2.1.2

とやったら nokogiri のインストールでこけた。

gem install nokogiri
Building native extensions.  This could take a while...
Building nokogiri using packaged libraries.
ERROR:  Error installing nokogiri:
        ERROR: Failed to build gem native extension.

    /Users/morygonzalez/.rbenv/versions/2.1.2/bin/ruby extconf.rb
Building nokogiri using packaged libraries.
checking for iconv.h... yes
checking for iconv_open() in iconv.h... no
checking for iconv_open() in -liconv... no
checking for libiconv_open() in iconv.h... no
checking for libiconv_open() in -liconv... no
-----
libiconv is missing.  please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies.
-----
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/Users/morygonzalez/.rbenv/versions/2.1.2/bin/ruby
        --help
        --clean
        --use-system-libraries
        --enable-static
        --disable-static
        --with-zlib-dir
        --without-zlib-dir
        --with-zlib-include
        --without-zlib-include=${zlib-dir}/include
        --with-zlib-lib
        --without-zlib-lib=${zlib-dir}/lib
        --enable-cross-build
        --disable-cross-build

extconf failed, exit code 1

Gem files will remain installed in /Users/morygonzalez/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/nokogiri-1.6.2.1 for inspection.
Results logged to /Users/morygonzalez/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/extensions/x86_64-darwin-13/2.1.0-static/nokogiri-1.6.2.1/gem_make.out

Installing REE with rbenv with iconv support and Homebrew — eddorre という記事を参考に、 --with-iconv-dir オプションをつけて Ruby インストールしたらうまくいった。

CONFIGURE_OPTS="--with-readline-dir=`brew --prefix readline` --with-openssl-dir=`brew --prefix openssl` --with-iconv-dir=`brew --prefix libiconv` --with-gcc=clang" rbenv install 2.1.2

| @技術/プログラミング

なんか作業してて変更発生して一旦 git commit したとします。例えば行末の空白(trailing white space)刈りをしていたとしましょう。一通り刈り終わって git commit して別のファイル開いたらまた trailing white space があったとします。さっき "remove trailing white space" とコミットログを残したのにまた同じの書くのは意味ないし同じようなことやってるコミットを二つに分ける意味はない。なので git commit --amend すると思うんですけど(じゃんじゃんコミットして後で git rebase -i するやり方もあるけど remote に push 後だったら force push しないといけなくてだるい)、単なる git commit --amend だとエディターが立ち上がってコミットログを確認して保存して終了しないといけない。非常にだるい。 git commit --amend のエディター立ち上がらないオプションとかないのかと調べていたら --no-edit というオプションがあることを知った。エディター立ち上がらずに --amend できて非常に便利。これまで「現在の作業内容をどこまで終わらせてからコミットするか」を考えるのが結構苦痛だったんだけど、 git commit --amend --no-edit のおかげでリストカット感覚でコミットしていけそう。