読者です 読者をやめる 読者になる 読者になる

よちよち.rb の開発合宿に行った #yochiyochirb

9/4(金) - 9/6(日)で、よちよち.rbの開発合宿に行った。

行き先

マホロバマインズ三浦さん。 弊社の開発合宿でも過去に使われたらしい。

会議室あり / 温泉あり / 卓球場あり / 雀卓あり / 駅近し / コンビニ近し / 海近し

って感じで、すごくよかった。

よちよちの開発合宿について

詳細はこちら -> Doorkeeper

よちよちで開発合宿をやるのは、去年に引き続き2回目。去年は熱海の山喜旅館さん。ちなみに去年の開発合宿で僕が作ったのはこれ。

highwide.hatenablog.com

合宿では各自が自分の好きなことをやればいいということになっていて、みんな各々のことをやってた。

タイムスケジュール

1日目

時間 やったこと
- 20:10 会社でインターン生と飲んでた
20:30 品川駅集合
21:15 - 22:30 京急線ウィング号でトイレ我慢してた
23:00前 宿到着
23:00 - 2:30くらい ハリガリとか厨二UNOとかニムトとかカードゲーム大会

※ハリガリ

ゲーム ハリガリ フルーツゲーム<AMIGO社 ドイツ>

ゲーム ハリガリ フルーツゲーム<AMIGO社 ドイツ>

2日目

時間 やったこと
6:30 奇跡的に目が覚めた
7:30くらい 朝食バイキングでとろろご飯食べた
9:00 - 12:00 設計についてあれこれ相談させてもらった
12:00 - 13:00 昼食 (牛丼)
13:00 - 13:30 卓球 (海に行ってる人もいた)
13:30 - 18:00 コード書いてた
18:00 - 19:00 夕食 (お重に入ったあれこれ)
19:00 - 21:30 話したり、お風呂入ったり
21:30 - 23:00 とみーさんとペアプロでテスト書く
23:00 - 3:00 厨二UNOとかニムトとかカードゲーム大会

※厨二UNO (僕らが勝手にそう呼んでいる)

Gods' Gambit~神々の一手~

Gods' Gambit~神々の一手~

3日目

時間 やったこと
8:00 絶望的な起床
9:00 - 10:30 テスト書き上げる
10:30 - 12:00 各自成果発表して撤収
12:30 駅近くでマグロ丼
13:00前 帰りの京急線乗り込んだ

僕がやったこと

最近とみーさん(@ta1kt0me)と shibaph というWebアプリを遊びで作っていて、そのコードを書いた。

shibaphは、僕がGitHubのcontributions graphが好きなので、それ使ってタスク管理とかできたらおもしろいかなというアイデアで始まったもの。Rails4で書いてる。

4月に転職してコードを書ける仕事に就けた喜びを噛みしめる一方で、仕事ってコード書くだけじゃないなって改めて思ったり、今の自分が価値発揮できるところがコード書くだけじゃなかったり、って感じだったので、合宿では「コード書くことに集中しよう」ってなんとなく決めてた。 きっと仲いい人たちとみんなで合宿すると楽しくなったり、雑談も弾むだろうなと思いつつ、僕はあんまりマルチタスクの遂行が上手でないことを自覚しているので、「一つのことをうまくやる」精神で臨んだ。

あとは、同僚が、プロコンの大会やハッカソンで2-3日ぶっ通しですごいコードをすごい量書いてすごい結果を収めているのを、すごいなぁと思っていたので、集中できる空間で集中してコード書くと、今の自分がどの程度できるのか確かめたかった。

結果

f:id:highwide:20150911004119p:plain

f:id:highwide:20150911003911p:plain

「上ででかいこと書いたわりに、めっちゃカードゲームしてんじゃんww」ってのはさておき、個人的には集中してコードが書けたと思ってるし、その一方で今の自分に書けるのはまだまだこんなもんかぁと思い知らされた気持ちもある。

難しかったこと

