Javaのコネクションプーリングの仕組み - ひがやすを技術ブログ
Javaのコネクションプーリングがどのような仕組みになっているのか、知らない人は結構多いんじゃないかと思います。 Slim3のコネクションプーリングの実装を見ると、この辺が理解できるようになります。トランザクションとコネクションプーリングがどのように連携しているかを把握することは重要です。 http://svn.slim3.org/browse/trunk/slim3/slim3-datasource/src/main/java/org/slim3/datasource/ 登場人物は、4人しかいないから簡単ですね。 最初に見て欲しいのは、ConnectionWrapper。DataSource.getConnection()したときに戻されるコネクションの実態です。このコネクションを論理的なコネクションと呼ぶようにします。 主な役割は、コネクションがクローズされたときに、コネクションをプー
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
最初のアクセスで;jsessionidを表示させない方法 - ひがやすを技術ブログ
URLの一部にセッションIDを埋め込むのは、アプリケーションサーバが、クライアントがクッキーをサポートしているかわからない場合です。 最初のアクセスで、アプリケーションサーバは、クッキーを設定してクライアントに返します。二度目以降のアクセスで、クッキーが返ってきた場合は、クッキーを通じてセッション管理ができるので、;jsessionidはURLに埋め込みません。 携帯の端末のようにクッキーが帰ってこない場合、二度目以降も;jsessionidをURLに埋め込みます。 クッキーがサポートされているブラウザで、最初のアクセスでURLに;jsessionidを表示させたくない場合、最初にindex.jspにアクセスしてもらうようにし、index.jspから本物の最初のページにリダイレクトします。 <html> <head> <meta http-equiv="Content-Type" cont
SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変
Railsが成功しEJB3が失敗したわけ - ひがやすを技術ブログ
Railsが成功し、EJB3が失敗したわけは、イノベーションへの解にでてくる「独自仕様の製品アーキテクチャ」と「モジュール方式のオープンな業界標準」の考え方で、うまく説明できるように思えます。 ただし、この手の話は、理論にあうように現実を説明しているところがあるので、あくまでも、1つの可能性として聞いてください。 ここでの重要な考え方は、「顧客のニーズ」と「製品の性能」の力関係です。 「顧客のニーズ」が「製品の性能」を超えている場合は、顧客は、製品の性能向上に価値を認め、お金を払います。このときに企業として、成功しやすいソリューションは、「最適化された独自アーキテクチャ」で望むことです。性能を向上させるためには、独自アーキテクチャのほうが、いろいろ工夫ができるためです。 「製品の性能」が「顧客のニーズ」を超えている場合は、顧客は、製品の性能向上に価値をあまり認めません。既に、製品の性能に満
Seasar2でサクサクか炎上か - ひがやすを技術ブログ
可燃プロジェクトに飛び込むことになりました。下記のような炎上する要素満載。 関係者各社に告知済みのためカットオーバーは伸ばせない 外部仕様を策定した会社は行方不明 外部仕様はあるが、OS も AP サーバも環境もアーキテクチャーも未定 外部仕様を分かる人がいないw 開発は 3 社合同なのにソース管理方式も決まってない DB アーキテクト不在っぽい フレームワークに詳しい人がいない AJAX っぽいのたくさん お金がない、規模はわりとでかい、納期短い、残業禁止、増員不可 最初このエントリを見たとき、4/1だったこともあり、一瞬ネタかなと思ったんですが、その後に、SAStrutsとS2JDBCに対する具体的な質問がいくつもあり、私のほうもできる限り質問に答えました。 その後、どうなったのか気がかりだったんですが、今見たらこんな書き込みが 開発メンバからは、簡単で楽でいい！ 1 機能が 1 時間
「JavaからRubyへ」についてそろそろ本音を書いておくか - ひがやすを技術ブログ
今回は、TKSKがおいらに乗り移って書くよ。おいらの文章じゃないので、誤解しないでね。(笑) TKSK開始 「JavaからRubyへ」を読んで、みんなおかしいとは思わなかったのかい。「Javaはフレームワークが乱立しているからだめで、RubyはRailsただ1つ(103ページ2行目)だからいいんだ」という主張がさ。 オープンソースなんだから、みんなが作りたいもの作っていいじゃん。競争があるから切磋琢磨していいものが生まれるんだろう。 お前(著者)はプロだろう。なんだよ45ページの3行目は。 激動するJavaの最新技術の動向に遅れをとらないようにするのが つらくなっていました。 選択肢の多さに圧倒されていました。情けねぇ。 今じゃ、Rubyも選択肢がいろいろあるよ。また、選択肢の多さに圧倒されるのかい。難しいことは考えられないから、無難にRailsを使い続けるのかい。それじゃ、JavaでSt
そろろろRailsについて本音を書いてみるか - ひがやすを blog
最近の大田さん@mixiのところで、Rubyについて考察する機会があったのと、よういちろうの考えと同じことを思っていたので、たまには本音で書いてみる。 Railsで、最も良いところは、テストの雛形も自動的に作ってくれて、テストの敷居を下げてくれてるところだと思う。なのに、それについて触れる人があまりにも少ないような気がする。一応、私は、1年半以上、はてなのキーワード検索で毎日Railsについては調べているので、はてなでRailsについて書いている人の記事はたいてい見ています。 理由は、いくつか考えられますが、私の読みだと、テストが当たり前の人にとっては、当たり前すぎてわざわざ書く意味がないし、そうではない多くの人にとっては、ほとんどテストは書いていないんじゃないかな。 実は、テストを書くのは結構工数かかるんですよ。スクリプト言語は、コンパイラがミスを教えてくれることはないので、Javaと比
好きを貫く - ひがやすを技術ブログ
「好きを貫く」よりも、もっと気分よく生きる方法 私は、プログラミングが好きではない。 じゃ、何でプログラマをやってるかって? 自分の力が発揮されるから。 私は大学のとき、ゴルフ部に入ったんだけど、半年でやめた。なぜって。 遠くに飛ばないから。 たぶん、ものすごく努力すれば、そこそこ飛ぶようになるかもしれないけど、きっと「そこそこ止まり」。一生懸命努力したのにそこそこってのは悲しいよね。 好きなことを極めるより、得意なことを極めるほうが、うまくいく可能性が高いと思う。 得意なことに力を発揮すると人にも喜んでもらえる。自分のやりたいことやって気分よく生きるよりも、自分の得意なことをやって人に喜んでもらえるほうが、私としては好きな生き方です。
ひがやすを blog - ドメインモデルに対する日米の温度差
ドメインモデルに対する日米の温度差 ひさびさにみたなぁ、この話題と思いつつ、コメントします。 昔書いた自分の記事をすべて読み返したわけではありませんが、どこにもトランザクションスクリプトが良いと書いたことはないはず。 この話題に関する問題の根源は、ファウラーが トランザクションスクリプトは、単純だから単純なシステムには向いている。でも、複雑な問題を扱うには、真のオブジェクト指向であるドメインモデルを使ったほうが良い。としたところにあると思います。これが、そもそもおかしい。複雑なシステムを扱うには、ドメインモデルのほうが向いているというのは根拠がない。データと振る舞いを一つにまとめることがオブジェクト指向というのも単純すぎる。 別にオブジェクト指向はこうあるべきなんていまさら議論するつもりはありませんが、私の中でのオブジェクト指向は、「それぞれのオブジェクトがきちんと割り当てられた責任を果た
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
