selmertsxの素振り日記

ひたすら日々の素振り内容を書き続けるだけの日記

自プロダクトのRailsコーディング規約

参考図書

みんなでコーディングする上で、共通知識とする書籍を決める。

  • リーダブルコード
  • Object Oriented Programing in Ruby
  • Perfect Ruby
  • Effective Ruby

Service Objectsは使わない

理由としては、チームみんなで理解してやってくには難易度が高すぎるため。 基本的に app/models 下に置く。まずは、Object思考でちゃんとやれないか考えてみる。

https://www.netguru.co/blog/service-objects-in-rails-will-help

一つのテストの中で、expectを書きすぎてはいけない

何をテストしたいのかわかりにくくなるため。

https://github.com/reachlocal/rspec-style-guide#the-one-expectation

ActiveRecord standardのassociations, validations, or scopes はテストしない

これらのテストをすることは、ActiveRecordのmethodをテストしていることと同じであるため

https://signalvnoise.com/posts/3159-testing-like-the-tsa

でも、正規表現とかバリバリ使ってます!って話ならやってもいい。

Railsの controllerにて、before_action等でインスタンス変数のセットをしないこと

DRYに見えるかも知れないけれども、 viewにどのような変数を渡すのか判別が難しくなるので禁止。

Migrationの中でDBへのinsertをしてはいけない

たとえば、User.create(name: "hage") という形でレコードを追加する migrateがある。 その後、user table に対して、age カラムをnullや空文字を許容しない形で追加しようとすると、 migrate:reset 時に必ずエラーが出てしまう。

よって、以降の変更に制限を加えるコードになってしまうため、migrateの中での insertは許容しない

Rails のViewの中で、Databaseへのアクセスはしてはいけない

MVCの概念から考えても良くないし、queryが発行される場所を制御できなくなるため、 パフォーマンスチューニングが必要なときに難しくなるので。

ロガーを使わない程度のメッセージ標準出力には p ではなく puts を使う

MySQLにおけるString型カラムはNULLを許容しない

  • string型にnullを許容すると、nullチェックする必要性が生まれる
  • nullチェックするコストは省きたい
  • nullチェックする必要があるカラムなのか、常に判断するのは難しい
  • よって、原則としてstring型はnullを許容しないようにする

定数はconfig/initializers/constants.rb 周りに置く

railsconfig にデータを保持させると、データを追加させたときに、みんな railsconfig を更新しなければならなくて手間。settings はコードに乗せてはいけない情報のみを扱いたい。

http://guides.rubyonrails.org/autoloading_and_reloading_constants.html#autoloading-and-initializers

ActiveRecord モデルが存在しない _id のカラム命名は都度検討する

_id で終わるカラム名は慣例的な経緯もあり、ActiveRecord モデルの存在を想起する場合がある。 一方で、外部システム連携時など、外部システム側で使用しているフィールド名 xxx_idカラム名としてそのまま採用した方が見通しよく把握できるケースも多い。

ここはチーム内で良く議論する必要がある。

ActiveRecord Callbackは使わない

class User
  after_create :send_mail
end

mailを送られるの気づかなくて爆死などを防ぎたい。 あと、factoryを作るのがツラくなる。そのときは便利に見えても、後々負債になるから禁止。

Queryは基本的にScopeで書く

※ これはプロダクト毎に意見が分かれる部分があると思うので、一概に適用はしないこと。

Rails上で発行されるQueryについて、全てModelに集約されていると、どのモデルでどのようなQueryが発行されているのか見通しがよくなる。同じ様な結果を得るために、似たようで微妙に異なるQueryが大量に生成される問題を避けることにも繋がるため、基本的に発行されるQueryはModelで参照できるScopeとして定義すること。

参考文献

GitHubで自分が作ったPRを追うためにTrailerが便利だった

モチベーション

GitHub上で、自分が管理していないリポジトリにPR投げると、その後どうなってるのか追い忘れることがあった。相手にとっても迷惑かなって思ったので、なんとかしたい。

結果

f:id:selmertsx:20180515203733p:plain 自分が作ったPRが見れる。便利

設定方法

1. Download

https://ptsochantaris.github.io/trailer/

ここからアプリをDL

2. リポジトリの設定

  1. リポジトリをwatchingにする f:id:selmertsx:20180515203704p:plain

  2. 通知するリポジトリの設定をする f:id:selmertsx:20180515203728p:plain

自分が管理しているリポジトリは PRもissueも全て表示するようにして、その他のリポジトリは自分がPR/Issueを作ったもののみ表示するようにした。 ( そのときに、該当リポジトリをwatchingにしておく )

Azure ADでDatadog(Connectorなし)のSSO設定を行う

最初に

