| @アマグラミング
Rails 、初心者にとってもよいフレームワークだと思う。いろいろ学びがある。ただ、なんとかスクールとかで金払って習うのではなくて、 DHH が書いてる『 Rails によるアジャイル Web ...

Rails 、初心者にとってもよいフレームワークだと思う。いろいろ学びがある。ただ、なんとかスクールとかで金払って習うのではなくて、 DHH が書いてる『 Rails によるアジャイル Web アプリケーション開発』を読むのがよいと思う。あの本はコラム欄に Rails の裏側の思想とかが書いてある。なんとかスクールで習うのだと最速で Twitter クローンを作るだとか、 Rails の使い方しか身につかないのではないかと想像する。なぜ Rails はその様に作られてるのか、その裏側にある考え方は何か、まで合わせて学べばかなり色んなことが勉強できる。 Rails を使うようになって 5 年くらいになるけど、いまだに毎日発見がある。

Rails is omakase (DHH)

Rails is omakase (DHH)

david.heinemeierhansson.com

| @アマグラミング
Vim で Emoji 補完したいと思ってプラグイン探したら見つかった。rhysd/github-complete.vimGitHub のユーザー名とかリポジトリ名も補完してくれるっぽい。設定す...

Vim で Emoji 補完したいと思ってプラグイン探したら見つかった。

GitHub のユーザー名とかリポジトリ名も補完してくれるっぽい。設定すれば Neocomplete と組み合わせて使える。

しかしこいつは自分の環境では単体では動かなかった。(補完用のデータの読み込みに失敗してるっぽい?)元になっている vim-emoji プラグインを入れたら動くようになった。

ユニコード絵文字表示できる環境では補完候補に Emoji が出てくる。

Terminal Vim

ユニコード絵文字を表示できない環境では日本語で Emoji の内容説明してくれる(要設定)。

Mac Vim

便利。

| @アマグラミング
YAPC に行ってきた。ちなみに去年は嫁さんに↓のように言われて行けなかった。俺「東京であるプログラミングのイベント(YAPC)に行っても良いでしょうか?」妻「あんたには中身がない。社長になりた...

YAPC に行ってきた。ちなみに去年は嫁さんに↓のように言われて行けなかった。

今年は YAPC 最後なのでどうしても行こうと思って無理矢理チケット申し込んで飛行機と宿とって行った。帰ってきて嫁さんに感想を聞かれて、詳細を話しても意味わからないだろうから「がんばろうという気持ちにさせられた」と話したら、「えー、それだけ? 何も学んできてないわけ?」と言われた。


一日目

一日目の方は業務の一環として参加させてもらった(チケット代とか飛行機代とかは自腹)。 受付で YAPC Tシャツもらえると思って着替えを持ってきてなかったんだけど申込時にサイズ選んでないのでTシャツもらう意思がないと見なされTシャツもらえなかった。明日着る服がないと思って焦ったけどリュックの中に予備のTシャツ(実家に帰ったときに洗濯したやつ)があって助かった。

Effective ES6

ES6 、全般的に天国ぽかった。 Babel というの使えばもういまから ES6 で書けるっぽい。ただ Kaizen のサービスは JavaScript でやらかすと皆様に多大なご迷惑をおかけすることになるのでリストカット感覚で導入すると危なそうだった。まずは自分のブログとかで実験してみたい。

偶然居合わせた kitak (ペパボ時代の元同僚)と Kaizen Platform で同僚の t32k さんと、二人の金沢時代の友人の方たちと無料弁当を食べた。 YAPC 、飲み物とか弁当とかまで出てすごい。電車賃とチケット代さえあれば参加できる。

TBD

最近なんで並行処理に優れた言語とか流行ってるのかという背景を交えながら、なぜ Streem を作ったのかという説明や Ruby の未来の話しが面白かった。あと質疑応答の返しが面白い。 Matz さんは言語開発者として優れていると同時に優れた話し手でもあるなと思った。

たまたま mizzy さんと隣に座って聞いてたんだけど、 mizchi さんいて(mizchi さんが mizzy さんに話しかけた)こんちゃと挨拶した。 YAPC 有名人ごろごろいるのすごい。

Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜

爆笑トークだったけど、オブジェクト指向や DDD がなぜ大切なのか、というのを業務での経験を交えながら発表されていてよかった。「オブジェクト指向設計入門とか DDD 本とか難しいけどどうやって業務に活かすのか」という質問に対しては、「歯を食いしばって実装するしかない」と返していてよかった。

ロビーでだらだら

見たかった発表満席で入れなかったのでロビーうろついてたら hsbt さんいたので声かけた。そしたらどこからともなくペパボ、元ペパボの人どんどん集まってきて hsbt さんの自撮り棒の被写体になったりしてた。出戻り歓迎しますと言われてニヤニヤしたりしてた。ペパボ版 mizchi さんの gyugyu さんを生で見られたの良かった。

