僕はVSCodeをエディタに採用しつつ、Vimキーバインドを使う人間です。VSCodeではVSCodeVimという拡張機能が存在し、インストールすることでVimのキーバインドを使えるようになります。 そのVSCodeVimのドキュメントを読んでいたところ、今まで知らなかったコマンドを知りました。 最近はフレームワークのアップデートを追ったり、アニメーション実装の研究、技術同人誌の執筆などの「すぐ役に立つ」系のものに時間を使いがちでしたが、コーディングの基礎速度を上げるエディタ系の設定やプラグインの整備にも時間を使うべきだと思った次第です。 そんなわけで、みんなに知ってもらいたくて動画を撮って、After Effectsで簡単に編集してみました。動画の方が伝わりやすいと思います。 VSCodeVimで型定義やエラーを見たり（gh）、定義元に飛べる（gd）コマンドを知った。数年前に知りたかった。基本操作をちゃんと見直す時期になってきたかも？ pic.twitter.com/uARGBymEwS— もっと@技術書典8 Day2く28 (@mottox2) January 19, 2020 見直しておきたいドキュメント Visual Studio Code Key Bindings Keyboard Shortcut for Windows Keyboard Shortcut for macOS 各プラグインのREADME.md

Reactでページ遷移時のトランジションを実装しよう！となった時に思い浮かぶのはreact-transition-groupを使ったトランジションでしょう。ですが、react-transtion-groupは出現、消滅する際に付与するclassNameを指定して使うため、コンポーネント間でCSSの依存ができたり、他の箇所はCSS in JSを使っているのにトランジションをつけるためにcssファイルを設置したりなど難が多い印象があります。 本記事ではそういった課題を解決できるframer-motionというライブラリを使ったページトランジションの実装例をお伝えします。実践的なケースを想定しルーターにはreact-routerを利用します。 サンプル サンプルアプリには/と/aboutにそれぞれHome、Aboutというコンポーネントがあり、コンポーネントが切り替わるたびにアニメーションします。 また、Homeにおいてある「OpenDialog」のリンクを押すことでダイアログが出現する形にしています。ダイアログに関してはクエリパラメータで識別する形にして、ブラウザのバックボタンで閉じれる実装になっています。 実装のポイント FramerMotionの基礎的なものに関してはドキュメントを参考にしてください。 react-routerとアニメーション framer-motionの提供するAnimatePresenceとmotionのコンポーネントを利用すると、コンポーネントのアンマウント時にアニメーションをつけられます。すると、motionのexitに渡した状態になるアニメーションをしてアンマウントされます。 注意点ですが、その際にAnimatePresenceの子にあたるmotionコンポーネントにkeyプロパティをつけるのを忘れないようにしましょう。react-routerに関してはSwitchコンポーネントにkeyを指定する必要があります。 クエリパラメータを利用したアニメーション 実際のケースとしては少ないかもしれませんが、ダイアログにURLを付与しています。事前の画面をoverlapするフォームといった画面としったものを想定しています。 今回はlocation.searchからクエリパラメータを取得し、その有無でコンポーネントの出し分けをしています。AnimatePresenceとmotionを使うことでアニメーションがつくので特に難しいポイントはないと思います。 AnimatePresenceのprops サンプルコード中ではinitialにfalseを指定しています。initialをtrueにすると画面の初期表示の際にもアニメーションが実行されます。 また、exitBeforeEnterはAコンポーネントが消えてBコンポーネントが出現する際に、Aのexit→Bのenterといった順に実行されます。このpropsを指定しないとexitとenterが同時に発火されます。

