コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

色の定数は役割で名前をつけてあげるほうがいい

雑記

SASSにした時に色の名前を横断管理するときどうするかとか、iOSやAndroidでも共通の色定数を持って使う時になんて名付けるかとかそういうときに発生するときの気持ちを述べた雑記

割とデザイナー的なトピックスなんですが、今回はプログラマ的でもあるトピックスとして。

つらいパターン：色名をそのまま定数にする

const val COLOR_BLACK = "#00000"

直感的に黒のカラーコードを定数化する。黒のカラーコードというのはわかるが、それ以上でもそれ以下でもない。

良いと考えるパターン：用途で名前をつける

ただ単純に黒ではなく、黒はどの場面に使われるかで名前をつける。例えば黒がテーマカラーだとしたら以下のような感じ。

const val THEME_COLOR = "#00000"

このようにすれば、色の役割で管理できるため多少色味を調整したくなっても用途で色が変えられるので問題が減る。

参考リンク

Rubyを馴染ませる知見が詰まったスライド『新卒を一人前のRailsプログラマーにするための『階段』の作り方』

スライド・記事回顧録

先日、銀座Railsにいったときに「あ、見たかったこの発表。Youtubeに動画あったんだ！」と思って探したら見つけたのでスライド紹介と感想交えたメモ

koic.hatenablog.com

koic.hatenablog.com

感想

  • 「（人のコードを）読み」「（自らコードを）書き」「そろばん（工数見積もり）」というフレーズはすごい良いフレーズだと感じた
  • Ruby認定試験、Rubyのメソッド群を一通り理解するにはすごい良さそう。
  • 途中で出てくるonkさんの話はそうだなと思いつつ、何もOSSに恩返しできてないので頑張っていかないとなという気持ち
  • 下記のスライドもよさげ

www.slideshare.net

Rubyでクラス名のはじめに::(コロンを2つ)をつけるとそのクラスの絶対的な位置表現をすることができる

Ruby Tips

RailsのActiveRecordのクラス名と同名のModule作ったときに誤動作するけど、どういう原理なのかというメモ

環境

$ ruby -v
ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin16]

要約

:: から始まる場合は一番上位のレベルを指すため、module内などで使う場合にモジュールの絶対的な位置を表現することができる。

例

moduleなどで名前空間を区切らないクラスがあるとする

class Hoge
  def initialize
    p "root hoge"
  end
end

これに対し、同名のクラスを持つが、moduleで囲まれたものがあるとする

module AAA
  class Hoge
    def initialize
      p "in module hoge"
    end
  end
end

このmoduleのなかで Hoge.new とすると…

class Hoge
  def initialize
    p "root hoge"
  end
end

module AAA
  class Hoge
    def initialize
      p "in module hoge"
    end
  end

  Hoge.new
end

$ ruby example.rb 
"in module hoge"

となり、module内のHogeが呼ばれる。

この場合にmodule外のHogeを呼びたい場合は以下のように書く。

class Hoge
  def initialize
    p "root hoge"
  end
end

module AAA
  class Hoge
    def initialize
      p "in module hoge"
    end
  end

  ::Hoge.new
end

$ ruby example.rb 
"root hoge"

参考リンク

マイクロサービスにおけるサーキットブレーカーとは（簡易まとめ）

雑記

サーキットブレイカーって何それって言うときに説明するときのメモ

要約

複数のサービスから利用されるものの場合、使われる側のサービスは一定異常な稼働をし始めたら、使われないように切り離されるためのしくみ

例を交えて

サービスAにAPIリクエストを送って表示するサービスBがあるとする。

サービスAが正常稼働しているときは問題ないが、サービスBからのリクエストが増大してサービスAが応答不能になると、サービスB自体も反応が遅くなってくる。その状態になるとサービスAがそのまま応答がない状態なのに、さらにサービスBはリクエストを送り続けるので、サービスAの状況は悪化してしまう恐れがある。

そのため、サービスAとサービスBの間にサーキットブレイカーを入れる。

サーキットブレイカーを間に介在させると、サーキットブレイカーを通る過程で一定回数異常な状態が発生したときはサービスBからのリクエストをサーキットブレイカー側で遮断し、サーキットブレイカーが異常状態であるリクエストを送る。

そうすることで、サービスAが復旧するまでサーキットブレイカーが代理返答してくれるので、サービスBとしてはタイムアウトまで待たずとも正常に可動するようになる。

元ネタ

電気回路のブレーカーのこと。事故や故障で大きな電流が流れたときに自動的に遮断して配線を保護する機構のことを指す（らしい）。

関連リンク

音読系読書会をやってみたのでそれのYWT

雑記

willnetさんが紹介していた音読読書会を、昔同じ職場だったエンジニア同士（3人）でやってみた

ネタの出典元

blog.willnet.in

題材

今回はデータのとりあつかいみたいなところで以下の本をチョイス

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

