今まで経験したプロジェクトでありがちな展開と、エンジニアとしてアウトプットしていくパターン - mizchi's blog
なんか最近、(比較的)アウトプットしてないな、とふと気づいたんだけど、よく考えたらプロジェクトの進捗のフェーズによってアウトプットの分量が偏るのはいつものことだなー、とも思った。 それらのフェーズを前期、中期、後期、運営期で考えみる。 初期段階 おそらくライブラリの選定段階から始まる。この時期のアウトプットは、いわゆる「やってみた系」の記事が増える。ウェブに出る記事だと、これが大多数をしめる。汎用性が高く、技術的に挑戦的なものが多い。(立場的な話をするとQiitaはそういう記事がたくさん共有されると助かる) 選定が終わった段階で、アーキテクト的な役割の人は、たぶんこうあるべきだ、みたいな思想を形成する。それをクラス図やコード規約や役割に応じたドメイン特化基底クラスとして表現したりする。DDD的なアレならこれをユビキタス言語の構築としてプロジェクトを通してやるべきなんだろう。 使う予定のフレ
Angularが嫌い - mizchi's blog
僕は本当にAngularが嫌いで、もはや許せないレベルに達していて、今ではもう本当に使いたくない。 イカ理由。 APIがほんっっっっっとうに糞 趣味の問題といえばそうでもあるが僕は糞だと思う 実装が黒魔術 良識あるJSエンジニアなら Function.prototype.toString() しない 実際に一部のクロージャが破壊されてて挙動が直感に反する DirtyCheckの実装、表面的にもDirtyな挙動として現れるのでデータバインドとして何も嬉しくない Googleだから許される、みたいなコミュニティの驕りが本当に嫌 Angularの都合だけでChromeでObject.observeを前倒しするのやめろ Angularの内部モジュール同士が密結合 DI, module, factory, それぞれ大きなテーマなのに密結合 使いはじめるとAngularをやめることが困難 パフォーマン
あなたがReactを使うべき理由 - mizchi's blog
最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか？ 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue
Haxe知見 - mizchi's blog
昔一度調べたんだけど、2系以来で2年ぶり2度目。 前提 自分はrobotlegsでのFlash経験があるJSerです。 セカンドインプレッション 昔と比べて生成されるコードがすごく綺麗になった 同窓会で会った幼馴染が綺麗になってたみたいな感じだった たぶん今なら生成したコードをJavaScript側から触るのも問題ないのでは (ライブラリ呼ばない限り)コードサイズも小さいのでnpm/bowerライブラリとかでも使えそう TypeScriptに慣れたあとに触るとコンパイル爆速すぎてウケる ウケる… でも「Haxeは速度を気にしてOCamlなんです！」って主張、OCamlで書くようなケースはだいたいOCamlそれ自身で書くことそれ自体が目標なのでは…(じゃなきゃC++になるだろうし) 文法的に気に入らない点は Arrow Functionがないこと ForumにIssueあるけど2年ぐらい放置
エンジニア Mac アプリ 環境 おすすめ - mizchi's blog
Macで捗るオススメのアプリひたすら書いてくわ : IT速報 が余りにも消化不良だったので書く。 (タイトル考えるの面倒臭かったのでワードサラダ風) homebrew入れる brewfileをつくる brew bundle おわり 以下、最近作った ~/brewfile です。デスクトップアプリもbrew caskから突っ込む。 もういろんなサイト巡ってアプリを入れて回る時代は終わったんだよ、爺さん tap phinze/homebrew-cask || true tap homebrew/versions|| true update || true install brew-cask || true install git || true install hg || true install ag || true install gist || true install gibo ||
どんなJavaScript開発環境でも*必ず*導入するライブラリ10選 - mizchi's blog
lodash.js moment.js mocha.js sinon.js chai.js es5-shim どんなにライブラリを導入しても、顧客との心の距離は一ミリも縮まりませんでした。
世の中のHTML5アプリケーションが糞だから、俺が「初期化」の作り方を教えてやんよ - mizchi's blog
2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、「ウェブエンジニア」は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか？基本的に「初期化」の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
