ログイン処理のコードレビューにおいて、認証部分が自作されていて、md5をつかっていたので、なぜ自作するのか?なぜmd5を使うのか?という点について議論になりました。

  • CodeIgniter-Ion-Authを使う
  • blowfishを使う(phpならpassword_hash関数、PASSWORD_BCRYPTオプションが良さそう)

僕は自前認証かつmd5を使う意味がわからなかったのでちょっと辛辣な表現になってしまいました。(その方が安全で楽なのに何故しないのか?的な)

ちょっと揉めてしまいまして、

「中途半端に(その実装を)採用しちゃったせいで、なんかあったら駒形さん直してくれんの?土日でも対応してくれんの?」

という感じになり、最終的には、

「レビューはあくまで"サジェスト"に留めて欲しい。」

ということになりました。コードレビューにおいて、

「ここはAAAではまずいのでBBBにすべきです。」

ではなく、

「ここはAAAよりよいBBBというやり方がありますよ。採用するかしないかは…アナタ次第です m9」

という感じですね。

https://gyazo.com/e00a80de33754a6f65c5a1c11ee15851

ホント レガシー改善は地獄だぜ

関連:レガシーPHP改善日記シリーズ

config/application.rbからは設定がなくなっている。

# Settings in config/environments/* take precedence over those specified here.
# Application configuration should go into files in config/initializers
# -- all .rb files in that directory are automatically loaded.

上記のようにconfig/initializersに置けとのことなので置く。

config/initializers/i18n.rb:

Rails.application.config.i18n.default_locale = :ja

いつも忘れてググるので。

下記のようにmigrationを作るとcreate_join_tableを使ってくれる。

$ rails g migration create_join_table_user_team user team

下記のような内容でできる。

class CreateJoinTableUserTeam < ActiveRecord::Migration[5.0]
  def change
    create_join_table :users, :teams do |t|
      # t.index [:user_id, :team_id]  
      # t.index [:team_id, :user_id]  
    end
  end
end

indexは必要だったら作れということでしょう。(優しい)

create_join_tableの良いところはテーブル名の順番をきにしなくて良いところです。この例でもuser、teamという順番で指定してるけど実際のテーブルは下記のようにteams_usersになってる。

# \d teams_users
  Table "public.teams_users"
 Column  |  Type   | Modifiers 
---------+---------+-----------
 user_id | integer | not null
 team_id | integer | not null

エラー管理サービス、Airbrakeが有名ですが、怖話ではRollbarを使っています。(確か無料枠の広さで選んだ)

cronで動いているバッチ(rails runner利用)などはrack middlewareを通さないのでエラー拾わず困っていましたが、rollbarではrollbar-rails-runnerコマンドを使えばよいみたいです。(単にevalしてる)

$ RAILS_ENV=production bundle exec rollbar-rails-runner 'puts User.count'

rollbar/rollbar-gem: Exception tracking and logging from Ruby to Rollbar

便利。

答え

ストロボリンガーを取り付ける。

問題

弊社ではインターンも含めてずっとヘッドフォンして作業してるのでお客様がきても気づけないという問題がありました。

弊社 @machida が @a_matsuda さんに相談した所、ユナイテッド・デザインワークス株式会社を紹介していただき、ストロボリンガーというハードを取り付けてもらいました。

ユナイテッド・デザインワークス株式会社 - ホーム

ストロボリンガーはドアフォンに取り付けると(たぶん)音や振動を検知して大音量と派手なストロボの光を発するものです。

ギターのピックアップみたいに?物理的に拾うので端子がなくても連携できるよがよいです。

結果

こうなりました。

ドアフォンにはマイク的なもの?を取り付ける。

https://gyazo.com/81ef08a394dca8d147e49c398c89704a

感想

元々のドアフォンはMAXにしても音はささやかで、光も作業スペースとは別の場所で光るだけなので気づけませんでしたが、ストロボリンガーを取り付けてからは最初はドキッとするほどの大音量 + かなりのビカビカで光り、100%気づけるようになりました。

二週間ほど使っていますが問題はなく、満足しています。

今日、案件が終了したのでお仕事を探しております。

二文字で表現すると無職です。😢