年末年始なので普段気になってるけど、触る機会のなかった技術やライブラリに触ってみました。フロントエンド周りのトピックとして、Framer Motion, GraphQL, Flutter, FaunaDBの4テーマに触れてみました。 Framer Motion Reactのアニメーションライブラリです。react-springが競合にあたると思いますが、自分は逆張りでframer-motionを掘ることにしました。 framer-motionはFramerというデザインツールを提供しているチームが出しているライブラリで、以前紹介したreact-poseの後継にあたります。 個人的には小さなインタラクションやジェスチャーに対応していくことでネイティブアプリライクな操作感に近づくと思っています。React以前のウェブではjQueryライブラリが繁栄し、リッチな見せ方、インタラクションなどで独自の進化を遂げていました。ただ、Reactになってからは（特に日本では）こういった議論はされなくなったように感じています。使いやすいPWAに至る道には必要と思うので取り組みました。 framer-motionに関しては、次のようなメリットがあります。 宣言的にアニメーションを記述できるためわかりやすく再利用もしやすい React Routerと組み合わせても、リッチなトランジションが簡単に実現できる ドラッグやタップなどのイベントと組み合わせるのも楽 このあたりの実装に関してリポジトリを作って、使いたい時に使えるようにストックを始めています。 UIフレームワークの実装と違い、「薄めの実装にして、プロジェクトに取り込みやすく」を意識して進めています。 http://react-motion-training.netlify.com/ https://github.com/mottox2/react-motion-training 海外のReact系カンファレンスではアニメーション的なセッションがあるので、日本でも増えればいいなと思っています。 Flutter Googleが提供しているマルチプラットフォームアプリが書けるツールです。一応、情報としては追っていましたが、自分の言葉で説明できるようにしたかったので触りました。 Flutterそのものよりも、開発環境の整備状況に驚きました。セットアップも特につまずくことがなく進み、Android Studioにプラグインが提供されていて使ってみたらめちゃ楽でした。 生のRN（ReactNative）より書きやすく、RN + expoを使っている気持ちになりました。 monoさんのFlutterの効率良い学び方を参考に次の内容をこなしました。 公式のGet Started Codelabで提供されているチュートリアル UdacityのFlutter講座 これに加えてFirestoreとつなげてみたり、QRコード読み込みを試してみたりしました。 ふとしたタイミングで「Webでいいのでは？」という気持ちになりました。経験が学習を阻害するので「アンラーニングが大事」という言葉の重さを知りました。 去年、仕事でiOS（Swift）をやっていたので、エラーが出てもなんとかできる力がついたような気がします。 GraphQL クライアント側からGraphQLを利用するのはGatsbyでやっていたので、今回はサーバーサイド（RoR）でGraphQL APIを実装しました。 主に「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶに従い、気になる点はドキュメント等を参考にしながら追加で実装しました。（リポジトリ） 以前からチューニングがしんどい等の話は聞いていましたが、自分で実装してみてそのしんどさを感じることができました。クライアント側からはほしいフィールドを指定するだけで楽な一方、サーバー側へ実装の負担が寄る実感を得ました。 DBとつなぐことでGraphQL APIを生やせるPrismaやHasura、データストアとともに提供している後述のFaunaDBあたりを掘っていくとよさそうです。 FaunaDB NetlifyやZIET Nowで公式のIntegrationとして用意されているデータストア。データへはFQL（SQLライクなクエリ言語）、GraphQLの二通りの問い合わせ方法がある。 正直Firestoreがしんどいので、サーバーレスに向いているデータストアを探ってみたいというのが発端。 とりあえず触って主要なドキュメントも読んだけど、Flutterのチュートリアルと比べて英語が読みにくかった。 認証方法としてパスワード認証が用意されているが、3rd Party Loginに関しては言及されていなかったのでアプリ導入に関しては様子見。（中間サーバーとか立てれば行ける？でも、それならFirebase使う…） 自分用ツールのデータストアに使えるかも？もう少し時間をかけてみてもよさそう。 以上のような年末年始の自由研究をやっていました。皆様、今年もよろしくおねがいします。

