ということで話早えぇ@sotarokさんにApple Watch売ってもらいました。
新しいバンドも届きました。
本当はスキューバブルーのバンドを買ったんだけど間違えて42mmの方を買ってしまったので@machida さんにプレゼントということにして買い直しました…。やっちゃったな…。
今のところやはり時計が一番のキラーアプリなのでAndroid Wareと変わりませんな。
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リクエストベースの制限は、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分プレビューは無いほうがいいですね。
何の話かというと、
- 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自体は相変わらず良い。
この意味で（複数でない・一つのもの）シンプルだなーと思ったもの。
芯なしロールのトイレットペーパー
芯とペーパーだったのがペーパーだけになってる。
強度の問題とかで多分芯ありの方がeasyなんだろうけど頑張ってシンプルにしてる。すごい。
iPhoneのTouch ID
電源を付ける、認証するの２アクション必要だったのがホームボタンを押す１アクションで両方いけるようになってる。
Nexus6では右のボタンで電源オン、その後ジェスチャー入力だったのが左手だけ１アクションでいけるようになった。
多分ホームボタンと指紋認証は別パーツの方がeasyなんだろうけど頑張ってシンプルにしてる。すごい。
Review.appでの無限ステージング環境をクッソｗｗｗ快適に使わせて頂いてるんですが、メール内のhost名設定で困ってたら @t-kawa さん、@chiastolite さんが教えてくれました。
@komagata 使ったことないですが、これでしょうか https://t.co/MuFi5GPo0B
— Toru KAWAMURA (@tkawa) 2016, 2月 22
@tkawa @komagata 自分、それを使ってHeroku Review Appsで使うS3のエンドポイント変えたりしているので行けると思います
— 出禁 (@chiastolite) 2016, 2月 22
あざーす！
% 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と馴染む感じの連携方法がわからん・・・。
ここ２年ぐらい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 ある程度、初めの形ができあがるまではレビュー無しで行きます。
そうしないと全く前に進まないので。
ある程度の二度手間が発生するのは承知してます。
一番最初から全員が完全に合意してい、１００％ものを作成するのは不可能だと思います。
時間がかかり過ぎます。
話し合いでだけで延々と時間が過ぎていき、全員の考えが合致することは永遠にないと思います。
リファクタリングフェーズに入りましたら、レビューしながらソース改善していく予定です。
komagata said:
@AAA レビュー無しで行くというのはチームの皆さん合意の上の話ですか？
全員の合意は要らないですが、作った人以外の誰かが最低レビューするというのは一般的なやり方だと思いましたので。
CC @BBB
AAA said:
@komagaga 現在、チームは私とCCCさんの二人ですが、
CCCさんの了解はとっています。
今は進めて形にするのを優先したいです。
たざわ「あ〜！
コードレビューの火がきえた〜！！」