カテゴリー: 技術

技術同人誌の表紙で得たもの、失ったもの

2018年12月11日

この記事は「技術同人誌 Advent Calendar 2018」の11日目です。

今年の技術書典5にて初めて同人誌を出しました。同人誌を出すまでの経緯、頒布時の体験などは既に記事にした通りなのでここでは特に語ることはせず、後々まで後悔が残った「表紙」についての反省を書こうと思います。

この表紙画像を見ていただければわかる通り、とあるメディアミックス作品の人気キャラクターが使われています。この表紙には、

・権利者の許諾を得ない二次創作の画像を使用している
・画像が内容と無関係

の、大きく2つの問題点があります。
（ついでに言えばオライリーのパクリでもあります）

順に説明していきましょう。

二次創作画像を使用することについて

日本のいわゆる二次創作同人作品は、歴史的な経緯もあり権利者の許諾を得ずに創作・頒布することが広く行われています。大きな同人誌頒布会から小規模なものに至るまで、様々な条件つきで半ば公然に認められてきました。私はこうした同人世界に深く入ったことがないので過去の経緯や現状のボーダーラインの機微には通じておらずあまり詳しくは書けませんが、「同人」といったときにメインストリームとして「二次創作」という一ジャンルがあり、「技術書」や「オリジナル創作」と並ぶ位置で一大勢力があるということは誰もが認めるところでしょう。そして当然ながら、それは権利者の現状容認というグレーゾーンあってのものです。

一方で技術書というジャンルの話をしますと、こちらはそういったグレーゾーンがなくとも成立するジャンルです。実際に出回っている技術同人誌を見ても権利関係はクリアです。表紙にアニメっぽい絵が使われている場合でもそれはオリジナル創作です。なぜなら本の内容自体が権利的に問題ないものであるために、わざわざ表紙に二次創作といった権利の微妙なものを採用する理由がないからです。

ちなみに、もし二次創作の画像をお金を払って誰かに書いてもらったとしたら商業利用としておそらく権利者は黙っていないと思います。こうなるとグレーゾーンではなく完全にクロになります。（この点ではこの画像は自分で描いたものなので問題にはなりません）。

内容と関係ない表紙を採用することについて

さて、技術同人誌界隈では私以外にも少数ながら二次創作の画像を採用した本の例があります。（万一延焼したら困るのでハッキリと名は挙げません）。しかしながらそうした本にはその画像を採用する理由があります。すなわち「内容が表紙と関係している」ということです。ガルパンの本ならガルパンの内容を踏まえた技術書になっていますし、艦これの本なら内容にきちんとキャラクターが登場しています。しかし私の本にはそれがありません。作品のキャラクターが出てくるでもなく、本文中にイラスト一つ見当たりません。これは詐欺と言って良いと思います。

すべての技術書が表紙と内容が連動するべきと言うつもりはありませんし、むしろ可愛いオリジナルキャラクターの描かれた表紙は堅いイメージを和らげ、手を取りやすくするために効果的であると言えます。しかしイメージを和らげるために虎の尾を踏む（＝権利関係がグレーなものを採用する）必要まではありません。存在がそもそもグレーゾーンな二次創作ジャンルと違って、安全地帯にいる人がわざわざ危険を侵しにいくのは愚かとしか言いようがありません。

さらに、この本のように誤認を狙うかのようにあざとい表紙にすることは、読者や手に取る人を見くびっているとも言えます。もし表紙によって手にとったとしても内容が伴っていなければ、それは伝えるための誠実さを欠いています。表紙買いして失敗したと思っている人がいたらどのように申し訳が立つと言うのでしょうか。

なぜこうなってしまったのか

さて、ではなぜこのような意味不明な表紙を採用した技術同人誌ができあがったのでしょうか。

【弁明1】とにかく目につけば売れると思った
【弁明2】みんながやってるからなんとなく（二次創作界隈を見ながら）
【弁明3】締め切り間際でそこまで頭が回ってなかった
【弁明4】普段二次創作しか描いてないのでオリジナルを描く技量がなかった

主に弁明4が大きいです。表紙買いで失敗したなと思われた方にはこの場を借りて深くお詫び申し上げます。

おわりに

みなさんも、このような失敗をしないように表紙はよく考えて採用しましょう。この表紙で得たものは教訓とこのエントリのネタ。失ったものはクリアな権利関係とお天道様の下を堂々と歩ける権利でした。

次回はちゃんとやろうと思います。

次回の同人誌どうするか悩んでいる話

2018年12月8日

遅刻して書くのが週末になってしまいましたが、これはEveryone Outputer Advent Calendar 2018の5日目の記事、兼、技術同人誌 その2 Advent Calendar 2018の5日目の記事です。

2018年は私が生まれて初めて同人誌というものを出した記念すべき年となりましたが、そろそろ出てくるのが「2冊目のネタどうしよう」ということ。1冊目は自宅で3年ほど運用したホームオートメーションシステムについての解説本でしたが、正直なところ続編を書けるほどの残りネタはありません。ということで、まったく違うテーマで書こうと思っています。

アウトプットを決意してから出来上がりまでを最適化する

まだテーマについてはもやもや考えているところなんですが（まだ技術書典6に申し込んでさえもいませんし）、継続的なアウトプットを助けるための本にしたいと思っています。ネタが出てくるための仕組みづくり、文章として整形するためのTips、ネタ詰まりを突破するための方法論、もろもろそんなやつをワンストップで俯瞰できるネタ帳的なものにしたいです。キーワードをちりばめた入門書みたいなやつです。

と、ぶち上げたものの、それを実現するには読むべき本が多すぎてちょっと手を広げすぎになりそうな気がしています。それをうまくコントロールして、全部の解説まではできないまでもキーワードを網羅しておいて詳しくはググってくれ的な感じでうすーい本にできればなあと思っています。

いまキューに入っている参考図書

書きながら考えるとうまくいく！ プライベート・ライティングの奇跡
はじめての技術書ライティング―IT系技術書を書く前に読む本
ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック
数学文章作法 基礎編
知的生産の技術
知的トレーニングの技術
思考の整理学

このあたりを参考にまとめ直して、簡単にサッと読める感じにしようかと思っています。

結論がモニョモニョしていますが、今のところこんな感じですという現状についてお話ししました。とりあえずこれで今日のアウトプットは完了ということで。

技術書典5のサークル参加レポート（当日編）

2018年10月9日

（この記事はnoteと同じ内容です）
技術書典5にて初めてのサークル参加をしたので、その経緯から終了までを、また参加する時の自分に向けてメモします。準備編はこちら。前日編はこちら。

新刊「Raspberry PiではじめるDIYスマートホーム」PDF版はBOOTHにて引き続き頒布中です。96ページ、1000円です。
https://yagitch.booth.pm/items/1034342

