portal shit!

YAPC に行ってきた。ちなみに去年は嫁さんに↓のように言われて行けなかった。

俺「東京であるプログラミングのイベント（YAPC）に行っても良いでしょうか？」 妻「あんたには中身がない。社長になりたい、起業したい、金持ちになりたいと言ってる高校生と同じでスカスカ。何をやるかがはっきりしてない。そんなんでイベントに行っても意味ない」

— 清貧太郎権左右衛門 (@morygonzalez) August 20, 2014

今年は YAPC 最後なのでどうしても行こうと思って無理矢理チケット申し込んで飛行機と宿とって行った。帰ってきて嫁さんに感想を聞かれて、詳細を話しても意味わからないだろうから「がんばろうという気持ちにさせられた」と話したら、「えー、それだけ？ 何も学んできてないわけ？」と言われた。

一日目

一日目の方は業務の一環として参加させてもらった（チケット代とか飛行機代とかは自腹）。 受付で YAPC Tシャツもらえると思って着替えを持ってきてなかったんだけど申込時にサイズ選んでないのでTシャツもらう意思がないと見なされTシャツもらえなかった。明日着る服がないと思って焦ったけどリュックの中に予備のTシャツ（実家に帰ったときに洗濯したやつ）があって助かった。

Effective ES6

ES6 、全般的に天国ぽかった。 Babel というの使えばもういまから ES6 で書けるっぽい。ただ Kaizen のサービスは JavaScript でやらかすと皆様に多大なご迷惑をおかけすることになるのでリストカット感覚で導入すると危なそうだった。まずは自分のブログとかで実験してみたい。

昼

偶然居合わせた kitak （ペパボ時代の元同僚）と Kaizen Platform で同僚の t32k さんと、二人の金沢時代の友人の方たちと無料弁当を食べた。 YAPC 、飲み物とか弁当とかまで出てすごい。電車賃とチケット代さえあれば参加できる。

TBD

最近なんで並行処理に優れた言語とか流行ってるのかという背景を交えながら、なぜ Streem を作ったのかという説明や Ruby の未来の話しが面白かった。あと質疑応答の返しが面白い。 Matz さんは言語開発者として優れていると同時に優れた話し手でもあるなと思った。

たまたま mizzy さんと隣に座って聞いてたんだけど、 mizchi さんいて（mizchi さんが mizzy さんに話しかけた）こんちゃと挨拶した。 YAPC 有名人ごろごろいるのすごい。

Perlの上にも三年 〜 ずっとイケてるサービスを作り続ける技術 〜

爆笑トークだったけど、オブジェクト指向や DDD がなぜ大切なのか、というのを業務での経験を交えながら発表されていてよかった。「オブジェクト指向設計入門とか DDD 本とか難しいけどどうやって業務に活かすのか」という質問に対しては、「歯を食いしばって実装するしかない」と返していてよかった。

ロビーでだらだら

見たかった発表満席で入れなかったのでロビーうろついてたら hsbt さんいたので声かけた。そしたらどこからともなくペパボ、元ペパボの人どんどん集まってきて hsbt さんの自撮り棒の被写体になったりしてた。出戻り歓迎しますと言われてニヤニヤしたりしてた。ペパボ版 mizchi さんの gyugyu さんを生で見られたの良かった。

SaaSを組み合わせて作る, ぼくらの障害対応術!

障害発生時に自動的に Qiita:Team に対応報告ドキュメントが作成され、 Reactio というサービス内にチャットルームも自動生成され、チームメンバー全員に電話もかかってきて障害対応に SaaS を組み込んで効率的に仕事をこなす、という LT だった。 LT 中、アラートメールが来るという演出も面白かった（たぶん仕込みだと思う）。

Kaizen Platform への就職を決めたの、要因はいろいろあるんだけど、入社前に CEO の須藤さんが Qiita:Team に書いている Kaizen のモットーみたいなやつを読ませてもらって、それに感銘を受けた、というのがある。自分たちが本当にフォーカスすべきことに注力して、その他のことは外部サービスを利用して徹底的に効率化したい、というようなことだった。実際、 Kaizen は外部の SaaS を利用できる部分は極力利用して自前で実装しないようにしている。それでお金はかかるけど、エンジニアが無駄に秘蔵の社内ツールのメンテナンスで疲弊することがないようになってるし、スタートアップ同士でお互いのサービス使い合って良い循環が生まれている感じする。

