技術書典4の戦利品の感想・その1

日曜日に参加した技術書典4ですが、

hmatsu47.hatenablog.com

こんなTweet

おはようございます #技術書典 Day2です。きこえますか…技術書典で戦利品を獲得したみなさんのタイムラインに直接呼びかけています…。感想をブログやTwitterに書くのです…著者がすごい喜びます…。めっちゃ喜んで次のモチベに繋がります…。

— mhidaka@技術書典 (@mhidaka) 2018年4月22日

があり、「ちゃんとお金を支払って感想を書くまでが技術書典」ということで、まだほとんど読破できているものはないですが、さらっと目を通したものだけ一言感想を書きます。

※カード利用額の口座引き落としができたら…という前提ですが、支払いは済ませました。

shutdown実践入門／講釈sync（第7開発セクション／tbofficeさん）

ネタのつもりで買いました。

RHEL7などsystemd系でshutdownがDeprecatedのような扱いになっていたのに気づいてなかったです。収穫あり。

また、syncを打たずに外付けUSB HDDをumountしてデータを飛ばしかけた現場を目撃したことがあります（さすがにテープドライブはWindowsでしか使ってな…いや、そういえば、RS/6000上のAIXで使ってたことを思い出した！）。

DNSをはじめよう（mochikoAsTechさん）

当日合流したまみーさんにお勧めした本ですが、お勧めしておきながら買わないわけにはいかない！と思って購入。まだきちんと読破できていないので目を通しただけですが、とにかく技術的なこと以外も丁寧に書かれていて、うちの会社のサポートメンバー（技術的なことはよくわからないけど仕事でドメイン関連のことをやってる）が読んでも理解してもらえそうな気がします。

マンガでわかるDocker／マンガでわかるScrapbox（湊川あいさん）

会場に入った時に場内で列ができてて「あ、やっぱり」と思いましたが、その後、ブースが別の場所に移動するという予想外の展開が（笑）。

インフラ屋ですがDockerはこれまで縁がなく、そろそろ使い始めねば（同僚は朝早く喫茶店に自前PC持ってきて個人研究してるらしい…業務でやらせたげて！）というところで購入。Scrapboxのほうはおまけでいただきました。

新しい技術・サービスに手を出すことへのハードルを下げるのに、マンガでの平易な解説、ホント良いです（という月並みな感想）。

Introduction of Elastic Stack 6（りまりま団／もふもふさん）

ちょうどAWSのElasticsearch Service（6.0）でログ分析環境を立てたので、理解が乏しい部分を埋めるべく購入。

ALB/CLBのアクセスログをElasticsearch Service (6.0/6.2) に取り込むメモ - Qiita

CloudFrontのアクセスログをElasticsearch Service (6.0/6.2) に取り込むメモ（手抜き編） - Qiita

TABLE形式のAurora（MySQL互換）スロークエリログをElasticsearch Service (6.0/6.2) に取り込みS3に保存するメモ - Qiita

Elasticsearch Service (6.0/6.2) に取り込んだログ（INDEX）をCuratorで削除するメモ - Qiita

LogstashやBeatsは使わずLambda経由でログ取り込みをしていますが、LambdaでCuratorは使っています。「Elastic Stackで作るBI環境」のKindleリフロー版もちょっと前に購入したので、結構「理解の穴埋め」ができそう…かな？2章を流し読みした感じでは期待できそう。

日経電子の本（Nikkei Engineer Team）

「本」とありますが、体裁は「新聞」です。縦書きです。無料配布されていたものをいただきました。内容、盛りだくさんです。コード（横書き）もあります。広告もあります。ラテ欄と小説、天気予報（事前に用意してたら間違って「雨」予報してたかも？）、今日の運勢は残念ながらありません。

Markdownライティング入門（SOLARSOLFA／藤原 惟さん）

普段、Qiitaで記事を書いていながら、あまりMarkdownのルールを知らず、はてなブログのMarkdown編集モードの存在に最近まで気づいていなかったぐらいなので、購入しました。さらっと見た感じではルールのあたりにもきちんと触れられているようなので、あとでちゃんと読みます。マスターできれば会社の開発チームの情報共有に役立ちそう。

（その2へ続く）

hmatsu47.hatenablog.com

技術書典4と東京国立博物館、びわ湖長浜 KANNON HOUSE（4/22）

予定通り、技術書典4に行ってきました。

techbookfest.org

EX-ICのグリーン早特でひかりに乗って行ったので、細かい時間調整ができず、ちょっと早めに会場に到着。

途中、間違ってサークル参加者列に並びかけたり、一般参加者が集まりすぎて「ここにとどまらないで。整理券はまだ配布しません」と言われてどこへ行こうか困っていたところでその10分後くらいに唐突に整理券配布が始まったり（人が集まりすぎたので仕方がないと思う）、整理券を貰ったところで入場列に並ばずにいたら、500番までまとめて入場列が形成されたり（100番台だったのに結局300人目あたりで入場した）、入場したら中でも列が形成されていたりと、若干混乱しながらも約1時間、中を回ってきました。

…と書くと、運営がグダグダだったように読めるかもしれないですが、予定外の事態になった時に臨機応変な運用変更が行われていたので、全体としては混乱がなくうまく回すことができていたのではないかと思います（不満がある人もいたとは思いますが、今回は整理券番号を厳密に見て入場順を決めていたら、かえって混乱が生じて無駄な待ち時間が生じたはず）。

もっとも、過去と比べると参加人数が増えすぎて、同じ会場で同じ規模のサークル参加があると、会場のキャパを超えそうです…。

帰り際、14:30頃の様子も、午前中とあまり変わりがない盛況ぶりだったので。

今回の戦利品はこちらです（ネタ込み）。

