こないだ振り返りしたばっかなのにもう・・・。

## Keep

1つのQだけど結構前進した感じのあるQだったな〜。

### 副業を増やせた

コネからお誘いをもらってNext.js、FirebaseのPJに参画してる。

稼働時間がガッツリ取れないタイプの副業はなんだかんだ初めてなので戸惑いながらやってるけど、今のところはそんな問題になってないかなあと思う。

ただやっぱり稼働時間が取れない分進捗が出づらかったり、相談事項のやり取りがむずかしかったりするのでそれは今後改善したい。

あとはやっぱりコアビジネスに関わる部分のタスクは雇用主からしたら振りづらいと思うので、そういう意味じゃビジネスサイドも含めた研鑽にはならなそうだなとおもった。

今回はReactとFirebaseの実践ってところに重点を置いてるので、そこの知見を吸収することと、できる限り短い時間で成果を出して信頼を得るところを頑張ろう。

### プライベートPJを2つ出せた

以下構成のPJを出せたのである程度知見が増えた。

- フロント Next.js + ApolloClient、バックエンド Express + TypeORM + ApolloServer
- フロント Next.js + ApolloClient、バックエンド Next.js API Route + Prisma + Nexus

プロダクションレディなレベルまで知見がついたかというと微妙だけど、チュートリアルだけ終えましたレベルは超えたはずなのでいざ使うとなったときにもある程度スピード感を持って作業ができそう。

ああ、あとポートフォリオとブログの移行をしたのもこのQかな？

ブログはGtasbyJSからNext.jsにガッツリ書き直したのと、ポートフォリオもNext.jsで放置されてたのをNext.js + GraphCMSに移行した。

GraphCMSはまじで最高だったので今後も使っていきたい。

### ギターの練習を増やせた

そもそもなんでギター辞めたんだっけって振り返ってみたら、たぶん面白くなくなったからだと思うんだけど、色々考えたら以下の結論に至った。

- 音楽と音学がある
- そもそもギターは最初っから面白いわけじゃない
- 音学を経て音楽になる
- 最初に学んだ技術で楽しめる範囲を楽しみ尽くしてしまっていた
- 次の音楽になるための音学をするべき

ということで音楽理論とスケールの勉強と、奏法についての勉強を始めた。

