Next.jsのStatic Generationを追っておく際に見たページをまとめた。簡単に要点をまとめてはいるが、詳しくはリンク先のオリジナルを見てほしい。 2019 in Review Guillermo Rauch（@rauchg） … Vercel社（元ZEIT）のCEO　のブログ記事 2019年はJamstackが伸びた年であること Staticは高速で安定性が高い SSGやClient JS/APIでdynamicを実現できること Next.jsはJamstackの機能を網羅している Static GenerationとかAPI RoutesとかDynamic Routing Vercelを使えば便利だよと等々 Static Generation / SSG Improvements ページ単位でSSG（静的生成）とSSRを出し分けられるようにする。 Next.js 9になってデータを必要としないページはhtmlとして出力されていた。（いわゆるAutomatic Static Optimization） データを必要とする場合は既存のexportを使うことでStaticにできたが、すべてのページが静的になってSSRが使えない。 また、getInitialPropsではクライアントでの遷移時にデータを取得する必要がありDBやCMSへのアクセスが発生していた。 これらを解決するためにgetStaticProps、getStaticPropsを導入し、静的なデータを扱えるようにした。 （サーバーサイドで実行されるgetServerSidePropsも追加された） RFC: Incremental Static Regeneration 上記のStatic Generationが実装され、高速に低コストでウェブサイトを配信できるようになった。 欠点として、静的に生成されたページのデータ更新された場合、完全な再ビルドが必要だった。 このリビルドを避けて、オンデマンドで新しいページを生成するのがIncremental Static Regeneration 各ページにtimeoutを設定し、有効期限が切れると再レンダリングが走る。 Staticにツイートを表示するデモ https://static-tweet.now.sh/ Static Hoisting Vercel社（元ZEIT） Guillermo Rauch氏のブログ記事 Hoisting（変数の巻き上げ）の説明し、Jamstackは計算結果を訪問者に巻き上げるものだと言っている。 CDNとJamstackの比較。JamstackはすべてのEdge Serverで共有される。 Next.jsはページ単位にアセットを生成するので静的な部分を巻き上げやすい構成になっている。 Dashboardのような一見動的な画面もClient JSでやるからデータの問い合わせをする静的ページ。

