去年は多くのアウトプットを行ったので、2019年はアウトプットの質を高めたいと思っています。 個人としてブログはもちろん、ハンズオンなどのアウトプットも行っていく予定なのでそういったアウトプットの質の向上が課題です。 そこで新年の読書課題として『学びを結果に変える アウトプット大全』という本を購入して読みました。 学びを結果に変えるアウトプット大全 | Amazon 精神科医の樺沢紫苑さんが書かれた本で2018年8月に発売されたのですが、2018年12月時点ですでに12刷、25万部を突破しているようです。 この事実だけでアウトプットの説得力がある本です。 今回は本中にあったフォーマットに則り、この本からどういう気付きを得られたか、どういった行動に活かしていきたいかを書きました。 アナログなアウトプット、気付きとTODOを記録すること 本書はアウトプットを話し方、書き方、動き方に分類して80ものテクニックを紹介する本です。 その中でも自分に響いたのは書き方の章でした。 本は読むだけではなく書き込みをすることで「気づき」を得る、本を読んで書くことで上手な文章を書く、カードに書くことでブレインストーミングをするなど、自分普段意識しないアナログなアウトプットについて考えさせられました。 本中ではノートに記録するということが何度も言及されており、読書やイベントに関して気づきやTODOを3つ書くというのは気軽に始められつつも自分の資産になるアウトプットだと思いました。 また、この本自体がアウトプット法を意識されて書かれているのも興味深い箇所です。 最初の章は、心理学や脳の仕組みを引用したり、アウトプットとインプットの比率はアウトプットが多い方がいい事実を明示し「アウトプットすることのメリット」をこれまでかというほどに説明してくれます。この導入で一気に読者を引き込み、自分は一日で一気に読んでしまいました。 また、本という媒体を活かして1つのテクニックが2ページ単位になっており図解を含むことで読みやすくなっていました。 次回の技術書典ではこういった本が書きたいです。 今日からやりたいアウトプット 個人的な反省なのですが、ブログやLTによるアウトプットをやっていても、本を読んだり、イベントに行っても内容に関するアウトプットは行っていませんでした。 この本を読んでやろうと思ったのは、「書き込みながら本を読む気づきを得る」、「ノートを使ったアウトプットを行う」、「本を読んだりイベントに参加したら気付きやTODOを書く」の3つです。 本を読む途中にメモを取りながら進めるというのは始めてやりました。今、感想記事を書いているのですが現在進行系で役にたっています。 Kindleで買っていたら書き込みしにくいので、書籍を買って良かったです。ラノベと漫画はKindleなどの電子書籍がいいと思います。 デジタルな記録よりノートを使ったアウトプットの方が絶対に書き込みやすいし自由度があると思っていたのですが、今までサボっていました。 アナログのアウトプットとデジタルのアウトプットをうまく組み合わせてアウトプットをやっていきたいと思います。一歩目として、ペンとノートを買ってきました。 ということでこの記事が、この本を読んで実践するはじめてのアウトプットです。 まとめ とりあえず、僕は3つの気づきと3つのTODOを決めるところから、この本の実践をしていきます。これらの習慣が身についたら次の3つのTODOを考えてより質の高いアウトプットを目指していきます。 おそらく1ヶ月に1回読むと読むたびに感想が変わりそうな本です。 この本は3つの大分類、80ものテクニックが書かれています。ブログを運営している自分に響いたのは「書き方」の章でしたが、読む人によって心に響く箇所は違うと思います。 また、この本を読んでからのアクションも考えやすく、かつハードルの高すぎないものになっているので、「アウトプットしたいけど何もできていない」といった悩みを持っている人でも安心して読むことができると思います。 学びを結果に変えるアウトプット大全 | Amazon 新年からいい本に出会えました。 （それにしても、技術書と比べてこういった本は値段が安くてコスパがすごいですね…）

あけましておめでとうございます。今回はGatsbyでつくってる当ブログに検索を実装しました。 なぜ自分で実装したのか、Gatsbyの構成でどういう実装を選択したのかを書きました。 つくったもの Gatsby.jsのブログに検索を実装してみました。あけおめ実装です。https://t.co/hvz25scB7r pic.twitter.com/qSLuKZTx32— もっと@GatsbyJSおじさん (@mottox2) January 1, 2019 プルリクエスト 検索機能 by mottox2 · Pull Request #27 · mottox2/website ミニマムリリース分 検索の改善 by mottox2 · Pull Request #28 · mottox2/website リリース後に気になった、クリック領域やアニメーションの修正。 結構 :thinking: なコードになってますが、我こそはと思う方はPRをください。待ってます。 自分で実装する理由 そもそもGatsbyやJAMstackといった文脈では、状態を持つサーバーを持たないため様々なバックエンドサービスを利用することが想定されており、検索においてはAlgoliaが利用されることが多いです。 Algoliaは検索機能を提供するSaaSです。 検索機能というとElastic Searchを利用することが多いかもしれませんが、運用がしんどいなどの問題がありました。保守する人がいるなら別ですが、手軽に導入するようなものではありませんでした。 簡単に言うと、AlgoliaはアップロードのAPIを利用しデータをインポートすると検索用のAPIで検索が利用できるというサービスです。 非常に簡単に利用できることからStripeのDoc、React公式, Gatsby公式などで利用されています。 結論からいうと今回はAlgoliaの採用を見送りました。 Algoliaの価格ページを見てもらうとわかるのですが、一番安いプランで$35/monthです。個人のブログに導入する価格ではないと思います。（オープンソースのために無料で開放してくれているみたいですが、個人ブログはプランに該当するかわからないので諦めました） そもそもGatsbyには高速・安全などのメリットがありますが、これは企業が感じるメリットです。 今、個人でGatsby（JAMstack）なブログを利用しているエンジニアからすると、静的ファイルだけで済むので固定費が安いという点でメリットを感じています。 企業であれば迷わずAlgoliaに課金すればいいと思います。しかし個人はどうすればいいのか？ その答えが「自前実装」です。 （これは嘘です、サイトの世界感を守りたいというこだわりがなければグーグルのカスタム検索が手軽でいいと思います。） 実装方針 Gatsby製のサイトでは、ビルド時に静的ファイルを出力してそのファイルを配信して動いています。 検索となるとサーバーサイドが欲しくなりますが、検索のためだけにサーバーを用意するのは本末転倒ですし、管理も煩雑になります。 また、Netlifyで運用しているため、Netlify Functions（AWS Lambda）の利用も考えましたが、誰もがNetlifyやAWSを使ってGatsbyをホスティングしているとは限りません。 Gatsbyを利用する人がそれなりに簡単に実現できる解決案を考えた結果、次の方針が良さそうでした。 静的ファイルのビルド時に検索用のJSONを生成 ブラウザでReactがマウントされたらそのJSONを呼び出す クライアントで検索 静的ファイルのビルド時に検索用のJSONを生成 Gatsbyではgatsby-node.jsでGatsbyのライフサイクルに処理を差し込むことが出来ます。 動的なページを生成する際に使われるcreatePagesで、ページ追加処理の他にJSONを組み立ててファイルに保存する処理を書きました。 gatsby-node.js exports.createPages = () => { // graphqlでデータを取得する const searchJSON = allEsaPost.edges.map(postEdge => { const postNode = postEdge.node const { field, number, tags} = postNode const { title } = postNode.fields return { title, tags, number, path: `/posts/${number}` } }) fs.writeFileSync('./static/search.json', JSON.stringify(searchJSON, null , 2)) //... } https://github.com/mottox2/website/blob/5507a406e761b4bd6ad67da786bac647e0b46a9e/gatsby/createPages.js#L64-L74 ブラウザでReactがマウントされたらJSONを呼び出す これは簡単で、Reactのマウントタイミングで上記のJSONを呼び出します。 検索用のJSONが重いのでは？と思う方もいるかもしれませんが、現状50記事ちょっとで2KB程度なのでパフォーマンス的には問題ありません。下手な画像を設置する方がよほどパフォーマンスへの影響があります。 Search.jsx import React from 'react' import axios from 'axios' export default class Search extends React.Component { async componentDidMount() { const res = await axios.get('/search.json') this.data = res.data } } https://github.com/mottox2/website/blob/5507a406e761b4bd6ad67da786bac647e0b46a9e/src/components/Search.tsx#L54-L55 クライアントで検索 テキストフィールドが変化するたびに取得したデータの配列をfilterを通して表示します。 実装前は重くなりそうだと思っていたのですが、データ量が少なかったのでほとんど問題なく動きます。重かったらイベントを間引いたり、Workerスレッドに検索処理を移動するつもりでした。 TitleとTagを元に検索しており、精度に関しては劣りますがざっくりとした結果は得られます。本当は本文の特徴語などをビルド時に出力しておくといいのかもしれません。 感想 以上の対応で問題なく動いたので勢いでリリースしました。 所要時間はミニマムリリース地点で6時間程度でした。検索処理よりもUIの方が時間がかかりました。 モバイルもやっつけで対応しましたが、レスポンシブ対応のスタイルとStateによる制御が合わさってスパゲッティコードに近いコードを書いてしまいました。 普通のアプリケーションであればwindowのサイズをJSで見て処理を分岐させたかもしれませんが、静的ファイルをジェネレートする関係上、JSを読み終わるまで適切な表示に切り替わりません。それを避けるためかなり無理矢理感のある実装になりました。 実装にやさしくないUIな気もするので、気が向いたら改修していきます。 静的サイトジェネレーターを使ったサイトを運用していて検索の実装で困っていた人に対して一つの方針が示せたのであれば嬉しいです。お金があればAlgoriaを使ってください。