SaaSを組み合わせて作る, ぼくらの障害対応術!

障害発生時に自動的に Qiita:Team に対応報告ドキュメントが作成され、 Reactio というサービス内にチャットルームも自動生成され、チームメンバー全員に電話もかかってきて障害対応に SaaS を組み込んで効率的に仕事をこなす、という LT だった。 LT 中、アラートメールが来るという演出も面白かった(たぶん仕込みだと思う)。

Kaizen Platform への就職を決めたの、要因はいろいろあるんだけど、入社前に CEO の須藤さんが Qiita:Team に書いている Kaizen のモットーみたいなやつを読ませてもらって、それに感銘を受けた、というのがある。自分たちが本当にフォーカスすべきことに注力して、その他のことは外部サービスを利用して徹底的に効率化したい、というようなことだった。実際、 Kaizen は外部の SaaS を利用できる部分は極力利用して自前で実装しないようにしている。それでお金はかかるけど、エンジニアが無駄に秘蔵の社内ツールのメンテナンスで疲弊することがないようになってるし、スタートアップ同士でお互いのサービス使い合って良い循環が生まれている感じする。

ソロ懇親会

一日目は懇親会あって参加してみたかったけど気がついたら募集終了してて参加できなかった。なのでよく知りもしない東京ビッグサイトのプロントの店員に「お疲れ様です」と声をかけられながらビール飲んでスパゲティー食べてソロ懇親会やった。バスでホテルに帰ろうとしたらペパボの元同僚の人いて最近どうですかとか軽く話した。ホテルに着いてからは浜松町の激安寿司屋に潜入したけどシャリがねちゃっとしてて不気味な感じだった。量も多くて腹一杯になってしまってとにかくつらかった。

二日目

だいぶ早めに着いたので余裕をもって座れた。ただ午後のコマは混みすぎてて発表見られないことが何度かあった。次の発表の時間前に部屋の前に列を作ったりするの予備校に通ってた浪人生時代を思い出した。人気講師の講義に群がる代ゼミ生に戻った気分になった。

Adventures in Refactoring

GitHub の人の話、 RubyKaigi の動画とか福岡でのミートアップとかでも聞いたことあったんだけどいまいち何言ってるかわからなんぁという話しする人多かった。今回の人の話はわかりやすかった。リファクタリングしてコード量が増えるのようなのはダメだとか、パフォーマンス劣化させたらダメだとか。あと GitHub では scientist という gem あってこれでリファクタリングの前後のコードの A/B テストみたいなのをやってるそうだった。エラー発生率とかパフォーマンスを計測しているそう。すごい。

昼セッションの弁当売り切れててもらえなかったので下に降りてコンビニで何か買おうかと思ったけどコンビニが異常に混雑してて地方在住者にはあれに並ぶ気になれなくて、一旦はフードコートとか行こうとしたけど結局どこも激混みで、あきらめてセブンイレブンでサンドイッチとか買ってプロントで買ったビール飲みながらオープン席的な場所で食べた。偶然、隣にモテメンガールズを引き連れたモテメンさんがやってきてモテメンステッカーくれた。家の冷蔵庫に貼ろうと思います。

【特別企画】YAPCあるある(仮)

YAPC の 10 年間を振り返るという座談会企画だった。僕はミーハーなのでこういう話しを聞くのは好きなので面白かった。そもそも始まりは宮川さんが台湾で行われた Perl のカンファレンスで来年は日本でやってくれよと声かけられてスライドの最後に急遽やりますというのを盛り込んで宣言したのが始まりのようだった。最初の会場が大田区産業会館というの地味な感じがあってよい。2007年だか2008年だかの YAPC で利用したフランスの決済システムがちゃんと動かなくて宮川さんがフランスまで行って直した、という話すごかった。伝説っぽい。

あとは牧さんがどれだけこれまで YAPC で苦労したか、という話だった。こういうの若い人聞いてもあまりぴんとこないかもしれないけど、所帯を持ってたりするとなかなか家庭外の活動に時間を割くのは大変だし、結婚式挙げたことある人はわかると思うけど、人を何百人と集めてなにがしかの催し物をやるのはとんでもなく骨の折れる大変な作業で、それをボランティアで行うのは本当に大変だと思う。若い人はもっと牧さんに感謝した方がよい。

Evaluating your stylesheets

同僚の t32k さんが LT 通ってて発表した。伊藤直也さんのこといじって受けてた。作ったスタイル何とかという CSS を解析するソフトウェア自体も良さそうだった。

コミュ力あげてこ

一日目は hitode909 さんの発表の裏で話を聞けなかった cho45 さんの LT 面白かった。前の人がたまたま電話の話してて、その後に登場した cho45 さんがモールス信号の話というのが最高だった。 cho45 さん、ツイッター見てる限り気むずかしい人なのかなと思ってけどおもしろお兄さんという感じで良かった。

