キャリアの点と線

約2年前 | 2 points

「面接での一つだけの質問」と題したBob Baxleyのブログエントリー :

「この仕事に就くと決めて、うちに入社したと思ってください。... 一つだけ確実なのは(短い期間であろうが、遠い将来であろうが)、貴方はいつか退職するということ。.... 退職してからこの会社のことを振り返って、あなたが経験したことや達成したことを3〜5個の箇条書きでまとめてLinkedInに掲載するとします。その時貴方は何と書きますか?」

数分しか時間がないと仮定した面接の際に何を相手に聞くのかという文脈の話なのですが、自分なら即答できないかもしれないなと思いました。答えられない質問という訳ではなく、本当によい質問なので、条件反射的に返すのではなく、じっくり考えて答えたい。もしくは事前に考えて書いたものを渡したいという意味です。

面接を受ける人が自身のキャリアに期待するところと、...

開発現場における並行処理の留意点

約2年前 | 1 point

Squareが主催した並行処理システムに関するパネルディスカッション。

まずは、並行処理理論で博士号を取得し、Sqaureで分析システムを担当するGian Perroneがハイレベルでの留意点を挙げています。

  • システム全体で起きていることを自分の頭で完璧に把握しようという姿勢は、正確な並行処理システムをつくる妨げになる。テクノロジーやツールをうまく利用すべき。
  • 並行処理システムを漏れなくテストするというのは相当難しい。
  • 自分で考えて、注意深く対処するというのでは不十分。うまく抽象化に頼るべき。

続いて同社のTamir Dubersteinが、以前データセンタを移行させたときに経験したバグについて、

非同期処理するJavaシステムと、Rubyなのでリアルな並行処理ではなかったが、Javaが実行するたびにプロセスをフォークし、Javaが新しい子プロセスを走らせる仕組みだった。...

分散システム設計のチェックリスト

約2年前 | 1 point

TwitterのMarius Eriksenは分散システムのエキスパートであり、モジュール化され、安全でかつ効率よく機能するサーバソフトの構築のノウハウは、「Your Server as a Function」という論文にまとめられています。

また、分散システム設計における留意点も、下記の内容のチェックリストというかたちで紹介してくれています。

1. 障害耐性

  • もし依存先が障害を起こしたらどうなるか?その障害がゆっくりと起きたらどうか?
  • システムをどのようにスムーズにデグレードさせることができるか?
  • システムは想定以上の負荷にどう対処するようになっているか?
  • 大きな障害が起きた時の最悪のケースはどうなるか?
  • どれだけすばやく復旧できるか?
  • 処理を遅らせることができる箇所はきちんと遅れて動作してくれるか?
  • シムテムは可能な限りシンプルにできているか?
  • システムは負荷をどのように分散できるようになっているか...

伝えてないから伝わらないこと

約2年前 | 2 points

GoogleのIlya Grigorikがプレゼン [1] において、TLSをもっと活用できるデフォルト設定をnginx側にしてほしい、つまり設定できるだけでは人々は気づかないのでデフォルトをどれにするのかというのが重要なのだと説明する文脈で例えにだしたのが、「Curse of knowledge」

The curse of knowledge is a cognitive bias that leads better-informed parties to find it extremely difficult to think about problems from the perspective of lesser-informed parties. [1] (… 情報を持つ側にとって、情報を持たない側の視線に立って考えることはものすごく難しい... )

これを聞いて、「Curse...

能動的な姿勢に比例して学びの効果は上がっていく

約2年前 | 1 point

TELUQ(ケベック大)のコンピュータサイエンスの教授であるDaniel Lemireが語る、効果的な学び方の話。

教室に座って教授の講義を聞いていると学んでいる気になる。新しい話題についての本を読むと学んでいる気になる。しかし、相当受け身な学び方ゆえに、それでは非効率。ある意味非効率よりももっと始末が悪い。理解できたような誤った錯覚を覚えるので、非生産的である。… その内、その話題や専門用語などに慣れてくる。(理解してないのに理解しているように感じて)自分を欺いてしまうので、何も学ばないよりももっとよくない状況になる。

という厳しい指摘から始まりますが、解決策は、「チェレンジングだと感じるアクションをすることで、自らを鍛えることができる。」ということ。

  • テキスト本をダラダラ読み進んでも意味はない、一番難しい課題を見つけ出しトライすること。
  • 学んだことのまとめを書いて、振り返ること。...

エンジニアと非エンジニアの境界

約2年前 | 3 points

この先、ソフトウェアの力でビジネスの競争力に格段の差がついてくる産業がどんどん増えてくることに備えて、プログラミング教育の必須化の議論も盛んですが、その必須化の是非はさておき、将来的には社会人になるうえで、ある程度コードを理解できる素養があることがもっと当然のことになってくるのではないかと期待してます。

そうなると、今の世の中の人が漠然と持っている、「エンジニア」と「非エンジニア」という言葉から連想してしまう偏見、両極端なイメージは、いずれの側に属する人々にとっても将来はもっと不利益になるかと。相互理解が必要です。境界を薄めることができるかどうかが重要です。

