kostumブログ

勉強したことやノート代わりのアウトプットに使っています。

Vue Fes Japan 2026に行ってきました

この記事はAIを用いて記載されています。

今年も Vue Fes Japan 2026 に行ってきました。
お聞きしたセッションについてのまとめです。

vuefes.jp

セッションメモ

キーノート

10:10–10:50

  • Vueは既存の使い方を壊さず、正しさとパフォーマンスを高める方針。Vapor Modeは同じAPIのまま、より高い性能を目指す。
  • Vue 3.6ではリアクティビティをAlien Signalsを基盤に再構築。多数のsignals実装を比較し、正確さと性能を重視している。
  • Vue Language ToolsではTypeScriptの公開APIを使い、Vueファイルを型チェックする仕組みを改善。vue-tscを介さず、TypeScript側からVueを扱える方向へ進む。
  • VoidZeroはOxcを中心にRust製のパーサー、コンパイラ、バンドラー、lintなどを整備し、Viteに統合してJavaScript全体の開発を速くする。
  • Cloudflare傘下になっても、Viteなどのツールはオープンソース、特定ベンダーに依存しない形、コミュニティ主導を維持する方針。今後はAIエージェントが使いやすいツール体験も探る。

デザインを開発する 〜 Vueで実現するデザインプロセス改善 〜

10:55–11:05

speakerdeck.com

  • AIでプロトタイプの出力数が増える一方、品質が低いままでは議論が進みにくい。高い忠実度と品質を両立するプロセスを目指す。
  • 機械的に判定できる領域と、人が判断する領域を分ける。前者は本番と同じVueコンポーネントをキット化して使い、生成・更新ごとの自動デザインレビューで品質を整える。
  • 人の判断が必要な論点はなくさず、画面上にピンを置いてコメントするなど、比較・レビューの往復を速くする。
  • 基準が明確なチェックは自動化し、人はより難しい判断に時間を使う。

契約で守るコンパウンドプロダクトのデザインシステム

11:05–11:15

speakerdeck.com

  • 機能追加を重ねるコンパウンドプロダクトでは、画面や実装がばらつきやすい。「誰が作っても同じ画面になる」ことを目標にする。
  • 構造、ルール、Single Source of Truthを定め、画面の形をスキーマの契約として表すスキーマ駆動UIを採用。
  • 画面ごとに異なるデザインシステムの版を使う状態を避け、同じ契約とコンポーネントを一貫して適用する。
  • 現状はReact向けコンポーネントが中心。今後はUIを拡充し、Vue対応も視野に入れている。

Astro is the new WordPress

11:15–11:25

  • WordPressの強みは、編集者が使いやすい編集画面、拡張できるプラグイン、所有するサイトに公開できること。一方、長い歴史を持つ基盤やプラグインの権限の広さには課題がある。
  • Astroのコンテンツ機能に、Astro製CMSの「EmDash」を組み合わせる構想を紹介。CMSの管理画面、コンテンツAPI、認証などをAstroサイト内に置き、同じドメインへ一緒にデプロイする。
  • 公開時に変更されたページだけをキャッシュから無効化でき、全体の再ビルドやWebhookを不要にする。テンプレートの内容を把握できるため、ページ上でのインライン編集も可能。
  • WordPressから記事・ページ・カスタム投稿タイプを移行する方法や、エージェントスキルを使ってテーマ・プラグインを移す考え方も紹介。

npmサプライチェーンが狙われた1年 ─ 金融システムで実践している防御策

11:40–11:45

Type-Safe URLs

12:50–13:20

  • URLの文字列をアプリ内で使う型へ変換するパーサーと、値をURLへ戻すシリアライザーを定義する。数値や真偽値のほか、日付・クラス・配列など、用途に合わせた型を扱える。
  • URLから値を読む際に検証し、失敗した場合はそのルートに一致しないものとして扱う。ページ内に散らばりがちな入力検証を、ルート側へ集約できる。
  • ファイルベースの自動ルーティングとresolverを使うと、ルート情報を生成して型付けできる。パスの構成やフォルダー規則もプラグインで調整可能。
  • URLを共有・保存できる利点を保ったまま、画面側の手作業の型変換と検証を減らす。

なぜその UI アニメーションは気持ちいいのか?

13:35–14:05

katashin.info

  • 気持ちよさの基本として、①操作にすぐ反応する、②動きが途切れずつながる、③ユーザーの意図に応える、の3点を挙げた。画面上のものを自分の感覚どおりに動かせると、直接触って操作している感覚が生まれる。そこに少しの「遊び」を加えると、楽しさや愛着につながる。
  • すぐ反応させるには、動き始めが速いイージング(ease-outやspringなど)を使うとフィードバックを感じやすい。ただし、アニメーションの完了まで次の入力を受け付けない設計は、慣れた操作を無意識に続けるユーザーの邪魔になる。短いデュレーションと、操作を止めない作りを意識する。
  • 動きの連続性は、別々のDOM要素へ切り替わる場面でも保てる。ルーム名の入力画面から確認画面へ移る例では、入力欄の文字を次画面の見出しへつなげ、位置や形が連続して見えるようにした。実装例として、startViewTransition()とview-transition-nameを使い、画像の拡大表示・閉じる動きを元のタイムライン画像へつなぐ方法も紹介。不要なクロスフェードは外し、拡大縮小の動きが主役になるよう調整する。
  • 操作意図に応える例として、ドラッグ中の指の動きに合わせて要素を動かし、指を離した後は勢いから軌道を予測する。予測位置が画面外ならそのまま飛ばして閉じ、勢いが足りなければ元の位置へ戻す。ドラッグ中に少し回転させるなど、基本の応答ができた後に遊びを加える例も示した。
  • 体験例には、画像の拡大・スライドで閉じる動きが印象に残ったTweetbotと、スワイプでアーカイブやスヌーズをするGoogle Inboxが登場。Inboxでは、気持ちよいスワイプがきっかけで、それまで使っていなかったアーカイブ操作をするようになったという。
  • 実装後は、操作した瞬間やアニメーションの途中、表示が切り替わる瞬間、指を離す瞬間を実際に触って確かめる。反応が遅くないか、動きがつながっているか、操作が意図どおりに進むか、入力を妨げないかを確認し、自分が気持ちよいと感じた動きも取り入れる。

Vue SFCから見直す正しいHTMLの守り方

14:20–14:50