2020年になり誰もが予想しなかった速度で、人々の営みはオンライン上で行われるようになりました。もちろん仕事も例外ではありません。 そういった変化の中ではオンライン上のコミュニケーションがより重要になりました。仕事というコンテキストでいえば、Slack / Chatworkといったグループウェアでコミュニケーションを取られることが多くなっています。 こういった変化の前から導入していた会社・チームであっても、オンラインを中心とした働き方では今までと同じ方法は通用しません。そこで有用なのが分報です。 分報は一言で言えば「社内Twitter」です。詳しくは次のブログ記事を読むのがおすすめです。 仕事の進捗、躓いたこと、課題などを投稿していき、チームで共有していく文化といっていいでしょう。 Slackで簡単に「日報」ならぬ「分報」をチームで実現する3ステップ 分報、以前からも行われてきた取り組みです。しかし、非同期に進捗や悩みを書き込んでいく分報はフルリモート勤務に非常の相性の良く、今以上に利用するチームが増えるのではないかと考えています。 私は比較的オンラインで物事を進めやすいIT業界で、4年ほどリモート主体のお仕事をしています。その中でも分報を中心にコミュニケーションを取ってきました。そういった経験から、分報を使う際に気を使っている点を紹介します。 投稿するハードルを下げる 全社で加入するチャンネルや、部署内で加入するチャンネルと違って、分報の主は自分です。投稿することに抵抗を感じなくても大丈夫です。 仕事に関係するものでなくても、業務外の勉強会や、ブログ記事の共有、趣味で作っているものを投稿してもいいでしょう。 また、他の人の分報であっても気軽にemojiを付けたり、気になって事があればリプライを返しにいくといいでしょう。分報の文化が活性化すると、他の人の暗黙知や考えていることが表に出てくるのでより仕事がやりやすくなります。個人的にはSlackの絵文字で:+1, :eyes:をよく使います。特に:eyes:は見てる感を出すのにおすすめなemojiです。 ただ、分報が活性化してくると、個人的なタスクの依頼などを分報で受けるようになり、それが常態化することがあります。こうなるとチーム全体のタスクが見えにくくなるので注意が必要です。タスクの依頼であれば、全員が入るチームチャンネルのようなところで行うのがよいでしょう。 やってる感を出していく リモート勤務をやっていて、言われるとちょっと面倒なのが「今どのぐらい進んでる？」「今何やってる？」といった進捗を把握したい人の言葉です。なんとなく疑われているような気持ちになってやる気を失わせる言葉だと思っています。そういった言葉を避けるためにも、自分からやっているタスクの進捗を共有していくといいと思います。 やっている感を出していくには、開始時にやることを宣言する、区切りのいいタイミングで進捗を報告する、つまずいていることを書いておく、終了時に次回稼働時にやることを書いておくのが有効だと考えています。 開始時には「今日は●●からやる」、終了時には「今日はここまで、明日は●●から」等の投稿をすると、朝仕事を始める際に何をやるか迷わず始められます。また、何をやったかが追いやすくなるので仕事の振り返りが行いやすくなります。区切りのいいタイミングでの進捗も重要で、自分は1,2時間に一回ぐらいを目安に投稿をするようにしています。 見落とされやすいですが、躓いていることを書いておくのもポイントです。 リモートワークで避けたいのが、「数時間苦戦したけど何も解決しなかった」という状況です。会社に出社しているのであれば「なんか頑張っている」というのが見えますが、リモートワークでは試行錯誤を見せることができません。 自分はそういった状況を避けるために、難しい仕事に取り組む時は、解決に必要そうなポイントを事前に書き込んでおき、途中途中で「何がネックで解決できていないか」を投稿しています。既にノウハウを持っている人が見れば解決策を書き込んでくれますし、ノウハウがなかったとしても「頑張っているんだな」という印象を持ってもらえます。解決が難しく、代替案を出す時もこういう試行錯誤を見せた上で提案すると通りやすくなったりします。 やってる感を出すことで、自分がしんどくなることを防ぎ、チームの人やマネージャーに不安を与えなくなります。特に顔が見えない状況では、不安になったり、他人に不信感を与えやすくなるので、こういった工夫で乗り切っていくといいでしょう。 情報量を上げる 仕事におけるコミュニケーションの方法には、対面、ビデオ通話（ex. Zoom）、テキスト（ex. Slack）がありますが、伝わる情報量は後にあげたものの方が小さくなります。 そうです、Slackでは、思ったより伝わる情報量は大きくありません。ビデオ通話をすればテキストで伝わらない情報を伝えることが出来ますが、テキストによる「非同期」というメリットが失われます。このデメリットを回避して、Slackで伝える情報量を上げるポイントは「画像」と「動画」をうまく使うことです。 特に覚えておきたい画像の活用法は2つあります。 1つ目は、スクリーンショットです。画面に写っている要素を画像にして共有する方法を覚えておきましょう。WindowsもmacOSもそれぞれOS標準でスクリーンショットを取る方法が用意されています。作っているものや、操作方法を伝える際に便利なのでぜひ活用しましょう。 2つ目は、テキストで伝えられない図を作って共有する方法です。これはPowerPointやKeynoteなどのプレゼンテーションツールを使ったり、SketchやFigmaのようなデザインツールを使って図を書き共有します。最初は難しいかもしれませんが、習熟すると手軽に図をかけるようになります。 これらの方法を覚えることで、ビデオ通話のようなお互いが時間の合わせる必要のある手段を用いずとも相手に情報を伝えやすくなります。もちろんビデオ通話が必要な場合もありますが、ぜひリモート・非同期であることを活かした働き方ができればと思います。 現在、親方Projectで「ワンストップ　オンライン生活」という合同誌を書いています。今回も湊川あいさんの素晴らしい表紙の本です。 出展予定の5/5（4日目）に向けて新刊を書いています。何ページの本ができるかな・・・Boothにて頒布予定。5/6頒布開始すべく鋭意執筆中・・・エアコミケ/C98新刊ワンストップ　オンライン生活https://t.co/2A6mz6PhDq #エアコミケ #ワンストップシリーズ #ワンストップオンライン生活 pic.twitter.com/CFQlyjbAy0— おやかた@春のコミケC98火曜日（4日目）南地区 "イ "22a (@oyakata2438) May 2, 2020