元々は、グラフをViewが描画しやすいように「ARモデルをValueとしたHashの、Array」っていう構造をControllerのprivateメソッドで作っていたのだが、呼び出すところでいちいちその構造を意識しなくてはいけないのがダルくて、呼び出され方をメソッド化した中間ClassをControllerで作ってViewに引き渡すようにした。 その際の中間ClassってRailsのディレクトリのどこに配置すべき?とか結構悩んだ。(結局Modelに置いた)

あと、「趣味プロジェクトなんだし使ったことない技術を使おう」と採用したminitestの書き方を調べるのにも時間がかかった。 (RSpecが書けるとは言っていない)

とはいえ

コード書くのも、みんなと話したり遊んだりするのも、楽しかった!

ありがとうございましたーー!!!

YAPC::Asia行ってきた

行ってきました。 初カンファレンス。とても楽しかった。 以下、観たやつとか。

8/21(木) 前夜祭

行けるかなって思ってたら行けなかった

8/22(金) 1日目

ビッグサイトの長いエスカレーター素敵だった。

Merry Christmas (Larry Wall) ※敬称略

  • Perl5とPerl6の関係は「ホビットの冒険」と「ロードオブザリング」の関係に近い。
  • 言語を作ることは物語を紡ぐことに似ているってなんか素敵だなと。
  • 中学生のときに観たロードオブザリングのことなんとなく覚えててすごく助かった。
  • 同時通訳すげーって思った。
    • 日常の言葉と、技術的用語と、トールキンの作品のことを正しく訳をわけるのほんとすごい。
  • Perl6、リリースできそう、よくわかんないけどなんかすごそう。
    • Perl6でのフィボナッチの書き方、ちょっと意味わかんなくておもしろかった。

Effective ES6 (teppeis)

  • とってもわかりやすくて、勉強になった。
  • あーーー、ES6のことちゃんと知らなきゃな―って思いながら放置してたので、「スライドで説明してもらう」っていう受動的なスタイル取れるの大変ありがたかった。
  • ES6素敵感やばいので、今のJavaScriptあんまり勉強したくないなとすら思ってしまった。
  • この前、「え、素のjsにArray#each的なのないの!?」ってテンパったので、早くES6触りたい。
  • 「バベっていこうぜ」って印象的だった。

TBD (matz)

togetter.com

  • Perl書けないし、参加前の時点で一番のお目当てのセッションだった。
  • To Be Determined かと思いきや違った。-> Toward Brain-aware Design
  • Rubyの一番反省している点は、Perlの影響」めっちゃ笑った。
  • 一方で、質疑で「Rubyの99.8%はイケてる」的なこと言ってたのなんかいいなぁって思った。
  • 「今日はRubyの話は封印」 -> 「封印を解く」めっちゃ笑った。
  • たぶんこのYAPCで一番笑った。
  • ハードウェアの進化による言語の変遷とてもおもしろい。関数型が注目集めてるのもマルチコアとかでの並列化とか背景にあるし、いろいろ考えたい。
  • Streemの考え方、やっとわかってきた。おもしろい。
  • もっとシェルの考え方身につける必要あるなと思った。

Conway's Law of Distributed Work (Casey West)

  • リモートワークの話。
  • CAP定理を組織にあてはめるっておもしろかった。
  • 「全員がオフィス通えるロケーションにいる」って中でリモートやる価値あるかどうかとか気になった。
  • 「リモートやりたいならまずは一週間とにかく試してみろ」的なの、やってみたい。

Podcasting, Media for Web Engineer, and CPAN (yusukebe)

  • Podcastのテクニカルな話ガッツリ!って感じだった
  • 意外と始めるコスト低いんだなとわかった
  • エンジニアのYoutuber的な感ある。始めるのは簡単だけど、人集めるのと、継続するの大変そう。

LT

  • PHPの闇の話印象に残ってる
  • うちのSlackにいる小野寺小咲さんと会話したいなと思った。
  • 株式会社ネコトーストラボさん覚えた。

タイムテーブルの事情とか、満員だったりで聞き逃したので、あとで読むシリーズ

こうやってまとめると、結局見たいのだらけだった感じだ。


疲れたし、長くなったので、2日目はまた別途書きます。

すっごい小さなところからOSSにコントリビュートした

以前、職場の人が、あるjsライブラリのGitHubリポジトリ

