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 するとプレビューも見られるし。

楽々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」 
• 「データは蓄積することのみに意味は無く、それを元にアウトプットするための資産である」 
• 「プログラムそのものには価値は無く、どのようにデータを扱うかが重要なのである」

Global Game Jam 2014 University of The Ryukyus に参加してきた

Global Game Jam 2014 University of The Ryukyus に参加してきました。

Global Game Jam は初参加だったりするのですが、オーガナイザーやったりでいろいろしてました。

参加者として

アナログゲームなチームで「バブバブブー」なる赤ちゃんなゲームを作りました。
ゲームな内容の解説はここでは一旦省略。
アナログゲーム作成も初でいろいろありました。とりあえず箇条書きで挙げてみる。

• スケジューリングは大事。集合時間とかは決めていた方が良い。
• 時間が無いので時間は気にする必要がある。1時間刻みでやるとか単位化すると見えやすいっぽい。
• 定期的にミーティングとか進捗確認とかある方が良い。それを単位ごとに作業が動いてるかとかを見ることができる。
• 切ると判断したものは容赦無く切る。時間は少ない。切ったものも紙とかに残しておくと後で使えるかも。というか全部紙で書いてて良い気がする。
• みんなでやるとたくさんアイディア出てくる。意外と被らない。
• みんなで(できる|やるべき)作業と個人単位でやる(並列可能|その人しかできない)作業がある。可能な限り並列でやりたいし、必要があれば全員は収集する。
• 作業の流れも考えてスケジューリングすると良さげ。(マイルストーン|〆切)からの逆算して考えるとか、並列に実行するにはこれを解決する必要があるとか。
• 紙に書くのは分かりやすい。とりあえず書いとこう、とか。ログに残るし共有もできる。マインドマップ、ポストイット、etc‥…
• ゲームは目的とか手段とか資源とか手番とかの視点で分解したりできる。(この分け方は一例らしいけれど)
• そういった視点を縦軸にして要素を貼っていくとこれはあれと対応する、というのが分かる。
• ゲーム的に目的重要。決めないとこれが何なのか分からないし進まない。
• 目的とか手段とかの要素が決まればルールが考えられる。
• ルールを考える上で、そのうちテストプレイが必要になる。
• プレイしてみないと分からない状態にもなるから。あとこの詳細はどう詰めるべきかの択が出てきたりするので。
• テストプレイは回数が重要。その都度フィードバックしながらテストプレイを回していく必要がある。
• やっぱり詳しい人いると捗る。
• みんなでやるといろいろできる。

まとめとしてはみんなでやると良い感じのできるんだなー 、って感じでいかがでせう。

オーガナイザーとして

イベント運営は経験少なめで、特にこれが運営した中で一番大きなイベントかもしれない。ということであわあわしたりしたのだけれど思ったこととか。

• 人の協力重要。特に今回は登録方法や運営方法を知ってる人とか、会場周りの話とかもしてくれる人がいたので非常に助かりました。ありがとうございます。
• 人がいない部分(ネットで連絡が回ってきて自分でやってね、みたいなもの)は結構検証必要。特にそれだけの情報で重要なことをする時。例としてはテーマ発表の方法は聞いていたけれど実際にリハーサルしてなくて、本番の時に若干焦ることになった。たぶん事前に一回やっておいた方が良かったのだと思う。
• アンケートとか意外と反応無かったりする。アンケートに限らず、参加者が想定外の行動をした時の予防線とかはあった方が良いのかもしれない。
• バックアップ大事。人間的な意味。重要な情報を持ってる人間が一人だとその人がいない時に何もできなくなりかねない。
• バックアップ大事。ログ的な意味。フィードバック必要だし、重要な情報の共有とかの意味合いでもログをちゃんと書いて公開すると良さげかもしれない。
• ある程度先は野となれ山となれ。なんかトラブル含めて Game Jam らしいです。

とかとか。

なんだかんだ会場では2チームでゲームは2つできましたし、深刻なトラブルも無かったと思ってるので良かったのかなー、とかとか。そんなこと無いよ、とか良くも悪くもフィードバックお待ちしております。

