yojikのブックマーク - はてなブックマーク

Seasar Conference Final - ひがやすを技術ブログ

今週の土曜、9/24にSeasar Conference Finalを行います。 10年前に始まったSeasar Conferenceもいよいよ今度でFinalです。お申し込みはこちら。 http://seasar.connpass.com/event/38679/ Seasar Projectの面白かったところって、開発方法論が盛り上がったところだと思うんですよ。ステートレスなサービス + DTO vs Fatなドメインモデルみたいな。マーチンファウラーをはじめとして、著名な人たちのほとんどが「ドメインモデル推し」の中、僕は、「ステートレスなサービス + DTO推し」だったからね。S2Daoは、このために作ったようなものです。あの開発方法論の議論に、かなりの人が参加したり、自分で考えたりしたでしょう。それが、面白かったところです。みんなが自分の事として考えたから。そんな難しい話で

yojik 2016/09/21

リンク

Seasar2の継続性 - ひがやすを技術ブログ

某掲示板で、Seasar2の継続性の話が出てたんで、この辺の実際を書いておきましょう。あくまでも、私が書いているので、主観的な意見ですが、そんなに外れてもいないでしょう。ここでいうSeasar2とは、主要プロダクトのS2Containerのことです。 Seasar2の継続性はきわめて高いはず。なぜなら、ISIDがスポンサーになって、主要なコミッタを雇っているから。ISID自身の基幹システムもSeasar2で再構築しようとしているし、Seasar2を使った社内案件(ISIDがプライムのSI案件)もあるので、サポート力を維持するためにも、ISIDがスポンサーから降りることは考えにくい。昼間仕事でコミッタ活動ができるということは、かなりのメリットです。二つ目は、ISIDがスポンサーになっているといっても、利益を上げることは目指してなくて、あくまでも社会貢献の位置づけだということ。利益を上げ

yojik 2015/09/29

ふと思ったんだけどISIDのサポート?サービスとかはどうなるんだろう

リンク

Seasar2から卒業しよう - ひがやすを技術ブログ

人は、新たな環境で経験を積んでいくと、少しずついろんなことが出来るようになり、そのうち、その環境では、何でも自分の思った通りに出来るようになります。「おら、強ぇ」状態。これは、素晴らしいことなのですが、一つ問題があります。成長が止まってしまうことです。人は、知らないことを経験したり、つまずきを乗り越えたときに、成長します。知らないことがほとんどなくなったり、つまずくことがなくなったりすると、成長が止まってしまうのです。 Seasar2.4、S2JDBC、SAStrutsと開発してきて、通常のサーバーサイドJavaは、十分にやりきった感がありました。このままこの場所にいるのは、心地いいんだけど、成長が止まってしまうのが不安でした。人って不思議なもので、一定の能力でとどまるってことが出来ないんだよね。成長が止まると、能力は落ちていく。自分はどこか、ドラゴンボールの悟空に似ているところ

yojik 2015/09/28

「(個人的に飽きたし)リソースもないので止めます! 使い続けるのは非推奨。フォークするなり好きにしてください！すみません！」で十分だと思うんですよね。この件に関してはポエム不要。

リンク

俺は守りに入らない、これが今の俺だ - ひがやすを技術ブログ

Seasar Conferenceが久々に開催されます。興味のある方はぜひお申し込みください。 http://seasar.connpass.com/event/19317/ 正直、話す内容は、個々人にまかされているので、どんな感じになるのかはやってみないとわからないのですが、私は、今取り組んでいることを話したいと思います。今、私が取り組んでいるのは、「ダンスマシン(すっげー仮)の開発」イメージはこんな感じ。 Padをたたきながら、ダンスを組み立てていきます。ダンスは、1,2小節ごとに組み立てていくことがほとんどなので、曲を作るのと同じような感じで組み立てていくことになります。出来上がったダンスは、Audioムービーの静止画の上に、シルエットで踊らせるようなことを考えています。いわゆる、VJ用のマシンな訳ですが、DJのソフト&ハードと、MIDIで連動させることができ、曲とダンスを

yojik 2015/08/27

めちゃ別分野参入だ。。 Launchpad みたいにステップシーケンサーのみ? KORG の electribe みたいにドラムマシン込み? めちゃめちゃ競合多そうな分野だけどVJ特化が特徴か? いろいろ謎！

リンク

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

yojik 2014/06/12

リンク

2014-04-25

Struts2に見つかった脆弱性と同様の脆弱性がStruts1系にも見つかりました。 Apache Struts 2の脆弱性が、サポート終了のApache Struts 1にも影響 HTTP(S)のリクエストでJavaのClassLoaderのメソッドが呼び出せてしまうという脆弱性です。もう少し噛み砕いて言えば、リクエストのパラメータをJavaBeansにセットする時に、リフレクションを使い、パラメータ名にaaa.bbb.cccのようなネストした名前をサポートしているフレームワークは同様の問題が起こる可能性があります。パラメータ名をclass.classLoader.xxxのような感じにして、ClassLoaderのメソッドを呼び出す訳です。このような問題を起こすリフレクションフレームワークで最も有名なのは、Apache Commons BeanUtilsです。リクエストのパラメータ

