勉強会やイベントなどでIT系のステッカーを集めるのが個人的な趣味である。これが絶妙に使い所がないため、溜まる一方。 かつてはMacbookの天板に貼っていたのだが、アラサーになってミニマリスト気味になってきたからか、気持ち的にはもうラップトップに貼りたくない。リセールのときに剥がしたりするのもめんどくさいし、かといってステッカーを貼る用のカバーをつけるのもちょっとな... という。 額縁に入れる というわけでダンボールを下地にしてステッカーをコラージュ的に貼ってみた。思ったよりいい感じ。 使っているのは、適当にAmazonで検索して出てきたA2額縁と、そのサジェストで出てきたフックで引っ掛けているだけ。 中に入っている段ボールは額縁の梱包をカッターで切り抜いて使ってみたのだが、コルクボードっぽい風合いになってこれがなかなか悪くない。ただ、クリア背景のステッカーを貼るには、やはり白い厚紙の方

前提としてクリエイティブな仕事は再現性が低い。しかし逆に言えば再現性があってはいけないものがクリエイティブであり、再現性がないからこそクリエイティブであると言える。アートのように非再現的なものはクリエイティブであり、再現性が低く刹那的な成果物であることに意味がある。 ソフトウェア開発にもまたアート的なクリエイティビティが求められつつも、ビジネスとしての利益追求では再現性が同時に求められることが多い。従って、多くの現場ではソフトウェア開発を再現性の高い労働集約的な仕事に転換しようとする。むしろ、そうしなければ開発組織の規模をスケールさせることができない。 ここで言うクリエイティビティの有無とは本質的に技術力とイコールであり、その具体性の表出はフレームワークやプログラミング言語を使うことではなく、逆にそれらを生み出す側にある。このレベルの技術力を持つ人材を集め続けるのは無理があるが、一方で技術

よくある野良の社内ツールは、開発生産性を向上させるための手段としてスポットで生まれることが多い。 たとえば、定期的に依頼されて手作業でキックしているバッチ処理を誰かがAPI化したり、それがCLIで実行できるようになったり、あるいは不特定多数の人々が手でやっている作業が有志で自動化されツールになるなど。そして社内の口コミや告知で伝搬され、使われていく。 出来の良い社内ツールは、野良だとしても開発チームが普段の開発プロセスのなかで意識したくない複雑性や実装の詳細をうまく抽象化し、認知負荷を下げる役割を果たしている。見方を変えれば、社内ツールはチーム・トポロジー*1でいうところのX-as-a-serviceインタラクション・モードの具象化のひとつだと言える。開発チームと社内ツールを開発する人間を社内ツールがインターフェイスとなって接続している。広い目線で見ると、これはプラットフォーム・エンジニア

今年もそろそろ終わってしまうので、若干気が早いが恒例のやつをここいらで一発。 Tailorに入社して1年経った 去年11月ごろに入社して、気づいたら1年が経過していた。スタートアップのスピード感を全身で感じる1年だった。 note.com 2023年はTailorプラットフォーム自体の機能拡充とインターフェイスの安定化がだいぶ進み、プロフェッショナルサービス(後述)で開発する顧客向けシステムもいくつかメンテナンスモードに入り始めているものが出てきたことが感慨深い。 思い返せば、自分が入社した当時はプラットフォームに足りない機能や細かいバグ、一貫性のない仕様やインターフェイスが多く、まずTailorを使ってストレートにアプリケーションを作るという行為そのものが無理筋だった。入ってすぐの2023年末はガラガラのWeWork KABUTO ONEでプラットフォームで使われている時間計算系のCel

実際の現場に現れる負債とかクソコードとか呼ばれるものは、簡単にできるはずのものが何十にも不必要な複雑性でラップされた成果物（標準ライブラリ相当の実装を自前で全部書いていて、かつエッジケースでバグだらけ、とか）であることが多い。しかし一方で、そもそもの実現したいこと・あるべき仕様のレベルである程度複雑性が仕方ないケースに対して、最短ルートで立ち向かったものが技術的負債扱いになってしまうこともある。 かつて、某データフォーマットプロトコルで外部のアイデンティティプロバイダとデータ連携を行う機能を開発したことがあった。 さすがに1からRFCに沿って自分で全部作るのはおかしいに決まっているので、Githubで使えそうなOSSライブラリを探していたのだが、その際に見つけたものは90%は欲しい機能があるものの残り10%ほど必要な機能が足りていなかった。そこまで使えるなら、あとは自分らでフォークして足り

