% irb -rrubygems
>> require 'rack'
=> true
>> Rack::Mime::MIME_TYPES['.csv']
=> "text/csv"
ここにある。
疑問
「忙しい」ことを誇らしげに吹聴する人（ミサワ）と、恥として黙っている人（非ミサワ）がいる。これらは正反対の反応である。何故だろう。
仮定
両者の違いは職能に「スケジューリング」が含まれているかどうかによって生じる。
理由
「忙しい」とは「スケジューリング」が機能していない状態のことである。（職務の果たす役割という意味での）職能にスケジューリングが含まれる職業・役職（管理職等）において「忙しい」とはイコール任務遂行能力の欠如である。
職能にスケジューリングが含まれない職業・役職（作業者等）において「忙しい」とは想定以上に自らの職能が必要とされている状態である。
後者は思春期においては、自己承認欲求を良く満たすため、露骨に発露する。前者においては自己の思春期の未熟さへの嫌悪が「忙しさ」への嫌悪に直結する。
関連
pluginの事を考えるとbeforeが複数回定義されてもちゃんとそれぞれが実行されないと意味が無い。なので試してみた。
komagata's double_before at master - GitHub
require 'rubygems'
require 'sinatra'
before do
@name = 'Masaki'
end
before do
@name += ' Komagata'
end
get '/' do
"Hello, #{@name}"
end
require 'rubygems'
require 'test/unit'
require 'rack/test'
require 'shoulda'
require './double_before'
class DoubleBeforeTest < Test::Unit::TestCase
include Rack::Test::Methods
def app
Sinatra::Application
end
context "Access pages" do
should "show index" do
get '/'
assert_equal 'Hello, Masaki Komagata', last_response.body
end
end
end% ruby double_before_test.rb
Loaded suite double_before_test
Started
.
Finished in 0.030489 seconds.
1 tests, 1 assertions, 0 failures, 0 errorsおお、問題無い！これは期待してなかったので嬉しいですゾ！(＠ムック)
明日土曜日・日曜、待ちに待った大イベント、Lokkathon #1が開催されます。気になる開催概要は下記です。
Lokkathon #1
- 日時 / DATE: 2010/11/20 10:00 to 19:00
- 定員 / LIMIT: 俺
- 会場 / PLACE: FJORD, LLC
- URL / URL: http://fjord.jp/
- 内容 / DESCRIPTION: Lokka本体・プラグイン・テーマを作る。
ああ、そうだよ。思いつきだよ。ダジャレだよ。
「どうせ大して変わらねえだろう」
という軽い気持ちでUSキーボードのパソコンを買ったんですが、違いの大きさに苦戦中です。USキーボードとvimについて現在の疑問を羅列してみました。
日本語変換キー
USキーボードではCmd+Spaceが日本語変換キーです。これは配置からいってどうにも押しづらい。KeyRemap4MacBookのCommand_R to Command_R(+ When you type Command_R only, send Command+Space)で右Cmdに割り当ててみましたが、コレ、完全に他のキーを押してない状態で右Cmdを押さないといけないのでかなり使い辛いです。普通みなさん何に割り当ててるんでしょうか？
vimのコロン
USキーボードではコロンはShiftを押す必要があります。vimで使いまくりのコロンが両手必須というのは厳しい。
noremap ; :
noremap : ;という設定を教わって便利になりましたが、普通どうやってるんでしょうか？
他にもUSキーボード、vimユーザーなら普通はコレやってるぜ！というのがあったら教えていただければ嬉しいです。
MacBook Airの11-inch買いました。
Apple Store Ginzaで
「11-inch USキーボードで一番良いのを頼む」
しました。(これまでは非Proの最初のユニボディMacBook)
量販店と違って、Apple Storeにはカスタマイズ済みのモノを在庫として持ってるそうで、店頭でその場で買えます。(発売当初は無かった)
そもそも僕にとってノートパソコンの最適サイズはこのぐらいなので13-inchはデカかったんですが、PowerBook以来、小さいのが出る様子が全くなかったので「アメリカさんは小さいのなんて要らないんや」と諦めてました。
スペックについてはこれまでのMacBookでもメモリ3GBでスワップすることは殆ど無かったし、CPUが遅いと感じることも無かったのであまり変わらない感じです。ディスクアクセスが必要な場面で速いぐらいです。HDDも以前のMacBookでも128GB以上使ってなかったので特に意識しないで使ってます。
使うアプリがFirefoxとTerminal(今は仕事でXcode)ぐらいなのでWeb系プログラマーはあまりスペックを必要としない人種なのかもしれませんな。(brew install mysqlしたときにFANが回ったぐらい)
オススメっす。
おまけ
信者乙 ＞ 俺
プラグインの管理画面へのリンク
Lokkaでプラグインで管理画面を持った時にプラグイン一覧からリンクしてくれるようにしました。
最初はプラグイン内でhave_admin_page(acts_as_fooみたいなの)を宣言するようにしてたんですが、頑張って、
Lokka側から "/admin/plugins/#{プラグイン名}"のページがプラグインに存在したらリンクを貼る。
というようにしました。
管理画面左メニューへの追加
また、管理画面の左メニューの一番下にyield_content :admin_menuというプラグインから挿入できるポイントを入れときました。複数回呼べるみたいなので、色んなプラグインから挿入されても大丈夫ですね。(順番はプラグインの読み込まれる順)
まだ、プラグイン内で管理画面作った場合の認証入れてないんですが、sinatra1.1のパス指定beforeを使えるようにしてからの方がいいかなと・・・。
テーマの方にもheader, footerという挿入できるポイントを入れようと思ってます。(全テーマ修正がだるい・・・)
- content_for :foo do
%p One
- content_for :foo do
%p Two
%h1 Hello, World!
2回同じ名前で呼んでも大丈夫みたいです。便利ー。
僕の中で曖昧だったので、ユーザー分類を元にLokkaの開発方針をまとめてみました。
ユーザー分類
- 閲覧者(visiter)
- ブログを見に来る人
- 投稿者(author)
- ブログにエントリーを投稿する人
- 管理者(administrator)
- ブログを設置し、管理する人
- 開発者(developer/designer)
- プラグイン・テーマを作る人
- コミッタ(commiter)
- 本体を作る人
上(人数が多い)、下(人数が少ない)
上(影響が少ない)、下(影響が大きい)
ユーザー分類補足
- 閲覧者
- fc2とwordpressの見た目が殆ど付かない現状、閲覧者にとってはどのツールも違いがない。
- 投稿者
- ブログの体裁を取っていれば殆どの投稿者にとっては最低限投稿することは出来る模様。UI改善の余地は多少あり
- 管理者
- インストールの敷居がまだ高い
- 職業Webデザイナーが多い
- ローカルで開発するデザイナーは殆どいないらしい
（Apache + MySQL or XAMPが必要等、敷居が高いため） - CMS/Blogツール導入の権限はココに該当する人にある。
- どれだけ管理者に好かれるツールであるかが最も重要。
- 開発者
- 上記管理者に好かれるツールになるかどうかは開発者の充実にかかっている。
- テーマはデザイナー、プラグインはプログラマーが主に作ることを意識する必要がある。
- コミッタ
- コア内部よりも上記開発者に触れる部分をどれだけ簡単でクリーンに出来るかが重要だと思われる。コミッタはそれ程大勢になるわけではないので開発者への奉仕に注力する必要がある。
- フルタイムのコミッタがいるプロジェクトは成功率が高いらしい
どんなソフトウェアを目指すのか？(スローガン)
- CMS for Cloud
- クラウド環境で良く動く
- 打倒WordPress
- 協調や補完では無く打倒。
- WordPressを置き換えるモノで無くてはならない。つまり現状のWordPressユーザーが置き換えたくなる機能が必要。
必ず実現したいこと
- デフォルトでHeroku(or GAE)で良く動くこと
- ファイルのWriteや大量DB消費があってはならない
- Windows, Mac, Linuxでzipを解凍すれば動くこと
- デザイナーがローカル環境で作業するのに必須
- zipを解凍してフォルダに置くだけでプラグインが動くこと
- WordPressユーザーにとって必須
- 少なくとも１つ、現実的な分散環境で簡単に動くこと
- プライベートクラウドで簡単に動くようにするということ
- mongodbとかkumofsとかromaとかそういうの。
できれば実現したいこと
- 本体とプラグインがgem
- プラグインが単体でテストし易い
- 本体のgem化が出来ればこれもできることになる
要は？
- ファイルのWriteしない(=クラウド対応)
- RDB, KVS, Document指向DBに対応
- zip解凍で動く
@nkmrshnさんの素晴らしいまとめ。Optionを使ってるコードとかまだ他で見たことないので素敵ですｗ
作成したLokkaプラグインのまとめ - nkmrshnの日記
- プラグインで使用するgemを、Gemfileと別にプラグイン側で管理する方法。（現状:Lokka本体のGemfileに書くしかない。）
- プラグインで使用するi18nのen/ja.yml。（現状:Lokka保体のen/ja.ymlに追記するしかない。）
- プラグインの読み込む順番。（現状:読み込む順番を設定できない。）
- プラグインの有効・無効。（現状:public/plugin/lokka-＜プラグイン名＞は全部有効。）
- プラグインのアップロード・削除機能。（現状:ターミナルのコマンドなどでプラグインファイルを追加・削除する必要がある。）
- public/admin/layout.hamlのdiv#aside（左側サイドメニュー）にプラグインのメニュー項目を追加。（現状:layout.hamlに追記するしかない。）
コメント欄に書いたらエラー？が出たのでココに書きます。（以下俺）
おおお、すばらしいまとめありがとうございます！
最後の6点は僕もどう本体を実装すべきか悩んでおります。
- C拡張を含むメジャーなgemは本体に同伴し、pluginで必要な(Pure Rubyの)gemはpluginに同伴してもらう？
- 頑張ればplugin毎のi18nを読み込める？拙作のdm-validations-i18nとあわせて対応できるか？r18nの利用を継続するか？
- railsのようにルールさえ明確ならば指定出来る必要は無い？
- DBで管理すれば可能だがWordPressであんまり必要性を感じてないので検討中。
- 実装方法が思いつかない・・・(基本WRITE出来ない環境を想定してるので現状でいいかも？)
- やり方を決めればいいだけなんですが、選択肢が有り過ぎてしっくりくる方法を思いついていない。文字列とリンクURLの構造体を持つ？xxxxx.{erb,haml,erubis}があったらそれを表示する？
という感じです。
やっぱりプラグインを書いてみた人本人でないとわからない点が沢山あるとおもいますので、「こうしたほうがいい」というところがあればお教えいただけると嬉しいです！