完売御礼

おかげさまで完売しました。冊子版、80部刷ったのが1時間半ですべてなくなりました。ダウンロードカードは多めに300部用意しましたので完売することはありませんでした。また、イベント時間中にBOOTHからも購入して頂けました。お求め頂いた方、本当にありがとうございました。来て頂いたのに冊子版がないということでお帰り頂いた方、申し訳ありませんでした。この経験は次に生かします。

頒布結果

冊子＋PDF版：79（印刷数82－見本誌3）
PDFダウンロードカード：51
PDF（BOOTH）：3

知見1：ワンオペはおすすめしない

ワンオペは死です。グランパさんもそうおっしゃっています。私はなんとかギリギリこなしましたがおすすめしません。まさに頒布会は戦場です。その中でトイレ休憩でスペースを離席せざるを得なかったり、荷物を置きっぱなしにできなかったり、あるいは他のスペースに偵察や挨拶さえも行けないというのは相当なハンデです。採算が合うなら日当を払ってでも売り子を頼みましょう。馬力二倍は効果百倍です。
私は初の設営に手間取り、9割方できたところでこまごましたことをやっているうちに開場時刻を迎えて慌てました。また、完売の掲示をしたり、見本誌を途中で増やしたり、応対しつつ色々なこともやらざるを得ませんでした。ブーストしても列整理できませんし、スループットも上げられない。できれば、せめて完売の報告やダメ押しのPRをTwitterでやりたかった……そういう反省からワンオペをすることはもうないと思います。
ちなみに、仲の良いフォロワーさんがいの一番に来てくれてお使いや売り子協力を申し出てくれてとても嬉しかったです。ただ「今日は一人でやってみる」と決めてそれを中心に段取りを決めていたので遠慮させてもらいました。優しい人の存在はありがたいものです。

知見2：電子版は冊子のようには売れない

12時半くらいに冊子版が完売して、初参加初完売を周囲のスペースさんたちに拍手で祝ってもらいました。この時点で被チェック数は214となっており、少なめに見積もってもあふれた100人くらいがダウンロードカードを買ってくれるかな？ と思っていましたがそこまでではありませんでした。開場したはじめは指名買いの方ばかりなので中身を見ることもなくポンポン捌けていくのですが、冊子版が完売してからはスローペースになりました。それでも完売当初は「仕方ないなー」みたいな表情でダウンロードカードを指名買いしてくださる方も途切れなかったのですが、開始2時間半くらいでボーナスタイムも終わり、後はダウンロードカードはさっぱり売れず、ひたすら見本誌を見て立ち去っていく人を見送るだけの人になりました。
「人はなぜ現物で欲しがるのか？」というのは業界のプロでも人によって論が違う難しい話ですが、冊子の過小読み違えに加えてダウンロードカードの過大読み違えさえもやってしまったというのは私にとって地味にショックな事でした。ポジティブに捉えれば、これはおそらく何年経ってもこの調子だろうと思うので、次回からは安心して予想ができます。少なくとも冊子の数以上に刷ってはいけません。

知見3：オペレーションでやれることは少ない

限られたスペースで押し寄せる来客を捌かなければならないので、スループットの維持は命綱です。私は初参加にあたってオペレーションの事前シミュレーションに時間を割き、ワンオペというハンデを考慮すると相当に簡単なフローにしないといけないという危機感がありました。そのためPixiv Payの対応は見送って現金とかんたん決済アプリでの支払いのみにしましたし、価格設定も1000円札一枚という単純なものにしました。かんたん決済アプリの良いところはQRコードを事前印刷して掲示しておくだけという手軽さなので売る側のアクションがいりませんし、もっとスピードを上げたいときは決済時の自機確認を省略する（セキュリティは低下します）オプションを取れるフレキシブルさにあります。
事前シミュレーションが奏功してワンオペでもギリギリこなせるラインで捌けましたし、私のスペースに来る人が滞留して隣のスペースに迷惑をかけることも少なかったと思います。（それより開場当初、会場自体の問題でうちの目の前がボトルネックになって滞留するという問題の方が大きかった）。あれもこれもやろうとするのはやめた方がいいです。バッサリ諦めましょう。その分を来客とお話しする余裕に回した方がよほどいいです。

その他のトピック

会場内にはおそろいのTシャツを着たインプレスR&D社のスタッフさんがおり、少数のサークル主さんに「商業化しないか」と声をかけていました。ああ、こうやって技術書典Kindleシリーズはできていくんだなーとその様子を眺めて思いました。なお、うちには来ていませんのでご安心ください。
立ち読み広場に提供した見本誌にはBOOTHのQRコードを貼っておき、最悪スペースに来なくてもいいようにしました。イベント時間中にBOOTHでは3冊売れたのですが、一人はTwitterで事前に問い合わせがあり、もう一人はスペース前でQRコードを読み取っていたので、おそらく立ち読み広場からアクセスした人が一人くらいいるんじゃないかな、と想像しています。このようにちょっとした工夫が奏功するのはとても嬉しいことです。スタッフさんに聞いたら立ち読み広場は大盛況だったとのこと。よかった！
ダウンロードカードをカラフルな便箋に入れて渡すというアイデアは好評でした。今回ダウンロードカードが売れ残ったことで便箋は大量に余ってしまったので、次回があればまた同じことをすると思います。また、ダウンロードカードに様々な工夫を詰め込んでいたのもアフターで他のサークル主さんに好評でした。こういうの。

ワンオペだったので技術季報を買うことはてっきり諦めていたんですが、撤収が佳境に入っても技術季報は出口のところで売っていたので購入することができました。これは運営さんナイスです。あとで読みます。
スペースに置く見本誌は2つあった方がいいですね。スペースの幅的に来客は2人が限度なので。はじめは1つだけ用意していて、売り物用の一番上のものも手に取って良いですよーという形で運用していてスムーズでした。冊子が完売するとそれがなくなるので、取っておいた自分用を急遽見本誌に仕立て上げて見本誌2つ＋ダウンロードカード販売という形にしました。これは大成功だったと思います。
逆に致命的な出来事として、飲み物を買わずに入場してしまい、気付かず設営していたら入退場できない時間帯になり、そのまま開場を迎えてしまうという失態がありました。幸運にもフォロワーさんが1Lコーヒーを差し入れてくださったのでものすごく助かりました。初の同人売り子の思い出はサザコーヒーの味とともに記憶されることになりました。
水分補給が少なめだったこともあり、トイレには一度も行きませんでした。ただし体には良くないし疲労のリスクもあるので真似してはいけません。水分はきちんと取りましょう。
途中で運営代表さんが挨拶にいらっしゃいましたので、前回混雑の話を聞いて人出にビビっていたけど今回は（開場当初は別にして）スムーズにさばけてますねという話をしました。またよろしくお願いします。
両隣が人気サークルで終始人が途切れない状態だったので、立ち読みの方がこちらにはみ出してくることが多々ありました。私の方も逆に侵食することもあったのでこれはお互い様だと思います。が、（双方実績に裏打ちされた）洗練されたコミケの行列形成に慣れてると「配置とスタッフ誘導何とかしてー」と思ったりはします。
オフラインの知り合いでは唯一のサークル参加者だったsanryuuさんが唯一のチームビルディングの合同誌を主宰していて、その本が異色かつ面白そうということでTwitterやブログで注目を浴びていたのを見ているのも楽しかったです。こういう楽しみ方もあるんですね。

