タグ

by-higayasuoに関するnak2kのブックマーク (18)

  • SI業界からはさっさと抜けだしたほうがいい - ひがやすを技術ブログ

    SI業界(日)のJavaプログラマーにはオブジェクト指向より忍耐力が求められている? - 達人プログラマーを目指して http://d.hatena.ne.jp/ryoasai/20110109/1294581985 をうけて自分の考えを書いておきます。 二年前なら、自分もどうしたらSI業界をよく出来るか真剣に考えていたし、NTTデータの人達と実際に話し合いもしています。 NTTデータとの真昼の対決シリーズ http://d.hatena.ne.jp/higayasuo/20080612/1213241779 http://d.hatena.ne.jp/higayasuo/20080828/1219901392 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受

    SI業界からはさっさと抜けだしたほうがいい - ひがやすを技術ブログ
  • https://twitter.com/yasuo_algo/status/6005350156

  • App Engineでバージョンによる楽観的排他制御 - ひがやすを技術ブログ

    Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま

    App Engineでバージョンによる楽観的排他制御 - ひがやすを技術ブログ
  • App EngineのEntityGroupを理解しよう - ひがやすを技術ブログ

    App EngineのEntitiGroupは、Keyの親子関係を利用して組み立てられたEntityの集まりです。 Entityとは、Bigtable上の1つの行で、ユニークに識別するためのKeyを持っています。 Keyは、種類をあらわすkindとAppEngineから自動的に採番されるidもしくはアプリケーション側で自由に決めることのできるnameで構成されます。 通常は、AppEngineの自動採番に任せますが、Emailのアドレスをキーに使いたい場合などは、nameを使います。kindはテーブル名のようなものだと思ってください。 Keyの親子関係は次のようにして作ります。 Key grandparentKey = KeyFactory.createKey("Grandparent", "しげお"); Key parentKey = KeyFactory.createKey(grand

    App EngineのEntityGroupを理解しよう - ひがやすを技術ブログ
  • 人間的魅力がない人はリーダーになれないのか - ひがやすを技術ブログ

    小野さんのところでこんなつぶやきがありました。 今九州大学の授業なんだけど、「リーダーになるためには人間的魅力が必要だと思いますが、人間的魅力がない場合にはどうすればいいでしょうか」なんという質問! この後に、清水さんの「だれでも努力次第でリーダーになれる」というのは詭弁だという話に続きます。 「だれでも努力次第でリーダーになれる」 僕はそれを詭弁であり欺瞞だと思う。 優秀な開発者になるのとも、マネージャになるのとも違う。リーダーになるのは、純粋に性格、才能なのだと思う。 この話の詳細は小野さんとこに shi3zさんが私について、「嘘を平気でつける人間」であり、それ故に「欺瞞に満ちた人間」であると言っている理由は、九州大学の授業に参加している生徒達に対して、shi3zさんが「君たちは僕のようには決してなれないから、才能ある人間の邪魔だけはしないようにしてほしい」というスタンスである(彼曰く

    人間的魅力がない人はリーダーになれないのか - ひがやすを技術ブログ
  • DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ

    Railsは、最初に素早く動くもの(scaffoldなど)を作って、そこからフィードバックをもらい、少しずつ動く状態を保ちながら、改良していくスタイルです。 スモールスタートを切るには最も向いているスタイルです。しかし、最初はそれで良かったものの、プロジェクトへの要求が増えるにしたがって、コードは複雑になっていき、だんだんメンテするのが大変になってきます。 これはRailsの問題ではなく、システムのアーキテクチャの問題です。 システムでやらなければならないことがたくさん増えたときでも、急にコードが複雑になることなく、きちんとメンテナンスし続ける方法があるなら、誰でも学んでみたいと思うでしょう。 その方法を教えてくれるのが、エンタープライズRailsなのです。 エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術 作者: Dan Chak,高井直人,笹井崇司出版社/

    DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ
  • SIerの解体と再生 - ひがやすを技術ブログ

    ござ先輩のところで、SIer涙目な状態が解説されてますね。 最近SIerがだいぶヤバくなっている件 - GoTheDistance 書いていることはだいたいあっているんじゃないかと思います。 じゃ、SIerは、どうやれば生き残ることができるのか。 「今の体制のまま生き残る必要はないんじゃないの」というのが私の考えです。多重下請け構造こそ、SI業界の最大の問題点なわけだから、「ゼネコン型SIビジネスが崩壊する」のは、悪い話じゃない。 もちろん、会社がなくなったりすると職がなくなり困る人も出てくるわけですが、問題のある業界を残しておくより、一度解体し、新たにやり直したほうがいいと思います。 だって、実際に物を作れないような人たちが設計するなんて、おかしいし、効率悪いもの。 効率の悪いことをしている人が淘汰されるのは当然の話です。 だったら、なぜこれまでゼネコン型SIビジネスが生き延びてこれたの

    SIerの解体と再生 - ひがやすを技術ブログ
  • GAE/Jは破壊的イノベーション - ひがやすを技術ブログ

    クラウドはバズワード的で何がいいのか良くわからないという人も多いことでしょう。その感覚は正しい。クラウドという言葉だけだと、意味が広すぎて、焦点がぼける。 例えば、同じように思われているAmazonのEC2とGoogle App Engineは、まったく違うものです。 Amazonのほうは持続的イノベーション、Googleのほうは破壊的イノベーション。 EC2は、過去の技術をそのまま使える(汎用的な仮想化サービス)ので、連続的な技術なのです。 それに対してGAE/Jは、できることをかなり制限して、しかもRDBMSをすててBigTableにのりかえるっていう非連続ぶり。 どっちがいいというものではありません。 クリステンセンのイノベーションのジレンマ-技術革新が巨大企業を滅ぼすときを読むと、マーケットリーダーである優良企業が、なぜ、ずっと成長を続けることができずに、破壊的イノベーションに滅ぼ

    GAE/Jは破壊的イノベーション - ひがやすを技術ブログ
  • Slim3 for Google App Engine/Java - ひがやすを技術ブログ

    Slim3をGAE/Jに対応させました。 デモサイトはこちら。 http://higayasuo.appspot.com/ ソースコードをチェックアウトしたい場合はこちら。 http://code.google.com/p/slim3/source/checkout https://slim3.googlecode.com/svn/を指定してチェックアウトできます。デモ用のプロジェクトは、slim3-demoです。 SAStrutsのチュートリアルをやったことのある人なら、デモサイトが、そっくりだということがわかるでしょう。Slim3 Struts(SAStruts相当)がGAE/Jで動くわけです。 素のStrutsだとGAEではファイルアップロードに失敗しますが、Slim3 Strutsはその辺も対応してます。 やってみて感じたのは、GAE/Jは、制限が結構厳しいので、高度なフレームワー

    Slim3 for Google App Engine/Java - ひがやすを技術ブログ
  • Seasar Conferenceのふりかえり - ひがやすを技術ブログ

    雨の中、600名の人に来ていただきどうもありがとうございました。 アンケートも一通り目を通しました。よねさんの俳句が好評で、今井さんのギャグが不評だったことが良くわかりました(笑)。 Seasar2とSlim3のすみわけについてよくわからなかったという意見がいくつかあったので、補足しておきます。Seasar Projectで、今最も人気のある組み合わせである「Seasar2.4 + SAStruts + S2JDBC」は、安定していて、機能も充実しているので、既にSeasar2を使われている人は、そのままSeasar2を使い続けて欲しいと思っています。 Slim3のターゲットとしているユーザ層は、現在Struts + Spring + Hibernate/iBatisで開発していて、生産性がいまいちあがらないなぁとおもっている人たちです。 別の言い方だと、コンテナには、Springを使いた

    Seasar Conferenceのふりかえり - ひがやすを技術ブログ
  • JPAの問題点 - ひがやすを blog

    JPAには非常に期待している人も多いでしょう。私もその一人です。実際にプロジェクトで使ってみて、見えてきた問題点を書いてみます。JPAの実装としては、Hibernate3.2を使っています。 学習コストが高い。 JPAの全機能のうち、プロジェクトで使うものに絞り込んで教育すると、3日程度で教えることができるのですが、そこそこ使えるようになるには、2〜4週間かかります。これは、Hibernate in Actionにも書いているのでそういうものなんでしょう。 トラブルシューティングが難しい。 多くのプロジェクトで実際にハマルのはこれでしょう。うちのプロジェクトでは、Hibernate職人である小林さんがいるにもかかわらずいろいろ苦労しました。Hibernate職人のいないプロジェクトで使うのは厳しいのではないかと思います。 SQLの扱いが貧弱。 JPQLは、SQLのかなり貧弱なサブセットなの

    JPAの問題点 - ひがやすを blog
  • ソースのヘッダのCopyrightを2008から2009にしたい - ひがやすを技術ブログ

    ソースコードのヘッダのCopyrightを新年になったから新しく2009にかえたいって人、いますよね。 mavenを使っていれば、簡単に書き換えられます。 詳細は、こちらをご覧ください。 http://code.google.com/p/maven-license-plugin/wiki/HowTo 簡単に使い方を書いておくと、まずpom.xmlにlicense-pluginの設定をします。 <plugin> <groupId>com.google.code.maven-license-plugin</groupId> <artifactId>maven-license-plugin</artifactId> <version>1.4.0</version> <configuration> <header>src/header.txt</header> <includes> <includ

    ソースのヘッダのCopyrightを2008から2009にしたい - ひがやすを技術ブログ
  • Slim3のトランザクション管理 - ひがやすを技術ブログ

    Slim3のトランザクション管理の部分を実装しました。 http://svn.slim3.org/browse/trunk/slim3/slim3-transaction/src/main/java/org/slim3/transaction/ 一番のポイントは、どのアプリケーションサーバで動いているかを自動で検知して、適切なセットアップをすることです。これにより、単に設定が楽になるだけではなく、同じ設定ファイルで、テストのときも番のときも動かすことができます。 設定といってもslim3_configuration.propertiesに次の一行を足すだけ。 slim3.plugins=org.slim3.transaction.plugin.TransactionPluginPluginというのは、アプリケーションの開始時と終了時に呼び出されるクラスで、通常は、Plugin#initi

    Slim3のトランザクション管理 - ひがやすを技術ブログ
  • Slim3入門 - ひがやすを技術ブログ

    Slim3 Container、略してS3ContainerのDI部分は出来上がったので、機能を軽く紹介します。 まだ、サイトのデザインが決まってないので、サイト自体がないのですが、興味のある方は、https://www.slim3.org/svnのリポジトリにアクセスすることで最新のソースを見ることができます。 はしもとさん、はやくSlim3のサイトの打ち合わせをしましょう。 S3Containerを動かすには、以下のjarファイルが必要です。 slim3-commons-xxx.jar slim3-container-xxx.jar geronimo-annotation_1.0_spec-1.0.jar geronimo-ejb_3.0_spec-1.0.jar geronimo-interceptor_3.0_spec-1.0.jar javassist-3.4.ga.jar ge

    Slim3入門 - ひがやすを技術ブログ
  • TopHatenarにみる「Javaの復活」 - ひがやすを技術ブログ

    TopHatenarを知っているだろうか。 http://tophatenar.com/ はてなユーザのRSSフィード購読者数とソーシャルブックマーク獲得数のユーザランキングを表示してくれるサイトだ。 ここ2,3ヵ年の流れだと、こういうアイディアサイト(作るに時間はかからないけどアイディアが秀逸なサイト。あまり好きじゃない言葉だけどWeb2.0系サイトともいえるかも)は、Railsで作るのがはやっていた。Railsのほうが作りやすいし、注目も集めるから。 TopHatenarは、実はJavaで作られている。フレームワークはSeasar2系だ。作者は、こういっている。 このサービスは、僕が去年末ごろから持っていたアイデアを、Cubby+Mayaa+S2JDBCの使い心地を確かめる意味を込めて実装したものです。 僕がWebアプリを作る上でのフレームワークの好みは、S2JSF、Teeda、Rai

    TopHatenarにみる「Javaの復活」 - ひがやすを技術ブログ
  • プログラミングファースト開発の必要性 - ひがやすを技術ブログ

    ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動

    プログラミングファースト開発の必要性 - ひがやすを技術ブログ
  • [Seasar Conference]「世界への普及目指す」---ひがやすを氏が新フレームワーク「Slim」を発表

    「新しいカテゴリのソフトウエアとして位置付け,英語で情報発信して世界への普及を狙う」---ひがやすを氏は2008年5月24日開催されたSeasar Conference 2008 Springで新フレームワーク「Slim(Simple, Less is More)」を発表した。 Slimは,ひが氏が開発したJavaフレームワークSeasar2の機能を絞り込んでシンプルにし,習得しやすくしたものだ。Seasar2はDI(Dependncy Injection)コンテナと呼ばれることが多かったが,DIコンテナとしては海外ではSpringが普及している。Seasar2の特徴であるホットデプロイ(Webアプリケーション・サーバーを再起動することなくプログラムの修正を反映できる)機能を前面に押し出し「ホットデプロイ可能なフルスタック・フレームワーク」という,Javaアジャイル(俊敏)な開発を行うた

    [Seasar Conference]「世界への普及目指す」---ひがやすを氏が新フレームワーク「Slim」を発表
  • プログラミングファースト開発 - ひがやすを技術ブログ

    プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら

    プログラミングファースト開発 - ひがやすを技術ブログ
  • 1