2012年4月24日火曜日

Kinesis KB700PB-us エルゴノミクスキーボード

腱鞘炎になってからキーボードはエルゴノミクスを使っている。
これで治るわけではないが、手が楽になるので気に入っている。


最近はKinesisのKB700PB-usという、二つに分かれるキーボードを購入した。(右はアフィリエイトリンク)。

日本では手に入りにくいエルゴノミクスな英語キーボード。

ちゃんとしたフルキーボードで、
ファンクションキーもあるし、
レイアウトも比較的普通で使いやすい。

キーの感触も悪くない。
値段を考えるとPFUのハッピーハッキングぐらいは期待したけど、まぁ十分かな。

そしてテンキーがない。
これも大事だと思う。



エルゴノミクスというと、こんなすごいキーボードがある。

自分では使ったことはないけど、昔の同僚が腱鞘炎になったときに、これを使っていた。

これが「使いにくい」らしい。

なんでも「わざと」使いにくくなっているらしい。ゆっくりとしかタイプできないので、腱鞘炎がよくなるとか。

そこまで腱鞘炎がひどいわけではないので、今ので十分と思う。




この前までは、マイクロソフトのカーブしたキーボードを使っていた(右上)。

これでも十分にエルゴノミクスだったと思う。ひどい腱鞘炎にはならなかったし、タイプもしやすい。

ただ日本語配列だったのとテンキーが邪魔に思っていて、新しいキーボードが欲しくなった。

下のは英語キーボードと勘違いして買ってしまったBluetoothキーボード。

これもカーブしていているが、最初はキーの配置が使いづらくてとまどった。慣れの問題と思うが、なれる前にKinesisのキーボードを買ってしまったので分からない。

ほんのちょっと、斜めに打てるだけで、手が楽になるので
エルゴノミクスキーボードを気に入っているのだけど、
あまり選べる種類がないのが痛い。

2012年4月20日金曜日

もっと早くUbuntu+PHPStormの開発環境にすればよかった

ちょっと感動したので、書いてみます。

Ubuntuにしてから1ヶ月ほど。
あまりPHPStormを使う機会がなかったのですが、先ほどデバッグ環境を設定しました。
あまりに簡単で書くことにしました。

なお、ローカルでApache2を動かしているという前提です。

PHPStorm

PHPの開発環境として、PHPStormは最強だと思います。
何が最強か上手に指摘できないのですが、意外と軽いわりに機能が豊富。かゆいところに手が届く、といった感じです。そしてデバッガーがちゃんと動きます。今までEclipse+PDTやNetBeans使ったことはありますが、設定に偉い苦労して、やっと動いたと思ったら次の日になると動かないとか、そんなことが多かった気がします。

一度、PHPStormを使ったら、ヘビーな開発は
PHPStormを使う以外は考えられません。

もっともお仕事の作業ではDreamWeaverも捨てがたく。
仕事だとライブラリやらフレームワークをいじくることはほとんどなくて、逆にHTMLやらフロントをいじくることが多いのでHTML←→ソースビューを行き来できるDreamWeaverは便利だと思います。

xdebug

そもそも過去デバッグが動かなかった原因は、xdebugかもしれません。
Windowsのバージョンにバグが多いのか、だいたい正しいdllを選ばないと動きません。
が、Ubuntuでxdebugインストールするのはとても簡単。

Ubuntuソフトウェアセンターでxdebugを検索、
インストールボタンを押したらインストール完了。
アパッチをリスタートして、xdebugが動いてました。

コマンドで言えば(多分)
sudo apt-get install xdebug
sudo service apache2 restart
で終了。

php.iniの修正

さすがに、これだけでデバッガーは動きませんでした。
ここのPHPStorm用xdebugの設定を見ながらphp.iniを修正。

ターミナルから
sudo vi /etc/php5/apache2/conf.d/xdebug.ini

を開いて(一行しか入ってないや)、
そして以下のように修正。


[XDebug]
  zend_extension=/usr/lib/php5/20090626/xdebug.so
  xdebug.remote_enable=1
  xdebug.remote_port=9000
  xdebug.profiler_enable=1
  xdebug.profiler_output_dir=/tmp/

アパッチをリスタートして、phpinfoでxdebugが動いているのを確認。

PHPStormの設定

最後はここの「何の設定なしでxdebugとPHPStorm2でデバッグ」という少々誇張されたタイトルに書いてあるとおりに設定します。

xdebug用のブックマークを作ること。

個人的には「Start debugger」と「Stop debugger」だけブックマークを作って、デバッグを始めるときにブックマークを押します。

そしてPHPStormでは「赤い電話機アイコン」を押して緑色に変わればOK。
ブラウザーをリフレッシュすると、PHPStormでデバッグが開始されます。

path mapping

以上で、動くと思うのですが・・・
たまに「path mapping」を設定してください、といわれます。

どうも、PHPStormがデバッグするには、xdebugからデバッグ中のファイル名を受け取っているようなのですが、ときどきファイルがどれか混乱するようです。