2018/12/27にTECH PLAY SHIBUYAで行われたエンジニアの登壇を応援する忘年LT大会 でLTしてご飯を食べていろんな人と話してきました。 イベント当日のこと 発表内容と反省 先日、イベントの主催をしている「エンジニアの登壇を応援する会」のアドベントカレンダーで書いた2019年はGo BoldからBe ProfessionalへをLT形式にしたものです。 スライド: 変化を生み出すのはいつだって大胆な選択だ 当日は機材トラブルで5分近く、PCとプロジェクターがつながらないトラブルに遭遇しました。 LT前のトラブルというのは予想以上にダメージを受けます。LTは回数こなしているので、もう少しトラブル耐性をつけていきたいです。 時間は手元のスマートフォンで計っていますが、ほぼぴったりでした。5分LTの時間制限への苦手意識は薄れてきたと思います。 トラブルで参っていてあまり話しているときのことは覚えていませんが、改めて見返してみるとスライドの構成が良くなかったと思っています。 2019年の流れが完全に蛇足感があるので、流れをしっかり考えればよかったです。 イベントの雰囲気 話す側としても参加する側としてもめちゃくちゃいいです。 話す側の立場から言うと、この会のイベントは聞く側のレスポンスがはっきりしていて非常に話やすいイベントです。この会のLTをこなした後に、他のイベントに行くと恐怖を感じるレベルです。 これは、イベント参加者の優しさだけではなく、最初の司会で拍手やレスポンスの練習を促すという運営側の工夫もあってのことです。 「エンジニアの登壇を応援する会」という名前に間違いはありませんね。 「初めてのLTをしたいけど、怖くて応募できない」という方はこの会のイベントでデビューするといいと思います。 参加する側としてもいいイベントです。 他のイベントと比べても圧倒的ご飯は美味しく、美味しい日本酒も飲めます。アルコールが苦手な方に美味しい野菜ジュースを用意する配慮まであります。 主催のariakiさんが会計の収支を公開していますが、限界まで参加者に還元しようという姿勢でイベント運営をなさっています。 Togetterを見てもわかるように、Twitter実況も多くの人が参加しています。Twitter実況もアウトプットといえるので、アウトプットを支援しているイベントらしさがあってこういった雰囲気が非常に好きです。 リハーサル会 「エンジニアの登壇を応援する会」のイベントでは登壇のリハーサル会を行っています。 このイベントでも本番の2日前にリハーサル会があり、自分も参加していました。 リハーサル会では本番同様、最初の司会も含めてのリハーサルが行われました。 おそらく、リハーサルにここまで力を入れている勉強会は少ないのではないでしょうか？ 他の人のリハーサルを受けて、意見をDropbox Paperに書いたり、口頭で伝えたりしてフィードバックをします。 ただ、指摘といってもマサカリのような鋭いものではないので心理的な安全性が担保されていました。 ただ、自分は準備不足で製作途中のスライドで参加したので、フィードバックを受ける準備をしっかり整えておけばよかったと思います。 実際、しっかり準備してきた他の登壇者は、リハーサル会と本番ですごいいい発表になっていました。 まとめ 運営やTECH PLAY、参加者の皆様ありがとうございました！ 非常に楽しい時間を過ごすことができました。 「エンジニアの登壇を応援する会」Slackの参加はこちら

