タグ

ブックマーク / higayasuo.hatenablog.com (14)

  • DIとStrategyパターン - ひがやすを技術ブログ

    Strategyパターンは、アルゴリズムをカプセル化し、 交換可能にするものですが、それをDIを使って実現するには、 どうしたら良いのでしょうか。 Strategyが静的なものなら、普通にDIするだけです。 問題は、Strategyがデータに応じて動的に変わる場合です。 その場合は、StrategyのFactoryをDIするようにします。 そして、必要なときに、データをStrategyのFactoryに 渡して、適切なStrategyを手に入れるのです。

    DIとStrategyパターン - ひがやすを技術ブログ
  • 残業を悪とするチームを作ろう - ひがやすを技術ブログ

    長時間労働やサービス残業は、基的には会社の問題であり、上司の問題です。 例えば、大手SIerで長時間労働やサービス残業が発生するよくあるケースを見てみましょう。 会社は、ワークライフバランスを向上させるために、年間360時間以上の残業をしてはいけないというルールを決めたとします。この段階で、会社は残業は社員のために良くないと認識しています。 現場は、社員の稼働率を上げるためにオーバーワーク気味に仕事をアサインします。仕事がないときに備えて、仕事があるときは、多めに仕事を振るのです。これが間違いなのですが、たいていの現場は、このように行動してるでしょう。つまり、仕事があるときは、多めに振られているので残業することが前提なのです。 ここで、会社の作った残業規制のルールが効いてきます。上司は、会社のルールがあるので、月30時間以上の残業をつけることを基禁止します。「残業をつけることを禁止する

    残業を悪とするチームを作ろう - ひがやすを技術ブログ
    ghostbass
    ghostbass 2012/07/09
    起きて13時間のソース?> http://allabout.co.jp/gm/gc/302313/
  • きれいなソースコードを書くために読んでおくべき本10冊 - ひがやすを技術ブログ

    なんか、プログラマとして必要なをあげるのが流行っているようなので、自分も書いておこう。きれいなソースコードを書くために読んでおくべき10冊。 最初はリファクタリング リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行購入: 94人 クリック: 3,091回この商品を含むブログ (312件) を見る 以上。終了。10冊じゃないか(^^; きれいなソースコードを書きたければ、一にも二にもリファクタリング、それしかない。 後は、良いソースコードを読みながら自分でも、実際にプロダクトを作ってみること。OSSとして公開すると、自然と良いコードを書こうというモチベーショ

    きれいなソースコードを書くために読んでおくべき本10冊 - ひがやすを技術ブログ
    ghostbass
    ghostbass 2010/11/26
    つまり「リファクタリング」を10冊買えと
  • AppEngineにどんなアプリが向いているのかを知ろう - ひがやすを技術ブログ

    AppEngineは、万能なプラットフォームではありません。むしろ、かなり使い道は限定されていると言ってもいいでしょう。 向いていないアプリで使うとかなりはまって、アプリが完成しないリスクがあります。 一方、向いているアプリで使うとこれまでよりかなり費用を節約できたりとか、儲けにつなげることができます。 AppEngineにどのようなアプリが向いているかというと、AppEngineがGoogleの既存のインフラをそのまま利用していることをまず知っておく必要があります。 Googleのインフラは、(極端に単純化すると)大量のデータを多くの人に同時に見せるために最適化されています。 AppEngineも同様で、大量のデータに大量にアクセスがあっても大丈夫なように、BigtableというKVSを使っています。また、自動でスケールアウトするWebのFront Endも既存のインフラをそのまま使って

    AppEngineにどんなアプリが向いているのかを知ろう - ひがやすを技術ブログ
    ghostbass
    ghostbass 2010/11/08
    BigTable的にあんまり複雑なクエリーはやめた方がいいかな。アマゾンとかMSとかも考慮に
  • 2007-10-18

    Seasarカンファレンスで、Seasar2入門セッションを、いろんな方に喜んでいただけるようにSeasar2ロードマップと復活のStrutsのセッションに変えるよというアナウンスをしたのですが、Seasar2の入門セッションはやはり必要だということで、元に戻すことになりました。 期待していた方ごめんなさい。でも、入門セッションのほうも面白いネタをいろいろしゃべるつもりなので、是非お越しください。 今後はやるフレームワークは「流れるようなインターフェース」を持ったものになるんじゃないかなぁと思います。流れるようなインターフェースの説明は、ファウラーたんのFluentInterfaceを参照してください。 Seasar2の新O/R Mapper(以後S2JDBCと呼びます)もこの「流れるようなインターフェース」を実現しています。例えば、JdbcManagerを使った検索はこんな感じになります

    2007-10-18
    ghostbass
    ghostbass 2010/07/20
    いれてなかった?
  • Bigtableの使い方教えます - ひがやすを技術ブログ

    GAE/Jを使うのに一番戸惑うのが、データのストレージがRDBMSではなく、Bigtableなことでしょう。 JOINが使えなかったり、WHERE句でORが使えなかったり、これまで慣れ親しんでいた方法が軒並み使えません。 これらの制限は、Bigtableに限ったことではなく、KVS(Key Value Store)型のクラウド系のデータベースではみんないえることだと思います。 最初、私も戸惑ったんだけど、いろいろ触っているうちに気付きました。昔、AS400でやってたころと一緒ジャンと。AS400とは、IBMから出ているオフコン(?)ですね。今は、System iと呼ばれているようです(最新だとまた違うようですが)。 AS400のファイル(テーブル)は、キーもしくはインデックスでアクセスします。インデックス(論理ファイル)は、ある行の特定のカラムがソートされていて、物理ファイル(テーブル)へ

    Bigtableの使い方教えます - ひがやすを技術ブログ
    ghostbass
    ghostbass 2010/06/22
    ISAMに逆戻り
  • 2007-10-25 - ひがやすを blog

    っていうか、Hibernateにも昔からcriteriaあるよね? http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#querycriteria List cats = sess.createCriteria(Cat.class) .add( Restrictions.like("name", "Fritz%") ) .add( Restrictions.between("weight", minWeight, maxWeight) ) .list(); 流れるようなインターフェースとメソッドチェーンは違うものだよヨシオリ。ぱっとみは似ているかもしれないけど。 流れるようなインターフェースでは、ソースコードを書いている人が、中断することなく流れるようにコーディングできなければいけない。 HibernateのCrit

    2007-10-25 - ひがやすを blog
  • 梅田望夫にオープンソースを語るなとガツンと申し上げたい - ひがやすを技術ブログ

    例えば、インターネットが社会にもたらしたインパクトのひとつに「オープンソース」という考え方があります。これは元々ソフトウエア開発に端を発した概念なのですが、いまやそれにとどまらず、世の中をより良い方向に導くと思われるテーマがネット上で公開されると、そこに無数の知的資源が集結して課題を次々に克服していくといった可能性を含む、より広い応用範囲での思考や行動原理を意味しています。サブカルチャー領域への応用は少しずつ進んでいるのですが、全体として、こうした動きがいまだに日では根付いていません。政治とか社会変化がテーマとなると特に、陰湿な誹謗・中傷など「揚げ足取り」のような側面の方が前に出てきていて、ウェブのポジティブな可能性──何か知的資産が生まれそうな萌芽がネット上に公開されると、そうしたことに強い情熱を持った「志向性の共同体」が自然発生して、そこに「集合知(ウィズダム・オブ・クラウズ)」が働

    梅田望夫にオープンソースを語るなとガツンと申し上げたい - ひがやすを技術ブログ
    ghostbass
    ghostbass 2009/06/19
    ニコニコ動画なんてめちゃくちゃオープンソースっぽいけど。
  • 自分の書きたいコードを書け - 脱職業プログラマのすすめ - ひがやすを技術ブログ

    良く仕事以外のプログラムをしたことない人っているじゃないですか。ここでいう職業プログラマとは、仕事以外では、プログラムをしない人のことを指しています。 仕事以外でもプログラミングをしている・勉強している人、は、職業Onlyプログラマではなく、職業でもプログラムをしているけど、それ以外にも努力をしている人です。 それは、もちろん何の問題もないんだけど、それだけでは実力はつきません。たぶん、コードを書きながら自分が成長している気がしてないでしょう。あなたの直感は正しい。 何らかのフレームワークを使えば、それなりにできることが増える、それももちろん成長です。ただし、知識のね。プログラミングの力はそれほど変わっていないはず。 自分の経験で言えば、多くの人に読んでもらえないコードは、いくら書いても、実力につながりにくい。人に見せようとするコードは、書いているだけで、いろんなことを考えるし、それが、力

    自分の書きたいコードを書け - 脱職業プログラマのすすめ - ひがやすを技術ブログ
    ghostbass
    ghostbass 2009/02/05
    本当に「成長しないコード」みてるしなあ。構造化すらされてない、何が起こるかわからないメソッド(一個で何でもかんでもやりすぎる)とか、etc…
  • 「ずば抜けているコンプレックス」を克服する方法 - ひがやすを技術ブログ

    404 Blog Not Found:それって勉強じゃないよ http://d.hatena.ne.jp/pollyanna/20081224/p1 なんかかみ合ってなくて残念だけど、弾さんは「天才コンプレックス」、pollyannaさんは「秀才コンプレックス」を持っているんじゃないかと思う。嫉妬の意味でのコンプレックスではなくて、「できる人」の悩みのほう。他人と自分のギャップに戸惑っている。 弾さんの「天才コンプレックス」については、この辺を見ると良くわかる。 私にとって、天才とは天災以外の何者でもなかった。かといって、「能ある鷹は爪を隠す」(これまた耳に胼胝が出来るほど言われた)というほど器用にもなれなかった。 pollyannaさんの「秀才コンプレックス」はこの辺。 それ以来、私には「頭のいい子」という称号がついて回った。 賞賛の意味でそう呼ばれることが多かったが、「変わってる」「す

    「ずば抜けているコンプレックス」を克服する方法 - ひがやすを技術ブログ
    ghostbass
    ghostbass 2008/12/25
    なんか違う気がする/ 大抵「あいつは勉強できる」に続くのは「けど、ほげほげ」っていう否定。それでいてわからない事を聞きにくるでもなし
  • IBMの問題はアメリカナイズされた老害 - ひがやすを blog

    IBM周辺でトラブルが続出している。IBMの下請けとしてサブシステムの開発に携わっていたソフトウェア企業が4億円近い負債を抱え、2008年10月中にも破産手続きに入る。同社は、IBMから追加費用の支払いが行われていなかったと主張して訴訟準備に入っていたという。ほかにも、スルガ銀行やソフト開発会社など、IBMを相手取った訴訟も続発しているのだ。 この訴訟続発を問題のように受け止めている人も多いようだけど、IBM自身にとっては、そんなに問題じゃないと思う。ユーザーの発注が確定しなくてもその先の作業を進めるために下請けに先行発注したりすることがなくなったり、不採算案件は最初からやらない、あるいは早期に手を引くことが、徹底されたからだと思うから。 これまで、日的な空気を読むビジネスから、アメリカ的な白黒はっきりな契約ベースになったということなので、一方的に悪いことではない。 でも、契約を交わ

    IBMの問題はアメリカナイズされた老害 - ひがやすを blog
    ghostbass
    ghostbass 2008/10/06
    クラス設計も満足に出来ずにプログラマに丸投げする若いSEが跋扈する世界で老害とか嘆いても仕方が無いよ
  • Webアプリで使用されているフレームワークランキング - ひがやすを技術ブログ

    2008年5月に行なわれた大手調査会社の結果が興味深いものでした。従業員50人以上の企業をランダムに6000社選び、アンケートをとったそうです。日の結果で、数値は%。言語は、Javaだけではなく、すべての言語が対象です。 EJB3.0(11) 独自フレームワーク(10.6) Struts(10.2) JSF(3.2) TopLink(2.4) Hibernate(1.1) Seasar類(0.9) iBATIS(0.4) Spring(0.4) Torque(0.4) その他(6.7) 利用なし(59.8) Seasar類か、微妙な表現だ(笑)、数値は意外と高いですね。EJB3やJSFが高いのが意外。Strutsが意外と低い。TopLinkがHibernateより高いのも意外。.NET系は利用無しに含まれているんでしょうね。 Seasarがトップ10に入っているなんて、とても光栄です。今

    Webアプリで使用されているフレームワークランキング - ひがやすを技術ブログ
    ghostbass
    ghostbass 2008/08/06
    asp.netは論外なのかフレームワークじゃないのか
  • SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ

    10年間泥のように働いて花が咲きましたのぶくまのコメントにこういうのがありました。 経営層がプログラムの品質を度が越えたほどに軽視する理由の 一つが説明されてます。目から鱗です。意外とみんな知らないようなので、「SI業界の経営層の考えが古い理由」をきちんと説明したいと思います。 汎用機あるいはオフコンの時代は、COBOLRPGなど(他にもありますが私が経験したものをあげています)の言語が使われていました。 昔の言語は、誰が書いても同じようなコードになると思われていました。もっというと、コピペしてちょっと書き換えるという開発スタイルが多かったのです。もちろん現場によって開発スタイルは違うと思いますが、コピペが横行してたんじゃないかなぁ。 コピペでの開発なら、そりゃ誰が書いても同じようなコードになるよね。 再利用性、保守性より「最初にとりあえず動かすこと」が重要視された。コピペでちょろっと変

    SI業界の老害が若手と下請けを蝕む理由 - ひがやすを技術ブログ
    ghostbass
    ghostbass 2008/06/03
    あとで読む/クラスデザインまともにできないSEはいらない/てか、どう実装するのか概念すら理解してないやつらが設計?アホか/「前は動いた」とか。たまたまやろが
  • 「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ

    昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、それを実現するために、ドキュメントをいっぱい書かなくてはいけないという話。大手SIerは、大体同じことを考えていると思います。 でも、「誰が書いても同じコード」にするってのは、そもそも無理だと思うんだよね。そうやって、わざわざドキュメントをたくさん書かせても、めためたなコードを書くやつはいて、総合テストするときに、現場は燃え上がるもの。ある程度の規模以上のプロジェクトなら、どこでもそんな感じじゃないかと思います。 重要なのは、「誰でもメンテナンスできるコード」にすること。そのために、コーディング規約は、きちんと決めてみんなで守る、それ以上は、がちがちに縛る必要はない。 がちがちに縛るために、設定ファイルをたくさん書かせたり、必要以上のドキュメントを書かせるのは、一定の品質を確保

    「誰が書いても同じコード」は大事なことなのか - ひがやすを技術ブログ
    ghostbass
    ghostbass 2008/03/25
    一番困るのは「変なコードの癖にまともに動いている」ようなコード。「動けばいい」なんて許されるのは映画のなかだけです。
  • 1