涅ir槃na

詩集病

キュウソネコカミと"日常の謎"

最近ちょいちょいキュウソネコカミのMV見てて、おっさんなので「え?こんな歌詞でいいの?」と思ってたんだが、「あれだ、これはミステリ界における"殺人事件"に対する"日常の謎"だ。ロック界における"人生の苦悩・怒り"に対する"日常のイラつき"だ」と思いついたらスッキリした。


キュウソネコカミ - ビビった MUSIC VIDEO - YouTube

これ何度も見てる。


キュウソネコカミー「ファントムヴァイブレーション」PV - YouTube

最近の若いバンド(ゲスの極み乙女。とかKANA-BOONとか)のMVはコント仕立てなのでとても見やすい。

ブログから詩集へ

  • ブログ
    • ブログやめようと思う
      • 正確にはブログという記事毎にURLがあるのでそのURLそのタイトルの記事にはなんやまとまった情報があるんだろうな〜というフォーマットが醸し出すアフォーダンスを気にしない
      • 人のために有用な内容を書こうと試みるのがしんどくなったので、自分のために好き勝手に書こうと思う
      • なので以後は記事毎にまとまった主題があるわけではない
    • タグ管理が全くできない
      • typoとか大文字と小文字で別れちゃってるの直すのがダルい
      • いつも破綻する
      • なので以後は全文検索だけに頼る
  • 言葉
    • 小銃が言うほど小さくないのショートソードが言うほど短くないのと似てる
    • バイオゴリラ、理想の黒ギャル、スケベエルフ、水龍敬ランド
    • 意外なことにググってもBLEACH寛解!」コラない
  • iPhone 6
    • iPhone 6 Plus
      • らくらくフォンでは?
      • どこにぶら下げてもかっこ悪いので萬田銀次郎風サイドバッグに入れるのが良い
      • 萬田銀次郎サイドバッグ関連銘柄を押さえろ
    • iPhone 6
  • Vim
    • これ書くために Previm と hateblo.vim 入れた
      • 確か atom.io でやっていく気持ちだったはずだが移行できてない
  • Anime
  • ネット
    • いむらリボルバー、良さある
    • ネットの問題、「法廷でやれ」と「通院しろ」で大体片付く
    • 問題を全て法廷と病院に押し付けてウェブを浄化しような
    • 罪の軽重によって刑の軽重が決まるの、成果報酬だ
      • 実績が解除されました

記法における「読みやすさ」と「書きやすさ」

プログラミング言語やテンプレート言語やHTMLやPDFを吐き出す言語において、記法って大事よねってみんな思ってるけど、宗教論争になっちゃうよね。んで、今回は宗教論争をさらに熱くするための一助をしたいと思う。まとめると、記法の良さには色々あるってこと。

読みやすさ

まず「読みやすい」ってなんだろう?読み方には大きく分けて(というかこれら以外知らんが)黙読と音読があるじゃないっすか。つまり、

  • 黙読に優しい記法
  • 音読に優しい記法

があるように思う。

例えば、Rubyは黙読に優しい記法を持ってると思う。まず、RubyPerlに比べると記号が少ない。$や@や%が登場する頻度が比較的少ない。同じ理由でテンプレート言語のSlimはHamlよりも黙読に優しいと思う。人によってはこれらの記号で目がチカチカすると思う。俺なのだが。しかし、人によっては強調されてて把握しやすくて良いと思う。そして、Rubyは変数名やメソッドには慣習的にsnake_caseを用いUpperCamelやlowerCamelを使わないのでうるさくない。確か英語的な感覚では大文字は大声だったと思う。CAUTIONとかWARNINGとか強調するときに大文字を使う。そんで、俺的にはUpperCamelやlowerCamelもややうるさい。だからRubyが好きなんだな(自己解決しました)。

一方、メソッドが通常UpperCamelであるObjective-CJavaは音読に向いた記法だと思う。まぁ記法というよりは標準ライブラリがもたらす慣習と言ったほうがいいかもしれないが、これらの言語で書かれたコードが冗長なメソッド名を持つのは周知の事実かと思う。長けりゃ悪いってわけでもなくて、話すときに正確に伝えられるってことは、チーム開発とかにも良いだろうし、普通は思考を音で考えるタイプの方が多いのでいいんじゃなかろうか。

視覚に訴える記法と聴覚に訴える記法があるってわけ。五感全部あればいいのだが、残念ながら匂いがする記法や甘い記法や敏感タッチいやんな記法にはまだあったことない。小説の文章ではたまにあるけどな。第六感?HaskellOcamlは数学感というか関数脳に訴えるんじゃない?(よく知らん)

書きやすさ

書きやすさの方はすっきり腑分けできないのだが、

  • そのまま読める記法
  • 書いていて動作や結果を想像しやすい記法

があるように思う。(思考を整理するための読みやすさは上で書いたので置いておく)

