ある程度の年齢を迎えたプログラマが生き残るには - ひがやすを技術ブログ
ある程度の年齢を迎えたプログラマが抱える悩みに、「若手のプログラマと比べて、どうやって価値を出していくか」という問題があります。これは言い換えれば「同じような生産性であれば、相対的に給料の低い若手のプログラマに置き換えられてしまうのではないか」という悩みです。 35才(2004年)でプログラマとしてオープンソースを始め、今年で42才になる俺が通りますよ。 35才までは、SIerの中でSEをやってたので、そんなにプログラムは書いたことがないです。 上記のエントリには、いろんな戦略が書いていますが、ぶっちゃけ戦略は一番重要なことではなく、一番重要なのは、常に自分の価値を高めるために努力し続けることです。 努力や挑戦をやめたら、自分の価値はどんどん陳腐化して下がっていくのは当たり前なのです。 自分がどんなことに挑戦してきたのかちょっと書いてみますね。 2004年1月、プログラマとして何か新しいこ
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる
App Engineでバージョンによる楽観的排他制御 - ひがやすを技術ブログ
Song of Cloudで送金のトランザクション処理パターンが紹介されていました。 http://songofcloud.gluegent.com/2009/11/blog-post_18.html 同様のpython版がこちら Distributed Transactions on App Engine - Nick's Blog 上記のやり方で基本的には問題はないのですが、バージョン管理による楽観的排他制御を行っていないので、送金だけを考えるなら、残高を差分で更新しているので大丈夫ですが、これを一般的なパターンに拡張しようとすると、楽観的排他制御は必要になります。 楽観的排他制御とは、エンティティにバージョン番号を持たせておいて、メモリ読み込んだときのバージョン番号と書き込むときのバージョン番号が等しいことを確認する方法で、RDBMSの場合は、次のようなSQLを実行することで実現しま
App EngineのEntityGroupを理解しよう - ひがやすを技術ブログ
App EngineのEntitiGroupは、Keyの親子関係を利用して組み立てられたEntityの集まりです。 Entityとは、Bigtable上の1つの行で、ユニークに識別するためのKeyを持っています。 Keyは、種類をあらわすkindとAppEngineから自動的に採番されるidもしくはアプリケーション側で自由に決めることのできるnameで構成されます。 通常は、AppEngineの自動採番に任せますが、Emailのアドレスをキーに使いたい場合などは、nameを使います。kindはテーブル名のようなものだと思ってください。 Keyの親子関係は次のようにして作ります。 Key grandparentKey = KeyFactory.createKey("Grandparent", "しげお"); Key parentKey = KeyFactory.createKey(grand
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
自分の書きたいコードを書け - 脱職業プログラマのすすめ - ひがやすを技術ブログ
良く仕事以外のプログラムをしたことない人っているじゃないですか。ここでいう職業プログラマとは、仕事以外では、プログラムをしない人のことを指しています。 仕事以外でもプログラミングをしている・勉強している人、は、職業Onlyプログラマではなく、職業でもプログラムをしているけど、それ以外にも努力をしている人です。 それは、もちろん何の問題もないんだけど、それだけでは実力はつきません。たぶん、コードを書きながら自分が成長している気がしてないでしょう。あなたの直感は正しい。 何らかのフレームワークを使えば、それなりにできることが増える、それももちろん成長です。ただし、知識のね。プログラミングの力はそれほど変わっていないはず。 自分の経験で言えば、多くの人に読んでもらえないコードは、いくら書いても、実力につながりにくい。人に見せようとするコードは、書いているだけで、いろんなことを考えるし、それが、力
SQL脳からBigtable脳へ - ひがやすを技術ブログ
Google App Engineを使って一番悩むのは、RDBMSが使えなくなって、Bigtableを使わなければならなくなったことでしょう。 「これまでSQLでこう書いていたのが、Bigtableではそのまま実現できない、どうすればいいんだ」と思う方も多いはず。 今度のSeasar Conferenceでは、「SQL脳からBigtable脳へ」というテーマであなたの悩みを解決します。 申し込みはこちら https://event.seasarfoundation.org/sc2009autumn/Form/RegisterForm 春のときよりももっと具体的に、「こんなSQLは、Bigtableの制限でできないけど、こんな感じでやれば同じ結果を得ることができる」見たいな感じで。 これで、Bigtableに対する不安も払拭されることでしょう。 それ以外に、 Slim3入門 GWTではじめる
深い業務知識が必要なのは案件の提案者と要件定義者 - ひがやすを技術ブログ
SIerが必要としているのは業務知識だという都市伝説のエントリで、誤解されたのは、「SIerは深い業務知識が不要だ」というふうに私が主張していると思われたことですね。 誤解されるのは、もちろん、私の書き方が悪かったせいなので、続きを書きます。 SIerで深い業務知識が必要とされる人がいます。案件の提案者と要件定義者です。営業がお客様のところから案件を持ってくると、その案件に関する深い業務知識を持っている人がアサインされ、提案書と見積りを作ります。この役割の人は、深い業務知識が必要です。 無事に案件が獲得できたとしましょう。お客様のところにいって要件をつめるのですが、このときのメンバも深い業務知識が必要です。しかし、全員が深い業務知識を持っていなくても大丈夫。全体の半分弱くらいのメンバが深い業務知識を持っていれば大丈夫だと思います。案件の難易度にもよりますが、一人が業務を深く理解していれば大
java.util.Dateをjava.sql.Dateにきちんと変換する方法 - ひがやすを技術ブログ
多くの人はこうやればいいと思っているかもしれません。 java.util.Date d = new java.util.Date(); java.sql.Date d2 = new java.sql.Date(d.getTime());確かにこれでも一応変換はできますが、きちんと変換してはいません。java.sql.DateのJavadocを見るとこう書いてあります。 SQL DATE の定義に対応させるために、java.sql.Date のインスタンスでラップされたミリ秒の値は、インスタンスが関連した特定のタイムゾーンで時間、分、秒、ミリ秒をゼロに設定することで、「標準化」する必要があります。 つまり、java.util.Date#getTime()をjava.sql.Dateにただ渡すだけでは不十分で、「特定のタイムゾーンで時間、分、秒、ミリ秒をゼロに設定しなければいけない」のです。そ
Seasar2でサクサクか炎上か - ひがやすを技術ブログ
可燃プロジェクトに飛び込むことになりました。下記のような炎上する要素満載。 関係者各社に告知済みのためカットオーバーは伸ばせない 外部仕様を策定した会社は行方不明 外部仕様はあるが、OS も AP サーバも環境もアーキテクチャーも未定 外部仕様を分かる人がいないw 開発は 3 社合同なのにソース管理方式も決まってない DB アーキテクト不在っぽい フレームワークに詳しい人がいない AJAX っぽいのたくさん お金がない、規模はわりとでかい、納期短い、残業禁止、増員不可 最初このエントリを見たとき、4/1だったこともあり、一瞬ネタかなと思ったんですが、その後に、SAStrutsとS2JDBCに対する具体的な質問がいくつもあり、私のほうもできる限り質問に答えました。 その後、どうなったのか気がかりだったんですが、今見たらこんな書き込みが 開発メンバからは、簡単で楽でいい！ 1 機能が 1 時間
DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ
Railsは、最初に素早く動くもの(scaffoldなど)を作って、そこからフィードバックをもらい、少しずつ動く状態を保ちながら、改良していくスタイルです。 スモールスタートを切るには最も向いているスタイルです。しかし、最初はそれで良かったものの、プロジェクトへの要求が増えるにしたがって、コードは複雑になっていき、だんだんメンテするのが大変になってきます。 これはRailsの問題ではなく、システムのアーキテクチャの問題です。 システムでやらなければならないことがたくさん増えたときでも、急にコードが複雑になることなく、きちんとメンテナンスし続ける方法があるなら、誰でも学んでみたいと思うでしょう。 その方法を教えてくれるのが、エンタープライズRailsなのです。 エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術 作者: Dan Chak,高井直人,笹井崇司出版社/
そろそろSeasar2のガラパゴス戦略について語っておくか - ひがやすを技術ブログ
Slim3のファーストリリース(今月中)の前に、Seasar2の開発で、どのような戦略をとったのか話しておきます。 2005/11/8、Seasar2.3のバージョンをリリースしました。このバージョンから搭載されたのが、コンポーネントの自動登録機能です。設定ファイル無しで開発できるようにする機能ですね。Springだと2.5から搭載されたcomponent-scan。 Spring2.5のリリースは、2007/11/19なので、実に2年以上差があります。オープンソースの世界では、みんなが手の内を見せ合っているので、誰かが新しい機能を実装した場合、それが良いものであれば、ライバルも直ぐにそれを取り入れ、それほど機能差がつくことはありません。 なぜ、従来のXML地獄を解消する「コンポーネントの自動登録機能」を実装するまでの期間にこれほど差が出たのか、それはガラパゴス戦略のせいなのです。 Sea
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
テストを書くときはコストベネフィットを考えろ - ひがやすを blog
InfoQにKent Beckの最新の提案がでてますね。Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案 でも、これは、Kent Beckが「ごく短期のプロジェクトではテストを省略しても良い」といってるわけではないと思うんですよ。キャッチーなタイトルをたまたまつけられてしまっただけで。 重要なポイントはここだと思います。 Maxを開発しているとき、テストを書くか否かという質問は、要するに、そのテストが単位時間当たりにより多くの有効な実験をするのに役立つかどうかでした。もし役に立つのであれば、私はテストを書きます。そうでなければ、不要だと判断します。私はMaxの収入を軌道に乗せるためのチャンスを最大化しようとしているのです。 つまり、「テストがかけた時間の割りに役に立つと思ったら書くし、そうでなければ書かない」ということだと思います。別に短期のプロジェクトでも、コス
いっちゃ悪いけどGAEでJavaを選択する場合の最大の理由をわかっちゃいないね - ひがやすを技術ブログ
いっちゃ悪いけど、 GAE で Java を選択する場合の最大の理由をちゃんと解ってて話をしているとは思えない。 タイトルの通りだけど、Javaはすでに十うん年を一線で過ごしてきた言語だ、過去のコード資産が莫大にあるはずで、それを活用する場合は GAE で Java を選択する事のメリットがある。 「うん十万行の既存コードをそのまま投入できる。それにインターフェースするために多少オーバーヘッド気味のコードが数100行必要なのが何の問題がある？」これを言えないJava 使いはコード資産って物が無い貧乏人だし、過去資産に物を言わせないJavaなど相手にするのがあほくさいぐらい貧弱なものだ。 そのままの言葉で返すけど、いっちゃ悪いけどGAEでJavaを選択する場合の最大の理由をわかっちゃいないね。Javaの豊富な標準ライブラリを使えるというのは、大きな利点だと思うけど、過去に自分たちで作ったよう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
