GAE/Jは破壊的イノベーション - ひがやすを技術ブログ
クラウドはバズワード的で何がいいのか良くわからないという人も多いことでしょう。その感覚は正しい。クラウドという言葉だけだと、意味が広すぎて、焦点がぼける。 例えば、同じように思われているAmazonのEC2とGoogle App Engineは、まったく違うものです。 Amazonのほうは持続的イノベーション、Googleのほうは破壊的イノベーション。 EC2は、過去の技術をそのまま使える(汎用的な仮想化サービス)ので、連続的な技術なのです。 それに対してGAE/Jは、できることをかなり制限して、しかもRDBMSをすててBigTableにのりかえるっていう非連続ぶり。 どっちがいいというものではありません。 クリステンセンのイノベーションのジレンマ-技術革新が巨大企業を滅ぼすときを読むと、マーケットリーダーである優良企業が、なぜ、ずっと成長を続けることができずに、破壊的イノベーションに滅ぼ
GAE/Jで日本語を使う方法 - ひがやすを技術ブログ
GAE/JでJavaのソースコードやJSPに日本語を使うと、ローカルの開発サーバ上では問題ありませんが、クラウドにアップロードするときに、プラットフォームのエンコーディングでコンパイルしようとしてUTF-8を使っている場合は失敗します。 これに対応するには、appengine-web.xmlのシステムプロパティに <property name="file.encoding" value="UTF-8"/> <property name="DEFAULT_ENCODING" value="UTF-8"/>を追加します。 http://www.jxva.com/blog/2009-04/change-the-google-app-engine%27s-javac-compiler-encoding.html 何語で書かれているのか良くわからないけど。 これで、確かにアップロードには成功するよう
オープンソースはそんな殺伐としたものじゃない - ひがやすを技術ブログ
どんな行動をとる時も、世の中に作品を出すというのならば常に敵の存在を意識しなければならない。 shi3zの言いたいことはわかる。自分のソースコードがコピーされて、それがコピーした人のオリジナルのようにいわれたら、誰だっていい気はしないだろう。 でも、あえて言っておこう。オープンソースの基本は、オリジナルのコピーと、それに対する改善なのだと。100%オリジナルのアイディアなんて見たことない。 これはオープンソースに限った話ではなく、たいていのものは、偉大な先人たちを真似たものだ。コピーすることにより、技術が伝承していく。 オープンソースがすばらしいのは、コピーすることに制限が余りない(ライセンスによる)ことだ。先人の良い点を学び、また、後に続く人が参考にしやすいようにソースコードを公開する。 自分もオープンソースから多くのことを学んだ。だから、自分で学んだ成果も、次の人のために公開する。 こ
成功するかどうかは100%運、でも努力によって成功する確率はあげられる - ひがやすを技術ブログ
オープンソースのフィールドで認められ、その功績が会社にも認められて、収入につながる。ひが氏はそれを実践してきたわけだが、実際には「レアケース」といわねばならないだろう。個人の頑張りだけで、このようなキャリアを積むことは可能なのだろうか。 ひが氏は「運ですね」と断言する。 「運以外の何物でもない。例えば、わたしがいまとまったく同じスキルのまま、生まれ変わって何かをしたとき、また同じように成功するかというと、成功しないと思っています」 ＠IT自分戦略研究所に私が受けたインタビューが出てますね。このインタビューで私が伝えたかったのは、成功するかどうかは100%運。でも努力によって成功する確率はあげられるということです。 「成功しやすさ」の確率を上げることはできる。どうすればいいのか。それは「常にチャレンジを続けること」だ。 「宝くじは買っておけ、ということ。宝くじはほとんど当たらないものだけど、
HOT deployで嵌らないためのパッケージ構成 - ひがやすを技術ブログ
Slim3では、ルートパッケージ直下がagileパッケージとfirmパッケージに分かれます。agileパッケージには、agileに開発する必要のある機能要件に応じたクラスが入ります。firmパッケージには、ユーザの要件には直接関係しない非機能要件に応じたクラス(一般的にはインフラストラクチャ層のクラス)が入ります。 例えば、ルートパッケージがtutorialの場合、次のようになります。agileとかfirmの名前はもちろん自由に選べます。 tutorial root package tutorial.agile agile package tutorial.agile.action agile package for action tutorial.agile.xxx agile package for xxx tutorial.firm firm package tutorial.fir
Railsバブルの崩壊? - ひがやすを技術ブログ
アメリカでRuby関連の書籍の売り上げが減速していることが話題になってますね。 米国でRuby関連書籍の売り上げが減速か − ＠IT これで、Rubyの人気が落ちていると判断するのは、かなり早計すぎる結論です。たとえば、Google TrendsをみてみるとRubyの検索数はほとんど変わっていません。 じゃ、なぜRuby関連の書籍の売り上げが減速しているかというと、たぶん、Railsバブルが崩壊したからじゃないかなと思います。事実、Railsの検索数は、2006年をピークに減少傾向にあります。 でも、これは悪い話じゃないと思うんだよね。バブルが崩壊しただけで、Railsそのものは、地に足をつけて使われているように思います。 私は、2006年ごろから、はてなキーワードで、Railsについて書いている人の内容を見ていますが、最初のころに比べると、確かにエントリ数は減ってきている気がします。ただ
JavaでRailsのflash機能を実現する - ひがやすを技術ブログ
Railsのflash機能とは、次のページまでは保持されている変数で、次の次のページでは、消えてしまいます。主に、リダイレクトでエラー画面に遷移して、メッセージを一度だけ表示したいような場合に使います。 Strutsで、このような機能を使いたい場合は、セッションスコープのActionMessagesを使います。 生Strutsを使う場合は、Action#saveMessages(HttpSession session,ActionMessages messages) SAStrutsを使う場合は、ActionMessagesUtil#saveMessages(HttpSession session, ActionMessages messages) を呼び出せばOKです。 意外にみんな知らないんだね。Twitterで困っている人がいたから書いてみた。
自分の書きたいコードを書け - 脱職業プログラマのすすめ - ひがやすを技術ブログ
良く仕事以外のプログラムをしたことない人っているじゃないですか。ここでいう職業プログラマとは、仕事以外では、プログラムをしない人のことを指しています。 仕事以外でもプログラミングをしている・勉強している人、は、職業Onlyプログラマではなく、職業でもプログラムをしているけど、それ以外にも努力をしている人です。 それは、もちろん何の問題もないんだけど、それだけでは実力はつきません。たぶん、コードを書きながら自分が成長している気がしてないでしょう。あなたの直感は正しい。 何らかのフレームワークを使えば、それなりにできることが増える、それももちろん成長です。ただし、知識のね。プログラミングの力はそれほど変わっていないはず。 自分の経験で言えば、多くの人に読んでもらえないコードは、いくら書いても、実力につながりにくい。人に見せようとするコードは、書いているだけで、いろんなことを考えるし、それが、力
進化し続けることはオープンソースにとって必須なわけではない - ひがやすを技術ブログ
「毎日毎日動きを続けていると、適切な大きさの問題がつぎからつぎに生まれる」 「それさえ生まれれば、インターネット上にはそれを解決する人が現れる。新聞にクロスワードパズルが載っていたらそれを解く人がいるように、それをみんなが解いていく」 それがオープンソースなんだと。 出展はこちら。 http://www.1101.com/umeda_iwata/2008-11-18.html もともとは、Matzともっちーの対談から生まれたものですね。見たことある人も多いでしょう。目からうろこが落ちた人は少ないかもしれないけど。 Rubyについていえば、上記のことは正しいと思います。Rubyが成功しているのが一番の証拠。ただし、それがオープンソースのすべてなわけではない。オープンソースは、そんな一言で語れるものではない。 別に俺が正解を知っているわけじゃないけど、機能が足りないうちは、いろんな人にその問題
Seasar2とSpringの将来性 - ひがやすを技術ブログ
それにS2よりもSpringの方が圧倒的に寿命が長そうに見えますし、HotdeployのためにS2覚えるの？Javarebelが普及して無料で使えるようになっちゃったらS2に移行したコスト意味なくない？とか言われると正直言葉につまります。 JavarebelのHOT deployの実装を見ればわかると思いますが、リクエストのたんびに全コンポーネントをデプロイして破棄していると思います。これでは、クラス数が増えると使い物になりません。 試してみるとわかると思いますが、component-scanは、重い処理なので、リクエストのたびに呼び出すのは、あまり現実的ではありません。 これに対し、Seasar2では、そのリクエストで必要とされたコンポーネントしかデプロイしないので、デプロイの負荷がかなり減ります。規模が大きくなってもそれに影響されないということです。 現実の案件で使うためには、Spri
「Seasarの問題点など」にそろそろ一言いっておくか - ひがやすを技術ブログ
2009-01-29 最初に言っておくと、結構いい指摘だと思います。せっかくなので、私のほうでも答えましょう。 だから、メンテナンスの不安の問題は、メンテナンスが行われてないということではなくて、メンテナンスが行われているのにメッセージとして発信されていないということだと思う。 ひがさんは上にあげた以外にもちょこちょことSeasar2のメンテナンスは続けられるということをブログに書いているのだけど、やはりブログという刹那的な形態ではなく、公式サイトに常設されたメッセージとしてメンテナンスをやっていくよということを書いていないといけないと思う。 これは、おっしゃるとおり。ただ、こういう政治的なメッセージは、理事会のほうから出したほうがいいと思います。そういう流れで、打ち合わせも進んでいたはず。 私は、プロダクトを作ることに専念するために、理事を辞めたので、プロダクトを作ることに専念したい。そ
Seasar2の継続性 - ひがやすを技術ブログ
某掲示板で、Seasar2の継続性の話が出てたんで、この辺の実際を書いておきましょう。あくまでも、私が書いているので、主観的な意見ですが、そんなに外れてもいないでしょう。 ここでいうSeasar2とは、主要プロダクトのS2Containerのことです。 Seasar2の継続性はきわめて高いはず。なぜなら、ISIDがスポンサーになって、主要なコミッタを雇っているから。ISID自身の基幹システムもSeasar2で再構築しようとしているし、Seasar2を使った社内案件(ISIDがプライムのSI案件)もあるので、サポート力を維持するためにも、ISIDがスポンサーから降りることは考えにくい。 昼間仕事でコミッタ活動ができるということは、かなりのメリットです。 二つ目は、ISIDがスポンサーになっているといっても、利益を上げることは目指してなくて、あくまでも社会貢献の位置づけだということ。利益を上げ
2009年SI企業の不況の乗り切り方 - ひがやすを技術ブログ
不況の嵐が吹き荒れていますが、SI業界の中の人はどうお感じでしょうか。たぶん、仕事が減ってきている気はするけど、製造業ほどひどくないと思っているのではないでしょうか。 ただこれは、不況の波が押し寄せてくるのが、遅いだけです。 SI業界では、プロジェクトが一年くらいかかることも多いので、まだ不況じゃないときに受注した案件分でそれなりに食っていけるのです。しかし、SI業界の主なお客様である製造・金融業界は、案件を凍結したりなど、新規の受注案件はかなり減ってきているので、今やってる仕事が一息ついたら、やることがなくなってくるでしょう。 仕事が減ってまずすることは、人減らしですね。元請なら、下請けをきることが最初に検討されるでしょう。ある程度はこれで調整できますが、直ぐに限界が来ます。今の元請は、下請けに任せていたようないわゆる下流工程を自分たちでは行えないので、単純に下請けをきるだけではすまない
DBFluteはそろそろS2Daoに依存しないほうがいいんじゃないかな - ひがやすを技術ブログ
2008年は、実は仕事を減らして、その分DBFluteをやってました。 去年の今頃、大きな決断をしました。リスクは高いですが、 自分はDBFluteをやりたかったのです。 久保さんのDBFluteにかける情熱が伝わってきますね。 今のDBFluteは、SQLファイル(Outside SQL)以外の部分は、独自で作られていると思うので、そろそろS2Daoに依存しないようにしたほうがいいんじゃないでしょうか。 そのほうが、より最適化もしやすいんじゃないかな。 後、Seasar2にも依存しないようにできるとなお良いですね。私は、Seasar2でフレームワークを囲い込もうとは思っていません。より選択肢があったほうが、ユーザの層も増えると思います。 がんばっているプロダクトは、もっともっと成功して欲しい。
JSPからアクションのViewHelperメソッドを呼び出す - ひがやすを技術ブログ
JSP2.1からは、Unified ELが搭載され、そのELResolverをいじることでいろいろ面白いことができます。 Slim3 Strutsでは、独自のELResolverを追加して、JSPからアクションのメソッドを呼び出せるようにします。使い方はこんな感じ。最初はアクション。convertというメソッドを定義します。 public class HogeAction { ... public String convert(boolean xxxFlag) { return xxxFlag ? "まる" : "ばつ"; } } JSPからは、${メソッド名[引数1][引数2][...]}で呼び出せるので、次のような感じになります。 ${convert[xxxFlag]} これまでは、表示用のロジックは、タグかファンクションに書いていました。正直めんどくさい。アクションのメソッドで表示用
SpringSourceがGrailsを買った - ひがやすを技術ブログ
正確には、GrailsやGroovyの中心的な開発元のG2Oneを買収するようです。 http://www.theserverside.com/news/thread.tss?thread_id=51826 http://www.springsource.com/node/837 Railsへの対抗策?。SpringとRailsが競合する気は余りしないけど。 この買収がどのような結果をもたらすのかは、まだ良くわからないけど、この不況のときに、それほど大きくない会社が買収でキャッシュを減らすのは危険だと思うけどね。キャッシュがなくて、黒字で倒産する会社もあるんだから。 この記事だけでは、キャッシュで買ったとは断言できないけど。 SpringSourceは、あせりすぎじゃないかなぁ。まだ、DM Server(S2AP)だって、どうなるかわからないわけですよ。メインテナンスポリシーの変更が、収益
オンデマンドデプロイのすすめ - ひがやすを blog
JavaでAnnotationがついたクラスがあったら、それに対して処理したい場合は、Seasar2のコンポーネント自動登録で使っているように、ファイルシステムまたは Jar ファイルを全走査してクラスロードする方法もあります。 ファイルシステムまたは Jar ファイルを全走査してクラスロードしてください。が結論です。 Seasar だったら、 org.seasar.framework.util.ClassTraversal を読むべし。 でも、これは、Seasar2.3時代(3年前)の話で、技術としてはちょっと古い。 HOT deployなどと組み合わせると、リクエストのたびに全コンポーネントをデプロイする必要があるので、コンポーネントの数が増えると実用的には使えないのです。 そこで、考え出したのが、Seasar2のONDEMAND deploy。コンポーネントの定義を見に行って、あれば
アクティブレコードパターンの本当の意味 - ひがやすを技術ブログ
アクティブレコード 1行に対応 ドメインロジックを実装している 最近はDBよりの所にドメインロジックを書くのは廃れている RailsのActiveRecord、S2JDBCとか データマッパー ドメイン設計したクラス群とERモデルのマッピング Hibernate、DjangoのORマッパー オブジェクト指向により忠実 PofEAAをみると、アクティブレコードは、「テーブルの行をオブジェクトでラップしたもの」で、データマッパーは、「データベースとオブジェクトを独立して設計しそれらを結びつけるもの」と書いているので、アクティブレコードパターンは勘違いされやすいかも。 アクティブレコードの定義を原文から持ってくると次のようになります。 An object that wraps a row in a database table or view, encapsulates the database
HOT deployを本番でも使えないか - ひがやすを技術ブログ
その HOT deploy を本番運用でも利用できないものかな。 LL のアプリケーションのように。 こう考えるのは三つの理由から。 一つは「アプリケーションを止められない」というビジネス的な都合。 そして「バグ修正や機能追加のモジュール入れ替えなどの複雑で面倒な作業をしたくないし、その方法や実施順序なんか考えたくもない」というのが二つ目。 技術的には、別に難しくはないのですが、運用を考えたときには、クラスタリングをさせておいて、その中の一つを止めて、デプロイを順々に繰り返せばいいだけなので、HOT deployを本番でも使うというのは、あまり賛成できません。 作業が面倒ならスクリプト化しておけばいいだけです。 開発時は、さくさくHOT deploy。本番は、パフォーマンス重視でCOOL deployってのが、最もそれぞれの特徴が生かされているので、いいと思いますよ。
アップロードのときにFormFile#destroy()を呼ぶ必要があるかどうか - ひがやすを技術ブログ
うちの嫁に聞かれた(家で技術的な話をするのはほとんどないんだけどね)ので、答えておくと、通常は、GCのタイミングで、テンポラリのファイルが削除されるので、明示的に呼ぶ必要はありません。 ソースで言うと、org.apache.commons.fileupload.disk#finalize()が最終的には呼ばれるので、問題ありません。 ただ、セッションにアクションフォームを入れていて、かつセッションからアクションフォームを削除するのを忘れていると問題が起きる可能性があります。 確実にやりたいなら、専用のMultipartRequestHandlerを用意すること。次のような感じ。 ポイントは、MyFormFile#getFileData()でdestroy()を呼び出していること。一度データをとった後は、開放してかまいません。 public class MyMultipartRequestH
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
