OpenSocial OAuth Filter バージョン0.6をリリースしました - GeekFactoryOpenSocialアプリの開発に役立つライブラリです。バージョン0.6ではGoogle App Engine向けの最適化を行いました。このライブラリと並行してmixiアプリも開発中です。 詳しくはこちらから。 http://code.google.com/p/opensocial-oauth-filter/
会計制度がソフトウェアの変化を困難にしているのか？ - GeekFactory
納品する立場では意識することが少ないですが、システムは機械設備と同様に固定資産となります。私は社内システムの開発に一時期関わっていましたが、システムを勝手に作ることはできず、投資計画に基づいて資産化する手続きが必要になります。システムを勝手に作ったとしても、そのシステムを作った人の給料をどこから支払うかが問題で、他の名目で支払えない以上は資産化する必要が出てきます。 システムの償却期間ごとに更改案件が発生することが多いと思います。これは、一度作ったソフトウェアやハードウェアは一定期間を経ると価値が下がるという考え方に基づいています。ハードウェアに対してソフトウェアは変更が容易なので、一度作ったものを大きく変更しないという考え方は現実に即していないといえます。 ここまで書いたことは教科書的な話で、実際は維持費でやり繰りするとか次期開発に混ぜるとか怪しげな話はたくさんあると思います。特に、ソフ
他ライブラリに依存せずにXML設定ファイルを読み込む方法 - GeekFactory
ライブラリをパッケージして配布する時、なるべく依存するjarを減らしたいことがあります。Mavenを使えば何ともないのですが、敷居を下げる意味では「1つのjarだけ入れれば動きます」が望ましいと思います。*1 Commons DigesterやJAXBを使うと、XML設定ファイルの読み込みが飛躍的に簡単になります。一方で、ライブラリを配布する時は同梱するか注意書きを加える必要があります。そこで、他ライブラリに依存せずJREだけでXMLを読み込む方法を考えてみました。 Java 5から標準になったXPathを使うと、XMLから任意のノードを簡単に取り出すことが可能です。XPathクラスをそのまま使うと記述量が増えるので、XPathをラップするクラスを用意します。 package org.hidetake.util.xml; import java.io.IOException; import
90年代と21世紀の越えられない壁 - GeekFactory
実質的な仕様承認者となることが多いであろう30代後半の人は、1990年代のクライアントサーバの経験で生きている。業務トランザクションやGUIの考え方は、VBに代表されるクライアントプログラムがベースになっている。業務データが入力されてからコミットされるまでプログラムは動いているし、画面の操作はイベントでやってくる。 これに対して、Webを当たり前のように使っている人たちはステートレスな世界に慣れているし、画面の操作はページ遷移を伴うことを前提にしている。HTMLで書かれたページに対してMouseOverだの再描画だの言っても噛み合わない。両者の間には越えられない壁が存在する。 まとめると、世代の違う人がレビューすると前提が違いすぎて話が噛み合わないケースがある。そんなことを感じた今日この頃。企業内システムはまるで時計が止まった世界にあるようだ。
今やれることをやる、後で困らないことは後でやる - GeekFactory
見積もり工数は、あくまでも個人的にざっくりベース（SI用語）で出した数字なので、ズレがあるわけで。事前にタスクを割り振る場合は見積もり時間を基準にする必要があると思うけど、見積もりのズレや個々人の状態によってかなりブレるのが普通で、途中でタスクの振り直しが発生する。絶対に。ということで、全体を事前に決めず、「今からどれをやろうか」を決めながら進めるようにした。 http://d.hatena.ne.jp/katzchang/20090924/p1 SIで不毛なのは完全なスケジュールの作成だと思います。不確定な要件から引いたスケジュールで「計画と実績の乖離」とか言われてもなぁ、というのは同感。 いま私が持ってるチームも同じような進め方をしていますが、インフラまわり*1を担当していることが大きな違いです。基本的にアプリ開発チームからの要望や苦情で50%以上の工数を使い切ってしまうので、「今やれ
Apache TomcatとHTTPクッキーにまつわる騒動 - GeekFactory
Apache Tomcat 5.5.26（6.0.16も同じ）で、HTTPクッキーの取り扱いについて大きな仕様変更が行われました。ここでは仕様変更の内容と影響範囲を考察します。 HTTPクッキー 簡単に復習しましょう。WebブラウザがWebサーバから以下のHTTPヘッダを受信したとき、Webブラウザは test というクッキーを記憶します。 Set-Cookie: test=nullpo; Expires=Wed, 08-Oct-2008 14:03:16 GMT; Path=/クッキーは NAME=VALUE という形で表現されます。連想配列と同じ。 NAME VALUE test nullpo 一度クッキーを受信すると、ブラウザは当該URLにアクセスする度に、以下のHTTPヘッダを送信するようになります。 Cookie: test=nullpoこのように、クッキーはWebサーバがブラウ
プログラミングを自動化できないたった一つの理由 - GeekFactory
自動車産業を始めとする製造業では高度な自動化が行われているが、ソフトウェア開発は未だ自動化が行われていない。数年前から、SIerの興味は建設業から製造業に移っている。 ソフトウェア開発という「家内制手工業」をせめて「工場制手工業」へ発展させ、ゆくゆくは「機械制大工業」に進化させようという試みの多くも、同様の誤解がベースになっているわけで、「ソフトウェア開発」を「モノ作り」と見なす誤解は、広く蔓延してしまっているのかもしれない。 http://blog.gcd.org/archives/50603640.html 実に広く蔓延している。ホント失望したよ。 自然言語で記述された要件を仕様に落とし込む作業は、人でなければ不可能である。仕様を記述する行為そのものがプログラミングであり、概念を構造化して言語に書き出すことがプログラミングだ。多くの（偉い）人が勘違いしているが、自然言語をプログラミング
プログラミングを単純労働と捉える3つの理由 - GeekFactory
int128殿の会社では、 >プログラミングは誰でもできる、頭を使わない作業 と思う方が多くいるのかしら？ http://d.hatena.ne.jp/int128/20080414/1208181589 うちに限らず、多くの大企業SIerではプログラミングを単純労働と捉えています。その理由は3つあります。 （1）プログラミングは業務をプログラムに落とし込む単純労働 SIの開発手法（の考え方）は30年前から進化していません。業務をプログラムに落とし込む作業は誰がどうやっても同じようになるという思想に基づいています。現在のように高品質なフレームワークやライブラリが溢れる時代では、いかにそれらを組み合わせて作るかが効率化の鍵になります。組織のトップが進化した設計思想を理解しようとしないのは問題です。 30年前の設計思想であれば、プログラミングは業務をプログラムに落とし込む単純労働です。 （2）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
情報を検索する世代と整理する世代 - GeekFactory