今までの記事 GatsbyJS v2 はじめの一歩 (1) 開発環境の立ち上げ GatsbyJS v2 はじめの一歩 (2) 実際にページを作る GatsbyJS v2 はじめの一歩 (3) ページにスタイルを当てる GatsbyJS v2 はじめの一歩 (4) gatsby buildとデプロイ Webページを構成するのに必要なのは、HTML, CSS, JSとDataです。Dataというのは stringという文字列だったり、42という数字だったり、{ pizza: true }のようなオブジェクトで表現できます。データはReact Componentの外にあるべきという考えに基づいており、マークダウンやCSVファイル、一般的なデータベース、Web APIなども含めてデータ層で持っておき、そういったデータを簡単に扱えるようにしています。 GatsbyJSではデータ層からReactコンポーネントにデータを取得するために GraphQL というクエリ言語を採用しています。 GraphQLはFacebookが中心になって開発されている技術でGitHubもGraphQLのAPIを提供しています。従来のAPI形式では複数のリクエストが必要だったケースもGraphQLでは一発でデータが取得できるようになっていたり、よりクライアント（GatsbyJSではブラウザ）から呼びやすい形式になっています。 余談ですが、GatsbyJSにとってGraphQLによってデータを管理することが他の静的サイトジェネレータとの違いになっています。他のジェネレータがリポジトリ内のファイルを取り扱うことが多いのに対して、GatsbyJSではWeb APIのデータとファイルと同列に扱えることによってよりマイクロサービス志向でコンテンツとビューの分離が実現できていると言えるでしょう。 はじめてのGraphQL 説明よりはどう使われているかを確認するほうが早いでしょう。 GatsbyJSで一番簡単なデータの定義はgatsby-config.jsに書くsiteMetadataです。いわゆるサイト全体で使用するtitleやdescriptionを管理するために使われるデータソースです。 今まではプラグインの情報だけを書いていましたが、siteMetadataを書き足しましょう。 gatsby-config.js module.exports = { pathPrefix: '', siteMetadata: { title: 'はじめてのGraphQL', description: 'GraphQLを初めて使ってみます。' }, plugins: [ 'gatsby-plugin-styled-components', ] } それでは定義したデータをReactコンポーネントから呼び出してみましょう。src/pages/data.jsを次のように編集します。 src/pages/data.js import React from 'react' import { graphql } from 'gatsby' const Data = ({ data }) => ( <div> <div>{ data.site.siteMetadata.title }</div> <div>{ data.site.siteMetadata.description }</div> </div> ) export const query = graphql` query { site { siteMetadata { title description } } } ` export default Data この状態で http://localhost:8000/data を確認するとgatsby-config.jsに定義した文字列が表示されていると思います。gatsby-config.jsをいじった後にgatsby developを立ち上げ直すのを忘れないようにしましょう。 ポイントを抑えておきましょう。 gatsbyからgraphqlをインポートして、テンプレートリテラル内にGraphQLのクエリを書く。 GatsbyJSのPageコンポーネントでqueryという名前でクエリをexportするとgraphqlを実行してくれる。 GraphQLによって得られるデータはdataという名前でpropsに付与される。 データとコンポーネントが分離されており、GraphQLが間を取り持ってくれるのが分かると思います。 GraphiQLの紹介 次の記事ではデータをGatsbyJSで管理するためのSource Pluginを取り扱いますが、その前でGraphQLを視覚的に扱えるGraphiQLの紹介をしておきます。 gatsby developを実行するときに次のようなログが表示されたと思います。その際に「View GraphiQL, an in-browser IDE, to explore your site’s data and schema」という文字列とURLが表示されたと思います。URL（ http://localhost:8000/___graphql ）を開いてみましょう。 URLを開くと次のような画面が表示されます。画面は左右に分割されており、左側はGraphQLのクエリを書けるテキストエリア、右側が実行結果が表示される領域になっています。 例えば先程入力したクエリを入力して、左上の「実行ボタン」を押すか、Cmd+Enterを押すと結果が右側に出力されます。 また、右上の「Docs」というボタンを押したり、Cmdキーを抑えながら、テキストエリアの要素をクリックすると画面右にクエリの構造などが表示されます。これもクリックしていくといろいろ見れるので、GatsbyJSで開発していく上でうまく使っていくとよいでしょう。

