PdM/EMが気づくべき「技術負債」の異変〜予測精度の幅で捉える〜
技術負債が溜まっている勘所について。現場のエンジニアは実際のシステムを触っているので変更や追加をする過程で当事者になるのでおおよそ異変に気づく。 一方、実際にそのシステムに対となるプロダクトに関わっているのはエンジニアだけではない。PdMやEM、事業責任者がいる中でこのメンバーにどう常に変化し続けるシステムアーキテクチャの異変に気づいてもらうのか、自ら気づかせるのかは至難の業である。 技術負債とは、現場のエンジニアが感じる理想と現実との乖離のことでリファクタリングやリプレイスはそれを少しでも差分を埋めることである。（その差分を本当に埋めることができるかはエンジニアのスキルとシステムの複雑性による） そうなったときに、どこに一番その予兆ができるかというと一番わかり易いのは工数の予測精度の幅があると仮定する。 以下の3つのフェーズがあったときにそれぞれのズレが大きい場合は負債が溜まっていること
エンジニアリングマネージャーになって1年がたった
私は，あるスタートアップ企業でエンジニアリングマネージャー（の，1人）をしている。toB向けSaaSを提供している数百名規模の会社で，社名が少しずつ世の中に知られるようになってきたくらいのフェーズ。会社からはDirectorという肩書をもらっていて，トラディショナルな日本企業だといわゆる部門長の層にあたる。中間管理職の中では上のほうで，執行役員の下あたり，というと伝わりやすいだろうか。 様々な事情（会社が大きくなった，比較的社歴が長い，そこそこの業界経験値がある，自分の専門領域(*1)に社内のフォーカスがあたるようになり，チームをスケールする必要が出てきた，etc.）から，半ば必要にかられて，重い腰を上げてエンジニアリングマネージャーとして活動を始めたのがちょうど1年ほど前。 決してマネージャーとして早咲きのほうではなく，IT業界でのキャリアは15年くらいで，これまではずっとプレイヤー，ま
Bit-for-bit reproducible builds with Dockerfile
At FOSDEM last month, I talked about the current status of bit-for-bit reproducible builds with Dockerfile: Presentation slides at FOSDEM 2023 (PDF)What are reproducible builds?Reproducible builds is a practice to guarantee that identical binaries can be built from its source by anybody at anytime. Slide 2Reproducible builds are helpful for security assessment of binary releases. If binary release
Rustが遅すぎる？プロファイリングで性能向上！
「開発プロセスにプロファイリングを組み込むのはどうだろう？」 ミーティングで、プロファイリングの重要性を発言するだけで、みんながあなたの深い知見、意識の高さに驚くことでしょう。もちろん、あなたは、プロファイリングのやり方を知っている必要はありません。開発の終盤に、性能目標が達成されず、解析が実施される頃には、誰もあなたの発言は覚えていません。しかし、万が一、あなたの意見が採用されても困らないように、この記事を参考にしてください。 Goは、CPU、メモリ、block、mutexなど、使いこなせないほどの種類をサポートするプロファイリングツールpprofを標準機能として提供します。一方、Rustは、そんな機能を提供しません。Rustへの愛が揺らぐかもしれませんが、Rustへの愛は、見返りを求めない純愛です。愛の見返りに何かが与えられると期待してはいけません。 Rustでもpprofあなたは、す
踏み台EC2を廃止してSession Manager接続に置き換えました
こんにちは、エウレカ SRE チームの原田です。 今年 (2021年) エウレカでは、公開鍵認証で接続するEC2の踏み台サーバを廃止し、代わりに各サーバへの接続をIAMで認証できるSSM Session Managerへのリプレースを行いました。本記事ではそのモチベーションや、実装のポイントを紹介していきたいと思います。 旧来の踏み台サーバ 旧来の踏み台サーバエウレカで長く運用されていた踏み台サーバ (Gateway) は以下のようなものでした。 各開発者は、自分の秘密鍵を使って踏み台サーバへSSHを行う ( 踏み台サーバ上には各開発者の個別ユーザーおよび公開鍵が登録されている )踏み台上では、接続が許可されているSSH対象のサーバの秘密鍵がユーザー毎に配置されており、その鍵で各サーバにSSHするMySQL / Elasticsearch / Redis など、Private Subnet
エウレカのデータ組織運営の1年間
はじめにこんにちは、@pacocat です！この記事は「eureka Advent Calendar 2020」15日目の記事です。 気づけばエウレカに入社して1年が経ちました。入社後はデータアナリストとして活動していましたが、今年の3月からはData Directorとして、AIを含むデータ部門を統括する立場として、組織づくりや戦略推進を行っています。 もともとエウレカに入社したきっかけは、過去にデータアナリスト→AIプロジェクトリーダーとキャリアを積んでいく中で、プレイヤーとしてだけでなく、チームや組織としてデータ活用のあるべき姿を考えたいという気持が高まったことにあります。今は毎日優秀なメンバーに支えられながら、成長痛を感じつつ新しいチャレンジを楽しめています。 この記事では、普段私がどのような観点でデータ組織を運営しているか、をまとめていこうと思います。データチームはこの1年だけで
DeNAがデータプラットフォームで直面した課題と克服の取り組み
はじめにこんにちは。この記事はDeNAの小口（Rikiya Oguchi）と長谷川（Ryoji Hasegawa）がお届けします。 小口はゲーム事業部の分析部データエンジニアリンググループの所属で、長谷川は全社共通部門である分析推進部の所属です。ゲーム事業部と全社部門で所属は違いますが、近しいミッションのもと、普段から密に連携して仕事をしています。 DeNAでは現在、データプラットフォームの刷新を進めています。この記事では、そのプロジェクトについて、以下の流れでご紹介します。 現行データプラットフォームの背景と概要データプラットフォーム構築後の環境変化現行データプラットフォームが抱える課題現行組織が抱える課題データプラットフォームの刷新刷新後のシステム構成組織体制の刷新我々と同じようにデータプラットフォームの構築・運用に携わっている方々や、データプラットフォームを利用されている方々、特に、
「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」を１年掛けて整理した
こんにちわ。rwle1212です。 本記事は JAWS Days 2020 で話す予定でしたが、昨今の事情によりオンライン開催となったため、登壇予定の内容を記事にしたものになります。 登壇していれば諸般の事情により左手首を骨折したネタが使えたのですが、ブログでは伝わらないので非常に残念な思いをしております。という話はどうでも良いので本題に入ります。 50分の登壇内容なので少々長くなりますが、お付き合いください。 JAWS Days 2019で登壇した内容の振り返り昨年の JAWS Days 2019 で「Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する」という内容で登壇しました。 まずは上のリンクに添付されているスライドを5分位で読めると思うので一読頂いて、下の文に進んで頂ければと思います。 そもそもInfrastructure as Cod
Spotifyの目指すHigh Alignment High Autonomy文化が面白い
Spotifyのエンジニアカルチャーというビデオで、Spotifyではどういうエンジニアリングをしているのかが説明されている。その中で、面白い概念がある。Alignment と Autonomyに関してだ。 Alignmentとは、いろいろなものを一つの考えのもとに一致させていくことだと言える。Autonomyとは自律的に動いていくことだ。この両者、相反する考えのようにも思われるが、そうでもない。その二つを軸に4象限に分けることができる。以下がSpotifyの例で出てくる図だ。 Alignment and Autonomy (From Spotify)Low Alignment Low Autonomy: この状態は、マイクロマネジメント文化だ。大きなビジョン、目的は見えず、あれをやれ、これをやれ、と指示されるだけの状態。 High Alignment Low Autonomy: この状態
GraphQL Resolvers: Best Practices
From graphql.orgThis post is the first part of a series of best practices and observations we have made while building GraphQL APIs at PayPal. In upcoming posts, we’ll share our thoughts on: schema design, error handling, production visibility, optimizing client-side integrations and tooling for teams. You might have seen our previous post “GraphQL: A success story for PayPal Checkout” about PayPa
バッチ処理のスケジューリングパターン
この記事はこの記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 12日目の記事です。 はじめにGoogle Cloud Platform (GCP) でバッチ処理を起動するための以下のパターンについてご紹介したいと思います。以下、８パターンあげてみました。とはいえ、最後の3つは GCP のバッチスケジューリングという観点からは少し外れますが、バッチの起動時に使われるということでご容赦を。 Cloud Scheduler : フルマネージドな cron ジョブスケジューラです。フルマネージドという点が非常に大きなメリットであり、多くの処理を自動化し実行することが可能です。Google App Engine cron サービス : HTTP GET を利用して、特定の URLを呼び出します。Google AppEng
Flutter はじめの一歩
本記事は、このPublicationの中でも特に初学者向けに書かれています。主なターゲット層は以下のような方です。 JavaScript・PHPなどとっつきやすいWeb系の言語は見よう見まねで触ったことがあるがきちんとは理解できてはいない(プログラムを1行も書いたこと無いレベルの場合はFlutterの前にまず何かとても簡単な入門書をまず一冊挟んだ方が良いです)Flutterを触り立て(環境構築は済んでいる)以前、以下の呟きをしましたが、例えばデザイナー本業の方がFlutterも活用できるようになると幅が広がると思い、また公式ドキュメントにもその旨が書かれていました。 とはいえ、元々バリバリコードを書けてしまうようなごく一部のデザイナーを除いて、やはりFlutterを使いこなせるようになるには(UIレイアウト周りに絞ったとしても)けっこう障壁が高いとは思うので、本記事がその補助となれば幸いで
本番環境のマルチテナント Kubernetes クラスタへの Istio 導入
これは Mercari Bold Challenge Month の3番目の記事です。 Mercari ではモノリスなサービスからマイクロサービスのアーキテクチャへと移行を行っている間、長期的な観点からみて、サービスメッシュの導入とその重要性を理解することが必要だと感じていました。ほとんどのインシデントレポートに対する現実的な対策としてあがるのが、レートリミットの導入、適切なカナリアリリースのフローの導入、適切なネットワークポリシーの導入などでした。そしてこれらこそがサービスメッシュによってもたらされる機能です。 前四半期では、私達はついに Istio の導入に挑戦することに決め、調査を開始しました。結果として、100 以上のマイクロサービスをホストするマルチテナント環境のシングル Kubernetes クラスタを深刻な障害を発生させずに本番運用を行うことができています。この記事では Me
【2019年版】UIとUXデザイントレンド - baby-degu - Medium
Scenery Illustration by J.HUAこちらの記事は、2018年12月に公開された『 2019 UI and UX Design Trends 』の和訳になります。 はじめに私たちは去年、モバイルUIデザインのトレンドについての予測をまとめました。今年はモバイルだけを対象とせずに、さらに深く掘り下げていきます。 モダンなデザインの一番のトレンドは前後関係のあるつながりの中にあります。そのため、一般化することができません。 この記事を読むことであらゆるツール、技術の進歩、またユーザー向けのプロダクトが実際にどのように機能なのか開発者が理解し、全てが上手くいくように感じるでしょう。 近いうちに、販売だけでなく、生産するものすべてを網羅するユニバーサルデザインの考え方を発展させて行くでしょう。自分で何か物事を行うためには、より良いデザインの選択が必要です。 国家としての印象さ
マイクロサービスで管理画面が乱立する問題と対策
こんにちは、qsona (twitter) です。 マイクロサービスアーキテクチャを指向するとき、(主に社内向け)管理画面をそのままサービスごとに作っていくと、マイクロサービスの数だけ管理画面が乱立するという課題があります。FiNC においては、それにより実際に以下のような問題が発生しました。 ユーザの追加/削除や権限管理がとても大変ユーザ(CS対応者)がどこの管理画面を使えばわかりにくい本記事では、 FiNC においてこれらの問題に対してどう対処してきたか、歴史とともに紹介します。 tl;dr各マイクロサービスで管理画面を作ること自体はよい。統一管理画面は開発のコストがかかりワークしなかった認証を中央管理にする権限管理は各サービス固有のドメイン知識だが、中央で一覧/変更できる状態になっていると便利マイクロサービスの横断的関心事への対処は、「標準」を意識する黎明期から、問題が起こるまでFi
エンジニアのコーチング by Kent Beck
以下は、Kent Beckによる「Coaching Engineers」の翻訳です。本人の許可を得て掲載します。tl;dr 有償でエンジニアのコーチをします。詳細と待ち時間についてはお問い合わせください。 物語の結末2018年2月にFacebookを退職する直前に、トップ1%のエンジニア（現在および過去にレベルE7以上だったエンジニア）のオフサイトミーティングに参加しました。海辺のリゾートでバスを降りると、私がコーチをしていた生徒が複数いることに気づきました。そのうち何人かは昇進したことを知っていましたが、その他の生徒には驚かされました。 私にとって、胸がはちきれるほどの誇り高き瞬間でした。私は、生徒たちと関係を築き、彼らの成功のために心の底から尽力してきました。多くの生徒らが成功を収めたことを目の当たりにして、私は大いに驚き、嬉しくなりました。物語はさらに続きます。 Facebookの上
GAE 2nd-gen でのサービス間認証
TL;DRGAE 2nd-gen では X-Appengine-Inbound-Appid ヘッダの代わりに、ID Token + Identity-Aware Proxy を使った方式をサービス間認証に使えます。 はじめにGAE でマイクロサービスを構成する場合、各サービス同士を呼び合うときに同一 GAE アプリからのリクエストであるかを確認したい場面があります。シンプルな例だと、サービスがフロントエンドとバックエンドに別れていて、バックエンドはフロントエンドからしか呼び出せないようにしたい場合です。 GAE 1st-gen では X-Appengine-Inbound-Appid ヘッダという魔法のヘッダがありました。このヘッダは URLFetch を使用して別の GAE サービスにアクセスする時に、GCP が自動で呼び出し元の Project ID を入れてくれるヘッダです。そのため
G Suite x Zendesk API で問い合わせの分析・可視化ツールを作ってみた
システムの全体像はじめにZendesk はヘルプページを作ったりユーザーからの問い合わせにメールやチャットベースで答えられるカスタマーサポートのためのサービスです。 弊社では Zendesk を利用しており、サービス改善のために問い合わせの内容を閲覧・分析しています。カスタマーサポートを業務で行わないが、プロダクト改善をしたい社内メンバー向けに、Zendesk API をたたいて可視化・分析する仕組みを G Suite で作ってみました。 Zendesk に限らず、外部サービスで API が用意されているものでしたら同様に可視化・分析の仕組みを作れるので参考にしてみてください。 できたものダッシュボードWeekly と Monthly の問い合わせ件数を Data Studio で可視化しています。問い合わせのタグや文言で絞り込みができます。 DataStudio によるダッシュボード問い
データ指向アプリケーションデザイン
AmazonでMartin Kleppmann, 斉藤 太郎, 玉川 竜司のデータ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理。アマゾンならポイント還元本が多数。Martin Kleppmann… 手軽に扱えるデータの量や種類が増える一方、CPUの性能はムーアの法則通りには成長しなくなり、大規模データ処理では、多数のマシンを活用する分散処理が欠かせなくなってきました。クラウドの普及とともに多数のマシンを自ら調達せずとも分散システムを構築できるようにもなっています。 しかし驚くべきことに、今までこの分野に入門するための定番の書籍がありませんでした。分散処理にデータ処理が加わる融合分野である上、オープンソースプロジェクトの進化も速く、専門家同士でも共通の理解を構築するのが非常に難しかった分野です。この本を上手に使うと、既存のOSSプロジェクトの位置付けや、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flutter Interact キーノート 発表内容のまとめ
