続Seasar2から卒業しよう - ひがやすを技術ブログ
前回のエントリは、OSSとしての説明が抜けていたので、今回、きちんと説明させてください。 Seasar2、S2JDBC(元々Seasar2の一部)、SAStrutsは、これまでも、これからもOSSであり、githubでずっと公開されるので、フォークでも何でも好きにしてください。 Mavenリポジトリ、ドキュメント、MLなどがどうなるのかは、現在話し合っている最中です。方向性としては、現在、Seasar2を利用している人々に、最も影響の少ない選択肢が選ばれるはずです。 Seasar Foundation、Seasar Projectsのクローズの提案をしましたが、これは、取り下げます。 あくまでも、お願いという形でしたが、私がお願いするとかなり強制力を持ってしまうことに対する配慮がかけてました。 2016/9/26にSeasar2、S2JDBC、SAStrutsのメンテナンスを現在のコミッタ
きれいなソースコードを書くために読んでおくべき本10冊 - ひがやすを技術ブログ
なんか、プログラマとして必要な本をあげるのが流行っているようなので、自分も書いておこう。きれいなソースコードを書くために読んでおくべき本10冊。 最初はリファクタリング リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (312件) を見る 以上。終了。10冊じゃないか(^^; きれいなソースコードを書きたければ、一にも二にもリファクタリング、それしかない。 後は、良いソースコードを読みながら自分でも、実際にプロダクトを作ってみること。OSSとして公開すると、自然と良いコードを書こうというモチベーショ
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
もうエンタープライズJavaなんて捨ててしまえ - ひがやすを技術ブログ
これまでずっとなるべく言わないようにしていたのだが、もう平たく／明快に言うことにしました。 １）エンタープライズJavaはもう立ち直れないと思う。 だから、 ２）GAEを勉強してそのままクラウドというバズワードに踊らされる道を真剣に考えてみて欲しい。 これまでは、１）は言わずに、２）だけ言ってきた。で、「クラウド」の中でも、私が知っている「GAEで開発する」ことの楽しさをなるべく具体的に紹介するようにしてきた訳なのであるが、前半も言うことにしました。 その理由は、若い人に早く気づいて欲しいから。年を取ったら駄目、というわけではないが、あるフレームワークになれて、その経験が長くなってくると、進路変更は大変になる。ところが、多くの人が「もはやそのフレームワークは、時代にあっていない」と気づく頃には、そういう「進路変更大変状態」になってしまっていることが多い訳です。 というわけで、明言することに
JavaでRailsのflash機能を実現する - ひがやすを技術ブログ
Railsのflash機能とは、次のページまでは保持されている変数で、次の次のページでは、消えてしまいます。主に、リダイレクトでエラー画面に遷移して、メッセージを一度だけ表示したいような場合に使います。 Strutsで、このような機能を使いたい場合は、セッションスコープのActionMessagesを使います。 生Strutsを使う場合は、Action#saveMessages(HttpSession session,ActionMessages messages) SAStrutsを使う場合は、ActionMessagesUtil#saveMessages(HttpSession session, ActionMessages messages) を呼び出せばOKです。 意外にみんな知らないんだね。Twitterで困っている人がいたから書いてみた。
自分の書きたいコードを書け - 脱職業プログラマのすすめ - ひがやすを技術ブログ
良く仕事以外のプログラムをしたことない人っているじゃないですか。ここでいう職業プログラマとは、仕事以外では、プログラムをしない人のことを指しています。 仕事以外でもプログラミングをしている・勉強している人、は、職業Onlyプログラマではなく、職業でもプログラムをしているけど、それ以外にも努力をしている人です。 それは、もちろん何の問題もないんだけど、それだけでは実力はつきません。たぶん、コードを書きながら自分が成長している気がしてないでしょう。あなたの直感は正しい。 何らかのフレームワークを使えば、それなりにできることが増える、それももちろん成長です。ただし、知識のね。プログラミングの力はそれほど変わっていないはず。 自分の経験で言えば、多くの人に読んでもらえないコードは、いくら書いても、実力につながりにくい。人に見せようとするコードは、書いているだけで、いろんなことを考えるし、それが、力
0.5倍しかできないエンジニアが生き残る方法 - ひがやすを技術ブログ
だから私がもし本当に10倍パフォーマンスがあって志あって,真に自分のやりたいことのあるエンジニアだったら,会社には2倍程度のパフォーマンスだけ見せて仕事をこなしつつ,残りでほかのことすると思う． この話の前提には、仕事をどれだけこなすかという量が重要だということがある。 でも、量を誇るエンジニアは、会社にとって都合の良い道具に過ぎない。実際、パフォーマンスがものすごく優れた人がいても、会社はそれに応じた給与を支払わないだろう。 それでは、どういう人に会社はお金を払おうと思うだろうか。それは、その人の成果のユニーク性が高いとき。他の人にはできない成果を出してくれるから、そこに付加価値が生まれる。 代替不可であることが重要なんですよ。かわりはいないから、お金を払ってもらえる。代替不可な人間になることは難しい。だからこそ、価値が出るのです。 0.5倍しかできないエンジニアが生き残る方法も是非＞＜
2009年SI企業の不況の乗り切り方 - ひがやすを技術ブログ
不況の嵐が吹き荒れていますが、SI業界の中の人はどうお感じでしょうか。たぶん、仕事が減ってきている気はするけど、製造業ほどひどくないと思っているのではないでしょうか。 ただこれは、不況の波が押し寄せてくるのが、遅いだけです。 SI業界では、プロジェクトが一年くらいかかることも多いので、まだ不況じゃないときに受注した案件分でそれなりに食っていけるのです。しかし、SI業界の主なお客様である製造・金融業界は、案件を凍結したりなど、新規の受注案件はかなり減ってきているので、今やってる仕事が一息ついたら、やることがなくなってくるでしょう。 仕事が減ってまずすることは、人減らしですね。元請なら、下請けをきることが最初に検討されるでしょう。ある程度はこれで調整できますが、直ぐに限界が来ます。今の元請は、下請けに任せていたようないわゆる下流工程を自分たちでは行えないので、単純に下請けをきるだけではすまない
日本IBMのリストラが始まった - ひがやすを blog
「日本で「キャリア選択援助計画」を終了させる。浮いた１億ドルの多くを日本での「Ｗｏｒｋｆｏｒｃｅ Ａｃｔｉｏｎ」（＝リストラ）に使い、日本ＩＢＭの収益構造をより競争力のあるものにする。」 かねてから噂のあったIBMのリストラですが、現実におきてるようです。これは、景気後退局面に対するすばやい対応なのでしょうか。 直接の原因は、景気かもしれませんが、根本は、アメリカ流の株主至上主義じゃないかな。株主を大切にするのはもちろん重要なんだけど、株主のため、過度に短期の数字を良くみせようとするところにあるんじゃないかと思っています。これは、IBMに限った話じゃないけどね。 米IBMは、2005年にも欧州を中心に、1万〜1万3000人のリストラをやっています。 とはいえ、会社の業績が悪い訳ではない。米IBMの第一四半期決算は、1株あたり利益、売上高とも前年を上回っている。それでも、株主のため、飽くなき
「元請けにこだわる理由」の「いいがかり」についてひとこといっておくか - ひがやすを技術ブログ
自社のバックオフィスの方が、外注先に対してどんな立ち居振る舞いをしているのかご存じですか？ 自社と外注先との間の契約がどのようになっているのかご存じですか？ それを目の当たりにしても同じことを言い続けられる自信はありますか？ そういうことはスーツの仕事とレッテルを貼って見て見ぬ振りをしてませんか？ それでいて業界を変えたいなどといいますか？ 業界を変えたいっていってるところから、おいらのことを言ってるとして話を進めるよ。 バックオフィス(この文脈では調達のことかな)の方が、外注先に対してどんな立ち居振る舞いをしているのかは、正直良くわかりません。転職したことがないので、他の会社のことは良くわからないけど、弊社の場合は、調達と外注先が価格や条件の交渉する場に、案件側の人間は立ち入ることはないためです。必要だといわれたらもちろん同席するけどね。 新規取引をさせていただくときの最初の顔合わせに同
勉強会とかコミュニティ活動に参加できるのは、下請けに仕事を押しつけてるからじゃね - ひがやすを技術ブログ
今は友人までの公開になっているので、リンクをクリックしても発言を読めません。このエントリを書いたときは誰でも読めたんだけどね。 勉強会とかコミュニティ活動に参加できるのは、下請けに仕事を押しつけてるからじゃねーの？ 仕事は、一人ではできないので、いろんな人に支えられてやっています。そういう意味で、支えてくれる人なしには何もできないのは事実です。 で、だ。 自分はどうかといえば、おれは、ほとんど、一人で仕事をしているから、下請けとか関係ないです。うちの会社でどうかといえば、下請けに仕事を押し付けている人なんていないですよ。みんな仕事大変だからね。忙しいし。 で、だ。 誰に言っていてもいいんだけど、上記の言葉の裏には、コミュニティ活動は、暇だからできるみたいなニュアンスが感じられるんだけど(間違っていたらごめん)、コミュニティ活動ってかなり大変だよ。 例えば、この前、「ひがやすを飲み会」なんて
IBMの問題はアメリカナイズされた老害 - ひがやすを blog
日本IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日本的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ
Railsバブルは終わった - ひがやすを技術ブログ
Railsバブルは終わったと思う。良い意味で。 Railsは世の中の技術者に大きな影響を与えたフレームワーク、そして偉大なフレームワークですが、バブルを起こそうと変に煽っている人たちが前から気になっていました。 最近、Railsについて何度も取り上げているのは、手放しに近い状況で「Rails良い」と煽りまくっている人が目に付くから。こういうのは、バブルにつながるし、バブルは最終的に、はじけてしまうものです。Railsバブルは、もうとめられない気もしますが、Rubyはバブルになってほしくない。 だってバブルがはじけて生き残るのはほんの一握りですよ。自分たちが原因で、失敗するならあきらめもつきますが、バブルを起こして運がよければもうけられるみたいに思っている人に散々利用されて失敗するのは、納得がいかないですね。過剰に評価されれば、それだけ失敗する案件も増えてくる。 煽られてそのプロダクトを採用
開発生産性が低い方が収入が多いって変だよね - ひがやすを技術ブログ
開発生産性が低い方が収入が多い（人月がかかるほどお金がとれる）というビジネスモデルを根底から覆す可能性があります。開発生産性をあげればあげるほど収入が減ってきます。SIビジネスが立ち行かなくなる方向に向かうのです。 実際の現場では、開発生産性が低くて、人月がかかるほうが売上が増えるというのは、紛れもない事実です。大手SIerの開発手法が、生産性よりも失敗しないことを重視するのは、この事実が原因なのは間違いありません。失敗せずに多くの工数をかけたほうが売上が増えるのです。 だから、ソースコードと一対一に対応するような無駄なドキュメントを「誰が書いても同じようなソースコードにするため」なんて理由で書かせるのです。 詳しくは「誰が書いても同じコード」は大事なことなのかのエントリを参照してください。 営業は、売上で評価されることが多いので、営業の力が強いところは、売上至上主義に走りがちです。でも、
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
女子だらけの飲み会に参加して感じること - ひがやすを技術ブログ
私は正直、女子だけの飲み会のほうが怖い。 大学時代は、月2,3回、ワイン会(ワイン飲み会)に行ってたんだけど、ワイン会ってほとんど女子ばっかりなんだよね。後、10年くらい料理教室に通っているんだけど、料理教室も女子ばっかりです。 はっきりいって男子だらけの飲み会に参加するようになったのは、オープンソースをはじめてから。 そんな「女子だらけの飲み会」と「男子だらけの飲み会」の両方を結構の数体験している立場からすると、「女子だらけの飲み会」の方が気が楽です。 「女子だらけの飲み会」の場合、女子は(基本的に)何にも気を使わないんだよね男子に対して。好き放題にしゃべってる。話をちゃんと聞いて、飲み物や食べ物に気をつけていれば大丈夫だから精神的には結構楽。 話の中身は、怖かったりするのかもしれないけど、そこには、深く触れないから問題なし。 それに対して「男子だらけの飲み会」の場合、しゃべらない人が結
Rubyにワクワク感以上に求めるもの - ひがやすを技術ブログ
「『まつもとゆきひろ×最首英裕』〜Rubyを仕事に2008〜」の対談のレポートがあがっていたので、とりあえず気になった点を突っ込んでおきます。 最首氏はRubyとJavaを比べたとき、「RubyはJavaのように使うことができて、 JavaはRubyのように使うことは出来ないかもしれない」と述べ、RubyをJavaのように使うことも危険だし、JavaをRubyのように使うのも同じように危険だと思います。 またRubyを仕事で使うメリットとして 「アジャイル開発がしやすい、プロトタイピングが容易」 「学習曲線が早い」ことを挙げた。Railsがあるので、プロトタイピングはやりやすいと思います。アジャイル開発は、チームのマインドの問題なので、言語は関係ないよね。 「学習曲線が早い」というのは、賛成できないなぁ。 まつもと氏は「10年前のJavaに似ていると言われる」と述べ、 最首氏は「Javaの
SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
NTTデータと真昼の対決 - ひがやすを技術ブログ
昨日、NTTデータに「お前は最近、NTTデータに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、NTTデータを嫌っていると思っているデータ関係者は、実際多いようです。 データの偉い人の発言に対して、それはちょっとおかしいんじゃないのといったことはありますが、データを嫌いといったことはもちろんないはず。 データの社員の中に根強くある(と思う)「プログラミングがあまりできない人でも何とかなるように、ガチガチにルールやツールで縛る。できる人はスキルを発揮できなくなるかもしれないけど、それはしょうがない。」という考えは、個人的には好きじゃないけど。大規模なプロジェクトをまかされるSIerとして、そう思う気持ちは良くわかるんだけどね。 話し合いの中で、私が言ったのは、できる開発者が力を発揮できるように、体力勝負になってしまうような縛りは
10年間泥のように働いて花が咲きました - ひがやすを技術ブログ
蓮の素晴らしさを語りたかったら、まずは花を見せるべきなのだ。花がわかってはじめて泥の重要さがわかってくるんだから。 2008-05-29 - ひがやすを blog 小飼弾のアルファギークに逢ってきたのメンバーと学生会の討論会を開くのだ。 もちろん、司会は、ダンコーガイ。いいよね、弾さん。 もちろんOK。というよりもすでに同様の話がいくつも来ているので、この通りになるかとにかく、ちゃんと「花」がある討論会はできるだろうし実現するだろうしすでにいくつか実現している。 しかし、これはこれでどうしても偏りが出る。10年も泥の中にいた人というのはさすがにこのメンバーの中から見つけるのは難しい。そしてIT業界の広さを考えれば、本当にそういう人がいてもおかしくないはずなのだ。 10年間SIerで泥のように働いたおいらが通りますよ。 おいらが、最初に就職したのは、電通国際システムという会社で、今のうちの会
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