records.yamanoku.net

  • 発表の問いは「Vue SFCのtemplateで、HTMLの正しさをどう検証するか」。HTMLの正しさを、①タグや属性などの字句的なルール、②要素の入れ子や内容モデルなどの語彙的なルール、③要素本来の用途に沿った意味論的なルールに分けて説明。
  • ブラウザは不正なHTMLも補正して表示するが、意図と異なるDOM構造になり、スタイル、SSRのハイドレーション、アクセシビリティに問題が出ることがある。意味のある要素を正しく使うと、コードの意図が伝わり、ユーザーエージェントも適切に扱える。
  • Vueコンパイラは構文上のパースエラーを検出する。一方、<div />のような自己終了タグをVue独自の解釈で受け入れるため、HTML仕様とのずれがある。Vue 3.4以降は不正な要素のネストを開発時に警告するが、コンパイルエラーにはならず、意味論的な使い方までは検証しない。
  • 静的解析の紹介では、eslint-plugin-vueはtemplateのパースエラーを検出し、Biomeは一部のHTMLルールとVue対応が進んでいると説明。Oxlintは発表時点でtemplate内のHTML検査がなく、フレームワーク対応のRFCが進行中。
  • 内容モデルを検証する選択肢として、HTML Living Standardに基づきVue parser/specも使えるMarkuplintを紹介。さらにVizeはVue・HTML・アクセシビリティを分けたルールを持ち、コンテンツモデルやコンポーネントをまたぐネストも検査できる。
  • すべてを一つのツールに任せるのではなく、プロジェクトに必要な検査を組み合わせる。決定論的な静的解析で基準を明確にすることは、AIエージェントに正しいコードを書かせる助けにもなる。

決定的なフロントエンドアーキテクチャがいい

15:05–15:35

  • 「何をどこに置くか」「依存の向き」「どう書くか」の判断を、必須・禁止・置き換えのルールとして明文化する。たとえば、1か所でしか使わない処理は共通フォルダーではなく利用箇所の近くへ置く。
  • utilsにはVue/Nuxt APIやComposable、API通信、外部状態に依存しない関数を置く。条件を満たす処理はutilsへ移し、満たさない処理をutilsに置かないようLintで制御する。
  • 状態を持つ処理は、非同期処理のローディング、複数状態の遷移、連動する状態の更新、WebSocketなど外部ライブラリのライフサイクル管理を例にComposableへまとめる。返す状態は読み取り専用にし、派生値はwatchで代入せずcomputedで表現する。
  • ページ固有のコードはページの近くにコロケーションし、別ページの内部ファイルへの依存や、ページ以外でのデータ取得をLintで制限する。公開コンポーネントは専用ディレクトリーにまとめ、内部実装を外から直接参照できない形にする。
  • ルールを適用すると、ファイルの置き場所から利用範囲が分かり、状態変更や依存方向も揃う。発表ではアーキテクチャに関するレビュー指摘が減り、フロントエンドに詳しくないエンジニアやデザイナーも変更に参加しやすくなったと紹介。
  • 一方、「何が一つの機能か」といった意味上の境界は機械的に決められない。ユーザーフローやドメインを整理して機能の境界を考え、複数ページで使う機能はNuxt Layersに分ける。Lintで判定できる事実と、人が設計する意味の判断を分ける。
  • 既存コードやライブラリーを調べてルールを言語化し、レビューで繰り返す指摘をLintに移しながら改善する。そこで生まれた時間を、要件整理、アクセシビリティ、性能、セキュリティなどユーザーに価値のある仕事へ回す。

JavaScriptエコシステムの境界線を問い直す

パネルディスカッション — 15:50–16:50

  • JavaScriptのランタイム、ツール、パッケージ配布、標準化を担う各プロジェクトが、どこまでを自分たちで作り、どこから既存の仕組みを使うかを議論。
  • npmの規模を考えると、JSRのような新しいレジストリも既存エコシステムとの互換性を保つ必要がある。新機能だけでなく、移行コストや利用者の資産も境界を考える要素になる。
  • Node.jsの小さなコアと互換性、Denoを企業中心からコミュニティへ開く運営、Oxcの性能と組み合わせやすさなど、各プロジェクトの背景と継続性が話題になった。
  • 結論を一つに定めるというより、目的・既存資産・運営体制に応じて境界を選ぶことが重要だと感じた。

Vue.jsのGitHubから学ぶ意思決定

16:35–17:05

speakerdeck.com

  • OSSの意思決定を追う資料として、Issue、Pull Request、RFCを行き来する。問題設定、選択肢、反論、採用理由や方針変更まで辿れる。
  • Composition APIの検討では、当初案への反応を受けて目的や位置づけが整理され、Options APIと並行して使えるAPIになった経緯を確認。
  • <script setup>は、SFCでの書き心地を改善する提案として生まれた。機能の完成形だけでなく、どの課題から始まり、議論でどう変わったかを見る。
  • OSSの設計を学ぶときは、現在のAPIだけでなく、そのIssueやPR、RFCを一つ開いて決定の過程を読む。

終わり

今年もありがとうございました。

JSConf JP 2025に行ってきました

はじめに

2025/11/16に開催されたJSConf JP 2025に参加してきました。

jsconf.jp

アクセス

会場:グラントウキョウサウスタワー 東京都千代田区丸の内1-9-2

Timetable

jsconf.jp

目次

横断組織が向き合うVisual Regression Testing — Chromaticは使い続けるべきなのか —

by Taiga Kiyokawa in トラックC 3F 301 at 10:10~10:20

VRT

  • Chromatic

    • 上限を超過した分は重量課金
  • クラウドの開発状況

    • chromaticを使用し始める
    • あっという間にコストが爆増
    • 予算を大幅に超過する
  • どうする?

    • 戦略を明確化。どこまでコストをかけるべきか。
      • なんぼあっても良いと思える。
      • VRTは粒度の違いというよりは検証観点での違い
      • 現状考えている戦略:
        • 1:VRT以外でカバーできるのか?
          • storybook/test-runnerとchromatic
            • interractiveなテストはchromaticは向いていない
          • パターンレベルをchromaticが担う
          • デザインシステムは
        • 使い続けるべき?
        • 利用規模ごとに決めるのが良さそう
      • 節約術:
        1. turbosnapを有効にする
          • 体感3割のコストかと
        2. デフォルトでスナップショットを無効化
          • 各storybookで設定
        3. 複数の状態を1つのstoryにまとめる
        4. ワークフローの実行を制御する

AtomicsAPIを知る

by TOMIKAWA Sotaro inトラックC at 10:20~10:30

  • メモリ空間を共有する

    • SharedArrayBuffer
      • workers間で共有されたメモリ空間を操作する
      • バイナリしか使えないので、数字しか扱えない
    • データ同期問題もある
  • Atomics API

    • 不可分操作を行うためのAPI
    • 書き込みを通知できる
    • 仕様はECMA Script
    • JavaScriptエンジンにも実装されている
    • が、悪用される可能性があるので今は無効化されている。
      • 保護されたコンテキスト内であること
      • オリジン同士が分離されている
    • Web Assembly
  • Party town

    • 本来の使い方ではないが、メインスレッドを待たせることができる。

調べてみた:

developer.mozilla.org

モダンJSフレームワークのビルドプロセス 〜 なぜReactは503行、Svelteは12行なのか 〜

by Maple in トラックC at 10:30~10:40

  • Reactとsvelteで同じコードをビルドすると全く異なる
  • svelteのバンドサイズが小さい理由:
  • 5つの抽象化層
  • React Copilorの登場によって、レンダリング周りが最適化される。

Error.prototype.stackの今と未来

by progfay in トラックC at 10:40~10:50

speakerdeck.com

  • Error.prepareStackrace: スタックトレースのテンプレートを書き換えることができる。
  • JSエンジン(ランタイム)によって、テンプレートが異なる!→ 標準化の動き
  • proposal-error-stacks

