この意味で（複数でない・一つのもの）シンプルだなーと思ったもの。
芯とペーパーだったのがペーパーだけになってる。
強度の問題とかで多分芯ありの方がeasyなんだろうけど頑張ってシンプルにしてる。すごい。
電源を付ける、認証するの２アクション必要だったのがホームボタンを押す１アクションで両方いけるようになってる。
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が増えてきましたな。
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さんの了解はとっています。
今は進めて形にするのを優先したいです。
たざわ「あ〜！
コードレビューの火がきえた〜！！」
組織論でもプログラムでもデザインでも「シンプルにしよう」とよく言いますが意味がフワッとしてるので自分的まとめを。
上記の俺的まとめ。
上記を使いやすくするために、easyでcomplexなもののことを偽のシンプル、hardでsimpleなもののことを正しいシンプルと名付ける。
simpleでeazyが最良でcomplexでhardが最悪だが、自明なので命名する必要はないと思う。
キーボード・マウス・ヘッドフォンなどのゲーミングPC環境を整えました。ゲーミングPC + Steam最高。
とても高いですが、Windows PC + Steamの組み合わせが最高。はっきり分かんだね。Fallout4でもやはり重量制限撤廃MODみたいなのは便利なんですよねー。僕のやるゲームがNexus Mod Manager対応ゲームばかりなのがでかい。（Witcher2、Skyrim両方未クリア）
SteelSeries SENSEI [RAW]
FPSはシングルプレイしかやらないので性能は必要ないんですが、すごく握りやすいです。ホイールの下についてるボタンでハイセンシとローセンシの感度を切り替えられるのがゲーミングマウスっぽい。けど僕には必要ないですな。
SteelSeries QcK マウスパッド 63004
同じくSteelSeriesのマウスパッド。布っぽい質感でとってもいい感じですが、これは大きすぎました。miniの方にすればよかった。
LOGICOOL ゲーミングキーボード G105
今まではBluetoothの小さいUS配列キーボードだったので適当なメンブレンのキーボードを買いました。メカニカルだとうるさいのでただでさえ肩身の狭いゲームプレイがさらに嫌がられそうです。
キングストン HyperX Cloud Core
指向性マイクをもったヘッドセットを探していました。コスパの高いゲーミングヘッドセットとして売っていました。僕は頭でかいので世間で評判良くても全く合わないヘッドフォンとかありますが、お試しした感じも密閉感が高くて良かったです。肝心のマイクの方もマイク機能がおまけのようについてる別のヘッドセットに比べたらクリアで全く違いました。
Macでは二股を使ってマイクとイヤホンにつなぐのではなく、二股を使わずイヤホンの方に刺さないとマイクが使えないのが注意です。
Xbox 360 Controller for Windows
いわゆる箱コン。Steamゲーはこれ一択。はっきりわかんだね。Fallout4も二周目はこれでやり始めましたがプレイ感が違うので楽しいです。キーボード + マウスだと長時間のRPGは疲れますが、コントローラーだと楽ですね。つないだだけでコントローラー操作になったりと、標準コントローラー感が心強いです。
PC本体の性能をあげようとするとくっそ高いので今回は周辺機器だけ買いました。それでもGeForce GTX 960単体より安いんですよね。RPGなどでは今のPCでもちょっとカクつくぐらいで十分楽しめました。
Fallout4が超必要性能高いって言われてるのはFull HD以上 + 60FPS前提の話みたいです。僕はグラフィックの違いとかFPSの差が底まで気にならないのでRPGが動かないぐらいになったころに買い換えたいと思います。
最近、表題のフレーズが頭を巡っております。
僕は最近どこにいってもそんな仕事ばかりしてる気がします。railsでできたシステムは沢山あり、技術的負債の返済は誰かがやらなければならないと思います。
しかし僕の本当の気持ちは、
「既に動いてるrailsアプリをnormalizeするより、汚くてもいいから新しい動くものを作ってケツは他人に拭かせたい。」
テキストにしてみたら思ったよりゲスなフレーズになりました・・・。
RailsでDBのデータ変更はどこに書く？ - komagataのブログ
ブクマ・閲覧が多いようなので僕の結論書いときます。
例えば、運営側しか触らないCategoryが増えたとしたら、seedに追記し、rakeタスクとしてcategory追加するタスクを書き、デプロイ時に実行します。このrakeタスクは一回実行するだけなのでしばらく立ったらリポジトリからも消しちゃいますね。
DBの状態が秘伝のタレ化しないようにseed整備は大事。
実データ（ほとんど本番と同じ）で開発すべきというのは別の話題。
railsらしいやり方、turbolinksともマッチするjavascriptの書き方ができるturboctrlというgemをリリースしました。
/posts/1にアクセスしたらapp/assets/javascripts/controllers/posts_controller.js.coffeeにあるPostsControllerクラスのshowメソッドが呼ばれるというものです。
# app/assets/javascripts/controllers/posts_controller.js.coffee:
class @PostsController
show: ->
console.log "Hey!"
「さっさとwebアプリを書きたい。」
「RailsのRailから外れる面倒なことはしたくない。」
「Railsはjsの書き方についてRailがなさすぎる。」
「Railsっぽいままjsを書きたい」
「Sprockets捨てるとかではなく、既存の仕組みのまま行きたい」
というのがモチベーションです。
「coffeeの1ファイルに1クラスだけ書く」というルールすら共有されてないと行くプロジェクト行くプロジェクトで辛いんですよね。
class @Foosprocketsを使う以上、上記のようなクラスの書き方しますよってとこも共通認識にしたい。
ご意見、ご要望、Issue、PR歓迎です。