この記事のオリジナルは voxxed に投稿されたものです。 JavaScript関連の問題を抱えるチームをサポートする仕事を通じて、いくつか共通の問題点があることに気づきました。もしあなたもJavaScriptに対するイライラを感じているのであれば、この記事は何らかの助けになるかもしれません。おことわり：私がお教えするヒントはすでにご存知のものもあるとは思いますが、うまくいけば、多少なりとも有用な情報があるかもしれません。特にエンタープライズアプリケーションやCMSソリューションを構築する際に有効なヒントです。チームの誰もが話したがらないCMSのコードについてお話しします。いずれも必要に応じて採用できるものです。 debuggerステートメント 大半のブラウザでサポートされているにもかかわらず、JavaScriptを書く際に最も活用しきれていない機能の1つです。debuggerステートメ

あなたは、これからキャリアを切り拓こうとしている素晴らしいエンジニアたちを抱えています。チームは優れた成果を出して成長し続けているので、何らかの具体的な方法で賞賛したいと考えています。すぐに思いつくことは、特にエンジニアたちがそのチーム内ですでに事実上リーダーの役割を果たしている場合には、彼らにチーム内での役職を与えて昇進させることでしょう。でもその報酬は、本当にエンジニアたちが望んでいるものでしょうか？　もしかしたら彼ら自身も、昇進は望むべきもの、と思い込んでいるだけではないでしょうか？ 人材マネジメント力は別のスキル エンジニアの世界では、エンジニアたちが技術面ではピークに達した後に、これまで習得したものとは全く別の、社交面だとかソフト面におけるスキルを学ぶよう求められることがよくあります。これらは、エンジニアたちが過去のキャリアではほとんど気にしていなかったものです。このようなスキル

先週、 Hacker News上で興味深い議論が行われました 。テーマは Linux Kernelのコーディングスタイル についてです。 議論の中で私は、 コーディングで垂直方向にそろえるインデントをとるべきか というささやかな聖戦を仕掛けました。私は全面的に賛成です。理由を説明しましょう。 垂直方向にそろえるインデントをとるとは？ 簡単な例を挙げてみます。 int robert_age = 32; int annalouise_age = 25; int bob_age = 250; int dorothy_age = 56; ちょっと見ただけで、「bob_age」がおかしいと分かるでしょう。また、目視であちこち探さなくても、全ての値が整数であることが簡単に確認できます。 この考え方は 一般的に 共有 されているわけではありません。ですので、なぜ 多くの 人たち がこれを有効なスタイルガ

これは Defrag 2014 の講演内容です。 テクノロジに長く従事することの（数少ない）利点の1つは、いくつもの技術サイクルの始めから終わりまでを見ることができるということです。いかにしてブレークスルーが実際に広まるかを見られるのです。サイクルの曲線の一部分しか見なければ、全体を正確に測り知るのは難しいでしょう。短期間で起きた進歩を見過ごしてしまうか、長期間で起こる進歩を見届けられないかのどちらかです。驚くべきことは世の中の事象がいかに速く変化するかではなく、その変化に呼応するエンジニアリングの変革がいかに遅いかということです。画像は、1891年に発明された、電話回線を自動で接続するストロージャー式自動交換機です。 1951年、デジタル交換機の最先端において、典型的な中央電話交換局はビクトリア期の特大サイズでした。ストロージャー式自動交換機は、通信中の全ての電話の信号を扱っていました。

“なぜ納期を守れなかったのだろうか？” 我々マネージャが、納期に遅れることを自分のチームのせいにするのは簡単です。しかし、納期に遅れる原因は本当に開発者の仕事が遅いせいでしょうか？ Sprintly は、開発者のサイクルタイムに関する膨大なデータを保有しています。当社は、タスクのサイズごと（S、M、L、XL）、また種類ごと（ストーリー、テスト、バグ）に、完了までにどれくらいの期間がかかるかを追跡しています。 当社が調査した動向について 1点目：開発者は非常に平均的です。ユーザ全体で見たサイクルタイムはほぼ同じであることを当社のチケットデータが示しています。システム内の全チケットの75%は、開始後およそ175時間で完了しています。 ^(1) 2点目：変動があるのは、ほとんどがチケットが開始される前（SomedayからBacklogまで）の段階です。これは、関係者が仕様を理解して作業の優先順位