[Rickyさん](https://www.youtube.com/c/RickeyGuitarChannel)の[ペンタトニックスケール講座](https://www.youtube.com/playlist?list=PLedsR4qZqNvFkJs2rtzKiL9p7fEAW7qd3)とか[すぐ分かる音楽理論講座](https://www.youtube.com/playlist?list=PLedsR4qZqNvGKqv4_RgBv5Ve3uNBAsd1Y)を見ながら勉強してるんだけど、めちゃくちゃわかりやすくて「これが無料でいいのか・・・？」ってなってる。

やってから思ったけどメジャースケールを飛ばしてペンタに入ったのは順番を間違った気がする・・・。

奏法についてはフィンガースタイルをベースにギャロッピングとかラスゲアードに手を出したりしてる。そのうちスラム奏法とかもやってみたいけどアコギ持ってないし当分先かなあ。

ギターの再開に伴って右手だけ爪を伸ばし始めたんだけどQOLが落ちててつらい。

## Problem

### 本が読めてない

全然読めてない印象があるけど、とはいえ2冊ぐらい読めたかな？

とくにまとめられるほどしっかりした感想は持ってないしここには列挙しないけど、もうちょい継続的にちゃんと読みたいなあという気持ち。

漫画ばっか読んでるのと最近は個人PJが落ち着いたので、ギターと本に専念するようにしようかな。

red-maple-5385956 1280

2020-3Q振り返り


は〜1年が終わってしまった。

来年はもうちょい計画立てて振り返りもしっかりできる1年にしよう・・・。

## K

う〜ん、4期にしてはまあK多めでやってこれたかな・・・？

### プライベートPJに注力できてる

React、Next.js、GraphQL、Firebase周りの知見がだいぶついたので、新しいプライベートPJを始めた。

最初はバックエンドをRESTでやろうと思ってたんだけど、やっぱり「きれいなプロダクト」を作るよりも「挑戦したプロダクト」にしたかったので、ギリギリでGraphQLに切り替えた。

だいたいこんな構成（まだ全然作れてないけど）

- フロントエンド
  - Vercel
  - Next.js
  - styled-components
  - Apollo Client（未定）
- バックエンド
  - Heroku
  - express
  - express-graphql
  - Prisma
  - PostgreSQL
  - Firebase Auth

### 趣味に投資できてる

ギターをまじでちゃんとやろうと思って、教則本を買ったりして練習してる。

[一人完結型! アコギ・フレーズレシピ 奏法革命を起こす3STEPトレーニング! [CD付] (<テキスト>) | こーじゅん |本 | 通販 | Amazon](https://www.amazon.co.jp/dp/4906954898)

これ完全にいい本なんだけど、初心者とかにはまじでゲキムズだと思うので、技術レベル的に背伸びが必要なくらいのタイミングで買えてよかった・・・。

アコギもそのうちほしいんだけど、やっぱり賃貸だと厳しいし、サイズ的にもでかくなっちゃうのでためらってる。

買うとしたらリトルマーチンかGS Miniがほしいけど、最初の1本だからフルサイズのフォークタイプを買うべきなのかなあとも思ったりしてる。

### 旧友に会う時間を作れてる

別にこれといって理由はないんだけど、古い友人に脈絡なしに会ったりしてる。

もちろん共通の話題がなかったりもするんだけど、それはそれで自分の知らない範囲に足を踏み入れることが出来たりしていいし、みんな頑張ってんだなってわかるだけでも人生へのモチベになったりしてる。

年齢的に不幸が起こってもおかしくない代ではあるから、今後も会えるときに会っとこうと思う。

## P

新しいプロブレムも継続しちゃってるプロブレムも多いな〜、まあ認識できてるだけいいか・・・。

### 本業のモチベ低下が改善できてない

もうこれはだめなのかもしれん。辞め時っぽさある。

他社にオファーレター用意してもらう直前まで行ったりしてるし、あんまり今の会社にこだわらず次に行っちゃったほうがよさそうという結論に行きつつある。

大きなストレスの元になってるし、それで悩むとまたストレスになるし、悪いループにはいってる。

ストレスになる原因を考えてみてるけど、だいたいこんなとこなのかなあ・・・。

- 組織側の要因
  - 将来性を感じなくなった
  - 技術的な進歩がない = とりあえず仕事をこなしてお金をもらうだけの関係になってる
- 僕個人の要因
  - 全体を把握しようとしすぎ、拾おうとしすぎて疲れる
  - そもそも仕事なんてどれもストレスフルなものだと理解できてない

というわけでいろいろ考えた結果、適当なところで限界が来たらスパッと辞めてフリーランスに戻ることに決めた。

### 挑戦が足りてない

新しく始めたことがそんなに無い年だったと思う。まあコロナがあったからっていうのもあるんだけど。

これはTryにもなるけど、ギターをちゃんと練習して社会人サークルに顔だしたりしてみようかなと思ってる。

他にも交友関係を増やしたりっていうのはしていきたいし、未知の領域に足を踏み入れる機会は増やしていきたいな。

## T

さ〜一番大事なやつ。ちょっと多くなりすぎて逆にヤバい気がする 🤔

### 仕事の手を抜く

あんまり頑張りすぎても変わらんし、それで潰れたら元も子もないので、手を抜くすべを身に着けようと思う。

たぶん僕の性格上ちょっと手を抜いたところで何も変わらないので、めっちゃ努力して思いっきり手を抜かないと変わらないと思うので、そこは2021年1Qになんとか身につけたい。

それで無理なら退職もあまり重く考えずに踏み切ろうと思う。

### 退職した場合のあてをつけておく

退職自体は前からずっと考えてたんだけど、その後どうするかを全く考えてなかったのは良くなかった。

今ん所だと一定期間フリーランスに戻ろうかなとも思ってるんだけど、特に理由や方針があってのことではないので、もうちょっと考えておきたい。

退職後の方針は退職の踏ん切りにも影響するので、スタートダッシュ切るためにも決めておきたいところ。

### ギターサークルに顔を出す

さっきPにちょっと書いたけど、未知の領域に踏み込むのと趣味を深めることを目的に、サークルに属することを検討してる。

いま検討してるのはここで、結構ハードル低く楽しくやれそうな印象があって気になってる。

[社会人音楽バンドサークル・ウォーターバグズグラブ東京・新宿（初心者・経験者歓迎）](https://wbbcc.web.fc2.com/)

たぶんスキルがなくてもいけると思うんだけど、とりあえずメジャーCスケールのリードとバッキングをもうちょっとできるようになっておきたいなという気持ちがある。

あとコロナがあるから今すぐっていうのは抵抗あるし。

### 課題図書を設定する

本が読めてないのは少し改善したけど、満足行くほどではないので仕組み化する必要がありそう。

今の状況では「とりあえずKindleに買って終わり」みたいな感じなので、そこから次に進むために土日の課題図書みたいなのを設定しようと思う。

あわよくばシステム化して1プロダクトにしたいな。課題図書を登録していつまでに読めたかみたいな記録つけるやつ。

### ギターで扱える奏法、スキルを増やす

いまのままだと「できること」をやってるだけなので、それはそれで楽しいんだけど、「できないこと」を「できること」に変えてさらに楽しめるようにしたい。

例えばこういうこと。

- スラップ奏法
- スラム奏法
- フィンガースタイル
- ソロギター
- コードの即興耳コピ

この過程でアコギが必須になったら買おうかなあ。

### 自分以外のユーザがいるプロダクトを作る

プロダクトは当たり前のように作っていたいんだけど、そろそろ自分のためだけじゃなくてちゃんと他の人も使えるプロダクトを作りたいなという願望がある。

もちろん自分だけしか使わなくても知見にはなるから問題はないんだけど、グロースフェーズの経験とか、自己満足じゃない仕様みたいな観点も入れるとやっぱり自分だけがユーザじゃだめだよなという気持ちがある。

というわけで2021年はプロダクトを作り続けるし、ちゃんと伸ばすところにも手を入れていきたいと思う。

### もっと筋トレ、運動をする

これは年齢的に当たり前ではあるんだけど、「気が向いたら」程度ではなくもうちょっとちゃんと時間を取ってやりたい。

筋トレであれば目に見えて数字にでるくらいやりたいし、運動であれば何キロ走るとかそういう記録をつけて負荷をあげていこうと思ってる。

### notionで目標管理、課題図書管理、日記をつける

今回のTryの「記録系」に関する解として、全部をnotionで管理することにした。

といわうけで振り返り記事も今回が最後になる。これからはちゃんとテック系の記事を頑張って更新していくぞ！

viburnum-3060769 1280

2020振り返り

## 複数のexportがあるモジュールのモックをする

jestでMockをするとき

```js
jest.mock('../../src/lib/api')
```

みたいなことをしようとしたんだけど、これをやると `api` モジュールがExportしてるリソースをすべてMockしてしまって動かなくなってしまう。

そういうときは `jest.requireActual` を使って以下の様に「特定リソースのみ」を上書きしてMockしてやれば部分的なMockができる。

``` js
jest.mock('../../src/lib/api', () => {
  return {
    ...jest.requireActual('../../src/lib/api'),
    getPosts: () => {
      return [
        { id: 1, title: 'post title1' },
        { id: 2, title: 'post title2' },
      ]
    }
  };
})
```

これもっといいやり方がある or 設計が悪い気がするんだけど、他の人はどうやってるんだろう 🤔

winter-1791370 1280

Jestで複数のexportがあるモジュールのモックをする

tsconfigにbaseUrlを設定しているとeslintがコケることがある。

1回設定したら終わりだしメモらなくていいでしょ〜って思ってたけど5回ぐらいググってるのでこっちにメモっとく。

```
error  Unable to resolve path to module '#/foo'  import/no-unresolved
```

## eslint-import-resolver-typescriptの導入とresolverの設定をする

ようはimport記法でtsファイルを解決できてないらしい。

```
yarn add -D eslint-import-resolver-typescript
```

して、

``` json
{
  // other configuration are omitted for brevity
  settings: {
    "import/resolver": {
      typescript: {} // this loads <rootdir>/tsconfig.json to eslint
    },
  },
}
```

したら消えます。


## refs

- [[import/no-unresolved] when using with typescript "baseUrl" and "paths" option #1485](https://github.com/benmosher/eslint-plugin-import/issues/1485)

pedestrian-bridge-5466182 1280

tsconfigのbaseUrlとeslintを共存させる

[Daisuke Tsuji's portfolio](https://yet.unresolved.xyz/)

もともとcreate-react-appで作ったものを1年ぐらい前にNext.jsに置き換えたんだけど、その後メンテしてなかったしコンテンツ管理もコードベタ書きで辛かったので一気に置き換えた。

6時間ぐらいかかった。

## 技術スタック

- [Next.js](https://nextjs.org/)
- [GraphCMS](https://graphcms.com/)

リニューアル前はJS上にJSONでコンテンツを持ってたんだけど、流石にメンテしづらいしGraphCMS使ってみたかったし、最近作った自分用サービスもあったからコンテンツ追加したいし、ということが重なったのでいいタイミングになった。

## GraphCMSがめちゃよかった

Headless CMSは個人的に気に入ってるソリューションなんだけど、今は群雄割拠の時代すぎてどれを選ぶかがめっちゃ困る状態になってる。

https://headlesscms.org/

同時にGraphQLは個人的にめちゃ気に入ってて、さらに深入りしていきたい気持ちもあったのでそこに特化しているGraphCMSを選んだ。

あと気になってたのはこの辺

- https://www.sanity.io/
- https://strapi.io/

GraphCMS、使ってみた感想としてはめちゃシンプルでいい！

ただのHTTPベースのAPIで認証もbearer tokenなので、Contentfulみたいにライブラリが使いづらいとかもないし、ブログもGraphCMSにしとけばよかったって気持ち。



books-5433432 1280

例によってポートフォリオをリニューアルした

正直それなりにデザインスキルが高いかつデザイナーさんたちがテクニカルスキルが高い組織じゃないとスタイルガイドの運用は結構むずかしいとおもうんだけど、ちょうど現職ですでに導入されてるレガシーな自前スタイルガイド機構があったので、負債化したそれをhologramに置き換えた。

- [trulia/hologram](https://github.com/trulia/hologram)

![Screen Shot 2020-07-17 at 10.25.42](//images.ctfassets.net/ra242vdzwrmo/2IHvbzKYwauV46nl28976M/6233847301156c52191d177fc72cc295/Screen_Shot_2020-07-17_at_10.25.42.png)

## hologramのここが良い

hologramはCSS上にコメント形式でMarkdownとマジックコードコメントを書くことで「実際の表示」と「コードの例」をそれぞれドキュメント化してくれるRuby製のツール。

![Screen Shot 2020-07-17 at 9.41.17](//images.ctfassets.net/ra242vdzwrmo/Z2sFx9AwsLEhA6itsW1cS/aa12c39263eafdaaf78ea83ec6180209/Screen_Shot_2020-07-17_at_9.41.17.png)

普通に自前で作ろうとすると「コードの例」を載せるのがすごく難しいので、それをやってもらうにはやっぱりライブラリを使ったほうが楽。

また、「CSS上にコメント形式で記載する」ことで、「そのCSSがドキュメント化される」のと「ガイドに掲載されているのか」がCSSを見るだけでわかるようになる。

自前で作るとなると基本的にはCSSとHTMLは分離されてしまうことが多いと思うので、これがCSS単品で完結するのはめちゃくちゃ強みだと思う。

## hologramをRailsに乗せる

とはいえRailsはコンパイル後のCSSにハッシュダイジェストをつけてくれちゃうので、実はhologramをRailsに乗せるのは結構難しい。

本来は「hologram -> 生成されたCSSを読むHTMLを吐き出す」という流れにしたいんだけど、生成されたCSSのファイル名を取得する方法がhologram自体にはないので、そこは自前で書くしかない。

### 方法1: styleguide用scssを自前コンパイルしてそのCSSから `app/javascripts/` 配下の元CSSを読ませる

この方法ならコンパイル後のCSSを知らなくても、コンパイル前を読み込んで自前でコンパイルさせてしまえるのでhologramでも使えるようになる。

hologram自体にもstyleguide用のCSSは必要なので、それをSassで運用するようにしてかつ元のCSSも読ませるようにすればスマートに解決する。

### 方法2: `manifest.json` を読んでCSSを埋め込めるようにする

僕は方法1を選んだのでこれが実際できるのかはわからないけど、理論的にはできそう？

Railsは `public/packs` 配下に元ファイルとコンパイル後のファイルのマッピングを持ったjsonを吐き出すので、それを読み込んでコンパイル後のファイル名を取得してしまえばhologramに埋め込むことも可能かもしれない。

## hologram導入で躓いたところ

意外と簡単にいけるだろ！って思ったけど思った以上に躓いて半日ぐらいかかったのでメモっておきたい。きっとまたやらかす。

### コメントは `/* doc` じゃだめ、 `/*doc` のようにスペースは入れない

これで30分ぐらい動かなくて悩んだ。

hologramのコードを読めばわかったのかもしれないけど、何回やってもHTMLが生成されなくて適当に触りまくってたら直った。

### SCSSの自前コンパイルとファイルウォッチ

スタイルガイドを作るとなると、ガイドだけじゃなくてデザインの確認にも使いたかったので、開発サーバを起動してstyleguideのテンプレートと実CSSファイルの変更を検知 & 再ビルドをさせたかった。

この辺はSCSSのコンパイルは [sass](https://www.npmjs.com/package/sass) を使ってたので、ついでに [paulmillr/chokidar](https://github.com/paulmillr/chokidar) を入れてファイルの変更検知をさせることで解決した。

## 終わりに

hologram、結構古いライブラリの割にJSXの対応とかがはいっててちゃんとメンテされてるんだなあという印象があった（最終更新は3年前だけど）。

本来はフロントを分離してstorybookとかを使いたいんだけど、レガシーシステムなのでそういうわけにもいかず、ちょっと泥臭くてもこういった小さい改善で今後もなんとかしていきたいなあという気持ち。

research-4170441 1280

Railsにhologramを導入してスタイルガイドを運用できるようにする

もうGatsbyJSはずーーーっと嫌だったんだけど、先週ついに限界が来ておらーーーーーーーーっと一気に置き換えることにした。

## 構成

ものすごい昔このブログはHugo + ローカルのMarkdownで運営してたんだけど、ローカルのMarkdownを編集するのがつらくてContentfulへ移行した経緯があって、以下みたいな感じになってた。

### As-Is

- コンテンツ管理: contentful
- ホスティング: Netlify
- ビルド: GatsbyJS

Netlify、ホスティングサービスとしてはめっちゃいいんだけどdependabotとかで依存性ガンガン回してるとビルドの上限行っちゃったりしてちょっと嫌だな感を持ってた。

特にGatsbyJSは依存性が増えすぎる傾向があるからなおさらそのデメリットを大きく感じてたように思う。

### To-Be

- コンテンツ管理: contentful
- ホスティング: Vercel
- ビルド: Next.js

こんな感じでNext.jsのStatic Optimizationを利用してビルドしてる。ちなみにホスティングもNext.jsにあわせてVercelに移行した。

もうNetlifyを使ってるのはポートフォリオだけなので、この際ポートフォリオもVercelに移行しようかなって気持ちが出てきてる。中身はNext.jsだし。

contentfulも正直API設計とかがそんなに好みではなくて、GraphCMSとかのほうが良かったのかもなあという気持ちはある。

けどこの移行コストはものすごく高いので一旦はやらなかった。GraphCMSに移行しても同じ問題を抱える可能性は捨てきれなかったし。

## 最近の個人開発とNext.js

最近はブログやポートフォリオを含めて個人でメンテしてるPJが4つほどNext.jsで動いてて、ようやくRailsからの脱却が本格的にできてきたなあという気持ちがある。

Next.jsはAPIエントリポイントがでたときに「え〜そんなフルスタックになっちゃうの？」って気持ちがあった。

ただよく考えてみたらRailsに対して抱いてたフルスタックの嫌悪感は「フロントエンドの描画をコントローラに依存して行ってる」ところだったので、Next.jsみたいにレンダリングがReactでできていて、バックエンドとの疎通をAjaxで行える（SPAを維持できる）のであればAPIエントリポイントは問題にはならないなっていう結論に行き着いた。

あとAPIエントリポイントがあるとプロキシとしても使えるので、バックエンドサーバを隠蔽することもできるし、HTTPヘッダにAuthorizationを埋め込んだりってこともできるのでめちゃくちゃ便利に使えてる。

Railsは1PJでGraphQL APIとして使ってるんだけど、正直これもTSで書いたほうが書きやすいのでそのうち捨てそうだなあという感じ。

慣れてるから書きやすいっていうのはあるし、何でも揃ってるから楽ではあるんだけど、やっぱりその分融通がきかなかったりはするので今後もRails脱却は進めていきたいところ。

ancient-5302623 1280

ブログをGatsbyJSからNext.jsへ変更した

Rails使うのやめるゆうて1年ほど過ぎました。

そうなるとバックエンドを何で書くんだって話になってとりあえずTSを選んだんだけど、どの言語を選んでも付きまとうのがマイグレーションやORMで、結局Prisma勉強したほうがいいわってことで再入門することにした。

とはいえ覚えることが結構多かったので写経ついでにメモもしておいて記憶を定着させたい。

## チュートリアル

Prisma、MigrationもExperimentalで利用可能になっていて、チュートリアルもそれぞれ用意されてる。

- [Start from scratch](https://www.prisma.io/docs/getting-started/setup-prisma/start-from-scratch-sql-typescript-postgres)
- [Start from scratch (Prisma Migrate)](https://www.prisma.io/docs/getting-started/setup-prisma/start-from-scratch-prisma-migrate-typescript-postgres)

実際はほぼ同じことが書いてあるんだけど、前者がMigrationを含まない場合のチュートリアルで、やってることはこの図を見るとわかりやすい。

![f7itiYw](//images.ctfassets.net/ra242vdzwrmo/1fECTKK0HSjFVYSXjqvHQj/4d365ac220b366043b8b1d89ef3c540b/f7itiYw.png)

[Introspect your database with Prisma](https://www.prisma.io/docs/getting-started/setup-prisma/start-from-scratch-sql-typescript-postgres#introspect-your-database-with-prisma) より引用。

DBに定義されているテーブルデータをPrismaが読み取ってスキーマファイルを吐き出すのがメインの処理で、 `prisma introspect` コマンドで実現されてる。

スキーマファイルはドキュメントにある通りこんなのが吐き出される。

```
model Post {
  id        Int      @default(autoincrement()) @id
  createdAt DateTime @default(now())
  title     String
  content   String?
  published Boolean  @default(false)
  User      User     @relation(fields: [authorId], references: [id])
  authorId  Int
}
model Profile {
  id     Int     @default(autoincrement()) @id
  bio    String?
  User   User    @relation(fields: [userId], references: [id])
  userId Int     @unique
}
model User {
  id      Int      @default(autoincrement()) @id
  email   String   @unique
  name    String?
  Post    Post[]
  Profile Profile?
}
```

### @prisma/client

`@prisma/client` は最初なんだかよくわからなかったんだけど、Prismaがスキーマを読み込んでJS上でORMのように振る舞うための情報を生成したりメソッドの提供をするライブラリっぽい。

ちょっと不思議な挙動をするんだけど、 `prisma generate` コマンドを実行すると `node_modules/.prisma` にスキーマファイルから生成したORM用のメソッド群を持つモジュールを吐き出すっぽい。

![FensWfo](//images.ctfassets.net/ra242vdzwrmo/3vsjEuRfBhNioFe6axulIK/112bd0e4db55b9e711b0090dff423b8a/FensWfo.png)

[Install and generate Prisma Client](https://www.prisma.io/docs/getting-started/setup-prisma/start-from-scratch-sql-typescript-postgres#install-and-generate-prisma-client) より引用。

## マイグレーション

ここがおもに覚えたかったやつ。まあどうせnpm scriptにしちゃうけど。

- マイグレーションの新規作成: `npx prisma migrate save --experimental`
  - `npx prisma migrate save --name init --experimental` で同時に名前を指定しちゃうこともできる
  - `rails g migration` と同義
- DBへの反映: `npx prisma migrate up --experimental`
  - `rails db:migrate` と同義

マイグレーションファイルは以下みたいなDSLだけど、まあ読みやすいし覚えることに抵抗はなさそう。ゆうてRailsのマイグレーションファイルもめっちゃわかりやすいわけではないし。

```
model Post {
  id        Int      @default(autoincrement()) @id
  createdAt DateTime @default(now())
  title     String
  content   String?
  published Boolean  @default(false)
  author    User     @relation(fields: [authorId], references: [id])
  authorId  Int
}
model Profile {
  id     Int     @default(autoincrement()) @id
  bio    String?
  user   User    @relation(fields: [userId], references: [id])
  userId Int     @unique
}
model User {
  id      Int      @default(autoincrement()) @id
  email   String   @unique
  name    String?
  posts   Post[]
  profile Profile?
}
```

ようは `prisma introspect` で吐き出されるものと全く同じやつ。

あとはPrismaで1プロダクト作って肌感身につけたいところ〜。

glass-roof-4564418 1280

Prisma再入門

Auth0最高って話じゃないです。

そもそもSPAとAPIの構成をもったアプリケーションでの認証とはどうあるべきなのか、どういうデザインパターンが存在するのかを全く知らずに作っちゃったのは良くないなと思った。

ということで何でもかんでもすぐ書いてみるのではなく、一旦手を止めて色々勉強してみたのでメモしておきたい。

## 何にもやもやしていたのか

前回の記事の内容でも動くには動いたんだけど、どうしてもそれが最適とは思えず、IDaaSを使うことによる恩恵がほぼないのでは、という印象があった。

例えばこういうこと。

- サーバサイドからAuth0のAPIを叩いてsignup/signinの管理をする方式が正しいのか
- クライアントでログイン状態を維持するために何の情報をどこに持てばいいのか

## Auth0が提唱するSPA、API構成の認証方式

Auth0のドキュメント、部分的にしか読んでなくていまさらこのドキュメントの存在に気づいた。

- [SPA + API
](https://auth0.com/docs/architecture-scenarios/spa-api)

ExampleCoという100人程度の社員を持つコンサル企業がタイムシート管理アプリをSPA、API構成で作る上でどうしていくか、というシナリオでドキュメントが構成されている。

### Auth0におけるAPIとApplication

Auth0にはApplicationという概念とAPIという概念がある。

APIには独自にPermissionを定義することができて、このドキュメントではタイムシート管理用の `read:timesheets` 、 `create:timesheets` などのPermissionを定義している。

Applicationはサインアップ、サインインの機能、UIを提供するためのもので、 `Regular web app` 、 `SPA` 、 `Native App` など利用元のプラットフォームを指定して使うことができる。

- [Applications in Auth0](https://auth0.com/docs/applications)

> Applications	
> Use this page to manage your applications. For every app of yours that you want to use Auth0, you should register an application here.

### API上の実装

以下ドキュメントにSPA & API構成でのNode.jsでの参照実装がある。

- [SPA + API: Node.js Implementation for the API](https://auth0.com/docs/architecture-scenarios/spa-api/api-implementation-nodejs#1-define-the-api-endpoints)

ユーザ情報の取得に関してはJWTをvalidateして取得している。

- [Determine the User Identity](https://auth0.com/docs/architecture-scenarios/spa-api/api-implementation-nodejs#4-determine-the-user-identity)

### Tokenの有効期限

SPAの場合TokenがExpireした場合、サーバ上に送ってJWTのValidationが失敗して初めて発覚するので少し問題になり得る。

- [Configure Silent Authentication](https://auth0.com/docs/api-auth/tutorials/silent-authentication#renew-expired-tokens)

この問題は [auth0.js](https://github.com/auth0/auth0.js) の機能によって解決できる模様。

> You can make a silent authentication request to get new tokens as long as the user still has a valid session at Auth0. The checkSession method from auth0.js uses a silent token request in combination with response_mode=web_message for SPAs so that the request happens in a hidden iframe. 


不可視のiframeを配置してその中で `checkSession()` の実行 & 再発行をしてくれるのかな？

## 終わりに

認証周りは本当に難しくて魔窟感ある。

IDaaSは便利なんだろうけど、楽できるとか何も考えずに認証機構を作れるという意味では少し違うのかもしれないと思った。

もう少しドキュメントを読んだりExampleを見たりして、再度手を動かして納得のいく実装になるまで挑戦してみようかと思う。

## 参考にさせていただきました

- [JWTを使った今どきのSPAの認証について](https://tech.hicustomer.jp/posts/modern-authentication-in-hosting-spa/)

ものすごく丁寧かつ包括的にまとめられていて感動しました。この方くらい深く広い洞察力を持ちたい😵

landscape-5298395 1280

Auth0再考、SPA & API構成のアプリケーションにおける認証について考える

しらんかった〜。

> fetch is not available in Node, which is where Jest is running your tests. Is it an experimental browser technology.
>
> You will need to polyfill the behaviour if you want to make actual http calls, or mock fetch to simulate network requests.
>
> https://github.com/facebook/jest/issues/2071#issuecomment-259709487

`yarn add -D whatwg-fetch` して

`jest.setup.js` に

```
const fetchPolifill = require('whatwg-fetch')

global.fetch = fetchPolifill.fetch
global.Request = fetchPolifill.Request
global.Headers = fetchPolifill.Headers
global.Response = fetchPolifill.Response
```

- [`fetch` undefined when running tests with jest](https://github.com/facebook/react-native/issues/11537)

cornflowers-5352633 1280

Jest実行時にReferenceError: fetch is not defined

[前回](https://blog.unresolved.xyz/retrospective-2020-q-1st/)。

もう6月が終わってしまう〜。まだ2ヶ月ぐらいしか経ってない気がするのに・・・。

とはいえ今回はあんまり書くことがないな、まあでもあとから見返すためにも書きたいので内容は薄くてもちゃんとやっておこう。

セクションわけがしっくりこないので、KPT形式で書いていこうかな。

## Keep

### 仕事にだいぶなれてきて自分の時間を持てるようになった

まあこれはリモートになったからというのが大きそう。

おかげで個人プロジェクトを進めたり趣味の時間にあてたりということができるようになったので、前よりは人間的な生活が出来てそう。

### 個人プロジェクトのモチベーションを保てている

これもリモートのおかげのように思う。

もともとあったエンジニアとしての焦燥感を解決できてるのでありがたい。

今やっていることはSPA/API構成のアプリケーションの実装なんだけど、やっぱりなんだかんだいってもバックエンドの実装がなくなることはないだろうなという気づきが多い。

なのでこのプロジェクトが一段落したら、この知見を更に深めてもいいし、バックエンドで違う設計や言語を試してみるのが自分のキャリアに貢献するかなと思ってる。

例えばメインのバックエンドとは別にServerlessのAPIを作ってみるとか、複数のバックエンド環境があるアプリケーションも試してみたい気持ちはある。

### ブログが書けてる

これも個人プロジェクトの相乗効果だけど、技術的なことをやればもちろん躓くし気づきもあるので、おかげでブログを書くことができている。

アウトプットの恩恵はまだそんなに受けることができてないけどこれは継続していきたい。まあつまり個人開発を続けていきたいってことでもある。

### 運動が続けられてる

ジムはもうコロナで解約しちゃったので、YouTubeの動画でHIIT系のトレーニングをしている。

正直ジムより効果が高いし継続もしやすいので、もう今後ジムを契約することはないかもなあと思ってる。

トレーニング以外にもウォーキング・ランニングが継続できているのでそれも良い習慣になってるなと思う。

最近は梅雨とウォーキングコースに飽きちゃった影響で頻度は少し減ったけど。

## Problem

### 本が読めてない

ちょっと怠け期にはいってるんだろうけど、最近は全然読めてない。

今クォータでは2冊ぐらい？漫画はめっちゃ読んでるけどそれはカウントする気はないので、進捗は悪め。

あまり無理して読めるものでもないので、これは倦怠期が過ぎるのを待つのがトライかなという程度の気持ち。

### 副業が増やせてない

そもそも副業を増やしたいのは居場所を増やしたいのと、個人開発だけだとプロダクションレディの技術になったとは言えないと思うのでそれをビジネスでも使ってみたいというのがある。

けどまったく動けてないのが現状で、これはまあ個人開発をもうちょっと続けてしっかりとしたスキルとアウトプットが出せるようになってからかなという気もある。


landscape-5289604 1280

2020-2Q振り返り

初めてIndexedDBを使ったんだけど、Jestが落ちるようになっちゃって直したのでメモ。

```
MissingAPIError: indexedDB API missing
```

議論はここでされてて、

- [Puppeteer, Jest, Unhandled rejection: MissingAPIError: indexedDB API not found](https://github.com/dfahlander/Dexie.js/issues/790)

これを使えば解決できる。

- [dumbmatter / fakeIndexedDB](https://github.com/dumbmatter/fakeIndexedDB)

jest.setup.jsとかに

```
import 'fake-indexeddb/auto';
```

を入れるだけ。

sea-5237374 1280

MissingAPIError: indexedDB API missing

React書くときはクラス名もローワーキャメルケースがいいなと思ってLintを設定しようとしたら色々手間取ったのでメモ。

stylelintのセレクタ命名は `selector-class-pattern` で設定できる。

公式にも汎用的な正規表現の定義が載ってるのでそれをパクってくればOK。

- https://stylelint.io/user-guide/rules/regex

```yml
rules:
  selector-class-pattern: "^[a-z][a-zA-Z0-9]+$"
```

bulb-5258341 1280

stylelintでセレクタ名にキャメルケースを強要する

dependabotのオートマージで夜中にデプロイ失敗したよってメッセージが来てた 😵

```
NoMethodError: undefined method `+' for nil:NilClass
  from sprockets/asset.rb:138:in `etag'
  from sprockets/asset.rb:67:in `block in digest_path'
  from sprockets/asset.rb:67:in `sub'
  from sprockets/asset.rb:67:in `digest_path'
  from sprockets/manifest.rb:175:in `block in compile'
  from sprockets/manifest.rb:173:in `each'
  from sprockets/manifest.rb:173:in `compile'
  from sprockets/rails/task.rb:68:in `block (3 levels) in define'
  from rake/sprocketstask.rb:148:in `with_logger'
  from sprockets/rails/task.rb:67:in `block (2 levels) in define'
  from rake/task.rb:281:in `block in execute'
  from rake/task.rb:281:in `each'
  from rake/task.rb:281:in `execute'
  from rake/task.rb:219:in `block in invoke_with_call_chain'
  from monitor.rb:230:in `mon_synchronize'
  from rake/task.rb:199:in `invoke_with_call_chain'
  from rake/task.rb:188:in `invoke'
  from rake/application.rb:160:in `invoke_task'
  from rake/application.rb:116:in `block (2 levels) in top_level'
  from rake/application.rb:116:in `each'
  from rake/application.rb:116:in `block in top_level'
  from rake/application.rb:125:in `run_with_threads'
  from rake/application.rb:110:in `top_level'
  from rake/application.rb:83:in `block in run'
  from rake/application.rb:186:in `standard_exception_handling'
  from rake/application.rb:80:in `run'
  from bundle/ruby/2.6.0/gems/rake-13.0.1/exe/rake:27:in `<top (required)>'
  from ./vendor/bundle/bin/rake:29:in `load'
  from ./vendor/bundle/bin/rake:29:in `<main>'
```
  
以下で解決できた。

```diff
-Rails.application.config.assets.version = '1.0'
+Rails.application.config.assets.version = 'v1.0'
```
  
- https://stackoverflow.com/questions/62208867/rails-deployment-to-heroku-nomethoderror-undefined-method-for-nilnilclass
- https://github.com/rails/sprockets/issues/683

canyon-5229681 1280

Heroku + Rails(Sprockets4.0.1)でassets:precompileがエラーする

最近[Next.js](https://nextjs.org/) + [TypeScript](https://www.typescriptlang.org/) + [GraphQL](https://graphql.org/)のスタックで個人PJを進めてるんだけど、Railsと違ってコードジェネレータがないのが辛かったので[Hygen](https://github.com/jondot/hygen/)を使ってみたときの些細なメモ。

## Hygenでのパラメタの先頭大文字や小文字化

結論言うとここに全部のヘルパが載ってる。

https://www.hygen.io/templates/#helpers-and-inflections

Reactだとファイル名やコンポーネント名をアッパーキャメルケースにしたり、変数名はローワーキャメルケースにしたりするので、適宜Helpersを使い分ければよさそう。

Hygenは簡単に使えちゃうのでDocumentをちゃんと読まなかったんだけど、テンプレートの章は目を通して損なさげ。

https://www.hygen.io/templates

拡張もできるらしい。

https://www.hygen.io/extensibility/#helpers


compass-5137269 1280

Hygenで大文字小文字の制御をする

前回に続いてローカルの作業自動化で何回か使ったので見失わないようにメモ。

``` ruby
Dir.glob('app/javascript/images/flags/improved/*.png').each do |file|
  img = Magick::Image.read(file)[0]
  thumbnail = img.resize_to_fill(512, 330)
  thumbnail.write(file)
end
```

記事にしなくてもTILでいいじゃんね。

## 参考にさせていただきました

- https://rmagick.github.io/resize_to_fill.rb.html

mountains-5055387 1280

rmagickで画像を一括リサイズする

最近やけに画像合成をサーバサイドでやることがあるんだけど、角丸の画像合成ってできるのかなって気になったので調べた & できたのでメモしときたい。

## rmagickを用いた角丸画像合成の実装

もう完全に動かしたコードのコピペだけどこんな感じ。ビジネス的な命名されてたところは雑に直したので動かなくなってるかもしれない。

``` ruby
class OgpGenerator < OgpGenerator::Base
  include Magick

  COMPOSIT_WIDTH = 300
  COMPOSIT_HEIGHT = 200

  def initialize(file_object:)
    @file_object = file_object
  end

  def exec!
    img = Magick::ImageList.new(Rails.root.join("app/javascript/images/og_image_background/v3.jpg"))
    composit_image = Magick::ImageList.new("app/javascript/images/composit.png")
    composit_image = rounded(flag_image, "#{COMPOSIT_WIDTH}x#{COMPOSIT_HEIGHT}>", 22)
    img.write(@file_object.path)
    img.destroy!

    true
  end

  private

  def rounded(source_image, geometry_string, radius = 10)
    source_image.change_geometry(geometry_string) do |cols, rows, img|
      # Make a resized copy of the image
      thumb = img.resize(cols, rows)

      # Set a transparent background: pixels that are transparent will be
      # discarded from the source image.
      mask = Image.new(cols, rows) { self.background_color = 'transparent' }

      # Create a white rectangle with rounded corners. This will become the
      # mask for the area you want to retain in the original image.
      Draw.new.stroke('none').stroke_width(0).fill('white')
        .roundrectangle(0, 0, cols, rows, radius, radius)
        .draw(mask)

      # Apply the mask and write it out
      thumb.composite!(mask, 0, 0, Magick::CopyAlphaCompositeOp)
      thumb
    end
  end
end
```

`rounded` メソッドに対象の画像とサイズ、角丸の大きさを渡して上から角丸になるように生成した画像を重ね合わせて合成した画像インスタンスを返してる。

新しい画像インスタンスを作ってるので元のインスタンスは変わらないことに注意（なので代入してる）。

ほとんど後述するSOFのコードのコピペです。

## 参考にさせてもらいました

- http://www.imagemagick.org/Usage/thumbnails/#rounded
- https://stackoverflow.com/questions/2716457/rmagick-rounded-corners

stairs-5146459 1280

rmagickで画像合成をするときにradiusをかける

よくよく考えたら1年に1回の振り返りでワークするわけないよなと思ったので定期的に振り返りたいと思う。

とはいえもう3月末になっちゃったのでクォータごとの振り返りにしよっかな。

## エンジニアとしてのこと

エンジニアとしてはまあ悪くないかな〜、相変わらずバグは出すけど順調に前に進んでるとは思う。たぶんね。

### 仕事のこと

結構ガチ目に転職を考えたりもしたけど今は前向きに仕事に取り組めてる。

考えた上で前向きにやるべきだって下した決断はきっと前のそれより強い気持ちなんだろうと思う。

やっぱり良くも悪くもベンチャーなのでモチベーションの起伏は激しくて、もうそれを常に上に留める努力をするよりも受け止めてしまう方がいいんじゃないかなと思い始めてる。

モチベーションが低いときはどうやったってダメだし、自分のせいにしても、人や環境のせいにしても何もかわんないよね。高いときはひたすらやるべきことをやろうぜって感じ。

組織が絡む事に関するモチベーションをコントロールするなんて、たぶん無理だよ。きっと良い付き合い方があるはずなのでそれはこれからも探していきたい。

### 個人PJのこと

3月なかばになってやっと着手できた。

それまではモチベを上げることができなかったのでやってなかった。
これまでの経験上そういうときに無理に始めてもあんまり良い結果がでないのはわかってたので。

やろうとしてるのは完全に未知の世界なので牛歩だけど、その分刺激的でもあるしエンジニアとしての技術貯金になってる実感があるのでとてもよい。

誰が言ってたか忘れたけど、失敗の場をどれだけ用意できるかがエンジニアとしての強さの1つになる、って本当にそうだなと思う。

できればある程度流入を稼げるサービスにしたいなあと思う。

貯金って書いて思ったけど、やっぱり今の働き方はこれまでの技術貯金を切り崩して生きてるところがあるなあって思う。もしくは経験貯金？

それがずっと不安でありストレスだったんだろうし、やっぱりプライベートでの研鑽はやっていかないといけないなと思った。

まだ隠居する年齢じゃないしね。できるならしたいけどね。

## プライベートのこと

プライベートもまあかわんないな、恵比寿に住むの疲れたのでもう逃げちゃったくらい。逃げてよかった。

体調も悪くないしジムも行けてる、筋肥大も実感できるようになってきたしちょっとモチベ持ててるかな最近は。

### 引っ越した

これまで住んだ中で一番広い家に住んでるけど広いって良いな〜って感じ。

あとギターをまた始めた。
サイレントギターを買ったんだけどやっぱりエレキほしいな〜ってなって先にアンプだけ買っちゃった。メンタル治ってきたんかな？

まだ届いてないから届いたらギター買うけど何買うか迷ってる。
あんまり高いのは買えないしね。

ハムバッカーとシングルコイルどちらかだけって言われたらどっちが満足度高いんかな〜。
いまんとこレスポールジュニアかPRSのSEを買おっかなって思ってる。

## 今年の目標の進捗

いちばん大事な振り返りをやらねば。

### 日常生活のこと

- スリーフィンガーの練習
    - **やってます。爪が短いので親指ピックを買いました。でも難しくて全然弾けないよ。**
- 食習慣の改善
    - **できてるんじゃないかなあ。たくさん食べると内臓が体力つかうことがわかったので食事量が減った。**
- 筋肉をつける
    - **できてるんじゃないかなあ。少なくとも腕と胸筋は変わってきてる。**
    - 毎日プランク
        - **やめました。これなしで！やめた理由は以下です。**
        - [Athlean\-X Shares 8 Bodyweight Exercises to Stop Doing Immediately](https://www.menshealth.com/fitness/a31340622/bodyweight-exercise-alternatives-athlean-x/)
- 英語
    - 毎日Cake
        - **これもやってないな、代わりに仕事では文面のやり取りのみ英語をできるだけつかうようにしてる。**
- がん検診もしくは人間ドック
    - **まだできてないよ〜。**
- 所属できる場を増やす
    - **まだできてないよ〜。**

### 技術的なこと

- GraphQLを使ってなんか作るぞ
  - **始められた〜、頑張ろう。**
- serverless frameworkを使ってなんか作るぞ
  - **まずは↑からなのでやってない。**
- Firebaseを使ってなんか作るぞ
  - **始めたばっかなのでやってない。**
- SPA/SSRのなんかを作るぞ
  - **始められた〜。**
- お金にならなくてもいいから0 -> 1の立ち上げのお手伝いがしたいぞ
  - **何もできてないし時間的に厳しいかなという感じはある、話があればやるけど。**

## 最近読んだ本

今年もちゃんと本を読むようにするぞ！でも漫画ばっか読んでるぞ！

### [人生の結論 $朝日新書$ \| 小池一夫 \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4022737824/)

これすごかったな〜、まじでこんな良い知見提供してくれてありがとうって感じ。まだ読み終わってないけどね。

小池さんTwitterフォローしててすごい好きだったんだけど、昨年亡くなっちゃったよね。

この本は1章がすごく短い（つまり章が多い）から目次をここに貼ったりはできないんだけど、1章はほんとに2ページとかだからさらさら読める。

寝る前にちょびちょび読むのがおすすめ。

僕が好きだったのはぱっと思い出せるやつだとこの2つかな〜。

- 人間関係が壊れるのはたいてい距離が近すぎるときか遠すぎるとき
- 師匠は旅の同伴者、いつか越えたっていいし違う道に進んだっていい

空で書いてるからちょっとニュアンス変わってるかもだけど。

### [あなたの人生の物語 \| テッド チャン, 浅倉久志 \| 英米の小説・文芸 \| Kindleストア \| Amazon](https://www.amazon.co.jp/gp/product/B00O2O7JEA)

セールで安くなってたから買っちゃった。

これ有名なあれでしょ！と思ったら実は短編集で、僕短編集好きじゃないからちょっと萎えちゃった。

有名なあれは読んでないけど短編自体は面白い。ちゃんと最後までよもって思ってる。

### [Amazon\.co\.jp： 人は、なぜ他人を許せないのか？ eBook: 中野 信子: Kindleストア](https://www.amazon.co.jp/gp/product/B0844GP2GP/)

これねえ、途中で読むのやめちゃったんだけどいい本だった。

ああ僕らのこういう行動ってこういう仕組みだから起きてるのね、っていうのがすごく実感できた。

Twitterとか見てて疲れたりするのも理由がわかったし、人間関係でよく起こるいざこざをちょっと俯瞰して見れるようになれるんじゃないかなって本。

著者の中野信子さん、こないだ普通にTVでててビビった。

### [オリエント急行の殺人 $クリスティー文庫$ \| アガサ・クリスティー, 山本 やよい, 山本 やよい \| 英米の小説・文芸 \| Kindleストア \| Amazon](https://www.amazon.co.jp/gp/product/B009DEMNUY/)

おまえアガサ・クリスティってキャラじゃないじゃんって感じではあるんだけど、これも安くなってたから買っちゃった・・・。

アガサ・クリスティはアクロイド殺ししか読んでなかったんだけど、これも「まじか〜〜〜〜〜」って感じの真実で良かったなあ。

アクロイド殺しに比べてポアロちょっと傲慢な感じしない？気のせい？

### [阿波連さんははかれない 1 $ジャンプコミックスDIGITAL$ \| 水あさと \| 少年マンガ \| Kindleストア \| Amazon](https://www.amazon.co.jp/gp/product/B072KQ9C8F)

なんか最近人間としてだめすぎて、恋愛とか漫画読んでりゃだいたい満足じゃね・・・？って感じになってきてしまった。

水あさとさんはもともとTwitterでフォローしてたから知ってたんだけど、作品を読んだのはこれが初めて。

なんかほんとにWeb漫画とかそういう感じの話なのかなと思ってたけど、結構ガチでしっかりした話ですごくよかった。焦らしがすごくてまじでじれったかった。

何より水あさとさんがめちゃくちゃたくさんの知識を持ってるんだろうな〜ってのがすごくよく分かるし、もう全方面読んでよかったなっていう感想しかでない作品だったな〜。

続きが楽しみ。

### [好きな子がめがねを忘れた 1巻 $デジタル版ガンガンコミックスJOKER$ \| 藤近小梅 \| 少年マンガ \| Kindleストア \| Amazon](https://www.amazon.co.jp/gp/product/B07N8ZT77X)

藤近小梅さんもTwitterをフォローしてたからこの作品も知ってたんだけどつい買ってしまった。

なんか王道なんだけどそれがいいんだよな〜30過ぎると。
いま出てるところまでだとめちゃくちゃ続きが気になるタイミングで切られてるのでまじで続きを待ってる。まじで。

cherry-blossom-1209577 1280

2020-1Qの振り返り

12月半ばにこの記事を出そうと思ってたのにもう年の瀬になってしまった〜〜〜。

でもちゃんと書こう。

前回はこちら

[2018年の振り返り、2019年からLang\-8社に入社します \- blog\.unresolved\.xyz](https://blog.unresolved.xyz/retrospective-2018-joined-to-lang-8/)

## エンジニアとしてのステージ

前も書いた気がするけど、自分のポテンシャル的に技術的限界に来たなあという印象がある。

特定の技術にdeep diveするだけの技術力もセンスもないということがわかったし、じゃあキャリアプランどうしようと考えることが多かった1年だった。

とはいえだから使えないエンジニアになったかというとそうではないと思うし、戦い方を変えていく必要性を強く感じた。

### Railsとのこれから

時代の潮流的に、バックエンドでViewまですべてやるのは終わる（これも前書いたな）と思うので、Railsは続けるにしてもAPI ModeでGraphQLエントリポイントみたいなポジションになるのかなと思ってる。

色々JSとか他のFWも触ったけど、やっぱりすべてが揃ってるRailsは楽だという結論に行き着いた。

なのでこれからもRailsは触っていくけど、フルスタックFWとしてのRailsはやらないだろうなあという感じ。仕事はそうなってしまっているのでそうしていくしかないけど。

## Lang-8での1年

たくさん学んだ一年だった。

自分じゃかなわない人ばかりの中で働くことで得られることの多さも実感したし、そこで働けることや貢献できることの嬉しさも学んだ。

昔、稲盛和夫さんの「生き方」って本を読んだことあるんだけど、

[生き方 \| 稲盛和夫 \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4763195433/)

当時は「なんでこいつこんな社畜精神なの？」と思ってよくわからなかったんだけど、それがハードワークをしてみてわかってきた気がする。

職場というのは5段階欲求でいう「所属と愛の欲求」を満たすのに最適な場で、そういう意味では仕事のために生きている（っていうぐらい本気でやって初めて見返りがある）、という見方は部分的には間違ってないんだなと思った。

## プロダクティビティの最大化

ハードワークしてるとなかなか継続的に結果を出すのが難しいことに気づいて、何より知らない間にメンタルにダメージを負ってることが多かったりした。

仕事にフォーカスするときも集中力が切れたりしてて、意識的に最高の結果を出すための努力をすることを学んだ1年でもあった。

例えばこんなこと。

- 休日に夜ふかしや長い昼寝をしない
- 普段からできるかぎり体を動かす

とにかく生活リズムに関しては変動のないルーチンにするのがよくて、できる限り体を動かして人間の体のつくりに適した生活（狩りをしていた時代に似た生活）をすべきだということがわかった。この辺は後述してる以下の本によく載ってる。

[時間術大全 人生が本当に変わる「87の時間ワザ」 \| ジェイク・ナップ, ジョン・ゼラツキー, 櫻井 祐子 \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4478106118)

### 仕事が終わらない問題を時間で解決しない

この辺の経歴になると、仕事が終わらないのは能力の問題ではなくて、

- 仕事量が多すぎる
- やり方が悪い

のどちらかになることが多くて、これを残業で解決してしまうと改善のチャンスを逃すことになって良くないと思った。（何よりそもそも残業しないんだけど）

とはいえ今いる会社は期限等に厳しくないし、やり方は相談すれば頭の良い人がアドバイスもくれるしそんなに困ったりはしなかった。でもこれからも1人でそれができるようにしていきたい。

少なくとも、時間をかけて成果を出す年齢ではなくて、短い時間でいかに集中して高品質な成果を出すかのフェーズにきたということを強く感じた。

## プライベートのこと

プライベートはほぼ捨ててた感あった1年だったな〜。

### 手術のこと

手術があったので年始から結構ドタバタしてた。

[AVMという病気の治療のため慈恵医大附属病院に4週間ほど入院してました \- Daisuke Tsuji \- Medium](https://medium.com/@dim0627/avm%E3%81%A8%E3%81%84%E3%81%86%E7%97%85%E6%B0%97%E3%81%AE%E6%B2%BB%E7%99%82%E3%81%AE%E3%81%9F%E3%82%81%E6%85%88%E6%81%B5%E5%8C%BB%E5%A4%A7%E9%99%84%E5%B1%9E%E7%97%85%E9%99%A2%E3%81%AB4%E9%80%B1%E9%96%93%E3%81%BB%E3%81%A9%E5%85%A5%E9%99%A2%E3%81%97%E3%81%A6%E3%81%BE%E3%81%97%E3%81%9F-38c8f11c942a)

まあ頭を開けるっていう意味ではいい経験だったし、障害も残らなかったし人生全体で見ればよかったかなという感じ。

手術のせいかタイポが増えました。

### お金の持ち方、使い方

できる限り形のないもの（健康や体験）にお金を使うように心がけてた。

あと、人間は使ったお金を基本すぐ忘れるという習性があるっぽいので、欲しいものはすぐ買うようにした。高すぎなければ。

余ったお金はほぼ全部投資に回してて、手元には200万いかないくらいしか残ってない状態にするようにしてた。

### デジタルウェルビーイング

時間の無駄すぎてSNS禁止にした。（Wantedlyのシェアときっとこの記事をはるくらいになる）

そして増えたのはKindleを開いてる時間。それだけ。

SNSによって不快に感じることも減ったしSNSを辞めるメリットはでかい。

## 来年の目標

今年はたくさんやりたいことがあるな〜！

### 日常生活のこと

- スリーフィンガーの練習
- 食習慣の改善
- 筋肉をつける
  - 毎日プランク
- 英語
  - 毎日Cake
- がん検診もしくは人間ドック
- 所属できる場を増やす

### 技術的なこと

- GraphQLを使ってなんか作るぞ
- serverless frameworkを使ってなんか作るぞ
- Firebaseを使ってなんか作るぞ
- SPA/SSRのなんかを作るぞ
- お金にならなくてもいいから0 -> 1の立ち上げのお手伝いがしたいぞ

## 読んで良かった本

今年は漫画も小説もたくさん読んだなあ。その中でも良かったものをまとめておきたい。

ここからはアフィリンクじゃないので心配せずに踏んでください。

### [ビッグ・クエスチョン―〈人類の難問〉に答えよう \| スティーヴン・ホーキング, 青木 薫 \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4140817739/)

「どうやって宇宙ができたの？」とか、「神は居るの？」みたいなでかすぎる質問をかのスティーブン・ホーキングがガチで意見を述べるみたいな、言ってしまえば勉強はしたくないけど答えだけ教えてよみたいな贅沢さを詰め込んだ本。

目次にあるものに興味が惹かれるならきっとおすすめ。

- 神は存在するのか?
- 宇宙はどのように始まったのか?
- 宇宙には人間のほかにも知的生命は存在するのか?
- 未来を予言することはできるのか?
- ブラックホールの内部には何があるのか?
- タイムトラベルは可能なのか?
- 人間は地球で生きていくべきなのか?
- 宇宙に植民地を建設するべきなのか?
- 人工知能は人間より賢くなるのか?
- より良い未来のために何ができるのか?

### [時間術大全 人生が本当に変わる「87の時間ワザ」 \| ジェイク・ナップ, ジョン・ゼラツキー, 櫻井 祐子 \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4478106118)

さっきも書いたけどこの本は良かった、色んな人にすすめた。

この本は2つの観点で時間術を提案していて、

- 無駄な時間を減らして時間を作る
- 効率を上げて時間を作る

僕は後者がとても参考になった。

効率的にカフェインを活用するとか、メンタルを整えてパフォーマンスをあげるとか、この本はエンジニアだけじゃなく頭を使う仕事をしてる人は誰でも参考になると思う。

### [進化の法則は北極のサメが知っていた $河出新書$ \| 渡辺佑基 \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4309631045/)

生物学者さんの研究に関するドキュメンタリーみたいな感じの本。

生物学に関して興味深かったというより、研究者って面白そうだなあって思った。来世では研究者もいいなって思った。

### [銀河核へ 上 $創元SF文庫$ \| ベッキー・チェンバーズ, 細美 遙子 \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4488776019/)

長らくの友人のhuyukiitoichi君が記事にしてたので読んだけど、とんでもなくよかった。

[多文化を乗せた宇宙船の、長い旅路──『銀河核へ』 \- 基本読書](https://huyukiitoichi.hatenadiary.jp/entry/2019/07/29/080000)

amazonのレビューにあるように、作者はきっと優しい人で卑劣なシーン（強奪とか侵略）がかなり薄くて、僕は逆にそれが良かった。ストレスになるので。

ストーリーは宇宙トンネルをあける業者に新人が入って、旅をしながら仕事をこなしていくというストーリーなんだけど、種族が非常に多い世界でかつ、各種族の性質をここまで緻密に描けるのかというぐらい細かく設定されていて、ストーリーよりそこが大きな魅力だと思う。

漫画で言うならヘテロゲニア リンギスティコの魅力と近いかなあという感じ。

[ヘテロゲニア リンギスティコ ~異種族言語学入門~ $1$ $角川コミックス・エース$ \| 瀬野 反人 \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/404107620X/)

### [無人島に生きる十六人 $新潮文庫$ \| 須川 邦彦 \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4101103216/)

ノンフィクション。明治31年に本当にあった出来事で、本当に漂流して生き抜いて来た話。

この話の魅力はサバイバルとかではなく、リーダーの聡明さや思慮深さだと思う。彼の才能や動き方っていうのはきっと現代でも活用できるもののはずなんだけど、もうそれができてる人は少数なのかもなあと思った。

### [ペンギン・ハイウェイ $角川文庫$ \| 森見 登美彦 \| 日本の小説・文芸 \| Kindleストア \| Amazon](https://www.amazon.co.jp/dp/B00AR76UAU)

「熱帯」でファンになった森見登美彦さんの他の本を読みたいなと思って読んだのがこれ。

名前は可愛いけど実際のところどうなのと思ったけど、実際のところも可愛く切ない話だった。

映画版も見たけどどっちもよし。少年のひと夏の思い出って感じ。

### [夜行 $小学館文庫$ \| 森見登美彦 \| 日本の小説・文芸 \| Kindleストア \| Amazon](https://www.amazon.co.jp/dp/B07YG2XY58)

なう読んでる。ホラー小説なんだけど普通に怖い。

### [働かないふたり　1巻 $バンチコミックス$ \| 吉田覚 \| 青年マンガ \| Kindleストア \| Amazon](https://www.amazon.co.jp/dp/B00Q7ZIXKG)

ニート兄妹の話なんだけど、兄貴がかなり達観した視点を持ってて、おだやかさの中にはっとさせられる場面があってよかった。

何回も読んでる。

### [新米姉妹のふたりごはん1 $電撃コミックスNEXT$ \| 柊 ゆたか \| マンガ \| Kindleストア \| Amazon](https://www.amazon.co.jp/dp/B019BQS7AI/)

百合路線なんだけど普通に料理の勉強になるし（料理嫌いだけど）面白い。続きが楽しみ。

### [ひとりぼっちの○○生活 $1$ $電撃コミックスNEXT$ \| カツヲ \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4048669842/)

ただ可愛いだけの本かと思って癒やしのために読んでたんだけど普通に面白くて泣ける。

### [後悔しない超選択術 \| メンタリストDaiGo \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4791627172/)

なんか無料だったから読んだけどそれなりに良かった気がするけどもう忘れたわ。

### [難しいことはわかりませんが、お金の増やし方を教えてください\! \| 山崎元, 大橋弘祐 \|本 \| 通販 \| Amazon](https://www.amazon.co.jp/dp/4905073243/)

お金に関する考え方という意味でめっちゃ参考になる。

christmas-balls-2995437 1920

2019年の振り返り

個人プロジェクトでGraphQLを使いたいとなったときに、リッチじゃないけどそれなりに管理しやすい安定したインフラを作ろうとすると結構困ったのでメモしておく。

動くものまで作れたわけじゃないので後日更新するかも。

## やろうとしていること

- BFFを挟んだSSRのSPAを作りたい
- APIはGraphQLでなんとかしたい

## 使おうとしているもの

- フロントはnowでnext.jsを載せようとしている
- バックエンドは何でもいいけどPrismaでマイグレーション & GraphQLのラップをさせようと思っている

## 選択肢として考えたもの

- [AWS AppSync](https://aws.amazon.com/jp/appsync/)
  - Prismaじゃなくなるけど、AWSのバックエンドに対してGraphQLでラップしてくれるっぽい
  - 個人プロジェクトでいきなりAWSか〜という感じはしたけど、結構信用できそうだし確度は高く考えてた
  - ただ、IaCまでちゃんとやろうとするとコストがかかりそうで、スピード感が落ちるのを懸念した、僕はインフラエンジニアではないし、今回身につけたいのはそこではないので
- [Cloud \| Prisma](https://www.prisma.io/cloud)
  - Prismaのマネジドサービス
  - そのままデプロイして使ったり、Herokuをバックエンドにして使ったりもできる
  - あとで書くけど、IaaSとしてプロダクションでは使うのは無理
  - 今回はHerokuバックエンドを使ってこのPrisma Cloudを使ってみることにした

## インフラの構成

最終的にはこう。

```
SPA(now) -> BFF(Prisma Client on Heroku) -> Backend(Prisma Server on Heroku with Prisma Cloud)
```

### BFF

ちょっとBFFとBackendがわかりづらいんだけど、BFF自体はリゾルバを持ったGraphQLエントリポイントで、フロントからもらったリクエストを元にBackendに通信をする。

雑に言うとBackendのPrismaをapollo-serverもしくはgraphql-yogaでラップしたもの。なのでこいつが外部公開される。

認証やデータの加工などの処理もここでやる。

### Backend

BackendはただのPrismaサーバ。データベースサーバみたいなもので、外部公開はされず、BFFのみがクライアントになる感じ。

ここには処理もなんにもなくて、PrismaがDBの前にたっているただのサーバ。なので一度立ち上げれば基本的に変更は入らない。

Prisma Cloudでもそれはできるんだけど、アクセス数の制限等があるのでできれば自分で持ちたかった。

あとPrisma Cloudは以下にあるように、

[Demo Servers $Prisma Cloud$ \- Prisma Docs](https://www.prisma.io/docs/prisma-server/demo-servers-prisma-cloud-jfr3/#limitations)

次を目的として使う想定の模様。

* Prototyping
* Learning
* Personal projects without a notable user base

そしてスロットリングもかかっているので無理したとしてもプロダクションでの利用は無理だと思う。

> Prisma Demo servers are rate limited to 10 requests per 10 seconds (on average).

### 余談

始めはBFFにバックエンドも混ぜようかなと思ってた考えてたけどそれはやめた。

以下の記事を読んで、BFFが完全にサーバサイドみたいな存在になるとそれってBFFではないよなと。

[Some thoughts on GraphQL vs\. BFF](https://philcalcado.com/2019/07/12/some_thoughts_graphql_bff.html)

Prisma、あとで捨てるのはほぼ無理なツールになると思うのでちょっとそこが懸念かな・・・。GraphQLはまだ成熟期ではないと思うので、そういう心配事は無視して進もうかと思う。

sand-dune-4319681 1280

ガチじゃないけどいい感じのインフラでPrismaを運用したいときの設計で悩んだので覚え書きしておきたい

リアルワールドで使っていくなら結局データの出し入れができないとなので、次はそこをやってみようと思う。

この辺をメインに参考にしていきます。

* [How to Set Up Basic Authentication with Apollo Server and Prisma \- Prisma Tutorials](https://www.prisma.io/tutorials/authentication-in-apollo-server-ct21)
* [pantharshit00/apollo\-server\-prisma\-starter](https://github.com/pantharshit00/apollo-server-prisma-starter)

写経みたいなものなので完全に備忘録。

## 言葉を整理する

登場人物が一気に増えるので整理しよう。

### GraphQL?

クエリランゲージ。欲しいデータ、ジョインしてほしいデータとかを問い合わせ時に全部指定できる。

RESTと対比されがちだけどこっちのほうがめっちゃ柔軟でいい感じ。まだまだ若いのでこれから成長していくんだと思う。

### prisma?

バックエンドにMySQLやPostgreSQLなどを選べるGraphQL実装、スキーマ定義をすれば必要なQueryやMutationをざっと吐き出してくれるツールみたいな感じ。

### apollo?

GraqhQLのサーバにつないだりリクエストを投げたりできる。

Reactプラグインもあったりしてかなり汎用的に使えるすごいやつ。

[世のフロントエンドエンジニアにApollo Clientを布教したい \- Qiita](https://qiita.com/seya/items/26c8a0dc549a10efcdf8)

## GraphQLサーバを立ち上げる

`prisma` が入ってるとdocker-composeでばしっと立ち上がる環境と一緒にplaygroundがついてくるので、

```
docker-compose up -d
```

でMySQLと一緒にデーモン起動して、

```
prisma deploy
```

でスキーマ反映して、（Railsでいうマイグレーションみたいなもの）

`package.json` に定義されてる `dev` スクリプトを流せば、

```
npm run dev
```

ブラウザでGraphQLが実行できるようになる。

### ここまでのまとめ

ちょっとかなりややこしいんだけど、

1. `src/index.js` がprismaの定義を見つつapolloのサーバを起動してつないでくれる
1. prismaは全Query、Mutationを吐き出してくれちゃうので、`src/resolver.js` に実際に使うクエリ定義を載せておく
1. なのでパスワードのハッシュ化などは `src/resolver.js` などで噛ませることができる
1. つまり読んでほしくないデータはここで塞ぐ

という感じらしい。つまりこいつはBFF相当の立ち位置になって、フロントエンドは完全に分離する設計になるのかなあ。

## JSON WEB TOKENを利用したログイン

`src/resolver.js` でmutationを追加する。

```js
login: async (parent, { username, password }, ctx, info) => {
  const user = await ctx.prisma.user({ username })

  if (!user) {
    throw new Error('Invalid Login')
  }

  const passwordMatch = await bcrypt.compare(password, user.password)

  if (!passwordMatch) {
    throw new Error('Invalid Login')
  }

  const token = jwt.sign(
    {
      id: user.id,
      username: user.email,
    },
    'my-secret-from-env-file-in-prod',
    {
      expiresIn: '30d', // token will expire in 30days
    },
  )
  return {
    token,
    user,
  }
}
```

## ベアラートークンを使った認証とコンテキストへの保持

次はQueryにcurrentUserを追加。

```js
const resolvers = {
  Query: {
    currentUser: (parent, args, { user, prisma }) => {
      // this if statement is our authentication check
      if (!user) {
        throw new Error('Not Authenticated')
      }
      return prisma.user({ id: user.id })
    },
  },
}
// Mutation: ....
```

`(parent, args, { user, prisma })` になっていて、userとprismaを渡せるように変わっている。

合わせて `srd/index.js` も対応。

```js
// Add this import to top of your file
const jwt = require('jsonwebtoken')

const getUser = token => {
  try {
    if (token) {
      return jwt.verify(token, 'my-secret-from-env-file-in-prod')
    }
    return null
  } catch (err) {
    return null
  }
}

const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({ req }) => {
    const tokenWithBearer = req.headers.authorization || ''
    const token = tokenWithBearer.split(' ')[1]
    const user = getUser(token)

    return {
      user,
      prisma, // the generated prisma client if you are using it
    }
  },
})
```

ログイン時に帰ってくるトークンをこんな感じで、プレイグラウンド下部にあるヘッダに設定したらちゃんと取れる。

![Screen Shot 2019-06-23 at 18.20.16](//images.ctfassets.net/ra242vdzwrmo/5FZwROKBHXn4MTfBXKjoDY/a0881bfd41884b7dcbf57dacc39463e6/Screen_Shot_2019-06-23_at_18.20.16.png)

というところまで来たので、次はインタフェースを作ろう！

## 参考にさせていただきました

* https://github.com/prisma/prisma/blob/master/docs/1.14/04-Reference/03-Prisma-API/03-Queries.md
* https://github.com/mizchi-sandbox/myjam/


ropes-4287995 1280

Apollo with Prismaで簡単なJWT認証を作るとこまで写経する

秘匿情報どうするかなと思ったけどとりあえず慣れてるやり方 & Docker化したりしても行けそうなdotenvでやってみようと思う。

ちなみにexampleがある。

[next\.js/examples/with\-dotenv at canary · zeit/next\.js](https://github.com/zeit/next.js/tree/canary/examples/with-dotenv)

気をつけなきゃいけないのは

* [motdotla/dotenv: Loads environment variables from \.env for nodejs projects\.](https://github.com/motdotla/dotenv)

はnodejs用（webpackではない）なので、

* [mrsteele/dotenv\-webpack: A secure webpack plugin that supports dotenv and other environment variables and only exposes what you choose and use\.](https://github.com/mrsteele/dotenv-webpack)

を使う。

## dotenv-webpackの導入

```
npm install --save dotenv-webpack
```

`.env` を置く。

```
touch .env
```

### next.config.jsの設定

exampleは間違ってる（1行目の `require('dotenv').config()` がいらない）ので注意。

```
const path = require('path')
const Dotenv = require('dotenv-webpack')

module.exports = {
  webpack: config => {
    config.plugins = config.plugins || []

    config.plugins = [
      ...config.plugins,

      // Read the .env file
      new Dotenv({
        path: path.join(__dirname, '.env'),
        systemvars: true
      })
    ]

    return config
  }
}
```

## 環境変数の参照

後は `process.env` 経由で好きに読める。

## 参考にさせていただきました

* [next\.js で \`process\.env\` 以下の環境変数を参照する \| :\-\) 🏕](https://9renpoto.netlify.com/2018/12/13/nextjs-enviroments/)

nature-4290442 1280

Next.jsでdotenvを使う

前回（[SSRを勉強したいのでインフラからやるぞ](https://blog.unresolved.xyz/learn-ssr-from-infrastructure/)）でとりあえずhello world的なのを外部公開まで行けたので、次はFWを使ったものでトライしてみたい。

## Next.jsでHello Worldまで

個人的にVueよりはReactを使いたいので、[Next\.js](https://nextjs.org/)を使おうと思う。

ひとまずHello World的なとこまで動くようにする。

[Documentation \- Getting Started \| Next\.js](https://nextjs.org/docs)

## プロダクションにのせる

pm2用にapp.jsonを作る。Next.jsなのでちょっとだけ工夫がいる。

[how can I use next in pm2? · Issue \#109 · zeit/next\.js](https://github.com/zeit/next.js/issues/109)

```
{
  "name" : "app",
  "script" : "./node_modules/next/dist/bin/next",
  "env" : {
    "NODE_ENV" : "development"
  },
  "env_production" : {
    "NODE_ENV" : "production"
  }
}
```

`name` がコンフリクトすることがあるので `pm2 delete all` とかやればこれまでのプロセスがきれいに消える。

あとは `pm2 start app.json --env production` で普通にいける。

次回はデプロイ周りを見るかソース触るかだな〜。

musical-background-2886886 1280

Next.jsをpm2で動かす

正直なところ、もうサーバサイドでDBアクセスもHTML生成もロジックもゴリゴリやる時代は終わると思っていて、2019年の後半はそこから手を引くためにいろいろとチャレンジしたい。

で、これからどうなると思ってるかと言うと、フロントに移った責務をフロントで処理するようになっていくんじゃないかと思ってる。

これまでもその流れが濃かったけど、ようやくプロダクションで当たり前にそうすべきでしょうというフェーズに踏み入れつつあるという空気を感じている。

フロントの責務が増えてきたにもかかわらず、実装はサーバサイドに取り残されていて、リッチなフロントを無理してサーバサイドで組み立てるのは限界が来ているように感じるし、いびつな状態で「とりあえず動くコード」をメンテしていくのはDXが低い、正直もうやりたくない。

というわけでこれからはSSR前提のフロントエンド開発をメインにやっていくぞ！ちなみにめっちゃ初心者だぞ！

## 最新のnodejsを入れる

[Ubuntuに最新のNode\.jsを難なくインストールする \- Qiita](https://qiita.com/seibe/items/36cef7df85fe2cefa3ea)

```
dtsuji@tk2-220-19763:~$ node -v
v10.16.0
```

最新って10だっけ？まあ新しい方ではありそうなので一旦おっけー。

## 適当なexampleを拾ってくる

SSRのコードなんて見たこともないしイメージもつかないのでexampleを使わせてもらう。まずはインフラのイメージをつけたいだけなので。

[mhart/react\-server\-example: A simple example of how to do server\-side rendering with React $no compilation needed$](https://github.com/mhart/react-server-example)

助かる。

## サーバをデーモン化する

nodejsアプリケーションのデーモナイズにpm2を使う。プロセスマネージャとしてデファクトぽいので。

[pm2でExpressアプリケーションをデーモン化する \- Qiita](https://qiita.com/daikiojm/items/0ac5d7e197ec4a5f8c40)

```
[PM2] PM2 Successfully daemonized
3.5.1
```

押忍。

雑にapp.jsonを置いて

```
{
  "name" : "app",
  "script" : "./server.js",
  "env" : {
    "NODE_ENV" : "development"
  },
  "env_production" : {
    "NODE_ENV" : "production"
  }
}
```

スタート。

```
pm2 start app.json --env production
```

ステータスを見る

```
dtsuji@tk2-220-19763:~/react-server-example$ pm2 show app                 
 Describing process with id 0 - name app                                  
┌───────────────────┬─────────────────────────────────────────────┐       
│ status            │ online                                      │       
│ name              │ app                                         │       
│ version           │ 1.4.0                                       │       
│ restarts          │ 15                                          │
```

いけてそう。

pm2、モニタリングとかも楽にできていいね。

### 外部からアクセスする

サンプルで使わせてもらってるソースが3000ポートでListenしてるので、iptablesを直す。

```
sudo vim /etc/iptables/iptables.rules
```

3000を許可。

```
-A INPUT -m state --state NEW -m tcp -p tcp --dport 3000 -j ACCEPT
```

反映。

```
sudo iptables-restore < /etc/iptables/iptables.rules
```

疎通したしSSRもできているので今回はここまで！

![Screen Shot 2019-06-23 at 10.33.03](//images.ctfassets.net/ra242vdzwrmo/63MKSvHSWYa103QyLsHTR1/f4386d52af3e5add1de5ff6e67af6266/Screen_Shot_2019-06-23_at_10.33.03.png)

次回はコードを読んだりしていくぞ。

swiss-4285605 1280

SSRを勉強したいのでインフラからやるぞ

例えばcanonicalやmetaタグにちゃんとした値が出てることもテストしたいとか。

system/feature specを使えば簡単だけどrequest specのほうがパフォーマンスいいし・・・。

## Capybara.stringのhas_css?メソッドを使う

``` ruby
expect(Capybara.string(response.body)).to be_has_css '.your-awesome-class'
```

## metaタグ、head内要素など見えないタグの場合

``` ruby
expect(Capybara.string(response.body)).to be_has_css '[content="noindex"]', visible: false
```

## 参考にさせていただきました

[Capybaraでドキュメント・メタデータが出力されていることを確認したい \| feedforce Engineers' blog](http://tech.feedforce.jp/capybara-rails_with_metadata.html)

waterfalls-4207893 1280

request specでもcssでマッチさせたい

いつも忘れてほんとに困るので。

```
heroku maintenance:on --app your-app-name

heroku pg:copy DATABASE_URL HEROKU_POSTGRESQL_COLOR_URL --app your-app-name
heroku pg:promote HEROKU_POSTGRESQL_COLOR_URL --app your-app-name

heroku maintenance:off --app your-app-name

heroku pg:info --app your-app-name

heroku pg:backups:schedules -a --app your-app-name
```

## 定期バックアップの設定

```
heroku pg:backups:schedule DATABASE_URL --at '4:00 Asia/Tokyo' -a your-app-name
```

## 参考にさせていただきました

https://qiita.com/takecian/items/e37bc5d2d753f600e7e6

flowers-3975556 1920

HerokuのPostgreSQLのプランを変更するときの移行手順メモ

haml、人気ですよね。僕もお手伝いしているプロジェクトでよく使われています。

とはいえlintまで入っていることは稀で、混沌としてしまっていることはままあります。

なのでじゃあそのまま混沌でいてくださいよってわけにもいかないので、一括置換でどこまで戦えるのかを試してみました。

> 結論いうと力尽きたのでぜんぜんだめです、2,3割は手動でやりました。

## チャレンジする環境

``` sh
$ cat ../../Gemfile.lock |grep haml
      haml (>= 3.0, < 5.0)
    haml (4.0.7)
    haml-rails (0.9.0)
      haml (>= 4.0.6, < 5.0)
      html2haml (>= 1.0.1)
    haml_lint (0.19.0)
      haml (~> 4.0)
    html2haml (2.2.0)
      haml (>= 4.0, < 6)
  haml-rails
  haml_lint
  
$ perl -v

This is perl 5, version 18, subversion 2 (v5.18.2) built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)

$ cat ../../.haml-lint.yml
───────┬─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
       │ File: ../../.haml-lint.yml
───────┼─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1   │ linters:
   2   │   LineLength:
   3   │     enabled: false
```

## 末尾にある不要なスラッシュを消す

``` sh
perl -i -pe 's/\/$//' **/*.haml
```

## 左のブレースに1つ空白をつける

``` sh
perl -i -pe 's/([^#]){([^ ])/\1{ \2/' **/*.haml
```

## 右のブレースに1つ空白をつける

``` sh
perl -i -pe 's/([^ ])}$/\1 }/' **/*.haml
```


## スクリプトのイコールのあとに空白をつける

``` sh
perl -i -pe 's/ =([^ |=|>])/ = \1/' **/*.haml
perl -i -pe 's/^( +)-([^ |=|>])/\1- \2/' **/*.haml
```


## ハッシュロケットの記法を統一

``` sh
perl -i -pe 's/:([a-zA-Z_-]+) =>/\1:/g' **/*.haml
perl -i -pe 's/" =>/":/g' **/*.haml
perl -i -pe "s/' =>/':/g" **/*.haml
```

## image_tagを使ってないところをできるだけ使う

``` sh
perl -i -pe 's/%img{ src: (.)}[/]/= image_tag \1/g' **/.haml
```

## 明示しなくていいdivを消す

``` sh
perl -i -pe 's/%div.(\w+)/.\1/' **/*.haml
```

## 末尾の空白を消す

``` sh
perl -i -pe 's/ +$//' **/*.haml
```

## コメントのシャープのあとに空白を入れる

``` sh
perl -i -pe 's/-#([^ ])/-# \1/' **/*.haml
```

## IDとCLASSの順序を整える

``` sh
perl -i -pe 's/(#\w+)(\.[\.|\-|\_|\w]+)/\2\1/' **/*.haml
```

fall-leaves-3744649 1280

カオスに満ちたhamlファイル群にhaml-lintを入れて一括置換でどこまで解決できるかやってみるよ

GitHubのSecurity AlertをOnにしていたら以下の様なAlertがあがってきた。

> CVE-2018-14732 More information
> low severity
> Vulnerable versions: < 3.1.11
> Patched version: 3.1.11
> An issue was discovered in lib/Server.js in webpack-dev-server before 3.1.11. Attackers are able to steal developer's code because the origin of requests is not checked by the WebSocket server, which is used for HMR (Hot Module Replacement). Anyone can receive the HMR message sent by the WebSocket server via a ws://127.0.0.1:8080/ connection from any origin.
>
> https://nvd.nist.gov/vuln/detail/CVE-2018-14732

webpacker3系はwebpack3系のラッパーで、webpack3系はwebpack-dev-server2系に依存している。で、webpack-dev-server2系に関する脆弱性らしい。

気持ち的にはさっさとwebpack4系にしたかったので、webpacker4系の安定版を待たずにRCの4系を使ってみようと思う。

CHANGELOGはここ。

https://github.com/rails/webpacker/blob/master/CHANGELOG.md

## Upgrade to webpacker v4.0.0.rc.2

とりあえずサクッとバージョンだけあげよう。

Gemfile

``` diff
- gem 'webpacker'
+ gem 'webpacker', '>= 4.0.0.rc.2'
```

package.json

``` diff
-     "@rails/webpacker": "^3.5.5",
+     "@rails/webpacker": "https://github.com/rails/webpacker",
```

## Reinstall binstubs.

binnstubが変わってるぽいので最新のもので再生成。

```
bin/rails webpacker:binstubs
```

## Regenerate configuration files.

あとで書くけど、babelやpostcssの設定ファイルのフォーマットが変わってるのでこちらも再生成。

```
bin/rails webpacker:install
```

## breakingなchanges（気になったやつだけ）

今使ってる3.5系からの差分をCHANGELOG見ながら読んだけどこんなもん？

### postcss-next is replaced with postcss-preset-env

さよなら・・・。`@apply`が仕様から落ちたのは本当に痛い。ので僕は一旦、postcss-nextを使い続けるようにした。

そのうち外す。

### Separate CSS extraction from build environment

エントリポイントであるJSから呼んだCSSをファイル展開せず、分割されたままheadに動的に埋め込むようにした？

https://github.com/rails/webpacker/pull/1625

webpacker.ymlに以下の記載をすることで設定ができるぽい。

```
  extract_css: true
```

trueにすればこれまでと同じ挙動をする模様？

### .babelrcと.postcssrcのフォーマットがJSに

babel.config.jsとpostcss.config.jsになった。

https://github.com/rails/webpacker/pull/1822/files

## 余談

webpacker4系になれば少しは薄いラッパーになるのかなあと思ってたけどそうでもないらしい。

webpackを自分で入れる運用にするべきか迷ってたけど、その気持ちが強くなった。

flower-3876195 1280

webpacker3系の依存してるwebpack-dev-server2系がCVE-2018-14732脆弱性に引っかかるのでwebpacker4.0.0.rc.2を使うようにした

highway-1209547 1280

[Rails5.1.3] Sass(SCSS)からwebpacker + PostCSSに移行してみるか

この記事は酔っ払いながら書いてるので正しくない可能性があります。

Railsをwebpacker + PostCSSに移行してそれなりにコードを書いてみたけど、ちょっと思うところや考えなければいけないことがあったのでまとめてみる。

[\[Rails5\.1\.3\] Asset Pipeline \+ SCSSからwebpacker \+ PostCSSに移行してみるか by 42 Design Work](https://42-design.work/technology/postcss-on-rails-with-webpacker/)

## PostCSSのリスク

PostCSSはすごく面白い仕組みで、なんかこの仕組を使ってるだけでわくわくしちゃうような仕組みなんだけど、組織で使うなら色々考えなければいけない部分もあるなと思う。

### 独自に進みすぎるリスク

まず誰もが感じるのはこれだと思う。

PostCSSはプラグイン形式でいろいろな機能を追加していけるので、ビュッフェ感覚で気軽にプラグインを追加できてしまう。

これはまさに秘伝のタレを作るようなもので、導入した本人はよくても、周りの人はそのルールを知ることが難しいし、結局文法が分離してしまうリスクになってしまうと思う。

### 過多になりすぎるリスク

webpackerではPostCSSのプラグインとして、デフォルトで以下の2個が入ってる。

* postcss-smart-import
* postcss-cssnext

これはまあいい落とし所だと思っていて、ギリギリ最低限のものに見える。

webpack側のローダーにはsass-loaderがあるので、Railsから移行する上でスムーズにいけるように、と考えられているんだと思う。

が、cssnextはちょっとプラグインが過多で、いきなり全部把握するのはちょっとむずかしい。
CSS4に準拠してるという意味ではまあ妥当なんだろうけど、個人的にいきなりcssnextを使うのはいいかなと思ったので使っていない。

## cssnextを使うか、cssnextのサブセットを構築するのが安全なのでは

というわけで、ここまで書いたようなことを感じたのもあって、先日書いた記事からPostCSSの構成をだいぶアップデートした。

どういう考えでどういうアップデートをしたのかをまとめてみる。

### Sassを実現しようとしない、cssnextで使われていないプラグインは使わない

とはいえcssnextは重要な指標になると思っていて、進むべき方向として参考にするには十分な存在だと思っている。
ものすごく安易でもはや自分で判断したものではないんだけど・・・。

cssnextは結局はプラグインの集まりなので、ここに使われているプラグインはある程度信用していいと思う。

CSS4の文法に則っているわけだし、もしプラグインが死んでも自分で作れる or 誰かが作る可能性が高いと思う。

そもそも、Sassの機能を使いたいならPostCSSに移行すべきじゃない。

### postcss-simple-varsを捨てる

これがめっちゃくちゃしんどかった。

変数なんてあっちこっちで使ってるし、記法が結構変な感じで変わるので置換もちょっとめんどくて・・・。

これまでは

``` scss
$font-size: 1rem;
.container {
  font-size: $font-size;
}
```

と書いていたのを、

``` css
:root {
  --font-size: 1rem;
}

.container {
  font-size: var(--font-size);
}
```

と書くようにする。ちなみにスコープが使えるようになるよ。僕は使ってないけど。

**追記: スコープは未実装でした。**

置換したコマンドはちょっとどれだったか覚えてないけど、これかな・・・。

``` sh
grep -rl "\\$" ./ | xargs perl -i -pe 's/\$([a-z|-]+)/var(--\1)/g'
```

動かなかったらすみません。

### postcss-nestingに乗り換える

僕はなぜかpostcss-nestedを使ってたんだけど、postcss-nestingに切り替えました。

これによって以下が、

``` css
.container {
  .element {
    font-size: 1rem;
  }

  .wrapper & {
    padding: 1rem;
  }
}
```

こう書かなければいけなくなりました。

``` css
.container {
  & .element {
    font-size: 1rem;
  }

  @nest .wrapper & {
    padding: 1rem;
  }
}
```

これは置換する方法がわからなかったので、1個1個手で・・・。
まだCSSのファイルが40くらいだったので、軽い痛みで済みました。

なんでわざわざ辛い方に行ったのかと言うと、これもやはりCSS4の仕様に追従するためです。
中途半端にSassの機能を引きずりたくなかったので。

### extendを捨てる

まあこれもSassで好きな機能だったんだけど、やめました。
postcss-applyを使えばだいたい同じことができます。

こう書いてたものが、

``` css
%filled {
  background-color: #fff;
  line-height: 1.25rem;
}

.container {
  @extend %filled;
}
```

こうなる。

``` css
:root {
  --filled {
    background-color: #fff;
    line-height: 1.25rem;
  }
}

.container {
  @apply --filled;
}
```

カレントセレクタはどうなんだろ、使えないと思う。

### mixinは残した

これはちょっとどうしょうもなかった。

他に代替的な仕様がないのか探したんだけど見つからなくて・・・。

## grepで除去できるものは使っても良いルール

最終的に、cssnextにないけど残したプラグインは以下の2個。

* postcss-hexrgba
* postcss-mixins

これらは最悪やめるときがきても、grepで引っ掛けられるからいいかなと。

### 今使っている.postcssrc.yml

``` yml
plugins:
  postcss-smart-import: {}
  postcss-mixins: {}
  postcss-apply: {}
  postcss-nesting: {}
  postcss-custom-media: {}
  postcss-custom-properties: {}
  postcss-hexrgba: {}
  autoprefixer: {}
```

わかんなくなったらplaygroundへ。

[cssnext Playground](http://cssnext.io/playground/)

以上です。

architecture-1477041 1280

今後もPostCSSを使っていく上でどうしていくべきかを考えてみた

久々に書く記事が年末の振り返りかよおまえ・・・って感じだけど・・・。

というわけであっという間に1年が終わってしまった。

今年はフリーランスやら技術顧問やらいろいろやったけどまあ前に進めたいい年だったのではないかと思う。

毎年やってるわけじゃないんだけど振り返りくらいしてみようと思う。

## フリーランスとして1年過ごした

これまでジョブホッパーとしていろんな会社で色んな経験をさせてもらった。

とてつもない幸運の持ち主なのでだいたいどの会社も居心地がよく、ホップしたのは本当に不義理なことをしてしまったと思う。

でもおかげで幅広い経験をさせてもらえたし、確実に糧になったし、僕自身は感謝してる。いつか恩返しもしたい。

というわけでホップしまくった結果、2018年（正確には2017年12月）からフリーランスとして仕事をしていた。

誰もがイメージするキラキラした感じのはたらき方ではなく普通にフルコミットで仕事しまくってたけど、別に食えなかったり実質ニートになったり死んだりもしなかった。

フリーランスになってどうだったかというと、まあお金には余裕ができた。税金でどれくらい持ってかれるか次第ではあるけど。

お金が増えても幸福度はあがらんみたいな記事を見るけど、意外とそうでもなく、今のところはある程度比例してあがってる。

仕事もありがたいことに途切れることなく、次の仕事を探さなきゃいけないみたいな強迫観念もない。

実際のところフリーランスになるのはそんな難しくないなとも思った。

スカウトが来たときに「業務委託でいいですか？」って言ってしまえばそれで晴れてフリーランスなんだということに気づいた。

エンジニアは今、空前絶後の売り手市場だから、もしなりたい人はさくっとなってみるといいと思う。

手続きも大変みたいなことよく聞くけど僕はそんなに大変じゃなかった。周りにそういうのに詳しい人が数人居たっていうのもあったと思うけど。

この辺のお話が聞きたい人はなんでも話すのでぜひ聞いてほしい。

## 技術顧問というはたらき方

僕は12月現在で4、5社並行して仕事をさせてもらっていて、そのうち1社は技術顧問として小さなチームに対してアドバイスをしたりしてる。

技術顧問という言葉はかっこよすぎてあまり使いたくないんだけど、昨今はそもそもそういうポジションも必要だしやってる人はアピールしてったほうがよいのでは？という流れもあるっぽいので、せっかくだし僕の例をまとめてみたい。

技術顧問というはたらき方はきっと千差万別で、人や会社によって全く違うのが現状だと思う。

僕がやってるのはだいたい次のことで、ほとんどリモートでやっている。

* 全体設計
* 命名のアドバイスやルールぎめ
* コードレビュー
* 難しい機能のベース実装と引き継ぎ
* 非エンジニアとの対話
* 新しい技術トレンドやニュースの共有
* 自分が得た知見や失敗の共有
* 採用のフォロー
* たまに飲み会で話を聞く

ポジショントークになってしまうのだけど、少人数のチームには技術顧問という立ち位置の人間がいることの恩恵はとても大きいのではないかと思う。

よくエンジニアが口にする言葉として「技術的負債」というものがあるけど、まずこれを作らないようにすることや、タスクに対して大きな手戻りがないように進め方をアドバイスしたり、テストの書き方やLintの設定、依存性の管理、インフラの設計や監視、アラートの設定など、経験がものをいうポイントでのアドバイスはチームのヘルスケアとして確実に貢献すると思う。

システム開発は考えるべきことが本当に多くて、これを経営者に寄り添いつつエンジニアの味方として考えられる存在がいると、確実にシステムの寿命が伸びる。

ありがちな話に、外注が作ったシステムが運用できなくて内製にしたいけど採ったエンジニアがつらい思いをする、みたいなものがあるけど、そういった場面も防げる。

会社と同じで、システムは作って終わりではなく、維持しなければ意味がない。そういった部分で問題が顕在化した結果、技術顧問という立場の人間が必要とされる時代になったんだと思う。

ちなみにこれは顧問をやる方の恩恵もあって、やっぱりそれでチームが良くなったり開発体験を良くしてあげられると本当に嬉しい。

若手が育つのを見れるのも嬉しいし、エンジニア界隈全体に少しは貢献できているのではないか、と思えたりもする。

なのでそういう話が来たらぜひ一度受けて見るといいと思う。

というわけで、Rails関係でそういう感じの人間がほしい会社さんあればやりますよ。スタートアップでエンジニア1、2人規模がいいな。

## プライベートの方

まあぼちぼちという感じ。

ゲームしたり個人開発したり本読んだり引っ越したり特につらいことはなく過ごした一年だった。

個人開発の方は1つちゃんとリリースして、もう1つリリースしたいけど時間がなくて何もできてないやつがあったりする。

個人でプロダクトを持つというのは技術研鑽、運用のスキル、コスト管理、監視、ディレクション、デザイン、モチベーション管理、あらゆる面でいい経験になる。

実際に個人開発しようとしたとき、まず抵抗があるのはデザインスキルとかだと思うけど、別に、自分のブログを自分で運営する、くらいでいいと思う。

自分ひとりである程度全体が見れるようになると本当にできることの幅が広がる。

もちろん躓くけど、その経験はきっと仕事でも活かせる。エンジニアとしてやってよかったと思うことの1つ。

あと、フリーランスになってから、仕事でもプライベートでも、良くも悪くも自分本位な生き方をするようになったなと思った。

時間がなければ仕事は断るし、お金が悪くても断るし、言いづらいことも言わなきゃいけない場面が増えた。

これはまあ長期的に見れば大人として生きていく上で必要なスキルだったのかなと思う。個人的には結構手に入れてよかったスキルだと思ってる。

思えばフリーランスとして複数社ではたらいたことで、そこで関わった人とプライベートで飲みに行ったりする機会が増えた。

これまでもなかったわけじゃないんだけど、それ以上に交流が大きく広がったのは今思えばフリーランスというはたらき方のメリットなのかと思う。

現場を離れたあとでも繋がれるのはありがたいし、困ったときにはぜひお手伝いしたいと思える相手がいるのはエンジニアとして生きていく上での貢献感につながる。

正社員だとそういう意味で幅の広がりに欠けるのが寂しいところだったりするかもしれない。

## Lang-8社に入社することになった

フリーランスとしてフラフラしまくってたら年末間際に拾ってもらった。

正社員は全く考えてなかったけど、フリーランスでやっていくぜ！みたいな気概があったわけでもないので、まあいっかってことでさくっと決めた。

Lang-8社自体はもともと知っていて、なんか難易度高そうなサービスやっとるなー、作るの大変そう、くらいの認識はあった。

もともとはCTOの[八木@sys1yagi](https://twitter.com/sys1yagi)さんから声をかけてもらって業務委託で入ってたんだけど、社員になってくれっていう話とまあ長く居たい気持ちはあるなというのがマッチしたので入社の流れとなった。

まあ、英語の勉強をしている身でもあったし。（サボりまくりだけど）

入社は1月なので厳密にはまだ業務委託なんだけど、Railsの開発者として[HiNative](https://hinative.com)の面倒を見てる。

設計やら何やらで改善点は多くあるけど、それでもテストが書いてあったり、つらい時期でも丁寧に育てられてきたサービスなんだろうと思ってる。

技術的に最適化すべきポイント（技術的負債とは言いたくない）は多々あれど、それはこれから率先して直していきたいし、それ以上にサービスを成長させるためにコミットしたいと思う。

というわけで次は長く腰を据えるつもりだという表明も込めてここで報告としたい！

あと語学勉強中の人はぜひ使ってみてください。

[HiNative \| 全ての外国語学習者のためのQ&Aサービス。](https://hinative.com)

ユーザテストも募集してるよ、気軽に声かけてね。

## 2019年はこれをやるぞ

10月頃まではとにかく仕事しない生活をしようと努力してきたんだけどなかなか思うように行かず、結局仕事漬けの1年になってしまった。

なんだかんだ12月になってみると、2019年はちゃんとプロダクトにコミットしたいな〜という気持ちになってしまったので、まあそれはLang-8社で頑張ろうかと思う。

というわけでエンジニアとして頑張るという曖昧なのが1つ。

もう1つはお金のことをちゃんと考えたいと思ってる。

具体的に言うと資産運用で、ずっとこれまでもやってみたかったんだけどなかなかイメージがわかず、それがようやくなんとなくやれそうな具合の余裕がでたので挑戦したい。

最後の目標はQOLを今よりあげること。

これは年内ずっと言ってたんだけど、人生の意味はよくわかんないけどQOLを上げるのは間違いなく正しくて、そのためにはお金をある程度使うべき（むしろ使わなきゃいけない）ということに気づき始めた。

なので来年は今以上にそういった生きやすさとか、過ごしやすさを重視して生活を改善していきたい。

締まらない感じになってしまったけど2019年も自分の人生最優先で頑張るぞ。

良いお年を。

rail-3678287 1280

2018年の振り返り、2019年からLang-8社に入社します

これ詰まったのでメモ。

```
yarn add git+ssh://git@github.com/[username]/[repository].git
```

`package.json`の`main`にCSSを指定できるのはじめて知った。

dandelion-3597681 1280

GitHubのレポジトリをsshでyarn addする

最近フリーランスとして技術顧問業をちょこっとだけはじめたので、組織づくりのためにいろいろツールを決めようとしたんだけど思ってたより難しかったのでメモ。

2018年9月現在の定番どころはだいたい検討できたんじゃないかと思う。

## 要件

* できれば無料、安く済ませたい
* 検索機能が強いほうがいい
* 下書きやスライドモードなど高機能さは不要、むしろ無いほうがいい
* カテゴライズはできてほしい
* Markdownで書きたい
* 日記や日報のような使い方ではなく、あくまでWikiのような使い方にしたい

## [esa \- A document sharing service for motivated teams](https://esa.io/)

1人500円/月。

僕が今お手伝いしている会社さんだと、一番多いのがesa。

個人的にはいうほど不満はなくて、まあ思考停止でこれにしちゃってもいいかなとは思ってるくらいに満足。

### 気になるところ

* 最近動作が遅い？
  * サイドバーの動作が遅いのが辛い・・・
* WIPはなくていい
* 導線設計がちょっと使いづらい
* 階層設計がむずい、だいたい破綻する

## [Scrapbox \- Realtime Knowledge Base \- Capture ideas in context](https://scrapbox.io/)

ビジネスの場合は1人1,000円/月。

最近話題のScrapbox。気になってたので今回まず導入して使ってみた。

他のドキュメンテーションツールと違って共同編集がとても強く、MTGのアジェンダ等の管理はとてもしやすかった。

完成度の高さゆえに、アジェンダ上で議論ができてしまうレベルだったので、それはそれで・・・という感じはあった。（運用次第だけど）

ページ同士がリンクしやすくなるのは本当に便利でよくできていて、これはドキュメントが増えていっても破綻しないだろうなという体験だった。

これのおかげで、ちゃんとしたドキュメントを作りたいときも、とりあえず書き捨てたいときも使えるサービスになっていると思う。

### 気になったところ

* やっぱりMarkdownが使えないのは辛い
  * [markdownはデカイ文字を書くのに便利 \- 橋本商会](https://scrapbox.io/shokai/markdown%E3%81%AF%E3%83%87%E3%82%AB%E3%82%A4%E6%96%87%E5%AD%97%E3%82%92%E6%9B%B8%E3%81%8F%E3%81%AE%E3%81%AB%E4%BE%BF%E5%88%A9)
  * 上記にあるとおりで、僕らはでかい文字を書くためにMarkdownを使っているので、それが書きづらいのはやはり体験としていいものではなかった
  * 文書の構造化がしたいわけではなく、ここからちょっと違う話になるぞ、っていうのを1ドキュメント内で区切りたいときに使いたい

## [Kibela \- a new communication tool to fuel the team](https://kibe.la/en)

5人まで無料。

Kibelaも実際に使ったことがあるサービス。

WikiとBlogで別れていて、使用体験としてはesaと変わらない感じ。

無料で5人まで利用可能なのがめちゃくちゃ魅力的。

### 気になったところ

* デザインが発展途上？
  * 全体的に整っていない感じがある
  * ドキュメントを読んでいて気になってしまう
* 個人的にBlogとWikiは別れていなくていいかな・・・
  * 使い方にこまってしまう
* ダッシュボード？トップページがただ情報が羅列されているだけなので、うーんという感じがしてしまう

## [Notion – The all\-in\-one workspace for your notes, tasks, wikis, and databases\.](https://www.notion.so/)

ストレージの容量制限はあるが人数無制限で無料。

Twitterで流れてきて知った。

ドキュメンテーション特化ではなく、タスク管理とか簡単なデータ管理もできる模様。

これは今回は採用しなかったけど、いずれ使ってみたい。

## [marchily \| 仕事見える、チームちかづく](https://www.marchily.jp/)

1人800円/月。

最近出てきたやつ？

デザインがめちゃくちゃかわいい。ちゃんとWebまでやれるデザイナさんがやってるんだろうなという感じ。

実際に使ってるわけではないのだけど、金額の面で採用しなかった。

### 気になったところ

* 「タスク管理にアソビの要素を!」はあんまり同意できないかも・・・
* バッジやタスクみたいな機能もあるみたいだけど、今回はシンプルにドキュメンテーションがしたかったので要件に合わなかった

## [情報共有ツール DocBase$ドックベース $ \| ストレスフリーなドキュメント共有ツール](https://docbase.io/)

3人まで900円/月。

これまったく知らなかったんだけど、意外とよくできてそうでびっくりした。なんか雰囲気的に大手企業向けなのかなって思った。

デザインもよさげで、テンプレートが作れたり機能的にもほとんど不満なく使えるんじゃないかなという感じ。

今回はお金の面で利用をしなかった。

## 参考にさせていただきました

* [ブラウザ上でいつでもどこでもメモが書けるサービスの個人的比較 \#webサービス \- mimemo](https://mimemo.io/m/3A2wRoN8741zM6X)

creative-869200 1280

Scrapbox、esa、kibelaあたりのドキュメンテーションツールを検討比較したのでまとめとく

ずっと放置してたポートフォリオをメンテした。

[Portfolio \- Daisuke Tsuji](https://yet.unresolved.xyz/)

## 依存性を整理した

[prop\-types](https://www.npmjs.com/package/prop-types)とか勉強がてら入れてたけど、ただのペライチに不釣合いだったので削除した。

加えて[styled\-components](https://www.styled-components.com/)に移行したりした。

ついでに以下の対応もやった。

[CircleCIでyarn upgradeとかbundle updateをやってプルリクを作ってもらう \- unresolved](https://blog.unresolved.xyz/continuous-dependency-update/)

## 構造のリファクタ

無駄にコンポーネント化されてたりしたのでフラットな感じに変えた。

ちょっとメンテせずに戻ってきたときにめちゃわかりづらかったので、たぶん良い構造ではなかったんだと思う。

## 404対応

ポートフォリオはGitHubのWebHookで[Netlify](https://www.netlify.com/)にデプロイされるようになるんだけど、create-react-appで作ったやつをそのままのせると、どんなURLでも200になってしまう。

ので、リダイレクトの設定をこうした。

`public/_redirects`

```
/ /index.html 200
/* /index.html 404
```

雑。

## 内容の更新

個人プロジェクトとかフリーになってからの経歴がのせられてなかったので追加した。

あと無駄な情報を削ったりもろもろ。


flamingo-3526365 1280

ポートフォリオをちょっとメンテした

ほんとにライフチェンジングなのでやってない人はぜひやってみてほしい。

<blockquote class="twitter-tweet" data-lang="en"><p lang="ja" dir="ltr">CIでまいにちbundleとかyarnのアップデートやらせるやつまじで革命的な生活だからもっとはやくやればよかったと思ってる</p>&mdash; dtsuji (@dim0627) <a href="https://twitter.com/dim0627/status/1013387079890264064?ref_src=twsrc%5Etfw">July 1, 2018</a></blockquote>

有志が以下のような素晴らしいツールを公開してくれているので、これらをありがたく使わせてもらう！

* [masutaka/circleci\-bundle\-update\-pr: Create PullRequest of bundle update in CircleCI](https://github.com/masutaka/circleci-bundle-update-pr)
* [taichi/ci\-yarn\-upgrade: Keep NPM dependencies up\-to\-date with CI, providing version\-to\-version diff for each library](https://github.com/taichi/ci-yarn-upgrade)

## CircleCIで依存ライブラリのアップデートを回す

僕はこんな`config.yml`を使っている。

``` yml
version: 2
jobs:
  build:
    # your default build scripts.
  bundle-update:
    docker:
      - image: circleci/ruby:2.5.1-node
    steps:
      - checkout
      - restore_cache:
          name: Restore bundler cache
          key: rails-demo-{{ checksum "Gemfile.lock" }}
      - run:
          name: Setup requirements for continuous bundle update
          command: gem install -N circleci-bundle-update-pr
      - deploy:
          name: Continuous bundle update
          command: circleci-bundle-update-pr $GIT_USER_NAME $GIT_USER_EMAIL

  yarn-upgrade:
    docker:
      - image: node:6-alpine
    steps:
      - run: apk add --update --no-cache git openssh-client
      - checkout
      - run: yarn global add ci-yarn-upgrade
      - run: yarn install
      - run: ci-yarn-upgrade --execute --verbose --latest;

workflows:
  version: 2
  build_and_test:
    jobs:
      - build
  nightly-bundle-update:
    triggers:
      - schedule:
          cron: "0 0 * * *"
          filters:
            branches:
              only: master
    jobs:
      - bundle-update
  nightly-yarn-upgrade:
    triggers:
      - schedule:
          cron: "0 0 * * *"
          filters:
            branches:
              only: master
    jobs:
      - yarn-upgrade
```

CircleCI上のcronはUTCで回るので、日本だとAM9時に処理がされる。

## サービスにやらせるならこれ

たぶん王道はこの辺なのかなー。

* [Dependabot \- Automated Dependency Updates](https://dependabot.com/)
* [renovatebot/renovate: Automated dependency updates\. Flexible, so you don't need to be\.](https://github.com/renovatebot/renovate)
* [Greenkeeper \| Automate your npm dependency management](https://greenkeeper.io/)

どちらもセルフホスティングできるはずなので、お金払いたくないなら自分でたてちゃえば済むと思う。


dark-1845065 1280

CircleCIでyarn upgradeとかbundle updateをやってプルリクを作ってもらう

もう移行終わっちゃったけど、最近いろいろ考えることが多かったのでまとめてみる。

## 何を決めるべきなのか？

そもそも選択肢が多いのがわるい。

よくあるパターンとメリット・デメリットはこんなもん？

### どこかのプラットフォームを使う場合

メリット

* 画像の圧縮だいたいやってくれるはず
* 管理コストがない
* ドメインが強いかも

デメリット

* 融通きかないかも
* HTML汚いかも（ゆうて自分で書いても汚い）

### 自作する場合

メリット

* いくらでも融通がきく
* 1プロダクトになる

デメリット

* インフラめんどう
* お金かかるかも
* メンテめんどう

## 何を目的にするのか？

そもそもブログってなんなんや

* ブランディング
* 個人メモ
* ブログ自体がサンドボックス

## 具体的にどんな手段があるのか？

多分こんなもん。

* [Medium](https://medium.com/)
* [Hatena Blog](http://hatenablog.com/)
* [Hugo](https://gohugo.io/)
* [GatsbyJS](https://www.gatsbyjs.org/)
* [Contentful](https://www.contentful.com/)

[Contentful](https://www.contentful.com/)は広告で知ったんだけど、そのときからこれすごくいいじゃん！と思ってて、まあこれを機に使ってみたい気はする。

でも管理画面クソ難しい。

## やっぱり自分で作りたい

楽したい気持ちもあるけど自分で作りたい気持ちもある。

### [GatsbyJS](https://www.gatsbyjs.org/) + [Netlify](https://www.netlify.com/)

* なんだかんだ触ってみたい[GatsbyJS](https://www.gatsbyjs.org/)
* [Contentful](https://www.contentful.com/)と連携させれば画像圧縮うまくやれんじゃ？
* これにしよう！新しいものをやりたい

### [Hugo](https://gohugo.io/) + [GitHub Pages](https://pages.github.com/)

* [Hugo](https://gohugo.io/)はまだまだ勢いがあるし枯れてるようで枯れてない
  * 最近追えてなかったのもなんか心残りだったし
  * でも飽きた感はある
* GitHub PagesもHTTPS対応したのでもう[Netlify](https://www.netlify.com/)はいい気がする、ポートフォリオだけそっち
* CircleCIで自動デプロイの環境を作ろう
* デザインをゼロから真面目に作る

## ポートフォリオもなんとかしろ問題

* マジ404の対応とかできてないしひどすぎ
* メンテしろ
* なのでポートフォリオは別でやる
  * [Nuxt\.js](https://nuxtjs.org/)でも使おうかな


new-york-city-336475 1280

エンジニアは技術ブログをどこで運用するのがいいんだ問題

Docker Composeいいよね。
めちゃくちゃ手軽に使えるし、慣れたらもう戻れない媚薬感がある。

僕の開発環境はcomposeで構築していて、Railsが載ってるWeb用イメージはRubyの公式Dockerイメージをベースに使ってるんだけど、
これだとDocker上で日本語が受け付けなくて何かと困ることが多い。

元のDockerfileは以下で、`FROM debian:jessie`でわかるようにdebianが使われてる。

[ruby/Dockerfile at 7a3e1295bbc840c350fc37d406692301b27f4e86 · docker\-library/ruby](https://github.com/docker-library/ruby/blob/7a3e1295bbc840c350fc37d406692301b27f4e86/2.3/slim/Dockerfile)

debianのロケール設定はUbuntuともちょっと違ったりして、調べて出て来る情報だと全然解決できなかったりする。
そして毎回この問題で困ってる自分も嫌なので、備忘録として残しておきたいと思う。

ちなみに**結論からいうと**、僕の場合の解決方法はこうだった。

```
ENV LANG C.UTF-8
```

## なぜ日本語を受け付けないのか

いろいろ調べてみるとロケールの設定によるものらしい。
この辺は小難しいのであんまり理解できてないけど、そのうちちゃんと勉強したいところ。

* [docker の ubuntu イメージで日本語が入力できない件 \- しゅんログ](http://shunlog.hateblo.jp/entry/2016/04/13/114059)
* [Docker1\.11 / Ubuntu14\.04 でコンテナの bash から日本語入力できない時 \- Qiita](http://qiita.com/narupo/items/ebee3018fb302365c053)
* [Docker＋Ubuntuで日本語入力できないのを解決した - nocorica](http://blog.nocorica.jp/2017/01/docker-ubuntu-japanese-input/)
* [Docker: Bash で日本語入力を扱う \- Sarabande\.jp](http://blog.sarabande.jp/post/129574578518)

だいたいは言語のパッケージを入れて、ロケールを設定すればいけるよっていう説明なんだけど、
Debianだとちょっと勝手が違ったり、そもそもそれじゃ直らなかったりする。

### Language Pack

Ubuntuだとこんな感じで、言語パックが導入できるらしい。

``` sh
apt-get install language-pack-ja-base language-pack-ja
```

これがDebianだとこう。

``` sh
apt-get install task-japanese
```

まあ**これが原因じゃなかった**んだけど、UbuntuとDebianでこんな些細な違いがあったりするんだなと。

## 日本語を打てるようにする

散々探し回ったのに、この記事で完璧に説明されていた・・・。


> たぶんLANG設定をすればうまくいきます
>
> FROM ruby:2.2.3
> ENV LANG C.UTF-8
>
> [Docker Compose でローカルの Rails 開発環境を作る \- Qiita](http://qiita.com/kbaba1001/items/39f81156589dd9a0d678#comment-6ed4ff57c5a4263b36a8)

うまくいきました。

## 結局のところロケールってどう使われてるの？

OSの動作をどういう言語で行うかを設定するものなんだろうくらいの認識。

> Linux では Locale を使ってユーザーがどの言語を使うか定義します。また、locale は使われる文字セットも定義するので、あなたの使っている言語が非 ASCII 文字を含んでいる場合、正しい locale を設定することは特に重要になります。
>
> [ロケール \- ArchWiki](https://wiki.archlinuxjp.org/index.php/%E3%83%AD%E3%82%B1%E3%83%BC%E3%83%AB)

じゃあ`locale`コマンドで表示される変数はどういう意味を持ってるのかというと、

``` sh
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
```

こんな感じらしい。

|環境変数|意味|
|:----|:----|
|LC_CTYPE|文字の分類および大文字/小文字の変換。|
|LC_NUMERIC|小数区切り文字 (または基数文字)、千の区切り文字、およびグループ化を指定します。|
|LC_TIME|月の名前、曜日、一般的な完全表示や短縮表示など、日付や時刻の書式を指定します。|
|LC_MONETARY|ロケールの通貨記号、千の区切り文字、符号の位置、小数点以下の桁数など、通貨の書式を指定します。|
|LC_COLLATE|ロケールの照合順序および正規表現の定義を指定します。|
|LC_MESSAGES|ロケールのローカライズメッセージの記述言語、および肯定と否定の応答 (yes と no の文字列と表現) を指定します。|

[ロケール（locale）まとめ \- Qiita](http://qiita.com/aosho235/items/58e2e7acd5c2ee3641ff#%E7%92%B0%E5%A2%83%E5%A4%89%E6%95%B0%E3%81%AE%E6%84%8F%E5%91%B3%E3%81%A8%E5%84%AA%E5%85%88%E9%A0%86%E4%BD%8D)

### 利用可能なロケールを確認 / 追加する

言語によっては最初から利用可能だったり、そうじゃなかったりするらしい。
利用可能なロケールは`locale -a`で確認できる。

``` sh
$ locale -a
af_ZA
af_ZA.ISO8859-1
af_ZA.ISO8859-15
af_ZA.UTF-8
am_ET
am_ET.UTF-8
be_BY
be_BY.CP1131
be_BY.CP1251
be_BY.ISO8859-5
 :
 :
```

Debian系の場合は、`/etc/locale.gen`に書いてあるロケールのコメントアウトを解除して`locale-gen`コマンドを実行することで有効にできるとのこと。

## 参考にさせて頂きました

* [Docker Compose でローカルの Rails 開発環境を作る \- Qiita](http://qiita.com/kbaba1001/items/39f81156589dd9a0d678#comment-6ed4ff57c5a4263b36a8)
* [Docker / rails console で日本語入力できない問題 · GitHub](https://gist.github.com/tasiyo7333/2163a09129ed36639645145a0146d8d3)
* [ロケール（locale）まとめ \- Qiita](http://qiita.com/aosho235/items/58e2e7acd5c2ee3641ff#%E7%92%B0%E5%A2%83%E5%A4%89%E6%95%B0%E3%81%AE%E6%84%8F%E5%91%B3%E3%81%A8%E5%84%AA%E5%85%88%E9%A0%86%E4%BD%8D)
* [ロケール \- ArchWiki](https://wiki.archlinuxjp.org/index.php/%E3%83%AD%E3%82%B1%E3%83%BC%E3%83%AB)

container-ship-596083 1280

Docker上のDebianイメージ（ruby/2.3.3-slim）で日本語が打てない

Hugoは静的サイトジェネレータの中でもだいぶ柔軟性のあるツールだと思う。

でも、その分気をつけなきゃいけないことがあったり、実現する方法が分かりづらかったりすることが多いので、
そういう点をまとめてみる。

## テーマの作成

まずはテーマを作る。
この章では、テーマを作るための環境の作り方を解説する。

### HugoBasicExampleをcloneしよう

HugoにはHugoBasicExampleという、サンプルの記事や基本的な機能を使ったテスト用レポジトリが用意されている。

[spf13/HugoBasicExample: Example site to use with Hugo & Hugo Themes](https://github.com/spf13/HugoBasicExample)

Hugoのテーマづくりは、このレポジトリのcloneから始まる。

### hugo new theme

次にテーマの雛形を作る。
Hugoにはテーマの雛形を作り上げるコマンドがある。

```
hugo new theme [name]
```

`hugo new`コマンドは、新しくサイトを作るときやページを作るときにも使われる。
とにかく、何か新しいものを作るときに使われるコマンドで、テーマを作るときもこれを使う。

cloneしたHugoBasicExampleのルートディレクトリでコマンドを実行すれば、`./themes/XXXX`に雛形が作られる。

後述するthemes.gohugo.ioに載せてもらうために必要なファイルも揃っているので、0からファイルを作るよりこのコマンドを使うのが賢明だと思う。

### ページの構造とテーマファイルの基礎的な構造を理解する

Hugoのページ構造はだいたい次の通り。

* HomePage
* list
* single
* taxonomies
* terms
* 404.html

で、`hugo new`で作られるテーマファイルの構成は次の通り。

```
.
├── LICENSE.md
├── archetypes
│   └── default.md
├── layouts
│   ├── 404.html
│   ├── _default
│   │   ├── list.html
│   │   └── single.html
│   ├── index.html
│   └── partials
│       ├── footer.html
│       └── header.html
├── static
│   ├── css
│   └── js
└── theme.toml
```

実は、この雛形には足りないものや要らないものもある。
それはおいおい自分の好きなように足したり消したりすればいい。

### テンプレートファイルと対象ページの紐付けを理解する

テンプレートファイルと対象ページの紐付けは、実は少しややこしい。

なぜかというと、Hugoは対象のテンプレートを特定の順番で走査する仕組みになっていて、
ページごとに細かくデザインを変えたり、全体で1つのテンプレートに統一したりと、融通が効くようになっている。

listページを例に具体的な構造を示すとこうなる。

```
/layouts/section/SECTION.html
/layouts/_default/section.html
/layouts/_default/list.html
/themes/THEME/layouts/section/SECTION.html
/themes/THEME/layouts/_default/section.html
/themes/THEME/layouts/_default/list.html
```

[Hugo \- Content List Template](https://gohugo.io/templates/list/)

上から順に、最初に見つかったテンプレートを採用する。
つまり、最終的に`/themes/THEME/layouts/_default/list.html`まですべて見つからなければ、何も描画されない。

### オーバーライドの仕組みを理解する

Hugoの最も便利なしくみの1つとして、テンプレートファイルは`./themes`とルート直下のものでそれぞれ用意できるような仕様がある。

つまり、`themes`においたテーマファイルをユーザが独自にオーバーライドできるようになっている。

先の例にあげたlistで言えば、`/layouts`と`/themes`で同じファイルを走査しているのがわかる。

```
/layouts/section/SECTION.html
/layouts/_default/section.html
/layouts/_default/list.html
/themes/THEME/layouts/section/SECTION.html
/themes/THEME/layouts/_default/section.html
/themes/THEME/layouts/_default/list.html
```

例えば、ユーザがあなたのテーマを使ってくれたとする。

そのまま使えばあなたがデザインしたとおりに描画されるが、対象のテンプレートファイルと同じ名前をルートディレクトリに配置することで、
そのファイルだけを独自に変更することができる。

ここで大事なのが、これはテンプレートファイルに限った話ではなく、**CSSや画像などの静的ファイルにも同じことが言える**ということ。

これをうまく利用することで、ユーザが豊富なバリエーションで使うことができるテーマを作ることができる。

## 何から手をつけるか

ここまでで、Hugoのテーマづくりにおける基礎的な解説はできたと思う。

しかし、実際に手をつけるとなるとどこから着手していいかわからなくなると思う。
というわけで、僕がテーマを作るときの作業順序をまとめてみる。

### ./layouts/index.htmlの削除

Hugoは`./layouts/index.html`がなければ、`./layouts/_default/list.html`が採用される。

僕は複雑な構造にするのが嫌なので、まず`./layouts/index.html`を消してしまう。

トップとそれ以外の記事一覧で表示を変えたい場合は、if文と`.IsHome`でなんとかする。

トップと一覧が大幅に乖離する場合は、ちゃんと分けたほうがいい。

### ./layouts/_default/baseof.htmlの作成

後述するblock templatesを使うため、`baseof.html`を作る。
ここでHTMLに必要な`<!DOCTYPE html>`や`meta`タグの配置、ヘッダとフッタのマークアップとデザインをする。

[Hugo \- Block Templates](https://gohugo.io/templates/blocks/)

### ./layouts/_default/list.htmlの作成

次に`list.html`を作る。
前述したとおり、Hugoは`./layouts/index.html`がなければ、`./layouts/_default/list.html`が採用される。

このタイミングで、トップページのマークアップとデザインを終わらせる。

### ./layouts/_default/li.htmlの作成

Hugoは断片的なパーツ、例えば一覧表示用の記事など、使い回しをする素材を切り出すことを推奨している。

これは`Page`が持つ`.Render`を使って実現する。

[Hugo \- Hugo Template Functions](https://gohugo.io/templates/functions#render)

`./layouts/_default/list.html`には最新記事の一覧を表示する場合がほとんどであるため、
`./layouts/_default/list.html`で作った記事1つ1つを`li.html`に切り出す。

### ./layouts/_default/single.htmlの作成

次に記事詳細を作ってしまう。
これはここまでで説明したものとなんらかわりないので、特筆なし。

### ./layouts/_default/terms.htmlの作成

次にtermsのページを作る。
このページは質素になりがちなので、デザインが難しい。

### ./layouts/404.htmlの作成

わすれがちなのが`404.html`。
ちゃんと作っておかないと空白のページが作られる。

## 気をつけたほうがいいこと

ここまでで基本的なテーマは作れるまでの説明をした。
しかし、これだけだときっとハマるであろう落とし穴がいくつかある。

### 相対パスは避ける

画像や静的資材の参照には相対パスを使ってはいけない。これはHTML上にあらわれるあらゆるファイルすべてに言える。

ユーザはドメインのルートであなたのテーマを使うとは限らない。
例えばthemes.gohugo.ioがいい例。

[Hugo Themes Site](http://themes.gohugo.io/)

各テーマのデモはサブディレクトリで構成される。
つまり、相対パスを使ってしまうと参照が壊れてデザインが崩れる。

`{{ .Site.BaseURL}}`を使って絶対参照で構築するべき。

### マジックナンバーは避ける

よくあるのが、Taxonomyに使われる値をべた書きしてしまうものだ。
`categories`や`tags`など。

これをマジックナンバーで書いてしまうと、ユーザが独自にTaxonomyを定義できない。
Hugoは`.Site.Taxonomies`で定義されたTaxonomyをすべて取得できるので、できるだけ柔軟に使えるようにしよう。

[Hugo \- Displaying Taxonomies](https://gohugo.io/taxonomies/displaying/)

Hugo側で`categories`と`tags`はデファクトみたいなスタンスを取っているので、それを理解した上でべた書きするのはありだと思う。

## 必要最低限の機能を付ける

サイトを作る上で、誰もが使いたいであろう機能がある。
そういった機能はできるだけつけたほうがいい。

### GoogleAnalytics

代表的なものがGoogleAnalytics。
Hugoは`config.toml`にGoogleAnalyticsのUserAgentを記述できるようになっている。

```
googleAnalytics = "UA-123-45"
```

この値が設定されていればGoogleAnalyticsのタグを配置するべきだし、
設定されてないなら出すべきじゃない。

そういったときには`with`が便利にはたらく。

[Conditionals | Hugo \- Go Template Primer](https://gohugo.io/templates/go-templates/#conditionals)

GoogleAnalyticsのタグは`_internal/google_analytics.html`という内部テンプレートが用意されている。
自分で書くよりもこれを呼び出してしまえば、値の設定、未設定の判定もやってくれる。

[Hugo \- Analytics in Hugo](https://gohugo.io/extras/analytics/)

### Disqus

静的サイトのコメント機能でもっとも有名なDisqus。
これもGoogleAnalyticsと同様、変数名が決まっている。

```
disqusShortname = "XYW"
```

[Hugo \- Comments in Hugo](https://gohugo.io/extras/comments#configuring-disqus)

DisqusもGoogleAnalytics同様、内部テンプレートが用意されているので、それを呼び出すのがいい。

### Generator

HugoはHugoのコミュニティを成長させるために、metaタグにgeneratorを明記することを推奨している。

``` html
<meta name="generator" content="Hugo 0.17-DEV" />
```

generatorは`{{ .Hugo.Generator }}`でタグとともに出力される。
ユーザに影響をあたえるものではないが、Hugoの発展のためにできるかぎり入れてあげたい。

[generator-meta-tag | Hugo \- Creating a Theme](https://gohugo.io/themes/creation#generator-meta-tag)

### Share button

シェアボタンも、基本的にはどのサイトにも必要になる。
これは国によって使われるサービスやSNSが異なるため、可変にできるとなおいい。

また、シェア自体いらないという場合もあるため、config.tomlで表示、非表示が切り替えられたり、
記事単位に`.Params`で切り替えられたりするといいと思う。

## よりよいテーマにするために

ここまでで、必要最低限なものが揃ったテーマを作るための説明はできたと思う。
次は少し発展させて、ユーザが柔軟にテーマを使うための機能を作る。

### Menuを可変にする

だいたいのWebサイトには、メニューが配置される。
HugoにはMenusという機能があり、これを使うこともできる。

[Hugo \- Menus](https://gohugo.io/extras/menus/)

が、実際にこれを使ってMenuを形成している人は少なそうな印象。
そのため、config.tomlなどで設定できるようにしているテーマが多く見られる。

自分がもっとも適切と思える形で実装し、READMEで設定の仕方を説明するといい。

### Shortcodesを用意する

Wordpressやその他のブログシステムにはShortcodesというとてつもなく便利な機能がある。

もちろんHugoにもあるので、基本的なものはテーマ側で用意しておくといい。

[Hugo \- Shortcodes](https://gohugo.io/extras/shortcodes/)

これはマークダウン内で定型的なHTMLを差し込むことができるもの。
例えば、画像やiframe、Twitterの埋め込みなどは、毎回HTMLを書くよりも手軽に呼び出せるようにしたかったりする。

テーマが用意するShortcodesとしては、画像の埋め込みと右寄せ、左寄せくらいを提供できるといい。
機能を作ったら、README.mdに使い方を書いておく。

### custom.cssを作っておく

ユーザが独自に、デザイン的なオーバーライドをしたい場合がある。

`styles.css`1つ用意しておけば、ユーザがまるまるHugoのルートディレクトリにコピーしてオーバーライドすることもできるが、
全体をコピーしないといけなくなる。

そういったときのため、custom.cssという空っぽのスタイルシートを用意して読み込ませておくといい。
ユーザは必要な場合のみcustom.cssを作ればいいし、そうでないなら空っぽのまま使われるだけ。

テーマのバージョンアップをしたときも、影響を少なくすることができる。

## 言語を超えて拡張性をもたせる

Hugoは全世界のあらゆる国で使われている。
テーマもできるだけ、特定の国に依存しないようにする。

### DateFormatを可変にする

まず言えるのが、日付の形式だ。

日本は`2016/01/01`といった形式だが、世界では違う。
これはできるだけ、柔軟に変えられるといい。

例えば、config.tomlに次のように設定できるようにする。

```
[params]
  dateformat = "Jan 2, 2006" # Optional
```

テンプレートファイルでは次のように描画する。

```
{{ .Lastmod.Format ( .Site.Params.dateformat | default "Jan 2, 2006") }}
```

### フォントを可変にする

英語圏ではHelveticaやArialなどでいいフォントも、国によってはそうとも言えない。

これもDateFormatと同じように、config.tomlなどで設定できるといい。
custom.cssを用意する方法でも良いが、フォントだけのためにファイルを作らせるよりは、設定で変えられると親切だと思う。

## 開発における発展的なノウハウ

ここでは、テーマを作る上でのさらに発展的なノウハウについてまとめる。

### block templatesを使いたい

すでに登場したが、Hugoはblock templatesという機能が使える。

[Hugo \- Block Templates](https://gohugo.io/templates/blocks/)

これはベースとなるテンプレートと子となるテンプレートを用意できる機能で、
HTMLの共通的な部分をベーステンプレートに切り出すことができる。

しかし、このHugoのこの機能には現在バグがあり、時折Golangのエラーメッセージを吐いてクラッシュする。

```
fatal error: concurrent map read and map write
```

この記事を書いている今も、かなりの回数クラッシュしている。

おそらく記事生成をgoroutineで回していて、その中でmapへの不適切なアクセスが走っているのだと思う。
そのうち直ると思っているが、気になる人はblock templates自体を使わないほうがいい。

[Concurrent map read and write error in template handling · Issue \#2224 · spf13/hugo](https://github.com/spf13/hugo/issues/2224)

Issueもあがっているが、再現できていないらしい。

### AMP対応をしたい

AMP対応は制約がいくつか付くだけなので、そこまで難しい実装ではない。

おそらくいちばんこまるのがスタイルシートの導入だと思う。
僕は`./layouts/partials/styles.css`にスタイルを配置して、次のようにしてインラインCSSとして描画している。

```
<style amp-custom>
  {{ replaceRE " +" " " (replaceRE "\n" "" (partial "styles.css" .)) | safeCSS }}
</style>
```

## themes.gohugo.ioに載せてもらう

テーマを作ったら、Hugoのテーマポータルであるthemes.gohugo.ioに載せてもらうための手順を進める。

[Hugo Themes Site](http://themes.gohugo.io/)

### theme.tomlを書く

まず、theme.tomlを書く必要がある。
これは`hugo new`で雛形が作られているので、それにそって書けばいい。

基本的な説明は、Hugoのテーマ用レポジトリのREADMEにある。

[spf13/hugoThemes: All Themes Hugo](https://github.com/spf13/hugoThemes)

### スクリーンショットを撮る

themes.gohugo.ioに表示されるサムネイルが2つの異なるサイズで必要になる。

> Thumbnail should be 900×600 in pixels
>
> Screenshot should be 1500×1000 in pixels
>
> Media must be located in:
>
> [ThemeDir]/images/screenshot.png
>
> [ThemeDir]/images/tn.png

一番映えるページでスクリーンショットを撮り、配置する。

### README.mdを書く

README.mdはユーザにもっとも近いドキュメントになる。
ここにはできるかぎり親切な情報を載せたほうがいい。

例えば次のようなもの。

* Screenshots
* Features
* config.toml example
* frontmatter example
* Shortcodes example

必要であれば、画像も使って説明をする。

### GitHubにIssueをあげる

ここまでできたら、自分のテーマレポジトリをHugoのテーマ用レポジトリにIssueとして連絡すればいい。

[spf13/hugoThemes: All Themes Hugo](https://github.com/spf13/hugoThemes)

コントリビューターの方が確認して、修正すべきポイントがあればIssueをあげてくれるし、
問題なければ取り込んでCloseしてくれる。


painter-1246619 1280

Hugoのテーマを何個か作ったので知見をまとめてみる

SPAがいいねと君が言ったから7月6日はGatsby記念日。ざっと3日くらいおうちで頑張って移行したぞ！

スタックはこう。

* [GatsbyJS](https://www.gatsbyjs.org/)
* [Contentful: Content Infrastructure for Digital Teams](https://www.contentful.com/)
* [Netlify: All\-in\-one platform for automating modern web projects\.](https://www.netlify.com/)

## HugoからGatsbyJSへ

Hugoが嫌いになったわけではないです。

開発も盛んで気がつけばバージョンが倍くらい上がってたりするような活発さで、ちょっとついていけなかったりしたけどとてもお世話になったプロダクトだった。

だけど、ちょっと静的サイトジェネレータ自体の運用に疲れてしまった・・・。

Markdownをファイル生成して書いて〜コミットして〜みたいなのってすごく楽なんだけど、なんか日付とかカテゴリをファイル内で管理するのが辛くなってきたのが正直なところ。

なんかこう、JSONを手でいじってるときと似た辛さ。

## 静的サイトジェネレータのここが辛かった

思えばいろいろと辛い場面はあった気がする。

まあでもGatsbyJSも静的サイトジェネレータではあるんけど、融通の利きやすさ（Contentfulとかコンテンツソースが選び放題）という意味で以下の辛さがだいたい解決できるのでは？と思ってる。

* Frontmattersの管理
* 画像の配置のめんどうさ、リサイズや最適化
  * 画像をディレクトリにいれてマークダウンにパスをかいて・・・みたいなの辛い
* 静的資材の管理、webpack等との共存
  * HugoもHugoで変更監視をしてるしwebpackにもやらせると仲良くできなかったりした
  * Ignoreしたり調整すればなんとかなると思う！
* （Hugoに限る話だが）Goのテンプレートの書きづらさ、エラー原因特定のしづらさ

どれも頑張ればなんとかできることだし、実際なんとかしてる人も多いと思うけど、ちょっと個人的に限界が来てしまった。

## バックエンドのContentful、フロントエンドのGatsbyJS

もうバックエンドは手元で管理するのをやめて、Contentfulに載せることにした。

Conntentfulは知ったときから気になってたHeadless CMSというたぐいのサービスで、まあデータ構造とデータ自体の管理だけやってあとはAPI（GraphQL）で配信してあげるよって感じのもの。

これ絶対有用だしこれからの時代でバリバリ使う場面あるっしょと思ってたんだけど、なんだかんだその場面が見いだせずにここまで来てしまった。出遅れた。

これがこれまでより楽になるかはもうちょっと運営しないとわからないけど、まあ物は試しで。

## とにかくGetting Started

まずこれを読む。

[GatsbyJS and Contentful in five minutes](https://www.contentful.com/r/knowledgebase/gatsbyjs-and-contentful-in-five-minutes/)

`package.json`を見ると`yarn dev`で動きそうなので叩いてみるけど、こんな感じでエラーしたので、

```
error We encountered an error while trying to load your site's gatsby-config. Please fix the error and try again.


  TypeError: Cannot destructure property `spaceId` of 'undefined' or 'null'.
```

`gatsby-config.js`を見ながらこんな修正をしてみる。

``` diff
~/Develop/repositories/src/github.com/dim0627/blog.unresolved.xyz (*master) $ git diff
diff --git a/gatsby-config.js b/gatsby-config.js
index 6f41f16..994f447 100644
--- a/gatsby-config.js
+++ b/gatsby-config.js
@@ -1,7 +1,7 @@
 let contentfulConfig

 try {
-  contentfulConfig = require('./.contentful')
+  contentfulConfig = require('./.contentful')[process.env.NODE_ENV]
 } catch (_) {
   contentfulConfig = {
     spaceId: process.env.CONTENTFUL_SPACE_ID,
```

これで通るようになるんだけど、実際にContentfulに設定されている構造とサンプルのGraphQLのリクエストがミスマッチを起こしてエラーするので、その変を適宜調整。

GraphQLは初めてで全然わかんなかったけど、読めばなんとなくわかるのですごい。

## カスタマイズ

[Next\.js](https://nextjs.org/)と同様、examplesがたくさん用意されているので疎通だけならほとんど詰まることはなかった。

[gatsby/examples at master · gatsbyjs/gatsby](https://github.com/gatsbyjs/gatsby/tree/master/examples/)

こういうのほんとたすかる。

とはいえReact自体の知識がなさすぎるのとGatsbyJSの土地勘がないので、細かい部分までやろうとすると結構詰まった場面は多かった。

いらないファイル消したりstyled-componentsに置き換えたり地道な作業もあったし。

## デプロイの自動化、WebHookによるデプロイ

Hugo使ってるときはコンテンツの管理とブログ自体のソースを一緒くたにしてたんだけど、今回はGitHub上にブログのソース、コンテンツはContentfulって感じで切り分けることができた。

なのでmaster pushをするとNetlifyがうけとってリビルドしてくれるんだけど、Contentful側でコンテンツをかえた場合はリビルドされないので、ContentfulのWebHookとNetlifyのWebHookをつなげてあげれば自動デプロイの環境が簡単につくれる。