もう2019年の終わりが見えてきた。今年の自分は何をやったのか、どういうことを考えていたのか、どういった反省が残ったのか、ブログ記事に残しておこうと思う。 ユーザーにより近い仕事を 仕事に関してはよりユーザーに近い側へ移行していったということに尽きる。 去年は『専門性を持ちたい』という気持ちでやっていたが、今年はiOSアプリをSwiftで始めたり、Railsの仕事を辞めたり、デザイナーの仕事を（数年ぶりに）始めたりした。かなり変化の激しい年だった。 Railsの仕事を辞めたのは、実力不足といった理由ではなく、ユーザーに近い側の実装をしたい気持ちが強くなったからだ。iOSの仕事をしたのもフロントエンドの一種なのでやる意義を感じたからで、Webにはないアーキテクチャの議論、iOS開発の事情・歴史などWebのフロントエンドにも応用できる知識と経験を積むことができた。 本来フリーランスで未経験の仕事はお互い不幸になりがちなので受ける気はなかった。ただ、インターン時代の同僚からの話だったので、お手伝いすることになった。アプリ開発初期のいちエンジニアとしてある程度価値を出せたと思っている。Freaxの開発チーム、ありがとう。 そして、もう1つの大きな変化がデザイナーの仕事を受けたことだ。今までもフロントエンドの仕事でPMの補佐でモックを作ったり、UIデザインを自分で作りながら実装をしていたこともあったが、あくまでメインはエンジニアという立場だった。 そもそも、インターン時代にはチラシ・パンフレット・広告・アプリデザイン、フリーランス時代初期にはSPA製SaaSのリードデザイナーをやっていたので、デザイナーの経験はあった。ただ、デザイナーだけで食べていけるか？というと怪しく、自分の周りではエンジニアの需要が多かった（し、単価も高い）のでエンジニアの仕事を中心にやっていた。 いまさらデザイナーの仕事を受けたのは、デザイナーとエンジニアリングの距離を縮めたいという気持ちがあったからだ。お手伝いしている先の開発チームはサーバーレスアーキテクチャを全面的に採用し、Reactを用いた開発を行っている。そういったサーバーレスやSPAの知識が役立つデザインの現場でデザイナーをすることは必ず意味があると考えた。 これは11月から始めたので大した動きはできていない。デザイナーは会社の空気や、PMの人柄・性格、業界知識を知るほうがいいという考えを持っているため、数年ぶりに定期的に出社している。体が全然ついていっていない自覚はあるので、もう少しなれたらパフォーマンスが出せるようになっていくだろう。 来年からはこの方向性での仕事を強化していくつもりでWeb・アプリエンジニアの知識を生かした動きをしていくのがよいと考えている。 去年までは『専門性を持つ』方針でやっていたが、今年は幅広い仕事の機会をいただくことができた。一昨年までは器用貧乏と感じていたことも、昨年フロントエンドに注力したことで、深みのある器用貧乏になれたと思っている。また、今後PWAでエンジニアリングとデザインのマルチスキルが生きるのでは？と思いこういう方向性でやっている。 今も年末年始の自由研究でReactを用いたリッチなトランジションやマイクロインタラクション、アプリデザインなどを深堀りしている。（今まで苦手意識のあったAdobe系のツールとも和解できた気がしている。） この方向で今までとは違うアウトプットが出せていけたらという思う。おそらく世間で言うデザインエンジニアという職種に当たると思う。そこで、来年は『自信を持ってデザインエンジニアと名のれるようになる』を目標にしていこうと思う。 アウトプットは減速 LT、ブログといったアウトプットは調子が悪く、下半期に関しては体の不調と重なって絶不調だった。技術同人誌も去年並で、強いて言えば、OSSでは大きめなツールを公開できたのが唯一の成長かもしれない。 LT・登壇に関しては、登壇枠を確保することに苦戦した。回数で比較することに意味はないが、去年が14回で、今年が7回なので半分になってしまった。 5分枠では話しきれないのはわかっていたので10分以上の枠を中心に申し込んだが、そういった枠は抽選になることが多くなかなかLT枠を得られなかった。 ただJavaScript祭の登壇は抽選枠ではなく、クローズドな募集で登壇の機会をいただけたのが嬉しかった。こういった枠に呼ばれるように、より質の高いLT・登壇を行っていきたい。 スライドテンプレートや図表に関しては制作スキルが上がり、より早くいいかんじのスライドが作れるようになった。今後はデザインスキルを生かした発表ができるかもしれない。 ブログに関してはとても酷い状態だった。write-blog-every-weekというコミュニティに所属して、毎週ブログを続けているが、このコミュニティがなかったら確実にブログが途切れたと思っている。というのも、ブログを書き続けていくうちに、自分の書く文章と内容に満足ができなくなってきたからだ。これに関してはある程度の妥協と、自信を持つための鍛錬を重ねていくべきだと思っているが、仕事の楽しさ故なかなか優先できない状況が続いている。もうしばらくすれば余裕ができてブログの優先度もあがるかもしれないが、なかなか先の見えない状況である。 今年新たに始めたアウトプットにハンズオンがある。ハンズオンに関してはサポーターズCoLabさんが、若手エンジニアが教え・学ぶイベントを多く開催しており、自分も例にもれずハンズオンの機会をいただくことができた。オフラインではGatsbyJSとNetlifyの2テーマ、配信形態のハンズオンではGatsbyJSと3回のハンズオンを行うことができた。ただ、やってみてわかったのは複数人同時に教えるのは難しく、習熟度や環境構築なども異なるということだ。 しかし、技術同人誌を書いてることもあり、人に伝える・教えるというのは嫌いでないので続けていきたい。配信のハンズオンをやって、YouTubeでのプログラミング動画、生配信に興味を持ったので来年のどこかでやれたらと思う。最悪、Twitterに動画を投稿する形でもいいので人への伝え方・教え方についても深堀りしていきたい。 技術同人誌へは、サークル主の立場とは別にイベント運営チームとしても関わるようになった。サークル主としては新刊を4冊（うち1冊は既刊の大幅改定）を出すことができた。個人的にはGatsbyとNetlify本の内容に自信をもっていたが、イベントでの売れ行きはSlack本の方がすごかった。ただ、自分が一般参加者のときは巷では読めないような本が好きなので、もっとニッチな本を書いていきたいと思う。次回はReactベースのNext.jsを新刊として出す予定だ。 サークル主ではないが、「ワンストップ技術同人誌」の親方プロジェクトでも寄稿を続けている。多数の著者でわちゃわちゃしながら書いていくワンストップ本は（単著ほど）まとまりはないが、一人では作れない知見の塊を生み出せていると思う。今後もアプリ本や生き方本を書いていくので興味を持ったら問い合わせをオススメする。その日から著者になれるはずだ。 運営チームとしては技書博（技術書同人誌博覧会）というイベントに関わっている。主賓のariakiさんから誘われ主にウェブサイト担当として公式サイトの開発をやったり、イベント当日はスタッフとして関わった。公式サイトに関しては、技術的な素振りを兼ねてFirebase + Next.jsを使っており、多くの知見を得ることができた。次回はサークル参加を予定しているので、大きな変化は起きないかもしれないが、よりよいサイトにしていければと思っている。当日スタッフで出会った人と意気投合し、新しい動きもできそうな気もしている。 最後にOSSというテーマだ。上半期は小さなツールを作ったり既存のリポジトリにプルリクエストを送ったりしていたが、下半期にはお手伝いしている会社からちょっと大きめなOSSを公開した。パワーポイントを出力するサービスの、ファイル生成部分をJSXで書けるのでは？という疑問から始まったツールだが、ある程度有用性が認められOSSとして公開するところまでやれたのは非常にいい経験になった。 ただ、既存のOSSへのコントリビュートが減ってしまったので、お世話になっているOSSへの貢献の気持ちは忘れないようにしたい。 仕事以外を充実させたい プログラミングは仕事であり、趣味でもある。一見いいフレーズだが、仕事以外の時間が減っている印象を受けている。勉強時間を確保するため、フリーランスとして受ける仕事も抑えているが、別途プログラミングやサービスづくりに時間を作っているので、仕事以外で充実を感じることは減ってきているように思える。 とくにに中学生から続けている楽器（ホルン）に関しても、市民オーケストラに所属はしているが、最近は勉強会の登壇やカンファレンスの参加、同人誌イベントのために休みがちになってしまっている。（ITエンジニアと週末のサークル活動は相性が悪い）また、楽器歴が長くなってきた分、上達を感じられず歯がゆい気持ちも強くなってきている。いちおう日常的に、ゲーム（Fortnite）をやったり、YouTubeを見たりはしているが受動的な活動なのか充実している感じはしない。 今後、もしプログラミングやサービスづくりに嫌気を感じてしまったときに怖くてしょうがない。仕事以外に熱中できるものを探すべきなのでは？とも感じている。なので、人からオススメしされたアクティビティをひととおりやってみるのもいいかもしれない。 来年へ向けて 大してなにもやっていないような気がしていたが、書いてみたらそれなりに状況が変わっていて驚いている。 仕事以外がおろそかになってしまっているのは否定できない。ただ、今は非常に楽しく仕事に向き合えているのでこのまま前に進んでいけたらと思っている。なれない環境・規模・業種・職種で悩むことも多いと思うがやっていきの気持ちを持ち続けていく。 仕事以外の余暇もうまく見つけていきたい。さいわい、外出への抵抗感は薄れてきているのでいろんな人とあって、オススメされるがままにいろんな活動をしていけば見つかるような気はしている。 一歩ずつ、しっかりと。

