Tech Racho エンジニアの「？」を「！」に。
  1. TOP
  2. 開発
  3. 週刊Railsウォッチ（20190528-2/2後編）Lambdaのパフォーマンス統計、Jetsフレームワークの可能性、createapp.devは便利ほか
  • 開発

週刊Railsウォッチ（20190528-2/2後編）Lambdaのパフォーマンス統計、Jetsフレームワークの可能性、createapp.devは便利ほか

こんにちは、hachi8833です。ベッドで毎朝腹筋してたらスプリングがだいぶ凹んでしまいました。

  • 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ
  • 「つっつきボイス」はRailsウォッチ公開前ドラフトを（鍋のように）社内有志でつっついたときの会話の再構成です👄
  • 毎月第一木曜日に「公開つっつき会」を開催しています: お気軽にご応募ください

⚓お知らせ: 第11回公開つっつき会（無料）

第11回目を迎えた公開つっつき会は6月6日（木）19:30〜にBPS会議スペースにて開催されます。皆さまのお気軽なご参加をお待ちしております🙇。

⚓クラウド/コンテナ/インフラ/Linux/Serverless

⚓Lambdaのパフォーマンス統計でわかったこと（Serverless Statusより）

つっつきボイス:「これをやってるEpsagonという会社は何かな？（ググる）、なるほど、監視サービスの会社ですね↓: つまり自社サービスとかではなくて、この会社が面倒を見ている顧客のLambdaサービスについてのパフォーマンス統計について記事にしたということね☺️」「なるほど〜顧客データの統計ですか」「Epsagon自身がガシガシLambda関数を書いて運用しているわけではなさそう😆」


epsagon.comより

⚓メモリ設定


同記事より

「Lambdaはデフォルトだとメモリ128MBだけど、configゼロでやってる顧客が結構多いらしい」「これで足りることが多そうですね」「ちょろいLambda関数なら128MBで十分ですし☺️」「そしてLambdaで3GB使えるようになったのは割と最近なので、3GB使っている人は少ないのはワカル」「なるほど、前はそこまで上限取れなかったんですね」「そこから推測すると、32%を占める1024MBの人たちは、そのときそのときで可能だった最大メモリ設定でやってたんじゃないかな〜って😆」「対象期間が長いと歴史的な要素が入ってくるんですね」「128MBが多いのもその当時のデフォルトメモリ容量をそのまま使ってた人が多かったからではないかと想像してます😆」

⚓duration設定


同記事より

「300秒って結構長いな〜」「パーセンテージってあるけど何のパーセンテージ？」「あ、300, 10%とかあるのは300秒の人が10%って意味か😆」「並べて書かないで〜😭」「グラフにピークがあるのがちょっと不思議🤔」「それはたぶん実行時間制限で打ち切られたんでしょうね」「なるほど！」「きっとこれも上と同じように、Lambdaで設定可能な最大実行時間が時と共に増えてきているから、そのときそのときのデフォルト実行時間じゃないかしら」「そういうことか！」「記事にもそういう感じで書いてあるし😋」「そのときそのときで、設定を最大値にする顧客と、デフォルト設定のままで回す顧客に大きく分かれるんでしょうね☺️」

⚓言語

「使っている言語のグラフにもそういうのが表れてますね: Node.jsが一番多いのも、Lambdaで当初使えたのがNode.jsだけだったからでしょうし☺️」「Javaが少ないのも、後からLambdaで公式にサポートされたからなんでしょうし: そもそもLambdaのJavaはめちゃ遅いですけど😆」

⚓コードサイズ

「次はコードサイズのグラフ」「ん？これは下から上にコードサイズが大きくなってるのか😆」「ちょい紛らわしい😆」「コードのサイズは、ライブラリを使い始めるとすぐでかくなりますし😇」「Javaなんかも勝手にサイズ大きくなりますし😆」「JavaScript使ってればコードサイズはめちゃ小さくなりますね😋」「バイナリとかライブラリとかないし😆」

