3泊4日をかけて名古屋でタスク消化合宿を行った。 簡単にまとめると、普段の環境では進捗が見えやすく、達成感を得られるプログラミングをやりがちですが合宿の場を用意することで普段進みにくいタスクを消化するのによい印象を持ちました。結果的にはやってよかったと思っている。 この記事では、なぜ合宿に取り組んだか、タスクの取り組み方、合宿の気付きなどをまとめた。 きっかけ ざきさんのプチ合宿記事を見て、なかなか良さそうということ。とはいえ、自宅が生産性最大だと思っている。 自宅でやる作業は、進捗が見えやすいプログライミングをやりがちだった。そのため、執筆や思考系のタスクが無限に溜まっていた。また、家で作業を進めがちなで運動不足なので、解消したい。 スケジューリング 福岡、大阪、名古屋で悩んで、一番近い名古屋にした。（昔住んでたのもある） 関東圏も悩んだけど、街に出た際にWi-fiがありそうな場所がいいと思ったので選択肢にしなかった。（実際にどうかはわかりません。翔んで埼玉に影響を受けているかもしれません。）2泊3日を基本にして、変えるのが面倒なら3泊4日にする前提でいた。 合宿本編 場所 宿、スーパー温泉、コワーキングスペースを利用して進めた。 効率的にはコワーキングスペースが一番良い。ただ、宿の風呂が個室タイプだったので、スーパー温泉は作業場＋風呂という感じで非常に良かった。 RAKU SPAガーデン 神田にもあるRAKU SPA系列のお店。神田と比べてめちゃ広く、露天風呂や岩盤浴があって良い。一日 で利用できる。Wi-fiも文句なく、コンセントも豊富。漫画があるので誘惑に打ち勝てるならありよりのあり。 https://rakuspa.com/nagoya/ コワーキングスペース Division フリードリンク付きのコワーキングスペース。受付のお姉さんが親切。付近にごはん屋さんがいっぱいある。8:0017:00、17:0022:00の単発利用でそれぞれ1,000円。1週間以上滞在するなら月額プランの方が良さそう。 http://division.works/ 進めたタスク MBPでは本格的なプログラミングができないので、執筆や企画、簡単な作図を中心にタスクを消化した。 なかでも技術書典8に向けて執筆している同人誌に行き詰まっていたのが解消したのが良かったです。（仕事に逃げがちだった。） 寄稿記事 2本 本文執筆 作図 技術同人誌関連 サイト調整 コンセプトの練り直し タイトル・目次の構成 本文執筆 Pandocの調査 各分野で追っておきたい人・もののリスト作り esaでやっていたものをScrapboxに試験移行 （チャンピオングラレコ、チャンピオンモーションデザイナーみたいな形でまとめています。） 仕事の片付け 健康・運動 普段と比べ、かなり健康的な時間を過ごせた。この健康的な習慣が続いてほしい。 予想通りご飯のタイミングですごい動いた 朝ごはんも普段は食べないが、合宿中は毎日食べた 小倉トーストがうまい 普段は4:005:00に就寝するが、期間中は0:002:00ぐらいに就寝した 運動時間の推移（Google Fit） ご飯 おいしい。 気づき 旅に慣れている人からしたら当然なことかもしれないが、初心者視点で気づいたことはそれなりにあった。 チェックインの時間は要確認 街を歩く際に、コートとマフラーが邪魔だった。季節を考えたらもっと身軽になれそう 宿の周りにスーパー銭湯的な施設があるかを確認しておくと良さそう。今回は徒歩20分ぐらいの場所にあったので運がよかった 新幹線は時間帯によって混雑する。金夜の19:00はめちゃ混む。1時間ずらすだけでも全然違った。ご飯の時間は避ける モバイルバッテリーはほとんど使わなかった。ただし、コンセントに刺すタイプの充電器はめちゃくちゃ有用 えるきちさんに教わった小さいタイプの60V充電器が有能すぎた。MacBook Proが充電できるのに、付属のものより小さい 感想 行き詰まっていたタスクに解決の目処が立つ、健康的な生活を送るという2点を踏まえると素晴らしい成果を得られたと思っています。今回は突発的に始めた合宿ですが、普段から行き詰まっていることや、時間をとって考えたいことをまとめておいて、合宿で取り組む運用が良さそうな気がする。 合宿だけでなく、地方で行われるカンファレンスにもフットワーク軽く参加できるようになりたい。

僕は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」と表示されればセットアップは完了です。