トップ > 2007年9月

Coreserverよさそう

CoreserverでDjangoを使う
[memo]coreserver.jpにアカウント作成

さくらから乗り換え検討する?

| 07-09-27 13:01 | コメント (0) | トラックバック (3)

さくらインターネットでDjango、再び

[補足]さくらインターネット、CGIでDjangoを動かすで、mysqlのバージョンが古いので文字コード指定のソースをコメントアウトするというイレギュラーな対応をしていたが、それだけだと問題がありそう。

[Django][本棚開発ログ][さくらインターネット] Django を最新にupdateしたら困ったことになった。
※コメントにも書きましたが、こっちでも紹介しとこうとエントリーにしました。トラバも送っときます。

で、マニュアルを見てみたんだけど、こんなことが書いてあった
データベースのサポート状況 : Django オンラインドキュメント和訳 - MySQLdb

古いバージョンの MySQL と mysql_old バックエンドを使うつもりなら, おそらく 1.2.0 で動作するでしょう.

というわけで、django/db/backends/ の中の、mysql と mysql_old を入れ替えてちょこっとadminを触ってみたけど、どうやら正常に動いている様子。re_guzyさんとは違ってDjangoは0.96のままだけど。
これで上手く行ってくれると良いな。

ちなみにDjangoのマニュアルによると古くないMySQL=推奨されるバージョンは4.1以降らしい。そりゃそうだ。
さくらインターネットさん、なんとかバージョンアップできませんかね?
ユーザーが多いから難しいのは分かるけど。

| 07-09-25 11:21 | コメント (0) | トラックバック (1)

「発注者ビュー検討会 | NTTデータ」に感じた違和感

何となく違和感を感じた。

発注者ビュー検討会 | NTTデータ

実践的アプローチに基づく要求仕様の発注者ビュー検討会(略称 発注者ビュー検討会)は、情報システムにおける「仕様」について、お客様にわかりやすい記述方法および合意方法を共同検討することを目的に国内主要SI事業者が結集した検討会です。
  • 「お客様視点でわかりやすい」、かつ
  • 「現場で使える」ベストプラクティス作り

を行い、IT産業界への浸透を目指すとともに、日本のIT産業全体のレベルアップを図ります。

どういった設計書で発注者とやり取りするのかについて分かりやすく業界標準を作る・・・というのが悪いわけではない。
各社、もしくは各プロジェクトごとに設計書(要件定義書や基本 or 外部設計所)の仕様を決めているため、記述レベルや結果的な品質のばらつきがあるのは確かだ。
発注者への確認・・・と言う意味での仕様書も、曖昧になっているプロジェクトが多いのかもしれない。

では何が違和感なのかというと、この目的が「より良いシステムを作るためではない」ということなんだろうと思う。

このプロジェクトは以下の観点が抜けているのではないかと思う。

  • どんなに設計書で合意しても、実際にシステムを使ってみないと分からない要件がある
  • 内部設計や実装を行う過程で、外部設計や仕様の改善点を思いつく場合が多い
  • 外部設計までのスケジュール・予算が厳しく、細かい仕様まですべてチェックしきれない場合が多い

ではこのプロジェクトの目的は何なのか?
言葉は悪いかもしれないが、受注者側の防御のためだと思う。もしくは請負で開発を投げて終わりにしてしまいたい発注者側、特にシステム部門の防御にもなるだろう。

発注者「実際見てみると、この辺はおかしいなぁ」
受注者「でもこの設計書で合意しています」

下流担当「ここは、仕様が統一されてないから、こうしたほうがいいのでは?」
受注者「でもこの設計書でお客様と合意しているから」

こんな会話のタネにしかならなかったらやだな。
全てが一つのウォーターフォールでしか考えられず、しかもこの設計書を書く人はシステムの内部まで分からない人だったりしたら・・・多分こういう会話が飛び交うんだろうな。

うがった見方の意見を述べてしまったが、この発注者ビュー検討会のような取り組みが必要なことは分かる。
でも発注者と受注者のコミュニケーションが上手く行かないのを改善するのに、こんなプロジェクトがあってそこそこ注目されるんだと思うと、この業界(請負開発、SI)のレベルが低いんだろうなーと感じてしまう。
発注者にも開発側にも分かる仕様書なんていうのは普通のことで、その上でよりよいシステムを作るためにはどうすれば良いのかという議論が普通にできる業界になればいいなぁ。

参考:
Japan.internet.com Webビジネス - NTT データなど9社、発注者と開発者の認識のズレを防ぐガイドラインを公開
デスマーチ撲滅への「飛躍」なるか--大手SI事業者、外部設計書の記述を標準化:ニュース - ZDNet Japan

| 07-09-20 09:40 | コメント (0) | トラックバック (0)

Google ReaderがGoogle リーダーに

「Google Reader」を開いたら、日本語化されて「Google リーダー」になった。

Google Reader派の私としては、(嫁のような)一般人にRSSリーダーを紹介するときに、Google リーダーでいいんじゃない、と安心して言えるようになるのかな。

| 07-09-18 14:54 | コメント (0) | トラックバック (0)

Javascriptのthisに戸惑った

普段適当な処理しか書いたことの無いJavascriptをマジメに書いていて、「this」に戸惑った。

オブジェクトの中でthis使ったら、Pythonのselfみたいに自分のオブジェクトを指すもんだとばかり思ってたよ。
違う場合があるんですね。

イベントやタイマー(setIntervalとかsetTimeoutとか)などで呼び出されると、thisは自分のオブジェクトを指すわけではない。
自分のオブジェクトを使いたいときは事前にthisをローカル変数に保存して利用する。

今回はイベントハンドラじゃなくってタイマーで呼び出して失敗した。
自分メモで動くソースを。

var obj = function () {};
obj.prototype = {
    timer: null,
    hoge: 'hoge',
    run: function() {
        var self = this; // thisを保存しておく
        var func_ref = function () {
            alert(self.hoge); // イベントやタイマーで呼ばれるときは、selfを使う
        }
        this.timer = setTimeout(func_ref, 1000);
    }
}
x = new obj();
x.run();


参考
ひげぽん OSとか作っちゃうかMona- - 実践 prototype.js [2]
404 Blog Not Found:怠翻 - JavaScriptでありがちな9つのシマッタ

| 07-09-11 18:50 | コメント (0) | トラックバック (0)

Javascript+ハンガリアン?

想定したとおりに動かないということで、Javascriptのソースを見てくれといわれた。

変なJavascriptのソースだった。
なんででハンガリアン記法なんだよ。(いわゆるシステムハンガリアンってやつ)

いや動的で弱い型付けだからこそ意味があるのか?


それにしてもDOMオブジェクトを保存する変数に文字列のプレフィックスを付けるのはやめてくれ。

| 07-09-06 14:07 | コメント (0) | トラックバック (0)

« 2007年8月   2007年11月 »