「ついでにLambdaをどこで使うかという話をすると、CloudFrontに付けるBASIC認証みたいなAWSのいろんなサービスに連携させる機能は、今だとLambdaでやるしかない」「そうなんですかっ！！😳」「CloudFrontはLambda関数との連携ができるんですが、逆に言うとBASIC認証なんかはそれを使うしかない🧐」「へ〜」

「なので、記事のコードサイズのグラフで1MB以下の小さいコードは、そういう感じの、アプリケーションよりもずっと小さな機能をLambda関数で提供しているんじゃないかなと想像しています」「その次の1〜5MBのコードもたぶん、AWS SDKあたりをちょっと使った程度のコードが多いんじゃないかな」「そして6MB以上のものは、PythonとかJavaみたいにライブラリが大きい言語が多そうな予感がしますね☺️」「たしかに普通コードベースだけで6MBはあんまりいかなさそう」

⚓VPC


同記事より

「VPCグラフ↑のw/って？」「w/がwithでw/oがwithoutのことでしょうね（略しすぎっ😆）」「VPCはAWSの仮想ネットワークなんですね」「グラフを見ると意外にVPC内でLambda関数を使ってる人いるな〜」

参考: Amazon VPC とは? - Amazon Virtual Private Cloud

「AWS Lambdaには、VPCの中に置くものと外に置くものと2種類あります: たとえばVPCの中で関数を作ると、そのVPCの中からしか関数を呼べないようになります」「ふむふむ」「たとえばバックアップバッチみたいなものはVPCの中に置く方が外からいじられなくなるのでよかったりしますね」

参考: AWS LambdaをVPC内に配置する際の注意点 | そるでぶろぐ

「LambdaをVPCの中に置くか外に置くかについてはこの辺の記事で説明されてますね↑: たとえばデータベース（AWS RDSとかEC2とか）と通信する場合はVPCの中に置かないといけないとか」「お〜なるほど！」「Lambdaにセキュリティグループを設定しないといけない、かつインターネット経由で通信しないなどの前提がある場合は、VPC内に置かないといけなくなります」「逆にAPI GatewayでAPIサーバーを建てるだけなら、VPCの外に置いても問題ない😋」

「以上を考えると、さっきのグラフのwith VPCの人たちは、おそらくDB接続が必要だったりプライベートなAPIにアクセスする必要があったりする人が多いんじゃないかと思います🧐」「そう思うとwith VPCの人ってそこそこいますね😳」「逆に、パブリックに公開するサービスやDynamoDBのようなAWS公式のマネージドなサービスに接続するだけのLambda関数なら、without VPCで構いません☺️」「な〜るほど！」

⚓実際のメモリ使用量


同記事より

「あれだけメモリを確保しておいても、実際に使われているのは平均で27%（65MB）だし😆」「右のp50って何でしょう？」「これは50パーセンタイルですね🧐: 先週のウォッチでも少し話したCDFに関連するヤツで、全体のうち下から50%は29MBしか使ってないと」「なるほど！」

⚓タイムアウト


同記事より

「割とタイムアウトしてるし😆」「左の関数のタイムアウトと右のinvocationタイムアウトって何が違うんでしょう？」「図だけ見ればですが、関数実行中に起きたタイムアウトと、関数の呼び出し自体がそもそも失敗したタイムアウトという違いじゃないかな〜🤔: Lambdaのドキュメント↓にあるInvocationというメトリクスを見た感じでもそれっぽい」

参考: AWS Lambda のメトリクス - AWS Lambda

「つまりLambdaの呼び出しは失敗することがあると😇」「関数の1割ぐらいはタイムアウトが起きたことがあると😆」「タイムアウトは別にLambdaじゃなくても、ネットワークに繋がっているものなら普通にありますけどっ😆」「なのでLambda関数は、失敗してもいいように必ず冪等に作るべきだし、タイムアウトも考慮しておくべきですね🧐」「ですね〜」

⚓アカウントごとの関数の数


同記事より

