アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ

リーダブルコードから学べるのは嘘メソッド名と嘘コメントが最大の罪ってことだよ— 片手間以上 (@mizchi) 2014, 7月 5 コードコンプリート、個人的にそんな有益な話はなかったという記憶なんだけど単に趣味のドメインが違うだけかもしれない可能性はある— 片手間以上 (@mizchi) 2014, 7月 5 コードコンプリート、作者が一生懸命になってる主張の部分が全然共感できないのがあった— 片手間以上 (@mizchi) 2014, 7月 5 僕はGoFはむしろ初心者に絶対に読ませてはいけない本だと認識していて、グローバル変数をファサードとか言い出したり、これはシングルトンなんです！と言い出す— 片手間以上 (@mizchi) 2014, 7月 5 本読んでコード書けるようになるとか幻想だと思ってるので、基礎文法覚えたあたりでコードコンプリート読んで、その後はいろんなパラダイムのフ

これまで Web 開発の現場で経験してきたあるあるを継続的デリバリー片手に振り返ってみます。また最近どういったツールを現場で活用しているかについてもご紹介します。 ※ どんな主旨で作ったスライドかはてなブログに書きました。 http://beniyama.hatenablog.jp/entry/2014/06/18/011411

機械学習の問題 については以前に紹介したので、次はどんなデータを収集し、どんな機械学習アルゴリズムを使うことができるのかを見ていきましょう。本投稿では、現在よく使用されている代表的なアルゴリズムを紹介します。代表的なアルゴリズムを知ることで、どんな技法が使えるかという全体的なイメージもきっとつかめてくるはずですよ。 アルゴリズムには多くの種類があります。難しいのは、技法にも分類があり拡張性があるため、規範的なアルゴリズムを構成するものが何なのか判別するのが難しいということですね。ここでは、実際の現場でも目にする機会の多いアルゴリズムを例にとって、それらを検討して分類する2つの方法をご紹介したいと思います。 まず1つ目は、学習のスタイルによってアルゴリズムを分ける方法。そして2つ目は、形態や機能の類似性によって（例えば似た動物をまとめるように）分ける方法です。どちらのアプローチも非常に実用的

三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン２：エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数（

はじめに 今となっては、プログラマにとってなんとなく理解して利用できることが当たり前になりつつあるオブジェクト指向ですが、しかし、それこそ今から数年前には、この「オブジェクト指向」というのは、いわばおじさん達が変な方針を打ち出したりして「え、それ変な実装方針じゃねえの」というツッコミが入ったりしていました(ちなみにそのあたりの雰囲気については、この記事を読むと分かりやすいでしょう)。 もちろん、これはこれなりにメリットがあるのかもしれませんが、しかしそれはまた別のオブジェクト指向を利用したモデリングと比較してのことであって、「これだけでいい」と考える人はいないでしょう。 原則: だってそのほうが開発しやすいから まず最初に原則を考える必要があります。まずひとつに、必ずしもオブジェクト指向が正しいモデリングの方法ではないこと。少なくとも自分が思うに、オブジェクト指向を使うべき理由というのは、

リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ

Web の会社でエンジニアを始めて 4 年、ずっと運用エンジニアをやってました。運用とは端的に言うと、社内外の他人が作ったソフトウェアを期待通りに動作させるためのエンジニアリングだと思ってます。アプリケーションはもちろん開発者が作ったものですし、MySQL や Apache や Linux も全部他人が作り上げたソフトウェアであり、それらの設定を変更したりパッチを当てたり運用ツールを駆使することで、協調動作させることに磨きをかけてきました。 ただ、いつまでたっても他人の作ったものの面倒を見てることには変わりないし、運用ツールを開発したところでそれはあくまで誰かが生み出す価値のサポートにすぎないのが自分的には満足できなくて、ずっとアプリケーション(ビジネスロジック)が作りたいと思ってました。 で、今年の始めからたまたまタイミングよく新規開発の部署に入ることになって、いきなり開発者をやることに

はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識が本になりました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない！vs. 現場に任せてくれない！の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマ

Yak Shaving の誘惑に打ち克つ ソフトウェアを作っている途中で、「これを作るのを効率化するためには ○○ が必要だ」と思い、本来やっていた作業の手を止めて ○○ を作り始めてしまうことは往々にしてある。 しかしその作り上げた ○○ が最終的に本当に（長期的にみて）効率化に役立ったケースは、自分の経験からいって 10 個のうち 1 つくらいではないかと思う。 効率化のための努力をするなということではない。大事なのは、アイデアを寝かせることだ。 人はゴミみたいなアイデアでも、気付かずにこれこそが素晴らしいアイデアだと信じこんでしまう。自分の考えたアイデアには愛着が湧くものだ。 そのアイデアが本当に優れているかどうか客観的に判断するには時間が必要だ。最低でも 1 晩、できればもう 2, 3 度は同じ必要性を感じてから作るのがいい。 1 回しか必要性を感じたことのないものをその場の勢いで

【Unity道場スペシャル 2017大阪】Post processing stackでワンランク上のビジュアル表現＋時間をかけずに武器になるツー...

Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計

数年前から身内で時々集まって開発合宿をしていて、成功失敗あわせて知見が貯まってきたので備忘録として記事にしておきます。 なお、ここで開発合宿と言っているのは1,2部屋に1泊して済ませるような規模のもので、ホワイトボードでブレストしまくりといったものではなくて淡々とみんなでパソコンするみたいなものを想定しています。 宿選び あえてオススメの宿リストみたいなのは書きません。なぜなら開発合宿向けの宿まとめみたいな記事を真に受けて失敗したことがあるので、そのようなリソースをインターネットに増やしたくない。 開発合宿で有名な某旅館は、割安ではあるが無線LANが弱すぎ、温泉はぬるすぎ、メシもいまいちという品質なのに、開発合宿に選ばれがちである。○○旅館に行ってきましたという開発合宿レポートをみんながブログに書くから検索にヒットしてみんなそこに行くみたいになってて、負の連鎖が起こってる。 無線LANより

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを

引き続きプログラミングの基礎体力づくりと、Pythonの勉強を兼ねてアルゴリズムを勉強中です。今回は『共通部分文字列をカウントする方法』について勉強しました。AIZU Online Judgeで対応している問題は、『Common Sub-String』です。アルゴリズムというよりは頭の体操的なパズル問題ですが、ある程度速度の早いプログラムを書くのには工夫が必要だなと痛感しています。 🏈 AOJ問題Common Sub-String Aizu Online Judge。2個の文字列が与えられたとき、 両方の文字列に含まれる文字列のうちもっとも長いものを探し、 その長さを答えるプログラム。 🍄 Rubyコードloop do s, t = gets.chomp, gets.chomp rescue break s, t = t, s if s.length > t.length max_l

読んだ理由 最近、ソフトウェアの設計力が不足していると感じる。もっといい感じにクラスを設計して、オブジェクト指向ぽいプログラムを書けるようになりたい。しかもスピード感を持ってやりたい。ということで、いまさらだけど、オブジェクト指向についてもう一度学んでみようと思った。本を読めばいいという訳じゃないけど、とりあえずもっと知識を増やしたい。渋谷の東急百貨店 7F の丸善＆ジュンク堂書店に行って、 オブジェクトデザイン (Object Oriented SELECTION) エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) の3冊で悩んだ結果、これを買った。決める要因となったのは、 ついでにデザインパターンについて理解を深められたらいいなと思った これまで