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

Let's write something good

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 にしかも簡単に書けるのがすばらしいので、パンくず実装するときは使ってみてください。

関西Ruby会議05のレポートをるびま45号に書きました。

2013-12-22
  • Share on Facebook
  • Tweet
  • Add to Pocket

先日の関西Ruby会議05でひとりレポート作成班をしていたので、その関係でレポートをるびまに寄稿しました。で、ちょっと褒められたので、自分なりに地域Ruby会議レポートを書くときに気をつけていたことを書き残しておこうかと思います。

もともとは、初めてレポートを作成した、前回の関西Ruby会議04のときに意識したことがベースになっています。基本は読み手が読み疲れしないようにするということを意識しています。

1セッションのレポート量はほどほどに

地域Ruby会議のレポートを書くとき、発表者のセッションは全部載せたいと思う。でも、そうなると長くなるので読み疲れが心配になる。

ということで、あまり1セッションに対して長い文章を書かないようにしています。ただし、少なすぎると記事の空白が気になってくる ので、空白とのバランスを考えて文章の量を調整します。これは解像度の違うPCとかスマートフォンで見ると実際の見え方が変わるので、複数マシンで確認するのがベストです。今回は、MBAとVAIO PROとスマートフォンで確認しました。

自分の意見・感想を入れる

レポートなので、そのセッションのあったことを書けばいいのですが、自分が書くのにセッションの内容のまとめだけだともったいないです。

スライドへのリンクがあるなら、スライドを見ればだいたい内容はわかると思うので、そこに載っていないことや自分がどう思ったかを書いたほうが読む方にも「こういう印象を与える発表だったんだな」とか「当日はこんな感じだったんだ」みたいなイメージをプラスできるんじゃないかな、と思っています。(まぁ、お前の意見はどうでもいい、と思われてるかもしれないけど……)

発表者の写真は入れる

これはまぁ、普通か。

当日の様子を入れる

発表の内容を知りたいと思う人が多いかもしれないですが、私は地域Ruby会議の雰囲気が好きだったりするので、当日の様子がわかる写真を入れるようにしています。

「楽しい」とか「勉強になる」とか「こんなやり方もあるのね」みたいなものが読む人にも伝えられれば、別の地域で開催する人たちのヒントにもなるかなぁ、なんて。

がんばって文章を作らない

あまりに完璧を求めるがために、会議当日に楽しめないくらい必死にレポートするとか、記事にあれこれ全部入れるとか、はしません。

文章は深い内容を伝えるにはいいですが、雰囲気みたいなものは画像である程度伝えられると思います。写真があるなら写真を貼って、無駄に文章の量を多くしないようにします。発表者の方のスライドがあれば、発表内容もだいたいそちらをみれば伝わるはず。やはり文章考えたり、推敲したり、誤字脱字直すのが一番しんどいですからね。ただそのためには、

  • 発表者のスライドをGETする。会議開催前にお願いしておくといいかも。
    • 事前に話をしておけば、公開されないものでもファイルだけもらうということはできると思います。
  • 写真を撮る人をレポート班として組み込んでおく。
    • エンジニアの写真愛好家率は割と高いと思うので、そういう人に頼む。
    • 発表者の写真は必ず撮るようにお願いしておく。

というのが必要になるので、これは運営のときに準備しておくとよいと思います。

複数人でレポート作成班を構成するとき(想像)

セッション別に担当をわけてメンバーがパートの分を書いて結合すると思うんですが、最終的には誰かがバランスを取らないといけないと思います。

今回は私ひとりで作成したのでこれには該当しないのですが、前回は複数人で作って私が最後全体を見て手直しをしました(るびま編集とのやりとり担当が私だったので)。セッションのレポートはメンバーの個性みたいなものが出るのがよいと思っていて、でも全体のバランスを崩しすぎるものアレだな、というのでこの方法を採りました。 これが良い方法かと言われれば疑問はあるのですが、誰か一人のスタイルを真似るよりはメンバーの個性が出たほうが面白い記事になるんじゃないかなぁと思っています。

モチベーション維持!

これが一番むずかしいのですが、会議の開催からレポート提出・公開までの間が空いてしまうのと、会議が終わった達成感から、レポート作成から逃避したくなるんですよね。。

前回作成時にこれに悩んだので、今回はそうしないようにすぐにレポートを作ろう!と思っていましたが、締め切りが遠いのでエンジンがかかりませんでした…… でも、締め切り前に頑張るんですよね。一応、会議終了一週間で当日とっていたメモの整理をしていたのが助かりました。記憶が新鮮なうちに何か手を打つとよいと思います。もちろん、記事ができていると一番いいんですよ!




とまぁ、これくらいが意識していることです。

2連続でレポート書いたので、次回は別の人に席を譲ろうかなと思っています。レポート書いてるびまに投稿すると、るびま編集の中身がみえるし、編集者がどんなこと考えているかも知れるので、いい経験になると思うんです。私がるびま編集に参加するきっかけは、前回のレポート提出なんですよ。

レポートは怖くない。けど、自分のエンジンがかからないのが一番怖い。経験者は語る……