タグ

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

  • Flux設計論 - mizchi's blog

    scala.jsの実用が真面目にペイされる環境を考えると、jsとscalaのアダプタ部分を考える俺と、scalaレベルで何ができて何ができてないか考える俺が二人いればプロダクションで成立しそう— ガソリンの味 (@mizchi) 2015, 4月 28 Scala.jsが生きる場所、たとえば次のプロジェクトはウェブ版シムシティを作ることですって言われたら、ドメイン部分がピュアでかつ複雑になるのでScala.jsを選択するのはありだと思う— ガソリンの味 (@mizchi) 2015, 4月 28 ドメインがピュアでかつ複雑、基的にatljsが活かせる部分なので、人によってはpurescript選んでもよいわけだし— ガソリンの味 (@mizchi) 2015, 4月 28 アダプタの書き方が altjs => js か js => altjsかで運用勘が結構変わる— ガソリンの味 (@m

    Flux設計論 - mizchi's blog
    nemoba
    nemoba 2015/05/11
    FluxはMVCが古来より戦い続けてきた所謂ViewStateに対して答えが提供されて無いので、ViewStateとそのコントローラーが再発明されまくるのが目に見えてる。
  • 小さいライブラリを採用する - mizchi's blog

    僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。

    小さいライブラリを採用する - mizchi's blog
    nemoba
    nemoba 2014/10/28
    クライアントサイドMVCは、DOMがViewだと気付かせてくれたことが最大の価値。ただ、でかい価値観で言えばUIは技術含めて長年持たせるもんじゃない。試行錯誤で捨てられるモノ。その空気に反逆するのもありだとおもうけど
  • node.jsで Isomorphic フレームワーク作ってみようとしたら超辛かった - mizchi's blog

    現状どんな実装があるかはここみてください Isomorphic JavaScript - The future of web app development 主張 Node.jsは現状フロントエンドユーティリティに最も適している Node.jsは一般にサーバーサイドでの運用は難しいし、自分もそう思う どうせやるなら、Node.jsにしかできないことをやるべきだ Node.jsのキラーアプリはRailsクローンではなく単体ソースからクライアント・サーバーのコードを同時に生成するIsomorphicフレームワークであるべきだ。 これだけは他のフレームワークには絶対に真似できないので、一応可能性は検証すべきだ 自分で実装することで、MeteorとかDerbyはなぜうまくいってないのかも考えたい というわけで Isomorphicなフレームワークを自分で作ってみたいと思っていた。 今ならせめてCo

    node.jsで Isomorphic フレームワーク作ってみようとしたら超辛かった - mizchi's blog
    nemoba
    nemoba 2014/10/08
    RIAでAIRとかGWTとかJSFを見てきてけど、出発時点で開き直ってて天国と地獄は同じ場所にあるという開き直りが必要。だからマーケティングの問題になる。JS-WebApiはむしろこの地獄への救世主だったわけで
  • Angularが嫌い - mizchi's blog

    僕は当にAngularが嫌いで、もはや許せないレベルに達していて、今ではもう当に使いたくない。 イカ理由。 APIがほんっっっっっとうに糞 趣味の問題といえばそうでもあるが僕は糞だと思う 実装が黒魔術 良識あるJSエンジニアなら Function.prototype.toString() しない 実際に一部のクロージャが破壊されてて挙動が直感に反する DirtyCheckの実装、表面的にもDirtyな挙動として現れるのでデータバインドとして何も嬉しくない Googleだから許される、みたいなコミュニティの驕りが当に嫌 Angularの都合だけでChromeでObject.observeを前倒しするのやめろ Angularの内部モジュール同士が密結合 DI, module, factory, それぞれ大きなテーマなのに密結合 使いはじめるとAngularをやめることが困難 パフォーマン

    Angularが嫌い - mizchi's blog
    nemoba
    nemoba 2014/10/06
    誰でもSPAが出来るオールインワンを揃えたところは認めるけど、所々にゾワッとする気持ち悪い感じが凄く嫌だよね。さっさと滅んでほしい
  • あなたがReactを使うべき理由 - mizchi's blog

    最近フロントエンドでfacebook/reactをずっと使っている。世界的には一部のエンジニアの間で流行っているのだが、国内だとqiitaのタグ等を見てもどうも少ない。みんなもっと使うべきだと思うので、宣伝かねて意見をまとめてみる。 複雑化するデータバインドに対する懸念 MVWのVに対して思いを馳せると、だいたい次のことに行き着く。すなわち、「ある構造体の入力に対して、必ず一意なビューを生成したい」 {items: [1, 2, 3]} を入力とすると、 1, 2, 3のli要素になってほしい。これは単純な例だから問題に成り得ないように見えるが、アプリケーション全体の状態を一つのjsonとして定義し、 そこから常に0から組み立てればアプリケーションの健全性が確保できると考えたことはないだろうか? 現実の問題 UIのだいたいの状態は遷移で表現される。遷移の差分をプログラマが記述する。jQue

    あなたがReactを使うべき理由 - mizchi's blog
    nemoba
    nemoba 2014/09/03
    ShadowDomがDOMツリーの隔離領域に対し、VertualDomはDOMから隔離、DOMレンダリングコスト解決の目的は同じで相当相性悪い。ShadowDomがWebComponentsの基盤。ともったらSafariがShadowDom削除して戦国時代。ただMVCと需要が違い両者コケも
  • リーダブルコード、あるいはコードコンプリートについて - mizchi's blog

    リーダブルコードから学べるのは嘘メソッド名と嘘コメントが最大の罪ってことだよ— 片手間以上 (@mizchi) 2014, 7月 5 コードコンプリート、個人的にそんな有益な話はなかったという記憶なんだけど単に趣味のドメインが違うだけかもしれない可能性はある— 片手間以上 (@mizchi) 2014, 7月 5 コードコンプリート、作者が一生懸命になってる主張の部分が全然共感できないのがあった— 片手間以上 (@mizchi) 2014, 7月 5 僕はGoFはむしろ初心者に絶対に読ませてはいけないだと認識していて、グローバル変数をファサードとか言い出したり、これはシングルトンなんです!と言い出す— 片手間以上 (@mizchi) 2014, 7月 5 読んでコード書けるようになるとか幻想だと思ってるので、基礎文法覚えたあたりでコードコンプリート読んで、その後はいろんなパラダイムのフ

    リーダブルコード、あるいはコードコンプリートについて - mizchi's blog
    nemoba
    nemoba 2014/07/07
    GofとかBeansってOOPの再利用に特化して、汎用再利用がJavaの歴史の良くも悪くも主題。現実は特化した手続きロジックが大量で剥離。DDDは「OOPは汎用だけじゃないんよ!特化したドメインに使えるんよ。」だから魂が惹かれる
  • 昔ながらの「片手間に書くJavaScript」の限界 - mizchi's blog

    Javascriptを使うのをやめろ:Railsの時代遅れ云々についての結論 - Qiita この記事は、全体的に自分の業務以外の評価基準やトレンドを知らないんだなという感じで、わざわざ付き合うと精神的に消耗する感じがした。ただ、それが彼らの職でない以上、自分もこの結論に至るのは仕方ないと感じている部分はある。 真の問題は、自分がレガシーなJavaScriptを書いているという自覚がない人間が、ここ数年の技術トレンドから乖離したコードを書き続けることで他のエンジニアやエコシステムそのものに悪影響を及ぼしているケースが散見されている。一行書く毎にグローバル汚染するスクリプトを見せられてもメンテ出来んと言われても、はいそうですねとしか言えないし、そういう人に最近のライブラリを触らせると遅くなるというのは、画面全体を一つのMustacheテンプレートにしてBackbone.Modelのパラメー

    昔ながらの「片手間に書くJavaScript」の限界 - mizchi's blog
    nemoba
    nemoba 2014/06/30
    コミュニティが活発だしJavaとかPHPがMVC無くて模索してた時代よりよっぽど整備しやすいよ。ぶっちゃけ。プラットフォームによる向き不向きは無理しすぎなだけで。Struts厨をdisってた頃の気概を思い出すんだ!!
  • Swift ファーストインプレッション - mizchi's blog

    とりあえずThe Swift Programming Language読んで、実際に自分で少し書いてみた感想。 諸事情でAppleにiOSデベロッパーとしてお布施していたので Xcode6beta落として少し書いてみた。プロジェクトスケルトンをswiftで生成できるので、そのコードを眺めたりしていた。 ファーストインプレッション Immutable脳の人が設計したっぽい。 スクリプト言語っぽい構文に、型注釈。これはGoとシンタックス上の設計思想が似ているんだと思う。 基的にImmutableな設計でありながら、オブジェクト指向を採用しており、Scalaっぽいマルチパラダイム感がある。Scalaの人は好きになりそう。 型推論のおかげで動的型付け言語触ってきた人にも抵抗がない感じになってる。推論のおかげで静的型付け言語が動的型っぽくみえるのはHaskellとかOCaml方面の雰囲気。 LLV

    Swift ファーストインプレッション - mizchi's blog
    nemoba
    nemoba 2014/06/04
    scalaの尖ったところをマイルドにC#の感じの良さを持って来たという。ある意味、みんなが妄想するオレオレクラスベース。型をネスト出来るらしいから、それでモジュールなりNameSpacce的なのをやれるんじゃないかな。
  • JavaScriptの生きてるundefinedと死んでるundefined - mizchi's blog

    JavaScriptの悪魔的な振る舞いの一つにundefinedがあると思う。 javascriptには存在するundefinedと存在しないundefinedがあるし、それはつまり [undefined].length => 1 だ— 俺は平気だよ (@mizchi) 2014, 4月 22 JavaScript、[undefined].length => 1 で arr = []; arr[0] = undefined; だけど、このとき前者のundefinedと後者のundefinedは性質的には別物ですよ— 俺は平気だよ (@mizchi) 2014, 4月 22 もう一つの例として、 obj = {}; のとき obj[‘a’] = undefined したとき、for i in obj するとイテレータが一回だけ回る。obj[‘a’] = undefined しても キーは消え

    JavaScriptの生きてるundefinedと死んでるundefined - mizchi's blog
    nemoba
    nemoba 2014/04/23
    null使えは同意だけど。null+1==1; undefined+1==NaNという罠があったりする。そんなわでCoffeeScriptとかaltJs使えという話になる。/ああ記事の配列の問題じゃcoffeeはあんま意味ないか
  • 新しいことをやる為の負荷と学習コストと迷子であることの自覚 - mizchi's blog

    読みにくい日記です。 一応今の会社はRubyRailsの会社ってことで通ってると思うんだけど、自分はほとんどRails触ったことなかったので、何かと色々やる必要が出てくる。 今はJavaScriptのフロントのタスクがあんまりなくてRailsやった方がいい感じで、じゃあ勉強がてらやるかって突っ込んだらちょっとウゥムって感じになった。 問題 勉強側に振ってしまいすぎたのもあるんだけど、かなり生産性低かった自覚がある。結局1週間やって出せたのがやりかけのPullRequest一件で、しかもwork in progress で残りお願いします… みたいな感じになってしまった。 で、今回新しいことをやるにあたって問題になったのは、次の点だと思った。 新しい登場人物の多さによる認知負荷の高さ パフォーマンス要件の厳しさ 最初からプロダクション前提の品質要求 ペアプロしてくれる人の確保 実は今の会社

    新しいことをやる為の負荷と学習コストと迷子であることの自覚 - mizchi's blog
    nemoba
    nemoba 2014/03/13
    自分が技術的な情報にアンテナを張るようになった理由の一部、そういう恐怖と戦うために少しでも武器を揃えおきたい。だったりする。まあ、大半は興味本位だけど
  • なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog

    ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、質的にJavaScript

    なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
    nemoba
    nemoba 2014/02/05
    整理されたMV*系は調整制御役は状態伝達媒体に。媒体としてのテストは簡単だけど、媒介によってテンプレートにイメージ通りに反映される(=DOMの状態)の方が本質的に興味は強い。でも、そっちの方で良いアプローチが
  • とにかくシンプルで簡単で高速なViewのコンポーネントを作れるHorn.jsを作った - mizchi's blog

    JavaScriptでリアクティブっぽくとにかく短くシンプルにビューが書けるライブラリを作った。 mizchi/horn.js https://github.com/mizchi/horn.js 名前は背骨とか角とかっぽければ何でもよかった。 方針 Angularっぽいユーザー定義のdirective Knockout.js っぽいデータバインド Backbone風の軽量なAPI 依存はjQueryのみ とにかく短くビューのコンポーネントの塊を書けるのを目的とした。UnityとかFlashのコンポーネントに影響を受けている気がする。 HTMLのテンプレートによって、ビューがどういう属性を持つか決定される。それをJavaScriptから使う。 インストール bower install horn 使い方 こんな感じでテンプレートを用意する <div data-template-name="st

    とにかくシンプルで簡単で高速なViewのコンポーネントを作れるHorn.jsを作った - mizchi's blog
    nemoba
    nemoba 2014/01/05
    knockout.jsをgetter/setterに基底Viewクラス導入とjQueryで軽量化にも見えるし。backboneをデータバインド&ディレクティブ導入にも見える。面白い感じ。
  • ボーイフレンドを直す方法 あるいは賢いjQuery.Deferredの使い方 - mizchi's blog

    問題 モバイルは回線が不安定なので、ロードの失敗が頻繁に起こります。 開発時は高速なwifi環境で開発しているので、リリース間近になって帯域を圧迫していることに気づいたりします。 解決方法 画像を先読みします var preload = function(src){ var d = $.Deferred(); var img = new Image; img.src= src; img.onload = d.resolve img.onerror = d.reject return d.promise(); }; 何をやっているかというと、空のimgタグをつくってそこに画像を読み込みます。その過程でブラウザキャッシュに画像が保存されます。正確に言うとこの時点ではどこにも紐付いていないのでGC対象ですが、その後すぐDOMに画像をはるなら問題ありません。 並列で先読みする(速い・不安定) va

    ボーイフレンドを直す方法 あるいは賢いjQuery.Deferredの使い方 - mizchi's blog
    nemoba
    nemoba 2013/12/17
    preload目的だけなら、Ajaxで拾ってくるだけでもキャッシュがきくんじゃないかな。onerrorはよくスルーされた思い出がある。開き直って、ajaxでとって、md5も計算して、createObjectURLで、img.srcにわたたた
  • BackboneマンがAngular勉強会いってきたけどそんなに好きになれなかった話 #ng_jp - mizchi's blog

    最初に僕のポジションは表明しておくけど、今までbackbone.js, というかそのラッパーであるchaplin.jsべったりの環境で開発してて、今のプロジェクトをゼロから作り直す機会があるので次バージョンのためのライブラリ選定のためにとりあえず比較として angularを試した見た程度の人間なので、深くは理解してない。 Angularのメリット 僕の浅い理解と勉強会での話を総合した感じ レールに乗り切った時の開発効率が半端ない レールがしっかり敷かれているので開発者の能力差が問題にならない HTMLがテンプレートなので意味的な乖離が少ない ビューモデルに対する操作が一貫していてテスタビリティがある 自分もモジュラリティがあるHTML/CSSは幻想だと思っているので、HTMLに直接属性を書くのは別に構わないと思っている。 ただ、集団開発でも開発者の能力差が問題にならない、という発表をしてい

    BackboneマンがAngular勉強会いってきたけどそんなに好きになれなかった話 #ng_jp - mizchi's blog
    nemoba
    nemoba 2013/12/11
    そして、あれ?データバインディングだけでいいんじゃね。と思い始めたらknockout.jsで
  • TypedCoffeeScript v0.8.1 リリース - mizchi's blog

    大量にダーティハックが残ってますが一応使えるやつとしてリリースしました。 数字が中途半端なのは、v0.8で仮リリースするつもりだったけど、v0.8.1でかなり修正したからです。 まだまだ仕様はテストコード読めって感じですが、試験的に使う程度にはどうにかなるはずです。 TypedCoffeeScript/test/type_checker.coffee at master · mizchi/TypedCoffeeScript 何も型情報書かなければ、元のcoffee-scriptなら通すはず。現在は、結構な分量のcoffee-scriptで書かれているcoffee-script-reduxのコードを、typed-coffee-scriptでコンパイルできています。 自分の中でのこのバージョンの位置づけは、この0.8がアルファリリースぐらいで、0.9でベータ。1.0でプロダクト利用可ぐらいのイ

    TypedCoffeeScript v0.8.1 リリース - mizchi's blog
    nemoba
    nemoba 2013/11/23
    複数ファイル悩ましい
  • Chromeのdevtoolsの中でTerminalを動かせてヤバイ - mizchi's blog

    やばい ↑ Chromeの中のTerminalの中のtmuxの中でvimが動いている様子です Terminal in Chrome Devtools — Dmitry Filimonov 導入手順 Chrome Web Store - Devtools TerminalChromeでインストール $ npm install -g devtools-terminal $ devtools-terminal ChromeのDevTools開いてTerminalを開く 一部キーバインドがChromeに握られて潰されてしまっているが(Ctrl-aなど)基的には問題なく動く。スクショ通りvimも動く。 ヤバイ

    Chromeのdevtoolsの中でTerminalを動かせてヤバイ - mizchi's blog
    nemoba
    nemoba 2013/11/01
    Chrome is IDE!!
  • mizchi's blog

    最初に言っておくとmizchi と syake の 離婚はお互い嫌いになったという理由ではなく、単に結婚に求めるものが違っていて、その齟齬が顕著になった、ということに尽きます。 mizchi と syake は離婚しても友人であり、一緒にイベントなどもやる予定があります。これからも仲がいい友人であり続けるために適切な距離が必要になり、それには婚姻契約や同居がお互いにとって邪魔になったよね、という同意に至りました。 この2年間は当に楽しかったです。結婚前にあった課題感、「エンジニアとして似たようなサイクルを繰り返すだけの予測可能な人生を打破したい」という当初の目的も達成できました。自分と違う人間と生活することで、様々な局所最適に陥っているのを自覚できるようになりました。これについて、syake には当に感謝しています。 これ以上詳しいことを知りたい人は、Twitter で「ワインと鍋」に

    mizchi's blog
    nemoba
    nemoba 2013/10/30
  • TypedCoffeeScriptに構造体宣言と関数型を追加した - mizchi's blog

    [注意] まだまだ全然使いものにならないよ! プロジェクト名をリネームした mizchi/TypedCoffeeScript https://github.com/mizchi/TypedCoffeeScript 構造体と関数リテラルを追加した。今は次のコードが通る。 struct Point { x :: Number y :: Number } p :: Point = {x: 3, y: 3} f :: Number -> Number = (n :: Number) :: Number -> n * n console.log f 4 f の関数型のところはわざと冗長に書いている。正直、型アノテーションを通すパーサが書けただけで推論は全然完璧ではない。 宣言済みのプロパティに代入しようとした瞬間だけバリデーションしている。関数型も返り値が一致しないと代入できないようにはなってる。引

    TypedCoffeeScriptに構造体宣言と関数型を追加した - mizchi's blog
    nemoba
    nemoba 2013/10/23
    readmeとtestみて気づいたけど、チェックのタイミングパース時か。すごいなあ。structはメンバーにFunctionいけると、結構おいしそう
  • 自分の強みを生かすこと on Quipper - mizchi's blog

    今リリース前にしてはタスクがあんまりないのでブログ書いてみる。 Quipperに入社してから一ヶ月半ほど経過した。それで感じたことをあれこれ書いてみようと思う。 あんまり熱心に書くと前の会社に入ったばかりのことを思い出して恥ずかしくなったりするので、ほどほどにする。 エンジニア文化の共有 会社に入ってまず最初にやることは、エンジニア文化を共有することだと思う。 どんなマインドかは、僕より Quipper のスピード感 - @kyanny's blog とかを読んだ方が伝わるはず。 QuipperはOSS文化というかRuby文化的なものを強く志向している感じがあって、そこらへん馴染みやすかった。 入社してからやったこと まず前提として、ベンチャーなので整った教育制度などはない。(そもそも自分も研修など期待していない)。 エンジニアとしての文化を共有しているから、最初からすぐ仕事に入れた。具

    自分の強みを生かすこと on Quipper - mizchi's blog
    nemoba
    nemoba 2013/10/22
    "AJAXやるなら中央管理する機構"は、ASP.NET MVC辺りだと、Breeze(Upshot)とか使われてるのだがORMの思想が根だから、リッチすぎて癖が強そう。モデルの整合性とキャッシングに特化した何かがほしいです
  • 型付きcoffees-scriptを作り始めた - mizchi's blog

    たぶん僕は人類の怠惰を極めたようなcoffee-scriptの文法が好きすぎるのだけど、その結果型を書けるcoffee-scriptを作り始めてしまった。 Fork元はCoffeeScriptRedux mizchi/CoffeeScriptRedux https://github.com/mizchi/CoffeeScriptRedux/tree/type とりあえず今の版だと次のコードが通る。 目標 x :: Number = 3 y :: String = "hello" z :: Boolean = false # z :: String = 4 #=> Error # y = x #=> Error a :: Any = 3 a = 'fadfa' b = 'a' fn :: Function = -> x = 3 n = -> i = '' f2 :: Function = (

    型付きcoffees-scriptを作り始めた - mizchi's blog
    nemoba
    nemoba 2013/10/15
    CoffeeScriptだと動的検査になるだろうから、複雑にした場合のオーバーヘッドとか気になる。関数とクラスをどこまで詰めるかになるかなあ。