同じファイル名がある場合など、どのファイルをデバッグするか聞いてくることがありますので、適宜選択してあげるとデバッグが始まります。

So, Happy debugging with PHPStorm!

高解像度の27インチモニターが安くなってきている

アマゾンをウィンドウショッピングしていたら、
高解像度の27インチモニターが安くなっていた。

普通の27インチモニターは、これ以上安くならないだろうと思えるぐらいに安い。
大体2~3万円で27インチの大画面が手に入る。

ただし、解像度は1920×1080という「俗に言うフルHD」
作業するには、もう少し解像度が欲しい。

ひとつ上の解像度で27インチを買おうと思うと、
ちょっと前まで、10万円以上していた。

それが6万円にまで下がっていた。
ほ、欲しい。
でも、去年~今年と散財したからなぁ。

心を落ち着かせる為にDPIを計算してみた。

Monitor        横    縦  インチ  DPI
-----------------------------------
NANAO 21     1600  1200  21    95.2
FullHD 27    1920  1080  27    81.6 
MoreHD 27    2560  1440  27   108.8 

Nanaoというのが今使っているディスプレー。
もう6~7年ぐらい使っている。

ちなみに右がちょっと前の作業環境。モニター3台あるけど、使っているのは左の2台だけ。

この右にある古い19インチを27インチモニターにしたいのだけど、フルHDだと解像度が落ちるので、気が乗らない。
でも、一つ上の解像度ならいい感じだ。

もっとも、アップルのiPadに使われるレティーナディスプレーが300dpiぐらい、それより大きなMacだと200dpiを目指しているというから、まだ半分ぐらいの解像度しかないのか・・・

この春のアップルの発表待ちだな。

下はアフィリエイトリンク。
今のところ、この2機種だけのようです。


2012年4月16日月曜日

PostgreSQLのinitdbと違うロケールでDB作成

Ubuntu上にPostgreSQLをインストールして、
phpPgAdminでログインして、EUC-JPでDBを作成しようとしたら、
ERROR: encoding EUC_JP does not match locale ja_JP.UTF-8

と言われた。
SQL文はこんな感じ。
CREATE DATABASE "example" WITH TEMPLATE="template1" ENCODING='EUC_JP'
古いDBをテストするために、EUC-JPでDBを作成する必要がある。
どうやら、initdbの文字コードと違う文字コードでDB作成できないらしい。検索してみると、結構な書き込みを見つけたので、かなりFAQな問題らしい。

ただし、initdbからやり直すという面倒な方法しか見つからない。

色々探して、initdbの文字コードと違う文字コードでDB作成を見つけて
簡単な解決をやっと発見。

要するに、
CREATE DATABASE "example" WITH
TEMPLATE="template0" ENCODING='EUC_JP'
LC_COLLATE='C' LC_CTYPE='C';
とSQLを発行することで解決した。

ポイントは
1)template0を使うこと。
2)LC_CTYPEをCで指定すること。
の2つだけ。
これでUTF-8でinitdbしていてもEUC-JPでDBが作成できる。

◆ただし、もう一つ、この作業の前に行ったことがある。

先に、こんなページを見つけていた。
PostgreSQL 9.1 installation and database encoding

つまり、OSでサポートされるロケールでなければいけないらしい。

Ubuntuでja_JP.EUC-JPを使用するを参考に調べたところ、
今のUbuntuにはEUC-JPが入っていなかった。

そこで、ja_JP.EUC-JPというロケールをOSにインストールしてから
上記のCREATE DATABASEコマンドを発行している。

どんな順序で動くかはテストしてないので、メモということで。



2012年4月2日月曜日

Chrome: Your Profile Could Not Be Opened Correctly [solved]

Took me more than a week to figure this out...

Problem: 

When using Chrome's sync function using Google's account, Chrome does not shutdown gracefuly, leaving zombie process in Ubuntu OS.

The zombie process, somehow, prevents Chrome to load account data, and reports,
Your profile could not be opened correctly...
When this happens, Chrome fails to load any of the password, cookies, from the past history, even if it is on the local data. This is very annoying.

Find out the cause:

After Googled around, found out how to kill the zombie process:
pkill -9 chrome

Then, found Chrome's history data is causing this, so removing it should help:
rm -rf .config/google-chrome/Default/History*
These worked fine, but when Chrome synchronize the account, the History data came back, and the problem occurs again.

To summarize the situation,
some bad data in History is the cause of this problem,
and the bad data is in the Google Sync (up somewhere),
so Chrome sync always downloads the bad data. 

OK, the solution is
to erase the bad data from Google account.

I tried to erase the sync'ed data from Chrome's Preference menu. But nothing  worked. So, I dived into the Google's maze of account setting pages...

This worked for me:

0) disconnect from Google Account.

Not sure if this is necessary, but I was disconnected when I did the following.

1) login to Google Account Setting. 

I used this url to get into my account setting.
https://www.google.com/settings/

no link, I found so far. 

2) turn off the Google Sync