「これはEpsagonの顧客のアカウントだから、AWS Lambda全体ではないはず😆」「グラフの読み方としては『Lambdaをよく使う人はLambda関数が増えてゆく』というところでしょうね☺️」「お、このグラフはアカウント数が0からじゃなくて1から始まってるし: ということは、ここには『Lambda関数をまったく使っていないEpsagonの顧客』は含まれていないということかな？🤣」「おおっと🤣」「Epsagonの監視サービスがLambda専門かどうかだけど、雰囲気としてはLambdaがメインのようですね🤔」

⚓トリガー元


同記事より

「最後はトリガー」「これはLambda関数をどこから呼ぶかという話ですね」「おぉ？」「AWS Lambdaは単なる関数でしかないので、それ単体では何もできません: なので何らかの形で外からトリガーをかけて実行する必要があります」

「グラフで一番多いAPI Gatewayは、いわゆるHTTPリクエストをトリガーとして実行するヤツ」「ふむふむ」

参考: Amazon API Gateway とは? - Amazon API Gateway

「その次のSNSはSimple Notification Serviceという、AWSの中でも歴史の古い汎用通知サービスです: SNSにはいろんなイベントをsubscriberに登録できるんですが、そのsubscriberにいろんなトリガーを入れられる、要はpub/sub😆」「なるほど！」「たとえばsubscriberに『メールアドレス』を入れると、SNSイベントをそのメアドにメール送信したりできるんですが、それと同じようにLambda関数にSNS通知することもできます」「お〜」

参考: Amazon SNS（サーバーレスアプリのための pub/sub メッセージングサービス）| AWS

「グラフのCloudWatch EventsもSNSとまあ似たような感じですね☺️」

参考: Amazon CloudWatch Events とは - Amazon CloudWatch Events

「SQSはメッセージをキューイングするサービスで、このキューからLambda関数を実行するというのも割とよくあるパターン: たとえば画像のリサイズをSQSにぶちこんでLambdaでリサイズをやらせるとか」「ふむふむ」

参考: Amazon SQS（サーバーレスアプリのためのメッセージキューサービス）| AWS

「Kinesisはデータ処理系のサービスで、Hadoopと似てます」

参考: Amazon Kinesis（ストリーミングデータをリアルタイムで収集、処理、分析）| AWS
参考: Apache Hadoop - Wikipedia

「S3とあるのはS3のイベントトリガーですね」

「繰り返しますが、Lambda自体は単なる関数であって、たとえば画像処理の関数であっても、いろんな経路で呼び出せます」「たしかS3のイベントトリガー（ファイルを置いたらトリガーが発火するなど）を使えるようになったのは割と最近だったと思うので、それ以前は別のイベントでLambda関数を起動するというのがよく使われてて、そのときにSNSが経由場所になることが多かったんですよ」

「以前は直接LambdaをトリガーできなくてSNS経由とかならトリガーできるサービスが割とあったんですが、今はだいぶ減りましたね」「あー、それでSNSやCloudWatch Eventsとかがグラフで多いのかも？」「たぶんそういう歴史的経由がこのグラフに表れているんだと思います☺️」「今は直接Lambdaをトリガーできるサービスが増えたので、SNSみたいな経路を使うことはあんまりしなくてよくなったはず🧐」「ありがとうございます！学び多かった〜😋」

⚓Jetsのドキュメントが充実中


rubyonjets.comより

つっつきボイス:「リンク先のJetsドキュメント（ページ右サイドバー）が随分増えているなと思って取り上げました: ページの左はJetsの紹介記事とかです」「うん、ドキュメント結構ガンガン増えてますね💪」

「Jetsのドキュメントはさらっとひととおり読んでみたところなんですけど、そこでわかった範囲で言うと、実はJetsはWebサービスに限らず、RubyベースのLambda関数の管理ツールとしても使えて、そこがかなりいいと思いますね👍」「お〜」