「nodeだけじゃなくて、bowerでもinstallできるようにしてくれよー」(英語)っていうissueをカジュアルに立てていて、

「気負わずにOSSにissue立てたりする姿勢尊敬しますー!」と言ったら、

Rubyのコミュニティとか参加してたら結構そういう人いるんじゃないですか?」と言われた。

「初心者向けのコミュニティ(よちよち.rb)ということもあって、やっぱりハードル高く感じちゃいますね。今Railsにコントリビュートしてるのは僕が知ってる限りだと2人です(※)」 と答えると、

「いや、Railsへのコントリビュートはレッドオーシャンなんで、もっと別のOSSをターゲットにしたほうがいいですよw」と言われたことがすごく心に残っていた。

「なるほど、コントリビュート○貞を捧げるのはRails以外が良さそうだな」とそれ以降思っていて、期せずしてそのチャンスが今月2回もあったっていう話。

※よちよちでRailsのコントリビュートしてるのは僕の知ってる限りだと @yuki3738 さんと @5t111111 さん。
@yuki3738 さんがコントリビュートした経緯はこちらに -> 新米エンジニアがRailsにコントリビュートした話 - スパイスな人生

つくって学ぶプログラミング言語

300近いはてブ数を集める、達人出版会から出ている「つくって学ぶプログラミング言語 RubyによるScheme処理系の実装」という本、実は前職の先輩が著者なので、わかんないことがあったら直接聞ける的安心感もあって、仲間内で読書会をやっていた。

たまたま、読書会中に @katorie さんが「本のとおりに書いていると動かないかも」という箇所を発見し、「PR出しましたよー」って僕から直接伝えられるメリットもあるなと思い、自分が本のGitHubリポジトリにPRを出す流れとなった。

とは言ってもコード的には、カンマを1つ消すだけなので1バイトの修正でしかない。

github.com

さらに言えば、リポジトリの管理者は知り合いなのであって、「初めて他人が管理するリポジトリにPR投げる」って意味では心理的ハードは最大限に低いはずなのだけれど、やっぱりPR送る瞬間はそれなりに緊張感があったw

そんな緊張とは裏腹にあっさりマージしていただいて、晴れて「つくって学ぶプログラミング言語 RubyによるScheme処理系の実装」のコントリビューター(と言っていいのだろうか??)になることができた。
少なくともGitHubのContributions Graphには載った。

f:id:highwide:20150729022204p:plain

autodoc

仕事でRuby 1.9系のAPIをいい加減2.x系にしたいねって話があって、それにあたってドキュメンテーションを改めてきちんと行った上で、Ver. up後の動きを確認したいねってことになった。

そこで、 r7kamura/autodoc が使えるかもって話になったものの、 autodocを bundle install したあとにテストが必ずErrorになる事態に陥った。

当然最初はgemを疑う前に、自分たちのAPを疑ったものの、どう見てもautodoc内のラムダあたりでsyntax error吐いてるしなぁと思い至る。

そこで試しに、vendor/bundle配下のautodoc gemを直接、 arrow記法が使われてたlambdaのsyntaxを -> から lambda に変えてみると動いた!

むむ、これは本格的にgemのラムダ周りが怪しいのかもしれないと思って、ググってたらとうとうこんな情報を見つけた。

ruby-journal.com

えええ〜、Ruby 1.9系と2.0系だと、 -> と引数の ( のあいだにスペースあると動かないの...マジで!?
と思いながらも、スペース消すだけだしなと思って、「プルリクチャンス」だと思うことにした。

ここも、r7kamuraさん、日本人だし、(あちらは僕のこと知らないけど)僕はRebuild.fmでrubotyとか作ってる人だって知ってるし...って感じで多少心理的ハードルは低かったように思う。

というわけで、7/27に出したPRを早々に7/28マージしていただいて、ご丁寧に CHANGELOG.mdthx @highwide とまで書いていただいた。(嬉しかった)

github.com

ただし、こちらもスペース消すだけなので、1バイトの修正w

そんなわけで

結果的に、7月はOSS2つに、計2バイトのコントリビュートができたw
ただし、単純なコントリビュートが常に善かというとそういうわけではなくて、OSSのメンテナさん的に「逆に対応がめんどい」みたいなこともあるらしいと聞いてはいる。
でも、そのへんの話はケースバイケースだったり、メンテナさんの考え方次第的なところもあるとは思う。
というわけで、個人的にはこんな感じで経験積んで、ときにはリジェクトされたりしながらも、使っているOSSにカジュアルな貢献ができるようになればいいとは思っている。

蛇足

autodocに出したPRがマージされた7/28が自分の誕生日で、ちょっといい誕生日になったなと思った。

VimでC-]が動かなかった