12月14日に開催された『技術同人誌博覧会』で手に入れた『探求 SVGとスクリーンショット』を読みました。タイトルの時点で『おっ？』となるようなものですが、めちゃくちゃ深い一冊でした。 なお、JSとフロントエンドをそれなりに程度いじっている人向けの内容でした。 探求 SVGとスクリーンショット 第1章 簡単なSVG画像をつくる 第1章はこの本唯一の初心者向けの内容です。いわゆる普通のSVGを説明した後に、ラスタ画像・リンクの埋め込み方、モノクロ化の方法などSVG Screenshotにつながる使い方の説明をしています。 言われればなるほど…となるのですが、初めて見た使い方で驚きました。 第2章 SVG Screenshot開発機 作者の開発しているSVG Screenshotについて説明しています。SVGに付与するメタ情報の取得方法、Pupperteerを使ったスクリーンショットを撮る方法などかなりテクニカルな話が読めます。 SVGはXMLをベースにしているので、それを活かしメタ情報（リンクや元URL）を付与する考えでした。その中でも画像やリンクの情報を保持し続けるなど実用性の高い形になっていて、非常に面白いものでした。 第3章 高解像度ディスプレイで撮ったスクリーンショットを適切なサイズで表示する 端末ごとの画面密度の違いを吸収するための話です。なんとこの本ではこのテーマだけで1章を割り当てています。 画面密度を考慮して表示する方法と、画面密度を算出する方法を、作者がどのようにして探っていったかがわかる内容になっています。すごく泥臭い感じですが、臨場感があって好きです。 第4章 ScreenshotMLの提案 筆者が提案しているScreenshotML（Screenshot Markup Language）について説明しています。 スクリーンショットに付随する情報をXMLで表現することで、見た目と情報の分離を行い拡張性の高い仕様を実現しようとしています。説明中でXMLにスタイルを指定するXSLやスキーマを記述するXSDなどに触れており、読者でも独自のXML拡張言語が作れるようになっています。 独自仕様を決めるときは仕様の決めが難しいと思ってるんですが、しっかり仕様を固めていて作者の強さを感じる内容でした。 付録 『PNG画像のバイナリから解像度を読み取る』、『Blinkでの画像のNaturalSize導出過程を追う』など非常にマニアックな付録です。SVGの本を読んでいてバイナリを読み始めたときはびっくりしました。 感想 SVGスクリーンショットというと、ベクターでスクリーンショットを保存するのと思いきや、ラスター画像とメタ情報を同居させる方法。ラスター画像のメタ情報より手軽に扱えるので面白い考え方だと思います。 作者はスクショなどのキャプチャを保存・共有するGyazoというサービスを提供する会社に所属しているようで、仕事と趣味が近そうで非常に楽しそうです。この本自体も同社の運営するScrapboxで執筆したらしいです。すごい（けど、意味がわからない） 私はNode.jsでXMLを作る仕事をしているのですが、仕事にも活きる内容が書いてあったので大満足です。SVGやXMLに興味のある方に読んでもらいたい同人誌でした。