今までの記事 GatsbyJS v2 はじめの一歩 (1) 開発環境の立ち上げ GatsbyJS v2 はじめの一歩 (2) 実際にページを作る GatsbyJS v2 はじめの一歩 (3) ページにスタイルを当てる 前回、styled-componentsでページにスタイルを当てました。今回は今まで作ったものをインターネットで公開するための作業をします。 buildでHTMLを生成 一般的に、プログラミングでものを作るときには、デバッグ用の開発環境と公開用の本番環境を用意します。開発環境は開発者向けにエラーログをそのまま表示したり、様々なデバッグのための機能が含まれています。一方、本番環境では閲覧に必要なものだけを含めるために動作速度も一般的に早くなります。 今までgatsby developと入力していたものはGatsbyJSが用意している開発環境でした。環境時の文法に誤りがあったりするとエラーが表示されたり、ファイルを更新するだけでブラウザがリロードしてくれるなど開発に便利なものがてんこ盛りでした。しかし、デプロイすることを考えると上のようなエラー表示や、自動リロードは不要です。そこで用意するのが本番環境です。 GatsbyJSは静的サイトジェネレータと呼ばれるツールに分類されていて、最終的に出力されるのはhtmlファイル+JSファイルです。これを出力するためのコマンドがgatsby buildです。 gatsby buildを実行するとpublicディレクトリ以下に次のようなファイル群が生成されます。 デプロイ gatsby buildでファイルを用意しましたが、それだけではインターネットに公開したことにはなりません。どこかのサーバーにホスティングする必要があります。この「サーバーにファイルを配置する作業」をデプロイと呼んでいます。デプロイは日本語訳として「配置」になっていますが、個人的には「反映」の方がしっくりときています。 サーバーは自分で用意することも出来るのですが、今回はNetlifyというサービスでホスティングしてもらいます。Netlifyは静的サイトのホスティングに特化したサービスです。登録も簡単で無料で利用出来る筆者の推しサービスです。 会員登録を済ませると、Netlifyにホスティングしているアプリケーション一覧に遷移するので、右上の「New site from Git」をクリックしましょう。 Gitをホスティングしているサービスの選択を要求されるので「GitHub」を選択（①）、デプロイしたいアプリケーションのリポジトリを選択しましょう。（②） ① ② リポジトリを選択するとBuild CommandとPublish directoryの入力欄に遷移します。 Build Commandはデプロイする際に実行して欲しいコマンドで、今回は「npm run build」を入力します。ビルド時に静的HTMLを生成するためです。 Publish directoryは公開するディレクトリです。「publish」を入力しましょう。これはnpm run buildで生成されるディレクトリです。 以上を入力するとデプロイの設定終了です。設定が完了するとアプリケーションにランダムに名前がつけられ（今回は「compassionate-benz-765c64」です。）、名前に対応するURLが生成されます。 ここでそのURLを入力すると、アプリケーションが無事デプロイされているはずです。

GatsbyJS v2 はじめの一歩 (1) 開発環境の立ち上げ、GatsbyJS v2 はじめの一歩 (2) 実際にページを作るの続編です。 ReactにおいてCSSを書くライブラリは多数存在しますが、筆者はCSS in JSというJSの中にCSSを書くアプローチなライブラリが比較的人気であると感じています。 その中でも勢いがあって、国内企業でも複数導入されているstyled-componentsというライブラリを使っていきます。 styled-componentsとは？ styled-componentはJSファイル中にCSSを書くライブラリの一つで、複数のスタイルを含めたコンポーネントを作るアプローチのライブラリです。 次の例ではTitle, Wrapperをコンポーネントと定義して、HogeComponentの中でそれらのコンポーネントを使っています。 import React from 'react'; import styled from 'styled-components'; const Title = styled.h1` font-size: 1.5em; text-align: center; color: palevioletred; `; const Wrapper = styled.section` padding: 4em; background: papayawhip; `; const HogeComponent = () => { <Wrapper> <Title>Hello World, this is my first styled component!</Title> </Wrapper> } 見てわかるとおり、JSファイルの中でCSSと同じ記法で書くことが出来ます。また、Titleというスタイルを含んだコンポーネントを見てわかるとおり、非常にリーダブルなコードになります。 css-modulesは？ Reactを書くときに考える必要があるのがCSSの扱いです。 Reactアプリケーションの雛形を作成するCLIツールのcreate-react-appで作られるReactアプリケーションではCSSとJSが別々のファイルになっていてJSからcssをimportする形式になっていました。 src/App.js import React, { Component } from 'react'; import './App.css'; class App extends Component { render() { return ( <div>hoge</div> ); } } export default App; これは一見良さそうに見えますが、ユーザーが見る際にすべてのコンポーネントのスタイルをまとめたCSSファイルが生成されます。この方針で作られたCSSをファイルが大きくなりがちで、ページの読み込みをブロッキングする要素になります。CSSファイルは何も考えずに読み込もうとすると、CSSファイルを読み込むまでページのレンダリングが開始されません。 styled-componentsはそのページに必要なスタイルをinline styleとして出力するので、CSSが読み込みをブロッキングすることがなく高速化の文脈で有利になります。 styled-componentsを導入する styled-components単体を導入するだけでは、ブラウザでしか動作しません。GatsbyJSではHTMLを生成する再にブラウザを通さない処理があるのでこのままではCSSのあたっていないHTMLが生成されてしまいます。 そこでGatsbyJS側でサーバーサイドでのみ動く処理を書く必要があるのですが、幸運なことにgatsby-plugin-styled-componentsというライブラリが用意されています。 gatsby/packages/gatsby-plugin-styled-components at master · gatsbyjs/gatsby pluginの利用方法 GatsbyJSにおけるプラグインはgatsby-node.jsやgatsby-ssr.js、gatsby-broswer.jsでGatsbyJSの挙動を変えてくれるパッケージのことをいいます。 今回のgatsby-plugin-styled-componentsはレンダリングするReactコンポーネントから必要なスタイルだけを抜き出しinline styleとして出力してくれる処理を担ってくれます。 https://next.gatsbyjs.org/packages/gatsby-plugin-styled-components プラグインのREADME.mdを見ながらインストールを進めていきましょう。まずは指示通りにパッケージのインストールをしましょう。 $ npm install --save gatsby-plugin-styled-components styled-components babel-plugin-styled-components プラグインを利用するにはgatsby-config.jsにプラグインの情報を入力する必要があります。今回は次のような処理をgatsby-config.jsに書き加えましょう。 gatsby-config.js module.exports = { siteMetadata: { title: 'Gatsby Default Starter', }, plugins: [ 'gatsby-plugin-react-helmet', { resolve: `gatsby-plugin-manifest`, options: { name: 'gatsby-starter-default', short_name: 'starter', start_url: '/', background_color: '#663399', theme_color: '#663399', display: 'minimal-ui', icon: 'src/images/gatsby-icon.png', // This path is relative to the root of the site. }, }, 'gatsby-plugin-offline' + 'gatsby-plugin-styled-components' ], } パッケージのインストール時には再度gatsby developの実行が必要です。gatsby developをctrl+cで一旦止めて再度実行しましょう。これでstyled-componentsを利用するための準備が整いました。 ここからは実際にスタイルを書いていきましょう。 実践styled-comopnents 基本的にはstyled-componentでコンポーネントを作ってReactをコンポーネントとして利用すれば大丈夫です。 src/App.js import React, { Component } from 'react'; import styled from 'styled' import './App.css'; const RedTitle = styled.div` color: red; font-size: 20px; ` class App extends Component { render() { return ( <RedTitle>hoge</RedTitle> ); } } export default App; ちゃんと反映されているかブラウザを開いて確認してみましょう。