本ブログはGatsbyを使って、esa.ioで書いたコンテンツをNetlifyで配信しています。 esa.ioは情報共有サービスとして作られているので非常に書きやすいサービスです。しかし、（意図しない使い方をしているので）文章以外の情報を持たせるには不向きです。 ブログでシリーズ物の記事を書いてみたいが、連載情報をesa.ioに持たせるのは難しい。ただ、見た目とコンテンツの密を避ける意図でブログのソースコードには依存しない形にしたいと考えていました。 そこで目をつけたのが日本製のHeadless CMS「microCMS」です。 Headless CMSとmicroCMS 本ブログでも何度か取り上げていますが、簡単にHeadless CMSについて説明します。 通常WordPressのようなCMSはコンテンツの管理層とプレゼンテーション層を持つソフトウェアです。しかし、Headless CMSはコンテンツの管理層である管理画面やコンテンツを利用するAPIを持つようなCMSです。マルチプラットフォーム化によるコンテンツの一括管理といった側面もありますが、Gatsbyのような静的サイトを吐き出すフレームワークと相性がよく、Jamstackの文脈でもよく利用されています。 「microCMS」は日本製のHeadless CMSで、国内のJamstack系のイベントに行くとよく耳にするCMSです。海外製のHeadless CMSと比較しても使いやすく、無料プランの制限が緩いために個人開発でも使いやすいのが特徴です。 連載機能 ブログは物理的な冊子と比べると連続性のあるコンテンツを表現しにくい媒体であると思っています。冊子では前章の内容は読んだ前提で執筆される一方、ブログでは検索エンジンからどのページに流入するか予測がつかないためです。 そういった特徴を踏まえた上で「ファーストビューで連載の１記事であることがわかること」を重視して連載機能の実装を進めました。本記事も連載記事ですが、右上に連載を表示するようにしました。 本ブログの閲覧者はPCが多いので、少なくともPCユーザーのファーストビューには入るようになっています。（ただ、サイドバーにgeneralの情報と記事の情報が混在してしまっている点はよろしくないと感じています。） コンテンツ本文を管理するのはesa.ioに任せて、microCMSには連載自体の情報と連載に含まれる記事情報を持っています。 通常、サイトをまたいだ情報をjoinするとパフォーマンス的な問題が発生しますが、ビルド時に情報をjoinするだけなのでサイト閲覧時に得に影響はありません。GatsbyやJamstackの恩恵を感じます。 開発当時はCMSの制約上、カンマ区切りというアプローチを取る必要がありました。しかし、現在はカスタムフィールドという機能が登場しきれいなスキーマが作れることを確認しています。暇なときに治そうと思っています。 GatsbyにmicroCMSの情報を読み込む際にはgatsby-source-microcmsを利用しました。利用する際に、serciceIDとapiKeyをgatsby-configでoptionに渡し、必要な箇所でGraphQLを使ってデータを取り出すだけです。 興味がある方はプラグインのREADMEや実際のプルリクエストをご覧ください。 これからは連続性のある記事も書いていきます。がんばります。

新型コロナウイルスの影響で外出が推奨されなくなって数週間がたった。 「自分は普段から引きこもりがちだ。大して影響はないだろう。」と構えていたが、日に日に後ろ向きの感情が強くなっているように感じている。 オーケストラやアンサンブルの演奏会が中止になって、プログラミングと仕事のみの生活で息を抜くタイミングを失ってしまった。 外に目を向けてもTwitterでは非常に攻撃的なツイートが目立ち、デマや買い占めなどの後ろ向きな出来事も増えている。 そんな中、自由に外出できない中で「#うちにいよう・#StayHome」をキャッチフレーズに前向きな活動を行っている人たちがいる。 自分もそんな彼らのように前向きな気持ちを持っていたいと思う。そういった彼らにならい、家でできるやってみたいことをリストに落としてみた。 リストを作る時に考えたのは「やるべきこと」「義務感からくるもの」ではなく「自分がやりたいものを選ぶ」ということだ。ときめかないものは書かない、こんまりスタイルだ。 エンタメ サブスクにはない映画を借りて見る 人から薦められた漫画を読む 誰かと一緒にFortniteをする リングフィットの音ゲー超上級でランクAをとる 今のところB+ 好きな曲と出会う テック系ポッドキャストを聞いてみる LINE UIT Insideを聞いている 生活 机をすっきりとさせる 朝、すっきりと起床したい 簡単な軽食を作れるようにする 趣味 絵をうまくかけるようになりたい zoom飲みを体験する 開発 人の個人開発を手助けする Google Hungoutで相談会をやった。2人の個人開発をお助けした。 OSSに貢献する Next.jsとGatsbyにちょっとコントリビュートした 「複雑GUI」と言えるGUIをつくる 仕事で高機能なギャラリーを作っている 「クリーンアーキテクチャ」を読む プログラミングの生配信をやってみたい Next.js + Cloud Run + Firebaseを試す 試した。デプロイの依存関係で考えることが減って良さそう。 https://twitter.com/mottox2/status/1249366895679029248 Cloud BuildでCloud Runにデプロイするやつを作る 作った。Googleの認証情報を外に出さなくていいメリットはあるが、GitHub Actionsと比べると使いづらい印象を受ける。 GatsbyJS Guidebookの改訂版を出す 目次を作っている その他 ブログの連載をちゃんと書きたい