職場の方に
Vimでtagジャンプ使ってないんですか!?Vim使うなら絶対に使った方がいいですよ」 と言われたので、設定をいれた。
ところががタグジャンプを行うデフォルトのキーバインド 「Ctrl-]」が動かなかったのでちょっと苦戦した話。

OS X Yosemite(10.10.3) + iTerm2 + zsh でやってます。

結論

iTermのキーバインドとコンフリクトしてた。

詳細

まずはプロジェクトごとにtagつけてくれるツールをインストール。

brew install ctags

プロジェクトルートでタグづけ。

ctags -R

あとは、
Vim開いて、任意の変数やメソッドにカーソル合わせて「C-]」 押せばタグジャンプできるはず...!!!
が、動かない。

ただ、
「C-w, ]」でプレビューウィンドウでのtagジャンプはできるのでtag自体は生成できている模様。
とするのは、疑わしいはキーバインド

ところが、

と、確認しても「C-]」を何かに割り当てている様子はないように見える。
しばらくハマっていたのだけれど、ふとしたときにMacデフォルトのターミナルを使ってみたところ、問題なく動作!
というわけで、犯人はiTerm2だと判明。

振り返ってみると、お世話になりまくったこのページで、tmuxのpane移動に「C-]」を割り当てていることに気がついた。

【図解】ゼロから始めるモダンなコマンドライン環境作り #iTerm2 #tmux #zsh

僕は「C-b, o」でpane移動は慣れてきていたこともあり、iTermからは設定削除。
無事にタグジャンプできるようになった。
モダンなエディタやIDEなら当たり前なんだろうけど、すげー便利に感じた。

蛇足

いるかわからないし、どれくらい効果があるかけど、同じ症状になった人が検索でこのページにいつかたどり着けるよう、こんなこと書いておく。

  • Ctrl カーリーブラケット 動かない
  • Ctrl 波括弧 タグ ジャンプ しない
  • Ctrl curly bracket not work

自分の職場でよちよち.rbの活動をやった

4月に転職して早くも2ヶ月が経った。 コード書けなくて悔しい思いをしたり、やっとの思いをしてリリースができたりといった、 それなりに気持ち的に浮き沈みがありつつも、平均すればポジティブな気持ちで毎日を送っている。


今日は兼ねてより参加していたよちよち.rbにて、 勤め先であるリブセンスの場所を使えないかという打診が主催者のゆかおさんからあったので、 会場として、会社の会議室を提供することができた。 自分の環境を変えようと思ったきっかけでもあるコミュニティにささやかながら恩返しができるのは嬉しい。

様子↓

(つぶやいてもらった)


meetup内容としては、予定されていたRails Tutorialの輪読を行わずに、

  • Rails Tutorialの輪読これからも続けていく?
  • そもそもよちよち.rbのあり方って?

みたいな話をした。

個人的には毎週主催者のゆかおさんが休まずに継続しているからこそ価値あるコミュニティになっていると思うので、 ゆかおさんがモチベーション上がる何かの中で、参加者の皆が協力したり、学んだり、いい感じになれればいいと思う。

4年間勤めたSIerを退職した

タイトルの通りなのですが、新卒で入って、丸4年間勤めたSIerを退職しました。 2015年4月からはWeb系企業でエンジニアとして働くこととなります。

なぜ辞めたのか

一言で言ってしまえば「SIerのことよくわかってないまま入ってしまった」。これに尽きます。