当日持ち物で使ったもの、使わなかったもの

【○ or ×】
○1000円札×30枚
○お金ケース
○スマホスタンド（イーゼルがないので見本誌置くのに代用）
○スマホスタンド（名刺を取りやすくする用）
○サインペン
○値段POP・お品書き・スペース番号を書いた紙・QRコードを書いた紙
○クリアケース（ポスター用、お品書き用）
○名刺
○名刺入れ
○名札カード
○対面電書シリアルコード
○ネックストラップ
○B5見本誌クリアカバー
○養生テープ
○メンディングテープ
×作業用手袋
○はさみ
○あの布
○ゴミ袋
【忘れた】飲み物
○モバイルバッテリー
×スケッチブック
○大きな付箋
念のため持っていったもの
○書見台（ポスタースタンドとして活用）
○カッター
×カッターマット
×物差し
×マジックテープバンド
×シール
×スティックのり

非公式アフターの熱気もすごかった

池袋のダーツバーにてアフターに参加してきました。その中に一般参加者を見つけたので執筆沼に引き込んでおきました。ふふ。アフターに来て無事で済むと思うなよ（ニヤリ）。
技術書典自体の熱気もすごかったですが、酒の入ったアフターの熱気も凄かったです。わりと引っ込み思案な私ですけど、のびのびと過ごして様々な方とお話しすることができました。LTも勘所を押さえたタメになる内容でした。
「執筆の時に、自分にプレッシャーを与えるためにあえて入稿締め切りを調べない」という私の（無謀な）執筆方法を武勇伝のように語ってしまったのはちょっとやり過ぎたと思います。はい。
あと、形はどうあれ「自分でイラスト描いて表紙にしたんだったら次は貴方に表紙を依頼したい」と言われたのは大きなモチベーションになりました。私はまだ自信がないので辞退しましたけど。
グランパさん曰く「初参加80部で瞬殺になって悔しい思いをするのは必要なステップだ。なぜなら200でも捌けると先人が言ったところで、その身で体感するまではその事実を絶対に信じないから」ということで、悔しく思っていた私には大きな慰めになりました。

おわりに

10月8日は私にとって大きな記念日になりました。たった3ヶ月前には夢にも思っていなかった、本を作り配るという楽しみがどれほどの破壊力を持っているかということを全身で感じられた一日でした。これは取り憑かれる人が多いのも頷けるばかりです。私も「次は何にしようかなあ」などと考え始めています。
多くの人に支えてもらって普通なら見られないものを山ほど見せてもらいました。技術書典に来てくださった方、私の本をお求めくださった方、事前告知に協力くださった方、立ち読みしてくださった方、場を提供してくれたスタッフさん、それから同じサークル参加の先人の皆さんに感謝いたします。最後までお読みくださりどうもありがとうございました。

技術書典5のサークル参加レポート（前日編）

2018年10月7日

（この記事はnoteと同じ内容です）
技術書典5にて初めてのサークル参加をするので、その経緯から終了までを、また参加する時の自分に向けてメモします。準備編はこちら。明日は当日編を書きます。
準備編(note版)がホッテントリ（「テクノロジー」カテゴリ内）に少しだけ入ったので、味を占めてこの記事でも洗いざらいお話ししていきます。
サークル情報・頒布情報はこちら。
https://techbookfest.org/event/tbf05/circle/32170001

新刊「Raspberry PiではじめるDIYスマートホーム」PDF版はBOOTHにて同時頒布予定です。96ページ、1000円です。
https://yagitch.booth.pm/items/1034342

事前告知方法

Twitterでの告知をメインにしました。気をつけたことは以下。

  • すべてを1ツイートにまとめる。読みやすい範囲で最低限の情報を入れて、フックしそうなキーワード（私の場合AlexaとかNode-REDとか）を混ぜる
  • ウォッチャーの多い #技術書典 ハッシュタグを付けて拾ってもらう
  • お品書き画像を付ける。これで情報量2倍
  • ワンクリックでサークルチェックできるように
  • 「おっRTしたいな」と思わせる一定のクオリティにする（簡潔。誤字NG）
  • このツイートを皆の見ている時間帯（昼～夕方）にツイートし、ツイート固定し、うざくない範囲でセルフRT（一日2～3回）して認知度を上げる
  • セルフRTだけではハッシュタグで見ると埋もれてしまうので、再告知という形で同内容新規ツイートも2日に1回程度混ぜる
  • アカウント名にも（ちょっと長いけど）書名を入れてしまう


普段私のするツイートはそんなに注目されることはありませんが、興味のありそうな18人にRTされ30人にいいねされました。他にも知人が弊サークルに言及した内容にいいねが集まったりもしているので、それだけの認知の上乗せができたと思っています。
お付き合いのあるエンジニアのフォロワーさんたちに取り上げてもらった効果もあると思います。皆様認知度向上に協力ありがとうございました。
また、幸いなことに技術書典5における、おもしろそうなサークル10選に選ばれたので、この記事をRT・再告知ツイートして間接的に弊サークルの認知度を上げることもしました。こういう間接的方法の方が読者のみなさんに受け入れられる（宣伝一辺倒より他サークルの情報も付いてくる有用さがある）と思います。
この方法に味を占めて、今度は自分で技術書典5で巡るスマートスピーカーの世界～サークル6選というガイド記事を書きました。スマートスピーカーという切り口で、どうせならジャンルの近いサークルさんもまとめてサークルチェックに入れてもらおう！ というコンセプトです。同ジャンルサークル主さんにも拡散に協力してもらえるかも、という下心もあります。
このような方法を前日までの5日間に行いました。兎にも角にも認知してもらわないことには話になりませんので、自分の使えるチャネルをすべて使って告知して、当日までに勝負が決まるつもりで力を入れました。

持ち物の準備

値札はこのような感じで作りました。


値札、お品書き、ポスターなどの紙類はすべてダイソーのプラスチックケースでカバーすることにしました。綺麗に見えるのと、破れたり風に煽られたりすることを防ぐためです（気にしすぎかもしれない）。
名札はできるだけ大きくしました。私自身が人の名前を覚えられない人なので、どうか他人は困らないようにと気を回した結果です。


