portal shit!

会社を辞めた。3年半在籍してた。

ペパボに入る前は凄いブラック企業で働いてて、 Subversion やめて Git 使いたいと言ったら会社辞めろと言われたりしてた。そんなときに蜘蛛の糸のように目の前に垂らされたのが Dazaifu プロジェクトの求人で、藁にもすがる思いで応募し入社したのだった。この辺は過去のエントリに適当に書いてあるので読みたい人は読んで下さい。

前働いていた会社の思い出と近況

いまの会社は労働環境よいんだけど、前働いていた会社がとてもつらかった。どのくらいつらかったかというと、もう辞めてしばらく経つのに、いまだに前の会社にいたころの夢を見てうなされて夜中に目が覚めるく...

portalshit.net

ペパボは働きやすくて、毎日18時になったらみんなさっと帰るし、21時過ぎに会社出ると最終退出者であることもしばしばだった。家庭の事情にも理解があって、育児休業をさせてもらったり、ばあちゃんの具合が悪いときには会社休ませてもらったり早めに帰ったりしてたし、ばあちゃん死んだときにはお花とかも出してもらった。労働環境の他にも年末の社員旅行とかプレゼン大会とか社内の催し物があったりして良い雰囲気だった。課長が女性エンジニアにセキュリティルームでセクハラしてたり社長が気に食わない奴はいきなりクビにしたりしてたブラック企業から移ってきた身にはほとんど天国だった。

なにより自分にとってよかったのが、インターネットが会社になったみたいなところだった。会社に @shikakun がいて、あとから @antipop さん（ Mr. CTO！）とか @udzura さんとか面白インターネットコンテンツな人も入ってきて、自分が @morygonzalez として存在することが是認される感じがとてもうれしかった。

とはいえペパボでもそれなりに厳しいことはあって、そういうのは一昨年の闇アドベントカレンダーに書いたのでこれも読みたい人は読んどいてください。

死んでしまったサービスの供養

この記事は 闇アドベントカレンダー、 22 日目の記事です。何書こうか迷って担当日に書けなかったので三日ほど遅れてしまったけど書きます。2011 年の 10 月から FANIC という音楽配信サ...

portalshit.net

社内ではおおよそ一年おきに異動していて FANIC => MuuMuuDomain => minne と渡り歩いた。そう、僕はいま CM やったりしてる minne の中の人だったのです。

3年半の間に PHP を書くこともあったけど、自分の指向性とかを汲み取ってもらい、概ね Ruby を書かせてもらった。ウィンドウズを使えと強要されることはなかったし、 Ruby は書きたい放題だし、毎日会社行くのが楽しかった。

最後にいた minne は本当に良いチームで、みんなでリーンキャンバス描いたりエレベーターピッチを考えたりして、どうやったらサービスが圧倒的に成長できるのかを真剣に考えてた。

エンジニアはみんなできる人たちで、特に初期から minne を支えていた @mizoR さんが凄く、ちゃんとコンピューターサイエンスのバックグラウンドがあるため文系の自分にはない視点で問題にアプローチしていて非常に勉強になったし、また歩く UNIX の哲学みたいな存在で、小さく作ってこまめにリリースし検証することの大切さを教えてもらった。（@mizoR さん作の rake_notification は神 gem なのでオススメです）

GitHub - mizoR/rake_notification: Notification of status for rake

Notification of status for rake. Contribute to mizoR/rake_notification development by creating an account on GitHub.

github.com

新卒入社の @keokent もできる奴で、モバイル端末へのプッシュ通知をサクッと作るしサービス愛も厚いし、風紀の乱れにもうるさくて、Tシャツの裾は常にズボンにインするように指摘されてた。

去年の4月に入社してきた @amacou さんも凄くて、 Ruby/Rails も Objective-C も両方書けて、出張申請とか経費精算さえできればフルスタックおじさんという感じだった。

ムームードメイン時代に仲良くなりプラチナサーチャーで女性ファン急増中の @モノクロメガネ（いけすかないのでリンクはありません） さんに助っ人で来てもらうこともあって、絶対間に合わないだろみたいな無理めなスケジュールでタスクが降ってきたときにもみんなでホワイトボード囲んでワイワイ開発して余裕で終わらせたりして最高だった。モノクロさんは隙あらば Go で Ruby のコードを置き換えようとするところ以外はエンタープライズ力も高いしスクラムマスター業もこなすナイスガイだった。本当にいけすかない。

