言語は Go、最終スコアは15532点、参考スコアを上から数えると45位だったようです。悔しい。
具体的な取り組みは下の方で述べますが、MySQL移行はバグなく完遂し、さてここからチューニングしていくぞ！という感じのところで終わりました。エンジンが掛かるまでの速度が足りなかった。

毎回、運営の皆様にはいくら感謝しても足りませんが、今回も取り組みがいのある問題で楽しかったです。ベンチマーカーも最後まで待ち時間がほぼなく、スコアも安定していたのでとてもストレスフリーでした。ありがとうございました。

マルチテナントで大量の SQLite3 データベースがあることが分かったとき、ISUCON本を読んだだけの人間には解かせないってことね!と思いながらニコニコしました。

ところで知り合いがたくさん著者に名を連ねているISUCON本ですが、予選の2週間前に購入し、予選開始1時間前に部屋から発掘されました。
30分ぐらいで流し読みしたのですが、大変実利的な内容に溢れているなあと感じました。nginx の upstream で keep-alive を有効にする方法は知らなかった……

9:00 起床

前日も早く寝るぞと自分に言い聞かせながら4時半まで起きてしまい、念には念で8時に掛けた目覚ましが1時間鳴っていました。すでにこの時点で心も体も終わっています。

部屋の隅にISUCON本が積まれているのを発見しました。ちいとぽも積まれています。
h-otterと合流するために移動しつつ、パラパラと眺めます。

10:00

まだ合流のため移動中ですが予選が始まっているようです

10:05

合流しました。 CloudFormation テンプレートを流します

10:22 初回スコア 2732

起動したのでベンチを回しました。この時点で分担も何も決まっていません。

とりあえず kataribe を入れたり pt-query-digest を入れたりします。
「そういえば先日の社内ISUCONで Cloud Profiler 便利だったな……」みたいなことを思いながら、入れ方を調べます。
GCPプロジェクトが必要らしいので作ったり、サービスアカウントキーを発行したりします。予選始まってからやることではない。

11:30ごろ

Cloud Profiler を入れたので眺めました

12:00

h-otter が MySQL 対応の実装を終わらせて、「Uber eatsでも呼ぶか〜」と言いながら、なぜか歩いてマクドナルドに飯を買いに行きます。なんで??

13:03 MySQL移行 3023点

MySQL移行が一段落します。今思うと速かった。

sqlite から SQL をダンプしてゴニョゴニョやり始めて十分程度経ったあと、 sqlite3-to-sql って名前のスクリプトあるけど?? と気付いて笑ってました。先に気付こうね。

とりあえず MySQL に流し込むこと数分、INSERT が一向に終わらないことに気が付きます。このままでは POST /initialize がタイムアウトしてしまうため、バルクインサートをするクエリに書き換えることにしました。

sed で気合でバルクインサートに書き換えましたが遅い。ここで1台目のインスタンスがメモリを食いつぶして死にます。160万件のINSERTを一発でやると死ぬことが分かる。
先日の社内ISUCONでもインスタンスのメモリを食いつぶしたんだよな……と思いながら1台目を捨てます。

これが答えです。

for i in `seq 1 100`; do echo $i; mv $i.sql $i.sql.bak; sed -z -e "s/);\n/);\n\n/" -e "s/NULL\n);/NULL\n);\n\n/g" -e "s/);\nINSERT INTO [a-z_]* VALUES/)\n,/g" $i.sql.bak > $i.sql; done

それなりに早くなりましたが、まだ遅いので tenant の player_score テーブルにおいて、 updated_at が一定以上のレコードを DELETE する作戦に切り替えます。これで10秒程度で POST /initialize が通るようになりました。

DELETE FROM tenant_X.player_score WHERE updated_at > 1654041599;
DROP TABLE tenant_X.competition;
DROP TABLE tenant_X.player;

他のチームの参加記を読んだら 「/var/lib/mysql をコピーする」「毎回 mysqldump を実行する」みたいな筋肉実装が多くて震えました……

確かここらへんで h-otter がなぜか flock を倒す実装を書くもベンチがコケました。
「そこはボトルネックじゃないっぽいし一旦revertしよ?」と、人の競技中の努力を無に帰すような心無い発言をしました。ごめんなさい。

なぜかここからしばらく無の時間が続きます。なぜ……

15:20 3758点

h-otter が competitionRankingHandler の N+1 を潰したようです。

15:50 6336点

グッとクエリを睨んで indexを追加。playerAddHandler がかなり速くなりました。

ALTER TABLE visit_history ADD INDEX (competition_id, player_id, created_at);
ALTER TABLE visit_history ADD INDEX (created_at);
ALTER TABLE tenant_X.player_score ADD INDEX (competition_id, player_id, row_num DESC);

マルチテナントのDBをそのまま持ってきたので、tenant_id は無視するようにしました。

16:08 7923点

h-otter が playerHandler の N+1 を潰したようです。

そして player_score に index を追加。
ALTER TABLE player_score ADD INDEX (player_id, competition_id);

バルクインサートと、JSONシリアライザの変更(encoding/json → goccy/go-json)をした結果、スコアがやや増加しました。(8269点)

16:36 10253点

なんかヤバそうな実装の dispenseId を倒しました。1万点突破。
よくわからんけど順序保証されてたほうが良さそうな気がしたので、 time.Now().UnixNano() を文字列にしてそのまま突っ込みました。爆速。

たしかこのあたりで、 tenant の player_score は (tenant_id, competition_id, player_id) ごとに最新の1行だけあればいいことに h-otter が気付きましたが、あまり速くならず。
この時点で row_num に関する index を落とすべきでした。

既存の tenant_{1..100} に対してもそれを適用しましたが、スコアとしては特に変化なしでした。

このあたりでベンチマーカのログから、タイムアウトでユーザーが減ったという表示がなくなり、ようやくISUCON始まったな! という気持ちになります。すでに手遅れ。

17:03 12505点

h-otter が jwt のパース結果をキャッシュします。神

17:45 14363点

app + DB の2台構成にした気がします。

17:50 15962点

流石にやや諦めムード。ログを切ったりできることをしました。
忘れずDEBUGログを切ったりスロークエリーを切ったりしました。偉い。

「再起動試験はしなくていいでしょ！」で終了

感想

1. MySQL 移行をバグらせずに完遂できた俺達は偉い (本当に偉いと思っている)
2. 毎回意味不明なバグを仕込んで後半暗澹たる感じにあるので、今回はほぼ最後までノーバグで駆け抜けられたのは良かった。良くも悪くも我々は大人になった
3. プロファイラ / スロークエリ / アクセスログの3本柱をちゃんと見ながら走れたのは本当に良かった。常に事実は正しい。fact based / metrics-driven
4. 後半のスコアのブチ上がり方が楽しかった。というかここに来るまでを自分は第一関門を突破した段階だと思っている。やれる改善はたくさん残っていたし、あと1時間あれば更に2倍, 3倍のスコアは出ていたんだろうなと思うと悔しい

そのほか

1. 午前中からの競技は本当に心も体も終了していて何も捗らなかった。ISUCONに必要なのは健康な心と身体
2. デカいテレビで h-otter がリゼ・ヘルエスタと名取さなの原神ガチャ配信をずっと流していた。「縁起がいいと思ったんだけどなあ」って何?
3. その後はリゼがパワプロしてた。リゼ・ヘルエスタについて私が知っているのは第一第二第三皇女のいずれかであるということぐらいです。
4. 最後1時間ぐらいローテンションお嬢様 (壱百満天原サロメ)流したら集中力が0になった。何?

昨日は @icchy さんで 「whywaitaであいうえお作文する」でした。タイトルだけでだいたい想像できますね。

なるほど。

@icchy さんのおすすめインターネットコンテンツは飲酒日記です。

閑話休題。
アドベントカレンダー、書くネタはあれど頭を使うものばかりで泣きそうになったので、とりあえず過去の下書きを漁っていたらタイトルだけ書かれたこの記事の下書きを見つけました。
最近思うこともあったので、すでに忘れ去られ、誰もが忘れたままでいたいと思っていたICTSCのコンテストサイトの歴史を紐解いてみたいと思います。
whyawitaさんとの関わりもあるし、whywaita Advent Calendar的には100点満点のネタですね。よろしくお願いします。

ICTSCとは

早速本題に入りたいのですが、そのためにはICTSCに関する簡単な知識が必要です。
ICTSC (ICTトラブルシューティングコンテスト) は学生による学生のためのインフラ技術を競うコンテストで、最近は年1回開催されています。途中でナンバリングが回数から年号になるの、あるあるって感じですね。
予選もありますが、予選のことは一旦考えないこととして、本選の話をします。選ばれた本選の参加者は、当日の限られた制限時間内に与えられる問題へ挑むことになります。

問題は次のような形式で与えられます。

「A社の技術者であるXさんは、自社の端末からあるWebサイトを開こうとするといつも失敗することに気が付きました。A社の社内ネットワークのトポロジは下の図のようになっており(省略)、ルータの管理コンソールへアクセスするために必要な情報はXXです。あなたはXさんに変わってこの問題を解決してください」

管理コンソールのIP: xxx.yyy.zzz.www
ユーザ名: admin
パスワード: nyannyan

社内端末のIP, ユーザ名, パスワード: …

参加者はこれらの情報を元に、持てる限りの知識と経験を活かして挑み、気合で問題を解決することになります。
(大会インフラとしてはVMがいて、仮想ないし物理のルータがいて……となりますが、今回の本題からはそれるので割愛します)

そうして、問題に不明点があれば質問をし (競技界隈では clar(ification) と呼ばれたりするみたいですね)、解決に必要な情報をまとめて回答します。基本的に回答はテキストで自由な形式で行われます。
運営は提出された回答を読み、必要があれば実際にVMへアクセスして回答の検証をし、採点を行います。
採点を行った結果、正答であれば点数が加算され、不正答であれば改めて参加者が挑戦する、というのが一連の流れになります。

コンテストサイトの必要性

ICTSCでは、約15問の問題が2日間かけて出題され、参加チーム数も15チーム近くに上ります。賞金が出るということもあり、運営は限られた時間内に公平性をできるだけ保ちつつ採点や質問対応といったタスクをこなさなければなりません。
15チームというのは意外と少なく見えますが、人数でいうと60人から80人近くおり、1つのチームでも分担して複数の問題に取り組んでいたりします。そうなると、意外と想像を絶する数の質問や回答が来ます。15チーム×15問で単純に225回答ですし。

私がICTSCの運営にジョインしたのは、遠い昔のICTSC5でした。当時はプロジェクト管理ツールである Redmine を使って出題を行っていました。チームごとにプロジェクトを立て、問題ごとにIssueを立てて、そのコメントで質問や回答の管理をしていた気がします。
この構成で実際に開催を行ったところ、様々なトラブルが生じました。
質問や回答の状況が適切に把握できない(どの質問にまだ返答してないのか?採点は行われたか?)だけでなく、特定チームへの紙のトポロジ図の配布漏れ (これなんで紙で配ってたんでしたっけ?) などが生じました。

今思えばこれなんで起きたんだ?みたいなトラブルですね。Redmineを賢く使えば良かったのではないかと思ってきた……

さて、こういった課題に対処するために若者がやることは一つですね?
そう、「僕が考えた最強のコンテストサイトで解決しよう」です！

コンテストサイトの開発

さて、経緯はどうあれコンテストサイトの開発が始まります。正確にはすでに私の知らないところで一度頓挫していたのですが、忘れます。

今のコンテストサイトは様々あり(後述)、私が知らない構成になっているので、とりあえず私が知っている構成の最後の回のブランチへのリンクを貼ります。

GitHub: ictsc/ictsc-score-server at ictsc2018

さて、途中で採用技術が二転三転している(なぜ?)ので、老害らしく順を追っていくことにしましょう。

ICTSC6

輝かしいコンテストサイト初回導入のときです。当時関わっていた人からはICTSC6の文字列すら見たくないという話も聞きます。当時の振り返りはこちら。

https://github.com/ictsc/ictsc-score-server/tree/ictsc6

開発が始まりました、技術的には、特に面白みのない簡単な REST API + SPA 構成です。

私はフロントエンド技術には疎かったので、同じ運営学生のメンバーの方と、スポンサーの中の方々に協力して頂きました。
一体本業外のこんなことにどれだけの工数を割いていただいたのか、想像を絶する状況になっていたことだろうと思います。本当にありがとうございました。

特に、デザイナーの方にはふわっとしたユースケースから具体的な行動パターンの書き起こしから何から何までお世話になってばかりでした。特に、第6回は初めてコンテストサイトを導入するので何が起こるかわからない、というときに「じゃあ念の為に紙の解答用紙も作っておきますね!」とネタで解答用紙までデザインして渡していただいたときは笑いました。

さて、当時の採用技術は次の通りです。

• REST API
  • Ruby
  • Sinatra (Ruby のシンプルなWebフレームワーク)
  • ActiveRecord (Rails で使われている O/Rマッパー)
  • (SQLite3)
• Web UI (SPA)
  • Angular 2.0
  • RxJS 5.0

REST API の方は私がRailsの経験がほとんどなかったので必然的にこうなりました。Web UIはおまかせしたらこうなりました。package.json 見るとわかるんですけど、Angular 2.0 って当時まだRCなんですよね。尖ってますね
RxJSが使われたコード、当時ちょっと弄ろうとしたら手も足も出なかったきおくがあります。今なら読めるかもしれない

ところで、当時のREST APIには致命的な設計ミスがあり、REST APIでN+1をしていました。例えば、参加者が問題文の書かれたページを開くと、次のようなアクセスが走ります。

• /problems/2
• /problems/2/comments
• /problems/2/issues
• /problems/2/issues/37/comments
• /problems/2/issues/39/comments
• …
• /problems/2/answers
• /problems/2/answers/27
• /problems/2/answers/27/comments
• …

うーんひどい、典型的なN+1ですね。

N+1 はデータ量が少ないと影響が見えにくいので、この問題は回答や質問量が増えてきた2日目に顕著になりました。
そして当時の私はDBにインデックスを貼るということを知らなかったらしい。いま schema.rb 見て吐き気が……

