YAPC::Asia Tokyo 2014で当日スタッフをしました
去年に引き続き、当日スタッフをしてきました。
YAPC::Asia 2013に参加したです！ - ミントフレーバー緑茶
スタッフと言っても例年通りコアスタッフの方々がしっかり準備してくださっているので、椅子を運んだりマイクを運んだりカキ氷を運んだりするくらいであんまり偉そうなことはしません。イベントは準備がキモですね。イベントホールの状況はコアスタッフでウルトラスーパー PHPer であるところの uzulla さんの記事がよくまとめられてて最高です。
スタッフとしてのYAPC::Asia 2014 レポート（Without about my talk) - uzullaがブログ
イベントホールスタッフを 3 グループに分割して、担当部分じゃないところは他のトークを見に行ったら良い。という提案を uzulla さんがしてくださったので、去年よりトークを見る時間ができて良かった。
以下は自分が見た発表＆スライドについて。社内で YAPC フィードバック会があるので、もうちょっと発表スライドを読んでいきたい。
「コマンドラインツールについて語るときに僕の語ること」 @deeeet さん
YAPC::Asia 2014でコマンドラインツールについて語ってきた | SOTA
自分にとって目新しいところはなかったけど、スライドがすごく見やすい＆分かりやすい。
「オープンソースの開発現場 - Perl 5.20 のSubroutine Signaturesが来るまでの奮闘の軌跡」 @lestrrat さん
YAPC::Asia Tokyo 2014 オープンソースの開発現場 - Google スライド
Subroutine Signatures を追加するまでのドラマが紹介されていた。皆が使っている既存のものに手を入れるということはそれぞれの人にとって賛否両論ある。自分にとっては良かれと思ってやっていることもいろいろな人にいろいろなプライオリティがあるから、否定されることもある。そんな中で自分のやりたいことを実現するには、コードを書いて実装するというだけではなく、やりたいことが実現するように仕向けていく人間力・政治力という、本質的ではなさそうなものが残念ながら必要になる。
大切なのは「自分以外の人は別のプライオリティを持っている」ということを認識し、それを持った上で立ち止まらず進み続けることかなと思う。他人が別のプライオリティを持っているということを知ると、他人がどんなプライオリティを持っているかという点を考慮しながら人間力・政治力を振るうために役立つし、人間力を発揮しなくても、他人の意見は他人の意見として過度に傷つかずに無視して我を通すか諦めるかして次に進むことができそう。
個人的には、既に動いている機能に手を加えるようなアグレッシブな変更よりも、質問の時に弾さんが言っていたように sub じゃなくて fun を作ってみるという手もありだったのになぁと思う（予約語が増えて、既に fun を使っているようなコードにダメージがあるかもしれないが）。有力そうな Subroutine Signatures の実現方法のひとつが序盤でバッサリと切られていたというのは残念。
HASH COLOR
ちょっとしたHTMLはGitHub Gistに置いてbl.ocks.orgで表示するのがお手軽です - Qiita で bl.ocks.org を知り、何か試してみたくなって、入力に応じて色を変えまくるやつ作った。ずっと入力してると気分悪くなる。
http://bl.ocks.org/jewel12/f20ed3003e57cf558e2e
bl.ocks.org は gist の HTML を表示するだけというシンプルさが最高だと思う。
SlackのCUI
https://github.com/jewel12/slacui
チャンネル一覧とチャンネルを指定して読むことしかできない。 percol / peco でチャンネルを絞り込むと少しは便利に使えるけど、毎回API叩くから遅くて使いものにならない。
lacui channels | peco | cut -f1 | xargs slacui read
コンパイルログとかに何かしら色をつけたい
最近はHaskellの本を読んでいて写経したり色々試したりするのだけど、コンパイルログの見辛さによって、静的型付け言語の強みであるコンパイル時エラー検出の力が出せていないような気がした（ghcに--colorオプションとかある？）。
社内LTもあることだし、自動で色付けするマシーンを作ろうと思いたって作り始めた。テキストに自動で色をつけるというと、テキストをルールでパースして色をつけるというやり方になるかと思う。しかしいちいちパースルールを書くのもだるいし、テキストを適当に標準入力から突っ込むと適当に色付けしてくれるものが欲しい。
自分が知っている自動色付け方法はCoding in colorという、シンタックスハイライトされない部分にも色を付けて見やすくしてやろうというもの。
Coding in color — Hacking Programs : Code, Programming Idea, Tutorial, Showcase, Experience — Medium
function等のキーワード以外の単語を名前順にソートして、予め用意しておいた色のリストに割り当てていくというやり方になっている。例えばtypoしたときに色が違っていたりするので気付きやすいという利点がある。
他にどうやってログに色付けするかも考えつかなかったのでパクろうと思いHaskellで書いてみようとしたが、自分は想像以上にHaskellに精通しておらず、色々調べながら進めていたら就業時間後の2日かけても出来上がらなかった。余談だけど、System.Console.Rainbow (https://github.com/massysett/rainbow) のコードを読むのはMonoidとかを実際に使っていて、初心者には勉強になった。例えば "text" <> blue <> bold で太い青色文字列 "text" を表わすとして、この組み合わせは "text" <> bold <> blue でもいいみたいな。
今すぐHaskell力を上げるのは厳しいことがわかったので、色付けプログラムをRubyで書いてみたらプロトタイプがLT発表日のお昼休みで出来上がった。
https://gist.github.com/jewel12/b33f73635bbbed2b9e97
入力を空白でsplitしていったものを単語として扱っていて、Coding in colorと同じように着色していった結果。
自分のコンソールではカビが生えたような彩色になってしまった。
元のログはこんな感じ。
他にも色付けする方法ないかと無い知恵を絞ったところ、語の頻度によって、高頻度になるに連れて色を強調していくという方法をとってみた（逆にどうでも良い語だともとれるので強調しないというのもあり）。
カビよりも落ち着いた感じになったが、たいして読みやすくなったようには思えない。"Not in Scope"の塊で色がついてるのはいい感じがする。頻度で色付けする方法の辛いところは、テキストファイルを全部読み込まないといけない点で、コンソールに流れるログに色付けはできない。
個人的には色をつけるだけでもなんとなく読みやすくはなったと思う。カッコ内は１語だったり複合語を考慮したりと適切な粒度の塊に色付けすればもっと見やすくなる予感はある。なんか適当に色付け方法を考えて試してみて、偶然いい感じになってくれたらと期待してたけど、まずここに色をつけて欲しいというふうに自分で色付けしてみてから、それに合わせて色付け作戦を練っていくアプローチが真っ当だったっぽい。
ご意見ご感想お待ちしております。
タスク切り替えにはコストがかかる
ゴールデンウィークに親と待ち合わせしていて、早めに着いたからジョエルオンソフトウェアを買って読んでいた。暇つぶしだから面白そうなところだけかいつまんで読むつもりだったけど、基本的に全部面白い。PART 2まで読み終わって一番面白かったのは23章の「人のタスク切り替えは有害であるとかんがえられる」。
Human Task Switches Considered Harmful - Joel on Software
よくタスクを平行してやるよりも直列で進めたほうが早く終わると感じる。フロー状態をぶつ切らないとかマジカルナンバーのように人間が同時に物事を把握できる量はそんなにないとか色々理由付けられると思うけど、この章のCPUのマルチタスキングを例にして解説しているところがわかりやすくて面白かった。
タスクの切り替えにはコストがかかる。ゴールデンウィーク前にしていた仕事の細部が思い出せない。昼休み前に自分はどんな構成のコードを書こうと思って途中まで書き進めていたんだっけ。という具合に人はすぐに物を忘れるので、思い出すのに時間がかかる。残念ながらパイプライン処理のようにタスクをこなす超人にはなかなかなれない。他のことが気になっても、できるだけ今のタスクが終わってからにできないかというのを意識するようになった。
ただ、期日が決まっている中で直列にタスクをこなすのは止めた方が良いときもある。タスクAとBがあって、序盤ではAもBも2日で終わるという（たいして根拠の無い）予測をしていて、2つ合わせて4日かかると思っていた。予定通りAを2日でこなし、Bにとりかかって1日目の夕方に、どうもBは4日必要なタスクだったと気付く。この時点で明日には終わらないから締め切りを３日伸ばしてくれとお願いすることになる。一方、最初にAを2日かけて終わらすのではなく、Aに1日、Bに1日というやり方だったら2日目で締め切りが伸びるということを伝えることができる。AとBが終了する日数は同じとしても、土下座するタイミングは速いほうが迷惑はかからない。すごい極端な話ではあるけど。
数日かかる大きいタスクは数時間単位に分割して、細かいタスクを直列に実行する。大きいタスクは直列に実行するのではなく、進めてない方のタスクをたまに様子見したりすると良いかなと思う。
最近遊んだiOSゲーム
面白かったのを一言ずつ。iTunesオススメゲームが基本的に面白いから、面白いゲームを探したりする行為をしなくなったように思う。パズルゲームとかも遊んだけど、ハズレが多かった。ミニマルを目指しましたみたいなデザインのゲームは面白そうに見えるがハズレを連続で踏んだから食傷気味。
Smash Hit
iTunes Storeのオススメコーナーにあったから遊んでみた。ボールを投げてガラスを破壊していくゲーム。ガラス破壊さえなければゴミ箱シュート系のゲームと変わらないけど、ガラス破壊の爽快感だけで全然別物になる。
Geometry Dash
強制横スクロールアクションゲームで、横からくるブロックをジャンプで避けたりする。操作はタップのみ。極端な難易度と１ステージの適度な長さのバランスがSuper Hexagonを思い出す。
Official Geometry Dash Trailer - YouTube
Duet
赤と青のボールを円に沿って右回転・左回転させて障害物を避けていくシンプルなゲーム。難易度は高い。これもオススメコーナーにあったし、もうオススメコーナーにあるゲームだけ遊んでおけばおｋなんじゃないかと思う。
Duet Game - Universal - HD Gameplay Trailer - YouTube
Deemo
音ゲー。ステージをクリアしていくとストーリーが進む珍しい音ゲー。現在、中間エンディング（？）みたいなのがあるだけで、話は終わっておらず、次の追加パックで話が進むらしい。
Deemo Android GamePlay Trailer (HD) - YouTube
Kero Blaster
開発室Pixelの新作アクションゲーム。攻撃は左右と上にスワイプすると方向が固定されるという操作方法で、スマホでも遊びやすいUIだと思う。サクッとクリアできる内容で、色々盛り沢山だった洞窟物語とくらべてしまうけど、そのサクサク感もスマホ向けに調整されているのかな。まあ、当たり前に面白いよねという感想だった。
Markdown => Textile
メモはMarkdownで書いてるのに、やむを得ない事情でそれをTextileにしないといけないこともある。 仕方がないのでいろんな形式のドキュメントを相互変換できるPandocを使いだした。
Installingに書いてあるとおり、PandocはHaskellパッケージ管理システムのcabalでインストール。
brew install haskell-platform cabal update cabal install pandoc export PATH="$HOME/Library/Haskell/bin/:$PATH"
pandoc -f Markdown -t Textile File
みたいにすればMarkdown形式のFileをTextileへ変換できる。 変換ついでにクリップボードに放り込めると便利なのでpbcopyを使う。
pandoc -f Markdown -t Textile File | pbcopy
記事のネタがないのでこんな感じでお茶を濁していきたい。