ソロ懇親会

一日目は懇親会あって参加してみたかったけど気がついたら募集終了してて参加できなかった。なのでよく知りもしない東京ビッグサイトのプロントの店員に「お疲れ様です」と声をかけられながらビール飲んでスパゲティー食べてソロ懇親会やった。バスでホテルに帰ろうとしたらペパボの元同僚の人いて最近どうですかとか軽く話した。ホテルに着いてからは浜松町の激安寿司屋に潜入したけどシャリがねちゃっとしてて不気味な感じだった。量も多くて腹一杯になってしまってとにかくつらかった。

二日目

だいぶ早めに着いたので余裕をもって座れた。ただ午後のコマは混みすぎてて発表見られないことが何度かあった。次の発表の時間前に部屋の前に列を作ったりするの予備校に通ってた浪人生時代を思い出した。人気講師の講義に群がる代ゼミ生に戻った気分になった。

Adventures in Refactoring

GitHub の人の話、 RubyKaigi の動画とか福岡でのミートアップとかでも聞いたことあったんだけどいまいち何言ってるかわからなんぁという話しする人多かった。今回の人の話はわかりやすかった。リファクタリングしてコード量が増えるのようなのはダメだとか、パフォーマンス劣化させたらダメだとか。あと GitHub では scientist という gem あってこれでリファクタリングの前後のコードの A/B テストみたいなのをやってるそうだった。エラー発生率とかパフォーマンスを計測しているそう。すごい。

昼

昼セッションの弁当売り切れててもらえなかったので下に降りてコンビニで何か買おうかと思ったけどコンビニが異常に混雑してて地方在住者にはあれに並ぶ気になれなくて、一旦はフードコートとか行こうとしたけど結局どこも激混みで、あきらめてセブンイレブンでサンドイッチとか買ってプロントで買ったビール飲みながらオープン席的な場所で食べた。偶然、隣にモテメンガールズを引き連れたモテメンさんがやってきてモテメンステッカーくれた。家の冷蔵庫に貼ろうと思います。

【特別企画】YAPCあるある（仮）

YAPC の 10 年間を振り返るという座談会企画だった。僕はミーハーなのでこういう話しを聞くのは好きなので面白かった。そもそも始まりは宮川さんが台湾で行われた Perl のカンファレンスで来年は日本でやってくれよと声かけられてスライドの最後に急遽やりますというのを盛り込んで宣言したのが始まりのようだった。最初の会場が大田区産業会館というの地味な感じがあってよい。2007年だか2008年だかの YAPC で利用したフランスの決済システムがちゃんと動かなくて宮川さんがフランスまで行って直した、という話すごかった。伝説っぽい。

あとは牧さんがどれだけこれまで YAPC で苦労したか、という話だった。こういうの若い人聞いてもあまりぴんとこないかもしれないけど、所帯を持ってたりするとなかなか家庭外の活動に時間を割くのは大変だし、結婚式挙げたことある人はわかると思うけど、人を何百人と集めてなにがしかの催し物をやるのはとんでもなく骨の折れる大変な作業で、それをボランティアで行うのは本当に大変だと思う。若い人はもっと牧さんに感謝した方がよい。

Evaluating your stylesheets

同僚の t32k さんが LT 通ってて発表した。伊藤直也さんのこといじって受けてた。作ったスタイル何とかという CSS を解析するソフトウェア自体も良さそうだった。

コミュ力あげてこ

一日目は hitode909 さんの発表の裏で話を聞けなかった cho45 さんの LT 面白かった。前の人がたまたま電話の話してて、その後に登場した cho45 さんがモールス信号の話というのが最高だった。 cho45 さん、ツイッター見てる限り気むずかしい人なのかなと思ってけどおもしろお兄さんという感じで良かった。

クロージング

ヒトデさんがベストトーク賞とってた。なぜか自分のことのようにうれしかった。

牧さんのこれまでの苦労話とかを最後にもう一回聞いたけど本当に大変だったと思う。2000人以上来場するイベントを取り仕切るのは筆舌に尽くしがたいほど大変なはず。牧さん、 udzura uzulla さん、運営の皆様本当にお疲れ様でした。

会社を辞めた。3年半在籍してた。

