portal shit!

ANA のマイル貯めたくてマイルが貯まるクレジットカードのこととかいろいろ調べてみたけど、あれは富裕かつ時間にも余裕のある層の道楽という感じがする。普通に暮らしててもすでに結構豊かな暮らしをしてる人が、その出費でさらにポイントを得ていい思いをしようというものだと思った。庶民が同じようなやり方でマイル貯めようとしても無理だと思う。陸マイラーの人たちみんな平気で年間 500 万くらいカード決済してるっぽい。

お金を使わなくてもポイントサイトでなんかやればマイルもらえるとかあるけど、 FX 口座開設して口座に入金して実際に取引をした上でポイントがもらえるとかそういうやつは、貯蓄額が限りなく 0 に近い自分にはできない。クレジットカードをじゃんじゃん発行しまくってポイントをもらうというやつも、ゴールドカードやアメックス、ダイナースのカード発行は審査が通らない。なのでマイル乞食ブログでよく紹介してある「ポイントサイトで貯めたポイントをマイルに変換して特典航空券を取得してビジネスクラスでハワイ旅行」みたいなのは、すでに現段階で年収 1000 万以上あるお金持ちにしかできない道楽という感じがする。

加えて仕事が忙しくなく、時間にも余裕がないとポイントサイトでちまちま募集案件を調べたり、様々なポイントを効率よいルートで交換していってマイルに変えたり、ポイントをもらうために 1000 円分だけわざとリボ払いになるようにカードの引き落とし額を調整する、とかいったことに時間を割くことができない。

なので陸マイラーになりたいと思ったらまずは

• 年収 1000 万を目指す
• 9 時 5 時で終わる仕事に就く

必要があると思う。しかしこんなのは 30 歳過ぎた人間が今から達成することは不可能で、若い頃にちゃんと勉強して医学部に入り開業医になるだとか、食いっぱぐれない資格を取得して士業に就くとかしないと無理っぽい。陸マイラーブログとかやってる人、大半が開業医か弁護士か司法書士か税理士（会計士は忙しそう）なんじゃないかと思う。あるいは政令指定都市の閑職公務員。小学生に戻って人生やり直すしかない。

アドベントカレンダー、去年は自分で一個作ってみた。

できる Mac OS X Advent Calendar 2015 - Adventar

 愛用している Mac のアプリケーションについて書いてみませんか。 みんな使ってないけど個人的にとても気に入って使ってる秘蔵のソフトとか、あんまり定番じゃないものを取り上げて順番で紹介していったら面白いのではないかと思って作ってみました。 ### カレンダー作った人が想定している情報 - Mac App Store で 3000 円くらいするけど有益で十分金出す価値あるソフトの情報 - Free だけど便利、しかしインストールに少し知恵のいるソフトのインストール方法 ### 多分求められてない情報 - エバーノート徹底活用術（笑） - Photoshop 用無料テクスチャ 10 選 TeX でも MacVim でも Cocoa Emacs でも QuarkXPress でも Excel でも何でもいいので書いてくれ！！！、！！！、！、！！！

adventar.org

カレ主（カレンダー作った人 = 自分のこと）以上にほぼ毎日記事を書いてくれた人（ trurusuke さん）がいて記事埋まったけど、 trurusuke さんのコントリビューションがなかったら全然スカスカだった。

自分でも複数記事書いたけど、一番最後は年明けの 2/27 に書き終わったりしてて最悪だった。

Soulver と Calca

この記事はできる！ Mac OS X アドベントカレンダー 20 日目の記事でしたが遅れて書いています。遅れてすみません。 テキストを入力するためのソフトはいま色々ある。プログラミング向け...

portalshit.net

アドベントカレンダー、作るからには真剣にファシリテートしないといけない。軽い気持ちで始めると書いてくれる人に失礼だしそもそも誰も登録してくれない。仕事でプロジェクトをリードするのに似てる。よいアドベントカレンダーをファシリテートできる人は仕事やオープンソースソフトウェアプロジェクトや町内会、保護者会、学生サークル・社会人サークルなどでリーダシップを発揮することができると思う。自分はどれもさっぱりなのでカレ主になれるような器ではなかったのだ。

