portal shit!

※絵といっても絵画のことではないてす。 UML とかのことです。

夜中まで訳の分からない仕様書・設計書を書かせられてたブラック企業時代の体験が辛すぎて UML 的なやつを見ると嫌な思い出がフラッシュバックしてたけど、最近は絵を描くのが好きになってきて、結構いいものだと思うようになってきた。

当時はアホにみたいにドキュメント書かせられてた。フローチャート、ユースケース図、シーケンス図、 ER 図、画面詳細設計書などなど。もちろん方眼の Excel で（ Visio は下っ端には使わせてもらえなかった）。オープンソースのショッピングカート（ Magento ）のガワだけ変えて EC サイト構築する場合でもユースケース図描けとか言われて、 OSS のコードの処理の流れを図化するとかギャグだろと思ってた。要するに単なる工数稼ぎで客から金を詐取するための汚いやり口だったのだ。

そもそも実際に絵に描いた通りにシステムを作れることなんてなかった。複数社で引き継がれてきたコ〜ルドフュ〜ジョンのコピペコードの塊の前では UML とか描いても意味なかったし、自分たちのコーディングスキルも低かった。今でも事前に絵に描いた通りにシステムを作るのは難しいと思う。

しかし自社で製品を作ってる会社で働くようになって、自分たちのために描くシーケンス図やらフローチャートはとても役に立つなと思うようになった。実装前にドキュメント作るよりも、実装してて詰まったときや最初にガーっと作ったやつをリファクタリングしてるとき、開発終盤のコードが安定してきたときに作るととてもよい。

最近気に入ってるのはシーケンス図で、 Microservice 化されたウェブアプリケーションのデータの流れを理解するのにとても役に立つ。社内のドキュメントツールを Kibela にしたおかげで PlantUML が使えるのが快適極まりない。 Markdown なので変更があったときに絵をサクッと編集しやすい。これがドローツールをいちいち起動して編集したあと画像を書き出さないといけないとかだったらなかなか更新する気にならない。

とはいえ PlantUML が苦手なやつもあって、フローチャートはダメダメだった。フローチャート、プログラムの処理の流れが描いてあるだけでは不十分で、見た目の整い具合も重要だと思う。そもそも絵や図は言葉で書かれているものだと理解しづらいものを視覚化して理解しやすくするものなので見た目はとても重要になる。 PlantUML ではなかなか条件分岐や処理の塊の位置が揃わず、綺麗にグリッドに配置される OmniGraffle の方が圧倒的に描きやすかった。 OmniGraffle は値段が高いのが玉に瑕だけどとても良いものだと思う。

頑張って PlantUML でフローチャート描いたけど全然きれいにならなくて、 OmniGraffle で描いたら 5 分くらいできれいなやつ描けてやっぱり絵を描くならネイティブのドローツールに限るなと思った。 pic.twitter.com/i77JeDvDUn

— morygonzalez (@morygonzalez) February 27, 2018

ブラック企業時代は絵を描くことが金儲けのためだから辛かったのだと思う。自分たちが後から困らないようにするために書くドキュメントは全然つらくない。当事者意識を持てるか持てないかの違いなのだと思う。 ATI を高めていけば Excel 方眼シートも辛くないのかも知れない。知らないけど。

Google アシスタントに対応した後継機種（ QC 35 II ）が出たことで BOSE の QC 35 旧型が 1 万円近く安くなっていたのでクリスマス、誕生日、バレンタインデーの合算プレゼントとして嫁さんに買ってもらった。 SONY の MDR-1RBT が壊れてしまったのでその代替。

ノイズキャンセリングは思ったほど効かないと感じるが、音楽を聴くと周囲の音はほとんど聞こえなくなるので自分の HHKB の音が気になって仕事に集中できない、というようなことがなくなり思う存分キーボードをガチャガチャさせながら豪快にプログラミングできて便利。

音やノイズキャンセリング以外で優れていると思ったのがスイッチや充電用の microUSB 端子。 MDR-1RBT や通勤・ジョギング用に使ってる Anker のワイヤレスイヤフォンはスイッチが長押し式で、電源を入れたり切ったりが煩わしかった。 QC 35 はスライド式になっており、オン・オフの切り替えが直感的でわかりやすい。

microUSB のメス端子に樹脂カバーが付いてないのも良い。充電するときにピローンとした蓋を外さないといけないのも小さくはあるがストレスだった。あんなもん付いてても意味ないし、充電必要なときにケーブルをぶっ刺すだけで充電できるのは非常に心地よい。スイッチにしろ端子のカバーの有無にしろ小さなことではあるが、地味にストレスになっていたことから解放されて嬉しい。