ペパボに入る前は凄いブラック企業で働いてて、 Subversion やめて Git 使いたいと言ったら会社辞めろと言われたりしてた。そんなときに蜘蛛の糸のように目の前に垂らされたのが Dazaifu プロジェクトの求人で、藁にもすがる思いで応募し入社したのだった。この辺は過去のエントリに適当に書いてあるので読みたい人は読んで下さい。

前働いていた会社の思い出と近況

いまの会社は労働環境よいんだけど、前働いていた会社がとてもつらかった。どのくらいつらかったかというと、もう辞めてしばらく経つのに、いまだに前の会社にいたころの夢を見てうなされて夜中に目が覚めるく...

portalshit.net

ペパボは働きやすくて、毎日18時になったらみんなさっと帰るし、21時過ぎに会社出ると最終退出者であることもしばしばだった。家庭の事情にも理解があって、育児休業をさせてもらったり、ばあちゃんの具合が悪いときには会社休ませてもらったり早めに帰ったりしてたし、ばあちゃん死んだときにはお花とかも出してもらった。労働環境の他にも年末の社員旅行とかプレゼン大会とか社内の催し物があったりして良い雰囲気だった。課長が女性エンジニアにセキュリティルームでセクハラしてたり社長が気に食わない奴はいきなりクビにしたりしてたブラック企業から移ってきた身にはほとんど天国だった。

なにより自分にとってよかったのが、インターネットが会社になったみたいなところだった。会社に @shikakun がいて、あとから @antipop さん（ Mr. CTO！）とか @udzura さんとか面白インターネットコンテンツな人も入ってきて、自分が @morygonzalez として存在することが是認される感じがとてもうれしかった。

とはいえペパボでもそれなりに厳しいことはあって、そういうのは一昨年の闇アドベントカレンダーに書いたのでこれも読みたい人は読んどいてください。

死んでしまったサービスの供養

この記事は 闇アドベントカレンダー、 22 日目の記事です。何書こうか迷って担当日に書けなかったので三日ほど遅れてしまったけど書きます。2011 年の 10 月から FANIC という音楽配信サ...

portalshit.net

社内ではおおよそ一年おきに異動していて FANIC => MuuMuuDomain => minne と渡り歩いた。そう、僕はいま CM やったりしてる minne の中の人だったのです。

3年半の間に PHP を書くこともあったけど、自分の指向性とかを汲み取ってもらい、概ね Ruby を書かせてもらった。ウィンドウズを使えと強要されることはなかったし、 Ruby は書きたい放題だし、毎日会社行くのが楽しかった。

最後にいた minne は本当に良いチームで、みんなでリーンキャンバス描いたりエレベーターピッチを考えたりして、どうやったらサービスが圧倒的に成長できるのかを真剣に考えてた。

エンジニアはみんなできる人たちで、特に初期から minne を支えていた @mizoR さんが凄く、ちゃんとコンピューターサイエンスのバックグラウンドがあるため文系の自分にはない視点で問題にアプローチしていて非常に勉強になったし、また歩く UNIX の哲学みたいな存在で、小さく作ってこまめにリリースし検証することの大切さを教えてもらった。（@mizoR さん作の rake_notification は神 gem なのでオススメです）

GitHub - mizoR/rake_notification: Notification of status for rake

Notification of status for rake. Contribute to mizoR/rake_notification development by creating an account on GitHub.

github.com

新卒入社の @keokent もできる奴で、モバイル端末へのプッシュ通知をサクッと作るしサービス愛も厚いし、風紀の乱れにもうるさくて、Tシャツの裾は常にズボンにインするように指摘されてた。

去年の4月に入社してきた @amacou さんも凄くて、 Ruby/Rails も Objective-C も両方書けて、出張申請とか経費精算さえできればフルスタックおじさんという感じだった。

ムームードメイン時代に仲良くなりプラチナサーチャーで女性ファン急増中の @モノクロメガネ（いけすかないのでリンクはありません） さんに助っ人で来てもらうこともあって、絶対間に合わないだろみたいな無理めなスケジュールでタスクが降ってきたときにもみんなでホワイトボード囲んでワイワイ開発して余裕で終わらせたりして最高だった。モノクロさんは隙あらば Go で Ruby のコードを置き換えようとするところ以外はエンタープライズ力も高いしスクラムマスター業もこなすナイスガイだった。本当にいけすかない。