ソートUIを作るための取り組みをしている。その中でドラッグ中の挙動について迷ったのでメモ。 ドラッグ中の挙動 図中のドラッグ中の挙動に差があり、さわり心地に大きく影響する。 上：ドラッグしている要素は元の位置から動かず、ドラッグ後の位置にプレビューを出す 下：ドラッグしている要素ごと、ドラッグ後の位置に移動する 各方式を採用しているアプリケーション例 上：Sketchのレイヤー、Figma 下：Keynoteのスライド一覧、Torello おそらく階層構造を含むソートであれば上の方式を採用したほうがよい。 下のほうが直感的だが、ドラッグするとブロックがずれる。 そのため、ツリー構造のような複雑な構造ではブロック移動が直感的でなくなるのかも。 実装例 Reactでソートツリーを実装できるreact-sortable-treeは下方式の移動方式を取っているが、直感的ではない。特に、ドロップ出来ない要素を選択した時の挙動が辛く、赤枠で表示されるところにドロップすると選択した要素が突然元の位置に戻る。（ドロップできる条件を含んだ時に上方式のメリットが出てくる可能性がある） https://frontend-collective.github.io/react-sortable-tree/?path=/story/basics—callbacks ということでソートUIの簡易実装をしてみた。（ただし、まだツリー構造を実装していない） https://react-tree-ui.netlify.com/

CodeSandboxはWeb上でVisual Studio Codeが提供されるWebサービスです。 ReactやVueのフロントエンド環境はもちろん、Next.jsやNuxt.jsなどのサーバーを必要とするアプリケーションの開発環境を立ち上げながらコードを書けるのが特徴です。 CodeSandboxをより便利に使うために、「Vimのキーバインドを有効にする方法」と「JSONでキーバインドをカスタマイズする方法」を紹介します。 Vimのキーバインドを有効にする方法 VimからVSCodeに入った人は「VSCodeVim」でVim風キーバインドを使っている人は多いのではないでしょうか？ 以下の手順でVimキーバインドを有効にできます。 ヘッダーのアイコンをクリックし「Preferences」を選択 次のような設定モーダルが表示されるので左ペーンから「Editor」を選択 「Enable Vim extension」を有効にすると、ページのリロードを求められるので支持にしたがい「Confirm」を選択 JSONでキーバインドをカスタマイズする方法 VSCodeでいう「Keyboard Shortcut」の設定をいじる方法もあります。 CodeSandbox上では一見設定画面へのアクセス方法がありませんが、Command Palatteを経由することで設定画面にアクセスします。 以下の手順でキーバインドをカスタマイズできます。 Cmd（Ctrl）+ Shift + P でCommand Palatteを開く 「Keyboard」と入力し表示された「Preference: Open Keyboard Shortcuts (JSON)」を選択 VSCode形式でキーバインドを設定します。 参考に自分が設定したJSONを掲載します。emacs風の行頭・行末に飛ぶキーバインドです。 [ { "key": "ctrl+a", "command": "cursorLineStart" }, { "key": "ctrl+e", "command": "cursorLineEnd" }, ]

2020/3/18に行われた「PWA Night vol.14」で『手触りのよいウェブを考える』というタイトルでオンライン登壇しました。昨今のコロナウイルスへの対策としてオンラインの開催形態を取った勉強会です。 普段、自分はWebエンジニアリングの登壇をすることが多いのですが、今回はUI/UXをテーマにした回でした。また、オンライン登壇ということもあり、聴衆でも触れるデモを用意しました。 内容 今回のテーマは、PWA Nightカンファレンスの懇親会LTで発表した『さわり心地のよいWebをつくる』の拡大版です。PWAの文脈ではAdd to HomeScreen（A2H）やService Worker、Web Pushなどの機能的な話に興味が行きがちです。そういった背景があるため、非機能要件であるさわり心地について話をする人があまり多くありませんでした。 今回の発表では「スマートフォン」というデバイスは直接操作という特徴から、ハサミのような道具的な性質が強いというテーマを取り上げ、道具としての使い心地を上げるのはどういったポイントに注意すべきか？という話をしました。 一方的に話すだけではなく、使い心地の悪いUIを実装したデモを見せながらポイントを抑え、最後に今からよいWebを作るためにできることを話しました。 デモに関してはTwitterを見た限り触ってくれた人もいて、ちゃんと引っかかりを覚えてもらったようです。当日2時に思い立って作ったものにしてはよく出来たと思っています。（自画自賛） デモ: https://bad-ui.netlify.com/ ソースコード: https://github.com/mottox2/bad-ui 感想 オンライン登壇の難しさを思い知った会でした。オフラインの登壇ではわかる「聴衆の反応」がないだけでこれほど難しいのか…という気持ちです。 一方的に話すなかで「伝わっているだろうか？」「見当違いなことを話していないだろうか？」という不安が湧いてきます。オンライン上の反応を見ようとしても、TwitterやSli.doを見ても結構なラグがあり数分前の反応しか見れませんでした。VTuber/Podcasterはすごいなー。 また、個人の環境によるところが大きいですが、家族がいる中の配信だったのであまり大きな声を出せない、登壇中はあまり大きな音を立てないで欲しいことをお願いするなどの工夫がいります。日中のオンラインMTGでは家族が不在なので気になりませんでしたが、勉強会の時間帯は夜だったので気を使う必要がありました。 しんどい面が多かったですが、いい面もあります。普通の登壇ではノートPCでしたオンラインの反応を見れませんが、自宅の仕事デスクからの配信だったので、メインモニタ・サブモニタ・iPadとスマホの4画面で情報を見ながら話すことができました。スマホにYouTube Live、iPadにタイマーを表示しながら、メインモニタでTwitterとSli.doの監視、サブモニターを配信する形でやりましたが、上記のデメリットさえなければ非常に快適な登壇になったと思います。普段の登壇でもサブモニターが用意されていれば、今までとはかなり違った形の登壇ができるかも？という可能性を感じました。 総じて辛さと悔しさが残った登壇でしたが、オンライン登壇という機会がいただけで良かったです。 さいごに 登壇の機会と場所の準備、この状況の中で勉強会開催を勧めてくれたPWA Nightの運営の方々には感謝です。ありがとうございました。