高いものなので自分ではなかなか買えないが、買ってもらえてよかった。

ルビーオンレイルザーの皆さん、 Fat モデル対策やってますか。 Fat モデル対策と言えば Concern ですね。 app/models/concerns/ ディレクトリに module を置いてモデルに include させるというアレです。

Put chubby models on a diet with concerns

Different models in your Rails application will often share a set of cross-cutting concerns. In Basecamp, we have almost forty such concerns with names like Trashable, Searchable, Visible, Movable, Taggable. These concerns encapsulate both data access and domain logic about a certain slice of re…

signalvnoise.com

しかしただ module を作って Fat モデルのコードを移動し、元のモデル側に include させるだけでは結局モデルのインスタンスに生えるメソッドの数に変わりはないので臭いものに蓋をしてるだけになります。 Rubocop の Metrics/LineLength 警告を逃れるためだけの module 乱立はあんまり意味がないでしょう。間違って別の module で同名のメソッドを定義してしまい意図しない挙動になってしまうことも考えられます。

最近自分がやってるのは、 include される module に定義するメソッドはせいぜい一つか二つにして、このメソッドから別クラス（ Plain Old Ruby Object）に定義したメソッドを呼び出す（委譲する）というものです。モデルに得体の知れないメソッドが増えないので便利。

例えば以下のようなモデルがあるとします。

• app/models/entry.rb
• app/models/comment.rb

両方ともレコードの新規登録があったときに通知を行いたい。共通の処理なので Notifiable モジュールを作ってそれを Entry モデルと Comment モデルでそれぞれ include しましょう。ここまでは皆さんよくやると思います。

• app/models/concerns/notifiable.rb

module Notifiable
  private

  def notify
    # do something
  end
end

class Entry < ApplicationRecord
  include Notifiable
  has_many :comments
  after_commit :notify, on: :create
end

class Comment < ApplicationRecord
  include Notifiable
  belongs_to :entry
  after_commit :notify, on: :create
end

しかし Entry と Comment では通知内容が異なるので単純に #notify メソッドを callback で実行すればよいというわけではない。通知用パラメーターを生成する処理をモデルに書くとよいのですが、そういうのを繰り返した結果が Fat モデル地獄なので通知内容を生成するクラスを別に作ります。こんな感じ。

• app/models/concerns/notifiable/entry_notification.rb
• app/models/concerns/notifiable/comment_notification.rb

Base クラスを作って共通処理をまとめ、継承させると便利でしょう。

• app/models/concerns/notifications/base_notification.rb

module Notifiable
  class BaseNotification
    def initialize(object)
      @object = object
    end

    def perform
      NotificationJob.perform(notification_params)
    end
  end
end

module Notifiable
  class EntryNotification < BaseNotification
    def notification_params
      {
        recipient_ids: @object.subscriber_ids,
        title: @object.title
      }
    end
  end
end

module Notifiable
  class CommentNotification < BaseNotification
    def notification_params
      {
        recipient_ids: @object.thread_joiner_ids,
        title: @object.body.truncate(25)
      }
    end
  end
end

Notifiable モジュールはこんな感じになります。

module Notifiable
  private

  def notifiy
    notification.perform
  end

  def notification
    "#{self.class}Notification".constantize.new(self)
  end
end

図にするとこんな感じ。

この Notifiable モジュールを include しても Model には #notify メソッドと #notification メソッドしか追加されず、通知処理の実装をモデルから分離することができます。 Entry クラスも Comment クラスも #notify メソッドより先のことは何も気にしなくてよくなる。リソースが追加されたときに #notify メソッドを実行することだけに責任を持てばよいし、通知を飛ばすという処理自体は Notifiable::EntryNotification と Notifiable::CommentNotification クラスの責任になります。

私はこれで Fat モデルのコードを concerns ディレクトリにしまい込んで臭いものに蓋をするような対応におさらばしました。よろしければお試し下さい。またもし他に良い方法をご存じであれば教えて下さい。

去年の年末に大掃除も年賀状もやらずに Rails に Pull Request を出してた。

年末だけど大掃除もせず年賀状も書かず実家にも帰省せず rails/rails に Pull Request 出した。https://t.co/a0xePd51vY

— morygonzalez (@morygonzalez) December 30, 2017

ActionMailer のプレビューで locale が複数ある場合に指定できるようにするというもの。 Kaizen Platform の Rails アプリにはこの機能付いてて多言語対応のメールをプレビューするときにめっちゃ便利だった。調べたところ Rails 4 時代にそういう Pull Request 出してた人がいて Merge 寸前まで行ってたんだけど commit が複数に分かれてたのを「 squash してくれない？」とレビューされたところでプルリク主の意欲が燃え尽きたっぽくて Merge されずにコンフリクトして死んでた。