この点について、RelateIQのFounder & CTOのAdam EvansがTech Crunchに寄稿したエッセーが秀逸(私がこのブログを書いている時点では日本語版には掲載されてませんが、そうなると期待しています。...

立て直しのケーススタディ

約2年前 | 1 point

日次のアクセスが1万人以下なのにサイトパフォーマンスが悪いシステムの立て直しを頼まれたJacques Mattheijjが、5週間で行った対応を紹介してくれているケーススタディです。

システム構成

  • Rails + PostgreSQL + Redis + AnguarJS + Symfony2
  • CentOS / HPブレード8台 (128G RAMと複数のVMware)、大型HPストレージアレー、Windowsマシン、Javaアプリ専用マシン

全体所見

  • アプリは概ね問題なし。システムレベルで非効率が散見され、開発の期限が近づいた時点で、雑な仕事がされたとみられる。
  • なぜか高額なハードウェアが先に選定されていて、それに合わせた調整手間が発生してしまっていた。

個別の対策

  • VMが130個。これを取除くことでシステムの複雑さが大幅に改善できた。
    • 取るに足らないシステム機能にもVMとバックアップVMが複数。...

iOSのデバッグを極める

約2年前 | 1 point

objc.ioはベルリンのメンバを中心に、月替りでiOS関連技術の特定のテーマに絞って発信しているブログ。もう既に知名度はかなり高いかと思いますが、毎月ものすごく力の入った特集ゆえに、その分ボリュームも相当で、読むのも大変というか、時間がないから読めてない人もいるかと。今月は#19としてデバッグの話題です。

  • Peter Steinbergerの「デバッグ : ケーススタディ」では、UIKit上のバグをLLDBで対処した話を紹介。
  • デバッガーでのダンス - LLDBのワルツ」において、Ari GrantはLLDBの使い方を詳説してくれています。
  • DTrace」はiOSシミュレータでしかまだ利用できないようですが、アプリに関して任意の調べたいことを本番のバージョンで、かつアプリを再起動せずに確認できるということで、Daniel Eggertは重宝しているようです。
  • Florian...

Yehuda Katzという生き方とインディーWeb

約2年前 | 1 point

昨日のエントリーでも名前のでてきたYehuda Katzですが、Rails / Ember.js / jQuery / W3C Technical Architecture Group (TAG) / TC39-ECMAScriptなどで活躍し、今回はRustのコアチームに参加することが発表されてます。Tom Dale曰く「インターネットの半分くらい書いてる感じだから。[1] 」という勢いがあります。Yehudaの仕事振りやプロジェクト運営における考えは、オープンソースという視点での発言ですが、企業におけるプロジェクトの進め方や今後の働き方のスタイルがどう変わるか、変わるべきかという観点からも、示唆に富むものだと思います。

まず。彼がメジャーなプロジェクトを渡り歩いてきた経緯について、

最初に掲げたコミットメントの成果をだし、舞台から時間をかけてゆっくりと引いていくスタイル。...

Ember.jsのサーバサイドレンダリングと強運の話

約2年前 | 2 points

Ember.jsを率いて、積極的な発言もあり、今やJavaScriptフレームワークの世界では主要人物となったTom Daleですが、成功する人は、それを掴める強運の持ち主でもあります。

自分は本当にラッキーだった。だから人にアドバイス頼まれても再現が難しい話なんだけど。大学ではコンピュータサイエンスの学位は取ろうとしたんだけど、純粋数学は難しすぎて単位が取れなくて。その後はApple Storeのジーニアスバーで働いていたんだ。友人がAppleのリテールチームにいて、彼は自分がシェルスクリプトをちょっと書けることを知っていて、「プログラマーを必要とするプロジェクトがあって、公式には会社からサポートされてないんだけど、やってみる?Apple Storeで働いてることにしてバイト代払うよ。」と言ってくれたのがSprouteCoreアプリの開発案件。...

理由駆動型の働き方

約2年前 | 1 point

会社のビジョンやカルチャーは、長期に続く活力あるチームであるために本当にすごく大切だなと感じることがこの数年の間に何度かありました。

では、その「本当に」「すごく」というのは具体的にどれくらい重要なのでしょうか?

PandoMonthlyの時間に及ぶ長いインタビューの最後に、WorkdayのCEOであるAneel Bhusriが、「ほとんどの人がそう思ってないけど、自分だけは強く信じていることは何?」という質問に答えて、

「うちの会社にとって、カルチャーはプロダクトよりも大切だ。」

と言い切っています。よいカルチャーが、よいプロダクトづくりに必ずつながるという彼の長年の経験から得た確信がそう言わせているのかと。

また、Ernie Millerは "Human-Driven Development" と題したブログで、

幼い頃から人は「なぜ?」と質問する。...

Androidの開発現場での学び

約2年前 | 1 point

日本に12月の頭から2ヶ月間滞在してますが、いくらなんでも寒すぎます。とはいえ、その合間に深刻な水不足に陥ってるカリフォルニアに唐突に嵐がやってきたりして、世界中異常気象ですね。。

さて、NewCircle / SF Android / AnDevConが主催したAndroid開発のメジャープレーヤー8名による座談会です。2時間近くの長丁場ですが、興味深いコメントだけをピックアップしてみると、ほぼSquareのJake Whartonの独演会のような構成になってしまいました。

Square

皆もよく知ってるように、初期のAndroidの基本設計は、Javaで書かれたものはどうテストすればよいかという従来の共通認識に反するものだった。Squareでは三種類のテストを実施している。最も大きな位置付けを占めるのは、ユニットテスト。例えば、Square Registerだと数千件ある。...