コード日進月歩

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

ログの保持期間の目安についてまとめられている資料があるので2023年2月時点で照らし合わせる

ざっくりまとめ

Twitterでみて書き留めておきたかったので残す

出典

IPAが2016年に出した「企業における情報システムのログ管理に関する実態調査」があり、こちらに法令やガイドラインと絡めてまとめられている。

記載のあるログ保存期間の目安と対応するガイドライン

改めて出典資料から2022年アクセス可能な情報で照らし合わせる

保存期間 法令、ガイドラインなど
1ヶ月間 刑事訴訟法 - 第百九十七条の3
3ヶ月間 サイバー犯罪に関する条約（略称：サイバー犯罪条約）（通称：ブダペスト条約）- 第十六条 ２
12ヶ月間(1年間) ・PCIDSS v4.0 - 10.5.1
・Successful SIEM and Log Management Strategies for Audit and Compliance - Discussion
36ヶ月間(3年間) 不正アクセス行為の禁止等に関する法律の時効に合わせて
60ヶ月間(5年間) ・金融商品取引法 - 25条の期間に合わせて
・電子計算機損壊等業務妨害罪の時効に合わせて
84ヶ月(7年間) 下記3つの時効に合わせて
・電子計算機使用詐欺罪
・詐欺罪
・窃盗罪
120ヶ月(10年間) ・『不当利得返還請求』等、2020年改正前民法上の請求権期限
・商法19条（旧商法36条）

なお出典元の資料にある「平成23年度政府機関における情報システムのログ取得・管理の在り方の検討に係る調査報告書」は現在閲覧不可のため削除、「欧州連合（EU）のデータ保護法」も原典にあたるものが見当たらないためで削除しました。

細かい補足は以下です。

刑事訴訟法 - 第百九十七条の3

法令を引用すると以下の通り

③　検察官、検察事務官又は司法警察員は、差押え又は記録命令付差押えをするため必要があるときは、電気通信を行うための設備を他人の通信の用に供する事業を営む者又は自己の業務のために不特定若しくは多数の者の通信を媒介することのできる電気通信を行うための設備を設置している者に対し、その業務上記録している電気通信の送信元、送信先、通信日時その他の通信履歴の電磁的記録のうち必要なものを特定し、三十日を超えない期間を定めて、これを消去しないよう、書面で求めることができる。（後略）

上記にあるように消さないように要求される可能性がある30日間は保持しておくことが安全という解釈。

「サイバー犯罪に関する条約（略称：サイバー犯罪条約）（通称：ブダペスト条約）- 第十六条 ２」について

こちらも引用すると以下のとおり

