React Native Matsuri 2021で発表したスライドです。 https://reactnative-matsuri.com/ja
データベース(に限らずあらゆる永続化リソース)を使用するテストをいかにして行うかはいつだって悩みの種です。この悩みは「どうやったらデータベースを使用するテストを行えるかわからない」ではなく「なんとかやってるけど、不満のようなものがある」というものになるかと思います。 やりかたはたくさんあるのですが、その優劣は条件なしに比較する意味がないくらい、条件に依存します。どんな選択肢も「この条件なら最適」と言えてしまうだけに、広いコンテキストで「こうするのがベスト」とも言いづらいのです。 前提 xUnit Test Patterns を下敷きにします。 ユニットテストでの話です。他でもある程度通じます。 具象イメージはSpringBootを使用するWebアプリケーションです。そこまでべったりな内容ではありませんが、背景にあるとご理解ください。他でもそれなりに通じます。 データベースを使用するテストで
2020 年末に発表された React Server Components は、一言でいうと React コンポーネントをサーバ側でレンダーする仕組みです。……が、初見ではちょっと魔法すぎて訳が分からない技術でもあります。トーク動画だけ見てても「具体的にどんな仕組みで動いてるの?」みたいな疑問が山ほど浮かんでくると思います。 一体裏で何がどうなっているのか、この技術はどう使うのか、デモコードを触りながらやっと具体的に理解しはじめたので、なるべく動作が想像しやすいようにまとめました。なお、この記事単体よりは、他の記事や上記動画を見てある程度概要や公式の売り文句を掴んでからの方が理解しやすいと思います。 これまでの、普通にブラウザで動作するコンポーネントのことを、区別のためにクライアントコンポーネントと呼びます(単に区別のために既存のコンポーネントに別名がついただけです)。以下ではサーバコンポ
Caution この記事はDHHファンの妄想によるシナリオが多分に含まれます。 というかほとんどです。 成り立ちが間違ってることも当然あるように思うので話半分で読んでください。 これは一体 最近のRailsフロントエンドやDHHの活動には一連の流れがあるわけですが、一部トレンドに沿ってない部分がある故にそれが汲めないというところがあるのではと思います。 それらの流れを記憶が定かなうちにつないで記録しておこうという記事です。 前提知識 Railsの生みの親、Rubyist Basecamp(社) DHHがCTOやってる会社 Basecamp(サービス) Basecamp(社)が開発してるプロジェクト管理ツール Trixを開発してたある日 Basecamp(サービス)に組み込まれてるリッチテキストエディタのtrixをcustomElements使って開発してたある日、DHHはあることに気づく。
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 16日目の記事です。 tl;dr「Google アカウントを使ったログイン機能を簡単に実装したい!」 Identity-Aware Proxy を使えば、ログイン画面すら作ることなく Google アカウントによるログイン機能を実装できます。ログイン可能なユーザを制限した社内向けアプリ等にも最適です。 「Google アカウント以外のソーシャル ログインもサポートしたい!」 Identity Platform で簡単に実現することができます。Firebase Authentication と共通の SDK が提供されており、ログイン画面も FirebaseUI により簡単に作ることができます。メールアドレスによるユーザリンク機能、マルチテナント対応、SLA も
まえがき開発中のソフトウェアのライセンスを策定するため、現時点でのベストプラクティスについて探っていたところ、ここ数年の OSS ライセンスの動向が面白かったので復習も兼ねてまとめました。 特に、Umbrel が採用したという PolyForm という新しいライセンス形態が面白かったので、これについて詳しく述べます。 なぜ今ライセンスについてまとめるのか私はソフトウェアやサービスをマネタイズする方法について興味があり、特にビットコインの応用について調べたりしています。 ビットコイン (Lightning Network) を HTTP で利用することで、Web API の課金方法の可能性は大きく広がることは間違いないのですが、これはあくまで単なる支払いの手法であって、広く使われる事を前提としたソフトウェアの開発を支える手法にすることは(それだけでは)難しいという問題があります。 ソフトウェ
数日前にTwitterで, JavaScriptのオブジェクトに対する===の挙動が初心者には難しいみたいな話を見かけた. 発端や周辺の議論をちゃんと追いかけてないからとくに出典は貼らない. たぶん元々の話は「へぇ, こういう挙動なんだ, 簡単ではないね」くらいの話だったのかもしれない. 自分のタイムラインの観測範囲では「そうだそうだ, (参照の同一性ではなく)同値性にしとけばいいのに」と思っている人もそれなりにいそうに見えた. 個人的にも同値性が簡単に確認できるとよい気はするものの, 「なんでそうしないんだ, オブジェクトの中身を確認していくだけだろ!」みたいな簡単な話ではないことも知っているため, 以下のようなツイートをしたのだった. JavaScriptのオブジェクトの同値性、再帰的な構造とか作るとぜんぜん自明じゃないんだよなぁ。リンクの構造は違うけどプロパティを辿ったときのパスはど
Mapped Typesの基本形 Mapped Typesの基本形は { [P in K]: T } です。 P は T の中で使える型変数です。このとき、 P はこのMapped Typeの引数型 (parameter type) K はこのMapped Typeの制約型 (constraint type) T はこのMapped Typeのテンプレート型 (template type) と呼びます。 T の中で P がどのように振る舞うかに注目すると type Element<P extends K> = T; という形の定義と相似であることから、P が引数型、 K が制約型と呼ばれる理由がうかがえるかと思います。 Mapped Typesの基本形で、 T が P に依存しないケースには Record<K, T> という名前がついています。 type Record<K extends
Google Cloud Platform(以降 GCP) の認証認可については GCP と OAuth2 などの記事があるが、 Compute Metadata credential そのものの解説はあまり十分にされているとは言えないので、今回一つの記事で説明する。 Compute Metadata Credentials と聞いてもピンと来ない人向けに書くと、「Cloud Run や Cloud Functions などの GCP のプロダクトから GCP の API を呼ぶのにサービスアカウントキーが必要ないこと」の裏側がどのように動いているかの話について説明する記事である。 Compute Metadata Credentials とは Compute Metadata Credentials は Google Cloud Platform(以降 GCP) の標準の credent
先日、妻が亡くなった。 ガンだった。ガンが見つかった時は既にかなり進行していたようで、医者から具体的なステージ名は告げられなかったが、余命3ヶ月を宣告された。 あらゆる治療を試みたが、彼女は治療開始から6ヶ月で亡くなってしまった。 治療中は全力で彼女のサポートをしていたので、音楽を楽しむ時間も心の余裕も無かった。 だが、葬儀や一連の手続きが済んだあと、ふと耳に入ってきた米津玄師のLemon。歌詞があまりに今の自分と符合していて、聴きながら号泣した。 勿論、以前からこの曲を何度も聴いたことはあったが正直そこまで深く歌詞を吟味したことはなく、何となくいい曲だなという印象しかなかったが、妻が亡くなって歌詞の感じ方が180度変わった。 そこでお願いします。 米津玄師のLemonのように、居なくなってしまった大切な人に思いを馳せる曲を教えてください。日本語の歌詞だと助かります。 6/16 追記: 1
はじめにこんにちは、Google Cloud Customer Engineer の Yutty です。久しぶりの投稿です。今回の投稿は、kwjp@との共著です。 2019年の Advent calendar で「 GCP の IAM をおさらいしよう」という記事を書きました。未だに多くの方に読んでいただいており、IAM まわりで情報を探している方も多いのだろうと推測しています。 今回は、比較的新しい機能や、こういうときどうするの?といったプラクティスを紹介していきたいと思います。 Cloud Identity Groupsもしかしたら、このトピックは「サービスアカウント Google グループ」といったキーワードで検索された方にはピッタリかもしれません。 10 new security and management controls for GCP and G Suite でも紹介されて
ときに、SSD のセルを完全に消去して、SSD 製造時の状態に完全に戻し、製造時の書き込み性能を取り戻したいと思うこともあるでしょう。たとえ SSD がネイティブ TRIM に対応していても、時が経つにつれて書き込み性能は下がっていくことが知られています。TRIM はあくまでファイルの削除に対する防護であり、差分保存などの操作には効果がありません。 Secure Erase を行っても、SSD セルのウェアレベリングの状態はリセットできません。寿命を迎えつつあるドライブの場合、短い間は書き込み可能になるかもしれませんが、限られた量の書き込み後は依然としてできなくなります。 警告: 消去を行う前に重要なデータをすべてバックアップしてください! この作業は SSD 上の全データを破壊し、データ復旧サービスでさえ復元不可能にしてしまいます! 作業を行った後に、デバイスを再度パーティショニングして
1. はじめに Google がChrome/89よりトライアルを開始しているFLoC (Federated Learning of Cohorts)技術に対して、現在多くの批判が集まっています。 批判の内容は様々な観点からのものが多いですが、以前より Privacy Sandbox に対して否定的な見解を示してきたEFFの批判「Google Is Testing Its Controversial New Ad Targeting Tech in Millions of Browsers. Here’s What We Know.」が一番まとまっているものだと思います。 これまで Privacy Sandbox 技術に関わってきた身としては、各種提案の中でFLoCは特にユーザへの注意が最も必要なものだと思っていました。しかし、これまでのド直球なGoogleの進め方によって、FLoCのトラ
TypeScript環境でのReactの useRef は、初期値と型引数の与え方によって返り値の型が RefObject と MutableRefObject のどちらかになります。どういう使い方のときにどう書いてどちらを得るべきかを、 @types/react の更新まわりの議論を追った結果を示します。 この記事は2021年5月現在、React 17.0.2が最新バージョンの時点で記述します。 参考にした情報 https://github.com/DefinitelyTyped/DefinitelyTyped/issues/31065#issuecomment-446425911 RefObject と MutableRefObject が別である理由について https://github.com/DefinitelyTyped/DefinitelyTyped/pull/38228#i
「頑張って遅れを取り戻す」 綺麗な言葉ですが、私は嫌いです。その中でも次の言葉が特に嫌いです。 頑張る 遅れ 取り戻す 全部。これらが嫌いな理由をそれぞれ説明していきます。順番は「頑張る」→「取り戻す」→「遅れ」です。 なお、「頑張って遅れを取り戻す」に期待される結果は「他に一切の影響を与えず、遅れだけが綺麗になくなる」だと思われます。 頑張る 「頑張ってなかったん?」と言うと「頑張っていましたが、もっと頑張ります。」みたいなのが返ってきます。でもこれって多分「頑張る」と言われることが求められているからそう返してるだけで、もともと手なんて抜いていない。仮に手を抜いていたとしたら「頑張る」は「手を抜いていました」の宣言になるので、それを許容してる状態が問題になるんじゃないかな。 とか言葉遊びは置いておいて、現実の話をします。こういう文脈での「頑張る」は「長時間連続労働」に他なりません。そこで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く