LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog こんにちは、LINEの京都開発室でフロントエンド開発を担当している柴坂浩行です。 みなさんは仕事中などにパソコンで音楽を聴くことはありますか？ LINE MUSIC にはスマホアプリだけではなくWeb版アプリがあります。 私たちが開発しているWeb版アプリでは、JSフレームワークとして Vue.js を使用しています。 https://music.line.me/webapp/ これまでこのWeb版アプリには Vue2 が使われてきましたが、 2022年6月、私たちは Vue3 にアップグレードしたバージョンをリリースしました。 私たちのチームではWeb版アプリの機能開発と平行して、パフォーマンスの改善にも取り組んでいます。パ

春ですね〜、ユーザー体験を最高にするチームプロジェクトオーナーのsakitoです。 以前、kintone フロントエンドリアーキテクチャプロジェクトをスタートさせたブログ記事が公開されました。 今回はこの取り組みの一つのチームである「ユーザー体験を最高にするチーム 」について紹介します。 ユーザー体験を最高にするチームとは？ kintoneのフロントエンドリアーキテクチャのアプリケーション構成はMonorepoを採用し、チーム単位でオーナーシップを担うことを意識しています。開発者視点では分割されていますが、ユーザー視点では1つのkintoneアプリケーションであり、各チームが足並みを揃えてデザインの一貫性や品質を意識しながら開発を行う必要があります。そこで、各チームを横断してkintoneのユーザーにより良い体験を届けることを目標としたチームが「ユーザー体験を最高にするチーム」です。 ユー

こんにちは。ユーザー体験を最高にする活動をしているチーム、通称 Mantle チームのプロダクトオーナー(PO)をしている sakito です。 Mantle チームでは、ユーザー体験を最高にする活動の 1 つとして kinotne のデザインシステムを作っています。この記事では、デザインシステムを作る上での PO の役割や、PO がいることによる効果を実際の事例と合わせて紹介します。 デザインシステムは成長するものデザインシステムは作って終わりというものではありません。組織やプロダクトの変化に合わせて、デザインシステムも成長させていく必要があります。初期に設定した課題から導いた理想やロードマップも、その都度修正していく必要があります。 デザインシステムを作ることだけが目的になってしまうと、最初の「完成」をもってメンテナンスされないといったことも起こりえます。 デザインシステムにおけるオー

ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフーのデータソリューション事業のデザインを担当しています、水野 直と申します。 私は2020年にヤフーに新卒入社し、DS.INSIGHTというプロダクトを支えるDS.DESIGN SYSTEMの大規模改修を担当しました。 デザインシステムの難しさは、構築することよりも、プロダクトの成長に伴走してシステムを運用し、機能させ続けることにあります。サービスの改善のスピード、人の流動が激しい現代において、多くの組織がプロダクトを発展させていくため、車輪の再発明をしないようデザインの言語化、パターン化にリソースを注いでいるかと思います。 今回はNijibox主催「なぜデザインシステムが必要なのか」のイベントに登壇した際の内容をベースに、立

スタディスト 技術支援ユニットの笹木 (@s_sasaki_0529) です。 2022年上半期、およそ500コンポーネントを持つ Vue 2 プロダクトである Teachme Biz を、半年間に渡る単独作業を経て、 Vue 3 に移行することに成功しました。 本記事では、私達がどのようにして、機能開発は止めずにバージョンアップや破壊的変更への対応を行えたのかを簡単に振り返ろうと思います。 昨年の TypeScript 移行の次のステップとして、今年は Vue 3 移行を実現することにより、相乗効果でのフロントエンド開発体験の向上を実現しました。 モチベーションTeachme Biz をVue 3 に移行するモチベーションは概ね以下になります。 モダンブラウザに合わせてリアーキテクチャリングされた Vue 3 の恩恵を受けることVue 2 への機能追加・改修が 2.7 で終了してしまった