時折、（私の）Twitterで話題になる複雑GUI会。その方々が「技術書典 応援祭」で『入門GUI』という本を頒布していたので、読んで写経を行いました。 複雑GUIの会を主催した - No Regrets in Bathing 複雑GUIという名前からわかる通り、本書ではブラウザのSelectboxを自前で実装する章、バウンディングボックス、並び替え、スクロールに連動するヘッダーDnDなど、普段Webフロントエンドをやっているとライブラリに頼りがちな箇所の実装を解説しています。 入門GUI ーWebブラウザで作る本格インタラクションー：複雑GUIの会 感想 ここからは感想です。 React, Vue, Web Componentsといろんな実装方法が使われていて実装の差が面白かったです。とりあえず第1章の自作Selectと第3章のスクロールと連動するヘッダーを比較的得意なReactで写経してみました。 第2章のバウンディングボックスは、今までやったことのない類の実装で結構苦戦しました。自作Selectやヘッダー、DnDはちょっとだけ触ったことがあったのですが… 最後の第5章では、Web上でデザインしてそのまま公開できる『STUDIO』のCPOを迎えてGUIの未来についての座談会の文字起こしを取り上げています。 NoCode系サービスが生み出す、新しいレイヤーの話や、メンテナンスの話。GUIと相性の悪いものの話、GUIの進化系など、ソフトウェアエンジニアとして未来を考えさせられる話をしています。 本では言及されていませんが、個人的にはスマホの次のGUIがめちゃ気になりです。 最近のフロントエンドはデータの取り回しに関心が集まっている雰囲気を感じますが、2010年代前半を感じさせる『入門GUI』にはすごい親近感がわきました。GUIパーツの自作、割と好きな方なので非常に面白かったです。

Wordで組版をしていくにあたって、Wordのアプリケーション上で文章やサンプルコードを入力していくのは現実的ではありません。 見出しのスタイルを当てたり、シンタックスハイライトを手動で当てていくのはMarkdownになれた人間がやるべきことではありません。ツールにまかせるべきです。そこで利用するのがPandocというツールです。 はじめてのPandoc Pandocとは？ Pandocはドキュメントの形式を変換するツールで、MarkdownやPDF、ePub、Wordなどの多くのフォーマットに対応しています。今回は、MarkdownからWordに変換する用途でPandocを利用します。 Pandoc - About pandoc Pandocのインストール Pandocは公式サイトからインストールします。 ターミナル（端末）から次のコマンドを入力して、バージョンが出力されたらインストールは成功です。 $ pandoc -v Pandocの実行 適当なMarkdownファイルを用意して、今回はentry.mdという名前で保存します。 コマンドラインで以下のコマンドを実行しましょう。 pandoc entry.md -o result.docx result.docxというワードファイルが生成されれば成功です。entry.mdに記述したマークダウンがWordファイルに変換されているはずです。 ただ、標準のテンプレートは少しダサく、そのまま印刷に回せるものではないと思います。Pandocにはカスタマイズしたテンプレートを利用する機能があるので、標準のテンプレートを次のコマンドで取り出します。 pandoc --print-default-data-file reference.docx > reference.docx その後、スタイルを整えた後に、次のコマンドでカスタマイズしたテンプレートを利用します。 pandoc entry.md —reference-doc=custom-reference.docx -o result.docx うまく動いていれば、カスタマイズしたテンプレートが適用できているはずです。 テンプレートに関しては、以下のポイントを意識作ると使いやすいテンプレートができます。 スタイル（見出し、本文）に対して、装飾を当てていく スタイルの継承を利用する ショートコード（ページ、章の表示）を利用する 参考 MS Wordで柱に章番号・テキストを表示する方法 - mottox2 blog docxファイルの中身を覗いてみよう - mottox2 blog defaults.ymlの利用 設定が増えてくると、どんどん実行するオプションが増え長くなっていきます。これらのオプションはファイルから与えることも可能で「Default files 」と呼ばれています。 例えば、次のymlをdefaults.ymlとして保存し、次のコマンドを実行します。 default.yml from: markdown+hard_line_breaks to: docx output-file: result.docx input-files: - entry.md reference-doc: custom-reference.docx pandoc -d defaults.yml このようにファイルに設定を落とすことで、コマンドの煩雑さも減り、管理がしやすくなります。 テンプレート これらの設定を利用するためのテンプレートを用意したのでぜひお使いください。 mottox2/pandoc-word-starter: Pandoc template for docx 次のコマンドでWordファイルが生成されます。 pandoc -d defaults.yml