Adventar 、最近は登録されるカレンダーの数めっちゃ数増えてて、奇をてらいすぎてるものや個人の日記、カレ主にやる気がない（去年の自分）ものも散見される。 25 個の枠が埋まってない状態のやつが増えてきてるのではないかと思って 2012 年から調べてみた。 JSON API を用意してくれてた Adventar++ 。

⚡ curl -s http://www.adventar.org/calendars.json?year=2016 | jq '. | length'
530
⚡ curl -s http://www.adventar.org/calendars.json?year=2016 | jq '. | map(select(.entries_count==25)) | length'
125
⚡ curl -s http://www.adventar.org/calendars.json?year=2016 | jq '. | map(select(.entries_count>=20)) | length'
169

⚡ curl -s http://www.adventar.org/calendars.json?year=2015 | jq '. | length'
510
⚡ curl -s http://www.adventar.org/calendars.json?year=2015 | jq '. | map(select(.entries_count==25)) | length'
236
⚡ curl -s http://www.adventar.org/calendars.json?year=2015 | jq '. | map(select(.entries_count>=20)) | length'
281

⚡ curl -s http://www.adventar.org/calendars.json?year=2014 | jq '. | length'
311
⚡ curl -s http://www.adventar.org/calendars.json?year=2014 | jq '. | map(select(.entries_count==25)) | length'
142
⚡ curl -s http://www.adventar.org/calendars.json?year=2014 | jq '. | map(select(.entries_count>=20)) | length'
168

⚡ curl -s http://www.adventar.org/calendars.json?year=2013 | jq '. | length'
230
⚡ curl -s http://www.adventar.org/calendars.json?year=2013 | jq '. | map(select(.entries_count==25)) | length'
112
⚡ curl -s http://www.adventar.org/calendars.json?year=2013 | jq '. | map(select(.entries_count>=20)) | length'
129

⚡ curl -s http://www.adventar.org/calendars.json?year=2012 | jq '. | length'
42
⚡ curl -s http://www.adventar.org/calendars.json?year=2012 | jq '. | map(select(.entries_count==25)) | length'
27
⚡ curl -s http://www.adventar.org/calendars.json?year=2012 | jq '. | map(select(.entries_count>=20)) | length'
30

下落傾向かと思ったけど調べてみたらそんなことなくて大体毎年 50% 弱くらいみたいだった。最初の年の 2012 年が枠埋まり率高い。個人的には闇アドベントカレンダーと寿司アドベントカレンダーがあった 2013 年がアツかった気がするのだけど枠埋まり率は 45% で 2015 年と大差ない。各年の 20 枠（ 80% ）以上埋まり率も調べてみたけど同じような傾向だった。

すべての情報を表にまとめると以下のような感じ。

最初の年を除いて、大体半分弱の全枠埋まり率、半分強の 20 枠以上埋まり率であるということがわかった。クラウドファンディングみたいに 12/1 までに枠埋まり率が 8 割に達しなかったらカレンダー不成立としたらどうかと思った。その方がスリルがあるしだるいアドベントカレンダーが量産されたりしないと思う。運営におかれましてはクラウドファンディング的システムの導入を検討してもらえたらうれしいです。あと携帯からも見やすいようにレスポンシブウェブデザインにして欲しい。

それにしてもだるい。

この記事はアドベントカレンダーだるい Advent Calendar 2016の三日目の記事でしたが一日遅れて書いています。四日目は空いていて五日目は ouka_puyo さんです。

追記 2019-09-22

2016 年の数字が 2016 年 12 月頃のものだったのでデータを取り直した。 2017 年、 2018 年のデータも追加してグラフも作ってみた。

こうして見ると 2 年目から 20 枠埋まり率と 25 枠埋まり率に大きな変化はないことがわかる。年数が経過するにつれてアドベントカレンダーに参加するユーザーの質が変化するのではと思ったが、 201X 年代でブログをやってる人となると結構変わり者でユーザーの質に変化はなかったのだろう。

Docker で rep2 を動かす - portal shit!

なぜ 2016 年にもなって rep2 を使うのか。実は２ちゃんねるはほとんど見ていなくて、まちBBSを見ている。特に大人になってから他県から移り住んできたような人だと住んでる町に同級生や昔からの知り合いというのがいないので町のちょっとした情報というのがきわめて入って来にくい。近所の人たちは自分の親かそれよりも上の世代の人ばかりなのでなかなか気軽に情報交換するということもできない。となるとネットで情報収集したいと思うけど、そういうのができる場所はまちBBSしかないような気がする。

