管楽器用の楽譜を書いていると、同じパートの楽譜をト音・ヘ音、時にはin Cで出力したい場面があります。 そういった時に、Doricoでは便利な方法が用意されています。 レイアウトを追加し、同じパートを複数の譜面として出力する設定を行う 追加したレイアウトに対して「音部記号と移調の上書き」を行い、同じパートで音部記号だけが違うパート譜を設定する 手順 1. レイアウトを追加し、パートを設定する 「設定」モードの画面右にあるレイアウトペーンに、レイアウトを追加します。 左から二番目の「パートレイアウト」を追加をクリックすると、レイアウトが追加されます。 追加されたレイアウトを選択した状態で、画面左にあるプレイヤーペーンから設定したいパートを選択します。 すると、現時点では同じパート譜が2つ表示されていると思います。 2. レイアウト設定をいじって、音部記号のみを変更する 追加したレイアウトを右クリックして表示されるメニューから「音部記号と移調の上書き…」を選択します。 音部記号をバス記号に設定すると、追加したレイアウトだけヘ音記号になります。結果として、1つのパートからヘ音・ト音パート譜を出力できるようになりました。 注意点: 記譜パネルで音部記号をいじると、上書きがかからない場合があるので、音部記号はレイアウトの「音部記号と移調の上書き」で設定するのがいいです。

AstroのContent Layerを使ってesaのデータを簡単に扱えるローダー「astro-loader-esa」を公開しました。これはこのウェブサイトをGatsbyからAstroに置き換える際にesa.ioのデータをAstroで使うために作ったものです。 本記事ではAstroのContent Layerについて簡単な説明と、astro-loader-esaの使い方を紹介します。 AstroのContent Layer AstroのContent Layerは、Astroのプロジェクトにおけるコンテンツ管理の仕組みです。マークダウンやCMSからのデータを統一的なインターフェースで扱えるため、開発者はデータの出どころを意識せずにコンテンツを利用できます。 Astro v5以前までは、リポジトリに含まれるMarkdownなどのファイルを扱う仕組みでしたが、v5からはLoaderという概念が導入され、外部サービスのデータも扱えるようになりました。 Loaderを使わなくても、データを利用するだけであれば利用側のコンポーネントから読み込みができます。しかし、Loaderを使うと事前にすべてのデータを取得してくるので、APIリクエストが少なく済み、結果的にビルドも早くなります。 具体的な流れでいうと、src/content.config.tsで定義したデータがサーバー立ち上げ時点で読み込まれ、以降はgetCollectionやgetEntryを使ってデータにアクセスできます。 astro-loader-esaの使い方 インストール astro-loader-esaはAstroでesaのデータを扱うためのローダーです。Astroのプロジェクト内でnpmなどのパッケージマネージャーでライブラリをインストールします。 npm install astro-loader-esa esa.ioのアクセストークンとチーム名を準備 esa.ioのアクセストークンを取得します。利用したいteamNameも控えておきます。 今回はそれぞれ環境変数ESA_ACCESS_TOKEN, ESA_TEAM_NAMEとして定義しておきます。 ローダーの設定 ローダーを利用する処理はsrc/content.config.tsに記述します。 src/content.config.ts import { defineCollection } from "astro:content"; import { esaLoader } from "astro-loader-esa"; const esaPosts = defineCollection({ loader: esaLoader({ accessToken: getSecret("ESA_ACCESS_TOKEN"), teamName: getSecret("ESA_TEAM_NAME"), params: { q: "in:blog wip:false", }, }), }); export const collections = { esaPosts }; データの利用 ローダーを記述して、サーバーを立ち上げるとgetCollectionやgetEntryを使ってesaのデータを利用できます。 src/page/index.astro --- import { getCollection } from "astro:content"; const posts = getCollection("esaPosts"); --- {posts.map((post) => ( <article> <h2>{post.data.number} {post.data.name}</h2> <p>{post.data.bodyMd}</p> </article> ))} src/page/posts/[number].astro --- export const getStaticPaths: GetStaticPaths = async () => { const items = await getCollection("esaPosts"); return items.map((item) => ({ params: { number: item.data.number } })); }; const { number } = Astro.params; const post = await getEntry("esaPosts", String(number)); const { Content } = await render(post); --- <h1>{post.data.name}</h1> <Content /> 作ってみた感想 ContentLayerの仕組みはビルド時にHTMLが確定するブログのようなサイトとの相性がとても良く、Web APIが提供されているサービスの多くをCMSとして利用できる仕組みだと思います。 また、Loader自体の実装自体も簡単なので、欲しいものがないなら作ってみる選択肢を取りやすいのでAstro自体をより人に勧めやすくなりました。

