Railsでparamsの値を処理するときによく使われるので、どういうものがあるかを一覧で整理する
class NilClass (Ruby 3.2 リファレンスマニュアル)
| メソッド名 | 変換されるクラス | 変換後の値 |
|---|---|---|
| to_i | Integer | 0 |
| to_s | String | "" (空文字) |
| to_a | Array | [ ] (空配列) |
| to_h | Hash | { } (空ハッシュ) |
| to_f | Float | 0.0 |
| to_c | Complex | (0+0i) |
| to_r | Rational | (0/1) |
to_param も使えるが、その場合は nil がまま返される。BigDecimal があるが、BigDecimal(nil) はエラーになる。法人でApple Developer Programに登録するときに必要らしいのでざっくり調べる
D-U-N-SはData Universal Numbering Systemの頭文字を取ったもので、企業コードの管理システムのことを指し、D-U-N-Sナンバーはそのシステムから振り出されたナンバーのことを指す。もともとはDun & Bradstreet(D&B)社が発行している番号だが、ISOやANSIなどの標準化団体でも公式に使われる番号のため広く使われている。なお読みはダンズ。
システム開発の分野においてはAppleやGoogleのストア申請、SSL証明書などで使われる。
日本では東京商工リサーチがD&B社と業務提携をしており、振り出しを含めた管理業務を行っている。
D-U-N-Sナンバーは9桁の番号となっており、日本の場合は東京商工リサーチのホームページから取得ができる。自社の番号の取得は申請を行えば無料だが、他社の場合は有料となる。そのためお金さえ払えば誰でも番号の照会自体は可能となる。
2023年夏時点での連携方法をまとめる
現時点だと簡単にAppを登録することができるので、Slack連携をする。イメージは以下。
なお、App連携はワークスペース全体に関係する部分なので、会社で管理している場合は追加に課題感が内科を問い合わせてから利用すると良いと思います。
連携が終わるとAppのところに GitHub が追加されます。
特定リポジトリをSlack通知させたい場合は、通知を流したいチャンネルで以下のコマンドを打つ。
/github subscribe {{オーガナイゼーション名}}/{{リポジトリ名}}
例えば私が所有するブランチだと以下。
/github subscribe shinkufencer/demodemo_demo
なお、リポジトリ側にSlackとの連携がされていない場合は案内の通知がくるのでそれに従って登録する。
成功すると連携できた旨が表示される。
デフォルトでは issues, pulls, commits, releases, deployments の項目のみ通知が来るため、issueのコメントやreview、branchの操作も通知したい場合は
/github subscribe {{オーガナイゼーション名}}/{{リポジトリ名}} {{追加対象}}
で追加できる。issueコメントの通知を追加したい場合は以下
/github subscribe shinkufencer/demodemo_demo comments
追加できる対象はドキュメント参考のこと。
自分自身にまつわることを通知させたい場合はのGitHubのAppから自身のアカウントを連携させます。Connect on GitHub Account をすると連携画面が出てきます。順に進めると最後に連携用のコードが出てくるので、コードをコピペし、Enter Code でコードを入力すると連携が成立します。
連携が成立するとリマインダーの設定ページ で設定ができるようになる。
こちらではOrgnization単位で、どこのSlackのワークスペースで、どう通知させたいかを設定することができる。
大きく2種類あり
が設定できる、いずれもSlack上ではGitHubのAppで流れる。
フレーズは聞くがどういうことかはわかっていないのでざっくりまとめる
Emailは実際のプロトコル上で取り扱われる宛先情報とメール本文に書かれる宛先情報があり、前者のプロトコル上で取り扱われる宛先を封筒に記載される宛先に見立ててenvelope-from (エンベロープFrom） と呼ばれ、校舎のメール本文に添えられるアドレスを header-from （ヘッダFrom）と呼ばれる。
ヘッダFROMに関してはメール送信自体では使うものではないので、エンベロープFROMと異なるアドレスをつかっても問題がない。そのためこのヘッダFROMをエンベロープFROMと全く関係ないものに変更してなりすますということが可能になる。
SPFは”heder-fromに指定したメールアドレスのドメイン”を持つDNSサーバに対して、"メールの送信元サーバの情報"を記述することで、受信側がDNSを通して適切なメール送信サーバから配信されたメールかを確認できるようにする取り組みです。
具体的にはDNSサーバのTXTレコードあるいはSPFレコードに規定のフォーマットに沿ってIPを記述する。
DKIMは公開鍵/秘密鍵のペアを用意し、秘密鍵でメールに電子署名化した内容を含め、DNSサーバに公開鍵を設置することで、受信した側は暗号化されたメールの情報が公開鍵を使って復号した情報が適切なものかを検証することで確かめる方式です。
具体的には送信メールにヘッダや本文を秘密鍵で暗号化舌情報として DKIM-Signature を含め、受信側はその送信メールアドレスのDNSにある公開鍵を使って DKIM-Signature の情報を復号化して内容検討を行うというものになる、
SPFやDKIMは「なりすましメールかを検証する仕組み」だったが、DMARCは「DNSへ問い合わせた情報を使って照らし合わせた結果、検証が失敗したときの振る舞いをどうするか？」というものになっている。そのためこの情報はDNSサーバに設定され、DNS上で「認証に失敗したらメールを隔離して欲しい」という意思表明をすることができる。
この仕組みは受信側のさじ加減で行われている迷惑メール分担処理などを明示的に送信側が意思表明するための仕様として存在している。
名前は聞くがどういうものか把握していないので、ざっくりサマリとして理解する。
Googleが提唱する仕組みで、今現在Cookieを利用してトラッキングや個人情報が容易に取得できてしまう状況を改善すべく考えられた概念。公式サイトから説明を抜粋すると以下。
プライバシー サンドボックス イニシアチブは、ユーザーのオンラインでのプライバシーを保護しながら、デジタル ビジネスの成功につながるツールを企業や開発者に提供することを目的としています。プライバシー サンドボックスは、クロスサイトやクロスアプリの追跡を制限しながら、オンラインのコンテンツやサービスをすべてのユーザーが無料で利用し続けられるようにします。 - プライバシーサンドボックス: プライバシー保護を強化したウェブのための技術です
かなり抽象的な概念なのだが、ウェブ向けにはもう少し具体が書いてある、同じく抜粋すると以下
ウェブ向けのプライバシーサンドボックスは、サードパーティ Cookieを段階的に廃止し、隠されたトラッキングも制限します。新しいウェブ基準を策定することで、データのプライバシー保護を強化しながらデジタル事業の構築を可能にします - プライバシーサンドボックス: プライバシー保護を強化したウェブのための技術です
Googleの書き方だとわかりにくい部分は多いが、上記の表現を言い換えると「3rdPartyCookieで様々なプライバシー情報が提供されている現状のため、それを廃止する。しかしそれをしてしまうとトラッキング広告などのWeb広告の市場としては死活問題になってしまうので、3rdPartyCookieよりもプライバシーを守る形でWeb広告の仕組みを維持できるための活動」と解釈するとわかりやすいかもしれない。
このプライバシーサンドボックスを実現するためにいくつかのAPIをChromeで提供しようとしている大きくは以下のもの
1つずつざっくり見ていく
「アクセスしてきたのが本当の人間か、botなどの人間ではないものかわかるようにしたい」という旨のニーズが原点にある機能。公式ドキュメントの内容を噛み砕くと以下。
TrustToken を発行し、ユーザのブラウザに保存してもらう。（発行したサイトを発行者サイトという）TrustToken を持っているかブラウザに尋ねるTrustTokenがある場合は、そちらを利用し発行者サイトとやり取りをして本当にその人であるかを確認する。元々はTrustTokenという名前で展開されていたものなので、その名称で説明されているサイトも多い。
「ブラウザの閲覧情報からユーザの興味がある情報を第三者に渡したいが、プライバシーも守りたい」というニーズが原点にある機能。
予め用意された「トピックのリスト」があり、ブラウザは閲覧情報に基づいてそのユーザがどのトピックのサイトにアクセスしたかを記録する。その記録した情報をサードパーティは閲覧ができるのでそれらをつかってユーザへのコンテンツの出し分けなどを行ってもらう。このトピックの割り出しの仕組みなどはGitHubを参照のこと。
「広告主が再度同じユーザにアプローチをさせたいが、プライバシーを侵害したくない」というニーズが原点にある機能。いわゆるリターゲティングを行う仕組み。
いままではCookieを受け取り広告提供側が過去その広告に触れたことがあるかなどをチェックしながらリターゲティングを行っていたが、Protected Audience APIではいままでサーバ側に持たせていたそれらの仕組みをブラウザ上に移すことにより、広告事業者側に情報を渡さずブラウザでいままでの機構を代替しようとしている。細かい仕組みはGoogleのページを参考のこと。
なお、こちらも改名された機能で、いままでは FLEDGE と呼ばれていた仕組みではある。
「広告のクリック数などを計測したいが、プライバシーを侵害したくない」というニーズが原点にある機能。
広告のクリックや表示、サードパーティの提供するiframeの広告表示数などに関してブラウザを介すことで、サードパーティCookieを使わなくても実現することができる仕組み。具体としては関連リンク参照のこと。
「ドメインの異なるサイトだが企業としては同じサイトで、それらのサイトに関してログイン状態やセッションを維持する際に、プライバシーを守りながら実現したい」というようなニーズが原点にある機能。本来はサードパーティCookieを使って再現していたがそこを機能化している。
情報を共有するサイトであるかどうかは事前にFirstPartySetのリストへの追加を依頼することで実現する仕様として策定している。
ただし、この仕組み自体にには過去に反対意見もあり現在も議論がされている模様
「複数のサイトで区切りのないデータの受け渡しをしたいが、意図しない相手へのデータ漏洩はさせたくない」というようなニーズが原点にある機能。
サードパーティCookieで実現していた複数サイト間で共有するような情報を代替できる機能というところで、具体の実装例はGitHub にある。
「サードパーティCookieをトップレベルサイト別で扱うようにしてまたがないようにしたい」というようなニーズの機能。
AのサイトにCのサイトのiframe、BのサイトにもCのサイトのiframeのような実装のときに、AのサイトでCのサイトの某かを操作したかのサードパーティCookieの情報はBのサイトに移動したときにも取得できてしまう。このCHIPSはAのサイトでのCookie,BのサイトでのCookieにとそれぞれのサイトに情報を閉じ込めるような機能。
「iframeのように他のサイトの内容を埋め込みたいけど、埋め込み元には情報を取得できないようにさせたい」というようなニーズが原点の機能。
文字通り、フェンスのような機能で fencedframe で宣言した「埋め込まれたサイト」から「埋め込み呼び出ししたサイト」情報取得もできなければ、逆の経路の「埋め込み呼び出ししたサイト」が「埋め込まれたサイト：の情報も取得できない。
これら2つのサイトが安全かつ適切なデータをやり取りするためには前述のSharedStorageAPIやProtectedAudienceAPIを利用することが想定に入っている。
「ID連携でサードパーティCookieを使うような仕組みではないものに」というニーズもありつつ、全体としてIDプロバイダとそれを利用する側が安全にID連携できるようにするための仕様。
サンプル実装などの例を見るに、ブラウザの機能として介すことでシームレスかつ安全にID連携を行えるようにしている。
もともとはWebIDと呼ばれていたときもある様子。
「bash で rootログインしたい」などのときのための小ネタです。
$ docker -v Docker version 20.10.22, build 3a2c30b
-user オプションを使い、rootのUIDである0を指定して実行することでrootになる
以下はdocker-composeでappというコンテナにbashで入る場合
docker-compose exec -u 0 app /bin/bash
当たり前といえば当たり前の小ネタ
$ rails -v Rails 7.0.6 $ ruby -v ruby 3.0.5p211 (2022-11-24 revision ba5cf0f7c5) [arm64-darwin22]
hashのmergeメソッドは2つのハッシュを1つにまとめ、同じキー名のものをマージする。例えば以下のような動作。
hash = {a: 20, b: 30, c: 40}
merge_hash = {b: 100, c: 500}
hash.merge(merge_hash)
#=> {:a=>20, :b=>100, :c=>500}
hashのキーを文字列で定義することもできるので、その場合はマージされない。例えば以下のような例。
merge_hash_str = {"a"=> 20 , "b"=>100}
#=> {"a"=>20, "b"=>100}
hash.merge(merge_hash_str)
#=> {:a=>20, :b=>30, :c=>40, "a"=>20, "b"=>100}
自身で定義したhash同士をmergeするときはあまりこのような場面には遭遇しないが、Railsのparamsやgemのconfigをつかっているときなどは留意する必要がある。
もしRailsで対応する場合は symbolize_keys など使って揃えてあげると楽。
hash.merge(merge_hash_str.symbolize_keys)
# => {:a=>20, :b=>100, :c=>40}