ブログは今どきやる気がある人しかやってないので情報が少ない。情報あったとしても福岡だと天神だとか博多だとか薬院だとか人が集まる場所の情報がほとんど。自分が住んでる町の情報にはなかなかたどり着けない。 Twitter は検索しても出てくる情報にばらつきがある。たとえば住んでる町の名前で検索しても、同じ地名が横浜や姫路にあったりして効率が悪い。そもそも Twitter は町の情報よりもその人の思ったこと、感じたこと、やってることがメインなので効率的に情報を収集できない。 Facebook は基本的に情報が閉じられているし、知らない人から情報を集めるというより知ってる人の近況を読む場所という感じ。 mixi はどうだろうかと思って、 10 年ぶりくらいにアカウントを作って自分が住んでいる町のコミュニティに参加してみたけど誰も人がいなくて閑古鳥が鳴いてた。

今年の梅雨頃、マチマチというウェブサービスできて地元の人とお店や病院の情報などをやりとりできるという話だったので、これこそ求めていたものだと思って飛びついたけど、お前がこの町の最初のユーザーだから一ヶ月以内に 5 人ユーザー集めろや、できなきゃマチマチ上のコミュニティは閉鎖な、という厳しいルールだった。嫁さんはこういうのは一切興味ないし近所の人はじいさんばあさんばかりなので当然 5 人もユーザーを集めることはできず終了した。そもそも近所に知り合いがいないからネットで情報を集めたいと思ってるのに知り合いはお前が人力で集めろというのは難易度が高いと思う。

まちBBSは30代以降みたいな人たちが皆好き勝手に自分が書きたいことを書いているけど、最近できたあの店はどうだとか、あそこの病院はよくないだとか、どこそこの店が閉店して別の店になる、移転する、などのような情報を仕入れることができる。当然匿名掲示板なので嘘やネイティブ広告（工作員による宣伝投稿）も時々はあるけど、まぁ読み手もそれは織り込み済みなので特に問題はない。少なくとも SNS よりかは格段に情報に触れやすい。掲示板はトピックが決まっていて、多少脱線することはあってもそのトピックについて話すので、福岡の今宿の話かと思っていたのに横浜の今宿だったみたいなことはないし、失恋してつらいさみしい、今年の夏に別れた彼氏と行った今宿の花火大会の写真です、みたいなおセンチツイートを目にすることもない。 2016 年になったいまでも掲示板が一番情報を集めやすいのかもしれないなぁと思った。

VPS 上で Docker を動かし、 rep2 ¹ 入りのコンテナを運用するようにした。

ホストの 81 ポートをゲストの 80 ポートに向けてマッピングし、ホスト側の Nginx で localhost:81 にプロキシするようにした。

まちBBS のスレッドの >>1 の記事があぼーんになる現象を直したので快適に閲覧できるようになった。

https://github.com/yaasita/docker_rep2 を docker hub から pull してきて最新版の rep2 を使うようにちょこちょこっと修正し、共有ディレクトリ内のコンテンツを /var/www に置くように修正した。なのでホスト側で PHP を編集したものがゲスト側に反映されるし、コンテナを落としてもデータが残り続ける。最高便利。

Docker 、これまでなかなかユースケースが思いつかずいまいち便利さがわからなかったのだけど、手元に PHP 入れたくないとかごちゃごちゃしたセットアップしたくないとかいうときに異常に便利。 rep2 のようなレガシー PHP 環境が必要なソフトを動かすのにもってこいだと思う。

このブログも Docker で運用できないか考えてみたい。

むかしやってた映画のブログ（ WordPress ）のデータをこのブログに取り込もうとしたら、 mysqldump しといたデータが文字化けして読めなかった。 映画ブログのデータベースの文字コードは utf-8 にしてたけど、 Dreamhost の MySQL サーバーの defualt-character-set がおそらく latin1 になっていたと考えられ、 mysqldump するときに utf8 のデータが latin1 として export されてしまい文字化けを起こしていたっぽい。

