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 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受
受託開発に未来はない? - ひがやすを技術ブログ
私は1年以上、エンタープライズの世界(企業向けSIとか)から離れ、ずっとGoogle App Engineをやっています。今は、Google App Engine + Webkitベースのブラウザで動くHTML5を使ったグローバルな新サービスを提供しようとしていて、新規事業立ち上げのために日々奮闘しているので、エンタープライズな世界に戻ってくることは、基本無いでしょう。 私は、受託開発に未来はないと思っているので、自分でサービスを提供する側に回ろうとしているわけです。受託開発に未来はないといっても、文字通り未来はないという意味で、すぐになくなるわけではないし、生きてくために必要な部分も多々あると思います(うちの会社もSIerだし)が、今後は撤退すべきだろうという判断です。 受託開発になぜ未来がないかというと、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものが生き
そろろろRailsについて本音を書いてみるか - ひがやすを技術ブログ
最近の大田さん@mixiのところで、Rubyについて考察する機会があったのと、よういちろうの考えと同じことを思っていたので、たまには本音で書いてみる。 Railsで、最も良いところは、テストの雛形も自動的に作ってくれて、テストの敷居を下げてくれてるところだと思う。なのに、それについて触れる人があまりにも少ないような気がする。一応、私は、1年半以上、はてなのキーワード検索で毎日Railsについては調べているので、はてなでRailsについて書いている人の記事はたいてい見ています。 理由は、いくつか考えられますが、私の読みだと、テストが当たり前の人にとっては、当たり前すぎてわざわざ書く意味がないし、そうではない多くの人にとっては、ほとんどテストは書いていないんじゃないかな。 実は、テストを書くのは結構工数かかるんですよ。スクリプト言語は、コンパイラがミスを教えてくれることはないので、Javaと比
「ずば抜けているコンプレックス」を克服する方法 - ひがやすを技術ブログ
404 Blog Not Found:それって勉強じゃないよ http://d.hatena.ne.jp/pollyanna/20081224/p1 なんかかみ合ってなくて残念だけど、弾さんは「天才コンプレックス」、pollyannaさんは「秀才コンプレックス」を持っているんじゃないかと思う。嫉妬の意味でのコンプレックスではなくて、「できる人」の悩みのほう。他人と自分のギャップに戸惑っている。 弾さんの「天才コンプレックス」については、この辺を見ると良くわかる。 私にとって、天才とは天災以外の何者でもなかった。かといって、「能ある鷹は爪を隠す」(これまた耳に胼胝が出来るほど言われた)というほど器用にもなれなかった。 pollyannaさんの「秀才コンプレックス」はこの辺。 それ以来、私には「頭のいい子」という称号がついて回った。 賞賛の意味でそう呼ばれることが多かったが、「変わってる」「す
華のあるイベントやりまーす - ひがやすを技術ブログ
以前予告した日本Javaユーザグループでクロスコミュニティカンファレンスの中身が大体決まったので、お知らせします。10/16の午後は空けておいてね。 タイトル:パフォーマンスチューニング入門 講演者:amachang 概要:IT戦士 amachang が日頃やっているパフォーマンスチューニングの方法を紹介いたします！ポロリもあるよ！ タイトル:ギークなお姉さん(仮) 講演者:べにぢょ、山田あかね タイトル:『JavaからRubyへ』・アンド・ナウ 講演者:角谷、高井、和田 概要:角谷がついカッとなって『From Java to Ruby』と題された書籍の翻訳をはじめてから2年が経ちました。『JavaからRubyへ』というバズワードは我ながらうまく状況をとらえたと思っていますが、書籍に書かれているのはあくまでも著者Bruce Tateの主張です。このセッションでは私たちそれぞれの立場と視点と
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
「PHPは初心者に優しい」は不適切な宣伝文句 - 2008-01-29 - ひがやすを blog
Seasar2は、2.5でやろうとしていたS2PersistenceとS2PresentationをS2JDBC、SAStrutsという形で、2.4ベースで実装してしまったため、2.5を出すことはおそらくないでしょう。 また、コンテナに手が入ることももうないと思います。やるべきことはやったと思うので。 S2JDBCで、データベースの定義からEntityを自動生成する機能と、Entityからデータベースを再構築する機能を今後追加予定ですが、それで、機能追加の予定は終わりです。Seasar2.4は、安定バージョンとして、ずっと使い続けられることになると思います。 Seasar2.4に対する追加要望があれば、もちろん検討します。ただし、大きな変更や追加はもうないでしょう。 「PHPは初心者に優しい」は不適切な宣伝文句 今回の件は、静観しておくつもりだったけど、やっぱ書いておく。 「PHPは初心者
2007-10-18
Seasarカンファレンスで、Seasar2入門セッションを、いろんな方に喜んでいただけるようにSeasar2ロードマップと復活のStrutsのセッションに変えるよというアナウンスをしたのですが、Seasar2の入門セッションはやはり必要だということで、元に戻すことになりました。 期待していた方ごめんなさい。でも、入門セッションのほうも面白いネタをいろいろしゃべるつもりなので、是非お越しください。 今後はやるフレームワークは「流れるようなインターフェース」を持ったものになるんじゃないかなぁと思います。流れるようなインターフェースの説明は、ファウラーたんのFluentInterfaceを参照してください。 Seasar2の新O/R Mapper(以後S2JDBCと呼びます)もこの「流れるようなインターフェース」を実現しています。例えば、JdbcManagerを使った検索はこんな感じになります
後輩の育て方 - ひがやすを技術ブログ
こんなことを書くと、うちのチームのメンバが「なにもやってないじゃん」って突っ込むでしょう。そう、ほとんど干渉せず全部のその人に任せるのが私のやり方。 社会人になりたてのころは、ある程度面倒見ることも大事だと思いますが、そこそこの経験をつんだ後は、自分で考えて行動するしかないんじゃないかな。 こんな私の方針のせいで、とばっちり(?)を受けているのは、Teedaのリーダーである大谷さんかもしれません。私は、Teedaの開発方針・運営については、ほとんど口を出さないので、自分で考えるしかありません。きっと、プレッシャーなり悩みなり思うところはいろいろあると思いますが、結局は自分で解決していくしかないと思うんです。 悩んだ分人は成長するなんて、甘いことは言いません。ただ、いろいろ考えたことは無駄にはならない。 後良く思うのは、上司だとか先輩だとかは、ちょっと経験があるからといって、本質が理解できて
ひがやすを blog - 2007-09-24 - 「なぜお前らは「好きだからコードを書く」はできるのに「好きだからメンテナンスする」ができないのか?
本当の問題は「スーツ + 頭のカタイおやじ VS. 無垢な技術者」という話だろうか。なんで、スーツの人や、頭のカタイおやじや、無垢な技術者がいるのか、その前提条件を問わなくちゃいけないんじゃないのか。その前提条件に、自分がどんな一手を打てるのかを考えて、世界を変えていこうよ。ていうか、世界を変えていたじゃない。 なんか、高井さんが勘違いしているみたいだから、書いておくけど、俺は、「だから世の中が悪い」とかいうつもりはありません。この構図は、過去何度も繰り返されている事実だから、まず私たち技術者は、その事実をきちんと認識しなければならない。 昨日は書かなかったけど、実は、「弱い技術者」というのは、「頭の固いおやじ予備軍」でもだったりする。 実際良く見かけるんだけど「最新の技術についていくのは疲れた」「なにかスーパーなデファクトが現れてそれで統一されて欲しい」「考えるのめんどくさいから標準で統
ひがやすを blog - Javaを古くしたやつとRubyを煽っているやつ
その正体はわかったよ。正体わかった瞬間からだが震えたよ。まじで。 まずは、羽生さんのこのエントリを見て欲しい。 http://d.hatena.ne.jp/habuakihiro/20070922#1190464426 その後によしおりのこの有名なエントリも復習して欲しい。 http://d.hatena.ne.jp/jYoshiori/20070826/1188150596 もうさぁ、変わってないよねぇ。昔からのこの構図。歴史は繰り返すっていうの。 あからさまにいうとさぁ。賢いスーツな奴らと、頭の固くてあわれで保守的なおやじの歴史だよ。 最初は、EJBだよ。EJB。これからは、ビジネスコンポーネントが流通して、もうプログラミングはいらなくなる。コンポーネントの組み合わせを考えるだけでOKみたいな。最初にね、キャッチーな言葉とともに、あらたなテクノロジーを広めようとするのは、賢いスーツな奴
2007-07-25
そんなの問題外だ、というくらい基礎中の基礎が抜けていたとしても、Seasar2プロダクトは使えてしまいます。 Seasar2で目指しているのは、基礎のできない人でも使えるということではなく、機械的にできるような非本質的な作業はできる限り自動化し、開発者が本来やらなければいけないことに集中できるようにすることです。 私は、性善説に基づいているので、最初は良くわからずに作っていた開発者も周辺の技術に興味を持ち、いろいろ勉強してくれるだろうと信じてきます。最初は、基礎的な知識が足りなかった人も、丁寧に誘導してあげれば、基礎的な知識を身につけてくれると信じています。最初から、「こんな基礎的なこともわからないのかボケ」みたいなことはしたくありません。 ITの業界が良くなっていくには、より多くの人が参加することが重要です。多くの人が参加すれば、そのうちの何人かは、すごいことをやってくれるでしょう。最初
Seamのテスト - ひがやすを技術ブログ
この手のフレームワークってあんまりunit testsは書かないのですかね？SeasarやTeedaではソースの中に結構unit testsがあるのを見たことがあるので、ちょっと不安に感じちゃいます。 インテグレーションテストも大事ですが、ユニットテストはもっと大事だと思います。ユニットテストをあまり書かずにインテグレーションテストをやるってのは、不安定な基礎の上に家を作っているようで不安です。また、インテグレーションテストが自動化されていないのは不安です。 Teedaはかなりテストをかんばってますけど、それでも残念ながらデグレすることもあります。少しでもそのような可能性を減らすには、十分なユニットテストと自動化されたインテグレーションテストしかないのではないかと思います。
ひがやすを blog - [etc]トランザクションスクリプトとドメインモデル
このネタについては、ループしやすく結論が出ないので、あまり書きたくはないのですが、私の考えを誤解している人が多いようなので、書いておきます。 トランザクションスクリプト、ドメインモデルなんてのは、所詮実装の話で、どっちもどっち。トランザクションスクリプトが良いわけでもないし、ドメインモデルが良いわけでもない。私はどっちも好きではない。 重要なのは、ユースケース(ユーザ要件)と実装の対応関係が明確になっていることです。それさえ満たされていれば、実装はどうなっていてもかまわない。 ユースケースと実装の対応関係を明確にする方法の一つとして、ユーザ機能レベルのユースケースは、Teedaでいうサブアプリケーション(関連する複数の画面を束ねたもの)にマッピングする。サブアプリケーションは、関連する各画面の親クラスに相当する。各画面は、サブ機能レベルのユースケースに相当し、サブ機能レベルのユースケースは
![ひがやすを blog - [etc]トランザクションスクリプトとドメインモデル](https://cdn-ak-scissors.b.st-hatena.com/image/square/8e78530571d6b2a4e4f7daa905c8574b19154a4d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126970898857%2F17680117126970927152%2F1550549907)
ひがやすを blog - [Seasar]JavaとLL
Seasar自体を使うかどうか、とかいうレベルではなくJavaという重量級言語でもテクニックを駆使することでここまでLL的に開発が行える、という意味でです。 Seasar2を使えば確かにLL的な開発が可能です。でも、Javaでそこまでがんばらなくても、LLを最初から使ったほうがいいんじゃないのと思われる方もいるでしょう。WEB+DB Pressの「Alpha Geekに逢いたい」で小飼弾さんにもそういわれました。 Railsの得意なところはRailsに任せればいいじゃんとは考えなかったんですか。システムの一生というものを考えたときに、LL的な開発が必要なのはほんの一瞬です。大部分は、運用のフェーズなのです。運用で大切なのは、「安定性」と「パフォーマンス」で、LL的な側面ではない。 だから私は「Railsに任せればいいじゃん」とは考えない。「LL的な面が必要な場合は、HOT deployを使
![ひがやすを blog - [Seasar]JavaとLL](https://cdn-ak-scissors.b.st-hatena.com/image/square/9911d3379caeb8ea97c0562417faa4fe56ca183d/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126970898857%2F17680117126970927287%2F1550549910)
ひがやすを blog - ドメインモデルに対する日米の温度差
ドメインモデルに対する日米の温度差 ひさびさにみたなぁ、この話題と思いつつ、コメントします。 昔書いた自分の記事をすべて読み返したわけではありませんが、どこにもトランザクションスクリプトが良いと書いたことはないはず。 この話題に関する問題の根源は、ファウラーが トランザクションスクリプトは、単純だから単純なシステムには向いている。でも、複雑な問題を扱うには、真のオブジェクト指向であるドメインモデルを使ったほうが良い。としたところにあると思います。これが、そもそもおかしい。複雑なシステムを扱うには、ドメインモデルのほうが向いているというのは根拠がない。データと振る舞いを一つにまとめることがオブジェクト指向というのも単純すぎる。 別にオブジェクト指向はこうあるべきなんていまさら議論するつもりはありませんが、私の中でのオブジェクト指向は、「それぞれのオブジェクトがきちんと割り当てられた責任を果た
2007-06-18
Seasar mini event http://d.hatena.ne.jp/higayasuo/20070606#1181103955 Webアプリケーションのスコープは、基本的に、リクエスト、セッション、アプリケーションの三つですが、リクエストよりは、長くセッションよりは短いスコープを扱うフレームワークが増えてきました。 このスコープは、会話スコープといわれることが多く、会話を開始して終了するまでの間、そのスコープにおいたオブジェクトが維持され、終了した後、自動的に破棄されます。セッションにはあまり長くオブジェクトを置きたくない、自動的にセッションのオブジェクトを破棄してほしい、これが会話スコープの目的です。 会話スコープを持っているフレームワークとしては、Spring Web flow、Shale、Seam、Teedaなどがあります。Spring Web flowとSeamの機能は
2007-06-08
Seasar mini event http://d.hatena.ne.jp/higayasuo/20070606#1181103955 http://quote.yahoo.co.jp/q?s=3850.t&d=t おめでとうございます。 誤解が無いように注意がいる箇所として、重複部分の全ては継承と述べているのではないです。次のように、委譲モデルも併用しています。 複数のユースケースで使われるロジックは、共通のユースケースを抽出し、共通のユースケース名Serviceクラスに持たせる。 なんとなく、このような設計にした方が良いとは思いますが、なぜ、上記のような局面において、継承モデルではなく、委譲モデルを採用したのか理由が気になるところです。 私は、単にシンプルさを求めるだけではなく、複数の人で並行で開発しやすいということも常に重視しています。一つのユースケースは一人で開発することが多い
DIって本当に必要? - ひがやすを技術ブログ
DIって本当に必要?たまにそう思うときがあります。DIによって開発は本当に楽になったのか。 DIのメリットでよく語られることとして、インターフェースと実装を分離し、機能の利用者側はインターフェースを通じて機能を利用することで、実装に直接依存しなくなり、後で実装を変更しても影響を受けなくなるということがあります。 実際後から、実装クラスを変更するということはめったにないので、よくあるのは、テストのために実装クラスをモックに変えることです。 でも、別にそれだけならDIContainerなんていりません。たとえば、次のようにServiceクラスに直接依存したClientがあるとします。 class Client { Service service = new Service(); void setService(Service service) { this.service = service;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
From JPA to S2Persistence - ひがやすを技術ブログ