そして、運営は全ての参加者の回答や質問を見ることができる、つまりどうなるでしょうか? 大変なことになります。
10秒経っても帰ってこないAPIが乱舞して開発者ツールはさながらナイアガラの滝の様相を呈していました。同一IPに同時に張れるセッション数限界までリクエストが飛んでドーン、返ってきたら第2弾がドーン、もう見たくない……

当時は完全にテンパっていたのでAPI側の修正を入れる余裕はなく、フロントエンド側で急遽キャッシュ等の対応を入れてもらったものの、却って新しいリソースが見えなくなるなどして大変でした。

そんなこんながありつつも、なんとか(?)大会は閉幕。次回への課題を残しつつ、コンテストは第7回へ続きます。

ICTSC7

知り合いのOB、みんなICTSC7の話しかしたがらんがち。
https://github.com/ictsc/ictsc-score-server/tree/ictsc7

ICTSC6で辛酸を嘗めた私達[誰?]は、次こそは運営がトラブルシューティングしないコンテストにすべく様々な改善を行いました。

• REST API
  • Ruby
  • Sinatra (Ruby のシンプルなWebフレームワーク)
  • ActiveRecord (Rails で使われている O/Rマッパー)
  • MySQL (MariaDBだったかも?)
• Web UI (SPA)
  • Vue.JS 2.1
  • Vuex 2.0

API は N+1 問題を潰すべく、様々な対策が取られました。
その集大成が nested_entity.rb です。この100行に満たないコードがこのコンテストサイトの真価といっても過言ではないでしょう。私はそう思います。
これは要するに「僕の考えた最強のGraphQLっぽいやつ」で、指定した関連リソースをいい感じに取ってきてくれます。こうやって使います。 こんな読みづらい使い方だからだめなんだわ。

これを使うと、上記のICTSC6の例が次の1リクエストで完結します。

• /problems/2?with=comments,issues-comments,answers-comments

便利なのは分かりました。さて、ここで内部的には何をやっているのかというと、大きく次の2つのことを行っています。

• アクセスするユーザの権限によるRBAC (Role-Based Access Control) の適用
• N+1を避けるクエリの生成

コンテストサイトのユーザには、参加者や運営、スポンサーといったロールが割り当てられており、それぞれ見ることができる情報に差があります。例えば参加者が他チームの回答を見られては困りますね。

これ、すなわちRBACを実現するために、全てのロールに対してあらゆるモデルで読めるものを ActiveRecord の scope で定義しています。例えばこんな感じです。
scope とは何かというと、あらかじめ用意されたパラメータの指定可能なクエリといえばいいでしょうか。scope は ActiveRecord::Relation 型の値を返します。これは何かというと、ActiveRecord の抽象的なクエリ表現なので、これを更に合成したりできます。便利

クエリレベルでもN+1を避けるためにはどうしたら良いでしょうか? 気合でクエリを合成したらできそうです。
なんと ActiveRecord はクエリに include パラメータを渡すと勝手に合成してくれます。そうしましょう。
nested_entity.rb では、このあたりで与えられたクエリパラメータをいい感じに ActiveRecord が解釈できる形に変換しています。

全てが ActiveRecord の世界で簡潔するので、RBACもN+1もクエリレベルで表現されます。これはすごくて、あとは全てのロールがアクセスできるリソースをActiveRecordのクエリで表現できれば大丈夫です。つらい、二度とやりたくない。

ちゃんとDBもMySQLにしてインデックスも貼ったので、APIも水平スケールできるようになりました。こうしてコンテストサイトの Iikanji Speed-Up に成功した我々は、その後数回に渡って予選敗退を繰り返しました。何が足りないん?

そして、フロントエンド担当のエンジニアの方の異常な熱意により、唐突に ui2 ディレクトリが爆誕しました。突然のAngular引退宣言に人々は涙を禁じえませんでした。

そうして開催されたICTSC7は、少なくともコンテストサイトについては成功裏に終わったといっても過言ではないでしょう。

ユーザから見える部分としては、問題がこれまでの2日間の午前午後、計4パートでの固定出題から、問題を解くごとに次の問題が解けるようになったり、最初に問題を解いたチームに追加点数(first blood)を与えるようになったりという変化の方が大きかったかもしれませんが、これもコンテストサイトの貢献ということで。

ちなみにこの頃のスクリーンショットがこちら。

ICTSC8

ICTSC8の記憶があまりありません。

https://github.com/ictsc/ictsc-score-server/tree/ictsc8
コミットログを見ると、たしかに差分はあるけどあまり変わってないですね。確かプッシュ通知を実装しました。CyberAgentのFRESHチーム?が作った plasma を使っています。

ICTSC8では小さなバグフィックスやルール変更の対応等はあったものの、それよりはテストを書くことにご執心だったようです。RSpecの鬼になったkyontanの姿が垣間見えますね。増える緑の. (RSpecではテストケースが1つPASSするごとに.がプリントされた)にエクスタシーでも感じていたんでしょうか。
https://github.com/ictsc/ictsc-score-server/tree/ictsc8/spec/requests
相変わらずへんなヘルパー定義しててウケました。そんなんだからお前のコードは人に読まれない。

そうして満足したので運営委員を引退しました。それはそれとして、参加記を見ると毎回のように後悔が綴られていますね。

ICTSC9

関わっていないのでほとんど分かりません。

https://github.com/ictsc/ictsc-score-server/blob/3730cfaa8d62b14a573a1e3a5998f045993e2504/services/nested_entity.rb#L16

ほんまにすまんて

ICTSC2018

運営に出戻ったものの何したのか覚えてません。コンテストサイトには手を出していないはず。

このあたりで API 向けの CLI が生えたらしい。今までシードデータ投入をSQLでやってたのを、 REST API 経由でやるようにしたんですかね。

https://github.com/ictsc/ictsc-score-server/tree/ictsc2018/cli

あとはしれっと Kubernetes 化とかされている。モダンなインフラってやつ

私が知るのはここまでです

ICTSC2019

Big Bang! · ictsc/ictsc-score-server@5d5fd50

唐突に api2 と ui3 が爆誕する。担当者のキレ具合が垣間見えますね。僕も同情します。

• REST API
  • Ruby
  • Rails 6.0
  • GraphQL
  • PostgreSQL
• Web UI (SPA)
  • Nuxt.js 2.0
  • Apollo Client 2.6