(前略）締約国は、ある者が保有し又は管理している特定の蔵置されたコンピュータ・データを保全するよう当該者に命令することによって１の規定を実施する場合には、自国の権限のある当局が当該コンピュータ・ データの開示を求めることを可能にするために必要な期間（九十日を限度とする。）、当該コンピュータ・データの完全性を保全し及び維持することを当該者に義務付けるため、必要な立法その他の措置をとる。締約国は、そのような命令を引き続き更新することができる旨定めることができる。

上記にあるように90日間を限度とする保全命令が出る可能性があるので、90日間は保持するほうがよいという解釈だと思われます。

「Payment Card Industry Data Security Standard v4.0」について

クレジットカードのセキュリティ基準であるPCIDSSでは細かい要件が定義されている。

そのうちv4.0の要件のひとつとして、監査ログの履歴を12ヶ月間保持すべきというガイドラインがあるためこちらに合わせると監査ログは12ヶ月保持すべきということになる。

「Successful SIEM and Log Management Strategies for Audit and Compliance」について

2010年頃にSIEM(Security Information and Event Management)とログの管理についてまとめた資料。

この資料内で以下の記述がある。

Sarbanes Oxley, also provides a base timeline of one year for event retention. Again, though not technology directed, actors subject to the law are required to provide annual reports, and both annual and one year appear repeatedly in the law.

いわゆるSOX法(Sarbanes Oxley)ではだいたいイベントの保持期間を1年保持としている、というところから出典資料では取り上げたのかと思われます。

各種法律の時効期限について

法律に関しては刑罰の期間に応じて時効の期間が定められている。(刑事訴訟法第250条2項6号)そのため時効になるまでは利用するタイミングがあるためその期間は保持しておくべきという解釈かと思われる。

なお今回とりあげられている法と罪と時効の対応付けは以下の通り。

法律 刑罰 時効
不正アクセス行為の禁止等に関する法律 第十一条 三年以下の懲役又は百万円以下の罰金 長期五年未満の懲役若しくは禁錮又は罰金に当たる罪については三年
刑法 第二百三十四条の二（電子計算機損壊等業務妨害） 五年以下の懲役又は百万円以下の罰金 長期十年未満の懲役又は禁錮に当たる罪については五年
刑法 第二百四十六条の二(電子計算機使用詐欺) 十年以下の懲役 長期十五年未満の懲役又は禁錮に当たる罪については七年
刑法 第二百四十六条（詐欺） 十年以下の懲役 長期十五年未満の懲役又は禁錮に当たる罪については七年
刑法 第二百三十五条（窃盗） 十年以下の懲役又は五十万円以下の罰金 長期十五年未満の懲役又は禁錮に当たる罪については七年

金融商品取引法の25条について

金融商品取引法の25条では内部統制関連文書、有価証券報告書とその付属文書などの文書を必要があれば公表しないといけない旨の条文であり、ログがこちらに関わる情報の場合はこの条文での最長期間である「五年」保持するべきという解釈かと思われます。

民法上の請求権期限について

出典元の設定がかなりアバウトなのですが、2020年の改正前の民法の請求などに関わる場合おいては十年という期間が出る事が多いため、代表例として「不当利得返還請求」をあげているのかと思われます。

また、2020年以降の出来事においては期間が5年になっているケースもあるので、決済など民事に関わりがありそうなシステムログなどは留意が必要かと考えられます。

以下、参考サイトです。

民法総則改正のポイントを徹底解説（第５回）～消滅時効について①～

商法19条と旧商法36条について

商法19条の3項では以下のような記述がある

商人は、帳簿閉鎖の時から十年間、その商業帳簿及びその営業に関する重要な資料を保存しなければならない。

ということで帳簿関係の情報は10年保存が必要となり、ログがそこに関わる場合はこちらを留意する必要がある。

なお、出典元の資料では商法改正前のものだったため36条という記載があったが、現在では19条として記載があるためそちらを今回は記載した。

以下参考リンク

余談、GDPRについて

GDPRについて「ログを保持せよ」ということではなく「個人に関わる該当ログを消せる状態にせよ」という話ので今回の切り口とは別になる。

関連リンク

合意形成のスキルを理論立って考えるときにみたいスライド『「笑顔の合意」のテクニック - 噛み合わない会話と対立を克服するための、エモさを排した実践的なスキルと技法 -』

スライド・記事回顧録

チームに関わるすべての人間が読むとズレが減らせそうなので時折読み返したい資料としてスライド回顧録です。

対象のスライド

speakerdeck.com

みどころ

  • 自身や他の人の「感情」「ニーズ」「要求」に関しての目の向けかたが紹介されており、その3つの取り扱い方が書かれている。
  • アンガーマネジメントを他の要素を合わせつつ、わかりやすく紹介している。
  • 最後にありがちな実例を交えており、資料としてもわかりやすい

関連リンク

Rubyにてハッシュを用いたキーワード引数(**引数)を使いたくなった場合は本当のそれが必要かを一息おいて考えてほしい

Ruby 経験則

ハッシュを用いたキーワード引数（アスタリスクを二重につける記法のもの）を使ってしまうことによるデメリットと代替案に関してまとめます。

今回扱うケースとRubyのバージョン

一息おいて考えてほしいケースのサンプルコードは以下

def put_english_text(**params)
  params_times = params[:repeat_times].to_i
  repeat_times = params_times < 1 ? 1 : params_times

  puts(params[:before_text])
  repeat_times.times do
    puts("#{params[:s_word]} #{params[:v_word]} #{params[:o_word]}")
  end
  puts(params[:after_text])
end

サンプルコードの確認につかったRubyのバージョンは以下

$ ruby -v
ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin19]

この書き方によるデメリット

引数として何を扱っているかがわかりにくい

**params としてしまっているので、このメソッドが引数として何を必要として、どう使うのかというのがメソッド内のプログラムコードを参照しないとわからない。

今回のサンプルコードでは少なからず6つの要素を引数的に扱っているが、それを把握するにはparams[:hogehoge]と使っている部分をコードから拾っていかなければいけない。

「params をIDEなどの検索で拾っていけばいい」という考え方ものあるが、メソッドの引数として愚直に並べた場合と比べると把握スピードに差がでるし、IDEの補完も効きにくくなるのでメリットのほうが少ないと思われる。

