最近 ID 界隈で話題になっているトピックとして、デジタルIDウォレット(DIW) というコンセプトがあります。これは、身分証、運転免許証や、銀行のキャッシュカード、さらにはお店のポイントカードまで、あらゆる本人のアイデンティティに関するデータを、スマホアプリに保存し、必要に応じて、必要な情報だけ、必要あれば複数をまとめて一度に、提示できるというコンセプトです。 話題になっている背景、必要となる技術、欧米の動きなど、２０２３年１２月時点での私の理解をまとめました。 明確なソースがある情報は、極力ソースとなるURLを添付しています。 また、一般論としてここに記載する情報については、国内外の多くの識者の方のお話を、直接的、間接的に伺う中で、私の中で咀嚼、消化した内容となっております。ここの皆様のお名前は略させて頂きますが、御礼申し上げます。それでも、本ブログの内容に誤りがあれば、すべて私の責任

以下のようなコードで、「setCount で count の値を 0 から 1 に更新したのに、console には古い値が表示されてしまう」ということがあると思います。(記事タイトルが不正確なのはわざとで、検索に引っかかって欲しいからです) const [count, setCount] = useState(0); const handleClick = () => { setCount(1); console.log(`同期: ${count}`); }; 「ステート 変更 反映されない」で Google 検索すると「それはステートの変更が非同期に反映されるから」という誤った解説が流布しています。 「setState の反映が非同期である」ことと「古い値を参照してしまう問題」は関係ありません。この記事で訂正できればと思います。 結論: 公式ドキュメントを見ろ React 公式の新ドキ

