ID生成大全 - Qiita
セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い
RSAの終わりの始まり - 暗号移行再び - Qiita
前振り 全国の暗号を使うエンジニアの皆さんこんにちは。今日は暗号移行とRSA暗号の話をしたいと思います。まず暗号を利用している皆さんであればCRYPTRECの「電子政府推奨暗号リスト」のことはご存じですよね！（言い切るw） CRYPTRECから2022年7月（昨年夏）に暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準（PDF直リンク）が公開されました。この中では暗号のセキュリティ強度で各種暗号と鍵長が整理されています。セキュリティ強度はビットセキュリティと呼ばれるビットサイズ（共通鍵暗号の場合のビット長）で区分されます。暗号アルゴリズムが違ってもセキュリティ強度で比較ができるということですね。例えば現在一般的に良く使われているセキュリティ強度は112ビットセキュリティが多く、これにはデジタル署名であればRSA暗号の2048ビットやECDSAのP-224等が含まれます。今日は公開鍵暗
Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理 - Qiita
Concurrent Modeは、現在（2020年3月）実験的機能として公開されているReactの新しいバージョンです。Reactの次のメジャーバージョン（17.x）で正式リリースされるのではないかと思っていますが、確証はありません。なお、React公式からもすでに結構詳細なドキュメントが出ています。 並列モードの導入（実験的機能） Concurrent Modeに適応したアプリケーションを作るためには、従来とは異なる新しい設計が必要となります。筆者はConcurrent Modeを使ったアプリケーションをひとつ試作してみました。この記事から始まる「Concurrent Mode時代のReact設計論」シリーズでは、ここから得た知見を共有しつつ、Concurrent Mode時代に適応したReactアプリケーションの設計を提案します。 なお、Concurrent Modeはまだ正式リリース
WHATWG Living StandardとHTMLパーサ - Qiita
この記事はドワンゴ Advent Calendar 2020 最終日の記事です。年の瀬ですね。 はじめに 本記事は、WHATWG Living Standardに準拠することを目的としたHTMLパーサである「gammo」の紹介を目的としている。gammoが実現していることを詳細に伝えるため、単なるgemの紹介に留まらず、HTMLの歴史や昨今のHTMLを取り巻く状況を簡単に解説し、WHATWG Living StandardにおけるHTML文書の解析アルゴリズムについて、実例と共に紹介する。 本記事で紹介するgammoの開発に取り掛かった理由は、主に以下の二点が挙げられる。 WHATWG Living Standardに準拠したHTMLパーサをRubyGemsの中から見つけられなかったため。 現在HTMLパーサの機能を持つライブラリの中で、最も利用されていると考えられるNokogiriと比較
Self-Attentionを全面的に使った新時代の画像認識モデルを解説！ - Qiita
08/31 (2020): 投稿 08/31 (2020): 「畳み込みを一切使わない」という記述に関して、ご指摘を受けましたので追記いたしました。線形変換においては「チャネル間の加重和である1x1畳み込み」を実装では用いています。 08/31 (2020): 本論文で提案されているモデルの呼称に関して認識が誤っていたためタイトルおよび文章を一部修正しました。 言葉足らずの部分や勘違いをしている部分があるかと思いますが、ご指摘等をいただけますと大変ありがたいです。よろしくお願いします！(ツイッター:@omiita_atiimo) 近年の自然言語処理のブレイクスルーに大きく貢献したものといえば、やはりTransformerだと思います。そこからさらにBERTが生まれ、自然言語の認識能力などを測るGLUE Benchmarkではもはや人間が13位(2020/08現在)にまで落ちてしまっているほ
2億資金調達してから二年、結構量子コンピュータ頑張った結果 - Qiita
はじめに 2008年に起業してからコツコツやっていましたが、2014年くらいから量子コンピュータの研究開発をがんばりました。資金調達もしてある程度技術に目処がついたのと、若者から起業したいという相談をよくもらうので、まとめておきます。 経営は大事 簡単にいうとベンチャーをやろうとしたら技術よりもキャッシュが大事です。なので、財務や経営感覚がついてから技術をつけないと結構大変と思います。特に1年目は慣れない事務に忙殺されますし、二年目以降はキャッシュが厳しくなります。 あとは、最初は経営に夢見て舞い上がりがちなので、その気持ちがおさまって厳しさが一通り身についたところからが本番です。 調達の前に譲渡 2008年から10年くらいはコツコツ会社をやっていた上、そんなに頑張るタイプでもなかったのですが、たまたま2014年からやっていた量子コンピュータのニュースが巷で新聞に載るようになってから、周辺
AVX-512を用いた、たぶん世界最速のBase64エンコード実装について - Qiita
この記事で紹介するのは高スループットなBase64エンコードの実装方法です。 Base64は、Webの世界を始めとして、世界中さまざまな箇所で使われているエンコード方式です。とてもよく使われるので、高速化についてもしばしば研究されてきたようです。 高速化の最新成果として、2019年10月に、Wojciech Muła, Daniel Lemireによる新しい論文がarxivに投稿されました。なかなか強烈なタイトルが付いています。 Base64 encoding and decoding at almost the speed of a memory copy 論文の主張としては、x86 CPUの持つ最新の命令群を駆使することで、非常に高効率なBase64エンコード・デコードが実現できたというものです。このQiita記事では論文の内容の一部を紹介します。 Base64は問題としては単純に見え
「サイゼリヤで1000円あれば最大何kcal摂れるのか」を量子アニーリング計算(Wildqat)で解いてみた。 - Qiita
こんにちは！初投稿です！ この記事が誰かに何かでためになれば幸いです！ 背景 僕は先日、この記事↓↓を読んでふと思いました。 サイゼリヤ1000円ガチャをつくってみた(Heroku + Flask + LINEbot) 「サイゼリヤで1000円あったら最大で何kcal取ることができるんだろう？」と。 最近、最適化計算を得意とする量子アニーリングの勉強を始めたこともあって、ナップザック問題をそのまま使えば、計算できるんじゃないか？と思い、早速実験してみました。 ナップザック問題とは ナップザック問題とは重量制限のあるリュックに、値段と重さが定義されたアイテムを詰め込むとき、値段を最大化させるアイテムの組み合わせは何か？というものです。 今回は、重量ではなく値段に制限があり、アイテムの価値でなくkcalを最大化させるので ・アイテムの重さ → メニューの値段 ・アイテムの価値 → メニューのキ
JWTライブラリの危機的な脆弱性について調べた - Qiita
JWT 脆弱性 で検索すると 【翻訳】JSON Web Tokenライブラリの危機的な脆弱性 って記事(4年ぐらい前の記事)が出てきて読んでいたのですが、よくわからなかったので手を動かしながら調べてみました。 ※ 翻訳の元記事はこちら node-jsonwebtoken, pyjwt, namshi/jose, php-jwt, jsjwtを非対称の鍵(RS256, RS384, RS512, ES256, ES384, ES512)で使っている場合、最新のバージョンに更新してください。 とのことなので、バージョン更新で直ったようなので修正を読んでいきます。 また、 js を利用して開発する機会が多いので node-jsonwebtoken の修正を確認してみます。 確認したコードは下記にあります。 https://github.com/OshiroSeiya/jsonwebtoken-a
とても強い計算量クラスのコンピュータとその実現方法 - Qiita
この記事は武蔵野アドベントカレンダー19日目の記事です。 物理のステートメントはだいぶ雑ですが、計算のステートメントには一応正確さに気を使って書いているつもりです。何か誤りがあった場合は、@iKodackまでご連絡いただけると幸いです。 (2018/12/22に「宇宙破壊コンピュータはセールスマン巡回問題の最適化問題を解けるか？ 」「時間遡行コンピュータで無限ループすると何が起きるか？」を記事末尾に追加しました。) (2018/12/28に「宇宙破壊コンピュータは答えが無い場合に全ての宇宙を破壊する？」について記事末尾に追加しました。) 前書き より速い計算機が欲しい、という欲求は全ソフトウェアエンジニア共通であることが知られています。 最近、業務において500GBのSSDや16GBのメモリを最低水準にするべきではないか、という議論がネットで活発になされていますが、生産性を限界まで高める限
結局、機械学習と統計学は何が違うのか？ - Qiita
これは私達の行っているデータサイエンスのトレーニングで、日本でもグローバルでもよく聞かれる質問です。実は2年ほど前にこの質問に正面から真摯に答えていた"Machine Learning vs. Statistics"という、とても素晴らしい記事があるのですが、今日は、そちらの記事をみなさんに紹介してみたいと思います。 ちなみに、筆者のTom FawcettとDrew HardinはSilicon Valley Data Scienceというデータサイエンスのコンサルティング会社で、多くの有名企業がデータサイエンスを使ってビジネスの問題を解決するための支援を行っていました。ちなみに、その会社の方は去年、Appleに買収されています。さらに、Tomは、「Data Science for Business」(翻訳書：戦略的データサイエンス入門 ―ビジネスに活かすコンセプトとテクニック）という有名
AIのプロジェクトを始めるとぶち当たる5つのハードル - Qiita
現在AIに対して多くの人がもつイメージとして、Over Estimate(過剰な期待) とUnder Estimate(過小な期待)という問題があります。Over Estimate(過剰な期待)はAIを使うと全ての問題が自動的に解決されるというもので、Under Estimate(過小な期待)はAIを使えば実は簡単に解決される問題なのにそのことに気づいてもいないということです。 今日では、比較的簡単にAIを使うことのできるツールがたくさんあるので、こうした機会を利用して、自分たちのデータをもとにどんどん使ってみて、AIを使うと実際に何ができて、何ができないのか、さらにどういったことが問題になるのかなどを理解していくことで、自分なりの正しい期待値を設定していくことが重要だと思います。 最近マッキンゼーから実際にAIのプロジェクトを始める時につまずくよくある５つのハードルとそれを解決するための
全盛期のJeff Dean伝説 - Qiita
Jeff Deanとは GoogleのSenior Fellow. Googleの基盤となる分散システムのほぼ全てに中心的に関わり、圧倒的なエンジニアリング能力を発揮したらしい。あまりにも尊敬されているため、IT業界において全盛期のイチロー伝説のような破天荒なホラ話のネタにされている人。 日本語での紹介がなさそうだったので意訳してみました。 元ネタはこちら。多すぎるのでGoogle社員じゃない人には面白みがわかりにくそうなもの、面白みが被っていると私が判断したものなどは省いてあります。 全盛期のJeff Dean NP問題 Jeff DeanがGoogleの採用面接を受けたときに、もしP=NPが成り立つとしたらどうなるかを問われて"P=0かN=1ですね"と答えた。試験官が笑い終わりさえしないうちに彼はGoogleのpublic keyを突き止め、private keyをホワイトボードに書き
とても長い配列の上位M件だけをクイックソートより高速に取り出す - Qiita
というわけで、10倍の差がでた。 当然、配列の長さやソートする長さ、また実装の方法によって性能差は変わってくるが 今回の方法は有効であるということは確認できた。 既存の記事(2015/11/09 20:22 追記) コメント欄でUnordered partial sorting にそれらしきことが書いてあると教えていただいた。 そちらでは、「上位k個を取り出す（ソートは不要）」という問題を考えている。 同様に分割統治法を用いてソートしていきながら、上位k個以内の小区間になったらその区間はソートせずに全て選択して良いとしている。 早い話が、QuickSelectによりk+1番目の要素を探してそれより上位の要素をごそっと抜き出している。 分割統治法で大雑把にソートしていきながら、不要なソートを行わないようにする という同様のアプローチである。 C++のSTLの場合(2015/11/09 22:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
