n-style;は5/13 – 5/15 まで出張のため、ご連絡はメールにてお願い申しあげます。

どうぞよろしくお願い致します。

元記事はこちら。

個人事業で開発している者としても、技術の選定は難しいところがありますが、やはり信頼性の高さ・お客様に役立てていただくことを目的として選択すべきであって、自己満足とかスキルを増やすとか、そういう目的であってはいけませぬ・・・。

開発者は決定を迫られ、専門的に思える流行語ーNoSQL、クラウド、REST、Map-Reduceなどーにさらされているものです。とりわけシステム設計に関わる開発者は、最新ではない簡潔な解決策よりも、明らかに有益とはいえない新技術を組み込みたくなるものです。より企業的なソリューションを、というだけの理由でKISSの原則はしばしば無視されるのはなぜでしょうか？

1. 退屈である：開発者はよく、同じような種類の問題を繰り返し解決させられます。新しい種類のプロジェクトに関わる権限を持つ人ばかりではありませんし、世界中のソフトウェア開発者によって以前に何千回も解決されてきた同じような課題に取り組むわけです。
   その課題を頻繁に解決してきたということであれば、新しいものに取り組みたいという気持ちがあるとしても驚くには当たりません。・・・（割愛）・・・
   どう対処できるか： ・・・たとえば、最新技術のうち本当に役立ちそうな部分を見出して取り込む事ができるでしょうか。それ以外に、余暇の時間を使って得意分野に取り組んでみることができるでしょうか。結局、わたしたちの仕事は高品質のソフトウェアを出荷することであり、自分を楽しませることではありません。
   注意点：新技術を使うことについて忠告しているのではありません。その利点を見極め、その選択が最善かどうかを見分け、既存のもので対応できないなら、取り組んでみてください。
2. 職務経歴を埋める：これがおそらく、開発者が間違った技術の選択をしてしまう最も悲しい理由といえるでしょう。組織の意思決定の貧弱さを露呈してしまいますが、特別なことではありません。
   ソフトウェア開発における契約や開発者の居場所は流動的で、数年で新しい会社に移っていくことも珍しくありません。馬跳びをするかのように、はしごを上がるかのようにして居場所がどんどん変わっていきます。平均かそれ以下のスキルの開発者にとって、同じ会社にずっと居続けるよりもそのほうが簡単なのです。・・・（割愛）・・
3. 仲間の圧力：抵抗するのが最も難しい問題といえるでしょう。みな自分の決定が他者の影響を受けているなどとは考えたくないものですが、皆人間ですし、最もやっかいに思える人でさえ、幸福な社会集団を持ちたいと考えている社会的な生き物なのです。
   最新技術に直面すると、最善のアイデアとはいえないようなものの実装に反対することにいくらかの恐怖を感じるものです。しかしそのような感情はできるだけ抑えなければなりません。ディスカッションと意見の相違が評価されるような（望ましい）環境にいるのであれば、最新の情報や大量の情報を知らないとしても懸念を表わすのをためらうことはないでしょう。ソフトウェアテクノロジーは行ったり来たりするものであることを思い出しましょう。基本原則は大きく変わることはありません。辻褄が合わないように感じるのであれば、率直に述べましょう。あなたが若い開発者であるなら、インプットをためらってはなりません。経験が人を正しくするわけではないのです。加えて、なされた選択に対する洞察を得られます。
4. 理解不足：さらに、技術の選択にあたって、開発者がプラットフォーム上の動作を十分に理解していなかったり、理解しょうともしていなかったりすることもあります。
   たとえば、ハイパフォーマンスなリレーショナルデータベースの経験がない場合、予想できないものを実装することへのおそれからNoSQLに魅力を感じるかもしれません。しかし、そのような恐れには根拠がありません。不適切にツールを使用するなら、もちろんうまく動かないでしょう。しかし、理解や知識の不足から愚かな行動を強いられる必要はありません。実際に、リレーショナルデータベースで十分解決でき、すでにプラットフォーム上で使用しているのであれば、持っているものを十分に知らないというだけの理由で新たな依存関係を導入するのは愚かなことです。
   避けるために：読んで学びましょう！選択するときは、前提条件を調べて、持ちこたえるかどうか見極めてください。そのツールを使ったことがある上級の開発者に相談し、長所や短所について詳細を尋ねてください。利用できるツールについて多くを学ぶのは決して無駄なことではありません。イニシアティブをとるならば、将来きっと役に立つでしょう。
