Secrets from the Algorithm: Google Search’s Internal Engineering Documentation Has Leaked
Watch Our Google Algorithm Leak Webinar Replay Google, if you’re reading this, it’s too late. Ok. Cracks knuckles. Let’s get right to the Google algorithm leak. Internal documentation for Google Search’s Content Warehouse API has been discovered. Google’s internal microservices appear to mirror what Google Cloud Platform offers and the internal version of documentation for the deprecated Document
ID生成大全 - Qiita
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
第４０４号コラム「マイナンバーのチェックデジットについて」 | デジタル・フォレンジック研究会
第４０４号コラム：上原 哲太郎 理事（立命館大学 情報理工学部 情報システム学科 教授） 題：「マイナンバーのチェックデジットについて」 ついにマイナンバー制度の運用が始まりました。個人的にも、年が明けて以来あちこちでの講演などで事務手続きに個人番号の提出を求められる機会が増え、いよいよ始まったということを実感しております。一方、運用を担う自治体現場ではさまざまなシステムトラブルや手続き上のミスが発生してしたり、昨年の年金機構を狙ったサイバー攻撃に対応するため個人番号を扱うシステムを系統分離したりと大変な作業になっていますが、ここをなんとか乗り越えて、行政の効率化にうまく繋げられることを願っています。それこそがこの施策の目的ですから。 このマイナンバーですが、この種の多くの番号の例に漏れず、人手での入力間違いが発生しても機械的にすぐわかるように、チェックデジットと俗に呼ばれる1桁が付け加え
RSAの終わりの始まり - 暗号移行再び - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前振り 全国の暗号を使うエンジニアの皆さんこんにちは。今日は暗号移行とRSA暗号の話をしたいと思います。まず暗号を利用している皆さんであればCRYPTRECの「電子政府推奨暗号リスト」のことはご存じですよね！（言い切るw） CRYPTRECから2022年7月（昨年夏）に暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準（PDF直リンク）が公開されました。この中では暗号のセキュリティ強度で各種暗号と鍵長が整理されています。セキュリティ強度はビットセキュリティと呼ばれるビットサイズ（共通鍵暗号の場合のビット長）で区分されます。暗号アル
UUID v6, v7, v8 : タイムスタンプでソートできる新しい UUID のドラフト仕様 - kakakakakku blog
ID を採番するときによく使われる UUID Version 4 の課題として「順序性がなくソートしにくい」という側面があり，ULID (Universally Unique Lexicographically Sortable Identifier) を使えばソートできるようになるという記事を前に書いた． kakakakakku.hatenablog.com 関連して調査をしていたら，標準化団体 IETF (Internet Engineering Task Force) によって，UUID Version 6, 7, 8 という新しい仕様が提案（ドラフト段階）されていることを発見した❗️UUID Version 6, 7, 8 の目的を簡単にまとめると「タイムスタンプ情報を使ってソートできる ID を採番できるようにする」となり，もしこの仕様が取り込まれると，UUID を活用する幅がさ
スイッチサイエンス、量子コンピュータ始めるってよ
2022年12月、販売開始しました！ 深センSpinQ社の卓上量子コンピュータ。１テスラぐらいの磁力で２つの量子を閉じ込め、計算している @tks です。深圳の量子コンピュータ企業SpinQに行ってきました。 秋田先生のレポート量子コンピュータとのファーストコンタクトをしてきたをぜひ読みましょう デスクトップで量子コンピュータが動く！ 深圳のSpinQ社は、世界で最初のデスクトップ量子コンピュータを商品化し、販売しています。NMRという、磁場と電磁波を加えて原子核の「スピン」の量子状態を操作・計測する方式を用いて量子計算を行う方式で、2020年に販売開始したGeminiと2021年末に販売を始めたGemini-Miniでは2つの量子ビット（Qubit)を操作します。 Gemini-miniの内部 かなり強い永久磁石２つの間に、液体の入ったチェンバーがあり、その液体に電磁波を当て、量子状態を
テキストエディタで使われがちなデータ構造 Piece Table の概要と実装 - A Memorandum
テキストエディタのデータ構造 Gap method Piece Table method Piece Table の構造 Piece Table の実装 Piece Table のメソッド まとめ テキストエディタのデータ構造 テキストエディタで採用されているデータ構造にはいろいろあります。 こちらの論文 Data Structures for Text Sequences では各種データ構造について比較検討されています。 多くは、Gap method や Piece table method をベースにしたものが多いのではないでしょうか(図で言う最下部の中心の丸印に当たります)。最近では Rope なども有名ですね。 Gap method Gap method では、現在のカーソル位置で、テキストバッファを2つに分割し Gap を間に挟み、カーソル位置に対する編集(テキスト追加/削除)を
40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog
2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。 この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります) www.ietf.org 改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。 概要 この改訂版の仕様(通称 rfc793bis)は、RFC793が
【重要】予測公開停止予定のお知らせ - 競馬AIゆま牧場
8月末をもって当サイト及びTwitterでの予測公開を停止します。 停止理由は「ゆまの利用者増加を支えきれなくなったため」です。 幸いなことにこの4年半の間で多くの人にゆまを利用いただけるようになりましたが、それに伴いオッズの低下も当然発生しました。(※1) 御存知の通り、競馬は同じ予想をしている人が増えるとオッズが下がり勝つのが難しくなります。 これまでオッズの低下をカバーするように予測性能の改善を行っていましたが、そろそろカバーできないレベルになりつつあります。(※2) このまま公開を続けていくと更にオッズが下がり、近々勝てない（勝つのが難しい）予測になりえます。 勝てない予想を提供することはポリシー上やりたくないので、その前に公開を終了することにしました。 今後は個人的に非公開のまま運用を続ける予定です。 オッズ低下がない状態、すなわち斤量ゼロの状態でどれだけのパフォーマンスが出るの
20日目: 正規表現が ReDoS 脆弱になる 3 つの経験則
はじめに 皆さんこんにちは．3回生のらん（@hoshina350）です． 文字列マッチングに便利な正規表現ですが，テキトーに書くと脆弱になり得るという情報を耳にしてから色々と原因や対策を調べていました． しかし，多くの記事で紹介されていた対策方法は，「独自の正規表現を使用しないー」とか「 * や + などの繰り返し表現はなるべく使わないー」とかいう なんともふわっとしたものでした．これでは「いやぁ確かにそうなんかもしれんけど…そうゆう訳にはいかんやんか…」と納得できません． つまり，「本質的に何が問題」で，「具体的にどんな特徴のある正規表現が脆弱になり得るのか」を知りたい訳です． そこで，様々な文献を調査してみました．本記事では調査して溜まった知見を紹介していきます． 本記事は， Purdue大学のJames Davis教授による “The Regular Expression Denia
Goの正規表現が遅いって言う人がいたから、（速い）正規表現エンジンを作ったよ
はじめに 「Goの正規表現は遅い」 そんなふうによく言われていました。（最近はあまり聞かなくなりましたが） たとえば、↓の記事ではPythonの正規表現と比較して1.5倍くらい遅いという結果になっています： この話には「Goの正規表現は最悪時間が短くなるように安定したアルゴリズムを採用しているから」という回答があります： ↑の記事の比較では、GoがPerlに対して約10倍以上高速という結果が出ているので、「Goの正規表現は遅くない！はい、論破ー！」というわけですね。 なんでこうなるのかも↑の記事で説明されているとおりですが、Perl（などのバックトラック型エンジン）が入力長に対して指数関数的に実行時間が伸びていくのに対し、Goの正規表現エンジンは入力長に対して線形時間で実行時間が伸びていくアルゴリズムを採用しているため、入力が長くなると急激にGoのほうが有利になるからです： 一方で、入力が
React Suspenseで不要な描画処理をなくす
function ProfileDetails() { const user = resource.user.read(); // throw promise here return <h1>{user.name}</h1>; } この仕様自体、それだけで記事になるほど面白いです。（ここでは割愛します。） React Freeze React Freezeは、そんなSuspenseを利用したライブラリです。 元々React側は、データ取得の際に使うことが主なユースケースと言っていたのに対して、このライブラリの目的は、ある瞬間にユーザーに表示されていないアプリの部分について、不要な再レンダリングを避けることとなっています。 どうやって実現しているのでしょうか？ 実は、ライブラリの実装もシンプルで興味深いです。 // ref: https://github.com/software-mansi
実践TLA+ | 翔泳社
設計だってテストしたい！ 【本書の内容】 本書は Hillel Wayne, "Practical TLA+", Apress, 2018 の邦訳版です。 複雑精緻なシステムを構築する際に、設計そのもの、仕様そのものにバグがないかをテストできたら、もう少し幸せな開発人生を送れそうな気がします。 本書は送金システムの小規模な仕様からTLA+を使ってヤバいバグを発見するところから始まります。この小さなサンプルをもとに、より良いアプリケーションの設計・テスト・構築に、どのようにTLA+を使えばよいかを理解し、実際のプロジェクトに援用できるよう、TLA+の演算子、論理、関数、PlusCal、モデル、および同時実行の基礎を学びます。 設計図の整理の仕方、分散システムや最終的な整合性の指定の仕方を学んだら、アルゴリズムのパフォーマンスやデータ構造、ビジネスコードやMapReduceなど、さまざまな実用
N番目の素数を求める - すぎゃーんメモ
SNSなどで話題になっていたので調べてみたら勉強になったのでメモ。 環境 Pythonでの実装例 例1 例2 例3 エラトステネスの篩 Rustでの実装例 試し割り法 エラトステネスの篩 アトキンの篩 おまけ: GMP Benchmark 高速化のテクニック 上限個数を見積もる Wheel factorization オチ Repository References 環境 手元のMacBook Pro 13-inchの開発機で実験した。 2.8 GHz Intel Core i7 16 GB 2133 MHz LPDDR3 Pythonでの実装例 例1 最も単純に「2以上p未満のすべての数で割ってみて余りが0にならなかったら素数」とする、brute force 的なアプローチ。 import cProfile import io import pstats import sys def m
2のべき乗サイズの配列は危ないという話 via 行列積 - elkurin’s blog
こんにちは。労働者です。とあるプログラムで学生さんの課題を添削していたら面白い話に出会いました。 僕は今、主に学部生向けのインターン研修的なプログラムでメンターなるものをやっています。メンターとしての仕事は、学生さんの課題へフィードバックを返し、Office Hourというセッションを毎週設けて質問受けやCSに関するトークを行うといった内容になっています。今回話題に取り上げるのはその中の課題の1つ、「行列積のプログラムを書いて時間を計測せよ」という何気ない話で、続く課題たちのいわば前座のようなものです。こういったところに沼は隠されているものですね。 担当している学生さんたちが細かい実験を行ってくれて以下のような疑問が提示されました。 「行列積の計算が N = 1024のときだけ N = 1023, 1025のときに比べて3倍遅いのはなぜ？」 配列のサイズが2のべき乗になるのは避けるべきとい
マルチコアのCPUを使い切って圧縮を速くする - それマグで！
gzip の限界 ＝ CPU 1コア マルチコア・マルチスレッドのCPUがあるのに、gzip や lzma(xz)や bzipといったメジャーな圧縮は、CPUを１コアで処理するんですね。 CPU使用率を見てみたら、CPU利用率は100%を超えないんですね。 HDD・SSDの書き込み速度に限界があるからそれでも良かったんだろうが。いまはメモリが一般的に６４GBもある時代です。うちのマシンでもメモリが12GBもあるのに３GB程度の圧縮に、５分とか耐えられません。もうちょっと速くしたい。 cpu利用率が100%で頭打ちになる。gzip gzipを使ってると、CPU利用率が100%で止まるんですよね。lzma などの他の圧縮でも同じ。 gzip/ gunzip をマルチで処理する pigz / unpigz Pigz のマニュアルには次のように書いてある。スレッドを使って並列処理をするっぽい。 P
GPUに比べて最大15倍高速な市販CPU向けのディープラーニングアルゴリズムが開発される
近年のAIは、人間が手を加えなくてもコンピューターが自動的に大量のデータからそのデータの特徴を発見する「ディープラーニング(深層学習)」という学習手法で動いています。このディープラーニングは、コンピューターゲームに代表されるリアルタイム画像処理に特化した演算装置・プロセッサであるGPUで処理されるというのが通例ですが、ライス大学のコンピューター科学者がIntelと共同で「GPUに比べて最大15倍も高速にディープラーニングできるCPU向けソフトウェア」を開発しました。 ACCELERATING SLIDE DEEP LEARNING ON MODERN CPUS:VECTORIZATION, QUANTIZATIONS, MEMORY OPTIMIZATIONS, AND MORE (PDFファイル)https://proceedings.mlsys.org/paper/2021/file/
LINEのストレージ効率化を支えるJPEG↔HEIF変換プロジェクト「Antman」開発記
Joonsick Baick2020-02-26Joonsick is in charge of media processing for LINE's MediaPlatform. はじめに 最近、ユーザーが作成したメディアを保存するためのクラウドサービスがかなり人気を集めています。Google フォトやNAVER nCloudなどのサービスがその例です。LINEでも、ユーザーの写真をサーバーに永久保存していつでも閲覧できるようにしたアルバム機能を提供しています。LINEのアルバム機能は、2013年9月にオープンして今年で6年を迎えます。たくさんのユーザーが活発に利用しているため、サーバーに蓄積されるデータ量も膨大になっています。 写真や動画などのLINEのメディアデータは、すべてLINEのメディアプラットフォームが運営するメディアストレージ「OBS（Object Storage）」で管
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Raft
SUSTEN（サステン） | 理想の投資を完全自動化