何をやらせてもスピーディーにこなす若手ネット芸人 @hisaichi5518 さんとも物理的に距離がある状態で仕事したけど、とにかく作り上げるという力はさすがだと思った。チーフエンジニアの @hsbt さんのオラオラと詰めてくる感じの Pull Request もサイコーだった。チームのエンジニアの間では「 @hsbt さんが通ったあとには草の根一本生えない」とよく言ったものだけど、こういう人がいないとフレームワークや言語のバージョンアップとかインフラ構成の大胆な変革はできないことがよくわかった。そういえば @udzura さんという人とも働いたけど、ギャグが寒いこと以外は問題ないです。

デザイナーやディレクター、サポートメンバーも良い人ばかりで、昨日は送別会を開いてもらったんだけど、こんなに良いチームを去るのは残念で仕方なかった。写真はトデガールズに対抗して森井ガールズが結集している様子です。

福岡でウェブサービスの開発やってみたいけどどこで働けばよいかわからないインターネットをこじらせたウェブプログラマーの人はペパボの門をたたいてみるとよいと思います。

で、誰？

無名のウェブプログラマーです、このような記事を書いてお目汚しをし誠に申し訳ございません。

なんで辞めんの？

「次に行く理由」があるだけで、「辞める理由」はないのです。

株式会社ドワンゴに転職します（4年3か月ぶり2度目） - Kwappa談話室

僕も同じ気持ちです。

次なにやんの？

Kaizen Platform という会社で働きます。無事試用期間を乗り切れるのでしょうか。ご期待下さい。

Ruby で動くソフトウェアは常に何でも最新を追っかけるのが吉な気がする。好きで使ってる earthquake.gem が最近新規インストール時に動かなくなった。バージョンを固定してないジェム（ eventmachine など）のバージョンが上がって死ぬようになったっぽい。そのジェム自身には変更がなくても、 Ruby のエコシステムはどんどん新しくなっている。止まっているのはそれだけでバグ生んでるのと一緒だと思う。なのでジェムを使ったり作ったりしたら、なるべく最新の環境で動くように気を配らないといけないし、いつも使ってるジェムに動かないところ見つけたらなるべく Pull Request 送っていかないといけないなぁと思った。そのことが最終的に自分のためにもなる。 earthquake.gem が動くようになる Pull Request 送ろう。

人生も一緒かなぁ。止まっているだけだとバグ生んでるのと同じなのかも知んない。世の中は常に動いている。

関わっているサイトの Rails のバージョンが 3.2.20 から 4.1.8 に上がった。自分は割と傍観していて他の人が主にバージョンアップしてたんだけど、いくつかはまりポイントがあって自分も Pull Request 送ったりしたのでやったことを書いときます。

1. session に注意

Rails 4 から Flash メッセージ（ログインしましたとか）を格納する session のオブジェクトが普通の Hash になってる。 Rails 3 ではこれは FlashHash とかいうやつ。

Rails 3 から Rails 4 へのアップグレードで一旦 Rails 4 を出してやっぱりやめて Rails 3 に戻したりとか、ロードバランサーに Rails 3 と Rails 4 で動くサーバーを混ぜてリクエスト捌いたりするとまずいことになる。

Rails 4 のサーバーで session 出来た人が次にリクエストしたときに Rails 3 に当たるとログイン後とかに session に残っているメッセージを消そうとする処理とかで NoMethodError が発生して落ちてしまう。しかもたちが悪いことに Rack 層で死んでしまったりするから皆さんよく使ってると思われる ExceptionNotification とかで気づくことが出来ない。これはつらい。

対処法としては Hash クラスをオープンしてモンキーパッチするというのがある。こういうの。

Rails 4 FlashHash Upgrade Gotcha

We upgraded an application from Rails 3 to Rails 4 this week and came across an interesting gotcha which I haven’t seen documented anywhere. As we rolled out the Rails 4 version of the app we split…

jasonneylon.wordpress.com

↑のだと #alert とか #notice が呼ばれたときにエラーになるので自分は以下のようにした。

# NOTE Rails 4 と Rails 3 を混ぜて使うと Hash#sweep が見つからなくてエラーに
# なるようなのでモンキーパッチします。
# 参照: http://jasonneylon.wordpress.com/2014/08/27/rails-4-flashhash-upgrade-gotcha/