GatsbyJS v2 はじめの一歩 (1) 開発環境の立ち上げの続編です。 ディレクトリの構成 前章ではgatsby developで開発環境を立ち上げました。 まずはディレクトリ構成を確認していきましょう。重要なファイル・ディレクトリのみ説明します。 - package.json - gatsby-node.js - gatsby-config.js - src/ - pages/ - components/ - public/ package.json Node.jsお馴染みのpackage.jsonです。プロジェクトが使用するnpmパッケージの依存関係や、各種コマンドを登録しておけるnpm scriptsなどに使用します。 gatsby-config.js サイトのメタデータ（タイトルなど）やGatsbyJSで使用するプラグインの設定などを記述するファイルです。後ほど詳しく解説します。 gatsby-node.js GatsbyJSのライフサイクルに処理を加えたい場合や、挙動を変えたい場合にしようするファイルです。動的にページを生成したい場合などもこのファイルに変更を加えます。このファイルに関しても後ほど詳しく解説します。 src/pages URLに対応するReactコンポーネントを定義するディレクトリです。 基本的にこのディレクトリが入り口になっていくので重要です。 yourdomain.com/はsrc/pages/index.js yourdomain.com/aboutはsrc/pages/about.js yourdomain.com/profile/snsはsrc/pages/profile/sns.js とURLの構成とディレクトリ構成が1体1に対応します。 gatsby-ssr.jsとgatsby-browser.jsに関しては入門のうちは触らないと思うので省略します。 public/ 公開ディレクトリです。GatsbyJSに関係なく公開したいファイル（faviconやlogoの画像ファイル）を置く場所です。 はじめの変更 ディレクトリ構成を抑えたところでよくわからないと思うので、開発環境を立ち上げた状態でファイルをいじってみましょう。 まずは http://localhost:8000 をブラウザで開いてそのページに対応する src/pages/index.js を開いてみましょう。 開いた状態で <p>Hi People</p> を消してみましょう。そうするとリロードなしで変更が反映されたと思います。GatsbyJSはファイルの変更であればリロードなしで変更の反映をやってくれます。ファイルの追加やリネームを行う場合はブラウザ側での手動リロードが必要になります。 src/pages/index.js import React from 'react' import { Link } from 'gatsby' import Layout from '../components/layout' const IndexPage = () => ( <Layout> <h1>Hi people</h1> <p>Welcome to your new Gatsby site.</p> <p>Now go build something great.</p> <Link to="/page-2/">Go to page 2</Link> </Layout> ) export default IndexPage 新しいページの追加 変更が反映されるところまで確認したら、次は新しいページを追加してみましょう。 src/pages ディレクトリ以下には index.js と page-2.js があるので以下のような page-3.js を追加してみましょう。 src/pages/page-3.js import React from 'react' import { Link } from 'gatsby' import Layout from '../components/layout' const IndexPage = () => ( <Layout> <h1>My First Component</h1> <Link to="/">Back to Home</Link> </Layout> ) export default IndexPage 追加後にブラウザで http://localhost:8000/page-3 を開いてみると新しいコンポーネントが反映されていると思います。 リンクを貼る /page-3 のページを追加しましたが、今はトップページからリンクが貼られていないのでアクセスできません。そこでリンクを貼っていきましょう。 GatsbyJSではリンクを作るためのLinkコンポーネントが提供されています。import { Link } from 'gatsby'で読み出します。 参考: GatsbyJS v1ではgatsby-linkのパケッケージから提供されていました。過去の情報を探すときに注意 それではsrc/pages/index.jsを編集してリンクを追加しましょう。 src/pages/index.js import React from 'react' import { Link } from 'gatsby' import Layout from '../components/layout' const IndexPage = () => ( <Layout> <h1>Hi people</h1> <p>Welcome to your new Gatsby site.</p> <p>Now go build something great.</p> <Link to="/page-2/">Go to page 2</Link> + <Link to="/page-3/">Go to page 3</Link> </Layout> ) export default IndexPage もう一度、http://localhost:8000 を開くと、「Go to page 3」というリンクが増えていると思います。 以上のようにGatsbyJSではディレクトリ構造とURL構造が連動しているので、ルーティング用のファイルなどは存在せずシンプルにプロジェクトを進めることができます。 ディレクトリ構造とURL構造が連動するのは、最近のフロントエンドの流れでNext.js(React)やNuxt.js(Vue)でも同様な仕組みが存在しています。 次の章ではstyled-componentsを使ってReactコンポーネントにスタイルを当てる説明をします。