最近、eslint/prettierの設定を共通パッケージ(eg. xxx-prettier-config/xxx-esling-config)に切り出すタイミングがあった。 これに関して、巷ではxxx-prettier-configとxxx-eslint-configというような形でツールごとに個別のパッケージを用意するのが一般的かと思うが、個人的にはこのようなコーディングルールの自動化に関連するツールの設定ファイルは、分けずに敢えてひとつのパッケージにするほうがよいのではないかと思っている。 使われているのかは知らないが、たとえばSalesforceだとこういうのがある。 github.com このパッケージはeslint, prettier, tsconfigなどのルール設定をひとつのパッケージにまとめている。 理由 端的にいうと、prettierとeslintで類似したルール設定に

現時点での自分の考えを雑なスナップショットとしてメモ 前提 ユニットテストに使うツールはjest(あるいはvitest)と@testing-library/reactを想定 テストに対応するモジュールを見つけやすいように __tests__ディレクトリは使わず、テスト対象と同じディレクトリに xxx.test.(ts|tsx) としてテストコードを配置する 最低限のディレクトリ構成としてpages/components/hooksを用意し、必要に応じてlibなどのディレクトリを追加する Next.jsなどフレームワークに対する依存を無理やり切り離そうとしない。 ほぼニコイチな存在なので逆に面倒なことになる。 テストしやすい(複雑なモックが必要ない)状態でメンテナブルなテストがたくさん書かれている方が重要。 Pages hook/componentsを組み合わせて画面を実装する データ取得や