参加してくれたみなさん、協力してくれたみなさん、改めてありがとうござました。

NeoBundle の NeoBundleLazy したプラグインをファイル名指定で autoload する

前回、 Processing なファイルを Vim で扱いやすいようにしたのですが、プラグイン導入には NeoBundle を使いました。
NeoBundle には Lazy Load 機能があって、プラグイン必要な時にロードすることができます。
その設定には特定の command が実行された時に load したり、 filetype によって load したりすることができます。
しかし、 Processing な filetype が Vim に無く、そもそも Processing 用の filetype を追加するためのプラグインが vim-processing でした。

なので、これを Lazy 化した後に必要な時のみ load する案として、

• NeoBundle では NeoBundleLazy するだけ
• autocmd で BufRead や BufNewfile の時のみ NeoBundleSource する

という方式で前回は Lazy Load していました。

そこで「filetype が無いファイルのために、拡張子ごとに autoload する設定とかが NeoBundle に無いかなー」とかつぶやいて寝て起きると実装されていました。暗黒美夢王さんすごい。

autoload に  filename_patterns というものが指定できるようになりました。
ファイル名の正規表現 もしくは 正規表現のリストを指定することにより、このファイルを編集した時に autoload してくれるようになります。

ということで、前回の *.pde を開いた時に vim-processing を load する、という設定が

NeoBundleLazy 'sophacles/vim-processing'
augroup Processing
    autocmd!
    autocmd BufNewFile *.pde NeoBundleSource vim-processing
    autocmd BufRead    *.pde NeoBundleSource vim-processing
augroup END

から

NeoBundleLazy 'sophacles/vim-processing' , {'autoload' : {'filename_patterns' : '.*\.pde'}}

に。
行も減ったし augroup も減ったので良い感じ。

あと、正規表現に対応しているのでオレオレファイルを開いた時に autoload とか、独自拡張子とかにも対応できそうです。

暗黒美夢王こと@ShougoMatsuさん、ありがとうございますー。

Processing を Vim から使う

Processing を使うことになったのですが、Vim に Processing な filetype は無い様子。

vim-processing という plugin があるらしく、それで filetype 検出や syntax highlighting はやってくれるみたいです。
加えて設定をすると、 quickrun から実行できるようなので設定など。


ということで以下の設定 .vimrc に追加してプラグインを入れる。

NeoBundleLazy 'sophacles/vim-processing'
augroup Processing
    autocmd!
    autocmd BufNewFile *.pde NeoBundleSource vim-processing
    autocmd BufRead    *.pde NeoBundleSource vim-processing
augroup END

これで *.pde を開くときちんと syntax highlighting されます。
あと、quickrun の設定で

let g:quickrun_config.processing = {
\     'command': 'processing-java',
\     'exec': '%c --sketch=%s:p:h/ --output=/tmp/processing --run --force' }

も追加。

これで quickrun から processing-java というコマンドで processing を実行できます。

processing-java のインストールは参考サイトにあるように、

Processing の Menu -> Tools -> Install "Processing-java"

で可能です。
インストールすると Command Line から processing を呼べるようになります。

ちなみに使い方は

--sketch で sketch のディレクトリ指定
--output で出力先を指定

するようです。

sketch は hoge/hoge.pde みたいなディレクトリ構成になってないといけないようで、 --sketch ではディレクトリごと指定してやる必要があるみたいです。
なので %s:p:h を使ってディレクトリを指定。
%s は quickrun の symbol で file name です。
:p:h はファイル名を絶対パス化した上でディレクトリのみを抜きだす、というもの。
filename-modifiers とかいうものらしく、 quickrun の document に You can use filename-modifiers for the symbols. って書かれてました。
:p:h の詳しい解説は :h filename-modifiers を見た方が早いはず。
ちなみに write してない buffer は名前の関係で quickrun できません。

あと --output は無難なところで /tmp に変更。

そんなこんなで、 processing な sytaxhighlighting + quickrun で実行できるようになりました。