本ブログでも使用されているReactによる静的サイトジェネレーターのGatsbyJSの入門記事です。 開発環境を整える GatsbyJSは静的サイトを生成するためにNode.jsを使用します。 また、プロジェクトの作成にはgatsby-cliというCLIツールを使うのでインストールしておきましょう。 TODO Node.jsをインストールする v6以上が最低要件ですが、v8以降であると書きやすいと思います。 Gatsby CLIをインストール npm install -g gatsby-cliを実行 Gatsbyのプロジェクトを作成 先程インストールしたgatsby-cliを使ってプロジェクトを作成します。gatsby-cliでは引数にGitHubのURLを渡すことで利用するテンプレートを変更することが出来ます。 GitHubのURLを渡さなかった場合、gatsby-starter-defaultという公式のテンプレートが使用されます。 ただし、2018/08/17現在ではGatsbyJS v1のデフォルトテンプレートが使用されてしまうため、明示的にv2の指定を加える必要があります。 $ gatsby new [project名] [GitHubのURL(optional)] 今回はproject名をhello-gatsbyとし、GitHubのURLとしてはgatsby-starter-defaultのv2を指定します。すると以下のようなコマンドを実行しましょう。 実行するとhello-gatsbyディレクトリが生成され、npm installを実行してくれます。 cdでディレクトリ移動し、開発環境を立ち上げるコマンドを実行しましょう。gatsby-cliが提供するgatsby develop`というコマンドで開発環境が立ち上がります。 $ gatsby new hello-gatsby https://github.com/gatsbyjs/gatsby-starter-default#v2 $ cd hello-gatsby $ gatsby develop 実行するとしばらく待ったのちに以下のような文字が出力されます。同じような出力が出れば成功したと考えてください。 出力された指示通りに http://localhost:8000 を開きましょう。以下のようなページが立ち上がっているはずです。 これでプロジェクトの作成から、開発環境の立ち上げまでが成功しました。 次章では、開発環境でCSSやページの追加を行っていきます。 TODO gatsby new hello-gatsby https://github.com/gatsbyjs/gatsby-starter-default#v2 cd hello-gatsby gatsby develop http://localhost:8000 を開きましょう 技術書展でGatsbyJS本を書く予定で、本記事は下書き的な扱いになります。頒布するものはブログ記事をまとめ、より体系的な構成にするつもりです。

この記事は既に内容が古くなっています。最新の内容は「Netlify Functions + TypeScriptのボイラープレートを作った」をご覧ください 先日Netlify Functionsの入門記事を書きましたが、TypeScriptで書きたかったので書けるようにしました。 Netlify公式がホスティングしているFunctions用のCLIであるnetlify-lambdaをフォークしてnpmで公開しました。 https://github.com/mottox2/netlify-lambda https://www.npmjs.com/package/@mottox2/netlify-lambda 使用方法 $ npm install --save-dev @mottox2/netlify-lambda でパッケージをインストール。 package.jsonに以下の様なnpm scriptsを定義しておきましょう。 { "scripts": { "serve": "netlify-lambda serve src/", "build": "netlify-lambda build src/" } } あとはnpm run buildなどで実行すれば動くはずです。 実際に利用しているリポジトリも参考にどうぞ！ 何をやっているか Netlify Functionsの中身はAWS lambdaなのでnode 6.10環境用にビルドすればよさそうな雰囲気を感じました。 netlify-lambdaの役割はNetlify特有の環境変数等の設定を読み込みWebpackを走らせるというライブラリになっていました。 なので、ビルド結果はnode6.10向けにしつつTypeScriptが動けばよいので、Webpackのbabel-loaderでbabel7 + baebl-preset-typescriptを読み込めばいけそうでした。目論見通り動いたので、それを名前空間(@mottox2)を付けてnpmに公開した次第です。 一応元のリポジトリに対してbabel7のプルリクエストは投げているのですが、ここ数ヶ月動きがないのであまり期待していません。 快適なNetlify生活をお送りください。

主にフロントエンドでアプリケーションを書いている人向けの記事です。 また、AWS LambdaやGCP Cloud funtionsは知ってるけど敷居が高く感じていて、まだ実際にやったことのない人もこの記事の対象読者です。 あらすじ FaaSを使う理由 任意のURLを生成して、そのURLにアクセスすると特定の処理が走るような仕組みをFaaS（Function as a Service）といいます。 何が嬉しいかというと開発者はサーバーを意識することなく特定の処理を実行する環境を手に入れることができるという点です。常にサーバーを立ち上げておく必要がないので、たいてい安く使えますし、サーバーの状態管理が必要なく気にすることも少ないです。 サーバーを意識することが少ないので、普段サーバーサイドになれていないフロントエンドな人でも始めやすいし、保守を必要としないので趣味プロダクトで使いやすいという性質も持っています。 とはいえ企業のプロダクトでも取り入れられていて、日経電子版とCookpadの例を載せておきます。 （どちらかといえば、FaaSというよりはサーバーレスアーキテクチャでlambdaが使われています。ただし趣味プロダクトと業務プロダクトではかなりの断絶があるように感じています。） 日経電子版の例: 紙面ビューアーを支える サーバーレスアーキテクチャ / serverless architecture supports Nikkei’s paper viewer - Speaker Deck Cookpad社の技術ブログ: AWS Lambda@Edge で画像をリアルタイムにリサイズ＆WebP形式へ変換する - クックパッド開発者ブログ Netlify functionsとは Netlify上でAWSのFaaSであるlambdaを利用できるようにしたものです。AWSのアカウントは不要でNetlifyのアカウントがあれば利用することが出来ます。 AWS LambdaやGCP Cloud funtionsは利用するのにクレジットカードの登録が必要で、始める敷居も高かったのですがNetlify functionsの場合、月120,000回の起動分は無料で使えるので非常に始めやすいという性質も持っています。 それでは、気軽に利用できるFaaSであるNetlify functionsを使ってFaaSを始めてみましょう！ 本編 前提として、Netlifyのアカウントは持っているものとします。 リポジトリの作成 GitHubでリポジトリを作成しましょう。今回はhello-functionsというリポジトリにします。 $ mkdir hello-functions $ cd hello-functions $ git init $ git commit -m 'Init' --allow-empty $ git remote add origin [GitHubのリポジトリのURL] $ git push -u origin master 実行する関数を書く 今回は入門のために hello world という文字列を返すようにします。 第3引数として渡ってくるcallback関数を実行することでレスポンスの内容をいじることができます。 functions/hello.js exports.handler = function(event, context, callback) { console.log('Hello Netlify Functions.') callback(null, { statusCode: 200, body: "Hello, World" }); } functionsの利用するディレクトリを指定する Netlifyの設定はGUIで操作できますが、リポジトリ上にnetlify.tomlというファイルを置くことでも変更可能です。今回はnetlify.tomlを利用します。以下の内容でリポジトリのルートディレクトリに置きましょう。 [build] functions = "functions" ``` ### Netlifyでリポジトリを紐づけます Netlifyへの会員登録を行っていない型はGitHubアカウントがあれば簡単に登録できます。 登録済みの方は「New site from Git」=> 「GitHub」とクリックしていくとリポジトリ選択画面が現れるので、今回作ったリポジトリを選択しましょう。 Basic build settingsの画面が現れますが、今回に関してはBuild command、Publish directoryは空でも大丈夫です。`Deploy Site`をクリックしましょう。 これでNetlify連携は完了です。 これ以降、GitHubにpushされたタイミングでNetlifyに変更が反映されるようになります。 ### 動作確認 <img width="1033" alt="スクリーンショット_2018-07-30_11_03_18-2.png (173.8 kB)" src="https://img.esa.io/uploads/production/attachments/6967/2018/08/01/4651/59fc088b-9d75-4603-bb2d-0ab4e421414b.png"> 上部の`Functions`を押すとそのリポジトリのFunctionの一覧が現れるので`hello.js`を選択します。 <img width="1088" alt="スクリーンショット_2018-07-30_11_04_42-2.png (134.3 kB)" src="https://img.esa.io/uploads/production/attachments/6967/2018/08/01/4651/e44f15ee-751c-4fda-b847-ff64430ac8e6.png"> 遷移先のページの上部にEndpointという項目がありそのURLが、Functionsの起動URLになります。 そのURLにアクセスしてみると`Hello, World`という結果が返ってくると思います。これで無事に動作していることがわかりました。 ## Next Step: なにに使っていけばいいの？ Hello Worldが表示されるだけだと何のメリットも感じられませんね。実際には、この関数の中の処理を充実させていくことになります。 多分、応用編も書いていきます。 ## 宣伝 技術書典5でNetlifyに関する本を書く予定です。Netlify Functionsを利用したSlack appの作成方法に関しても書こうと思っています。 興味のある人は[僕のTwitter](https://twitter.com/mottox2)をフォローしていただけると嬉しいです。

