はじめに この記事を書いている時点で 7.0 は alpha だが、触る機会があったので知ったことを書こうと思う。 一応 7.0 用のドキュメントページはあるけど、まだドキュメントの更新はされていないので役に立たないと思って良い (alpha なので当然)。 6.5 からの変更点を知るにはマイグレーションガイドが役に立つ。 Storybook 6.x までで使いにくかった点 以下のような構成の monorepo 考える。 それぞれのサブパッケージに @storybook/vue3 や @storybook/react をインストールすることになる。 ここで、build-storybook や start-storybook コマンドを使いたいのだがうまくいかない。 例えば、vue パッケージで start-storybook コマンドを実行しても react 用の storybook が起

はじめに 最初は一人の開発者としてスタートしても、ある時、技術面に責任を持つリーダーになったり、プロジェクトをうまく進める責任を持つマネージャーになったり、ピープルマネジメントをする存在になったり、あるいはそれらを兼任するというシーンがあると思う。 システム開発者の組織を率いる上で、こういうことが大事だというコンセプトや、それらを表現したキーワードは色々なところ耳にする事が多い一方で、それらの『実装』として具体的にどのように振る舞うかということについては多くの人が悩んでいると思った。 ソフトウェアで、色々な設計論などは知っているけど具体的な実装がどうなるかというところで悩むのと同じだなーと思い、年末年始という切りが良いタイミングなのもあり、チームが成長するために必要だと考えるリーダー・マネジャーの振る舞いについて思うところを書き出してみたいと思った。 前提となること 必要だと思う振る舞いを

はじめに TDD は Test-Driven Development を省略したもので日本語では『テスト駆動開発』という語が訳として与えられている。 TDD は現在多くの人に認知されていて、多くの実践者がいると思う。 私も TDD というスタイルが好きでよくそのような開発をする。 これまで、開発者の方と TDD について話すと『どうやる』の方に興味がいって『なぜ』の部分が置き去りになっていると感じることがあった。 例えば、『どうやればいいかわからない』といわれたのだが、TDDの典型的なお作法自体は知っているようなのだ。これはそもそも『なぜ』TDDをやりたいのかがわからないのではないのかと思った。 TDD はその名の通りテストでソフトウェア開発を駆動させるための開発スタイルだ。 なので、TDDをより効果的に行うためには、ソフトウェア開発がどのように行われるかを理解し、『なぜ』テストが開発を駆

Atomic Design は難しい Webフロントエンド開発をしている人で Atomic Design を用いた経験がある方に会った時は、必ず 『Atomic Designどうですか？』と聞くようにしています。 大体の方はちょっと苦笑いをしながら『やっぱり難しいですねぇ』とか『試行錯誤しながらで...』みたいなことを教えてくれます。 私もメインの開発をする際に Atomic Design という枠組みを用いています。そして、同様に色々と悩んだのですが、このあたりについて納得がいく解釈ができたと思っています。 そこで、私の思う Atomic Design の難しさや、そう思う原因、どうやってそれを解消するかという点について、https://atomicdesign.bradfrost.com/ を適宜参照しながら共有したいなと思います。 そもそも Atomic Design 何やねん。な方