「Eventsが普通にJetsで書けますし、JetsをWebサービスのフレームワークとして使わなくても、ちょうど『rails newするけどジョブしか使ってない』みたいに使ったっていいわけです😆」「そうでしたか！😳」「まだ手を動かすところまではやってないんですが、ドキュメントを読んだ限りでは、たとえばS3に置いてあるファイルを変換するだけのサービスみたいなものも書ける、そういう設計になっていると思いました😋」「何だかスゲー！」

「ただ、Jetsだといわゆるネイティブ系のライブラリを使うのは苦しいようです😢」「あ〜、C拡張のコンパイルが走るgemとかですね」「ライブラリによっては動かないものがあると思います」

⚓書籍『Web開発者のための大規模サービス技術入門』と『Linuxのブートプロセスをみる』

つっつきボイス:「はてなの中の人が10年前に出した『Web開発者のための大規模サービス技術入門』をこの間読んで、今の自分にとってかなり学びがあってよかったと思ったんですが、どうでしょう？」「ああ、これは10年前のソシャゲ全盛期の頃にかなり有名になった本で、データベースのシャーディングあたりの話はさすがに最近あまり流行ってないけど、それ以外は結構よくまとまってると思いますね😋」「よかった〜、外してなくて😂」「ほら、自分のAmazonページにもこの本の購入履歴が『2010年7月』って出てますし😆」「当時買ってたんですね😆」

「本ではオンプレのシステムを著者たちが学びながらメンテしているのが具体的でいいと思いました😋」「パフォーマンスチューニングで大事なローカリティの話とかはオンプレに限らず重要ですけど、この本ではそのあたりがひととおり網羅されているのがいいですね👍」

「『やはりOSとネットワークを知らないとだめだ』とか『アルゴリズムも重要だ』みたいな教訓も身に沁みました😅」「そりゃもう、パフォーマンスチューニングをするならOSとネットワークを知らなければ手も足も出ません😇」「何もわからないどころか、正解か不正解かすらわからない状態に陥りますし☺️」

「その意味ではこの本で扱っているようなことはここ10年であまり変わってないとも言えますね: 今後不揮発性メモリが台頭して再起動が一瞬で済むようになってきたりすると、アーキテクチャレベルのパラダイムが多少変わるかもしれませんが😆」

⚓OSのファイルキャッシュ今と昔

「そういえばこの本の中で、データベースをいきなり起動するんじゃなくて、データベースファイルをcatしてキャッシュに乗せてから起動するというテクニックが書かれてたんですけど、こういうのって昔から普通に行われてたんでしょうか？」「昔はむしろそれをやってませんでしたね: OSがファイルキャッシュを今のようにアグレッシブに使うようになったのは、割と最近になってメモリが潤沢に使えるようになってからのことなので」「あ〜そうでしたか！」「うんうん、そうですね☺️」「方法論としては昔からあったと思うんですが、OSのデフォルト設定がそうなったのは割と最近です」

「最近のLinuxでfreeコマンドを実行してみると、まったくアタッチされていない完全にフリーなメモリってほとんど残ってませんし」「昔のOSはもっとちゃんと解放してましたね」「最近はファイルキャッシュにメモリのほとんどを費やすようになってますし」「そういえばこの本にも同じことが書いてありました！」「今どきfree memoryはほとんどゼロですし」

「たとえばMacだとwiredという項目↓が実際に使われている（かつ解放されたら困る）メモリなんですけど、それ以外の部分はめいいっぱいファイルキャッシュとかに割り当てられます: 今どきのOSの設定がそうなっていることを考えればcatとかでファイルキャッシュに乗せる戦略はもっともですね☺️」

「ところでさっきのデータベースの起動ですけど、いきなり起動するのは構いませんが、すぐにin-service状態にはすべきでないということだと思います」「あ、たしかに😅」「ウォームアップしてデータがメモリに乗る前にin-service状態にすると死ぬ、ということですね☺️」