ダウンロードカードはすべて便箋に入れてお渡しすることにしました（封はしない状態）。これは「裸で渡すよりは何か包んだ方がいいかも？」という気持ちの問題です。オペレーションの問題から事前に封入を済ませました。

設営シミュレーション

何しろ初めてのサークル参加ですので、事前シミュレーションは念入りにしています。


当日はこのような感じになる予定です。

初参加だけど完売？

入稿時点では結構攻めて80部刷ったのですが、現時点の被チェック数を見ると100を超えており、皆が冊子版をお求めになると完売する可能性が出てきました。というかたぶん完売します。
ダウンロードカードは潤沢にあるので、どこかの時点からはダウンロードカードのみの頒布になる予定です。PDFの方が欲しい！ という方は焦らなくてもBOOTHでも頒布していますので余裕をもってお越しください。
また、当日は立ち読み広場に冊子見本を置かせて頂く予定です。見つけたら写真に撮ってTwitterとかにどんどんUPしてくださいね！
BOOTHにてサンプル版も読めます。全体の4割くらいをサンプル版にしています。
いよいよ明日です。楽しんでいきましょう！
（当日編へ続く）

技術書典5で巡るスマートスピーカーの世界～サークル6選

2018年10月6日

技術書典5 が近づいて参りました。参加するにあたって忘れてはいけないのがサークルチェック。この記事ではテーマを「スマートスピーカー」に絞って、おもしろそうなサークルをチェックしていきます。Amazon Alexa、Google Home、LINE Clovaなどなどに関する本を出しているところです。

う28 ひろ亭（ヒロテイ）

https://techbookfest.org/event/tbf05/circle/41000002
『子どもと育てるスマートスピーカー』（※商業誌）
“技術書典4で頒布したスマスピ本の商業版。技術書典会場限定価格とおまけつきです”
『スマートスピーカーを遊びたおす本』
“スマートスピーカーを楽しんでいるエンジニアたちの夢の共演！
VUIスキル・アプリのTIPSや事例、勘所などをまとめました。”
技術書典でスマートスピーカーを取り上げるならここを外しては語れない大サークルです。『子どもと育てるスマートスピーカー』は技術書典4で出し、その後商業出版社によってKindle版として再発売されたという経緯があります。私も買いました。

お01 umitsuki（ウミツキ）

https://techbookfest.org/event/tbf05/circle/25970001
『はじめてAlexaスキルをリリースするまで（仮）』
“「藤沢市のごみ収集日」というAlexaスキルをリリースするまでにスキルを作るために設計で考えたこと、選んだ実装方法などについて共有できればと思っています。”
スキル開発の実体験本のようですので、スキルを開発したいけどまだ踏み出せていない私のような初心者にはぴったりかもしれません。AWS SAMや TypeScript の話が出てくるようです。

お02 ITO（イトー）

https://techbookfest.org/event/tbf05/circle/27560001
『俺たちが知りたかったAlexaの話』
“この本はAlexaスキルを開発するための技術書です。 スキル開発の中級者向けに、音声ユーザーインターフェース（VUI）の設計、ask-sdk for Node.js バージョン2を使った最新の開発、ask-cliとServerless Frameworkを使って開発からデプロイをシンプルにするテクニックが書かれています。既にスキルを開発したことはあるけれど「スキルの設計から開発までを体系的に学びたい人」や「もっと高度なスキルを作りたい人」向けに書かれた本です。”
140ページと大ボリュームです。スキルが向上したときのために確保しておきたいところです。

お03 温泉♨︎BBA（オンセンババア）

https://techbookfest.org/event/tbf05/circle/29520007
『スマートスピーカーアプリのお品書き』
“この本は、いま急速に拡大しつつある「ボイスユーザーインタフェース」のスキル開発に関わるエッセンスを、初心者にもわかりやすく説明したものです。”
対象者にサンデープログラマーなどが入っていますので、まだスキル開発について自信の無い方でも安心して取っつける内容ではないかと思います。

あ17 huhka.com（フーカコム）

https://techbookfest.org/event/tbf05/circle/37230004
『Raspberry PiとGoogle Homeで赤外線リモコンをアレでナニする本』
新刊は別にあり、これは技術書典4で頒布した既刊ですが再版する予定のようです。私の手元にもあります。ラズパイとADRSIR（ラズパイ用学習リモコン基板）やIFTTTなどを使ってGoogle Homeを動かすための解説本です。

お04 yagi.tc（ヤギドットティーシー）

https://techbookfest.org/event/tbf05/circle/32170001
『Raspberry PiではじめるDIYスマートホーム』
“Raspberry PiとPhilips Hue、Amazon Echo(Alexa)、IRKit、netatmoなどを組み合わせてスマートホームをDIYしちゃおう！という本です。筆者が3年間試行錯誤しながら自宅をスマートホームにした経験を元に、Raspberry Piを中心に既製品IoTデバイスを組み合わせる方法をスクリーンショット付きで完全解説。”
この記事を書いている私が書いた本です。スキル開発ではなく、既存のNode-REDブリッジを使って生活の中に自動化とAlexaインターフェイスを取り込むための実用的な本です。

最後に

以上、「スマートスピーカー」をテーマに6つのサークルをご紹介しました。うちも出すよ！ って方がいたらコメントまたは @yagitch までご連絡をお願いします。

技術書典5のサークル参加レポート（準備編）

2018年10月3日

（この記事はnoteと同じ内容です）
技術書典5にて初めてのサークル参加をするので、その経緯から終了までを、また参加する時の自分に向けてメモします。終わったら当日編を書こうと思います。
サークル情報・頒布情報はこちら。
https://techbookfest.org/event/tbf05/circle/32170001

本はBOOTHで試し読みができます。
https://yagitch.booth.pm/items/1034321
Continue reading 技術書典5のサークル参加レポート（準備編）

alexaが使えなかったのでalexaで何がやりたいかまとめる

2017年12月4日

これはAmazon Alexa Advent Calendar 2017の4日目の記事です。

Amazon Echo Dotを発売翌日に入手して意気揚々とセットアップしたものの、USとJPでアカウント結合しているのが良くなかったのか「居住国設定が正しくありません」と言われてうまく動いてくれません。仕方ないのでサポートに連絡したもののなしのつぶて。Alexa Skillsを開発しようとしても、SkillsやLambdaの設定までは行くもののアプリのスキル選択画面に反映されず、これまた断念。
これでは書くことがないので、もし問題が解消されたらこのように動かしたいというユースケースを説明してお茶を濁すことにします。
我が家には既にRaspberry Piで組んだ自作スマートホームシステムがあります。これを司令塔として、今回手に入れたEcho Dotを音声認識トリガーとしてのインターフェースに位置づけます。既存システムにはNFCリーダとHUIS（学習リモコン）とcron（スケジューラ）をトリガーとして動いているので、それにEcho Dotが追加される形になります。