From Chaos to Harmony: A History of JavaScript(混沌から調和へ ― JavaScriptの歴史)

by Allen Wirfs Brockin トラックB at 11:10~12:00

https://dl.acm.org/doi/10.1145/3386327

inzkyk.xyz

Next.js Caching - Legacy, Improvement, Re-Architecture

by rung Vo in トラックA 7F パーティースペース at 11:10~11:40

JavaScriptにおけるasync/await呼び出しのスタックトレースの困難と実装

by Sosuke Suzuki in トラックB at 13:30~14:00

speakerdeck.com

Winter TC: Standards forserver - side runtimes

by Andreu Botella in トラックC at 14:10~14:40

wintertc.org

www.publickey1.jp

Running TypeScript Natively in Node.js

by Marco Ippolito in トラックC at 14:40~15:10

nodejs.org

Bringing Songs to Life: Music Visualization with JavaScript

by Ursula Cervantes in トラックA at 15:20~15:50

Shrink Supply Chain Risk in JS

by Ruben Bridgewater in トラックA at 15:50~16:20

V8: from <script> to call $rcx

by Olivier Flückiger in トラックA at 16:30~17:00

  • Maglev
  • Turbolev

Technical Discussion with TC39

by various in トラックA at 17:10~17:30

SponsorLT

by ? in トラックA at 18:10~19:10

技術的福祉の受容、および Web 開発との「出会い直し」

by Jxck in トラックA at 19:20~20:00

最後に

英会話、やるか...

Vue Fes Japan 2025に行ってきました

キーノート

by Evan you in FitFits with hacomonoトラック at 10:10

去年よりもダウンロード数が増えてきている。

Alien Signal

もう成熟したフレームワークだと思っている。
安定性とエコシステムの安定。

内側から改善。内部の再実装。
パフォーマンスの最適化を行なっている。

AlienSignalは様々なフレームワークで使われている。

Vapor mode
コンパイル戦略。
vaporによって合ってアウトプットとされたものはシンプルで行数が少ない。

hydration, kepalive, teleport, transition, async, component, src,

パフォーマンス
vue3.6 beta before eoy
language tool
hybridmode が常にon
Insiderバージョンが自由に使える。

void0について
なぜビルドツールが必要なのか。
アプリケーションの規模が大きく複雑化してきた。規模を拡大しようとした時に様々な問題を解決する必要がある。
OGsJSでJSを書くツール babel, acorn, npmなど。 The next gennative languageでjsを書く swc, oxc, bun

void0ではRustを使っている。
Native
まだ断片的。

boidzero -> vite vitest rollldown oxc

new どのライブラリも成長している。 oxlint: oxcを基にしたlinter。tsは遅い。oxlintは高速。何千ものファイルを数秒で。
biome、prettierよりはやい->oxfmt alpha版

Rolldown
より機能的に、だけど高速。

exbuildより早くrspackよりはやい。
バンドルサイズの最小化

vite
vite7.0
react Servercomonentのサポート

vitest
4.0
browser modeが安定版に。
VRT

Rolldown-vite

vite dev full bundle mode
起動がはやい。フルバンドルは。
変換プラグインがJSで追加の解析を実行している。Rust側にすでに存在しているASTをJSに渡すこと。ただ遅い。メモリのチャンクを取得してクローンを作成せずにJSに直接送信することで速度を改善。
ただ、ガベージコレクションが大きくなる。
rolldown
fast magic-string変換
JavaScript ただ操作するだけ
magic-string変換をrolldownで
rustからASTを取得traverse AST
magic-stringメソッドを呼び出す

vite+
web toolchain
nextstep

vite+ Plugin API
vite+のさまざまなところにフックできる。
Agemt Mode AIアシスタントとの共同が増えることを見越して

Licencsing
企業で持続可能なものにするため。
これまでのOSSはずっとMIT

webpack依存からの脱却!快適フロントエンド開発をViteで実現する

by Nobuaki Kambe in FitFits with hacomonoトラック at 10:55

vuefes.jp

speakerdeck.com

alien-signalsと自作OSSで実現するフレームワーク非依存なロジック共通化の探求

by Aose Yuu in FitFits with hacomonoトラック at 11:05

vuefes.jp

自作ライブラリ化という手段を用いて、プロダクトによらない処理として管理。

regrea vueでcomposableを使ったノリでかける。

フレームワークを超えて:次の10年のWebを築く

by Daniel Roe in FitFits with hacomonoトラック at 12:50

vuefes.jp

どうやって最高のビルドをすることができるのか?

Nuxtを使うこと、ではない。

ツールによって自分自身を定義しているのは間違い。
重要なのは作る人。

フレームワークの採用
フォント
Nuxt/fonts
楽に開発することができる。->フレームワークをう買う理由。

fontless
ベストプラクティスを共有できる。

フレームワークをembrace
Nuxtは特定のバンドラに依存しないように作っている。

experimental
シングルチャンクにする
非同期データハンドラを静的サイトをNuxtで作成するときに役立つ
Javascriptの削減ができる。

tighter vertical integrations
vercel cloudflare
nitro, sveltekit, astro

build with other
他の人と協力して作る。
どれに貢献したいか、で決めても良いかもしれない。

Nuxter

some spoilers
vite environment api
vite builder workflow
nuxtv4.2→プッシュされた!
nuxt-rs

5年間におけるVue言語ツールの進化

vuefes.jp

by Johnson Chu in FitFits with hacomonoトラック at 13:35

veturの問題
tsserverが遅い
十分な型安全性がない。

TS language serverの知識が必要で、新しく作った。

how

New Project Volar

5年かけて6つの問題を解決した。

Single LSP server
パフォーマンス問題

Multple LSP Servers セマンティックフィルタ、構文server

TS Plugin 巨大なメモリ使用

Take Over Mode Built-in TSextension is disabler Hyblid mode with named Pipes

Hybrid mode with request forwardiing

rstoreとローカルファーストなストア構築の課題

vuefes.jp

by Guillaume Chau in FitFits with hacomonoトラック at 14:20

rstoreとは
data management solution 相互接続されたコンポーネントが多数あるため、データ管理は大切。
ヘッダーのアバターなど
これを一元管理できると嬉しい。
フレームワーク

コレクションのスキーマを持つインスタンスを作る。piniaとの違い。
型安全。

どうやって動くのか
コレクションAPI -> Plugins
そのため、一種のフレームワークのようなものである。
Nuxt devtoolsでも導入されている。
queryでsubscribeし、同一サーバーでリアルタイムに値を変えることができる。
オフラインの復旧からも対応している。
 ローカルのindexed DBを使っている。

Vue3.6時代のリアクティビティ最前線〜Vapor/alien-signalsの実践とパフォーマンス最適化〜

by 平沼 真吾 in フューチャーアーキテクツトラック at 15:05

vapor mode
vdomを削除
直接DOMを変更すると、再計算がおこる。
VDOMにも問題点あり。
 メモリオーバーヘッド
 仮想DOMをコピーして比較するのでその計算コストがかかる。  バンドルサイズの増加 vu3でもVDOMの問題点は残ったまま。
-> vapormode

solid.jsと共通の哲学。
vue独自の進化

