Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

var p = new Promise(function(fulfill, reject){ console.log("start"); fulfill(""); }); p.then(function(result){ console.log("1-1"); }).then(function(result){ console.log("1-2"); }).then(function(result){ console.log("1-3"); }); p.then(function(result){ console.log("2-1") }).then(function(result){ console.log("2-2"); }).then(function(result){ console.log("2-3"); });
@armorik83です。ちょっと一段落ついたところで、そろそろ真剣にPromiseの中身を読む必要があるなーと感じたので、そのときのメモです。 読んだ実装 今回はjakearchibald/es6-promise v2.0.1を読んでいきます。基礎知識としてJavaScript Promiseの本にも目を通しておくとよいでしょう。 サンプルソース サンプルとしてPromise本の1.3.1を若干改変して利用させてもらいました。 var Promise = require('es6-promise').Promise; function getURL(URL) { return new Promise(function (resolve, reject) { var req = new XMLHttpRequest(); req.open('GET', URL, true); req.on
ES6形式のPromiseを使うときに頻出する3つのパターン。直列パターン、並列パターン、分岐パターンを説明します。 最近、Promise周りが盛り上がっていて、reduceを使ったほうが良いとか、ライブラリがどうとか・・・いう話を聞くのですが、そもそも「ベタに書いたときにどうするのが基本なのか」という情報が見つからないので書いてみました。 直列パターン 一番良く使うのは、複数の処理を直列につなげるパターンでしょう。#1が終わってから、#2、#2が終わってから#3というパターンです。 Promise.resolve() .then(function(){ return new Promise(function(fulfilled, rejected){ asyncFunc(function(){ fulfilled(); }); }) }) .then(function(){ return
メリークリスマス。Elixir Advent Calendar 2013 24日目ですよ。 Elixirが大好きなみんなは、ErlangやRubyにも興味があると思うんですよね。ああ、もしかしたらScalaにも興味があるかもしれませんね。 RubyでElixir/Erlang/ScalaのようなActor modelを実現しようとしたら、Celluloidが定石かなと思いますし、最近はconcurrent-rubyというのも出てきましたが、でもCRubyのマルチスレッドは実質シングルスレッドだったりして(CRuby 2.0時点)、そのままでは計算機リソースを活かすことが難しいです。 というわけで先週日曜に半日かけて一通り作りました。 actoryとは RubyでActor modelや並列処理を実現するためのフレームワークです。actoryはActor model like, concur
メモ代わり GoF曰く→既存のオブジェクトのコピーであるテンプレートを元にオブジェクト生成を行うこと jsで実装が簡単(もともとprototypeベースだし) jsで継承を簡単に実装出来る。 継承の実行時には関数のコピーを生成するのではなく、参照が作成される わかりやすい(個人的に) 以下が例 var myCar = { name: "Ford Escort", drive: function(){ console.log("I'm driving!"); }, panic: function(){ console.log("Wait, How do you stop this thing?"); } }; // 車のインスタンスを作成するためにObject.createを利用 var yourCar = Object.create(myCar); console.log(yourCar.
暇すぎるから 書いてみた。が、 interfaceについてTypeScript (0.8.3)だと public static〜という感じでプロパティ指定ができないので、 (new Slime).create();という感じになってしまう。 あとclass内でのプロパティとして持たせるのがだるいので moduleを使ってしまった。 ES5で定義されているgetアクセサを利用しているので、 interface EnemyStatus { name: string; hitPoint: number; magicPoint: number; experiencePoint: number; gold: number; } interface Enemy { status: EnemyStatus; name: string; attaked: (attackPoint: number)=> v
はじめに Angular JS で複数のコントローラ間でモデル(状態や値)を共有する方法として、次の 3 種類を解説します。 モデルを共有するサービスを使用する (Shared Service)。 親コントローラのスコープを子コントローラで共有する (Parent Scope Sharing)。 イベントを利用する (Pub/Sub)。 Shared Service 複数のコントローラ間で共有するモデルをサービスとして作成し、そのサービスを複数のコントローラで参照します。 実装例を示します。 <!DOCTYPE HTML> <html ng-app="AngularJsStudy"> <head> <title>Shared State Service - AngularJS Study</title> <meta charset="utf-8" /> <meta http-equiv="
Rubyを勉強する上で役立つ情報源をまとめてみました。まだ仕入れていない情報源があれば価値がある記事なんじゃないかと思います。 書籍 Everyday Rails - RSpecによるRailsテスト入門 Rubyでテストコードを書くときは多くの人がRspecを使っていると思いますが、そのRSpecを学ぶ上で実用的な書き方が学べます。実践で頑強なプログラミングを書けるようになり、チームの人たちも安心して仕事を任せてもらえます。 メタプログラミングRuby Ruby力を高める上で必要な知識がメタプログラミングです。コードを読むのにも書くのにも知っているかどうかで大きく影響します。これを読みきった頃には中級者に達していると言っても良いでしょう。 パーフェクトRuby ここまで学んだ知識の穴埋めをしてくれるでしょう。実践力向上に役立ちます。 パーフェクトRubyOnRails Rubyを使う上で
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 本投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 本が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代
これだけモデリングとは **「これだけモデリング」**とは、メソドロジックの山岸さんが提唱されている「軽い」モデリング手法です(山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き)。 デベロッパーでなく情報システム部門目線で見て、どんどん複雑になる企業アプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性がテーマです。 そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなか実装から遠いモデリングがペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 エンタープライズアジャイル時代のリーンモデリング(slideshare) これだけモデリングとは、 誰が? ー 情報システ
仕事などでJSを書くようになって少々経つが、Java信者で頭が固い僕にとってはどうもJSというのは柔らかすぎてしっくりこない部分が多い。 考え方を整理するにはデザインパターンを知るのが早いと、最近思い立ったので改めて調べてみた。 ということで、Javaは大体分かるし、JSも書くけどそこまで詳しくない人向け(つまり自分主体)にまとめておく。 今のところシリーズ化予定。 ※ JSの知識には自信ないので間違った点に気付いた方がいらしたらコメント等でご指摘いただけると助かります。 ※ デザインパターンとして挙げているコードは、個人的にアレンジしている場合がありますので、ご了承ください。 0.はじめに 本編案内 内容に入る前に、予備知識をおさらい。要点ではないのでざっくり。 シリーズ案内 Javaプログラマから見たJavaScriptデザインパターン(導入編) Javaプログラマから見たJavaSc
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。(参考文献の一覧は記事の最後にあります) 内容的には文献[2,3]を踏
ちょっと煽り気味のタイトルにしてみましたが、Railsで開発する時は意識的にOOPに寄せないとオブジェクトの力が活かせなくなるよってことと、Railsが提供しているクラスの責務を分割することを支援してくれる機能について話をします。 ActiveRecordの性質 Rails開発においては、モデル層にロジックを書いてコントローラーは薄くしろ、というのはしつこく言われているので、概ね浸透してきていると思います。 それに加えて、最近私が結構しつこく主張しておきたいのが、モデル = ActiveRecordでは無いよ、ということです。 ActiveRecordは成り立ちから言うと、ロジックとDBへの永続化をまとめてカプセル化するアーキテクチャパターンから来ています。(詳しくはエンタープライズアプリケーションアーキテクチャパターンという書籍を読むと良いです) この方法はロジックが複雑でない場合、つま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く