この記事は『真・エンジニアの登壇を応援する会』 Advent Calendar 25日目の記事です。24日目は創始者の@ariakiさんでした。 今年は去年の自分では想像出来ないほどのアウトプットを行いました。 ブログをはじめて、技術書典でサークル出展して、カンファレンスでも登壇して、OSSのコントリビュートも積極的にやるようになりました。 その大きな変化には常に大胆な選択があり、大胆な選択はいつも周りの人に支えられたものでした。 1年を振り返りつつ、来年取り組んでいくことをここで宣言します。 大胆な選択は常に周りの人に支えられたものだった 今年を振り返ってみると、自分の大胆な決断はいつも周りの人に支えられたものでした。 OSSコントリビュートの機会をくれ、技術書典で書いた本でもあるテーマのGatsbyは、@5t111111さんから布教されたものです。 Gatsbyと出会ってなければ、これほど多くのLTや登壇をすることはなかったでしょうし、技術書典に参加することはなかったでしょう。 GatsbyJSのMaintainersになりました！技術書典のGatsbyJS本も頑張るぞ！ pic.twitter.com/1PUNOA105H— もっと@締切駆動 (@mottox2) September 8, 2018 ブログメンターを定期的にやっている@kakakakakkuさんのブログメンティになれたのも非常に大きな出来事でした。それまではQiitaやnoteを点々としており、僕にとってのブログは継続とは程遠いものでした。 ブログメンティになれたおかげでほぼ週1ペースでのブログを継続しており、ブログをベースに勉強会でLTしたり、技術書典のネタを生み出せたり、カンファレンスのプロポーザルにチャレンジしたりしました。 ブログメンター興味あります！noteとQiitaをやっているんですけど、うまく続かなくて困っています。note: https://t.co/LdLZ4bqTcFQiita: https://t.co/e5LKXdlrN3— もっと@締切駆動 (@mottox2) May 2, 2018 技術書典への応募も@tbpgrさんから刺激を受けたものです。かねてから親交があるのですが、技術書典に出すことを聞いて自分も本を書いてみたいと思って勢いで応募しました。 ブログをやっていたのでネタには困らないだろうという自信もあったので、ブログに支えられた選択でもありました。 執筆中も合同誌を一緒にやった@nabettuさんや@takanoripさんたちにも非常にお世話になりました。技術書典参加経験のあるお二人には、いろいろサポートをしていただきました。 お二人がいなかったら、今のクオリティには絶対に達することが出来なかったと思っています。次は自分も助ける側になれればいいと思っています。 明日10/8に池袋サンシャインシティで行われる #技術書典 で初心者向けのJavaScript本 「GatsbyJSで作るモダンウェブサイト」、「netlifyで始めるサーバーレス開発」を頒布します。「け52 つのぶえ出版」でお待ちしています！https://t.co/G14JGZa3AD pic.twitter.com/7xJ6HUtStr— もっと@締切駆動 (@mottox2) October 7, 2018 また、エンジニアの登壇を応援する会の創設者である@ariakiさんの存在も自分にとって大きなものでした。何回か勉強会での登壇を一緒にやっていく上で親交を深め「エンジニアの登壇を応援する会」最初のイベントである夏休み自由研究LT大会の「絶対面白いLT枠」に応募するまでになりました。 今考えると「なんで応募したのかよくわからない」という印象すら感じる行動ですが、この選択があったからこそコミュニティでの活動をやるようになったのだと思っています。 今から絶対おもしろいテーマ考えます https://t.co/d5qcDz7CBd #engineers_lt— もっと@締切駆動 (@mottox2) August 2, 2018 エンジニアの登壇を応援する会をする中で自分もCfPに応募してみようという気持ちになって応募したのが、Frontend Conference FUKUOKAです。コミュニティのSlack内でプロポーザルの添削をやっているのを見て、自分もやってみたいと思ったのがきっかけです。 普段から競合の少ないテーマでやっていることもありプロポーザルも通って無事カンファレンスの登壇を成功1させることができました。 15:15からサリー会場で話す「CMSとフロントエンド」の発表資料です。CMSで消耗している人が幸せなフロントエンド開発を目指す内容になります。 https://t.co/uVNu5XNvJF #fec_fukuoka #fec_fukuoka_sally— もっと@締切駆動 (@mottox2) December 8, 2018 人間不思議なもので、いつも同じ店のランチに行ってしまったり、ほとんど同じ服を買ってしまったりと、こういうちっぽけな物事ですら現状維持を選んでしまいます。ましてや変化を生むような大胆な選択を一人ではできなかったでしょう。 このように多くの人によって大胆な選択をしていけたのが2018年でした。本当に感謝しています。 より質の高いアウトプットを 周りの人からの後押しもあり、大胆に前へ進むことはできたのですがまだアウトプットの質に関しては満足いくものにはなっていません。 もっとうまく文章を書きたい。もっとうまく喋れるようになりたい。もちろん、もっとうまくプロダクトを作れるようになって、もっと多くの人に自分のつくったものを届けたい。 そこで2019年の目標として据えるのは、アウトプットの精度を上げていくということ。 質より量でやってきたアウトプットから、質も高いアウトプットを目指していきたいと思っています。[^2] 具体的にどうするかはまだ具体的には考えていないですが、次のようなことを考えています。 仕組みで楽する 個人的に「頑張る」や「気合でなんとかする」という言葉は嫌いです。自分が怠けてても続く仕組みを考えるのが自分のありたいエンジニア像です。2 2018年はブログ 66記事、LT/登壇14回といった回数をこなすなかでクオリティが落ちやすい箇所や、満足いかない箇所、工夫できそうな箇所は見えてきたので、機械的に直せそうな箇所は仕組みでカバーしていきたいと考えています。 たとえば、ブログや本に関してはtextlintといったツールを使って機会的に校正できる箇所を直していくこと。説明する図を簡単に作るための色や太さなどのガイドラインを作る。 LTに関してもコンテンツだけ考えればLT資料ができるレベルまでスライドマスターを洗練させたり、code-surferといった他のスライド作成ツールなどを試してみるなどいろいろできることはあります。 これらの取り組みもブログネタになるので、適宜アウトプットしながら進めていきます。 みんなで強くなる 週1ブログを書くコミュニティの『write-blog-every-week』やこのアドベントカレンダーの『エンジニアを登壇を応援する会』といったコミュニティでお互いのアウトプットの質を上げる取り組みをしていけたらいいなと考えています。 とくに@yoshitaku_jpさんとは「質を上げていきたい」という話をしていてアウトプットの質の向上に取り組んでいきたいと思っています。よろしくおねがいします！ まとめ 今年は本当に周りのみんなに支えられた年であり、ここ最近で一番変化の大きな年でした。 来年は今年取り組み始めたものをより洗練させていくので各位よろしくおねがいします！ Go Bold（大胆に）とBe Professional（プロフェッショナルであれ）は六本木のM社のミッションです。個人的にすごく好きなミッションなので自分もこのミッションを大切にしています。 変化を与えてもらった分、みんなと一緒に強くなりたい気持ちもめちゃくちゃ持っているのでみんなで強くなっていきましょう。 注釈 自分では成功したつもりでいます。 ↩ 僕の目指すエンジニア像です。 ↩