我が家のスマートハウスシステムの図解

HUIS（学習リモコン）

Continue reading alexaが使えなかったのでalexaで何がやりたいかまとめる

Nook Simple Touchをroot化してEPUB/PDFリーダーとして活用する

2017年11月10日


我が家にはBarnes & Noble社の電子書籍リーダー、Nook Simple Touchが転がっています。5年前に友人の米国出張で買ってきてもらったやつで、けっこう当時としては優秀なデバイスです。ハックしようと思ってずっと放置していたものです。
これを今更活用してみようと思い立ちました。
2011年の発売から6年以上が経過し、搭載しているAndroid 2はとっくに骨董品。rootを取る方法などを掲載したブログなども多数リンク切れになっています。そもそも検索して出てくる情報なんて最新でも2013年かそこらの記事ですし、日本語記事も数少ない。逆に言うとそれだけ枯れきっていて、うまくドキュメントを探せばやりたいことが全部インターネットに書かれてあります。そんな玄人好みの遊びをやってみることにしました。
結論から言うと、このデバイスが持っている潜在能力を引き出して電子書籍リーダーとして活用することに成功しました。私のように死者を現代に復活させようという変わり者たちの為に、いくつか有用な情報を記すことにします。
Continue reading Nook Simple Touchをroot化してEPUB/PDFリーダーとして活用する

エレガントなパーマリンクとは

2017年10月31日


このブログを開設してから17年、現在のドメイン（yagi.tc）を使い始めてから12年になりますが、マイナーccTLDということもあり、相次ぐ値上げと運用上の制限が気になるためにドメイン移転をすることにしました。ものはついでで、どうせ301リダイレクトを設定するのならブログのパーマリンクもより運用しやすいものに変えようと考えました。
しかしブログに適したパーマリンクについて日本語でいろいろ調べてみても、SEOに有利かどうかについて書かれたエントリしか見つからず、しかもその内容もそれぞれ根拠のない内容を扱っているだけで、ベストプラクティスのようなものは存在しないようでした。それならひとつ自分が情報を整理してエントリに仕立て上げてみようと思い、ここにまとめることとします。

1. このエントリの前提

前提として、個人が所有するブログのパーマリンクに主眼を置くこととします。分野をあまり絞らないパーソナルな内容で、長期間の運用をし、独自ドメインを持ち、WordPressなどのCMSでパーマリンクを選ぶときに、ハテどうしようかと悩んでいる私のようなひとのための検討材料です。
近年は「URL」のことをより広い集合である「URI」と呼ぶこともありますが、このエントリではブログのパーマリンクを主眼にしている意味合いから「URL」で統一しています。
また、コンテンツのURL全般を指す場合は「URL」、ブログやその他コンテンツが一意に持つパーマリンクのみを指す場合は「パーマリンク」と呼んでいます。

2. 参考資料と現状認識

コンテンツのURLについては検索エンジンGoogleによってガイドラインが公開されています。
コンテンツに関するガイドラインhttps://support.google.com/webmasters/topic/4598733?hl=ja
ざっくり「シンプルかつ論理的で可読性のあるURLにしなさい」と書いてあります。そのためにコンテンツに対して一意であることが望ましく、IDを使用するよりは意味のある単語を使用した方がよいようです。
もうひとつ参考になるのは、Googleのサービスの一つであるGoogle Cloud Platformが公開したAPI設計についてのブログエントリです。
API design: Choosing between names and identifiers in URLshttps://cloudplatform.googleblog.com/2017/10/API-design-choosing-between-names-and-identifiers-in-URLs.html
これは人間が理解するブログではなくコンピュータが理解するAPIのための内容ですが、両者に共通する思想を持っているために、上記のガイドラインよりも一歩踏み込んだ内容として手本となります。
ざっくり内容を紹介すると、例えば
https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7
のようなIDを使用したフラットな構造のものと
https://library.com/shelves/american-literature/books/moby-dick
のような分類による階層構造を伴うものとあり、両者にはトレードオフが存在し、より好ましいのは後者のように見えるが、一概にそうだとは言えないということが書かれてあります。そして、前者はパーマリンクとして、後者は検索のために使用して両立させるという例が挙げられています。
実際のブログのパーマリンクの主流はどのようなものでしょうか。もっとも使用されているCMSであるWordPressでは、規定値のパーマリンクは
https://example.com/?p=1
のような形式になっています。他に、日本でもっともユーザ数の多いブログサービスであるLivedoorブログでは、
https://example.com/archives/52017243.html
のような形式になっています。いずれもエレガントとは言えないようです。

3. エレガントなパーマリンクとは

では「エレガント」なパーマリンクって何なのでしょう。突き詰めるととても主観的な話になってしまいますが、基本的にはGoogleのガイドラインにある「シンプルかつ論理的で可読性のあるURL」でよいと思います。そこに私は「運用が単純であるURL」を加えたいと思います。この重要性については後述します。
これらの各要素を順番に確認していこうと思います。

3-1. シンプルさと可読性を両立させるURLとは

まずはGoogleのガイドラインにある「シンプルかつ論理的で可読性のあるURL」を見ていきます。

3-1-1. シンプルさを優先する（短縮URL）

もしこれを「シンプルかつ論理的」の方向に突き詰めるとどうなるのでしょう。
Twitterで使用されている短縮URLサービス「t.co」の例です。
https://t.co/nEDMKlFpP4
人間にとってたいへん読みにくいことを除けば「シンプルかつ論理的」であると言えるでしょう。冗長な部分を廃してもっとも短く、かつ一意になるURLです。短いことの利点は単純で無駄がないことです。保存に場所をとらず、通信するのも短時間で終わります。（あくまでURLは、の話です）
このURLが生きるのはもちろんTwitterです。Twitterは一投稿あたりの文字数に厳しい制限を課しています。どのような長いURLであっても、URLが投稿に収まりきらないということはこれでなくなりました。素晴らしいですね。
URLが短いことの利点はモバイル環境でも発揮されます。これは短縮URLサービスを指した話ではなく、URLが短いこと自体についてです。モバイル環境ではブラウザのアドレスバーに表示される文字数が限られるため、より少ない文字で収まるURLであれば、人間にとって認識できる情報量が増えます。
（※ただし認識できても理解できるかどうかは脇に置きます。短縮URLサービスでは本来URLから推測できる情報が欠落するため、フィッシングサイトの温床になっている現実があります）
短縮URLサービスではなく、そのサイトのパーマリンクを「人間が理解できないほどシンプル」にしている例として以下があります。
YouTube
https://www.youtube.com/watch?v=3RDYVVmVR2U
実のところ冗長であまりシンプルとは言えませんが、投稿された動画がいくつになろうと対応できる柔軟性と、それでいてURLの長さがほぼ変わらない安定性を持っていることは特筆すべきです。私ならもっと短縮URLチックに「https://youtube.com/3RDYVVmVR2U」とするところです。
Qiita
https://qiita.com/toyoshi/items/f40e6440e50b3fc5ccd9
こちらもやや冗長ですが、エントリのハッシュ値をとって擬似的に一意にするという発想は特筆すべきです。同様の例にはGithub Gistがあります。
Github Gist
https://gist.github.com/toriwasa/7e1464d8050a596705793770fe158234
16進数のハッシュ値よりさらに短くできるBASE64で良いのではないかと思いましたが、URLのルール上「/」が含まれてしまうのが微妙なので16進数で手を打っているのかもしれません。
Evernote 共有ノート
http://www.evernote.com/l/ABANAls7iwVNvokclFwn2Vb-1jP8QVjXAsP/
人間の理解を一切考慮せずBASE64的なURLにしており、たいへん合理的です。Qiitaに比べて衝突可能性も格段に低いと思われます。

