タグ

ブックマーク / havelog.aho.mu (5)

  • React に対する感情とかコンポーネント管理ライブラリの選定とか

    コンポーネント管理できそうなライブラリの選定 ここでいうコンポーネントは HTML 要素をコンポーネントに見立てるような、近代 Web フロントエンドにおける狭義のコンポーネントです。大まかな条件は次の3点。 コンポーネント中心の開発ができること >= IE9 をサポートすること(切っても良さそうなんだけど...) 既製品・スクラッチは問わないが極端なリスクは踏めない(納期がシビア) あとは期待度や API のセンスなど、個人的な審美眼判定に依ります。 angular/angular : 2.0 が正式リリースしたらまた会いましょう jashkenas/backbone : 最近のコンポーネント管理には及ばない Custom Elements ( Polymer ) : polyfill が >= IE10サポート segmentio/deku : 振る舞いは十分だったけど、>= IE10

    React に対する感情とかコンポーネント管理ライブラリの選定とか
  • モバイルブラウザでの画像アップロードについて覚え書き

    前置き スマートフォンブラウザで画像アップロードしたいという要件があったので、あんまり無理しないで実装できるとこまでやったら、どうなるのかやってみた。 やりたいことは、アップロードに加えて、画像データにリサイズ処理を適用すること。さすがに3G回線で2MB近い画像データを、input[type="file"]でそのまま送りつけるのは無理がある。 某所で書いたブツの要約版なので、某所のほうを見た諸氏はアレでソレして解釈してください : ) サンプルコード 基方針としては、以下のようなコードで処理することになる。 var elFileInput = document.getElementById('js-select-photo'), elPreview = document.getElementById('js-preview-photo'), createObjectURL = windo

    モバイルブラウザでの画像アップロードについて覚え書き
    mut00tum
    mut00tum 2016/01/06
    アップロード
  • npm とフロントエンドのパッケージ管理の未来

    JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー(Grunt/gulp)・モジュールシステム(browserify/webpack)・テストスイート(karma/testem)などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 題につながる話としては、ブラウザで動くライブラリの一部は npm にも

    npm とフロントエンドのパッケージ管理の未来
  • 最近あまり使ってない、流行っていた時期もあるフロントエンドもの

    最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu

    最近あまり使ってない、流行っていた時期もあるフロントエンドもの
  • 技術は発想やデザインの限界にならない

    当時の思い違い たとえば、一般的なエンジニアが何かを作ろうとすると、その個人の「技術的な限界=発想の限界」となりがちです。 ではデザイナーと呼ばれるような職能を持っているひとが、果たしてプロダクトを実装として理解すべきか、というと、それは分業上の実装サイドによるエゴ(こっちの都合もちゃんと考えて欲しい!的な)でしかないと思っていました。 多少、吹っ飛んだ話であっても、意図を失わずに現実的な実装に落とし込むのはコミュニケーションの問題であって、デザイナー職能の理解不足ではない、と。 コミュニケーションでも解決できる問題として、これは今も間違ってはいないはずですが。 しかし、これは適切なタイミングで、大きな青写真を描くための能力であり、デザイナー職能を全うする話とは違ったのです。 優秀とは 身の回りで優秀なデザイナーと呼ばれる諸氏は、ビジュアルを作るだけでなくステートの管理までよく考え、利用コ

    技術は発想やデザインの限界にならない
    mut00tum
    mut00tum 2014/01/07
    "型があってこそ、発想は型破りと言われるに至れるのでしょう。" 理想は守破離ですのん。
  • 1