Rustが再評価される:エコシステムの現状と落とし穴 In this article, we share findings and insights about the Rust community and ecosystem and elaborate on the peculiarities and pitfalls of starting new projects with Rust or migrating to Rust from othe...
![仮想パネル:最先端のJavaScriptユニットテスティング](https://cdn-ak-scissors.b.st-hatena.com/image/square/bed7a226728cd44e8903868be9dade6f15bbba66/height=288;version=1;width=512/https%3A%2F%2Fres.infoq.com%2Farticles%2Fjavascript-unit-testing%2Fja%2Fsmallimage%2Fjut.jpg)
これに対して、CommonJSグループはPromiseという形でこれに答えている。これは任意の時点で、完了しているかもしれないし完了していないかもしれない、非同期に実行されるアクションの結果を表現したオブジェクトとのインターフェイスを提供する。この方法では、さまざまなコンポーネントが非同期アクションのためのpromiseを返すことができ、コンシューマは予測可能な形でそのpromiseを利用できる。また、Promiseは非同期性を支援するために構文上便利な言語レベル拡張のために利用される基本エンティティを提供することもできる。 Stratified JavaScriptはこれとは別のアプローチをとっており、JavaScript言語のスーパーセットを提供することで、この問題を解決している。しかし、使う言語を切り替えられないのなら、とるべき道はシーケンシャルなコードをエミュレート可能な、柔軟なA
原文(投稿日:2010/08/26)へのリンク ソフトウェア開発ディレクターで、以前チーフ・ソフトウェア・アーキテクトも務めたMax Indelicato氏は、拡張性のためにどのようにアプリケーションを設計するかという記事を書いた。氏は、正しいデプロイ、ストレージソリューションおよび拡張性のあるデータストレージとスキーマを選択し、抽象レイヤを利用するように推奨している。 仕事に適したツール Indelicato氏の最初のアドバイスは、次のアーキテクチャ上のソリューションの中から、「仕事に適した正しいツールを選択する」というものだ。 クラウドに配備するソリューションの利用 MongoDBやCouchDB、Cassandra、Redisなどの拡張性のあるストレージソリューションの利用 Memcachedのようなキャッシュ層の追加 これらのソリューションは、アプリケーションの初期から必須ではない
原文(投稿日:2009/6/26)へのリンク Twitterサービスチームの主任エンジニアであり、主に最適化とスケーラビリティを担当しているEvan Weaver氏が、QCon London 2009においてTwitterのアーキテクチャ、とりわけ過去一年にわたって行ってきたウェブサイトの最適化について語った。 Twitterで使われているツールの多くはオープンソースである。そのスタックは、フロントサイドにRails、中間のビジネス層にC、Scala、Java、データストアとしてMySQLを利用してつくられている。すべてがRAM上に保持されており、データベースは単なるバックアップである。Railsのフロントエンドはレンダリング、複合キャッシュ、DBクエリ、同期的挿入を扱う。このフロントエンドは、MySQLクライアント、Memcachedクライアント、JSONクライアントなどの、多くはCで書
実際、Javaには1.1の時代から(インナークラスという形で)クロージャがあります。次のコードを見て下さい。 public interface IFilter { public boolean filter(int x); } public class FilterFactory { public static IFilter greaterThan(final int i) { return new IFilter() { public boolean filter(int x) { // iは語彙的スコープの外部から与えられる return x > i; } }; } } 上記のコードサンプルでは、FilterFactoryにgreaterThanというファクトリメソッドがあり、これは呼び出しに際して引数に関するクロージャを返します。同じコードを異なる引数で呼び出すと、異なるクロージャ
まだ開発が始まっていないプロジェクトがアジャイルのスイート・スポットだと主張する人も多いでしょう。しかし、私の意見は違います。私はいつも既存にシステムの方が簡単にアジャイルを適用できるということを見てきました。重要なのは、今では新しいプロジェクトでも既存のシステムでもアジャイルで開発するための十分な経験が蓄積されているということです。 アジャイルのスイート・スポットの中だけでアジャイルが実践されるわけではありません。アジャイルについての素晴らしい知識が存在するのがスイート・スポットなのです。このスイート・スポットには好循環が存在します。すなわち、多くの経験が多くの成功をもたらし、その成功がまた経験を得る機会を生み出します。 エンジニアリングの実践 チームはアジャイルの導入をどこから始めるべきかという問いに対して私の答えはいつも同じです。すなわち品質です。もしチームがイテレーションの終わりに
スクリプトの開発は、出力結果の様子を見ながら、試行錯誤的に記述を修正していくため、起動速度が重要になります。1秒はとても待っていられません。 Groovyはその機能からして、本来PerlやRuby、Pythonなどにも拮抗しうる強力なスクリプト言語ですが、GroovyServを併せて使うことで、スクリプト言語としてのGroovyの本来のパワーを最大限に引き出すことができるようになります。 起動性能ベンチマーク GroovyServを用いた場合の起動時間、具体的には以下のコマンドラインの実行に要する時間を計測してみます。 $ time groovy -e "println 'hello'" この測定方法だと、起動時間だけではなく処理時間や終了に要する時間も含みますが、それは十分に小さいと仮定しています。 Mac OS Xでの起動速度の測定結果を[グラフ1]に示します(グラフ縦軸目盛りの単位は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く