Add locale selector to email preview by plus3x · Pull Request #19923 · rails/rails

@rafaelfranca Fix of #19922

github.com

Rails 5 でも動くようにコンフリクトを解消してテストケースも追加したのが以下。

Add locale selector to email preview by morygonzalez · Pull Request #31596 · rails/rails

Summary This Pull Request make it possible to select location on ActionMailer Preview. Just like below. This is a rework of #19923. #19923 was almost done, but had not been merged and now it gets ...

github.com

動作イメージはこんな感じ。

ただ Merge 後にバグってるのを指摘されていま直してるところです。

Fix locale_selector JS bug in ActionMailer Preview by morygonzalez · Pull Request #31750 · rails/rails

Summary Fix bug arise from the Pull Request #3159 . locale_select only appears in I18n.available_locales.count > 1. So if users have only one locale, this code will occur error. — #31596 (revi...

github.com

頭良くないのでこういうしょぼい Pull Request でしか contribute できないけど自分にできる範囲で貢献していきたい。

追記 2018-01-24

問題を修正する Pull Request も Merge してもらったんで多分 Rails 5.2 にこの機能入ります。

嫁さんの Mac mini 2011 が危機的な状況を迎えていて、何か操作する度に常にレインボーサークルがくるくるしてしまい動作が非常に遅くなっていた。ディスクの空き容量が足りないこととメモリ不足が原因のようだった。このまま極限まで空き容量がなくなると OS の起動さえできなくなる恐れがあったので 960GB のSSD と 16GB のメモリを嫁さんに調達させて換装してみることにした。

購入時、 Mac mini 2011 はデフォルトのメモリは 4GB で拡張しても 8GB までということだったので Apple Store で 8GB に増設してもらったのだが、ネットで調査したところ実は 8GB 二枚差しで 16GB まで認識できるということがわかった。 8GB のメモリ 2 枚が 13000 円、 960GB の SSD が 30000 円ちょいで合計 43000 円程度費用がかかった。 SSD は SanDisk のものを、メモリは Komputerbay という聞いたことがないメーカーのものを利用した。

データ移行時に使うディスクケースと分解時に使うトルクスドライバーは以前使ったやつがあった。分解の手順は以下のサイトが詳細で非常に参考になった。

Mac mini(Mid 2011)のHDDをSSDに入れ換える

2018/1/22（追記）：こちらの記事は内容が古くなってしまった（＆分解手順がザックリだった）ので、各内容を新たな記事として作成し直しました。よって、こちらの記事ではなく以下の新しい記事をご覧ください。・Mac mini 2011/201...

sekinesan.jp

なお Mac mini は外見は似ていても発売年によって中のレイアウトは違いがあるようなので参考にするサイトを探すときは交換対象と同じ年式かどうかを確認した方がよい。

手順を以下にまとめる。

1. ディスクケースに SSD を入れて Mac mini に USB 接続しフォーマット
2. Mac mini の電源を落として ⌘+R しながら起動
3. ディスクユーティリティで起動ディスク（交換前の HDD ）の内容を外付けディスク（交換用の SSD ）にコピー
   • 一晩かかる
4. Mac mini を分解して SSD とメモリを交換
   • ほこりがいっぱいたまっているので掃除機で吸いながら分解する
   • トルクスドライバーは T6 と T8 の両方が必要
   • ロジックボードにつなげてあるコネクターの取り外し作業は思い切りが必要かつミスって壊すと Mac mini が不燃ゴミと化すので慎重さと大胆さが求められる
5. 元通りに組み立てる
   • SSD はねじの出っ張り部分が元付いていた HDD と同じ穴に入るように取り付けないときちんと固定されない
   • 元に戻すときに SATA ケーブルとロジックボードのコネクターが外れてしまいやすい。きちんと取り付けられていないと Mac 起動時にフォルダー内にはてなマークが表示されて正しく動作しない。
     • ディスクコピーがちゃんとできていないのかと思って焦ったが再分解して確認したところコネクターが外れていた
6. Mac を起動して動作確認
   • ブラウザーのクッキーはおろか開いていたウィンドウやタブまで完全に復元される
   • MS Office 系はライセンス認証が切れているのでライセンスキーの再入力が必要
     • Adobe ソフトを利用している場合はおそらくそちらも
7. Terminal.app を開いて sudo trimforce enable を実行し TRIM を有効にする

MacBook Pro のディスク交換よりも難易度は高かったが何とかなった。開発用途に使わない Mac なら十数万出して最新式のに買い換えるよりも数万円出してハードドライブを SSD に変えたりメモリを増やしてあげるだけで快適に使い続けられると思う。 Mac mini が遅くなったなぁとお困りの方はお試し下さい。

