2008-12-16
LucyのCoreとAOPを分離して、プロジェクトの構成もmavenのマルチプロジェクト構成にしました。 これ、ソースフォルダが増えまくるので嫌なんですけど、まあこれも諸行無常ということで納得。 実をとれっちゅーはなしのようで。 というわけで、構成変えてデプロイしてみました。 Lucy-core http://maven.t2framework.org/maven2-snapshot/org/t2framework/ioc/lucy-core/0.4.1-SNAPSHOT/lucy-core-0.4.1-20081215.042156-1.jar Lucy-aop http://maven.t2framework.org/maven2-snapshot/org/t2framework/ioc/lucy-aop/0.4.1-SNAPSHOT/lucy-aop-0.4.1-20081215.0
2フェーズコミットと分散トランザクション - おおたに6号機blog
2フェーズコミットと分散トランザクションの日本語のさっと読めるサイトなら、この辺よいですよと獄長に教わりましたｍ（＿ ＿）ｍ 5.X/Open の分散トランザクション処理参照モデル とかちゃんと知らなかったっす・・・・ http://www.ogis-ri.co.jp/otc/hiroba/technical/DTP/step2/index.html http://www.datadirect.co.jp/SupportLink/dev_center/jdbc/topics/jta （追記） 2フェーズコミットとその最適化として、あわせて読みたい 「2 フェーズコミットと Logging Last Resource，特許とオープンソース」 http://d.hatena.ne.jp/koichik/20081204#1228395633 ちょw、いま気づいたけど小林さんのblogが業務連絡
Webフレームワーク勉強会開催 - おおたに6号機blog
株式会社フルネスさんのご協力もあって、 今回Webフレームワークの勉強会を開催します。フルネスさん、ありがとうございますｍ（＿ ＿）ｍ 開催概要はこちら。 タイトル：知っ得 納得 Webフレームワーク 講師 ：米林正明さん （株式会社ABBY：http://www.abby.co.jp/） 概要 ：昨今、さまざまなJavaフレームワークが乱立していますが、実際にどれを使ったら良いか頭を悩ます 機会も多いのではないでしょうか？ 本勉強会では、Teeda, S2Flex, SpringMVCを実際に実案件で採用したことのある講師や現在進行 プロジェクトであるT2のコミッタを迎え、知って得する情報を交えながら、フレームワークの利点・欠点、 実践的な内容などを計3回に渡り開催します。 日時 ：11/19(水) 19:00〜20:30 場所 ：高円寺 フルネストレーニングルーム（http://www
Architect also implementsなのだ。 - 2008-10-28 - おおたに6号機blog
アーキテクトとか言うと何様的に思う人もいるかもしれませんが、全体構成を決めるという 意味でアーキテクトは重要なロールです。ロールなので実体が誰であるかはともかくとしても。 アーキテクチャとは何か、その深淵な話題に自分が触れられるほどのもんだとは とても思えないですが、下記の平鍋さんと萩原さんのお話は読んでおくべきことだと感じました。 実際にXPなどの手法でアーキテクチャは段階的に育てていく人と、ある程度初期から形を作りこむ人といますが、 実際に作るときにはそのバランスを取るはずです。 アーキテクチャを決めないで実装の結果をアーキテクチャですとすると、それを使う方が変わっていく様が 激しすぎてついていけないというリスクがある。アーキテクトの一存とその実装方法にゆだねられてしまう。 かといって、アーキテクチャをがっちり決めすぎる（所謂BDUF（Big Design Upfront)）と、今度は
リッチなアプリ開発はデータバインディングが一つのキモがGood！ - おおたに6号機blog
どうも。夏休みボケなDQNです。 id:kagamihogeさんの「リッチなアプリ開発はデータバインディングが一つのキモ」が 非常によいエントリです。 とりあえず重要なのは、Web ベースの業務アプリの流行の一つに、 再びクライアント側重視の流れがあるらしいこと。Web アプリは、サーバサイドで 色々ゴチャゴチャ処理したあと最後にヴァーンと html を吐き出して終わり、というシンプルなのが 基本形である。しかし、Ajax, Flex, Silverlight などなど―どんな技術を採用するのかの 違いはあるが―こうしたリッチな技術を使う場合、データ表現は html、サーバ側で何がしか処理、 とシンプルな分離だけでは収まらなくなる。 http://d.hatena.ne.jp/kagamihoge/20080925/1222337488 この辺に激しく同意ですね。言い方を変えれば、クライア
2008-08-11
一時ネットワークとかインフラ屋さん目指してたので、再度復習がてら。 相当量の知識・ノウハウが押し込まれているのに関わらず3000円とは驚異的。 OSSなプロダクトが中心ですが、考え方も含めかなり応用が利くと思う。 夏休みのお供のつもりが大分読んでしまいました＾＾； [24時間365日] サーバ/インフラを支える技術 ?スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ) 作者: 安井真伸,横川和哉,ひろせまさあき,伊藤直也,田中慎司,勝見祐己出版社/メーカー: 技術評論社発売日: 2008/08/07メディア: 単行本（ソフトカバー）購入: 133人 クリック: 2,270回この商品を含むブログ (288件) を見る ちょー要約。（というか勝手な解釈） ・「Hello World」を書くだけなのに、たくさんコードを書く必要がある。 ・命名規則を覚え
2008-07-24
Blogを書くことで何を得られるんだろ？というのはずっと考えてたので 自分の意見を述べてみる。 Blogを書くことで何を得ることが出来るか。アルカーナさんのミッションに近しいことを書くけど、 それは人と人とのつながりだと思います。とても有意義な。発信者は基本的に損な役割です。 常に１人でしかない。Blog上は「gothedistance 対不特定多数の読者｣という構造になる。 その不特定多数の読者の方のコメントが仮に５０個あったら、僕は１人でその５０個のコメントと 向き合わなくてはならない。こんな経験は実社会でもまず出来ないため、 ものすごく自分にパワーを求められる。 http://d.hatena.ne.jp/gothedistance/20080723/1216784650 これに近しい感覚を今では自分も持っている。 ちょっと前までは軽い気持ちでいろいろBlogに書いちゃダメなんだと思
2008-07-25
いまかなり理想論的なことを言っているが、この件はみなさんおおいに議論して欲しいと思う。 このブログでも再三言ってきているように、欧米からパッケージやソフトウエアを買ってきて、 人月作業は中国・インドにもっていくなんていうモデルはくやしいと思いませんか。 http://kamawada.com/~masanori/blog/2008/07/post_523.html mark-wadaさんに釣られて色々意見が出てくるかとおもいきや、 なんだか意外と意見が出てきていないようなので、自分の意見をマジレスで書いてみる。いつもそうだけど。 自分の意見では、プログラミングファーストは現在のSI開発では（そのままでは）導入できないと思う。 自分の前提は10人以上の開発者が入る（ピークはその数倍以上）感じの中・大規模案件程度ね。 プログラミングファーストはまず幾つかの前提があるように思う。 お客さんがある
RIA時代のプレゼンテーション層 - おおたに6号機blog
id:da-yoshiさんの素晴らしいエントリを読んで呼応。 確かに私もRIAを使ったシステム開発がいよいよ本流になりつつあるなという気がしています。 その主流はFlex/JavaScript/Silverlightでしょう。 いまのところ、自分はFlexを一番にお奨めしていて、次にjQueryやExtJSを使ったJavaScript、 その次にSilverlight2をお奨めしています。この辺は個人・会社さんによって各々優先度つけるところです。 多分JSまわりは知れば知るほど、使い勝手がよくなって、もしかしたらFlexを 抜く可能性もあるかもなあとはちょっと思ってますが。 IDEサポートなどを考えるとFlexは今のところ一番楽だとおもう。 しかしRIAを使うと責務の分担が難しい。そう考えています。 よりいっそうクライアント側で出来ることが増えるため、明確な指針が無いと開発を 円滑にまわし
良い残業 続編 -個人で力をつける習慣の威力- - おおたに6号機blog
これだと残業と変わらないと思う．場所が自宅に移っただけで，仕事のためのものを 個人の時間でやること自体が問題．つまり，残業代が出ない分不利かと． 残業して勉強したほうがましです．もっとも，残業しないでやるのが望ましいわけで，つまり・・・ http://d.hatena.ne.jp/shin/20080718/p3 一応自分のblogでも回答しておきます。 たぶんshinさんの言っている勉強と自分の言っている勉強があってない感じ。 勿論仕事で即必要であれば業務時間内にやりくりしますよ。それもなるべく残業なしで、します。 それは業務の一貫として自分は捉えてます。 しかし、それ以外にも自分のモチベーション的にやりたいこと・やるべきだと思うことって いっぱいあるわけです。未来の自分に対する先行投資の一種でしょう。 例えば、一例あげれば自分にとってPythonやDjangoは明らかに先行投資です。
2008-07-18
じゃあどういう残業が人を成長させ、あるいは人を潰すのか。 良い残業というのは、頑張った分だけ評価され、プログラムがどんどん出来上がっていく達成感があり、 結果的に本人のモチベーションが高く保てるようなタイプの仕事。こんな開発チームならきつい状況でもけっこうなんとかなったりする。 たとえば文化祭前夜のような、クラス一丸となって異常なテンションの中、ひとつの目標に向かって深夜まで没頭する感じ。 あんな気持ちでカットオーバーを迎えられればそれは良い経験になるよね。 http://d.hatena.ne.jp/aike/20080717 確かに評価されるっていうのはその当人にとってはありがたいと思うし重要なことだけど、 企業としてはそれでいいのかな？それで利益が出るの？顧客にとってはいいことなの？ 本人の家族にとってはどうだろう？友達との付き合いもなくなるけど？何より自分を豊かにする時間は？ 極論
2008-07-09
せろり（id:cero-t）の娘さんが「ぽっちゃま」が大好きということで、 調べてしまったｗ 続きを読む 今回はUTについてです。 ここでいうUTは主にxUnitの話です。 フレームワークのようなある程度期間が長くいろいろなコンテキストで使われるものの場合、 自動回帰テストは欠かせません。これをUTレベルでサポートするのがxUnitです。 また、開発促進のためのやりたい事を明確にするのもxUnitあってのことです。 TDDのような手法を実現しようとすると事前にテストを何かの形で明記しておく必要があり、 それが動く仕様となって仕様の番人となります。 続きを読む 0.3である、コードネーム「Diet」に向けての絶賛調整中です。 機能のブラッシュアップとサブプロジェクトの分離が目下の課題。 「Diet」は機能を極小化するのを目標にしてて、こいつをまずはリリース対象としたいなと考えてます。 リリー
2008-07-06
さすがにOSI参照モデルまで疑おうとすると範囲が広すぎてしまいますが、 (X)HTML、JavaScript、CSSに絡むテストケースはいわばクライアントの影響を もろに受ける部分な訳で（Flexならなおのこと）、これを業務ロジックとかRDBMSとの連携の部分と いっしょくたに取り扱おうとしても、そもそもがきれいに結びついてくれないと思います。 という訳で、プログラム自体をなるべく小分けにして、個別にテスト出来るようにすることでまずテストケースの組み合わせ爆発を防ぎ、かつクライアント向けのコードとサーバ・サイドのコードと同じ視点で扱わなくても良いような設計にしてあげないといけないな、と。 (途中略) それよりも、フレームワークという単語が指し示す「枠組み」としての側面を強調して、生産性というか作業効率に寄与するようなものを目指さないと、ですね。 http://d.hatena.ne.jp/
2008-07-02
新戦略の中でオラクルが「戦略的製品」として挙げた20製品のうち、 旧BEA製品がそのままの形で残ったのは5製品。 Webアプリケーションサーバー「BEA WebLogic Server」の関連3製品と、 Java仮想マシン「BEA JRockit」、トランザクション処理モニターの「BEA Tuxedo」だ。 新名称はそれぞれ、「Oracle WebLogic Server」「Oracle WebLogic Suite」 「Oracle WebLogic Application Grid」「Oracle JRockit」「Oracle Tuxedo」である。 http://itpro.nikkeibp.co.jp/article/NEWS/20080702/309935/ ということは旧OASは無くなるってことなのかな。 OAS残留はわからないけど、WebLogicが残るのは確定みたいなので
フレームワークのジレンマ - おおたに6号機blog
フレームワークを作っている人にはいつもあるひとつのジレンマがあるんじゃないでしょうか。 それは機能追加によるフレームワークの肥大化です。 ユーザさんから言われた機能・自分達のチームでこれは良い！と思って入れた機能など 理由はそれぞれですが、フレームワークが形になってからの機能追加は進む一方です。 機能が増えればそれだけ故障箇所が増えるのと一緒です。また想定しない使い方をユーザさんが してくる場合もあるでしょう。 自分もこのような機能追加は正しい・求められているんだとずっと思っていました。 今でも間違ったことだと思ってるわけではありません。 ただし、それには大きな前提があることにちょっとだけ気づいたのです。 それは、 最初に開発されたフレームワークの機能は十分に検討され、 厳選されたミニマルセットな機能以外はあってはならない。 という前提です。書いてみれば当たり前で拍子抜けされるかもしれませ
2008-06-24
時間をたっぷりとるのはいいんだけど、学生との討論会を2セットやるよりも、 もう1セットは、SI業界の重鎮との討論会のほうが面白いと思うんですが、 みなさんの意見をお聞かせください。 http://d.hatena.ne.jp/higayasuo/20080623/1214197466 実は1セット目はアルファギーク枠なんですが、 しかし2セット目は197x枠で企画をもちかけてました。 というわけで197xグループで「日本のSI業界のリアル現場な人たちと学生との交流会」をやる予定です。 そう、ひがさんとほぼ同時期に197xグループでも技術評論社さんに企画を持ち込んでたりするんです。 技術評論社さま、ありがとうございます。 それもほぼ予想通り、アルファギークたちが理想論ポジティブな未来をしゃべってた後に 日本のSI業界のリアルな開発の現場はどうなってんだい？ほんとのところどうなってんの？という
2008-06-17
思考のカタを身に着ける、こういうのも非常に大事だろうなあと思いつつ、勝間さん最新本買いました。 内容は今までの勝間さんの本の中でも特に考え方・どのように考えるかという点で絞られていて、 自分にはフィットしそうです。ロジカルシンキング系のスキルを伸ばしたいという方にはお奨め。 続きを読む 出ましたね！ようやく日本語も正式対応です。 http://www.adobe.com/jp/products/air/ む。FlexSDKも更新しなくちゃいけないのですね。今日にはFlex SDK3.0.2が出るとのコト。 待ってます、待ってますよぅ〜〜 http://weblogs.macromedia.com/akamijo/archives/2008/06/air_11.html 昨日のエントリ「BlazeDSをDisる（っていうのはうそでBlazeDSで使いにくいところ）」の自分なりの解。 それがこ
小学館を金色のガッシュの著者が提訴 - おおたに6号機blog
この訴訟、漫画原稿というところじゃなくプロの仕事とその受けとり手の話として 読むと非常に面白いです。もっといえば違う能力をもつプロ同士の共同作業としての漫画執筆というのかな。 最近漫画の質が落ちてきているんじゃないかなあと思ったりするのも もしかして昔ほど作家と編集の間でのよい意味での衝突が少なくなってるために、 作品の練り込みが足りなくなってきているんじゃないかなあとちょっと思ったりもします。 この辺にあつい思いが入ってるなあ。 漫画家さんの実力をフルに出すにはプロの編集さんがいないといけないんだよって思いが伝わってくる。 もう、これ以上漫画家は編集者に馬鹿にされてはいけない。まともに仕事相手としてみなければいけない。 漫画雑誌では当たり前だが、漫画家がいなければ造れない雑誌である。普段漫画家を見下して馬鹿にしている編集者も、 絵は描けなくても漫画原作者として一人立ちし、漫画雑誌を支えろ
2008-05-19
んー、マーケットどころか社員からも受け入れられてないなんて・・・・・ http://www.infoq.com/jp/news/2008/05/sun-deflextions-continue 業務システムにOOはほとんど必要ないと考えている断然トランザクションスクリプト派の わたしですがｗ、下記の説明をみても従来のトランザクションスクリプトとの違いがそんなにない気がする。 DDDのServiceパターンはエンティティとして扱えないものだけを どのように一貫して抽出するのかというのがポイントになりそうだけど、 どの時点で扱えないと判断するのかが明確じゃないように思うので、抽出基準が きちんと定まらず使いにくいんじゃないすかね。 というわけで、おいらは過去から一貫して、トランザクションスクリプト派で、 かつレイヤ的には Pageモデルを使うならば、Page（副次的にActionが入る余地あり
2008-04-18
ちょっといまいちな部分もあるかもだけど、10分での超訳なので勘弁。 あとは原文も読まないと駄目だわ。文脈がよみとれん。 1.REST posits an interconnected information ecosystem, not an isolated set of point Web services. RESTはWebサービスの相互接続に使うべきものであって、単独のWebサービスに使うものではない。 2.A focus on Design for Consumption instead of Design for Integration. RESTは統合のためのデザインではなく、リソースを消費するため（表現する、かな？）のデザインに注目すべき。 3.REST security is egalitarian and is as secure as the Web itself.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