感想

やったこと

  • 1章だけだけど、言い出しっぺファシリテーターの私がずっと音読する。
  • ところどころお菓子を食べたり、気になることを言い合ったりする。
  • 脱線しても話がある程度丸まるまでは喋ってみる

わかったこと

  • 進みは輪読会形式に比べると遅いけど、普通に読んでたらすっ飛ばしそうなところも意識として拾える。
  • 結構バックグラウンドが違うと、各々の知識で喋れたりするので良い。
  • ネットワーク環境があると、その場でググってこういう話もあるよね、とか自分のうろ覚えの知識を補強して喋れるので楽しい。

つぎにすること

  • 割と話したいひとがわーっと喋ってしまって、3人だから問題なかったのの、多くなると進行を止めたりしたので、討論タイムはある程度時間を考えたい
  • 時間設定が曖昧だったので、タイムキーパー的にちゃんと行動したい
  • もっといろいろなバックグラウンドがある人を集めたい感じ。

関連リンク

RSpecのdescribeにメソッド名を記述する場合、クラスメソッドは .か:: 、インスタンスメソッドは # で始めるのが一般的

RSpec

そういやこれの出典どこやみたいな気持ちで探してみたメモ

出典元

Better Specsに書いてあった。

use the Ruby documentation convention of . (or ::) when referring to a class method's name and # when referring to an instance method's name.
Ruby文書の規約ではクラスメソッドの名前には.(もしくは::)をインスタンスメソッドの名前には#を使っています。

関連リンク

『ボトムアップドメイン駆動設計』に行ってきたよメモ

行ってきたメモ

『アーキテクチャ ディスカッション Vol.1のときにめっちゃ事例を話されていたnrsさん独演会的な勉強会であるボトムアップドメイン駆動設計 - connpass に行ってきたのでメモというか感想

発表

大ボリューム前後編の資料

発表メモ

  • エリック・エヴァンス本に関して「パターン」と「マインド」という切り出し方をして、「パターン」の部分に関して実装的な部分の内容をよりぬきでC#のコードに落として説明。
  • ValueObjectはもちろん、リポジトリの説明のためにDependency injection の話にも触れて、実装例やその際に使う実装手法を交えながらわかりやすい順番で話されていた感じ。
  • 最後の話の締め的にはDDDというよりかはレイヤードアーキテクチャ、ヘキサゴナルアーキテクチャの文脈で今日の実装例を締めくくった。

感想

DDDに出てくる実装寄りの話を「パターン」という囲み方でとっつきやすい形に説明されていた感じでした。ただ御本人もお話されていたようにドメイン駆動設計でよく登場するユビキタス言語のような概念部分の話は「マインド」という形で切り分け、そこの理解は実際の書籍を読んでねという感じ分けてました。

この切り方、あんざいゆきさんがDroidKaigiで話したものにおきかえると今回の「パターン」の部分が「戦術的設計」で、「マインド」の部分が「戦略的設計」にあたるのかなという印象でした。

https://2.bp.blogspot.com/-gI5NBeRI2B4/WMDZ1MGfYPI/AAAAAAAAlow/NjR-agnEsNojXft8Eb-KNM1X2SumFe2EACLcB/s320/DroidKaigi2017.046.jpeg

- Y.A.M の 雑記帳: ドメイン駆動設計について DroidKaigi 2017 で登壇しました。 より

ドメイン駆動設計の本質的な部分は今回で言うところの「マインド」のほうがウェイト大きいかなと思っていて、それを実践していく上でモデリング技術力であったり、ドメインエキスパートとのコミュニケーションフロー(ユースケース駆動開発とか)に発展していくと思うので、今日の内容はそういう意味でも「エリック・エヴァンスのドメイン駆動設計の本を読むにあたって、先に知っておきたいプログラミングテクニックガイド」という感じだったなという印象です。

そこに関しては「軽量DDD」という形であるということも発表内でも、Twitterでも発表者ご当人がお話されていました。

上記のような感想を書きましたが、今日の話は面白くなかったとかためにならなかったとかでは全然なく、実際に値オブジェクトやエリック・エヴァンス文脈のエンティティはどう使うのか、ドメインモデル貧血症ってどういう状態なのか、というようなところが順を追って説明されたのでとてもわかりやすく、また実践的に使っているテクニックが落とし込まれていてとても勉強になりました。

「ドメイン駆動開発で扱われているこれって、実コードにするとどうなるの？」みたいなときに取り出しやすい資料を作っていただけてありがたいかぎりな感じでした。

（あと加えて書くとするなら、「マインド」の部分のドメイン駆動設計を知りたければもちこ本を読むと、エリック・エヴァンス本を読む前にはいいかもという気持ちにもなりました。）

おまけ

会場で質問したことにかとじゅんさんがレスポンスされており、なるほどなー！と思ったのでメモ

関連リンク