「Deploy to Netlify」ボタンを設置するためにDeploy to Netlify Buttonを読んでざっくりまとめつつ補足を加えました。 「Deploy to Netlify」ボタンはNetlifyに簡単にリポジトリの内容をデプロイできるボタンのこと 挙動としては指定されたGitHubリポジトリと同じものが自分のリポジトリとして作成されて、そのリポジトリがNetlify連携された状態になる。（ForkではなくCopy） ステップスクショGitHubと連携する画面。GitHubのRepository nameを決める連携が完了。すぐデプロイされます。 ボタンの設置 ボタン設置のHTML例 <!-- HTML snippet --> <a href="https://app.netlify.com/start/deploy?repository=https://github.com/netlify/netlify-statuskit"> <img src="https://www.netlify.com/img/deploy/button.svg" title="Deploy to Netlify"> </a> https://www.netlify.com/img/deploy/button.svgがボタンの見た目のSVG https://app.netlify.com/start/deploy?repository=https://github.com/netlify/netlify-statuskitのようにGitHubのURLをrepositoryパラメータに乗せたリンクを踏むことでデプロイ設定ページに遷移する テンプレートの設定 Netlifyはリポジトリごとにnetlify.tomlという設定ファイルを持っていて挙動をコントロールすることができる。参考: netlify.toml Reference [template.environment] SECRET_TOKEN = "change me for your secret token" CUSTOM_LOGO = "set the url to your custom logo here" [template.environment]セクションに項目を追加するとデプロイ時に、環境変数のテキストフィールドが現れる。 Repository nameを入力するステップにフィールドが追加される

