タグ

ブックマーク / shot6.hatenadiary.org (16)

  • 2012-08-20

    なんかまわりがきちんとブログ書いているのを見て、たまには書いてやろうと思った次第です。訳あって、AWS Simple Work Flowを動かして色々検証しています。SWFを一言でいうなら、非同期かつノンブロッキングなやりとりが含まれる複数コンポーネント間でのワークフローを比較的楽に書くためのサービス。それなりに奥が深いのと、実際に日語の情報が皆無なので、ひとまず動かすところまででも晒してみようと思います(先に続くかわからない・・・)。 動かす言語はJavaにするので、他言語の人はすまん。ちなみにフレームワークも利用します。AWSが出しているFlow Frameworkで、こいつはSWFを使うのを(多分)楽にしてくれる。SWF自体はワークフローサービス(というかワークフローに伴う状態管理サービスが実態に近い)なので、HTTPコールさえできればどの言語からも利用可能ではあるはず。ただし多分

    2012-08-20
    terazzo
    terazzo 2012/08/20
  • DynamoDBをちらっと触ってます - 2012-01-22 - おおたに6号機blog

    なんだかBlogをさぼり続けて早数年w 2012はもう少し書き連ねていきたいものだ。純粋に諸事情もあり、今までの10分の1以下しかないのでしょうがないのかも。ああ20代って時間あってよかったんですねw DynamoDBを触っている。パフォーマンスもそこそこ測定しているけど、データを見る限り予測できるパフォーマンスだという触れ込みは正しくて、その点は今までのNoSQLよりはやりやすい気がしている。そのうちにどこかで公開したいとは思う。もう少しデータを増やしていきたい。 ProvisionThroughputのところは、それなりに癖をおぼえないといけない気はしてる。というのも、テーブルを一度作ると、そこからのIOPSの向上は最高で100%まで、つまり現状の2倍までしか設定できない。 最初の設計段階で想定のIOPSがどの程度かをきちんと想定して測定したうえで、IOPS値を決めておく必要はありそう

    DynamoDBをちらっと触ってます - 2012-01-22 - おおたに6号機blog
    terazzo
    terazzo 2012/01/23
  • SDLoaderがめちゃ便利な件 - おおたに6号機blog

    SDLoaderというWebコンテナをT2メンバでもある、id:c9katayamaがリーダーで作っています。 このWebコンテナがかなり便利で、テストを書くとき、プロトタイプを書くときなどにとても重宝しています。 便利なシチュエーション1 サンプルに簡単なブートストラップをつける サンプルを書いて誰かに提供するときに、できるだけその敷居は下げたいものです。 たとえばEclipseでプラグインを入れてくださいといっても、忘れる人が多いのは事実。 なので、できるだけ簡単にブートストラップできることが僕としては開発時のWebコンテナに望むことです。 そこでSDLoaderですよっと。 こんな感じでさくっとブートストラップを書けます。Eclipseプラグインとか全く必要ありません。 public class SampleServerStart { /** * サーバを起動し、ブラウザを立ち上げま

    SDLoaderがめちゃ便利な件 - おおたに6号機blog
    terazzo
    terazzo 2009/09/09
  • 知っとく納得Webフレームワーク勉強会のStruts2資料でけた - おおたに6号機blog

    結局ぎりぎりになってすいません>< 資料できました。今回英語で書いて、日語に訳してみました。 なぜそんな面倒なことをするかというと、前回ASP.NET MVCやって、Slideshareにおいたときに 色々な人が見にきてくれたようで、日語じゃないものもあったほうがよいのかしらと思い立ったのでやるだけやってみました。 当然super-japanized Englishです。 ネタが今回Struts2なんですけど、今までちら見くらいしかしてなかったけど、今回まじめに中身みて意外と勉強になりました。 良い部分悪い部分が相当見えたのでやってみてよかったです。 というわけで以下にはります。英語版と日語版の順番です。 Struts2 in a nutshellView more presentations from Shinpei Ohtani. Struts2を始めよう!View more p

    知っとく納得Webフレームワーク勉強会のStruts2資料でけた - おおたに6号機blog
    terazzo
    terazzo 2009/08/27
  • yuva_akiさん報告のバグ - おおたに6号機blog

    id:yuva_akiさんからフィードバックもらいました.ありがとうございます. 内容確認しました.バグ確定です. ひとまずいくつかの理由がありそうですが、問題はT2の初期化時には純粋なClassからアクションメソッドのアノテーションなどをゲットしてるのに対して、実行時にはAOPによってクラスがT2のしらぬところでエンハンスされてそれでアノテーションが一部ロジックで取得できなくなってました.無念. というわけでまだ確定でないですが対応してみました.ちょっといれかえるモジュール多いですが、これで試してもらえないでしょうか?>id:yuva_akiさん commons SNAPSHOT commons SNAPSHOT source T2 SNAPSHOT T2 SNAPSHOT source S2Adapter SNAPSHOT S2Adapter SNAPSHOT source 確定版の修

    yuva_akiさん報告のバグ - おおたに6号機blog
    terazzo
    terazzo 2009/08/24
    これはエンハンスする奴がアノテーションをコピるべきな気もする。でもそれだとフィールドに対するアノテーションが探せない。Interceptorベースで動いてるんならMethodInvocation経由で元クラスを取れるんだけど。
  • 2009-08-11

    VMWareがSpringSourceを買収しました. 今年の後半(Q3)にどうやら全て完了する予定のようです. 続きを読む というわけでTwitterでのつぶやきの続きものせてみた。 続きを読む T2 0.6.0-gaをリリースします。 それにあわせて、ドキュメントもWikiベースで大きく更新しました。 ドキュメント GoogleWikiで書きなおしました.勝手に国際化されるのがGoodです. http://code.google.com/p/t-2/wiki/Index 変更点 大きな変更点としては、 T2でFlexやAMFを喋るクライアントからAMFを使った通信が簡単に出来るようになりました. URLマッチングのバグを多数修正しました コンテキストルートにPageクラスを割り当てるなどのケースも対処しました 変更点は下記にまとめています。 http://code.google.com

    2009-08-11
    terazzo
    terazzo 2009/08/11
  • JavaDoc i18nにする方法 - おおたに6号機blog

    T2のJavaDocのために、幾つかJavaDocをi18nにする方法を試してみましたのでここに書いてみる。 何をやろうとしているかというと、JavaDocを英語、日語両方で出力したいという割と単純かつよくありそうな要望です。 localized docletを使う方法 最初に試したのがこれ。Doclet拡張ですね。 簡単に言うと、日語部分には{@.ja }、英語部分には{@.en }で括る。 記事としてはこれが最初に読んだやつです。 http://www.ibm.com/developerworks/jp/ysl/library/java/y-j-inlinetaglet/ プロダクトとしてはid:skimuraさんが出しているのでこちらを利用しました。ありがとうございます。 http://code.google.com/p/localizable-doclet/ メリット 比較的簡

    JavaDoc i18nにする方法 - おおたに6号機blog
    terazzo
    terazzo 2009/07/17
  • 2009-06-06 - おおたに6号機blog - Google Sitebricks

    JavaOneでGoogleの新しいWebフレームワークが発表されたみたいですね。 その名もSitebricks。GWTベースのようです。 まずは見てみてください。JavaOne資料から抜粋。 POJOコード。 class MyPage { @Property String meaning = “17”; } テンプレートはこちら。 <body> The meaning of life is: ${meaning} </body> PageとURLをマッピングして、そのプロパティがJSPのELでマッピングといったところ。 とまあここまではまあ普通。 ところが、例えば以下のようなtypoをすると、コンパイルエラーになります。 どうやらコンパイル時にチェックするみたいですね。 型の不一致とかもチェックするみたい。 class MyPage { //typoしてるよ! @Property Str

    2009-06-06 - おおたに6号機blog - Google Sitebricks
    terazzo
    terazzo 2009/06/09
    これはやられたなー>コンパイルタイムソリューションでテンプレートとPageを結びつける/当たり前のようにテンプレート編集時にIDE上で補完とかもできそうだ
  • クラウドはパラダイムシフトとなりうるか - おおたに6号機blog

    僕の答えは明快で、クラウドはパラダイムシフトとなり得ると思います。 理由は2つ。 1つは、MapReduce(概念自体は非常に古いんだけども)のような新しい可能性を示唆できるプログラミングパラダイムが 出てきている事。これによって、現状の段階的進化を飛び越える可能性が出てきた事。主に大容量のWeb上のデータ解析と それをベースとした未来への付加価値をソフトウェアで構築するシステムにエンハンスできるという可能性です。 ここまでは誰もが関心を持ってると思います。 そして2つ目はベンダがきちんとビジネスとして成り立つものが出てきている事。 きちんとした事業の継続性を考えると、ベンダがきちんと適正に儲かるのはとても大事です。 Javaが流行した理由も大きくはJavaに関わるベンダが企業努力した分きちんと儲かるからです。 そういう仕組み、今の言葉でいうとエコシステム、が出来たことがこれだけエンタープ

    クラウドはパラダイムシフトとなりうるか - おおたに6号機blog
    terazzo
    terazzo 2009/05/02
  • 2009-04-01

    JR東日が全面禁煙になったこの4月みなさまどうお過ごしでしょうか。 突然ですが、T2メンバ全員、はてなidをより適切な名前に改名することにしました。 なぜid変更か。ことの発端は、T2メンバのjad疑惑にあります。 Seasarカンファレンスの打ち上げにて事件は起こりました。T2メンバによる内部告発です。 私は参加できずに又聞きなのですが、こともあろうにデコンパイラツールjadによって、 あるT2メンバが某Tomcatや某Strutsなどをjadって中身を解析し、それをピーコして流用していたという事実が発覚しました。 そこで、T2メンバのはてなidは今の名前はふさわしくないんジャマイカというDisりを関係各位から頂きました。 それを受け、全員丸坊主的な意味も含めまして、心機一転、新しいidで再出発することにしました。 新しいidは以下のようになります。 id:shot6 → id:ja

    2009-04-01
    terazzo
    terazzo 2009/04/01
    ばれた理由を予想→コメントが無い/開始波括弧が新行にある/フィールドの宣言が後ろにある/フィールドの初期化がコンストラクタ毎にある/定数を宣言してるのにコード中ではリテラルを使用
  • 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

    2008-12-16
    terazzo
    terazzo 2008/12/16
    物事のシンプルな構造を(言い換えれば「本質」を)切り出すことと、それを出来るだけ簡潔に(最少の語彙と最少の語数をもって)記述することが仕事だと思ってる。
  • Architect also implementsなのだ。 - 2008-10-28 - おおたに6号機blog

    アーキテクトとか言うと何様的に思う人もいるかもしれませんが、全体構成を決めるという 意味でアーキテクトは重要なロールです。ロールなので実体が誰であるかはともかくとしても。 アーキテクチャとは何か、その深淵な話題に自分が触れられるほどのもんだとは とても思えないですが、下記の平鍋さんと萩原さんのお話は読んでおくべきことだと感じました。 実際にXPなどの手法でアーキテクチャは段階的に育てていく人と、ある程度初期から形を作りこむ人といますが、 実際に作るときにはそのバランスを取るはずです。 アーキテクチャを決めないで実装の結果をアーキテクチャですとすると、それを使う方が変わっていく様が 激しすぎてついていけないというリスクがある。アーキテクトの一存とその実装方法にゆだねられてしまう。 かといって、アーキテクチャをがっちり決めすぎる(所謂BDUF(Big Design Upfront))と、今度は

    Architect also implementsなのだ。 - 2008-10-28 - おおたに6号機blog
    terazzo
    terazzo 2008/10/30
  • 2008-10-23

    ひがさんのDIコンテナはEJB3.1でコモディティ化するという意見には賛同しかねるなあ。 自分はあんまりDIコンテナがEJB3を中心にコモディティ化するとは思わない。 何故なら、EJB3を初めとするJavaEEの仕様がそこまで受け入れられてるわけじゃないからです。 もう少し言えばJSF+EJB+JPAの組み合わせが残念ながら受け入れられてない。 海外では標準として受け入れられているかもしれないけど、標準なら標準のまま使うのが 王道でしょう。それか全体を統一してしまうSeamかなあ。 今後JavaEE5のAPサーバが出て、日でも標準としては間違いなく今よりは 使われるようにはなると思います。その意味でJSF+EJB3+JPAは覚えておいて損は無いです。 しかし、標準からずれてわざわざOSSを使うのであれば、それなりに標準よりメリットが なければ利用者にとって意味がありません。OSS開発する

    2008-10-23
    terazzo
    terazzo 2008/10/23
    StringがUnsupportedEncodingExceptionに依存も。というかなんでIOExceptionなんだろう。
  • 2008-07-25

    いまかなり理想論的なことを言っているが、この件はみなさんおおいに議論して欲しいと思う。 このブログでも再三言ってきているように、欧米からパッケージやソフトウエアを買ってきて、 人月作業は中国・インドにもっていくなんていうモデルはくやしいと思いませんか。 http://kamawada.com/~masanori/blog/2008/07/post_523.html mark-wadaさんに釣られて色々意見が出てくるかとおもいきや、 なんだか意外と意見が出てきていないようなので、自分の意見をマジレスで書いてみる。いつもそうだけど。 自分の意見では、プログラミングファーストは現在のSI開発では(そのままでは)導入できないと思う。 自分の前提は10人以上の開発者が入る(ピークはその数倍以上)感じの中・大規模案件程度ね。 プログラミングファーストはまず幾つかの前提があるように思う。 お客さんがある

    2008-07-25
    terazzo
    terazzo 2008/07/25
  • URI Templateにあやかって、T2のTemplate - おおたに6号機blog

    なんか世の中URI Templateブームらしい(?)のでおいらが作ったURI Templateをご紹介♪ 元ネタは.NETのUriTemplateですw あれがなかなかシンプルで素晴らしかったのでJavaにポーティング。 基的な使い方は3つほど。テンプレートのELのキーと実際の値のマップを取るやつと、 位置でバインドしてURL生成するやつ、あとは名前でバインドしてURL生成する奴。 まずテンプレートと実際のURLの値のマップがほしければ、 UrlTemplateImpl template = new UrlTemplateImpl("/hoge/{foo}"); Map<String, String> map = template.parseUrl("/hoge/moge"); なかんじ。戻ってきたマップのキーは{foo}で値はmoge。 位置でバインドして、URL生成したいなら、 U

    URI Templateにあやかって、T2のTemplate - おおたに6号機blog
    terazzo
    terazzo 2008/07/17
  • フレームワークのジレンマ - おおたに6号機blog

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

    フレームワークのジレンマ - おおたに6号機blog
    terazzo
    terazzo 2008/06/27
    削った機能をリリース版のフレームワークで実現するコードをサンプルで付ければサンプルも充実して良いかも
  • 1