コード日進月歩

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

普通のRubyはクラスの定義は何回でも書けるし後勝ち

雑記

Railsのmoduleのことがわからなすぎて繰り返しやってたら気づいた程度のメモ

環境

$ ruby -v
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin18]

事例

module Oya; end


class Oya::KodomoA
  def self.call
    p "Say1"
  end
end

module Oya
  class KodomoA
    def self.call
      p "Say2"
    end
  end
end

module Oya
  class KodomoB
    def self.call2
      KodomoA.call
    end
  end
end

class Oya::KodomoA
  def self.call
    p "Say3"
  end
end



Oya::KodomoB.call2

こんなのがあると 結果は say3 が返ってくる。

なんでここらへんを調べてたの元ネタ

eager_loadでバグるのでその原理を知りたかったがタイムアップ

Rubyにおける%記法と%iと%wの挙動

Ruby Tips

よくRubocopに直された状態になり、あれ、これ何と同じなんだっけ？ってなるのでメモ

％(パーセント)記法

%を使う記法はリファレンスにも%記法として紹介されている。

リテラル (Ruby 2.6.0) - %記法

%wと%W

小文字のダブリューで始まるとシンボルとして生成される

なお、大文字のダブリュー (%W) になると囲んだ内容が式展開される

value = "atai"

という感じにやると

