タグ

2017年12月25日のブックマーク (7件)

  • FAQs - Lockbox Extension

    Rockridge
    Rockridge 2017/12/25
    Firefoxの次世代パスワードマネージャは、パスワードの生成機能を備えるほか、Firefoxアカウントでのサインインを前提に、クラウドへのバックアップも行えるようになりそうだ。
  • Firefox Lockbox alpha by Mozilla replace built-in password manager - gHacks Tech News

    Rockridge
    Rockridge 2017/12/25
    Firefoxの次世代パスワードマネージャでは、最新の暗号化技術によってパスワード等が保護される一方、Firefoxアカウントによるログインが必須になるかもしれない。
  • Intent to implement: support CSS paint-order for HTML text

    Google グループでは、オンライン フォーラムやメール ベースのグループを作成したり、こうしたフォーラムやグループに参加したりすることで、大勢のユーザーと情報の共有やディスカッションを行うことができます。

    Rockridge
    Rockridge 2017/12/25
    Fx59:SVGで実装済みのpaint-orderプロパティがHTMLテキストでもサポートされる見込み。参照:https://bugzilla.mozilla.org/show_bug.cgi?id=1426146 http://takenspc.hatenablog.com/entry/2013/12/12/010350 / Fx60に延期された。
  • 巨大 WebAssembly ファイルのコンパイル時間

    funcs というのは、wasm 内に何個関数が入っているか、です。1 func の場合は Function body が約 25Mb、100,000 funcs の場合は約 2.5kb、500,000 funcs の場合は約 0.5kb です。 Chrome では 20秒〜1分 ほどかかっています。なおこのコンパイル処理は現在の Chrome の実装だとページをロードする度に必ず発生するので、巨大 WebAssembly が存在するページを Chrome で開いた場合、キャッシュの有無等と関係なく相当待つ必要があります。 Firefox だと、Function Body のサイズによって処理時間が大きく変わります。1 つしか関数がないときはクラッシュしましたが、Function Body が小さくなるにつれて速度が向上しています。例えば Emscripten 等で出力される巨大な Web

    Rockridge
    Rockridge 2017/12/25
    「Unityなどのゲームエンジンなどで普通に出力される」数十MbのWebAssemblyファイルは、「現在のブラウザだと起動までに大変時間がかかってしまい」、「『タップしてすぐに起動』という世界には遠いのが現状です」。
  • AssemblyScriptを使ってTypeScriptのコードを早くしよう - Qiita

    TL;DR; AssemblyScriptを使うと、TypeScriptコードをWebAssemblyに変換できます。オブジェクト指向プログラミングをしている場合は、オブジェクトが保存されるメモリ領域を自分で管理しなくてはならないので、その手間とのトレードオフを見極めてください。 なお、使用しているascのバージョンは 0.9.2 です。 C書けない私にWebAssemblyをつくれと言われましても WebAssembly(以下、WASM)とはWebブラウザで動くプログラムのバイナリ表現です。Safari, Edge, Chrome, Firefoxと、モダンなWebブラウザへの搭載も終わり、格的に利用できるようになってきました。その特徴はスピードです。ネイティブに近いスピードで動作します。画像処理やエンコード、暗号といったCPUの処理能力に依存するような処理を行うモジュールをWebAs

    AssemblyScriptを使ってTypeScriptのコードを早くしよう - Qiita
    Rockridge
    Rockridge 2017/12/25
    AssemblyScriptを使うと、TypeScriptをほぼそのままWebAssemblyへと変換できるので、C/C++が書けなくてもWebAssemblyの力を利用できるようになるとのこと。
  • 意図的にプログラムの動きをランダムにしてバグを早期発見するテクニックについて|Rui Ueyama

    プログラムを書いていると、素直に実装した結果として毎回特定の条件が満たされているけど、来それは誰も保証してないという場面に出くわすことがよくある。保証されていない偶然の動作に依存することで生じるバグというのはかなり多い。 例えば最近では、ドラゴンボールZ ドッカンバトルというゲームで、2回SQL文を実行した結果が同じ順序で並んでいるという誤った期待をしているコードがあったせいで、ガチャの確率表示がめちゃくちゃになってしまって、運営が確率操作しているのではないかという騒動が発生したことがあった [1]。データベースでは空のテーブルにデータを追加してその直後に読み返すと、データを追加した順番に結果が返ってきたりしがちなので、問題のコードはきれいなテスト環境では偶然うまく動いてしまったのだろうと思う。 上のようなバグを防ぐために最近よく使われているのは、来保証しないところをわざと壊すという方

    意図的にプログラムの動きをランダムにしてバグを早期発見するテクニックについて|Rui Ueyama
    Rockridge
    Rockridge 2017/12/25
    次世代TCPともいうべきQUICプロトコルでは、「コネクション確立の最初のネゴシエーションのときに、サーバは(注:バージョン番号に関し)ランダムなダミー番号をレスポンスに入れることが推奨されている」。
  • HTML 5.2 is now a W3C Recommendation

    The Web Platform Working Group has published a W3C Recommendation of the HTML 5.2 specification that would obsolete the HTML 5.1 Recommendation. The HTML 5.2 specification defines the 5th major version, second minor revision of the core language of the World Wide Web: the Hypertext Markup Language (HTML). In this version, new features continue to be introduced to help Web application authors, new

    HTML 5.2 is now a W3C Recommendation
    Rockridge
    Rockridge 2017/12/25
    2017年12月14日、HTML 5.2の仕様がW3C勧告となった。