vim で開いて e ++enc=utf8 してみたり、 nkr で変換しようと試みたり、ググって出てきた Perl のスクリプトで変換しようと試してみたけど直らなかった。この変換は MySQL 自身にやらせないとダメなのではと思い、以下を試したがダメ。

• [x] latin1 で DB 作成し latin1 で import 、 utf8 で export
• [x] latin1 で DB 作成し utf8 で import 、 utf8 で export

結局、 Stack Overflow にあった以下の方法で解決できた。

utf 8 - Detecting utf8 broken characters in MySQL - Stack Overflow

I've got a database with a bunch of broken utf8 characters scattered across several tables. The list of characters isn't very extensive AFAIK (áéíúóÁÉÍÓÚÑñ) Fixing a given table is very straightfo...

stackoverflow.com

一旦文字化けしたまま utf-8 の文字列として import し、以下の SQL を流す。

UPDATE [table_name] SET [column_name] = CONVERT(BINARY CONVERT([column_name] USING latin1) USING utf8);

やっぱり MySQL で化けたデータは MySQL で直すしかないみたいだった。

アウトライン・プロセッシング入門を読んだ

『アウトライン・プロセッシング入門』という本を読んでみたら意外とよかったのでアウトラインとアウトライナーについて思っていることを書きます。

読んだきっかけ

WorkFlowy というアウトライナーについて調べてたらよく紹介されていたので読んでみた。 WorkFlowy というのはウェブベースのアウトライナー。 Google で「 WorkFlowy 」で検索すると Evernote でライフハックしまくりお父さんみたいな人たちが群生してる様子が観察できる。犬のえさやりタスクや子どもを公園で遊ばせる予定などをどうやってクラウドで管理するかみたいなことをアツく語っている。

良かったところ

アウトライナーの使い方を見直した。最近の自分のアウトライナーの使い方は間違っていた。

アウトライナーとは

文章の概要・目次を書くために使うものというのが一般的な理解。文章を箇条書きにして書くことができる。箇条書きにした内容を入れ子にしたり、順番を並べ替えたりできる。しかし概要や目次の作成だけにアウトライナーを使うのはもったいない、というのが本書の趣旨。

自分のアウトライナーの使い方

昔

以前はよくアウトライナーを利用していたが、最近はあまり使わなくなってしまった。暇だったためブログの記事を書くのに時間を割くことができたので、アウトライナーで入念に内容を練ってから書くようなことをしていた。ブログに投稿する直前までアウトライナーで書いていたので、書きながらつながりのおかしいところがあると文章を入れ替えたり見出しを付け替えたりが楽だった。

最近

職業プログラマーになって Vim を使うようになり、 Vim で書くのが一番速く書けるようになった。何でも Vim で書くようになり、アウトライナーは最初のアウトラインを考えるときだけ使うようになった。このようなスタイルではアウトラインが最初に固定されてしまい、つながりが不自然なところがあってもそのまま突き進むしかなく、文章を書いていて何とも言い表しようのない息苦しさがあった。¹

アウトラインはどんどん変わっていくべき

アウトラインは決して不変なものではなく、文章を書いていてアウトラインが修正されていくのはよいことだといえる。アウトラインを修正しながら本文を書いて行くことができるのがアウトライナーのメリット。雑に書き出された断片的な内容を「シェイク」という過程で並び替え、論旨を整えていくプロセスが良い文章を書く上で重要。最初のアウトラインの作成にだけアウトライナーを使うのはアウトライナーのメリットを享受できずもったいない。アウトラインを先に作ってからの文章作成はウォータフォール型の開発に似ていると思う。アウトライナーで最初から最後まで書くのはアジャイル型の開発に似ている。小さく区切って作業を進め、こまめに振り返り、変化に対応することで良い成果物＝読みやすい文章ができあがる。

アウトライナーで最初から最後まで書くことの問題点

アウトライナーで書けば万事オッケーかと言われるとそうとも限らない。書き終わった文書の管理が問題となる。

いま

memolist.vim で書いて Day One.app に保存している。 Terminal で grep するか Day One の検索窓で検索すると必ず目的のものにたどり着ける。

アウトライナーで文書作成