2018年にGatsbyで構築したこのウェブサイトをAstroでリニューアルしました。この記事では、リニューアルに至った背景や技術スタックについて紹介します。 リニューアルの背景 このサイト自体は2018年5月にファーストコミットが行われており6年もののサイトになっていました。サイト自体のデザインやコードが古くなり、手を入れたい気持ちが高まっていました。一方でGatsbyの本を出版している程度には思い入れがあるため、現状のGatsbyサイトを残したいという気持ちがストッパーになっていました。 しかし、Gatsby本体の開発が実質停止状態になっていたのに加え、仕事で扱うことの多いNext.jsと比べても、そのモダンさとのギャップが目立つようになりました。そうした理由からリニューアルを行うことにしました。 技術的なお話 Astroの採用 リニューアルの構成を検討するにあたり、Next.jsやRemixといった主要フレームワークも候補に挙げましたが、最終的にはAstroを採用することにしました。Astroはアプリケーションというより、ドキュメントサイトやブログなどの「コンテンツ中心」のウェブサイト向けに特化しており、やりたいことがシンプルに実装でき、ブログ中心のウェブサイトにはピッタリだと考えました。 以前から続けてきたesaへの投稿をAPI経由で取得し、ウェブサイトに表示するフローはそのまま維持しています。これはAstroのv5で導入された「Content Layer」を利用することで簡単に実現できました。ビルド時にコンテンツをキャッシュできるため、API制限のあるサービスを扱う際も負荷がかからず、とても使い勝手がいいです。 ほぼ同じことができるGatsbyJSのGraphQLのデータレイヤーよりも洗練されていると感じています。 Content Layer用のローダーの自作 esaは国内向けのサービスであるため、AstroのContent Layerに対応したローダーが存在せず、自前で実装する必要がありました。 他のローダーの実装を参考にしながら開発を行いましたが、非常にスムーズに実装できました。しばらくして、コードが固まったタイミングでnpmパッケージとして公開します。 Astroはマークダウンを扱うremark系の処理を公式が持っていて、それに相乗りする形でマークダウンの変換処理も任せることができました。旧式のマークダウン変換処理と差分がありましたが、適切なプラグインを導入し、妥協できるレベルの出力にしました。 今まではesaが変換してくれたHTML1を利用していましたが、フレームワークに乗っかったことで、より柔軟な変換処理ができるようになりました。 zodでスキーマを定義してデータのバリデーションを行いつつも、TypeScriptの型として提供されるのは、とてもいい仕組みだと思いました。 マイクロインタラクション このサイトではリニューアル現在はクライアントで動作するJavaScriptを（3rd Party Scriptは除いて）書いていません。ただその中でも、ページ左上ナビゲーションの現在位置を示すドットに、View Transition APIを活用したインタラクションを実装しています。 ページ間の遷移時に、ブラウザがスムーズにアニメーションを付けてくれるのが特徴です。今回のリニューアルでお気に入りの箇所です。 その他の開発技術 今回のリニューアルではTypeScriptをファーストクラスで採用し、スタイリングにはTailwind CSS、パッケージマネージャーにはpnpmを利用しています。また、今回はデプロイをNetlifyではなくVercelで行っています。Netfliyも同人誌を書くレベルで好きだったのですが、時は残酷です。 数年ぶりの大きなアップデートでしたが、「ウェブフロントエンドの変化がとにかく早い」と言われていた時期に比べると、あまり変化はないと思いました。適切な頻度で知識のアップデートを行えば、ついていく分には問題がなさそうで安心しています。 これからの展望 このウェブサイトはもともとフロントエンドエンジニアとしての技術の素振りも兼ねていました。今となってはUIデザイナーが本業なので、素振りというよりは今までとは違った表現やメモ置き場として運用していきたいと思っています。 ゆくゆくは海外のデザインエンジニアがやっているようなCrafts的なものを作っていきたいです。 旧サイトのGatsbyJS版のソースコードはGitHubのパブリックリポジトリに引き続き残しておきますので、興味がある方はぜひ覗いてみてください。 注釈 生のマークダウンの他に変換されたHTMLがAPIレスポンスに含まれています。 ↩