class Hash
  def now
    Rails.logger.warn "Stubbing now during upgrade"
    {}
  end

  def keep
    # stub keep for upgrade purposes
    Rails.logger.warn "Stubbing keep during upgrade"
  end

  def sweep
    # stub sweep for upgrade purposes
    Rails.logger.warn "Stubbing sweep during upgrade"
  end

  def alert
    Rails.logger.warn "Stubbing alert during upgrade"
    self[:alert]
  end

  def notice
    Rails.logger.warn "Stubbing notice during upgrade"
    self[:notice]
  end
end

ただこれもパーフェクトではなくて、何もしないように上書きしているだけなのでログイン後のメッセージとか削除後のメッセージが消せなくなったりする。それでも 500 エラーになるよりかはましなのでどうしても Rails 3 と Rails 4 を混ぜて投入したいみたいときなんかは有効。

2. 絵文字に注意

Rails 3 の頃は ActiveRecord が絵文字を DB に保存することが基本的になかった。ユーザーが POST してきたフォームの中に絵文字が含まれてたら絵文字のところでテキストをぶった切って DB に保存するような挙動だった。しかし Rails 4 からは ActiveRecord は絵文字を素通りさせるようになってしまったので困ったことになる。

絵文字を DB に保存するためには、 MySQL の場合は DB のテキストエンコーディングを utf8mb4 というやつにしてないといけない。ただの utf8 だと保存時に Mysql2::Error: Incorrect string value というエラーが出て DB に保存できない。emojimmy のような gem を使えば utf8mb4 でない DB でも使えるけど、 stores_emoji_characters :column_name を忘れずにモデルに定義しないといけない。たとえば購入時に購入した製品のスナップショットを注文テーブルに取るような DB 設計だと、製品テーブルのカラムは stores_emoji_characters してたとしても注文テーブルのカラムを stores_emoji_characters し忘れていて死亡、というような悲劇が起こり得る。

いまはスマートフォンの時代で、ユーザーが入力してくるフィールドには必ず絵文字が含まれると思っておいた方がいい。スマートフォンをメインで使ってる人たちは開発者が想定しないようなフィールド（名前の敬称とか）に平気で絵文字を使ってくる。下手すりゃ住所や名前にも絵文字を入れて送ってくるかも知れない。アスキー文字しか受け付けないようなフィールドは JavaScript やサーバーサイドでバリデーション行ってると思うけど、マルチバイト文字列を受け付けるフィールドの場合はせいぜい長さくらいしかチェックしてないと思う。チェックを入れて絵文字を弾くことも可能だけど、スマートフォンの時代の流れに反しているしユーザーを失うことになりそう。これから新規でサービスを作ってデータベースに MySQL を使う場合はエンコーディングは utf8mb4 にしておいた方がいい。

他にも script/rails が bin/rails に変わってること忘れてて rails runner なバッチ処理が動いてなかったとか、 paranoia.gem の Rails 4 対応バージョンで物理削除のときに呼び出すメソッド名が変わっててはまったとかいろいろあったけど大きなところは上の session と絵文字だった。開発環境で使ってるときには気がつかず本番に出すまで気がつきにくいという意味で非常にやっかいな現象だと思う。

これから Rails 4 に上げる皆さんは頑張ってください。応援しています。

会社のアドベントカレンダーが空いてたので書きました。前日は @kenchan さんでした。

大学生の頃に書いてたウェブ日記を Day One.app に取り込んだ。このウェブ日記は Caldiary というソフトウェアを使っていて、KENT Web で配布されてた CGI をベースにデザインが良くなるように改良されてるやつだった。RSS とかはなく、まだブログがはやる前に作られたものだった。昔ながらの Perl の CGI でデータベースは使っておらず、日記自体はテキストファイルに保存されていた。なので簡単にデータをぶっこ抜けた。テキストエンコーディングが Shift_JIS なのに気をつけつつ UTF-8 に変換して Day One の中にぶっ込んでいった。 Day One が公式で用意してる CLI を Ruby から使いやすくする rb-dayone という gem を使ってやった。

10年前の日記を読み返すといろいろおもしろい。アルバイト先のいやなやつの悪口とかもあるんだけど、人から聞いたおもしろい話を備忘録代わりに書いてて記憶がよみがえったりする。読んでいる本の感想とかもある。黒歴史感あってよい。