個々のファイルに内容が分断してしまう。こうなると検索しづらく、参照性が低い（「ファイルの壁」問題）。ただ一部のアウトライナーはこの問題に対応している（後述）。

アウトライナーで書いて Vim で Markdown 形式に整えて清書、 Day One に保存すれば検索できそうだが若干面倒くさい。しばらく頑張ってみる。

Mac で使えるアウトライナーいろいろ

Tree 2

http://www.topoftree.jp/tree/

www.topoftree.jp

個人的に一番よく使ってる。安くて機能シンプル。 iOS 版がないのがちょっと残念。

OmniOutliner

Outlining Software For Pros - OmniOutliner - The Omni Group

Outlining software for professionals that helps structure their ideas.

www.omnigroup.com

昔は OS にバンドルされてて、 .plist の拡張子のファイルを開こうとして勝手に立ち上がったりしてうざかった。最近の OmniOutliner は横にカラムを追加して Excel みたいな使い方できる。一見、地獄っぽい。Excel 方眼おじさんに OmniOutliner を与えると泣いて喜ぶかもしれない。

TaskPaper

TaskPaper – Plain text to-do lists for Mac

www.taskpaper.com

実は TaskPaper はアウトライナーそのもの。タスクを書き出すという行為、アウトラインで考えを整理する行為に似てる。したがってよいタスク管理ソフトはアウトライナー的な側面を持つ。実際アウトライナーでタスク管理する人は多い。

MindNode

MindNode

Mind mapping and outlining for Mac, iPhone, iPad and Apple Vision Pro.

mindnode.com

実はマインドマップも OPML （アウトラインプロセッサーの共通フォーマット）で書き出せるためアウトライナーとして使える。ミーティングなど大人数でブレインストーミングしながらアウトラインを作成するときは MindNode のようなマインドマップの方がよい。

WorkFlowy

A simpler way to organize your work - Workflowy

If you have a crazy job or an ambitious project, we will be your trusty sidekick. Workflowy is a simpler way to stay organized.

workflowy.com

WorkFlowy なら先述の「ファイルの壁」問題を解決してくれる。従来なら個々のファイルに分かれていたアウトラインを一つに統合し、個々の Node として扱う。ファイルは一つしかないので分断が起こらない。一つのアウトラインの中に自分のすべての思っていること・考えていることが保存される。

WorkFlowy は「ファイルの壁」を突破した使い方が出来るが、 SaaS なのでオンラインでないと使えない。飛行機の中などインターネットにつながらない場所でアウトライン書けない。完全ローカルで使える買い切り型の WorkFlowy があったら最高²。オフラインでも使えるインストール型のアプリの方が動作が速くて快適なのは自明だ。アウトラインが増えてくると結構高い Pro プランにしないといけないのもつらい（月額 $4.99）。

なお以下のリンクから登録してもらえると僕とあなたの無料で使える WorkFlowy のアウトライン数上限が 250 個増えるので登録してやってもよいという方は是非よろしくお願いします 🙇🏻

A simpler way to organize your work - Workflowy

If you have a crazy job or an ambitious project, we will be your trusty sidekick. Workflowy is a simpler way to stay organized.

workflowy.com

まとめ

自分の文章の書き方、アウトライナーの使い方を見直した。文章作成の大半の部分をアウトライナーで行い、 Vim を使うのは文章の最終仕上げ段階だけにとどめたい。そうすることでつながりのおかしい文章や読みにくい文章を避けることができる。

『アウトライン・プロセッシング入門』は Kindle オーナーライブラリにあって無料で読めるので Amazon プライム会員の人は読んでみるといいかも。よい内容は最初の方に集約されています。

おまけ

このブログの記事でアウトライナーで割と最後まで書いてた文章の例。

• 家を買ったので得られた知見を共有します
  • 最初は普通に書いていたが文章が冗長で読みにくさを感じたので文章のダイエット目的で箇条書きにしてアウトライナーで書き直した。
  • はてブで 2000 ブックマークくらい付いた。
  • 箇条書きのつながりが良く読みやすかったのかもしれない。
• 糖質制限で脱デブ成功しました
  • ほとんど最後までアウトライナーで書いたが「シェイク」不足。
  • 文章が読みにくく、ほとんどブックマークされなかった。

