CAPSLOCKがなぜ不要か

日本でも日々高まりつつあるcapslock不要論について、私からも意見を呈したいと思います。

使用頻度が少なすぎる

CAPSLOCKはONにすると、すべての入力が大文字になります。
この機能は大変便利な機能なように見えますが、なかなか使い道がありません。

英語で論文を書く場合などは必要に思えます。
しかし、ほとんどの場合はcapslock キーを押すまでもなく、shiftキーに小指が伸びているのが現状ではないでしょうか?

使用頻度に比べて押しやすい位置にありすぎる

capslockはキーボード上でかなり押しやすい位置にあります。
「a」を押そうとしたら、capslockを押していた。知らない間に大文字入力しかできなくなっていたなんてこと皆さんも有るはずです。
本当にユーザーエクスピエリエンスを害しています。

誤打した場合の影響範囲が大きすぎる

これはvimの場合ですが、大文字と小文字で全く違うコマンドが入力されるような、危険極まりない使い手を選ぶアプリケーションもあります。

そんな文字入力の基本部分を根底から覆すようなアプリはあるべきではありません。

capslockへの傾向と対策

capslockキーを無効にする/ctrlキーと場所を入れ替える

恐らくほとんどの人がcapslockよりも使用していると思われるctrlキーと場所を入れ替えるという対策は最もよくある対策です。

macの場合は、日本語キーボードの場合は既に良しなな場所へと変更してくれています。
英語キーボードの場合は残念ながら、「a」の横を陣取っています。
ただしデフォルトでappleはこの場所を入れ替える機能を用意してくれています。

素晴らしい。

windowsの場合はレジストリを変更するか、キーマッピングソフトを使用する必要があります。
面倒くさいので、キーボード側で切り替え機能を持っているのがオススメです。

capslock を誤打したことを認識できるようにする

macはcapslock がオンの場合小さくキーボードが点灯してくれます。多少マシなエクスピエリエンスです。

ただ、文字入力に集中しているときに誤打したことになど気づきません。
だって、capslock が光ったところでcapslock なんて見てませんから。

アプリケーション側で「お前今押したぞ!」と言ってくれるものを入れてしまうのはどうでしょうか?

windowsの場合
http://blog.layer8.sh/ja/2011/10/21/keyboard-leds/

macの場合
http://veadardiary.blog29.fc2.com/blog-entry-2658.html

やりたいことをやらねばならないという矛盾

人間誰しもやりたいことをやって生きていきたいものです。

しかしながら、やりたいことをやらねばならない という矛盾に苦しめられている人が多い気がする。

やりたいことをやること、それは本当に素晴らしいことです。

なんの否定もしませんし、割と僕もやりたいことやって生きてる方です。

もう遠い過去の話になりますが、ある分野で僕も日本で何番で居たことがあります。

どんな分野でもある程度高いレベルで戦うには、そのことが好きだということが多くを占めることでしょう。

もちろんやりたいからやっていたのですが、それと結果は無関係に思えます。

僕より嫌いで僕より結果を残した人もいますし、僕より好きで結果を残さなかった人もいます。

僕とて気持ちでは誰にも負けない、と奮い立たせていました。でも、本当にそうだったか断言はとてもできません。

そして、やりたいというよりも、やらなければならないという使命感の方が、一層強かった心地もします。

使命感で結果を残せるのであれば、それもまたいいことでしょう。

やりたいことをやらなければ、と結果を残さないよりは。

結果が全てなのですから。

第82回 PHP勉強会にいってきた

タイトルの通りPHP勉強会に参加してきました。
スライドは、多分 こっちから共有されるはず。
今日はcakephp3の話でいろいろ収穫があったのでその辺を。。

cakephpのドンの安藤さんは世界飛び回ってるらしいです。

ちょいちょいと引用があったのはスペインで開かれたcakefesのお話で非常に興味深い話でした。
cakephpはアメリカ、インド、スペイン、日本、ブラジルの順でアクセスが多いらしい。
symfonyは英語にドキュメントが偏っている気がするし、それに比べれば確かに多様性がある。