3-1-2. 可読性を優先する（冗長なURL）

上記の通り、シンプルで論理的なURLを追求すると人間の理解が難しい文字列になります。このため、たとえ短くても人間がコピー＆ペースト以外で手打ちしたり読み上げたりする場合は大変です。多少冗長であれば手打ちや読み上げ時に間違いがあってもエラー訂正が可能ですが、人間の理解ができないURLでは訂正を期待できません。
そこでスラッグ（slug）を使うという方法があります。私のブログはこの形式です。
yagi.tc
https://yagi.tc/archives/2017/10/16/always-on-ssl/
上記の例では“always-on-ssl”の部分がスラッグで、全エントリ中一意になるようになっています。つまり設定を変えて、もっとシンプルに
https://yagi.tc/always-on-ssl/
とすることもできます。ある程度シンプルかつ論理的な形を保ったままで人間に理解しやすい形にするというバランスの取れた解決策です。URLから内容が推測できるため、Google Analyticsなど、配下のURLを大量に認識する必要がある場合にとても役立ちます。
ただしスラッグの難点は、タイトルとは別にいちいち設定する必要があることです。もし英語圏の人がエントリを書いたなら、自然とタイトルや本文はASCIIに収まるのでスラッグを設定しやすい（何なら自動で設定させても良い）のですが、ASCII以外の文字（マルチバイト文字）を使う文化圏の人にとってはどうでしょうか。
WordPressでスラッグを有効にした場合、他に何もしなければタイトルの前から何文字かが自動でスラッグになります。日本語で書けば当然マルチバイト文字になります。困ったことに、スラッグがマルチバイト文字で設定され、URLもマルチバイト文字を含む形になった場合、URLエンコード（パーセントエンコーディング）が発生します。エンコードされたURLはとても長くなり、人間の理解ができない形になります。Wikipediaのパーマリンクがよい例です。
Wikipedia
https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B0
URLエンコードされる前は「https://ja.wikipedia.org/wiki/スラッグ」となりますが、このページを表示してアドレスバーからこのURLをコピー＆ペーストした場合、ブラウザによってコピーされる文字列が異なります。Chromeなら「https://ja.wikipedia.org/wiki/%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B0」が、Edgeなら「https://ja.wikipedia.org/wiki/スラッグ」が入ります。
このように表面的にはマルチバイト文字はきちんと表示されても、内部的にはエンコードされた文字列になるので実装がまちまちで、とても厄介です。はじめからASCIIに収まる形にした方がよさそうです。しかしタイトルも本文も日本語なのにスラッグをどうやって付けるのでしょうか。
たとえばタイトルの日本語が「このサイトを常時SSL化しました」なら「konosaitowo-joujisslka-shimashita」にすればよいのでしょうか。これだと可読性に乏しく、URLエンコードされた文字列とあまり変わりませんね。おそらくスラッグを使っている多くの人は英単語を利用して設定していると思います。
でも内容が日本語なのにわざわざ和英辞書を引いて英単語のスラッグを付けるなんてちぐはぐで、ちっともエレガントじゃありませんよね。もしかするとQiitaがハッシュ値を利用しているのも、内容がマルチバイト文字であることを前提にこうした仕様にしているのかもしれません。
これについての解決策は特に思いつきません。私たちはエントリを書くたびに和英辞書を引くか、自動でID番号やハッシュ値が設定されるようにするかの、どちらかの（あまりエレガントではない）選択肢を選ぶしかなさそうです。
ASCII文字以外を用いる言語圏のサイトを少し見てみましたが、ロシア語では英単語で代替、フランス語やスペイン語では発音区別符号を無くした母国単語と英単語の混在などの形にしているようです。

3-2. 長期的な使用に耐えるURLとは

ブログのパーマリンクについてSEO的にどのようにすればよいか書かれたエントリは多数ありますが、正反対のことを主張する二つの勢力に分かれているようです。それは「カテゴリをパーマリンクに含めるか否か」です。
WordPressのパーマリンク設定を変更して、SEOや日本語URLの対策をしようhttps://liginc.co.jp/web/wp/customize/148458

http://トップレベルドメイン/カテゴリー名/投稿名（英数字）
「http://liginc.co.jp/web/wp/custmize/145732」という形ですね。
パッと見ただけでも、Web関連でWordPressのカスタマイズにまつわる記事なんだろうな、ということが想像できるようになりました。
結論から言うと、おおむね上のようなパーマリンク構造が理想的です。

【WordPressのパーマリンク】おすすめの設定と理由https://fujimotoyousuke.com/2017/01/wordpress-permalink-setting/

パーマリンクにカテゴリ名を入れたほうが良いという人もいますが、わたしはおすすめしません。

二つの勢力に分かれているだけあって容易に解決できる問題ではないのですが、私は「カテゴリをパーマリンクに含めるべきではない」という立場をとります。なぜならカテゴリは（少なくともブログのパーマリンクとしては）長期的な使用に向かないと考えるからです。
以下ではそれについて触れていきます。

3-2-1. 階層構造の弱点