Word組版を実現するにあたって理解しておくといいことに、Wordのファイル形式を意識することです。 そこで本記事では、Word組版を始めるにあたって知ってほしいファイル形式について簡単に掘ってみましょう。 Cheap Dive into docx1 Wordのファイル形式『.docx』は、実際はOffice Open XML（OOXML）というXMLをベースとしたファイル形式を採用しています。実際に、docxファイルをzipファイルとして展開すると次のようなファイル群が現れます。 docxfile ├── [Content_Types].xml ├── _rels ├── docProps │ ├── app.xml │ ├── core.xml │ └── custom.xml └── word ├── _rels │ ├── document.xml.rels │ └── footnotes.xml.rels ├── comments.xml ├── document.xml ├── fontTable.xml ├── footer1.xml ├── footer2.xml ├── footnotes.xml ├── header1.xml ├── header2.xml ├── media │ ├── rId33.png │ └── rId62.png ├── numbering.xml ├── settings.xml ├── styles.xml ├── theme │ └── theme1.xml └── webSettings.xml このようにWordは複数のxmlで情報を持っています。 代表的なxmlと内容の対応を示します。 word/document.xml - ドキュメントの内容 word/footer1.xml - フッターの情報 word/media - メディア（画像等）の情報 word/styles.xml - スタイル情報 重要なのはwordディレクトリ内にある、document.xmlとstyles.xmlです。各ファイルの一部を抜粋します。 document.xml <w:p> <w:pPr> <w:pStyle w:val="2" /> </w:pPr> <w:bookmarkStart w:id="44" w:name="spaで開発する根拠は何" /> <w:r> <w:t xml:space="preserve">SPAで開発する根拠は何？</w:t> </w:r> <w:bookmarkEnd w:id="44" /> </w:p> <w:p> <w:pPr> <w:pStyle w:val="FirstParagraph" /> </w:pPr> <w:r> <w:t xml:space="preserve">最近のウェブフロントエンド開発では、2章で扱うフレームワークの存在もありますが、SPAが採用されることが増えてきました。</w:t> </w:r> <w:r> <w:br /> </w:r> <w:r> <w:t xml:space="preserve">技術を決定する際に、その決定理由を言語化できるかは重要です。開発者目線でSPAを採用すると何が嬉しいのか？を複数の観点から説明します。</w:t> </w:r> </w:p> <w:p> <w:pPr> <w:pStyle w:val="3" /> </w:pPr> <w:bookmarkStart w:id="45" w:name="npmエコシステムの利用" /> <w:r> <w:t xml:space="preserve">npmエコシステムの利用</w:t> </w:r> <w:bookmarkEnd w:id="45" /> </w:p> <w:p> <w:pPr> <w:pStyle w:val="FirstParagraph" /> </w:pPr> <w:r> <w:t xml:space="preserve">SPA以前のウェブでは、jQueryをベースにライブラリを大量に突っ込んで作るのが主流でした。</w:t> </w:r> <w:r> <w:br /> </w:r> <w:r> <w:t xml:space="preserve">jQuery系のプラグインはパッケージマネージャで使えない場合があり、（CDNを利用しないのであれば）minfyされたJSファイルをプロジェクト中に置くことになるでしょう。</w:t> </w:r> <w:r> <w:br /> </w:r> </w:p> <w:p> styles.xml <w:style w:type="paragraph" w:styleId="1"> <w:name w:val="heading 1" /> <w:basedOn w:val="a" /> <w:next w:val="a0" /> <w:uiPriority w:val="9" /> <w:qFormat /> <w:rsid w:val="00921183" /> <w:pPr> <w:keepNext /> <w:keepLines /> <w:numPr> <w:numId w:val="13" /> </w:numPr> <w:spacing w:before="480" w:after="0" /> <w:outlineLvl w:val="0" /> </w:pPr> <w:rPr> <w:rFonts w:ascii="Arial" w:eastAsiaTheme="majorEastAsia" w:hAnsi="Arial" w:cstheme="majorBidi" /> <w:b /> <w:bCs /> <w:color w:val="262626" w:themeColor="text1" w:themeTint="D9" /> <w:sz w:val="32" /> <w:szCs w:val="32" /> </w:rPr> </w:style> <w:style w:type="paragraph" w:styleId="2"> <w:name w:val="heading 2" /> <w:basedOn w:val="a" /> <w:next w:val="a0" /> <w:uiPriority w:val="9" /> <w:unhideWhenUsed /> <w:qFormat /> <w:rsid w:val="00C011D5" /> <w:pPr> <w:keepNext /> <w:keepLines /> <w:numPr> <w:ilvl w:val="1" /> <w:numId w:val="13" /> </w:numPr> <w:spacing w:before="200" w:after="0" /> <w:outlineLvl w:val="1" /> </w:pPr> <w:rPr> <w:rFonts w:asciiTheme="majorHAnsi" w:eastAsiaTheme="majorEastAsia" w:hAnsiTheme="majorHAnsi" w:cstheme="majorBidi" /> <w:b /> <w:bCs /> <w:color w:val="262626" w:themeColor="text1" w:themeTint="D9" /> <w:sz w:val="28" /> <w:szCs w:val="28" /> </w:rPr> </w:style> <w:style w:type="paragraph" w:styleId="3"> <w:name w:val="heading 3" /> <w:basedOn w:val="a" /> <w:next w:val="a0" /> <w:uiPriority w:val="9" /> <w:unhideWhenUsed /> <w:qFormat /> <w:rsid w:val="00D808E1" /> <w:pPr> <w:keepNext /> <w:keepLines /> <w:numPr> <w:ilvl w:val="2" /> <w:numId w:val="13" /> </w:numPr> <w:spacing w:before="200" w:after="0" /> <w:outlineLvl w:val="2" /> </w:pPr> <w:rPr> <w:rFonts w:asciiTheme="majorHAnsi" w:eastAsiaTheme="majorEastAsia" w:hAnsiTheme="majorHAnsi" w:cstheme="majorBidi" /> <w:b /> <w:bCs /> <w:color w:val="262626" w:themeColor="text1" w:themeTint="D9" /> </w:rPr> </w:style> <w:style w:type="paragraph" w:customStyle="1" w:styleId="FirstParagraph"> <w:name w:val="First Paragraph" /> <w:basedOn w:val="a0" /> <w:next w:val="a0" /> <w:qFormat /> </w:style> <w:style w:type="paragraph" w:styleId="a0"> <w:name w:val="Body Text" /> <w:basedOn w:val="a" /> <w:link w:val="a4" /> <w:qFormat /> <w:rsid w:val="000D2419" /> <w:pPr> <w:spacing w:before="180" w:after="180" w:line="360" w:lineRule="auto" /> </w:pPr> </w:style> <w:style w:type="paragraph" w:default="1" w:styleId="a"> <w:name w:val="Normal" /> <w:qFormat /> <w:rsid w:val="00FA3EAF" /> <w:rPr> <w:sz w:val="20" /> </w:rPr> </w:style> 内容を見たところ、document.xmlには文章と<w:pStyle w:val="FirstParagraph" />といったタグが見れると思います。このFirstParagraphに対応するスタイルがstyles.xmlに存在します。 w:styleタグのw:styleId要素がw:pStyleのw:val要素に対応しています。 また、styles.xmlのスタイルを見てみましょう。 <w:style w:type="paragraph" w:styleId="a0"> <w:name w:val="Body Text" /> <w:basedOn w:val="a" /> <w:link w:val="a4" /> <w:qFormat /> <w:rsid w:val="000D2419" /> <w:pPr> <w:spacing w:before="180" w:after="180" w:line="360" w:lineRule="auto" /> </w:pPr> </w:style> <w:style w:type="paragraph" w:default="1" w:styleId="a"> <w:name w:val="Normal" /> <w:qFormat /> <w:rsid w:val="00FA3EAF" /> <w:rPr> <w:sz w:val="20" /> </w:rPr> </w:style> w:basedOnタグはその名の通り、スタイルの継承元を指定するタグです。 Wordのスタイルウィンドウからスタイルを見ると、『基準』の表示に対応しています。 まとめ ここまででわかったことをあげます。これら事実を知るとスタイルが重要なことがわかると思います。 WordファイルはXMLで構成されたファイルである。 コンテンツとスタイルは分離されている。 スタイルは継承することができる。 注釈 元ネタ ↩