yojik 2014/04/28

最近のSpringの場合はSping.DataBinder、マッピング対象のプロパティの名前を与える(ホワイトリスト方式)というちょっとしょっぱい方式で対処可能。(ざっと見ただけなので他の対処あるかも) / playもこれ使ってる

リンク

StrutsのClassLoader脆弱性はSAStrutsに影響しません - ひがやすを技術ブログ

Struts2に見つかった脆弱性と同様の脆弱性がStruts1系にも見つかりました。 Apache Struts 2の脆弱性が、サポート終了のApache Struts 1にも影響 HTTP(S)のリクエストでJavaのClassLoaderのメソッドが呼び出せてしまうという脆弱性です。もう少し噛み砕いて言えば、リクエストのパラメータをJavaBeansにセットする時に、リフレクションを使い、パラメータ名にaaa.bbb.cccのようなネストした名前をサポートしているフレームワークは同様の問題が起こる可能性があります。パラメータ名をclass.classLoader.xxxのような感じにして、ClassLoaderのメソッドを呼び出す訳です。このような問題を起こすリフレクションフレームワークで最も有名なのは、Apache Commons BeanUtilsです。リクエストのパラメータ

yojik 2014/04/25

リンク

梅田望夫にオープンソースを語るなとガツンと申し上げたい - ひがやすを技術ブログ

例えば、インターネットが社会にもたらしたインパクトのひとつに「オープンソース」という考え方があります。これは元々ソフトウエア開発に端を発した概念なのですが、いまやそれにとどまらず、世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していくといった可能性を含む、より広い応用範囲での思考や行動原理を意味しています。サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日本では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知（ウィズダム・オブ・クラウズ）」が働

yojik 2009/06/18

モチオ先生のオープンソース解釈がおかしいのはいつもの事だけど、確かに元バージョンの引用の仕方もよくないかな。切ったところは明示すべき

リンク

GAE/Jは破壊的イノベーション - ひがやすを技術ブログ

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

yojik 2009/04/20

巨大なプラットフォーム上で動くServletエンジンがなぜ破壊的イノベーションなんだろ | GAE/J自体は素敵だと思う。| あ、でも「仮想化」メインだったホスティングで単なるSevletエンジンだけホストするのは発想の転換かも

リンク

強みがなければ淘汰される40代のためのSWOT分析 - ひがやすを技術ブログ

自分の人生を日記ネタにして生きているhigayasuoです。昨今の不景気風ビュービューふきすさぶ中、皆様いかがお過しでしょうか。 inspired by 2009-01-04 S(Strengths、強み) 大手企業で働いていたってのは、それほど、強みでないと思う。天下りなどで特別な力がない限り、勤めていた会社は関係ない。もちろん、ポジション(肩書き)も関係ない。勤めていた企業はあまり関係なくなっているところが、よしおかさんの世代との違いかも。自分が何をやってきたかが重要だと思う。会社名に助けられて仕事してきた人も多いと思う(自分もその一人)けど、会社名は自分の実力とは直接結びつかない。もちろん、会社名は、利用したほうが良い。使えるものは何でも利用すること。でも、個人の実力で作り上げたものをきちんと持ってなければ、特に不況のときなどは相手にされない。他人と簡単に交換できない価値を発

yojik 2009/01/05

OTは「外的要因」だから、OTを考えるとき「強み」とか関係無いっす

リンク

「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - ひがやすを技術ブログ

自社のバックオフィスの方が、外注先に対してどんな立ち居振る舞いをしているのかご存じですか？　自社と外注先との間の契約がどのようになっているのかご存じですか？　それを目の当たりにしても同じことを言い続けられる自信はありますか？　そういうことはスーツの仕事とレッテルを貼って見て見ぬ振りをしてませんか？　それでいて業界を変えたいなどといいますか？業界を変えたいっていってるところから、おいらのことを言ってるとして話を進めるよ。バックオフィス(この文脈では調達のことかな)の方が、外注先に対してどんな立ち居振る舞いをしているのかは、正直良くわかりません。転職したことがないので、他の会社のことは良くわからないけど、弊社の場合は、調達と外注先が価格や条件の交渉する場に、案件側の人間は立ち入ることはないためです。必要だといわれたらもちろん同席するけどね。新規取引をさせていただくときの最初の顔合わせに同

yojik 2008/10/18

ひがさんとはぶさんがどういうテーマで議論してるのか見失った。だれかガンダムに喩えて説明してくれー

リンク

軸がぶれないって危険なことかもね - ひがやすを blog