Google Cloud Platformのブログエントリでは、
https://library.com/shelves/american-literature/books/moby-dick
のような分類による階層構造を伴うURLが示されています。見たところ分かりやすいURLですし、実際インターネット上でもっともよく見るタイプのURLだと思います。
ところがパーマリンクは「Permalink」の文字通り、恒久・不変である必要があります。困ったことに、こういった分類というものは途中で弄りたくなるものです。動植物の分類学でしょっちゅう変更があるように、「このページはこっちだったけど、あっちでまとめた方が良さそうだな」みたいなことが起きる可能性があります。これは長期的に運用すればするほど高まります。
もちろんそういった場合のために、301リダイレクトという方法があります。しかし細かい話をすると、そのマッピングがあることで運用コストはどんどん上がっていきます。初めから無いに越したことはありません。特に私の場合何度かの移転を経てマッピングが膨大で、これ以上増やしたくないのです。
はじめに前提条件として「個人が所有するブログのパーマリンクに主眼を置く」と述べました。個人が所有するブログである以上、私のように十数年と運用していると興味関心がどんどん変わっていきます。その都度ブログを作るのも良いですが、私は文章のはけ口を一箇所にしたいのです。もしそういう場所でカテゴリ分けをするのであれば、なるべく長期間それが機能するものでなければなりません。この教訓は私が10年以上前、このサイトをブログに再構成したときに作ったカテゴリが現在は機能していないという事実に基づくものです。

3-2-2. 階層を廃したURLとは

ではカテゴリを使用しない場合、どのような形が「エレガント」なのでしょうか。
私のブログのパーマリンクについて再掲します。
yagi.tc
https://yagi.tc/archives/2017/10/16/always-on-ssl/
これをよりエレガントにするには2つの方向性があります。一つはスラッグのみにしてしまうことです。
https://yagi.tc/always-on-ssl/
内容について推測ができ、それでいてシンプルです。階層構造が一切ないので、スラッグを設定する名前空間に気を付ける必要があります。（サイトの連絡先が書かれた重要なページも、ただの一エントリも同じ階層に所属することになります）
気を付けなければならないのは、Movable TypeのようにHTMLファイルをパブリッシュ（出力）するタイプのCMSでは、一ディレクトリの直下に大量のファイル（またはディレクトリ）が存在することになるため管理が煩雑になります。なのでこれはWordPressのようなタイプのCMSに向いています。
もう一つはタイムスタンプのみにしてしまうことです。
https://yagi.tc/2017/10/16/
または
https://yagi.tc/20171016/
スラッグではないので内容については推測できませんが、ブログは時系列で更新していくので割と理にかなっていると思います。特にテクノロジーなど陳腐化の激しい分野を扱う際、URLから書かれた時期を把握できることは重要です。（テクノロジー系のブログエントリなのに書かれた日付がどこにも表記されてなくて怒りに震えることはよくあることです）
難点は、この形式では一日に最大一エントリしか扱うことができないことです。時刻の2桁まで入れれば一時間に最大一エントリになりますが、パッと見てそれが時刻であると認識できる人は少ないと思いますので、思い切って時分秒まで入れた方が良いかもしれません。
https://yagi.tc/2017/10/16/12/00/58/
または
https://yagi.tc/20171016120058/
作家の結城浩さんは自らの文章をまとめるのに以下のようなURL形式にすることを検討しているようです。

以前から結城はタイムスタンプを使った14桁の数が大好きです。 14桁の数というのは「2017年10月31日12時34分56秒」なら、 20171031123456のことです。
いろんな文章をネットのあちこちに書いていても、 作成日時をもとにした14桁の数ならば、 散らばらずにぎゅっと集約できます。 そして、
　hyuki.org/20171031123456
のような形で、自分の活動へのリンクとできないだろうか。 結城は「仕事の集約」をそんなイメージで描いているのです。
（結城浩の「コミュニケーションの心がけ」2017年10月31日 Vol.292）

同じ形式ですね。
なお、一般的にはスラッグの代わりにエントリIDを用いたパーマリンク
https://example.com/789/
または
https://example.com/?p=789
も見かけますが、万が一CMSを変更した場合にIDが変わる可能性があることから、あまり推奨できません。

3-2-3. バージョン番号を付ける構成

APIでよくあるURIにバージョン番号を付けたものがあります。
https://www.googleapis.com/upload/drive/v2/files/fileId
これを応用すればバージョン番号ごとに異なるパーマリンク体系を採用できるので長期間の運用に耐えられるのでは……と思いましたが、結局後方互換性を残すために全バージョンでCMSを運用し続けないとパーマリンクとして機能しないので、運用コスト的に現実的ではなさそうですね。HTMLファイルをパブリッシュするタイプのCMSではアリかもしれません。

3-3. より踏み込んだ議論

長期間の運用を前提にする場合、上記以外にもパーマリンクを構成する要素はなるべく普遍的なものを使用するのが良いと思います。
以下は要素として挙げるのみで、具体的な議論は行いません。

  • 自然言語の選択
    • 英語以外のURLがメジャーになる可能性があります
  • マークアップ言語の選択
    • https://example.com/example.html より https://example.com/example/ が好ましいです
    • 現在はHTMLですが、XML等の形に置き換えられる可能性があります
  • ドメインの選択
    • ランニングコストが安く、メジャーなgTLD/ccTLDが適しています
    • サーバ運用上／メールアドレス運用上、タイプする量が少ない方が好ましいです
  • サブドメインの選択
    • https://www.example.com/ より https://example.com/ が好ましいです
  • スキームの選択
    • 現在はhttpからhttpsに移行しつつありますが、ポストhttpsが今後出てくる可能性があります

4. おわりに

長くなりました。
結論としては、スラッグ形式とタイムスタンプ形式を組み合わせた以下のような形式でいこうと思います。
https://yagi.tc/2017/always-on-ssl/
以上

独自ドメインのWordPressを常時SSLに変更する際の注意点

2017年10月24日

先日このサイトを常時SSL（AOSSL、または常時HTTPSとも）に対応させました。いろいろと知見がありましたのでまとめておきます。

要点

私は今回以下のことを実施しました。

  • Apacheからnginxへの変更とconfigの書き直し
  • Let’s Encryptの導入
  • HSTSの導入（※必須ではない）
  • ドメインのネームサーバの変更（※必須ではない）

それによって得たTips/注意点は大きく以下のとおりです。

  • SSL/TLS対応状況確認について
  • nginxのconfigについて
    • “/.well-known/acme-challenge/”へのルールを設定しよう
    • HSTS設定を有効にするのは最後にしよう
    • SSL/TLSプロトコルバージョンの指定はよく確認しよう
  • Let’s Encryptの導入について
    • 試行錯誤は”–test-cert”オプションを使おう
    • cron実行時に”–force-renewal”指定は避けよう
  • WordPressについて
    • 混在コンテンツのデバッグにはSearch Regexなどのプラグインが便利
    • 混在コンテンツを許容する場合はネットワークパス参照が使える
    • ソーシャル連携では「いいね」数やブックマーク数の引き継ぎ対応が必要
  • ネームサーバについて
    • 今後証明書を発行するならCAAレコードが必須になりそう

SSL/TLS対応状況確認について

確認のための便利なサイトがあります。
SSL Server TEST
https://www.ssllabs.com/ssltest/
このように、うまく対応できていれば「A+」の結果になります。

