pospome @pospome Twitter profile

Last Seen Profiles

@rino_kr

@jandakembangstw

@HbtrshM15212

@foulplay

@hotpluscinema

@taripasutri

@naylooevs

@erikhayser

@Welito_Betto

@dymension

@MikeLew4

@bingcheong39510

@tech3000algo

@DiscoverCrypto_

@RugbyWath

@KourtniO76269

@penyukastw21

@katheryn79020

@RodrigoS14125

@theAnjelGrace

@kosnicaa

@Blossom_SSBU

@TehranTri32114

@JacquilynL63902

@stw_pdg

@ShatoriaJo96292

@lopeexhib

@AjakakukeKUA

@Ur_Pal_Val5150

@jexpeditious91

@W72MZh01dhGNOIP

@JodieMogel5316

@ZDNET

@a_SARCASM

@Bonniedeadbodie

@MolBiolAU

pospome

@pospome

2 years

新卒が入ってくる季節になると毎回「エンジニアとして成長できる環境ってどーゆーものだろう?」って考えるけど、結局 "強いエンジニアと一緒に働く" って以外ないと思うんだよな。"どこで働くか" よりも "誰と働くか" が重要になる。特にジュニアなエンジニアだとここで成長に差が出ると思う。

7

290

2K

pospome

@pospome

2 years

自分は「強いエンジニアさえ集めれば開発は上手くいく」と思ったけど、全然そんなことないと最近感じる。いるに越したことないけど、開発体制や組織体制が良くないと開発は上手くいかない。難しいなーと感じる。もうなんかスポーツみたいだな。ワールドクラスのFWを11人集めても勝てない的な。

7

238

1K

pospome

@pospome

1 year

自分はDMMでアーキテクトをしているんだけど「最終的には全部お金で説明できるようにしないとダメだな」と思うようになってきた。エンジニアのときって「10人日でこの機能を作ります」みたいな考えだったんだけど、経営層が本当に欲しいのは「いくら投資して、いくら利益が出るか」なんだよな（多分

1

207

1K

pospome

@pospome

1 year

エンジニアに「暇な時にやっておきます」って言われると、暇な時なんてないだろって思うかもしれないけど、これは「なんかメインタスクやる気でないから、これでもやるか」みたいなリフレッシュ用タスクなんだと考えると、問題ないかなと思ってしまう（自分もそーゆーことするので）。

4

268

1K

pospome

@pospome

2 years

なんだかんだでこーゆー実装パターンの王道みたいなものを知っていて、それを実コードで適切に利用できるエンジニアが強いなーと思う。言語とか実装対象によっては利用機会が少ないものとかあるけど。

7 Must Know Software Design Patterns

A Dive Into These Patterns With Examples in .NET

levelup.gitconnected.com

0

102

884

pospome

@pospome

2 years

業務で手を動かさなくなると、自分で技術を深堀りすることができないので、大体チームメンバーに任せることになるんだけど、それによって"自分が目指したい世界"を実現するためにどういった技術を使えば良いのかっていう部分の精度が落ちるという経験をしている。

1

146

766

pospome

@pospome

3 years

副業の技術支援では毎回以下の3つはどっかのタイミングで言ってる気がする。 1. マイクロサービスはやめたほうがいい 2. k8s はやめたほうがいい 3. 非同期はやめたほうがいい支援先に依存する部分はあるけど、これ全部が本当に必要なケースはそうそうない。

1

130

734

pospome

@pospome

5 years

自分は今すぐにでもメルペイ辞めたいと思ってるので、楽しい人と楽しくない人で会社として総合的にバランス取れててバチ当たらないと思う。

takeo🐈

@takeotokyo

5 years

こんなに仕事楽しくてバチが当たらないのだろうか

0

5

63

2

125

633

pospome

@pospome

2 years

いいまとめ。Design Docを書くかどうかの判断は結構難しくて、開発作業に入ってから「これ意外と複雑だからDesign Docあった方がよかったな」と思うことがたまにある。で、そーゆーときは大体スケジュールが遅延しているっていう。

GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita

概要Design Documentと聞くと何を想像しますか？一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。設計書、簡単に説明するのであればソフトウ…

qiita.com

0

66

584

pospome

@pospome

1 year

これいいスライドだな。意外となんとかなるんだよなー。

30点で打席に立つ

めもりーさんと語るFindy Engineer Lab オフ会＠東京 LT https://findy.connpass.com/event/294069/

speakerdeck.com

0

89

574

pospome

@pospome

2 years

RDBで性能限界に当たると、まあこーするしかないよなーっていう典型的な例。

ZOZOTOWN のショッピングカート移行プロジェクトを支えた Amazon DynamoDB | Amazon Web Services

このブログでは、リレーショナルデータベース管理システム (RDBMS) のパフォーマンスの問題があった e コ […]

aws.amazon.com

0

75

568

pospome

@pospome

2 years

自分が求めるテックリードは技術領域をリードするエンジニアなので「チームの成果物レビューに時間を割くので手を動かして開発できません」みたいな状況を可能な限り回避したいと思っている。技術領域をリードするためには、技術の詳細を理解する必要があるので、手を動かす必要があると思うんだよね。

