なんか書いていこうぜー.com

Let's write something good

XP祭り2014に参加してきた

2014-09-07
  • Share on Facebook
  • Tweet
  • Add to Pocket

XP祭りに同僚が参加するというので、XP祭りなるものに参加したことがなかったので、良い機会と思い参加してみた。

第一印象は、もっとこう”堅い”感じのものを想像していたのだけれども、そういうものではなく、本当に現場で遭遇した問題や日頃やっていることの発表が多かった、思ったより柔らかかった、というものでした。

XPを再興する(関将俊さん)

咳さんの発表は以前 RubyKaigi だったかな?で聴いたことがあったので、マイペースな感じの発表で質問に臆せずバッサバッサ斬っていくのが心地よかったw

自動テストは checking であって testing ではない というのは、そうだよなぁと思いながら、testing なテスト(?)のためには何ができるんだろうって考えると、やはり手で動かしてテストするしかないよなぁ…… となったときに、テスト項目の一覧は Google Docs なのかな? Excel は諸々の理由で敬遠したい。。

DevLOVE Pubの技術書定期刊行技術(小芝敏明さんとPublisherの皆様)

電子書籍の同人誌を出版するためにやっていることの発表でした。

複数人で記事を書いて誰かが間に合わなくても刊行ができるようにしたり、刊行するたびに行ってきた工夫や自動化作業があったり。 あくまで趣味だから、趣味の範囲でゆる〜い感じで出版が苦にならないようにする、毎回何かしら改善して執筆により注力できるように環境を整えていく工夫を聞くことができました。

最近、この「苦にならないように」っていうのが自分の中ではキーワードになっていて、仕事でもないのに苦しんでまでやる意義を見出すのって結構ツライと思っていて、そんな状況になっているところをどうしたらいいかなぁと考えつつも、結論が出てない感じですねぇ……

ペアプロを勘違いしていませんか?(林尚之さん)

林さんがこれまでやってきたペアプロの中で出会った誤解や、林さんの思うベスト・プラクティスの話。

新規参画者や新人のためにペアプロするというのはOKだけど、そのためのペアプロっていう認識は払拭したいところですよね。 あと、コスト高と現場にいないレベルの上司に思われるのが厳しいよね、というのはあるあるですよね。 発表にも数値的なメリットの紹介があったのですが、それでもペアプロ文化のないところへの導入のハードルを上げる最も大きな要因で理解してもらいにくいところですよね……

キーボードとマウスを2つ接続してやるっていうのはいいですね!

俺の価値創造契約(木下史彦さん)

4年前に発表して話題になった「価値創造契約」のその後のお話。

なぜうまくいっていないか?という点の分析事例はあまり聴く機会がないため、たいへん参考になる発表でした。

木下さんの 俺の価値創造契約 や、俺の事業部 は、最近入ったものとしては経緯等知ることができてほほぅ〜という感じでした。(ちょっと訊きにくいしね)

実は木下さんの発表を聴くのは初めてだったので、よい経験になりました。

なぜアジャイル開発はうまくいかないのか(倉貫さん)

う〜ん、これはちょっと合わなかった。。 なんだかタイトルと内容がちょっと私の中では一致しなくて。。トーク自体は面白く進んでいたと思います。

LTとクロージング

LTにもいろいろ勉強になる発表があって、いろいろコミュニティでもやってるんだなぁとか、POと開発者の信頼関係って大事だよね、とかいろんなお話を聴けました。

勉強することもあり、更にお土産までもらって、本当に参加してよかったと思えるお祭りでした。ありがとうございました。

atom、はじめました

2014-07-13
  • Share on Facebook
  • Tweet
  • Add to Pocket

最近 vim を使っていると、CursorMoved の影響か、前に入力した文字が画面に残り続けるようになったので、先日から暇人になったこともあって atom を使うようにしています。

まだ全然使いこなせてはいないのですが、独自の設定を記述できる keymap.cson とか styles.less にとりあえず書いた内容をメモしておこうと思います。 まずは、keymap.cson から。(vim-mode は利用している前提で書いています。)

'.editor':
  'shift-cmd-l': 'editor:select-line'
  'cmd-l': 'unset!'
'.editor.vim-mode:not(.insert-mode)':
  'space j': 'core:page-down'
  'space k': 'core:page-up'
'body':
  'cmd-h': 'pane:show-previous-item'
  'cmd-l': 'pane:show-next-item'
  ': w': 'core:save'

vim を使っていたときは cmd-h/cmd-l でコンソールのタブを移動できるようにしていたので、タブを cmd-h/cmd-l で移動できるように body のところで変更しています。 設定したコマンドでタブ移動ができるように、元々定義されていた cmd-l の設定を unset! で無効にして、shift-cmd-l に逃しています。

.editor.vim-mode:not(.insert-mode) のところは、ページ送り/ページ戻し を spece j/spece k で行っていたため、その設定の追加です。: w は vim のときの保存癖が治らないので、追加しておきました。

