builderscon.ioMySQLでパウンドケーキ(とクッキー?)を焼くというもので、元になった記事はこちら。gihyo.jpあのガムテープでオーブンを常にオンの状態にしておくというハックがウケました。あとはMySQLの2つめのイシューで「MySQLではトーストを焼けない」というのがあったらしくて、その辺の知見も面白かったです。(これも上記記事で解説されています)3つ目はこちら。builderscon.ioおそらくこの日一番の「盛り上がったで賞」という感じでしたが。発表の元になった記事はたぶんこちらで、qiita.com結果としてはこのような感じでしたが(ビルコン用に用意された動画みたい)。www.youtube.comwww.youtube.comもうこの発表はね・・とにかくトークが面白かったですね。すれば人が笑うのか、という構造をある程度わかってて話を進めている感じがあって、非常にリラックスしながら終始笑いながら聞きました。builderscon.ioじつはというか、これはちょっと複雑な問題をはらんだ発表で、後からCoC(行動規範)絡みの議論がしばらく起こりました。会場で聞いていたときの素朴な感想としては、初めのうちはマッチングアプリの概要や課金の仕組みみたいなものを見ながら「そんな風になってるのか〜(知らなかった、を知ったなあ)」と感心して聞いていましたが、途中ぐらいからちょっと説明の中で女性をモノ扱いしているように感じられてしまうくだりがいくつかあって、「ん〜、なんか・・居心地わるいな」と思い始めていました。なんというか、この話って会場にいる女性、普通に嫌なんじゃないかな・・と。その後、感想ツイートなどで問題性を指摘するものがいくつか出てきて、「ああ、やっぱりそう思ってた人けっこういたんだ。・・」という感じになったり。上記で「複雑」と書いたとおり、案外現場にいると、サッと動いて「それアウト!」とも断定しづらい事情はいくつかあって、第一にトーク全体の方向としてはあくまで技術にまつわる話をしているので、その「主題は技術」という前提が、ある種反応を「遅らせた」みたいなところがあったように思っています。それから、これはどこか反フェミニズム的な考え方にもつながりそうなんだけど、結局そのマッチングアプリって「どっちもどっち」感が醸されているというか、「たしかに男性も女性をモノのように見るかもしれないけど、逆も然りじゃん?」という見方を許すサービスでもあるので、「あくまでマッチングアプリに関する話です、出てくる女性も女性全般を想定しているのではなく、このサービスの利用者に限定した話です」みたいな見方もありうることを考えはじめると、「もしかして許容すべきなのか・・?」と思えてしまう部分もあるというか。後から冷静に考えれば、「聞いてる側が微妙になってる時点で駄目でしょ」とは簡単に言えるわけだけど、現場で即ストップするというのは、よほど事前にそういう状況を強く想定していないかぎり、難しかったんじゃないかな・・というのが現時点でのその現場に対する考えです。それから、今回の発表者およびその段取りを進めた人たちはおそらくまだ若い人たちで、きっとそういうことに慎重になるだけの知識や経験が少なかったのだろうとも思います。なれば、それはもう各個人だけの問題ではなく、彼らを取り巻く会社・友人・家族などの社会的な不備であり問題でもあるわけで、その意味でも個人を責めるのではなく、関わる人々全体の責任として受け止めるべき部分もあるのかなと。この問題に対して「何が悪いのかわからん」的な反応もゼロではないようですが、それについて言えることはシンプルで、わかろうとする気がない人には何を言っても無駄です。その人は何を言われても「それじゃわからん、俺を説得してみろ」とさえ言えば常に勝てる無敵の人だからです。大事なのは、そういう不毛な戦いをすることではなく、共に幸せに暮らせる社会を作るために力を合わせていける相手と、議論を積み重ねながら、より豊かな場所を作り続けることだと思います。次回予告さて、いつもの私ならこのまま脇目もふらずに翌日(本編初日)の話に入っていくところですが、各日の午前・午後および懇親会などのトピックが待ち構えていることを考えると、記事がかなりの長尺になることが予想され、かつその推敲(というか修正)も大変な量に膨らんでいきそうなので、一旦ここまでにします。風穴さんとお会いしたり・・などの話は忘れず書いておきたいところです(忘れないようにメモ)。(食べ物ばっかりですが)とかもたぶん含めます(メモ2)。Hub」に寄稿しました。初歩的なコードだけで身近な問題を解決!」です。Perlの連載なので、ここで言う「ツール」とか「コード」はPerlのそれですね。その他、掲載誌の目次など詳細情報については下記をどうぞ。gihyo.jp執筆に至る経緯など、大まかな話は前回書いたので、今回はその具体的な内容についてまとめてみたいと思います。いうぐらい知られた雑誌ですから、話をもらってから引き受けるまでは一瞬でしたが、いざ取り組んでみると想定外の問題がいろいろと噴出・・。工程前半のテーマ設定には苦労したので、その辺りから。最初に話をもらった時点で大まかなテーマとして提案されたのは、「大掛かりではないけどつど便利に使えるPerl活用法」みたいな、「小道具としてのPerl」みたいな、いずれにしてもまさにぼくがいつもやっているようなことを、そのままちょっと紹介して、という感じだったと思います。これについてはぼくとしても、自分が書けるとしたらそんなネタだろうな〜と思っていましたから、「ではそれで。」という感じでスムーズにスタートしたのですが、実際に書き始めてみると、いやこれってそんなにシンプルなテーマでもないな・・ということがわかってきました。いうのも、第一にどうしてぼくがそういう「小ネタ的なプログラム」を量産しているのかと考えてみると、それはぼくが「大掛かりなプログラムを書けない(そのための技術がない)」からで、つまりそうした小さいプログラムの背景には、ぼくが「非エンジニア」であることが密接に関わってるんですよね。対象のコードについて何か書こうとすると、どうしてもその説明の中で自分の非エンジニア的な側面について触れざるを得なくて、でもこれって文章全体を通してみるとけっこう邪魔というか、テーマをボヤけさせるノイズにもなりがちなんですね。一つ、今回は既存ツールの概要やTIPSを紹介するのではなくて、自作のコードを示しながら解説する体を取ることになるので、ということは上記の「小道具としてのPerl」や「非エンジニアである私」といった要素に加えて、「自作ツールのお披露目」という、これはこれでちょっとレイヤーが異なる要素が生じてきます。当初はこの辺りの切り分けをほとんどしないまま、「まあ、とりあえず書いてみましょう、なんとかなるっしょ」みたいな感じでスタートしたので、初稿ではまさにそれらが渾然一体となったものが仕上がってしまったのですが、その問題点をメイン監修者の牧さんからズバッと指摘されまして、それで対象とするテーマをグッと絞り込むことになりました。それでどうしたかと言うと、ある意味では最初期のテーマ(「小道具としてのPerl」)に立ち戻りつつ、「非エンジニア」の要素は最小限まで減らして、話の軸としては「初心者でも扱えるPerlの基礎構文だけで、便利なツールが作れる!」みたいなことにフォーカスすることにしました。ぼくの性格・指向的には、ついあっちこっちに話題を飛躍・拡散したくなりがちなんですが、とにかく「基礎構文だけで便利なツール」という点に軸足を置いて離さない、ということを考えるようにした、という感じでしょうか。この原稿はたしかアウトライン(見出し案)を3月から書き始めていましたが、このテーマに定まったのは・・結局5月の半ばぐらいでしょうか。その間もけっこう休みなく書いていたので、だいぶ時間がかかりましたね。懸念と対策さて、そんなふうに具体的に書き進める中で、テーマとは別に、いくつか新たな問題が出てきました。言っても、これはあくまでぼく自身が問題視していただけで、他の人から言われたわけではないんですが、簡単に言うとぼくのコードの正当性というか、妥当性というか、信憑性みたいなものが不安だなと。いうのも、ぼくが普段書いてるコードって完全に自分の中に閉じているもので、一応GitHubに公開しているものも少なくはないですが、その内容が間違っていたからって誰が困るものでもないので、ようは他人のレビューというものをほとんどまったく受けてないのですよね。そんなコードをいきなりWEB+DBに載せるなんてできるわけがないし、直すったってどこから直したらいいのか😇という感じなので、こういう悩みは他のプログラマーの人が執筆する場合に比べて、けっこう独自のものだったのではないかなあ、と思います。そのために監修の皆さんがいらっしゃるというか、掲載にあたっては事前にコードもチェックしてもらえるわけですが、とはいえ対象によってはそれなりに膨大なコードになるので、実際にそれを全部手元で動かして確認してもらうとかはちょっと現実的ではないし、仮にそれをやってもらったところで「直せ」と言われて直せるとも限らないし、さらにはそんなふうにコードを直したら当然文章の方だって影響を受けるはずだし、というのでこれもまたなかなか大きめの懸念に。したかと言うと、とにかく誌上に出すコードは可能なかぎり初歩的・基礎的なものにとどめて、コード周りの推敲が最小限になるようにしました。これによって、コードとそれに伴う文章を延々直し続けるような事態は避けられますし、文章もメインテーマの「基礎的なコードだけで便利ツールを作る」を維持しながら仕上げることができます。デメリットとしては、一部のトピックでは具体的なコードを示せず、「あとはGitHubを見ておいて」みたいになっているので、そこで技術的な物足りなさや違和感を感じさせてしまう可能性もあるなとは思いましたが、それはもう、すみませんがそういうものとしてお受け取りください、という感じで割り切ることにしました。記事構成そんな感じで徐々に固まっていった記事の中身は、大きく4つの章で構成されています。最小限のコードで書くそれぞれひと言で言ってみると、1番では主にPerlだけで書いた超シンプルな初心者的コードを、2番ではそれにシェルコマンドを組み合わせたものを、3番ではpecoなどの他のツールを組み合わせたものを、そして4番では再び超シンプルな小ツールを紹介しています。この章立てもかなり終盤の方まで編集さんと議論しながら詰めていったのですが、原則的には、「単純なものから複雑なものへ」とか、「昔のコードから最新のコードへ」みたいな時間の流れを意識して組みました。記事解題といった前段を踏まえつつ、以下ではその各章で取り上げたトピックや関連リンクなどを記していきます。基礎構文でツールを作るここでは上記のとおり、Perlだけで書かれた単純な、しかし自分の実作業を飛躍的に効率化してくれたツール群を紹介しました。あまりにもシンプル過ぎて、これを「ツール」と呼んで良いのか、という問題もありそうですが・・とはいえ、ここで紹介しているコードは、ぼくが実際の仕事の作業をする中で「これプログラミング使わずに全部手作業でやっていたらめっちゃ大変だったろうなあ」と実感していたものばかりで、なおかつぼくのプログラミング初期の頃から使っていたものなので、記事の最初はとにかくこれを取り上げなきゃ、と思って紹介しました。ちなみに、ここで取り上げた各ツールの利用シーンとしては、ぼくがフリーランス時代に手がけていた音楽全集の編集作業がかなりの割合を占めると思います。commmons.comそれもあって、記事中では当時の詳しい素材データなどもわずかながら例として出していますので、クラシック音楽好きの人には面白がってもらえるのでは・・と少し思っています。シェルコマンドを組み合わせるここではMacのopenコマンドをはじめとするシェルコマンドを、Perlと組み合わせる事例を紹介しています。考えてみると、ぼくが普段書いてるコードって、だいたいここまでに扱ってる技術ばっかりで、それより複雑なものってほとんどないのですよね。ほんとにプログラミング始めて1〜2ヶ月ぐらいの人でも十分に書けるものだと思うので、そういう意味では(とくに非エンジニアの人には)参考にしてもらえるかもしれません。具体的なところだと、「複数ファイルの行数や文字数をカウントする」で紹介しているツールは上記の編集者時代に頻用しましたし、あるいは「複数のWebサイトを一斉に開く」とかは我ながら単純すぎてちょっとバカっぽいなとも思いますが、でも地味に便利なんですよね。ほかのツールを組み合わせるメインはこの章だと思っています。ぼくが普段めっちゃ使ってる自作ツールを次々紹介していますので。note103/choco今回扱ったツールの中で何かひとつだけ選べと言われたらこれを選ぶぐらい、ぼくにとっては必須のものなので、これを紹介できたのは良かったなと。toolそのpecoを開発している牧さんが今回のメイン監修者だったので、なんというか・・今にも逃げ出したいような😱でも非常にありがたいような、得がたい経験をさせてもらいました。note103/carvoこれは冷静に考えると便利ツールでもなんでもないんですが(笑)、しれっと含めることができてよかったかなと*1。あとはAgっていう文字検索ツールを手軽に使うためのツールとか。GitHubこれもかなり使用頻度が高くて、作り始めたときよりも今の方が使ってるかも、というぐらいよく利用してます。最小限のコードで書く最後の章はこちらですが、ここでは今まさに会社で自分の業務のために使ってるツールを紹介しています。今月発売のWEB+DB記事の最後で紹介しているツール、今まさにめちゃ頻用して安堵している。2019年8月5日そこで言ってるのがこのツールです。GitHubあまりにも短いので誌上でもほぼ全部載っけています。詳しい用途については記事で解説しているので、そちらをご覧頂きたいですが、とにかく出社して編集仕事をしているときは必ず使っているので、そのつど「ああ、作ってよかった」と思っています。ええと、曲がりなりにも過去10年にわたって編集の仕事をしてきて、その間にはプロの執筆家の方々と毎日のようにやり取りしたり、その原稿を読んだり、時には自分でもテキストを書いたりしてお金をもらってきたわけなので、最初はどちらかと言うと、同誌に寄稿する他のプログラマーの人たちよりも自分の方が「本業の人」として取り組んでいる自負があったのですけど、いやあ・・やってみるとめちゃめちゃ大変で、「本当にみんな、こんな大変なことをいつもやってるの??」という思いが何度も湧き上がりました。上記のとおり、この作業はたしか今年の3月からスタートしていて、まあ仕事をしながらではありますけど、でも土日はかなり使っていたし、平日も仕事から帰宅後に深夜まで及んで対応したりして、それでも入稿*2の数日前まで修正してましたからね・・。普通に本業で編集・執筆やっていたときと同じぐらいの労力および時間を費やしてようやく間に合いました・・みたいな感じだったので、ほんとに他の執筆者も編集さんもみんなすげ〜な〜・・というリスペクトの気持ちでいっぱいです。これで税別1480円、めちゃめちゃ安いですよ(笑)。180ページほどの中にとてつもない価値と手間が詰まっています。GitHub以下はどこまで詳しいことを公開していいのかわからないので概要までですが、今回の記事はGitHub上で進行しました。これもありがたかったですね。ぼくは基本的に、日本語テキストの編集もじゃんじゃんGit管理(というかGitHub管理)できたほうが良いと思っているので、環境的には申し分なかったです。Kaigi」というイベントに参加したときに、編集長の稲尾さんが登壇しているのを見てざっくりは知っていたんですけど、gihyo.jpまさかそのフローを自分も体験できるとは(笑)5年前の同会場では想像もできなかったですね。(細かいフローはだいぶアップデートされてると思いますが)GitHubの良いところは、とにかく前のバージョンを残せる、見返せる、というところだと思います。消したい過去も残るわけですが、基本的には同じ目標に向かって進むひとつのチームですから、仮に恥ずかしい間違いや操作ミスがあっても、それはそれでべつにいいや、という感じで遠慮なく使わせてもらいました。Issueなどの機能もけっこう初めの方からバリバリ使って、思ったことはなるべくそのつどオープンに伝えるようにしました。この辺は生来の空気読まない気質が良い方に作用したかなと思っていますが、まあ同時に、その意見言い過ぎなところがいつまでも執筆・編集が終わらない遠因になったのかも・・という気も今してきましたが。話を戻すと、GitHubを使うとテキストベースで正の情報をアップデートしていけるので、それがありがたかったです。最終的には、本番デザインに組んだデータの方が正(最終版)になるわけですが、それでも簡易的なレイアウトや文字数はギリギリ最後の方までGitHub上のプレーンテキストでチェックできるようになっていたので、この辺はやっぱり技評さんならではの技術力と言いますか、助かりましたね。コミュニケーション編集チームとのコミュニケーションも円滑で良かったです。編集長の稲尾さん、この1コーナーにここまでコミットしてくるのか(笑)と驚くぐらいすごいスピードで動いてくださって、これがプロの仕事・・という感想でした。硬軟のバランスというか、アメとムチの出し方というか(笑)あれよあれよという間に執筆モードに誘導され、必要な環境がセットされ、気がついたら集中して取り組んでる、みたいな感じでした。工程の後半は同編集部の渡邉さんに担当してもらいまして、こちらも毎回迅速なレスポンス、かつぼくのめんどくさい相談にも深いレベルで検討&回答してくれて、ありがたかったです。良かったのは、お二人ともレス(返信)が確実に来るんですよね。いうのも、個人的にはレスって、べつに「早ければいい」というものではなくて、一番良いのは「想定どおりのタイミングで来る」のが良いレスだと思っていて、その意味で最悪なのは「めっちゃ早いときもあればまったく来なくなるときもある」というやつで、逆にその日のうちに返事が来なくても、毎回「午前の問い合わせには翌日午前、午後の問い合わせには翌日午後に返事が来る」みたいにパターンが一定なのがありがたいというか。事前に予告されていて、そのとおりに返ってくるとか。いう、ある意味基本みたいなところがきちんとされていてありがたかったな、と。監修の牧さんにも、pecoの使い方でどれだけ怒られるかと戦戦恐恐としていましたが(←大げさに言いました)、改善点の提案なども論理的・丁寧に示してもらって、とてもやりやすかったです。終わりにということで、丸々4ヶ月ほどにわたって取り組みました執筆もようやく終わりまして、またこの解題をもって本件全体についてもひと区切りかなと思います。さん、編集部・監修者の皆さん、ありがとうございました。見ぬ読者の皆さん、どうぞお楽しみください。『ノルウェイの森』で小林緑が言った、以下の言葉を捧げます。