こちらは Next.js Advent Calendar 2019 17日目の記事です。 Next.jsの話をすると「ReactでSSRをするやつでしょ？」と言われます。正しくはありますが、その答えでは不十分です。 ここでNext.jsの公式サイトを見るとランディングページにはThe React Framework for Production Server-rendered App, Static Websites, the Enterprise, the Desktop, the Mobile Apps, SEO-Freiendly App, PWAs and Electronとあります。要するに、いろんな用途に使えるということです。 SSRを使用しないのであれば、「ユーザー向け（Not管理画面）なサービス開発であればCRA（create-react-app）で十分じゃない？」と思う方もいるかもしれません。 そこでなぜ私はNext.jsを使うのか？という理由を整理してみました。チームの技術選定でNext.jsを候補に入れている方に届けば嬉しいです。 比較対象 CRA(create-react-app)はFacebookが提供しているReactのプロジェクトをセットアップするコマンドです。CRAで作られたプロジェクトはreact-scriptsというパッケージを通してプロジェクトの開発を行います。react-scriptsの範囲で開発を行うのは簡単ですが、自分で拡張しようとすると力技が必要になります。 自分でフロントエンド開発周りの設定を行う方法もあるでしょう。これはwebpackなどの設定を自分で書いた上で、expressなどのサーバーの上でReactをレンダリングする仕組みを実装する方法です。 自分でSSRの仕組みを実装し、本番運用をしていたこともありますが大変でした。 これらの比較対象を頭にいれた上で、Next.jsのメリットを整理してみました。 具体的なメリット フロントエンドの足回りが整う。 CRAでも同じメリットが得られますが、webpackやbabelといった開発に必要なツールをフレームワーク側に持たせることができます。 もし、自分で設定するとなると、webpack本体やwebpackのプラグインのアップデートはもちろん、設定ミスによるバグを自分で解決する必要があります。また、保守においても属人化しやすく、担当者がいなくなってしまったために触れなくなった…などという話も聞きます。 IMOですが、これらの設定を自分でカスタマイズするのは組織として大きくなり、開発の足回りを整える役割ができてからでも遅くないと感じています。初期はアプリケーション開発に専念するためにフレームワーク側に設定を隠蔽してもらうことをおすすめします。 CRAでは設定を拡張するのに、eject（隠蔽されていた設定を露出させる）やreact-app-rewrited（CRAの設定を拡張するための”非公式”ツール、積極的なメンテは行われていない）を利用する必要がありますが、Next.jsでは標準でwebpackの設定を拡張できるので、簡単な拡張であればフレームワークを外れずに行えます。 管理画面的なReactアプリケーションでNext.jsを使おうとするとルーターとの相性が悪いですが、ユーザー向けなSPAであれば問題はありません。 SSR（サーバーサイドレンダリング）をやってくれる React単体で行うクライアントサイドのレンダリングだけでは、クローラーが対応しない限り内部のコンテンツは読み込むことができず、ほとんど空のindex.htmlを読むことになります。 Googleのクローラーは対応を初めていますが、FacebookやTwitterなどのクローラーはクライアントでレンダリングしたコンテンツを読むことができません。（従来のWebページと完全に互角とは言えません）そのため、SNSシェアする際に、ページごとにOGP情報を設定することができませんでした。 また、クライアントでレンダリングを行うということは、レンダリングされるまではユーザーからは真っ白なページが表示されることになります。クライアントのレンダリングでは通信速度や端末の性能にも依存することがあるので、ユーザーによってはページ表示まで長い時間を待つことになります。 こういった問題に対応するためにSSR（サーバーサイドレンダリング）が行われます。通常クライアントでやっていたレンダリングを、サーバーで行うことでページごとにレンダリングされたHTMLを配信します。また、HTMLを読み込み後はSPAとして動作します。 Next.jsがこういった仕組みをフレームワーク側で提供してくれます。（自分で作ると、保守やドキュメンテーションが大変だったりします。） Static Exporting ビルド時にSSRし、レンダリングした結果をHTMLファイルに出力する機能です。このHTMLファイルを利用するとSSRが必要なくなり、本番環境では静的ファイルを配信する単純な構成になります。 HTMLファイルと言っても、SPAのメリットは失われません。HTMLを読み込み後、JSが実行されるとSPAとして振る舞います。 SPA単体で利用した際に、デメリットとなる表示速度やOGP問題などを回避しつつ、SSRによる保守コストも負う必要もありません。ただし、コンテンツの更新などで配信するHTMLを変更する際には、ビルドを行う必要があるため、コンテンツの更新を即時反映できない等のデメリットがあります。 この方向性で、より高性能なStatic Exportingを行うフレームワークとしてGatsbyJSというものもあります。 速度の最適化 フレームワークに乗ることで機能要件だけでなく、ページの表示速度面といった非機能要件でのサポートも行ってくれます。例を上げると、次のようなものがあります。 ルーティングごとにJSファイルを分割 ページ上に存在するリンクを見て、リンク先のJSを先読み ビルドの最適化（共通部分をcommon.jsなどのようなファイルにまとめてくれる） 開発時に重いページがあるときに警告を表示 その他 目立った機能ではありませんが、Googleが中心になって進めているAMP HTMLを出力する機能があります。 他にも、Next.jsを開発しているZEIT社が提供しているnowという開発プラットフォームへのデプロイが簡単などのメリットも得られます。（本番で使ったことはないですが、no configなデプロイが可能です。） また、機能ではありませんが、Next.jsではexampleが提供されており、非常に多くのケースが想定されています。 まとめ Next.jsを使うと以上のようなメリットが得られ本番運用に必要なパーツが一気に揃います。 SSRじゃない場合でもStatic Exporting、またはServerlessと組み合わせることで実運用に乗せることも可能です。（これに興味を持った方はJAMstackを掘っていくと面白いです） 今までは過剰なミニマムと言われていましたが、最近は機能的にも充実してきており、Chrome Dev Summitでも取り上げられるなど将来が楽しみなフレームワークです。 まずは年末の自由研究にNext.jsを触ってみてはどうでしょうか？ Next.jsは比較的薄めなフレームワークなのでReactを学習した方であれば覚えることは多くありません。 技術書典8ではNext.jsの本を書きたいと思っており、言語化を進めています。もし新刊が無事に出せたらよろしくおねがいします。

We are JavaScripters、略してWeJS。そんなWeJSが3周年ということで「WeJS Festival！」というイベントが開催されました:tada: そんな、超イケイケなフェスにPowerPointをテーマに殴り込んできました。 話してきたこと 内容 PowerPoint製のレポートを提供するサービスを運営している会社の研究開発をお手伝いしています。 そのサービスでは複雑なレイアウトのPowerPointファイルを提供しています。もちろん、その複雑なPowerPointを組むためのコードが内部で動いているわけです。 そのコードはいわゆる命令的なコードでUIを組む、座標や要素の大きさを数値で指定する感じのものでした。 変更コストが高いので、そういったコードがReactのパラダイムで動くようになればサービスの進化が早くなると思いました。 そういった理由からPowerPointをReactで組むライブラリを作ったので、それを発表しました。 現在は本ライブラリを使ってサービスのプロトタイプを作っている段階ですが、今後の話もどこかでできたらと思います。 リポジトリ 本体 kobit-develop/jsx-presentation テンプレート kobit-develop/jsx-presentation-starter 感想 Cybozuさんのオフィスがめっちゃきれいだったり、WeJSクッキーや飯がとても美味しかったのが記憶に残っています。基本的に大きな部屋で他の登壇を見ていました。 ReasonMLやJSの処理順序の話など面白いテーマが話されていましたし、特に@ __ sakito__さんの発表は会場の一体感を含めラストにふさわしいライブコーディングでした。自分もASTを使ってなにかできそう！という気持ちになりました。 運営の皆様、3周年おめでとうございます！こういったタイミングで登壇の機会をいただけて嬉しかったです。