Azure ADに DatadogのSSOを設定をしたい。 けれども、Datadog公式のドキュメントは2016年製で、微妙に設定内容が異なる。 https://help.datadoghq.com/hc/en-us/articles/216980686-How-do-I-configure-Azure-AD-as-a-SAML-IdP- なので、他のドキュメントも見ながら試行錯誤して設定したので、その履歴をここに残す。

手順

1. SSO Applicationの作成 【Azure AD】

  • ギャラリー以外のアプリケーション
  • 名前を付けてアプリケーションを登録

f:id:selmertsx:20180501195828p:plain

  • SSOを構成する
  • SSOモードをSAMLベースにする

f:id:selmertsx:20180501195836p:plain

2. Service Providerの設定を確認する【Datadog】

f:id:selmertsx:20180501195911p:plain

3. Id Provider側のSAML設定【Azure AD】

  • 識別子と応答URLを、SP側で確認したEntry IDとService URLのそれぞれの値で設定する

f:id:selmertsx:20180501195939p:plain

  • ユーザー識別子をuser.emailに変更する
  • SAML証明書発行ボタンから、Azure ADの証明書のXMLをDL

f:id:selmertsx:20180501200012p:plain

4. DatadogにAzure ADのSAMLを登録する【Datadog】

  • Datadogにて Azure AD側で作成したSAMLをupload
  • 生成されるSingle Sign-on URLにアクセスする

f:id:selmertsx:20180501200033p:plain

  • Datadogに対してSSOでアクセスすることが可能となる

注意

f:id:selmertsx:20180501200110p:plain

設定直後(10~15minくらい?)は、なぜかアクセスできませんでした。時間をちょっと置いてアクセスしたら問題なくログインできました。

参考資料

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-custom-apps https://docs.datadoghq.com/ja/guides/saml/

技術書展4に参加しました

技術書展にて、本を出す側で参加させていただきました。

techbookfest.org

TypeScriptを使って、AWS Lambdaを書く際の注意点などを記載しています。 実は、個人的に作っていたAWS Lambda製のchatbotについて記載したかったのですが、プライベートの諸々の予定と完全に被ったため時間が無く....今回は断念しました。次回こそは!

普通のLinuxプログラミング勉強会 9章 Linuxのディレクトリ構造

9.1 基本的な構造

ディレクトリツリーの標準規格であるFHS(The Filesystem Hierarchy Standard)に基づいて説明する

  • /: ルートディレクト
  • /bin: ブートするときに必要なコマンド (bash, ps, cp)
  • /sbin: ブート時に必要な管理者用コマンド (mount, reboot, ifconfig)
  • /lib, /lib64: ブート時に必要なライブラリ (libc.so.6とか)

9.2 /usrディレクト

基本的に複数のマシンで同じ環境を利用したケースがある。 そのときはNFSを使って、環境がインストールされているディレクトリをマウントする。

/usr/local/${package_name} にすると、管理には楽だがPATHを通すのが手間になる。

9.3 /varディレクト

/varは頻繁に書き換えられるファイルを置く。 /var/logとかがそれにあたる。

9.4 ルート直下の重要なディレクト

  • /etc: passwdやらmy.cnfやら、各マシン毎に必要な設定ファイルが置かれている
  • /dev: デバイスファイルが置かれている。
  • /proc: プロセスファイルシステム(プロセスをファイルシステム上に表現する仕掛け)がマウントされる。
  • /boot: Linuxカーネルのプログラム置き場
  • /tmp: 一時ファイル置き場。リブートしたら消える
$ sudo cat /proc/1/status
Name:   init
Umask:  0022
State:  S (sleeping)
Tgid:   1
Ngid:   0
Pid:    1
PPid:   0
$ file /boot/vmlinuz-4.9.77-31.58.amzn1.x86_64
/boot/vmlinuz-4.9.77-31.58.amzn1.x86_64: Linux kernel x86 boot executable bzImage, version 4.9.77-31.58.amzn1.x86_64 (mockbuild@gobi-build-64011) #1 SMP T, RO-rootFS, swap_dev 0x4, Normal VGA

「クラウドセキュリティ & プライバシー」読書メモ

目的

クラウド時代におけるIAMについて考える。

1章 クラウドコンピューティングの進化

産業時代、組織は電力を自給する必要があった。 電化によって、組織は電力を自給する必要がなくなり、 必要なエネルギーを必要なときに、必要な分だけ調達することが可能となった。 クラウドコンピューティングはまさしくこれと同じである。

2章 クラウドコンピュテーィングとは何か?

クラウドコンピューティングのためのSPIモデル

  • Software as a Service
  • Platform as a Service
  • Infrastructure as a Service

Software as a Service

これまでは、あるサービスを利用したい場合、Softwareを購入して自身のアプリケーション上で実行して、その結果を得ていた。 SaaSを活用すると、アプリケーションの管理やホスティングを自身で管理しなくても、そのサービスの恩恵を受けることが可能となる。 SaaSベンダーは、ソフトウェアのコピーなどを防ぐことができるというメリットもある。