alien-signals
refやreactiveのメモリ改善
パフォーマンスの改善
computedに紐づいている場合に効率化できる

なぜ早いのか
実装レベルの最適化

vapormodeの注意点
optionsAPIでは使えない

設計思想

zenn.dev

【パネルディスカッション】フロントエンドの未来を語る─React/Vue.js/Svelteが見据える次の10年

vuefes.jp

by Evan You, Dan Abramov, dominikg, Kia King Ishii in FitFits with hacomonoトラック at 15:50

IntroducingViteDevTools

vuefes.jp

by Anthony Fu in FitFits with hacomonoトラック at 17:20

vite+に移行予定。
vitestと紐づく。

なぜDevtoolが必要なのか。
Developer Toolsとして使う。Nuxtとか
DevTools:ツールをよりよく使うためのツール。こっち。

良いツールの原則
直感的な設計:ユーザーの期待を裏切らない。新機能が発見しやすい
透明性:内部状態が把握しやすい。透明性
組み合わせ:分離されたモジュール
拡張性

透明性:
UnoCSSから始まった。
内部状態を表示するツール
Nuxt Devtools, Vitest UI, ESLint Config Inspector, Node modules Inspector(Node modulesの関連性も可視化した。)

ビルド概要
build mode
Bundle List
FileTree
Module Graph
Module Rransformation Flow

Code
Chunk情報
 Chunkは大きくない方が良い。最適化の自のための情報を表示する。
 Plugins プラグインをリストして表示
 Plugin Hooks どのプラグインファイルがボウルネックになっているかとなっているか可視化
Chunking
Bundled Packages 重複するPackageを検出する。
PackageSizeGraph
可視化だけではない。
フレームワーク非依存

拡張性
Viteは拡張性を重視している。
DevToolsKit

Vite DevTools Plugin
VitePluginの上位集合

目標と展望
より良い透明性を実現し、探索しやすくすること。

可視化
分析と提案
ビルド
ビルドスナップショット
Vite Plusとの統合
DevTools Kit
バンドル分析

DevToolsKit
開発モード
フルバンドルモード

終わりに

最後までお読みいただきありがとうございました。 ノート部分は、あくまで私が記載したものなので、間違っていることを記載している可能性があります。なので話半分で読んでいただければと思います。

自宅NASサーバーの構築方法

目次

こんにちは。

自宅NASサーバを構築したいと思いました。 色々と調べながらやってみたのですが、なんだかうまく構築できなかったので、順序立てて一つずつ対応していくためにやり方をまとめました。

せっかくなので記事としてまとめ、誰かのお役に立てれば良いかと思います。

要件

今回NASサーバを構築する際において、以下の要件を満たすことにしました。

  • OS: Ubuntu
  • 家にある使われていないPCを使う
  • RAID1を採用する
  • 管理・運用のためにSSH接続できるようにする
  • ファイルサーバとして他PCから共有ができるようにする

実践

というわけで、インストールから始めます。

必要なもの

その前に、NASサーバを構築するために必要なものを記載します。

  • PC
    • ファイルサーバにするためのパソコン。
    • 有線のキーボードとマウス
  • HDD × 2
    • データを保存するためのHDD。RAID1を構築するため、2つ用意します。
  • USB 16GB以上
    • Ubuntuをインストールするために必要です。後述しますが、ISOファイルを書き込む都合上、16GB以上の容量が必要になります。

Ubuntuのインストールのための準備

UbuntuをOSとして用いるため、まずはUbuntuをダウンロードします。

Ubuntuを入手する | Ubuntu | UbuntuUbuntuを入手する | Ubuntu | Ubuntu

Ubuntuは、その用途に合わせてさまざまな種類をダウンロードすることができます。 今回の場合、用途がファイルサーバなので、Ubuntu Serverを選択しても良いのですが、GUIを備えたUbuntu Desktopを選択します。

Ubuntu Desktopをダウンロードすると、ISOファイルが取得できます。
ISOファイルとは、1つの光学ディスクに保存されるデータを一つにまとめたデータ、のことです。 つまり、このISOファイルがUbuntuOSを使うためのひとまとめのデータということです。

次に、このUbuntuOSをPCにインストールします。
しかし、このISOファイルをどうやってPCにインストールすれば良いのでしょうか。
ここでは、USB Boot機能によるインストール、つまり、USBからOSを起動してインストールを行なってみます。

USBからBoot起動させるには、まずUSBにISOファイルを書き込む必要があります。
この書き込み用ソフトウェアにRufusがあります。

rufus.ie

なので、Rufusをダウンロードします。

Rufusを起動する前に、USBをフォーマットしておきましょう。
フォーマットしたら、USBをPCに挿したまま、Rufusを起動します。
PCにUSBだけを挿していれば、「デバイス」項目にそのUSBが選択されているはずです。
ブートの種類の横にある「選択」をクリックし、先ほどダウンロードしたISOファイルと選択します。その他の設定はそのままとし、「スタート」をクリックしましょう。

「スタート」をクリックすると、ハイブリッドISO形式のイメージを検出したことによる書き込む形式の確認ダイアログが表示されます。
ここでは、推奨されている「ISOイメージモードで書き込む」を選択し、「OK」をクリックします。
その後、データ消去の確認ダイアログも「OK」とし、書き込みを開始します。

この書き込みは10分くらいかかるので、気長に待ちましょう。

書き込みが完了したら、NASにしたいPCに差し替えましょう。

UbuntuOSのインストール

さて、Ubuntu OSのインストールの準備が完了しましたので、次はUbuntuOSのインストールを行います。

NASにしたいPCはシャットダウンしておきます。

そして、RufusによってUbuntuが書き込まれたUSBをPCに挿しておきます。
次に、そのPCの電源を入れるのですが、USB Boot起動をさせるために、PCをBIOS起動させます。
BIOS起動させるための方法は、PCメーカによってさまざまなため、以下のサイトを参考に起動方法を調べましょう。

www.tenorshare.jp

私の場合はASRockのマザーボードを使っているので、起動した時のメーカーロゴ画面でF11キーを押下してBIOS画面を起動しました。

BIOSに入ると、bootデバイスを選択する画面になるので、USBを選択しましょう。
すると、Ubuntuのインストール選択画面に入るため、「Try or Install Ubunt」を選択して、Ubuntuをインストールします。

そうすると、UbuntuOSのGUI画面が表示されます。
その画面の右下にインストールショートカットがあるので、それをダブルクリックしてPCへのインストールを開始します。

インストールでは、ウィザードに沿って進めてください。ただし、インストールするハードディスクは、RAID1用のHDDにはインストールしないように注意しましょう。

インストールが完了したら再起動をして、そのときにUSBを抜いておきましょう。

初期設定

SSH

NASを構築する上で、さまざまな設定を行なっていきます。 が、このままNASとして活用していくPCで操作するのは、開発者体験があまり良くありません(NAS PCがディスプレイと場所を占有してしまうのは他の作業ができなくなってしまうので)。
なので、私の場合は別のMacBookから無線アクセス、つまりSSH接続して設定していきます。

再起動したNAS PCでログインし、インストール時にWi-fiを設定していない場合はWi-fiを設定します。この後、パッケージの更新を行うときに、ネットワークが繋がっていないと更新ができないので気をつけてください。