最近、PowerPointファイルを生成するツールを作っています。 「PowerPointを作る」というと難しいと思われるかもしれません。しかし、OOXMLという仕様に従いXMLを作ってZIP形式で圧縮するだけでPowerPointファイルを作ることができます。 しかし、OOXMLはWeb上に仕様書以外の情報がほとんどありません。 そこで、OOXMLについて書かれた希少な本、「Office Open XMLフォーマットガイド」を読んだので紹介します。 https://www.amazon.co.jp/gp/product/B07ZJ4ZZZB この本の良かったところ Webにほぼ存在しない情報が一冊にまとまっている。 仕様のざっくりとした解説でOOXML入門に最適。 図解が多く、視覚的に理解しやすい。 取り扱っている内容 OOXMLでサポートしている形式としてはWordprocessingML、SpreadseetML、PresentationMLとある。この本では、3つの形式について触りを行った上で、WordprocessingMLを中心に深堀りする内容になっています。 自分が読んで気に入った箇所について紹介します。 第1章 Office Open XMLとは OOXMLの概要や仕様書について取り扱っています。OOXMLに今から取り組みたいという人にピッタリの内容です。仕様をダウンロードしたときのファイルの解説まで書いてくれているのがよかったです。 第2章 導入（HelloWorld） WordprocessingML、SpreadseetML、PresentationMLのそれぞれについて最小構造のファイルを作って内容を確認していく章です。 最小構造といってもPresentationMLではSlideMaster、SlideLayoutといった要素にも言及しておりかなりボリュームのある内容になっていました。 第4章 文章（WordprocessingML） Wordファイルを構成するWordprocessingMLの章です。第2章では最小構造のファイルを作りましたが、この章では段落番号・箇条書き、共通の文字スタイル、図形などの踏み込んだトピックについて解説しています。特に、（見落としがちな）日本語の扱いについて説明しているのが良かったです。 第5章 描画（DrawingML） 図形描写を行うDrawingMLについての章です。最初に図形の基本単位であるEMUについて取り上げ、テーマや色、フォント、グラデーション、図形などの要素について取り上げています。 特に図形に関しては多く取り上げられていて、図解も多くわかりやすかったです。 感想 OOXMLを利用したツールを開発するのであれば必読の一冊だと思います。 自分が目的としていたPresentationMLについては触り程度しかありせんが、それでも十分に役にたつ内容でした。（ツールを開発する前に読みたかった気持ちはあります） ちなみにKindleで技術書を読むときは、iPad 12.9インチが便利です。

先日、『転職透明化らぼ』というイベントに参加してきました。 転職透明化らぼは転職に関わる情報を透明化して企業・個人双方にとってよりよい転職が増えることに貢献するのが目的です。 今回のテーマは『技術ブランディング』で、なぜ企業は技術ブランディングを行うのか？　個人として技術ブランディングが出来るとどううれしいのか？　といった内容で、個人の技術ブランディングについて話せないかというオファーが来たのでパネラーとして参加してきました。 また、他の登壇者の内容はないぱかさんがブログにまとめてますので、そちらをご覧ください。 【イベントレポート】第4回 転職透明化らぼ-技術ブランディング編 - あるぱかになりたい 本記事では自分が話した内容を簡単にまとめました。 話したこと 今回のイベントでは、次の2点を伝えたいことに設定し話をしました。 すべての人に知られる必要はない。 まずは、個人の活動を発信すること。 前提 Web系企業のアプリケーションエンジニアの視点からなので偏りもあるかもしれません。 また、技術を掘ったり勉強するのが苦ではないタイプです。 個人のブランディングができている状態って？ 今回のイベントのパネラーが3人で翔泳社の近藤さん（ゆうこりん）、クラウドワークスの飯田さん、フリーランスのmottox2（私）という並びでした。 この3人の中で一番パッとしないのに個人のブランディングについて話していいのか？ 　という観点で話を始めました。 具体的には、「僕のことを誰だ？　と思った人。それが正しい反応です」という一言から始めました。 「ブランディングができている個人は誰だろう？」という問いをすると、まつもとゆきひろさんや伊藤直也さんなどの人が思いつくかと思います。ただ、すべての人がこのレベルの認知を得るのは現実ではありえません。 ここで引き合いに出したのがYouTuberやVTuberです。みんなに認知されている人は誰かというと、ヒカキンさんやはじめしゃちょーさん、キズナアイさんが思い浮かぶと思います。 ただ、「あなたの好きなYouTuber/VTuberは誰ですか？」と訪ねたときに彼ら・彼女ら以外を上げる人も多いと思います。具体的に上げるとスプラトゥーンの実況者や、歌を歌うVTuber、ひたすらタイムを競い合うRTA奏者などです。この人達をエンジニア界隈で例えると、勉強会で何度もLTをしており、Twitterでフォローしてて「何をやっているかわかる人」に当たると感じています。 つまり、何をやっているか、出来る人なのかが認知されていれば個人としてのブランディング（差別化）は達成されてそうです。よって、自分が人事やWebフロントエンドエンジニア以外の人に知られていないのは、技術ブランディングを語る上で問題はないと考えています。 まとめると、対象の人達に何ができる人なのかが認知されていること＝技術ブランディングが達成されている状態と考えています。言いかえるとすべての人に知られることがゴールではないということです。 個人の活動を透明化すること GitHubで特定のOSSにコントリビュート、ブログや技術同人誌で特定分野について書く、スピーカーとして勉強会に参加する、ものづくりをして発表するような行動を続けることで認知につながっていきます。一つ抑えておきたいのは、自分の活動を表に出していくこと。つまり個人活動の透明化です。 ただし、透明化さえ意識しておけば、ブランディングを意識することはあまりないと考えています。 話に使ったスライド 感想 登壇することになり、あらためて技術ブランディングについて考え直し、言語化する非常によい機会になりました。 技術に関する勉強会ではなく、他の登壇者もすごい人たちばっかりなので非常に緊張しました。 運営スタッフの方や会場・飲食のスポンサーをしてくださった企業様、雨の中会場に足を運んでくださった参加者の皆様、ありがとうございました。