「軸がぶれないことが重要」っていう人は、結構多いと思うんだけど、危険なことかもね。最初に決めたことがあっているならそれでいいけど、あってるとは限らないからね。「だからこそ最初に良く考えるんだろう」っていいそうだけど、どんなに良く考えたって、間違いはある。人間は、未来のことはわからないんだから。私は、XPのYAGNI(You Aren't Going to Need It)の考え方が好きです。「今必要のあることだけをやれ」っていう考えが。「人は未来のことはわからないんだから、できる限りの予想をして未来に備えよう」ってのと真逆な考えで、「人は未来のことはわからないんだから、予想するのはやめちゃって、今必要最小限のことだけをしよう」ってことです。そして、「現実にあわせて素早く舵を切る」のです。私は、XPにふれて以来、ずっとこの考えに従っています。先のことは予想しない。現実にあわせて

yojik 2008/06/25

よくわからなかった。YAGNIは未来を予想するなーということで、「軸(←行動規範や原則だとすれば)」とはあまり関係無い話だと思うんだけども。むしろ軸があるからこそYAGNIできるのでは

リンク

SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ

10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。経営層がプログラムの品質を度が越えたほどに軽視する理由の一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。汎用機あるいはオフコンの時代は、COBOLやRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変

yojik 2008/06/02

汎用機自体には、バージョン管理と連動したモジュールの再利用追跡システムなど、意外にしっかりした仕組みがある所が多いと思いますけどね。問題は技術を超えたところにあると思ってます。

リンク

「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ

昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保

yojik 2008/03/25

あとで

リンク

ひがやすを blog - Javaを古くしたやつとRubyを煽っているやつ

その正体はわかったよ。正体わかった瞬間からだが震えたよ。まじで。まずは、羽生さんのこのエントリを見て欲しい。 http://d.hatena.ne.jp/habuakihiro/20070922#1190464426 その後によしおりのこの有名なエントリも復習して欲しい。 http://d.hatena.ne.jp/jYoshiori/20070826/1188150596 もうさぁ、変わってないよねぇ。昔からのこの構図。歴史は繰り返すっていうの。あからさまにいうとさぁ。賢いスーツな奴らと、頭の固くてあわれで保守的なおやじの歴史だよ。最初は、EJBだよ。EJB。これからは、ビジネスコンポーネントが流通して、もうプログラミングはいらなくなる。コンポーネントの組み合わせを考えるだけでOKみたいな。最初にね、キャッチーな言葉とともに、あらたなテクノロジーを広めようとするのは、賢いスーツな奴

yojik 2007/09/25

もうみんなやめてっ！とっくにStrutsのライフはゼロよ

リンク

ひがやすを blog - [Seasar]JavaとLL

Seasar自体を使うかどうか、とかいうレベルではなくJavaという重量級言語でもテクニックを駆使することでここまでLL的に開発が行える、という意味でです。 Seasar2を使えば確かにLL的な開発が可能です。でも、Javaでそこまでがんばらなくても、LLを最初から使ったほうがいいんじゃないのと思われる方もいるでしょう。WEB+DB Pressの「Alpha Geekに逢いたい」で小飼弾さんにもそういわれました。 Railsの得意なところはRailsに任せればいいじゃんとは考えなかったんですか。システムの一生というものを考えたときに、LL的な開発が必要なのはほんの一瞬です。大部分は、運用のフェーズなのです。運用で大切なのは、「安定性」と「パフォーマンス」で、LL的な側面ではない。だから私は「Railsに任せればいいじゃん」とは考えない。「LL的な面が必要な場合は、HOT deployを使

yojik 2007/07/02

例えばRailsにだってproductionモードとかあるわけで。。僕は逆にがんがんプログラミングしてる時期こそ重量言語が生きると思う。ビルド時にいろいろチェック可能にするとか。。。

リンク

ひがやすを blog - [Seasar]DIの設定をJavaで

以前､Seasar2の設定をJavaでかけるようにするってのをSeasar2のコミッタMLで提案したことがあるのですが､小林さんに却下されました(笑)。個人的には､Springの案は悪くないと思っています。 http://blog.interface21.com/main/2006/11/28/a-java-configuration-option-for-spring/ Seasar2の場合は､上記に加えて､includeをどのように扱うかが問題ですが､DIContainer.javaというインターフェースを用意して interface DIContainer { T getComponent(Class clazz); T getComponent(Class clazz, String name); }使う側では class AppConfig extends DIConfig {

yojik 2007/01/06

java

リンク

ひがやすを blog - [Seasar]ページ駆動開発とテーブル駆動開発

Seasar2.3の時代は､Goyaと言われる開発手法がありました。Goyaのアーキテクチャは､JavaEEの基本にのっとったレイヤモデルアーキテクチャです。詳しくはこの辺。 http://d.hatena.ne.jp/higayasuo/20050817#1124260949 http://d.hatena.ne.jp/higayasuo/20050818#1124338844 役割分担がきちんとされているきれいなアーキテクチャだと思うのですが、CRUD(Create Read Update Delete)しかないような単純な画面でもそこそこクラスが必要で重い感じがするのも事実です。過去のDIではインターフェース中心の設計が強く推奨されていたため､レイヤモデルアーキテクチャは重く感じられても非常にDIにフィットしていました。しかし、Javaでさらに生産性を高めるためには､レイヤモデル