次に、画面左下のアプリケーションメニューから「Terminals」を起動します。 そして以下を実行して、パッケージの更新を行います。

sudo apt update
sudo apt full-upgrade -y

さらに、SSH接続のためのパッケージをインストールします。

sudo apt install openssh-server

この後、NAS PCを再起動します。

%% 再起動コマンド %%
> sudo reboot

再起動が完了したらターミナルを開いて、以下のコマンドを実行してSSHの状態を確認します。

admin@file-system:~$ sudo systemctl status ssh
[sudo] password for admin:
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Sat 2025-06-21 21:10:18 JST; 1h 40min ago
TriggeredBy: ● ssh.socket
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1180 (sshd)
      Tasks: 1 (limit: 6931)
     Memory: 4.4M (peak: 20.6M)
        CPU: 261ms
     CGroup: /system.slice/ssh.service
             └─1180 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

上記のようになっていれば(Active: active (running))、正常に起動しています。
また以下のコマンドを実行して、NAS PCのIPアドレスなども調べておきましょう。

admin@file-system:~$ ifconfig

...

wlp7s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1440
        inet 192.168.0.215  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::4f83:1976:f576:fa2c  prefixlen 64  scopeid 0x20<link>
        inet6 2001:268:738d:eab6:a7be:cc83:caf6:e76c  prefixlen 64  scopeid 0x0<global>
        inet6 2001:268:d2df:5a2f:49a9:cc42:c170:db2e  prefixlen 64  scopeid 0x0<global>
        inet6 2001:268:d2df:5a2f:86:535e:854a:7fb8  prefixlen 64  scopeid 0x0<global>
        ether 58:a0:23:db:80:ad  txqueuelen 1000  (Ethernet)
        RX packets 62371  bytes 9698686 (9.6 MB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 27767  bytes 3653553 (3.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

この192.168.0.215にアクセスすることになります。
このIPアドレスは、再起動するたびに変更されてしまいます。 そのため、Ubuntuのネットワーク設定でIPアドレスを固定するように設定しておきましょう。

以上、NAS PCでの操作はここまでになります。これ以降はMacbbook PCでの操作になります。

NAS PCへSSH接続できるか確かめてみましょう。
Macbook PCで、ターミナルを開きます。また、Wi-fiはNAS PCと同じネットワークを使用しておきましょう。
以下のコマンドを実行すると、今までの設定がうまくいっていればログインできるかと思います。

❯ ssh admin@192.168.0.215
admin@192.168.0.215's password:
Welcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.11.0-26-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

Expanded Security Maintenance for Applications is not enabled.

0のアップデートはすぐに適用されます。

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

Last login: Sun Jun 22 21:06:47 2025 from 192.168.0.220

これで、SSHのインストールは完了です。

おまけ

SSHを使用してログインするとき、ユーザー名やIPアドレス、パスワードをいちいち入力するのは面倒です。
なので、より安全なログイン手法であるキーペアを使ったログインとショートカットコマンドの作成を行います。

まず、キーペアを作成します。 以下を実行するとキーペアが生成されます。

ssh-keygen

生成されたキーペアは、サーバー側に登録する必要があるので、さらに以下を実行します。

ssh-copy-id {ユーザー名}@{IPアドレス}

ここまで行うと、以下を実行することでキーペアを使ったログインが可能になります。

ssh -i {登録したキーペアのパス} '{ユーザー名}@{IPアドレス}'

最後に、~/.ssh/configに以下の設定値を記載することで、ショートカットコマンドを登録することができます。

Host {コマンドキー}
    HostName {ホスト名} 
    User {ユーザー名}
    Port (ポート番号)
    IdentityFile {鍵へのPATH(例えば~/.ssh/hoge)}
さらなるおまけ

SSHにログインすると、常に以下のテキストが表示されます。

Welcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.11.0-26-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

Expanded Security Maintenance for Applications is not enabled.

0のアップデートはすぐに適用されます。

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

このテキストは、/etc/update-motd.d/内にbashファイルを含めることで、好きなテキストを表示ことができます。
例えば、/etc/update-motd.d/01-welcomeを作成し、以下を作成してみます。

#!/bin/sh
printf "\n"
figlet "WELCOME TO FILE-SERVER" | /usr/games/lolcat -f

また、NASサーバで以下をインストールしておきます。

sudo apt install figlet lolcat -y

このように設定すると、以下のように表示することができます(FILE-SERVERのところは色がついています)。

Welcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.11.0-26-generic x86_64)

__        _______ _     ____ ___  __  __ _____
\ \      / / ____| |   / ___/ _ \|  \/  | ____|
 \ \ /\ / /|  _| | |  | |  | | | | |\/| |  _|
  \ V  V / | |___| |__| |__| |_| | |  | | |___ _
   \_/\_/  |_____|_____\____\___/|_|  |_|_____( )
                                              |/
 _____ ___ _     _____     ____  _____ ______     _______ ____
|  ___|_ _| |   | ____|   / ___|| ____|  _ \ \   / / ____|  _ \
| |_   | || |   |  _| ____\___ \|  _| | |_) \ \ / /|  _| | |_) |
|  _|  | || |___| |__|_____|__) | |___|  _ < \ V / | |___|  _ <
|_|   |___|_____|_____|   |____/|_____|_| \_\ \_/  |_____|_| \_\


 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/pro

Expanded Security Maintenance for Applications is not enabled.

0のアップデートはすぐに適用されます。

Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status

RAID1設定

SSHによる設定ができるようになったところで、RAID1構成を構築していきます。
以下は、NASサーバーにログインして行なってください。

まず、対象となるディスクを確認するために、以下のコマンドを実行してください。

sudo fdisk -l

すると、以下のような出力が見られます(以下は、すでにRAID1を構築してしまった後の出力のため、少し違うところがあるかもです)。

Disk /dev/sdb: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: ST8000DM004-2U91
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4BBFCFF6-2C8B-4FC1-B8F3-7B36208CEBA6

Disk /dev/sdc: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: ST8000DM004-2U91
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 75BBFE6C-ED6D-4FB4-811E-DFAA2790B2D3

自分がどのHDDを用意したのか把握しておくと、判別しやすいですね。
上記の場合では、/dev/sdb, /dev/sdcが対象のディスクになります。
また、構築の前に、対象となるディスクにデータが含まれていないか確認しておきましょう。RAIDを作成するとき、初期化が行われるので、重要なデータはすべて削除されてしまいます。

まず、partedコマンドを使用して、gptで全容量を指定したパーティションを作成します。gptなどについては、こちらを参照してください。

sudo parted --script /dev/sdb "mklabel gpt"
sudo parted --script /dev/sdc "mklabel gpt"
sudo parted --script /dev/sdb "mkpart primary 0% 100%"
sudo parted --script /dev/sdc "mkpart primary 0% 100%"

続いて、パーティションにraidフラグを付与します。これを付与しないとカーネルにRAIDアレイと認識されないようです。

sudo parted --script /dev/sdb "set 1 raid on"
sudo parted --script /dev/sdc "set 1 raid on"

