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では?

TL;DR

キーボード・マウス・ヘッドフォンなどのゲーミングPC環境を整えました。ゲーミングPC + Steam最高。

最高のゲーム環境はWindows PC

とても高いですが、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本体はどうしたのか

PC本体の性能をあげようとするとくっそ高いので今回は周辺機器だけ買いました。それでもGeForce GTX 960単体より安いんですよね。RPGなどでは今のPCでもちょっとカクつくぐらいで十分楽しめました。

Fallout4が超必要性能高いって言われてるのはFull HD以上 + 60FPS前提の話みたいです。僕はグラフィックの違いとかFPSの差が底まで気にならないのでRPGが動かないぐらいになったころに買い換えたいと思います。

最近、表題のフレーズが頭を巡っております。

僕は最近どこにいってもそんな仕事ばかりしてる気がします。railsでできたシステムは沢山あり、技術的負債の返済は誰かがやらなければならないと思います。

しかし僕の本当の気持ちは、

「既に動いてるrailsアプリをnormalizeするより、汚くてもいいから新しい動くものを作ってケツは他人に拭かせたい。」

テキストにしてみたら思ったよりゲスなフレーズになりました・・・。

RailsでDBのデータ変更はどこに書く? - komagataのブログ

ブクマ・閲覧が多いようなので僕の結論書いときます。

  • データ変更はrakeのタスクとして書く。
  • migrationには書かない。
  • 初期データはseedに書く。

例えば、運営側しか触らないCategoryが増えたとしたら、seedに追記し、rakeタスクとしてcategory追加するタスクを書き、デプロイ時に実行します。このrakeタスクは一回実行するだけなのでしばらく立ったらリポジトリからも消しちゃいますね。

DBの状態が秘伝のタレ化しないようにseed整備は大事。

実データ(ほとんど本番と同じ)で開発すべきというのは別の話題。

railsらしいやり方、turbolinksともマッチするjavascriptの書き方ができるturboctrlというgemをリリースしました。

komagata/turboctrl

これは何?

/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 @Foo

sprocketsを使う以上、上記のようなクラスの書き方しますよってとこも共通認識にしたい。

ご意見、ご要望、Issue、PR歓迎です。

KRAY@amachinさんにこう言われたので書きます。

実ペアプロ時間1年未満の僕がコツなんて言うのはおこがましいですが、ペアプロオンリーでやっているMediweb社さんのやり方の受け売りです。

1台のPCを共有しない

ペアプログラミングは1台のPCを使って交代しながらやるものですが、エディタの違いとか環境の違いをあわせるのはクッソストレスが溜まるのでやりません。EmacserとVimmerは一生わかりあえません。

かわりにラップトップを持ち寄って1台の外部ディスプレイを交代でつなぎます。(Thunderbolt Displayは電源も一緒になってておすすめです)

ペアの交代時にはWIPでpushしときます。

別プロジェクトの人とペアを作らない

別のプロジェクト同士でやってもあまり興味が持てないので初心者にはおすすめできない。まずは同一プロジェクトの人同士でやる。

ドライバーを長時間やらない

一定時間で交代する。1時間がおすすめ。タスク毎交代だと他人事になりやすい。

残業しない

ペアプロは疲れます。残業はもってのほか。はじめは休憩を多めにとって6時間を目標にやるとよい。

昼を食べ過ぎない

ナビゲーターが眠くなってしまう。

毎日ペアを変えない

前日仕掛中のタスクが気になるようだったら同じペアで続行してすっきりさせてもよい。

プログラミングに限らない

インフラやタスク整理もペアでやってよい。

まとめ

TDDが「テストファーストじゃなくてもテストは書く」というのが当たり前になったように、ペアプログラミングもコモディティ化してきたのでエクストリームじゃないやり方に一般化してくのは自然なんじゃないかと思います。

本来のエクストリームプログラミングのプラクティスとしてのペアプログラミングに対してペアプロって感じで気張らず当たり前のこととしてやっていきたい。

今年前半はMediWebさんにいって製品コードは全てペアプロで書くという環境でやっていました。

ペアプロは疲れるけれど、コツが分かってくると、うまいやり方をすればとても有用だと知りました。

今年後半はAQさんとリモートオンリーで仕事をしました。

リモートの快適さに酔いしれました。

今やっているプロジェクトではペアプロやったりリモートで画面共有したりしてます。

ペアプロはプロジェクトリーダーにこそ有用

メンバーとしての利点はいろいろ語られていますが、自分がリーダーのプロジェクトで感じたのがプロジェクトを把握するのにペアプロはとてつもなく手っ取り早いということです。

リモートワークのリーダーにとっての不安ってプロジェクトやメンバーの把握が難しい点だと思いますが、リモートペアプロならカバーできるように思います。

リモートペアプロオンリーチーム

開発の全てをリモートペアプロオンリーでやるチームを作ったらどうかなと思いました。小さい会社やフリーランスでチームを組んで、僕らはリモートペアプロオンリーでやりますよとうたう。