「あと、データをメモリに乗せるのも別にcatである必要はなくて、よく使われるのはSELECT * FROM なんとかでデータを総なめする方法」「なるほど！」「他にもベンチマークなんかだと、過去のSQLクエリのリストをファイル化しておいて起動時にそれを一気に実行するという方法も使われますね」「お〜」「そういうのを俗に『DBをあっためる』なんて言います☀️」

「catでファイルキャッシュに乗せるなんて初めて聞きましたけど何かピンとこないし🤔」「私も読んだときは『それでできるの？』って気持ちでした😅」「そこはOSの一番下のレイヤだと4KB単位とかでページに乗りますし、そこのアラインメントがずれることはないはずですね☺️」「それもそうでした😅」「その話もこの本に出てました」

「なのでcatでもできます」「catでも大丈夫ですよ〜☺️」「よかった〜、もう誰も使ってないsync syncみたいなテクニックだったらどうしようと思ってました😆」「😆」「とにかく1回ページキャッシュに乗せちゃうことが大事☺️」

参考: sync; sync; sync; haltの伝承 - Qiita

「ちなみに、LinuxのBashでキャッシュを強制クリアしてから性能を測定するともろに違いが出ますよ😎」「あ〜わかる！」「どんな違いでしょうか？」「つまり初回のファイル読み込みではめちゃくちゃ時間がかかるけど、2回目以降からは一瞬で終わります☺️」「なるほど〜」「当然の影響っすね☺️」

「というような部分を知らない人はこの本を読むといいと思います👍」「はてなのサービスはよく使っているので、この本で説明されているサービスをイメージしやすいのもうれしい点でした😋」「この本が突き刺さる人はたぶん、OSも一応勉強したしコードも書いているけど、両者の挙動の結び付きが今ひとつイメージできてない人でしょうね☺️」「私だ🤣」「逆にOSをまったく勉強したことのない人がいきなりこの本を読んでもよくわからないまま終わっちゃいそう😆」「OSのページキャッシュとかL1/L2キャッシュなどがある、ということぐらいは押さえてから読むといいでしょうね☺️」

同書はOSの話以外にもアルゴリズムの選択の重要性や検索の高速化の話など、学びが多いと思いました😂。

⚓Linuxのブートプロセスを学ぶ

「その辺は、自分も何度かオススメしている『Linuxのブートプロセスをみる』↓でかなり詳しく解説されてますね」「おお」「この本はそれこそ8086の挙動とか割り込みピンの位置まで解説してます😋」「この本を読み終わったあたりでやっとLinuxがブートするんですね😆」「😆」「Linux全体というよりLinuxカーネルのブートですけど😆」

「まあ相当重たい本ですし😆、自分は学生時代の暇でしゃーない時期に読んだからいいけど今読むには気力が足りなくなりそうなぐらいにはしんどい本ですけどっ😅」「惜しいことにこの本は今となっては古い: 今のLinuxはGRUBやEFIになってますので」「BIOSが主流の時代の本ですね😆」

参考: GRUBについて
参考: EFIシステムパーティション - Wikipedia

「BIOSの頃は3段階ぐらいに分けてブートしてましたね: 最初のローダーは、次のローダーを展開するだけの小さいカーネルを読み込んで、それを使って次のもう少し大きいカーネルを読み込むとちょっとだけディスクにアクセスできるようになって、それでさらに次のカーネルを読み込む、みたいな😆」「そのたびにビット数が増えていくと😆」

「昔読んだ雑学なんですけど、ヘリコプターがない時代に巨大な吊橋をかけるために、まず子どもに凧を上げさせて向こう岸に届かせたら賞金を出すことにして、そうやって届かせたタコ糸に少しずつ太い糸を結んで手繰り寄せて、最終的に太い鉄のワイヤーを向こう岸まで渡した、という話に似てるなと思って🐙」「それがブートストラップというヤツですし😆」「『自分の靴紐（boot-strap）を引っ張って空を飛ぶ』でしたっけ😆」「そんなネタにもされますし☺️」「今はBootstrapというと違うものを指してるみたいですけど🤣」