パイプライン は、最近のソフトウェアエンジニアリングにおいて、非常に便利な（そして驚くほど活用されていない）アーキテクチャパターンです。ソフトウェアでデータの流れを制御するためにパイプとフィルタを用いる考え方は、最初のUNIXシェルが作られた1970年代からあります。もしターミナルエミュレータでパイプ” | ”を使ったことがあるなら、”パイプとフィルタ”を活用できていることになります。以下の例を見てみましょう。 cat /usr/share/dict/words | # Read in the system's dictionary. grep purple | # Find words containing 'purple' awk '{print length($1), $1}' | # Count the letters in each word sort -n | # Sort l

現代のプログラマを取り巻く世界には無数の方法で組み合わされた、たくさんのUnixツールがあふれています。優れたツールは開発環境とシームレスに統合されますが、そうでないツールは使うたびに不満がたまっていきます。また、優れたツールはあなたの想像力次第でどんなものにも適用できますが、そうでないツールはあなたの開発環境で動かすためだけでも、あの手この手の対策を講じなければならないことがよくあります。 “One thing well” misses the point: it should be “One thing well AND COMPOSES WELL” — marius eriksen (@marius) October 10, 2012 “一つのことだけうまくやればいい”という考えでは目標に到達しない。”うまくいったものを、うまく組み合わせる”ことまで考えるべきだ 良い設計に必要なもの

以前、 OpenVz コンテナだった私の” ホームクラウド “と、 私があらゆるビルドに関して”ビルドサーバ”のリビルドを推奨するようになったワケ について書きました。 Docker はあっという間に私のお気に入りのツールに仲間入りしました。限りなく静的なサーバ環境を作り出す繰り返し可能なビルドを作成するという考え方が気に入ったからです。 今回は、私がDockerを使用する中で繰り返し現れるようになったいくつかのパターンを説明します。どれも特段に目新しいものでも非常に驚くようなことでもありませんが、皆さんにとってそれが役立つものであり、また皆さんがDockerを使用する中で遭遇するパターンについても聞くことができれば幸いです。 私がDockerを使って色々なことを試す根本にあるのは、データを喪失することなくDockerコンテナそのものが自由に再作成できるよう、ボリュームにあり続ける状態を維

このブログ記事は2014年5月21日に行った私の講演の内容に基づいています。 ここ数年、GNU/LinuxのディストリビューションはSysV initを避ける傾向にあり、代わりに多種多様な新しいinitシステムへと移行が進んでいます。SysV initに満足しているユーザにとっては、これは予想外の流れでしょう。問題なく使えるのに、なぜ多くのディストリビューションはSysV initに背を向けているのでしょうか。 この記事ではSysV initの問題点と、それに対してsystemdがどんな解決法を提供しているのか説明してみようと思います。 私は特にsystemdの大ファンだというわけではなく、ただ広く使われているツールだという認識以上の思い入れは無いことだけお断りしておきます。 initシステムの役割とは何か？ コンピュータが起動する時には、ビルトインされたファームウェア（コンピュータの場合

数ヶ月前、私はJames O Coplienの ほとんどのユニットテストが役に立たない理由 という記事に出会いました。Jamesはほとんどのユニットテストは無意味であると考えていて、タイトルは内容をそのまま正確に表しています。彼は 追加記事 で議論をさらに展開しています。私は彼の議論に大変興味をそそられました。というのは、私はユニットテストから多くの利益を得ているからです。私たちはどうしてこのような異なる見解を持つに至ったのでしょうか？ 私が何かを見逃したのでしょうか？ 結局のところ私は彼の見解に賛成できませんでした。以下は彼の記事に対する私の意見です。 ユニットテストが必要な場合 私の経験では、ユニットテストはアルゴリズムロジックに対して行う時に最も有益です。結合度の高いコードについてはその性質から特に有益ではありません。結合度が高いコードはユニットテストのために多くのモックオブジェクト