例えば、Markdownは前者の配分が高めだと思う。んで、名前忘れて検索できないけど、とあるMarkdownっぽいやつは(イタリックを/Italic/などとして「あ、斜めなんだな」と分かるように書ける)後者の配分が高めだと思う。Markdownはパラグラフは良いんだけど改行がクソ(改行前に半角スペース2個打つとか、リストの前後に空白行を書かないいけないとか)なんで、小説などのepub作成にはあまり向いていない、つまり、後者の用途で差し障りがある場合もある。アセンブリは後者なんじゃないかな、多分。なんかあんま思いつかないからこれで終わるわ。

まとめ

いろんな燃え方を見たい。

f:id:babie:20140112010632j:plain

中間テーブルにidつけるとWeb APIが綺麗

なんかActiveRecordが中間テーブルにid付けるのに反対する人たまに見るんだけど、俺は付けた方がいいと思う。というのは、Web APIがすっきりするから。

例えば、followships って中間テーブルがあったとして、カラムに followee_id, follower_id って名前を付けるとしようじゃないか。(followship, followee 共に造語です。-shipsを付けて関係を表し、-ee を「される人」-er を「する人」に付けるのが個人的な趣味なのです。interviewee/interviewerの関係ね。話題が逸れるけど俺は書く!オススメはしません)

で、フォロワー作るときはいいとして、フォロワー削除するときのAPIにidナシとidアリじゃ違いが出るじゃんね。

DELETE /users/1/followships?followee_id=256&follower_id=1
_人人人人人人人人_
> かっこわるい <
 ̄Y^Y^Y^Y^Y^Y^Y ̄
DELETE /users/1/followships/4
_人人人人人人人_
> かっこいい <
 ̄Y^Y^Y^Y^Y^Y ̄

ActiveRecordってそもそもRailsで使うのが主目的じゃんすか。んで、Railsってウェブアプリケーションフレームワークじゃないっすか。なんで、Web APIが綺麗になるなら、データベースの領域とはいえ、一考に値すると思うんすよね。いかがか。

DCIが便利になるのはまだ時間がかかる

ぼんやりした随想であって、精密な議論ではありません。よくわからんけどよくわからんまま書くわ。あしからず。(一応付け足しとくけど、「DCIはエンドユーザのメンタルモデルを実装に落とし込むための設計パラダイム」だから云々とか言う気はないです。誰かがライブラリ作ってくれて実装に落としこむの楽になったら大歓迎です。)

DCIは今のプログラミングにおいては、そのメリットを生かし切れないように思う。というのは、今のプログラムはオブジェクトを使ったらGCに回収される、つまり、捨てるから。富豪!extendはいいとして、unextendする必要がない。現時点でもメンタルモデルの整理に役立ち、まぁまぁ生産性や保守性の向上は見込めるとは思うが、別に性能の向上に役立つ代物ではない。手法であって機能ではない。そもそもそんな主張は誰もしてないわけだが。

それはそれとして、手法から機能へ、つまり「物凄く便利」にまで評価が上昇する時が来ると思う。それは、MRAMなどの不揮発性メモリが普及した時。オブジェクトデータベースと共に猫も杓子もDCI使い出すのではないか。と思った。

不揮発性メモリ上のオブジェクトデータベースにはプレーンなオブジェクトを保存しておき、使うときにロールをextendし、役割を終えて何かアトリビュートの変更などがあった場合はunextendしてプレーンな状態で保存するって使い方。

どうか。どうだろな。適当。ぼんやり。

vim - Vimの自動保存で読み込み専用や名前がない場合に警告が出ないようにする設定

Qiitaに投稿しました。

http://qiita.com/babie/items/fa1154e2979c45fa77af

短いですが、今日のノルマはこれで。

次回予告

やっと新しいMacBook Proの環境が整ったので、バリバリ更新していきたいと思います。

さて、次回ですが、

  • pdfの漫画の余白を切り取る
  • はてなブログに予約投稿がないのでツラい

このあたりを何とかしたいと思っています。

Earthquakeで:plugin_install時にgithubネームに数字が含まれているときまずいのを直した(初めてのpull-request)

新しい13" MacBook Pro(Retina 2013 late)の環境構築しないといけないので軽く。

例えば

⚡ :plugin_install https://gist.github.com/no6v/946219

するとgithubネームの6の方が引っかかって https://gist.github.com/maddox/6 をインストールしそうになるってのを直しました。インストールするかどうか聞かれるファイル名がsick c0dezになるのでクラックされたのかと震えました。

https://github.com/jugyo/earthquake/pull/156

正規表現1個だけです。

始めてのpull-request

お恥ずかしながら、初めてpull-requestしました。プルリクしてたった8分後に取り込まれたので「これがSocial Coding……」と思いました。無言でしたので「アオ いいよね」「いい…」に通ずる侘び寂びがあると思いました。

それはそうとhubコマンド便利ですね。

$ git clone jugyo/earthquake
$ cd earthquake
$ git fork
$ git checkout -b fix-plugin_install-in-case-of-name-has-number
(ファイルを編集したり動作を確認したり)
$ git commit -m "fix :plugin_install in case of github name has numbers"
$ git push babie fix-plugin_install-in-case-of-name-has-number
$ git pull-request
(エディタが起ち上がるのでプルリクエストのタイトルと本文を編集して保存)

こんだけ。

次回予告

存在の耐えられない軽さのコミットでお茶を濁そうと思います。まだ梱包といてない。