参考: ナイアガラ・フォールズ吊り橋 (Niagara Falls Suspension Bridge)
参考: ブートストラップ - Wikipedia

⚓DB

⚓SQLFlow: SQLで使うAI（DB Weeklyより）


同サイトより

つっつきボイス:「名前からしてTensorFlowをなぞってるかなと」「Jupyter-notebookっぽいな...と思ったらJupyter-notebookだし😆」「😆」「デモも自分でdocker runでやっとくれという感じでした😆」「TensorFlowっぽいデータをSQLで取れるようにしたのかな🤔」「SQLに慣れてる人には読みやすそうではありますね」「流れ↓を見ると、SQLFlowのジョブがgRPCやJupyter-notebookを通ったりと...結構深ーい😆」「ストリーミングでもやれるっぽいですね」「ベタなテキストでやるよりはいいかも？😋」

Web browser 
 ↑
 | HTTP
 ↓
Jupyter Notebook server
 ↑
 | ZeroMQ streams: Shell, IOPub, stdin, Controls, Heartbeat
 ↓
iPython kernel
 ↑
 | IPython magic command framework
 ↓
SQLFlow magic command for Jupyter
 ↑
 | gRPC
 ↓
SQLFlow server
 ↑
 | Go channels
 ↓
SQLFlow job manager (Go functions)
 ↑
 | IPC with Go's standard library
 ↓ 
SQLFlow jobs

⚓その他DB

つっつきボイス:「デンマークのタクシー会社がGDPRでしくじって結構な罰金を請求されたみたいです」「マジで？ついにそんな事例が」「これって判決まで出たんだろうか？訴えるだけなら誰でもできますけど😆、判決が出たかどうかの違いの方が大きいはずなので」「後で見てみます〜」

この罰金は元記事の時点ではデンマークのData Protection Authority（DPA）からタクシー会社への勧告（recommendation）の段階で、デンマークでは初のGDPR事例だそうです。記事ではそれとは別に、今年1月にフランスでGoogleがGDPRの罰金を課せられた件についても言及しています（現在Googleは不服申し立て中）。

参考: グーグル、仏当局によるGDPRの罰金に不服申し立てへ - CNET Japan

⚓JavaScript

⚓createapp.dev: JS/CSS設定ファイル生成サイト

つっつきボイス:「BPSの社内Slackで貼っていただいたヤツです」「実はこちらのツイート↓が元でした☺️」

「createapp.devはちょうど自分が欲しかったので: こうやって画面をポチポチして、ReactとかSassとか使いたいものを選ぶだけでwebpack.config.jsができてくれるし😋」「これはスンバラシイ〜😍」「しかもWebpackでもPercelでもいいんですね」「今まであちこちからconfigをコピペしてくるのがどんだけしんどかったかと😭」「もうこれでいい、こういうのでいいのよ〜😂」


同サイトより

⚓最近のReact周りメモ

つっつきボイス:「BPS社内のJavaScript勢に、最近チェックしているものを教わってメモしました」「React Hooksは割と最近のものでしたね☺️」「JS勢の彼は、React HooksでReduxを置き換えられたらいいなと探り始めてるそうです」「実地ではまだらしいですが『Redux Thunkは簡単だけどやばくなりやすいらしい』『Redux-sagaはコード量増えるけどやばくなりにくいらしい』と伝聞レベルで聞きました」

「JS界隈は動き速すぎて勘が働かないので😭、実際にJS書いてる人に聞くのが早いかなと思って」「ワイも勘働かないし😇」「一度これを使うと決めると、それをひっくり返す工程を後から加えるのは難しいですね☺️」「特にJSだと、これを今使うべきかどうかの見極めって難しい〜」「React Reduxとか名前だけ見たら何だかわからないし😆」「😆」

⚓その他JS

つっつきボイス:「V8もいろんなことやるな〜」「こういう技術が出てくるとCDNの重要性が増してきそうですね: サイトをまたがってもURLがまったく同じであれば高速化できるとか」「ふむふむ」