自分は2015年ぐらいからSketchというMac専用のデザインツールを利用してきました。しかし、最近はFigmaというツールをよく聞き、知人から（とくに@takanorip氏）も評判がいいので触ってみることにしました。 基本的にNo Knowledge, No Pluginな状況での乗り換えなので、もっと便利だぞ…と思ったらツッコミをください。 ショートカットキー 基本的にSketchと同じショートカットキーを使えますが、ブラウザのショートカットとぶつかる操作に関しては別のキーが割り当てられています。 次の表は自分が乗り換える際に戸惑ったものです。 操作SketchFigmaフォントを大きくするCmd + Option + UpShift + Cmd + >フォントを小さくするCmd + Option + DownShift + Cmd + <opacityを10%に変更Option + 11opacityを100%に変更Option + 00 キーボードショートカットに迷ったときは『Ctrl + Shift + ?』でショートカットキー一覧が表示されます。 これを参考によく使うキーバインドを覚えておくといいでしょう。 SymbolはComponentに Sketchでは、再利用可能なレイヤーを『Symbol』という概念で管理していました。一方Figmaでは『Component』という単位で再利用可能なパーツを管理します。 Sketch Symbolを利用する際は、「Symbols」というページが作成されオリジナルのSymbolをそのページ内で管理していました。 また、右ペーンに表示されるフォームに入力しインスタンスのオーバーライドを行っていました。 Figma Figmaでは設定したレイヤーがオリジナルのコンポーネントになります。コンポーネントの一覧は左ペインのAssetsから確認します。 Assetsの表示から見るに、フレーム（Sketchでいうアートボード）の中にコンポーネントが所属する形になっています。 また、インスタンスを直接編集することでオーバーライドが可能です。 このあたりは触ってみた方が早いです。 Library周り WIP: 模索中です。すごい便利な気がしています。 Plugin周り WIP: 模索中です。Sketch APIよりいじりやすい感じがしています。 ブラウザ上の制約 スポイトツールはブラウザ内でしか利用できません。 これは解決策がありそうな気がしています。 ローカルフォントを利用するのがめんどくさい。 フォントを有効にするためのインストーラーを利用することで可能。 Google Fontsのフォントは利用できるので、ローカルフォントを利用しない選択もありそうです。 Google Fontsだけであれば、フォント共有や実装が楽になりそうです。 Figmaの何が良さそうか？ Sketchユーザーが一人でデザインを作るにあたってFigmaの恩恵を受けることはあまりないと思います。しいて言えば、ライセンスなしで利用できる点でしょうか…そのため、Googleアカウントがあれば楽に共有できます。 ただ、Webベースのツールで常に最新版が表示される、共有も簡単というポイントを踏まえると、Figmaはチーム開発で本領が発揮されるツールのように思えます。 個人的には、ファイルのディレクトリとか考えなくていいのがGoodなポイントです。今まではAppleのiCloudで管理していましたが、誤ってローカルに保存したり、iCloudの容量が足りないなどの問題も発生していました。 FigmaにするとすべてのファイルがWeb画面で見れるのでファイル管理が楽になりそうです。（整理しないと膨張しそうではあります）

日本国内で、SPAをベースにしたフレームワークはVueベースのNuxt.jsが有名です。しかし、Nuxt.jsはNext.jsというReactをベースにしたフレームワークを参考に作られたものです。 本連載は（影の薄い）React.jsのフレームワーク『Next.js』を使うにあたって基本的な事項を抑えることを目標としていきます。技術書典で向けた文章の素振りも目的としています。 環境 Node.js v8以降がインストールされていること Next.js 9.x系 プロジェクトのセットアップ セットアップ方法の選択 Next.jsのアプリケーションを立ち上げるには次の方法が用意されています。 CLIツール『create-next-app』によるセットアップ 手動によるセットアップ お手軽なのは前者のcreate-next-appを使ったセットアップ方法です。create-next-appはプロジェクトの雛形を展開してくれるCLIツールです。 ただし、create-next-appで採用されている標準テンプレートには、Next.jsの開発元であるZEIT社が開発しているstyled-jsxというCSS in JSライブラリが採用されています。しかし、残念なことにCSS in JSはReact界隈での採用例も少ないため、詰まった時が大変です。 そういった理由から、筆者は手動でセットアップする方法を推奨しています。 手動のセットアップ 今回は『first-next-app』という名前でセットアップを行います。 ターミナルで次のコマンドを実行し、プロジェクト用のディレクトリを作成しましょう。 $ mkdir first-next-app $ cd first-next-app このコマンドを実行し、first-next-app/package.jsonが生成されていることを確認しましょう。 この時点でfirst-next-appディレクトリをVSCodeで開いておきましょう。 packge.jsonに次の記述を追記しましょう。 "scripts": { "dev": "next", "build": "next build", "start": "next start" } 続いて、Next.jsを動かすのに必要なライブラリをインストールします。 ターミナルで次のコマンドを実行しましょう。 $ npm install react react-dom next $ npm install -D typescript @types/react @types/node また、最初に表示するコンポーネントを作成します。pagesディレクトリを作成し、次のようなpages/index.tsxを作成してください。 const Index = () => ( <div> <p>Hello Next.js</p> </div> ); export default Index; これでページを表示する準備が整いました。次のコマンドを実行して開発サーバーを起動してみましょう。 $ npm run dev [ info ] bundled successfully, waiting for typecheck results... [ ready ] compiled successfully - ready on http://localhost:3000 しばらく待ち、ready表示されたら「http://localhost:3000」をブラウザで開いてみましょう。 「Hello Next.js」と表示されればセットアップは完了です。