技術書展8に向けてWordとPandocを使って同人誌を作っています。PandocではWordのテンプレートを用意して、その中にMarkdownで書いたコンテンツを流し込みます。この構成で大事なのがWordのテンプレートファイルです。 本らしいテンプレートを作る上でポイントになるのが、柱やページ番号（ノンブル）といった版面以外の部分だと思います。そこで本記事では柱とノンブルを調整していく方法を紹介します。 事前知識 ヘッダー・フッターの編集方法 Wordには、版面以外をいじるためにヘッダーとフッターというコンテンツ領域が設定されています。 編集するには、2通りの方法があります。 「挿入」タブ→「ヘッダー」または「フッダー」をクリック 編集領域のヘッダー・フッダー部分をダブルクリック 編集状態に入ると、「ヘッダーとフッター」タブになって、本文領域が薄く表示されます。 この状態で文字を入力、画像・フィールドの挿入を行うことで編集を行います。 奇数ページと偶数ページで内容を変える ヘッダー・フッターを編集する上で奇数ページには右側、偶数ページには左側にコンテンツを表示したいといったケースがあると思います。 その際は、「ヘッダーとフッター」タブの「奇数/偶数ページ別指定」にチェックを入れることで、奇数ページ・偶数ページのヘッダー・フッターをそれぞれ変更することができます。 フィールドを挿入する Wordでは動的な要素（ページ番号、最終更新日時、見出しのタイトル）などを埋め込む際にフィールドという機能が用意されています。 「ヘッダーとフッター」タブの「フィールド」ボタンをクリックすると、フィールドの一覧が表示されるのでその中から使いたいフィールドを選んで挿入します。 Word でフィールドを挿入、編集、表示する - Office サポート フィールドコードを可視化する 上記の方法で入れたフィールドは、通常フィールドの結果のみが表示されます。例えば、PAGEは1や12など実際のページ番号が表示されます。しかし、フィールドの実態は式なので、これを表示する方法も用意されています。 macOSではOption+F9、WindowsではAlt+F9を入力することでフィールドコードをそのまま表示します。 フィールドコードを直接入力する Cmd + F9を入力することでフィールドコードの入力欄をそのまま挿入できます。その中に任意のフィールドコードを書いていく事もできます。 フィールドコードをネストさせる場合はこの方法で入力する必要があります。 ページ番号を入れる ページ番号を各ページに入れていきましょう。 ページ番号はフィールドで表示できるので、フッターを編集状態にしたあとにフィールドから「番号>Page」を選択しましょう。 見出しを柱に入れる 見出しを柱に入れるのは、本文の見出しに対してスタイルが設定されている必要があります。フィールドを使えば見出しスタイルに応じて柱にテキストを挿入できます。 フィールドコードにSTYLEREF "見出し 1"を入力すると、見出しのテキストを参照できます。 『第2章 GatsbyJSの基礎』といったようにテキストだけでなく章の番号も入れたくなると思います。そういった際は、フィールドコードとしてSTYLEREF "見出し 1"\nと入力すると、見出しについている段落番号を参照できます。ただし、見出しに対して、段落番号が当てられている必要があります。 章に段落番号がついていない場合もあります。まえがき、あとがきといったコンテンツです。 段落番号があたっていない場合は、上記のフィールドコードの出力結果が0となります。もちろん制御用にIFというフィールドコードも用意してあるので、次のようなフィールドコードを入力します。