先ほどのfdiskを実行するとフラグが立っているのが確認できます。

sudo fdisk -l

Disk /dev/sdb: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: ST8000DM004-2U91
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 483BCA84-082D-40A9-9014-9D31985E3C7A

Device     Start         End     Sectors  Size Type
/dev/sdb1   2048 15628052479 15628050432  7.3T Linux RAID


Disk /dev/sdc: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: ST8000DM004-2U91
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 6A7AB752-5E96-4954-9E61-A751D03BA223

Device     Start         End     Sectors  Size Type
/dev/sdc1   2048 15628052479 15628050432  7.3T Linux RAID

次に、RAIDを構築するために、mdadmパッケージをインストールします。

sudo apt install mdadm

インストールが完了したら、以下のコマンドを実行し、RAID1アレイを作成します。

sudo mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1

このコマンドによって、/dev/sdb1, /dev/sdc1を使用して新たに/dev/md0というRAIDデバイスを作成しています。
作成には、HDDの容量によって非常に長い時間がかかる場合があります。例えば、私の場合は8TBで12時間ほどはかかっています。
進捗を確認するには、以下のコマンドで確認できます。

cat /proc/mdstat

さて、RAID1の作成が成功したら、今度はこのRAID1構成を永続させる設定を行います。
まず、現在のRAID構成をmdadm.confに保存します。

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

次に、RAIDアレイにファイルシステムを作成します。以下の場合は、ext4として作成しています。

sudo mkfs -t ext4 /dev/md0

さらに、マウントポイントを作成します。マウントポイントとするディレクトリ名は自分の好きな名前にしてください。

sudo mkdir -p /mnt/file-server

そして、マウントしてみます。

sudo mount /dev/md0 /mnt/file-server

動作確認がうまくったら、自動マウントのために/etc/fstabにUUIDで追記を行います。

sudo blkid /dev/md0

出力されたUUIDをもとに、以下のように/etc/fstabに以下を記述します。

/dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /mnt/file-server ext4 defaults 0 0

最後に、

sudo update-initramfs -u

を実行して、ブート時にinitramfs(初期 RAM ディスク)から読み込ませるようにします。
これで再起動した後でも、RAID1が自動でマウントされるようになります。

WindowsPCの共有設定

このエントリもそろそろ終わりに近づいてきました。 最後は、WindowsPCからの共有を可能にしていきます。

今ままで、データを保管する場所を作成しましたので、ここからはファイルサーバとして使うための設定を行なっていきます。

ファイルサーバを構築するためには、sambaというパッケージを使用します。
以下のコマンドを実行して、sambaをインストールします。

sudo apt install samba -y

これによってsambaがインストールされますので、今度は設定を記載していきます。
sambaの設定ファイルは、/etc/samba/smb.confに記載します。なので、以下を実行して設定を記載してください。

sudo nano /etc/samba/smb.conf

[file-server]
comment = file-server
path = /mnt/file-server
browseable = yes
writeable = yes
read only = no
guest ok = no
create mode = 777
directory mode = 777

そして、Sambaでファイル共有を行う場合は、Sambaユーザーを作成する必要があります。そのため、Linux上に通常のユーザーを作成し、そのあとでSambaのパスワードを設定します。

sudo adduser hoge
sudo smbpasswd -a hoge

最後に以下のコマンドを実行してsambaを再起動して設定を反映させます。

sudo systemctl restart smbd

これによって、上記で固定したIPアドレスにWindowsからアクセスし、先ほどのユーザー名tとパスワードを入力すれば、Ubuntuのfile-serverへアクセスできます。

終わり

これで自作NASサーバの構築は終わりになります。
ネットで最初に出てきた情報だけだと、RAIDの永続化やWindowsの共有設定など上手くできませんでした。
上記にまとめた内容で、自分はうまく構築することができたので、皆様の役に立てれば幸いです。

また、最後にこの構築方法に至るまでに活用させていただいた参考文献を記載しておきます。上記の方法でうまくいかない場合は、参考にしてみてください。

それでは、最後までお読みいただきありがとうございました。

参考

qiita.com

qiita.com

qiita.com

qiita.com

qiita.com

www.linux.digibeatrix.com

scrapbox.io

qiita.com

minokamo.tokyo

zenn.dev

JSConf JP 2024に参加してきました。

はじめに

2024/11/23に開催されたJSConf JP 2024に参加してきました。 そこで参加できたセッションについて、まとめとノートしたこと(少ないですが...)、感想をアウトプットさせていただきます。

jsconf.jp

アクセス

会場:九段坂上KSビル 〒102-0073 東京都千代田区九段北1-14-6 九段坂上KSビル

Timetable

jsconf.jp

目次

LT:Promise.try:シンプルで強力な同期/非同期統合の未来-実装の深層とPromiseの進化

by saku in トラックB 3F 301 at 10:10~10:20

sakupi01.github.io

  • NewPromiseCapabilityがキモ。
  • Promise.tryはJSでかkれている。
  • abortControllerはDOM API。

わざわざPromiseでラップする必要がなくなるので便利そう。

LT:JavaScriptを支えるエコシステム(漫才)

by ECMAボーイ (@uhyo_) and # ECMAボーイ (@shqld) inトラックB 3F 301 at 10:20~10:30

docs.google.com

  • おかん時々おとん。

パッケージマネージャやバンどらの特徴を面白く捉えた漫才だった。

LT:Storybookとの上手な向き合い方を考える

by りんたろー in トラックC 3F 302 at 10:40~10:50

speakerdeck.com

途中から聞けた。 開発後半になると形骸化してしまうStorybookの向き合い方を教えてくれました。

LT:あなたの知らないFunction.prototype.toString()の世界

by mizdra in トラックC 3F 302 at 10:40~10:50

speakerdeck.com

ハック的な使い方。かと思いきや、みんな知ってるライブラリの中でも使われているのに驚いた。最終的には容量用法を守って使う必要があるとのことですが、面白い使い方を知れました。

WebAssemblyUnleashed:PoweringServer-SideApplications

by Chris Fuentes in トラックA 7F パーティースペース at 11:10~11:40

{資料}

頑張って英語(翻訳無し)を聞いてみましたが、分かりませんでした。。。すみません。。。

CreatingFast-FeelingWebApps

by rung Vo in トラックA 7F パーティースペース at 11:10~11:40

trungvose.notion.site

こちらは事例とかを動画で見せてくれたため、少し理解ができました。 Webアプリを早く見せるための妙を紹介してくれました。 ローディングアニメーションやライブラリを使ったり、キャッシュを実装することで早くしているのかな、と思います。

BuildingAIappswithJavaScript

by Aileen Villanueva Lecuona in トラックA 7F パーティースペース at 13:10~13:40

jsconf.jp

  • Data
    • テキスト
  • SPLIT
    • テキストを適切なObjectへ変換?
  • EMBEDDING
    • コード化(parse)
  • STORE
    • データの保存?[suspense]
  • RETRIEVE
    • KEYWARD
    • ○SEMANTIC
  • GENERATE

頑張って英語(翻訳無し)を聞いてみましたが、分かりませんでした。。。すみません。。。

WhyBuildaSecureSupplyChainManagement?

