タグ

ブックマーク / mizchi.hatenablog.com (5)

  • Flutterのコミットログを読んで、これは一体何由来なのか調べた - mizchi's blog

    当に凄い雑にコミットメッセージと気になったdiff だけ読んだ感じなので正確性は保証しません。 Flutterの実態、Chrome と同じく描画エンジンの Skia を直接叩いている点、Dart であるという点、仮想DOM相当のモジュールが後付である点などから、これはおそらく Dartium から既存のウェブブラウザの後方互換を切り捨てたところからスタートしてると想像できる— human eslint --fix (@mizchi) 2018年5月22日 結果としてこれは間違ってました とりあえず dart engine の initial commit 見つけたが昔の名前は Sky だった模様 https://t.co/HwFKCpKtYv— human eslint --fix (@mizchi) 2018年5月22日 The approach we're exploring is

    Flutterのコミットログを読んで、これは一体何由来なのか調べた - mizchi's blog
    mitsuse
    mitsuse 2022/05/02
  • プログラマという現代の傭兵 - mizchi's blog

    エンジニア転職とかプログラミング教育周りで考えていたこと。 フランス革命と技術のコモディティ化 最近フランス革命やナポレオン戦争やナショナリズム、そしてクラウゼヴィッツの戦争論などを調べたりしていたんだけど、傭兵や専門技術の扱いについて、示唆的なものが多かった。 当時の傭兵は、扱いが難しかった大砲・銃火器を扱う専門集団で、技能職でもあった。それが 18 世紀になり火器の改良が進み、産業革命で効率的な生産が可能になり、そしてナポレオンによる国民軍の創設、そのヨーロッパにおける戦果によって、傭兵はその役割を終えた。 「傭兵はすぐ逃げる」というのが定説だが、彼らは金で動く専門職なので、負ける側に付く理由がないので、当然とも言える…特に戦争という、敗者の支払いが期待できない場では。そして彼らを雇う王侯貴族の経済力が、そのまま軍団の動員力に直結した。常備軍を持たない分、平時のコストも安くついた。

    プログラマという現代の傭兵 - mizchi's blog
  • 漸進的型付け言語の時代に必要なもの - mizchi's blog

    最近では、Gradual Typing、漸進的型付けと呼ばれる型システムを備えた言語(拡張)が増えてきています。 次のようなもの JavaScript: TypeScript / Flowtype Python: mypy / pyre-checker PHP: hack / php-storm flow/pyre-checker/hack と facebook 製が多いですね。 この記事は、それらを使う動機と運用について書きます。この記事の出発点として、 おそらく TypeScript/Flow で発生した問題が後発の言語で発生すると思っており、それらを使う方や、設計する人への提言でもあります。 自分は昔 https://github.com/mizchi/TypedCoffeeScript というAltJS作ろうとして、実装のツラミはなんとなく知ってるつもりです。ホビーレベルで作るもの

    漸進的型付け言語の時代に必要なもの - mizchi's blog
  • GraphQLを勉強した - mizchi's blog

    自分でGraphQLサーバーを実装しながら勉強したログ。間違ってるかも。 コードはここにあるが、何の注釈もない。 https://github.com/mizchi-sandbox/play-graphql-server RESTの課題 REST は URI とモデルのマッピング構造だが、往々にしてクライアントで必要となる構造は モデルのうち一部であったり、そのリレーショナルな構造に依存する。 つまり、REST というルールに従って必要なデータを組み立てると、リレーショナルな構造によってN回のリソースへのアクセスと、興味がないデータを含んだ不要なペイロードが発生しがちである。 GraphQL は何をしたいか 1リクエスト内でモデルへの問い合わせを合成し、さらに必要なものだけ返却したい 言語とは独立した、転送経路上のモデルの定義を行いたい パフォーマンス上の理由とセマンティクスが同居している

    GraphQLを勉強した - mizchi's blog
  • Rx.js, Immutable.js について - mizchi's blog

    自分はImmutable.jsとRxをなぜ採用しなかったか、自分の考えを整理するために書き出してみる。 僕の理解が及んでいない無知のゆえのアレもあると思うので間違っていたら罵倒ブコメお願いします。 Immutalbe(.js) 扱う対象をイミュータブルにするのはたぶん間違いなく正しい。正しいが、現時点のエコシステムにおいてその必要性を示せてない。具体的に言うと、Immutable.jsの110kbのオーバーヘッドの配信負荷、読み込み負荷、開発者の学習コストを支払ったとき、それに見合う価値を提示できているのか?にまだ疑問が残る。 PureなJSでも、ただ単に目的のデータを作るだけなら、ほとんどのケースで組み込みのarray.mapとObject.assign(またはそのポリフィル)で代用できる。(勿論生成したオブジェクトに副作用を加えないことが前提になるが) あと型がない環境でImmutab

    Rx.js, Immutable.js について - mizchi's blog
    mitsuse
    mitsuse 2017/01/11
    これっぽい "お互いに無関係なイベントが散発的に発生するような、つまりは普通のアプリケーションにおいて、Rxの強みを活かせるシーンがほとんどない"
  • 1