僕はもともとコンテンツやサービスを作りたい人間でした。そんなわけで就活当初は出版業界を志していたのですが、自分の経験やスキルから就活で挫折を味わいます。そのときに考えたのが、「別に紙のコンテンツにこだわらなくてもいいかな」ということでした。

じゃあ、IT系ってアリだなと思ったのですが、一方で当時は「ある程度生活は安定させたいな」と思った末、通信事業者や、そのグループのSIerを志望する流れとなり、結果、新卒で通信系のSIerに入社することとなりました。

「通信事業者のコンテンツ創造に技術的側面から携わりたいから」という当時の志望動機に嘘偽りはないですし、就活生の掲げる志望動機としてはある程度真っ当かなと今でも自分で思うのですが、携わったシステム的にも、仕事のやり方的にも、思い描いていた仕事像とは異なるものでした。

結局、よく「SE(笑)」と言われているとおり、「コードを書かない/書けない」、「スクリーンショットExcel貼り付け」、「Excel方眼紙の設計書をSVN管理」といったことが当たり前とされる文化の中では、自分のやりたい目標に向けてのスキル醸成は(たとえ担当システムが変わったとしても)難しいだろうなと、だんだん気づいていった次第です。

ただ、単純に前職disやSIerオワコン論を振り回してもあまり意味が無いとは思っていて、結局新卒のときにそういう環境を選んでしまったのは自分だからなぁという思いがあって、冒頭の「SIerのことよくわかってないまま入ってしまった」という言葉につながります。

前職に入ってよかったこと

ゆるやかに理系学問への理解を深められた

今後「文系出身」であることを誇ったり、言い訳にしたりしてはいけないという気持ちはあるのですが、僕はもともと文学部出身で、コンピューターサイエンスとは縁遠い世界にいました。

