プログラマという現代の傭兵 - mizchi's blog
エンジニアの転職とかプログラミング教育周りで考えていたこと。 フランス革命と技術のコモディティ化 最近フランス革命やナポレオン戦争やナショナリズム、そしてクラウゼヴィッツの戦争論などを調べたりしていたんだけど、傭兵や専門技術の扱いについて、示唆的なものが多かった。 当時の傭兵は、扱いが難しかった大砲・銃火器を扱う専門集団で、技能職でもあった。それが 18 世紀になり火器の改良が進み、産業革命で効率的な生産が可能になり、そしてナポレオンによる国民軍の創設、そのヨーロッパにおける戦果によって、傭兵はその役割を終えた。 「傭兵はすぐ逃げる」というのが定説だが、彼らは金で動く専門職なので、負ける側に付く理由がないので、当然とも言える…特に戦争という、敗者の支払いが期待できない場では。そして彼らを雇う王侯貴族の経済力が、そのまま軍団の動員力に直結した。常備軍を持たない分、平時のコストも安くついた。
二世の呪い - mizchi's blog
僕はエンジニアで、このブログで書くことは、そういうテーマを期待されていることを知っている。それ以外はノイズだから、あんまりやらないでほしい、とも。 でもこれは自分のアイデンティティの根幹に関わることで、そういう前提で、一部で話題になってたこの動画を見た。幸福の科学の大川総裁の息子の、幸福の科学との断絶宣言。 www.youtube.com happy-science.jp エンタメの文脈でそれはどうなんだと思うところはあれど、内容自体は非常に思うところがあった。 8歳ぐらいまで、家の宗教に疑問を持つことはなかった。幼稚園までは、人に隠れて食前の祈りを捧げていたと思う。それが褒められると知っていたから。 ティーンエージャーの頃、自分は怒りに支配されていた。自分の家の異常さを客観視できるようになり、その異常さを許せなくなった。自派以外を否定する排他的な教義、一時期採用された一夫多妻、そしてその
手足がもがれる感覚 - mizchi's blog
最近乗り換えたもの Twitter: 夜フクロウ => Tweetdeck ブラウザ: Firefox(Vimperator) => Vivaldi RSSリーダー: Livedoor Reader => Inoreader ただ、これらにかなり不満がある。 情報には上流がある。情報の上流は、一次情報が乱雑に転がってる未整備の荒野みたいなもので、下流はその二次情報やまとめみたいなもの。キャズム理論でいうと、一次情報に接する人がイノベーター、イノベーターを観測する人がアーリーアダプター、イノベーターまたはアーリーアダプターによる編集物を閲覧する人がマジョリティという分類になると思う。 自分が思う近年のインターネットの問題は、一次情報を整理していたイノベーターやアーリーアダプターに対するサービスが本格的に終わってきたこと。 最初に挙げた3つのサービスは、どれもサービス終了やサポート終了などの必
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
ブログを書き続けること - mizchi's blog
昔から気をつけてることなのだけど、ある程度、ブログ、とくに技術テーマ以外の記事を書く頻度はコントロールしよう、と思っていた。具体的には、1ヶ月の間に2, 3回ホッテントリなどに入ることは問題ないが、2, 3ヶ月連続で耳目を引き続けるのは、避けた方がいいのではないか。とくに落ち着いて暮らしたいなら。 中長期的にあまりに注目を引き過ぎると、勝手に記事間の文脈を悪意を持って補完されたり、固定のウォッチ対象にされてしまったりすることがある。粘着なアンチは聞く耳を持たないので無視するに限るが、人間何に反感を持つかわからないもので、自分がコントロール出来ない要素をたくさん抱えると、書くことそのものが億劫になっていく。日常生活にも影響が出る。少なくとも僕は、自分が書いたものが自分のコントロール下から外れていないか、怖くなってエゴサーチばっかりしてしまう。 「悪意を持ったコメント」に対抗する方法は難しく、
あなたがReactを使うべき理由 - mizchi's blog
最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
Web系エンジニア1年半ですが、このたびは転職する運びとなりまして、各位に連絡させていただきます - mizchi's blog
みんなが好きな転職エントリです。 mizchiくんのフォロー/フォロワー傾向を見張っているが、そんな古典的な手段が通じるかとばかりにガードされている— mala (@bulkneets) 2013, 9月 5 8月で株式会社Aimingを退職し、9月からQuipperに転職しました。 Quipper Quipperは端的に言うと教育ベンチャーです。自分で紹介するのもアレなのでググってください。ロンドン30人、日本20人ぐらいの会社です。 ちょうどいいのでブログも http://d.hatena.ne.jp/mizchi/ からはてなブログへ引っ越しますね。 転職理由 前職で色々としがらみを感じるようになって不満を感じていたところ、自分が気になっていたエンジニアが続々とQuipperに入社しているのを観測していて、気になっていました。 で、@kyanny こと刺し身ブーメランさんに連絡をとっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