ザ・モダン・Webアプリケーション大全。僕の心境としては「GraphQLもどきを作って公園で砂遊びしてたらいつのまにか本物のGraphQLで置き換えられていた、何が起きているのか(ry」って感じです。
DB が Postgres に変わったのはなんでなんでしょうね? 僕は理由を知らないので知っている人がいたら教えて下さい。

増えた機能が多すぎて良くわかりませんが、Webでだいたいのリソースが編集できるようになってたり、問題VMへのアクセスに必要な情報を専用のテーブルで管理できるようになったりしたようです。憶測ですが、VMをプロビジョニングするいい感じのツールと連携していい感じにできるんじゃないですかね。

こうして生み出したプロダクトが自分の手を離れて育っていく様子をまだ学生の身にして実感することができました。ハッピー。

万物は流転する

私事になりますが、先日JANOG47？っていう日本最大級のネットワークエンジニアの集まり？ってやつでNETCONっていうあいしーてぃーえすしー？みたいなのをやるって言われてあれやそれやで運営委員になりました。

どうやらコンテストサイトが必要らしいんですよね。

………というわけで最近forkしました。これどうしたらいいんですか?

そんなこんなで、泣きながら Ruby の GraphQL実装を調べています。ドキュメントの大切さが目に染みる。

明日は同期だったはずのくるとんさんです。ワンワールドサファイアステータスを求めて飛び回りたいという発言を最近目にしましたがお元気ですか?

前回再起動試験で落ちたのでチーム「再起動非対応」で参加しました。ベストスコアは4410点でした。再起動試験までたどり着けなかった……悔しい……

チーム「再起動非対応」は同期3人 (自分 @kyontan, @hogashi, @h-otter) での参加でした。学生は2人いたはずですがエントリーをミスったので学生は1人ということになっています。

使用した言語

私はRubyが一番得意だと思っていますが、非同期処理が書きやすいとか型が着いていると嬉しい、みたいなことはあり今回もGo言語です。
でも今回はN+1潰すときの型マッピングで無駄に時間を溶かしてしまったので、Rubyの方が良かったかもしれない……つらい……

開始前の準備

Prometheus/Grafana等のサーバの設定を @h-otter にお願いしました。前回のコードを読み返しつつ、何をしたかを思い出すなどした。

時間がなくて完全に忘れてしまいましたが、せめて練習はやっておくべきでしたね…

あと、 Alibaba Cloud の UI が色々不思議な感じで良かったですね。

本番

完全に正解していますが、今回はマイクロサービス問だということに気が付いたのは開始してからだいぶ経ってからでした。

開始30分前、チームメイトとの雑談「今日は何がでるかなー」「フリマアプリかオークションかそういうやつでしょ」「マイクロサービスとかね」「わかる〜」 #isucon

— kyontan@新刊はまだ (@sukukyon) September 8, 2019

今回できたことが異常に少ない気がする。kataribeのログを眺めつつ、チームでやったことは以下のことです。比較的時系列だけどそうでない部分もあるかも。

• 開始スコアは 2310
• 10:30 メモリ多いな〜って思っていたら2, 3台目のインスタンスタイプを間違えていたことに気がつく。インスタンス立て直し
  • コードは既にリポジトリへ追加していたのでチームメイトはルール/コードリーディングを進める
• 10:50ごろ: 作業開始
• 11:30ごろ?: MySQL 5.7 を 8.0 へ (@h-otter)
  • スコア変化なし
• 11:45 DBにインデックスを張る(@kyontan)
  • 多分間違えていて、これらにインデックスを貼りましたがあまり効いていなかったようにみえました
  • BigQuery の触りすぎでRDBのインデックスの挙動をほぼ忘れたのも敗北ポイント

config (name)
items (created_at, id)
items (id)
items (buyer_id)
items (seller_id)
shippings (transaction_evidence_id)
transaction_evidences (id)
transaction_evidences (item_id)
users (account_name)
users (id)

• 12:20: カテゴリをオンメモリへ (@hogas, @h-otter)
  • 2510点ぐらい
• 12:30: http2 対応, 静的ファイルをキャッシュ, アップロードされた画像を nginx で返すなど
  • スコア変化なし
• 13:30: config もキャッシュするように
• 14:00: 新着商品には発売中の商品だけを返すようにする (@hogas)
• 14:45  – 16:00: GET /users/transactions.json の N+1 を潰す (@kyontan)
  • 3500点ぐらい
  • なぜか色々ハマって2時間半ぐらい溶かしていた。これは敗北ポイント
  • 多分ここらへんでMySQLがサチらなくなっていた気がする
    • CPUがサチっていたことに気が付いていたが原因が分からず (pprofをなぜ見なかったのか……)
• 15:30: UserSimple が持つ情報は全てオンメモリでキャッシュする
  • ユーザの存在チェックだけするような部分 (権限チェック) も基本的にこれで対応できるのでそうした
  • 4210点
    • ここからスコア上がらず……
• 16:00: 同じクエリを何度か叩いているエンドポイントがあったので潰す (@hogas, @kyontan)
• 16:00ごろ: transactions 以外詰まってないしCPUに余裕があるので campaign (負荷レベル)を弄ったところ外部APIで 403エラー  {“error”:”IP address is not allowed”} が連発しだす
  • 主にGET /users/transactions.json での外部 shipment  サービスへのリクエストで連発
  • 外部APIへの403はアプリケーション的には500を返す仕様だったので、これが連発してベンチマーカが途中終了し完走しない
  • ここらへんで手詰まりに
• 17:00: 明らかに不要な SELECT FOR UPDATE を削除 (4箇所+ぐらい)
  • これかこれの次辺りで4410点。これがベストスコア
• 17:10: 外部APIを叩く部分で exponential backoff を実装 (@h-otter)
  • 変化なし / 403 が連発する
• 17:30: 外部APIをリクエストするエンドポイントだけ2台へ分散する
  • 403 の連発は解決せず、なぜ……
• 18:10: 最終スコア0点 (failed) で終了

色々施策を打つもスコアの変化要因が今ひとつ分からず頭が回っていなかったですね。
特に外部API が undocumented な 403 を返す (しかもメッセージは 「許可されていないIPアドレス」) というのは全然分かりませんでした。
マイクロサービス問題なら単一IPから連続でアクセスすると弾くようになっているのかな、などと思い、後半で外部APIへリクエストをするエンドポイントだけ複数台へ分散するなどしていましたが全く解決せず泥沼へ。

これベンチマーカと外部API側に問題あるのでは? みたいな気持ちになりつつ、マイクロサービス問だしちゃんとbackoffとか実行すればいけるでしょ! と思っていましたが、意図したエラーだったのかは未だに分からず……

他の方の感想を見た限りでは、ポータルサイトへ登録されていないIPからのアクセスは弾かれるみたいですが、これについてはUI上で正しく登録されていることを確認したので問題なさそうでした。
11:00 ごろにインスタンスを立ち上げ直してIPを再登録したのがポータルサイトの何らかのエッジケースを踏んだのでは? などと勝手に邪推しています。謎ですね。

そのほか、 campaign の値を変えると何が変わるのか (POST系アクセスが増える?)、みたいなことも終了後にログを分析してようやくなんとなく傾向がわかり悔しい気持ちに。

感想

終わってみれば途中重大な気付き (「外部APIのレスポンスキャッシュできるじゃん」「ユーザの嗜好に合わせて商品出し分けたら?」など) があり、見逃しの多い回でした。
bcrypt の件は全く気づいておらず。前回は初手でやった(があまり意味がなかった) pprof を今回なぜ見なかったのか……

短い時間で追い詰められている環境の中でどれだけ集中できる / 気付けるか、というのが重要になると改めて感じました。

コンテストとしては今回も設定が面白く、運営の手の込みようが分かり、かつ短期間で取り組みがいのあるとても良い問題でした。
運営の皆様、大変お疲れさまでした。

チーム「hhkb」で同期3人 (自分 @kyontan, @hogashi, @h-otter) 2回目の参加で2日目で Go 実装でした。学生枠突破ならずでした、悔しい。というよりは 55,982点で全体4位の点数で落ちました。ちなみに hhkb は h-otter, hogashi, kyontan, :boom: ???? の略です。
スキルセット的には、 @h-otter がインフラ(ミドルウェア含)なんでもできる+Goの経験が一番あるマンで、 @hogashi がアプリケーションなんでもできるマンで、 @kyontan はアプリとインフラとDBを一通り見られるマンみたいな感じでした。

今回の参加に向けて、取り組んだことをつらつらと書きます。

今回は真面目に本戦に行きたかったので前々日に ConoHa で ISUCON7 の予選を解き直して練習しました。具体的には ConoHa の練習用イメージを使って 1GBプラン x3台で予選環境を再現しました。結果、10時間程度で 5,204点から509,190点まで持っていけることが分かり、計測と試行の反復を効率的に行えば ISUCON の予選は突破できるという確信を深めていました。
また、前回は最後の最後でベンチマーカを走行させた結果点数が下がって落ちたので、前回の直後に「泣きの1回はやらない」というスローガンを掲げ、1年越しでそれを達成しました。

事前に準備したのは Prometheus のサーバ (@h-otter がいい感じにやってくれた)と、やること/できることチェックリストぐらいでしょうか。だいたい大会では開始した瞬間にテンパってそのまま撃沈するのが常なので、思考停止状態でもコピペで動くようなコード片とかを用意しておくと便利ですね。あとは思考が無になったときに確認するべき事項とかを作っておくと良いのではないでしょうか? 頻繁に無になって帰りたくなりました。メンタルは大事。

例えば下のような感じです。

当日は3人がローカルで開発し、本番環境のVMへバイナリを転送して検証する、という進め方でやっていました。Go はクロスプラットフォームでのビルドがしやすいのが便利ですね。

具体的にやったことを羅列します。というか @h-otter が書いていたのを未承諾引用します。順番は適当

• SELECT * する系のクエリを必要な列しか取らないようにした
• /api/users は user_id で reservations を全部とってきて、アプリ側で処理してやったらめっちゃ速くなった
  • ここでベンチマーカが重いと言ってくるエンドポイントが /users/:id から /api/events/:id/actions/reserve になった
• getEvent を getEventWithoutDetail と分けた
• getEvent と getEvents を2クエリに
• sheets へのクエリを消す
  • 効果があったのかは良くわからない
• MariaDB のチューニング
• Prometheus と Grafana で可視化
• ログインのクエリを1つに
• パスワードを平文で突っ込むようにした
• DB にインデックス張った (けどあまり良い結果がでなくてもんにょりした)
  • 最初に mysql コマンドでインデックス張ったけど結果が全く変わらなくて、なぜ? と思ったら毎回 /initialize でテーブルを作り直していることに気がついた。
• IN句を使いたかったので DBにアクセスするライブラリを sqlx に切り替えた
• トランザクションの開始がおかしいところがあったので直したり デッドロック時にエラーを返さずリトライするようにした

最後は予約時のシート決定を高速化するコードが安定化しなくて入らなかったり、Redisでいい感じにやろうぜみたいなことを思うだけ思ってやらなかったりしました。多分ここができると数万点上がったはず。

あとはスコアに関係ないけど作業便利になる系として、 エラーログでソースコードの行番号を吐くようにしたり、 Makefile 弄って1コマンドでデプロイできるようにしました。
開発は3台のサーバでバラバラにやっていましたがDBは1台だけを参照するようにしました。これはDBのチューニングとかがあって、1台でやった変更を他に反映したりするのが面倒くさかったので。こうすると、やりたい人間が適当にベンチマーク対象のサーバを変更して実行してやればいいので楽でした。

ソースコードは GitHub で管理し、いい感じにやりました。コミットログは下の通りです。

数字がタグに付いていることがありますが、これはいいスコアが出た時にバイナリごとコミットしてタグつけておこうぜ、みたいな感じにした結果でした。

今回の僕の活躍はよく分からなくて、いい感じデバッグ担当だった気がします。PRを見るなりとりあえずマージしてベンチマーカを落としたりバグ探しをしていたりしました。とにかく @h-otter がぶち壊しつつ @hogashi がいい感じに安定化するコードを書いてくれてよかった感がある。

Webサーバはh2oで十分高速だし、画像のトラフィック詰まりもないしで、とにかくアプリケーションコードの改善に注力した/するしかなかった8時間でした。

最終的に残り30分でベンチマーカを叩いたところ3万点前後のスコアが5万点に若干跳ねてそこで打ち止め。一度再起動をしてブラウザからアクセスできることを確認し天命を待ったところ、無事再起動試験で落ち失格となりました。天命……

(追記: スコアが跳ねたのは、最後に実行先サーバを変えた時に インデックスを張る処理を init.sh に書いたサーバで実行したからかもしれないことを思い出した。)

なぜ失格になったのかは分かっていなくて、おそらく /admin/api/reports/events/:id/sales の処理が遅くて不整合が起きて落ちたのかなあなどと思っていますが、2回連続で落ちるのは運が悪かったなと……

なんやかんやでやることがなくならない8時間で、やることが見つからない8時間よりは良かったのではないかと思います。

ISUCONの予選に向けて昨日は練習をしていたわけだけど、知っていることをちゃんと愚直にできれば比較的現実的な時間で予選突破ラインには十分立てることが分かったので良かった

— kyontan@新刊はまだ (@sukukyon) September 14, 2018

イキっているなどと言われてもこれは事実だと信じていて、典型的な N+1 を潰すなどすれば予選は通過できるはずなことは分かりましたね。くぅ〜〜

来年はちゃんと本選に行けたらいいですね。頑張りましょう。

そして、参加会場を提供していただいた mixi 様、惜敗の悔しさを教えてくれる最高のコンテストを運営をしていただいたISUCONの運営の皆様、お疲れ様でした、ありがとうございました!

以下は画像です

Ruby実装で挑み、最終スコア 38605点@2017-10-22 20:59:30, ベストスコア: 67792点@2017-10-22 20:44:59 でした。
ベストスコアでは予選ラインは超えていたんだなあと思いますが、最終的には伸び悩んだチームも多いようで、結局落ち着くところに落ち着いたのかなと思います。

ソースコードは kyontan/isucon7_qual です。踏み台でやっていた影響でコミッタが僕に見えますが、だいたい僕ではない。

次回も参加したいなという気持ちになってきたので、ひとまずはやったことを記していきます。

実は僕と @hogas は ISUCON6 の夏期講習に出たことがありましたが、そのときには日程等もあり参加しておらずということで、今回が初参加に。
@h-otter というインフラにとても強い同期がいたことや、周囲でも参加する人間が何故か多く、とにかくやっていくしかないという流れに。

チーム名を決めるところで消耗/摩耗し、本番前日までSlackはほとんど流れておらず。前日夜になって僕とか @h-otter がぽちぽち参加記やチューニングできそうなところを貼っていく感じに。

最近、正午より前に起きると早起きしたと言い出す僕が時間に間に合っていたあたりで色々とミスっていたんですが、東京都内の某所で3人で集まってやっていました。

事前にやった

とりあえずグローバルIPを持つ作業用サーバを用意しておいた。Rubyは事前に入れておいて、開始後に MySQL  も入れてスタンドアロンで動くようにした。あとあと @hogas はここでずっと作業してたり、 @h-otter が Prometheus のサーバを立てたりしていた。便利

コードについては GitHub リポジトリを立てて、普通にブランチ切ってやっていた。便利

情報共有は対面だったので、コードスニペット貼れるしリアルタイムで最高な HackMD を例のごとく使っていた。ベンチマーカの結果を全部ペタペタ貼っていたら容量制限に引っかかり、2スレ目、3スレ目が誕生した。HackMDのタイトルは「ISUCON7 まだチーム名で消耗してるの? 2スレ目」でした。

やったこと

ミドルウェアより下は正直 @h-otter に丸投げしていたので、アプリケーションより上をぽちぽち見ていました。
インフラについては正直何をしたのかは全容を把握していないですが、初手で nginx や MySQL に基本のチューニングを突っ込み、Prometheus で延々と監視しながらPDCAを回していたっぽい。正しいインフラチューニングや……

言語は僕と @hogas が使い慣れている Ruby を選択しました。正直クエリ弄るぐらいでいいなら Go でもいいよねーって言っていましたが、慣れてるほうが便利でした。Sinatra の文字列には幼馴染のような安心感がある。

僕と @hogas はよしなにアプリケーションコードを読みながら色々した。以下は色々

erb を haml に置き換える / hamlit gem の導入

気持ち+2000点ぐらい

初期実装が erb で、erubis に置き換えるというのも一案ありましたが、行きの車内で「erubis hamlit 速度」などで検索した結果やっぱり hamlit かとなっており、ノータイムで haml に書き換えることを決断しました。
erb2haml とかあったね〜と @hogas と話しながらやってもらった。

以下様子です

. @hogextend 「erb2hamlどうやって使うの?」ぼく「とりあえず rails new して突っ込んでみたら?」 #isucon

— きょんたん (@sukukyon) October 22, 2017

僕「ﾖｯｼｬ(gem install rails)」

— hogas (@hogextend) October 22, 2017

(erb2haml はコマンドラインツールとかではなく、Rails に追加する rake タスク群ということに気が付いた様子)

nginx <-> Puma を UNIXドメインソケットに

気持ち +2000点

定番です。HTTP 5000/tcp から UNIXドメインに変えた。

SQL のクエリ改善

気持ち+10000点ぐらい

これは定番ですね。SELECT のカラムを絞ったり (@hogas)、 LIMIT を付けたり (@hogas)、インデックスを張ったりした。N+1 は手を付けていましたが、コード変更に集中できなくて最終的に投げてしまった。悔しい

終了直前にソースコード眺めてたら statement.close を意図的に忘れていそうなコードが見つかり慌てて修正した。スコア上の変化は分からず。

 画像を静的ファイルに書き出す

気持ち+15000点ぐらい

ユーザーのアバター画像が DB に blob で入っていたので、雑に Ruby のワンライナーで書き出して (ここまで @kyontan)、 nginx に try_files で食わせる (@h-otter) みたいなことをした。
既に話題になっていますが、最終的には Cache-control 的な問題でキャッシュヒット率が悪かったらしい。むむむ。

SHA1 を殺す (パスワード, アバター画像)

気持ち+2000点

パスワードのソルトを生成している random_string を見たときに、これは要らないのではと思ってしまったのが始まり。初期データのパスワードはハッシュ化されていたので、 id が1000より大きい user は全て平文パスワードを DB に突っ込んだりした。 (by @hogas)
アバター画像は、ファイルの内容を SHA1 したものをファイル名に使用する実装になっていましたが、もしかしていけるのではと言いながらユーザIDをそのままファイル名にしたら通ってしまったのでそのままに。

Redis (最終的に入れず)

気持ち+2000点ぐらい(?)

画像をバイナリで入れるのはまあそうだね〜〜と言いながら、Redis に載せようとしていた。正直コードの変更は大したことがないのは分かっていたので実装はシュッとできたけれど、実際に動かしてみると意外とスコアに有意な差が出なかった。その後も永続化周りで少し足踏みしていたり、他の変更を見ていたために最終的に入れられなかった。残念

アプリケーションサーバ3台化

気持ち +3000点ぐらい

@h-otter がラスト30分でイケると言い出してやってた。ここで Puma (アプリケーションサーバ) のスレッド数を調整していた (10 -> 18スレッド)時に出したのがベストスコアです。

その他

• 再起動試験は何の問題もなかった????
  • 過去の参加記なんかを見てるとここが関門かなというのはあったので絶対やっておきたかった (やりました)
  • Redis に手を出してなかったのでここで不安はあまりなかった
• MySQL の Too Many Connections が割りと頻発した
  • ここは statement.close 忘れも影響してるかなと思うけれど、500が途中で出たり安定しないことがあった。最終的には安定しました
• 日ごろは頭痛の頭の字もないのに、とにかく頭痛が酷かった。緊張にはやはり弱い。
• JSONシリアライザが遅いのは分かっていて、 Oj を入れるぞと言いながら入れるのを忘れた。あれを入れただけでシリアライズについては数倍速くなるというのは分かっていたので、ただただつらい。
• ICTトラブルシューティングコンテストでスコアサーバを延々とやっていたことが知見として生きたとは思う。DB設計なりアプリケーション設計なりチューニングなり。
  • 当時のオーバーキルなチューニングしたときの操作が生きることになるとは思ってなかった
• 最後のベンチマークの結果を見て全員で嘘やんって言ってた
  • ルールを読んでなかった。次回は読みます
  • にゃーん

そういえば30分ほどですがスコアボードの上位に乗っていました。学生トップなのは分かっていたので、これは予選突破できるんじゃない? とか言いながら笑っていたのを覚えています。このあたりが後々ボーダーになるんだろうな〜という話をしていて、実際そうなったのである程度読みは正しかったのかなと思いつつ。

総括/最高

監視に強い人(@h-otter)強い。常に横で IOバウンドかネットワークバウンドか、みたいなことを見ながらアドバイスしてもらえる環境は最高。

限られた時間の大会という環境でもくもくとコードいじれる人(@hogas)強い。とにかく僕が頭が回ってなくてコードをまともに書けない状況にあったので、そんな中でちゃんと改善する変更を入れ続けてくれて最高。

基本的にどこに手を入れればいいか、この変更はコスパ的にどうかみたいなことを常に考えながら立ち振る舞えてはいたと思うので、そういった点ではなかなか善戦はできたかなと思いつつ。
しかし、できたことは山のように残っているなという感想。、途中で集中力が切れてしまったこともあり、こういう結果になったのは悔しいなと思う。

ただ、これだけ言えるというのはつまりバランスが最高だということに他ならなくて、こういった駆け引きができるバランスのゲームを作るのはとにかく難しいなと思っているだけに最高だな！！！という気持ちです。
こんな最高のコンテストを生み出してくれた運営の皆様、ありがとうございました。そしてお疲れ様でした！

本選に行かれる皆様はぜひとも頑張ってほしいなと思うところです。

次回は最高の♨️から最高の心構えでやっていきたい。

成果物は kyontan/datadog-zabbix-history です。

長い前置き

ところで皆様は Datadog を使われていますでしょうか?
インフラ監視系の SaaS やソフトウェアというと、今挙げた Datadog を始め, Mackerel や Zabbix, Nagios, AWS Cloudwatch 等々、現状では様々なプロダクトが存在しています。最近だと Datadog や Prometheus の名前をよく見かける気がします。

そんな中最近、自分のバイト先では使われているのが Datadog です。サーバの監視なんかだと、 Integration の種類も多く、デフォルトで様々なメトリックが取れることや、ダッシュボードの見やすさなどがイケているかなと。
特に SaaS だと、バッファリングがあるにしてもメトリクスの抜け落ちや一時アクセスできなくなる問題などはあり、クリティカルなものを全部載せるわけにもいかず、ただ SaaS の恩恵は受けたいというのが正直なところでしょう。
(mackerel-agent のログを眺めているとたまに何故か 404 が返ってきていて笑います)

ただ、設定が複雑化したり、そもそも設定数が多くて移行がダルいというのが正直なところです。エイヤでやる体力があれば良いですが、ホスト数が増え、監視項目が万の単位であるとそれはそれは……

おそらく皆さんは Zabbix のアイテムやらなんやらを XML で書き出してごにょごにょしたり、それを Prometheus の設定にいい感じに変換する何かを書いたりされているかと存じます。そしてそんなコードは短いから/特定のドメインに特化しているからと公開せず、誰もが誰かは書いているだろうと思いながら書いていることでしょう。そうですよね?

今回ご紹介するのはそんなあるあるプロダクトです。やることは記事のタイトルに書いてありますね。

本編

最初にも書きましたがこれ (kyontan/datadog-zabbix-history) です。実装としては、Zabbix の DB からメトリクス (Zabbix でいうアイテムのヒストリ) を勝手に拾ってきます。
いい感じに動きます。良かったですね。

現状イケてないところが1つあって、 dd-agent は独自の組み込み python を使うので pip で入れたパッケージを読んでくれません。インポートパスを弄ります。良くないですね。

まだ、とりあえず動くというところなので、様子を見ていきたいですね。

皆さんはおそらく何らかのチームでのコミュニケーションに Slack を使っていて、総資産を Dr.Wallet で管理されていて (ここで読者の8割が脱落)、その総資産を逐次仲間に共有したいですよね! (残存者0)

で、やっぱり皆さんも共有したいでしょう、というわけで作りました。

(実は1年ぐらい前に作ってあったのですが、環境依存が辛かったので Docker に押し込む作業をしました)

GitHub kyontan/assets2slack

雑に docker-compose run --rm crawler とかやると共有できて便利です。

おそらく最近のアプリケーションなので docker-compose.yml が置いてあります。ポジショントーク?じゃないですが、こういう環境作りが面倒くさいアプリケーションの共有には向いていると思います。
1コンテナにまとめたかったのですが、少し面倒くさそうだったので投げました。PRお待ちしています。

実装は至極簡単に、 Ruby あるあるな capybara + selenium-webdriver で雑にクロールして Webhook で投げているだけです。技術に新規性はありません。

話が逸れますが、 Dr.Wallet のレシート人力OCRは精度も良いしおすすめです。あと、どうやら iOS より Android アプリの方が3倍ぐらい機能が充実していて便利です。NFC で Suica も読めるし。

皆さんもこれを使って総資産で殴り合っていきましょう。僕の総資産はたまにマイナスになります。

MMA は大学のサークルですが、前回のチーム overflow +αみたいな感じでした。主要メンバーが運営にいるし、新たに入ってきた後輩はなぜか別チームでやっていたので、謎です。

僕は VoIP (Forensics 100), Memory Analysis(Forensics 100), PNG over Telegraph (Crypto 300) を解きました。とりあえずメモです。

VoIP (Forensics 100)

pcap が振ってくるので、WireShark で開いて VoIPツールで再生して終わり。これICTSCでやったやつや……
SECCON{9001IVR}

Memory Analysis(Forensics 100)

Volatility というツールを使えということだったのでその通り頑張ってみる。

strings forensic_100.raw | grep http をメモ
./volatility_2.5_mac -f forensic_100.raw dumpfiles --dump-dir dumpdir -S summary.txt
summary.txt を見るとプロセスの絶対パスが取れて、怪しい svchost が分かる (PID1776)

$ ./volatility_2.5_mac -f forensic_100.raw pstree
(snip)
.... 0x81f65da0:svchost.exe 1776 672 2 23 2016-12-06 05:27:10 UTC+0000
..... 0x8225bda0:IEXPLORE.EXE 380 1776 22 385 2016-12-06 05:27:19 UTC+0000
...... 0x8229f7e8:IEXPLORE.EXE 1080 380 19 397 2016-12-06 05:27:21 UTC+0000
(snip)

プロセスツリーが取れて、 PID 1776 の子プロセスが分かる

$ ./volatility_2.5_mac -f forensic_100.raw connscan
Offset(P) Local Address Remote Address Pid
---------- ------------------------- ------------------------- ---
0x018c3cc8 192.168.88.131:1077 180.70.134.87:80 3676
0x0196f6a0 192.168.88.131:1122 175.126.170.70:80 3676
0x0233bbe8 192.168.88.131:1034 153.127.200.178:80 1080
0x02470238 192.168.88.131:1036 172.217.27.78:443 2776

PID 1080 がアクセスしてるのが `153.127.200.178` だと分かる

上の strings でアクセスしてた URL のドメイン部分を全部 `153.127.200.178` に変えて、curl

echo http://153.127.200.178/
curl -I http://153.127.200.178/ 2>/dev/null | head -1 | grep -v 404

こういうのを書き連ねて、 200 OK が返ってくるものを探す

(snip)
http://153.127.200.178/entry/Data-Science-import-pandas-as-pd
HTTP/1.1 200 OK
(snip)

後はアクセスして取ってきたファイルを開く

$ cat Data-Science-import-pandas-as-pd [/Users/kyontan/Code/ctf/2016online]
SECCON{_h3110_w3_h4ve_fun_w4rg4m3_}

PNG over Telegraph (Crypto 300)

待っていました YouTube 問題、と思ったんですが、50分を超える動画で最初から心が折れる。
とりあえずダウンロードして、ffmpeg で 1fps で連番画像へ変換。

mkdir tower; ffmpeg -i SECCON\ TOWER\ 2016\ -\ YouTube.mp4 -vf fps=1 tower/out%04d.png

これ、最近授業でやった気がするなーと思いつつググルも、一般的な手旗信号ではないようで少し戸惑っていたら、 @f_dita 先輩が最初のデモから対応表を作っていたようなので拝借。

そもそもパターン数が26+αあって、コマ数がトータルで3000を超えていたので人間技で分けるのは無理だと判断し、ImageMagick でごにょごにょするも、動画内の棒がブレるわ、次第に少しずつカメラがずれている? やらで全く精度が出ず、ここまで3-4時間近く。

最終的に心が折れ、手動分類アシストツールを書きやっていくこととなります。
そのようにして、160行のSinatraアプリケーションがここに爆誕しました。HTMLを文字列として扱って結合する簡単仕様。
そして去年のごとく、突然 @hogas を呼び出し、ひたすら朝まで単純作業。

それに伴い少しずつ分類器の機能が向上され、再分類(間違えた画像のやり直し)や大分類(軸となる棒の向き)→小分類 などの仕組みが整いスピードアップ。

これはSECCONではないと思いつつやるも、結局どのようにしてフラグを得たら良いのか分からず、更に混乱するなど。
問題文でPNGに戻せることが示唆されているので、何らかの方法で元に戻るはずですが、そもそも動画の冒頭で文字の対応が示されたのは20パターンほどに過ぎず、全部で何パターンあるのかも良く分からないままひたすら分類していきます。
最終的に32パターンになるのですが、途中で分類を誤ったりなんやかんやあった結果、36パターンの分類が完成し、Base36という誤った道を踏みそうに。答えは Base32 でした。

気合でバイナリに戻したら、馴染み深い IHDR の文字列が見えて感動しつつ、ここから更に間違えた分類画像100枚以上を探しつつ、気合でCRCを合わせて行きます。

最終的に、IHDR や PLTE, tRNS, pHYs, IEND 領域は CRC32 がマッチして、IDAT の inflate がチェックサムでコケるところまでは上手く戻せました。

input = "rfie3rynbinauaaaaagusscekiaaaaw5aaaafwqbamaaaabvebthaaaaaadfatcuiuaaaahzzzz5lwmz4uaaaaacorje3uzzzzellx1haaaaaclqjbmxgaaabmjaaaalcia2fxl1zqaaabwyjfcecvdyttw2uqms1i2ayrsrkvsqclbjlpxslmiavl5bus3zuqagz3xdt0oq15ci3kjuy0gjjknzzyjqobyha3dqobyha3dqobyhb3cpxdstrxdzt0zu1zzi5dwzc11jzvydx44gx2t0zfz3d4244rhdlcpir50u2mcaob1zrddyzj4bw11np1v02y5u1lcdrzjwouzjnzqobyb41geohcxsxdb3fdz3c0sejzsd2nbcye40jeapcdi3dt1g13gp2giw23z5jta0dfrt1ih55btxvmhxa3hqhzdpwdrl4whjsfrdqkzc2gljdeob0zdp1d55oe2uai1mnd4wxifhag344rpcm0rrbuha2pqr02i1dz2pd1bmbqobgzrhgrbqmzg00w12lpxgk1yn5c2obvnjwj4quha3pqjx2t2g1bmaq3rvpav5dmynuv2wlkuoppsrwidqodyl41hizwxhrl5lkz0ssvqdjwyzuvtev3k2dh05yha3d2zbdhljc1h4kj5ynk0100gw2xb5hz2jtuv2qobyg41gj2k3kl4jhftp2vfrr40fyme1l2vhc1dgzbpcnqgbyf41ewivxoh2pkn0qn5zpztpyllw33nzxoe2kqbhyda3cnzbepo3nylrfs0zjchnxcqyepu4krkupr1dqkbyh41evurfvlpar4ujdekpk34e1211lzzxacaob5zb5n5t0muzhmbs2urt2yr5524npkwukyot4z4xaiobyzbhtyzrj1okx5fv0g53voxfjfwqupsrj442n0ku0v4nyda3d2za4v0bvhnf5fpbv2lr3hvdndispkg5vi1byhatpyntgnwgusdvdnvh433x0rovk2r1lxzj0wi3dqohyi31nuunlupdqruvpo2gtp4lpzot4u2z053g3dqobg4qsfjvh1cz4jfy1kvg4u55givzw4acoobyzbdlyo21oo4wunlu5zmafr3tlqla0c0k4o5zwbihazpysw0wtz0feuyiyzznmxvk312gcpeyj4khmfy3dr1cwpvsvjt5mhl44404l4zuztj25ysxgf1vmmyldqohyl11yvxrlskky5fh02ncwlszjofoaffnleoiyha3d2zbzuvcoit5pxvqazyokxh1235ektpk3rd1tm4qibyh41cupelmkyzw40xl4t3omhlcvwmlwwq40zkf5klqodye4oekmt12pq5p2v3yh4dedtfui0pe5gu4fs1saeha2pqpc2u4gxeolww4j2lngsflw0xohl2byj1ayha4pymzf53hjbupoen5x4noc5beplaq4in2xb0ogq3dr1fz3o2ihvn0wxe34vlatswxkinpxmp5hxsomd55fqgbyf41g3kbgwk2ngbtfpupxwcndg3yzhkdaqdqpx3bmzgpntd4p0sfgwa441hppwmq2lsk2janbyhl3e1ptgpbdlnat2w21ukhm1kv4dpclpzp0p2vauob0zb4hsxvzi0gywexxzltim5ilmyvnrmwlk40hsly3q4xaadqpx3cvntfnn0ytnffkjc4x5trs44454sgucu4kx2m2byfa3d2zbshssd5wir0f13l14ln1xfcpe2w5j0d5rdnsda3dqjx3g3vdlk5xcjpcok1wypokpwgnlil4khjqkbyh41d5vruumwors0fu024zgkot100vjtrk34lx3ga3dv1cnlvhsmf1z5wutp0vkw2pwixvctl5j4iobypa4zrvkkch05giwwq4lmwqrf1ntwih21ly4fv1eiobyha4pylyyefx2tombpdl1lte5jlg3p0vilw5xmcla3dqnx3knm50tjlqnv12pwmz152ponnmafzs4iobyha4zrb4vtrlcxl20oqj54rxsuv5lrxcvdphm3dr1dgzqjp3otwo022qlrx0tlfiz3yfff4znfbyda3dp1eop2klbgoufqi2w3m5vqkyczlsjoagpxmuda3dqlx3dy020t0gde3vngk0d1u2vnkke1pnpf0a43kp3aha3dz1dwp2tvxklwknk55dlv2fbs135r0ix3pxbysdiob0zc44q1showz05sgn1moezliktgbku3lw55gmt3mo1ceobypaxlyx0mbl5ik1cl2oo4kdh40wwkxx5zoki1gbfyhb3fnxdmwqicfgdlzijcvkyvqz03h5yc31ev55ycxa3hqlx3n0qp5mxolk1nn4q1bwtkvmvtw22upeu5dqohys23m0lbxg04rx114zs3u31ehzki34jzihpotha3hpkbiha4pyu1xnmdt35ww31ht1f2epymzjf2x0phwwhamdqjx3ek1a54ufwoadzvikpo5iorjtplsm24eonyhb3dnzaef0m00jfmzvkatlu0xxdn0zpjueaaob5za4p23twus04k0ildq2nugd0dytpfsxgli22y1c33dr1cxpcgsax512lsmyq1h243s4kzmjmn3vtgayhazpyuj2yhgmv0nltaz01spccxf44kpn20mowlyodyh51h3kc2i43lddhvevviv1r4hqp5jkzkbtzvxqzlbi3dq1bg4yqr2gpw25vc4v3l4aan2xgx2zvxixhyobyg41eols0ong5koxbvretcf52ochl1nwbihazzqwpcif3ulfl3oixqvyulo5vky2ir45yag521jyha4pyplj3kmtoranly3wmn2mjoworm1wunnjcmx1adqobzzb4hvdqn3x5m1fzi3xnp4tm4y0ybhxfo5lfxyha3d2zbz15eaqobyha3dqobyha3dqobyhp3mz3apaujsxhmrfz0maaaaaacjivhejlscmcbaaaaaaaaaa"

s = "abcdefghijklmnopqrstuvwxy054321z"

x = [input.chars.map{|x| s.index(x) }.map{|x| ("00000" + x.to_s(2))[-5..-1] }.join].pack("B*")

# "\x89PNG\r\n\x1A\n\x00\x00\x00\rIHDR\x00\x00\x02\xDA\x00\x00\x02\xDA\x01\x03\x00\x00\x005 fp\x00\x00\x00\x06PLTE\x00\x00\x00\xFF\xFF\xFF\xA5\xD9\x9F\xDD\x00\x00\x00\x02tRNS\xFF\xFF\xC8\xB5\xDF\xC7\x00\x00\x00\tpHYs\x00\x00\v\x12\x00\x00\v\x12\x01\xD2\xDD~\xFC\x00\x00\x06\xD8IDATx\x9C\xED\xDAA\x92\xF2:\fFQUe\x01,)[\xEF%\xB1\x00\xAA\xF4\x1AK\x9F\xA4\x00o\xF2\xE3\x9E]\x0FhH\xE2\x93Ld\xC9J\x9B\xFF\xE10ppppppppppppp\xF0O\xB8\xE58\xDC\x7F\x9E\x7FO\x7F\xE8\xD0\xED\xF1{\xC9\xFDp;\xEFf\xBFg\x9F\x97\xFC\x1E\xFB\xBD\xC4\xE3X\x9E\x88\xEB4\xEB\x04\a\a\xDF\x88\xC7\x8F\xA7a\xB7\xBC\xD7\xFA\xB9\xEE5O,C\x8F\xD3gS\xE9o\xE0\xE0\xE0;\xF1\x88\xE3\x8A\xF2\xB8\xC3\xC2\x8F\xFC\x16dD\xFEC\xEBB,\x13yI\x00\xF1\r\x1C\x1C\xFCop\xCF\xE9\x91n\xF3\xFAL\xC1\x91\x963\xF2\x0F\xAD\x06w\xAB\x0Fpp\xF0?\xC6\xFB\x0E+\xDD\x8E\x99\x16#\x82\xBE.\x99i\x19\x1C\x1C\xFCo\xF0\xF5\xA7\x13\xB4\x02<\xC6\x8Fv\xBA\np\e\x9B\xDC^&f1\r\x0E\x0E\xBE\x11\xCFQ\xE1\xFF\xAF\x1F\x82\xC0\xC1\xC17\xE2sD0g\xCD\x9C\xDB\xDD[\xEEe{\r\xD0\xBA\xE0\xD5\xA9\xB2w\n\x1C\x1C|\x13~\xCF\xA6\xF0X\br5x+\xA1\xB3\r\xA5{e\xAA\x8E{\xE5\e pp\xF0\xBD\xF8\xE8\xFD\xAEx\xAFKW\xF3)V\x03M\xB1\xFAVd\xAF\x15\xD1\x9F:\xC1\xC1\xC1\xF7\xE1\x19\xD6\x91x\xFBRu\x86\xAB>\xCEMn\xDC:?\xFA\x99\xD2\xBD\x83\x83\x83o\xC6OU\xC5/i9f\xFE\xD4\xB1\x8E\xF2\\0\x9E_jqxf\xF8^&\xC0\xC1\xC1w\xE2Y\x15\xBB\x8F\xD7\xA9\xB9\x83u\xF7\xFEo\xC2\xD7nq\xBF\xBB\x89\xD5@'\xC0\xC1\xC17\xE1#\xDD\xC6\xE1q,\xB3\xF4\x88\xED\xB8\xA1\x82>\x9BTUG\xC7\xC3\x82\x83\x83\xEF\xC4\xAD\"Z\xAD\xE0\x8E\xE8\x91\x91OW6Ow\xDE_\xFFp\b\x0E\x0E\xBE\x1D7S\xCB)\xF3\xB02\xED#>\xE2:\xD7v\xD7\xAA\xD4V\x1D=\xFFw\x02\x1C\x1C|'\x9E?\x14\xF9\xCA\xBE\x8B\\\x9B\\\xAB\xAET\x96\xD0\xA3\xE5\x14\xEF}nUL\xD7m\xC0\xC1\xC1\xF7\xE0\xDDr\x1A\x9D\xA5\xD1^\x1A\xF5q\xE1\xEA6\x8D\x12z\x8D\xAA\xA3\xC1\xC1\xC17\xE1\xB33ljHu\ej}\xF3\x97\xCC]Uv>]\xFE\x9C\xD9\x1C\x1C\x1C|#\x9Em(\xD5\xD1\xE3\x84iW\xBB\xA6\x9B\xF6\xB7\xFD\xD3\xDD;\xFC\xEB\x86\xE0\xE0\xE0\x9Bp\x91SS\xF8_\xDAK\x8F*\xA6\xDD5\xA3\"\xBF\xB6\xC0'88\xF8F\xBC;\xBEs\xB7j5t\xD7\xD8\x02\xC7\x93\\\x16\f\x8B*\xDB\xB5\xFB\x05\a\a\xDF\x89[6\x9F\xF2RS\b\xC7\xFE\xD6^\xAA\xE7\xBAa<\x98N\xD4v\x17\x1C\x1C|+>\xB2\xAAg\xA6\x1D{\xDE\xF3\xB5\xEF\xF4\xFC\xD3\xDDbW1}V3\v\x1C\x1C|/\xDE\xC5o\x15\xC9J\xC6\x8A|\xF5\xA2\xB2\xE5\xF4\xB8\xAE\x01J\xD5\x91\xC8\xC1\xC1\xC1\xF7\xE1\xFD*'\"z}\xEB\x00\x7F\x0EU\xCF\xEE\xF3DT\xDE\xAED~\x9B7\x04\a\a\xDF\x85G\x91lV?m\xE6\xEB\xDC\xF8\xE6\x1Db\xAD\x98\xBBZ\e\xCF\xD4])pp\xF0M\xB8\x8Ad\xFD\xD7\xC3O\xEDy\x83\xECd\x1C\xCBDe\xE4\xD1\xA9\xB2\xCB\xD2\x01\x0E\x0E\xBE\x0F\x17i\xB3\\\x8E]\xAD\xB4\xF5m4\x8A\xBBf\xEE:\xFA\x1C'\xC0\xC1\xC1\xB7\xE1\x9F.\xB8t\x86\x8Fq\e\xAB\xED\xAE\x16\x82G\xAC\x10\xDA\e\xDB\x87.488\xF8\xBF\xE3\xBA\x83\xD5\xB9\xB5\xC9\xCD\xD5`\x9C\xADu!\xAF\xBB\x1F\xA3\xDEN`\xF5\xA2\xC0\xC1\xC1w\xE3qA5\x95\xD6\x983+\xE8\xFB\xD8M\x19\xB9\x8F\x9DC\x04\a\a\xDF\x81g\xCC\xF6\xCC{~dSX\e\xDF\x8E\xF7\xD9\x90\xEA\xE4\xAE\xA4\r\x0E\x0E\xBE\x13\xCF\x99\x9E\x11\xAD\xA0\x9Fm\xDFQGg\x95]\x8D\xE2[\xFE\xFC\xBF\xB5\x05\x1C\x1C\xFC;<\xAF_\xA3&\xC5\x89{\xFDsC4\x85\xB3\x15lYe\xABy<\x97\x8ECw\x00\a\a\xDF\x82\xABfV\xB78\x9BJU$[\xBE\xA7\x19o{\xD6\xE4j\n\x9BU\xFA\xCE\x87\x05\a\a\xDF\x86G\x94\x87\xAB\"9/\xB8\xBFmm\xF5\xCA'\x93\xB6\xD2r=Dm\x90\xC1\xC1\xC17\xE1\xB9Q\xADZ\xB8\x92\xF19^\xB6\x1E\xE5>\xC6j\xD0\xBD\xA8\xE9\x82\x83\x83\xEF\xC3\xD5cJ2\xCE\x8C\xB2Zg\xBB\xF9\x94\xE9\xFB9\xAAg\x15sk\xBF\f\x0E\x0E\xBE\x13WS\xC9\x85\xF7\xF5jM\xF9\xAA\xAD\xD7\xD9\x17\xA8\xA6\xBD'hpp\xF0o\xF1\xAA\x94#\xE7FE\xAD\r\xAD\x96\x84K\xE6\xCE\xC8?|\xBCl\xB5\xF1\x10\xE0\xE0\xE0\xDB\xF0\xBC`\x85\xBFf\xE6\x05\xE3_\x972i+7\x1F\x9A\xA1v\xD5\xD8%\x83\x83\x83o\xC55\x9A\xCC\xD2\xB86\xBE\xEB\xEC\xCF\xFB]{\x9A\xD6\x00\xBF\x96\xD0\xE0\xE0\xE0\xDF\xE2\x1D\xD6qX\xAE\xBE\xE5\xD0N\xB7\e\xCA\x95\xD2\xE3qTo;88\xF8f\xFC\x12\xFE:vv{\xD8.7\xCC\xD6T\x7F\x98)K\xBF\xB4\xA1\xC0\xC1\xC1\xBF\xC4s\xFA\xA5\x84\xCE\xA1`\x8E\xDB\x8C\xD5`\xAC\v\xEB\x92\\\x03>\xEC\xA0\xC1\xC1\xC1w\xE0\xF1\x9E\xE6y0\xC9\xCA\xB4\xCA\xC8\xFDN\xD5\xAAQ<\xF6\xBC\xB9\x06\xF8\xA7\xF0\a\a\a\xFF\x0E\xCF\xEC\xEBu.\xCAj\xB5\xA1\xAE\xBD(e\xEEj9E\xF8\xFB\x87\x12\x1A\x1C\x1C\xFC[\xDC=#\xBA\xDF\xCE\xA4f\xF9\x8E'\xD6\x85L\xC1U8\xBBkFd\xF8\xC7xDpp\xF0]x\xBEX\x15\xE9\n\xF0\x97\xD7;j\x19\xF7\x9BYW\xBE\xBE\xE5#\xC6\tpp\xF0\xAD\xB8\xD9h E0\xD7\xF4$UV+\x0F\xE7\x87\xD6\x05\xCF\x12\xBA\xD6\x05pp\xF0]\xF8\xDC\xC1\xFAe\xDC\xB5y\xAD\xDC<\eMUegn\xF6\x8F%488\xF8\x97x\xCC\xAC76w\e\xFB\xDB\xFC\xB9Nx\x87\xFA\x91\xCD\xA7\xE8;\xDD3\x83\x87z\x82\x83\x83o\xC5=v\xB0s\xE6\xADnx\xF3\xF1zG\xE1\x9FI{|\xBC\xF6\xB1\xC0\xC1\xC17\xE1\x15\xE0kt-\x9C\x01\xFE\xA8S\xDD\xA4:)\x9B\xD7&wdspp\xF0m\xF8\b\\\xB39IY\xFA\xA8\x13]3{\x8D\xB9\xFB\xD3B\x00\x0E\x0E\xBE\r\xBF\xBC\x9D\xA9,\xEDYB\xC7\x0E\xB6\x86\x1EG\x89\xBC\xB2\xB9\x96\x8E\xF7\x1E\x1788\xF8Wx\x8D _^\xEA\xE4\xCCC\xC7\xEE\xF9-\xAB\xECK\e\xCA\xCC\xC0\xC1\xC1\xF7\xE2\x89\xEE\x0EfW-\\\xC1\xFC\xFAO\x10\xAE]\xEDOor\xC7Yxp\xF0}x\xFCP\xBA\x8D\xF1c\x19\xEAJ\xD5\x15\xF4vx?IW\xD4\x19\xFE\xB7\x87\xD6\x14pp\xF0M\xBCB=3\xED\xDDT[\xAF\x17\xB0\x01\xBD\xB9\xAF\xDF\xD6\xE8\xB9\xF0\xE0\xE0\xDB\xF1\x1C\xB9e\xCD6\x94\xEB\x86\xB1$\xC4]u\xC2:\xFC\xDB\x05\a\a\xFF\v<H/(\xB2\xAF\x8EE\xE1\\Qn\xD5U\x8E\xA2;\xD6\x00mw\xC9\xC1\xC1\xB7\xE1\xEBO\x14\xC9\xBA j\xF1\xCB1\xBDb]gE\x9E\xB5\x1A\xD4\x89\x97\xF0\a\a\a\xFF\x0E\xCFQ\xC1\xBC\xBE\x99\xE2\xFD\x1C\xBB_\xB9\xB3x\xCE\x02{\x95\xDAYo\x83\x83\x83\xEF\xC3\xFFh\x80\x83\x83\x83\x83\x83\x83\x83\x83\x83\x83\x83\x83\x83\xBF\x8C\xFF\x00\xF0Q2\xB9\xD9\x12\xFF,\x00\x00\x00\x00IEND\xAEB`\x82\x00\x00\x00\x00\x00\x00\x00"

圧縮の展開に失敗するため、普通の Preview.app などでは見ることができませんでしたが、とりあえず Chrome に投げたらある程度の断片が拾えて、QRコードだったので、なるほど〜といいつつ画像をチームチャットに投げたところ誰かのアプリが良い感じに読んでくれました。

SECCON{SEMAPHORE_LINE_IS_THE_1ST_TELEGRAPH_SYSTEM_IN_THE_WORLD}

7番目ぐらいに解けた気がします。これ、多分うまくやると自動分類できるんですが、それでもそこそこしんどい気がしますね。結局PNGは最後まで戻せるのかどうか……

普段 Web 系の人間なはずなのに全く分からなくてしんどいし困りますね。でもバイナリにも強くなりたいですね。やっていきましょう。

今までは shotgun でやっていたのだけれど、これは毎回リクエストする度に変更の有無に関係なくサーバーを立ち上げ直すので、遅いという欠点があった。
副次的な問題として、better_errors で REPL が無効になるという欠点があった。(レスポンスを返すとそのコンテキストを捨ててしまうから?)

ずっと前からどうにかならないかなーと思っていたのでググったら rerun というものを見つけた。
Rack とか関係なくもっと汎用的なやつで、ファイル変更検知してサーバー上げ直すぞ! みたいなプロダクトらしい。

入れたら下のような感じで使える。便利。

RACK_ENV=development rerun -- rackup -o 127.0.0.1


調子に乗って通知有効化するぞ! というノリで terminal-notifier を入れてみたらサーバーが上がらなくなった。何事かと思ったら tmux 上で使おうとすると一癖あるらしく、こういうIssue が立っていたので適当に読んだら解決した。

要するに、brew なりなんなりで、reattach-to-user-namespace をインストールして、.tmux.conf に下を書き加えるという話。

set -g default-command "which reattach-to-user-namespace > /dev/null && reattach-to-user-namespace -l $SHELL || $SHELL -l"

再起動に掛かる時間が体感で倍ぐらいになったけれど、better_errors使えることで圧倒的効率アップみたいなところがあるので、トータルで幸福度が向上した気がする。

app.rb

require_relative "hoge"

class App < Sinatra::Base
  configure do
    disable :protection
  end

  use HogeRoutes
end

hoge.rb

class HogeRoutes < Sinatra::Base
  get "/" do
     ...
  end
end

みたいな事をしていた。
disable :protection をしているのにどうしても Rack::Protection が有効になるので、どうしてこうなるんだとあちこちのコードを追いかけたりした結果、HogeRoutes が App とは別にもう一度 session, protections 等のセットアップが行われるので、以下のように、 use HogeRoutes を configure より上に持ってくる必要があった。

app.rb

require_relative "hoge"

class App < Sinatra::Base
  use HogeRoutes

  configure do
    disable :protection
  end
end

HogeRoutes 内の configure で disable :protection とやってもいいが、こうするとクラスが増えた際にその分だけ書かないといけなくて大変。セッションみたいなアプリケーション全体で統一的な設定を持つ部分は親の App でやって良いんじゃないかと思う。

ふと、季報的な物を書きたくなったので書きます。

10/27: monora rebuild

12/7: Adventar::List release

12/11: 某社に見学に行く / バイトを始める

12/14: monora improve

12/16: ネットワークスペシャリスト試験合格

monora rebuild / improve

12月に一番力を入れたのがここ。

新デザインの構想は結構前からあって、ずっと laboの方 にはデザイン案が置いてあった。ファイル名を見るに 2014/5/18 に作ったっぽい。

確か Adobe Creative Cloud の学生プランに入って Illustrator が使い放題になったので、使い方を学ぶべく作ったというところ。
ただ、この時はまだWebでこの見た目を HTML / CSS で再現するのは無理だと割りきっていて、いつかこのデザインが日の目を見ると良いな、という感じだった。

そこから1年半が経過して、ふと思い出したのが SVG 。
HTML 5 もそろそろ普及してきて良い感じに使えるんじゃない? と思いつつ、ものは試しで Illustrator で SVG出力してみた。

「うん、普通に表示できるね」

というのがその時の率直な感想。実はこれ、1年前の時点でできたんじゃない? とか思うけれど気にしない。
Illustrator は優秀で、それなりに読める SVG を吐いてくる。これは結構驚きだった。(コードジェネレータがまともなコードを吐いてくるとはあまり思っていない)

ただ、パスの部分は合成操作を多くしたせいか、結構長くてごちゃごちゃとしたパスが出力されていたので、その辺りも含めて一度全部書き直した。

もう1つ面白い発見があって、SVG の見た目の部分を html ファイル内に書くのがダサい!! と思っていたら、なんと CSS で書けることが発覚した。

http://www.w3.org/TR/SVG/styling.html#StylingWithCSS

6.6 Styling with CSS に書いてあって

svg circle {
  fill: #3C241A;
  fill-opacity: 0.64;
  stroke: #3C241A;
  stroke-opacity: 0.64;
}

というように SVG の属性 を CSS で書ける。とても便利。
問題はエディタがこういった仕様を知らないことで、手元の Sublime Text 3 では全く色が付かない……

そうして、これが

こうなりました

自分でも感動した。めっちゃ良い。現代って感じがする。

元より v1 の時点でも corner-radius が正式に出る前から使っていたし、丸っこいデザインが好きで、そういうデザインをしたかったというのがあっただけに実際にブラウザに表示された時は感動した。まだまだWebで丸を全面的に使ったサイトというのは中々見ないし、文字の配置なんかもイケてると思う。

ただ、SVG による難点もいくつかある。例えば <foreignObject> を使ってHTMLの要素 (<p> とか) を使わないと幅を固定して複数行表示ができない。けれど、<foreignObject> は現状でサポートされていないブラウザもそれなりにあるので、<text>と<tspan>を併用して地道に座標を当てる対処も必要。
ただ、今回は TypeSquare という、無料で和文のWebフォントが使えるサービス (リュウミンや新ゴのようなすごいフォントがタダで使えるすごいサービス ) を使っているので、どの環境でも同じフォントでほぼほぼ同じに見える……はず……

12/14 には improve と題して無駄な機能を付けた。

カーソルを乗っけると色が変わったりブラーが掛かったりする。モダンな感じに動くし良いんじゃないかなみたいなノリ。
Material っぽく、カーソルを乗っけたところから色が変わると面白いかなと思ったけれど、結構実装がつらそうなので後回し。

今でも正しかったのか悩んでて、そのうち外すかも。
(この記事を書きながら Firefox で検証しようとしたら、この変更のせいでまともに文字が描画されていないことに気が付いたのでブラーは無効化しました……)

背景はデザインを変更して少ししてから変えたもので、上の画像のものは大学に一眼レフをふらっと持っていって撮ったもの。
背景にも地味ながらこだわっていて、もっとバリエーションを増やしていきたいなと思う。そして年も開けたしそろそろ差し替えたい。この辺りの話はまたいつか。

そんなこんなで結構良い感じのデザインをしたと勝手に思っている。コンテンツを増やしていきたいと切実に思う今日このごろ。

Adventar::List release

この記事が公開されているときには既にアドベントカレンダーは終わっているんですけど……
2014年12月にリリースして、その後しばらく動いていたんですが最近またサーバー環境のあれこれでぶっ壊しまして、ほぼほぼ1から作り直しみたいなことをしました。
ただ、今回はなんやかんやでクローラが上手く動かないし直そうにも忙しいしで困った。
(今確認したら何故か今日の日付が表示されているし困った。後で直します。)

某社へ見学に行った / バイトを始めた

書いてある通りで、何の変哲もないです。
見学に行ったつもりが仕事してました。何か前のバイトでも同じことをした気がする。学習してないですね。

業種としては自社開発のWebサービスの運営企業で、Wantedly にも載ってるような、いわゆるスタートアップというところです。僕は Wantedly 経由じゃないですけれど。

前からインフラに興味があって、たまたま中の人からお話を伺う機会があったというタイミングの良さもあり、インフラ関連の開発をさせて頂くことになった。
これを書いてる時点ではDockerとかAWSとかそのあたりを弄っています。

いい椅子があって、壁で仕切られて無くて明るくて美味しいコーヒーが飲み放題でうんぬんかんぬんという、自分の想像するベンチャー像をまさに具現化したような存在でとても良い開発環境で作業をさせて頂いています。

近況は以下のとおりです。

某社にて、何も考えないで @whywaita っていう先輩と「マウントポイント? alice でいいんじゃない??」「ﾖｯｼｬ」とかやってたせいで 社内チャットに alice って単語が飛び交うのを観測している

— kyontan (@sukukyon) January 4, 2016

@sukukyon アリスカータレットではない事を主張していこう

— why/橘和板 (@whywaita) January 4, 2016

@sukukyon 全く覚えてないけど、確かアリスとボブからだったと思うし、ついでにアリスゲームも関係あることにしよう

— why/橘和板 (@whywaita) January 4, 2016

思いつきで名前を付けるのは良くないですね。意味のある名前を付けるよう心がけましょう。

ところで、前のバイトを退職したという事実は一切なくて、、むしろ新しく始めたこっちの方が勤務日数としても結果的な給料としても少なくなるはずです。(現状では)

気になるお給料については前の会社と同じ時給という感じにしてもらった。半年後、1年後となった時にどっちの方が高くなっているのかは個人的に興味深いところ。(今の時給は1000円台前半です。まさかこの歳でこんなに貰えるとは……)

前からいた会社の方では、最近はもっぱら iOS 開発を主にやっています。社外秘と書かれた紙を見るだけでワクワクするし、Objective-C という言語は知れば知る程賢い設計だなあと感動する。Swift にもそういうワクワクはあるのかな。

12/16: ネットワークスペシャリスト試験合格

ネスペに合格しました。これで、IPAの情報処理技術者試験は AP/ES/SC/NW を取ったことになります。

テクノロジ系だと、あと DB は取れると思いますが、今ひとつ興味が……
マネジメント / ストラテジ に関しては全く歯が立たないですし、ひとまず IPA に関してはこのあたりで卒業したいかなというところ。
NW は興味がある分野といえど勉強期間が短く詰め込み学習になったのもあって一番つらかった。

一番楽しい資格試験はエンベデッドシステムスペシャリストだって、わたし、なんどでも言えちゃいます！

— kyontan (@sukukyon) December 18, 2015

また3週間後に資格試験が控えている気がしますし、これを取ったらしばらく資格を取るのはやめたい。

ではまた。

15:57:20 MMA(kyontan) got -163215 points from ….

http://pastebin.com/KTqNZ4Jf

さて、今回は人生2回目のCTF大会である、SECCON  2015 Online CTF へ、学校の同級生である h-otter / @hogextend と共にチーム overflow として参加しました。

最終順位は 1200点 147位 でした。初心者なりには良くできたのではないでしょうか…… (http://score.quals.seccon.jp)

自分が解いたのは、以下の通りです

• SECCON WARS 2015 (100)
  何かQRコードが見えるなという感じだったので、良く分からないままにとりあえず動画をダウンロードし、適当にQRが見えている部分のスクリーンショットをVLCで17枚ほど取って、ImageMagick で比較(明) 合成してみたら解けた。
  (参考: http://d-poppo.nazo.cc/blog/2014/04/imagemagick/)
• Unzip the file (100)
  既知ファイル2個を h-otter が見つけたものの、既知ファイルを圧縮したものを引数に与えるのを忘れていたっぽいので渡してみたら解けた。
• Reverse-Engineering Android APK 1 (100)
  一番苦戦しました。
  apk を逆アセンブルしてソースを除いたら native で libcalc.so の calc() を呼んでいるところまでは分かったものの、どうやって呼ぶかと……
  x86 やら armeabi-v7a の so があったので、Raspberry Pi でビルドしてみたりするものの上手くいかず、結局 Android Studio を入れてアプリケーションを1から作って解くというかなりつらい解き方をした。
  他の人の Write-up を見た感じだと、calc() のバイナリを読めば 7 を返すことが一瞬で分かったらしい。なるほどつらい
• Exec dmesg (300)
  問題の zip を展開したら iso があったのでとりあえず VirtualBox で起動。
  Tiny Core Linux なるものが起動するも、 dmesg コマンドがなくて怒られる。調べてみたら busybox 使ってることが分かったので、フルバイナリ落とせば行けるやろ! と busybox のバイナリを wget で落としてきて dmesg を叩いて終わり。
  300点……? という感じのさっくり感でした。うーん……
• Last Challenge (50)
  換字式暗号です!! 1問目でハッシュのキーとバリューを逆向きに作るとかいう凡ミスをやらかしている間に h-otter に解かれましたが、今度はちゃんと解けました。

QR puzzle (Nonogram) についてはソルバを持って来たりパーサでごにょごにょしたりして数時間粘るものの ソルバの精度が低い && QRコードの認識精度が低い という二重苦に苦しめられ、最終的に全操作を自動化して寝て数時間放置するも、2000回 問題を試行して最大正解数が 22/30 とかいうことになっていたので完全に敗北しました。つらい

その他の感想としては、 h-otter が割と色々やってくれて強いな―って思ったみたいなのがあります。
あと、@hogextend が QR puzzle (Windows) を手動で300問 9パズルを解いてフラグを得ていたのが印象的でした。お疲れ様でした。

初めてにしては頑張ったと思っていますが、同じサークルの先輩方のチームには完全敗北を喫したので頑張っていきたい。最強のQRソルバがあるんだよ〜〜などと言われまして、それは何処に……という感じです。

これ、とても一般的な問題で、 Rails だと、seed_fu というのを使って解決したりするらしい。

Rails (ActiveRecord 4.x) で動くなら Sinatra (sinatra-activerecord) でも問題なく動くとおもいきや、$ rake -T しても db:seed_fu が表示されない……

ソースやらなんやら見ながら唸っていたら、どうも Rake のタスク追加を、 Railtie を使ってやろうとしているところを発見した。
どうやら Rails だと、初期化時にここのコードが走るらしいのだけれど、Sinatra にそんなものはないので当然タスクは追加されない。

というわけで、Rakefile にベタ書きしてみる。
メインのアプリケーションソースが ./app.rb にあるということになっています。(適宜書き換えてください)
あと、なぜか << が < < に置き換えられたので修正してください。

namespace :db do
  desc < <-EOS Loads seed data for the current environment. It will look for ruby seed files in (settings.root)/db/fixtures/ and (settings.root)/db/fixtures/(settings.environment)/. By default it will load any ruby files found. You can filter the files loaded by passing in the FILTER environment variable with a comma-delimited list of patterns to include. Any files not matching the pattern will not be loaded. You can also change the directory where seed files are looked for with the FIXTURE_PATH environment variable. Examples: # default, to load all seed files for the current environment rake db:seed_fu # to load seed files matching orders or customers rake db:seed_fu FILTER=orders,customers # to load files from settings.root/features/fixtures rake db:seed_fu FIXTURE_PATH=features/fixtures EOS task :seed_fu => :environment do

    if ENV["FILTER"]
      filter = /#{ENV["FILTER"].gsub(/,/, "|")}/
    end

    if ENV["FIXTURE_PATH"]
      fixture_paths = [ENV["FIXTURE_PATH"], ENV["FIXTURE_PATH"] + "/" + settings.environment.to_s]
    end

    SeedFu.seed(fixture_paths, filter)
  end

  task :load_config do
    require "./app"
  end
end

Rake::Task["db:seed_fu"].enhance(["db:load_config"])

SeedFu.fixture_paths = [
  Pathname(settings.root).join("db/fixtures").to_s,
  Pathname(settings.root).join("db/fixtures/#{settings.environment}").to_s
]

コードとしては、seed_fu の rakeファイル を元に、sinatra-activerecord から、データベースの接続設定を拾ってくる部分を参考にしたりした。

Rake::Task["db:seed_fu"].enhance(["db:load_config"])

の部分がミソで、これでアプリケーションを通してデータベースに接続する必要がある。ここで2時間ぐらいハマった。

*** UTF-8 support was requested, but insufficient UTF-8 support was
*** detected in your curses and/or C libraries. Please verify that your
*** slang was built with UTF-8 support or your curses was built with
*** wide character support, and that your C library was built with wide
*** character support.

これを non-root な環境で以下の方法にて解決した。
とてもシンプルではあるんだけど、 –enable-widec とか忘れるねん……

バージョンは執筆時点のものです。

$ wget http://www.nano-editor.org/dist/v2.4/nano-2.4.2.tar.gz
$ rm nano-2.4.2.tar.gz
$ cd nano-2.4.2
$ apt-get source libncursesw5
$ cd ncurses-5.9-20140118
$ ./configure --enable-widec --prefix=$HOME --with-shared
$ make
$ make install
$ cd ../nano-2.4.2
$ ./configure --prefix=$HOME --enable-color --enable-multibuffer --enable-nanorc --enable-utf8
$ make
$ make install

追記 (2015/10/14)

@sukukyon Gehirn RS2 Plus の明日のアップデートで nano と libncursesw5-dev をインストールします。明日のお昼までにこのアップデートが適用されます。

— Kohei YOSHIDA (@yosida95) October 13, 2015

とのことなので、Gehirn RS2 では non-root でも何もしなくても nano が使えるようになるらしい。ありがたい……。

Gehirn DNS というのは、エイリアスやらマイグレーションやら機能が充実している DNSサービスです。
Web インターフェースもモダンで結構使いやすいのですが、もちろん API も叩けるので CLI でアップデートできて便利。
ステマっぽいですが、使ったところで僕には1円も入りません……

そんな Gehirn DNS を、gddns を使って DDNS っぽく使っていたのですが、Gehirn Infrastructure Service の開始に伴い API体型もガラッと変わりました。

新しい Gehirn DNS でも DDNS っぽく使いたいですよね。
というわけで gddns2 を作りました。

gddns2、複数ゾーン/複数ドメイン使えて便利になった! みたいなのがあります。
そのうち IPv6 対応もしたいところですね。

ちなみに、新しい Gehirin DNS ではリクエスト元の グローバルIP が取得できなくなったので、ipinfo.io を使って取得しています。

Gehirn DNS、2円/日でとても安価なのですが、執筆時点(2015/10/13) ではプレビュー期間なので無料です。ぜひ使ってみてください。

グラフの描画領域をスクロールした時に、ノードをドラッグしようとすると座標がぶっ飛ぶという割りと深刻なバグなのだけれど、sigma.js のサンプルは全てページに全画面で描画されていたので今まで気が付かなかったんだと思う。

原因はブラウザの座標系の違い (pageX/Y と clientX/Y のズレ) だった。JavaScriptでブラウザの座標系なんて今まで意識したこともなかったせいで、原因を突き止めるのにかなり手間取ってしまった……

結果として、修正は以下の2行の変更で済んだ。

-  x = event.pageX - offset.left,
-  y = event.pageY - offset.top,
+  x = event.clientX - offset.left,
+  y = event.clientY - offset.top,

僕はこのコードが存在するもう一箇所(タッチデバイス向けのコードだった)にも修正をして、PR(Pull Request) を送ったのだけれど、これが問題だった。

送ってから数週間反応が無かったので、いつ Merge されるのかなと楽しみにしていたら、昨日 Issue に返信があって、「そのPRはタッチデバイスのピンチイン/アウト操作を破壊している」と突っ込まれ、………?! とびっくりしつつ、返信の検証コードを試したら確かにバグっていて、急いで元々の修正点1箇所だけを修正したPRを送信。

昨夜未明に無事 Merge されました。よかったよかった。

OSS、こうして人のプロダクトに貢献出来るの良いな〜と思いますし、承認欲求も満たせて一石二鳥な感じがありますね。
今後も貢献していきたい

なんとなくこの記事を書きながら、Issue の英語間違ってて恥ずかしいなこれーとかなっていた。恥ずかしい恥ずかしい

LLDBの使い方（チュートリアル日本語訳） | こん

とりあえずここを読めばいいと思います。

以下は、上を読みながら実際にどのようにして作業を行ったかという流れのメモ。

まず、コンパイル時に -g オプションをつけてコンパイルすること
(これによって変数名や関数名のようなデバッグ情報が埋め込まれる)

$ pgrep a.out

なんかでプロセスのpidを取得して、

$ lldb -p [pid]

で対象プロセスにアタッチ

(lldb) breakpoint set -n malloc_error_break

とすると、mallocにまつわるエラーにブレークポイントがセットできる
(その他のブレークポイント等は元記事を参照)

これを叩いた時に、メインプロセスの実行が止まったら

(lldb) c

で再開出来る。(c は continue の省略コマンド)
で、実行すると、ブレークポイントで自動的に lldb がスタックトレースを吐いて止めてくれる。

(lldb) bt

でスタックトレースが表示できる (bt = thread backtrace)

(lldb) frame select [n]

で、n番目のフレームに移動出来る (btで表示した #n にあたるもの)

(lldb) frame variable

とすると、そのフレームから見える変数が表示できる。

(lldb) p [variable]

とかすると、 valiable の値が表示できる。
また、*, &, ->, [] みたいな演算子も使用可能

(lldb) expr (int)printf("hoge")

みたいにすると、 printf(“hoge”) の返り値を取得できる。
ただし、返り値のキャストが必須のよう
(普通にhogeと表示出来るらしいけれど、こちらの環境では上手くいかなかった)

以下、気を付けた方が良いと思った点です。

• そもそもFreeBSDでCUDAをネイティブに扱うことは出来ないので辞めたほうが良さげ。(ハマった
• GUI環境だと何度もコケたので、GUI環境は避ける方が良い (Ubuntu Server をおすすめします。
• apt-get でドライバ, CUDA Toolkitを入れるのはハマることが多いので、NVIDIAのサイトから.runファイルを落とすのがおすすめです。
• nvidia-smi コマンドでグラボが認識しているか確認出来る。

参考リンク

• ドライバ: NVIDIAドライバダウンロード
• CUDA Toolkit (Downloads | NVIDIA Developer Zone)

ただ、このサービス、1つ気になったことがあります。

なんでアドベントカレンダー作るのはそんなに簡単なのに今日の記事一覧が見れないんだ!!

……何故でしょうか…… 今日公開された記事を5つ観ようとしたら、5つそれぞれのアドベントカレンダーのページを開き、そこから今日の日付のところまでスクロールし、リンクをクリックしないといけないのです……

これはまとめを作るしか無いなーと思いまして、作りました。

Adventar::List

※ちょこちょこ稼働させながらコード書き換えてるので500返りますがご愛嬌

超シンプルです。めいどいんSinatraです。
最初はCGIで作っていて(何)、1ファイルで動いてミニマム感溢れていたのですが、あまりにも遅すぎたので途中でPassengerに変更しました。
データはAdventarから持ってきたものをNokogiriでスクレイピングして、redis_ormを使ってRedisに投げています。
ただ、redis_ormの実装がアレなのか良く分かりませんが、異様にバグります。なんでや!!
例えば、id=1なオブジェクトを検索したらid=2なものが返ってくるとか、find(:all, …)で取得したデータが何故か最後に突っ込んだデータだけとか…
あまりにも残念すぎたので素直にDataMapperを使うべきだったと反省。

最後に:
クリスマスプレゼントお待ちしております!

https://twitter.com/sukukyon/status/381401707759935489

https://twitter.com/sukukyon/status/381401849338683394

Chrome Extension 、作るの面倒くさそうだなーという思い込みがあったのだけど、実際に試してみたらかなり簡単でした。

情報も充実してて、分からないことはググったら一発で解決したので、ふとした思いつきという微妙なモチベーションでも詰まらずに完成したわけですっ。

今更、作り方を説明などしても無駄な感じなので、参考になったサイトを2つだけ。

Chrome Extensions API リファレンス

ただのリファレンスと言っては何だけれど、困ったことは大体ここを見れば良いと思う。

What are extensions? – Google Chrome

公式の解説ページ。リファレンスにもなっているけれど、チュートリアルだったり、各機能のサンプルが豊富にあったり。

単に自分が使えればいいやー程度の、そもそも公開する気なんてさらっさら無い拡張機能なので、セキュリティ周りとかを何も考えずに作ったら1時間で出来た。

それにしてもお手軽だなーと。

JavaScript やら HTML やらの基本知識さえあれば、そこそこの物は簡単に作れる気がする。ただ、既存の物は結構多いのでやはり新規性が…

とりあえず出来上がったものを置いておきますね。

http://dev.monora.me/test/TabCount.crx

Chromeでそのままインストールしようとするとエラーが出るので、一旦ダウンロードしてから、設定->拡張機能 のところに ドラッグすればインストール出来る気がします。

FreeBSDでのmakeのやり方がまた変わってしまったので後述します。
とりあえずベンチマークの結果から。

$ cat test.txt
Hello!

$ cat test.rb
#!/usr/local/bin/ruby

print "Content-type: text/plainnn"
print "Hello"

$ cat test.mrb
Apache.rputs("Hello")
Apache.return(Apache::OK)

検証機のスペック: IBM ThinkCentre A55 (9636-A16)
CPU: Core2 duo E6300@1.86GHz
RAM: DDR2-SDRAM 1GB
LAN: Broadcom Gigabit Ethernet
Apache/2.2.23 (FreeBSD), mod_fcgid/2.3.6

Varnish(3.0.3)がリバースプロキシとして動いているので参考値であることをご了承ください。

abの条件は前回と同じく下記の通りで、3回計測して平均を取っています。

$ ab -n 100000 -c 100

な……何故か、FastCGIのrubyに負けてますが、このような結果となりました。

2013/2/17 21:15追記:
mod_mrubyの作者である @matsumotory さんがこんな事を仰っていたので最新版をビルドし直して再測定しました。は、速い…

mod_mrubyはApacheのモジュールとかを書くのに面白く使えそうなので、そちらの道を模索してみたいなぁ……と

FreeBSDでmod_mrubyを使うためには、またちょこっと弄る必要があるみたいです。

$ git submodule init && git submodule update
$ cd mruby

mruby本体のビルド設定に-fPICを付ける。

$ nano tasks/toolchains/gcc.rake
4: cc.flags = [ENV['CFLAGS'] || %w(-g -O3 -Wall -Werror-implicit-function-declaration -fPIC)]

makeではなくgmakeを使う。

$ rake
$ cd ..
$ ./configure
$ gmake && gmake install

この2点だけです。エラーが読めない人間には辛い……
もう httpd.conf が mod_mruby を読み込むよう設定されているはずなので、 Apache を再起動させれば終わりです。

$ httpd -k restart

組み込み向けのRubyであるmrubyをApacheに組み込めるようにした、mod_mrubyというものをFreeBSDで動かしてみようかと思って手を出したら大苦戦しました。

とりあえず動いたには動いたという状況ですが、簡単なメモとベンチマークを取ってみました。

2013/2/17追記
mod_mrubyの更新によって手順が変わりました⇒ mod_mruby on FreeBSD

導入はmod_mrubyのページと同じようにやればいいのかと思いきや、makeでエラーを吐いてしまいます。

$ make
make: illegal option -- -
usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
        [-d flags] [-E variable] [-f makefile] [-I directory]
        [-j max_jobs] [-m directory] [-V variable]
        [variable=value] [target ...]
rake aborted!
Command failed with status (2): [make -C src --no-print-directory CC='gcc' ...]

Tasks: TOP => default => all
(See full trace by running task with --trace)
*** [libmruby.a] Error code 1

Stop in /root/mod_mruby.

どうもmrubyのRakefileがLinux向けのようで、makeをgmakeに書き換える必要があるようです。

$ nano tmp/mruby/Rakefile
#MAKE = ENV['MAKE'] || 'make'
MAKE = ENV['MAKE'] || 'gmake'

mrubyは1回mod_mrubyをmakeをしないとRakefileが存在しないので注意です。

あとはWarningが出ますがとりあえずスルーして、make installすればApacheにモジュールが登録されます。
あとはhttpd.confに、

AddHandler mruby-script .mrb

と書き加えれば普通にmrubyファイルが動くはずなのですが……

自分の環境(Freebsd 9.1-BETA1 amd64, Apache/2.2.23 Event MPM)な環境では、httpdを起動した直後からCPUをバカ食いする上、リクエストに全く応答しなくなるという状況に陥ってしまい、解決策が分からなくなりました。
そんなことをTwitterで呟いたら、mod_mrubyの作者である、matsumoto-rさんから

@kyonfuee 現状、きちんと対応しているのはpreformでworkerもeventも一応動くのですが、不安定です。preforkで試してもだめでしょうか？

— Ryosuke Matsumoto / まつもとりー (@matsumotory) December 21, 2012

という指摘を頂きました。試しに(FreeBSD 9.0 i386, Apache/2.2.22 Prefork MPM)な旧サーバーで試したところ、何も問題がないかのように動きました。
どうもApache 2.2でEvent MPMをやるのはだめみたい……？

試しにどのくらい速いのか、mruby, FastCGIのRuby(mod_fcgid, 1.9.3p125), 静的ファイルの3つで比較してみました。

$ cat test.mrb
Apache.rputs("Hello")
Apache.return(Apache::OK)
#!/usr/local/bin/ruby

$ cat test.rb
print "Content-type: text/plainnn"
print "Hello!"

$ cat test.txt
Hello!

検証機のスペック: IBM ThinkCentre 8086-AGJ
CPU: Celeron D 330 2.66GHz
RAM: DDR-SDRAM 1GB
LAN: Gigabit Ethernet(Intel chip)

abの条件は下記の通り

$ ab -n 100000 -c 100

結果:

• mruby

Time taken for tests: 108.551 seconds
Requests per second: 921.23 [#/sec] (mean)
Time per request: 108.551 [ms] (mean)
Time per request: 1.086 [ms] (mean, across all concurrent requests)

• Ruby(FastCGI)

Time taken for tests: 362.996 seconds
Failed requests: 109
Requests per second: 275.48 [#/sec] (mean)
Time per request: 362.996 [ms] (mean)
Time per request: 3.630 [ms] (mean, across all concurrent requests)

• txt

Time taken for tests: 98.767 seconds
Requests per second: 1012.48 [#/sec] (mean)
Time per request: 98.767 [ms] (mean)
Time per request: 0.988 [ms] (mean, across all concurrent requests)

なんとmrubyが静的ファイルに迫る速度を出してました。すごい……

ちなみにmrubyが動かなかった方のメインサーバー(Core2 duo E6300@1.86Ghz, RAM512MB)ではRuby(FastCGI: mod_fcgid)で1857.93 [#/sec]とかいう値を叩きだしてました。
後日メインのサーバーの方もPreforkにして検証してみようかと思います。
いつになったらFreeBSD PortsにApache 2.4が来るのだろう……

そういえば、もう明後日に迫っていますが、CombConfに参加します！
内容は、「HTTPSを使わずに暗号化通信をしよう」でやる予定です。
出来るの………？(まだ検証してない

なんとかA, B問題を解くことが出来ました。流れはこんな感じ。

http://twitter.com/kyonfuee/status/272311520388591616

長いでんがな……
C問題は解けなかったです。時間足らず。

今回は初のRubyで挑戦してみました。getsとsplitとchompでどうにかなりそう？とか思いつつ、ARCで他人のRuby解答を見よう見まねでやってました。

提出コード

A – C-Filter
見た瞬間に正規表現で解けそうだと思ったのでそのまんま。
/aaa/だと”aaaa”にマッチしてしまうので、/^aaa$/にするようにして解決

#!/usr/bin/ruby -Ku
input = gets.split

ng = []
num = gets.to_i
num.times { ng < < gets.chomp }

ng.map!{|v| v = Regexp.new("^" + v.gsub("*", ".") + "$")}
ng.each{|n| input.map!{|i| i =~ n ? i = "*" * i.length : i}}

input.length.times.each {|n| print input[n]; print " " if n != input.length}
puts

298Bytes(提出時から若干変更あり)

B – Password
最初は簡潔なコードにして書いていたつもりが、前述の通りひたすらにA問題に提出してWAを返されていたので焦りながら修正していたらこんなありさまに…
でも最後のこのコードしか通らなかったり。本当に良く分からないミラクル。

Rubyではchar ⇒ intは “a”.ord, int => charは 96.chr みたいにやるらしい。へえ
というのを利用して、後は普通のC言語でやるような感じで解いた。

後半のif out == input 以降が若干キモ？のようです。
入力が”b”の時に”aa”を返したり、”zz”のときに”yza”を返すようにしてます。

#!/usr/bin/ruby -Ku

hash = 0
input = gets.chomp
input.each_char {|s| hash += s.ord - 96}

if hash == 520 || hash == 1 #a, zzzzzzzzzzzzzzzzzzzz
  puts "NO"
  exit
end

out = ""
out += "z" * (hash / 26)
out += ((hash % 26) + 96).chr unless (hash % 26) == 0

if out == input
  if hash < 26
    out = "a"
    out += (hash - 1 + 96).chr
  else
    out = "y"
    hash -= 25
    out += "z" * (hash / 26)
    out += ((hash % 26) + 96).chr unless (hash % 26) == 0
  end
end

puts out

484Bytes

総評
もう少し落ち着いたほうがいいと思う(4度の提出ミスに対して
後はC言語みたいなコンパイラ言語が書けなくなってるくさいので、またそっちも書かないといけないような……
そういえばJOI予選も控えてますし…(PCKはあと1問が5分という所で予選落ち)

そして結構謎なのが、表彰式(1問以上解いたら参加出来る)の開始が12/3(月)の16時からということ。
平日の16時とか参加出来る人が限られそうです……

かくいう僕も地理的には近いけれども時間的に無理ゲなので遅刻の旨を伝えた上で良さげなら参加します。

(どうでも)いいこと

12/22 プログラミング生放送勉強会 第19回＠品川 参加受付中！ #pronama « プログラミング生放送参加するよ！
第12回 日本情報オリンピック予選参加しますよ！

以上

Kuin0.02でコンパイル, 動作確認してます。

まだKuin用のシンタックスハイライトがない………

constに関するコンパイルエラー、Kuin0.021で修正されました。くいなちゃんに感謝です。 (2012/8/27 22:55)

{
  エラトステネスのふるい

  Author: きょんたん (@kyonline)
}

func Main()
  const N : int :: 10000000

  var isPrime : []bool :: @new [N]bool
  var Prime : []int :: @new [N]int
  var numPrime : int :: 0

  for i(0, N - 1)
    do isPrime[i] :: true
  end for

  do Prime[0] :: 2
  do numPrime :+ 1

  for i(3, N - 1, 2)
    if (!isPrime[(i - 1) / 2 - 1])
      continue i
    end if

    do isPrime[(i - 1) / 2 - 1] :: false
    do Prime[numPrime] :: i
    do numPrime :+ 1

    do Kuin@Dbg(i.ToStr())

    var j : int :: (i - 1) / 2 - 1 + i
    while (j < N)
      do isPrime[j] :: false
      do j :+ i
    end while

  end for

  do Kuin@Stop()
end func

公式サイトには日付しか書かれていなかったりしてメールでの発表なのかな？とか思いながら12時になるもメールなし。

なるほど落ちたのかーと思ったころ、まさかの予選通過通知。

まさかのSupercon2012予選通過です！東工大でお会いしましょう！

— きょんたんさん (@kyonfuee) 2012年6月29日

とりあえず前の記事にも書いてあるとおり、何でバグあるはずなのに通ったのかとか色々謎は残りますが…

Supercon2012、バグ死してる方多いのだけど、領域破壊してる自分のプログラムなんで通ったの…？

— きょんたんさん (@kyonfuee) 2012年6月29日

でも出場できるからには全力で頑張ります！

自分と先輩方2人で参加します。チーム名は後ほど…？

チーム名はhogeになりました。よろしくお願いします。(2012.7.2 2:38追記)

追記(2012/6/25):詳細の説明は私事により2週間ほど先になるかも……？
コードが長いのは仕様です。期限日の午前4時に書いていたらこうなります。
動的計画法とかそんな時間短縮を使う暇も知識もなかったのですし…
全てが同じ文字のパターンに対しては一応関数を作って対処してます。
ただ、|W|が短い場合の対策がほぼ皆無。

添付ファイルミスとは: 寝ぼけて< と< =を間違えたプログラムを送信した。

というわけでとりあえず修正したソースだけ置いておきます。詳細は後ほど?

多分書かない。というか書けない…… (2012.7.8追記)

/* SuperCon 2012 予選問題C用テンプレート(問C,スーパーコン予選問題 兼 1級認定問題 2012版)
・解答プログラムはこのテンプレートに従って作成すること.
・解答プログラムは1つのファイルで,チーム名.c という名前にすること.
・入力の方式は,あらかじめ入力ファイル(例:input_sample.txt)を作っ
ておき,実行時にファイル名を指定する方式です.
*/

#include <assert.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <time.h>

/* ↓以下の範囲は変更可能 */
#define TIME_LIMIT 59.5
#define MAX_LEN 10
#define MAX_V 100000

#define max(a,b) ( a > b ? a : b )
#define min(a,b) ( a > b ? b : a )

int isFront(char input[]);

void searchTree(int flag, int answerTemp, char inputStr[]);

void searchB (void);

int isTypeB(void);

int Sum(int flag);

int N_G = 0;
int v_G[1000];
char w_G[1000][10 + 1];
char W_G[10000 + 1];
clock_t start_G;

int answerTemp_G = 0,strLenTemp_G = 0;
/* ↑上記の範囲は変更可能 */

int main(int argc, char** argv){
int answer = -1; /* この変数に答(Vの最大値)を代入してください */
int N;
static int v[1000];
static char w[1000][10+1];
static char W[10000+1];
char* problem_file;
clock_t start, end;
FILE* fp;

int i;
char buf[0xffff];
char* p;

if(argc <= 1){
fprintf(stderr, "Enter the input file.¥n");
exit(EXIT_FAILURE);
}

problem_file = argv[1];
fp = fopen(problem_file, "r");
if(fp == NULL){
fprintf(stderr, "Cannot open %s.¥n", problem_file);
exit(EXIT_FAILURE);
}

p = fgets(buf, 0xffff, fp);
assert(p != 0);

N = atoi(strtok(buf, " ¥n"));
assert(1 <= N && N <= 1000);

p = fgets(buf, 0xffff, fp);
assert(p != 0);
p = strtok(buf, " ¥n");
strcpy(W, p);
assert(1 <= strlen(W) && strlen(W) <= 10000);
for(p = W; *p; ++p){
assert(islower(*p));
}

for(i = 0; i < N; ++i){
p = fgets(buf, 0xffff, fp);
assert(p != 0);
v[i] = atoi(strtok(buf, " "));
assert(-1000000 <= v[i] && v[i] <= 1000000);
p = strtok(NULL, " ¥n");
strcpy(w[i], p);
assert(1 <= strlen(w[i]) && strlen(w[i]) <= 10);
for(p = w[i]; *p; ++p){
assert(islower(*p));
}
}

fclose(fp);

start = clock();

/* ↓以下の範囲は変更可能 */

N_G = N;
strcpy(W_G, W);
for (i = 0; i < N; i++) {
memcpy(w_G[i], w[i], sizeof(w[i]));
v_G[i] = v[i];
}
start_G = start;

if (isTypeB() == 0) {
searchB();
} else {
searchTree(0, 0, "");
}

answer = max(0, answerTemp_G);

/* ↑上記の範囲は変更可能 */

end = clock();
printf("%s, %f, %d¥n", problem_file, (double)(end - start) / CLOCKS_PER_SEC, answer);

printf("%s, %d¥n", problem_file, answer);
return 0;
}

/* ↓以下の範囲は変更可能 */

int isFront(char input[]) {

int ret = strncmp(input, W_G, strlen(input));

if (ret == 0) return 0;
if (ret < 0) return 1;

return -1;
}
void searchTree(int flag, int answerTemp, char inputStr[]) {
int quit = 0, len, i;

char *tempStr;
tempStr = (char *)calloc(10000 + 1, sizeof(char));
strcpy(tempStr, inputStr);
len = strlen(tempStr);

for (i = flag; i < N_G; i++) {

if(((double)(clock() - start_G) / CLOCKS_PER_SEC) >= TIME_LIMIT) {
answerTemp_G = max(answerTemp_G,answerTemp); break;
}
memset(tempStr + len, 0, sizeof(char) * (10001 - len));

strcat(tempStr, w_G[i]);

switch (isFront(tempStr)) {
case -1: continue;
case 0:
answerTemp += v_G[i];

answerTemp_G = max(answerTemp, answerTemp_G);

flag = i + 1;
searchTree(flag, answerTemp, tempStr);
answerTemp -= v_G[i];

if (quit == 1) continue;
break;
case 1:
answerTemp += v_G[i];
flag = i;

answerTemp_G = max(answerTemp_G,Sum(flag + 1) + answerTemp);

quit = 1;
continue;
}
}
RET:
free(tempStr);
tempStr = NULL;
return;
}

void searchB (void) {
int AnsS = Sum(0), AnsL = AnsS, WLen = strlen(W_G);
int strLenS = strLenTemp_G, strLenL = strLenTemp_G;
int a = 0, b = MAX_LEN, c, d = MAX_V, e = MAX_V;

if (strLenTemp_G <= WLen) { answerTemp_G = Sum(0); } else {
int i;
while (strLenS > WLen && strLenL > WLen) {

for (i = 0; i < N_G; i++) {
if (v_G[i] > 0) {
c = strlen(w_G[i]);
a = max(a, c);
b = min(b, c);
}
}

for (i = 0; i < N_G; i++) {
if (v_G[i] > 0) {
c = strlen(w_G[i]);
if (a == c) d = min(v_G[i], d);
if (b == c) e = min(v_G[i], e);
}
}

strLenL -= a; AnsL -= d;
strLenS -= b; AnsS -= e;

}
if (strLenL <= WLen) answerTemp_G = AnsL;
if (strLenS <= WLen) answerTemp_G = max(answerTemp_G, AnsS);
}
return;
}

int isTypeB(void) {
char isSame = w_G[0][0];
int i,j = 0;

do {
for (i = 0; i < strlen(w_G[j]) ; i++) if (w_G[j][i] != isSame) { return 1; }
} while ( ++j < N_G );

return 0;
}

int Sum(int flag) {
int i, ret = 0;
for (i = flag; i <= N_G; i++) if(v_G[i] > 0) {
ret += v_G[i];
strLenTemp_G += strlen(w_G[i]);
}

return ret;
}
/* ↑上記の範囲は変更可能 */

まさか初投稿がこんな残念な記事になるとは…