関係ない値をメソッドの引数のように記述できる

通常のキーワード引数の場合は、足りない場合はエラーになるし、想定外のものが引数に設定されていればエラーになる。だがこの形式の場合メソッド上に使わない値をセットしてもエラーにはならない。

# 下記のように全く関係ないsurpriseをセットしても問題ないし、repeat_timesなどを入れなくても問題がない
put_english_text(surprise: "yeah!",after_text: "see you!")

作り上は問題がないが、コードリーディングするときにノイズになるためリーディングコストがあがる。

定義済みのハッシュの転用が可能になるのでコードリード難易度が上がる

このサンプルコードのメソッドを呼び出す場合以下のような書き方ができます

## 普通のキーワード引数のように利用する
put_english_text(before_text: "hello!", s_word: "I", v_word: "like", o_word: "dog")

## ハッシュの中身をそのまま転用する
params_hash = {s_word: "I", v_word: "like", o_word: "sushi",repeat_times: "5" }
put_english_text(**params_hash)

後者のように「定義済のハッシュをそのまま利用する」ということが可能なので、他の場所から取得したハッシュをそのままセットもできる。そのためRailsのControllerなどでは params の actionが受け取ったパラメータをそのままメソッドに送るということも可能になる。

一見すると便利なように見えるが、メソッドの引数がパラメータ名に依存するので、パラメータの名称が変更になった場合にメソッドの実態処理にも変更の影響を受けるので変更容易性が損なわれる。

代替案

多くは引数の多さを回避するためなので、少なくするためのアプローチをご紹介します。

引数をまとめる

例えば今回のケースだと「SVOの文」に関しては1つの文字列にまとめられそうなので、3つの引数が1つにできる。以下変更例です。

def put_english_text(repeat_time: ,before_text: ,svo_text: ,after_text:nil)
  repeat_times = repeat_time < 1 ? 1 : repeat_time

  puts(before_text)
  repeat_times.times do
    puts(svo_text)
  end
  puts(after_text)
end

svoのテキストは事前に組み立てて置けばいいので呼び出しは下記のようになる。

main_text = "#{s_word} #{v_word} #{o_word}"

put_english_text(repeat_time: 1, before_text: "hello!", svo_text: main_text)

コンテキストの塊でクラス化する

引数をまとめると基本的な目線は同じだが、考え方を変えます。今回の put_english_text のメソッドは3つの英文をputsするものなので、英文の塊を1つのオブジェクトとして捉えてクラス化してしまえばいいという発想もできる。

今回のケースの場合は以下のような考え方

class EnglishText
  def initialize(text:, repeat_time: 1)
    @text = text.to_s
    set_repeat_time = repeat_time.to_i <= 0 ? 1 : repeat_time.to_i
    @repeat_time = set_repeat_time
  end

  def output
    output_text = "#{@text}\n"
    output_text * @repeat_time
  end
end

def put_english_text(before_text:, main_text:, after_text:)
  puts(before_text.output)
  puts(main_text.output)
  puts(after_text.output)
end

英文本体と繰り返しがあるという部分の機能をクラスに定義し、メソッド自体は表示だけに集中させた。このメソッドを使う場合は以下のようになる。

s_word = "I"
v_word = "like"
o_word = "sushi"

set_before_text = EnglishText.new(text: "Hello!")
set_main_text = EnglishText.new(text: "#{s_word} #{v_word} #{o_word}", repeat_time: 10)
set_after_text = EnglishText.new(text: "See you!")

put_english_text(before_text:set_before_text,main_text:set_main_text,after_text: set_after_text)

このようにすると責務を分離できるので、メソッドの内容も明快にしやすいです。ただ今回のサンプルコードだとやりたいことが単純なためやや冗長にも見えるため、パラメータの性質を見極めながらこちらの例を参考にしていただきたいです。

この状態を利用したくなるケース

その時どう考えればいいか、というところを最後にまとめておきます。

RubocopのMetrics/ParameterListsで怒られたから回避策として使いたい

安易にRubocopの警告を回避するために利用するのはオススメできません。原則引数が多いということは「そのメソッドに多くのことをやらせようとしすぎている」という前兆なので、そこに対してアプローチをしていくのが良いかと思います。以下アプローチの例です。

  • そのメソッドに引数としてすべて渡す必要があるか、事前に処理を加えてまとめられないか？
  • 複数の引数で1つの意味を構成するようなものがないか、もしあればプレーンなRubyのクラスや構造体を作れないか？
  • そのメソッドに複数のことをやらせようとしていないか。その処理は分けられないか？

