An online AST explorer.
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Reactがもっと広まって欲しいと思っている今日このごろ。React EuropeでJoseph Savona氏の講演でRelayについての「モヤっと」がいっきにかなり解消された気がするので、要点を本編を翻訳しながら自分なりにまとめておきます。 私の理解が誤っている可能性は十二分にありえるので、ご指摘いただければ幸いです。 はじめに ReactとFluxって組み合わせと共によく目にするのが↓の図。 矢印は一方向にしか進まないのが特徴で、わかりやすいってのがいろんなところで書かれているんですけど、 **結局データをサーバからとってくるとこ
一ヶ月近くの有給休暇を経て8/1から完全な無職になりました。前職ではjsといえばviewsに$()を書きまくるという所業をはたらいておりましたが、railsはapi、フロントは別口でというのが流れであるっぽいので、ちゃんとしたjs作業をしましょうというのが今月のあらすじ。 成果物 うごいてるもの No Mines Land 左右同時押しがMouseEventから簡単にとれてびっくりした。 ソース https://github.com/mmmpa/mine はじめてつかった Browserify とくにBrowserifyはとてもよくて、javascriptのファイル分割に関する知見がまったくない自分でも、簡単に分割と結合が行えるようになっており本当によかった。 Browserifyについて勘違いしていたこと Browserifyを読み込んでおくとrequireが使えるようになると思っていた
Googleは、Ajaxのクロール/インデックスに対応する新しい仕様を9月までには公開できるようです。 Ajaxコンテンツをクロールするためのスナップショットの作成はもはや必要ないとしつつも、URLを「?_escaped_fragment_=」に置き換えたスナップショットを作成する仕様を推奨構成として現在も引き続き公開しています。 今四半期中の完成に向けて実験中 AjaxやSPAなどJavaScriptフレームワークを使って生成するコンテンツに対してスナップショットを作る必要は今はないとGoogleは言っています。 それなのに、_escaped_fragment_をURLに含むスナップショットを事前に準備する構成のドキュメントをいまだに公開しているのはどうしてなのでしょうか? GoogleのGary Illyes(ゲイリー・イリーズ)氏はStack Overflowで次のように説明していま
JerryScript is a very lightweight JavaScript engine with capability to run on microcontrollers with less then 8KB of RAM. JerryScript is the lightweight JavaScript engine intended to run on a very constrained devices such as microcontrollers: Only few kilobytes of RAM available to the engine (<64 KB RAM) Constrained ROM space for the code of the engine (<200 KB ROM) The engine supports on-device c
JavaScriptで画像処理などの重い計算をしているとどうしても気になるのがループの部分。実際の処理に加えてループの部分でのロスが気になり始めたので実際にどのループ方法が速いのか試してみました。 概要 0~9999999の長さ1000万の配列のすべてを足し合わせるという単純な計算を行います 配列は、各ループの前で常に初期化を行います。 ループはforまたはwhileを用います。foreachやforinは使いません。 v8(Node.js)、Chrome、Firefox、Safariで実験を行います 筆者が噂で聞いた5つのポイント(後述)を加味した計32種類のコードを自動生成し、実行します。 各プラットフォームで5回実行し、平均をとります。 ウェブブラウザではWebWorkerを用いて実行します。 結果は実行環境に左右されている可能性があります 環境 MacBook Air (11-in
Introduction We spend a lot of time writing code. In the early phases of a project, the directory structure doesn’t matter too much and many people tend to ignore best practices. In the short term, this allows the developer to code rapidly, but in the long term will affect code maintainability. AngularJS is still relatively new and developers are still figuring out what works and doesn’t. There ar
タスク管理 package.json にはパッケージの依存を書いて npm install するのが基本だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、
というのを考えたので紹介します。 2015.09.04 内容が古くなっていたので修正 リンティングツールを jshint から eslint に変更 テストでの power-assert 用のオプション指定方法の変更 概要 基本的にはこの記事 ライブラリをES6で書いて公開する所から始めよう (必読) と同じで、それにいくつかのタスクを追加しています。やることと使用しているライブラリは以下の通りです。 ES6のコードをES5ベースに変換する / babel ブラウザ用コードを生成する / browserify ミニファイする / UglifyJS テストする / mocha, power-assert カバレッジレポートを作る / isparta リンティング / eslint ディレクトリ構成 build: ブラウザ用にビルドされたコード bower install されたときに読み込ま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く