Webサービス開発の文脈で、モノレポ環境を作る方法について整理しました。 ※バックエンドもフロントエンドも全てTypeScriptで開発している前提 この記事を書いた背景 世間で言われる「モノレポ」がどのように達成されているのか知らなかった 参考記事を読んでると実現方法が異なっていたり、運用のイメージが見えなかったり、ベストプラクティスが分かりづらかった Turborepoのようなモノレポツールを導入すれば解決しそうだが、このツールが何をしてくれるのか理解できなかった モノレポ何も分からない………になった この記事ではモノレポに関連する仕組みを1つ1つ丁寧に把握し、最終的に理想的なモノレポ環境を実現することを目指します。 モノレポとは？ まずは用語の整理から。 モノレポを素直に訳せば「1つのリポジトリ」という意味でしかなく、1つのリポジトリで開発していればそれは「モノレポ」と呼べそうです。

はじめに 単一リポジトリで運用しているモノリシックな Web フロントエンドアプリケーションがある。 Vue.js を利用していていくつかのコンポーネントを実装している。この資産を利用して別のアプリケーションを構築したい。 ソフトウェアの内部としてはしっかりとレイヤを分けているが、Webアプリケーションを構成するための構造になっているのでビルド・CIなどはそれのためのものになっている。 したがって、コンポーネントなどをライブラリとして切り出していこうとするとビルドなどが複雑になる可能性が高いためそれぞれのレイヤを npm パッケージとして定義したい。 一方で、もともとが一つのアプリケーションであるため、今後も同時に更新される頻度も高いことが想定される。そのため、独立したリポジトリで運用するよりも monorepo で運用していこうと思った。 また、Vue 2 ベースのアプリケーションだけど

2022 年現在、Node.js 界隈は ESM (ES Module) への移行の過渡期であり、特に既存プロジェクトにおいては CJS (CommonJS) 構成であることがまだまだ多い。また、Pure ESM な npm パッケージは、CSJ プロジェクトからの利便性が悪く、dynamic import が必須で非同期化を強いられたり TypeScript の設定変更が必要だったりと面倒が増える。 そんな状況のため、広く使われたい npm パッケージを公開する場合、importでもrequireでも利用できるよう dual package 構成を取りたくなるが、定番手法が確立しているとは言えず、意外と面倒が多い。よく見るのは、tscやesbuild等で ESM 用と CJS 用の設定ファイルを用意してそれぞれ別ディレクトリに出力し、パッケージに両方同梱して conditional ex

LeanとDevOpsの科学の著者の一人であるNicole Forsgren氏が著者に入っているThe SPACE of Developer Productivity: There's more to it than you think - Microsoft Researchで提唱されているSPACEについて 以下記事も Four Keysだけじゃない開発者生産性フレームワーク 開発生産性の可視化フレームワークであるSPACEを活用するために、どのようなメトリクスをどう取得するかについて考えてみる 要約 SPACEは開発者の生産性を計測するためのフレームワーク 推奨されている測定指標のカテゴリ(本文ではディメンションと定義)の頭文字 satisfaction and well being performance activity communication and collaborati

「考え方が合わないなー」と感じた時は、相手と自分の持っている情報が揃っているかを疑ったほうがいいよね、という話を雑に書く。 たとえば「上司の理解がない」「部下の危機感が足りない」「同僚が慎重すぎる」みたいなやつ。なんでそんな考え方をするのかわからなくて憤りを感じるようなことがある。本当に考え方が合わないこともあるが、実は持っている情報量の違いによって思考結果が異なるだけで、思考回路自体に違いはなかったということも多い。 例を出してみる。プロダクトの1年後を考えてこれを絶対にやったほうがいいというボトムアップの提案が受け入れられなかったとする。 この時、実は相手は裏側で短期の売上目標を達成するために必死なのかもしれないし、ステークホルダーとのハードな交渉をしているのかもしれない。あるいは、プライベートで大変なことがあって考える余裕がないのかもしれない。逆の立場で見ると、実は提案する側はメンバ

