RailsGuidesにちゃんと書いてありますが、ちょっとハマりました。

こういうのはダメ。

Rails.application.routes.draw do
  constraints subdomain: :api do
    scope module: :api do
      namespace :v1, format: :json do
        resources :posts
      end
    end
  end
end

ちゃんと文字列にする。

Rails.application.routes.draw do
  constraints subdomain: 'api' do
    scope module: 'api' do
      namespace 'v1', format: 'json' do
        resources :posts
      end
    end
  end
end

3.9 リクエスト内容に応じて制限を加える

リクエストベースの制限は、Requestオブジェクトに対してあるメソッドを呼び出すことで実行されます。メソッド呼び出し時にハッシュキーと同じ名前をメソッドに渡し、返された値をハッシュ値と比較します。従って、制限された値は、対応するRequestオブジェクトメソッドが返す型と一致する必要があります。たとえば、constraints: { subdomain: 'api' }という制限はapiサブドメインに期待どおりマッチしますが、constraints: { subdomain: :api }のようにシンボルを使用した場合はapiサブドメインに一致しません。request.subdomainが返す'api'は文字列型であるためです。

ドメインやPATHなど、文字列っぽいものは文字列で指定すべきと考えておけば良さそうです。

Nexus PlayerからApple TVに乗り換えました。

理由は最近iPhoneに乗り換えてすこぶる快適なので合わせたかったのと、Nexus PlayerのGoogle MusicアプリはGoogle Musicの音楽聴き放題に入っていてもその機能が使えないのに対して、Apple TVならばApple Musicの聴き放題をそのまま使えるからです。

結果、対して変わらないっすね。主な用途がHulu、Netflix、Youtubeなのでどっちでも変わらんです。どちらもアプリ少ないし。(現時点ではAndroid TVの方が多い)

唯一気になったのは、僕は時々Google Play Storeで映画を借りていたんですが、Google Play Storeの映画のプレビューってのは本当のプレビューで、最初の数分をそのまま見れる形になっています。

これ、海外ドラマじゃなく映画なので最初5分なんてスゲー退屈なんですよね。インターステラーをみたいと思ったんですが、最初の5分見せられてもさっぱりでした。

それに対してiTune Storeはプレビューがそれ用の予告編ムービーになっています。予告編ムービーは「おもしろいぞー」って感じでこれでもかと煽ってくるので非常にみたくなります。インターステラーはなかったけど、ゼロ・グラビティの予告編みたら、これ見てぇ!ってなりました。

最初の5分プレビューは無いほうがいいですね。

Nexus Playerのゲームパッドは誰も使ってない可能性が巨レ存・・・? - komagataのブログ

何の話かというと、

  • Aの学習にはBの学習が必須
  • Bの学習はAの経験がないとまったくピンとこない

という問題があって困るってことです。

まあ学校の数学の授業みたいにとにかくBは黙って覚えろ話はそれからだスタイルで行けばいいんですけど、僕自身がそういう学習辛かったなーと思うので何とかしたい。

具体的に弊社のインターンシップのカリキュラムで言うと、

  • railsアプリ作成の学習(has_many :throughtを使うところ)にはRDB設計の学習(正規化や多対多の関連)が必須。
  • RDB設計の学習アプリ作成の経験ないとまったくピンとこない

という問題が起きております。

まずrailsで簡単なhas_many :throughtを使わないアプリ作成を経験し、その後RDB設計の学習をして、戻ってきてhas_many :throught有りのアプリ作成をするというのがいいのかなぁ。

カリキュラムの順番的に行ったり来たりするのは嫌だなぁ。

Kindle Voyage買った。

結果、Paperwhiteの新しいやつでよかったなと思います…。

初代のPaperwhite持ってますが、確かにDPIと速度上がってるんだけど思ったほどではなかった。

ただ、Kindle自体は相変わらず良い。

この意味で(複数でない・一つのもの)シンプルだなーと思ったもの。

偽のシンプル、正しいシンプル - komagataのブログ

芯なしロールのトイレットペーパー

https://gyazo.com/f69ca2f3cb9bcfcd08cf7668fa02d65d

芯とペーパーだったのがペーパーだけになってる。

強度の問題とかで多分芯ありの方がeasyなんだろうけど頑張ってシンプルにしてる。すごい。

iPhoneのTouch ID

https://gyazo.com/0e46f8508f6eab3e16994e2cb52462cc

電源を付ける、認証するの2アクション必要だったのがホームボタンを押す1アクションで両方いけるようになってる。

Nexus6では右のボタンで電源オン、その後ジェスチャー入力だったのが左手だけ1アクションでいけるようになった。

多分ホームボタンと指紋認証は別パーツの方がeasyなんだろうけど頑張ってシンプルにしてる。すごい。

Review.appでの無限ステージング環境をクッソwww快適に使わせて頂いてるんですが、メール内のhost名設定で困ってたら @t-kawa さん、@chiastolite さんが教えてくれました。

