2008年7月6日のブックマーク (6件)

  • SIerにとって“怖い”のはSaaSよりもPaaS

    SaaSよりPaaSの方がシステム・インテグレータ(SIer)に大打撃を与えるなあ・・・セールスフォース・ドットコムのマーク・ベニオフ会長兼CEOの話を聞きながら、そんなことを考えていた。クラウド・コンピューティングの最終的な勝者がどこになるかは別にして、このパラダイムシフトはSIerのビジネスモデルにトドメを刺す、そのことが妙にリアリティを持ち始めてきた。 PaaSはプラットフォーム・アズ・ア・サービス、つまりサービスとしてのアプリケーション開発・実行基盤のこと。SaaSのようにアプリケーションまで作り込んだサービスではなく、アプリケーションを作って動かす環境をサービスしましょうって話だ。セールスフォース・ドットコムは「Force.com」とか言っているが、PaaSは何もこの会社の専売特許ではない。日ITベンダーもおっかなびっくりだが似たようなサービスに乗り出そうとしている。 情報シ

    SIerにとって“怖い”のはSaaSよりもPaaS
  • 鶏胸肉・鶏むね肉・鶏ムネ肉の料理:アルファルファモザイク

    激安の鶏むね肉を、(゚д゚)激ウマー料理にしよう! 前スレ 鶏胸肉・鶏むね肉・鶏ムネ肉の料理 4 http://food8.2ch.net/test/read.cgi/cook/1179813803/ 過去スレ 鶏胸肉・鶏むね肉・鶏ムネ肉の料理 1 http://food6.2ch.net/test/read.cgi/cook/1094711144/(dat落ち) 鶏胸肉・鶏むね肉・鶏ムネ肉の料理 2 http://food6.2ch.net/test/read.cgi/cook/1136525909/(dat落ち) 鶏胸肉・鶏むね肉・鶏ムネ肉の料理 3 http://food8.2ch.net/test/read.cgi/cook/1164383017/(dat落ち) 美味しいレシピ・テンプレは>2-10くらい 過去スレより炊飯器調理 20 名前: ぱくぱく名無

    tomerun
    tomerun 2008/07/06
  • フレームワークのジレンマ - おおたに6号機blog

    フレームワークを作っている人にはいつもあるひとつのジレンマがあるんじゃないでしょうか。 それは機能追加によるフレームワークの肥大化です。 ユーザさんから言われた機能・自分達のチームでこれは良い!と思って入れた機能など 理由はそれぞれですが、フレームワークが形になってからの機能追加は進む一方です。 機能が増えればそれだけ故障箇所が増えるのと一緒です。また想定しない使い方をユーザさんが してくる場合もあるでしょう。 自分もこのような機能追加は正しい・求められているんだとずっと思っていました。 今でも間違ったことだと思ってるわけではありません。 ただし、それには大きな前提があることにちょっとだけ気づいたのです。 それは、 最初に開発されたフレームワークの機能は十分に検討され、 厳選されたミニマルセットな機能以外はあってはならない。 という前提です。書いてみれば当たり前で拍子抜けされるかもしれませ

    フレームワークのジレンマ - おおたに6号機blog
  • Javaのランタイムコアrt.jarの内訳 - kaisehのブログ

    JREのコアになるrt.jarが、Javaのバージョンアップと共にどんどん大きくなってることに気付きました。 JRE 1.4.2の時点でrt.jarは22MBなんですが、1.5.0になると33MB、1.6.0だと42MBに増えています。 その内訳がどうなっているのか、HDD使用状況分析ツールのOverDiskで調べてみました。JRE 1.6.0_05付属のrt.jarを展開して、そのディレクトリ階層を表示した結果が以下です。 主要なパッケージのサイズは以下のようになりました。 com.sun.* 17.1MB - com.sun.org.apache.* 6.8MB - com.sun.xml.* 4.0MB - com.sun.corba.* 2.3MB sun.* 8.9MB javax.* 6.5MB - javax.swing.* 4.4MB java.* 4.6MB - java

    Javaのランタイムコアrt.jarの内訳 - kaisehのブログ
    tomerun
    tomerun 2008/07/06
  • プログラミングは目的でなくて手段であるべきか - 文字の洪水に溺れながら

    僕はプログラミングのプの字もわかりません。 ぎりぎりHTMLを2年ぐらい前にHPを立ち上げた時にいじってみたくらいで、それすら、もうすっかり忘れてるぐらいです。 正直、C言語?何それ喰えんの?見たいな感じです。 ただし、そんな僕でも重度のネットユーザーだからかプログラミングの便利さはわかります。はてぶに始まりちょっとしたアイディアでも自分の思い通りの指令を動かすソフトができるのならとても便利なんだろうなぁと、PCをいじっていると思うことがよくあります。 そんな中でこの頃考えるのがプログラミングというのはそもそも目的なのか、手段なのかっていうことです。 そもそも、僕の周りのプログラミングをやっている人になぜプログラミングをやっているのですか?と聞くと十中八九「面白いから」という返事が返ってきます。 正直な話、「便利だから」って言う答えは聞いたことがありません。 だからこそ、「あぁ、みんなはプ

    プログラミングは目的でなくて手段であるべきか - 文字の洪水に溺れながら
  • 銀行の言語事情 - novtan別館

    といってもグローバルに活躍するためのマルチリンガルな話ではありませんよ。 今やメガバンクになってしまいましたが、僕がIT業界に入ったときはまだ都銀と呼ばれていた某銀行でのお話。用語について一切説明せずに行ってみる。世代チェッカーかも。 ホスト系 今やメインフレームだからといってホストでもない時代ではありますが、都銀のシステムはトランザクション量やダウンタイムの問題からやっぱりメインフレーム、で、過去の遺産がありすぎてホスト型。 言語はCOBOLが中心ですが、コア部分に近づくとPL/Iだったりアセンブラだったりする。大事なスキルはJCLを書けること。まあ、JCL自体はシェルプログラミングと変わりません。VOL-=SELの指定とか面倒だけど。基的に端末のI/Fを想定しているから、SNAとかFNAとかで通信しなきゃいけなくて手続きはめんどくさい。メモリとかディスクの容量が少なかったときの設計を

    銀行の言語事情 - novtan別館