ここ数年間「自宅でグローバルに活躍する」写真でSNS等で活動していたのですが、先日わかばちゃんシリーズの湊川あいさんにアイコンを書いてもらいました。 なんでアイコンを変えたのか？なんで湊川あいさんに頼んだのか？湊川さんに頼むとなぜいいのかをブログに書き残しておきます。 依頼までの経緯 もともとのアイコンは「自宅でグローバルに活躍する」という写真です。 実際に今は自宅で仕事しているので間違ってはないのですが、ブログやLTをしていることを踏まえるともう少しマイルドなアイコンにしたいと考えていました。 以前から湊川あいさんの書いたてぃーびーさん（エンパワーメントの人）のアイコンを見て気になっていたのですが、ある日VTRyoさんのツイートがリツイートが僕のタイムラインに流れてきました。 やってみたいなとツイートしたところもんりぃさん（キッズスターの人）のひと押しもあり湊川さんにアイコンを依頼することを決めました。 なぜ湊川さんにお願いしたのか？ 経緯で説明したようにてぃーびーさんやもんりぃさんのアイコンを見て気になっていたのもあるのですが、もう一つ決め手があって、湊川さんが初心者向けの技術マンガを書いていることです 湊川さんは「わかばちゃんと学ぶ Webサイト制作の基本」、「わかばちゃんと学ぶ Git使い方入門」など初心者向けのマンガ解説本を書いています。 そういった人に依頼をしたときのUXを体験できる機会はめったにありません。 湊川さんから学んだこと ということで湊川あいさんとのやり取りで気になったポイントを書いておきます。これであなたも湊川さんにアイコンを頼みたくなるはずです。 すごい雑で、良くないクライアント感はあるんですけどあまり要件が決まってませんでした。その中でもDMで僕の要望を汲み取りつつ要件を固めていってくれました。 このへんのやり取りでGoogleAnalyticsやDockerなどの技術を調べながら伝え方を考えている湊川さんの能力の高さを実感することが出来ました。ふわっとした要望の中で光るヒアリングの美味さといったところでしょうか。 自分もこのぐらいスムーズにやり取りできるようになりたいものです… やり取りの中でも、 よくある質問をScrapboxにまとめてて、コミュニケーションの回数を無駄に増やさない工夫をしている。 差し戻しがないように、ここぞというポイントで確認してもらえる +αの提案をしてくれる。 あたりはすぐにでも自分のやり取りの中でも活かせると思いました。 できた新アイコン！！ 実は「つのぶえデザイン」という屋号でフリーランス活動をしているのですが、その角笛要素いれてもらったのがお気に入りポイントです。 これからはGitHubも含めてこのアイコンで活動していこうと思います。湊川さん、ありがとうございました！ 新アイコンになって心機一転！更にやっていきの気持ちをもっていくぞ！