新型コロナウイルスによって、技術書典8は中止になりました。その流れを受けて新刊の頒布も中止になりました。ごめんなさいm(_ _)m 技術書展7、技書博1に続いて技術書展8や技書博3に向けて、つのぶえ出版として新作を書いています。今回は「フロントエンドの技術選定」「仕組みの理解」あたりをテーマに考えています。 ReactとVueの大きな違いは何？どんなケースで差が出るのか？ GatsbyとNext.jsは何が違うのか？（NuxtとGridsomeの違い） ネイティブアプリ開発に応用しやすいのはどれ？ SSRをしたい理由としたくない理由って何？ Next.jsやNuxt.jsにおけるhydrationとか何か？ Jamstackって何？どんなメリットがあるの？ 具体的には上記のような技術選定において「なんでこの技術を使うんだっけ？」みたいな箇所を1ページに1テーマ、解説を入れるイメージで書いています。 技術書展で買った本は積まれやすいという話も話題にあがりました。これに関しては自分も同意見で、どうも分厚い本は読むハードルが高いと感じていました。 そこで、当サークルではチュートリアル系の本を多く書いていたのですが、今回はページ完結型で36ページ程度、本当の意味での薄い本を書こうと思い当たりました。読み口が軽いのに、タメになる本を書きたい気持ちがあります。 扱うトピックもフレームワークやライブラリのチュートリアルだけでは気づきにくいポイントに絞ってあるので、脱初心者を図りたい人にピッタリの本になる予定です。 予定です。