komagataのブログ

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

下記のように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 さんに相談した所、ユナイテッド・デザインワークス株式会社を紹介していただき、ストロボリンガーというハードを取り付けてもらいました。

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

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

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

結果

こうなりました。

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

感想

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

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

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

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

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

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

直近のお仕事

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

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

探したいお仕事

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

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

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

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

得意な仕事

• railsアプリをnormalizeするお仕事 - komagataのブログ
• 開発チームを作る仕事（求人含む）
• アジャイルな開発フローを導入する仕事（タスク管理や振り返りMTGなどを根付かせる）
• レガシーコードを粘り強く改善する

やりたい仕事

• 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時間前だろうが既につないでおくことです。

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のトリガーとかに解決策を見出してしまうと筋悪臭がすごいので素直に手で書きます。

NSLayoutConstraintのAPIがあまりにも辛いので調べてみるとAutoLayoutを簡単に記述できるライブラリがいくつかあるらしい。

しかしSwiftのライブラリマネージャーはどれがいいんだろう？CocoaPods、Carthage、Swift Package Managerなどがあるらしい。どれがおしゃれなんだろうか。

怖話のiOSアプリをSwift化しようと思ってiOSに再度入門してます。

ヘッダファイルがないだけでも気持ちいいですね。どうせプロジェクトファイルを作りなおすのだからUIWebViewからWKWebViewに移行しようと思っています。ただ、WKWebViewはstoryboardから使えないらしい😢

iOS7からStatusBarやNavigationBarの構造が変わったらしく、デフォルトのViewはStatusBarなどの下に潜り込む形になっていてそのままWKWebViewを追加すると重なってします。

参考：iOS 7の全画面対応 その1 | Cyber Passion for iOS

ViewController.swift:

import UIKit
import WebKit

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()

        let webView: WKWebView = WKWebView(frame: view.bounds)
        view.addSubview(webView)
        let url = NSURL(string: "http://kowabana.jp")!
        let request = NSURLRequest(URL: url)
        webView.loadRequest(request)
    }
}

沢山のデバイスサイズがあるこのご時世、AutoLayoutというやつに入門するしかないと調べてみましたがNSLayoutConstraintのクッソ（笑）ややこしいAPIが憎い。