Caldiary がすばらしいのはカレンダー形式のサイドメニューがあったことだ（おそらくカレンダー付きの日記だから Caldiry なのだろう）。カレンダー式だと一日もサボれない気がしてほぼ毎日日記を書いてた。 Evernote などパソコン上に日記を書けるソフトはいまいっぱいあるけど、カレンダーが出るのは（自分の狭い観測範囲では） Day One しかない。また Day One は見た目が美しく、過去に書いた文書を読むのに適したインターフェースだと思う。もっと活用していきたい。

むかし日記書いてた人は Day One に取り込んでみるとおもしろいのでオススメです。

この記事はPepabo Advent Calendar 2014 - Qiitaの3日目の記事でした。

明日は未定です。

Go 言語でなにかやってみようと思っていたところ、先々週末くらいにアンチポップさんが gyo という、 Go 言語で Yo するやつを作ってたので、 gyo とそのサンプルコードを利用して gyowitter というのを作った。 Yo の MORYGONZALEZ が Yo を受け取ったら Yo を返しつつ Twitter に「また @wyinoue さんから Yo がありました。この人仕事してるんですかね？」とか Post するやつ。一部の異常者から10連続で Yo とか来て軽くうざいと思うことがあったので、 Twitter のこの人こんなに Yo してきて異常者ですよ、というのを知らしめたくて作った。

Go 言語、初めて書いてみたけど簡単なことしかしてないので大した感想述べられるほどは分からない。 JSON で設定ファイル書いてその内容を読み込む対応を昨日今日くらいでやってたんだけど、静的型付けなためか、読もうとする JSON がどういう構造になってるかを分かってないといけなくて、 Ruby とかだととりあえず parse したあと Hash にして好きに扱える感じだけど、読み込む前にどの階層のなんという key のバリューが map になってるとか配列になってるとか分かってないといけないのが窮屈に感じた。

コンパイルしたらバイナリが一つ出来てそれを置けばデプロイ完了（環境構築とかいらない）のは大変便利だと思った。 Mac で書いて Linux 用にクロスコンパイルして scp してデプロイ完了（Linux 側には Go インストールする必要ない）というのはスクリプト言語にはない感じなので新鮮だった。

ただビルドしたバイナリのサイズが結構でかくて、 gyowitter は大したことしてないけど 6MB くらいあって、細い回線でアップロードしようとすると結構つらい。

percol 流行ったときに会社で使ってる 3 年前の MacBook Pro （HDD のやつ）に入れて使ってみたらあまりにもレスポンス悪くて使うの諦めてたんだけど、 Go 言語版の peco を使い始めたら普通に使えて快適だったので、 Go 言語には夢がひろがりんぐな印象を持ってる。新しい言語勉強するの新鮮で頭が若返りするような感覚あるので引き続き勉強してみようと思います。

CleanRuby を途中まで読んだ。一年半前に DCI 流行って、その後会社（東京の方）でも流行ってたので、「乗るしかない、このビッグウェーブに」と思って買うだけ買って積ん読してた。正月くらいから本気出して読み始めた。まだ全部読み終わってないんだけど、 Day One にメモ走り書きしてあって良い話っぽいのが書いてあったのでメモする。

2014/01/23

Clean Ruby 読んでる。まだ最初の方だけど何となく DCI についてつかめてきた。 DCI 、つまるところ RSpec みたいな BDD の考え方を製品コードにも持ってきたものだと思う。「テストコードだけ実際にプログラムが利用されるときの文脈（ context ）とか反映してるのもったいなくね？ これプロダクトコードにも反映させるべきでは？」みたいなノリだと思う。

2014/01/26

Clean Ruby、3章くらいまで来た。 DCI の考え方だいたい分かった。Methodless Roles とはつまり良い名前を付けるところ、というところにぐっと来た。Clean Code からの引用で、「良い命名をすることがコードを良くしないことはない」というのが良かった。

モデルにいろいろ書くな、という話も良かった。 Being と Doing を分けるというやつ。モデルは変更しない情報（データ）だけを保存する場所にして、データを変更したりする処理は別の場所に書くという考え方。

サインアップについて。ユーザーがサインアップするとき、ユーザー自身がサインアップすることもあれば管理者がユーザーの代わりにサインアップすることもある。同じ種類のデータを作ろうとしてるんだけど、システムの挙動は異なる。管理者がユーザーの代わりにサインアップするときには、管理者にメールで通知する必要はない、など。モデルにデータの変更処理まで書くと、別の文脈からデータ操作しようとするときに苦しい感じになる。

頑張って最後まで読みたい。