「それとは別に、最近のHTMLのscriptタグって改ざんチェック用のシグネチャが付けられるようになってるんですけど、これをちゃんと付けていると今後高速に実行できるようになるかも（あるいは既に始まってるかも）という気がしてます」「スクリプトのパスとファイル名までチェックしなくても、シグネチャさえ同じであれば以後のパスのチェックや読み込みをスキップして高速化、みたいなことも既にどこかでやってるかもしれないな〜と思ったり☺️」

「ちなみに今のBootstrap 4はシグネチャ付きです」「知らなかった〜！」「以下のintegrity="sha384なんちゃらの部分↓」「お〜SHAの384ですか！」「これがあることで、ブラウザがHTML側とホスト側のintegrityをチェックしてくれます」「これが合わない場合にどういう挙動になるのかはやったことありませんが😆、今後こういう部分も高速化に寄与するんじゃないかなという気がしています」

<-- getbootstrap.comより -->
<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>

参考: Secure Hash Algorithm - Wikipedia
参考: サブリソース完全性 - ウェブセキュリティ | MDN -- integrityの解説


getbootstrap.comより

⚓CSS/HTML/フロントエンド/テスト

⚓emotion: スタイリングライブラリのいいとこ取り？

つっつきボイス:「これも社内JS勢に教えてもらいました」「CSS-in-JSですか〜」「PostCSSは〜？」「フロントエンド界隈速すぎていろいろやべー」「この界隈は最初の一歩の定番が四半期ごとに変わるってbabaさんも言ってましたし😆」「新しいものを覚えるより、1つを確実に使えるレベルで覚える方が大事ですし😅」「そうそう！😤」

参考: emotion – フレームワークに依存しない洗練された CSS-in-JS – PSYENCE:MEDIA

⚓その他

⚓フォント

つっつきボイス:「いろいろやってnerd系フォントに落ち着きましたけど、フォントのビルドって自分でやると意外に失敗しますよね😆」「フォントはもうIとlと1と、あとOと0が区別できてればいいし😆」「0は中棒か中点が欲しい」「中点はちょっと気持ち悪い気が😆」

⚓番外

⚓おひとついかが

つっつきボイス:「NASAが『あなたの名前を火星に送ります』というのを募集してるそうです😆」「怪しい響きが😆」「火星の土地の権利証じゃなくてよかった😆」「何十年か前に月とかでそういうのがあったような😆」

ICチップに名前を焼き込むそうなので重量は大丈夫そうです。

参考: 月の土地の価格が高騰するかもしれない？可能性を真面目に考えてみました | ど安定捨てて島移住

後半は以上です。

バックナンバー（2019年度第2四半期）

週刊Railsウォッチ（20190527-1/2前編）RuboCopが3分割へ、Railsリクエストのライフサイクル、Opal 1.0、Railsベンチマーク、Rubyパターンマッチングの現状ほか

今週の主なニュースソース

ソースの表記されていない項目は独自ルート（TwitterやはてブやRSSなど）です。

Publickey

publickey_banner_captured

DB Weekly

db_weekly_banner

Serverless Status

serverless_status_banner


タグ
この記事を書いた人

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。 これまでにRuby on Rails チュートリアル第2版の監修および半分程度を翻訳、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れて更新翻訳中。 かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。 実は最近Go言語が好きで、Goで書かれたRubyライクなGoby言語のメンテナーでもある。 仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.comに移転。Amazonウィッシュリスト: https://bit.ly/32aAmiI

hachi8833の書いた記事一覧へ

本記事の内容へのお問い合せはTwitterで@techrachoへMentionまたはDMにてご連絡頂くか、運営会社であるBPS株式会社のお問い合せフォームよりお問い合せ下さい。

CONTACT

TechRachoでは、パートナーシップをご検討いただける方からの
ご連絡をお待ちしております。ぜひお気軽にご意見・ご相談ください。
CONTACT FORM