by VJ in トラックA 7F パーティースペース at 13:40~14:10

企業ブースの方に寄っていたら、時間を過ぎてしまいました。

リアルアセットとWebのシームレスな活用のためのパスキー

by maxmellon (Kento TSUJI) in トラックB 3F 301 at 14:20~14:50

{資料}

パスキー導入のための東急株式会社さんの取り組みを紹介してくれました。
パスキーの導入の仕方についてはもちろんですが、そのパスキーをどうやってユーザーに使ってもらうのかが大変だったようです。

JavaScriptのモジュール解決の相互運用性

by berlysia in トラックB 3F 301 at 14:50~15:20

speakerdeck.com

Import PathおのPath解決方法について。 cjsとesmのどちらかの方法を使うことになるのかをお話ししてくれました。

ModularMonolithMonorepo

by 坂本結衣(yui_tang) in トラックB 3F 301 at 15:30~16:00

speakerdeck.com

Modular Monolith Monorepoを実現するためにやったことをお話ししてくれました。 かなりの量のルールを決めたDesignDoc、pnpmをうまく使うことで実現されていました。

JavaScriptのイテレータとイテラブルの概要と課題、未来

by Sosuke Suzuki in トラックB 3F 301 at 16:00~16:30

{資料}

JavaScriptのIteratorについて分かりやすく説明していただけました。 ArrayやMapなど、for文でループすることができるものは、イテレータの機能が用いられているのは目から鱗でした。 e18eによるとジェネレータは最適化されていないため使用しない方が良い、と書かれていた気がしましたが、ユースケースに記載がある場合は、逆に使った方が良いかもと思いました。

SponsorLTx12

by ? in トラックA 7F パーティースペース at 16:40~17:50

スポンサーをしていただけた各企業様の会社紹介やLT。

啓蒙者の視点で振り返るウェブ

by Eiji Kitamura / えーじ in トラックA 7F パーティースペース at 17:50~18:30

API開発時の公開やためになるお話を聞けました。 Web Audio APIは、自分でもかなり勉強したことのあるAPIだったので、非常に興味深かったです。

まとめ

以上、私が参加しようと思っていたセッションのノート、感想でした。

JSConf JPの参加は初めてでしたが、楽しかったし勉強にもなりました。 運営の方、発表してくださった方、そして参加した皆様、ありがとうございました。

以下では、私は参加できませんでしたが、他セッションで発表していただいた方のスライドを貼っておきます。

speakerdeck.com

speakerdeck.com

scrapbox.io

speakerdeck.com

speakerdeck.com

JavaScriptにおける再代入可能な変数の扱い方

目次

調べたものとは?

再代入可能な変数を定義し、ある関数が実行されるたびにその変数に任意の数を加算する実装が必要になりました。

「状態」という概念を用いればhooksやcomposablesの中でuseStateやrefを使い簡単に実装できます。しかし、それを使わないで実装したいな、と思ったのでchatGPTを使って調べてみました。

結果

まず問題あるのか?

JavaScriptにおいて再代入可能な変数を関数が実行されるたびに変更するのは一般的に問題ありません。

しかし、その扱いには注意が必要となります。変数が関数の外部にあり、関数実行のたびに更新されるような「状態」を持つ場合、変数の管理方法がコードの読みやすさや保守性に影響します。

再代入可能な変数の状態管理における注意点

JavaScriptでは再代入可能な変数を更新して状態を持たせることは可能ですが、以下のような注意が必要となります。

  1. スコープ管理:状態を持つ変数がグローバルスコープにある場合、予期せぬ変更や競合が生じる可能性があります。できるだけ変数のスコープを狭めることが望ましいです。
  2. 可読性:状態を持つ変数は、どこで変更されるのか分かりにくくなる可能性があります。予期せぬタイミングで変数が変わると、バグを招きやすくなります。
  3. 関数の副作用:内部で直接関係のない変数を更新する副作用を持つと、他の部分で再利用しづらくなる可能性があります。必要に応じて変数を更新する関数(例えば increment() など)を定義し、関数の実行後にその関数を呼び出すようにすると、可読性やメンテナンス性が向上します。

より良い状態管理の例

次のコード例は、外部変数 variable の管理を工夫した形です。

let variable = 0;

function hogeFunc() {
    // 関係のない処理
    console.log("Executing unrelated logic");
}

// variableを増やすための関数を別に定義する
function increment() {
    variable += 1;
}

// test関数実行後にincrementAを呼び出す
hogeFunc();
increment();
console.log(variable); // variableが+1された状態で出力

JavaScriptでの状態管理のための代替アプローチ

状況によっては、以下のような管理方法も検討すると良いでしょう。

クロージャを用いた変数のカプセル化:

変数を関数内に閉じ込めて外部から直接アクセスできないようにすることで、意図しない変更を防ぎます。

function stateManager() {
  let variable = 0;
  
  return {
    increment: function () {
      return variable += 1;
    },
  };
}

オブジェクトやクラスを利用した管理:

変数variablesが増加する機能を持つオブジェクトやクラスを定義すると、状態の管理がしやすくなります。

const stateManager = {
    variable: 0,
    increment() {
        this.variable += 1;
    }
};

function hogeFunc() {
    console.log("Executing unrelated logic");
}

// hogeFuncの後にincrementを呼ぶ
hogeFunc();
stateManager.increment();
console.log(stateManager.variable); // variableが+1された状態で出力

関数引数で状態を受け渡す方法

場合によっては、状態を関数の引数として渡し、戻り値で更新する方法も有効です。これにより、関数の副作用がなくなり、this も不要になります。

function increment(value, amount = 1) {
    return value + amount;
}

let variable = 0;
variable = increment(variable); // Aに1を加える
console.log(variable); // 出力: 1

variable = increment(variable, 3); // Aに3を加える
console.log(variable); // 出力: 4

まとめ

JavaScriptで再代入可能な変数に関数実行のたびに変更を加えること自体は可能ですが、スコープ、関数の副作用、可読性を考慮し、状況に応じてクロージャやオブジェクトを活用するのが望ましいです。

Vue Fes Japan 2024に行ってきました

vuefes.jp

前回の記事 kostum.hatenablog.jp

2024/10/29に昨年も参加したVue Fes Japan 2024に参加してきました。

ということで、今年も参加したセッションでメモしたノートをアウトプットさせていただきたいと思います。
(本当は共有と言いたいところですが、そんなにレベルの高いことができなかったので。。。)

また、他セッションのスライドは公式Webサイトのタイムテーブルにリンクがあるので、興味がある方や、他セッションの内容も気になるという方は上記のリンクから見てみてください。

目次

キーノート