Gatsbyを使った人でStarter（Scaffold）を利用してGatsbyのサイトを構築したことのある人は多いのではないでしょうか？ Starterとは別にGatsbyのサイトを構築していく上で便利な「Theme」という仕組みもあるのでご紹介します。 2018/12月時点ではexperimentalな機能ですのでご注意ください。 Starterの再利用性の低さ 従来のStarterをGatsby CLIで展開する方法は、実行時点でのStarterの最新版をローカルのディレクトリに展開するものでした。 Scaffold方式の問題点なのですが、一回展開されたコードは、元のディレクトリのコードが変更されたときに追随するのが非常に困難です。 また、1人で複数のサイトを管理する際にお決まりの設定が各リポジトリに乱立するという問題もあります。 Contentfulのお決まりの設定や、Markdownの処理を行うremark系のプラグイン設定が各リポジトリに存在するようなケースです。 他にも、ドキュメントサイトのようなサイトに対してLogoやColorを変更したいだけなのに、大きなGatsbyプロジェクトが必要なのも問題です。必要以上に大きなコードをいじる必要があり初学者からすると避けたいケースだと思います。 Starterの再利用性の低さを解決するために作られたのがGatsby Themeです。 概要 Gatsby Themeは、Gatsbyの各種設定やページ、コンポーネントを含むnpm packageです。 利用者はそのThemeを利用して、設定を拡張したり、Viewの一部を差し替えたりすることで簡単にサイトを構築していきます。 想定される利用例 Gatsby Daysのセッションで話された内容ですが、次のような場合で利用すると効果的です。 同じ会社や個人がサイトを作成するときの共通設定 同じSource Pluginを利用する場合 同じTransformer Pluginを利用する場合 SASSなどの共通設定を利用する場合 ドキュメントサイトのような大枠が変わらないサイト 変更したいのは、ロゴやブランドカラーだけのようなとき 実装例（利用者側） 今回はgatsby-theme-blogというThemeの作者がサンプルでつくっているテーマを使ってみます。本記事ではテーマの作成方法については言及しません。 $ npx gatsby new gatsby-theme-sample https://github.com/gatsbyjs/gatsby-starter-hello-world $ cd gatsby-theme-sample $ npm install gatsby-theme-blog 次のgatsby-config.jsを作成しましょう。 gatsby-config.js module.exports = { __experimentalThemes: [ { resolve: "gatsby-theme-blog", options: { root: __dirname } }, ], } src/pages/index.jsを削除し、src/assets/gatsby-logo.pngに適当なpng画像を置き、次のようなマークダウンファイルをsrc/pages/sample-post/index.mdとして作成してください。 --- title: New Beginnings date: "2015-05-28T22:40:32.169Z" --- This is sample post. この状態でnpm run developを実行しましょう。 これで一応動きます。ファイルツリーを見てもシンプルな状態で動いていることが確認出来ます。 ただ、暗黙的に必要なファイルが多かったりするので、初見で使うのは非常に難しいです。おそらくテーマによって前提となる作業も違ってくるでしょう。 現実的には「ThemeをベースにしたStarterを利用する」という形になると思います。 個人的な感想 Gatsby Theme触ってるけど、WPのChild Themeと同じ印象を受ける。そのまま配布するのは良さそうだけど、それを元に開発とかはあまり適していなそう。まだExperimentalなので今後に期待。— もっと@締切駆動 (@mottox2) December 23, 2018 おそらくThemeに関してはgatsby-config.jsの設定の共通化のみを行うのが良くて、UIはthemeに乗せるよりは別にライブラリ化して共通化を図る方が現実的な気がする。個人的な意見だけど、UIの継承は悪手感漂ってて好きじゃない。— もっと@締切駆動 (@mottox2) December 23, 2018 configは多分コピペの嵐になっていると思うので、Themeで共通化できるのは嬉しい。 暗黙的に呼び出されるRouteは辛いのでRoutingに関しては各プロジェクトで持ったほうが楽そう。 UIもThemeの中にあるコンポーネントより、ドキュメントが用意されているライブラリを使った方が楽だと思う。 Document系のテンプレートを固めて、色やタイトルをオプションといった形で利用できるようにして、継承はされないという前提であればよさそう。 そういった場合は用途を限定した静的サイトジェネレーターのような扱いになるはず。それはそれであり。 今後に期待しましょう。 参考ページ Composing Gatsby Sites by ChristopherBiscardi · Pull Request #8917 · gatsbyjs/gatsby Themeが実装されたプルリクエスト Introducing Gatsby Themes | GatsbyJS Gatsby Blogの記事 Introducing Gatsby Themes - YouTube 『Gatsby Day』というGatsbyのカンファレンスで話されたセッションの動画です。

この記事はwrite-blog-every-week Advent Calendar 19日目の記事です。もっと（@mottox2）が担当します。 今年はアウトプットをするという目標を立てたました。個人的には達成したと思っています。 自分は2016年ぐらいから「今年はアウトプットする」という年間の目標を立てていたので「3年目の正直」とでもいったところでしょう。 そこで、今年のアウトプットと達成した理由について振り返ってみます。 内訳 執筆 65記事 + 2冊 本2冊 Blog 50記事 Qiita 9記事 note4記事 会社ブログ 2記事 発表 14回 LT 9回 登壇 3回 非公開LT 2回 LT予定 1回 なぜ達成できたのか？ 主に、人からフィードバックを受けることができたことと専門性を持つことができた点が大きかったです。 アウトプットを支えてくれたのは間違いなくブログです。 9月の「アラサーになったので1年を振り返った」の記事で振り返ったように、@kakakakkuさんのブログメンティになりブログを始めたというのが一番大きな分岐点だったと思います。 ブログメンティを卒業したあともブログは続けていましたが、write-blog-every-weekという毎週ブログを書いていくSlackグループに参加したのも継続の要因になりました。 毎週定期的にSlackBotがブログを書いていないとメンションしてくれたり、（いい意味での）メンバーの煽りやコメントなどでアウトプットが継続的に行えるようになりました。 ブログ以外の執筆という点では、10月の技術書典ではブログや仕事で貯めた専門分野の知識を本にすることができ200冊近くの本を頒布することができました。（参考「技術書典5にサークル参加した振り返りレポート - mottox2 blog」） また、LTや登壇などアウトプットに対する反応がわかりやすいアウトプットも行っていました。 アウトプットをやっていく中で一番つらいのは反応がないことなので、LTや登壇は反応がわかりやすく反応がもらえてモチベーションに繋がります。 こちらは4月にLTを初めてから「月1でLTをする」という目標を立てて実行しました。登壇枠で参加することで、懇親会の立ち回りが楽になり人からフィードバックを得たり、逆に質問もしやすいなど一人フリーランスとしては最高のアウトプットでした。 LTも回数をこなすうちに資料作成の能力が上がったり、コミュ障なりに人と話すのが以前ほど苦痛ではなくなりました。 8月から参加した「エンジニアの登壇を応援する会」というコミュニティからも非常に多くの影響を受けることができました。 その名の通りエンジニアの登壇を応援してくれるのですが、Slackでのメッセージも活発です。カンファレンスのCfPが発表されるとともに多くの人がプロポーザルの応募している様子などを見て、自分もプロポーザルを出してみようと後押しされました。 後押しされてプロポーザルを出したイベントがFrontend Conference FUKUOKA 2018です。 イベントではブログや技術書典でテーマにしたJAMstackををイベントのテーマである「開発現場の「イマ」を知って、 フロントエンドをもっと楽しもう」にそって再構成したセッションを行う機会を頂きました。 これは普段のアウトプットがあってこその成功体験だったと思います。 普段はブログを書いて経験値を貯めて、定期的にLTや登壇をこなすことでモチベーションを得る。そして、そのアウトプットの中で専門性を高める。 このようなバランスのよいアウトプットが継続をささえてくれました。 来年は今年以上のアウトプットをやっていきたいと思います。 来年はすでにサポーターズ様でGatsbyの開発ハンズオンが決定しており、今年とは違ったアウトプットをやっていきます。 支えられるだけではなく支える側になる努力も行っていくので皆様よろしくおねがいします！ 記念すべきブログ50記事目は以上です。

