「オープンソースソフトウェアの育て方」 -全てのオープンソースに関わる人にお奨め- - おおたに6号機blog
以前にもお奨めしていた「オープンソースソフトウェアの育て方」が書籍になったので購入して読んでみました。 内容は目から鱗です。オープンソースというものに対してとても詳細にかつ適度な厳密さをもって書いてあります。 大元の内容は著者の5年にわたるSubversionプロジェクトの開発・運営の経験が元のようです。 実際に、一人でオープンソースをやっている・やっていく人にはもしかしたらあまり関係がない本かもしれませんが、誰かとコラボレーションをしよう・誰かと議論をしたうえで何かを作っていこうとする人にはとてもとても大事なことが書いてあります。また、オープンソース開発者が見落としがちなこと・見てみぬふりをしがちなこと（例えば見た目が重要）などにも、きちんと言及しています。 またプロジェクトのリーダーや管理者が取るべきロールなどにも言及がされています。優しい独裁者・合議制などです。 一般にこのあたりは議
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/ メリット 比較的簡
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-03-10
Lucy Extensionをリリース準備中です. このバージョンから、本体とバージョン番号をあわせることになりました. 結局それが一番わかりやすいということで. というわけで0.5.1-gaが本バージョンになります. まだドキュメント書き中ですが、こんな感じです. Lucy Extension Lucy Extensionは複数のLucy拡張モジュールの集まりです. Lucy自体は非常にシンプルなコンテナ機能を提供しており、そのコンテナに対して 機能拡張を施すのがLucy Extensionになります. Lucy Extensionモジュールは下記のようなものがあります: 共通インタセプタ トランザクションインタセプタ 拡張スコープ 環境切り替え機能 コンポーネント自動登録機能 こんなところです. log4j作者で現在はslf4j作者でもあるCekiさんのCommons Loggingの
DIのインジェクション種類まとめ - おおたに6号機blog
なんか土日ふくめ最近何故かそういう機会が幾度かあったので、DIのインジェクション種類をまとめてみます。 DI(Dependency Injection)の種類には幾つかあって、特性が少しづつ違う（少なくとも僕はそう思ってる）ので その違いがある程度クリアになればというのが意図です。 というわけでまとめてみました。 候補は以下の4つです。 セッターインジェクション コンストラクタインジェクション メソッドインジェクション フィールドインジェクション セッターインジェクション セッターインジェクションは最も標準的なタイプのインジェクションです。 public void setExecutor(Executor executor) { this.executor = executor; }のようにJavaBeans仕様に従って、セッターを準備しておけばよいだけ。 基本的にはどのDIコンテナ（とい
2009-01-26
視点をころころ変える練習を積んでいる。 考え方の視点を切り替える訓練だ。 ただそれだけだとあまり面白くないので、物理的な視点も頭の中のイメージで切り替えるような 練習も足してみた。例えば、すれ違う人の視点を頭の中で再生。しかし、やりすぎてどうにも逝ってしまっている人の ようになっていたので中断。 視点を切り替える訓練は、やりすぎると自分の元となる視点が起点だったところになかなか戻ってこなくなる点が自分の問題。 しかし、こうやって視点を切り替えることで色々課題は見えてくる。 特に拘っている部分が無いと思っていたが実は単一な考え方に縛られているところも見えてくる。 自然と単一な考え方に偏る傾向にある。それをエゴと呼ぶのかもしれないが、エゴとして意識的に 打ち出している部分ではないのにエゴと呼ばれるのは心外なので、なるべく自然発生したエゴは つぶしておきたいところ。 意識しないとニュートラルで居
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-11-26
TSS、たまに面白いことやりますね。 フレームワークで悩んだから比較検討してほしい こんな観点で、とのこと。 * 開発環境: LinuxとWindowsが混在、Java、EJB 2/3 * デプロイ環境: Linux、新しいプロジェクトはUI目的でGlassfishを使用、既存のプロジェクトはWebLogic Server 10.3を使用 * 新しいフレームワークの学習曲線が緩やかであること * すでに十分成熟したものであること * Ajaxサポートが優れていること * 簡単に開発できること * バックエンドのデータモデルにきつい制限がないこと http://journal.mycom.co.jp/news/2008/11/25/029/index.html この中でだったら、自分なら通常のWebアプリならStripes+Spring、UIがもう少しリッチなら Flex+BlazeDSとか
2008-11-17
橋本さんが良いことを書いているので便乗。 ただ、この「一匹狼の群れ」は、ともすれば「自由な奴等」で、何かを継続するということがなかったりします。 新規性、挑戦性のあるようなことには、狼として食らいに行くのですが、そうでないと、見向きもしない。 端的に言えば、派手さを好み、地味さを嫌うのです。 そのような「群れ」には、新しい扉を開ける力はあっても、それを継続する力はないように感じます。 継続できないもの、それは「世の中的には、無かったこととあまり変わりがないことだ」と僕は思います。 収束することを考えていなかったり、パワーがなかったりしたときには、「邪魔なもの」になる可能性も秘めています。 例えば、仕事をルーチン化していくこと、ルーチン化された仕事をコツコツとこなすこと。 過去を大事にし、そこから得るものを今後のために生かすこと。 新しいアイデアを自己否定していくこと。 そういうことも、必要
AS3のアクセサ、使わないほうが便利な気がしてきた - おおたに6号機blog
FlexBuilder限定のお話。 最近ASをそこそこ書いているのですが、 AS3のアクセサ使わないで普通にゲッターとかセッターとか書いた方が良い気がしてきた。 id:c9katayamaに言われてはっとしてから、最近アクセサやめてるけど、そっちのほうが楽。 public function get hoge():Hoge { return _hoge; } より、 public function getHoge():Hoge { return _hoge; } のほうが楽です。何より利用コードが楽。 foo.hoge ってBuilderで補完しながら勢いで書いていると、foo.hoge()ってなっちゃう＞＜ 括弧をあとから自分で消さないといけん。。。 これなら、foo.getHoge();のほうが補完も正しく使える。Java屋なら、呼び出してるところがすぐにわかるし。 というわけで、最近A
Architect also implementsなのだ。 - 2008-10-28 - おおたに6号機blog
アーキテクトとか言うと何様的に思う人もいるかもしれませんが、全体構成を決めるという 意味でアーキテクトは重要なロールです。ロールなので実体が誰であるかはともかくとしても。 アーキテクチャとは何か、その深淵な話題に自分が触れられるほどのもんだとは とても思えないですが、下記の平鍋さんと萩原さんのお話は読んでおくべきことだと感じました。 実際にXPなどの手法でアーキテクチャは段階的に育てていく人と、ある程度初期から形を作りこむ人といますが、 実際に作るときにはそのバランスを取るはずです。 アーキテクチャを決めないで実装の結果をアーキテクチャですとすると、それを使う方が変わっていく様が 激しすぎてついていけないというリスクがある。アーキテクトの一存とその実装方法にゆだねられてしまう。 かといって、アーキテクチャをがっちり決めすぎる（所謂BDUF（Big Design Upfront)）と、今度は
2008-10-23
ひがさんのDIコンテナはEJB3.1でコモディティ化するという意見には賛同しかねるなあ。 自分はあんまりDIコンテナがEJB3を中心にコモディティ化するとは思わない。 何故なら、EJB3を初めとするJavaEEの仕様がそこまで受け入れられてるわけじゃないからです。 もう少し言えばJSF+EJB+JPAの組み合わせが残念ながら受け入れられてない。 海外では標準として受け入れられているかもしれないけど、標準なら標準のまま使うのが 王道でしょう。それか全体を統一してしまうSeamかなあ。 今後JavaEE5のAPサーバが出て、日本でも標準としては間違いなく今よりは 使われるようにはなると思います。その意味でJSF+EJB3+JPAは覚えておいて損は無いです。 しかし、標準からずれてわざわざOSSを使うのであれば、それなりに標準よりメリットが なければ利用者にとって意味がありません。OSS開発する
エンジニアだからもてないの？ - おおたに6号機blog
僭越ながらご指名いただいたのでｗ 【2】（「エンジニア」に対する先入観を打破する）については、エンジニアのネガティブイメージって、 大きく分けると、忙しそうなのでは？（＝デートしてくれないのでは。土日孤独な私はイヤイヤ。）ってのと、 器械やパソコンに詳しい＝内向的なんじゃ？オタクなんじゃ？キモい人なんじゃ？っていう２つの意見に分かれる気がするんだけど、 結局は個人勝負だよね。会って話せば、（追記/「エンジニア」だからどうこうと言う先入観や偏見は）正しいのか間違っていたのかなんて、 すぐわかると思うし。 http://d.hatena.ne.jp/love_chocolate/20081001/p2 エンジニアというかこの業界の人は忙しそうなイメージって結構ありますよね。 よくエンジニアの人だと付き合ってもなかなか会えないとか、そもそもエンジニアの方では出会いが無いとか言ってるのを聞きます。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