by Evan you in メドピアトラック at 10:40

  • Vueの歴史
  • keep evolving
    • 1.0: DOM based
    • 2.0: virtual DOM + SSR
    • 3.0: composition API , ES2015, TypeScript, compiler optimization
  • vue's future
    • 10年間で37%の成長率
    • vue3に至っては1年間で98.4%
  • Vue3 stableとimprove
    • 3.2:
    • 3.3:
    • 3.4: parser rewrite, reactivity reflection
    • 3.5:
      • reactivityの体験を良くした
      • useTemplateRef
      • SSRの改善
        • Lazy hydration
        • useId → serverとclientで共有
      • defineCustomElement
  • volar 2.0
    • IDE support
      • takeover mode
      • Hybrid mode(ゼロコンフィグ)
  • Devtoolsもパフォーマンスが良くなっている。
  • vapor mode
    • パフォーマンスの向上
  • 3.6 planning
  • vite
    • 様々なフレームワークに優れている。
    • perfectではない。妥協していたものがあった。
      • esbuild, Rollup, swcそれぞれに依存している。
      • ↓
      • Rolldownはunifyしていきたい。
    • viteが抱えている課題。巨大なJavaScriptのエコシステムと同じ。
      • unified toolchainが必要。
      • void(0) - next-generating tool
  • oxc
    • oxcの機能
      • parcer
      • linter
      • resolver
      • transformer
      • minifier
      • formatter
    • oxcの特徴
      • faster parser
      • faster linter
      • faster resolver
      • faster transformer
      • s,aller package/Binary size
  • Rolldown
    • Basic Bundling
    • oxc integration
    • advanced feature < vite integration

VueとViteで作るUIコンポーネントライブラリ~デザインシステムとプロダクトの理想的な分離を目指して~

by 辻 佳佑 in メドピアトラック at 11:20

speakerdeck.com

IT未経験者をVue.jsで開発できるITコンサルタントに育てあげる秘訣-フューチャーの新人研修の取り組み

by 永井 優斗 / Yuto NAGAI in メドピアトラック at 11:35

聞けなかった。

AIとともに歩んだライブラリアップデートの道のり

by 中上 裕基 in メドピアトラック at 11:50

speakerdeck.com

途中から。

Piniaの現状と今後

by 若原 緑 in MNTSQが全ての合意をフェアにするぞトラック at 12:20 - 12:40

speakerdeck.com

pnia(ぴーにゃ)と読むのが正解。 公式推奨がVuexからPiniaになったので、npm downloadsも逆転したのかも。

Oxc-The_JavaScript_Oxidation_Compiler

by Boshen Chen in メドピアトラック at 13:10 - 13:40

https://jjdlwtezpdclgxxagxpj.supabase.co/storage/v1/object/public/common_asset/archives/boshen.pdf

  • compiler
  • oxcは誰が使うのか
    • nova emgine
    • React, shopify
  • performance engineeringとは
    • MIT OpenSource
    • 様々な属性より優先度が落ちがち
    • CPUの内部を考慮すると、メモリだけではなくCPUに任せた方が良い
  • Rust Programming
    • memory safety
  • JavaScript
    • 最適化による効率化が難しい
  • parser
    • swc, babelより高速
    • String
      • heap allocation → 遅い
    • SIMD - Single instructions, multiple data
      • Web assemblyにのみある
    • Memory Arena for AST
      • oxcでは何百万ものノードをヒープに登録する。
      • これが遅くする
      • Rustの課題としては、GCを持っていない。
  • OXlint
    • ESlintよりも高速
    • Parallelization
      • multiple core
    • transformer
      • performance
        • swc, babelより高速
        • single AST Path
      • minifier
        • benchmark
          • swcを超えない
    • test infrastructure
    • Bundler(Rolldown)
      • performance
  • Rustの学ぶ意味
    • 高速を目指すのであれば学ぶべき。
    • ただ、学ぶことが多い。
  • learn more
    • oxc.rs
    • rolldown.rs

Vue3とSvelte5のランタイムを比較する〜技術を一段深く理解する〜

by 山下 裕一朗 in MNTSQが全ての合意をフェアにするぞトラック at 13:55 - 14:25

docs.google.com

VueとSvelteの違いとして仮想DOMの使用有無の違いがありますが、それを実装レベルで知れて面白かったです。 また、そもそもそのフレームワークの様々なbuilt-inの機能をコードレベルで知ることができたのは勉強になりました。

次世代フロントエンドクロストーク

by Evan You, Boshen Chen, 太田 洋介, Sosuke Suzuki, unvalley, Kia King Ishii(通訳兼ファシリテーター) in MNTSQが全ての合意をフェアにするぞトラック at 14:40 - 15:40

JavaScriptエコシステムの未来

evan you:

既存のものと競合するようなことをしているように見えるが、JavaScriptのエコシステムを良くしていくことを目的としている。 vueやviteコミュニティでは様々な他プロジェクトに絡んできている人もいる。

昔はビルダーやフレームワークからwebエンジニアが入ってきて、フレームワークにより設定ファイルが全く異なっていた。

この4年でmetaフレームワークが出てきており、0からの再開発をせずに開発していきたいところがある。

このメタフレームワークにViteが選ばれてきている。 これによって、Viteによって基礎を築き始めている。この機会がJavaScriptも統一する気持ちになった。

sosuke:

会社のエンジニアとしては設定を書きたいわけではなく、ユーザーに価値を届けたいので、toolchainの統合は嬉しい。

なぜJavaScriptのRust化が進んでいるのか

Boshen:

toolchainという文脈で言えないが、そもそもJavaScriptで書いているのが間違っていると思っている。昔は小さいものをJavaScriptで書いていたが今は巨大になり過ぎてしまった。 さらに今はAIが出てきていても、その  には何も寄与していない。 会社のミッションとしても実行時間も減らすことができればメリットが大きい。

evan you:

JavaScriptもエンジニアが書くしかなかったから、必ずしも間違いとは言えない。 このプロセスは悪いことではない。 柔軟でよりコード自体も簡単だった それだけでなく、思想や設計とか決議を決めることができた。 他のプログラミング言語の欠点を補いかつ高速なので、合理的な判断までできる。 ただ課題もある。

o:

oxcがなかったらどうしていたのか、別のものを使うつもりだったのか?

evan you:

oxcがなかったら、swcでなんとかやっていたと思う。

これまでとこれからのJavaScriptエコシステム

pluginを加えればオーバーヘッドがかかる。
→ これを解決するアイディアがある。

  1. 互換性100%を石すること(Rollup)
  2. pluginを一部だけ使えるようにする
  3. もっと大きい有名なコア部分に
  4. JavaScriptで書く必要のない部分をサジェストさせる。

ASTの共有化 これはVoidZeroの仕事。 これを共通化することで、JavaScriptをすべて実行時になってから処理する必要がなくなるので、パフォーマンスブーストが多いと思っている。 JavaScriptの並列化 woekerを並列処理させる。 既存のものがRustに置き換わっている。

s:

言語が変わることによってコントリビュートが減るなどの影響はないと思っている。やる人はやるし、やらない人はやらない。 Rustやりたいからフロントのツールチェインに来る人もいる。

Demystifying_Vite_Internals

by Nozomu Ikuta in MNTSQが全ての合意をフェアにするぞトラック at 15:50 - 16:20

speakerdeck.com

Deep_dive_into_Nuxt_Server_Components

by wattanx in MNTSQが全ての合意をフェアにするぞトラック at 16:30 - 17:00

speakerdeck.com

終わりに

最後までお読みいただきありがとうございました。 ノート部分は、あくまで私が記載したものなので、間違っていることを記載している可能性があります。なので話半分で読んでいただければと思います。