Google App Script使っていますか？僕も最近ちゃんとやってみました。 ちゃんとやってみた結果ある程度、自分の中で開発手法にケリがついたのでブログにまとめていこうと思います。 WebpackやBabelを使わず、GitHubで管理しつつローカルのエディタで開発する方法です。 普通に使った時の様子 Google Apps ScriptはGoogle Drive上で他のGoogleサービスと連携したり、cronライクな定期実行タスクを実行できるプログラミング環境です。JavaScriptライクな記法で書けます。 例えば、一日ごとに外部APIを叩いてSlackに通知。スプレッドシートに記録をとるような目的で使われることが多いです。 ただ、手頃に触れる環境ではある分、普段の開発になれたWebエンジニア的には、「もう少しコード管理をしたい」・「コードレビューをしたい」・「普段のエディタ」で開発したいという欲求が生まれると思います。 何を達成したいか ここで快適に開発するために達成したいことを整理していきます。 Google Apps Scriptのエディタが辛い。補完が中途半端。 GitHubでソースコードの管理をしたい。 webpack, babelを使いたくない。 [補足] なぜwebpack, babelを使いたくないのか **Google Driveのスクリプトエディタで実行可能な形式を保つためです。**確かに今どきの開発手法を採用すれば開発効率も上がるとは思いますが、GASに関してはGAS特有の挙動が多く実行するには、スクリプトエディタを経由し実行することになります。 ここで何らかの前処理を行っている場合、スクリプトエディタ上で編集したものをローカルで書き直す作業が発生します。実行可能な形式で書いておけば後述のclasp pullというコマンドを入力することで変更をそのままローカルのファイルに反映することができます。 やること Clasp CLIでGitHubでの管理を実現 google/claspはGoogle製のApps Scriptをローカルで開発するためのCLIツールです。これを使うことでローカルで開発で、GitHubなどでリポジトリ管理を行うことができます。 claspを使い、Google Apps Scriptプロジェクトをgitでバージョン管理する - Qiitaの記事がわかりやすかったです。 npm i @google/clasp -g で@google/claspをインストールするとclaspコマンドが使えるようになります。 最初にclasp loginを行うとブラウザでGoogleログインの画面が立ち上がり、ログインすると~/.clasprc.jsonが生成されます。 プロジェクトの作成 clasp create [scriptTitle]でGASプロジェクトが作成されます。 その際に、.clasp.jsonとappsscript.jsonが生成されます。.clasp.jsonにはscriptIdが記録され、‘appscript.json’にはタイムゾーンや権限などのメタ情報が記録されます。  pullとpush clasp push でGoogle DriveにあるApps Scriptに反映、clasp pullでローカルに持ってくることができます。ローカルである程度変更してclasp push; clasp openを行いスクリプトエディタで試し、スクリプトエディタ側で変更した場合はclasp pullをする流れになります。 TypeScriptの補完の恩恵を受ける webpackやbabelを使わないといいましたが、GASをそのままで書くのはMっ気のある行為だと感じました。実はVSCodeではtsconfig.jsonをおいておけばjsファイルでもTSの恩恵を受けることができます。 （もちろんjsファイル内で型を書くことはできません。） ただ、標準ではGASの型に対応していないので、npm install --save-dev @types/google-apps-scriptで型定義ファイルをダウンロードしておきます。tsconfigは適当に用意しておけば補完が有効になるはずです。 tsconfig.json { "compilerOptions": { "module": "commonjs", "outDir": "./build", "rootDir": ".", "alwaysStrict": true, "inlineSourceMap": true, "noEmitOnError": true, "noImplicitAny": true, "noImplicitReturns": true, "noImplicitThis": true, "pretty": true, "strictNullChecks": true } } 素のJavaScriptプロジェクトにtsconfig.jsonを置いといてVSCodeの便利さを享受するの記事を見てできることに気がつきました。 まとめ claspとTypeScriptの型定義ファイルを利用することでそれなりに楽をしつつGoogle Apps Scriptの開発を行うことができました。 今回は小規模なGASを前提にしましたが、もう少し大きなプロジェクトの場合は全面的にTypeScriptを採用する・Babelを利用するなどの選択肢が見えてくると思います。要は適材適所なので各位最強の開発手法を頑張って探してください。 ちなみによくある感じのSlackと連携する勤怠Bot作ってました https://github.com/mottox2/gas-kintai

Next.jsのアプリケーションを本番にリリースした そういえば、Next.js本番投入しました。嬉しい。 pic.twitter.com/33nsBtapbV— もっとx2 (@mottox2) July 11, 2018 - GAE nodejs SEで運用を始めました。 - SSRのロジックをフレームワークに寄せることで考えることが減って嬉しくなれる。 - 考えることは減らして、世界中のNext.jsユーザーで考えてもらうみたいな方が間違いなくよくなると思う。 - ドキュメントが見づらい。JSXのシンタックスハイライト入れたPRを投げようと思ったけど、うまく当たらなくて困ってる。 eslint-scopeにマルウェアが入った問題 Postmortem for Malicious Packages Published on July 12th, 2018 - ESLint - Pluggable JavaScript linter あったこと eslint-scopeにマルウェアが混入されて、npm installを行うとnpmの認証トークンを含む.npmrcの中身を外部に送信してしまう問題。 eslint-scopeがeslintやwebpackなどに依存するパッケージであったことから、影響範囲が広そう 既にnpmによる対応として、認証トークンは無効化された NPMのeslint-scopeハッキングとNPM全トークン無効化 - Qiitaが詳しい npmのエコシステムとして、いろんなパッケージに依存すること前提になっているので、一つのパッケージに悪意の持ったコードが入ると多くのパッケージに影響がある。 left-pad事件を思い出した。 GastbyのJSビルドが早くなりそう [v2] Hulksmash build slowdowns on larger sites by KyleAMathews · Pull Request #6226 · gatsbyjs/gatsby Add multi-process HTML rendering support to Gatsby by KyleAMathews · Pull Request #6417 · gatsbyjs/gatsby マルチスレッドとファイルシステムのキャッシュ周りの改善で早くなってそうな雰囲気を感じる gatsby@2.0.0-beta.30あたりでリリースされている様子なので、今開発中のサイトで試す予定。