この記事は技術同人誌 Advent Calendar 13日目の記事です。技術書典5で2冊の新刊（+1冊の合同誌）を出した@mottox2が担当します。1 技術同人誌は「書けば生える」と言ってる方が多く見られるのですが、実際に書こうとなったときに「なにを書いていいかわからない」という方は多いのではないでしょうか？ この記事では、書きたい・広めたい技術に出会うヒントや切り口を紹介していきたいと思います。 前提として、ITエンジニアがテーマを見つける方法について書いています。 自分がやっていることから見つける 一番見つけやすいのが、今自分が取り組んでいる技術をテーマにすることです。仕事でプログラミングをやっている人が取り組んでいる技術であれば、濃い内容の技術同人誌になるでしょう。 ただ、「巷に同じテーマの技術書は溢れてる」「すごい人がいるのに自分が書いていいのだろうか」と手を止めてしまう人がいるかもしれません。 しかし、「巷に同じテーマの技術書は溢れてる」と思うあなた！その本にはあなたが求めている情報がありますか？ 世の中に出ている商業誌というのは、部数をある程度ないと採算が取れないために人数が多い初心者層を対象にした本が多いです。また、（数年前まで変化が早かったウェブフロントエンドなどの）変化の早い分野では商業誌の特性上、追いきれていない場合があります。 このギャップを埋められるのが技術同人誌です。個人的に感銘を受けた（技術書典5の）事例を紹介します。 PHP中級者を目指す 〜言語を使いこなすための本〜（@konosumi） PHPの中級者向けをターゲットにした本 YYPHPというコミュニティないで需要の確認や、応援を受けて執筆 技術書典で技術同人誌を書いて良かったこと - メリットや反響を振り返る 0から始める！簡単！FreeNAS（@kameneko1004） FreeNASというNASを構築する技術について書いた本 昔からある技術だったが、まとまった情報がない/古い情報にも当たる混じっていたものを初心者向けにまとめたそう アウトプットをほとんどしない ペンギンが本を書いた話 このようにすでに成熟している分野からも切り口を変えるだけで魅力的な本が生まれます。 自分が「こういう本がほしかった」と思える切り口をテーマにしてみてはどうでしょうか？ 触ったことのない技術から見つける方法 これは技術同人誌のテーマの見つけ方というよりは、エンジニアの学習というテーマのほうがふさわしいかもしれません。 ITエンジニアは（個人的観測範囲では）新しい分野を探っていくのは大好きだと思います。その中で「書きたい」「広めたい」と思える技術に出会えたら幸せだと思います。 そういった技術に出会えるヒントを紹介します。 尊敬している人が「いい！」と言っている方法に触れる ITエンジニアとして尊敬している人はいますか？ 技術タイプや人間的に素晴らしいタイプやマネージメントが素晴らしいタイプなどいろんなエンジニアがいると思います。 技術を深ぼったり、新しいことに挑戦することが得意なエンジニアさんの言っていることを聞くと、おもしろい分野に出会えることが多いです。 自分自身、技術書典で出した本のテーマであるGatsbyは、尊敬するエンジニアの方が「めっちゃいい！」と言っていたことがきっかけで手を出しました。 尊敬している人がいいと言っているものなのでバイアスが働いて、多少躓くことがあってもチャレンジすることができたりします。 これで教えてくれた人より詳しくなる気持ちで取り組んで、「めっちゃいい」と思えるようになったら次はあなたが布教する番です。本を書きましょう。 「尊敬できる人が周りにいない」という人も少なからずいると思います。そういうときは、いつもいいブログを書く人や、いい技術スライドをつくっている人、発信する情報を見て尊敬できる人をインターネットで見つけましょう。 そういった人たちが発信する情報から「いい！」と思える技術が見つかるかもしれません。 個人開発で出会う ITエンジニアは他業種と比べて、個人学習をやっている人が多い印象を持っています。 個人学習では仕事とは違う技術を使えるために、いつもとは違う技術を選択する人も多いのではないでしょうか？ IT技術の進歩は早く、時間経過によってベストプラクティスが移り変わりやすいです。 今のベストはなんなのか？みたいな観点で技術を選んだり、上記にあげた尊敬している人の情報から技術を個人的な開発に持ち込むこともいいと思います。 実際に個人で開発していく上で、メリットやデメリット、つまづきやすい点などがはっきりしていくことでしょう。 触っていく上で「なぜこれが知られてないのか？」みたいな感想も持つかもしれません。 そういった技術を広める手段が技術同人誌です。初心者を導いていけるような本を書いて、推しの技術を布教していきましょう！ 自分が出した本のテーマであるNetlifyは、個人開発で使い始めて魅了されました。 参考に、筆者が今年取り組んだ個人開発メモを記載します。興味があればぜひ読んでください。 自分のGitHubから読み取る挫折の歴史 in 2018 まずは熱くなれるテーマ選びから 自分が今やっている技術、未来に出会う技術からテーマを見つける方法を紹介しました。 読んでくれた方はわかるかもしれませんが、熱量をかなり意識した内容だと感じられたかもしれません。 同人誌では熱量は大切な要素です。技術ブログとかで「○○をやってみた」という記事を書くのは1日あればできますが、同人誌は数十ページ以上のケースがほとんどです。（薄い本は例外ですが…） 数十ページを執筆すると少なくとも1週間以上はそのテーマに向き合って書いたり、校正したりすることになります。 そこに熱量がないと完成させることは難しいでしょう。 熱量を持てるテーマを見つけることが、技術同人誌を書き上げるための最初のハードルだと思います。 今回の記事で、熱量の持てるテーマを見つけられる人が一人でも増えると嬉しいです。 注釈 振り返り記事: 技術書典5にサークル参加した振り返りレポート ↩

