“テックリードという役割”のその後 — Will Larson “Staff Engineer”
この本は大きく前半と後半にわかれていて、著者によるStaff Engineerの職務内容・昇進・会社選びなどに触れた前半、”Stories”と章立てされたStripe・Slack・FastlyといったTech企業で働く14人のインタビューを掲載した後半の構成になっています。私は前半を読みおえ、後半のインタビューを2人目まで読んだ状態です。 本書にかかれているスタッフエンジニアの職務内容や求められるものは良い意味で私のイメージしていものとは違いました。 これまで私が想像していたのは「所属する組織が使うOSSにコントリビュートして技術的な優位性を保る」「社内のツールを開発して組織全体の生産性を上げる」のような一言で言えば凄腕のエンジニアでした。 しかし、本書で紹介されるスタッフクラス以上の職務を自分なりにまとめると「チーム間・全社的な技術面でのマネジメントを行い、経営上のゴール達成に貢献する」
RubyにはオブジェクトのIDがあるのにJavaScriptにはないのはなぜか？
この記事は Ruby Advent Calendar 2021 の6日目の記事です。 Tebiki 社の渋谷です。今回は「Ruby は各オブジェクトに対して一意な整数（object identifier）が割り当てられているけど、JavaScript にはそういう値がないのはなんでなんだろう？」というのに思いを巡らせてみた話です。 Ruby の object identifier は以前アドレス値だったRuby ではオブジェクトを一意で特定できる object identifier を object_id というメソッドで取得できます。言語を利用する側としてはそんなに使う機会はないのですが、Rails 本体でもテストのときにオブジェクトの同一性を検証するために使われていたりします。 ※1 で、object_id を生成している具体的な実装を見てみると、Ruby 3.0.3の場合はこんな感じ
Cloud Run でマイクロサービスを作る 5 つのポイントをまとめてご紹介！
はじめに早速ですが、皆さんはマイクロサービスを構築するとしたら、どのような構成を考えますか？ 多くの企業で、GKE を使ったマイクロサービス アーキテクチャが採用されています。選定理由として、Kubernetes が持つ機能や大きめなリソースが必要であったり、社内インフラチームによる Kubernetes のサポートがあるといった理由などがあります。一方、定期アップグレードなどの観点から、Kubernetes の運用は少し大変…と感じる方もいるかと思います。 GKE Autopilot の利用という考えもありますが、サーバーレスでコンテナを動かせる Cloud Run を使って、インフラ管理不要でマイクロサービスを構築が出来ると嬉しくないですか？ 実際、そういった構成を採用されている企業も見かけます。 この記事では、設計や実装時に考えるであろう、以下の 5 つのポイントにフォーカスしてみた
踏み台EC2を廃止してSession Manager接続に置き換えました
こんにちは、エウレカ SRE チームの原田です。 今年 (2021年) エウレカでは、公開鍵認証で接続するEC2の踏み台サーバを廃止し、代わりに各サーバへの接続をIAMで認証できるSSM Session Managerへのリプレースを行いました。本記事ではそのモチベーションや、実装のポイントを紹介していきたいと思います。 旧来の踏み台サーバ 旧来の踏み台サーバエウレカで長く運用されていた踏み台サーバ (Gateway) は以下のようなものでした。 各開発者は、自分の秘密鍵を使って踏み台サーバへSSHを行う ( 踏み台サーバ上には各開発者の個別ユーザーおよび公開鍵が登録されている )踏み台上では、接続が許可されているSSH対象のサーバの秘密鍵がユーザー毎に配置されており、その鍵で各サーバにSSHするMySQL / Elasticsearch / Redis など、Private Subnet
BigQueryの2020年アップデートを（だいたい）全部振り返る
BigQueryに関する話を自由にしましょう - BigQueryでデータ基盤を作った - BigQueryと他サービスでデータ転送した - BigQuery関数でこんな計算をしている などなど みなさんこんにちは。年末ですね。年末やることといえば、振り返り、総集編ですよね。 BigQueryアドベントカレンダーができたのをみて、「そういえば2019年にやったBigQueryのリリースまとめ的なの、2020年やってないな・・・？」と思い立ち2020年のBigQueryアップデートをまとめました。リリースノート開いたらスクロールバーがすごく小さくなり心が折れかけましたが、なんとか気持ちを奮い立たせました。もしもこんな長い記事を最後までスクロールしてくれる方がいたら、感謝の意を表明しますので、Twitterで @yutah_3 まで教えていただけると、泣いて喜びます。 以下、カテゴリに分けてア
【いでよ障害対応太郎】我々はインシデントにどう向き合っているのか 〜社内向け障害対応リスト付き〜
「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ
「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」を１年掛けて整理した
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
開発組織で重要なコンウェイの法則ともう一つの原則
原則を数個決めたら他のことはすべてそれらから導出されるような考え方が好きです。 開発組織の設計あたってはコンウェイの法則というのがよく参照されます。 コンウェイの法則：システム設計は、組織構造を反映したものになる コンパイラーを3チームで開発すると必ず３パスのコンパイラーになる、みたいな例を読んだことがあります。 これが起こる理由は、チーム内でのコミュニケーションコストがチーム間のコミュニケーションコストよりも格段に低いためです。同じチームで開発するシステム内はコミュニケーションコストが低いため密結合になり、チーム間のシステム結合はコミュニケーションコストが高いため疎になっていきます。 これを逆手に取って、最終的に実現したいシステムの形に合わせて組織を分けるのが逆コンウェイの法則です。 大きな単位のシステム設計は、３年、５年、あるいはそれ以上の長期間に渡って影響を及ぼします。ここを間違うと
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
エンジニアのコーチング by Kent Beck
以下は、Kent Beckによる「Coaching Engineers」の翻訳です。本人の許可を得て掲載します。tl;dr 有償でエンジニアのコーチをします。詳細と待ち時間についてはお問い合わせください。 物語の結末2018年2月にFacebookを退職する直前に、トップ1%のエンジニア（現在および過去にレベルE7以上だったエンジニア）のオフサイトミーティングに参加しました。海辺のリゾートでバスを降りると、私がコーチをしていた生徒が複数いることに気づきました。そのうち何人かは昇進したことを知っていましたが、その他の生徒には驚かされました。 私にとって、胸がはちきれるほどの誇り高き瞬間でした。私は、生徒たちと関係を築き、彼らの成功のために心の底から尽力してきました。多くの生徒らが成功を収めたことを目の当たりにして、私は大いに驚き、嬉しくなりました。物語はさらに続きます。 Facebookの上
BigqueryStandardSQLの黒魔術ってなに！？記してみました！
この記事は eureka Advent Calendar 2018 15日目の記事です。 こんにちは。BIチーム小林です。 最近はもっぱらFortniteをメインに、スマブラをたまにやっています。 お昼は機械学習周りをメインに、分析をたまにやっています。 最近はガリガリとクエリを書くこともなくなってきたので、備忘録を兼ねて、かつて習得した黒魔術、もといStandardSQLの便利な記法を記しておきます。 ただし、主旨としては、SQLを使ってこんな便利なことができるんだぜ、こんな計算までできちゃうんだぜ、というよりは、こんなん書くのめんどくさいからこう書いちゃおうや、という記事です。 氷魔法 : 定数化TEMP FUNCTION を使って何回か使いそうなものは定数化BigqueryStandardSQLでは、クエリの中に一時的なUDF (ユーザーが定義した関数) を書くことができます。 これ
Web 技術をキャリアの中心にしない
うろ覚えの記憶だが、2013 年に Twitter でこの話題が拡散されていたと思う。Web 業界では誰もが知っていながら誰もが認識しているわけではなかった簡潔な表現に、当時の私は衝撃ではなく、うまいこと言うなと感心していた。 しかし、当時はまだまだ Web 技術は発展途上でありながら先進的なイメージがあったように思う。ソフトウェア開発の未来が Web 技術であることは多くの人は認識していたが、Web はさして大きくないリソース上の制約を設けつつ、さして多様性のないプロトコル上の制約を受けつつ、特定技術に絞れば2年ぐらいやればその分野の詳しい人になれるという、Web 業界以外のソフトウェアエンジニアからみたとき、スキルとしてどこかチャラいイメージがあった。 知人の Linux Kernel 開発者とゲームの話をしていたとき、経験や知識の積み重ねで勝てないゲームは嫌いだという話になって、その
心理的安全性が高くアジャイルな組織設計
心理的安全性の高いチームを作るためにサーバントマネージャーに徹する話などを聞くことがありますが、なんか大変そうだなーと考えてたら、これは組織設計の課題だと思ったわけです。 サーバントマネージャーは過渡期と割り切って、本来の仕事である課題解決に時間を使えるようにしていったほうがいいです。 心理的安全性とは他者の反応に怯えたり羞恥心を感じることなく、自然体の自分を曝け出すことのできる環境や雰囲気のことを指します。 だそうです。失敗するかも…と早めに言えることはアジャイルな組織には必須です。 心理的安全性は1人のメンバーが日常的にコミュニケーションする相手との視座、視野、視点が近いと高くなると仮説を立ててみました。 視座、視野、視点の図 https://tech.drecom.co.jp/viewpoint-of-being-leader/視座が離れてる例：リーダーが超ベテランでメンバーが超若い
海外と日本でのソフトウェア開発職の文化を振り返ってみた – reyabe – Medium
こんにちは。阿部と申します。とある渋谷のIT企業でエンジニアのお仕事をしています。普段はブログを書いていないのですが、お勤め先の社内ブログ用に以前執筆した記事をlean-agile podcastで紹介していただく事になり、当時の記事を今回こちらのプラットフォームでも公開する事にしました。長文になりますが、ご興味を持たれた方は是非ご覧ください。 「海外と日本でのソフトウェア開発職の文化を振り返ってみた」という記事のタイトルにしているのですが、この話のモチベーション・裏付けとしてまず自分のバックグラウンドを簡単に説明しておきます。私は名前によらず外国籍・海外育ちで、今までヨーロッパと日本それぞれでベンチャー・中小企業・大手の仕事環境を６社ほど転々とし、色々な国のエンジニアと仕事をしてきました。 （＊ちなみに、日本語で記事を書くのはあまり得意でないので、言葉遣いがおかしいところは大目に見ていた
Gitpod — Online IDE For GitHub
After over one year of intensive work, we are proud to announce the public Beta of Gitpod. Gitpod is an online IDE which can be launched from any GitHub page. Simply prefix any GitHub-URL with “https://gitpod.io#” or use our browser extension that adds a button to GitHub pages. Within seconds, Gitpod provides you with a fully working development environment, including a VS Code-powered IDE and a c
メルカリの小泉さんと組織の課題について話したら恐ろしい程勉強になった話 – tsukuruba – Medium
僕の中で仕事人生に影響を与え続けてくれている三大COO（と勝手に呼んでる人たち）がいる。 一人目がアカツキ共同創業者COOの香田哲朗くん、二人目がフリークアウト(元)COOで現hey代表の佐藤裕介さん、そしてメルカリ社長兼COOの小泉文明さんだ。 それぞれ社長もできる人だが、COOとして事業及び組織の構築も構造的分析もハイレベルにできる。恐ろしく広域のアビリティを持ち、バイタリティとバランス感覚に優れ、超人的な仕事量をこなす人たちである。 そのうちのお一人であるメルカリ小泉さんと1on1させてもらう機会があり、その話が組織の課題に悩む他の人にもとても有用だと思ったのでメモを公開させていただくことにした。（ほんとにメモなんで乱文ご容赦ください） ツクルバでは組織・文化づくりに社をあげて徹底的に投資していく方針なので、非常に参考になった。 ＊＊＊以下メモ＊＊＊ [お題] メルカリで急激に組織を
ActiveRecordを試すときに便利なやつ - r7kamura - Medium
手元で ActiveRecord を試したいときに、いちいちデータベースを用意したり、再現性のあるコード片に整えたりするのは、結構な手間に感じてしまうかもしれません。この記事では、そういったケースで利用できる知識を幾つかまとめておこうと思います。 以下は今回題材に使うコード例で、これを上から順に説明していきます。 ActiveRecord で .count の挙動を試す例bundler/inlinebundler/inline は Bundler 1.10 から追加された機能です。これを利用すると、Gemfile を独立したファイルとして用意することなく、スクリプトの中にその定義を埋め込めるようになります。 続くスクリプトがどのバージョンの Gem で動かせるのかということを明示でき、必要であればライブラリを実行時に自動的にインストールし、依存関係を調べて $LOAD_PATH を調整し、
真面目な人を本気にさせる方法
先日、他社の開発の方々が、アジャイルに関する相談ということで、弊社にいるアジャイルに詳しい髪の長いおじさんに訪ねてきた。その中で、実感駆動開発の話になって、久しぶりに「本気（マジ）と真面目（マジメ）」の話を聞いた。 この話を聞いてから、人がプロダクトの価値について考えられるようになるにはどうしたらいいのか考えてみた。 TL;TRありきたりな回答だけれど、さっさとリリースして、さっさと使ってもらう。それをできるためのことを、もちろんリスクを下げつつ、できるようにするためのことを頑張ろう。 本気と真面目 人はドキュメントを前にして真面目な態度を取るが、動くソフトウェアを前にして本気になる。端的に言うと、人は仕様書などドキュメントを前にするとそれを徹底的に重箱の隅を突くようなレビュー（真面目）をしてしまうが、本当に欲しかったことに対して考え始める（本気）は実際のプロダクトを前にしてからという話だ
Why you must not ask questions on Github issues
TL;DRAsking questions on issue tracker may be a DoS attack to developers. Use user forum for discussion, if it exists. BackgroundBefore the Github era, many OSS projects had issue trackers and forums (BBS or ML). Users discuss on forum and report bugs to issue tracker. Issue tracker was place for issue tracking. When a user asks a question on the forum, other users helped them. It breeds “user com
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
OKRをチームで運用してみての学び
