Google の面接を受けてみた - 科学と非科学の迷宮
Google の面接について書かれたブログ記事が面白かったので翻訳してみました。 原著者の許可取得済み。(Thank you, Petris!) 本文 二週間ちょっと前、ぼくはカリフォルニアのマウンテンビューで Google の面接を受けてきたんだ！ Google の面接が面白い体験だったから、ぼくはそのことを話したいんだ。(Google からはこの記事を出すゴーサインをもらった) ぼくが面接を受けた職種は Google SRE だった。SRE というのはサイト信頼性エンジニアリング(Site Reliability Engineering)という意味だ。サイト信頼性エンジニア(SRE)はソフトウェアエンジニアでもあり、システム管理者でもあって、Google の製品サービスを端から端まで責任を持つんだ。 合計8回の面接があった。最初の3つは電話越しで(電話面接)、残りの5つは現地での面接だ
プレビュー付きエディタ『Google AJAX APIs Playground』を使ってみた
すごいねこれほんとすごい。ってか今まで知らなかったこんなのあるなんて・・・。 Learn & Test Google’s APIs Easilyで掲載されてて朝から色々触ってました。 その簡単なレポートです。 GoogleAPIが色々サンプル収録されたエディターって感じでしょうか。 AJAX APIs Playground 面白いなぁ。わくわくするなぁ。 手っ取り早くRSSリーダーみたいなのを作ってみると この時点で、下のほうにプレビューが生成され、レイアウトや仕様を見ながら選べるのが特徴的。 すごく便利ー。 後はキーの部分や、取得するRSSのURLをちょこっと変えてコードをコピペすれば、あなたのサイトで簡単にRSSリーダが設置できますね。 APIキーについては、公式で確認するのが一番ですが、それぞれのサービスを使う為に、APIを使うURLをGoogleに申請して『キー』を発行してもらう必
バグで大事なのは内容じゃない！ - Fight the Future
火消しプロジェクトなので、毎日数十件というバグが出ていた。 BTSのようなシロモノはなく、Excelでの障害管理表という(悪い意味での)一般的なバグ管理だった。 しかし、そこに書かれているのはバグの内容ばかり。 ああ、わかっていない。 エンジニアにとって、重要なのはバグの内容でもなければ、コードを書けもしない人の原因の推測でもない。 バグの再現手順だ。 再現さえできればバグの内容なんてすぐに把握できる。 だからバグの内容なんて1行程度の概要だけでいい。 でも再現手順がなければそのバグを再現するだけで相当の工数がかかる。 たとえば、どんなユーザーでログインしたのか？ どんな画面遷移をしてその画面に行くのか？ どんなIDのデータなのか？ 画面上でどんな操作をすればバグが出現するのか？ こういったことが記述され、すぐにでも再現できればバグの修正コストは相当低くなる。 そもそもの話で、管理表にバグ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