京都であった RubyKaigi 2016 を観覧してきた。 RubyKaigi 、つくばであった 2010 がこれまでの人生での唯一の RubyKaigi で、人生二度目の観覧だった。

RubyKaigi 2010 の思い出

一度目のときは少し前に増田に上がってた勉強会ゴロ状態（受付の人と技術書を買ったジュンク堂の人と以外誰とも会話をせずに帰宅）だった。

ちなみにこのとき ESM の企業発表を見に行って、 ESM に転職したばかりの hsbt さんの姿を初めて目にした。なんか入社したばかりなのに社内ブログで暴れてて愉快、みたいな紹介のされ方だった。その後同じ会社で働くことになるとは思いもしなかった。

ESM の発表はとにかく鮮烈に印象に残ってて、ペアプロのライブコーディングだった。 ursm さんが CRM か何かの開発を実演してた。まず最初に落ちるテストコードを書いて、その後にパスするプロダクトコードを書く、というやつを初めて目にして、田舎で HTML コーダーをしつつちょっとしたプログラムを書いてた自分は衝撃を受けた。黒い画面の Vim で高速にコードを書いていく様がとにかくかっこよかった。はやくこういう感じでコード書けるようになりたい、と思ったものだった。

クックパッドの企業発表みたいのも聞きにいって、このときクックパッドもまだそんなにエンジニアの数多くなかったはずで、同じくはてなから転職してきたばかりのセコンさんが話してるのを聞いてトートバッグもらって帰った。

YAPC::Asia Tokyo 2015 の思い出

去年の夏、 YAPC で東京に行って、このときはペ社時代の知ってる人としゃべったりして無言の帰宅は避けられた。

YAPC 2015 は気がついたときには懇親会の申し込み締め切られててどこにも行けず、一人浜松町の宿泊先の近くの「とにかく安くて量が多い」と食べログにレビューが書いてある寿司屋に入って一人で寿司を食べたら寿司がねちゃっとしてて具合が悪くなったりしてた。

YAP寿司::Asia 始まった pic.twitter.com/5AI2FXedlJ

— morygonzalez (@morygonzalez) August 21, 2015

RubyKaigi 2016

今年も発表する側にまわったわけではないので一般ピープルである点は同じだったが、これまで話したことなかった人と話せたのがよかった。

取り分けよかったのが Fjord 社の komagata さんと話せたことだった。今後の Lokka の方針をどうするか開発者会議的なものを開催してババっと方針を決めましょう、という話をした。 Lokka 、思い入れがあるので積極的にメンテナンスに関わって今後も長く使い続けていきたい。

一日目

一日目は Kaizen Chat についてのブログ記事を公開するというタスクがあって、 Matz のキーノートとかはあまりじっくり聞けなかった。記事公開後に会社のブースで自分のシールを配布したりして公私混同してた。

今年の RubyKaigi は懇親会の枠が大きかったおかげで申し込みそびれるということにならなくてよかった。

オフィシャル懇親会で Fusic 社の k1low さんと初めてゆっくり話をした。Fukuoka.rb で顔を合わせることあっても一緒に酒飲んだりする機会なかったので RubyKaigi に来て初めてじっくり話すという感じだった。

ヒトデさんとその愉快な仲間たちの皆さんとも話して、 shikakun はオリジン弁当ばかり食べてるくせにやたら調理器具を持っていて不可解だとか、風呂蓋付きの浴室がある部屋にすんでいていけすかないという話をした。

Twitter で 8 年くらい前にハゲクラスタとしてわいわいやってた send_ さんとも再会できて、お互い帽子をかぶった状態でいまの仕事の話をしたりした。

オフィシャル懇親会のあとは、ヒトデさんオーガナイズの二次会に参加させてもらった。デンエンという物価が崩壊してる飲み屋に行ってタワーから注いで飲むビール飲みまくった。クックパッド社の著名エンジニアの皆さんと対面に座ったけど人に自慢できるような OSS とかなくて雑魚いので自己紹介に困ったが、とりあえずこういうアイコンのものですと言ってシールを見せたら「あ、なんか見たことある」という感じになったのでシール便利だった。

二日目

朝一番の Justin Searls さんのリファクタリングについての発表がとにかく面白かった。