From the account setting page, click on "Profile and privacy". 
then, scroll down to "Sign in to Dashboard" and click.
find "Chrome Sync", and click on "Stop sync and delete data from Google" or something 
(well I'm a Japanese, and I changed the language to English to write this entry. But this page was still in Japanese. so I cannot be sure how the link is written in English.)
wait for a few minutes according to the message. 

3) delete web history

From the account setting page, click on "Go to web history".
Click on "Remove all Web History", and clicked just yes to whatever the question was. 

4) start Chrome and synchronization

and it worked for me!


The Google account pages were just like a maze. 
So, many of the above may change at anytime. But I hope that this list gives some clue about this problem. 

[additional note: 2012/04/20]

The same problem happened again, about two weeks after I wrote this blog entry. So, I stopped syncing 'address bar history', and the problem went away (for now). 

2012年2月25日土曜日

Simple@高円寺(2012/02/25)

高円寺でSimple勉強会。
今回は人数少なめ。おいしいカキフライ弁当で腹ごしらえして
黙々と作業開始。

◆AmidaMVCという名前について。
多分、MVCは使っていない。

だいたいMVCが分かっていない。


◆最初は1月で開発をやめるつもりだったが、面白いので2月も続けてしまった。で、フレームワークからCMSになりつつある。FWとCMSの違いって何だろう?

◆今はMarkdownを使ったPukiwikiみたい。
これでdiffも出来るようになったし、ほぼ機能はそろった?
自動で登録したファイルを一覧するのが足りないか。

twitterのbootstrap使ってみた。
最初は戸惑ったが、ちょっと触れば簡単。jQuery Mobileのようにマークアップだけでボタンの色・形、そしてモーダルの動きを指定できる。というかクラスを指定すればOK。クラス名だけ調べれば簡単。
ただ途中でbootstrap使い始めたので、競合が起きて面倒だった。

simplediffというPHPのテキストdiffツールを使ってみた。
Pearを試したが、ウォーニングばかりで動かなかったので、こちらを試したら一発で動いた。遅いらしいが、ま速度を気にする段階ではないので。動く方が大事でしょう。

◆アミダ式チェーンは、
開発はしやすい。
ただ、次のチェーンを理解する必要がある。
ので、あまり長くアクションを使い回すのはよくないかも。

◆コンポーネントは汎用性を高くするのは難しい。
CMSごとのコンポーネント群を作って管理するがあるかも。
例:ルーター・管理者機能なし、ファイルの閲覧のみのCMS。

◆自分のコーディングスキルに絶望、まではしないが、残念な気持ちになった。

2012年2月3日金曜日

AmidaMVC:設計方針を決める

さてコントローラーのアミダ式チェーンが出来たので、
今度は中身のフレームワーク。

HTTPのリクエストはコントローラーが受け取り、
コンポーネントを次々と実行する。

で、コンポーネントで何をするか?
まずは、
  1. リクエストから読み込むファイルを探して、
  2. ファイルを読み込んで、
  3. テンプレートに流し込んで、出力。
これが最低必要な流れでしょう。
それぞれ、Router、Loader、そしてRenderという名前のコンポーネントを開発することにしました。
試してませんが、今でもこの3つのコンポーネントだけで動くんじゃないかな?

Router

コントローラーからpath_infoを読み込む。
単純に最後のパスがファイル名で、残りがフォルダー名。
で、探し出せればLoaderにファイル情報を渡す。 
今はルートマップから探索できるようになりました。どちらの方法でもファイルが見つから無ければPageNotFoundにアクションを変更。 

Loader

ファイル情報からファイルの中身を読み込む。
拡張子から中身の種別を判断(HTML、markdown、テキスト、PHPのソースコード)したうえで読み込む。
PageNotFoundの場合は、前もって決めておいたファイルを読み込む。最初、ファイルはLoader内に直書きしてたが、今は設定コンポーネント(Config)で設定するよう変更済み。ファイルが正常に読み込めれば、アクションをデフォルトに戻してRenderに処理を渡す。

Render

中身の種別により、マークダウンならHTMLに、テキストならnl2brとhtmlspecialcharsをかけて、PHPならソースコードハイライトして、と前処理を行う。

それから中身のデータをテンプレートに流し込む。
とにかく簡単に。単なるPHPをインクルードするだけ。

◆$siteObj

コンポーネントで色んなデータを扱う必要があるので、必要な情報は全部このオブジェクトにぶち込んで、コンポーネント間で持ち回します。デザインパターンで言えばData Transfer Objectですな。

◆Toolsフォルダー

コンポーネントが行う実際の処理はここに書く。
コンポーネントは、処理を行うルーチンを呼び出すのが仕事。

こういう汎用的なルーチンは再発明しても仕方ないので、出来るだけ自分で書かないのが方針。実際、『パーフェクトPHP』のフレームワークの章から、ほとんどのコードを書き写しました。とても参考になったいい本だと思います。

理想はsymfonyなどのフレームワークのライブラリを再利用できるといいな。

◆以上、簡潔に方針をまとめると
・コントローラーは単純に、
・コンポーネントは薄く、
・ツールは汎用的かつコピペで書く、
のが開発方針です。