TypeScript+VSCodeの組み合わせはエディタは軽く、補完も最強という特徴があり最高の開発体験を得られます。 ここ最近はほとんどTS(JS)を書いているので開発環境の恩恵を受けていたのですが、久しぶりに仕事でRailsを触ることになりました。1 しかし、最高の開発環境に慣れてしまったあとでRubyを書くと補完が弱い箇所にイライラしたり、JSの文法で書いてしまったりと大分辛さを感じます。とにかくツライ！2 ここで、JetBrains（RubyMine）のライセンスをセールで買っていたことを思い出したので、RubyMineに乗り換えてRuby専用環境の恩恵を受けようと思いました。 初心を忘れないため / RubyMineへの乗り換えを検討している人のために感想を残しておきます。 ファーストインプレッション とにかくショートカットキーがわからない。 補完はサクサク。（いい意味で）Rubyとは思えない。 ちょっと重い。特に起動が。 Ruby/Railsに特化した機能が便利。 Rubyに関してはVSCodeより良さそうな印象。 ショートカットキー 自分はプログラミングを始めて4年ほどVimを使っていたのでVim Pluginは必須です。RubyMineでは「IdeaVim」というVimキーバインドを再現してくれるプラグインが用意されており、インストールの途中、オプトイン形式でインストール出来ます。 Vimキーバインドはプラグインで解決するのですが、エディタ固有のキーバインドに苦戦しています。 VSCodeでよく使った機能との対応を把握すると多少楽だった。このあたりのショートカットは抑えておきたい。 RubyMineVSCodeファイルのインクリメントサーチCmd + Shift + OCmd + PコマンドパレットCmd + Shift + ACmd + Shift + Pターミナルの起動option + F12ctrl + ` 補完がいいぞ TypeScriptほどじゃないけど、まあまあ書きやすくなった。 Railsプロジェクトだけど、モデルのフィールド名ぐらいの補完はしてくれる。 vimやvscodeではctagsプラグインなどを使って実現していたが、デフォルトでいい感じにしてくれるのはかなり体験がよい。 ちょっと重い 筆者のエディタ遍歴がVimとVSCodeなので、とにかく軽量なエディタを使ってきました。そのこともあり統合開発環境は起動がめちゃくちゃ遅いという印象があります。 iMac 2017でメモリ40GBで「まあ我慢出来る」ぐらいの感想なので、ノートPCで起動しようとは思えないかも… 同じ職場のちょっと古いMBPを使っているエンジニアいわく「まともに動かない」とのこと Ruby/Railsに特化した機能が便利 大体コマンドパレット（RubyMineでは「Find Action」と呼ぶらしい）からRuby/Railsの各種機能が呼べる。ターミナルもあまり必要なくなってよい。 とりあえず「rake」とか「rails」で検索するといい感じのアクションを示してくれる感じ 今後やりたいこと Ctrl + Aで行頭に、Ctrl + Eで行末に動くショートカットキーを設定した。（Vimキーバインドに乗っ取られてる） VSCodeのCmd + [、Cmd + ]（インデント変更）に当たるショートカットキーを設定したい。 感想 ちまたのプログラミングスクールではRuby on Railsを教えているスクールが多いとの噂ですが、補完の効くTypeScriptとNext/Nuxtみたいな組み合わせで始めたらいいんじゃないでしょうか？ 作りやすさもポイントだとは思うけど、快適に開発出来るかどうかって結構重要だと思います。TypeScript最高！ Rubyに関してはRubyMineでもう少し頑張ってみようと思います。年内はRailsやっていき。 注釈 もともとはRailsをずっとやってきた人間なので、去年までRubyの方が得意でした。本当は新規のRails案件は避けていたけど、知り合い経由だったので引き受けた。 ↩ TSだと動かす前にエラーがわかることが多いので、更にツライ ↩

10/26にTECH PLAY SHIBUYAで開催された執筆の技術を勉強する会 #1に参加してきました。 自分はスピーカーとして参加しており、「自分を甘やかして続ける技術ブログの始め方」という意識低めなセッションをしてきました。 セッションについて 4つのセッションと3つのLTという構成でのイベントの最初のセッションを担当しました。 今回は技術書典5でサークル参加した人のトークということだったのですが、技術書については他の方がやってくれそうな気がしたので、身近に感じられる技術ブログをテーマにしました。 自分はブログの中でも一番つまづきやすいのが、続けることだと思っています。自分がようやくブログを続けるときに意識している「モチベーション」を中心に話しました。 モチベーションの文脈では「どうやってモチベーションを上げるか？」のような議論になることが多いと思います。ですが、今回は「モチベーションが低いときにどうするか？」というスタンスで話をまとめました。  イベントについて このイベントは「エンジニアの登壇を応援する会」という団体が運営しているイベントなのですが、「日本酒枠」という日本酒を持ち込むことで参加費が無料になる＆日本酒の紹介LTができる枠があるのが特徴です。 日本酒枠があるので、日本酒の品揃えが豪華ですし、おつまみも他のイベントと比べると圧倒的に豊富です。 #engineers_lt で話します！めちゃくちゃ豪華なお酒とおつまみが用意されています！渋谷開催です！ https://t.co/o5PkV4wpjR pic.twitter.com/RsPLixcqFR— もっと@Gatsby&Netlify本 (@mottox2) October 26, 2018 また、参加者や会場の空気がとてもいいことが印象に残っています。 司会の@ariakiがオープニングで場の空気を盛り上げてくれたこともあり、参加者のレスポンスがとても強かったです。 セッションのはじめの挨拶でみなさんが挨拶を返してくれて、とても心強く感じました。自分も聞く側の時はレスポンス強めを意識したいところです。 他の方のトークも非常に盛り上がり、エモ目なトークが続きました。「本が生える」という言葉がパワーワード感が溢れていたので自分も引き続き本を生やしていきたいと思います。ただ、盛り上がりすぎてしまい、懇親会が2分になってしまったのが残念です。 ただ、全体として非常に満足出来るイベントでした。今回はイベントのリハーサル会1もあったので、発表の満足度も高いまま終えることができました。 参加者のアウトプットについて 技術書典後ということもあり非常に熱量の高い人たちの集まりです。参加率も非常に高いとは聞いているのですが、Twitterのトレンドにも一瞬出るぐらいTwitterにアウトプットしていたようです。すごい。 また、イベントのレポートを積極的に書いている方も多く、既に11本が公開されているようです。 イベントレポート作成のために参加者のみなさまのブログをTwitterで確認していたらなんと11本が現時点で投稿されていました。たくさんのフィードバック本当にありがとうございます！運営にいかせる色んなアイデアが書かれていてすごく嬉しいです。#engineers_lt— ariaki (@ariaki4dev) October 27, 2018 このように非常に熱量の高い勉強会です。技術書典6ではこの勉強会に参加した人達がどのぐらい「本を生やす」か気になります！ 改めて、@ariakiさんを始めとする運営やスタッフ、参加者の皆様、楽しい時間をありがとうございました！ 注釈 リハーサル会では他の人のフィードバックも受けることができ非常によい経験でした。 ↩

10/11に行われた技術書典5から、2週間半ほどの時間が経過しました。 自分はサークル側で出展していたために、あまり本を手にすることが出来ませんでしたが、何点か気になる点があったので記事にしておきます。 1行にまとめると積ん読状態になるので、内容に関係なく読み始めやすい本の特徴があるということ。 どんな本に手をつけやすいか 前提として、技術書典に参加した人は多くの本を購入したタイミングで積ん読状態になっていると思う。 積ん読状態で100ページ近い本は手に付かない。 軽めのものから読もうと思った。 パット見で文字の密度の低い本。 サンプルコードが少ないと読む気になりやすい。 紙書籍であること。 B5サイズのPDFはiPadを持ち出さないと、読まないことに気がついた。 固定レイアウトだとスマホで開く気にならない。 これは人に依存しそう。自分は小説とマンガ以外は紙本で読むタイプの人間。 その他気づいたこと 明朝体のが読みやすい。Re:VIEWで執筆されている本は安心して読める。 DLカードの保存方法に迷っている。 カメラで取ってesaに保存かな？ ごくごく当たり前の内容かもしれませんが、次回の糧となりますように。

静的サイトジェネレーターの中でも、自分はGraphQLのデータ層を採用しているGatsbyJSを激推ししている。 しかし、GatsbyJSはビューをReactで書く必要があり既存のサイトを移植するというのが大変だった。 今日見つけたのは、GatsbyJSにインスパイアされVue.jsでビューを書けるGridsomeという静的サイトジェネレーターである。 まだバージョンは0.2.2なので、ファーストインプレッション程度に思ってもらいたい。 複数のデータソースを元に、静的サイトを生成する図はほとんどGatsbyのそれと変わらず、Vue.jsでビューを書くことが出来る。 WordPress Starterの観察 例えば、公式のWordPressのstarterを取り上げてみる。 @gridsome/source-wordpressのようなソースデータを扱うパッケージをインストールしたのち、gridsome.config.jsにプラグインを利用するための記述を追加する。 gridsome.config.js module.exports = { plugins: [ { use: '@gridsome/source-wordpress', options: { baseUrl: 'YOUR_WORDPRESS_URL' } } ] } @gridsome/source-wordpressによって追加されたソースデータはGraphQLで取得出来るようになる。 vueの単一ファイルコンポーネントの中のpage-queryにデータを取得するGraphQLを書くと、template内で参照出来るようになる。という話。 src/templates/WordPressPost.vue <template> <div> <h2>Latest blog posts</h2> <ul> <li v-for="edge in $page.allWordPressPost.edges" :key="edge.node._id"> {{ edge.node.title }} </li> </ul> </div> </template> <page-query> query Blog { allWordPressPost (limit: 5) { edges { node { _id title } } } } </page-query> Nuxtと比べてなにがいいの？ Nuxtの静的サイトじゃダメなのか？という話があるが、Nuxtは1ページ目については静的サイト化してくれるが、2ページ目以降は、asyncDataに記述されたAPIリクエストが行われてしまうので、キレイな静的サイトではないという認識。 GridsomeはGraphQLで取得したデータを静的ファイルに保存するので、本番環境で外部のAPIへのリクエストは発生しない。静的化されたファイルはレスポンス早いし、先読みも出来る。 みやおかさんの「Firebase、Flamelink、Nuxt、Netlify、PWAを使ってJAMstackなブログを作る」が詳しい。 勢いで書いた。 参考: Say hello to Gridsome 👶🎉💚 - Gridsome

Pixelaというサービスのnodejsクライアントライブラリを書きました。 Pixelaとは？ GitHubのような芝生画像を生成するWebサービス。すべての操作をAPI経由でやる。 こういう画像を生成できる。 作者ブログ: commit以外の数値でも草を生やせる、PixelaというAPIサービスを作った！ - えいのうにっき 公式サイト: Pixela | Pixelation API Service pixela-node すごいいいサービスだと思ったので、Node.js用のクライアントをつくって公開しました。 （メソッドの返り値がaxios全開なので、返り値変更の破壊的な変更を行う可能性が高い。） mottox2/pixela-node: Pixela API Client for nodejs 次のようなコマンドでインストール出来ます。TypeScriptの型定義もあるので、TSで触るのがおすすめ。 $ npm install --save pixela-node or $ yarn add pixela-node これからSlackからPixelaをいじるコードを書く予定です。 筋トレの習慣化に向けて頑張るぞ！作者の@a_knowさん、ありがとうございます！ 正直PWAで同じようなアプリケーションを作ろうと画策していたのだけど、Pixelaが良かったのでPixelaの使いみちを考えることにした。

池袋で行われた日本最大の技術書の同人誌即売会の技術書典5で技術同人誌を頒布してきました。 今回の振り返りとして、やったこと、反省すべき点、今後の販売について記事にしました。 やったこと 執筆 「GatsbyJSで作るモダンウェブサイト」と「netlifyで始めるサーバーレス開発」という本を自分のサークルで頒布、別サークルで合同誌を書きました。 技術書執筆にはRe:VIEW（Tex1を人間向きにした組版ツール）がいいと聞いていたので採用することは決めていました。 ただ、Re:VIEW記法に慣れることが出来ず、最初はMarkdownで執筆を行っていました。 しかし、技術書となるとMarkdownの記法だけでは表現力が弱く、執筆序盤でRe:VIEWに移行しました。 図表番号の参照や、画面のキャプションなど技術書らしさを出すための記法が揃っているので、最初からRe:VIEWを使うべきでした。 宣伝 主にTwitterで行いました。出来るだけ画像をつけてツイートすることで、少しでも多くの人の目に留まるよう工夫をしていました。 結果、8月の「121 Tweets / 62.3K Imp」に対して9月の「157 Tweets / 114K Imp」と普段よりは多くの人にツイートが見られたようです。 Netlify Meetup Tokyo での登壇やブログでの宣伝も行っていました。 登壇を聞いてブースに来てくれた方もいて、「面白い登壇だった」との言葉も聞けて嬉しかったです。 表紙、DLカード 使い慣れたSketchでざっくりつくって、印刷用のデータをPhotoshopで作る手法を用いました。 全体的に使い回せるようにデータをつくっていたので、デザインの出来はともかくうまく進めることが出来たと思います。 反省すべき点 締切に追われるのが良くなかった そもそも同人活動が始めてで、「なにが必要なのか？」「なにに対して締切があるのか？」みたいな事柄に関するキャッチアップが弱かった製で、全体的に後手後手な対応になった。 かろうじて、親方プロジェクトさんの「ワンストップ!技術同人誌を書こう」という本のおかげでキャッチアップ出来た箇所もありましたが、それでも考えることがたくさんありました。 締切が迫ると、徐々にプレッシャーがかかって不眠症のような症状が出てきたので、背水の陣みたいな戦法は避けたいところです。 一般参加者として回れなかった 売り子（プログラミング経験なし/接客力すごい）に手伝ってもらったのですが、一人にするのは無責任だと思ったのでほとんど自分のブースにいました。売り子が呼び止め役、自分が語る/質問に答える役と分担してうまくハマっていたと思います。 ただ、自分のブースにいたがために、一般参加者として回ることがほとんど出来ませんでした。 後述の戦利品は、トイレに行く途中、目についたものがほとんどです。 普段馴染みのない分野のブースで、立ち読みしながら購入を検討する体験をしたいです。 ブログと全然違かった 最初は「ブログ書いてるしいけるでしょ？」と根拠のない自信を持っていたのですが、執筆始めた途端で「ブログと全然違う…」という気持ちになりました。 ブログではコンテキストありき（ex. Gataby / Reactを触ったことがある/良さを知っている）な文章を書いていた。 検索を通してアクセスしてくる想定なので、ブログとしては正しいと思っている。 対象層を絞ればそれも可能だが、多くの人に手に取って欲しかった。 ブログでは記事ごとに一貫性がなくても許される 本では、一つのテーマについて破綻のないように書く必要があった。 どっかを書き換えるとどっかが破綻する、保守性の低いプログラムを書いている気持ちになった。 商業出版で書いている人達に尊敬の念が生まれた。 人にイラストを頼みたかった ほぼ同じテーマを扱っている「0から始めるNetlify」の表紙を見た時「これがプロか！」と打ちのめされました。 相当ニッチで、売れないことが予測されない本でないのであれば出来る人に頼むのがいいと思いました。 自分のつくったものに関しては、字詰めやレイアウトなどのレイアウトはともかく、「同人誌としてふさわしいデザインなのか」という観点であまりふさわしいものではないと思いました。イラストが欲しい！ もっとカッコよくて、かわいい本を作りたいです！ うぉぉぉぉ！今回のNetlify本の表紙＆サークルカットが出来たぞー！本も仕上がってきました！タカユリさん @mazenda_mojya の描いたNetlifyさんキャラ＆職場でも広げやすいかっこいいデザインに仕上がりました！公式サイトでサークルチェックをお願いします！#技術書典https://t.co/L3xxYBzLQz pic.twitter.com/2tC6cTGno5— ナベ🍲 技術書典-Netlify本 (@nabettu) October 2, 2018 2冊同時に書くのは辛かった 初参加なら1冊書くのに留めるべきだと思います。 入稿の締切を2週間ずらしたので、2イテレーション回した気分です。PDCA（） Pixiv Payは対応しなくてもよかった 自ブースでは現金、技術書典後払いアプリ、Pixiv Payを支払い方法として用意していました。 利用者の内訳は技術書典後払いアプリが31人、Pixiv Payアプリが3人でした。 おそらく他の同人イベントではPixix Payは便利だとは思うのですが、公式が支払い方法を提供している技術書典では、利用者が少なくなるのだと思いました。 また、技術書典公式アプリが、利用者側の端末で完結するのに対して、Pixiv Payはブース側でも操作する必要がありオペレーション的には技術書典公式アプリの方が楽でした。 次回もサークル参加するのであれば、現金or公式後払いアプリを採用すると思います。 名刺をつくっておけばよかった そもそもフリーランスなのに名刺を持ってない僕が悪いです。 名刺を作る仕事をたまに受けるのにもかかわらず、自分の名刺はつくっていませんでした。 名刺を渡してくれる方もいたので、僕も返すための名刺を持っておきたかったです。 「俺しかやらない」という使命感 Netlify本はNetlifyのFunctionsを使ってFaaSに入門する内容、GatsbyJS本は「React入門から始めてウェブサイトをGatsbyで構築する」本です。どちらともニッチといえるような分野の本でした。 正直のところ自分がかきたいものは「Netlifyをハックして便利ツールとして使う」本や「Gatsbyでより柔軟にサイトを構築するgatsbyテクニック集」でした。しかし、自分が伝えたいことは「NetlifyのFaaSは便利でいいぞ！」というと「GatsbyもReactも最高だぞ！」ということでした。 どちらもニッチな分野で、既に存在を認知している人は「いいぞ！」と思って使っているでしょう。技術書典で伝えるべきことはフロントエンドに明るくない人に存在を認知してもらうことだと思い入門本に振り切ることにしました。 こういった本は「自分しかかけない」内容とは思っておらず、「自分しか書かないもの」だと思っています。 ただ、ニッチとは言っていますが、GatsbyJSはGitHubで25,000以上スターがついており、スター数だけで言えば最近盛り上がっているNuxt.js2（約15,000star）よりメジャーです。 これは日本や中国を中心にVueが流行っているという背景もあると思うのですが、もう少し正当な評価を受けられて広まるといいと思っています。 戦利品の紹介 #技術書典 の戦利品です。知り合いのところは自分で買いに行こうとしたらタイミングを逃して買いそびれた…正直の所18時までだと思って油断してた pic.twitter.com/YmpGtG62eS— もっと@技術書典5 け52&う58 (@mottox2) October 9, 2018 俺たちの戦いはこれからだ 自分の伝えたいことを本にした。ただ、次はもっとうまくやれるはず。 次回の技術書典6は伝えたい内容があればまた出展します。 本じゃなくて動画も良さそうと思ったのでいろいろ試していきたいと思います。 俺たちの戦いはこれからだ。 今後の販売について 物理本はとらのあな、電子版（PDF）はBoothで販売します。 物理本はBoothを予定してたのですが、絵が可愛かったのでとらのあなに入荷してしまいました。3疲れてると判断が適当になるのは反省点ですね。 物理本 Gatsbyで作るモダンウェブサイト netlifyで始めるサーバーレス開発 電子版（PDF） Gatsbyで作るモダンウェブサイト netlifyで始めるサーバーレス開発 とりあえず、気になるマンガとアニメのストックが溜まったので、漫画喫茶・dアニメストア・Netlflix活動を再開しようと思います。 注釈 理系学生の卒論などで使われる組版処理システム ↩ Vue.jsベースのフルスタックフレームワーク。potato4d氏がすごい勢いで広めている ↩ 疲れていたからしょうがないとはいえ、とらのあなの管理画面がよくわからないので辛いです、「めっちゃレガシー」って感じ。 ↩

9/26にABEJA社で開催されたNetlify Meetup Tokyo #2で「静的サイトだけじゃないNetlifyの活用法」という内容で登壇しました。 初の20分登壇でかなり緊張していたのですが、会場の温かい空気に励まされました。話しやすい勉強会大好きです。 背景 Netlifyはあまりにも簡単すぎて本来の「静的サイトをホスティングする」という役割に関して話すことが見つからず、ちょっと先の未来に役立つテクニックを紹介することにしました。 次のテクニックについて話してきました。 Netlify Functions JSONの配信 SlackやGitHubとの連携 Build CommandでHack 発表資料 https://speakerdeck.com/mottox2/netlify-extra-mode 紹介した活用法 Functionsを使ってFaaS風に使う このブログでも何回か取り扱っているNetlify Functionsです。 内部ではAWS Lambdaが動いているのですが、Netlifyを通して使えばAWSのアカウントいらずで使えます。 JSONファイルを配信する 静的サイトをホスティングしているので、当然と言えば当然なのですがJSONファイルを配信するためにも使えます。 JSONを別ドメインに配信するときに気になるAccess-Control-Allow-Originヘッダーなどは_headersファイルを使うことでいじることが出来ます。 Node.jsで収集したデータを配信するAPI ビルドコマンドを設定出来るので、その中で外部APIを叩いたり、WebsiteのHTMLを見てJSONを保存するコードを書けばAPIとして使えます Slackのメッセージを配信するAPI Slackでreactionの追加メッセージをJSONとして配信するAPIの事例を紹介しました。 内部でSlack Event APIとGitHub Rest APIを使うことで実現しています。次のような仕組みで実現できました。 SlackでReactionがつくとSlack Event APIによってFunctionsに対してPOSTリクエストが飛ぶ Functionsの処理でメッセージを取得し、GitHubのcreateFile APIを叩く メッセージをファイルに保存する GitHubのcreateFile APIによって作成されたcommitをフックにNetlifyのビルドを開始 ビルド中に保存されたメッセージをJSONにまとめて公開ディレクトリに保存 NetlifyによりJSONが配信される 同様の事例として日経の米朝首脳会談の速報ページがありました。 日経の米朝首脳会談の速報ページ、気味の悪い拡張子のファイルによるとSlackが使われているっぽい。現地からSlackに投稿するとそのまま公開される仕組みっぽい。すごい今風。https://t.co/PFumeSAJMA pic.twitter.com/FDGX6oR8uq— こに@SocialDog/whotwi (@koni) June 12, 2018 esa.io + GatsbyJSなブログ 当ブログの事例を紹介しました。Gatsbyなので普通の静的サイトですが紹介しました（宣伝したかった…） 情報共有ツールesa.ioをCMSとして使って1ヶ月運用してみた 宣伝 サークルチェックはここからできます。 https://techbookfest.org/event/tbf05/circle/41140002

今までの記事 GatsbyJS v2 はじめの一歩 (1) 開発環境の立ち上げ GatsbyJS v2 はじめの一歩 (2) 実際にページを作る GatsbyJS v2 はじめの一歩 (3) ページにスタイルを当てる GatsbyJS v2 はじめの一歩 (4) gatsby buildとデプロイ GatsbyJS v2 はじめの一歩 (5) GraphQLによるデータ管理 GatsbyJS v2 はじめの一歩 (6) Source Pluginの利用 GatsbyJS v2 はじめの一歩 (7) 動的にページを生成する Progressive Web Appとは PWA（Progressive Web App）は近年よく聞かれるようになった言葉ですが、ざっくりというと「アプリのようないい体験をWebでも提供しましょう。そのために早くて信頼性が高く魅力的なものをつくりましょう」という話です。 巷では、ホーム画面における、オフラインでも動くような機能的な側面がプッシュされがちですが、全体としての体験やそのための機能群（ex. Offine、Add To HomeScreen, etc…）のことです。 GatsbyにおけるPWA対応 実はGatsbyのデフォルトテンプレートで既に対応されおり Service Workerによるオフライン対応 Add to home screen (A2HS) は動く状態になっています。 今回は自分でまっさらな状態から対応する場合の説明をします。 Service Workerとは？ 一言で言うと、UIと切り離された状態で動作してくれるスクリプトです。 基本的にイベント駆動なスクリプトになっており、プロキシのような動作を実現できたり（ex. ブラウザとワーカーの間でサーバーと通信する前にブラウザ側のキャッシュを返す)、プッシュ通知を受け取るような処理を実現することが出来ます。 参考リンク: Google DevelopersのService Worker の紹介 Add to Home Screen (A2HS)とは？ Add to Home Screenは簡単に言うとホーム画面にアイコンをおける機能です。従来もアイコンをホーム画面に置くことができましたが、PWAの文脈のA2HSでは、起動画面（SplashScreen）、アプリケーションの色、ブラウザのバーの有無の設定などがカスタマイズできるようになっています。（ただし2018年iOS 11.4時点でのサポートはAndroidほど進んでいません。） A2HSを利用するためにはWeb ManifestというWeb Appとしての振る舞いをJSONで記述するファイルを設置する必要があります。 Web Manifestはmanifest.webmanifestという名前で<link rel="manifest" href="/manifest.webmanifest"/>のようなlinkタグで呼び出されます。まずはシンプルなWeb Manifestファイルを示します。 { "background_color": "purple", "description": "Shows random fox pictures. Hey, at least it isn't cats.", "display": "fullscreen", "icons": [ { "src": "icon/fox-icon.png", "sizes": "192x192", "type": "image/png" } ], "name": "Awesome fox pictures", "short_name": "Foxes", "start_url": "/pwa-examples/a2hs/index.html" } このようなWeb Manifestファイルを設置したサイトで、「ホーム画面に追加」を選択するといい感じにアプリライクになったアイコンをホーム画面に追加できます。 なおA2HSを有効にするためには次の条件を満たす必要があります HTTPSになっていること linkタグでWebManifestが呼ばれていること 適切なアイコンが設定されていること ServiceWorkerが有効になっていること Pluginを利用したPWA対応 GatsbyJS（やNuxt.jsなどの主要フレームワーク）の文脈でのPWA対応は「オフライン対応」、「Add to Homescreen」が多いです。これはある程度やることが決まっており、プラグイン的なもので簡単に対応出来るからです。 GatsbyJSでも例に漏れずPWA対応をプラグインで行うことが可能です。使用するプラグインは次の2つです。 gatsby-plugin-manifest gatsby-plugin-offline gatsby-plugin-manifestではWeb Manifestを有効化、gatsby-plugin-offlineでオフライン対応を行います。それではプラグインの導入を進めていきます。 といっても簡単で、PluginのオプションにWebManifestの内容を入れるだけで終わりです。簡単ですね。 module.exports = { siteMetadata: {}, plugins: [ { resolve: `gatsby-plugin-manifest`, options: { name: 'App Name', short_name: 'AppName', start_url: '/', background_color: '#663399', theme_color: '#663399', display: 'minimal-ui', icon: 'src/images/logo.png, // This path is relative to the root of the site. }, }, 'gatsby-plugin-offline', ], }

アラサーになりました。ちょうどいい機会なので一年を簡単に振り返ってみました。 去年はなんでもやっていたのですが、ブログを中心としたアウトプットをする中で「より早く試す」・「開発速度を落とさない開発」のテーマに収束していきつつあります。 お仕事 マーケティング系サービス Railsアプリケーションの一部SPA化 WordPressからGatsbyJSへのリプレース サービスのプロトタイプを作っていろいろ検証中 Google AnalyticsベースのCRM基盤の整備 メディア系サービス 社長・デザイナーとプロトタイプ作りながらサービス立ち上げ エンジニア採用の面談、コードレビュー、設計の相談 GKEベースのインフラ整備 SPA + SSR + CDNアーキテクチャ導入 エンタメ系サービス 立ち上げからデザイン&フロントエンドで参加 残念ながらクローズ 人材系サービス サービスのリブランディングでディレクションを担当 5年もののサービスをEC2からBeanstalkに載せ替えた 営業のパワーアップをすれば事業が伸びるモデルはわかりやすい。エンジニアは武器職人。 その他 WordPressサイトのリニューアル 名刺の制作 そのほかにも何かやった気がするけど思いついたのはこのぐらい ありがたいことに常に仕事があったので抑えめではあったけど一年中働いてた。本当にありがとうございます。 2018年になってから仕事は抑えめにしてインプット＆アウトプットに力をいれていたので、後半の仕事量はそれほど多くない。ただ、アウトプットした内容が仕事になることも増えていって、仕事に深みが生まれた気がしています。 言語面では2017年末はRuby(Rails), Python(Django), PHP(WordPress), golang, JavaScriptを書いていたが、2018年になって仕事を抑えめにしたところほとんどJavaScript(TypeScript)とRuby(Rails)だけになった。 インフラはAWSからGCPを使うことが多くなっていった。App Engine, Kubernetes Engine, Cloud SQL, Cloud Functions, Cloud Storageと主要サービスは大体触った。好き。 EC2からのリプレースで懲りたのでイミュータブルなインフラを目指していきたい気持ちが強い。Dockerは2年前ぐらいから触っているけどk8sでようやく腑に落ちた。 エンタメ系サービスは自分の中で挑戦だったが、うまくいいトレンドが作れなかった。その反省で新規で大きなことを始める前にはプロトタイプを作るようにした。 Sketch + Invision Studioが今の所推しツール。ただツールにとらわれず挑戦していく。最近はnoteに鬼のように事例が上がるので感謝。 プロトタイプを作ってみるとアイディアの段階よりインパクトが弱かったりするので、失敗は回避出来ている気がする。ただ、これだってものが作れてないので、今年はプロトタイプで検証して成功の流れを作りたい。 アウトプット ブログ 2018/5から始めてから22記事公開。 少しずつ検索流入が増えている最中。 ブログのメンターをやってくれた@kakakakakkuさんのおかげ。 LT 8回LTした。資料をアップロードしてあるのはそのうち6回分。 イベント主催者や会場を提供してくれる会社さんには感謝です。 いいアウトプットでお返ししたいけど、運営の方も少しやってみたい。 Qiita / note note/Qiitaともに7記事 ブログを初めてからは投稿をほとんどしなくなった。 技術書典 10/8開催の技術書典5でサークル出展 絶賛執筆中 興味のあるテーマ GatsbyJS Netlify (JAM Stack) まとめるとブログ記事等は36記事、LTが8回。 3年前から「今年はアウトプット」するぞって言ってた気がするのですが今年は達成しました。 @kakakakakkuさんのブログメンティ募集に応募したのがすべての転機になったと思います。おかげさまでOSS活動を始めることができ、Gatsbyのメンテナーになったり、技術書典への応募までたどり着きました。 2018年感謝大賞があれば、間違いなく大賞です。大変感謝しています。ありがとうございました。 少しアウトプットに慣れてきたので、エンジニアの登壇を応援する会の@ariakiさんのように「人のアウトプットを引き出す」ような活動を出来たらなと思っています。 GatsbyとNetlifyはJAM Stackの文脈でやっており、非常に可能性を感じています。技術書典のアウトプットや実例を作っていくことで流行ればいいなと思っております。 アウトプットで大きく一歩を踏み出せた反面、自分の中での反省もあるのでしっかり直してしていこうと思います。 直近でいうと技術書典までは、ほぼ執筆集中モードなので原稿を落とさないようやっていきます。 最近個人Webサービスを作っている人とよく合うので 今年もより多くの人に使われるものを作れるようがんばっていきます。

2018/10/8に池袋サンシャインシティで開催される日本最大の技術同人誌イベント「技術書典5」が開催されます。 今回、サークル「つのぶえ出版」としてNetlifyとGatsbyの布教本を書くことにしました。 主に、初心者から中級者に向けて、モダンなフロントエンド中心の開発を実現するための本です。 今は過渡期で情報が氾濫しています。そういった情報を本という形式でまとめることで、少しでも学習のハードルが下がればと思って書いています。 サークルの配置場所は「け-52」というブースです。会場内の地図も載せておきます 興味を持ってくれた方は公式サイトから「チェックリストに追加」ボタンを押して貰えると嬉しいです。 チェック数によって印刷数が変わってくると思います。 https://techbookfest.org/event/tbf05/circle/41140002 というわけで新刊の詳細です。初参加・初執筆ですが2冊書きます。 GatsbyJSでつくるモダンウェブサイト 自分がブログやLTでよくアウトプットしているGatsbyJSの本です。 普段は断片的な情報（しかも中級者向け）が中心になっていますが、ある程度網羅的なアウトプットになるよう意識して書いています。 GatsbyJSというフレームワークというよりは、「データとビューが分離された構成での開発の素晴らしさ」を感じてもらえればと思います。 ■ この本で得られること Reactでのウェブサイトを開発出来るようになる GatsbyJSでの開発が出来るようになる フロントエンドとバックエンドが分離することの嬉しさを感じることが出来る Headless CMSについて知ることが出来る ■ 想定読者 JS初心者から中級者ぐらいの人 Git/GitHubでリポジトリを作れる人 ■ 目次 第1章 Reactのキャッチアップ 本書を読む前に知っておいて欲しいReact開発部分の知識を説明します。 第2章 GatsbyJSの基本 GatsbyJSの基本を抑えつつトピックごとに説明します。 第3章 Headless CMSベースのウェブサイト開発 Headless CMSをデータとして利用するウェブサイト開発について説明します。 Netlifyで始めるサーバーレス開発 ■ この本で得られること Netlifyが使えるようになる FaaSを用いた開発が出来るようになる LINE Botが作れるようになる SlackAppが作れるようになる ■ 想定読者 JS初心者から中級者手前ぐらいの人 Git/GitHubでリポジトリを作れる人 ■ 目次 第1章 Netlify入門 Netlifyへの登録や基本的な利用方法について説明します。 第2章 Netlify Functions入門 Netlify Functionsの基本的な使い方や、netlify-lambdaというバンドラーを使った開発方法を説明します。 第3章 LINE Bot開発 LINE Botの基本的な説明と実際にFunctionsで開発する方法を説明します。 第4章 Slack App開発 Slack Appsの基本的な説明とSlashCommandという機能拡張をFunctionsで行います。 第5章 この本のあとに取り組みたいこと GAS(Google Apps Script)やAWS LambdaやGCP Cloud Functions/Firebaseの紹介をします。 「エンジニアのためのUIデザイン本」 「犬テトラ+(う-58)」というサークルでUIデザイン本も書きます。@takanoripさんと@atsuco_02さんと@nabettuさんとの合同誌です。 ガチ目なフロントエンドメンバーで書くUI本なのでぜひこちらも！ サークルチェックはこちら => https://techbookfest.org/event/tbf05/circle/28380002 あとは書くのみ、いい本にするのでぜひ読んでください。 重ねてサークルチェックもお(ry https://techbookfest.org/event/tbf05/circle/41140002

今までの記事 GatsbyJS v2 はじめの一歩 (1) 開発環境の立ち上げ GatsbyJS v2 はじめの一歩 (2) 実際にページを作る GatsbyJS v2 はじめの一歩 (3) ページにスタイルを当てる GatsbyJS v2 はじめの一歩 (4) gatsby buildとデプロイ GatsbyJS v2 はじめの一歩 (5) GraphQLによるデータ管理 GatsbyJS v2 はじめの一歩 (6) Source Pluginの利用 前回の記事ではSource Pluginを使って外部のデータをReactコンポーネントで使えるようにしました。ただし、前回のままだと一覧ページしか作っていません。ブログなどのウェブサイトを作ろうとすると、一覧ページだけではなく詳細ページも欲しくなると思います。 GatsbyJSのルーティングはsrc/pages以下のルーティングで決定されるということは以前説明しましたが、これでは外部データに依存する（例えば、記事詳細ページ）を作ることが出来ません。そこでgatsby-node.jsを利用することでGraphQLのデータを元にページを生成する方法も用意されています。 gatsby-node.jsはGatsbyJSの動作をカスタマイズするファイルです。このファイルの中でGatsbyJSのライフサイクルに合わせた関数をexportすることで希望の動作をさせることが出来ます。参考: Node APIs 今回はcreatePagesを使用します。この関数は動的にページを生成するための関数でプラグインによるソースの追加・加工が終わったタイミングで実行されます。 gatsby-node.js exports.createPages = ({ graphql, actions }) => { const { createPage } = actions const postTemplate = path.resolve(`./src/templates/PostTemplate.jsx`) return new Promise((resolve, reject) => { graphql(` allHnStory { edges { node { id title score order domain url } } } `).then(result => { // GraphQLのデータを使ってページを追加する処理 result.data.allHnStory.edges.forEach(edge => { const node = edge.node createPage({ path: `/posts/${node.id}`, component: postTemplate }) }) resolve() }) }) } それでは順を追ってコードの解説をしていきます。 動的に追加するには次の手順を行います GraphQLでデータを取得する 動的に作成するページのテンプレートを作成する 取得したデータを作ったテンプレートに適用する まずはGraphQLでデータを取得します。次のコードをgatsby-node.jsに追加してください。 exports.createPages = ({ graphql }) => { return new Promise((resolve, reject) => { graphql(` { allHnStory { edges { node { id title score order domain url } } } } `).then(result => { console.log(JSON.stringify(result, null, 4)) resolve() }) }) } このコードを保存して、gatsby developを実行するとビルド中に以下の出力が表示されます。無事にデータが取得されconsole.logで表示されました。 次に動的に作成するページのテンプレートを作成します。Gatsbyでは動的に生成されるファイルはsrc/templates/以下に保存することが通例となっています。 今回は src/templates/story.jsx として次のファイルを追加します。 import React from "react" export default () => { return ( <div>This is story page</div> ) } 最後にGraphQLで取得したデータと、作成したテンプレートを紐づけます。ページを作成するためのメソッドがactions.createPageです。path（サイト上のパス）とcomponent（適用したいテンプレートのファイルパス）とcontext（ページに渡したい変数のオブジェクト）を引数とするメソッドです。 const path = require('path') exports.createPages = ({ graphql, actions }) => { const { createPage } = actions return new Promise((resolve, reject) => { graphql(` { allHnStory { edges { node { id title score order domain url } } } } `).then(result => { result.data.allHnStory.forEach(storyEdge => { const node = storyEdge.node const path = `/stories/${node.id}` console.log(path) createPage({ path: path component: path.resolve(`./src/templates/story.js`), context: { id: node.id } }) } ) resolve() }) }) } この状態で再度gatsby devevelopを実行しましょう。実行時のログにpathを表示しているので、それをURL欄に入力すると、Templateで定義したページが表示されます。 TODO: スクショ この状態ではまだ動的にURLに対応するページが生成されただけで、ページの内容にデータが反映されていません。ページ内にデータを反映させていきましょう。src/template/story.jsxを次のように編集します。 graphQLでeq: $idとあるのは、createPageで渡したcontext内にあるidです。idと一致するhnStoryを取得するというクエリを投げています。この状態でブラウザを開くと、個別のデータが入ったページが表示されます。 import React from "react" import { graphql } from "gatsby" export default ({ data }) => { const story = data.hnStory return ( <div> <h1>{story.title}</h1> </div> ) } export const query = graphql` query($id: String!) { hnStory(fields: { id: { eq: $id } }) { id title score order domain url } } ` このような手順で、動的にページを作成していくことができます。多少長い手順となりましたが、データとテンプレートの結合度が低い状態で実装していけることが分かると思います。

今までの記事 GatsbyJS v2 はじめの一歩 (1) 開発環境の立ち上げ GatsbyJS v2 はじめの一歩 (2) 実際にページを作る GatsbyJS v2 はじめの一歩 (3) ページにスタイルを当てる GatsbyJS v2 はじめの一歩 (4) gatsby buildとデプロイ GatsbyJS v2 はじめの一歩 (5) GraphQLによるデータ管理 前回の記事でGraphQLを使ってデータをReactコンポーネントに呼び出す方法を書きました。今回は自分で定義したデータだけではなくプラグインを使ってWeb APIなどのデータを利用する方法を説明します。 外部のソースデータを取り込むのに一番簡単な方法はSourcePluginを利用する方法です。例えばgatsby-source-filesystemやgatsby-source-medium, gatsby-source-githubなど色んなサービスのAPIを利用するプラグインが開発されています。（これらのプラグインはSource Pluginと呼ばれ、gatsby-source-xxxという命名規則になっています。） 例としてHackerNews（Y Combinatorというベンチャーキャピタルの運営するニュースサイト）を利用するgatsby-source-hacker-newsを使ってみます。 プラグインの利用方法はgatsby-plugin-styled-componentsを使用したときのようにgatsby-config.jsにプラグインの名前を記載します。プラグインの利用の際にはGitHubのREADME.mdを見てgatsby-confi.jsgにプラグインの情報を追記します。 gatsby-config.js module.exports = { plugins: [ 'gatsby-source-hacker-news' ] } gatsby-config.jsの変更が終わったらgatsby developを実行しGraphiQL ( http://localhost:8000/___graphql )を開きましょう。開いて画面左の入力欄に次のGraphQLクエリを入力して実行しましょう。実行すると次のような結果が得られます。allHnStoryはREADMEに書いてあるQuery例を元に入力しました。 { allHnStory { edges { node { id title score order domain url } } } } これで https://news.ycombinator.com/ と同じデータがGraphQLで取得することが出来ました。このようにSource Pluginを利用することでWeb APIのあるサービスのデータを利用することが出来ます。 次は、このデータをReactコンポーネントから呼び出しましょう。GraphQLによるデータ管理 で示した例と同様に次のようなコードと実行結果になります。 src/hn.jsx import React from "react" import { graphql } from "gatsby" export const query = graphql` query { allHnStory { edges { node { id title score order domain url } } } } ` export default (props) => <div> { props.data.allHnStory.edges.map(story => <a style={{ color: 'inherit'}} href={story.node.url}> {story.node.title} <small style={{display: 'block'}}>{story.node.score} Point | {story.node.domain}</small> </a>) } </div> いかがでしょうか、このようにGatsbyJSではリポジトリの外のコンテンツにも簡単にアクセスしてサイト内のコンテンツとして利用することが可能です。 次は、外部から持ってきたデータを元に動的にページを生成する方法を紹介します。