タグ

ブックマーク / ledsun.hatenablog.com (6)

  • 人はFat Modelを恐れサービスを求め ドメインモデルは貧血に至る - @ledsun blog

    この文章は祈りです。 主にRuby on Railsアプリケーションを想定した話です。 Ruby on Railsアプリケーションでは、Fat Model問題という問題が起きることがあります。 ドメインオブジェクトが肥大化しメンテナンスしにくくなる問題です。 Fat Model問題に対応するためにサービスレイヤーを導入することがあります。 「ドメインモデル貧血症」と呼ばれているアンチパターンです。 ドメインモデル貧血症 ドメインのロジックをドメインオブジェクトの中に入れないという設計ルールに従っているのでしょう。その代わり、すべてのドメインロジックを含むサービスオブジェクト群が存在しているのです。 Fat Modelを恐れよ Fat Modelは「単一責任原則」を満たしていないモデルです。 単一責任原則 | プログラマが知るべき97のこと 1つのサブシステムやモジュール、クラス、関数などに

    人はFat Modelを恐れサービスを求め ドメインモデルは貧血に至る - @ledsun blog
    fumikony
    fumikony 2022/04/08
  • 実行するたびに決まった順番で値を返すRubyスクリプトはなぜか自分を書き換える - @ledsun blog

    Webアプリケーションのテストに使う端末を決定するために、最初はruby -e 'p %w(iPad Firefox Android).sample'とランダムで値を返していました。 使っていると、ランダムよりは順番がよいと感じました。 また、順番も前回使った端末を覚えていて、その次から実行できると嬉しいです。 そして作ったのが、このスクリプトです。 script = File.read(__FILE__).split("__END__\n").first value = DATA.gets puts value File.open(__FILE__, 'w') do _1.write script _1.write "__END__\n" _1.write DATA.read _1.write value end __END__ iPad Firefox Android 実行すると次のよ

    実行するたびに決まった順番で値を返すRubyスクリプトはなぜか自分を書き換える - @ledsun blog
    fumikony
    fumikony 2021/08/20
    おもしろい
  • 優秀なプログラマになるために - @ledsun blog

    みんな良いこと言うので、刺激を受けて考えたことを記録します。 生きてるだけで丸儲け ストレス対処法 撤退戦術 タスク殺すマシーン 人間に戻る儀式 運 技術力を身につける方法 車輪を再発明する 脱ゴールデンハンマー病 学習の助 優秀なプログラマとは? おまけ 生きてるだけで丸儲け 優秀なプログラマーになるためのコツ · GitHub 優秀なプログラマーに「育つ」んだし、それには時間が必要 優秀なプログラマーになるということは、上記の通り長時間を要するということも踏まえると、メンタルヘルスにリスクがある環境に長時間暴露されることが不可避である 業界で長きにわたり活躍し続けている人というのは、それだけですでにひとかどの人物 すごく良いです。 優秀なプログラマになる前に、死んでしまっては元も子もありません。 生き延びることはなにより大切です。 幸か不幸か現状のIT業界はハードなストレスにさらされや

    優秀なプログラマになるために - @ledsun blog
  • 日本でアジャイルが流行らない理由 - @ledsun blog

    ポジション的なもの 個人的に、アジャイルは「(あんまり未来や遠くのことを考えるのをやめて)目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは? と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ

    日本でアジャイルが流行らない理由 - @ledsun blog
  • 中間業者を中抜きすると受発注者はWin-Winになるか? 事例:クラウドワークス - @ledsun blog

    結論 事例:クラウドワークス クラウドワークスは発注者のためのサイト 中間業者中抜きへの期待 先人の失敗 絵や音楽 伝統工芸 価格維持力が失われる 中間業者が必要な構造 クラウドワークスの価格低下構造 受注者は増える 価格下げ圧が強すぎると市場は縮小 中間業者の機能1 参入障壁(受注者のフィルタリング) 中間業者の機能2 案件のバッファリング クラウドワークスさまへのご提案 参考リンク 結論 中間業者を中抜きは不可能。よりよい中間業者による代替えを目指そう 事例:クラウドワークス crapp.hatenablog.com にて、受注者側から見たクラウドワークスの問題点が挙げられています。 クラウドワークスは発注者のためのサイト クラウドワークスとは、そもそもエンジニアの為に作られたサイトじゃなく、むしろクライアント(発注者)がエンジニアを安く買い叩くためのサービスに過ぎなかった また 発注

    中間業者を中抜きすると受発注者はWin-Winになるか? 事例:クラウドワークス - @ledsun blog
  • #TestingFrameworkMeeting に参加しました(1) - テスティングフレームワークの歴史 - @ledsun blog

    参加した時のメモです。 t-wadaさん Testing Framwork Meeting テスティングフレームワークの歴史 http://www.slideshare.net/everzet/bdd-in-symfony2/42 のスライドがベース。 有史以前 make checkのように、テストを自動化する風習はあった。 開発者はそれぞれ秘伝の手法でテストコードを書いていた。 JUnit Kent BeckがJUnitを書いた。 1994 SUnit 1997 JUnit プロダクトコード書いてから、テストコードを書くまでの時間が短いほうが、 プロダクトコードに対する気づきが得られ、それをプロダクトコードに反映できることがわかった。 テストコードをさらに早く、プロダクトコードより早く書いた。 テストファーストが生まれ、ユーザーの視点でプロダクトコードを設計できるようになった。 自動テス

    #TestingFrameworkMeeting に参加しました(1) - テスティングフレームワークの歴史 - @ledsun blog
  • 1