『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』 を書いたFred Brooksはその論文の中で、 偶有的な複雑性と本質的な複雑性 について重要な区別をしています。 本質的な複雑性 とは、問題特有の領域から生じる複雑性のことを指します。例えば、SMTPクライアントを作成しているディベロッパは、 RFC 5321 の核心の細かいところ全てに取り組む必要がありますが、これはSMTPクライアントの作業をする上で避けては通れないものです。これに対して 偶有的な複雑性 とは、私たちが自ら作り上げた問題から生じる複雑性のことを指します。 技術者としては、自らの選択で生じる偶有的な複雑性によって、余計な負担が増えないようにとても注意しなければなりませんよね。その意味では、言語の選択は偶有的な複雑性を軽減できる完璧な例と言えます。Webアプリケーションを書くのにアセンブリ言語を選びます

（訳者注: 検定手法について、この記事には一部内容が古い部分があります。Optimizelyは現在、両側検定を採用し、独自開発したより精度の高い統計手法(Stats Engine)でテスト結果を表示しています。Stats Engineに関する記事: 日本語 ・ 英語 ） 私たちがSumAllでA/Bテストを一斉にスタートさせて6ヶ月が経ち、あまりよくない結末を迎えました。それは勝算があるとした結果のほとんどが新規ユーザーの獲得改善にはつながらなかったことです。それどころか、私たちは失敗したのです。そして私の一番の責任はユーザー獲得の増加であるということを考えると、本当に最悪の状況でした。私にとっても、私のキャリアにとっても、そしてSumAllにとっても。 過去に A/BテストとWebサイト･パーソナライゼーションの会社 に勤めていた経験から（はっきり言うとMonetateはOptimize

ほとんどの開発者は、自動のガベージコレクション（GC）を当たり前のように使っています。これは、私たちの仕事を容易にするために言語ランタイムが提供する素晴らしい機能の1つです。 しかし、最新のガベージコレクタの中をのぞいてみれば、実際の仕組みは非常に理解しづらいことが分かります。実装の詳細が無数にあるため、それが何をしようとしているのか、また、それがとんでもなく間違った事態を引き起こしかねないことについて十分理解していない限り、すっかり混乱してしまうでしょう。 そこで、5種類のガベージコレクションアルゴリズムを持つおもちゃを作ってみました。小さいアニメーションはランタイムの動作から作成しました。もっと大きいアニメーションとそれを作成するコードは github.com/kenfox/gc-viz で見ることができます。単純なアニメーションによってこうした重要なアルゴリズムを明らかにできることは

昨年と今年の冬学期に、私は CS149 コースのティーチング・アシスタント（TA）を務める機会に恵まれました。CS149とはスタンフォード大学の並列プログラミングのコースです。講師を担当したのは Alex Aiken と Kunle Olukotun でした。私は仕事に取り掛かると、コースで使用するマシンの管理について根本から見直しました。CS149は一風変わったコースで、課題ごとに異なるプログラミングモデルを学びます。ですから、課題が出る度に、異なるハードウェアやソフトウェア・スタック上でプログラミングを実行することになります。 開講当初、TAは各課題で使用する物理的ハードウェアを個別に管理していました。課題の準備をする際には、ゲイツ・ビルディングの地下へ降りて行って、使用するマシンが貸し出し中であったり盗まれたりしていないことを確認しなければいけませんでした。また、学期ごとにソフトウェ

