portal shit!

Rails のログファイルを tail -f で見たいんだけど余計なものはフィルタリングして表示されないようにしたかった。最初は以下のようにしてみた。

⚡ tail -f log/development.log | grep -v -e ‘asset|Cache|Rendered’

これだと条件にマッチする行は表示されなくなるけど改行が削除されずに空行がたくさん表示される。これでは見やすいとは言えない。以下のように sed で空行を削除するようにしてみた。

⚡ tail -f log/development.log | grep -v -e ‘asset|Cache|Rendered’ | sed -e ‘/^$/d’

しかしこうすると必要な情報まで表示されなくなってしまう。 tail ではなく cat とかでやると望んだ通りになる。 tail -> grep -> sed の流れだとうまくいかないぽかった。

“tail grep sed” でググったら以下のような記事を発見したので試しに grep に —line-buffered オプションを渡してみた。

grep, awk, sed でバッファしない方法 | TECHSCORE BLOG

こんにちは、TechscoreBlogのログ閲覧が日課になっている河野です。ログをtailでリアルタイムに見ているときに、grep, awk, sedと組み合わせることがあります。ところが、特にオプシ...

www.techscore.com

⚡ tail -f log/development.log | grep -v -e 'asset|Cache|Rendered' --line-buffered | sed -e '/^$/d'

これで望んだ通りの出力になった。便利。

rebuild.fm でたびたび HipChat とか IRC の話がある。最近は Slack というサービスが流行っているらしい（Rebuild: 54: Email Will Never Die (naan, N)）。ウェブ開発者じゃない人の間にも広まってる感じなのかな。自分はいまの会社に入って初めて IRC に触れて便利だなぁと感動したし、もう IRC のようなチャットシステムがない会社で働くのは無理だなぁという感じがする。

これまで働いてきた会社の情報共有手段を振り返ってみる。

最初に就職して三日で辞めた会社

数人しかいない会社。なんかよくわからない P2P のメッセンジャーだった。一対一でしか情報やりとりできない。 URL の共有とかファイル共有に使ってた。口頭での情報共有がメイン。

二番目に勤めた地元のホームページ制作会社

10人くらいしかいない会社。 Yahoo! メッセンジャーだった。グループチャットとかできたのかもしれないけど一対一でしか使ってなかった。使い方は同じように URL とファイル共有だった。口頭での情報共有がメイン。

三番目に勤めた福岡のウェブ制作会社

社員数は70人くらいで東京やベトナムの社員とも協働することが多かった。基本的に ML でやりとりして、チャットは MS の Communicator とかいうやつだった。 Active Directory なやつ。グループチャットとかあったけど基本的に一対一で情報やりとりしてた。この会社くらいの規模から口頭での情報共有が厳しくなってくる。

現在の職場

社員数300人くらいで、 IRC でやりとりしてる。チームによっては Skype 使ってるところもあるけど、基本的には IRC 。 IRC の良いところは、話しかけることで会話が始まるのではなく、チャンネルがあってそこに人が入っていく感じ。たまり場感ある。大学生の頃サークルやってなかったからちょっと違うかもしれないけど、サークルのたまり場に似てるんじゃないかという感じがする。 IRC に接続すると誰かいてなんか返事が返ってくる感じがいい。

あと ZNC などの IRC バウンサー使うと自分が接続していなかった間のログも読めて良い。 Skype のチャットにもこういう機能あるけど、 Skype はグループを作ったりとか人との会話とかで、人と人のチャットに主眼が置かれる。 IRC はトピックごとに場所がある感じ。

社員全体へのお知らせとか #all チャンネルとか #fukuoka チャンネルに書かれるけど非同期に読めるのが良い。 MS の Communicator とかはその場ですぐ来たメッセージ読んで返事しないとちっこんちっこんアイコンが光ったりしてうざい。というか一対一の会話ツールは非同期コミュニケーションしづらい。 IRC だと手が空いたときにまとめて読んだりできるので良い。