何をやらせてもスピーディーにこなす若手ネット芸人 @hisaichi5518 さんとも物理的に距離がある状態で仕事したけど、とにかく作り上げるという力はさすがだと思った。チーフエンジニアの @hsbt さんのオラオラと詰めてくる感じの Pull Request もサイコーだった。チームのエンジニアの間では「 @hsbt さんが通ったあとには草の根一本生えない」とよく言ったものだけど、こういう人がいないとフレームワークや言語のバージョンアップとかインフラ構成の大胆な変革はできないことがよくわかった。そういえば @udzura さんという人とも働いたけど、ギャグが寒いこと以外は問題ないです。

デザイナーやディレクター、サポートメンバーも良い人ばかりで、昨日は送別会を開いてもらったんだけど、こんなに良いチームを去るのは残念で仕方なかった。写真はトデガールズに対抗して森井ガールズが結集している様子です。

福岡でウェブサービスの開発やってみたいけどどこで働けばよいかわからないインターネットをこじらせたウェブプログラマーの人はペパボの門をたたいてみるとよいと思います。

で、誰？

無名のウェブプログラマーです、このような記事を書いてお目汚しをし誠に申し訳ございません。

なんで辞めんの？

「次に行く理由」があるだけで、「辞める理由」はないのです。

株式会社ドワンゴに転職します（4年3か月ぶり2度目） - Kwappa談話室

僕も同じ気持ちです。

次なにやんの？

Kaizen Platform という会社で働きます。無事試用期間を乗り切れるのでしょうか。ご期待下さい。

Ruby で動くソフトウェアは常に何でも最新を追っかけるのが吉な気がする。好きで使ってる earthquake.gem が最近新規インストール時に動かなくなった。バージョンを固定してないジェム（ eventmachine など）のバージョンが上がって死ぬようになったっぽい。そのジェム自身には変更がなくても、 Ruby のエコシステムはどんどん新しくなっている。止まっているのはそれだけでバグ生んでるのと一緒だと思う。なのでジェムを使ったり作ったりしたら、なるべく最新の環境で動くように気を配らないといけないし、いつも使ってるジェムに動かないところ見つけたらなるべく Pull Request 送っていかないといけないなぁと思った。そのことが最終的に自分のためにもなる。 earthquake.gem が動くようになる Pull Request 送ろう。

人生も一緒かなぁ。止まっているだけだとバグ生んでるのと同じなのかも知んない。世の中は常に動いている。

関わっているサイトの Rails のバージョンが 3.2.20 から 4.1.8 に上がった。自分は割と傍観していて他の人が主にバージョンアップしてたんだけど、いくつかはまりポイントがあって自分も Pull Request 送ったりしたのでやったことを書いときます。

1. session に注意

Rails 4 から Flash メッセージ（ログインしましたとか）を格納する session のオブジェクトが普通の Hash になってる。 Rails 3 ではこれは FlashHash とかいうやつ。

Rails 3 から Rails 4 へのアップグレードで一旦 Rails 4 を出してやっぱりやめて Rails 3 に戻したりとか、ロードバランサーに Rails 3 と Rails 4 で動くサーバーを混ぜてリクエスト捌いたりするとまずいことになる。

Rails 4 のサーバーで session 出来た人が次にリクエストしたときに Rails 3 に当たるとログイン後とかに session に残っているメッセージを消そうとする処理とかで NoMethodError が発生して落ちてしまう。しかもたちが悪いことに Rack 層で死んでしまったりするから皆さんよく使ってると思われる ExceptionNotification とかで気づくことが出来ない。これはつらい。

対処法としては Hash クラスをオープンしてモンキーパッチするというのがある。こういうの。

Rails 4 FlashHash Upgrade Gotcha

We upgraded an application from Rails 3 to Rails 4 this week and came across an interesting gotcha which I haven’t seen documented anywhere. As we rolled out the Rails 4 version of the app we split…

jasonneylon.wordpress.com

↑のだと #alert とか #notice が呼ばれたときにエラーになるので自分は以下のようにした。

# NOTE Rails 4 と Rails 3 を混ぜて使うと Hash#sweep が見つからなくてエラーに
# なるようなのでモンキーパッチします。
# 参照: http://jasonneylon.wordpress.com/2014/08/27/rails-4-flashhash-upgrade-gotcha/

class Hash
  def now
    Rails.logger.warn "Stubbing now during upgrade"
    {}
  end

  def keep
    # stub keep for upgrade purposes
    Rails.logger.warn "Stubbing keep during upgrade"
  end

  def sweep
    # stub sweep for upgrade purposes
    Rails.logger.warn "Stubbing sweep during upgrade"
  end

  def alert
    Rails.logger.warn "Stubbing alert during upgrade"
    self[:alert]
  end

  def notice
    Rails.logger.warn "Stubbing notice during upgrade"
    self[:notice]
  end
end

