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
記事のネタがないのでこんな感じでお茶を濁していきたい。
白と黒のとびら
- 作者: 川添愛
- 出版社/メーカー: 東京大学出版会
- 発売日: 2013/04/19
- メディア: 単行本
- この商品を含むブログ (8件) を見る
魔法使いに弟子入りした少年ガレット．彼は魔法使いになるための勉強をしていくなかで，奇妙な「遺跡」や「言語」に出会います．最後の謎を解いたとき，主人公におとずれたのは……
http://www.utp.or.jp/bd/978-4-13-063357-4.html
こんなふうにオートマトンと形式言語に関連するテーマで１つのストーリーになっている。ある程度わかってる人たちは読んでると先が読める部分があると思うけど、それはそれで面白くて、主人公のガレットよ頑張れという気持ちになった。もちろん、オートマトンなんて単語も聞いたことない人でも読めて、最後にはチューリングマシンとはなんだとか、チューリングマシンで解けない計算問題とはどんなものかというところまで分かる。
ガレットに対する師からの言葉には身につまされる部分が多くて、辛い感じになるところもあった……身が引きしまる。
対角線言語
解説にあった対角線言語という単語を知らなかった。対角線言語はチューリングマシンに入力する文字列のうち、記述するチューリングマシンによって受理される文字列を除いた集合だと解説には書いてある。すなわち、受理されない文字列の集合。
受理されない文字列には「そもそもチューリングマシンを記述しない文字列」と「記述するチューリングマシンで受理されない文字列」がある。対角線言語を受理できるチューリングマシンがあるとその文字列は受理可能だという矛盾が生じるので、対角線言語を定義できるチューリングマシンは存在しない。
