Kazuho's Weblog: 良いソフトウェアに求められる３点セットとJSXの開発手法の改善とgit-pushdirについて
テスト駆動開発（TDD）の一般化とGitHubの登場によって、機能追加の際にコードとテストを同時に実装する（そして、両者を一括してmasterにmergeする）という開発手法が一般化してきました。 しかし、「良いプログラム」の要素を構成するのは、コードとテストのみではありません。動作するコードと、その品質を担保するためのテストがあったとしても、適切なドキュメントがなければ、ユーザーはそのプログラムをどうやって使ったら良いかわかりません。 つまり、ユーザーに使いやすいプログラムを継続的に開発／提供しようと思うと、 コード テスト ドキュメント の３点セットを提供する必要があるのです注1。 今日のJSXが抱えている最大の課題は、ドキュメントが不足しているという点にあります。その原因は、「機能追加」の際にコードとテストのみを実装してmasterにmergeすることを繰り返す一方で、ドキュメントは
とあるプログラミング言語処理系のセルフホスティング化に携わった - wasabizの日記
2013-12-15 とあるプログラミング言語処理系のセルフホスティング化に携わった (この記事はJSX Advent Calendar 2013の一部として書かれました。) 僕がJSXというプログラミング言語の開発に携わってこの冬で早1年半になります。コンパイラとしてのjsxにはこの1年半で幾多の出来事がありましたが、その中でも一番巨大なものがセルフホスティングでしょう。つまりJSXのコンパイラをJSX自身で書きなおすということです。 メインラインのコードをまるまる入れ替えるこのセルフホスティングは大きな苦労を伴いました。実際、通常のポーティングとは違いコンパイラそのものを入れ替えてしまうわけですから、バグの出方などもなかなか味わい深いものです。 JSXセルフホスティングを行ってから既に1年が経過しようとしています。今までこの作業の苦労について外で話したことは無かったのですが、「プログラ
JavaScriptで高速なコードを書く際の注意点。または私は如何にして心配するのを止めてJSXを作ることにしたか
JavaScriptで高速なコードを書く際の注意点。または私は如何にして心配するのを止めてJSXを作ることにしたか 本日、福岡で開催されたプログラミング言語のパフォーマンスを考えるイベント「ぷろぐぱ」で、「JSX 速さの秘密 - 高速なJavaScriptを書く方法」という演題で講演しました。 JavaScriptで速いコードを書こうとする際に陥りがちな罠を紹介し、それらの問題にJSXではどうやって対処しているか、プログラミング言語設計と最適化機能の実装を説明しました。プログラミング言語設計に興味がある方にとっても、JavaScriptを使ったプログラミングに興味がある方にとっても面白い内容になっているかと思います。
JSX minifierの圧縮性能 - Islands in the byte stream (legacy)
JSX compilerのソースコードで検証してみました*1。 Mode Size(KiB) Ratio original 1507 1.00 JSX minifier 277 0.18 Closure Compiler/D 602 0.40 Closure Compiler/A 301 0.20 対象にしたソースコードがJSXから変換したJSというやや特殊な状況ですが、Closure CompilerのADVANCED_OPTIMIZATIONSよりもサイズが小さくなりました。また、ADVANCED_OPTIMIZATIONSと異なりJSX minifier*2はコードを破壊する圧縮は一切行わないので、圧縮したらコードが動かなくなるということが非常に起こりにくくなっています。しかしそれでも、JSXの豊富な型情報を使って圧縮すればADVANCED_OPTIMIZATIONSよりもサイズを小
JSXのgeneratorで同期的なsleep()を実装してみる - Islands in the byte stream (legacy)
[追記]v0.9.84現在、--enable-generator-emulationが必要です。これを付けないと、ES6のgeneratorを使うようにコンパイルされます。[/追記] 最近、JSの非同期まわりが新しい盛り上がりがありました。 Google Chromeに入ったジェネレータとPromiseで非同期処理に革命が起きた - 素人がプログラミングを勉強していたブログ 2013-05-02 とくにES6のgeneratorを使えば、非同期コードを同期的に書けるようになるということで期待が持てます。 ところで、JSXにも最近実験的にgeneratorが実装されました*1。生成されるJavaScriptはES5準拠ですから、スマートフォンでも実行可能です。 すなわち、これが本格的に使えるようになれば、ブラウザの対応を待たずにgeneratorが使い放題になるというわけですね！genera
JSX の名前空間の仕組み - Islands in the byte stream (legacy)
JSXには名前空間の仕組みがあります。ここで名前空間とは厳密に定義はせず、「同名の異なるクラスを同じスコープで使用する仕組み」とします。つまりJavaではパッケージ、C++では名前空間、 ES6/TypeScriptではモジュールと呼ばれるものですね。JSXの名前空間は宣言する構文こそありませんが、ファイルがその単位となっていて、必要であればそれを特定の名前空間に割り当てて使うことができます。 この「宣言構文がない」「必要なときのみ名前空間を割り当てる」という仕様のため普段意識することは少ないのですが、たとえばJavaのようにファイルシステム上の名前とpackage宣言の名前を一致させなければならないという冗長性がなくとてもシンプルで、私は気に入っています。 さて、使い方も軽く紹介しましょう。たとえば以下のように同名のクラスMyClassを定義している foo.jsx, bar.jsx が
JSXをPhantomJSで動かしてみる - Islands in the byte stream (legacy)
遅くなりましたが、AltJS Advent Calendarの7日目です。 PhantomJSというのは、コマンドラインで使えるJavaScript実行環境です。Mac+Homebrewだと brew install phantomjs でインストールできます。 さて、まずは以下のようなJavaScript source codeを用意してみましょう。通常のJavaScriptと違うのは、 phantom.exit() を実行しないとスクリプトが終了しないことです。 // hello-phantom.js console.log("Hello, world!"); phantom.exit(); 実行するにはphantomjs(1)にファイル名を与えて起動するだけです。 $ phantomjs hello-phatntom.js Hello, world! これだけみると単なるJavaSc
TimSort in JSX - Islands in the byte stream (legacy)
JavaScriptのArray.prototype.sort()のアルゴリズムは特に規定されていないようだ。つまり、stableかどうかや最悪計算量は処理系依存である。その結果、JSXのsort()も同様となっている。 そこで、stable sortであるTimSortのJava版をJSXに移植してみた。 https://github.com/gfx/jsx-stable-sort/ このアルゴリズムは、完全にランダムシャッフルされた配列に対してはmerge-sortやquick-sortよりも時間が掛かる傾向にある。しかし、一部がsort済みである配列に対しては非常に速い。 nodejs 0.8.0 (MacOSX Lion)で100万要素の配列をソートする時間を測ってみた。組み込みsortはソートされた配列を返す非破壊的ソートで、StableSortの非破壊版は完全にシャッフルされた
Code/JSX - CODE CODIUM.
The MIT License Copyright (c) 2012 CODE CODIUM. All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software,
Big Sky :: JSX の Vim 環境を整備してみた ～ jsx.vim に何個か pull req を送った
「JSX 書くなら Vim だよね」というのが当たり前になる明るい未来を目指して jsx.vim に何個か pull req を送りました！ jsx/jsx.vim - GitHub https://github.com/jsx/jsx.vim pull reqを送った機能は次のとおりです。 コンパイラプラグインの追加 補完機能の追加 簡単に説明していきます。 コンパイラプラグインの追加 デフォルトではオンになっていないので、:compiler jsx にしておくか、vimrc で以下を実行する必要があります。 autocmd FileType jsx compiler jsx この状態で :make を実行すると quickfix にエラーが表示されます。vim-hier と併用すると以下の様になります。 補完機能の追加 manga_osyo さんが neocomplcache での実装
neocomplcache で JSX のコード補完を行う neocomplcache-jsx をつくった - C++でゲームプログラミング
jsx 側でコード補完を行う機能が実装されたので、それを使用して neocomplcache の source を書きました。 先に行っておくと非同期ではないのでレスポンスが悪いです。 また、コード補完機能が実装されている JSX の git は master の branch ではないので注意。 jsx-auto-complete - github neocomplcache - github neocomplcache-jsx - github こんな感じ。 たまに補完がうまく行かない時がありますが、だいたい動いているかな。 Windows 環境でしかテストしていないので補完の環境だと動作するか分かりません。 あと、なぜかわたしの環境だと vimproc#system で結果が取得出来なかったので system を直接使っています。 ここら辺は原因がよくわからないので保留。 それと非同
JSX の neocomplcache-snippets-complete を書いた - C++でゲームプログラミング
ちょっとつついて見たのでついでに書いてみました。 neocomplcache-snippets-complete-jsx - github :NeoBundle "git://github.com/osyo-manga/neocomplcache-snippets-complete-jsx.git" JSX 歴5時間の輩が書いたので、気になった部分があれば fork するなり煮るなり焼くなり好きにして下さい。 Tutorial や Example を眺めつつ書いたので言語仕様的な抜けがあるかも知れません。 型推論回りはまだよく分かっていない。 しかし、普段書いているのが C++ なので型を後置に書くっていうのが慣れないですね。 そろそろ Haskell の snippets を書きたいところ。
JSX で Array#forEach が５倍以上速くなった話 - kazuhoのメモ置き場
JSX の進化速度が半端ない - ぐるぐる～ で紹介していただいているとおり、最新の JSX では function expression の型宣言を省略できるようになっています。これを利用して、たとえば配列の合計を求める場合、 var sum = 0; [ 1, 2, 3, 4, 5, 6, 7, 8 ].forEach(function (n) { sum += n; }); のように、JavaScript と 100% 同様に書くことができるようになりました。省略形を利用して [ ... ].forEach((n) -> { sum + n; }); でもいいです。 ところでこのコード、見た目は同じなんですが、実は JSX だと JavaScript よりも５倍以上速く動くんです。まだ最適化があまいところがあるのに。 なぜか。JavaScript の Array#forEach は配
JSX の進化速度が半端ない - ぐるぐる～
気に入らない所を直して pull request 投げたら、取り入れられたので、8 日前に書いたエントリが過去のものとなっちゃいました。 関数型 以前の JSX では、関数型は function(: int): string のように書く必要がありました。 これはこれでそのまま使えるのですが、新たに (int) -> string という形式にも対応しました。 ちなみに、複数引数はカンマ区切りで (int, boolean) -> string のようになります。 カリー化された関数は、 function(: int): function(: number): string の代わりに (int) -> (number) -> string と書けます。 引数を囲むカッコは、(今のところ) 省略不可能です。 これには 2 つの理由があります。 この機能を追加したとき、JSX のパーサの能力
JSXにテンプレート型サポート入れ始めた - kazuhoのメモ置き場
まだ master にはマージしてないですが kazuho/user-defined-templates ブランチのやつを使うと、 class Adder.<T> { static function f(x : T, y : T) : T { return x + y; } } class Test { static function run() : void { var n = Adder.<number>.f(1, 3); log n; var s = Adder.<string>.f("abc", "def"); log s; } } が、最適化オプション (--optimize inline,fold-const) でコンパイル後に Test.run$ = function () { /** @type {!number} */ var n; /** @type {!string}
JavaScripterから見たJSX
私は2001年からJavaScriptを専門にして実装をしており、かなり長い間JavaScriptを使い続けてきました。ExGameをはじめとして、異常なほどにJavaScriptを使い倒したプロジェクトを何個か完遂させています。前の会社「ブロードテイル」がDeNAに買収されたのは、JavaScriptのプロダクトだけでなく、私たちのJavaScriptのスキルを生かしたいという側面も大きくあったと感じています。 そんな私ですが、正直に言うとJSXの開発にはほとんど関わっていません。JSXは基本的に一穂さんが主導し、gfxがフォローし、a_bickyがドッグフードを食べる（自分たちのプロダクトをまず自分たちで率先して使う）という形で進んできました。私が強くかかわったのは、主に3月の言語仕様を決めるときの議論程度です。なのでJSXについてそこまで詳しい訳ではないのですが、そばで開発を見てきた
JSX はなぜ「速い」のか - kazuhoのメモ置き場
なぜ「速い」のか、について JSX 開発者の立場から。 たとえば、シューティングゲームで一番重たい処理は何か。言うまでもなく衝突判定。多数の弾や敵機の衝突判定を毎フレームごとに行う必要があり、この演算が重たい。 JSX に同梱されている web/example/shooting.jsx には衝突判定のコードが複数あるが、一番重たいのは Bullet#update 関数で、その処理は以下のようになっている*1。 for (var rockKey in st.rocks) { var rock = st.rocks[rockKey]; if (this.detectCollision(rock)) { if (rock.hp == 0) return false; inDisplay = false; if (--rock.hp == 0) { st.score = Math.min(st.s
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSX の使い方 自分メモ - latest log
http://spheresofa.net/blog/?p=757
JSXの補完を強化します - Islands in the byte stream (legacy)