他のハッシュ要素をそのまま当てはめたい

「定義済みのハッシュの転用が可能になるのでコードリード難易度が上がる」のパートで紹介した、別のハッシュを埋め込みたいというニーズを満たすために使うケースもあると思うが、よほどのことがない限りそのまま渡すことはオススメできないです。以下理由です。

  • 前述で紹介したとおり、関係ない内容もセットできるので関係がない値も渡るので要不要の判断が利用先を見ないとわからない
  • 渡ってきたハッシュの中身がどうあるべきかが定まらないので、テストコードが書きにくい
  • 送り元のハッシュのキー名が変更になるとメソッド内の記述も変更しないといけない

基本的には「コードの見通しが悪い」「依存が強くなりすぎて変更の難易度が上がる（＝変更容易性が著しく下がる）」という2点なので、代替案のパートで紹介したやり方を元にきっちり必要なものを引数として明示的にセットしたほうが良いかと思います。

参考サイト

「良いコード/悪いコードで学ぶ設計入門」をRails開発に活用する目線で整理してみる

読み終わったよメモ

ミノ駆動本の読書会を社内で行い、そちらを振り返りRailsで活用する目線でどのようなところが活きるポイントかを「章ごと」と「全体を通して」で整理をしてみます。

章ごとに振り返る

1 悪しき構造の弊害を知覚する

こちらはイントロダクションの章で、どのようなコードをこの書籍では「悪い」と呼んでいるNGパターンのものがどんなものなのかを説明していく章となっており、後続の個々の説明とつながっていく章となっていると思います。

2 設計の初歩

この章では例示した悪いソースコードをベースに、今後の章で取り上げていくものを当てはめていくとどのように改善されるのかという例示を示すパートです。この章だけでも初歩的な改善のやり方を紹介しており、言語に関わらず参考にできる部分が多いと思います。

3 クラス設計 ―すべてにつながる設計の基盤―

この章から具体的なプログラムコーディングにおけるクラスの組み立て方の話がNGパターンとともに取り上げられてます。

Railsで「FatModelになったからPOROに切り出そう」などとなったときにどういうクラスを作ればいいのかわからなくなる、というケースもあるのではないかと思うがその際に「3.2 成熟したクラスへ成長させる設計術」のパートで多く参考になるところがあります。ストレートに参考になるのは以下の部分。

  • 3.2 成熟したクラスへ成長させる設計術
    • 中でも以下の章
      • 3.2.1 コンストラクタで確実に正常値を設定する
      • 3.2.3 不変で思わぬ動作を防ぐ
      • 3.2.4 変更したい場合は新しいインスタンスを作成する

上記に関しては「変更容易性をあげる」というところに大きく寄与する部分なので言語に関わらず利用できると思います。

なお、この章に登場する「値オブジェクト」は語る人によって定義の変わるワードのため使う場合は気をつけると良いかと思います（参考サイト）

4 不変の活用 ―安定動作を構築する―

前の章で取り上げた部分を掘り下げた章で、「なぜ再代入が変更容易性に影響するのか？」「可変にするべきケースはどういうものがあるのか？」という話が中心になっています。

Railsでも以下のようなコードを見かけるので、このようなコードがどういう悪影響をもたらす可能性があるのかをこの章を読むと認識できるようになり、バグの発生をグッと減らす書き方につなげることができるのではないかと思います。

def create
  name = params[:name]
  age = params[:age]
  user = User.create(name: name, age: age)
  ## ユーザ作成時にボーナスポイントが入る
  point = 2000
  
  ## 年齢が20歳以下の場合はポイントが4000pt
  point = 4000 if age >= 20
  
  user.point = point
  
  ## 関連プロフィールレコードを作成
  user.build_profile
  
  user.save!
  
  ### 所持ポイントが3000以上ならリダイレクト先を変える
  redirect_to "/special" and return if point >= 3000
  
  
  redirect_to "/"
end

個人的にはこの章がプログラムコードを書く面においては学びが多い部分かと思っています。

5 低凝集 ―バラバラになったモノたち―

