メタプログラミングの光と影 - ひがやすを技術ブログ
メタプログラミングとはソースコードを生成するプログラミングのことです。メタプログラミングによって生成したソースコードは、eval関数で実行することができます。 メタプログラミングとは、ロジックを直接コーディングするのではなく、あるパターンをもったロジックを生成する高位ロジックによってプログラミングを行う方法、またその高位ロジックを定義する方法のこと。 メタプログラミング - Wikipedia だから、eval関数は、手段であり、メタプログラミングそのものではない。これは弾さんが指摘してますね。 evalだけがメタプログラミングの技法ではないし、またevalはその威力ゆえ最後の選択肢とすべきだ。 弾さんのパフォーマンスの指摘に対して、miyagawaさんが、「必ずしもevalが遅いとは限らない」と指摘してますね。 メタプログラミングとevalのベンチマーク - Bulknews::Subt
Rails3は成功するのか - ひがやすを技術ブログ
Rails3のコアは、なんとMerbベースになるそうです。 http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3 http://yehudakatz.com/2008/12/23/rails-and-merb-merge/ http://rubyonrails.org/merb 日本語の情報だとこの辺。 http://blog.s21g.com/articles/1153 正確な情報は、上記のリンクを見て欲しいのですが、私の受けたイメージは、「Merbで確立されたcoreの部分の高速化をRailsにもちこんだんだな」というものです。 他のフレームワークの良いところを取り込んだ例としては、JavaのStruts2が直ぐに思いつきます。Struts2は、Struts1.xを捨てて、WebWorkベースで作り
勉強会とかコミュニティ活動に参加できるのは、下請けに仕事を押しつけてるからじゃね - ひがやすを技術ブログ
今は友人までの公開になっているので、リンクをクリックしても発言を読めません。このエントリを書いたときは誰でも読めたんだけどね。 勉強会とかコミュニティ活動に参加できるのは、下請けに仕事を押しつけてるからじゃねーの？ 仕事は、一人ではできないので、いろんな人に支えられてやっています。そういう意味で、支えてくれる人なしには何もできないのは事実です。 で、だ。 自分はどうかといえば、おれは、ほとんど、一人で仕事をしているから、下請けとか関係ないです。うちの会社でどうかといえば、下請けに仕事を押し付けている人なんていないですよ。みんな仕事大変だからね。忙しいし。 で、だ。 誰に言っていてもいいんだけど、上記の言葉の裏には、コミュニティ活動は、暇だからできるみたいなニュアンスが感じられるんだけど(間違っていたらごめん)、コミュニティ活動ってかなり大変だよ。 例えば、この前、「ひがやすを飲み会」なんて
アルファギークが空回り - ひがやすを技術ブログ
エンジニアの未来サミット、一部が学生とアルファギークの対談、二部がアラサーにとってのIT業界。 一部は、企画者としては反省点がいろいろあります。一番の反省点は、弾さんをモデレータに選んだこと。 これは、弾さんが悪いということじゃないですよ。弾さんは、熱くて、場の空気は読まない人だから、スピーカーには向いているけど、モデレータには向いていない。 弾さんをモデレータに選んだのは私なので、これは完全に私のミス。 学生とアルファギークの対談も空回りしていたと思います。あんまり対談になっていなかった。猛獣の中に、ウサギを放り込んだような。チャットでもいわれていたけど、前半は、学生が空気のようになっていたかもしれないです。ごめんなさい。 泥の話も空回り。泥の話って結論が出にくい割りに、たとえ結論が出ても前向きな話にならない。泥はテーマからはずすべきでした。 チャットによって、見ている人の意見がダイレク
Seasarの技術情報を2chで求めるのはやめなさい - ひがやすを技術ブログ
2chはなんでもありで自由にやればいいと思うけど、すくなくとも仕事で使うSeasarの技術的な情報を2chで得ようとするのはやめたほうがいい。 例えば、S2JDBCは、PostgreSQLのbyteaに対応しているし、s2jdbc-itのテストケースを見れば、テストされていることは明らか。 まぁ、これだけじゃなくていろいろあるけどね。 匿名のほうが聞きやすいってのはあるかもしれないけど、仕事で使う情報なら、きちんとMLで聞いたほうがいい。Seasar-user MLのサポート力は、オープンソースのMLの中でもトップクラスだから。 私のお勧めは、「仕事で使うSeasarの技術的な情報はMLで聞いてください」ということです。匿名で軽く聞きたければ、私のblogに匿名でコメントしてもらえれば、答えますよ。 大事なことだからもう一度言っておくと「仕事で使うSeasarの技術的な情報は2chできくな
優秀なプログラマの給料が低いわけ - ひがやすを blog
昨日の開発生産性が低い方が収入が多いって変だよねのエントリでは、企業レベルの話だと、生産性が低いほうが売上が上がるという話をしたんですが、実は同じようなことが、個人レベルでも言えます。 生産性の高い超優秀なプログラマより、社交性の高いそこそこ優秀なプログラマのほうが、評価が高く給料も多くもらえるようになるのです。さすがに、個人レベルだと生産性の低い人が評価が高いということはあまりないけどね。一時的には残業が多くて給料が増えるときもあるかもしれないけど、それはあくまでも一時的なこと。 評価が高いということは、上司にそれだけ認めてもらっているということですが、それではなぜ、優秀なプログラマは、上司に高く評価されないのでしょうか。 「上司に技術をきちんと評価する力がないから」それも多少はあります。でも、主な原因ではありません。会社によって違うと思いますが、評価における技術力の部分は2,3割りに過
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
PHPな人は本当にPHPしか知らないのか - ひがやすを技術ブログ
言語を比較するためには他の言語についてのある程度の知識が必要だろう。 Perlを知らずしてスクリプト言語を深く語るのは難しいし、 Lispの知識なくRubyを深く語ることは難しい。 Pythonは？ うーん、PythonにはPythonの知識だよね(笑) たとえばPHPしか知らないとしたら、PHPの欠点を指摘されると自分のやり方全体が 否定されたと感じるのではないだろうか。 Matzのエントリが原因ではないと思うけど、「PHPの人はPHPしか知らない」というイメージがなんとなくあるよね。でも、そのイメージは間違っていることを今日この場で宣言しておく。 昨日、PHPカンファレンスのパネルディスカッションに出たんだけど、そこで、会場の人にどれくらい他の言語を使ったことがあるか聞いてみた。数字はうろ覚えだけど。 Perlは70%くらい Rubyは80%くらい Pythonは70%くらい Java
NTTデータと真昼の対決 - ひがやすを技術ブログ
昨日、NTTデータに「お前は最近、NTTデータに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、NTTデータを嫌っていると思っているデータ関係者は、実際多いようです。 データの偉い人の発言に対して、それはちょっとおかしいんじゃないのといったことはありますが、データを嫌いといったことはもちろんないはず。 データの社員の中に根強くある(と思う)「プログラミングがあまりできない人でも何とかなるように、ガチガチにルールやツールで縛る。できる人はスキルを発揮できなくなるかもしれないけど、それはしょうがない。」という考えは、個人的には好きじゃないけど。大規模なプロジェクトをまかされるSIerとして、そう思う気持ちは良くわかるんだけどね。 話し合いの中で、私が言ったのは、できる開発者が力を発揮できるように、体力勝負になってしまうような縛りは
SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
IT業界の重鎮に期待せず、アルファギークと学生の討論会はいかが - ひがやすを技術ブログ
@IT:「10年は泥のように働け」「無理です」――今年も学生と経営者が討論 ITpro「IT技術者はやりがいがある仕事か」---学生とIT産業のトップが公開対談 みんな@ITに釣られすぎ。重鎮たちの意見は、古いなぁとは思うけど、そんなにおかしいことは言ってない。ITproとあわせて読めば、@ITが意図的に煽っているのがわかると思う。 なんか@ITの記事が最初見たときと違っている気がするけど気のせいかなぁ。 とはいえ、重鎮たちと学生を討論させても、学生がIT(SI)業界に夢を持ってくれるとは思えないので、ここで1つ提案をしたい。 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 ゼッタイに面白いと思うし、学生のイメージアップ間違いなし。重鎮たちに文句を言うだけよりも、自ら動いたほうがゼッタイ良い。 技術評論社さん、ぜ
2007-12-19 - ひがやすを blog - SeamとJBossToolsがやばい
昨日、GavinにJBossToolsのデモを見せてもらいましたが、これがやばい。 もちろん良い意味で。 HOT deployでさくさく開発していくようすは、まるで私のデモのよう。HOT deployは、まだ完璧ではなくて、Hibernateが管理している部分とメッセージリソースは、HOT deployが利かないようだけど、あそこまでできているとは、すばらしい。 ツールのサポートもかなりGood。今後は、フレームワークだけではなくて、ツールも含めて生産性をあげるべきだというSeasar2の流れと完全にシンクロしてますね。 SeamとJBossToolsを組み合わせての開発は、Springといくつかのフレームワークを組み合わせて開発するより明らかに生産性が高いと思います。HOT deployもできるし、ツールが隅々までサポートしてくれるから。nekopが自信をもってそういってたのもうなづけま
僕がRubyをやめたわけ - ひがやすを blog
私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこすことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふくれあがってしまいました。その上、Rails では動的なコードの変更が可能なため、開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバレッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も安定していません。それなのに開発コミュニティはそのことに見向きもしません。 liftを開発した人へのインタビューなんだけど、ちょっとひ
「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保
優秀な技術者をラインマネージャにすると「だめ」になる - ひがやすを技術ブログ
たいていの会社は、部長だとか課長だとか呼ばれるラインマネージャがいます。ラインマネージャの仕事は、部下が能力を発揮できるようにサポートしてあげることです。 会社の中で、昇進していくとは、平社員 -> 課長 -> 部長 -> 取締役のように役職を上げていくことです。役職の名前は、会社によって違うと思いますが、その仕組みはどこも一緒でしょう。 でも、実はここに問題があります。 あなたが優秀な技術者で平社員だとします。その仕事ぶりが認められて、課長に昇進することになりました。そのとき、あなたは、給料と引き換えに、大好きだった技術者のポジションを失うのです。技術のために時間を費やすことは許されず、管理業務に追われる日々が続きます。 ラインマネージャは、技術よりも組織を動かすほうが好きな人にとっては、やりがいのあるポジションです。しかし、「管理業務なんかめんどくさい」「技術で世の中を変えてみせる」と
2008-03-05 - ひがやすを blog - SIerが自動車産業をまねしようとするのはいい加減やめなさい
「自動車のような産業構造に再編すべきだ」。NTTデータの山下徹社長はインドや中国など海外ソフト会社が日本市場に本格進出してくる前に、ソフト産業の構造改革を実行する必要性を説く。日本のソフト産業が崩壊の危機にあるからだ。 パッケージベンダが自動車産業を参考にするのは、100歩譲るとありかもしれない。消費者に受け入れられるだろうという予想にもとづきプロダクトを開発していくモデルだから。 でも、やっぱないな。車は、多少の違いがあっても、どれも基本的な構造は同じ。パッケージは、いろんなものがあるからね。 それに対して、SIは一品ものだもの。規格(パッケージ)通りじゃないものを作るのがSIです。 マフラーだけを作るソフト部品会社、タイヤだけを作るソフト部品会社と、システムインテグレータと呼ぶシステム組み立て会社に分業化することで、インテグレータはソフト部品会社から調達した部品を組み合わせてシステムを
「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は初心者
ひがやすを blog - JavaからRubyへ -
http://d.hatena.ne.jp/higayasuo/20070417#1176813784の続き。 前回のエントリーでDIContainerが提供する機能で重要なのは AOP スコープ管理 で、IoCがDIContainerの敷居を高くしていると書きました。それでは、どうしたらよいのでしょうか。 必要なオブジェクトは、自分から取りにいけばよいのです。たとえば、AOPとスコープ管理を低要するFactoryクラスがあるとします。 public class Factory { public static T getInstance(Class<? extends T> type) { ... } }使うときには、次のように呼び出します。 Service service = Factory.getInstance(Serivice.class);このFactoryクラスを使ったときのC
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第二回チキチキ Java-ja 大運動会 〜比嘉さん参戦!!本当のクロスコミュニティを見せてやる!!〜 - ひがやすを技術ブログ