5月頭から@kakakakakkuさんの元でブログメンティをやっていたのですが、6月末に卒業しました。 振り返れば2ヶ月前にはブログがない状態から、今や20記事以上公開されているブログを運営するところまで来ました。 以前の記事でブログメンティになった経緯は書きましたが、それからもう一ヶ月ブログを続けて、その間にLTを2本、OSSのコントリビュートができたり、ブログからのお仕事の問い合わせイベントが発生しました。 とりあえず、ブログメンティをやったらめちゃくちゃ世界が変わったので、メンティを通して学んだこととどう世界が変わったのか書いていきます。 メンティを通して学んだこと ネタ出しの仕方とアウトプットの継続 メンティを初めたタイミングでブログネタを20個上げる宿題が出てブレストのような感じでネタを出したり、OSSにコントリビュートしてみたり、LT駆動でネタ出しするなど、自分では思いつきそうにないネタ出しの方法を学びました。 ネタが決まっていればブログは書けたも同然みたいなところはあると思うので、アウトプットを継続するヒントを得ることができました。 昔、B向けのSaaSのデザイナーをやっていたときに「人間はめんどくさがりなので工夫をしないとサボる」という知見を得たのですが、ブログでもそうなので、積極的に工夫をしていくべきです。 ブログが続かない人は、自分が悪いんじゃなくて生物学的に難しいということを認識して工夫をしていくといいと思います。ネタ出しは工夫の中でもそれなりにコストが低い方法だと思います。 他の人に感謝すること 自分が嬉しいことは他人も嬉しい．自分の問題を解決してくれた記事に感謝の気持ちを！ TwitterのDMで頂いた言葉です。僕もブログをシェアされたりコメントつけてもらうと嬉しいので、シェアしたりコメントしたりします。発言すると批判の方が目立ってしまうのですが、肯定的な意見も積極的に発していきたいですね。 自分も助けられた分、他者の問題を解決出来るアウトプットをしていけるといいと思いました。 そのほか細かいこと 最初にGoogle AnalyticsとSearch Consoleの設定を済ます、LT後のイベントページにスライドをアップする。しっかりシェアボタンを置く、LT後にイベントページにスライドをアップするなどしっかりアウトプットを届けるといったこと。 ホットエントリー向けの記事と検索流入向けの記事は違うので伸びなくてもめげる必要はないこと。 などいろんなアドバイスをDMでもらっていました。 他のメンティ視点の記事 僕以外にもブログメンティで振り返りをしている記事があるので、そちらの方も見てもらえれば別視点でのブログメンティを知ることが出来ると思います。 3ヶ月続けた kakakakakku ブログメンティーを卒業しました - よしたく blog @kakakakakku さんのブログメンタリングを3ヶ月間受けて卒業した @kakakakakku さんに２ヶ月間ブログメンターをしてもらった知見まとめ - t-miliya612のブログ ブログメンターをしてもらった振り返り | dvg-179 何が変わったのか？ ブログを始めることができた 以前はQiitaやnoteに記事を散発的に投稿していたが、ブログを初めて継続的にアウトプットしていくようになったし、フロントエンドエンジニアとしてブログという実験場を手に入れることができました。 また、その中ではてブのホットエントリーになる記事も出てきて一日最高670Userという人に見てもらうことができました。ブログプラットフォームのような場所ではなく完全に独立したサイトでアクセスを集めるのが不利な状況で多少がんばれたのではないかと思っています。 OSSのコントリビュートをするようになった ブログメンティになる前にGatsbyJSのLTをしていたのですが、kakakakakkuさんにコントリビュートしてブログネタにしてみたら？という提案を頂きコントリビュートを初めました。 ちょうどそのタイミングでv2のalpha版の時期だったため非常に多くのコントリビュートネタがあり、v2のexample対応やその対応の中で見つけたバグ修正、新し いドキュメントの不備の修正など多くのコントリビュートを行うことができました。 https://github.com/gatsbyjs/gatsby/graphs/contributors なんだかんだ800人以上コントリビューターがいる中で14番目にコントリビュートしている人になりました。 仕事の質が上がった 4月に触り始めたGatsbyJSに関しては5月に本番アプリケーションとして1つ、開発中のものが1つお仕事で触ることができました。また5月に始めたNext.jsも既に本番に出すなど、ブログでアウトプットしている内容に関して仕事に繋がり始めました。 お仕事中に考えたこともブログで言語化することで、思考の質もあがったり周囲への共有の質も上がったと思います。ブログは一見人にTakeしているように見えて、自分へのGiveもある行為なんだと強く感じます。 フリーランスの不安との付き合い方がうまくなった フリーランスとして次のような不安があった。 出来ることをやり続けて、相対的に弱くなってしまう不安 見当違いなことをやっているのではないかという不安 ブログやLTのアウトプットをすることで、今までやったことのないことを始める切っ掛けもでき、Twitterやはてブのコメント、LT後の懇親会などでのフィードバックを得ることができました。おかげでこれらの不安は少しずつ弱くなってきている気がします。 これからもアウトプットしていくぞ ブログを初めてアウトプットを始めることで予想もつかない変化が起きた。2018年は「アウトプットをしていく」という目標を立てたが、半年時点でかなり目標達成に近い状態になったと思うので気を抜かず残り半年しっかりアウトプットしていきます。 kakakakakkuさん2ヶ月間、本当にありがとうございます！ブログメンティは卒業しますがこれからもアウトプット続けていきます。 とりあえず技術書典5のサークル申し込みは済ませましたので、次は技術書典でのアウトプットを大きな目標にしていこうと思います。 ブログメンティの募集は定期的にやられているので、機会を得たいと思うなら@kakakakakkuさんのTwitterを是非フォローしておきましょう！