1

56

541

pospome

@pospome

3 years

よくよく考えると、プログラミングも同じで、将来的に発生しうる要件��盛り込んだ実装や設計は読み手に意図が伝わらず、結果的に可読性を下げたり、実装の保守に工数がかかる可能性がある。現状に最適化して、必要に応じて書き換えるという実装サイクルを素早く回した方が良いコードになるんだよな。

3

106

516

pospome

@pospome

2 years

チームの新卒が「大きめのOSSのソースコードの読み方を知りたい」って言ってたので、チームメンバーを集めて "コードの読み方共有会" みたいなのを30minやったんだけど、体験としてよかった。結局色々試行錯誤して該当箇所を探し当てる必要があるんだけど、最初の一歩は踏み出しやすくなればいいなー。

1

58

486

pospome

@pospome

11 months

HTTP2すらよく分かってないのに3が来るのか・・・。資料はとてもわかりやすかったです。

フロントエンドエンジニアも知っておきたい HTTP/3 で変わること

フロントエンドカンファレンス沖縄 2023 の登壇資料です

speakerdeck.com

0

56

466

pospome

@pospome

2 years

モノリス→マイクロサービス→モジュラモノリスに移行したという話。マイクロサービスの問題に気づいてモジュラモノリスに舵を切ったというのは良いことだなーと思う。

モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組み｜ハイクラス転職・求人情報サイト AMBI（アンビ）

モジュラモノリスに移行する理由 ─ マイクロサービスの自律性とモノリスの一貫性を両立させるアソビューの取り組みページです。AMBI（アンビ）は若手ハイキャリア向け転職サイト。年収500万円以上の案件が多数。職務経歴書を元にした三段階評価によって、選考通過の可能性がわかる。新規事業や外資系企業へのチャレンジも。

en-ambi.com

1

62

463

pospome

@pospome

10 months

Netflixの開発者生産性について。規模感がすごい。

Developer Productivity Engineering at Netflix

Not every team can be a Netflix, but learning about how they do developer productivity engineering may help your team anyway.

thenewstack.io

0

41

448

pospome

@pospome

8 months

すごい面白い記事だった。自分のチームは完全にレベル1だわ。しかも、レベル3が無駄だと思って結果的にレベル1に行き着いたんだけど、そこも記事中で言及されていた。

2

54

429

pospome

@pospome

8 months

DMMのお話。すごいキラキラした話に見えるけど、エンジニア全員に工数入力してもらったり、数値が意図した形で現れなかったり、ものすごく試行錯誤した結果、こうなっていると思うので、地道な頑張りは必須。

開発生産性の現在地点～エンジニアリングが及ぼす多角的視点 / Current status of development productivity

2024/2/15 Developers Summit 2024 登壇資料 https://event.shoeisha.jp/devsumi/20240215

speakerdeck.com

0

41

428

pospome

@pospome

1 year

すごい参考になった。

(翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book

本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏では…

t2y.hatenablog.jp

1

52

423

pospome

@pospome

3 years

なんかエンジニアって新しいマイクロサービス作るの好きだよね。どんどん増えていって失敗するパターンは意外と珍しくないと思う。マイクロサービスを新規作成する理由も具体的なメリデメを考えず、単に "責務が違うから" っていう抽象的なものであることが多かったりする。

3

47

409

pospome

@pospome

2 years

CTOって自社の技術領域において「何にどの程度投資するのか」を判断する経営者なので、経営のことはもちろんだけどエンジニアリングのことも分かってないといけない気がしていて、相当能力高くないと務まらない気がするんだよな。

3

37

404

pospome

@pospome

2 years

マイクロソフトの調査に比べると全然レベルの低い話になるけど、DMMプラットフォームでも開発スピードを可視化する取り組みが走っていて、たまたま開発スピードが悪そうなチームがあったのでそのチームと他チームとで"PRがmergeされるまでの時間"を比較した。

1

63

387

pospome

@pospome

1 year

なんだかんだでk8sを2年以上運用してきたんだけど、最初は運用コストが低くて「k8sの運用そんな大変じゃないな」って思ってたんだけど、載ってくるワークロードの数が増えて、各種オペレータを導入しだしてから運用コストが爆発的に上がった気する。

3

59

373

pospome

@pospome

2 years

ソフトウェア開発ってどーしても実際にやってみないと分からない部分（問題に気づけない部分）があるので、問題が発生する前提で"とりあえず作ってみて、ダメだったら改善する"っていうサイクルをいかに早く回すかが重要なんだよね。失敗によって知見を得られてエンジニアもレベルアップするし。

1

47

371

pospome

@pospome

2 years

これドキュメントだけ用意してもダメなんだよね。読まない人いるし、パターン化するのにも限界がある。なので、スライド中の"誰かが質問を投げかける"という部分が重要だと思う。チームで高品質なコードを追求するための「設計標準」の育て方 / loglass coding standard

チームで高品質なコードを追求するための「設計標準」の育て方 / loglass coding standard

ログラスでは、チームとして高品質なコードを追求するために「設計標準」というものを定め、チームで育てています。この資料ではそのような取り組みについてご紹介します。株式会社ログラス会社紹介資料 https://speakerdeck.com/loglass2019/whats-loglass …

speakerdeck.com

2

38

363

pospome

@pospome

7 months

"Object-Oriented Conference 2024" の登壇資料です。 #ooc_2024

DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁

"Object-Oriented Conference 2024" の登壇資料です。 https://ooc.connpass.com/event/305241/

speakerdeck.com

0

56

360

pospome

@pospome

1 year

"一方で、コード品質の問題を認識しているのは、開発者やアーキテクト、プログラムマネージャーであり、経営者やビジネスマネージャーはほとんど認識していない"←これが問題なんだよな。大体ここで詰む事が多い。

コード品質はやはりビジネスに影響を与える - mtx2s’s blog

私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性…

mtx2s.hatenablog.com

3

64

336

pospome

@pospome

9 months

自チームのDBをTiDBに移行したんだけど、分散DBなので無停止でバージョンアップしたり、スケールアップしたりできるのがとても助かる。DMMは60以上のサービスがあるので、停止する場合は関係各所とスケジュール調整しないといけなくて、これがとても大変だった。これしなくていいのとても嬉しい。

1

49

325

pospome

@pospome

5 years

これよくまとめたな。すごい。アプリケーションにおける権限設計の課題 - kenfdev’s blog

アプリケーションにおける権限設計の課題 - kenfdev’s blog

日々権限設計で頭を抱えてます。この苦悩が終わることは無いと思ってますが、新しい課題にぶつかっていくうちに最初のころの課題を忘れていきそうなので、現時点での自分の中でぐちゃぐちゃになっている情報をまとめようと思い、記事にしました。

kenfdev.hateblo.jp

1

89

324

pospome

@pospome

8 months

先日「Googleではマネージャーがテックリードの業務を云々」とか「日本で言うエンジニアリングマネージャーの定義が云々」って言ってたけど、そこら��んが体系的に整理されている記事を見つけた。自分はエンジニアリングマネージャーに該当するっぽい。

0

34

325

pospome

@pospome

4 months

ミノ駆動さんが5月に入社したんだけど、やっとコード品質改善プロジェクトを開始することができる。正確に言うとエンジニアの設計スキル向上になる。やることとしてはシンプルでミノ駆動さんと一緒に設計、実装するだけ。結局強いエンジニアと一緒に作業できる環境が一番成長するんだよなー。

1

25

320

pospome

@pospome

9 months

これ嬉しいかも。Dockerfileを新規で作る機会少ないので、毎回ググってる気がする。

Dockerの設定を大きく省力化する「Docker Init」コマンドが正式リリース。DockerfileやCompose設定ファイルなど自動生成

Docker社は、DockerfileやDocker Composeの設定ファイルであるCompose.yamlなどを自動生成してくれる「Docker Init」コマンドが、1月25日付でリリースされたDocker Desktop 4.27...

www.publickey1.jp

0

22

323

pospome

@pospome

1 year

リモートワークだと人の目がない分サボれてしまう可能性があるので、そこに甘えてサボってしまうと成長機会を失って将来的に詰む感じがある。リモートワークは通勤時間がなくなるみたいなメリットもあれど、自分で自分を律する必要があり、それはそれで厳しいなーと思う。

1

42

312

pospome

@pospome

2 years

DMMは多くのサービスを展開していて、エンジニア数も多いのでマイクロサービスにせざるを得ないんだけど、"組織をまたいだアプリケーション間通信が発生する" というのがいかに面倒かを定期的に実感する。そして"通信"という部分よりも"組織をまたぐ"という部分の方が圧倒的に面倒だなと感じる。

0

29

304

pospome

@pospome

1 year

エンジニア→テックリード→アーキテクト（マネージャー）みたいなキャリアパスってピラミッドを登っていくイメージだったんだけど、実際は下のレイヤにいる優秀な人達から逃げていくイメージに近いんだなと最近感じる。彼らと同じフィールドで戦うわけにいかず、彼らも同じ道を辿ってくるんだよな。

1

38

297

pospome

@pospome

1 year

評価者や経営者からすると、年収って一度上げたら下げづらいので「その人がその年収に見合う成果を継続的に出せる保証がないと上げづらい」みたいな部分があるのかなと思っているんだけど、被評価者からすると「今期は頑張った」みたいな半年や1年での成果ベースで昇給を考えると思っている。

1

36

295

pospome

@pospome

1 year

書きました。

【追記 2023/06/26】テックリードに求める役割と適切なチームサイズについて - pospomeのプログラミング日記

自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、最初に比べると組織がそれっぽく拡大したこともあり、ここ最近テックリードを立てる機会が増えてきた。一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームの…

www.pospome.work

1

32

296

pospome

@pospome

1 year

会社の同僚にテスラのアジャイルについて教えてもらったので、参考記事を読んでみたけど、すごかった。なんか自分のやっていることってアナログというか・・・おままごとみたいなことやってるなって気持ちになった。

あなたが学んだアジャイルとテスラの手法は何が違うのか？　認定スクラムトレーナーが語る、テスラの真の凄さ

「Agile Tech EXPO（あじゃてく）」は、社会をちょっと良くするテクノロジーを学び、ちょっと先の未来の話をする無料オンラインコミュニティです。Keynote Speakerとして登壇したのは、ビル・ゲイツ氏、ジェフ・ベゾス氏、イーロン・マスク氏の下で働いた経験があるジョー・ジャスティス氏。テスラ社の急成長を支える、アジャイルハードウェア開発について話しました。全2回。前半は、イノベ...

logmi.jp

1

49

286

pospome

@pospome

1 year

本日の資料です。

120名の開発組織を支える、技術マネジメントと選定

"ソフトウェアアーキテクトの挑戦　技術選定を成功させるために" の登壇資料です。 https://offers.connpass.com/event/289340/

speakerdeck.com

1

33

289

pospome

@pospome

5 years

メルペイには"メルカリ、メルペイにおける認証認可の仕組みを構築すること"を目的にした認証基盤というチームがあります。高負荷でありながら高い可用性を要求され、システム仕様も複雑です。難易度の高いタスクがたくさんあるチームなんですが、興味ある人いますかね・・・?

2

57

281

pospome

@pospome

2 years

DMMプラットフォーム内の各チームのWebAPIを1年以上継続的にコードレビューしてるんだけど、外からレビューしてるとなんとなく技術的負債の返済期限みたいなのを感じる。「これは今やらないとヤバい」みたいなリファクタリングは、その期限を過ぎると後から絶望的にリファクタリングしづらくなる。

1

44

280

pospome

@pospome

9 months

今まではアプリケーションの不具合を発見したら、すぐに修正するようにしていたけど、SLOを本格的に運用すると「これSLO割ってないから今すぐ修正する必要ないな」みたいな判断が定量的にできるようになったので、運用が楽になった。良い意味で手を抜けるので、開発作業に避ける工数が増えた気がする。

1

40

278

pospome

@pospome

1 year

スゴイ分かりやすい。

熊崎宏樹さんが質問に回答しました | mond

mondでこの回答を読んでみましょう

mond.how

0

25

276

pospome

@pospome

1 year

自分はDeNA, メルカリでマイクロサービスを経験して、7~8年くらいマイクロサービスに携わってきたんだけど、（今の立場とDMMという多様なサービスを展開している組織特性がありつつも）DMMのマイクロサービスは過去最高に難易度が高い。マイクロサービスに興味ある人はDMMに入社するのがいいと思います

1

28

274

pospome

@pospome

3 years

さっきの Cloud Run の進化とかを見てると、ほんとk8sに投資してペイできる規模の企業じゃないとk8s導入する意味ないよな。メガベンチャーレベルだと投資する価値あるとは思うけど、それ以外だとコスパ悪い気がする。GKE, EKS はマネージドとはいえ、運用するだけで結構大変。

1

34

273

pospome

@pospome

2 years

普段は自分でコード書かないけど、最低でも週3時間くらいはコードレビューしていて、コードの良し悪しを見極めるスキルは落とさないように頑張っている。やっぱり実際のコードを前にして「これどーすれば良くなるかな」って考える機会を作らないと、ここらへんはキープできないなと思う。

1

22

269

pospome

@pospome

2 years

AWSとしてはECS推しなんだろーな。そもそもk8sが必要になる組織の方が少ない気がするので、世の中のニーズ的にECSやCloud Runみたいなフルマネージドコンテナプラットフォームに注力する方がいいんだろーなと思う。

1

21

270

pospome

@pospome

1 year

マネージャーとかアーキテクトになって手を動かさなくなると技術の詳細が分からなくなるので、現場のエンジニアに劣等感を抱きがちだけど、そこで手を動かす方にシフトしたところで作業時間を確保できないので、手を動かさない領域で自分の価値を見出す方向にシフトしないといけないんだろーな。

2

30

268

pospome

@pospome

1 year

自分のチームではNewSQLとしてTiDB Cloudを採用して、レガシーアプリケーション（PHP, Java & オンプレMySQL）をTiDB Cloudに移行しているんだけど、今の段階での評価とSpannerとの比較をなんとなーく書いていく。

1

44

259

pospome

@pospome

1 year

参考になるな。おそらく自分は"強めのEM"としての動きをしているものの、能力的には"弱めのEM"に近いので求められている動きができていない気がする。あくまで"強めのEMの動きをしている"だけで、できているかどうかは別っていう。

エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita

本記事は、Engineering Manager Advent Calenderの１日目です。はじめにエンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。私たちの主…

qiita.com

1

16

251

pospome

@pospome

3 years

k8sを運用すると「これECSだとデフォルトで使えるよな・・・」って機能をわざわざ構築しないといけなくなるので、中途半端にk8sを使っていると"劣化版ECS"を作っている感じになって辛い。特にクラスターを作った初期は足りないものが多いので、これを感じることが多い。

0

30

246

pospome

@pospome

1 year

副業の技術支援でマイクロサービスの導入や改善を依頼されるんだけど「マイクロサービス採用するメリットないので、そもそもやめた方がいいと思います」って提案することが多い。一方で「顧客がマイクロサービスやりたいって言ってるんだから黙って支援すればいーのでは?」って気持ちもある。

2

38

245

pospome

@pospome

9 months

SQLのテストってイメージわかないので、インテグレーションテストやE2Eテストで保証するって感じだったけど、やろうと思えばできるんだな。

より信頼できるクエリを書くために、SQLでもテストを書く - ハヤオキスルフクロウ

はじめにこんにちは、久しぶりに技術系の記事を書きます、株式会社カンムで機械学習エンジニアをしている fkubota です。今日はSQLについてです。弊社に入社してから毎日のようにSQLのクエリを書いてきました。クエリを書き始めてからもう3年が経とうとしています。日々クエリを書きながら少しずつ自分のスタイルが出…

fkubota.hatenablog.com

0

26

244

pospome

@pospome

9 months

テストを書くのもスキルの1つなので、テストを書けば書くほど上手く早く書けるようになる。この投資ができないと、中途半端にテストを書いて、メンテできず、常に落ちてるテストばかりになってしまう。

テストコードを負債化させない上手な付き合い方 / Test Code Management

XUnit Test Patterns に筆者の経験則を落とし込んでまとめています。 2024/01/25 TechBrew in 東京〜技術的負債と共に歩むプロダクトの成長〜の登壇資料です。 https://findy.connpass.com/event/306451/

speakerdeck.com

0

19

243

pospome

@pospome

2 years

SREはGoogle発の職種だと思うんだけど、Googleは世界規模のサービスとそれを支える独自インフラを持っているからSREという職種が重要なのであって、そーでもない規模のサービスでパブリッククラウド使っている場合、SREの重要性は薄れてくる（そこまで投資しなくても十分サービスが動く）と思っている

1

16

242

pospome

@pospome

3 months

ミノ駆動さんに社内勉強会をしてもらったけど結局「コード品質は定量化できないから評価されづらい」「コード品質を理解できない組織は詰み」ということだったので、そーだなーと思った。一般論だから「それはそう」という感じかもしれないけど、ここに理解のない組織が多いのが事実だったりする。

1

34

236

pospome

@pospome

2 years

100回くらい言ってると思うけど、マイクロサービスアーキテクチャって言ってしまえば"アプリケーション同士が通信するだけのアーキテクチャ"なので、よほど大規模なものじゃない限り動いちゃうんだよね。動いちゃうから成功に見えてしまって、"開発速度の低下"みたいな問題に気づきにくい。

2

28

232

pospome

@pospome

2 years

ドキュメントを書けるエンジニア少ないのはすごく実感する。ドキュメントは開発をスケールさせることができる強力な武器なので、上手く活用するとエンジニア同士のコミュニケーションがなくなって開発効率上がるんだよね。伸ばすのが難しい能力

伸ばすのが難しい能力: 柴田芳樹 (Yoshiki Shibata)

2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。ソ��トウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない...

yshibata.blog.ss-blog.jp

1

32

231

pospome

@pospome

6 months

本日の資料です。TiDBを採用した背景についてのものですが、Spannerとの比較にも少し言及しています（LT資料なので大分ざっくりした内容になっていますけど）。

DMMプラットフォームがTiDB Cloudを採用した背景

私たちはなぜNewSQLを使うのかTiDB選定5社が語る選定理由と活用LT https://findy.connpass.com/event/314602/

speakerdeck.com

0

44

231

pospome

@pospome

1 year

これ便利だわ。自分のチームのコンテナイメージほんと何も入ってないんだよな・・・。

Dockerがコードネーム「Docker Debug」発表、コンテナ内に任意のデバッグツール群を一括導入、効率的なデバッグを実現。DockerCon 23

Docker社は米ロサンゼルスで10月3日と4日の2日間、年次イベント「DockerCon 23」を開催しました。 1日目の基調講演で、Dockerコンテナ内でのアプリケーションのデバッグを高効率化するDocker Desktopの新しい拡...

www.publickey1.jp

0

29

228

pospome

@pospome

2 years

DMMプラットフォームで"障害期間における機会損失の可視化"をやっているんだけど意外と難しい。これができるようになると維持すべき運用レベルや恒久対策に費やす工数みたいな部分を機会損失額を基準にロジカルに判断することができるので、最初は雑でもいいから形にしたいなーと思ってるんだけど。

1

31

229

pospome

@pospome

2 years

DDDを学んで良かったのは、今までリクエスト/レスポンスやDBのテーブルのデータ構造に引っ張られてドメインオブジェクトを設計していたのが、そうする必要がないってことを知ったことによって、プログラミングの設計作業がとても楽しくなったことかな。

1

16

226

pospome

@pospome

3 months

Terraformの設計難しいんだよな。インフラの規模感にも依存するし、場合によってはやり直しが難しかったりする。

Terraformモジュール構成のベストプラクティス - ENECHANGE Developer Blog

VPoTの岩本 (iwamot) です。この記事では、Terraformモジュール構成のベストプラクティスをご紹介します。Terraformドキュメントに書かれているものですが、従わずに時間を溶かした失敗談をまじえてお伝えすることで、同じ轍を踏む方が減ることを願っています。取り上げるのは下記のベストプラクティスです…

tech.enechange.co.jp

0

18

219

pospome

@pospome

3 years

マイクロサービスになるとモノリスとは違って1人のアーキテクトが技術戦略をコントロールするのが難しくなるので、各チームに優秀なエンジニアがどれだけいるか、どこに優秀なエンジニアを配置するのか、というのが重要になるなーとしみじみ感じる。

1

18

220

pospome

@pospome

1 year

ドキュメントが機能しない問題は、そのドキュメントがどれだけ日々読まれるか（使われるか）次第なので、gitにしたからといって変わらないと思う。

設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ

はじめにTIG真野です。秋のブログ週間2023 の3本目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽

future-architect.github.io

1

28

219

pospome

@pospome

1 year

"マイクロサービスアーキテクチャは大変という話" を書きました。ただの感想なので薄いです。

マイクロサービスアーキテクチャは大変という話 - pospomeのプログラミング日記

最近「マイクロサービスって大変だな」と感じることが多いので、書いてみた。単なる感想です。 pospomeのマイクロサービス歴面倒なのは技術ではないモノリスだと厳しい楽しくもある宣伝 pospomeのマイクロサービス歴以下の企業で7年ほどマイクロサービスに携わっている。 DeNA（ゲームプラットフォーム）メ…

www.pospome.work

1

10

218

pospome

@pospome

2 years

GitHubがモノリスからマイクロサービスに移行したという話。内容としては「まあこう進めるよね」みたいな感じで目新しさはないと思うんだけど、大変だったんだろーな・・・。

GitHubのモノリスからマイクロサービスへのジャーニー

この記事では、GitHubの最近のマイクロサービスアーキテクチャに向けたジャーニーについて説明します。 GitHubの歴史的および現在の状態を詳しく調べ、いくつかの内部および外部の要因を検討し、マイクロサービスアーキテクチャを実装するための主要な概念やベストプラクティスなど、Githubが移行にどのように取り組んだかについての実際の検討事項について説明します。

www.infoq.com

0

23

212

pospome

@pospome

2 years

これスゴイ良くまとまってるなー。こーやって言語化するの難しいんだよな。「継続性アーキテクト」という生き方 - エス・エム・エスエンジニアテックブログ

「継続性アーキテクト」という生き方 - エス・エム・エスエンジニアテックブログ

介護や医療、ヘルスケア、シニアライフなどの4つの領域で高齢社会の情報インフラを構築している株式会社エス・エム・エスで技術責任者をしている @sunaot です。2015年2月に入社して以来、技術責任者として開発組織づくりやサービスの内製化を進めてきました。「『継続性アーキテクト』という生き方」というタイトルをつけてい…

tech.bm-sms.co.jp

1

32

213

pospome

@pospome

1 year

当然あらゆるものをお金に換算して提示するのは難しいので、そんな上手くいかないんだけど、可能な限り「このロジックだと、このくらいの利益が出ます」みたいな形に落とし込めるといいなーと思う。そのロジックの精度をどこまで信じるかは受け取り手が判断すればいい。

1

30

207

pospome

@pospome

8 months

この発表のための資料を作ってるんだけど、意外と40分に収めるのが難しい。過去に社内勉強会で使ったスライドを一部流用する形を想定していたんだけど、その資料ですら60分用だったからな・・・。

DDDはなぜ難しいのか / 良いコードの定義と設計能力の壁

私がDDDに出会ったのは2014年です。そのころはDDDの情報も少なく、試行錯誤しながらDDDに向き合ってきました。思い返すと「DDD理解した」と「DDD分からん」を繰り返してきたように思えます。今回の発表では私の経験をベースに「なぜDDDが難しいのか」「どうすればできるようになるのか」を設計原則や良いコードの定義を交えて説明しようと思います。

fortee.jp

0

17

209

pospome

@pospome

7 months

例えばDMMプラットフォームはマルチクラウドなので、AWS, GCPのリソースを管理しないといけないし、Pager Duty、Discordなどの各種ツールのリソース管理も必要になる。現在はこれをTerraformで管理していて、新しい人が入社した場合、GitHubにPR送るだけで必要なアカウントが用意される。

1

19

204

pospome

@pospome

8 months

SRE本に"Googleのマネージャーは技術色が強いから、マネージャーはテックリードの仕事をほぼ行える"って書いてあったので、やっぱり理想としては、技術領域を扱うチームのマネージャーってテックリードと同等の技術力を持たないといけないんだろーな。

1

24

208

pospome

@pospome

3 years

マイクロサービスにおいてDB共有はアンチパターンだけど、"READだけは許可する" という戦略はありだと思っていて、そう考えると、各マイクロサービスのCRUDを完璧に把握して制御できる場合は別に共有してもいーんだよな。パフォーマンスとか他の要件もあるから、現実的には避けた方がいーんだけど。

1

24

205

pospome

@pospome

27 days

小さいPull Requestを作るのって結構エンジニアのスキル高くないと難しいんだよな。実装者はある程度実装の全体像をイメージしてPR作らないといけないし、レビューする側は細切れのPRをレビューすることになるので、コードの全体像が分からないと正確にレビューできない。

Findy Team+を活用した開発生産性向上の取り組み - ZOZO TECH BLOG

はじめにこんにちは。会員基盤ブロックの小原田です。弊社では、ZOZOTOWNという大規模なモノリシックシステムをマイクロサービスへリプレイスする取り組みを進めています。私が所属する会員基盤ブロックでは、ZOZOTOWNの会員情報を扱うマイクロサービスの開発と運用を担当しています。会員基盤ブロックでは、開発生産性の向…

techblog.zozo.com

2

36

206

pospome

@pospome

2 months

こんなことできるんだ。昔大きいテーブルを扱っていたときに、いつ処理が終わるか分からないまま不安になりながら待ってたな。

重いALTER TABLEの実行中に進捗状況を確認する方法 - CyberAgent SRG #ca_srg

メディア統括本部サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。本記事は、MySQ

ca-srg.dev

0

33

200

pospome

@pospome

11 months

DMMプラットフォームでレガシーシステムのリプレイスという形で技術的負債の返済をしているんだけど、技術的負債が大きければ大きいほど、返済に必要な工数が大きくなり、機能追加を一定期間止めないと返済できない状態に陥ってしまう。そうなると結果的に経営陣の理解を得られず、返済できなくなる。

1

47

196

pospome

@pospome

3 years

DMMプラットフォームでは諸事情があってGKE, EKSを両方運用しているんだけど、それぞれのクラウドの同じサービスを使ってみると、AWS, GCPの思想みたいなものが明確に見えてきて面白いなーと思う。

1

26

194

pospome

@pospome

10 months

SREとプラットフォームチームの役割の違い。DMMプラットフォームでは来年くらいに既存のSREチームに加えてプラットフォームチームを立ち上げる予定なんだけど、部分的に役割が重複する感じがして、どう切り分けたものかと思ってたんだけど、この図でも重複しているので、こーゆーものなのか。

1

17

195

pospome

@pospome

1 year

ADRいいな。Design Docでカバーできると思っていたけど、DMMプラットフォームのDesign Doc��用ってあくまで開発作業に着手する前に設計を固めるものであって、開発過程での設計変更を反映させるかどうかは任意にしてるんだよな。

日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード / Architectural Decision Records

2023年7月27日「Developers Summit 2023 Summer」にて「日々の意思決定の積み重ねを記録するアーキテクチャ・デシジョン・レコード」というタイトルで「ADR」について発表した資料です

speakerdeck.com

1

25

191

pospome

@pospome

2 years

なるほどなー。フロントエンド全然分からんからこーゆーのでなんとなく理解した感を得るっていう・・・。

Webの将来はサーバサイドレンダリング（SSR）に回帰していく。Denoが主張するIsomorphic JavaScript（もしくはUniversal JavaScript）とは何か？

静的なHTMLファイルをWebサーバが配信する仕組みから始まったWebは、サーバ側で動的にHTMLを生成するCGIの仕組みや、Webブラウザ上でJavaScriptを実行してインタラクティブな操作を実現するなどの仕組みを得たことでWebアプ...

www.publickey1.jp

1

17

192

pospome

@pospome

3 years

ログの保存って意外と費用が高いなーと最近思っているんだけど、よくよく考えるとマイクロサービスだとリクエストトレーシングするためにアクセスログもモノリスの数倍の量になるので、結構費用かかるなと思った。モノリスってエコなんだなー。

2

28

191

pospome

@pospome

3 years

Goは結構バランスの良い言語で、Google規模でなくともそれなりに大きな組織のソフトウェア開発だと結構合うと思う。自分がDMMプラットフォームのサーバサイドやインフラ周りで全面的にGoを採用したのも、そういった背景がある。今は段階的に各種アプリケーションをGoで書き換えています。

1

18

190

pospome

@pospome

9 months

コードの設計って「今悩んでも分からん」みたいなものがあるので自分は「悩んでも仕方ないから、どっちかでやってみて問題あったら、そのときに直そう」って言うんだけど、これって「後で直せる程度の問題」であることが事前に分かってないと判断できないよなーということに最近気づいた。

2

22

188

pospome

@pospome

2 years

Uberのリモート開発環境の話。モノレポ移行による問題をクラウド上の開発環境で解決するっていう。エディタとのインテグレーションもサポートしてるのすごいな。さらっとトランクベース開発を採用していることも書いてある。

Devpod: Improving Developer Productivity at Uber with Remote Development | Uber Blog

In this blog, we share how we improved the daily edit-build-run developer experience using DevPods, our remote development environment. We will start with some of the initial challenges, the pain...

www.uber.com

1

18

190

pospome

@pospome

1 year

DMMプラットフォームのSREチームがここ数ヶ月クラウドインフラの費用削減をしているんだけど、結構な金額が削減できることになり良い成果を出せる感じになっている。ただ、逆に「今まで無駄な費用が多くかかっていた」と考えることもできるので「成果を出した」と言えるかどうか怪しい雰囲気を感じる。

1

23

187

pospome

@pospome

1 year

自分が作るチームは基本的にAmazonのTwo Pizza Ruleを参考にしていて、1チームの人数が7 or 8人くらいになったら、2つのチームに分割するようにしている。1チームの人数が多くなるとテックリードが "成果物レビューおじさん" になり、手を動かす時間がなく、技術領域をリードできなくなる。

1

21

186

pospome

@pospome

5 years

最近DDDにあまり興味がなくなってきていて、その理由は "普通に開発したらDDDになるじゃん" 的な気持ちになってきたから。普通なことに興味って持たないよね的な。でも、この "普通" という感覚は5年前の自分にとっては普通ではなかったものなので、DDDに出会ったことで成長できたのかなと感じる。

2

31

185

pospome

@pospome

1 year

この記事の内容は正しいと思う。「中規模以上の開発にははっきりと向いていない」「controllers 自体はあってもよいが」「データベースコネクション周りに関する知識は db に入れてよいが」みたいな形でポイントを抑えている。

強い思想: Go を Web 開発に採用する上で

zenn.dev

0

21

185

pospome

@pospome

6 months

DMMプラットフォームは組織の方針として技術的負債を抱えすぎて財政破綻したレガシーアプリケーションのリプレイスをしている最中なんだけど、肌感で3,4人のエンジニアを貼り付けて2,3年くらいかかるので、中長期的な開発スピードを考慮すると適度に負債を返済するって大事なんだなーと思う。

0

36

185

pospome

@pospome

2 years

開発プロセスのどこがボトルネックになっているのかは確認しているけど、こんな風に積み上げグラフにするって発想はなかった。結構良さそう。

1

21

179

pospome

@pospome

1 year

先日テックリードの役割とチームサイズに関する記事を書きましたが、それ系で有名なのは "Good Tech Lead, Bad Tech Lead" という記事だと思うので、これも一緒に読むといいかもしれないです。

Good Tech Lead, Bad Tech Lead

A brief guide to tech leadership at Foursquare, inspired by Ben Horowitz’s Good Product Manager, Bad Product Manager. Good tech leads act as a member of the team, and consider themselves successful…

medium.com

1

12

184

pospome

@pospome

2 years

DMMプラットフォームでは、第三者（チーム外の人）がGoのコードをレビューするという文化があって、自分はその業務の一部を担当しているんだけど、負債のない新規開発であっても大体1~1.5年で「このコードベースだと、これ以上品質を上げるの限界あるな」と感じるタイミングが来るなと最近感じた。

1

13

182

pospome

@pospome

3 years

DMMに入社して2日目に上司に言われたのが「pospomeさんはDMMの認証認可をどうしていきたいですか?」だったんだけど、逆にこっちがどうしていきたいか知りたいと思った。まあでも今考えると自分に求められてるのが、こーゆー抽象度の課題なんだなーというのが明確になって良かったかもしれない。

1

17

181

pospome

@pospome

2 years

"正解にする力"っていうのはたしかにそーだなーと思う。テックリードレベルの技術選定や技術戦略の決定は "組織をどのようにその技術に合わせていくか" という組織開発ならではも観点も重要になるなーと。

技術選定で失敗しない、正解にする力 - クックパッド開発者ブログ

技術選定というと、世の中のデファクトだとか、新しい技術だとか、社内で実績のある枯れた技術とか色々な理由や基準で選ぶのが良いと、至るところで言われていると思います。選定時に議論が平行線にならないように、判断基準を設けるべきというのもあるでしょう。これらは重要であり、検討、準備することは必要ですが、それに加えて「正解に…

techlife.cookpad.com

1

27

181

pospome

@pospome

9 months

マイクロサービスって1つ1つが小さくてコードを保守しやすい印象あったんだけど、実際にやってみるとエンジニアの数に依存する部分があって、例えば100人のエンジニア組織が100個のマイクロサービスを扱えるわけがない。なので、場合によってはマイクロサービスといえど、意外とモノリスっぽくなる。

1

22

180

pospome

@pospome

1 year

dmm.goの登壇資料です。DMMプラットフォームでコード品質をどのように向上させるかという話です。

組織のコード品質を向上させる “レビューシステム”の取り組み

dmm.go #6 の登壇資料です。 https://dmm.connpass.com/event/295065/

speakerdeck.com

1

19

181

pospome

@pospome

2 months

数千QPSをさばいているTiDBに6000万件のテーブルがあって、それにインデックスを張った。インデックス追加は物理オンラインDDLで実行時間は3min程度だった。実行中にエラー率の増加は見られなかった。レイテンシは全体的にp99が20~30msec程度悪化した（本番影響はないレベル）。

1

30

179

pospome

@pospome

2 years

以前はモノリス→マイクロサービスという流れだったけど、最近はモジュラモノリスというアーキテクチャが認知されてきたので、モノリス→モジュラモノリス→マイクロサービスという流れが主流になると思っていたけど、意外とマイクロサービスからモジュラモノリスにシフトするケースもあるのは面白い。

1

11

175

pospome

@pospome

7 months

今までは要件によってRDB, NoSQLを使い分けていたけど、NewSQLによって書き込みがスケールするようになり、強整合性も保証されるようになり、さらにHTAPという概念によって集計処理も高速になってきた。自分が新卒の時は単一のDBを使ってれば良かったんだけど、そういう感じに戻りそうなのは面白い。

1

12

175