あと IRC は Ikachan とか Hubot とか bot にいろいろやらせられるのがよい。 Jenkins のビルドが走ったら IRC に通知する、デプロイが始まったら IRC に通知する、 Hubot にデプロイをやらせる、 GitHub の Issue にコメントがあったら IRC に通知するなどなど。

三番目の会社は各人が情報にアクセスできるレベルが Active Direcotry で管理されてて必要な情報を必要な時に得ることが難しかった。 IRC でも選ばれたメンバーしか入れないチャンネルとか作ることもできるけど基本的に本人がこの情報欲しいと思ったときにそのチャンネルに入って情報を得ることができて効率が良いと感じた。

もっと多くの人が IRC とかチャット使って仕事して欲しい

IRC はずっと前からある技術だけどいまでも便利な情報共有手段だし何でもっと多くの会社で使われないんだろうという感じがある。小さな会社じゃ自前で IRC サーバーたてるのとかしんどい感じあるしある程度技術者がいて運用スキルがある会社じゃないと使えないのかも知れない。いまは HipChat とか Slack とかあって IRC サーバーたてなくても良いし ZNC とかの使い方がわからなくても過去ログ追えたりするわけだし、ウェブ開発者がうようよいるような会社じゃなくても便利なチャット使えるのだからもっといろんな会社に広がるといいと思う。自分がいまの会社に入ったときに感じた情報源の広がり感をもっと多くの人に味わってもらえると日本社会もっと良くなる気がする。

隔週木曜日にグルーヴノーツ社と会場を交代交代で Fukuoka.rb やってたんだけど、8/21 の回がたまたま Fukuoka.go と重なってしまって、Fukuoka.go は同僚でプラチナサーチャーでいけすかない有名な @monochromegane さんが主宰しててペパボ開催だったし、 Fukuoka.rb 重鎮の @nagachika さんが Fukuoka.go に参加登録してたので、どうせならということで Fukuoka.go と Fukuoka.rb 共催することになった。

なんか LT できるっぽい感じだったので大して技術力もないくせに LT させてもらった。他の人のハイレベルな話が続いた後に、本当に Lightening な感じですぐ終わるトークをやらせてもらった。新卒研修のときのスライドの内容をベースに gyowitter のご紹介をさせてもらった。

ただ社外の人も来る勉強会で話できたのは良い経験になった。もうちょっとネタよりから技術的にも意味がある内容の発表をできるようになりたいなぁ。

合同勉強会、普段見かけない人とかも来て良い感じなのでたまにできるといいなぁと思った。あと今回懇親会とか企画されてなかったので次は懇親会もあると良さそう。

新卒研修の一環で、若者向けにおっさんエンジニアが座学をするという取り組みが会社にあって、自分も担当したので資料を公開します。自分は技術力低くて技術的に有益な話はできないと思ったので奇行に走ってポエムを吟じた。

うちの会社、技術基盤チームの面々がすごく熱心に教育するし前年に新卒で入った若者たちも研修に絡んで斧を投げてくるので新卒で入ると大変便利なのではと感じる。業務として Rails チュートリアルやらせてくれる会社とかあんまないと思うし、おっさんエンジニアによる座学とかもあって、自分のようなポエムから Go 言語の話とか AWS やらインフラの話まで聞ける。技術的に有名な会社とかだと新卒入社時からエンジニアとしての高い能力が求められたりするのではないかと思うけど、うちの会社は雑魚キャラでも入ってから育てる的な環境がある気がするので、当初は Visual Studio でしかコード書いたことないしコードのインデントは Tab とスペースが入り乱れ、そもそもインデントがおかしい、みたいな状態の若者でも研修後には割とまともになってて一年後には Emacs でバリバリコード書いて何食わぬ顔で新サービスリリースしてたりする。なので今は雑魚キャラだけど成り上がってやりたいという方にもおすすめです。

こちらからは以上です。

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 は "はぼっと" なのでは？