nginxのconfigについて

nginx1.12+PHP7.1環境において、nginxのconfファイルは最終的に以下のようになりました。
（一部改変しています）

server {
    server_name example.com;
    listen 80;
    listen [::]:80;
    root /var/www/html;
    # Let's Encryptで使用するディレクトリ
    location ^~ /.well-known/acme-challenge/ {
    }
    # Let's Encryptで使用するディレクトリそのものには404を返す
    # （つまり配下に実在するファイルのみ200を返す）
    location = /.well-known/acme-challenge/ {
        return 404;
    }
    # 上記以外のすべてをHTTPSにリダイレクトする
    location / {
        return 301 https://$host$request_uri;
    }
}
server {
    server_name example.com;
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    root /var/www/html;
    location / {
        index index.html index.php;
        try_files $uri $uri/ @wordpress;
    }
    location ~ .php$ {
        try_files $uri @wordpress;
        fastcgi_pass unix:run/php/php7.0-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
        include fastcgi_params;
    }
    location @wordpress {
        fastcgi_pass unix:run/php/php7.0-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root/index.php;
        include fastcgi_params;
    }
    charset utf-8;
    access_log /var/log/nginx/access.log;
    error_log  /var/log/nginx/error.log;
    # Let's Encryptで設置されたファイル
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    # HSTSの設定（最大365日間は常時リダイレクトする）
    add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout 5m;
    # プロトコル設定など
    ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
}

基本的にはこのコピペでいけると思いますが、初めてnginxの表示を確認するなど常時SSLがまだ始まっていないときは以下の行（19、53、54、57行目）をコメントアウトしてください。

    # 上記以外のすべてをHTTPSにリダイレクトする
    location / {
        return 301 https://$host$request_uri;
    }

まず19行目。当然ながらnginxインストール直後でHTTPでの表示を確認したい場合はここをコメントアウトしてリダイレクトを無効にしてください。

    # Let's Encryptで設置されたファイル
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

その場合、まだ53～54行目のファイルが存在していないので（19行目が無効であっても）エラーになりnginxが起動できません。あわせてここもコメントアウトしておいてください。Let’s Encryptのcertbotを起動しファイルが作成されたらコメントインしてHTTPSでの表示確認を行ってください。

    # HSTSの設定（最大365日間は常時リダイレクトする）
    add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';

57行目は常時SSLを実現するHSTSの設定です。HSTS（HTTP Strict Transport Security）はHTTP接続を強制的にHTTPSへリダイレクトし、以後はすべてHTTPSで接続する機能です。上記では1度接続したら最大365日間（31536000秒間）HTTPSを使い続ける設定になっています。HTTPSの表示確認中の段階ではこの行はコメントアウトしてください。でないと手元の表示環境でHSTSが効いてしまい、一度HTTPSで表示したページをHTTP表示に戻したい場合などにうまく表示されなくなってしまいます。都度ブラウザのキャッシュをクリアするか、最後の最後にコメントインするようにしてください。
includeSubDomainsの指定はサブドメインにもHSTSが適用されるようにするための設定です。preloadはプリロード登録のためのものです。今のところ私はプリロード登録をしていませんがいちおう残しています。
HSTSの設定についてはこちらのページも参考になります。
常時SSL化（https）するときのHSTS設定の方法と注意点
http://tuono034s.com/web-entry/2310/
それから、63行目のプロトコル指定はnginxのバージョンによりますので確認して指定してください。2017年10月現在、最新バージョンのnginxにおいてTLS1.3はドラフト版のみの対応となっており、厳密には以後の動作保証ができないため外しています。

Let’s Encryptの導入について

導入方法については他のサイトを参照するとして、まだ試行錯誤段階である場合はcertbotの実行時に”–test-cert”オプションを付けてテストサーバに接続するようにしてください。メインサーバの方には一定期間内の接続回数に上限があり、何回か繰り返すと弾かれます。
テストサーバでテスト用証明書を取得した後、証明書をそのままにしてメインサーバへと接続すると、既にある証明書を置き換えるかどうか尋ねられるので自動実行の際は注意してください。
また、certbotのrenewコマンドをcronで実行する時は”–force-renewal”オプションを使わないようにしましょう。Let’s Encryptのサーバに不要な負荷をかけることになります。
以下のページも参考になります。
Let's encrypt運用のベストプラクティス – Qiita
https://qiita.com/tkykmw/items/9b6ba55bb2a6a5d90963

WordPressについて

WebサーバだけをHTTPS対応させても、読み込むコンテンツ（JavascriptやCSS、iframeなど）がHTTPだと混在コンテンツ（Mixed Content）となり、ブラウザで警告が出ます。これらを取り除くためにはブラウザの開発者ツール機能などを利用しながら一つ一つ取り除いていく必要があります。
読み込み元によっては “http://example.com” を “https://example.com” に置き換えればよいだけのものもありますし、URLが変わるために丸ごと書き換えが必要なものもあります。
特定のサービスを利用しているなどで一括置換できる場合は、Search Regexなどのプラグインを利用するのがよいでしょう。正規表現が使えますし、置換前後を確認しながら置換していくことができます。
これらのツールはエントリ内などで内部リンク（aタグやimgタグ）を絶対指定で行っている場合の置き換えにも使うことができます。便利。
◇
もし常時SSLを行わない場合で、あるページがHTTPでアクセスされるかHTTPSでアクセスされるか一定しない場合、埋め込まれたリソースを「src=”http://example.com～”」などと指定して読み込んでしまうとブラウザで警告が出ることがあります（混在コンテンツ）。この場合はネットワークパス参照を使用してURIスキームを省略し、「src=”//example.com～”」などと指定することで、ブラウザ側で読み込み元ページのURIスキームに合わせて解釈してくれます。あまり見ない記述方法ですが、RFCに準拠した方法であり、最近のブラウザでは正しく動きます。もちろんこの場合、どちらのURIスキームであっても埋め込みリソースに正常にアクセスできる必要があります。
◇
常時SSLを行うとURLが変わるため、ソーシャル連携していた場合「いいね」数やはてブ数が引き継がれません。特殊な対応が必要になります。

ネームサーバについて

今は必須ではありませんが、今後SSL/TLS証明書の取得には、第三者による発行を防止するためドメインのネームサーバにCAAレコードを設定するよう求められるようです。CAAレコードについての解説は以下が分かりやすいです。
DNS CAA レコード設定について – さくらのサポート情報
https://help.sakura.ad.jp/hc/ja/articles/115000139062-DNS-CAA-レコード設定について
現在CAAレコードに対応しているDNSサービスは少ないですが、HTTPS化の流れとそれに伴うCAA必須化の流れに乗って今後続々と対応が進むでしょう。私の場合はGoogle Cloud DNSを使用して有料で運用しています。