継続渡しすると戻り値は引数になるから「Optional は戻り値にのみ使うべき」というルールは無意味だよ、という話。 あ、そういう話ね、と分かった方はこれ以上読む必要はありません。 Mono が Async + Optional + 例外という欲張りパック状態なのも問題ですが、それについてはまた今度(Mono<Optional<T>> 使わずに Mono<T> を使え、という指摘があり得る。ただ、そっちもそっちで言いたいことはある、という程度)。 今回は、 Mono は Async くらいの意図として使っています*1。 まず、こんなメソッドがあったとします。 Mono<Optional<String>> f(); これ自体は戻り値に Optional を使っているだけなので、「Optional は戻り値にのみ使うべき」は守っています。 しかし、これを使う側はそうはいきません。 例えば、値が

3年前にこんな記事をあげました。 bleis-tift.hatenablog.com 3行でまとめると、 Power Assertはユニットテストのためにほしかったものではない 欲しいのは結果の差分 誰か作って！ というエントリでした。 そしたら id:pocketberserker が作ってくれました！ github.com PowerAssertより強そうな名前でいい感じです。 Power Assertは時代遅れ、今はMuscle Assertだ！的な話かな？— 裸のWPF/MVVMを書く男(マン) (@gab_km) 2016年6月1日 MuscleAssertの使い方 このライブラリは、PersimmonというF#用のテスティングフレームワークを拡張するライブラリとして作られています。 ただ、ざっくり概要をつかむだけであればどちらも知らなくても問題ありません。 このライブラリででき

アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで 作者: Tom Stuart,笹田耕一(監訳),笹井崇司出版社/メーカー: オライリージャパン発売日: 2014/09/18メディア: 大型本この商品を含むブログ (2件) を見る 一番最初にはっきりさせておきますが、Rubyは嫌いな言語です。 が、この本はRubyが嫌いな自分でもいい本だと言える*1本でした。 自分が対象読者に入っているかどうかは実際に読んでみるまで微妙かな、と思っていましたが、とても楽しめました。 以下、書評です。 Rubyという選択 説明用のコードとして本書はRubyを使っていますが、 これに関してはその理由が1章にあります。 私はその明瞭さと柔軟さに魅かれてRubyを選びました また、続けて 本書にはRuby独自の機能に依存しているところはありません。 そのため、もしあなたにとってわか

今日、id:htid46 とF#の話をしつつ帰った時のまとめです。 前提条件 次の2つのエントリを読んでいることが前提です。 詳説コンピュテーション式 - ぐるぐる～ コンピュテーション式の実装にStateを用いる - pocketberserkerの爆走 returnとyieldの変換規則 先日のエントリでも書いたように、ReturnとYield、ReturnFromとYieldFromは全く同じ変換のされ方をします。 T(return e, C) = C(b.Return(e)) T(yield e, C) = C(b.Yield(e)) T(return! e, C) = C(b.ReturnFrom(src(e))) T(yield! e, C) = C(b.YieldFrom(src(e))) つまり、ReturnもYieldも同じ実装にしたとしても、コンパイルは通ります。 とい

