spray | Blog » The Magnet Pattern
In this post I’d like to shine some light on one particular implementation technique that is used extensively under the hood of sprays routing DSL and which has turned out as a very valuable tool in our “pattern toolbox”. It solves certain kinds of problems in Scala API design and DSL development, especially (but not only) with regard to overloaded methods. We call it the magnet pattern and, hopef
ClojureではじめるSTM入門
4. STMとは Software Transactional Memory ソフトウェアトランザクショナルメモリは、データベーストラン ザクションに似た並行性制御機構であり、並列計算を行う際の 共有メモリへのアクセス法である。 この機構はロックベースの同期を用いた並行性制御の代替手段と して機能し、ノンブロッキングな方法で実装される物もある。 Wikipediaより 楽観的： 他のスレッドを気にせずとりあえず実行してみる 変なことになったらリトライする 最近盛んに研究されている(らしい) 5. ロックの利点と欠点 利点 いつロックを取得し、解除するかを陽に制御できる 開発者にとって馴染みがある方法 多くのプログラミング言語でサポートされている 欠点 ロックのとる順序によってデッドロックが起こる 優先度逆転が起こる composableでない
Java8のStreamを使いこなすをC#で - 平々毎々（アーカイブ）
さて、C#で関数型っぽいことをやって遊んでみたわけですが、恥ずかしくなって猫の写真に置き換えました。 C#で実際に使うのは、LINQです。 ということで、LINQの使い方をひととおり見てみます。 基本 LINQの中核となるのはIEnumerable<T>インタフェースです。これがJava8のStreamに相当します。 さて、IEnumerable<T>インタフェースにはForEach拡張メソッドが用意されていません。これはFAQで、意図的に入れていないということです。 LINQとはズレますが、List<T>クラスにはForEachメソッドがありますから、こっちを使いましょう。ええ、クラスです。インターフェースではありません。 var names = new[] {"hoge hoge", "foo bar", "naoki", "kishida"}.ToList(); names.ForE
Indexed Monadの世界 - モナドとわたしとコモナド
もっと、モナドの力を引き出したくはないか？ え？アクションの前後で型を変えたい？いやいやいや、モナドは自己関手の圏上の単なるモノイドだよ、そんなことができ…る…！？えっ、できるの…マジで…？ できる。そう、Haskellならね。 {-# LANGUAGE QuasiQuotes #-} import Control.Monad.Indexed.State import Control.Monad.Indexed import Language.Haskell.IndexedDo hoge :: IxState Int [Int] () hoge = [ido|do imodify (*10) imodify show imodify reverse imodify (++"123") imodify $ map fromEnum |] *ghci> runIxState hoge 42 (
Program imperatively using Haskell lenses
Haskell gets a lot of flack because it has no built-in support for state and mutation. Consequently, if we want to bake a stateful apple pie in Haskell we must first create a whole universe of stateful operations. However, this principled approach has paid off and now Haskell programmers enjoy more elegant, concise, and powerful imperative code than you can find even in self-described imperative l
あなとみー おぶ mrubyのJIT (その1) - miura1729の日記
ふと思い立ってものすごく影の薄いmrubyのJITの内部構造を説明することにしました。mrubyのJITは正式名称がないというとてもかわいそうなmrubyのフォークですが、オリジナルのmrubyの1〜3割(倍じゃないのに注意)速いようです。ここにあります、 https://github.com/miura1729/mruby さて、mrubyのJITはTracing JITなるものを使っています。第一回目はTracing JITの説明をしたいと思います。コードの解説はしないので、そういうのが読みたい人はTwrtter (@miura1729)かコメントで続きはよとつっついてください。 Tracing JITは今やLuaJIT, Pypyをはじめとするいろんな処理系で使われていますが、あまり解説記事はないようです。ただ、http://dodgson.org/omo/t/?date=20080
pipes-concurrency-1.0.0: Reactive programming
This post introduces the pipes-concurrency library (which you can find here), which is the renamed pipes-stm library that I previously promised. I ended up completing this much sooner than I anticipated, which is why it precedes the upcoming pipes-parse package. Begin with the tutorial if you want to learn how to use the library. This post mainly highlights some features and compares the pipes-con
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
C#／Scala／Python／Ruby／F#でデータ処理はどう違うのか？
http://ntcncp.net/2012/12/26/translate-dhh-concerns-to-extract-module