続いて、styles.less

.editor {
  //http://qiita.com/MOKYN/items/02e3789c35fc81850bbd 参照
  .line.cursor-line {
    // カーソル行の背景色
    background: rgba(0, 37, 253, 0.97);
  }

  .line, .line-number {
    // カーソル移動するたびにちょっとずれるの防止
    border-bottom: 1px solid rgba(0, 0, 0, 0);
  }
}

.tab-bar {
  .tab.active {
    color: rgba(0, 183, 255, 0.97);
    &:hover {
      color: rgba(0, 183, 255, 0.97);
    }
  }
}

.editor 部分は、vim でいう、:hi CursorLine ctermbg=DarkBlue と同様のことをしています。qiita の記事にあった設定を拝借しました。

.tab-bar は、タブが選択状態になった場合に、文字が bold になるだけではわかりにくかったので、明示的に色変えてみました。

いろいろ試しているものの、そもそもファイルがタブごとに開くのが違和感あったりで前途多難なのですが、がんばって育てていきたいと思います。

Chef 実践入門を買って写経中

2014-05-26
  • Share on Facebook
  • Tweet
  • Add to Pocket

ちょっと気になっていたので買ってみました。Chef実践入門 で、写経しています。ただし、Ubuntu を対象の OS にしているので、記載するコマンドが違っていたりするので、純粋に「写経」ではないのですが、ちょっと頑張ってみましょう。

ちなみに、Ember.js の写経対象として、Ember.js Testing on Rails を買ってみたものの、ちょくちょく記載が誤っていたりなんだりで進んでいないのでした。 先日の更新でだいぶマシになったので、ちょっとこちらも頑張ってみよう。

東京で仕事していた間の出来事と思い出(1)

2014-04-27
  • Share on Facebook
  • Tweet
  • Add to Pocket

1月から4月の3週目くらいまで某プロジェクトでお世話になっていて、今現在別のプロジェクトに移ったので前のプロジェクトの思い出を書こうかと思って書いています。(現在は別のプロジェクトにいる)

※注 特にまとまりはありません。

基本的に、今いる会社はどこかの現場に常駐で入って作業をするということがないため、他の会社の人たちが活躍しているプロジェクトを見れる機会がないのですが、今回なぜか(信じられないことに)私に声がかかったので、他の会社の人たちが活躍しているプロジェクトを見たいというのもあって、「行きたい」宣言をして(実力的に不安を感じながらも)参加させていただいたのでした。

1ヶ月目

参加したプロジェクトは、pull request 運用が普通に根付いているところで、プロジェクト外の人たちからもレビューが飛んでくるところ。。 斧がバンバン飛んできて、最初の3週間は毎日心に斧が刺さって抜けなかった…(ごもっともな斧なので、弾き返すこともできず100%命中する始末)

朝、目が覚めたときに指摘のメールが十数件溜まっていたり、出した PR がなかなか通らずに rebase して直しては指摘を受け、直しては指摘を受け…を繰り返したりするうちに、~心が麻痺して~ 学習して斧の量も減ってきた、というのが最初の1ヶ月目のことであった。

この間、だいたい指摘されやすいものが見えてきて、私の場合、block を取るメソッドでコードを短くできるならば積極的にそちらを使うとか、名前のつけ方(意識しても指摘もらうんですが…)とか、spec の書き方とか、が代表的なものであった。(だいたい全部じゃん?ってのはなしの方向で)

そこらへんの怪しいところは書いた後に何回か確認して PR 出すように心がけても、まだすんなり merge はされないのであった。

2ヶ月目

2ヶ月目。プロジェクトのコーディングもだんだんペースができてきて、かつ、機能がそれなりに触れるくらいの数になってきたころ、ラードに溺れる毎日がやってくる。

1ヶ月目のような指摘は減ったものの、詰めの甘い、ちょっとしたミスとか名前おかしいとかいう指摘が目立つようになってきた。 いわゆる、「だからお前は詰めが甘い、ラードでも飲んでろ」案件である。

毎日、いただいたパイン飴を舐め、押し寄せるラードを飲み込む毎日。

この頃、ラードとは別に、杏仁豆腐 という新たな魔物と出会うのであるが、その恐ろしさを目の当たりにするのは、プロジェクトを抜ける間際のことなのであった…

3ヶ月目

この月はなんかモリモリ書いていた気がする。機能はここでだいたい作ってしまっておこうって感じだったので、必死だったような… このあたりから、メンバーの杏仁豆腐攻めが始まるのであった。

きっかけは中華屋でお昼を食べたときである。定食を頼むとほぼデザートに杏仁豆腐が付いてくる。「杏仁豆腐が苦手だ」というので、大好きというわけでもないのであるが 私がその杏仁豆腐をもらった。その瞬間。「僕のもあげますよ」という声が…その日の昼、私は杏仁豆腐を4人分食べることになったのである。

これが悪ノリの始まりである。

