島津 真人

島津 真人

職種
EngineerCTO
Twitter

大学院を卒業し、GoogleのChromeチームでSoftware Engineerとして５年間勤務。テックリードとして Service Worker の実装をする傍ら、STEP教育コースの講師なども行っていた。

2021年4月より Progate に入社し、Progate Pathのテックリードやグループリードを経て、2023年4月よりCTOに就任。

note

チーム一丸となって開発を行うための技術と施策｜Progate｜note

Progate Path のチームリード兼テックリードとして働いている島津です。今回は技術的な側面から Progate Path の開発フローについて共有できたらいいなと思ってこの記事を公開しました。 Progate Path は現在、デザイナー、コンテンツプランナー、エンジニア、あとCEOのマサさん（加藤）で構成されるチームで機能開発・改善が行われています。日々開発・改善を行う中でも特に、デザイナーやコンテンツプランナーも含め全員がプロダクトのコードをさわり、 PR をつくり、直接プロダクトの改善をしていくワークフローを構築していることはこのチームのひとつの特徴かなと思っています。 このワークフローを構築するにあたって、意図的な狙いをもって行った技術選定や施策がありました。今回は Path チームが一丸となって開発できている背景となる、それらの技術や施策について紹介させてもらおうと思います。 「めんどくさい」と感じることなくシステムを変更できるようにしていくことでメンバーが積極的に改善を続けられる仕組みをつくれるのではないかと考え、以下のようなことを行っています。 まず、 Progate Path ではすべてのコンポーネントを一つのリポジトリに入れ、モノレポ構成でコードの管理をしています。実際のサービスを提供するシステムのコードに加え、 Progate Path のリポジトリではユーザーさんが触る演習のコードやそれの説明のためのテキストも管理しています。このようなデータをすべて一つのリポジトリに入れることで、サービス全体を簡単に立ち上げることができるようになり、テストやデプロイも一括して行えるような CI/CD を構築することができました。 この構成のおかげで、デザイナーのメンバーがQA中に演習内にちょっとしたタイポや表記違いを見つけたりしたときサッとPRを送ることができるようになったり、逆にコンテンツ開発時に Lint の設定を開発リポジトリから参考にしてきたりなど、ちょっとした変更を普段触っている領域にとどまらず低コストで入れられるようになっています。 また、 Progate Path では API 、 CLI 、 Web という大きく分けて３つのコンポーネントで構成されていますが、これらはすべて gRPC で通信しています。 Protocol Buffer は記法もわかりやすく、後方互換性があり、各言語のバインディングと型定義が簡単に生成できるためフィールドの追加や削除の影響がビルド時にわかるため、管理コストが低くなります。 また、 proto ファイルにはできる限りコメントを書くようにすることで、各 API に関するマスタードキュメントをそこで一元管理するような運用をしています。 また、複数のコンポーネントの環境構築や立ち上げを一括で行うため、 Docker Compose を利用しています。モノレポの利点を活かし、 docker-compose up を叩けば一通りのサービスが動くようにした結果、ローカルでの QA がしやすくなりました。 ただ、この部分に関してはホストのボリュームマウントをするとファイルのパーミッションの扱いが難しいという問題があるため、より良い方法がないか引き続き模索しています。 Progate Path は initial commit からちょうど１年たち、少しずつ規模が大きくなっていくにつれて開発速度を徐々に意識しなければならなくなってきました。ここでは以下に挙げたような、開発当初から意識していた開発速度に関する施策や、最近はじめた取り組みなどについて紹介しようと思います。 Progate Path ではスピーディーに仮説検証を行っていくため、 Feature Flag を用いたトランクベースな開発フローを実践しています。 たとえば新しい UI への変更を行うような例を考えてみましょう。一つのブランチで機能開発を行い、完成してからマージするワークフローだと、新しい機能を入れた際のQAが大変になったり、別の機能修正を入れづらくなるといった問題が発生します。 一方で Feature Flag を利用すると、ユーザーさんに影響が出ないように新機能をフラグで囲うことで、小分けにしたPRをどんどん main ブランチにマージしていくことができます。さらに、 QA する際も開発メンバーにのみ機能を有効にすることができ、さらにそのまま A/B テストを開始したり、段階的にローンチしてみたりといったロールアウト方法を取ることができます。 Progate Path では、開発メンバーの少ない中でも並行してどんどん開発を進めており、それぞれの機能を独立して開発・リリースできる Feature

note.com

チーム一丸となって開発を行うための技術と施策｜Progate｜note

Tech blog

現実のコードでの計算量の「１」はどれくらいの大きさか - 計算量の「１」の再確認 - Progate Tech Blog

こんにちは、Progate で新規事業開発のテックリードをしている 島津(@MakotoShimazu) です。 この４月に入社 してから半年以上経ち、重い腰をあげてようやく Progate のテックブログデビューしました。皆さんよろしくおねがいします。 ※ 本記事は Progate Advent Calendar ３日目の記事になります。 計算量といえば、少し前にちょっとした話題になったのを覚えている方も多いのではないでしょうか。 100日後に退職する47歳90日目#100日後に退職する47歳 pic.twitter.com/QqVgmonX7q - 元アプリ開発者47歳@100日後に退職する47歳 (@tome_ura) 2021年10月13日 しかし、学生さんなどに実際に計算量を数えてもらおうとすると、しばしば何を数えればよいのかわからない、つまり「１」の決め方で混乱している人を見かけます。 そこで本記事では、時間計算量における「１」とは何者なのかを振り返ってみようと思います。 （そして、もしやる気がでたら、もう一歩踏み込んで実際のコードを見ながら「１」の時間について考えてみようと思います。） 時間計算量は、ある処理における計算時間を見積もるための値です。 Time complexity - Wikipedia なんかを見てみると、以下のように書いてあります。 Time complexity is commonly estimated by counting the number of elementary operations performed by the algorithm, supposing that each elementary operation takes a fixed amount of time to perform.

tech.prog-8.com

現実のコードでの計算量の「１」はどれくらいの大きさか - 計算量の「１」の再確認 - Progate Tech Blog

イベント