この記事は、「Crieitアドベントカレンダー」9日目の記事です。遅刻ごめんなさい。 Crieitはプログラマー・クリエイターのためのサイトなので、自分のクリエイターになろうとして失敗した記録をGitHubから引っ張り上げました。 2018/1 sketch-naming-lint (deprecated) Sketchの命名ルールなどをまとめたGuidelineをつくりましたという記事を見て作ろうとしたもの。 sketchは内部でJSON形式でデータを保持しています。npmで配布されているsketch2jsonを使うことで簡単にJSONデータを取り出せます。 おそらく命名ルールのLinterを作ろうとしたのでしょう。 Sketchをチームで使うことがほとんどなかったのでモチベーションが足りず開発が停滞しました。 kvendrik/sketchlintという上位互換なリポジトリを発見してアーカイブしました。 ghsay Google Homeに喋らせるためのCLIです。 npx ghsay 喋らせたいこと を実行するとGoogle Homeに喋らせることができます。ただ使い所がデプロイ完了タイミングぐらいしか見つけられずモチベーションが落ちていきました。 あとはGoogle Homeの検知周りを他ライブラリに頼りすぎていてデバッグが面倒になったんだと思います。  2018/3 ease /で区切ると自動でカテゴリを振り分けてくれるesa.ioライクなTODOアプリです。 一番ちゃんと作ったやつだと思います。 https://ease.netlify.com ショートカットキー周りの実装したhttps://t.co/g6Oqqldy6e pic.twitter.com/Coix88mvVh— もっと@九州初上陸 (@mottox2) April 3, 2018 TypeScript + ReactなTODOアプリです。当時PWA Desktopの話が飛び出していてなにか作りたいと思い、TypeScriptの練習がてら作りました。 データはIndexedDB、Desktopに特化するためのキーボードショートカットなどにも対応した本格的なアプリです。 しばらくは使っていたのですが、データ同期機能がないと本格的な使用には絶えず開発が停止されました。 FirebaseをDBにして作り直してもいい気がします。 Netlifyと出会ったのもこのアプリケーション開発がきっかけです。 これがなかったらNetlify芸人になってなかったと思うとやってよかったという気持ちになれます。 2018/4 mini-scrape JSでスクレイピングするときにいい感じのインターフェースでスクレイピングのコードを書きたいと思って作りました。 メンテはあまりしてないけど、たまに使ってます。 結構便利です。 使用例はこちら。 import scrape from 'mini-scrape' const url = 'https://github.com/mottox2/mini-scrape' scrape(url).then(window => { console.log('title: ', window.document.title) console.log('h1: ', window.document.querySelector('h1').textContent.replace(/\n/g, '')) }) gatsby-source-esa Roppongijs #2用に作ったGatsbyプラグインです。確かイベント前日にLT枠が繰り上がってきたのでネタづくりのために作られたライブラリです。 確かGatsby触って2日目の出来事だったと思います。Gatsbyの良さに感動したんだと思います。 今もこのブログのためにメンテし続けています。 2018/5 website カックさんのブログメンティーに申し込んで、翌日の午前に立ち上げた当サイトのリポジトリです。前述のgatsby-source-esaがあったからこそ立ち上がったものです。 まだちゃんとメンテし続けています。日本で生きているGatsbyのコード例としてPublicにしています。 これが今のアウトプットの源になっているので、一番自分に影響を与えたリポジトリな気がします。 2018/6 shinka (deprecated) フレームレスで便利なYouTubeクライアント（予定）でした。 この頃からYouTubeのゲーム実況にハマっていた記憶があります。 Electron+Reactで作ってたのですが、ビルドプロセスとかに納得感がなくモチベーションが落ちていったパターンだったと記憶しています。 ボイラープレートで使えそうなのがelectron-react-boilerplate/electron-react-boilerplateぐらいしかないのですが、FlowとReduxがデフォルトで入っていてだいぶやる気を削がれました。 DXの重要性がはっきりとわかりますね。 json-sketchapp (deprecated) Roppongijs #4ように作ったJSONのDSL的なものをSketchファイルに変換するネタライブラリです。 JSONでDSLを書く意味が（自分ですら）わからないので一発芸で終わりました。 「yoga（ReactNative）のレイアウトエンジンを使うと簡単にレイアウトを表現できますよ」という教訓が残りました。 仕事でPowerPointを出力するアプリケーションの面倒を見ているので、いつかyogaベースに変更できたらいいなと思っています。 2018/7 gas-kintai Slackで「kintai start」「kintai end」を入力すると自動でスプレッドシードに記入されるSlackアプリケーションをGASで作りました。 お手伝いしている会社の勤怠管理がスプレッドシードに記入する形で面倒だったので作りました。（月末にSlackから頑張って転機する作業で消耗していました） このブログでも紹介しているGoogle Apps ScriptのCLIであるclaspで作っています。Reduxを参考にactionsを実行するような設計を取り入れようとして失敗しています。 これを作って以来コミット時間が増えました。まだ使っています。 そこそこ便利です。 slack-esa-preview Slackにはられたesa.ioのリンクを展開してくれるSlack Appです。 esa.ioはプライベートで使っていると、URLのみでリンクを踏まないと内容がわからないのでSlack Appの練習がてら作りました。 Netlify FunctionsでSlackのEventを受けて、関数内でesa.ioのAPIを叩きデータを取得、Slackに内容を返す処理を書きました。まだ使ってます。 Netlify Functions処女作らしいです。ソースはTwitter。 投稿されたesaのタイトルを取得してSlackに投稿する処理も出来た。Netlify Functions入門から3時間でこれが出来たのは奇跡。 pic.twitter.com/VitDJVNqea— もっと@九州初上陸 (@mottox2) July 22, 2018 esa-node esa.ioのNodeクライアントです。 上記のslack-esa-previewを作っている過程でいい感じのesaクライアントが欲しくて作りました。既出のクライアントはあったのですが最終更新が数年前で、TypeScriptの型を提供していいものを作ってやろうという気持ちで作りました。 TypeScriptでhttps://t.co/TXTmXrRsCgのnodeクライアント書いた。便利。 pic.twitter.com/0EW6dLkdc7— もっと@九州初上陸 (@mottox2) July 26, 2018 この開発で、型を提供するパッケージの作り方を学びました。 slack-esa-previewの中で生き続けています。 2018/8 webgrapher (deprecated) Webサイトのスクリーンショットをいい感じにとって管理するアプリケーション（予定）でした。 技術書典でスクリーンショットをいっぱい取るから、いい感じに管理できたらいいなという気持ちで作りました。 ghqui (deprecated) ローカルのGitリポジトリを効率よく管理できるghqというツールのGUI（予定）でした。 開発を長く続けているとローカルで管理しているリポジトリが増えてどんどん重くなるので、GUIを作ってキャッシュやインクリメンタルサーチを実装したら楽になりそうというモチベーションではじめました。 インクリメンタルサーチはWebWorkerとか使うと面白そうだなとか思っていましたが、そこに行き着く前にやめました。確かElectron周りでだるくなってやめた気がします。 miyaokaさんがQiitaに投稿した「ghq + pecoが重くなったら」内で触れられている手法を使えばghqの重さは回避できることがわかったので、作る理由は消え去りました。 2018/10 b.mottox2.com (private) 技術書典で配布した本のダウンロードサイトです。Gatsby on Netlifyで動いています。 Netlifyは有料プランを使うとBasic認証がかけられます。本サイトはNetlify Functionsでパスワード認証を作ってフロントエンドと連携してダウンロードリンクを表示するようにしました。 ダウンロードカードや本とデザインを揃えたのがこだわりポイントです。 pixela-node 「PixelaのNode.jsクライアントライブラリをつくった」で取り上げたPixelaのNodeクライアントです。 TypeScriptで型を出しているのがポイントです。esa-nodeで学んだことが生きたライブラリです。 自分も習慣化アプリケーションを作ろうと考えていたところ、習慣化がうまくなってしまって作るモチベーションが落ちてしまうという学びを得ました。 pixeland (deprecated) 上記のPixelaのGUI（予定）。途中で習慣化がうまくなってきてモチベーションが消失しました。 2018/11 next-cms リポジトリだけ作った。日本でHeadless CMSを流行らせたいという気持ちだけある。手段は未定。 shotoku carloで立ち上げるChrome中にReactアプリケーションを載せたやつ。 Reactのコンポーネント内からcarloにシェルコマンドを送信して、実行結果をReactに表示してなにかをやろうとしていた形跡がある。 アドベントカレンダーネタにしようとしたけど諦めた気がする。 2018/12 SSRecord GAS中でSpreadSheetを便利にするORMなライブラリです。開発中です。 GASで一番しんどいのがSpreadSheetをデータソースとして扱う部分だと思っていて、ORMがあったらいいなと思ってので作り始めました。 自分はGASをTypeScriptで書いているので、型にも対応しています。 一応findAll, findなどのデータ取得系はざっくり書いてあって、追加系や更新系をどうしようか迷っている段階です。 仕事で書いているGASアプリケーションには既に導入されており、コードが40%減、保守性も高くなるという結果が出ています。 実用に堪えるようになったらブログで紹介したいと思っています。 まとめ 全体的に技術主導型で「途中で飽きる」ことを繰り返しているので2019年はちゃんと作りきりたいです。 GUIは長丁場になるのでつらそう。ライブラリは飽きる前に形になるという特徴もありそうですね。 少なくとも技術力やアウトプットの向上にはつながっているので、趣味プロジェクトはいいと思います。

