2014/03/11

unicode の east asian ambiguous 文字

最近、 Agda を使ったりしているので agda-mode な emacs にちょっと手を出していたりします。

Agda は π やら ∀ やらの記号を容赦なく使うので、iTerm2 では agda-mode 時に emacs の表示がおかしくなることがありました。
iTerm2 の問題かと思って Terminal に戻ってきたは良いものの、今度は ∀ とかが一文字幅になってしまって表示がおかしい。

Terminal の
Preferences -> Advanced -> Unicode East Asian Ambiguous character are wide
のチェックを入れると解決はするんだけれど、iTerm2と同じ状況になる。

どうやら Unicode East Asian Ambiguous とやらが問題らしい。

調べてみると、∀ とかが全角なのは国によるっぽい。
特に日本は全角だけれど、アメリカだと半角らしい。
国によるので幅が曖昧な文字がUnicodeにあるとか。 
それが Unicode East Asian Ambiguous みたい。

なので、Inconsolata とかの英字フォントにすると問題の記号が全部半角になって表示が正しくなる。
が、そうすると日本語がヤバそう。
私が使っているフォントは Ricty なので、日本語や記号は Migu に依存してる。
Migu は日本語フォントなので、とりあえず全てを全角に統一することにしました。

環境

  • Mac OSX Mountain Lion
  • Terminal : Version 2.3 (309)
  • iTerm2 : Build 1.0.0.20140112
  • Vim 7.4.192
  • Emacs 22.1.1 / 24.3
  • Font : Ricty

対策


iTerm2 / Terminal

East Asian Ambiguous を wide にする。

Terminal だと
Preferences -> Advanced -> Unicode East Asian Ambiguous character are wide
をチェック。

iTerm2 だと
Preferences -> Profiles -> Text -> Double-width Characters -> Treat ambiguous-width character as double width
にチェック。

Vim

set ambiwidth=double
する。というか既にしてた。

Emacs

なんか22と23で違うらしい。
emacs 22 では utf-translate-cjk-set-unicode-range を使う と良いっぽい。
23 以降では cjk が消えたらしく、別の方法があるっぽい。

んで、問題はこれら2つは完全に互換が無いこと。
22 の設定方法を 23 以降に適用すると cjk が消えちゃってる。
23 以降の設定を 22 に適用すると、 char-width-table が無いとか言われる。

加えて Mountain Lion とか Marvericks とかの emacs が 22 なのと、brew で入れられる emacs が 24 だったりでちょっとアレしたので両方に対応できる設定にしてみるなど。

設定はこんな感じ。単に emacs-major-version で場合分けしているだけだけれど。
下にコピペで使える状態な gist を置いておきます。
とりあえず 22.1.1 と 24.3 で表示の問題が無いことは確認できた。
elisp 書いたこと無いのでどこか変かもしれない。

とりあえずはこれで良いかなー、とか。
英語フォントにするなら width を single に統一すればたぶん問題無いはず。
 
ただ、iTerm2 に乗り換えた後に勘違いで Terminal に返ってきて、ちゃんと設定した結果どっちでも良いことが確認できたんだけれど、これどっち使おうかなー、ってなってたりもする。どーするかな。

んで設定コピペ用 gist は以下。

2014/03/02

沖縄Ruby会議01 へ行ってきた

沖縄Ruby会議01 へ行ってきました。

地域 Ruby 会議 in Okinawa な感じで、沖縄での初Ruby会議っぽいです。
まつもとさんご本人も呼んでわいわいやってた感じ。

実は運営陣営に地味に紛れ込んでいて、ゲストネットワークとかの設定をしていたりしました。
とかしていたらなんと開始1時間ぐらいにネットワーク全断。
まつもとさんの発表を途中で抜け出してあわあわしながら障害切り分けとかしてました。
結果的には大学全体の障害だったので、復旧を待つのみ。
待機中は割と気が気じゃない状態だった記憶が。いやある意味すげー経験なのかなこれ。

最終的には2時間ほどで復旧してもらってどうにか。どうにか……?
これってネットワーク担当だった以上はごめんなさいするのが正しいのだろうか。
ネットワーク切れちゃってごめんなさい。

障害後は、もう発表を聞くどころじゃなかったのでサテライト会場で通信状況をプチ監視してたりしました。
あとはサテライトらしくもくもくしよう、ということで作りかけの gem をいきなり公開してたりとか。
公開時は、なにやっているか分からないレベルなのでコメントしづらかっただろうなー、とか思いつつも。
やっぱりもうちょっと作り込んでから公開すると良かったかな。
けれど、バグを見つけてもらったりとかコメント貰えたりしたので良かった。
タイミングはともかく公開するべきなのだろーな、とか。
コメントくれるのありがたい。

という感じで本編は怒涛の記憶でそれしか残ってない状態。ある意味忘れられないイベントになりそう。
本編なのに割と Ruby 成分摂取量低めかもしれない。



して懇親会へ。
私が参加した中で一番賑やかな懇親会だったように思えました。
規模が大きいからなのか、Rubyな人達だからなのかは分かりませんけれど。
なんか褒められたり、シリアスなアドバイスを貰ったり、なんか業界っぽい話を聞いたり、社会人の闇っぽい話ったり、まつもとさんと写真取ったりとかわいわいしていた。

ブログを書いていて思ったのだけれど、今回のイベントだけでたくさんの人にお世話になったなー、とか思う。良い人ばかりだー。ありがとうございます。

というかもっと学生来たら良いのになー。もったいない気がする。良い人ばっかりやで。