connpass で募集されていた勉強会に参加したところ、イベント終了後にイベント管理者から一方的にメールマガジン的なものが送られてくるようになった。勉強会直前の確認メッセージや次回の勉強会の告知ならよく他のイベントからも届くが、そうではなく主催者の私信的な内容だったのでこのようなメールは不要だった。大抵の一斉送信メールにはフッターなどに購読解除ページへのリンクなどがあるが、 connpass から届くメールにはそのような文言はなかった。

最初なぜこのような私信メールが届き続けるのかわからなかったが、自分が管理者になっているイベントで確認してみたところ、管理画面からイベント参加者に任意のメッセージを一斉送信することができるようだった。 connpass はイベントに参加登録すると自動的にイベントのグループに追加されるので、グループの管理者はグループメンバーにメッセージを一斉送信する仕組みがあるようだ。勉強会に参加しただけで一方的にグループのメンバーにされてしまうのは違和感がある。

とりあえず今回はメールマガジンは受信したくないと思ったので該当のイベントページから主催者に「勉強会に参加したときにこのようなメールを送り続けるという説明はなかった、メールマガジンを受信したくない」旨の問い合わせを行い、あわせて connpass にも「勉強会参加後に定期的にメールが届くようになった、同意なしにこのようなメールを送り続けるのを規約上容認しているのか」を問い合わせた。イベント主催者の方からは即座に返信があり、今後メールが届かないようにしてもらえた。 connpass の方（運営元のビープラウド社）からは一週間後に返信があり、自分でイベント主催者とやりとりしろという旨の文章と利用規約ページへのリンクが貼ってあるのみで、自分が尋ねた規約上容認しているかどうかへの回答は書かれてなかった。

そもそも自分が情弱だったのだが、勉強会参加後に自動的に登録されるグループから退会すれば主催者からの一斉送信メールは届かなくなるようだ。自分の場合には当該グループから退会すればよかったのにイベント主催者に苦情めいた問い合わせを行ってしまい申し訳なかった。ただ退会ボタンはぱっと見 disabled されており、到底クリックできるようには見えないし、そもそも退会することでメールが届かなくなるかどうかはわからない（ヘルプページをよく読まない限り退会することで何が起こるのかわからない）。

そもそもメールのみの受信設定を行えるような画面があってもよいと思うのだが、調べてみたところ新しいイベントが公開されたときや資料がアップロードされたときの通知設定は行えるが、イベント主催者からのメッセージを受け取らないようにする設定項目は存在しなかった。

connpass 内全体の各グループで適用される受信設定も同様で、イベント主催者からの恣意的なメッセージを受け取るかどうかの設定項目はなかった。

いらないものを拒否する手順への説明が記されておらず、自分の意図に反して送られてき続けるメールは全て迷惑メールだと思うが、運営元に問い合わせる限りはこれらは規約違反でもなくイベント管理者は自由に行えるようなので、 IT 勉強会を主催している各社の採用担当の皆さんは一度でも勉強会に参加したことがあるカモの皆さんに求人メールを定期的に送り続けてやれば良いのではないでしょうか。

イヤーパッドカバーがぼろぼろになっても自分で取り替えたりしながら割と大事に使ってきた SONY の MDR-1RBT のヘッドアームが折れて使えなくなってしまった。落としたりぶつけたりして壊したというより経年劣化でプラスチックがもろくなっていたっぽい。

音を出すという機能は生きているのに頭に装着するという機能が壊れて使えなくなったのは残念。修理もできるようだが家からかなり離れた車でしか行けないようなところにある郊外の電器屋に平日か土曜の日中に持ち込まないといけない＆修理料金が高いっぽいので修理するか逡巡してる。天神にソニーストアあるのにここで修理頼めないのは極めて謎。タカビーな Apple でも Apple Store に持ち込んだら古い Mac でも見てくれるのになぁ。あまり修理はして欲しくないのかも知れない。

しょうがないのでいまは iPhone に付いてくる Apple の純正イヤフォンを使ってる。ワイヤレスヘッドフォンに慣れきってたので有線は引っ張られる感じがして使い心地が悪い。 Anker の安い Bluetooth イヤフォンもあるにはあるが、電池のもちがよくないし何より自分は耳垢がしめってるネチョ耳クソ野郎なのでインイヤータイプのイヤフォンはあまり長時間付けたくない。頭の上に載っけるタイプのヘッドフォンが一番使い心地よかった。

ヘッドフォン、仕事道具という認識なかったけど失ってみて集中したいときなどに結構依存していたことがわかる。ワイヤレスヘッドフォンは偉大だった。