タグ

2018年7月12日のブックマーク (5件)

  • 静的解析の限界、現実世界との境界

    2018年に静的解析をとにかく強力につけまくるのは多分あんまりコストに見合わないのでよくない じゃあ静的解析を窓から投げ捨ててよいかというとそれはただの愚行 (以下、静的解析を普通に使えてる人には自明なことしか言いません) 私が最初に静的解析の限界を感じたのは多分依存型で遊んでいたとき 依存型の力はすごくて、まぁそれもそのはず命題論理から述語論理に進んで元への言及ができるので見かけ上表現力はとんでもなく上がるわけです。例えば「ある方程式を満たす解のみを受け取って何かする」みたいな関数が型として表現できるようになる。 一見すると最強に見えるんだけどこれは実質定理証明をすることなので、制限の強い型をつければつけるほど実装で苦しむ羽目になるということを割とすぐ痛感することになった。 例えば head : Vect (Suc n) a -> a で長さ1以上のvectorの先頭を安全に取り出す関数

  • Cacooの次期エディターでWebpackのビルドを6倍早くした話-Wepackビルドパフォーマンス改善ガイド | 株式会社ヌーラボ(Nulab inc.)

    こんにちは。みなさまがCacooで図の編集をするエディターを開発している、Cacooチームの国広です。Cacooチームでは、エディター部分のビルドに Webpack を使用しています。ビルド対象はTypeScriptJavaScript、PostCSS、Riot(のtagファイル)、画像等です。 そのままビルドするには少し我慢ならない程度に待たされるようになったので、Webpackの公式ドキュメントを見ながら少しだけビルドのパフォーマンスの改善を行いました。その結果、ビルドにかかる時間は当初のシンプルな構成に比べて6倍早くなりました。 対象読者 Webpackを使用している人 ビルドのパフォーマンスを改善したい人 Webpackのビルドパフォーマンス改善 ビルドとは何か 現在のCacooのエディターでは、いくつかのJavaScriptファイルをHTMLに読み込ませることでアプリを起動させ

    Cacooの次期エディターでWebpackのビルドを6倍早くした話-Wepackビルドパフォーマンス改善ガイド | 株式会社ヌーラボ(Nulab inc.)
  • Webpackでライブラリを作る - Qiita

    npmには多数のライブラリが存在しますが、自分でライブラリを作ろうとしたところ、正しい設定にたどり着くまでにちょっと手間取りました。 ライブラリの特徴 ブラウザやNode向けのプロジェクトの場合、ビルドした後は読み込んで使うだけなので、外部との関係性を考える必要はそこまで大きくありません。一方で、ライブラリの場合は、 ライブラリを読み込む側との連携(CommonJS、ES6 Module、AMD、UMD) ライブラリ内で使うライブラリの切り離し(そのままにすると、他のライブラリを取り込む形となってしまい、あとで依存ライブラリを差し替えることができなくなる) といった処理が必要となります。ただ、これらはWebpackでも実現できます。 ライブラリモードの利用(&エクスポート) まず、Webpackをライブラリのビルドに使いたい場合、output.libraryに名前を指定します。この名前は、

    Webpackでライブラリを作る - Qiita
  • neue cc - UniTask - Unity + async/awaitの完全でハイパフォーマンスな統合

    Unityでasync/await使えてハッピー。が、しかしまだ大々的に使われだしてはいないようです。理由の一つとして、Unityが標準でサポートする気が全くなさそう。少なくとも、Unityがフレームワークとしてasync/awaitには何一つ対応していない。async/awaitという道具立てだけじゃあ何もできないのです、フレームワークとして何らかのサポートがなければ機能しないわけですが、なんと、何もない……。 何もないことの理由はわからないでもないです。パフォーマンス面で不満/不安もありそうですし、マルチスレッドはC# Job System使ってくれというのは理にかなっている(私もそちらが良いと思います、つまりTaskのマルチスレッドな機能は原則使わない)。とはいえ、async/awaitは便利なので、このまま、便利だけど性能は微妙だから控えようみたいな扱い(あ、それ知ってる、LINQ

  • SQLiteのテストコードは4567万8000行! 本体のコードは6万7000行

    軽量なリレーショナルデータベースとして人気のSQLite。そのWebサイトに掲載されている「How SQLite Is Tested」の内容が、海外のプログラマなどのあいだで話題になっています。 3月に公開された最新バージョンのSQLite 3.6.23。体のソースコードは約6万7200行(67.2KSLOC、Kilo Source Lines of Code:空行やコメントを除いた行数)なのに対し、テストコードはなんと4567万8300行(45678.3KSLOC)だと紹介されているのです! これはテストコードが体の約679倍もの大きさだということになります。 100%のブランチカバレッジ SQLiteコアのライブラリをテストするテストコードとして、以下の3つが紹介されています。 TCL Tests TCL Testsはもっとも古いテストコードで、TCL scripting lang

    SQLiteのテストコードは4567万8000行! 本体のコードは6万7000行