curl -L 'https://example.com'
curl -H 'User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 14_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1 Mobile/15E148 Safari/604.1' 'https://example.com'
curl \
'https://example.com' \
-w '\n%{http_code}' \
-o /dev/null -s
この記事はLCL Advent Calendar 2021 - 18日目です。
こんにちは、 id:kasei_san です。
皆さん、技術情報の情報収集どうしてますか?
昔はLiveDoorReaderとか、はてなブックマークとかで集めれば割と良かったのですが、RSSがオワコンになり、はてなブックマークも(個人的には)ノイズが多くて使いづらくなってしまい、どうしたものかと考えています。
今回は、かせいさんの試行錯誤中の情報収集方法を晒して「みんなどうしてる?」という意見を伺いたくて、記事を書いてみました。
なので、「自分はこうしてるよ!」とか「こうしたらどう?」とかあったら、コメントなりはてブなり、引用RTなりで何かフィードバックいただけると嬉しいです。
それではどうぞ
だいたいこんな感じで、AWSやRuby/Railsをメインに情報を収集しています。後でそれぞれの詳細について解説しますね
なんやかんやでまだ生き続けているRSSも購読しています。
重要度が低いものは、feedly で暇な時にチェックして、 重要度が高いものは、slackの自分の分報チャンネルに出るようにしています
速報性ではなんやかんやここが一番ですね。 自分のやっている分野の本を書いたり、アウトプットを良くしている人、AWSの中の人などを 350人ほどフォローして います。 AWS障害とか、最近だとLog4Shellみたいな大きなできごとがあると、話題が何度も上がってくるので、見落としが無いのが良いですね。
log4j の件ようやく NHK が取り上げるくらいのニュースになったけど、それまで気付いてない人達もいただろうし、ほぼ第一報に近かったという意味でエンジニアが Twitter やるのは必須だし避けられないな。これは仕事だよ仕事。
— mattn (@mattn_jp) 2021年12月14日
仕方ないですね!
こちらも速報性は高いです。Ruby以外にも、AWSの障害やセキュリティインシデントなども話題になるので、Rubyのwebエンジニアやっていて必要なニュースは割とここでキャッチアップできます。あと、Rubyで開発している企業blogの更新を通知してくれるチャンネルもあるので、ここでの情報キャッチアップもなかなか良いです。(弊社LCLも参加しています!)
AWSの中の人などがやっている、毎朝平日9時に開かれる twitter スペースです。前日に更新された内容を30分ですごい勢いでキャッチアップしてくれるのを仕事をしながら聞いています。各サービスについてどういう場合に使うものなのかとか、マイナーなサービスの場合、これはどういうものなのかも解説してくれるので、単に更新を見るよりも理解しやすくて、助かっています。
現状はだいたいこんな感じで、Ruby/Rails/AWSの情報を集めています。収集先が多すぎても見なくなってしまいますし、少なすぎてもキャッチアップしきれないのでなかなかバランスが難しいですね。RSS以降の世代の人はどんな風に情報収集しているのか気になっています。ぜひ「自分はこうしているよ」とかありましたら教えていただければ幸いです。
それでは!
これの続き
複数のオリジンからクロスドメインのリクエストを受けるサーバが Access-Control-Allow-Origin を返す場合、オリジンごとに異なる値を動的に返す必要がある。
途中にCDNが挟まってる場合、Access-Control-Allow-Originが、最初に来たオリジンのままで固定されてしまう。
これにより、Access-Control-Allow-Originの値と異なるオリジンからのリクエストがすべて、CORSエラーになってしまう。
レスポンスヘッダに Vary 'Origin' を追加する。
キャッシュ時にURL以外に、キーとなるリクエストヘッダの値を決める設定。
例えば Vary : Accept-Language とすると、同じURLでも、言語ごとにキャッシュされるようになる。
んで、Vary 'Origin' の場合、Origin がキーになる。
Origin は、クロスドメインのリクエストを投げた場合に、元々のドメインが格納されるリクエストヘッダ。
そうすれば、複数オリジンからのリクエストごとに、異なる Access-Control-Allow-Origin を返すレスポンスをそれぞれキャッシュできる。
Access-Control-Allow-Origin の値が ("*" ワイルドカードではなく) 具体的なオリジンであるレスポンスをサーバーが送信する場合、レスポンスには Vary レスポンスヘッダーに Origin という値を設定して、 Origin リクエストヘッダーの値によって値が変わることをブラウザーに対して示してください。
$ echo|openssl s_client -connect helloworld.letsencrypt.org:443 -servername helloworld.letsencrypt.org
Verify return code: 20 (unable to get local issuer certificate)
R3 --> ISRG Root X1 --> DST Root CA X3 となっているDST Root CA X3 が 2021/09/30 に期限切れとなったISRG Root X1 と DST Root CA X3 が入っているが OpenSSL 1.0.x では、 証明書チェーンの中に「トラストストアにあるが期限切れ」の証明書があると検証が失敗扱いになる という挙動があるDST Root CA X3 から ISRG Root X1 に変更しようとする流れDST Root CA X3ISRG Root X1 に変えようとしていたISRG Root X1 が無いため、中間証明書を DST Root CA X3 と ISRG Root X1 のクロスサイン証明書にしていた(これにより、どちらかがトラストストアにあれば検証が通る)DST Root CA X3 の期限が切れるため、ルート証明書を ISRG Root X1 だけにする動きが始まるR3 --> ISRG Root X1 --> DST Root CA X3
👇 Let'sEncrypt による、OpenSSL 1.0.x では Android互換チェーン の検証に失敗する件の記事
OpenSSL公式は、トラストストアにて、期限切れのDSTのルート証明書を削除するようにと、アナウンスしている
https://t.co/bL7HmxKqcr?amp=1 www.openssl.org
AWS(EC2)では、ルート証明書のyumパッケージである ca-certificates にて、上記の対応を済ませたバージョンを配布しているので、yum update ca-certificates すれば解決する
AWSでは、さらにこちらで手動対策方法もアナウンスしている
どうしても古いままの環境をいじらざるを得ない時ありますよね...
FROM centos:6 RUN \ sed -i -e "s/^mirrorlist=http:\/\/mirrorlist.centos.org/#mirrorlist=http:\/\/mirrorlist.centos.org/g" /etc/yum.repos.d/CentOS-Base.repo &&\ sed -i -e "s/^#baseurl=http:\/\/mirror.centos.org/baseurl=http:\/\/vault.centos.org/g" /etc/yum.repos.d/CentOS-Base.repo RUN yum -y install \ git \ bzip2 \ gcc \ openssl-devel \ readline-devel \ zlib-devel RUN git clone https://github.com/rbenv/rbenv.git ~/.rbenv RUN git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build RUN echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile RUN echo 'eval "$(rbenv init - bash)"' >> ~/.bash_profile RUN \ source ~/.bash_profile && \ rbenv install 2.7.4 && \ rbenv local 2.7.4 RUN yum -y install wget
vault.centos.org をリポジトリの参照先にするsource ~/.bash_profile する必要がある。これどうすれば省略できますかね👆 DHHによる、「Rails 7は、2021年以降のJavaScriptに対する3つの素晴らしい答えを出すだろう」 の翻訳記事
Railsは当初からフルスタックである。
Rails 7では、JavaScriptに3つの明確な選択肢が用意されている Hotwireとimport mapsを使ったデフォルトの道。 人気のあるJavaScriptバンドラーの1つとの薄い統合を使った代替の道。 そして最後にフロントエンド用の別のリポジトリを使った厳格なAPIの道。
最後に、Railsを単にAPIとして使用するという選択肢もある。 それを利用するSPAは、まったく別のプロジェクトとリポジトリに置いておく。 Railsは長い間、--apiでこの道をサポートしてきて、これからもそうしていく。 小中規模のチームにはお勧めできない方法だが、フロントエンドとバックエンドの間に高い壁を設けてSPAを作ることに専念している大規模な組織の中にいる場合は、意味のある方法かもしれない。
StimulusやHotwireなども少し学習で触りましたが、それなりに学習コストがかかるので、Rails7の上でDHHが推しているJavaScriptの書き方でやっていくと、「Railsの上ではJavaScriptが書ける」みたいな状態になりそうに思います。
DHHの推奨するRailsでのjsに特化しちゃうとキャリアが狭まりそうだよねというのはすごく分かる
View層においてJavaScriptのFrameworkもしくはコードの比重が増えていくとともに、バックエンドまで一気通貫で同じ言語を使用できればいいのにという思想からか、加えてRailsとモダンフロントエンドとの相性がよくないからか、Railsの出番は今後減っていくだろうという意見に対しての賛同が増えてきているのを感じている。
今のトレンドである(と思われる)リッチなUXを提供するには、Railsは無用なものになってしまうのでは? という危機感の記事
Rails のフロントエンド周りは限界 Rails は文化的にパフォーマンスに対する指向を持たない ActiveRecord の賞味期限は Rails と同じ 型による大規模化への伸びしろの有無が決定的な差になってきた
👆 Railsはスケールしない個人開発レベルのプロジェクトで強みが活かせるというお話
スケーラビリティが不要なアプリケーションをスモールチームで開発するためのフレームワークがRails
そこ(個人開発の場)では「フロントエンドの最適化」よりも「いかに仮説を検証するか」が重要であり、Railsが提供する高速な開発が重要な意味を持ちます。Railsのエコシステムにより各種実装を省略できることもまた重要です。
Railsに欠けているものは詰まるところ「段階的なスケーラビリティ」に尽きるのではないかと私は考えています。
bundle install が手間ですよね...sleepwatcher という、sleep & wakeup 時に任意のコマンドを実行するアプリを使います
また、google アカウントは、 https://accounts.google.com/Logout にアクセスすると、ログアウトできるので、スリープ時に、デフォルトブラウザで、これにアクセスさせます
brew install sleepwatcher brew services start sleepwatcher
sleepwatcher は、スリープ時に ~/.sleep を実行してくれます
cat <<EOS > ~/.sleep #!/bin/sh open https://accounts.google.com/Logout EOS
実行権限も忘れずに
chmod +x ~/.sleep
以上で、スリープ時にgoogleアカウントからログアウトできます
sleepwatcher はだいぶ長いこと更新されていないので、使用は自己責任で
退勤時にgoogleアカウントからのログアウトする会社ルールができたので作ってみました