あざーす!

% heroku config:get HEROKU_APP_NAME -a kulku-pr-173
kulku-pr-173

取れるじゃな〜い。

staging環境用にconfig/environments/staging.rbをこんな感じにしてみました。

require File.join(__dir__, 'production')

Rails.application.configure do
  config.action_mailer.default_url_options = { host: "#{ENV['HEROKU_APP_NAME']}.herokuapp.com" }
end

これで無限ステージング環境でメールもばっちり。

Rebuild.fmでしって@jishihaさんもやってみたら良かったと聞いたのでReact.js Introduction For People Who Know Just Enough jQuery To Get By · React for Designersをやってみた。

やっぱりサーバーサイドみたいに何も考えずrenderできるのはいいですね。この機能は欲しいんだけどrailsと馴染む感じの連携方法がわからん・・・。

ここ2年ぐらいJSの進化についていくのをずっとさぼってて、最近の半年でその流れを順番に入門していって追体験してる感じです。(今やっとReact.jsに入門の地点)

やっぱり実際に触ってみないとわからない部分多かったなーと思いました。

理想:2-wayバインディングが便利だろう。

現実:あんまりうれしくない。Model -> Viewの1-wayだけでいいよ。

とか、

理想:Web componentが未来。

現実:Polymerクッソ使い辛い。

とか、

理想:componentに分ければ複雑なアプリも解決。

現実:component間連携が死ぬ。

とか、

理想:サーバー側はREST APIだけあればいい。

現実:クライアント側はそんな単純じゃない。パフォーマンスが死ぬ。

とか。

全部に時間を使うことはできないので取捨選択は必要ですが、この、使わないと勘所をかなり外してしまう感は肝に銘じていきたい。

仕事で使うのでMarionett.jsを公式にあったスクリーンキャストで入門しました。JS Frameworkは案件毎に1個づつ入門してるので使えるFrameworkが増えてきましたな。

  • Angular 1.x
  • KnockoutJS
  • Polymer 1.x
  • Backbone.js
  • Vue.js
  • Marionette.js [new!]

Marionette Fundamentals | Pluralsight

Free Trial 10 daysのうちに見てしまおう。

アプリを作りながら説明してるんですが普通にバグを出したり、直って喜んだりするのがリアルで面白い。

JSなので本題には影響ないですが、サーバー側(API)がC#でWindowsなのが新鮮でした。

あるGithubのPRスレッドにて。

AAA merged.

komagata said:

@AAA レビュー無しのマージはまずいとおもいますー

AAA said:

@komagata ある程度、初めの形ができあがるまではレビュー無しで行きます。
そうしないと全く前に進まないので。

ある程度の二度手間が発生するのは承知してます。
一番最初から全員が完全に合意してい、100%ものを作成するのは不可能だと思います。
時間がかかり過ぎます。
話し合いでだけで延々と時間が過ぎていき、全員の考えが合致することは永遠にないと思います。

リファクタリングフェーズに入りましたら、レビューしながらソース改善していく予定です。

komagata said:

@AAA レビュー無しで行くというのはチームの皆さん合意の上の話ですか?

全員の合意は要らないですが、作った人以外の誰かが最低レビューするというのは一般的なやり方だと思いましたので。

CC @BBB

AAA said:

@komagaga 現在、チームは私とCCCさんの二人ですが、
CCCさんの了解はとっています。

今は進めて形にするのを優先したいです。

https://gyazo.com/cba99bde225ddc988300ba5bcc982f60

たざわ「あ〜!
コードレビューの火がきえた〜!!」

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

組織論でもプログラムでもデザインでも「シンプルにしよう」とよく言いますが意味がフワッとしてるので自分的まとめを。

Rich Hickeyのシンプルの定義

シンプルさの必要性 | eed3si9n

上記の俺的まとめ。

  • simpleの対義語はcomplex。
  • simpleを語源・対義語から考えると、多数のものを組み合わせてない・一つのものという意味になる。
  • それに対してeasyを語源から考えると、近くのものという意味になる。
  • complexこそが悪。
  • easyだけどcomplexなもの = 甘え
  • hardだけどsimpleなものを恐れない。simpleなものはしばしばeasyでない。

命名

上記を使いやすくするために、easyでcomplexなもののことを偽のシンプルhardでsimpleなもののことを正しいシンプルと名付ける。

simpleでeazyが最良でcomplexでhardが最悪だが、自明なので命名する必要はないと思う。

普段の仕事で注意すること

  • えてして偽のシンプルに陥りがちである。正しいシンプルを恐れない。
  • 「シンプルにAで行きましょう。」
    その「シンプル」はsimpleか?easyか?
  • 「そのツールは学習コストが高いので辞めましょう。」
    それは偽のシンプルでは?
  • 「それは複雑だから辞めましょう。」
    その「複雑」はcomplexか?hardでは?