8月に書いた「Netlify FunctionsでTypeScriptを使う」という記事で、netlify-lambdaをフォークしてTypeScriptを使っていると書きました。 数ヶ月経ち、フォークした内容が本体にマージされ簡単にTypeScriptが使えるようになったのでボイラープレートを作りました。（netlify-lambda@1.1.0からTypeScriptが使えるようになりました。） mottox2/netlify-functions-typescript-starter 使用方法 your-project-nameを作成したいプロジェクト名に置き換えて次のコマンドを実行しましょう。 $ git clone --depth 1 --single-branch --branch master https://github.com/mottox2/netlify-functions-typescript-starter.git your-project-name $ cd your-project-name $ yarn 開発はsrc以下にtsファイルを作成していきましょう。 Netlify Functionsの実態はAWS Lambdaなので型ファイルはLambdaのものを使うといいです。devDependenciesに入れているので既に使えるようになっているはずです。 src/index.tsの型を参考に作っていくといいでしょう。 import { APIGatewayProxyEvent, APIGatewayProxyCallback // @ts-ignore } from '@types/aws-lambda' exports.handler = async ( event: APIGatewayProxyEvent, context: any, callback: APIGatewayProxyCallback ) => { let body = {} if (event.httpMethod === 'GET') { body = event.queryStringParameters } else if (event.httpMethod === 'POST') { body = JSON.parse(event.body) } // do something... const response = { ...body } callback(null, { statusCode: 200, headers: { 'Content-Type': 'application/json' }, body: JSON.stringify(response) }) } ボイラープレートを作った経緯 一応フォークしたTypeScript部分はマージされたのですが、netlify-lambdaとは別途babel-preset-typescriptを含む.babelrcで上書きする必要があり、ハードルがあるので簡単に使えるようにボイラープレートを整備しました。 noconfigでTypeScriptを使えるようになるまでは保守する予定です。 この記事は2018/12/13に行われる [Netlify Meetup #3](Netlify Meetup #003 - connpass) 中の飛び込みLTの原作記事です。 執筆時点で2人余裕があるので興味のある方はぜひ参加してみてください。

2018年5月に公開を始めた当ブログですが、Gatsbyをより多くの人に使ってもらいたいと考えソースコードをオープンにしたので、ブログで用いている技術について説明します。 当サイトについて Gatsbyでesa.ioのデータを使って静的サイトをビルドする構成のリポジトリです。Netlifyでホスティングしています。 https://github.com/mottox2/website スターがつくとやる気がでます。 ポイント Gatsbyについて少し知っている前提で中身を説明します。 esa.ioをソースとして扱う（gatsby-source-esa） Gatsbyではファイルシステム上のファイルだけでなく、Web APIなどを経由した様々なデータをソースとして扱う仕組みを持っています。 ソースとして扱われるデータはビルド中に処理され、静的ファイルとして書き出され、本番に公開されてもデータ元へのアクセスは不要になります。しかもCDNに乗せることができ早いです。 esa.ioは情報共有ツールですが、Web APIやWebhookといった開発者に馴染みの深い仕組みをもっています。しかし、APIには15分に75リクエストという制限があります。 ただ、Gatsbyのソースとして扱えば、ビルド時にしかAPIを叩くことはないので、APIの利用制限はほとんど影響がなく利用することができます。 そのesa.ioの記事をsourceとして扱うためのプラグインがgatsby-source-esaです。 mottox2/gatsby-source-esa TypeScriptに対応する（gatsby-plugin-typescript） GatsbyはReactでViewを書いていきます。近年React+TypeScriptは流行っている印象があって、ReactコンポーネントのPropsに型をちゃんと設定しておくと呼び出し時に型チェックをしてくれます。 開発初期にはあまり効果を発揮しませんが、改修をする際にPropsのチェックがあることで安心してコードの変更を行うことができます。 Gatsbyは標準ではTypeScriptは採用していませんが、内部で利用しているwebpackの設定をいじるAPIがあり、そのAPIを叩いてくれるのがgatsby-plugin-typescriptです。 gatsbyjs/gatsby: /packages/gatsby-plugin-typescript noteの記事をソースとして扱う このブログを始める前にnoteで少し記事を書いていたので、水増しのためにnoteの記事もブログに掲載しています。 gatsbyにはgatsby-node.jsという挙動をいじるファイルがあるので、そのファイル内でnoteのRSSから得られたファイルをGatsbyのAPIを叩いてソースとして登録しています。 RSSを扱うプラグインはあったのですが、あまりイケてると思わなかったのでリポジトリ内で対応しました。ｆ 該当コード: gatsby-node.js gatsby-node.js exports.sourceNodes = async ({ actions, createNodeId }) => { await parser.parseURL('https://note.mu/mottox2/rss').then((feed) => { feed.items.forEach(item => { const digest = createNodeId(`${item.link}`) actions.createNode({ ...item, id: digest, parent: null, children: [], internal: { contentDigest: digest, type: 'Note', }, }) }) }) }; タイトルを元に公開日時などのフィールドを作成する 「情報共有ツールesa.ioをCMSとして使って1ヶ月運用してみた」の記事でも書いたのですが、esaにはTitle, Category, Tag, Contentぐらいしか入力項目がありません。 ブログとして必須と思われる公開日時が欲しいのでタイトルに「[2018-12-01] Gatsby+esaブログのソースコードを公開しました」と入力することで、公開日を指定する方式を採用しています。 これもgatsby-node.jsで挙動をいじることで実現しています。 該当コード: gatsby-node.js gatsby-node.js const DATE_REGEXP = / ?\[(.*?)\] ?/ exports.onCreateNode = ({ node, actions, createNodeId }) => { const { createNode, createParentChildLink, createNodeField } = actions if (node.internal.type === 'EsaPost') { createNodeField({ node, name: 'title', value: node.name.replace(DATE_REGEXP, '') }) createNodeField({ node, name: 'excerpt', value: h2p(node.body_html)}) // Extract the date part from node.name (ex. "[2018-10-08] I participated in Techbook Festival") const matched = node.name.match(DATE_REGEXP) const day = matched ? dayjs(matched[1]) : dayjs(node.updated_at) const dateNode = buildDateNode({ nodeId: node.id, day, createNodeId }) createNode(dateNode) createParentChildLink({parent: node, child: dateNode}) } } 今後の展望 2018年12月1日現在の展望です。 サムネイルの設定ぐらいはできるようにしたい。 いくらでも方法は思いつくけど、しっくりくるものがなくて困っている。 もしかしたらesa.io以外のツールをソースにするかもしれない。 普段の技術メモとして使えるツール。 airtable, inkdropあたりが候補 英語記事を書きたくて、その場合はMediumやdev.toにクロスポストする仕組みを整備する。 もう少し読まれやすい記事を書きたい。 まとめ このような技術でブログを半年続けることができました。技術ブログを書くことで知識のインプット・アウトプットが行え、技術ブログを作ることでソースコードとしてのアウトプットを行えました。 ぜひ皆さんも「俺の考えた最強のブログ」をつくって、継続してみてください。

