2018/12/17 気になった記事まとめ
特に書くことがないときの日課です。 今年もあと数日出勤すれば終わりという現実が見え隠れしており、一年すぎるのマジ早くなったなーと感じる次第です。(´・ω・`)
アカウント削除をどう考えるのか
意味がない、という記事。実際にはデータの保持義務なりいろいろあるので、完全削除は現実難しいですな。論理フラグが良い、実削除が良い、と色々意見がある話ではあるのですが、一番は、
ユーザーは退会してどうなってほしいのか?
を真っ先に考えることですかね。サービスなりシステムを提供している相手が一番メリットを感じられることをやることを目指しましょう、というのが私の考え方です。
なので、自分なら
- 決済履歴等、保持義務があるものはそのまま保持
- 保持期限なくても、後から返金できるか?みたいな問い合わせくることあるのでつらい
- サービス利用に関わる情報で個人が特定できる情報をマスクして、履歴を別ディスクに退避(例えばS3)
みたいにやるんじゃないかなーと考えてます。
Non-attribute arguments will be disallowed in Rails 6.0
えっ?
この記事で知りました(´・ω・`) 記事の内容より、タイトルで上げたことが気になって仕方ありません。あんまり使ってる所ないとはいえ、全部書き換えるの面倒だなぁ_(:3」∠)_というお気持ちに。
記事の本文についてですが、結論、SQLインジェクションを防ぐために、paramsの値を直接where条件に突っ込むのやめましょうねーって話だと認識してます。
入力値は必ずFormオブジェクトを作成してvalidationし、そこから引っ張る形を取るようにしています。あとでテストも書きやすいのでおすすめです。
class xxxForm include ActiveModel::Model include ActiveModel::Attributes attribute :aaa, Integer attribute :bbb, String validates :aaa, presence: true, numericality: {only_integer: true, greater_than_or_equal_to: 0} validates :bbb, presence: true def initaialize(**params) params.each {|k, v| send("#{k}=", v) } end end # controller if (form = xxxForm.new(params)).invalid? raise InvalidParamError(form.errors) end
多分こんな感じ(動かしてない)
キモは事前に入力値を検証して正しいものだけ通す。これができていれば後工程で雑に扱ってもある程度は防げると思います。ただし、文字列をActiveRecordの条件式にする場合はちゃんとplaceholder を使いましょう(´・ω・`)インジェクションこわい
機械学習のコスト計算で考えたいこと
学習はGPUほぼ必須なのは理解していましたが、学習結果を元に推論するだけならCPUで十分いけるんですね、という学びがありました( ・`ω・´)
それにしても1500万/yearの削減は凄まじいですね。わりとコスト計算おざなりになりがちなので、必要十分な性能をうまく見極められるスキルがほしいですねー(´・ω・`)
トランザクションとか、クラッシュ時対応とか、胃が痛くなりそうな設計
個人開発であれば、この内容でも、まあ動くとは思います。自分はやりたくないけど。
バックアップとかどうしてるんですかねー。巨大なしかも書き込みロックされているcsvをまんまコピーとか、タイミング次第では地獄を見そうな予感しかしないんですが_(:3」∠)_
とあるユーザーの決済履歴の一覧を表示させたいとして、どうやって探すんでしょうかね。全文検索ですかね。
と、いろいろつらみを感じさせそうな設計。何事もなく運用できることを祈ってあげたいお気持ちです。