Go-to person（頼りになる人）
何か相談事があるときに真っ先に話をしに行く相手のことを go-to person と呼ぶ。要するに「頼りになる人」のことである。本記事ではミドルレベルのソフトウェアエンジニアが go-to person として頼りにされるためにはどう振る舞えばよいか私見を紹介する。職種や立場が違えば目指すべき go-to person のあり方もまた違ったものになることはご留意ください。 Go-to person の役割 Go-to person は相談者が抱える課題を分解・整理するのを手伝い、自身の知識や経験に基づいた適切なアドバイスを提供する。相談者は go-to person と話すことで暗中模索する時間を節約し、最終的な判断に自信を持つことができる。シニアソフトウェアエンジニアやテックリードになる要件として、何らかの分野で go-to person として認知されていることを求めている場合も多いだ
設計に悩みすぎる前に手を動かしてみる話
私がソフトウェア開発において心がけていることの一つに「設計に悩み始めたらとりあえず手を動かす」というものがあります。今まで深く考えずにそう心がけていましたが、この記事で自分がなぜそうしているのか整理して言語化してみたいと思います。 話のスコープ ここでいう「手を動かす」とは「コードを書く」ことです。設計と聞いて人によって思い浮かべるものが違いますが、ここでは「一人のソフトウェアエンジニアが四半期程度かけて開発する規模の機能の設計」を想定しています。何人ものソフトウェアエンジニアが長期に渡って行うような大規模開発には当てはまらないです。 本題 次のような経験はないでしょうか？ 設計を考えながらデザインドキュメントを書いていたら細部の粗が見えてきて無限に悩み続けてしまった。考えなきゃいけないことがどんどん膨らんでいって、いつまでも実装に手を付けられなかった。 これに対して私は「設計に悩み始めた
リソースの読み込みを助けるウェブブラウザ API の世界
ウェブブラウザはネットワークから様々なリソースを集め、それらを処理して組み合わせてウェブページをレンダリングします。リソースが揃わないとレンダリングできないので、この一連の処理のどこかが遅れるとページの表示も遅くなります。レンダリングをすみやかに開始できるようにウェブブラウザはリソースの取得やその処理を最適化するための API を提供しています。本記事ではそれらを網羅的に紹介し、ウェブアプリの性能改善を図る上でどのようなブラウザ機能が使えるのかを知ってもらうことを目的としています。各機能の具体的な適用事例については他の記事に委ねます。 本記事の内容は記事公開時点での情報に基づいており、閲覧時点では既に古くなっている可能性があります。最新の正確な情報は一次情報源を参照してください。また特定のブラウザ実装について言及する場合は、断りがない限り Chrome を想定しています。誤りや補足、質問な
「大学の授業は大切ですか？」への回答 (情報系)
以前、情報系の学科で学ぶ大学生から「大学の授業は大切ですか？」という質問を受けました。もしかしたら同様のことで悩まれている方がいるかもしれないので私なりの回答をここに記しておきます。予め強調しておきたいこととして、これは私見に過ぎず、私が経験したことや見聞きした事柄に強く依存しています。色々な人に同様の質問をしてより客観的な判断をしていただければと思います。 元の質問者の方は少し込み入った状況にあってこの質問をしてくれたんですが、記事にまとめるにあたってそのあたりを端折って一般化しています。 私の回答 学士としての専門性を獲得する上で大学の授業は重要ですし、そこに異論はないでしょう。それを前提として、私はさらに (1) 単位の取得、(2) 共通言語の獲得、という二つの点から大学の授業は大切だと考えています。 (1) について、単位の取得や良い成績を収めることは、海外留学や就職といった成績表
チームにいると頼りになるソフトウェアエンジニア
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
ウェブの進化とウェブブラウザ開発の最前線
学部 3, 4 年生向けの特別講義で『ウェブの進化とウェブブラウザ開発の最前線』というタイトルで話をしてきました。 ウェブの進化の歴史を知ることで現在のトレンドについて理解し、またウェブブラウザというグローバルで大規模なソフトウェアの開発の一端を垣間見ることで、ウェブやウェブブラウザの開発に少しでも興味を持ってくれたら良いなぁという気持ちで話をしてきました。 なお歴史観については私の事実誤認も含まれると思うので、間違いを見つけたら教えて下さい :-) 追記 (随時) たくさんの反応を頂きありがとうございます！次回同じような資料を作るときの参考にできるよう、ここにメモしていきます。ウェブは無限に話せる話題があって楽しいですね！ ウェブ以前のハイパーテキストの歴史も取り入れるべきでは？ ありがとうございます！おっしゃるとおりで、ウェブの進化史と言いつつウェブが公開されてからの話しかしていないの
論文｜MESH: Compacting Memory Management for C/C++ Applications (PLDI 2019)
「MESH: Compacting Memory Management for C/C++ Applications」という論文を読んだのでその紹介です。arXiv.org で公開されています。PLDI 2019 で採択されている論文のドラフトだそうです。私は v2 を読みました。ソースコードが GitHub (plasma-umass/Mesh) で公開されています。 免責 読み間違えている可能性があります。正確な情報が欲しい方は必ず論文を読んでください。誤りの指摘や補足、議論などは GitHub Issue や Twitter へお願いします。 読んだ動機 C/C++ でリロケーションせずにコンパクションを行う手法に興味があった。 Speedmetor 2.0 benchmark を走らせた Firefox でメモリ消費量が減ったと報告されており、ブラウザ開発者として気になった。 Ch
日々の進捗の出し方
私は「何かを習慣化してやり続けてそこそこのレベルまで持っていく」のがわりと得意な方だと思っています。本記事はその辺りのことを言語化してみようという試みです。 大体いつも二つのことを意識しています。一つは「毎日前に進む」、もう一つは「当たり前のレベルを上げる」です。 毎日前に進む 身も蓋もない話ですが、やらないと進捗は出ません。一方、少しでもやり続けていればいつか絶対にゴールに到達できるはずです。眠くても疲れていても毎日ちょっとずつ前に進むべきです1。ここで大事なのは「量はどうでもいい」ということです。「毎日やり続ける」ことが重要で「毎日 15 ページ本を読む」のように決まった分量をこなすことをルールにしてはいけません。破綻します。 さて「いつか絶対にゴールに到達できるはず」と言いましたが、ゴールがあやふやだといつまでも到達できません。ゴールは到達判定可能で少しずつ近づけるものにし、進捗もざ
就職して 6 年過ぎた
新卒のソフトウェアエンジニアとして Google に入社して丸 6 年が過ぎました。「若者は 3 年で辞める」という話があるけど、その二倍も働いていることになります。当時の気持ちを忘れないうちに今までの振り返りをしてみようと思います。 (2019/04/04 追記) 入社までの話を「新卒のソフトウェアエンジニアになるまで」という記事に書きました。 なお、すべて個人的な体験談であって会社の見解等を表しているわけではありません。 きっかけ Google を意識したきっかけは大学一年生の頃に読んだ梅田望夫さんの『ウェブ進化論』でした。多分同世代の多くの人がこの本に影響を受けたんじゃないかと思います。私も「これからネットの世界はどんどん変わっていくんだ！」と興奮し、その中心的な会社だった Google に憧れを持ったことを覚えています1 。 直接的なきっかけは修士一年生の頃。そろそろ就活に向けて動
JavaScript のスレッド並列実行環境
これは Chromium Browser アドベントカレンダーの十日目の記事です。本記事では Chromium における JavaScript のスレッド並列実行環境について仕様・実装・API の面から包括的に紹介します。ブラウザの内部実装に興味がある人を対象に、各機能の使い方ではなく実行モデルに焦点を当てて説明しているため、難易度は高いです。使い方を知りたい人は MDN などの記事を読んでください。この記事をきっかけに実装解読に挑戦してみる人が一人でも増えると幸いです。 本記事を書くにあたり、yuki3 さんに多くのコメントをいただき、議論に付き合っていただきました。ありがとうございました。なお、文責はすべて私 (nhiroki) にあります。誤りや補足、質問などは気軽に GitHub Issue もしくは Twitter へお寄せください。 更新履歴 2018/01/15 Layout
Chromium のソースコードの歩き方
これは Chromium Browser アドベントカレンダーの一日目の記事です。初日ということで、本記事では Chromium のソースコードを読む上で役に立つであろう、プロジェクトのディレクトリ構成やファイル構成を紹介します。 (2018/04/09) “The Great Blink mv”1 プロジェクトによってついに WebKit ディレクトリが blink ディレクトリにリネームされました。それに伴い本記事の内容を更新しました。差分は以下の通りです。 third_party/WebKit/Source を third_party/blink/renderer に置換。 blink/ 内のファイル名の命名規約を Bar.{cpp,h} から bar.{cc,h} に置換。 置換に伴う説明文の修正。 (2017/12/01) ディレクトリ構成について追記しました。 Chromium
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