5. 問題を誤って理解したり、存在しない問題を解決しようとする：・・・開発者が新技術に取り組む際よくあることは、「これはXとYを行い、Zから保護する」ということです。しかし殆どの場合、X、Y、Zは優先順位の高い問題ではありませんでした。たとえば、クラスタ内の複数のノードの読み込み専用データセットをキャッシュする必要があるとします。ある人たちは分散したデータセットを要素が各ノードで重複しないようなキャッシング技術を提供することに取り組むかもしれません。しかしもしデータセットが小さくて、分散キャッシングを必要とするどんな変化も期待されていないとすれば、どうでしょうか。存在し ない問題のために、本質的により遅く、よりもろく、より複雑でな新技術を導入していることになります！
   そうならないために：開発者は問題領域全体を理解していなければならず、前提条件が正しいかどうかをクロスチェックする必要があります。時には問題ではないものを問題と思い込むことがあるので、あとのステップは重要です。「もしも」の状況をカバーしたいという誘惑を避けましょう。恐らくそれが必要になることはないでしょう。もしカバーするなら、後日変更を加える際のコストを高く見積りがちになります。後日同じ作業量が発生する僅かな可能性のためにいま専念している努力は全く理解されません。

どうすればよいか？
要求をレビューしよう：整合性、フェイルオーバー、パフォーマンス、など。
既知のものが合致するかどうか評価しよう：もし合致するなら、たいていは最善の選択です。
ほかの技術がニーズに合うか、新たな依存関係や失敗時のコストなどを検討します。（無料のものはなく、どんな新技術にもメンテナンス費用は重要です）
チームの専門知識を見極めよう：あなたがよく知っている良いところ
他の気がかりな要素を検討しよう：価格、納期など
チームで討議しよう：長所・短所のリストを作ろう

これらはガイドラインの一例です。慎重で合理的な決定ができるようにアプローチしてください。

photo: john holzer

意外にもあっという間でした。

iOS 5.1 on iPhone4 の環境ですが、iOS 5.0の時はかなりもっさりした動作で、タッチのレスポンスもあまりよくなく、やはりハードウェア依存の改訂が多かったのかなぁなどと考えていましたが、iOS 5.1になってその「もっさり感」が全くなくなっており、むしろ快調に動作しているような・・・。

アップデートしてよかったです。皆様もお試しあれ。

私は当時新入社員で、その会社では、新入社員は早く出社して社内の掃除（デスク脇のゴミ回収と床のモップがけ）をすることがルールになっていました。

専門学校出たばかりで、開発系の仕事をやろう！という自分の希望とは異なって、Macを扱える人がいないからと、DTPをやってくれと言われ、先が見えない感じでいっぱいだったことを今でも苦く思い出します。

photo credit: blakespot

朝早く出社するということで、朝一納品をよく頼まれました。新人時代のはじめての納品は、出向社員Aさんへのメール納品でした。
B主任が、文面とファイルを渡すので、それを貼りつけてその出向社員へ送ってほしい、との依頼。
文面はというと、「C営業部長さんから連絡がいっていると思いますが、〜〜」といった感じの結構砕けた内容。少なくとも新人が先輩社員に送る文面ではない。読んでいて大変恥ずかしい内容。
作業前にメールソフトを起動すると、C営業部長から急ぎのメール。「例の納品、Dさん（xx@xx.xx）にもCCで送ってくれますか」とのご依頼。お安い御用で、と、そのままCCに追加して送信。

何が起きるか。感のいい方はお気づきでしょう。そうです。

1. Aさん宛の文面のまま、Dさんにも送ってしまった
2. AさんもDさんも、同じドメインなのでメールアドレスの見た目では判断不能
3. 私はどちらとも面識なし
4. Dさんは実は出向先（＝取引先）の上司！

後日、なぜかC営業部長から呼び出されて、これらの理由を知らされないままマンツーマンでメールの書き方についてご指南いただきました。言葉の使い方とか、お客様にはこういうふうな文章を書いてはいけない、といったような内容の話を小一時間ほど。なんだか「マナーのなっていない若い子」扱いで、極めて不愉快でした。

釈然としない感全開で自席に戻ると、B主任がいらっしゃって、

「この間頼んだあの件、じつはDさんは（取引先）の部長さんだよ」

photo credit: foilman

問題解決を仕事にしている現在、この件を「よみがえる不快感」を抑えながら振り返って考えてみました。

どうすればこの問題は起きなかったのでしょうか？

私が納品を頼む立場なら、初めて新人が納品するときに、同じ部署の人間が誰も居ない所でやらせたりはしない！