みなさんこんにちは。 現在、フロントエンドでは宣言的UIが大流行しており、そのためのフレームワークも Vue.js をはじめ複数存在しています。 （React はフレームワークではなくライブラリです） 同種のソフトウェアや言語があれば、自分の好みを巡って意見を出し合うのはエンジニアの常でして。 それがパフォーマンスに関することであれば、無関心ではいられなかったりするわけです。 とはいえ Evan You もいうように特定のフレームワークやライブラリが現実世界のパフォーマンスの問題を銀の弾丸のように解決できるわけではありません。 フレームワークの開発者が数10ミリ秒単位でパフォーマンス改善に勤しむなか、利用する企業が（数100ミリ秒要するような）広告会社のスクリプトを迷いなく追加したりするのですから。 それでも僕たちは、パフォーマンスの話題をせずにはいられません。 だって、それがエンジニアで

Remember Javascript fatigue? It was 2015, and every few hours a new framework/boilerplate/build tool would burst onto the scene, one-upping the previous contender and shooting to the top of Hacker News. Eventually, React and Webpack became a de facto standard and a relative peace fell across the land. Frontend devs were able to relax and get real work done rather than frantically switching tools e

はじめに ごめんなさい。懺悔します。 ストーリーブック使ったことがないし、メンバーも少ないし、他に必要なライブラリがいっぱいあって、その使い方とかも調べないといけないし、そろそろ開発も進めないと進捗もやばいし、 正直ストーリーブックまで用意しなくてもよくね？と思ってました。 ぶっちゃけもうメンドウだし、別になくても開発に困らんでしょと。 だから必要なライブラリは大方いれたし、ストーリーブックなしで開発進めちゃいました。 そしたらすぐ気付いたんです。こまごました汎用的なコンポーネント作りだしたらね、 あれ？もしかしてこれってストーリーブックないほうがメンドイんじゃない！？ 自分が間違ってました。もう本当ごめんなさい。 というわけで、今回は Vite で作成した React アプリケーションに Vite 用の Storybookを導入する方法です。 つまづきポイントは1か所です。 Storyb

JavaScriptランタイムと言えばnode。 nodeの代替としてdenoがありますが、新たにbunというものを知ったのでふわっとまとめてみました。次のリンクは、Bunを知るきっかけとなったものです。 トップのコメントを一部抜粋(DeepL翻訳) 私が興奮していることのひとつは、bun install です。 Linuxでは、シンプルなNext.jsアプリの依存関係を、現在利用できる他のnpmクライアントよりも20倍ほど速くインストールします。 Bunとは 「速くて All in One な Javascript ランタイム」 内容を見ていく前に、Bunへの注目度がわかるグラフをご覧ください。 7月6日からほぼ垂直にStarを獲得しており、7月11日までの五日間で約20倍になっています。すごい。 ここからは私が気になった内容をピックアップして紹介していきます。 All in One B

爆速のアイコン検索サイトを作ったので、遊んでみてください。 (1) まずは自分が使いやすいアイコン検索サイトを作りたかったので作りました。(2) 様々なアイコンを爆速で横断検索し、サクッとアイコンをコピーできるようにしました。単純ながら意外とその部分が面倒なサイトは多い気がします。(3) また応用とメンテがしやすい実装にして、非常にサポート範囲の広い DB を GitHub Pages 上で構築しました。公開時点では 120+ のアイコンセットと、130,000+ のアイコンをサポートしており、サポート数も観測範囲では No.1 です。 開発動機 アプリ/サイト開発ではまずお世話になるであろうアイコン。私はこれまで Material Icons と Bootstrap Icons ばかり使っていました。これは検索が面倒だったからです。検索が面倒だと知名度の高いものだけに閉じてしまうので、良