2018/11/19にRetty社で開催された「Roppongi.js #7」のLT枠を頂き「Vueで静的サイトをつくるGridsome」というタイトルで話してきました。 発表資料 先月ブログに書いた「GatsbyJSライクなVueの静的サイトジェネレーター Gridsomeを触ってみた」をもとにしており、「今求められる静的サイトとは？」という前置きからGridsomeの紹介をさせてもらいました。 最初はVueでJAMstackが実現できるというポイントを推したかったのですが、5分の中でJAMstackの話までするとなにも伝わらなくなりそうなのでやめました。 未確認情報ですが、Nuxtにstatic modeという静的化ファイルを吐き出す機能が生まれる話（Twitterで見た）があるのでNuxt.jsでより精度の高いJAMstackが実現できるかもしれません。 感想 Rettyさんはスマホ世代の飲食店レビューサービスですが、食べ物を扱っているサービスだけあって出てきた豪華でびっくりしました。 今回はほぼ時間どおりに発表をこなしましたが、静的サイトのテーマを5分で話すのはしんどくなってきていてます。自分の理解度がどんどん上がっているという理由もあるのですが、どんどん前置きが長くなってしまっています。 前回のRoppongi.jsで時間配分に大失敗したので、その経験は活かせてよかったです。 ちなみにGridsomeはコード読みやすい上に勉強になるのでマジおすすめ！ Roppongi.jsの運営さん方や会場の提供をしていただいたRettyさん、ありがとうございました！

最近はOSSに貢献したいという気持ちを持っていて、今月はGatsby.js、ReactNative, netlify-lambdaのコードの改善や新機能のコントリビュートをしていた。 Reactを頑張りたいフロントエンドエンジニアですが、今回はVueのフレームワークであるNuxt.jsにコントリビュートした。 Nuxt.jsにコントリビュートしたところ非常に体験が良かったので、いいOSSコントリビュート体験についてメモ そもそもなにをやったか Nuxt CLIの提供しているgenerate/buildコマンドにそれぞれdevtoolsオプションを追加しました。 https://github.com/nuxt/nuxt.js/pull/4357 経緯 Nuxt CLIの提供しているgenerateコマンドでは、作成しているVueのアプリケーションを静的ファイルとして出力します。その出力結果をデプロイして本番環境で動かすわけなのですが、本番環境ではVue Devtools（Vueのインスペクトツール）が有効になっておらずデバッグには向いていません。 このIssueではその設定を有効にするworkarroundが紹介されていたのですが、「これをCLIのオプションに追加したらどうか？」というところでIssueのやりとりが終わっていました。 またこのIssueにはhacktoberfestタグが付与されており、最初に取り組むのにはピッタリだと感じたので実際に取り組んでみました。 https://github.com/nuxt/nuxt.js/issues/4117 いい体験だと思ったこと 2分でファーストレビュー 最初の反応が約2分後にあり、オプションのリネームの提案がありました。 自分がやっているOSSのコントリビューションではマージまで半日〜数日待つことが多いのですが、2分で反応がありました。 プルリクエストを出したタイミングが4:30で寝ようかと思っていたのですが、反応がついたのが嬉しくてその場で修正してしまいました。PRのオーサーの熱量を保ったまま、リードタイムも短くなり、3.5時間（8:00にはマージされていた）という速さでマージまでたどり着きました。 学びたいポイント OSSに限らないのですが、例えばesa.ioという情報共有サービスに問い合わせをすると30分以内には大体反応があり、翌日には修正されていることがあります。 問い合わせや、OSSのコントリビュートというのはアクションするユーザーにとっては不安なアクションなので、まずは反応して相手の不安を取り除いてあげるのは有効です。 普段の仕事Slackでも、メンションつけてくれた方には :eyes: なリアクションをとりあえず返してあげるようなことはしています。それに限らず相手の不安を取り除くというのは意識してやっていきたいです。 簡潔なContribution-Guide 普段Gatsbyへの貢献を多くやっているのですが、Nuxtは要点が絞ってContributionGuideが書かれていて、非常に良かったです。 参考: Nuxt.jsのContribution Guide / GatsbyのHow to contribute GatsbyNuxt 見てもらうとわかるのですが（画像はらないUXは許して…）、Gatsbyと比べてNuxtは文章構成がGetting Startのような構成になっており非常にセットアップやテストの流れが簡潔にかかれています。 また、スタイルの問題だとは思うのですが、Gatsbyは非常に密度が濃く英語が母国語じゃない人としては読むハードルが高いです。 対して、Nuxtはordered-listや見出しとの大きめなジャンプ率、広めの行間で工夫していたり、文字色を#555に設定しているため目に優しい感じになっています。 Gatsbyがセリフ体とNuxtがサンセリフ体を設定しているのも興味深いですね。 学びたいポイント 「なんとなく読みやすい」ぐらいに思われる文章を目指します。 読む人を考えた文章構成、スタイリングを意識していきたい。 文章構成は自分の中で答えが出ていないので、自分がいいと思った文章をためていこうと思っています。 ただ、スタイリングに関しては、基本的なフォント選び・行間/色の設定などで読みやすくできることはわかっているのでしっかり実践出来る形に落としていきます。 お気持ち 新機能の思想にもReactと圧倒的な差を感じられて、同じIssueがGatsbyにたったら「シンプルじゃないからPluginで対応して欲しい」って理由でCloseされる気がする。 Vueはoptionとかどんとこい感がすごいｗ Vueについてのお気持ちです。Reactな人なので異文化を感じました。（否定しているわけではありません。） 少なくとも、日本で熱いNuxtにコントリビュートできて嬉しいです。ちゃんとレビューしてもらえるのも「最高」というお気持ち。