陥りがちなプロジェクトの落とし穴と改善点（その２）

先日の記事では、マネージメントと設計について書きました。

• 一時的ではなく、継続的に要件・仕様を詰める事
• 問題が発覚する前に動く事
• 「とりあえず」の意識
• 伝える事を前提にしていない意識
• 適切なツールを使っていない

が問題を引き起こす、という事を書きました。

今回は

• 伝える事を前提にしていない意識
• 適切なツールを使っていない

という２点について詳しく書いていきたいと思います。

陥りがちなプロジェクトの落とし穴と改善点（その１）

しばらくぶりの更新となります。というのは、ひどいプロジェクトに参画していたため、更新する時間がほとんどなかったためです。

という事で、何回かに分けて、ひどいプロジェクトになる原因と、その改善点をいくつか挙げてみたいと思います。

なお、これは特定の個人を中傷するものではなく、単純なプロジェクトとしての良し悪し、誤ったやり方を見直す機会・一意見としてご覧頂ければと思います。

Google ChromeでAdobe Edge Inspectが動かない場合の方法

つい先ほどAdobe Edge Inspectを動かそうとしたら、MacのローカルアプリケーションもChromeのExtensionも、iPadのアプリも入れているのに、「Adobe Edge Inspectを起動してくれ」って表示のまま接続されない状態になっていた。

どうやら、Chromeのバージョンがv30に上がったためっぽく、検索してみたら、以下のページがヒットした。
http://forums.adobe.com/thread/1308519
ExtensionをAdobeが修正するまでの暫定の処置になると思うが、必要な人の為にも残しておく。

node.jsでのRESTサーバ作成

Express.jsを使ってRESTなAPIサーバを作成する方法を調べてみました。

ポイントを箇条書きにします。

• express-resourceモジュール
• jQueryでのPUT/DELETE送出

各メソッドと、コールする際のHTTPリクエストです。

• index(GET)
• new(GET)
• create(POST)
• show(GET)
• edit(GET)
• update(PUT)
• destroy(DELETE)

ではExpressのインストールから始めます。

plistを使ってforeverをデーモン化(OSX)

個人的な使い方として、foreverをMac上で使って永続化する事は（必要な時だけ起動するので）今のところそれほど無いのですが、使う事もあるかと調べてみました。

forever自体が起動・停止・一覧表示機能を持っているので、launchctlから扱う利点は、OS起動直後の起動や、ファイル・ディレクトリ監視での起動などでしょうか。（画像を特定ディレクトリに放り込んだら起動して、ファイル形式の変換や、エフェクトかけたりとかができるかも知れません）

という事で、始めます。

node.jsをGoogle Chromeでデバッグ

node.jsで開発していると、サーバ側のデバッグは単純な場合、console.logを使って変数などをコンソールに出力すると思います。ただ、これだとオブジェクトなどの変数が展開されて表示されるため、変数の構造が込み入ったものの場合、とても探しにくい事があります。

PHPなどでもクライアントブラウザのコンソールに出力するツールなどはありますが、node.jsでも同じくあります。いくつか選択肢がありますが、そのうちのいくつかを挙げていこうと思います。

iPad Retina / iPhone 5 / Kindle FireをMacのセカンドディスプレイに

最近、必要にかられてiPad Retinaを買いました。
そろそろ新型の噂も流れているので、時期的にはもう少し待ってからの方が良かったのかも知れませんが、実機の速度の検証が必要だったので。
せっかくiPadを買ったなら、単にタブレットとしてだけ使うのは勿体ないので、セカンドディスプレイとして活用する方法を調べてみました。

ついでに、以前頂いたKindle Fireや、iPhone、Androidでも試したかったので、全てを接続できるものを限定しました。