zsh のタブ補完ってどうやってるのかなー、と思って調べてみたら思ったよりあっさり作れる様子。
発端は、rbenv は補完できるのに、 rails 補完できないなー、と思ったこと。
ということで zsh -v とかして rbenv - init の中身を見るとなんか書かれてる。
ソースの中を探せばここらへんな様子。
どうやら compctl -K ってものを使えば良いっぽい。
man zshcompctl があるので詳細はそちらで。
-K で function を指定して、それを使う command を指定すれば良いみたい。
ということで、 hoge command に対してタブ補完をする設定を書いてみたら意外とあっさり。こんな感じ。
補完用の _hoge に渡されている words の最後を look に食わせることで hoge command with 簡易スペルチェッカー のできあがり。
2014/02/21
2014/02/16
Vimperator の hint のサイズを大きくする
Vimperator の f で出てくる hint のフォントが小さいので大きくする方法とか。
コピペして、font-size を大きくして .vimperatorrc に書いておしまい。
私の設定はこんな感じ。基本的にデフォルトの値で font-size だけを 16pt に変更。
highlight の設定方法は
: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設計総論
DB分からないー、とか言っていたら貸してもらっていました。
借りたのは良いけれど積んでいたので、この機会に若干飛ばしながらも読み切る。
おおざっぱな感想としては
- 業務向けっぽい
- データベースってデータ管理フレームワークなのだな
- どっちかというと読み物
どうして業務向けかというと、データベースについての話はするのだれど、業務にとって重要かそうでないかとか、自身の経験に基づいているっぽい意見とかが多かったのでそう感じた。おそらく苦労があったのだろうな、とか。
データベースってデータ管理フレームワークなのだな、というのは当然っちゃ当然の話。だけれど、多数の言語から統一インターフェース(SQL)でアクセスできるもので、中身は高速化だのトランザクションだのって実装されている、という点からなんかフレームワークっぽいなー、とか。それを言えばファイルという存在自体フレームワークか、とか書いてて思わなくも無い。
どっちかと言うと読み物、というのは歴史とか経験とかそういった部分も解説されているから。あと、正規化手法とかそういったものは省略されていて、現場ではどうするか、という部分に重きを置いている感じがあったので。あと、2005年な本だったりするので、若干気になるところもあるけれど読み物チックなので良いかな、とか。
とゆーことで読んでて思ったことの列挙とか。若干眠いお時間なので列挙するだけで。
第1部 : DB設計総論
- いろいろ変更とかありえるデータを想定したい、というのが念頭にあるみたい。
- 単価が顧客によって変わるとか
- 内部外部で呼び方が違うとか
- そういう意味では負の遺産っぽいな、とか
- 仕様変更や想定外の要素などが過去にあって大変だったのだろうな、とか
- そういう意味では経験を語っている本っぽい
- 解決手法として、リソースには unique id を振って、属性とか関連とかを柔軟に追加できるようにしようよ、って感じだったよーな
- あとツッコミとして、コードって何やねん、ってなった
- なんかこう、顧客コードとかっていう物体。idとは別らしい。
- code も identifier っぽくてユニークじゃないのか、ってツッコミたかった。
- unique でない「コード」というもの存在している、ってことなのかもしれない
- そもそもDBとはレポート生成システムであるとのこと
- DBってデータマネージメントフレームワークぽいな、とか
- データに関する処理を一元実装してしまったもの
- 利用するための共通インターフェースがSQL
- ストアドプロシージャ便利そう
- プログラミング言語側でSQL組み立てがいらないので、処理もRDBMSに投げられる
- でも使われているのか、とかって思案が。面倒そうだし。
- ActiveRecord とか内部でSQL組みたててそうだよなー
- RDBMSの特性を理解しようね、とか言ってるような
- ハードウェアスペックに依存した部分もあるよ、とか
- 正規化の遅さ速さとかって話以前にね
- sql は batch であるとか
- 何をするにもデータを読むためにselectしちゃうよね、とか
- これを知らないでやるととんでも無い処理を書いちゃって遅くなるよ、とか
- ハードウェアスペックに依存した部分もあるよ、とか
- イベント/リソース でのデータベース設計
- イベントは 「* する」のように言えるもの
- リソースは 5W1H的なもの
- みたいな視点でテーブルを作ってみよう、って感じだった
- 「One fact in one place」
- 「データは蓄積することのみに意味は無く、それを元にアウトプットするための資産である」
- 「プログラムそのものには価値は無く、どのようにデータを扱うかが重要なのである」
登録:
投稿 (Atom)