%w(value #{value})
# => ["value", "\#{value}"]
%W(value #{value})
# => ["value", "atai"]

%iと%I

小文字のアイで始まるとシンボルとして生成される

なお、大文字のアイ (%I) になるとW同様に内容が式展開される

%i(value #{value})
#=> [:value, :"\#{value}"]

%I(value #{value})
#=> [:value, :atai]

参考リンク

WORKDAY関数を駆使して人日工数の稼働開始日から終了日を割り出す

雑記

昨日の発展編。WORKDAYに関してはこちら参照のこと

WORKDAY関数の仕様

WORKDAY関数の仕様は以下

  • 経過日数を設定する「日数」の数値を0にすると休日判定かかわらず「開始日」の値になる
  • 日数のカウントは当日が含まれない。そのため、1を指定すると翌日の値になる。
  • 土日の場合は当日が含まれないので明けの日数からカウントされた日付になる

工数換算の仕様

対して工数見積もりとしてスタンダードそうな仕様は以下

  • 開始日は1日とみなし、作業終了日を見積もりたい
  • 土日を含めた祝日は工数として入れない

2つの要件を満たす方法

  • WORKDAYに指定する日数は原則人日工数から-1した数値を指定する
  • ただし開始日が土日と祝日の場合は-1すると開始日になってしまうので-1しない。

このような形で関数を組み合わせればOK

例と解説

  • 開始日がB1
  • 人日工数の値がB2
  • L列が祝日の日付が並んでる

とすれば以下のようにする

=WORKDAY(B1,IF(OR(WEEKDAY(B1,2)>5,COUNTIF($L:$L,B1)>0),B2,B2-1),$L:$L)

分かりづらい部分を解説する

対象が土日か

WEEKDAY(B1,2)>5

WEEKDAY関数の2つ目で 2 を指定すると 月曜日が1となり順番に曜日が進む毎にカウントされ、土曜日が6,日曜日が7となる。

対象が祝日か

COUNTIF($L:$L,B1)>0

L列が日付の羅列になっているので、それと合致するものが0個以上あればその日は祝日とみなすことができる

土日か祝日の場合はB2の値そのまま、それ以外はB2から-1の数値を出す

IF(OR(WEEKDAY(B1,2)>5,COUNTIF($L:$L,B1)>0),B2,B2-1)

上2つをORで囲んで、土日かを比較する

参考リンク

Excelやスプレッドシートで稼働日を出すのはWORKDAY関数が便利

Tips

ガントチャート職人になりかけているのでそのメモ

関数

=WORKDAY( 開始日 , 稼働させたい日数 , 祝日リストの範囲指定）

開始日から稼働日分後の日付を算出する。土日、および祝日リストで指定した日付はカウント対象としない

便利ポイント

土日と指定の日を読み飛ばして日付を導出してくれるので、稼働日のスケジュールを引くときなどに便利

祝日リストなどは用意してくれている人がいるので、それをコピーして別シートに貼り付けるなどするといい

Excel最新版！2019年 祝日一覧（2019年～2022年まで） - 教えて！HELPDESK

不便ポイント

開始日は稼働させたい日に含まれないので、そこを考慮する必要がある。

例えば開始日を 2019/2/18 (月曜日) から2日を指定する。その場合18日と19日で2日使うので終了日は 2/19 みたいに考えられそうだが、出てくるのは 2019/2/20 、指定日はカウントには含まれない。

参考リンク

休みの際の対応フローを考えるときのはじめの一歩

雑記

連休前なので自分の知識整理を含めた「障害対応の体制づくりを考えるときにまず何から考えるべきか」という内容の雑記です

考えること

トピックとしては3つ

  • どれくらい止まってもいいのか
  • 有事の際の連絡系統、意思決定系統はどうするべきか
  • 何かあったときにどうすればトラブルに対処できるのか

どれくらい止まってもいいのか

大概のWebサービスが24時間365日稼働していれば一番幸せだけれど、それを確実に保つことはできない。

ただし100%の稼働率を担保するのは難しいので、その場合にどれくらい止まっていいかという観点が重要になる。

そのため「どれくらい止まってもいいのか」というのを考える必要がある。

有事の際の指示系統

障害時は慌ただしくなるのが世の常。そのため慌ただしい状況下においてもただしく関係各所に伝えることが大事。

そのため何か起きたときの連絡先、そして指示系統はしっかりしておくといい。決めるべきこととしては以下の内容

  • 障害発生時の報告先（チャット/連絡網 etc..)
  • 有事の際に動くときのアクションの仕方とルール

1つ目は割と感が得られることも多いのだが、2つ目はあまり考えられることがない。2つ目を定めておくメリットとしては、気づいた人が慌てて行動したことで二次被害を招くということがあるので、有事の際は複数人の意思を絡ませるようにするなど、一定のルールを敷いて認識合わせをしておくことが大切になる。

トラブルに対処できるのは誰か

サービスもRailsやLaravelなどで構成されるようなアプリケーション部分と、Linuxなどのミドルウェア部分だったりと多岐に渡ることが多い。みんながすべてのレイヤーに対して対応できるのであれば問題ないが、大概においてそうではないことが多い。そのため以下のようなことをまとめておくといい。

  • トラブルが起きるとしたらどういう分類でトラブルが起きるのか
  • そのトラブルが起きる部分は誰なら対処できるのか
  • その対処方法はマニュアル化できるか、できるのであればあるか

例えばサーバーの再起動のようなことはマニュアル化できる部分なので、有事の際に人に依存せずできるようになっているとすごく楽になる。

関連リンク

『突撃！隣のアーキテクチャ』に行ってきたよメモ

行ってきたメモ

突撃!!隣のアーキテクチャに行ってきたのでメモ

各発表の感想

SUGARのアーキテクチャ

感想

  • サーバ/iOS/Androidすべてのアーキテクチャを紹介するというボリューム抜群の話
  • 内容事例としてあhCleanArchitectureの考え方依存性逆転の法則（DIP）でやっていてScalaのコードを読めない自分でも結構把握することができた
  • OSのコア機能はどうしてもレイヤーの層に沿わせるとつらくなるからそこらへんは別で考えるというところは、やっぱりそうなりますよね…という気持ちになる。

関連リンク

CQRS+ES(再)入門

感想

  • DDDといえば名前の挙がるかとじゅんさんのCommand and Query Responsibility Segregation + Event Sourcing のパターン説明
  • 「何故CRUDはDDDに不向きなのか」という話とそれに他するアプローチの話はすごい学びがあった
  • やはりこういうアーキテクチャはできた根源の理由などを説明してもらえるとすごい使い型を考えることができる。

関連リンク

AbemaTV iOS Architecture

感想

  • 画面遷移がめちゃくちゃ大変そうなAbemaTVの事例
  • GUIのアーキテクチャとしてMVVMとMVVM+Fluxを使い分けながらやるという論法はあまり聞かなかったのでなるほどそういうやり方もあるのかなという感じ。
  • 実装を整えるためにライブラリを用意してオープンソースとして運用して、キレイにしていくというアプローチは正の循環だなぁと思った

関連リンク

Mirattive Androidアプリの取り組み

感想

  • 自由度が高いネイティブアプリ開発において起こりがちなマッチョソースとそれに立ち向かう話
  • 6000行のKotlinのコードは固まるというパワーワード
  • 「よいコードはお金を作り出しているコード」という側面もあるので、それに感謝しつつも持続可能なものに切り替えていく良い話だった

関連リンク

DIライブラリ Airframeを使ってみた

speakerdeck.com

感想

  • 3ヶ月で強そうな人たちのいる前で発表するという部分にみんな共鳴していて、同じく私も同じく子供の演奏会を見るような気分に
  • こういう経験を早く踏めることはとてもいいことだな…という感想を

関連リンク

GoでのAPI開発現場のアーキテクチャ実装事例

感想

  • ゼロからGoのアプリケーションを作ってみてこうしてみたけどどうだろう事例
  • 多分いろんな事例をかき集めて来たんだろうけどここまで構成できるのはすごい…
  • 実際のコードを交えながら、という今回のコンセプトにハマってた

関連リンク

SPA状態設計（Elm）

speakerdeck.com

感想

  • SPAの責任分離範囲に関して悩む話
  • SPAってやっていくと実は普通にサーバーでHTML組み立てるほうがはやいんじゃね…？みたいな疑問にぶつかるし、結構そういう場面って多い気がする
  • ElmじゃないからScalaのコードを用意するという周到さがすごかった

関連リンク

全体を通しての感想

  • サーバサイド、ネイティブアプリ、各社で取り組んでいることを聞けてとても学びが多かった
  • Railsに振れているとアーキテクチャをどうしようみたいな議論起きないし、逆に悪手になるパターンが多いのでこういうバラエティに富んだ情報提供の場は最高にありがたい
  • 全体的にアーキテクチャの話でありながらScala成分が多かったのは主催者側の成分が多かったからかな…Scalaやってみたい…

『銀座Rails #8』に行ってきたよメモ

行ってきたメモ

銀座Rails#8 @リンクアンドモチベーション - connpass に行ってきたよメモ

各発表の感想

Railsエンジニアのためのウェブセキュリティ入門

感想

  • Railsを使った定番脆弱性の解説シリーズ
  • 天然物ではない脆弱性を用意しており、結構油断するとやりかねないな…という話が多かった。
  • Railsのレールにさえ載っていれば、多くの脆弱性が防げるんだなと言うことがわかる話だった。
  • 脆弱性があるシステムを納品したら敗訴した例は怖い。

関連リンク

その正規表現、異議あり！ 〜 ReDoSについて

感想

  • メアドのバリデーションでクライアントとサーバーで移植しやすいからよく持ち出される正規表現
  • いくら富豪プログラミングな世界観になってきてもかなりの負荷がかかるんだなというのを数値を見て実感
  • 結構この試行回数を無駄に増やしてアタックするという手法はありそうなので気にかけて動いたほうがいいなという気持ちに。

関連リンク

Rubyコミッタの武者さんからRe2の紹介もあった

SQLQLとは

感想

  • めちゃくちゃ便利な世界観ではあるが、悪意に対しての防護策をきっちり取らないとすぐにやられてしまう世界でもあるなと感じる。
  • ここらへんの変化球がGraphQLなのかなとか思った、と思ったらその話をこの前のRailsDMでされていた模様

関連リンク

障害対応で実施する３つのこと

感想

  • 結構体験した人はわかるけど、体験していない人はそうなるのかっていう見る人の経験値によって感想が変わりそうな話
  • インシデント発生時ってめちゃくちゃ慌てるから、そういうときにでも指差し確認で実行できる手順書なりスクリプトを日頃から用意しておく大事さが身にしみる話
  • 謝罪がある不思議な雰囲気なLTでした

関連リンク

全体を通しての感想

  • Railsに関して徳丸先生が語るというのはものすごく新鮮だったし、いつも見るevilサイトとRailsが組み合わさって不思議な気持ちに
  • Railsの良さや、Railsでも通り抜けてしまうものを実例を交えて説明していただけたので、生で見ることができてよかった
  • 正規表現についてのDos攻撃の話は全然しらない分野だったので学びがあった
  • 後続の予定があったので懇親会には参加できなかったが、とても参加できてよかった勉強会だった。