Platform as a Service

ベンダーが開発環境自体をアプリケーション開発者に提供し、プロバイダのプラットフォーム経由でサービスを提供するもの。 細かいこと設定できない代わりに、アプリケーションの開発に集中させてあげるよ!って環境。 Herokuなどのサービスがこれにあたる。

Infrastructure as a Service

クラウドの基本要素から成るもので、ネットワーキング機能、コンピュータ、データストレージ領域へのアクセスを提供する。 リソースは渡すから自分でサービスを組み立ててねって印象。Amazon EC2やGCEなどがこれにあたる。

5章 Identity Access Management (IAM)

クラウドサービスを使うと、アンコントローラブルな領域がどうしても生まれてしまう。 その場合、セキュリティの強度を上げようと思ったら、アプリケーションセキュリティやユーザーアクセスコントロールなどを強くしなければならない。 その結果、二要素認証、アイデンティティ連携、SSO、ユーザ行動の監視・監査が重要になってきた。

IAMで重要なのは、集中的で自動化されたアクセスコントロールできるようにすること。 それによって、安全で効率化されたシステムを実現する。

IAMの定義

IAMではAAA(Authentication, Authorization, Auditing)の3つの要素が重要になってくる。

  • Authentication
    • ユーザーのシステムのアイデンティティを検証するプロセス
    • もっと簡単な言葉で言うと、通信の相手が誰か確認すること
    • 指紋などその人固有の情報や、パスポートなどの所有物、パスワードなどの知識を使って行う
  • Authorization
    • アイデンティティが確立されたときに、ユーザやシステムに与えられている特権を決定するプロセスのこと
    • とある条件に対して、リソースアクセスの権限を与えること
    • 駅で切符を買ったから電車に乗れるとかそういうの
    • 誰かに貰った切符で電車に乗るなど、移譲された権限を行使することもできる
  • Auditing
    • 認証のレビューおよび検査プロセス、認可記録、IAMシステムコントロールの妥当性を判断する
    • セキュリティサービスへの侵害を検知して、その対策を勧告する

この資料がよりわかりやすかった

https://dev.classmethod.jp/security/authentication-and-authorization/

IAMアーキテクチャ

IAMでは下記の運用アクティビティが存在する

プロビジョニング

ユーザーをシステムやアプリケーションにオンボーディングするプロセス。 ここでユーザーのロールや、アクセス可能なリソースの設定などの権限管理を行う。 これに対して、ユーザーに割り当てられた権限を剥奪することをデプロビジョニングと呼ぶ。

クレデンシャルと属性の管理

クレデンシャルとは、リソースにアクセスするために必要なものを指す。 例えばパスワードや、APIキーなどがこれにあたる。 クレデンシャルは、特定のユーザーにのみ結び付けられている。 属性とは、氏名、メールアドレスなど、ユーザーを一意に定めるために必要な情報を指す。

この資料を読みながら補足した。

https://dev.classmethod.jp/cloud/aws/iam-bestpractice-1/#toc-aws

エンタイトルメント管理

エンタイトルメントとは認可ポリシーとも呼ばれるもの。 リソースにたいしてユーザーがアクセスするために必要な権限のプロビジョニングとデプロビジョニングを担うプロセス。

コンプライアンス管理

アクセス権や権限は企業のリソースのセキュリティを確保するために、監視、記録がされている必要がある。 これにより、監査人が適切なアクセスコントロールポリシーを遵守しているか検証することもできる。

アイデンティティ連携(Federation)管理

Federationとは、ネットワークドメインを超えて確立された信頼関係を管理するプロセスのこと。 SSOを実現する際に役に立つ。 この機能を使うと、ユーザー情報を共有することなく、アイデンティティを連携することが可能となる。

認可と認証の集中化

認証・認可のためのインフラストラクチャを用意することで、開発者がアプリケーションに認証・認可機能を構築しなくて良くなる。 認証と認可の外部化とも呼ばれる。

学びまとめ

クラウドを活用する時代になって、IAMも変わってきた。

  • 安全・効率的にアイデンティティを連携したい
    • 認可・認証の機能を共通化させる
    • それによって、アプリケーション開発者は、認可・認証を気にせずにアプリケーション開発に集中できる
  • IAMでは認証・認可の他に Auditing という要素も重要になる
    • 認証・認可のログを取り、おかしなアクセスがあったら検知できるようにすること

JSとかRailsのログをWebPに変換してみた

概要

第4回SpeeeKaigiで、発表した資料です。 JSコードをWebPに変換してみました。

発表資料

speakerdeck.com

コード

github.com

参考資料

WebPの圧縮アルゴリズム

Compression Techniques  |  WebP  |  Google Developers