ここ数年のお仕事戦略の変遷

  1. rails案件がやりたい期
  2. iOS案件がやりたい期
  3. レガシーPHP改善期
    レガシーPHP改善日記シリーズ - komagataのブログ
  4. インターナショナルな案件やりたい期
    東京にいながらにしてインターナショナルな環境でプログラマー(Rubyist)として働くというお話 - 僕は発展途上技術者
  5. ペアプロ期
    ペアプログラミングのコツ - komagataのブログ
  6. リモート期

直近のお仕事

今日終わったお仕事も週3日でリモートでのお仕事でした。

フルリモートだと何やってるのかわからなくなりがちですが、毎朝ハングアウト朝会をやってたので生活リズムも崩れず、何やってるのかわからなくならずによかったです。

探したいお仕事

直近と同じようにリモートがいいなと思っています。

僕は自社オフィスに通ってお客様の作業を行いますが、自転車で30分という僕にとってベストな距離なのでとても快適です。普段自転車だと通勤ラッシュが余計に辛い…。

また、週2日は自社サービスに確保しているので週3日までがありがたいです。

得意な仕事とやりたい仕事

得意な仕事

やりたい仕事

  • golang(めちゃ速そうなので)
  • Swift(怖話iOS版を書き直してるので)
  • Android(怖版Android版に役立つ)
  • ReactなどのやったことないJSフレームワーク= Angular1.x、Vue、Backbone、Marionette、Knockout、Polymer以外(勉強になるので)
  • rails(自分にとっては楽なので)

もしお仕事ご存知の方がいらっしゃったらこのブログのコメント欄はつかいづらいので @komagata 等他の方法で連絡いただけるとありがたいです。 🙇🏻

7月15日追記:ご連絡くださった方々ありがとうございます。直近のお仕事は決まりました。今後別の機会があれば宜しくお願い致します。 🙇🏻

デフォルトになってるから。素晴らしい。

Rails 5 support by marcroberts · Pull Request #46 · evrone/quiet_assets

ハングアウトミーティングでカレンダーに定期予定で入ってる場合などは誰かが声かけてくるわけじゃないのでうっかり数分過ぎてしまいがちです。

僕はこれをやりだしてからほとんど遅刻しなくなりました。

それは30分前だろうが1時間前だろうが既につないでおくことです。

https://gyazo.com/f78bfe9ac94f563fcc3a244948c2098a

Skypeとか開始時にかかってくるタイプだとできない(というか必要ない)テクです。

秘密ですよ。

長いことrailsばっかりやってると他人のコードを「Railsのレール(流儀)にどれだけ乗れてるか、どれだけ流行りの書き方してるか」だけで判断しがち。

見慣れない書き方だったり、他の言語っぽい書き方だったりするとボロカスに評価しているのを見かける。

Railsに浸かり過ぎて、Railsっぽくないもの=悪。レールから外れている=ゴミ。そういった判断は楽だしRailsプロジェクトにおいては大抵あってる(Railsを理解するのを面倒臭がっているゴミコード)んだけど、対象のコードが持つ価値(どんなことをどういう方法で解決してるのか)を判断する力が衰える気がする。

Railsのレールや最近の流行りの書き方とは違うけど、一貫性のあるコードだったり、不具合が出づらく変更に強いコードってのはある。

特にRails経験は浅いけど他の言語・フレームワークに習熟してる人のコードにそういうものが多い。

手癖でやってるとそういう筋肉が落ちる。自戒を込めて。

railsでコメント数の実装の悩み - komagataのブログ

コメント欄で色々アドバイスいただきました。ありがとうございます。

そもそも独立した二つの問題を一度に扱っていました。

  1. count数が遅い問題。
  2. 削除時のdependent: destoryが遅い問題。

counter_cacheやredis云々は1の話で僕の直近の問題である2とは関係無いですね。

2についてはdependent: :delete_all使え!で答えかと思います。(user → post → commentのように多段になってる場合はdelete_allではcallbackが動かないので手でやるべき)

1の方が大きなサービスを作っている方々が気になる問題かと思いますが怖話の規模ではconditional_counter_cacheで十分なので問題になったら考えたいと思います。

逆にdependent: destroyって面倒な処理が宣言的に書けてスゴイなとおもいます。この自動感を追い求めてDBのトリガーとかに解決策を見出してしまうと筋悪臭がすごいので素直に手で書きます。