海月玲二
2016-01-21(木)

無題

大学の成績って,正直昨今の状況だと詳細につける必要ない気がする.「不合格」「合格」「優秀」の三段階ぐらいでいいんじゃないだろうか.どうせ誰も見てやしないし,そもそもたいした意味はないわけだし.

あと大学当局とか文科省とかが「公正な評価」とか「客観的評価」とか言って指針らしきものを出してくるのもちゃんちゃらおかしい.そんなことを言うぐらいなら,「『優』評価は全体のXX%ぐらいをおおまかな目安に」とか寝言言うのやめれ.

ていうか,この試験問題にしたら何割ぐらい合格できますかねとか聞かれても知らんわ.

2016-01-23(土)

無題

T62Dのタッチパネルを修復するのも難しいので,やむなくKobo Glo HDを入手した.android系e-ink機をもう一台買うのは予算的にちょっとね.解像度が上がった新型なんか3万ぐらいするし.

やむなく買ったとか言ったけど,Kobo Glo HDもそれなりに使えそう.持ってない状態で調べてもいまいちわかりにくくて若干不安だったけど,俺のような「公式の電子書籍ストアから本を買う気は一切なく,よそで買った非DRMのファイルとかフリーで公開されてる文書とかを読むだけのつもり」という使い方も問題なくできるようだ.最初だけ楽天IDで接続してセットアップしたけど,その後は一度もネットにつないでいない.なんなら最初のセットアップ時のログインもバイパスできるらしい.

というか,これ,pdfを読むときと横文字のepubを読むときに関しては,もうKobo Start Menuとkoreader入れておけばそれでいいんじゃないだろうか.元々のnickel環境よりよっぽど便利だと思う.そもそも,中身がlinuxというのがなじみやすくていいな.やりたければ自分で何か書いたプログラムを動かすこともできそうだ.

日本語の小説テキストとかを読みたいときだけは若干問題がある.具体的には青空文庫とかニンジャスレイヤーとかをepubにして読む場合の話だ.さすがにkoreaderは縦書きに対応していないので,nickelに戻るしかない.いちおうUSB接続でコピーしたファイルを読めないこともないようだが,なんか妙に不安定な気がする.

2016-01-27(水)

無題

エスカレーターでは片側を空けたりせずに全員立ってたほうが結局速い,という研究結果があるらしい.まあアレだ別に直観に反するわけではないし順当だと思う.片側空けにしたら高い確率で「歩く側」にデッドスペースができてるからな.

問題はそういうことではない.「全員立ってたほうが結局速い」というのは,「総合的に考えて,単位時間あたりに運べる人数が多くなる」という意味で,歩いて登り降りしたい人の意見は「『私が』エスカレーターを抜ける時間を最小化したい(他の人は別にどうでもいい)」ということである.そもそも目的が違う.もちろん,片側空けシステムのほうが,速く進みたい人は速く進めるのだ.だから,「全員で立ってたほうが結局速いんだから」という呼びかけは間違いで,「みんなのためにちょっとずつ譲歩しようよ」というかんじの話だろう.

しかしまあ,たかだか数十秒か数分速く進んで,だからどうだって言うのかね.俺としては譲歩して総合的効率を最大化すべきだと思うので,お店とかのエスカレーターではわざわざ左側(関西での「歩く側」)に立ったりする(もちろん「通してくれ」って言われたら素直に通してる).ただ,駅でだけはやらないことにしている.日本の駅では数十秒の差が問題になることがある気がするから.

2016-01-30(土)

無題

haskell業界では最近,cabalをそのままどうこうするんじゃなくて,stackなるツールを使うのが便利らしい.

試してみたらこれが本当にすげえ便利でびっくりした.そもそもhaskellコンパイラや基本ライブラリのインストールさえしなくていい(というかstackが必要に応じてホームディレクトリ下に入れてくれる).stackさえ入れておけば,あとは全てstackにお任せできるようだ.普通の人はhaskell-platformとかを使う必要すらないのか.

もちろんプロジェクト毎に必要なコンパイラやライブラリのバージョンを管理もしてくれるので,cabalのsandboxを明示的に操作する必要も別にない.どうも,「sandboxごとに同じライブラリがインストールされることが多くてなんか無駄だな〜」ということもないようだ(stackがバージョンとともに一元管理してくれてるみたい).

プロジェクトディレクトリを作るまでもないようなプログラムで,runghcで動かすような場合でも,必要なライブラリとかを書いておける拡張がされていて,同じように管理できる.これでちょっとした処理のスクリプトとかでもhaskellでやって問題ないな.

利用者の立場からは,バージョンアップが活発なhaskell業界でも依存関係地獄が起きないようにする,最終的な解決手段だと言い切ってもよさそうな雰囲気である.でも,stackが使ってるリポジトリ(各種ライブラリやツールの)をちゃんと管理する仕事は,どうも有志のひとたちが頑張ってやってるみたいだな.今後もちゃんと続けていける運営になるとよいのだが.

まあとりあえず,stackで始めれば今までより飛躍的に環境構築が楽なので,haskell始める人が増えるといいと思う.