- サーバーサイドの人にも伝えたいJAM Stackと静的サイトのイマ
aircloset社で行われたWeb界隈LT会で話した「サーバーサイドの人にも伝えたいJAM Stackと静的サイトのイマ」です。
静的サイトと動的サイト
静的サイト
早くて、落ちないし、セキュリティで心配することも少ないけど、自由度低いよね。
動的サイト
運用面倒。スケーラビリティ的に不利
攻撃される。
速度的に不利。
静的サイトジェネレータ
動的に静的サイトを生成するジェネレータ
基本的にGitHubのpushと連動してビルドするような感じ
時代は変わっている
monolithic services => micro services
FTP => GitHub中心の開発環境の変化
PC => スマホシフト
GitHubを中心とした開発者の環境の変化
ソースコード管理がGitHubになり、CIと連携してデプロイしたりすることが一般的に。
GitHub Pagesで簡単にサイトが公開できたり、GitHubと連携して静的サイトを公開できるNetlifyの登場
ビルドコマンドの指定や、Global CDN、PR Previewなどがデフォルトで使える。神サービス。
スマホデバイスによる速度の重要性の高まり
3Gから4Gになったとはいえ、都市部から離れると3Gや劣悪な通信環境が存在する。
Googleのアルゴリズムで遅いサイトはランクが下がりそう
より早くレスポンスを返して、通信量を抑える必要性が高まっている。
動的サイトはサーバーサイドでの処理の分速度的に不利。
Micro Services志向な思想
Micro Serviceが一般的になり、サーバーサイドの分離はともかく、Stipe（課金）やContentful（CMS）、Sentry（エラー収集）などの外部サービスとAPIを経由して利用する方法が一般化した（はず）。
backendは別サービスのAPIを使ったり、自前で実装するなりして、フロントエンドだけ別プロジェクトに切り出すのも自然。
これらの変化に対応するように静的サイトジェネレータも変わった。
以前の静的サイトジェネレータ
基本的にGitHub上にあるMarkdownを元に静的ページを生成
直近の静的サイトジェネレータ
APIを叩いてそのデータを元に静的ページを生成
静的サイトよさそうでは？
なんと言ってもメンテナンスフリーになるなら最高だよね。
ここで主要なジェネレータを確認
Jekyll Ruby
Hugo Golang
Next JS(React)
Gatsby JS(React)
Nuxt JS(Vue)
=> JavaScriptを選ぶべき
なぜJavaScriptのジェネレータを選択するのか？
Serverで生成したHTMLをJSでいじるのはそろそろ辞めたい。
APIを叩いてViewに表示する処理がJSで完結する。
考えることが増えないままSPAにできる
フロントエンドの資産である開発環境が便利。
ビルド環境を整えるのにNodeだけ用意すればよい。
JAM Stack
これらの
JavaScript
APIs
Markup
の要素を満たすスタックをJamStackという。
各フレームワークの紹介
Next.js
SSR付きのReactアプリケーション用のフレームワーク。
routerやSSRに関してレールを敷いてくれる。
Nuxt.js
@potato4d氏が日本に流行らせたVueのフレームワーク。
Next.jsインスパイア系のフレームワークだったけど、フルスタック方面に向かっている。
設定より規約なフレームワークという印象。フロントエンドのRails（個人の見解です）
GatsbyJS
Reactで静的サイトを書くためのフレームワーク
とにかく普通に書けば早くなるように設計されている。
複数のデータソースを扱いやすい設計になっている。
よくある質問
問い合わせフォームとかは？
Google FormとかNetlify Form、他フォーム系のSaaS
ビルド速度はどうなの？
静的ページをビルドするのはそんなに数分あればいける。生成処理は最適化が行われ続けているが、APIを叩くのがネックになりやすい。
React, Vueって考えることが多そう。
Next.js, GatsbyJS, Nuxt.jsを選べば、ある程度のレールが敷かれているためライブラリ選定問題と直面することは少ない。
WordPressを静的サイト化したい
わかる。既存のものはWordPressのまま静的HTML化するプラグインとかでごまかすのがよし。普通に既存の要件を満たそうとするとめちゃくちゃしんどい。
新規のものはWordPressではなく、Headless CMSを採用するとよさそう。
Next.js、Nuxt.js、Gatsbyの使い分け
SPAにする必要がない・更新頻度が高くないのであればGatsby。SPAにする場合でReactならNext.js、VueならNuxt.js。具体的にCGMとかだとNext.js、Nuxt.jsにする。Nuxt.jsの方が万人向けだと思う。
APIに利用制限がある場合、静的サイト化する必要があるのでGatsbyを選ぶ気がする。
One More Thing
Youのサイト、SPAでもよくね？
基本的にSPAも静的サイトと言って良い。
PrebuildではないのでJAM Stackとは呼べないが、より構築が簡単になるはず。
<html>
<div id='app'></div>
<script src='app.js'/> <!-- #appに対してSPAを展開するJS -->
</html>
SSRとか静的化の話をしているのは、
Googleがちゃんとクローリングしてくれるか不安
ソーシャルメディアにシェアされたときのOGP情報
の要件をSPAでは満たせなかったから
Netlify Prerendering
Netlifyがprerenderingをサポート
bot向けにJSでレンダリングした結果を返してくれる。
ホスティングサービスについたのでシームレスに設定可能
以前からもprerender.ioというサービスもあったが、設定がめんどくさそうであまり流行っていない印象
例: SmartDrive
takenorip先生のSmartDrive
どんどん静的サイトでできることが広がっている。
運用レスなサービス作っていこうぜ。
2018/07/06 - Roppongi.js #4でYoga LayoutのLTしてきた
時間配分で大失敗した回。反省しかない。
6/26（火）にDMM社で行われたRoppongi.js #4でYoga LayoutについてLTしてきました。
スライド
https://speakerdeck.com/mottox2/yoga-with-sketch
Yoga Layoutとは？
Yoga LayoutはFacebookがOSSとして公開しているクロスプラットフォームのレイアウトエンジンです。
あのReact Nativeのレイアウト計算に用いられているライブラリになっていて、Flexible Box Layout (like Flexbox)ベースなAPIを用意しています。
なお挙動としてはYogaのPlaygroundで確認できるので、触ってみると意外と出来がいいことに気づくと思う。
今回はnpmで提供されているyoga-layoutを使ったものを採用した。割とシンプルなAPIなので中を見ていくのも良いと思う。webassemblyな箇所もあって新鮮さも味わえるはず。
デモでつくったJSON to Sketch.appについて
mottox2/json-sketchapp: Sketch Plugin: Convert JSON file to Sketch file
JSONからSketchファイルを作るという、用途不明なデモアプリ。Real Worldで使われる想定はなく、ただflexな感じのAPIを使っていい感じにファイルに落とし込めるというデモ。
このJSONを使った結果例
{
"name": "root",
"width": 375,
"height": 667,
"children": [{
"name": "Top Bars",
"height": "auto",
"children": [{
"name": "Status Bar",
"height": 24,
"backgroundColor": "#E8E8E8"
},
{
"name": "App Bar",
"height": 56,
"backgroundColor": "#FFFFFF"
}
]
},
{
"name": "Body",
"height": 300,
"flexGrow": 1,
"backgroundColor": "#F5F5F5"
},
{
"name": "Bottom Navigation",
"height": 56,
"backgroundColor": "#6202EE",
"flexDirection": "row",
"children": [{
"name": "Navigation Item",
"width": 56,
"backgroundColor": "white",
"text": "Nav1"
},
{
"name": "Navigation Item",
"width": 56,
"backgroundColor": "#40009D"
}
]
}
]
}
何に応用できそうか
PowerPoint, Excel、図面系などのファイルをプログラムで作ろうとすると自前でレイアウト計算をする必要があるがYogaを使ってレイアウト計算をお任せすることができる。
PowerPointファイルを作るサービス開発をお手伝いしているので、もしかしたらそこで使うかもしれない。
また入力もJSONだけじゃなくJSX、YAMLなどのフォーマットも選べるので、クロスプラットフォームのComponentDSLみたいなこともできるかもしれない。
時間配分に失敗しすぎてとてもつらかったです。5分LTでは自己紹介を最後にします。あとデモは厳しい。
2018/06/29 - 先週のWebフロントエンド(6/18) - React Nativeとmizchi氏周辺の動きが面白そう
スランプに陥ってた。
自分が手を動かすより人が手を動かした結果を見ていた。
ReactNativeのレイアウトエンジンのYogaを触り始めた。
LTネタ用として。
React Nativeの暗めな話を聞く中で興味を持った。
Flexible box layoutの座標計算をしてくれる
JSX to pptx（誰得?）みたいなのは作りそうな感覚はある。
gatsbyjs.orgでhuge thanksされた。
GatsbyJSのv2 exampleをひたすら書いていたら Life After Layouts | GatsbyJSでhuge thanksされた。嬉しい。
サンプルコードはコピペされやすいので、真剣に書かないと永遠にクソコードが残ってしまう可能性があって怖いw
VSCodeのデバッグ機能がなかなか使いやすかった
node inspectより使いやすかった。replって何度も打ってたのが馬鹿らしくなった。
Visual Studio CodeでNode.jsのデバッグをする | 株式会社ビヨンド
AirBnbがReact Native開発から撤退する件
react-native-jp/react-native-at-airbnb-jp-translationで日本語訳が公開されている。感謝しかない。
やっぱりネイティブエンジニアが採用できる環境だと、並列で勧めていくのが難しそうだなと感じた。
ネイティブエンジニアが採用できない、しにくい環境であればReact Nativeは十分選択肢に入ってくるのでは？
mizchi氏のnext-editorのコードが公開された
mizchi/next-editor: Standalone Git Editor on Browser
https://nervous-kilby-73c9b0.netlify.com/
gitと密に連携したWeb上で完結するIDE。Twitterを見ている限りchromebookで開発を完結させるのがモチベーションぽい。
TypeScript + React + Redux + Atomic DesignのSPA。Netlifyにデプロイされている。
Service WorkerにはWorkboxを使っている。
ReduxでStoreの管理をしつつgitとfilesystemの操作はCQRSで書かれている。
2018年の先進的フロントエンドって感じでおもろい。
jvilk/BrowserFS: BrowserFS is an in-browser filesystem that emulates the Node JS filesystem API and supports storing and retrieving files from various backends.でbrowser上でファイルシステムを扱っている？魔法感がある
babel触ってたらASTにも興味が出てきた
社内勉強会TechLunchで”JavaScript ASTことはじめ”という発表をしました - Medley Developer Blog
↑の記事でAST Exploreを知って素晴らしいってなった。
2018/06/27 - babel7で@babel/node(旧babel-node)を使う
最近はGatsbyJS v2を触っていることもあり、まだbeta版なbabel7を使うことが多くなってきた。
Babel 7 リリースプレビュー - Qiitaで取り上げられているように、スコープ付きのパッケージ名に変更されているのが大きな変更でパッケージ名の対応がよくわからず30分ぐらい悩んでしまった。
@babel/node（babel-node）とは？
babel-nodeはbabelした結果に対してnodeしてくれるもの（という認識）
適当にnodeを書きたいときに非常に便利。
v6まではbabel-nodeをインストールしてCLIとして実行するだけで良かった。
使い方
1 パッケージのインストール
$ yarn add @babel/core @babel/env @babel/node
2 適当に.babelrcを書く。
（babel7ではbabel.config.jsを書くのが推奨されてそうな雰囲気を感じる）
{
"presets": ["@babel/preset-env"]
}
3 適当にnpm scriptsとして定義
package.json
{
"scripts": {
"start": "babel-node src/index.js"
}
}
4 実行
$ yarn start
公式のDocumentを読むのが一番
What is Babel? · Babel でnext版(v7)のドキュメントが読めるのでこのあたりに目を通しておくのがよさそう。
特にUpgrade to Babel 7 · Babelを見るとどんな変更が行われたのが読めるので良い。
2018/06/21 - 6/11週のフロントエンド俺 - react-poseとGAE Standard Environmentとか
次回があるかわからないけど、「今週のフロントエンド俺」。
react-poseによるアニメーション実装が楽
react-pose - npm
styled-componentsとの相性がいい
日本語情報は現時点で見つからなかった
雰囲気としてはこういうコードがかける。Posed | Pose
const Sidebar = posed.nav({
open: { x: '0%' },
closed: { x: '-100%' }
})
export default ({ isOpen }) => <Sidebar pose={isOpen ? 'open' : 'closed'} />
GatsbyJS v2のbetaリリース
Release beta version of v2 · Issue #5762 · gatsbyjs/gatsby
自分は引き続きv2のexampleを作りながら、バグを直したりしてる
GAE/nodejs SEを試した
Google App Engine Node.js Standard Environment Documentation | App Engine standard environment for Node.js docs | Google Cloud
FlexibleEnvironmentと比べるとデプロイが早い
再来週あたりにproductionをSEに載せ替えたい
app.yamlをちょっといじって試してみると思ったより動く。
[18/06/26 追記] gcloud components update を忘れているとapp.yamlのパースエラーが出ます。
こんな感じのエラー
No URLMap entries found in application configuration
diff
- env: flex
- runtime: nodejs
+ runtime: nodejs8
VueNative on ReactNative
vueでマルチプラットフォームアプリを制作できる。
Weexとはアプローチが違くて、ReactNativeを利用するアプローチ
dependencesやソースコード中にreactが普通に出てきて笑った
REQUのスタックを見てた
REQU - アメーバのスキルシェアサービス
DevToolsとかwebpackかましたソースコード見たところ次のようなスタック？
react (v16.2)
redux (with saga)
react-router (with react-router-config?)
かなりスタンダード
APIが以下のようなレスポンスを返してた
{
body: {},
meta: {}
}
2018/06/17 - GAE(nodejs|FE)でデプロイ中にbuildを含める方法
仕事でGAE Flexible EnvironmentにNodejsのアプリケーションをホスティングしています。その際、デフォルトの設定だとnpm install --productionが実行されるのでdevDependenciesのインストールはスキップされることに困っていました。
ちょっと前まで手元でビルドしてgcloud app deployを叩いており、さすがにイケてないなと思っていましたが、ついに解決しました。
まとめ
以下のようにgcp-buildをnpm scriptとして定義してあげるとデプロイ中にnpm run gcp-buildを行ってくれます。
package.json
{
"scripts": {
"build": "NODE_ENV=production webpack",
"gcp-build": "npm run build"
}
}
該当のDockerfile
nodejs-docker/Dockerfile.txt · GoogleCloudPlatform/nodejs-docker でhasBuildCommandがtrueだとnpm run gcp-buildを実行してくれる。
nodejs-docker/detect_setup.ts でpackgeJson.scriptsにgcp-buildが定義されていればhasBuildCommandがtrueになる。
nodejs-dockerリポジトリ
gcloud app deployを実行すると、Container Builderでイメージのビルドが行われている。nodejs-dockerはそのビルドに使われるDockerfileを保持するリポジトリ。
RailsもGCPで運用しており、GoogleCloudPlatform/ruby-dockerにDockerfileがあってトラブルがあったときはよくお世話になっています。
自前のDockerfileを使用する手もある
gcloud beta app gen-config --customでDockerfileを吐き出してくれて、app.yamlのruntime: customとすることで自分が作っているDockerfileを見てくれる。
あまりスタンダードなデプロイから離れたくなかったので今回の標準的な方法（？）を採用した。ただ、将来的にはGKEでk8s を動かす気がするのでDockerfileは自分で書くことになりそう。
正直ビルドプロセスをおまかせしたいからApp Engineを使っているのに、なんでソースコード見ることになるのか…
2018/06/12 - 情報共有ツールesa.ioをCMSとして使って1ヶ月運用してみた
このブログはesa.io（情報共有ツール）をソースにしています。API経由でとってきた記事データをGatsby（静的サイトジェネレーター）を使ってhtmlとして吐き出したものをホスティングしています。
この記事では情報共有ツールをCMSとして扱うメリットと使ってみて見えてきた欠点などについて書いていこうと思います。
仕組み
esa.ioの特定のディレクトリが更新された際に、WebhookでNetlifyに通知。
esa.io Webhook
GatsbyJS
gatsby-source-esa
NetlifyはWebhookを受けて、GithubのリポジトリのBuildタスクを実行し、HTMLを生成、そのままデプロイ
Netlify
ざっくり同じことを再現しようとするならmottox2/gatsby-starter-esaをベースに作ればいけます。（近日中にもっとわかりやすいものにしようと思っています。）
Merit1. 普段文章を書く場所から公開できる
普段、普通に使っていればesa.ioには文章やドキュメントを書き溜めているはずです。それを blog/ カテゴリに動かすだけでブログに記事が公開できるという仕組みをとっています。
これは、社内共有用に文章を書いたものを、少し変えればブログとして記事を公開できるようになっています。
通常、ブログを書こうとすると、noteやはてブ・WordPressなどのサービスを使うと思うのですが、そうなると「ブログを書こう」と強い意志を持たなければ、そのURLにすらたどり着くことはありません。
esa.ioなら、普段から書いていれば下書きがあるので、それを書くための気力さえあれば記事を公開できます。
つまり情報共有ツールがCMSとして機能することでブログ投稿のハードルが下がります。
Merit2. esa.ioの機能がまんま使える
エンジニアの技術ブログで採用されるデータソースはリポジトリ内のmdファイルが多いです。ですが、mdファイルを書くのにエディタを立ち上げますが、エディタは基本的にコードを書く場所であって、文章を書くのによいツールが揃っているとは限りません。（もちろんエディタの方がなれている人が多いでしょう）
しかし、esa.ioをCMSとして使うと、本来文章を書くために作られたツール一式がそのまま使えます。
例えば、タグ・カテゴリの補完やテンプレートなどの機能が備わっています。
タグの補完
テンプレート
しかもこれらのエディタは基本壊れず、運営によって自動的にアップデートされます。（何らかのアップデートによって）壊れたとしても運営の人が直してくれるでしょう。
コードエディタと違って、間違いなく文章を書くために作られたツールなので使いやすいです。
補足: 正直、textlintで文章チェックとかマークダウンを挿入する独自拡張を作りたくなる気持ちはあります。
Merit3. WIPの概念とAPIがよい
これはesa.io固有の話で、esa.ioにはWork in Progressの概念があり、WIPなドキュメントであることを簡単に示すことができます。
このブログではWIPなものは表示せず、Ship Itされたものだけブログに公開されるようにしています。WIPがあるので、雑に下書きを書いておいて気が向いたら本番に書くというお気楽運用ができています。
また、Webhhookも実装してくれているので、Ship Itされたら、ホスティングしているNetlifyでPOSTリクエストが飛んでHTMLをビルドという仕組みも簡単に実装できました。前の記事で書いていますが、esa.ioのプラグイン作成時間を込みで4時間ほどでこの仕組みを作っています。
Demerit. メタ情報を載せにくかった。
基本的に、esa.ioで記事に入力できる情報は次の4つでした。
カテゴリ(/区切りで入力できる)
タイトル
タグ(#から始めた部分がタグになる)
本文
最初はこの4つの情報だけで頑張りました。ただ、日付に関する情報が更新日時と作成日時しかとれず、一発で記事を書ききらないと日付がずれる問題と直面しました。公開日時の概念がなかったのです。
最初はfrontmatterの採用も考えましたが、esa.ioの生成するHTMLにfrontmatterの情報が入ってしまうのは実装上しんどいので却下。
いろいろ考えた結果、タイトルの中に公開日を入れる方針にしました。[year-month-day]形式で入力すると、静的サイトジェネレーターがそれを公開日として認識する実装をしました。
ただ、これはプレビューで表示されるものとブログ上で表示される見た目に乖離が起きてしまったのでちょっとつらいです。
簡単に公開できる仕組みを公開予定
esa.ioをデータソースにしたブログの仕組みはもう一周ぐらい自分の中で試してから、誰でも簡単に扱えるような形にして公開していこうと思っています。
2018/06/11 - 逆引きstyled-components 共通コンポーネントをうまく作る5つの小技
ここのところstyled-componentsでのAtomicDesignの実装を考えていた。共通コンポーネント(Atomっぽいの)を書くときに役立つTips。
それ以外のときはあまり役立たないかもしれない。基本TypeScriptで真価を発揮すると思っています。（エディタ補完的な意味で）
react-routerのLinkにstyled-componentsを使いたい
styled.h1, styled.pみたいにHTMLにもともと存在するタグにstyled-componentsを使うのはよくある。Linkはどうなの？って聞かれたのでその時の見せた例。
調べてみたらDocsのstyling-any-componentsに書いてあった。
import styled from 'styled-components'
import { Link } from 'react-router-dom'
const StyledLink = styled(Link)`
text-decoration: none;
`
const HogeComponent = (props) => (
<StyledLink to='/'>No underline</StyledLink>
)
複数のボタンやバリエーションをキレイに書きたい
よくあるケース、ボタンみたいなバリエーションを作りたい時は、ベースとなるスタイルを定義して、継承させて別スタイルを当ててexportする。
Docsのextending-stylesで記載されている例。
Button.jsx
import styled from 'styled-components'
const BaseButton = styled.a`
padding: 8px 16px;
color: white;
`
export const SuccessButton = BaseButton.extend`
background-color: green;
`
export const DisabledButton = BaseButton.extend`
background-color: gray
`
もう一つpropsで管理する方法もあるが、可読性的には上記のextendが好み。3項演算子が増えてくるとしんどい。
Button.jsx
import styled from 'styled-components'
const BaseButton = styled.a`
padding: 8px 16px;
color: white;
background-color: ${props => props.primary ? 'blue': 'gray'};
`
同じスタイルを別のタグで使いまわしたい
styled-componentsで作ったコンポーネントにwithCompoentを使うとベースのタグが変えられる。a => spanとかh1 => h2, h3, h4とかのケース。
import styled from 'styled-components'
import { Link } from 'react-router-dom'
const MenuLInkItem = styled(Link)`
border-bottom: 3px solid transparent;
padding: 15px 12px 12px;
`
const MenuActiveItem = MenuLInkItem.withComponent('span').extend`
color: red;
border-bottom-color: #red;
`
定数や色を管理したい
別ファイルを作ってimportして使う。
colors.js
export default {
primary: '#0a9b94',
secondary: '#efede0'
success: '#08837d',
warning: '#bf7600',
text: '#3c4a60'
}
styled-componentsのcssでスニペットみたいなのも作れる。font-familyとかSCSSでいうmixinみたいなものを定義しておくと良さげ。
snippets.js
import { css } from 'styled-components'
export const fontFamily = css`
font-family: "Lato", Arial, Emoji, "ヒラギノ角ゴPro W3", "Hiragino Kaku Gothic Pro", "メイリオ", Meiryo, "ＭＳ Ｐゴシック", sans-serif
`
export const fontFamilyDreamOrphans = css`
font-family: "DreamOrphans", Arial, sans-serif
`
export const truncateMultiLine = (lines) => css`
display: -webkit-box;
-webkit-line-clamp: ${lines};
-webkit-box-orient: vertical;
overflow: hidden;
`
Text系のスタイルが乱立するのでまとめたい
冗長と思う人もいるかもしれないが、1ファイルにまとめていくのがいいんじゃないかと思ってる。
Interface Inventoryっていう既存サイトの同じようなスタイルをまとめて一覧化するみたいな手法がある。それを模したコードを意識したらこのファイル構造になった。
既存サイトがあってデザインがバラバラみたいなシチュエーション（ある？）ではデザインガイドを作る時にこういったファイルが役立つのではないかと思っている。
共通化のスタート地点としてのファイル。
ここではcssで共通スタイルを書いて、それを各コンポーネントで読む方式で書いた。
Heading.jsx
import styled from 'styled-components'
const headingBaseStyle = css`
font-weight: 600;
color: #3c5064;
`
const BaseHeading1 = styled.h1`
${headingBaseStyle}
font-size: 20px;
letter-spacing: 1px;
`
export const Post = BaseHeading.extend`
margin-top: 6px;
`
export const PostSection = styled.h2`
${headingBaseStyle}
font-size: 20px;
margin-bottom: 16px;
`
export const Card = styled.h3`
${headingBaseStyle}
font-size: 13px;
`
正直AtomicDesignはエンジニアとデザイナーが協力しても難しいトピックなので自分の中でもあまり明確なゴールは描けていない。
AtomicDesignのボイラープレートみたいなものがあって、それをエンジニアとデザイナーでこなしていけば完成みたいな銀の弾丸はないだろうか？（いや、ない）
現状は、今あるデザインを共通箇所を見つけていって小さくしていくことが多そう。デザイナー的にこれを意識しながらAtomから作っていくのはしんどそう。
ただ、styled-componentsはAtomic Designでなくても使えるので便利に使っていきたいと思う。
2018/06/08 - @kakakakakkuさんに弟子入り・ブログを初めて1ヶ月たった
このブログを初めて一ヶ月立ちました。@mottox2といいます。
そもそもこのブログを始めたのは、2018年はアウトプットしていくぞという豊富もあったのですが、以下のツイートが後押しになりました。
今週から数名「ブログメンター（アウトプットメンター）」を追加募集します！・どう技術ネタを探すか・どう習慣化するか・どう読まれる記事を書くかなどを探求します．1ヶ月単位で自由に終えることができます．ただし，必ず週1回は記事を書いてもらいます．完全無料．興味あれば連絡ください🎉 https://t.co/qhe5rMnzkm— カカカカック@1000ブクマ実績解除🎉 (@kakakakakku) May 2, 2018
kakakakakku（吉田）さんのブログはよくはてブで話題になっているなというイメージで、特に「ブログを書く技術」を発表したを読んだ時は**「パワーワードだ」**という感想を持っていました。
2018年の目標に上げたことで、qiitaやnoteにも投稿していましたが不定期で安定せず悩んでいるところに上のツイートがタイムラインに流れてきました。ツイートの3分後には連絡をとってブログメンティになりたいという意思を伝えました。
自分がこの1ヶ月ブログ関係でやったことを書いておきます。
ブログを初めてやったこと & 起こったこと
即行動、とりあえずブログをつくった
連絡をとったあと、ブログサービスは統一したほうがいいというお話を頂いたので、自分的に最強なブログを作ろうということで連絡後半日ぐらいでブログを作って以前から持っていたmottox2.comにデプロイしました。
ブログを始めることにしたという記事でなぜqiitaやnoteを選ばなかったのか書いています。
偶然なのですが、4月にRoppongi.js#2でGatsby + NetlifyのLTでesa.ioをソースにした静的サイトのデモを作っていたので1時間ぐらいでデプロイまで持っていけました。
週2ペースを守って投稿した
最初のDMでブログ投稿のペースは？という質問があったので週2と答え、週2ペースで投稿を続けました。
同時に書けそうなタイトルを20個を上げてという宿題ももらったのでテーマに困ることはありません。この段取りがあったので、「書く」か「書かないか」の問題になります。もし書けなかったことがあれば、書かなかっただけです。
テーマは昔React + TypeScriptで書いたease(Source)というツールに記録しています。
ブログ駆動のLTを2回した
発表資料と同時にブログ記事を公開すると，ブログ側に PV を集めることができるため，他の記事にも誘導することができたり，ブログをお気に入りにしてくれたりもするので，戦略としては重要かと！もし次また LT する機会があればご検討頂ければと思いますー
kakakakkuさんがGatsbyJSのLT資料を見てくれていて、LTするならブログ書くといいよ！というアドバイスを頂きました。
そこでWe are JavaScriptersと PWA BegineersのLT枠に申し込みました。自分が見た段階で定員超えになっており抽選が確定していたので、どちらかのLT枠がもらえるといいなと思っていました。
結果としてはどっちともLT枠をいただけたので、We are JavaScripters!ではWordPressのフロントエンドをGatsbyにした話、PWA BeginnersではPWAで戦えそうなシチュエーションをLTしてきました。
どちらとも同じ週のイベントだったのでめちゃくちゃ大変でしたが、充実感もすごかったです。
PWA BegineersのLT資料は100はてブ超えしたので多少は見てもらえたのかなという気持ちです。
日本語情報のないものを調べるのが苦痛じゃなくなった
ブログネタになるという気持ちがあると少し楽しくなります。
最近はGatsbyJSとNext.jsあたりをよく触っているのですが、日本語情報がかなり少なめです。GatsbyJSに関してはそれなりにアウトプットして今はalpha版を触るところまで深掘りし始めました。
v2に関する記事も日本初のブログ記事だという自負があります。
記事のシェアや引用リツイートが増えた
「他の人のブログも読んでシェアしましょう」というアドバイスも頂いていて、記事のシェアや引用リツイートが圧倒的に増えたと思います。
「自分がやられて嫌なことはしない」しかり「自分がしてもらったら嬉しいことは人も嬉しい」と思います。
この記事もシェアしてくれると嬉しいですｗ
いろいろ、いいことがあった
GatsbyJSの記事を書いたりLTをしていく中でNext.jsやNuxt.jsを触る機会があったのですが、Next.jsも仕事で使うことになって今Productionで出すためのコードを準備中です。仕事につながる
技術顧問先で質問された時に自分のブログ記事のURLを貼って答えられるシチュエーションがある。嬉しい。
LTやブログ記事を書いたものに関しては、理解が深いのでより深い説明が出来る。
文章を書くのが少し早くなった。どうしてもメールを書かないといけない時も多少ストレスが減った。
ブログネタになりそうなものを言語化したからか、まだ自分の中で答えの出ていない問題に対する思考をよくするようになった。
まだ、ブログを初めていない人に伝えたいこと
DMM TELLERやPixiv chatsroryなどの会話文小説が流行り始めているこのご時世に今更ブログか！と言われるかもしれませんが、確実にやった方がいいです。ブログを書くことで知識に深みが出てくる（と感じています）
少なくともWebエンジニアの皆さんはOSSやネットの情報を受け取っているので、ブログという形で返していきませんか？
Takeは十分もらっていると思うので、Giveも初めていきませんか？
最近、ネットの情報に頼っているという点で既にTakeは十分もらっているので、Giveしても赤字にならないということに気づいた。Giveしまくっていきたい。 https://t.co/cSOMfP5TOc— もっとx2 (@mottox2) May 16, 2018
もし、ブログメンティの募集があったら最速で飛び込んで行くべきだと思うので、@kakakakkkuさんのTwitterをフォローしておくといいんじゃないでしょうか？
6月もGiveを続けて行くので@kakakakakkuさん、これからもよろしくお願いします！
2018/06/03 - Gatsby 2.0.0-alpha.48までの変更点をまとめてみた
このブログはGatsbyで作られています。
Gatsbyの最新版は1.9.269ですが、Githubでv2の開発が進められています。もう既にalpha版としてリリースされているので、実際に使ってみつつ、変更点をまとめてみました。
変更内容
Breaking Changes
v2ブランチにあるBreaking Changes.mdを確認すると現段階(2018/06/02)での破壊的変更を確認できます。
Breaking Changes.mdと実際に触ってみて気になった変更点を記録しておきます。
Remove postcss plugins (cssnext, cssimport) from default css loader config
postcssが依存ライブラリから削除されています。
boundActionCreators => actions
gatsby-node.jsでexportする関数の引数のリネームです。
pathContext => pageContext
propsで渡されてくる引数名の変更です。
Source & transformer plugins now use UUIDs for ids. If you used glob or regex to query nodes by id then you’ll need to query something else.
DataSource系のプラグインのUUIDの方式が変更になりました。
Changed modifyBabelrc to onCreateBabelConfig
gatsby-nodeでexportする関数のリネーム
Changed modifyWebpackConfig to onCreateWebpackConfig
gatsby-nodeでexportする関数のリネーム
Inlining CSS changed — remove it from any custom html.js as done automatically by core now.
html.jsで<style id="gatsby-inlined-css" dangerouslySetInnerHTML={{ __html: require('!raw-loader!../public/styles.css') }} />みたいな記述を書いてCSSをHTMLに埋め込んでいたのですが、これがcoreの方に移動しました。
Manually install react and react-dom, along with any dependencies required by your plugins.
reactとreact-domが依存ライブラリから外れて、自分のリポジトリでdependenciesに入れるようになりました。
現時点の最新版でreact@16.4が使うことができました。new Context APIを使うこともできます。
gatsby 1系ではreactの15系が動いていたので最新版を使えるのは嬉しいです。
Layouts have been removed. To achieve the same behavior as v1, you have to wrap your pages and page templates with your own Layout component. Since Layout is a non-page component, making query has to be done with StaticQuery.
これは大きな変更でHeaderやFooterをlayouts/index.jsで書いていたと思うのですが、書くページでレイアウトのコンポーネントを呼び出すようになりました。
実際にはlayout.jsみたいなコンポーネントを書いてpages/以下のコンポーネントで呼び出すことになると思います。
layout.js
import React from 'react'
const Layout = (props) => {
return <div>
{props.children}
</div>
}
pages/hoge.js
import React from 'react'
import Layout from '../src/layout.js'
const Page = () => {
return <Layout>
<SomeComponent>
</Layout>
}
気になった内容
gatsby buildからbuild-cssが消えた #4588
gatsby buildで5つのステージがあったのですが、build-cssが削除されて4つのステージになりました。
webpackがv4になる際にbuild-javascriptに統合されたようです。
gatsby-linkからimportしていたLinkがcoreに統合 #3864
gatsby-linkのパッケージからインポートしていたLinkがcoreの方に入りました。
before
import Link from 'gatsby-link'
after
import { Link } from 'gatsby'
webpackの設定の書き換え方が変更された
今までは引数のconfigを使って書き換えていましたがsetWebpackConfigというメソッドで変更するようになっています。 gatsby/src/utils/api-node-docs.js#L156-L162
内部で使われているwebpackがv1 => v4になっているのでv4にそった書き方をする必要があります。
api-node-docs.jsより
exports.onCreateWebpackConfig = ({
stage, getConfig, rules, loaders, actions
}) => {
actions.setWebpackConfig({
module: {
rules: [
{
test: 'my-css',
use: [loaders.style(), loaders.css()]
},
],
},
});
}
v2に上げた作業記録
とりあえずv2にしてパッケージを揃える
package.jsonでnextとバージョン指定することで実際に使用することができます。
"dependencies": {
"gatsby": "next"
// gatsby系のプラグインに'next'をつけておく
}
あとはreactとreact-domが必要なのでyarn add react react-domを実行しておきます。
一旦このあたりでgatsby devを実行するとgatsby-plugin系のライブラリでpeer dependency化したプラグインがいくつか現れ Module not found: Error: Can't resolve 'PACKAGE_NAME' みたいなエラーが出ます。
yarn add PACKAGE_NAME を実行してインストールします。
gatsby-node.jsの修正
次のメソッドを使っているならリネームをします。
Changed modifyBabelrc to onCreateBabelConfig
Changed modifyWebpackConfig to onCreateWebpackConfig
webpackの設定を書き換える記法をactions.setWebpackConfig形式に変更します。
layout/index.jsの代わりのコンポーネントを書く
Breaking Changeで書いた内容のように変更していきます。
あとは試行錯誤
基本的にgatsby devが通らなければなにか治ってないので、エラー文を見て直していけば動くようになります。
おわりに
全体的にgatsbyや関連pluginに依存してたライブラリがpeerDependencyになり、ユーザーの使いたいバージョンが使えるようになっているのが好印象です。
内部のbabalもv7が使われており、babelでTSを使うこともできるのでよりきれいに使いたい方は選択肢が増えていくのではないでしょうか？
誰得の記事なのかわかりませんが、日本のGatsbyJSユーザーの皆さんのお役に立てたら嬉しいです。
2018/06/02 - Netlify Formsで問い合わせフォームを作ったら簡単だった
追記(2022/12/29): 問い合わせに対応する窓口をTwitterに統一したいので、フォームページは削除しました。
当ブログは静的サイトホスティングサービスのNetlifyでホスティングされています。
今回、ブログに問い合わせフォームを置くためにNetlify Formsを使ったのですが、静的サイトのまま簡単にフォームが設置できて最高でした。
Speeeのもくもく会（めっちゃおしゃれなオフィスでもくもくできる）で作りました。ありがたい。
つくったもの
https://mottox2.com/contact
Netlify Formsとは？
静的サイトを運営しているのに、フォームを置くために裏にPHPなどのコードを動かすみたいな選択肢はイケていません。
フォームを置くだけならGoogle Formなどの選択肢もありますが、NetlifyにはNetlify Formsというフォームを簡単に作って管理画面上で簡単に確認できるような仕組みを用意してくれています。
<form name="contact" method="POST" netlify>
<!-- Your Form -->
</form>
のような形のHTMLを書くだけです。また自分でHTMLを書くのでデザインのカスタマイズも自由自在、サイトにあったイメージのフォームを置くことができます。
なお、100件のリクエストまで無料プラン(Forms Free)で使うことができます。参考: Price
Docsによると、ビルド時にHTMLをパースして、内部にformが存在しているか確かめているそうです。
Docucment
Static Site Generatorで使うときに注意すること
GatsbyなどのStatic Site GeneratorでFormsを使用するはform-nameというhidden fieldを足す必要があります。Netlifyのブログ記事によるとNetlifyが挿入するフォームをGatsbyが消してしまうためだそうです。
おそらく前述のビルド時にHTMLをパースするときにNetlifyがform-nameというhidden formを埋め込むので、それを手動でやってくれという話だと思います。
以下のようなコードを書けば動きます。
<form name="contact" method="post" data-netlify="true">
<input type="hidden" name="form-name" value="contact" />
...
</form>
GatsbyでNetlify Formsを使うサンプルコードも用意されています。
imorente/gatsby-netlify-form-example: Example site integrating Netlify’s form handing in Gatsby’s starter template
2018/05/30 - PWA BeginnersでPWAで戦えそうなシチュエーションについてLTしてきた
5/24にPWA Beginners #4で「ネイティブアプリの代わりにPWAで戦う選択肢」というタイトルでLTをしてきました。基本的にPWAはネイティブアプリの代わりにはならないと思っているなかで、どういったシチュエーションでネイティブアプリの代わりになるのかを検討してます。
https://speakerdeck.com/mottox2/pwa-instead-of-native
Progressive Web Apps
最初に言っておくと前提としてPWAはネイティブアプリの代わりにはならないという見解はほぼ多くの人が思っていると思っていて、僕もそう思っています。
PWAはReliable, Fast, Engagingな特徴を持つものである。ということで、基本的にはWebAppでもよりよい体験を提供していこうという認識が近いと思っています。
Progressive Web Apps | Web | Google Developers
Progressiveが示すとおり段階的に対応できるという話ではありますが、WebエンジニアとしてはNativeアプリを代用できるか？という可能性を探りたいものです。
銀の弾丸にはなりませんが、条件が揃えばネイティブアプリとは違った選択肢になりうるのではないか？という気持ちからこのLTをしようと思いました。
今、PWAをアプリライクに使おうとすると発生する問題
ブラウザ対応がいまいち
Google、Microsoftは前向き、Appleの対応は不透明
今後サポートしても、バージョンによって使える機能・細かい挙動が変わる可能性が高い
現状でもiOS SafariとGoogle ChromeでWeb App Manifest周りの挙動が異なる。
Webページが遅いと、圧倒的に体験がネイティブアプリと比べて劣る
アプリストアを使えない
GooglePlayはサポートする方向に動いているが、AppStoreは正直期待出来ない。
インストール動線
一般的ではないので、入れてもらうのにハードルがある。
オフライン対応などでキャッシュ戦略など考えることが増える
もちろんProgressiveが示すように、既存サイトにServiceWorkerを入れてアセットをキャッシュすることや、Android端末向けにWeb Pushを入れる、Payment Request APIで決済機能を利用するなどPWAの一部機能を使用するだけなら上のような問題は考える必要はありません。あくまで、ネイティブアプリで戦わずPWAで戦うという選択肢をした場合です。
補足：ただ基本的にPWAは通信環境が悪い国向けに、通信量をへらすという文脈での提供が多くこの用途では日本は対象になりません。ネイティブアプリもあるけどPWAも用意しているというのが主流だと思います。 (例: Instagram, Twitter Lite)
どういう時にPWA Orientedがよさそうなのか
ストア(AppStore, GooglePlay)の意向に振り回されたくない限り、予算・人材が確保できるなら基本的にネイティブアプリでやっていくといいと思っています。
ただ、予算・人材が確保出来ない中でネイティブアプリを作っているなら、「そもそもネイティブアプリは必要なのか？」「工数を食い合ってしまい中途半端なものにならないか？」みたいなところがポイントで、iOSユーザーにはリーチが弱くなるけどPWAでWebに注力していこうという選択はありな気がしています。
採用できない
他の事業部とかなくてiOSの経験者がいない場合、成果物がないので募集をするのも大変ですいし、採用する際も難しいでしょう。iOSを立ち上げるだけの力を持ったエンジニアを見つけるのは難しいでしょう。（メガベンチャーに吸い取られ続けてる中で、あなたの会社にはいる優位性を見いだせますか？）
そこで、今いるメンバーの中でPWAだけではなくReactNativeなどのAlternativeな選択肢をやりたい人を見つけて進めてもらう方が現実的な場合が多いのではないでしょうか。
（ただ、多くの場合かなりのレベルアップを必要とすることが多いので押し付けにならないようにしたい）
予算がない
予算がないならスコープを狭くするとか開発期間を長くするとか検討してほしい。
ストアの都合
アダルト系のアプリ（Google Playも厳しい）やApp Storeで多い謎のリジェクトなどに振り回されたくない。IPhoneXの画面対応や64bit対応でストアから追い出されるなど、そういったものから自由になりたいなど。
ただ、アプリの性質上、ストアに出せるものならストアに出しとくといいんじゃないかと思ってます。
MVPを作りたい
提供する上で本当に価値があるのか、MVP（Minimum Viable Product）を作って確かめたいという場合もPWAが有効だと思っています。
ストアの申請（AppStoreだと数日、GooglePlayだと数時間）に振り回されず高速にフィードバックループを回せるのはWebの利点です。そこでネイティブアプリを模した体験をしてもらうというのは一つの選択肢になりうるかもしれません。
意思決定ができる
これらのメリットがあってもRead Worldで重要なのは、PWAのデメリットを把握した上で、進めていくという意思決定です。「やっぱりiOSも」なども言い出すと現場のエンジニア的には非常にしんどいです。
ただ、予算・人材がない時点で導入の判断が出来て成功するころには、技術者のレベルが上がって他社の技術者にとって魅力的な環境になるかもしれませんし、成功してお金があれば人材確保も楽になりますし、広告で勝負もかけられます。また、時間が立つとPWAが普及していて、アーリーアダプターになっている可能性もあります。
まとめ
銀の弾丸ではない。使い方次第でネイティブアプリよりベターな選択肢になりうるというところ。
現状、予算・人材が確保できるなら基本的にネイティブアプリかと思っている。ウェブエンジニアができるとう点でReact Nativeもありだと思っています。
PWAはもう少しブラウザ対応（というかAppleの意向）がわかるまでは、尖った意思決定が出来ない場合は積極的に進めづらいと感じています。
ユーザーに対して、エンゲージメントをどう上げていくかという選択肢にWebが上がってくるので個人的に非常に嬉しいと思っています。PWAはネイティブアプリライクに作るだけでなく、基本的には既存サイトの体験をよくしていくためのツール群だと思っているので、うまく使ってWebの体験を改善していけたらと思います。
PWA Begineersの運営の皆さん、LTの機会を頂きありがとうございました。
2018/05/26