この章ではメソッドを作るときの具体的なノウハウを紹介する章になっておりRails開発で使える部分としては以下の部分。

  • 5.1 static メソッドの誤用
    • ここではRubyのクラスメソッドとして作るときの考え方、判断基準がわかる
  • 5.2 初期化ロジックの分散
    • 初期化のロジックが複雑化する場合の一個のアプローチとして利用できる
  • 5.3 共通処理クラス(Common・Util)
    • どういうことを共通処理としておくべきか、というポイントがわかる
  • 5.5 多すぎる引数
    • 不変にしたり、完全コンストラクタを目指すと起きがちな多すぎる引数への対策アプローチがわかる

他の部分に関してはRubyやRailsだと噛み合わない可能性があるので、考え方の1つとして読んでおくとよいと思います。

6 条件分岐 ―迷宮化した分岐処理を解きほぐす技法―

アプリケーションは成長していくごとに当初とは違ったユースケースが増えていくので条件分岐も増えるのは必然、そのときの条件分岐に関しての対策方法に関しての話がこの章です。Railsで有用そうなものは以下の部分

  • 6.1 条件分岐のネストによる可読性低下
    • 早期returnの有用性がわかる
  • 6.2 switch 文の重複
    • どのようなときに「条件分岐が散らばっているのか」というのがわかり、まとめる方針がわかる

6章ではinterfaceを用いた条件分岐ロジックの解体を中心に話が進むため、Rubyの場合読み替えれば当てはめられる部分も多く一切使えないというわけではないですが、ストレートに当てはめにくいところではあるので、読みながら使える部分を整理するトピックかと思っています。

7 コレクション ―ネストを解消する構造化技法―

この章は配列などのコレクション要素を取り出してループさせるときの処理に関して陥りがちな話を取り上げてます。この章はコンパクトかつRubyでもストレートに使える要素が多いと思います。

特筆しておくべきところはコレクションを直接渡さないようにする（7.3 低凝集なコレクション処理)というのは認識がないとやりがちな部分なのでは作り方の1つとして覚えておくと良いかなと思います。

8 密結合 ―絡まって解きほぐせない構造―

この章では「単一責任原則」がどのような利点をもたらすというのかを中心に説明している章で、メソッドやクラスをどういう塊で扱うべきなのかを説明しています。この章もストレートに活用できる部分が多いと思います。

また、DRY原則で陥りがちな罠に関しても書いてくれているので、「DRY原則で共通化したほうがみんな便利だ！」と善意からくる悲劇もここを読んでおくと起きることが少なくできると思います。

加えて「スマートUI」に関しては取り上げられている部分は少ないですが、RailsではViewにロジックが置かれすぎてしまうなどかなり起きがちな話なので意識してみると良い部分なのかなと思います。

9 設計の健全性をそこなうさまざまな悪魔たち

この章は変更可用性においてつらくなるポイントをあげている章になっています。Rails開発にストレートに活用できそうな部分は以下のパート。

他の部分はRubyだと参考にならない部分や、Railsのパッケージング構成自体がこれで述べられているアンチパターンに近いので一部そぐわないかもしれない、というところでした。ただ他の章同様に知識としては役に立つ部分なので一読すると良いと思います。

10 名前設計 ―あるべき構造を見破る名前―

ここでは「名前」を中心に語られています。「名前なんてみんながわかればいい」というように考えている人にはぜひ読んでいただきたい章で名前が以下にアプリケーションの成長と変更可用性に寄与するかというのが語られています。Rubyの父、Matzも名前重要というところは語っており、Rubyを扱う人には他の章よりも意義のあるパートかと思います。

個人的には「汎用的な名付けをするとなんでもかんでもそこに機構が追加されて低凝集になる」という旨の部分がコードレビューをする際に大変役に立つ考え方だなと感じました。

11 コメント ―保守と変更の正確性を高める書き方―

こちらの章はコメントに関しての考え方の章となっており、どのようなコメントが未来のために有用かという観点で書かれています。コメントを書く自分自身の指針や、チームのルールをつくるときの起点になるような内容のため、特定の言語に限らず役に立つ話題かと思います。

12 メソッド（関数） ―良きクラスには良きメソッドあり―

こちらは2章から9章で紹介してきた方法論をどう扱うと変更可用性の高いメソッドをつくることができるか、という実践紹介的な章です。いままでは問題に対しての解法という切り口だったので、いざゼロイチでメソッドを作るときにはどういうことを考えるべきかというおさらい的な章なので、いままでの章を読んだ上で読んだほうがいいかと思います。

