タグ

2016年2月23日のブックマーク (9件)

  • Google Chromeが採用した、擬似乱数生成アルゴリズム「xorshift」の数理

    2015年12月17日、Google ChromeJavaScript エンジン(処理系)である V8 の公式ブログにて、 JavaScript の標準的な乱数生成APIである Math.random() の背後で使われているアルゴリズムの変更がアナウンスされました。 Math.random() 関数は JavaScript を利用する際には比較的よく使われる関数ですので、親しみのある方も多いのではないかと思います。 新たなバグの発見や、従来より優秀なアルゴリズムの発見によってアルゴリズムが変更されること自体はそれほど珍しくはないものの、 技術的には枯れていると思われる Math.random() のような基的な処理の背後のアルゴリズムが変更されたことに驚きを感じる方も少なくないかと思いますが、 それ以上に注目すべきはその変更後のアルゴリズムです。 実際に採用されたアルゴリズムの原

    Google Chromeが採用した、擬似乱数生成アルゴリズム「xorshift」の数理
  • 【翻訳】/binと/usr/binが分裂してる訳 - みっどメモ

    Translation of "Understanding the bin, sbin, usr/bin, usr/sbin split" Posted by midchildan on May 22, 2015 1969年、どのようにケン・トンプソンとデニス・リッチーはPDP-7でUnixを開発したか知っているだろうか。実は1971年に彼らは1.5MBのRK05ディスクパックを2つ搭載したPDP-11にアップグレードした。 彼らのOSが大きくなり、ルートファイルシステムとして使ってた1個目のディスクに収まりきらなくなったとき、保存しきれなくなったファイルは2個目のディスクに移した。このディスクにはもともとユーザーのホームディレクトリが保存されてたために /usr という名前でマウントされていた。こうして第二ディスクに /bin , /sbin , /lib , /tmp などOSのディレ

    【翻訳】/binと/usr/binが分裂してる訳 - みっどメモ
  • MacにUbuntuを入れるとOSXより起動が速い - Money Forward Developers Blog

    最近中途入社した卜部です。よろしくおねがいします。諸事情にてLinuxを使います。Macで。 結論からいうと OSXより起動が速いです。 経緯など 弊社はお客様の大切な情報を扱っています。情報セキュリティにはとても気を遣っています。通常であれば意味もなくOSの再インストールなどは行いません。 とはいえ卜部の業務は社業とは直接関係しません。そもそもお客様の大切な情報といったものに卜部がアクセスできてしまう方がリスキーといえます。そこで「production環境にそもそもログインできなくする」「オープンソースではないソースコードをそもそもgit cloneしないようにする」等の運用方針で、リスクをじゅうぶんに低減できると考えたため、普段使いのパソコンとしてLinuxを利用できるか試してみることにしました。 今回はMacに最初から入っているOSXを全部消してUbuntu Desktopを入れるこ

    MacにUbuntuを入れるとOSXより起動が速い - Money Forward Developers Blog
  • Engadget | Technology News & Reviews

    Research indicates that carbon dioxide removal plans will not be enough to meet Paris treaty goals

    Engadget | Technology News & Reviews
  • 新規事業の成長を支えるRuby // ruby-business-users-conf-2016 // Speaker Deck

    Ruby Business Users Conference 2016 https://rubyassociation.doorkeeper.jp/events/36358 2016-02-23 (火)

    新規事業の成長を支えるRuby // ruby-business-users-conf-2016 // Speaker Deck
  • OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る

    はじめに この文書では、OAuth 2.0 + OpenID Connect サーバーをゼロから一人で実装した開発者(私)が、得られた知見について書いていきます。基的には「実装時に考慮すべき点」を延々と述べることになります。 そのため、この文書は、「素早く OAuth 2.0 + OpenID Connect サーバーを立てる方法」を探している方が読む類のものではありません。そのような情報をお求めの方は、「Authlete を使って超高速で OAuth 2.0 & Web API サーバーを立てる」を参照してください。そちらには、「何もない状態から認可サーバーとリソースサーバーを立て、アクセストークンの発行を受けて Web API をたたいて結果を得る」という作業を、所要時間 5 ~ 10 分でおこなう方法が紹介されています。 文書のバイアスについて 私は、OAuth 2.0 + Ope

    OAuth 2.0 + OpenID Connect のフルスクラッチ実装者が知見を語る
  • 分散プログラミングモデルおよびデザインパターンの考察 その3 - Software Transactional Memo

    昨日に引き続いて分散システムのデザインパターンについて書いていきたい。 だがそれ以前に故障モデルに関する前提を忘れてはならない。人によって様々な方針があるが、個人的には分散システムの世界において意識しなくてはならない故障モデルは4つだと考えている。僕は前回のブログに書いた Replication のをベースに書いており、少し言葉遣いや定義が他とやや違う点は許して欲しい。また、通信の脱落・遅延とはレイヤーが異なる議論である。 故障モデルの分類 故障が起きないモデル これは故障が起きない世界を仮定するモデルである。これ自体はプロダクションにそのまま投入できるものではない。だがこの故障モデルを想定しても解けない問題は故障が発生する状況では絶対解けない事が断言できたり、合意プロトコルが正しいかを議論する土台となったり、様々な実用的なアルゴリズムや分散システムの土台となるアルゴリズムが生まれる土壌

    分散プログラミングモデルおよびデザインパターンの考察 その3 - Software Transactional Memo
  • 分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo

    前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか?」「データフローは

    分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo
  • Let's Encrypt -- What launching a free CA looks like [32c3]

    Let's Encrypt -- What launching a free CA looks like Let's Encrypt is a new free and automated certificate authority, that entered closed beta in October and has already issued a large number of valid certificates. This talk will provide a short overview of how the Let's Encrypt client and server software work, and explore statistics gathered during our closed beta and launch period. Let's