そんな中、「導入研修」としてIT基礎やJavaを学んだり、IPAの情報処理資格を受験するための手ほどきや奨励金を出してくれたり、コード書かないながらも最低限はIT技術に触れる生活を送ったりすることで、ゆるやかに、エンジニアとして自学自習するための土台を作ることができたように思います。(といっても、まだまだ勉強不足なのですが...という予防線は張らせてください(汗 )

「IT技術が今全然わからなくてもSEになれますよ」という新卒採用時の文句は、「プログラミングは外注に丸投げなので業務でやりませんよ」という意味もあるし、「今全然わからなくても研修や業務の中で教えますよ」という意味もあったと思うのですが、後者の恩恵を受けられたのは、僕には幸せなことでした。

すごい人たちと知り合えた

なんだかんだ言っても、すごい人っているんですよね。業務で使ってないはずの関数型言語をつないこなせる人、業務で使ってないはずのGitについて内部構造まで知ってる人、業務で使ってないはずのバイナリを読む力を持っている人...etc。

なんでこの会社にいるんだろうという気はしなくもないのですが、なぜかいてくださったおかげで、彼らとお知り合いになることができました。きっとこれから僕がスキルを高めたとしても、尊敬し続けるであろう人たちと知り合えたのは、これまた幸せなことだと思っています。

これから

企画〜コーディングまで担うエンジニアを募集している企業に採用してもらったので、当初思い描いていた仕事により近づくことができそうです。どうやら、よちよち.rb等で勉強していたRailsにも携わることができそうで、嬉しく思っています。

ところで、ここ最近世を騒がせている退職エントリ関連の一連の流れを追ったのですが、素直にすごいなぁと思ったことがあります。それは自分の技術スキルに絶対の自信があること。

自分のスキルでやっていけるのか、自分にエンジニアとしての適性があるのか不安でしょうがない...というのが、新しい職場に初出勤する前夜の、僕の正直な気持ちです。 所属しているコミュニティの名前のとおり、まだまだ「よちよち」であることを自認していて、今後どれだけ経験を積んで、勉強すれば、技術で飯食っていくに値するエンジニアになれるんだろうと思っています。

ただ、エンジニアとして成長するには、つべこべ言わずコード書いて勉強するしかないというのも、頭では理解しているつもりなので、優秀で勉強熱心なエンジニアの方が多い環境に身を置くことができてよかったなと思うことにします。

やるだけやってから「やっぱり適正なかったわw」となっても、きっといろいろと得ているであろうと、今は信じることにしようかと。


そんなわけで、明日の初出勤を前に、ドキドキしながらこのエントリを書きました。 おやすみなさい!

GitHub、消えたコミットを追え

このエントリの結論

GitHubにpushしたコミットは、後でrebase -iなどで取り消した後に再度pushしても、コミットのハッシュがわかれば再度アクセスできる。

経緯

社内のGeekの人たちによる、Prototype Cafeというコミュニティでゆるっと活動しているのですが、そこのSlackでこんなことが話題になりました。

git rebase -iなどで取り消されたcommitについていたGitHubのコメントは消えてなくなってしまうのだろうか?」

ということです。

具体的に言うと、Slackで飼ってるHubotにスクリプトを追加するとき、以下のようなことがあったのです。

  1. 僕が「A」というコミットをする。
  2. 「A」というコミットにtypoがあったので、typoのfixを「B」というコミットにする
  3. 僕が「A」「B」というコミットを含むブランチからPull Requestを作る
  4. 先輩がコミット「B」に対して、これは前のコミット「A」とまとめてほしいと言う
  5. 僕が手元でgit rebase -iをし、「B」をsquashする
  6. git push -f origin {作業したブランチ}とする
    -> おや、先輩が「B」に対してしてくれたコメントが消えてるぞ!

まぁ、今回の場合は解決済みのコメントが消えていて何か困るということはありませんでしたし、連携しているSlackにもコメントが飛んできていたので経緯が追えないことはないのですが、なんとなく気になったので別途実験してみました。

① コミット「A」「B」からなるプルリクエストを作る

  • コミットAのSHA1ハッシュ: 4d0a7b17d356b3db5b36ee891ffbe985becd052b
  • コミットBのSHA1ハッシュ: 4ac7bcaa958d7031b600d13ed4c26a57717e7887

f:id:highwide:20150206203243p:plain

②コミット「B」にGitHub上でコメントする

f:id:highwide:20150206203253p:plain

③手元でrebase -iして、コミット「B」をsquash(※)する

  • 新しいコミットのSHA1ハッシュ: 1070b14877f7cb1896920132f15bb666bb04e58d
    -> 意図した動きは「B」を「A」の中に入れることだけれど、もともとの「A」のハッシュからも変わっている!!
    ※ s, squash = use commit, but meld into previous commit

git push -f origin {このブランチ}する

f:id:highwide:20150206203302p:plain

結果: やっぱりコメントはGItHub上では消えたように見えますね〜。


では、GitHubではコミットごとにパーマネントリンクを持っていますが、消えてしまったコミットにアクセスすることはできるのでしょうか。 コミットのパーマネントリンクは以下の通りです。

github.com/{ユーザー名}/{リポジトリ名}/commit/SHA1ハッシュ

というわけで、以下のとおり確認してみると...

コミットAのパーマネントリンク: https://github.com/highwide/test_repo/commit/4d0a7b17d356b3db5b36ee891ffbe985becd052b

アクセスできるー!!

コミットBのパーマネントリンク: https://github.com/highwide/test_repo/commit/4ac7bcaa958d7031b600d13ed4c26a57717e7887

そしてコメントいたー!!!!

f:id:highwide:20150206203313p:plain

つまり、コミットログ上、追うことのできなくなったコメントですが、コミットのパーマネントリンクを指定して見てあげれば、コメントも追うことができるのですね。
ただ、ログから消えてしまったハッシュを調べるというのは難しそうではあります。
(Slackに飛んでくるGitHubのメッセージではショートハッシュしか確認できませんでした)


というわけで、今回調べたかったことは以上なんですが、改めてコミットは気をつけなくちゃいけないなぁと思った次第です。
うっかりパスワードとかをコミットしてGitHubにpushしまうと、そのコミットをrebase -icommit --amendで消しても、ハッシュがわかってしまうとアクセスできるということですもんね。
公式によると、そういったコミットが含まれる別のPRや、Clone/Forkにも注意ということのようです。
最終的な手段はサポートへ消してもらうよう連絡することみたいです。

https://help.github.com/articles/remove-sensitive-data/

気をつけなくては。