時代はlaravel?みたいに言われているけど、cakephp史上最高に今のcakephpは活発だそう。
cakephp3のプロジェクトは6000コミット20コミッターは確かに多い。

symfony2に追いついたcakephp3

cakephp3もcomposerで、symgonyに追いついた。
ormもオブジェクトでsymfonyに追いついた。
ちなみにcakephp3のdocはすでにあるそうです。素晴らしい。しかも昨日cakephp3 beta2が出たところ、というホットなタイミングでした。

cakephp3はあくまで、いままでのcakephpの進化系

lithiumとは違う。cake3はあくまで、リファクタリング。
テストが今までのものを利用している。

これは、既存のプロジェクトでどんどん技術的負債の返済をしていかなければならないプロジェクトも学ぶところが多いので、
cakephpコミュニティのコミュニケーションは一度追ってみたいなあと思いました。必ずや学ぶことがあるはずかと思います。

doctorineを使わなかった理由は別に内製志向というわけではない

doctorineをつかわなかった理由は、ユーザエクスピエリエンス重視。
doctorineのドキュメントとcakephpのドキュメントは全然読み方が違う。確かに。
それにymlやアノテーションなど、cakephpでは使わない文化も多い。
ユーザへの負担を減らすために、cakephpはORMを内製した。

cake3のormは将来切り離す考えもあるらしい。
RDB以外は扱わない。
xmlとかymlとか使う必要のないORMを使うと。
fuelでも使われてる?kohanaのやつとかでもよかったのになとか思ったけど。どうなんでしょうね。

doctorineとはdataMapperパターンとAcriveRecordパターンでそもそもの設計思想が違うよね、と。
より軽量な開発はcakephpの方が使いやすそうな気がします。一応テストもしっかりとしてるし。

modelがオブジェクトになったことで、遅延ロードができるようになった。
なんか当たり前のことのようにも思えたけどもwww
プロパティを指定したときに、イテレータでプロパティに実行されるので、ごりごりactiveレコードパターン。
パフォーマンス的にはまだ全てが2より早いわけではないけど、遅くもないようです。

なんでもかんでも、内製思想ではない。
実際に色々と使ってる。i18nは外部化。hashも。
例えばmigrationやscafoldなんかはpulugin化されるのだと。

その他

ロングメンテナンスは安心です。確かに。
cake2系も3年以上はメンテする。
cake1.3は3のリリースで終了。マイクロソフトより長い!

cake3でphpのメジャーバージョンアップにも対応していくらしい
5.5とか5.6とかにやっていく。

PSRにはまだ対応してない。autoloadはcomposerで対応してるようですが。
cakephp自体は別にその辺うるさくないコーディング規約だったはずですしね。
公式リリースの前に一気にcs-fixer掛けられる可能性もありますね。phpstormもかなり普及してますゆえ。

PHPUnit DBUnitのカラムデータを取得する場合

PHPUnit DBUnitのカラムデータを取得する場合

phpunitのエクステンションDBUnitを使用しているときに、
テーブルの値を取得する場合はこれ。

12

$queryTable = $this->getConnection()->createQueryTable(‘TABLE’, ‘SELECT * FROM TABLE’);$queryTable->getTable(‘TABLE_NAME’)->getValue(0,’id’);

view raw gistfile1.php hosted with ❤ by GitHub

ドキュメントやphpdocを見ると、columnはintって書いてあるけど、カラム名をstringで受けるっぽい。嘘つき。。

MySQLマイグレーションツールキット

MySQLマイグレーションツールキットというものがあるらしい。

MySQL Migration Toolkitを使用してのOracleからの移行

上記の記事はそれでoracleへの移行テストを行っているよう。
mysqlからmysqlへの移行であれば、かなりいけてそう。

昨日の記事ではwordpressのDBのデータを移してからのデータ変換をCUIで扱ったけれども、
やっぱりGUIがあれば簡単にできますよね。機会があればこの辺りの使い方もまとめていきたいかもです。

oracle(sun)ではこのツールの改修を含めた移行サポートを行っているよう。
金があればなんでもできるが、一体サポートにどれくらいのお金がかかるのだろう。