残業を悪とするチームを作ろう - ひがやすを技術ブログ
長時間労働やサービス残業は、基本的には会社の問題であり、上司の問題です。 例えば、大手SIerで長時間労働やサービス残業が発生するよくあるケースを見てみましょう。 会社は、ワークライフバランスを向上させるために、年間360時間以上の残業をしてはいけないというルールを決めたとします。この段階で、会社は残業は社員のために良くないと認識しています。 現場は、社員の稼働率を上げるためにオーバーワーク気味に仕事をアサインします。仕事がないときに備えて、仕事があるときは、多めに仕事を振るのです。これが間違いなのですが、たいていの現場は、このように行動してるでしょう。つまり、仕事があるときは、多めに振られているので残業することが前提なのです。 ここで、会社の作った残業規制のルールが効いてきます。上司は、会社のルールがあるので、月30時間以上の残業をつけることを基本禁止します。「残業をつけることを禁止する
いまさらきけない「ドメインモデル」と「トランザクションスクリプト」 - ひがやすを技術ブログ
このネタは、私自身も何度も書いてきたけど、結局意味のある結論になったためしがありませんが、再度考え直してみたいと思います。 「ドメインモデル」と「トランザクションスクリプト」をすごく簡単に説明すると、トランザクションスクリプトとは「アクションより起動される一連の手続き」、ドメインモデルとは「ドメイン内の名詞によって体系化されたモデル」です。 トランザクションスクリプト派は、「トランザクションスクリプトの方が書くのが簡単だし、業務アプリケーションにオブジェクト指向は、ほとんど必要ない」といいます。 それに対し、ドメインモデル派は、「ドメインモデルはオブジェクト指向を生かすことができるのでメンテナンス性が良い」と主張します。 ずっと平行線のままですね。 私は一番最初に「ユースケースと一対一にサービスクラスを設け、ビジネスロジックはサービスクラスに記述する」という主張をしてました。 記念すべき(
DIコンテナの必要性 - ひがやすを技術ブログ
DI コンテナの起動が遅いなら、起動が速いのを作ればいいじゃない 何度か書いているとおり、DIはテストをしやすくすることが一番のメリットであり、オンプレミスの世界では、今でもある程度有効です。ただ、appengineの世界では、テストする環境が整えられているので、DIを使う必要はないということです。 http://d.hatena.ne.jp/higayasuo/20091115/1258245284 DIを使ったことがある人はわかると思うけど、DIには、ある程度のめんどくささがあります。appengineの世界では、DIがなくてもテストが簡単にかけるので、わざわざめんどくさいことをする必要はないでしょう。 appengineの世界でテストがどれくらい書きやすいのかは、次のustをみればわかります。 http://www.ustream.tv/recorded/6377235 技術的には、
DOAはRailsの銀の弾丸か - 書評:エンタープライズRails - ひがやすを技術ブログ
Railsは、最初に素早く動くもの(scaffoldなど)を作って、そこからフィードバックをもらい、少しずつ動く状態を保ちながら、改良していくスタイルです。 スモールスタートを切るには最も向いているスタイルです。しかし、最初はそれで良かったものの、プロジェクトへの要求が増えるにしたがって、コードは複雑になっていき、だんだんメンテするのが大変になってきます。 これはRailsの問題ではなく、システムのアーキテクチャの問題です。 システムでやらなければならないことがたくさん増えたときでも、急にコードが複雑になることなく、きちんとメンテナンスし続ける方法があるなら、誰でも学んでみたいと思うでしょう。 その方法を教えてくれるのが、エンタープライズRailsなのです。 エンタープライズ Rails ―企業ユーザのためのWebアプリケーション設計術 作者: Dan Chak,高井直人,笹井崇司出版社/
テストを書くときはコストベネフィットを考えろ - ひがやすを blog
InfoQにKent Beckの最新の提案がでてますね。Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案 でも、これは、Kent Beckが「ごく短期のプロジェクトではテストを省略しても良い」といってるわけではないと思うんですよ。キャッチーなタイトルをたまたまつけられてしまっただけで。 重要なポイントはここだと思います。 Maxを開発しているとき、テストを書くか否かという質問は、要するに、そのテストが単位時間当たりにより多くの有効な実験をするのに役立つかどうかでした。もし役に立つのであれば、私はテストを書きます。そうでなければ、不要だと判断します。私はMaxの収入を軌道に乗せるためのチャンスを最大化しようとしているのです。 つまり、「テストがかけた時間の割りに役に立つと思ったら書くし、そうでなければ書かない」ということだと思います。別に短期のプロジェクトでも、コス
梅田望夫にオープンソースを語るなとガツンと申し上げたい - ひがやすを技術ブログ
例えば、インターネットが社会にもたらしたインパクトのひとつに「オープンソース」という考え方があります。これは元々ソフトウエア開発に端を発した概念なのですが、いまやそれにとどまらず、世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していくといった可能性を含む、より広い応用範囲での思考や行動原理を意味しています。サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日本では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知（ウィズダム・オブ・クラウズ）」が働
プログラミングファースト開発 - ひがやすを技術ブログ
プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら
SIerが必要としているのは業務知識だという都市伝説 - ひがやすを blog
SI業界が開発するシステムの目的は何か？ それがつまり「業務知識」というやつで、金融や保険だったり、証券取引、財務会計、生産管理、物流・在庫管理、販売管理だったりするのだ。それぞれ必要とされる知識は非常に多い。普通の新入社員がOJTで身につけようと思ったら数年かかってもおかしくないだろう。 金融(ディラーが使うようなポジション計算をするフロントシステム、リスク計算をするようなミドルオフィス、勘定系のバックオフィス)、流通、輸出入、製薬など、いろんな業務をやってきたおいらが通りますよ。 確かに金融は業務知識がないと歯が立たない。でも、自分の経験した限りでは、それ以外の業務は、案件が始まってから勉強しても十分間に合います。 一週間以内の勉強で、お客様のところにいってシステムの仕様を話し合うことはできるようになります。もちろん、この道何年って人にはかないませんよ。でも、仕様を決める分には困らない
第一回ひがやすを飲み会やるよ - ひがやすを技術ブログ
エンジニアの未来サミットのときに予告した「IT業界をざっくばらんに語る会」を10/8(水)におこないます。 学生だとか若手でIT業界についていろいろ聞いてみたい人だとか、業界の人といろいろ話してみたい人だとか、自由に参加してください。もちろん、若手じゃなくてもOK。 http://d.hatena.ne.jp/hyoshiok/20080915 表では聞けないようなことも自由に聞いてください。ただ、そういうことは後からblogに書かないように(笑)。 営業の方だとかエンジニアでない人も、IT業界に関係ない人も遠慮なくどうぞ。いろんな人がいたほうが、有意義な話になると思います。 エンジニアの未来サミットのようなちゃんとしたイベントも重要だけど、こうした草の根的な飲み会も重要だと思う。 開始は、19:00から。参加したい方は、higayasuo_at_gmail.com(_at_は@に変更)に
RailsとSeasar2で同じアプリを作って比較する - ひがやすを技術ブログ
この間から、コードなにがしに「SAStrutsによるWebアプリケーションスーパーサンプル」を投稿し始めましたが、さらに同じ仕様のものをRuby on Railsで作成してみようと思いまして「Ruby on Railsあれこれ」に「Ruby on RailsによるWebアプリケーションスーパーサンプル」も始めちゃいました。。。 RailsとSeasar2で同じアプリを作っている方がいました。 nanigac.com Loading... Seasar2の方は、とても情報が充実しているので、SAStrutsとS2JDBCで開発されている方は一度目を通しておくといいんじゃないかと思います。 生産性の違いはというと コーディング量は、 「Ruby on Rails」＜「SAStruts」 ですね。Railsの方が、生産量は少なくすみます。 ただ、情報の充実度は、 「Ruby on Rails」＜
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