大変そうに見えるが簡単 ウィンドウ関数を使用するためには、OVER()句で”ウィンドウ関数の構文”を用いる必要があります。サンプルテーブルを作成し、それを使って全てのウィンドウ関数に対する例を挙げてみましょう。 この例では、14名の学生が居るクラスを管理しています。 -- Creating the table CREATE TEMP TABLE students ( id serial, name text, grade int DEFAULT NULL, last_seen_in_class date ); -- Adding some students INSERT INTO students (name, grade, last_seen_in_class) VALUES ('Jacob', '9', '2014-08-16'), ('Michael', '6', '2014-08-

この数ヶ月というもの、プログラマーに本を執筆することを薦めている記事をいくつも見かけてきています。このような記事ではそれぞれ少なくとも少しは役に立つアドバイスを提供しており、最終的には同じようなアイディアへとつながる結論に達していました。 自分のブランド構築のために本を執筆するべき . この結論は私からすると正確で非常に残念なものです。本を執筆するということに対する圧倒的な理由がブランド構築というのであれば、これから著者になるであろう人々はブランド構築をすることで何らかの利得があるという人（そして、時間を無駄遣いする人）だけになってしまいます。 そこに至るまでの道のり インターネットが原因だというのは明白です。誰もがといっていいほど多くの人が動画や楽曲、そして書籍を無料でダウンロードできることを知っています。「違法ダウンロード」に関する意見は反対意見からプライドに満ちたものまでと様々です。

本エントリは 翻訳リクエスト より投稿いただきました。 ありがとうございます！リクエストまだまだお待ちしております！ 後編 を公開しました 私たち、Y Combinatorがアドバイスする最も一般的なことの1つに、「スケールしないことをしよう」というのがあります。創業予備軍の多くが、スタートアップは上手くいくかいかないかのどちらかだと考えています。会社を立ち上げ、ものを提供する、そしてそれが良いものであれば、おのずと売れます。しかし、需要がなければ結果はその逆になります。 ^(1) とは言え、意外とスタートアップは上手くいくものです。なぜなら、創業者がそうさせるからです。自分たちの力だけで成長するスタートアップはほんの一握りかもしれませんが、大抵は後押しするような力が働きます。良い例が、車のエンジンをスタートさせる役目をするクランクです。エンジンがスタートしてしまえば、エンジンは回り続けま

前編はこちらです 4：テストに伴うコスト 2014年5月27日 audio 今回のテーマは、テストとTDDのマイナス面です。 テストをやりすぎることがあるか、そして機能的なコードよりテストを重視するチームには問題があるかという点について議論しました。 議事録 Davidが会話の口火を切りました。 「トレードオフについて話すなら、当然そのマイナス面について理解しなければならない。なぜなら、欠点のないトレードオフは存在しないからだ」 このあと彼は続けて、TDDは開発者に何かを強制するわけではないが、ある一定の方向に導くことは確かだと言いました。 それから、最初の問題点として、テストの過剰な実施を取り上げました。 TDDでよく言われるのは、テストに失敗せずして1行のコードも書くべきでないということです。 Davidも当初はこの考え方を合理的だと思っていましたが、そのうち、テストをやり過ぎる傾向が

私はGo言語が気に入っていますし、多くの場面で使用します。現にこのブログもGoで書いています。Goは便利な言語ですが、優れた言語とは言えません。つまり、悪くはないけれど、十分ではないということです。 満足できない言語を使用する際は注意が必要です。注意を怠ると、その言語を次の20年間使い続ける羽目になるかもしれないからです。 私のGoに対する主な不満を本文にまとめました。既に何度も指摘されていることも含まれていますが、中にはこれまでほとんど話題になっていない指摘もあります。 これから列挙する全ての課題には既に解決策があることを示すため、私が優良な言語と考えるRustやHaskellと比較して説明します。 汎用プログラミング 課題 誰でもさまざまな事柄に幅広く対応できるコードを記述したいと考えます。例えば数のリストの合計を求めるために定義した関数が、小数、整数、またその他の合計を求められるもの