Fearlessly Refactoring Legacy Ruby - RubyKaigi 2016

September 8..10, Kyoto, Japan

rubykaigi.org

去年 YAPC で GitHub の人が話してた sicientist と似てるけど、リファクタリング前後のコードで A/B テストをする gem の紹介。新しい方のメソッドが例外投げたら rescue して古い方のメソッドを実行するというのが面白かった。本番にも安心して投入できるとのこと。

三日目

午前二番目に tkawa さんの HTTP クライアントについての発表聞いた。 HTTP クライアント乱立しててひどい、 API をラップしてリモートサーバー側のクラスを再現するような異常なクライアント多くて、 REST API とは一体何なのか状態だ、みたいな話だった。言われてみれば確かにそうかもしれない。独自の API クライアント作ることなく、 Rack が Rack Middleware を use して拡張していくみたいに、 HTTP クライアントの側でも Middleware を use していくのがよい、そこで Faraday ですよ、という話で、あ、 Faraday ってそういうことを目的にしてたんだと膝を打った。

午前中最後の Chris Arcand 氏の発表が面白かった。

Deletion Driven Development: Code to delete code! - RubyKaigi 2016

September 8..10, Kyoto, Japan

rubykaigi.org

Ruby のコードを解析して呼ばれてないメソッドを調べる、という発表だった。実際に Rails プロジェクトとかで使うのは大変そうに見えたけどいまから君のプロジェクトに投入できるよ、 Rails もダイジョブみたいなことを言ってた気がするのでスライド見直したい。

最後のセッションの前、一日目のデンエン会で知古を得た pastak さん見かけたので uiureo さんを紹介してもらって話をした。 uiureo さん、初対面だけど話しやすくて好青年な感じだった。 r7kamura さんとも少ししゃべらせてもらってよかった。

飛行機の時間の都合があったのでクロージングまでは残らず、最後のキーノートの途中で離席して帰途についた。ホールを出ようとしたところで滑り込みで会場にやってきた元同僚の hisaichi551 さんと邂逅して自分のシールを何枚か雑に渡した。ゆっくり話がしたかった。

京都での開催について

京都での開催良かった。個人的には福岡からだと東京に行くよりも京都の方が近いので移動が楽で良い。首都圏からの大多数の参加者も京都に宿泊して参加するので夜通しどこかで RubyKaigi 関連の飲み会が開かれてる感じで祝祭感あった。夕方から観光したりできて海外からの参加者も満足度高いのではないかと思う。京都国際会館のインフラも素晴らしかった（施設、庭園、食事内容）。スポンサーの提供で振る舞われたお弁当おいしかった。

総合的な感想

RubyKaigi 、海外からのスピーカーの発表はどうやってよいコードを書くかとかリファクタリングとかの話が多い。日本人の発表者の人は Ruby を開発する方の話が多い。（ Ruby コミッターのほとんどが日本人だから）。なので Ruby 本体の開発に興味ない人（ Ruby 開発者ではなく Ruby ユーザーなプログラマー）はぽかんとすることが多いかもしれない。自分は結構ぽかんとしてた。

あと今回多いと感じたのが Concurrency についての話だった。どうやって Ruby で並行性を上げるかという話。 Thread は難しいので素人は手を出すな、ということはわかったけど Ruby 3 の Guild というので素人でも Concurrent なプログラムが書けるようになるかどうかは今ひとつわからなかったので資料を読み直したい（ reuibld.fm の Episode 158 を聞くと良い復習になりそう）。 Ruby 3 に並行処理の使い勝手が向上する前に、他の言語で並行処理について学んで準備をしといた方が良さそうだと感じた。

2010年の勉強会ゴロ状態のときに比べれば、何人かの人と話したりシールを配ったりすることができて、有意義な時間を過ごすことができたと思う。ただアイコンの気持ち悪さで認知されるよりも書いたソフトウェアの知名度で認知される方がよいので、カンファレンスに行って自己紹介するときに「○×というソフトを作ってます」と言えるようになりたい。仕事だけじゃなく、オープンソース活動もやっていけるように頑張りたいな、と気持ちをあらたにした会でした。

公私混同してる pic.twitter.com/nlrFCMOPXb

— morygonzalez (morygonzalez) September 8, 2016