人はFat Modelを恐れサービスを求め ドメインモデルは貧血に至る - @ledsun blog
この文章は祈りです。 主にRuby on Railsアプリケーションを想定した話です。 Ruby on Railsアプリケーションでは、Fat Model問題という問題が起きることがあります。 ドメインオブジェクトが肥大化しメンテナンスしにくくなる問題です。 Fat Model問題に対応するためにサービスレイヤーを導入することがあります。 「ドメインモデル貧血症」と呼ばれているアンチパターンです。 ドメインモデル貧血症 ドメインのロジックをドメインオブジェクトの中に入れないという設計ルールに従っているのでしょう。その代わり、すべてのドメインロジックを含むサービスオブジェクト群が存在しているのです。 Fat Modelを恐れよ Fat Modelは「単一責任原則」を満たしていないモデルです。 単一責任原則 | プログラマが知るべき97のこと 1つのサブシステムやモジュール、クラス、関数などに
1on1ミーティングのやり方 - @ledsun blog
1on1ミーティングに備えるアンケート - しるろぐ を読みました。 大変参考になりました。お礼の代わりに、弊社のやり方を書きます。 前提条件 弊社は20人以下のSIerです。 受託開発や技術支援がメインです、プロダクトを中心とした面談ではありません。 インタビュワーとインタビュイーの組み合わせはプロジェクトに閉じていません。 総当たりで組み合わせています。 面談をはじめたのは退職者対策としてでした*1。 インタビュワーの負担が個人に偏らないように、ベテランエンジニアが全員インタビュワーになります。 やり方 人数 インタビュワーは6人います。ベテランエンジニア5人と営業1人です。 インタビュイーは8人います。 1年目は毎月、それ以外のエンジニアは2ヶ月に一回実施指定います。 組み合わせ もっとも長い期間面談をしていない組み合わせで実施します。 組み合わせは、モンテカルロ法で抽出します。 そ
日本でアジャイルが流行らない理由 - @ledsun blog
ポジション的なもの 個人的に、アジャイルは「（あんまり未来や遠くのことを考えるのをやめて）目の前にある問題を解決しよう」という思想と認識しています。 現実の問題を見ないで「将来、日本と米国のソフトウェア開発技術の差が広がるから、ウォーターフォールをやめてアジャイルをやろう」とか、何を言っているんだ、おまえは？ と、思います。 キーワード「エンタープライズ」が出てきているので、業務システムの話をします。 情けないぞアジャイルコーチ 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログを読みました。 感想を書きます。 サム・グッケンハイマーの一言 サム・グッケンハイマーは、マイクロソフトが、アジャイル、そして DevOps 移行したことに関するソートリーダー の方が 「ウォータフォールは一切メリットがないので止めておきなさい」 といったそうです。まあ、ポジシ
永和さんの「価値創造契約」に思うこと - @ledsun blog
刺激を受けました。 個人的な思いを書きます 後出しじゃんけんです。 寝言です。 価値観 「初期費用が無料だから私たちは本気です」という価値観はあまり好きではありません。 「斉藤浩司＠帯をギュっとね」メソッドや「苦しければ報われる欺瞞」に近いものを感じます。 お客にリスクを負ってもらって、それに報いる方がより本気のように感じます。 商売として お金は商売の血液 1000万円の資金を全額、保証金としてロックするのは商売として考えると微妙です。 商売お金をお客様とそのお客様と自分たちと協力会社と・・・の間を血液のように流す活動のことです。 バッファとして30%ほどをプールするのは良いですが、100%プールするのはいけません。 脾臓に血液を貯めても全身に巡らなければ死んでしまいます。 *1 気が長い 2,3年続かないとペイしない契約で、 成り立つのはファンドや保険などの数百〜万契約を束ねられる商売
Ruby on Rails を勉強しない方が良い100の理由 - @ledsun blog
はじめに 今すぐ辞めて欲しい、「Ruby on Rails勉強してます」「CakePHP勉強してます」 | つい全力ツッコミしてしまうエンジニアCEOのブログ | sumyappを読みました。最初ツッコミどころが凄い*1なと思ったんですが、二回読んでちょっと思い当たる節があるなと思ったので書きます。 Rails を勉強しない方が良い理由 Railsにはscaffoldがあるので間口がすごく広いです。実際それを紹介した 15m intro video*2 が理由で人気を博しました。が、奥行きが深い。どこまで学べば「Railsを使いこなせます」って言えるのかまるでわかりません。 鉄板作法が共有されていない 2005年に出てきた割に意外に鉄板作法が共有されていません。 たとえばビジネスロジックをどこに置くのかについては以下のような議論があります やはりお前らのMVCは間違っている Rails の
SIビジネスの流れ - @ledsun blog
システムインテグレータ（SI）のビジネスは大きく以下のような流れで進みます。 集客 営業 要件定義 製造 検収・請求 フォローアップ 集客 どんなビジネスでも同じですが、まずは見込み客を集めます。システム開発に興味を持ったお客様を探しアポイントを取ります。よく使われる手法に商品・サービスの説明をするテレアポ、割引を謳ったDM、自社の推す技術のセミナー、役員が個人的に懇意にしている既存顧客の紹介があります。会社の規模やブランドにマッチした手法を選ぶ必要がありますが、会社が成長にするにつれ手法を変えていかなければいけないのが難しいところです。 営業 アポイントの取れたお客様に顧客に直接、自社の提供するサービス、商品の説明を行います。また会社の紹介も同時に行います。お客様がある程度の金額を掛けてソフトウェア開発を行いたいと意思表示をされた場合に次の段階に入ります。そこで現状の課題を聞き出します。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
