月曜日にHeroku-jpの飲み会?に行くのでHerokuネタを。

Herokuを使うには必ず鍵が必要。ちょっと試したいって人には敷居が高いので、使い捨ての鍵作るサービスを作ってみました。

DISPOSABLE KEYS

DISPOSABLE KEYS

GENERATE KEYS押すと、

DISPOSABLE KEYS

鍵が表示される。それぞれ指定の場所に適当なエディタでファイルに保存すればいい。

ソースコード:komagata's disposable-keys at master - GitHub

私有鍵は私有するから安全なのであって、他人に作らせたら意味が無い。あくまで使い捨て用途にどうぞ。1024bit、RSA、パスフレーズ無しで、コード的には下記の2行です。

@private_key = OpenSSL::PKey::RSA.new(1024)
@public_key = @private_key.public_key

標準ライブラリでこんなに簡単に書けるとは知らなかったです・・・。

% 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ユーザーなら普通はコレやってるぜ!というのがあったら教えていただければ嬉しいです。

photo

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が回ったぐらい)

オススメっす。

おまけ

buy now!!! on Twitpic

信者乙 > 俺

プラグインの管理画面へのリンク

Lokkaでプラグインで管理画面を持った時にプラグイン一覧からリンクしてくれるようにしました。

Test Site - 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!

Double content_for

2回同じ名前で呼んでも大丈夫みたいです。便利ー。

komagata's double-content-for at master - GitHub

僕の中で曖昧だったので、ユーザー分類を元に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ユーザーにとって必須
  • 少なくとも1つ、現実的な分散環境で簡単に動くこと
    • プライベートクラウドで簡単に動くようにするということ
    • mongodbとかkumofsとかromaとかそういうの。

できれば実現したいこと

  • 本体とプラグインがgem
  • プラグインが単体でテストし易い
    • 本体のgem化が出来ればこれもできることになる

要は?

  1. ファイルのWriteしない(=クラウド対応)
  2. RDB, KVS, Document指向DBに対応
  3. zip解凍で動く
今のところこれがこのソフトの存在意義。これが出来なければ作る意味が無いので気をつけていきたい。