- [egoist/prisma-repl: REPL for Prisma databases.](https://github.com/egoist/prisma-repl)

普段プライベート開発ではTSばっかり使ってて、バックエンドのDB周りはprismaに任せてるんだけど、どうしてもrails consoleみたいなものが欲しくなってしまって困ってた。

`prisma-repl` はなんかいい感じに全部ロードしてくれて `db` 変数が使えるようになるREPLツールで、導入もめちゃくちゃ簡単でいい感じ。

prisma studioとも一旦お別れかも・・・。

prisma-replが便利すぎた

chakraのサンプルにある

```js
const variant = useBreakpointValue({ base: "outline", md: "solid" })
```

だと柔軟性が伝わらないんだけど、結局の所ブレークポイント単位に特定の定義した値を返すことができるので、こんな感じでPropsをごそっと定義することもできて便利

``` js
const Component: React.VFC = () => {
  const imageprops = useBreakpointValue({
    base: { src: "xxxx.sp.png", width: 380, height: 397 },
    md: { src: "xxxx.png", width: 710, height: 350 }
  })

  return <Box>
    <Image { ...imageprops } alt="any image" />
  </Box>
}

export default Component;
```

無茶なレスポンシブ対応をしたいときとか（しないほうがいいけど）に活躍したりする

- [useBreakpointValue - Chakra UI](https://chakra-ui.com/docs/hooks/use-breakpoint-value)

chakraのuseBreakpointValueでProps全体を柔軟に扱う

``` jsx
<Paper className={props.styles.choices} variant="outlined">
  {[0, 1, 2].map((i) => (
    <FormItem key={i}>
      <fieldset name="japaneseChoices" className={props.styles.fieldSet}>
        <Controller
          as={TextField}
          id={`japaneseChoices${i}`}
          name={`japaneseChoices.${i}`}
          label={`${I18n.t('attributes.word.japaneseChoices')} ${i + 1}`}
          fullWidth
          control={props.control}
          defaultValue={props.word.japaneseChoices && props.word.japaneseChoices[i]}
          onChange={console.log}
        />
      </fieldset>
    </FormItem>
  ))}
</Paper>
```

- [React Hook Form - Array Fields - CodeSandbox](https://codesandbox.io/s/6j1760jkjk)

Material-UIで配列を複数のTextFieldに分割して処理する

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)

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にしとけばよかったって気持ち。



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

正直それなりにデザインスキルが高いかつデザイナーさんたちがテクニカルスキルが高い組織じゃないとスタイルガイドの運用は結構むずかしいとおもうんだけど、ちょうど現職ですでに導入されてるレガシーな自前スタイルガイド機構があったので、負債化したそれを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とかを使いたいんだけど、レガシーシステムなのでそういうわけにもいかず、ちょっと泥臭くてもこういった小さい改善で今後もなんとかしていきたいなあという気持ち。

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脱却は進めていきたいところ。

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

しらんかった〜。

> 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)

Jest実行時にReferenceError: fetch is not defined

初めて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';
```

を入れるだけ。

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]+$"
```

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

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


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

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

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

秘匿情報どうするかなと思ったけどとりあえず慣れてるやり方 & 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/)

Next.jsでdotenvを使う

例えば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)

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

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

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を自分で入れる運用にするべきか迷ってたけど、その気持ちが強くなった。

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

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

というわけであっという間に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年も自分の人生最優先で頑張るぞ。

良いお年を。

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

これ詰まったのでメモ。

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

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

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)

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
```

雑。

## 内容の更新

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

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


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

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

<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/)

どちらもセルフホスティングできるはずなので、お金払いたくないなら自分でたてちゃえば済むと思う。


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/)でも使おうかな


エンジニアは技術ブログをどこで運用するのがいいんだ問題

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をつなげてあげれば自動デプロイの環境が簡単につくれる。


ブログをGatsbyJS + Contentful + Netlifyで作り直したので今日はGatsby記念日

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

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/)

以上です。

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

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

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)

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してくれる。
