サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
掃除・片付け
gfx.hatenablog.com
abstract: https://jsconf.jp/2019/talk/fuji-goro Wasmを触り始めるにはまだ少しはやくて、おそらく2020年にはリリースされるであろうSIMDなどがほしいところです。とはいえ、JSの最適化コンパイラ(スライドではV8のTurboFanにだけ触れていますがほかのJSエンジンでも基本的には同じ傾向なはず)に頼らず安定したパフォーマンスを出せるというのは大きなメリットなので、その方面だと現在の状況でも考慮に値する可能性はあります。 ところでスライドでも触れてますが、eBayのバーコードスキャナ事例は大変興味深いです。 WebAssembly at eBay: A Real-World Use Case ここのエントリでも次のように書かれていて This is sort of expected, as JavaScript can indeed be
2019年9月9日からFastlyに入社しています。勤務地は東京です。今後ともよろしくお願いいたします。 前職の Bit Journey, Inc. では3年ほどKibelaのサーバーサイドやフロントエンドアプリの開発に関わりました。Bit Journey在職中に子供がうまれ、現在も夫婦で分担しながら子育てをしていますが、この子育て初期という大変な時期*1にBit Journeyで気持ちよく働けたのはたいへんな僥倖でした。ここで改めて感謝いたします。 さて、Fastlyは方向性を変えて、ウェブアプリではなくVarnishやH2Oなどのミドルウェアの開発に関わります。 Kibelaは自分が数年のあいだ心血を注ぐにふさわしいサービスでしたし、実際のところ大いに開発を楽しみました。しかし、しばらく今後のキャリアの方向性を考えた結果、かねてから経験してみたいと思っていた低レイヤーなソフトウェア開発
発表の機会をいただきありがとうございました。会場を提供していただいたメルカリさんにも感謝いたします。 「AsssemblyScriptはTypeScriptのサブセットだから実質TypeScriptを書くだけでパフォーマンスアップ!」みたいな言説をみるにつけ、「ええ〜ほんとか〜??ほんとにやってみて言ってるんか〜??」と思っていたので、小規模とはいえ実際にやってみて検証&考察できたのはよかったなあと。 speakerdeck.com 特に、最適化JITの効きずらい状況(たとえばスタートアップタイムの高速化)での高速化に寄与する可能性を示唆できたのは大きな発見です。V8チームの目下の関心事はスタートアップタイムのようですし(ただしJSのダウンロード&パースなどの時間も含む)、FacebookもHermes Engineという新しいJSエンジンを開発してまでスタートアップタイムを改善しようとし
ちょっとまえに The cost of JavaScript in 2019 · V8 というブログが話題になりました。 このなかで次のように説明している箇所があります: As long as the JSON string is only evaluated once, the JSON.parse approach is much faster compared to the JavaScript object literal, especially for cold loads. (JSON stringを一度しか評価しないのであれば、オブジェクトリテラルよりも JSON.parse のほうがはるかに高速です。コールドロード(サイトの初回アクセス時、何のキャッシュも利用できないケース)では特にそうです。) この巨大なJSONリテラルは、たとえばwebpackの組み込み JSON lo
GraphQL APIのシリアライザとしてMessagePackを使うとGraphQLのcustom scalar typeを活用したくなりますね。ということで、graphql-rubyの ISO8601DateTypeを参考にMessagePackのtimestamp型にシリアライズ・デシリアライズできるようにします。 これまでの話 GraphQLとMessagePackは相性がよさそう - Islands in the byte stream msgpack-ruby に timestamp型を実装した - Islands in the byte stream コード # frozen_string_literal: true module Types class DateTime < GraphQL::Schema::Scalar description "A datetime ty
timestamp型というのは2017年8月にMessagePackに追加された型です。 frsyuki.hatenablog.com しかし、おそらくMessagePack開発元がtimestamp型を使っていないためか、長らく msgpack-ruby には実装されていませんでしたし、msgpack-java の実装もpull-request はあるもののマージされていません。 ところでKibela Web APIはMessagePackをサポートしています。 github.com ここでGraphQLのDateTIme型をMessagePackのtimestamp型で表現したくなったので msgpack-ruby にもtimestamp型を実装しました。 MessagePack timestamp type by gfx · Pull Request #168 · msgpack/m
MessagePackはJSONのようなデータをシリアライズできるbinary formatで、JavaScript実装である msgpack-javascriptを基準で考えると次のような特徴があります: JSONよりencodeもdecodeも少し速い かつ、streaming decodeができるので fetch() のresponseのdecodeの効率がとてもよい とはいえ実用上は「JSONより遅くない」ということのほうが重要ではある binaryを直接扱える これに対してJSONでbinaryを扱うときははbase64などでエンコードする必要がある timestamp型があり、デフォルトではJSのDateにマッピングされる Intl.DateTimeFormatへの入力としてならこれで必要十分 マッピングをあとから変えることはできる 特にバイナリを直接扱えるのはJSONとくらべ
ブラウザ互換性表 (a.k.a. browser matrix) とは、こういうやつです。 ブラウザ互換性表 powered by Sauce Labs TypeScriptで MessagePack encoder/decoder を実装した - Islands in the byte stream で作った msgpack/msgpack-javascript にこのバッジをつけようとして苦労しました。今回は単に一度やってみたかったというのもあって頑張りましたが、いろいろ大変だったので記録を残しておきます。 しかし、どんなプロジェクトでもやるべきかというと微妙で、ブラウザの機能に大きく依存するライブラリでもない限りはバッジは頑張らなくてもいいかなあという結論です。ブラウザに依存した機能をもっと多用するのであれば、バッジの価値があるのかもしれません。 今回はブラウザテストをはじめてから1
npm install @msgpack/msgpack でインスコできます。NodeJS v12 でベンチマークしたかぎり、JSONと同程度の速度で、これまで最速といわれてきた msgpack-lite よりもさらに少しだけ高速です。 github.com もともとこのリポジトリには uupaaさんによる実装(tagged as classic) があったんですが、メンテされなくなって久しく npmjs.com にもリリースされていないという状況でした。 https://github.com/msgpack/msgpack-javascript/tree/classic その後kawanetさんが msgpack-lite を実装したのが2015年。これが2019年現在、もっとも週間ダウンロード数の多いMessagePack for JSの実装です。 msgpack-lite ピュアJa
employment.en-japan.com 「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶ に引き続き、TypeScriptの記事を書きました。 TypeScriptに苦手意識を持っている人に向けて再び触るきっかけを作りたいと考えて書いたので、細かい言語仕様にはまったく触れてませんが、「ああこれならやってみてもいいな」と思ってもらえたら幸いです。
TypeScriptのコンパイラ・プラグインとして振る舞いASTの操作を行えるcustom transformer (AST preprocessor) が実装されたのは TypeScript 2.4 (2017年) でした。 そのときの様子は次のエントリに非常によくまとまっています。 [TypeScript 2.4] custom transformer を利用して実行時に型情報を参照可能にする - Qiita さて、現在のTypeScript v3.3 でのTransformer APIの状況はというと、TypeScript compiler本体としては依然としてドキュメントに乗ってない水準の扱いです。特に、コンパイラAPI そのままではtransformerは型情報を利用できません。ts.TransformerFactory に渡される ts.TransformationContex
表題のとおりで、fetch(...) はエントリが存在しないと例外を投げるため、エントリが存在しないときに nil を返すアクセサよりもtypoに対して安全です。 こういうのは rubocop-rails でカバーできるといいなと思って起票して、良さそうというコメントはもらったんですが: https://github.com/rubocop-hq/rubocop-rails/issues/42 いかんせん rubocop-hq/rubocop-rails 自体がまだ開発中なのでいつ使えるかわかりません。 こういうときにquerlyを使うといいですね。 (cf. プロジェクト固有のルールを指定できるLinterであるところのQuerlyがめちゃ便利 - Islands in the byte stream) というわけでruleはこんな感じです。 rules: - id: kibela.pr
ユースケース Excelから社内ブログやWikiに表をコピペしたい 実装 とりあえず paste イベントをうけて処理するのでそのようにする。今回はCodeMirrorで制御されているtextareaなので、CodeMirrorを使ってないない場合は適宜読み替えてください。 ClipboardData pasteで発行されるClipBoardEventに clipboardData: DataTransfer プロパティがあります。 spec: https://www.w3.org/TR/clipboard-apis/ // Web IDL dictionary ClipboardEventInit : EventInit { DataTransfer? clipboardData = null; }; こいつが items: DataTransferItemList をもっています。 /
ないと困るので、 polyfillをつくりました。MediaQueryList すら実体がないので、やむをえず mathMedia() を上書きしています。 // MediaQueryList.prototype.addEventListener.ts if (typeof matchMedia !== "undefined" && !matchMedia("all").addEventListener) { console.log('installing polyfill: MediaQueryList.prototype.addEventListener'); const originalMatchMedia = matchMedia; self.matchMedia = function matchMedia(mediaQuery: string): MediaQueryList {
追記: この件に関してエンジニアHubにもTypeScriptの記事を書きました: TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に - エンジニアHub|Webエンジニアのキャリアを考える! TypeScriptに対する失望は2パターンあって、その理由は理解できるのですが、いずれにせよそこでTypeScriptを捨てる判断をするのはもったいないと思っています。この2つの失望を感じたとしてもなお、TypeScriptには導入する価値があると思っています。 パターン1: 実はJavaScriptに対する失望である そこらのブログやTwitterで観測していると、理由の7割くらいこれです。これは、TypeScriptが独立した言語ではなくJavaScriptへのトランスパイラ(言語変換ツール)であり、独立したランタイムを
書きました*1。 employment.en-japan.com GraphQLという規格そのものについての解説が前半で、後半はRailsアプリのWeb APIをRESTful APIからGraphQL APIに書き換えるというハンズオンです。 GraphQLの特徴やら Swagger, gRPC, etc との比較はわりとよく見かけるので、そのあたりについては最低限触れるにとどめて、GraphQLという規格について知るための入門記事として書きました。特にRelay (Relay Server Specification) についてはあまり日本語の説明を見ないので、この記事できちんと紹介できてよかったなと思っています。 サンプルコードは https://github.com/gfx/graphql-blog にあります*2。 この記事は結構長いんですが、それでも発展的な使い方に触れる余裕は
追記: 加筆修正してGitHub projectにしました: https://github.com/gfx/android-oss-best-practices paper.dropbox.com (potatotips #56 (iOS/Android開発Tips共有会) - connpass) 久しぶりのpotatotipsでのLTでした。 「OSS開発のリテラシー」は他の言語版もほしいですね。誰か書いてくれないかな〜|д゚)チラッ
追記: Apollo Boost は Apollo Client に統合される見込みのようです。Apollo Client 3.0 Roadmap · Issue #33 · apollographql/apollo-feature-requests · GitHub TypeScript用のGraphQL clientであるところの Apollo ですが、これのGet Startedなどのドキュメントでは apollo-boost というパッケージを使っています。 www.apollographql.com しかし、 apollo-boost はサンプルコードをシンプルにするための apollo-client などのラッパーと考えたほうがよく、プロダクションコードでは apollo-boost ではなく apollo-client および関連モジュールを直接使うほうがいいです。 以下理由
追記: Terser v3.10.11 でこの問題が修正されていることを確認しました。現在は collapse_vars: false というワークアラウンドは不要になりました。 webpackのproduction buildの話です。 Reactが悪いわけではないんですが、たまたま秘孔をつくコードがReactないし関連するReact v16に依存するライブラリにあったんでしょうね。 Reactをv16にアップグレードしたら webpack で production build ができなくなった pluginを着脱しながら調べた結果、 uglifyjs がクラッシュしていることがわかった uglifyjs は現在 オリジナル + 2つのforkがあり、すべてで再現する original: https://github.com/mishoo/UglifyJS fork 1: https:/
Sider社の開発する Querly を使うと「歴史的経緯の説明」をコード化できるよという話です。 Querlyの話は以前も書いたことがあります: プロジェクト固有のルールを指定できるLinterであるところのQuerlyがめちゃ便利 - Islands in the byte stream Querlyは便利で可愛いやつなんですが「価値がわかる」ところに到達するのが難しいツールなので(ぼくなんて2年かかってようやく理解できましたからね!)、もうちょい公式ドキュメントがわかりやすくなるといいな〜と思いますね。あと querly init がほしい。
ある特定のファイルのテストカバレッジが、ある特定のテストファイル(群)を実行したときに一定のカバレッジ率であることを保証したいと思うことはありますか?私はあります。 そこで、 次のような spec/coverage_helper.rb を用意して、 spec/rails_helper.rb などから require すると、 COVERAGE_ASSERTION=app/models/ability.rb rspec spec/models/ability_spec.rb:99 のようなコマンドをCIで実行したときに一定のテストカバレッジ以下のときにCIがコケるようにしました。 # frozen_string_literal: true class CoverageAssertion class CoverageAssertionFailure < StandardError end at
github.com cmake-js という cmake のラッパーを使うと、 node-gyp を使わずに NodeJS native addon を作れるみたいです。 node-gyp は Python 2.x に依存しているのが嫌なので、 node-gyp 依存をなくせるというだけで個人的にはけっこう嬉しかったりします。 ついでに NodeJS native addon の新しい C++ API であるところの N-API もちょっと試してみました (src/hello.cc)。これは、 NodeJS のJSエンジンである V8 API を抽象化して、V8 API のバージョンごとの差異を吸収する API layer です。N-API 登場以前の NodeJS native addon は NodeJS / V8 のアップデートですぐビルドできなくなっていたものですが、 N-API
https://github.com/soutaro/querly Rubyを構文解析したASTに対して独自DSLでパターンマッチ&メッセージを出すツール プロジェクト固有の事情に配慮したLinterとして使える false positive 上等で注意喚起として使う たとえばKibelaの querly.yaml から一部抜粋するとこんな感じです。 rules: # ... - id: kibela.order_by_string pattern: - "order(:dstr:)" - "where(:dstr:)" - "find(:dstr:)" - "exists?(:dstr:)" message: "文字列によるSQL構築は本当に必要ですか? SQL Injection を引き起こさないように気をつけてください。" - id: kibela.block_call patter
1行で 「特定の場合でバージョニングしなくても対応できることはある」程度なので、「バージョニング不要」とは言わないほうがよい どういうことか RESTful API から GraphQL へ、GraphQL から別の Web API systemへ、ということを考えると大きな意味でのバージョニングは必要 e.g. 実際にGitHub は GraphQL API を "API v4" と呼んでいる 細かなレベルのバージョニング、たとえば1画面の仕様が微妙に変わるたびに /foo, /foo_201807_1, foo_201807_2 みたいにどんどん特定画面専用APIを定義していく、みたいな意味でのバージョニングは不要 fieldの追加は無造作に行ってよい RESTful APIでもfieldの追加は普通はできる、ただし負荷に注意 重いcomputed fieldの場合でも、GraphQL
DX: Developer Experience (開発体験)とは、あるシステムを「気持ちよく開発・保守できるかどうか」を示すもの 開発者は開発・保守という行為を通じたそのシステムのユーザーであり、DXはUXの一種である DXがよいと日々の開発を楽しめるようになり、気持ちに余裕ができる 気持ちの余裕がでるとコードの品質があがり保守時のデグレも減らせる また、DXがよい事自体がDXを高める動機になり、正のスパイラルを見込める つまり、「定められたタスク」(=義務)以上のことを行うようになる DXが悪いと開発を楽しめず、「定められたタスク」以外のことをしたくなくなる DXは放置すると悪化するので、「DXがよくも悪くもない」プロダクトは時間が経つに連れ「DXが悪い」になる なので積極的にDXを良くしていく活動を奨励していくのがよい いくつか興味深いフィードバックがあったので記しておきます。 DX
最近、Kibelaのtslint configの Rule: array-type を "generics" にしました: + "array-type": [ + true, + "generic" + ], 以前は特に指定しておらず、 T[] と Array<T> が混在してていて、それでよしとしていました。今でも、混在することによるデメリットは特にないと思っていいます。ただ、 Array<T> には一つだけメリットがあったのでこちらに統一することにしました。 autofixできるので、エディタ上では T[] と書いて保存時にtslintに Array<T> に直させるということができるため、導入のデメリットがないというのも大きいです。 さて Array<T> のメリットは、 ReadonlyArray<T> に直しやすいということです。 ReadonlyArray<T> は Array
scrapbox.io graphql-ruby の知見をまとめはじめた。 / “GraphQL for Ruby” https://t.co/PqotLzAdtV— FUJI Goro (@__gfx__) 2018年6月10日 なんで graphql-ruby 限定かというと、graphql-ruby はいくつかの独自機能(e.g. complexityベースのAPI制限)があったGraphQL schemaをまったく知らなくても開発できたり、と、他の言語(特にJS)とは開発体験がだいぶ違いそうだからです。— FUJI Goro (@__gfx__) 2018年6月10日
追記(2019/03/18): yarn-toolsからyarn-deduplicateが独立して使いやすくなり、 --strategy でdedupeの方法を選べるようになっています。タイトルも変更しました。 yarnpkg(1) を使って依存関係を管理しているとき、 yarnpkg upgrade-interactive は対話的にライブラリのアップデートができるので大変便利です。しかし、これを実行すると yarn.lock に不必要に重複エントリが作られることがよくあります。 nodejsで実行するケースでは重複があっても問題がないことが多いのですが、 クライアントサイドでは重複があると単純にファイルサイズが大きくなり。また、@types/* や react, jquery といったフレームワークはどの環境でも動作に問題が出たりするので、重複エントリは問題です*1。そこで今までは、
追記(2019/08/23): https://github.com/nodejs/node/issues/19214 によると、将来的にはfull-icuビルドがデフォルトになりそうです。 gfx.hatenablog.com 上記エントリの続きです。 その後調べた結果、 full-icu というNPM moduleでfull-icu相当のデータをインストールできることがわかりました。 https://github.com/unicode-org/full-icu-npm 中身については精査していませんが、 unicode-org が提供しているものなのでそれなりに信頼できるでしょう。 このモジュールをインストールすると node-icu-data-path(1) が提供されるので、それで得たパスを NODE_ICU_DATA 環境変数にいれるとnodejsの Intl APIで日本語を
次のページ
このページを最初にブックマークしてみませんか?
『Islands in the byte stream』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く