タイトルはもちろん釣りで・・・はない！ ちょっと真面目に、Power Assertについて意見を述べたいのです。 そもそもPower Assertって何？ てきとーに説明すると、 普通の比較演算子で普通にassert書けば、失敗時に各部分式の値を表示してくれる ようなものです。 Groovy製のテスティングフレームワークであるSpockがおそらく本家大本です((要出典。こういう系の発想は割と昔からあったし、Spock以前に実装例がありそうな気がする。そもそも、Spockは最初からPower Assert持ってたのかも調べないといけない。ちなみに、式木を弄ってAssertを組み立てる、というものであれば(PowerAssertよりも情報量は少なくなるものだけど)、自分の知る限りだと2009年6月にこんな記事があります。 http://themechanicalbride.blogspot.j

発表資料の圧縮版です。 仕事で使うF# View more presentations from bleis tift 「仕事で使う F#」と言いつつ、仕事で使う部分は少ないです。 最初の構想としては、NaturalSpec とか Excel DNA とか FParsec とかの話をしようと思っていました。 が、参加者を見てみると、関数型プログラミング言語のことを知らない人や、 F# を勉強中の人がいたので、方向転換しました。 方向性として、 関数型プログラミング言語を知らない人向けに、F# を使うとなんだか凄そう感を出す F# を勉強中の人向けに、躓きそうなところや疑問に思いそうなところを潰しておく の 2 つが考えられたんですが、デブサミの発表では前者に振ったので、今回は後者に振ってみました。 仕事で・・・の部分については、「実案件で」ということで FParsec の話を入れました。

自分で考えたお題を自分で解くとかそれなんてマッチポンプ・・・ 打ち上げ終了後のホテルと、翌日の帰りの新幹線の中で書いたコードを順番に追ってみます。 準備するものは Git で、あるといいものは Visual Studio 2010 と NUnit です。 まぁ、割と小さいコード (テストを含めても 300 行もない) だし C# を知らない人でもそれなりに雰囲気は掴めると思います。 あ、このエントリかなり長いです。 準備 Windows の場合、Git Bash を開いて、適当なフォルダに移動して git clone git://github.com/bleis-tift/MotsunabeZombieProject.git cd MotsunabeZombieProjectとしてください。 MotsunabeZombieProject というフォルダができて、その中に Git のリポジト

あると便利ですよね、ということで書いてみた。 よくあるコーディングパターンには yield とか使ってないです。 こっちの方がよくありそうでしょ？ Select 全ての要素に何らかの処理を行いたいときに使用します。 // よくあるコーディングパターンその1 // 全ての要素を2倍するメソッド public IEnumerable<int> DoubleAll(int[] target) { var result = new int[target.Length]; for (int i = 0; i < target.Length; i++) { result[i] = target[i] * 2; } return result; } // Selectで書き直し public IEnumerable<int> DoubleAll(IEnumerable<int> target) { re

ついったーにつぶやいたものを中心にまとめました。 まだこれで正しいという確信を持てていないので、メモという位置付けでお願いします*1。 なので追記する可能性が高いです。 TDD でドキュメンテーションコメントを書くタイミング カテゴリを指定して実行するテストを分ける git stash の使い道 TDD でドキュメンテーションコメントを書くタイミング ここでは Git を前提にしますけど、rebase 使えるならほかのものでも大丈夫なはずです。 TDD でいつドキュメンテーションコメントを書けばいいのか、というのは、 Re:TDD を理解するためのまとめ - ぐるぐる〜 TDD Boot Camp の参加報告とか読んで - ぐるぐる〜 と、過去 (といっても半年も経ってないけど) ずっともやもやしてたんですが、 事前条件で楽できないかなーという考え - Logic Dice に対する自分な

Yuki Tamura @isoparametric @finalfusion 簡単にいうとVSSはいつも誹謗されるが、VSSを体験したことがない人は幸せで、VSSは死ね、ということですね？ 2010-02-04 22:39:30

List＜Char＞.ToString() とか C# 3.0 以降なら LINQ やら拡張メソッドやらで OK ですね。 using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace ConsoleApplication { class Program { static void Main(string[] args) { var hello = "hello"; // 元ネタにあわせるためにToListを呼び出す var buf = hello.ToCharArray().ToList(); // LINQ Console.WriteLine(buf.Aggregate("", (s, c) => s + c)); // 拡張メソッド Console.Wri

備忘録の意味も込めて。 やりたいことは、 Debug 系メソッドはリリースモードでは呼出しごと削除したい いちいち LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType); って書くのだるいから省略したい の 2 つ。 Debug 系のメソッドをリリースモードで呼出しごと削除する これは、ConditionalAttribute を使えば出来そうだと軽く考えていたんだけど、この属性、インターフェイスやら抽象メソッドやらには指定できないらしい・・・ まぁ、当たり前っちゃぁ当たり前なんだけど・・・ で、partial メソッドもなんかそれっぽいことに使えそう・・・と、思ったんだけど、こっちも制限が厳しすぎて実現不可能・・・ これも当たり前なんだけどね・・・ で、結局、ObsoluteAttribute と pragma

NUnit 2.5 RC - ZOETROPEの日記 これみてもらえればもうほとんど言うことって残ってないんですが・・・ 一応、ちょっと補足的な情報を。 TestCase 元エントリでは引数が 3 つとなってますけど、3 つ以上も可能でした。 [TestFixture] public class AttributeTestSample { [TestCase(1, 2, 3, 6)] [TestCase(10, 20, 30, 60)] [TestCase(10, 10, 10, 30)] public void TestCaseSample(int x, int y, int z, int expected) { Assert.That(x + y + z, Is.EqualTo(expected)); } } TestCaseSource との使い分けの指針としては、 コンパイル時定数

TDDを理解するためのまとめ - Logic Dice を読んで、いい機会だと思って テスト駆動開発入門 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート出版社/メーカー: ピアソンエデュケーション発売日: 2003/09メディア: 単行本購入: 44人 クリック: 1,026回この商品を含むブログ (156件) を見る を買って、実際に「Part 1 Money オブジェクトの例」を写経してみた。 んで、感じたことなどを。 あ、あくまで今の時点での考えなので、変なとこあったら指摘してくだしあ！ Red から Green、Green から Red ある意味では残念な事なのですが、大抵のTDDの説明に記述されている、「RedからGreenに変わることが気持ちいい」という、その感覚が分からないのです。 TDDを理解するためのまとめ - Logic Dice この気持ちは

結果が変わっていないことを確認しながら SQL をリファクタリングするために、EXCEL - マクロ・シート間の照合 - Office系ソフト - 教えて！gooを参考にマクロを組んでみた。 Function HasDiff_Expect_Actual() As Boolean HasDiff_Expect_Actual = False ' 必要な情報の取得 Set EXPECT_SHEET = ActiveSheet.Previous Dim END_OF_ROW, END_OF_COL As Integer END_OF_ROW = EXPECT_SHEET.UsedRange.Rows.Count END_OF_COL = EXPECT_SHEET.UsedRange.Columns.Count ' アクティブ部分を比較 Dim col, row As Integer For col

大阪で働く友人 mi との合作*1で不完全版が完全版に！ やっぱり mi はすごかった！！ WITH Input(id, str) AS ( -- idと数式を渡す SELECT 1, '1 + 3 / -8' UNION ALL SELECT 2, '2*3*4*5+99' UNION ALL SELECT 3, '4 * (9 - 4) / (2 * 6 - 2) + 8' UNION ALL SELECT 4, '1 + ((123 * 3 - 69) / 100)' UNION ALL SELECT 5, '2.45/8.5*9.27+(5*0.0023)' ) , Separators(i, ch, str_src, priority) AS ( SELECT 1, '-', 1, 1 UNION ALL SELECT 2, '+', 1, 1 UNION ALL SELECT