せつないぶろぐ

JSONPを利用して通信した後ってオブジェクトの中身って確かめたいよね。
ちょっと探したんだけど、私の検索力ではJavaScriptの中身を確かめる
良いライブラリが見つけられなくて結局自作したので晒します。
イメージとしてはphpのprint_rっぽいやつ。
※見ればわかりますが結構適当です。実用レベルって事で
※Firebug使えば見れるんですけどね。画面にガッと出したかったりもするので

function obj2str(obj, space) {
var lf = “<br>”;

if (space == undefined) {
space = ” “;
} else {
space = space.replace(” “, ” “);
}

var str = “”; for (key in obj) {
str […]

Posted on 1月 30th, 2007 by t
Filed under: JavaScript, プログラム＆技術系 | No Comments »   

「アート・オブ・プロジェクトマネジメント」を読んでプロジェクトでの信頼関係が
いかに大事かを再認識したのだけど
実際の現場ではこう思われてるの？
代替可能なシステムエンジニア
代替可能なプログラマ
リスクを管理するうえでプロマネが考えなくてはいけないことかも知れないが
自分がそう思われていると思うと辛い。
ksh Days - プログラマのスキルレベルに依存しない体制ができたらプログラマはいらないような気がする件について
http://d.hatena.ne.jp/ksh/20061230/1167490514
304 Not Modified: ＳＥの理想とプログラマの理想
http://maname.txt-nifty.com/blog/2007/01/skill.html

Posted on 1月 25th, 2007 by t
Filed under: 提案・開発・運用 | 3 Comments »   

プチ・パラダイムシフトせよ！ － ＠IT
http://www.atmarkit.co.jp/fdotnet/nagilemind/nagilemind04/nagilemind04_04.html
結局システム開発の目的はこれに限る。システム開発だけではなく、ほとんどの仕事にあてはる事だと思う。
手法やツールは「顧客の問題を解く」為にあるものなので、こだわる事はあっても固執してはいけない。
デスマになる原因もこれ（「顧客の問題を解く」）が多いと思う。
１）仕様が決まらなくてスケジュール超過
２）顧客が検証する段階になって、「何これ？」って言われてやりなおし
１）の場合、顧客側が顧客の問題を理解していない場合に起こりやすい。
何が問題かわからないから何が欲しいかわからない。
※社内の政治的問題もあるとおもうけど、ここでは割愛
※システム化よりそういった政治問題がおこることを解決するべき
２）の場合は、開発者側が顧客の問題を理解していない
顧客の問題を理解しないまま設計したり、顧客に言われたそのままを作るとこうなりやすい。
顧客が「こんな風に作ってよ」って言ってきたら「なぜ」かを問わなくてはならない。
そこで初めて「問題」が現れるから。
毎回思うのですが仕事中に読んでると周りが気になる記事ですね（絵がね^^;）

Posted on 1月 18th, 2007 by t
Filed under: 提案・開発・運用 | No Comments »