クロージング

ヒトデさんがベストトーク賞とってた。なぜか自分のことのようにうれしかった。

牧さんのこれまでの苦労話とかを最後にもう一回聞いたけど本当に大変だったと思う。2000人以上来場するイベントを取り仕切るのは筆舌に尽くしがたいほど大変なはず。牧さん、 udzura uzulla さん、運営の皆様本当にお疲れ様でした。

| @アマグラミング
Rails とかで例外が発生したときに Slack に通知するやつ作った。 exception_notification という便利 gem のプラグインとして動く。 ...

ExceptionNotification::Slacky

Rails とかで例外が発生したときに Slack に通知するやつ作った。 exception_notification という便利 gem のプラグインとして動く。

morygonzalez/exception_notification-slacky

morygonzalez/exception_notification-slacky

Notify exception to slack channel. Contribute to morygonzalez/exception_notification-slacky development by creating an account on GitHub.

github.com

実は ExceptionNotification 本体に SlackNotifier あるんだけど、通知内容があっさりしてて自分たちのユースケースには合わなかった。 IRC 使ってた頃は同僚のスーパープログラマー @udzura さんが作った exception_notification-ikachan を使ってて、それと同程度のエラー通知が来るのを Slack で実現したかった。

世の中には Airbrake のような便利なサービスあって、エラーの統計情報とか取ってまとめて通知してくれたりするものもあるけど、甘えてはいけない。エラーが即 Slack に通知されることで、バグを放っておくと Slack のチャンネルがてんやわんや状態になって業務に支障が出るのでバグを直すインセンティブが生まれ、ソフトウェアの品質が向上していくのである。

| @アマグラミング
Pull Request 、レビューしないといけないものが貯まってしまってつらいと感じることが多かった。そういうつらみを解消するための ruboty プラグイン作った。 ...

Pull Request 、レビューしないといけないものが貯まってしまってつらいと感じることが多かった。そういうつらみを解消するための ruboty プラグイン作った。

morygonzalez/ruboty-check_pr_please

morygonzalez/ruboty-check_pr_please

make ruboty beg pull request review. Contribute to morygonzalez/ruboty-check_pr_please development by creating an account on GitHub.

github.com

ruboty-cron と組み合わせて

@ruboty [GitHub の Issue のラベル名]のPull Request

という感じで job 登録しておくと、毎時決まった時間になったら Bot が Pull Request のレビューを促す。

便利。

使い方

  1. ruboty の Gemfile に gem 'ruboty-check_pr_please', github: 'morygonzalez/ruboty-check_pr_please' と追加する
    • 定期的に動かすためには ruboty-cron もいる
  2. ruboty の .env に GITHUB_ACCESS_TOKENGITHUB_REPOSITORY='owner/repo' を書く
  3. ruboty をデプロイする

開発時に苦労した点

ruboty 、 rubory とタイポしてしまうこと多くてつらかった。

| @アマグラミング
関わっているサイトの Rails のバージョンが 3.2.20 から 4.1.8 に上がった。自分は割と傍観していて他の人が主にバージョンアップしてたんだけど、いくつかはまりポイントがあって自分...

九州新幹線

関わっているサイトの 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

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 に上げる皆さんは頑張ってください。応援しています。

| @アマグラミング
Lokka 、フォームの DOM が bot で解析しやすいのか大量にスパムコメントが登録される。スパムを一括削除する機能は自分で作って Lokka にパッチ送って取り込まれたけど、 Lokka...

Lokka 、フォームの DOM が bot で解析しやすいのか大量にスパムコメントが登録される。スパムを一括削除する機能は自分で作って Lokka にパッチ送って取り込まれたけど、 Lokka の ORM の DataMapper は一括削除するときに馬鹿っぽい SQL 投げて一括削除は処理が重いし、そもそもスパムコメントを定期的に消すという行為自体が面倒くさい。

むかし P_BLOG でブログ書いてた頃もある頃からスパムコメントが大量に来るようになったので reCAPTHA を導入してみたらとんとスパム来なくなった。

504 Gateway Time-out

504 Gateway Time-out

portalshit.net

また reCAPTCHA 使おうとして久しぶりに調べてみたら Google のプロジェクトになってた。

Error 404 (Not Found)!!1

Error 404 (Not Found)!!1

www.google.com

設置してから二日くらい経つけどとりあえずスパムコメントは来なくなった。便利。念のためプラグイン化しておいた。

morygonzalez/lokka-recaptcha

morygonzalez/lokka-recaptcha

Lokka で reCAPTCHA するやつです. Contribute to morygonzalez/lokka-recaptcha development by creating an account on GitHub.

github.com