指示系統は1つにしないと大変厄介なことになる！仕事の場合は特に、全容を知らない第三者は加わってはダメな気がします。

学んだ教訓：納品は慎重に。

Image: Salvatore Vuono / FreeDigitalPhotos.net

Wanting to be the best in your field is an admirable goal, but don’t allow that one thought to dominate your life. If you ignore thoughts of love, laughter, and the joy of life, or if you are so fixated that you forget to enjoy life, you are stressing yourself.

自分の活動分野で一番になりたいという目標も結構だが、その考えだけに生活を支配されてしまってはいけない。愛とか笑い、生活の喜びなどについて考えず、成功することに固執しすぎて生活を楽しむことを忘れてしまうなら、自分にストレスを加えていることになる。

Dr. Arnold Fox

n-style;は10/27 – 11/3 まで出張のため、ご連絡はメールにてお願い申しあげます。

どうぞよろしくお願い致します。

n-style;は、9/11〜9/28まで出張となっております。

ご連絡はメールでお願いいたします。

どうぞよろしくお願いいたします。

昨年の秋からiPhoneユーザになりました。

でも秋田県ではWifiスポットが余り無いので、出先ではもっぱら3G通信になります。

最近模様替えをして、書斎のアーム付きモニタをダイニングに移設しました！長年の夢ついに！

我が家のライフスタイルではダイニングでPCを使いたい環境が多くて、ダイニング用のPCが欲しいと思っていましたが、用途が用途（息子のためにDVDみせるとか、おくさんがレシピ検索するとか、食事中に映像を見るとか、家族で勉強するとかetc）なので、新調するほど費用を掛けたくなくて・・・

で。

おくさんのMacBookをクラムシェルモードで外部モニタ出力し、それをリモコン操作みたくする。

ということができないか調べていました。

そこで見つけたのが、タイトルにあるtouch mouseです。

http://itunes.apple.com/jp/app/touch-mouse/id338237450?mt=8

ロジテックのものだということで安心して使用できると思いました。

パソコン側にはサーバアプリを入れて、iPhoneにはクライアントアプリを入れて、iPhoneからトラックパッドやキーボードとかを利用できるのです。もはやリモコンです！

MacBookはMac OS X 10.6.7 (Snow Leopard)、iPhoneはiOS4.3.3です。

使ってみてわかったこと。

CommandとかOption、Shiftなどのキーを一度使用すると、使用を解除できなくなる。

常に右クリックみたくなって嫌でした。

というわけで、現在はHippoというユーティリティを使っています。

http://itunes.apple.com/jp/app/hipporemote-lite-wireless/id357348996?mt=8

http://stackoverflow.com/questions/965083/jquery-sortable-list-wont-serialize-why

$("#foo").sortable("serialize");

でシリアライズした値が取得できなかったのですが、これは各ドラッグしたい項目ごとにidに_（アンダースコア）付きの名称を設定しないといけないんだそうです。

例：tableタグのtr（行）単位でsortableを使いたい場合

<tr id="category_<?php e($category['Category']['id']);?>">

のようにしておく。

n-style;でも複数の事例を扱うようになってきました。CakePHPはけっこう前からi18n対応していました。php4で動作しかつi18n対応のフレームワークは、数年前はCakePHPしかなかったように思います。

手順としては、

1. アプリケーションを普通に作成。メッセージは
   __(‘english message’);
   のようにしておき、英語で記述すること。
   動的に変化させる必要のある部分はsprintfなどを用いて記述するとよい。
2. コンソールから
   cake i18n -app /path/to/your/app
   とコマンドを叩いて、 英語のメッセージ文を抽出する。
3. poeditを使って翻訳する。
4. 翻訳後、書き出しを行う。
5. 日本語の翻訳ファイルを
   /app/locale/jpn/LC_MESSAGES/default.po
   に配置する。

ざっと上記のような感じになります。

プログラマーとしては、メッセージの作り方、UIの作り方に注意すればよいと思います。

テンプレートの読み込み分けとか、画像ファイルの読み込み分けなども必要になってきますよね。

意外と、画像の中にテキストが含まれるもの—例えば、ボタンのグラフィック、スローガン入りバナーなど—を「多言語仕様」で作るのを忘れる、なんていうことが起きます。
別途デザイナーさんがいらっしゃるようなプロジェクトでは要検討事項になるでしょう。

Webアプリケーションの多言語展開をお考えでしたら、どうぞn-style;にご用命ください。