13 モデリング ―クラス設計の土台―

この章では意味のあるモデルをどう考え、それをどうやってクラスにしていくかという話が中心の章になります。どうやってクラスを分けるべきか、概念を整理するべきかというところを説明しているため、システムの大枠の設計をする際に助けとなる話かなと思っています。

個人的にはこの章がRails開発をやっていると一番混乱する章かなと思っています。Model=ActiveRecordという前提で読んでしまうと混乱するので、一般的なモデルとは何かというのを前提として頭に入れてから読むとスッと入ると思います。

参考：モデルとは何であって、何でないのか #kichijojipm - Speaker Deck

14 リファクタリング ―既存コードを成長に導く技―

こちらは著者の経験値や知識をベースにしたリファクタリングのテクニックが紹介されている。いざリファクタリングをしなければならなくなったときにコードを直していく手法などは参考になる部分が多いです。

また、著者のRailsでのリファクタに関してもコラムとして書かれているのでその部分ももともと主軸を別の言語においていた目線なので従来のRailsでのリファクタとは違う切り口が紹介されているので学びがあると思います。

15 設計の意義と設計への向き合い方

こちらの章は章のタイトルどおり向き合い方の話となる、設計というよりかは考え方が主体の部分とはなる。そのため設計というよりかは知識の活かし方や取り組みかたのTips的なことが書かれているので、今までと毛色は違う部分となるが読み物として読んでおくと良い部分かなと思います。

16 設計を妨げる開発プロセスとの戦い

こちらはいままでの手法などをどうやって実際のプロダクトコードやチームに浸透させていくか？という部分の話となる。もしいままでの話をチームとして広げて行く場合の想定問答として活用できる部分かと思われます。

17 設計技術の理解の深め方

こちらは最後の総括の章なので、この本よりも先に、というところの内容となっています。

全体を通して

Railsでも使えるコードのテクニック

こちらの本は著者の方が「変更可用性」を中心においた書籍であるということは様々な場所で語られており、導入部分にも記載があります。そのため考え方や心構えの部分はビジネスの成長や変化に伴ってアプリケーションやシステムをいかに楽に（≒省コストで）変更させることができるかというのを扱っていると思っています。

Railsだとフルスタックフレームワークの密結合の特性を生かして、素早く作ることができるという利点があるため部分的にはこの書籍と相反する部分もあります。しかしながらプログラムコードレベルでの設計の話もあるためRailsのレールで高速にプロダクトコードを書きつつ、一定の変更のしやすさを作り上げることができるテクニックは紹介されていると感じています。

名前重要と単一責任原則

この書籍内でも紹介されているが、Rubyは静的型付け言語や他の動的言語と比べても自由度が高い言語のため、クラスをたどるためのコードジャンプが苦手な言語となっています。

ただこちらの本は様々なシーンで名前の重要性を説いており、また単一責任原則に関しても度々登場します。そのためこの本で紹介されている名付けや単一責任原則を意識すると名前が洗練され良い意味で名前のかぶりが減るのでコードジャンプの恩恵が受けやすくなり、変更時の把握がしやすくなるという効果も期待できると思われます。

Railsだと理解しづらいモデリングの部分

従来のモデリングは「アプリケーション上の課題に対して扱い易くするためのオブジェクトのモデリング」であり、この書籍で取り上げられているモデリングもそちらに類するものと思っています。

ただ、RailsだとどうしてもActiveRecordがあるため、この書籍で取り上げられているようなモデリングがどうしてもデータと一体化して考えてしまう。またRailsがキャリアスタートの場合「Model=データベースのテーブルから成り立つもの」という理解をしている可能性もあるので余計に「モデリング」がわかりにくいかなと思います。

そのためモデリングの部分に関してはRailsのActiveRecordの性質を理解した上で読み直すと良い部分かと思っています。また、そこがわかるとオブジェクトとしてのメソッドの選り分けかたも洗練されるのではないかと思います。

なお、ActiveRecordの性質を理解するにはこちらが大変参考になると思います。

参考/関連リンク

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

Amazon

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

Amazon

