PdM/EMが気づくべき「技術負債」の異変
技術負債が溜まっている勘所について。現場のエンジニアは実際のシステムを触っているので変更や追加をする過程で当事者になるのでおおよそ異変に気づく。 一方、実際にそのシステムに対となるプロダクトに関わっているのはエンジニアだけではない。PdMやEM、事業責任者がいる中でこのメンバーにどう常に変化し続けるシステムアーキテクチャの異変に気づいてもらうのか、自ら気づかせるのかは至難の業である。 とはいえ、つばり一番わかり易いのは工数の予測精度の幅がある。 以下の3つのフェーズがあったときにそれぞれのズレが大きい場合は負債が溜まっていることが多い。（特に、1.と3.） 一般的な視点と現場システムへの理解度のズレ詳細から開発手前での予測のズレ予測工数と実績工数のズレここでいう工数予測がズレるのはエンジニアリングスキルの問題ではなく、システムに関する理解度の認知問題によってズレるケースが該当する 1.一般
How an empty S3 bucket can make your AWS bill explode
Update AWS started investigating the issue: https://twitter.com/jeffbarr/status/1785386554372042890 Imagine you create an empty, private AWS S3 bucket in a region of your preference. What will your AWS bill be the next morning? A few weeks ago, I began working on a PoC of a document indexing system for my client. I created a single S3 bucket in the eu-west-1 region and uploaded some files there fo
The beginning of the end for Terraform?
Source:imgflip.comAs I write this on the 25th of April, I am still reeling from the announcement of IBM’s acquisition of Hashicorp. When I first heard the rumours yesterday, I was concerned about the future of possibly my favourite Infrastructure-as-code (IaC) tool. It has long been obvious that Hashicorp has been struggling to make money, making a $274 million loss in 2023. This undoubtedly led t
これからはじめる 実践SRE / SLO の監視をやってみよう
SRE がアツいですね。 昨年は以前に増して SRE 関連のイベントも増え、SRE 人材への注目も更に高まっていると感じた 1 年でした。私も Google Cloud の Customer Engineer として、お客様へ SRE のお話をする機会が増えてきています。 ご存知の通り、SRE は Google から生まれた運用プラクティス、またはそのロール自体を指す言葉です。 詳細は無料で読むことができる書籍を御覧ください。 “Site Reliability Engineering” 及び “The Site Reliability Workbook” （右上の右2つ）は HTML 形式 なので、Google Chrome で右クリックして 翻訳を選択するという簡単な手順で日本語でも読むことができます。（書籍がよい方は日本語版も購入できます。） 今回のテーマは SLO (Service
踏み台EC2を廃止してSession Manager接続に置き換えました
こんにちは、エウレカ SRE チームの原田です。 今年 (2021年) エウレカでは、公開鍵認証で接続するEC2の踏み台サーバを廃止し、代わりに各サーバへの接続をIAMで認証できるSSM Session Managerへのリプレースを行いました。本記事ではそのモチベーションや、実装のポイントを紹介していきたいと思います。 旧来の踏み台サーバ 旧来の踏み台サーバエウレカで長く運用されていた踏み台サーバ (Gateway) は以下のようなものでした。 各開発者は、自分の秘密鍵を使って踏み台サーバへSSHを行う ( 踏み台サーバ上には各開発者の個別ユーザーおよび公開鍵が登録されている )踏み台上では、接続が許可されているSSH対象のサーバの秘密鍵がユーザー毎に配置されており、その鍵で各サーバにSSHするMySQL / Elasticsearch / Redis など、Private Subnet
JWM: a new standard for secure messaging
Messaging technologies have exploded in popularity in recent years. The broad usage of messaging as a framework, especially in distributed systems, requires a dedicated and standardized approach to security. One possible solution to the problem of standards-based secure messaging is to build on top of a family of pre-existing security technologies known as JOSE. JSON Web Message (JWM) is a draft s
Flutterの状態管理手法の選定
Photo by Daniel Pelaez Duque on UnsplashFlutterの状態管理周りの手法はちょくちょく動きがあって、それに関する話題が度々盛り上がっている気がします。 今の自分は以下を組み合わせて使っていて、満足しています。 Riverpod (新Provider)StateNotifier (Better ValueNotifier)freezed (immutableなクラスの扱いなどを楽にするコード生成器)どうしてこの組み合わせを好んでいるのか、以下述べていきます(コード例などはリンク先で充分かなと思うものが多かったので少なめです)。 Riverpod (新Provider)そもそもProviderとはProvider自体、決して古いものではなく、2018年末に登場し、2019年初めにFlutterチームとのやり取りを経て認められ、Google I/O 20
Generating UUIDs at scale on the Web
TL;DR can you trust every browser to generate globally unique identifiers at scale? At Teads, we have tried, and the answer is yes, with a few caveats. This article describes the experiments we’ve run and the discoveries we made along the way. Why we need client-side unique identifiersGenerating unique identifiers is a common need that third-party scripts integrated on Web pages and e-commerce sit
プログラマーテストの原則 by Kent Beck
チョコレート対バニラTDD対BDD。このテストツール対あのテストツール。テストビフォー対テストアフター対これは動くから俺を信じろ。ある時期から、こうした詳細に関する議論には飽きてしまった。もっと原則について議論したい。 詳細に関する議論はなかなか結論に至らずに、話が行ったり来たりする。チョコレート対バニラ。チョコレート。バニラ。チョコレート。バニラ。 詳細の議論に負けを認めさせられるようなことがあっても、その譲歩は絶対的なものではない。私の状況がチョコレートを勧めているのに、私にバニラを食べさせてくれと言えるだろうか？ これでは埒が明かない。 原則一方、原則は議論を生み出す基盤になる。原則には賛成しても状況が違っているのなら、答えは違ってくるかもしれないが、そこで論争になることはない。原則が、異なる状況における異なる答えを生み出したのである。 詳細で論争するよりも、原則で論争したほうが生産
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
エンジニアのコーチング by Kent Beck
以下は、Kent Beckによる「Coaching Engineers」の翻訳です。本人の許可を得て掲載します。tl;dr 有償でエンジニアのコーチをします。詳細と待ち時間についてはお問い合わせください。 物語の結末2018年2月にFacebookを退職する直前に、トップ1%のエンジニア（現在および過去にレベルE7以上だったエンジニア）のオフサイトミーティングに参加しました。海辺のリゾートでバスを降りると、私がコーチをしていた生徒が複数いることに気づきました。そのうち何人かは昇進したことを知っていましたが、その他の生徒には驚かされました。 私にとって、胸がはちきれるほどの誇り高き瞬間でした。私は、生徒たちと関係を築き、彼らの成功のために心の底から尽力してきました。多くの生徒らが成功を収めたことを目の当たりにして、私は大いに驚き、嬉しくなりました。物語はさらに続きます。 Facebookの上
呪い: 見積もりの3倍だけ常にかかってしまう
みなさん、進捗どうでしょう？最高ですか？そんなことないよね！なぜならあなた達は呪われている。事前の計画よりも、常に、3倍の期間が必要になる。常にだ！！この呪いは強力であり、解放されるのは難しい。我々はどうすればよいだろうか？ パーキンソンの呪いある資源に対する需要は、その資源が入手可能な量まで膨張する パーキンソンの法則 — Wikipedia ある仕事の作業量を見積もったとしよう。機能Aの追加に2週間程度必要そうだ、とする。順調にいけば、再来週には動き出し、価値が出せそうだ。ペースを作り、粛々と仕事を進めていこう。 ところが、現実的にはそんなに上手くはいかない。新しく導入するライブラリがうまく動かないとか、くだらないtypoに悩まされて半日失ったとか、既存コードの改修箇所が想像してたより多かったとか、何らかの別の仕事をやらなければいけなかったり、もしくは休暇が必要だったりとか。当初計画よ
G Suite x Zendesk API で問い合わせの分析・可視化ツールを作ってみた
システムの全体像はじめにZendesk はヘルプページを作ったりユーザーからの問い合わせにメールやチャットベースで答えられるカスタマーサポートのためのサービスです。 弊社では Zendesk を利用しており、サービス改善のために問い合わせの内容を閲覧・分析しています。カスタマーサポートを業務で行わないが、プロダクト改善をしたい社内メンバー向けに、Zendesk API をたたいて可視化・分析する仕組みを G Suite で作ってみました。 Zendesk に限らず、外部サービスで API が用意されているものでしたら同様に可視化・分析の仕組みを作れるので参考にしてみてください。 できたものダッシュボードWeekly と Monthly の問い合わせ件数を Data Studio で可視化しています。問い合わせのタグや文言で絞り込みができます。 DataStudio によるダッシュボード問い
Google Apps Script は何が強くてどんなときに使うべきかプラクティスをまとめてみた
はじめにGoogle Apps Script は無料で色んなことが実現できるため、ついつい「全て GAS でやっちゃおう」みたいな話になりがちです。Google Apps Script も万能ではないので、強み・弱みを理解した上で他の選択肢と比較して使うのをお勧めします。 Google Apps Script のプロジェクトを 2–30 個作ってきた中で、自分なりのプラクティスをまとめてみます。 この内容は Cloud Next ’18 in Tokyo で登壇したときの内容を含んでいます。この登壇から半年以上経ったのでアップデート部分も以下にまとめています。 Google Apps Script の強み・弱みまず、強みと弱みについてまとめてみます。 強み 1. Google Apps の API を簡単に呼び出すことができる一番の強みはこれだと思います。Google Apps Scrip
技術力評価会のこと
VOYAGE GROUPでは技術力評価会という制度でエンジニアの技術力を評価している。そのやり方を紹介しつつ、よくあるトラブル、そしてそこに込められた想い…。我々はどこに行こうとしているのか。その全貌が明らかになる。 （この文書は エンジニアのマネージメントで悩んでいる人が集まる会 #3 での発表資料をもとに加筆・修正しています） 技術力評価会の実装VOYAGE GROUPでのエンジニア職評価は4グレード制を採用しており、グレード1, 2の人が評価対象者、グレード2,3,4の人が評価者となる。つまり、グレード2の人は評価される方もやるし、評価する方もやることになる。 人事評価は「能力」「実績」「CCFB」で決定されるということになっている。ここでいう「能力」について評価しようっていうのが技術力評価会の領域というわけだ。つまり、人事評価制度のすべてではないし、ここだけで給料が決まるわけでもな
Web 技術をキャリアの中心にしない
うろ覚えの記憶だが、2013 年に Twitter でこの話題が拡散されていたと思う。Web 業界では誰もが知っていながら誰もが認識しているわけではなかった簡潔な表現に、当時の私は衝撃ではなく、うまいこと言うなと感心していた。 しかし、当時はまだまだ Web 技術は発展途上でありながら先進的なイメージがあったように思う。ソフトウェア開発の未来が Web 技術であることは多くの人は認識していたが、Web はさして大きくないリソース上の制約を設けつつ、さして多様性のないプロトコル上の制約を受けつつ、特定技術に絞れば2年ぐらいやればその分野の詳しい人になれるという、Web 業界以外のソフトウェアエンジニアからみたとき、スキルとしてどこかチャラいイメージがあった。 知人の Linux Kernel 開発者とゲームの話をしていたとき、経験や知識の積み重ねで勝てないゲームは嫌いだという話になって、その
Hummingbird: Building Flutter for the Web – Yegor Jbanov – Medium
At Flutter Live today, we announced that we are experimenting with running Flutter on the Web. In this post, we describe how we are approaching the challenge, and the current state of the technology. At the end of the post you will find answers to questions about interop and embedding. Let’s begin with a quick refresher of Flutter’s architecture. Flutter is a multi-layered system, such that higher
プロダクトマネージャーは、自分達が「頭がいい」ことを理解しなければならない – Teruhisa Fukumoto – Medium
みなさんこんにちは。 チャットボット開発のスタートアップでプロダクトマネージャー（以下PM）兼エンジニアをやっている福本です。 先週11月6日~7日にかけて、プロダクトマネージャーカンファレンス2018(pmconfjp)が行われましたね。僕も参加してきましたが、「PMという職種が市民権を得てきている」というのが、当日の盛況ぶりから伝わってきました。 さて、今回はカンファレンスで色々な方と接して改めて感じた「PM」という人種について(偉そうに)語っていきたいと思います。例によって、この記事は僕の妄想に基づいた怪文書となっています。 「頭がいい」とは今回もタイトルを刺激的にしてみたわけですが、僕はPMの地位を不当に上げるために「頭がいい」という表現を使ったわけではありません。ましてや、PM上げをすることで遠回しに「オレは頭がいいぞ」という主張がしたいわけでもありません。 僕はPMの「頭の良さ
PMFを狙うスタートアップの開発戦略 – SOELU Developers – Medium
最短でサービスをローンチするサービスが世に出ない限り、検証は何も始まりません。最短でサービスをローンチするための技術選定を行う必要があります。 技術的な冒険はしない重要なのは『チームをリードできる技術を使うこと』であると考えています。最も自分が精通している技術で、メンバーが躓くことなく一直線に開発できるようサポートする必要があります。私の場合、最も手に馴染んだ言語がRubyであったため、Rubyを選択しました。 コードを書かないことに勝る手段はないまた、『いかにしてコードを書かずに済ますか』という観点も重要です。成熟したフルスタックフレームワークを使用することで、自分たちで書くコード量は圧倒的に短縮できます。私たちの場合、Ruby on Railsを使うことで多くの処理をGemに丸投げし、管理画面はRailsAdminを使用することで開発時間を圧縮しました。Railsはもちろん銀の弾丸では
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flutterの効率良い学び方