少し遅めのお昼を済ませた後は、目黒の雅叙園の百段階段でねこでも見ようか…と思っていましたが、時間が微妙なのと「暑さで帰りの登り坂が辛い」のとで諦めて、上野へ。

まずは、いつもの（？）東京国立博物館へ。

東京国立博物館 - トーハク

特別展「名作誕生－つながる日本美術」ということで、4種類の「つながり」をテーマにした展示を見てきました。

常設展は、高村光雲の「老猿」などを軽く眺める程度にとどめて退館。

上野公園を縦断し、「びわ湖長浜 KANNNON HOUSE」へ。

www.nagahama-kannon-house.jp

「横山神社の馬頭観音立像」を見て絵葉書を買って、上野を後にしました。

本日は暑かったせいもあり、移動を控えたので10,000歩ちょっと。ほどほどに疲れて帰ってきました。

MySQL 8.0.11 GAリリース記念／くだらない小ネタ（STATEMENT_DIGEST）

どうやらMySQL 8.0がGAになったようですが、

MySQL :: MySQL 8.0 Release Notes :: Changes in MySQL 8.0.11 (2018-04-19, General Availability)

Qiitaに書くほどのことでもないので、こちらでくだらない小ネタを1つ。 

先日、Qiitaにこれ

qiita.com

を書いたのと、みんな大好き世界のyoku0825さんが、これ

yoku0825.blogspot.jp

を書かれたので、あらためてMySQL 8.0のリファレンスマニュアルを読み返したところ、

ここ

MySQL :: MySQL 8.0 Reference Manual :: 12.13 Encryption and Compression Functions

と、ここ

MySQL :: MySQL 8.0 Reference Manual :: 25.9 Performance Schema Statement Digests and Sampling

で、正規化したSQLの表現が若干違うのが気になりました（後者にはカラム名等のバッククォートがない）。

実際に確かめてみたところ、前者が正しい表現でした。

で、ついでに「どこまで正規化されるのか？」が気になったので、軽く試してみました。

バッククォートと空白、キーワード／予約語の大文字小文字は、

mysql> SELECT STATEMENT_DIGEST('SELECT `hoge1`, `hoge2` FROM `hoge`.`fuga`');
+------------------------------------------------------------------+
| STATEMENT_DIGEST('SELECT `hoge1`, `hoge2` FROM `hoge`.`fuga`') |
+------------------------------------------------------------------+
| 1b1547c6f30f8a648296cbac9c40857014fab13917c7e6aaccb915eabb9194e3 |
+------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT STATEMENT_DIGEST('SELECT hoge1, hoge2 FROM hoge.fuga');
+------------------------------------------------------------------+
| STATEMENT_DIGEST('SELECT hoge1, hoge2 FROM hoge.fuga') |
+------------------------------------------------------------------+
| 1b1547c6f30f8a648296cbac9c40857014fab13917c7e6aaccb915eabb9194e3 |
+------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT STATEMENT_DIGEST('SELECT hoge1, hoge2 FROM hoge.fuga');
+------------------------------------------------------------------+
| STATEMENT_DIGEST('SELECT hoge1, hoge2 FROM hoge.fuga') |
+------------------------------------------------------------------+
| 1b1547c6f30f8a648296cbac9c40857014fab13917c7e6aaccb915eabb9194e3 |
+------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT STATEMENT_DIGEST('select hoge1, hoge2 from hoge.fuga');
+------------------------------------------------------------------+
| STATEMENT_DIGEST('select hoge1, hoge2 from hoge.fuga') |
+------------------------------------------------------------------+
| 1b1547c6f30f8a648296cbac9c40857014fab13917c7e6aaccb915eabb9194e3 |
+------------------------------------------------------------------+
1 row in set (0.00 sec)

こんな感じで同じものとしてうまく正規化されました（ダイジェスト値が同じ）。

mysql> SELECT STATEMENT_DIGEST('SELECT HOGE1, HOGE2 FROM HOGE.FUGA');
+------------------------------------------------------------------+
| STATEMENT_DIGEST('SELECT HOGE1, HOGE2 FROM HOGE.FUGA') |
+------------------------------------------------------------------+
| 6c952560d06129f0ec76ebfb8e2180af28821831d1dd75c7fc3bf4f03a85dc41 |
+------------------------------------------------------------------+
1 row in set (0.00 sec)

カラム名については、大文字・小文字の区別があるので別のダイジェスト値になります。

※「lower_case_table_names」の設定に関わらず、の模様。

文字列（定数）のクォートの違いについては、

mysql> SELECT STATEMENT_DIGEST("SELECT 'aaa'");
+------------------------------------------------------------------+
| STATEMENT_DIGEST("SELECT 'aaa'") |
+------------------------------------------------------------------+
| d1b44b0c19af710b5a679907e284acd2ddc285201794bc69a2389d77baedddae |
+------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT STATEMENT_DIGEST('SELECT "aaa"');
+------------------------------------------------------------------+
| STATEMENT_DIGEST('SELECT "aaa"') |
+------------------------------------------------------------------+
| d1b44b0c19af710b5a679907e284acd2ddc285201794bc69a2389d77baedddae |
+------------------------------------------------------------------+
1 row in set (0.00 sec)

という感じで、表記が揺れても同じダイジェスト値になりました。

…しかし、クエリキャッシュが活用されていた頃にはキャッシュされたクエリが正規化されなかったのに、5.6→5.7→8.0と、クエリキャッシュが非推奨→廃止になる一方で、SQLの正規化機能が向上する（パフォーマンススキーマでMD5正規化対応→SHA-256対応→関数で正規化SQLのダイジェストやテキストも取り出せる）というのは、なんだか皮肉な感じですね。

※正確には、クエリキャッシュでは定数を「?」に置き換えてはいけないので、正規化の範囲が違いますが。