4ヶ月目

さて、最後の月である。

すっかり話のオチに使われることも慣れ、すっかり排水口キャラが定着していた。あまりにオチに使われたり、杏仁豆腐の餌食になることが増えたため、「排水口もたまには詰まるんだよ!」と言ったくらいである。でも効かないwww

しかもこの頃には既に、お世話になっている会社内では私の顔を知らなくとも「杏仁豆腐が大好きな人がいるらしい」ということで、三度の飯より杏仁豆腐が好きでもない私のことが杏仁豆腐大好き野郎としてキャラが確立されていた。 どれほどかというと、帰社日ということでおじゃまするといきなり「杏仁さん」、と言われるほどである。

emoji-white_large_square がコメントに出てくることも増えた。(理由は訊かないで欲しい)

しかもこの頃、大阪の方面にいる知り合いからも、杏仁豆腐に関するいじりを受けることが多くなり、イラッ としながらコメントを返していた。(現在も継続中である)

この頃、リファクタリングが結構行われていたので、気がついたら自分の書いたコードが一行もなくなるのでは? と思ったこともありました。

総じて

なんか思い出形式で書くと、ネタにされていることが多すぎて泣けてくるのでありますが、非常に勉強をさせていただきました。 コーディングのスタンスとか、考え方、gemとかその使い方とか本当に勉強になりました。仕様とか設計についても勿論考えたりはするのですが、コードについて本当によく考えさせられた期間だったと思います。

以前に作っていたプロジェクトのコードとか見ると違和感を感じるので、少しは成長できているのかな?とも感じています。

最後に、僕の写真がプリントされたTシャツをプレゼントにいただきました。ありがとうございました。

次は若干、Tシャツが僕より先に行っているようです…

(文章はおもしろおかしく茶化して書いていますが、フィクションではありません!)

P.S 写真に撮ったものだけで数えても、2/25 から数えて 55 個も杏仁豆腐を食べていました…どう考えても過剰摂取です。

パンくずリストを出す gretel gem が使いやすくて感動した

2014-04-03
  • Share on Facebook
  • Tweet
  • Add to Pocket

今日仕事で gretel が使いやすかったのでメモ。

これまでの パンくずリスト(breadcrumbs) は、だいたい、controller の中で add_breadcrumb みたいなメソッド を呼び出してリストを作る感じなのですが、 gretel はちょっと違うのね。

Contoller を汚さずに、パンくずが作れる

gem を install します。ここは適宜、bundle とかにしてください。

$ gem install gretel

設定を記述するファイルを出力するコマンドを入力します。いわゆる、install コマンドです。

$ rails g gretel:install

このコマンドを打つと、config/breadcrumb.rb が作成されます。 ここに表示するパンくずの設定を書くのですが、

# Root crumb
crumb :root do
  link "Home", root_path
end

# Issue list
crumb :issues do
  link "All issues"
  parent :root
end

この記述で、 Home > All issues のパンくずの設定ができました。

view の layout と、パンくずを表示する画面にメソッドを書く必要があるのですが、パンくずの関係の設定はこのファイルに書くだけです。

これの何が嬉しいかというと、controller に書くタイプの下の例だと、update で更新に失敗したとき、edit で設定したパンくずの設定をもう一度書かないといけない。これが面倒で漏れやすいんですよ。

# 結構適当に書いてる
def edit
  add_breadcrumb 'Home', root_path   # ←ここ
  add_breadcrumb 'All Issues', nil   # ←ここ
end

def update
  @post = Post.find(params[:id])
  @post.attributes = post_params

  if @post.update
    redirect_to posts_path
  else
    add_breadcrumb 'Home', root_path # ←ここ
    add_breadcrumb 'All Issues', nil # ←ここ

    render action: :edit
  end
end

gretel は、この設定と後述する view 側の設定で、view単位でパンくずの設定が書けるのでこの点は気にせず、DRYに書けます。

view 側も簡潔に書ける

とりあえずパンくずを出力するには、app/views/layouts/application.html.erb

<%= breadcrumbs %>

のように書き、表示したい各view に 以下のように書けば、 Home > All Issues が出力されます。

<%= breadcrumb :issues %>
# 指定された :issues から parent の設定をたどって、 'Home > All Issues' が出力される

view 単位にパンくずが設定できるので、前述のようにupdateedit に同じ記述をする必要がなく、DRY にパンくずが書けます。しかも、指定した crumb から parent たどっていくだけなので、設定自体も非常に見やすい。

gretel を見ると、bootstrap や foundation5 に対応していたり、リストの形式を ol, ul にしたり、class の指定をしたりもできます。

私が仕事で使ったときは、別にパンくず用のデザインがあったので、そのデザインで出力されるように書きました。 Building the breadcrumbs manually のパートに書かれているやり方を使えば簡単に独自レイアウトにも対応できます。

とにかく、DRY にしかも簡単に書けるのがすばらしいので、パンくず実装するときは使ってみてください。