最速攻略記事によると、Reactのuseはキャッシュと組み合わせる必要があらしい。 というわけでmoizeを使ってみたらいい感じだった。 "use client"; import { Suspense, use, useState } from "react"; import moize from "moize"; export default function Home() { return ( <main> <h1>Suspense</h1> <Suspense fallback={<div>Loading...</div>}> <Waiter /> </Suspense> </main> ); } const waiting: () => Promise<string> = moize( () => new Promise((resolve) => setTimeout(() =>

React v18では以下のようにCache APIの関数をimportできるのだが、あまりに情報がないので2023年の現時点でのコードを少し読んでみる。 Reactのコミットヒストリを見る限りCache APIは2022年10月ごろにmainへマージされたらしい github.com Cache, CacheContext, createCache まずは cache が呼ばれた際に、そのデータがどこに格納されるのかを知りたい。 少し読んでみると CacheContext という名前で以下のコードが見つかる。 export type Cache = { controller: AbortController, data: Map<() => mixed, mixed>, refCount: number, }; // ... export const CacheContext: Reac

Publickeyで公開されていたPlatform Engineering Meetup #1のまとめがとてもよかった。 www.publickey1.jp スライド中でも書かれているように、共通のプラットフォームを作るのがめちゃくちゃ難しいというのは同意。 自分が今年の1月ごろに書いた記事とも若干関連があると思っていて、やはりいい開発組織はプラットフォームという形をうまく扱っているし、その組織構造の結果としてマイクロサービスがアーキテクチャに現れる。 izumisy.work 詳細はボカすが、かつて僕が働いていた会社でも当時流行っていたチーム・トポロジーの輪読会を経て、プロダクト開発組織の中でいわゆるプラットフォーム・チームというものが組成されたことがある。これは、当時分割されていた個々のマイクロサービスに対してオーナーシップを割り当てる形でチームを再組成し、既存のバックエンドにある認知

転職活動でいろんな会社のエンジニアの人と話して思ったことをマイクロサービスの観点で備忘録がてらメモしておく。 よくあるマイクロサービスの分割軸として、業務機能、ユースケース（動詞）、リソース（名詞）あたりが一般的だが、これらどれもがドメインを構成する要素であるため、マイクロサービスに分割してしまうと結果的にソフトウェアの形がビジネスルールの変化を制限してしまうケースの方が多い気がしていた。実際、規模の小さい開発組織でマイクロサービスやってみました〜からのツラミはそういうのが多いイメージで、よくある「マイクロサービスやったけど逆に開発遅くなった」みたいなとこは上で挙げたような粒度の切り方をしている印象がある。 この件に関して、去年末の転職活動のタイミングでいろいろな人に話聞いてみた結果、実際にマイクロサービスでうまくやっていそうな組織は、上で書いたようなドメインを構成する要素でマイクロサービ

前職でフロントエンドチームのスペシャリストとして開発プロセスを考えるポジションにいた。そのときに試してみて良かったなと思えたのはAutoApproveという仕組みで、これは任意のPRにAutoApproveというラベルが付くとGithub Actions経由でPRがGithub BotにApproveされコードレビューなしでマージできるというもの。 コードレビューでは、プロダクトの規模が大きくなっていくにつれ認知的・時間的なコストが嵩む。レビュワーも広汎なドメインや設計レベルの知識が求められたり、人が増えると「これレビューする意味ある？」みたいなPRもレビュワーにバンバン飛んでくる。そうなると、全体的にさらっと見てApproveしたりする。これはもちろんレビューをされる側もそうで、コードレビューという仕組みがあるとなんとなくレビューをゲートキーピング的に捉えてしまいがちなところがある。 な

業務でE2Eテストの導入を進めており、ブラウザ自動化のためのツールに関して調べる必要があったので備忘録的に書き残しておく。 自分のブラウザ自動化周りの知識といえばはるか昔に大学生のころインターンでSeleniumを用いたテストの自動化をやったくらいで止まっており、その頃の記憶からブラウザの自動化はあまり信頼のおけない挙動ばっかりする... というイメージがあった。 とはいえ、現在は当時よりも様々な選択肢があるらしいので、少しづつ過去の歴史に触れつつキャッチアップしてみる。 Selenium Remote Control (Selenium 1) おそらく自分が大学生のときに触ったのはこのRCの世代だと思われる。 www.selenium.dev Selenium 1はブラウザ上での動作を実行するSelenium Coreとそれに対して操作処理を送信するRemote Controlから構成さ

最近諸事情あり業務でFirebase JS SDKのDatabase実装周りを読むことがあったので、備忘録的にブログ記事にしてみる。 初期化処理の雰囲気 Databaseまで含めると全体像があまりにでかすぎるので、とりあえず初期化処理周りだけを雰囲気でクラス図にしてみた。staticと書いてあるところはクラスではなくただ単にファイルとそこに定義されている関数であることを示している。 実際にDatabaseそのものの詳細な処理（コネクションハンドリングやら内部での状態管理など）はまた別で解説することとして、この図ではSDKの初期化に関連したクラスとメソッドのみを抜き出すことにした。 Firebase JS SDKの実装ではIoCコンテナとDIが設計において積極的に活用されており、独自のDIコンテナを内部実装している。ComponentというパッケージではDIコンテナの実装となるクラスがまとま

izumisy.work マネージャという役職として働くようになってそろそろ2年目が見えてきた。 自分の所属するUniposでは、複数チームが開発組織に並存するようになってから日が浅く（とは言っても1年以上は経っているが）それにともなって各チームをマネジメントするミドルマネージャ（中間管理職）というポジションはまだ黎明期的な立ち位置にある。転職組はある程度経験者もいるとはいえ基本的にはみんながニューゲーム状態であり、自分も全くと言っていいほど手探りな進み方をしている。 そんな中でも、ある程度「ミドルマネージャかくあるべし」を知るのに役立った書籍を3つ紹介する。 HIGH OUTPUT MANAGEMENT マネージャという立ち位置ならこれを読まない人はいないレベルのやつ。 なにから読むべきか... というときにはまずこれで間違いない。とはいえ、文章もなかなか小難しい感じでもありかつボリュー

izumisy.work 前回はあまりキャッシュについて触れることができなかったので、今回はEarthlyが持つキャッシュ機構だけにフォーカスして書く。 Earthlyにおけるキャッシュ Earthlyは環境に依存しない実行環境を提供するため、キャッシュにおいてもローカルファイルキャッシュのようなホストマシンに依存するタイプのキャッシュ機構*1を提供しない。代わりに、ビルドプロセスの中で SAVE IMAGE を呼んでいるターゲットの成果物をDockerイメージ化してキャッシュしコンテナレジストリに格納する。ビルドの実行時にはEarthlyが必要なDockerイメージのキャッシュをコンテナレジストリから取得する。 キャッシュイメージをpushするコンテナレジストリとして、使える人はDockerhubを使うのがいいとは思うものの、Dockerhubは無料プランだとレートリミットがかなり厳しく

【これはUnipos Advent Calendar 2021の2日目の記事です】 つい最近、EarthlyというDockerコンテナベースのビルドツールで、自分の開発しているGoのアプリケーションのMakefile/Dockerfile/docker-compose.yamlを置き換えたのでそれを記事にしてみる。 Earthlyとは github.com めちゃくちゃ雑に言うとDockerイメージをベースにしたビルドツール。 できることとしてはGoogleが作っているBazelに近い*1が、書き味はMakefile+Dockerfileに近く*2、独特の文法が少ない雰囲気。当然、言語やフレームワークに依存しない。まるでローカル環境でビルドをしているかのようにシームレスにコンテナ環境でビルドを実行できる。 Earthlyは書き味こそDockerfileと似ているが、Dockerイメージを作

discourse.elm-lang.org つい先日、数か月ぶりにElmのupdate話がでてきた。 Elmは0.19からほとんどメジャーバージョンアップしていない。最後のリリースは約9か月前にもなる。 この事実だけを知ると「Elmはもう終わったのか」「Evan*1は開発のモチベーションを失ったのか」と思われることがある。実際そういう話はネットでチラホラ見かける。確かに、フロントエンド開発言語のAltJSとして近しいTypeScriptやFlutterと比較すると、あまりにも機能追加され無さすぎるようにも見える。究極的には「何と比較するか？」という話だとは思うが、たしかにフロントエンド界隈的な観点ではElmは亀の歩みなのは間違いない。 変化するのはいいことだ... なんとなく肌で感じる人も多い事実として、世の中には"最先端を目指して変化するのはいいことだ"という暗黙的な統一見解が存在して

内容的には自分が過去記事で紹介した「データ指向アプリケーションデザイン」の内容を、もう少しとっつきやすくかみ砕いたような雰囲気。大学での講義を収録したっぽいものなので、ある程度初めての人でも分かりやすいかもしれない。 lms.gacco.org この講座の中で触れられているトピックは 分散コミット(2層コミット, 3層コミット) 定足数(クオラム, ビザンチン合意) 論理クロック データ複製の一貫性(強整合性, 因果整合性, 弱整合性, 結果整合性, ...) IaC(Infrastructure as Code) などが中心になっている。 定足数や論理クロックのあたりは、実際にアプリケーション開発をやっていて必ず登場する概念ではないが、クラウドプラットフォームから提供されるデータベース製品の仕様だったり、オーケストレータの挙動を理解するためにはある程度知っている方がいいのかなと思う。 一

うちのコンサルが「システムアーキテクチャを決めるためには、ビジネスアーキテクチャを先に固めることが必要」と言ったら、お客様が「事業構造の変化が激しすぎてビジネスアーキテクチャを固めることが難しい」と仰った。 そうだよなぁ。システムの寿命よりビジネスの寿命のほうが短くなってるのかも— ボム / SIer (@bombombomb2017) 2021年8月29日 これにめちゃくちゃ共感した。 よくあるアーキテクチャ設計では、ドメイン層と応用層を分離することで応用層におけるコントロール不能な変化をドメイン層に及ばないようにさせたりする。しかし、現実のプロダクト開発ではDBやフレームワークなどの応用層で起きる変化よりもドメイン層の変化のほうが圧倒的に多い。システムにおけるすべての中心にあり、あらゆるところから依存されているドメインが頻繁に変化するとなると非常にツライ。 とはいえ、ビジネス・アーキテ