ただこれもパーフェクトではなくて、何もしないように上書きしているだけなのでログイン後のメッセージとか削除後のメッセージが消せなくなったりする。それでも 500 エラーになるよりかはましなのでどうしても Rails 3 と Rails 4 を混ぜて投入したいみたいときなんかは有効。

2. 絵文字に注意

Rails 3 の頃は ActiveRecord が絵文字を DB に保存することが基本的になかった。ユーザーが POST してきたフォームの中に絵文字が含まれてたら絵文字のところでテキストをぶった切って DB に保存するような挙動だった。しかし Rails 4 からは ActiveRecord は絵文字を素通りさせるようになってしまったので困ったことになる。

絵文字を DB に保存するためには、 MySQL の場合は DB のテキストエンコーディングを utf8mb4 というやつにしてないといけない。ただの utf8 だと保存時に Mysql2::Error: Incorrect string value というエラーが出て DB に保存できない。emojimmy のような gem を使えば utf8mb4 でない DB でも使えるけど、 stores_emoji_characters :column_name を忘れずにモデルに定義しないといけない。たとえば購入時に購入した製品のスナップショットを注文テーブルに取るような DB 設計だと、製品テーブルのカラムは stores_emoji_characters してたとしても注文テーブルのカラムを stores_emoji_characters し忘れていて死亡、というような悲劇が起こり得る。

いまはスマートフォンの時代で、ユーザーが入力してくるフィールドには必ず絵文字が含まれると思っておいた方がいい。スマートフォンをメインで使ってる人たちは開発者が想定しないようなフィールド（名前の敬称とか）に平気で絵文字を使ってくる。下手すりゃ住所や名前にも絵文字を入れて送ってくるかも知れない。アスキー文字しか受け付けないようなフィールドは JavaScript やサーバーサイドでバリデーション行ってると思うけど、マルチバイト文字列を受け付けるフィールドの場合はせいぜい長さくらいしかチェックしてないと思う。チェックを入れて絵文字を弾くことも可能だけど、スマートフォンの時代の流れに反しているしユーザーを失うことになりそう。これから新規でサービスを作ってデータベースに MySQL を使う場合はエンコーディングは utf8mb4 にしておいた方がいい。

他にも script/rails が bin/rails に変わってること忘れてて rails runner なバッチ処理が動いてなかったとか、 paranoia.gem の Rails 4 対応バージョンで物理削除のときに呼び出すメソッド名が変わっててはまったとかいろいろあったけど大きなところは上の session と絵文字だった。開発環境で使ってるときには気がつかず本番に出すまで気がつきにくいという意味で非常にやっかいな現象だと思う。

これから Rails 4 に上げる皆さんは頑張ってください。応援しています。

会社のアドベントカレンダーが空いてたので書きました。前日は @kenchan さんでした。

大学生の頃に書いてたウェブ日記を Day One.app に取り込んだ。このウェブ日記は Caldiary というソフトウェアを使っていて、KENT Web で配布されてた CGI をベースにデザインが良くなるように改良されてるやつだった。RSS とかはなく、まだブログがはやる前に作られたものだった。昔ながらの Perl の CGI でデータベースは使っておらず、日記自体はテキストファイルに保存されていた。なので簡単にデータをぶっこ抜けた。テキストエンコーディングが Shift_JIS なのに気をつけつつ UTF-8 に変換して Day One の中にぶっ込んでいった。 Day One が公式で用意してる CLI を Ruby から使いやすくする rb-dayone という gem を使ってやった。

10年前の日記を読み返すといろいろおもしろい。アルバイト先のいやなやつの悪口とかもあるんだけど、人から聞いたおもしろい話を備忘録代わりに書いてて記憶がよみがえったりする。読んでいる本の感想とかもある。黒歴史感あってよい。

Caldiary がすばらしいのはカレンダー形式のサイドメニューがあったことだ（おそらくカレンダー付きの日記だから Caldiry なのだろう）。カレンダー式だと一日もサボれない気がしてほぼ毎日日記を書いてた。 Evernote などパソコン上に日記を書けるソフトはいまいっぱいあるけど、カレンダーが出るのは（自分の狭い観測範囲では） Day One しかない。また Day One は見た目が美しく、過去に書いた文書を読むのに適したインターフェースだと思う。もっと活用していきたい。

むかし日記書いてた人は Day One に取り込んでみるとおもしろいのでオススメです。

この記事はPepabo Advent Calendar 2014 - Qiitaの3日目の記事でした。

明日は未定です。

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 言語には夢がひろがりんぐな印象を持ってる。新しい言語勉強するの新鮮で頭が若返りするような感覚あるので引き続き勉強してみようと思います。

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に来てる人たちはみんな公私ともにばりばりコードを書いててとても楽しそうだった。なんだかとても羨ましかった。

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