そういえばちょっと違う話だけれど、学生が来なさすぎて ryudai.rb の残り一人になりそうなんだった。みんな来ようよ。
勉強会とかコミュニティな件でも思うところはあるなー。これから ryudai.rb どうするかとか、人をどうするかとか。とりあえず考えとこう。



とかとかいろいろな内容が混ざりながらもなんだかんだ楽しめたと思います。
#okrk01 な皆様方、ありがとうございましたー。

2014/02/21

zsh のタブ補完を定義してみる

zsh のタブ補完ってどうやってるのかなー、と思って調べてみたら思ったよりあっさり作れる様子。

発端は、rbenv は補完できるのに、 rails 補完できないなー、と思ったこと。
ということで zsh -v とかして rbenv - init の中身を見るとなんか書かれてる。
ソースの中を探せばここらへんな様子。

どうやら compctl -K ってものを使えば良いっぽい。
man zshcompctl があるので詳細はそちらで。
-K で function を指定して、それを使う command を指定すれば良いみたい。

ということで、 hoge command に対してタブ補完をする設定を書いてみたら意外とあっさり。こんな感じ。
補完用の _hoge に渡されている words の最後を look に食わせることで hoge command with 簡易スペルチェッカー のできあがり。

2014/02/16

Vimperator の hint のサイズを大きくする

Vimperator の f で出てくる hint のフォントが小さいので大きくする方法とか。

:highlight Hint
すると、Hint 関連の css っぽいものが表示されます。
コピペして、font-size を大きくして .vimperatorrc に書いておしまい。

私の設定はこんな感じ。基本的にデフォルトの値で font-size だけを 16pt に変更。

highlight Hint font-family: monospace; font-size: 16px; font-weight: bold; text-transform: uppercase; color: white; background-color: red; border-color: ButtonShadow; border-width: 0px; border-style: solid; padding: 0px 1px 0px 1px;

highlight の設定方法は
:highlight Hint font-family...
みたいに command-line menu からやっても良いので、調整しながら決まった後に .vimperatorrc に書いても良いかもしれない。:highlight Hint するとプレビューも見られるし。

2014/02/13

楽々ERDレッスン を読んだ

楽々ERDレッスン を読むなど。

DB分からないー、とか言っていたら貸してもらっていました。
借りたのは良いけれど積んでいたので、この機会に若干飛ばしながらも読み切る。

おおざっぱな感想としては
  • 業務向けっぽい
  • データベースってデータ管理フレームワークなのだな
  • どっちかというと読み物
といった感じ。

どうして業務向けかというと、データベースについての話はするのだれど、業務にとって重要かそうでないかとか、自身の経験に基づいているっぽい意見とかが多かったのでそう感じた。おそらく苦労があったのだろうな、とか。

データベースってデータ管理フレームワークなのだな、というのは当然っちゃ当然の話。だけれど、多数の言語から統一インターフェース(SQL)でアクセスできるもので、中身は高速化だのトランザクションだのって実装されている、という点からなんかフレームワークっぽいなー、とか。それを言えばファイルという存在自体フレームワークか、とか書いてて思わなくも無い。

どっちかと言うと読み物、というのは歴史とか経験とかそういった部分も解説されているから。あと、正規化手法とかそういったものは省略されていて、現場ではどうするか、という部分に重きを置いている感じがあったので。あと、2005年な本だったりするので、若干気になるところもあるけれど読み物チックなので良いかな、とか。

とゆーことで読んでて思ったことの列挙とか。若干眠いお時間なので列挙するだけで。

第1部 : DB設計総論
  • いろいろ変更とかありえるデータを想定したい、というのが念頭にあるみたい。
    • 単価が顧客によって変わるとか
    • 内部外部で呼び方が違うとか
    • そういう意味では負の遺産っぽいな、とか
      • 仕様変更や想定外の要素などが過去にあって大変だったのだろうな、とか
      • そういう意味では経験を語っている本っぽい
    • 解決手法として、リソースには unique id を振って、属性とか関連とかを柔軟に追加できるようにしようよ、って感じだったよーな
  • あとツッコミとして、コードって何やねん、ってなった
    • なんかこう、顧客コードとかっていう物体。idとは別らしい。
    • code も identifier っぽくてユニークじゃないのか、ってツッコミたかった。
    • unique でない「コード」というもの存在している、ってことなのかもしれない
第2部 : RDBMS総論
  • そもそもDBとはレポート生成システムであるとのこと
  • DBってデータマネージメントフレームワークぽいな、とか
    • データに関する処理を一元実装してしまったもの
    • 利用するための共通インターフェースがSQL
    • ストアドプロシージャ便利そう
      • プログラミング言語側でSQL組み立てがいらないので、処理もRDBMSに投げられる
      • でも使われているのか、とかって思案が。面倒そうだし。
      • ActiveRecord とか内部でSQL組みたててそうだよなー
  • RDBMSの特性を理解しようね、とか言ってるような
    • ハードウェアスペックに依存した部分もあるよ、とか
      • 正規化の遅さ速さとかって話以前にね
    • sql は batch であるとか
      • 何をするにもデータを読むためにselectしちゃうよね、とか
      • これを知らないでやるととんでも無い処理を書いちゃって遅くなるよ、とか
第3部 : 楽々ERDレッスン
  • イベント/リソース でのデータベース設計
    • イベントは 「* する」のように言えるもの
    • リソースは 5W1H的なもの
    • みたいな視点でテーブルを作ってみよう、って感じだった 

あとはなんか名言っぽかったの。
  • 「One fact in one place」 
  • 「データは蓄積することのみに意味は無く、それを元にアウトプットするための資産である」 
  • 「プログラムそのものには価値は無く、どのようにデータを扱うかが重要なのである」