GitHubが提供しているGitHub Actions(beta)は「ソフトウェアワークフローを簡単に自動化できる」とあります。その中にcron形式でワークフローを実行することが出来る仕組みがあり、定期的に行いたいタスクを簡単に実現できるのでご紹介します。 ※ GitHub Actionsは現在ベータ版です。利用する際には公式サイトよりベータ版に登録する必要があります。 GitHub Actionsのscheduleイベント GitHub Actions GitHub Actionsでは複数のアクションを組み合わせることでワークフローを定義していきます。 その中でワークフローの実行をトリガするイベントという概念があります。 例えば、IssueやComment、Pull Requestが作成されたタイミングをはじめ、cronもトリガーとして扱えます。今回はcronをトリガーとしたワークフローを定義し、定期的にビルドを行えるようにしました。 設定方法 GitHub Actionsではリポジトリの~/.github/workflows以下にyamlでワークフローを定義します。 例えば、次のような~/.github/workflows/schedule.ymlを作成してみましょう。 name: Scheduler # https://help.github.com/en/github/automating-your-workflow-with-github-actions/events-that-trigger-workflows#scheduled-events-schedule on: schedule: - cron: '*/15 * * * *' jobs: build: runs-on: ubuntu-latest steps: - name: Run a one-line script run: echo Hello, world! - uses: actions/github-script@0.2.0 with: github-token: ${{github.token}} script: | github.issues.createComment({...context.repo, issue_number: 1, body: 'Hello github actons!'}) ワークフローはonに指定したイベントをトリガーとして起動します。この例の場合はcronで指定した15分間隔で起動します。 実際に行われるワークフローの中身はjobs以下に定義したstepが順に実行されます。この例は、リポジトリのIssue#1に対して「Hello GitHub Actions!」というコメントを行う設定になります。 Issueにコメントするコードはactions/github-scriptを用いて記述しています。 何が出来るのか？ 定期的に実行したい処理がある際に、サーバーを立てたり、Google Apps Scriptに設定を分割していたようなことが今後不要になります。管理が単純になるのに加え、設定がリポジトリの中にまとまるのもメリットです。 GitHub ActionsはPrivateリポジトリには制限があり、課金が必要になることがありますが、Publicリポジトリでは制限がありません。 定期的にcurlを叩きたい、GitHubのAPIを叩きたいといった場合に、GitHub Actionsを検討するのは良い選択肢になりそうです。 記述例: 外部に知られたくないURLに対してcurlを叩きたい。 このケースでは次の2点がポイントになります。 ワークフローのymlを記述する方法 外部に知られないようなURLの設定 secretの設定 CIのように利用する場合、プラットフォームの認証情報など外部に知られてはいけない値を利用するためにsecretという仕組みを用意しています。今回のURLも外部に知られてはいけない値を扱うので、同じ方法を利用します。 次の手順で設定します。 1.リポジトリの「Settings」を選択 2. 左サイドバーから「Secret」を選択 3. 「Add new secret」を選択 4. 「Name」は変数名、「Value」には変数の中身を入力し「Add secret」を選択 この設定を行うと、workflowのyml内で次のような形で変数を呼び出せます。 steps: - name: Hello world action with: # Set the secret as an input super_secret: ${{ secrets.SuperSecret }} env: # Or as an environment variable super_secret: ${{ secrets.SuperSecret }} 詳しくはドキュメントが用意されています。 srcretの設定: https://help.github.com/ja/github/automating-your-workflow-with-github-actions/virtual-environments-for-github-actions#creating-and-using-secrets-encrypted-variables yamlの記述 curlは標準で使えるようになっているので、curlに適切なオプションを指定すれば動きます。 さきほど設定した、「WEBHOOK_URL」を変数として呼び出します。 name: Daily Deploy # https://help.github.com/en/github/automating-your-workflow-with-github-actions/events-that-trigger-workflows#scheduled-events-schedule on: schedule: - cron: '0 0 * * *' jobs: build: runs-on: ubuntu-latest steps: - name: Post netlify build hook run: curl -X POST -d {} ${{ secrets.WEBHOOK_URL }} 結果の確認 GitHub Actionsの結果はリポジトリの「Actions」タブで確認します。 ワークフローの名前の左に、緑色の丸アイコンが表示されていればActionsとしては実行が成功、赤色のばつ印があれば実行が失敗しています。 ワークフローの名前を選択すると、ワークフローの実行ログが確認できます。 今回のワークフローはPublicリポジトリで動作させています。 => mottox2/website