W3Cのpotentially trustworthy URL (信頼できるかもしれないURL）の定義に関して調べる

ざっくりまとめ

CORS関連のフレーズを調べているときにW3Cでよく出てくる potentially trustworthy URL というフレーズについて調べる

定義

W3Cの「 Secure Contexts - 3.2. Is url potentially trustworthy?」曰く以下の通り

A potentially trustworthy URL is one which either inherits context from its creator (about:blank, about:srcdoc, data) or one whose origin is a potentially trustworthy origin. Given a URL record (url), the following algorithm returns "Potentially Trustworthy" or "Not Trustworthy" as appropriate:
1. If url is "about:blank" or "about:srcdoc", return "Potentially Trustworthy".
2. If url’s scheme is "data", return "Potentially Trustworthy".
3. Return the result of executing §3.1 Is origin potentially trustworthy? on url’s origin.

機械和訳ミックスすると以下のとおり

potentially trustworthy URLとは、作成者からコンテキストを継承しているもの（about:blank、about:srcdoc、data）、またはその起源が潜在的に信頼できる起源であるもののことです。URLレコード（url）が与えられると、以下のアルゴリズムにより、"Potentially Trustworthy" または"Not Potentially Trustworthy" に切り分けられます。
1. "about:blank" か "about:srcdoc" は 、"Potentially Trustworthy"
2. URLのschemaが"data"であれば "Potentially Trustworthy"
3. 1と2のいずれでもない場合はURLのオリジンを「 §3.1 Is origin potentially trustworthy?」で判断した結果に依存する

§3.1 Is origin potentially trustworthy? について

こちらはURLのorigin(URLのscheme,host,port番号のワンセットの組み合わせ)の信頼できるかもしれない判定のロジック。W3Cのこちらに判断ロジックがある。こちらは"Potentially Trustworthy" か "Not Trustworthy" のいずれかが決まる。以下W3Cより意訳抜粋

  1. originが無効なオリジン(opaque origin)の場合は "Not Trustworthy"
  2. originが tuple origin であること
  3. originのschema が "https" or "wss" であれば "Potentially Trustworthy".
  4. originのhostがCIDR表記での127.0.0.0/8 または ::1/128の場合は "Potentially Trustworthy"
  5. Let 'localhost' be localhost. のルールに準拠している状態かつoriginのhostが localhost、localhost.、あるいは末尾が .localhostか.localhost. の場合は"Potentially Trustworthy"
  6. originのschema が "file" であれば "Potentially Trustworthy"
  7. originのschema が アプリケーションが問題としないものである場合(例：Chromeの chrome-extension: など）は "Potentially Trustworthy"
  8. origin が信頼できる originとして他の部分で設定されている場合、"Potentially Trustworthy"
  9. 1から8の条件で判断がつかないものは "Not Trustworthy"

上記を加味してざっくりと整理する「potentially trustworthy URL」とは

厳密な定義は上記のとおりだが、ざっと信頼して問題ないの判断ポイントとしては以下

  • localhost、ループバックアドレス、about:blank、などの特別な定義のURL
  • data , file のschemaではじまるURL
  • アプリケーション独自の定義済みschemaとして設定済みのURL
  • WebSocketの場合のschemeの wss のURL
  • httpsのURL

関連リンク

日本語のローマ字表記に関してシステムを作るときの知識をざっとまとめる

ざっくりまとめ

おおまかに3系統あり、ISO3602をベースに考えればよさそう、というのをざっとまとめる。

ローマ字の系統

ローマ字の系統はいくつかおあるが、代表的なものは3系統ある

訓令式

2022年現在においてはベースとなる方式で、政府がローマ字のつづりに関しての告示を出した際にもこの記法で使うよう明示されている形式。

a,i,u,e,o をベースに ka,ki,ku,ke,ko という形で母音のアルファベットとくっつける形式

歴史的には後発であるため、日本式とヘボン式のアレンジとして定義した形式となる。

日本式

日本にてローマ字を普及させる際に日本人が提唱した形式。訓令式と差異がある部分は以下の通り。

  • だ行の「だ」以外に関しては z ではなく d の形式で表現する（「ぢ」を di、「ぢゅ」 dyu）
  • 「を」をo ではなく wo と表現する。

修正ヘボン式

ヘボン式はローマ字の元祖であり、1867年にアメリカの医療伝道宣教師、ジェームス・カーティス・ヘボン氏が定義したことからヘボン式とされています。このヘボン氏が提唱したヘボン式を「旧ヘボン式」とし、訓令式が出されたと同時期の1954年のタイミングにヘボン式の見直しがあり、その見直し後のものを「修正ヘボン式」と呼ばれている。

国際的にはこの修正ヘボン式がスタンダートに使われており、イギリスやアメリカなどではこちらの形式をデファクトスタンダードとして使われている。

訓令式との違いは以下

  • さ行の一部、たとえば「し」を si ではなく shi のように hを含む形で表現する。
  • ざ行の一部、例えば 「じゃ」 を zya ではなく ja のように j で表現する。
  • た行の一部、たとえば「ち」を ti ではなく chi のように hを含む形で表現する。
  • 「つ」を tu ではなく tsu と表現する
  • 「ふ」を hu ではなく fu と表現する

どれを使うといいのか

2022年現在では統一された唯一1つの規格があるわけでもなく、それぞれの形式で現実世界の使われかたとして物足りない部分が出てくるため、どれか1つベストなものを選ぶということではなく、適宜ミックスして使う形となる。

ただISO3602では訓令式をベースに定義をされているため、ISOに準じるのであれば訓令式を基礎として考えるのが良いと思われる。ISO3602は訓令式をベースにしつつわかりにくいところをいくつかアレンジを加えている。例えば「を」に関しては原則は o の表記が訓令式のルールだが

「を（ヲ）」は直接目的語を示す助詞としてのみ wo を用いる。ローマ字では o と書く。

というように「お」と「を」の表記の使い分けを分けている。

関連リンク

Kaigi on Rails 2022 で『とりあえず抑えておきたい Railsでの「テストの内容」の考えかた』という内容で登壇してきました。

登壇

Kaigi on Rails 2022で発表してきました。

発表したスライド

speakerdeck.com

こちらで動画も見れます。

伝えたかったこと

  • テストコードってそもそもなんで書くんだっけ？となりがちなのでそれを改めて整理したい
  • テストコードに書くべきケースの見極め方を紹介したかった

補遺編

今回のプロポーザルを作ろうと思った動機

昨年、割と初学者向けの発表が少なかったということで今年も「初学者向けになにか伝えたいことないかな」と思ったときに、ちょうどアジャイルテスティングのことを業務的に考えることがあったので、それを題材にしたくて取り上げました。

Railsを扱う人の間では、はRSpecをいかに運用しやすく書くか、ということには様々な人がとりあげていると思います。ただ、扱いやすいテストケースの書き方がわかっても、具体書くテストケースがちゃんとしているものでなければ意味がないものになってしまいます。

そのような「自動テストの文脈でちゃんとシステムに活きるテストコードとはなにか」という説明をする資料が意外とないのでそれを軸にプロポーザルを構成して応募しました。

資料を作成するに当たり参考になった資料

今回テストの考え方を調べるにあたり大変参考になったのが以下のnoteです。

ASTERセミナー標準テキスト｜Kouichi Akiyama｜note

ソフトウェアテスト技術振興協会（ASTER） の標準テキストに沿ってテストの考え方を紹介しているnoteの記事なので体系的なものをベースに噛み砕いた解説となっており非常に読みやすかったです。

もっと紹介したかったが時間におさまらなかった手法

テストケースの作成方法としては同値分割法と境界値分析をメインに紹介しました。これはこれで知らない初学者の人はもちろん、なんとなく体得してきた人たちも改めて学び直す事ができるような資料にまとめました。

が、本当はもっと異なる手法も紹介したかったのですが、どうしても15分には収まらなかったので今回は削りました。断片的ではありますがブログにはまとめたのでご興味のある方は以下の記事をどうぞ

登壇後記

  • 去年以上に時間がなく、2日目の登壇だったのでかなりギリギリまで修正をしていました。前半はかなりガラッと修正しました。
  • 2日目の最後なので皆さん疲れているだろうということでライトな内容を心がけました。
  • 反面やっぱり反応があんまりないので終わってしばらくは手応え無かったんですが、懇親会で良かった旨の感想をいただけたのでよかったです。
  • Twitterにも書いたのですが、テストケースの考え方は諸派あるので、色々出典を取りまとめるのにすごいパワーがかかったというのがありました。
  • 実は登壇資料のカラーはユニバーサルカラーデザインを参考にした
  • t_wadaさんの発言をt_wadaさんスライド風に引用をしてみたがあんまり気づいてもらえなくて悲しかった

今回この登壇に役立った書籍

Software Design (ソフトウェアデザイン) 2022年03月号 [雑誌]

Software Design (ソフトウェアデザイン) 2022年03月号 [雑誌]

Amazon

ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～

ソフトウェアテスト技法練習帳 ～知識を経験に変える40問～

Amazon