モチベーション WebAssemblyが面白そうだと思いつつ、HelloWorldだと味気ないし、SQLiteを移植した、というようなものだと複雑すぎるということで、少し複雑なGoのプログラムを、ブラウザで動かすように変更してみて、雰囲気を掴みたいと考えました。 Goのプログラムを書く 文字でHelloWorldのサンプルは味気ないということで、今回選んだのはGoで画像を生成するプログラムです。 以下の記事のプログラムをほぼそのまま利用しています（以下の記事では日本語を出すための内容が書かれていますが、その部分は今回はスルーします） package main import ( "bytes" "fmt" "image" "image/png" "os" "github.com/golang/freetype/truetype" "golang.org/x/image/font" "gola

いきなり追記 2024-01-09 この記事にはまともな結論がありませんし論点も定まっていません この記事には批判が多いので、こちらの素敵な記事をぜひお読みください。 Free Wi-Fi(00000JAPAN)は安全なのか？ コメントで不愉快とされたところを削除しました。 徳丸さんのツイート 猫の写真 素人というエクスキューズ （編集履歴はqiitaの機能で見れると思います） 信頼できるサービスであれば Free Wi-Fi に限らず被害に遭う可能性はとても低いと思います。気にせず使ってください。 気分を害された方にお詫び申し上げます。 ここから元記事 お正月休みは卒業した大学の記事を書く予定でしたが、ちまたで話題の「httpsなら安全」について攻撃的なツイートを散見どころかめっちゃ見たのでこの記事を書いています。httpsを盲信されるならまだしも、無知の斧で攻撃を振るう方に悲しみを覚え

はじめに Nostrという、SNSのようなものはご存知でしょうか？ ご存知でなければ、ぜひまず一度触ってみることをお勧めします。 割と普通にSNSっぽく使えます。 分散系SNSっぽいシステム Nostrは、分散系のSNSっぽいネットワークです。 図で表すとこんな感じ。普通に想像するWebサービスとは随分形が違うと思います。 各所のリレーサーバーに、ユーザーは投稿をばらまき、ユーザーがそれを見る形です。 分散の責任がユーザー(クライアント)側にあって、リレーサーバーが落ちたり消えたりしても影響が起きにくい仕組みです。 より詳しい説明は上記でやってるのですが、端的に言って 中央管理者がいない(各リレーに管理者はいる) 冗長で災害に強い Websocketのリアルタイム通信 オープンでシンプルで、でも拡張し放題な仕様 数多のサーバーによる分散ネットワーク といった特徴があります。 ※P2P技術は

最近 ID 界隈で話題になっているトピックとして、デジタルIDウォレット(DIW) というコンセプトがあります。これは、身分証、運転免許証や、銀行のキャッシュカード、さらにはお店のポイントカードまで、あらゆる本人のアイデンティティに関するデータを、スマホアプリに保存し、必要に応じて、必要な情報だけ、必要あれば複数をまとめて一度に、提示できるというコンセプトです。 話題になっている背景、必要となる技術、欧米の動きなど、２０２３年１２月時点での私の理解をまとめました。 明確なソースがある情報は、極力ソースとなるURLを添付しています。 また、一般論としてここに記載する情報については、国内外の多くの識者の方のお話を、直接的、間接的に伺う中で、私の中で咀嚼、消化した内容となっております。ここの皆様のお名前は略させて頂きますが、御礼申し上げます。それでも、本ブログの内容に誤りがあれば、すべて私の責任

はじめに toPromiseはRxJS7で非推奨となりRxJS8で使用できなくなることが予定されています。 今後はtoPromiseの代わりにlastValueFromを利用するべきという記事が多くありますが、本当に同じことができるのかを検証してみました。 結論 多くのケースでは問題ないが全く同義ではない 下記公式ドキュメントでもこう記載されています。 RxJS Conversion to Promises The lastValueFrom is almost exactly the same as toPromise() almost（ほぼ）ということで異なる挙動をするケースがあるのでこの記事ではその説明をしていきます。 toPromise終了に向けて追加された2つのFunction lastValueFromとtoPromiseの違いの前にまずtoPromiseの終了に向けて追加され

データベース検索秘匿化技術「Private Information Retrieval (PIR)」の最先端アルゴリズムの発明と特許・商標出願までの道のり特許ElGamal暗号PIR商標 ブロックチェーンエンジニアのびりあるです。 データベースの検索内容をサーバ側に知られることなく検索ができる「Private Information Retrieval (以下PIR)」という暗号技術があるのですが、既存の実装ではシングルコアかつCPUでしか計算できるものがなく、実用的な範囲の計算時間では大規模化が難しいという課題がありました。 そこで、独自の研究開発を重ね、並列化がCPUもりも難しいGPUを用いて非常に高い効率で並列化ができるアルゴリズムを考案し、その試験実装を行った結果、家庭向けの安価なGPU (NVIDIA GeForce RTX 3080) 一台のみで、従来実装と比べて実実行時間性能

はじめに Electronいいわー ChromiumとかNode.jsの知見もあるといいらしい *1 でもChromiumとかようわからんぜ この際勉強しちまえばいいじゃん！ 本エントリはElectronを構成する要素の一つ、Chromiumのアーキテクチャについて初心者が入門してみたものです。 Chromiumドキュメントを読む Chromiumの仕組みを優しく解説した本やエントリはざっと探した限りはありません。 そういうのが必要な人がふれる領域の話ではないのでしょう。 必然的に英語で書かれたドキュメントを読むことになります。 Chromiumプロジェクトはリンクの樹海のようになっていて迷いそうです。 Developer向けドキュメントは以下のリンクを辿って行くとみつかります。 For Developers > Design Documents - Engineering design

記事の概要 約1年間DAOでサービス運営したものの、今回クローズすることを決定しました。過去1年間で利益230万円を達成し、サービス改善、NFT会員証の発行、ハッカソンで優勝するなど、多くの成果を上げました。しかし、貢献数と売上の低下によるモチベーションの低下、運営コスト、税務上の問題などがクローズの理由となりました。それでも、この1年間で得た成果からDAOのポテンシャルを熱烈に感じることができました。 Englister DAOの成果 この1年間でEnglister DAOが生み出した利益は230万円でした。これは僕ひとりの力では絶対に達成し得なかった数字であるため、まさにDAOがあったおかげ、DAOの成果だと考えています。 この成果を次の３つに分解して紹介していきます。 １、サービス改善に伴う売上増加 1~5月は個人開発で運営していましたが、その間はずっと横ばいだったのですが、6月にD

CRDTについて勉強したので纏めてみました。15分くらいでざっとわかったつもりになれる感じで纏めてみたつもりです。 全体スライド Slideshareのスライドが埋め込めなかったので、↓からアクセスしてくださいm(-_-)m 下記はスライドの講演の書き下しのようになっているので、スライドだけ見るんじゃなくて、スライドを見ながら文章を読み進めたい方向けです。 CRDTとは 今回は、CRDTというデータ構造について紹介します。CRDTはそもそも2011年にSSS(Stabilization, Safety, and Security of Distributed Systems)という国際会議で、INRIA(フランス国立情報学自動制御研究所)のMarc Shapiro博士によって発表された、比較的新しいモノです。 CRDTは"Conflict-free Replicated Data Type

DID Methodとはなんぞや、という話は省略する。DID-COREのリンクを貼るので参照して欲しい。 The did:key Method (以下did:key) はエフェメラル用途向けに考案されたDID Methodで、DID Documentの名前解決にDLTや共有ストレージのようなバックエンドを必要としない。「key」という名前の通り、did:keyのDID文字列は単一の公開鍵と全く同じ情報量を持ち、DID DocumentはDID文字列(⇔公開鍵)から一意に導出される。DID文字列に情報が全て含まれるので、誰でも、たとえオフラインでも名前解決が可能なのが最大の特徴だ。 導出方法 ここからは実際の導出の過程を見ていこう。 公開鍵 ←→ DID文字列 DID文字列は公開鍵から次のように一意に導出される： didString pubKeyType rawPubKeyBytes = "

ある日の我が家 娘「ねぇ、パパ！」 ワイ「おお、なんや？娘ちゃん」 娘「HTMLとCSSでダイアログを作る方法を教えて欲しいの！」 ワイ「おお、ええでぇ」 ワイ「ちょうど今、ワイの個人ブログを作ってるところでな」 ワイ「これからダイアログを作るから、やり方を見せてあげるでぇ」 娘「わ〜い、ありがとう！」 娘「わたし、z-indexがうまく使えなくて困ってたの！」 ワイ「おぉ、パパに任せとき！」 ワイ「パパはz-indexを完全に理解してるからな！」 z-index完全理解ワイ、説明開始 ワイ「今、こんなサイトを作ってるんやけどな？」 ワイ「↑このサイトにダイアログを表示できるようにしたいんや」 「記事の投稿が完了しました。」 ワイ「↑こういうメッセージを表示するためのダイアログや」 娘「なるほどね」 ワイ「ほな、コードを書いていくで」 ワイ「まず、現状のコードは──」 <body> <he

入門本でGoの世界にGo!(言ってみたかっただけ) 2009年にあのGoogle発、Better Cの立ち位置でマスコットのゴーファー君とともに人気を伸ばしてきたGo言語。 コンテナやマイクロサービス関連、実行速度が求められる場面でもお馴染みになっています。先進的な企業での採用事例も多く、まだ使える人がIT業界全体ではそれほど多くないからか求人でもよく見かけます。なんとなく優秀なエンジニアや先端技術動向に通じたエンジニアが嗜んでいそうなイメージもあります。 最近入門したこともあり、ここでは日本で手に入るGoの書籍についてまとめてみました。2022年現在、電子書籍もしくは物理書籍で比較的手に入りやすいものを中心に、カテゴリ別、出版された順番に並べています。 プログラミング自体が初心者向け 初心者向けの本はここ数年で何冊か出ています。 入門Goプログラミング 2019年/5月刊行、海外の"Ge

Googleから最近になって、FIDO認証デバイスの「Titanセキュリティーキー」が発売されたので、購入しました。 [Google Titanセキュリティーキー］ https://store.google.com/jp/product/titan_security_key_kit 今のところ、はやっていそうですし、せっかくなのでこれを使って遊んでいきたいと思います。 Titanセキュリティーキーがあれば、Webサーバから見てユーザID/パスワードで認証するのではなく、Titanセキュリティーキーのデバイスを認証してくれます。公開鍵をベースとしているそうです。 また、Titanセキュリティーキーには、USBに加えて、NFCとBLEの接続方法があるので、直接PCに挿さなくとも、デバイス認証してくれます。 ということで、今回は、王道のFIDOサーバを立ち上げます。 (参考) こちらもどうぞ。

はじめに この記事では、OAuth 2.0 のアクセストークンの実装に関する考察を行います。本記事の執筆者本人による動画解説も『OAuth & OIDC 勉強会 【アクセストークン編】』で公開しておりますので、併せてご参照ください。 English version of this article is here → "OAuth Access Token Implementation". 1. アクセストークン実装方法の分類 OAuth のアクセストークン※１の実装方法は認可サーバーの実装依存です。 実装依存ではありますが、RFC 6749 の『1.4. Access Token』にある次の記述が示唆するように、 The token may denote an identifier used to retrieve the authorization information or may

TypeScriptでは配列の型はT[]のように宣言します（Array<T>でも可）。この配列は、もちろん要素数が何個でも構いません。 const arr1: number[] = [0, 1, 2]; const arr2: number[] = [0]; const arr3: number[] = []; しかし時折、「2個以上の要素を持った配列」のような条件を書きたくなることがあるかもしれません。すなわち、配列の最低要素数を型で指定したいという場合ですね。実はTypeScriptでは、タプル型を応用することでこれが可能です。 タプル型を用いた最低要素数の表現 // 要素が最低2個あるT型の配列 type AtLeast2<T> = [T, T, ...T[]]; const arr1: AtLeast2<number> = [0, 1, 2]; // これはOK const arr

ブラウザスタイルは平坦化しておく リセットCSSはオプトアウト可能にしておく 登場頻度の高い組合せはplaceholderとして登録してから利用する 可能な限り画像はスプライト生成してから利用する それ以上分解不可能なコンポーネントは要素のように扱う コンポーネントは自己完結型のものを使う BEMはDRYになるよう粒度を下げる 可能な限り@extendは利用しない レスポンシブでない場所では、Utilitiesクラスを活用する shame.cssはいつも綺麗にしておく 詳細度または特異性の高いものほど後方に記述する 可能な限り!importantしない 可能な限りハックしない 変数をデザインガイドとして活用する CSSファイルを分割するメリットはほとんどないので一つにまとめる 1. ブラウザスタイルは平坦化しておく 例えば、こういうScrap & Buildは単に通信量のムダ。 * { f

TL;DRとは？ TL;DRは"Too Long, Didn't Read" 「長すぎるから読まないよ。」「要約です。」など記事や論文、プレゼンテーションなどで省略や引用を簡潔に説明する時にちょいちょい見かける表現です。(だと思っていました） 実用英語でもこういう表現が市民権を得て使われていると思って英会話で使ってみたところ顰蹙を買いました。 なにやらTL;DRには 「〜(笑)」 「本田△」 「~(以下略)」 のような煽りや小馬鹿にした意味合いも持っていることがあるということを教えてもらいました。 なので発言の仕方、かっちりしたフォーマルな場での多用はあまり避けた方がよさそうです。 ※ネットぽいというかNerdyな感じらしいです。 追記 2019/06/24 1人だけの意見を書いてしまったので数人の英語ネイティブ（非IT業界勤務)にもどういう風に見えるか、聞こえるのか聞いてみました。 ・T

概要 内容と動機 これは、「A Philosophy of Software Design」の要約になります。 本書の内容としては、筆者が経験ベースで、ソフトウェアの複雑性の原因とどれにどう向き合うのかをまとめた内容です。 普段チームで開発する中でわかりづらさや、設計に関する違和感を感じることがあります。 その自分の違和感が本当に正しいものなのか、仮にそうだとしたらきちんと言語化してレビューしたいという動機から本書を読むことにしました。 170ページの本書を完璧に要約することは困難なので、幾分自分にとって印象深かったことが選ばれていると思います。 逆に、その過程で触れられなかった章もありますので、その点ご留意ください。 また、ここでは具体例は少ないですが、ある程度大きなコードベースで開発した方であれば想像しながら読めるのではと思っています。 もし、具体例を参照したい場合は、ぜひ本書を読んで