シャドーイングとイミュータブルプログラミング - ぐるぐる～
シャドーイングのない言語と、イミュータブル中心のプログラミング(以下イミュータブルプログラミング)の相性って悪いのでは？と思ったのでブログに残しておきます。 シャドーイングとは 既存の変数と同名の変数を定義して、そのスコープで既存の変数にアクセスできなくする機能です。 例えば、F#ではシャドーイングができるので、 let f x = if x % 2 = 0 then (* 引数のxをシャドーイング *) let x = -1 printf "%d, " x (* スコープが抜けたので、引数のxを表示 *) printfn "%d" x f 10 (* => -1, 10 *) f 11 (* => 11 *) となります。 シャドーイングのない言語、例えばC#では同じことはできないので、別の名前を付けるか、再代入で回避することになります*1。 public void F(int x) {
続・そろそろPower Assertについてひとこと言っておくか - ぐるぐる～
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#用のテスティングフレームワークを拡張するライブラリとして作られています。 ただ、ざっくり概要をつかむだけであればどちらも知らなくても問題ありません。 このライブラリででき
並列/並行基礎勉強会でasync/awaitをDisってきた - ぐるぐる～
async/await不要論 from bleis tift 3/23 に開催された、並列/並行基礎勉強会で「async/await 不要論」という発表をしてきました。 一番言いたかったこと 一番言いたかったことは、実は並列とかとは全く関係ないことです。 それは、言語への機能追加に関することです。 C# は 5.0 で非同期処理のための専用の構文として、async/await を導入しました。 これは、F# が計算一般という抽象度の高いものための汎用的な構文として、コンピュテーション式を採用しているのとは対照的です。 専用の構文を用意するかしないかは、その言語を取り巻く環境次第です。 専用の構文の利点と欠点 専用の構文の利点は、その使用用途が明確であるというところにあります。 そのため、書き方さえ覚えてしまえば、その裏で何がどうなるかなどを一切気にせずに使えてしまえたりします。 欠点は、専
re:僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - ぐるぐる～
元ネタ: 僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記 OOPの文脈で見ると、元の記事が言っていることもわからなくはないのですが、対象が広すぎていろいろと不正確になってしまっているので、ちょっとまとめてみます。 元の記事が対象にしているのは、Maybe / Optional / Nullableの3つです。 対応する型を持つ言語を見てみると、下記のようになります。 Maybe(Haskell) Optional(Swift/Java) Nullable(C#) これらは、「値がないこと」を表すもの、という見方では同じですが、それぞれ異なる価値観の元に作られています。 Maybe/OptionalとNullable これらはすべて型パラメータを取ります*1。 しかし、この中でNullableだけは型パラメータに
Log4Net のラッパーをつくる - ぐるぐる～
備忘録の意味も込めて。 やりたいことは、 Debug 系メソッドはリリースモードでは呼出しごと削除したい いちいち LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType); って書くのだるいから省略したい の 2 つ。 Debug 系のメソッドをリリースモードで呼出しごと削除する これは、ConditionalAttribute を使えば出来そうだと軽く考えていたんだけど、この属性、インターフェイスやら抽象メソッドやらには指定できないらしい・・・ まぁ、当たり前っちゃぁ当たり前なんだけど・・・ で、partial メソッドもなんかそれっぽいことに使えそう・・・と、思ったんだけど、こっちも制限が厳しすぎて実現不可能・・・ これも当たり前なんだけどね・・・ で、結局、ObsoluteAttribute と pragma
例外について色々と考えてみた - ぐるぐる～
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる〜から派生して、 「他の例外クラスを継承しただけの例外クラスを作らない」に不同意の理由 - Diary of Dary、 例外クラスの指針 - 猫とC#について書くmatarilloの雑記や、さらには Twitter で Java の検査例外と非検査例外についての議論へと発展したので例外についてまじめに考えてみた。 あくまで、今の自分の考えなので真に受けない方がいいかも！そもそも経験が少ないので、トンチンカンなことを言ってるかもしれません。 あ、それと、用語は基本的に Java から取ってきています。ただ、メソッドじゃなくて関数を使っているけど、これに深い意味はありません。多分。 例外とは まず、例外とは一体何者なのか、ということ。 ここでは面倒を避けるために、Meyer 先生の定義を借りること
NUnit 2.5 が便利すぎる - ぐるぐる～
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 との使い分けの指針としては、 コンパイル時定数
Java の enum - ぐるぐる～
イマドキの Java には enum があるんですよ実は、という話。 知ってるよそんなこと！な人は読むまでもないかも。 enum って？ 列挙型のこと。C とか C++ とか C# とかでおなじみのアレ。 単純な enum は Java でもこれらの言語の enum と同じような記述になるけど、これらの言語の enum が整数型をベースにしているのに対して、Java ではオブジェクトをベースにしている点が異なる。 まぁその話は後ほど・・・ 単純な enum ただ列挙するだけの enum なら、本当に C や C++ や C# とほとんど変わらない。 // 信号機の色 enum SignalColor { RED, BLUE, YELLOW } ただこれだけ。末尾には、余分なカンマがあってもいい。 enum SignalColor { RED, BLUE, YELLOW, } 更に、末尾にセ
コンストラクタで final なフィールドをあきらめない方法 - ぐるぐる～
思いつきエントリ。後で説明とか付け加える予定。付け加えた。 final なフィールドは基本的にコンストラクタ内部で初期化することしか出来ない。 でも、そのフィールドを初期化する方法が複雑な場合、素直に実装するとコンストラクタがどんどんふくれあがってしまう。 なのでメソッドに分割したい・・・というのはまぁ普通によくあることなんだけど、例えそのメソッドがコンストラクタからしか呼び出されていなかったとしても、 // コンパイルエラーになる public final class Hoge { final int hoge; public Hoge(int piyo) { prepareHoge(piyo); } // コンストラクタからしか呼び出されない private void prepareHoge(int piyo) { // 何かとても複雑な処理 // ... hoge = result;
再帰で考える - ぐるぐる～
再帰は関数型言語を構成する重要な部品の一つです*1。 しかし、手続型言語に慣れたプログラマにとって、再帰で考えるというのは難しいものがあります。 このエントリは、そういうプログラマが再帰で考えることができるようになるために書きました。 言語としては、F# と C# を使っています (推奨は F#。C# の例は実用性が無いに等しい) が、Java プログラマでもある程度読めるでしょう。 前提条件として、これらの言語の文法は知っているものとします。 特に、C# で言う Func デリゲートを多用します。 すごい長いので、時間があるときに一気にどうぞ。 再帰以外の話もちょろちょろと出てきます。 再帰の重要性 いきなりですが、再帰はあくまで最後の手段です。 普通は再帰をカプセル化した関数を使うことになります。 通常使わないのであれば、再帰を学ぶことに意味はないのでしょうか？ いいえ、それでも再帰を
そろそろPower Assertについてひとこと言っておくか - ぐるぐる～
タイトルはもちろん釣りで・・・はない！ ちょっと真面目に、Power Assertについて意見を述べたいのです。 そもそもPower Assertって何？ てきとーに説明すると、 普通の比較演算子で普通にassert書けば、失敗時に各部分式の値を表示してくれる ようなものです。 Groovy製のテスティングフレームワークであるSpockがおそらく本家大本です((要出典。こういう系の発想は割と昔からあったし、Spock以前に実装例がありそうな気がする。そもそも、Spockは最初からPower Assert持ってたのかも調べないといけない。ちなみに、式木を弄ってAssertを組み立てる、というものであれば(PowerAssertよりも情報量は少なくなるものだけど)、自分の知る限りだと2009年6月にこんな記事があります。 http://themechanicalbride.blogspot.j
よくあるコーディングパターンと LINQ to Objects の対応付け - 予定は未定Blog版
あると便利ですよね、ということで書いてみた。 よくあるコーディングパターンには 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
TestCase 属性などによるテストコードのリファクタリング - ぐるぐる～
昨日のわんくまの昼休みに TDD 道場があったんですが、テストコードのリファクタリングについて賛否あったのでちょっと自分の考えをまとめておきます。 それに加え、C# と NUnit でどのようにテストコードをリファクタリングできるか、というのも紹介します。 というかこちらがメイン。 テストを追加した際に追加したテストだけを実行するか全部実行するかというのも意見が分かれたんですが、主に個別に指定するのが面倒という理由で全部実行する派です。 全部実行すると時間がかかる？それはもはや単体テストじゃないですね。重いテストは分割して分離しちゃいましょう。 これに関してはレガシーコード改善ガイド (Object Oriented SELECTION)をどうぞ。機会があればここら辺についても書きたいところです。 テストコードのリファクタリングについて まず、テストコードのリファクタリングはありだと思いま
「変数に型がないということの利点について考える」の問題について考える - ぐるぐる～
id:perlcodesample さんの 変数に型がないということの利点について考える - サンプルコードによるPerl入門 から。 ううむ。 けれども、型がないということは、本当に素晴らしいことです。 型がないことによって、たくさんの面倒から解放されるからです。 冒頭のこれが、「静的型付き言語にはメリットが(ほとんど)ない」と言っているように思えてしまいます。 コメントのやり取りを見ても、ある程度そう考えているように受け取れます。 勘違いなどが多く見られたので、補足というか、反論というか、そんな感じのことを書きます。 追記： ごく一部、このエントリを「動的型付き言語と静的型付き言語を比べて、静的型付き言語の方が素晴らしい言語である」ということを言うためのものだと勘違いしている人を見かけました。 このエントリは、そこについては言及していません。 あくまで、元記事で「動的型付き言語のメリッ
SQLアンチパターン - ぐるぐる～
献本いただきました。ありがとうございます。 当たり前を当たり前にできる可能性を秘めた本 この本の素晴らしいところは、よく見る「悪い」方法を、「悪いこと」としてまとめてくれたことです。 今までは、筋のよくない設計やSQLを考え直してもらうためにあれこれと言葉を尽くして説明する必要がありました。 その結果として、直してもらえることもありましたが、直してもらえないことも多くありました。 この本が出たことによって、今後は「SQLアンチパターンという本にアンチパターンとして載っていますよ」と、強力な理由づけの一つとなるでしょう。 この本は「自分の中の当たり前をみんなのあたりまえにできる可能性を秘めている」と感じます。 参考文献 付録Bに参考文献がまとめられているのですが、新しい版が出ているものもありますので、自分の把握している範囲で補足します。 Joe Celko's SQL for smartie
複数の共通表式の使い方 - ぐるぐる～
「SQLクックブック ―データベースエキスパートのための実践レシピ集」を含むブログ - はてなキーワードで、自分のブログを除いて一番最近のブログのカテゴリ「SQL Server」を読んでびっくり。 はてなダイアリーとか、はてなダイアリーとか、それなんて今日のエントリの内容？ ・・・精進します。 で、ちょっと気になったのが、はてなダイアリーと、その続編 (?) のはてなダイアリーについて。 この解決案として、 BETWEEN 条件で絞った WITH 文を入れることで回避はできます とコメントしたものの、WITH 文はネストできないようです。 嘘のコメントをしてしまいました。 はてなダイアリー とあるんですが、そんなことないですよー。できます*1 *2。 WITH X([伝票日付], [借方金額], [貸方金額]) AS ( SELECT [伝票日付] , [借方金額] , [貸方金額]] F
C# から使いやすい F# コードの書き方 - ぐるぐる～
さて始まりました、F# Advent Calendar 2012 です。 今年は、「実用」がテーマと言うことで、F# で書いたコードを C# から使いたくなった時に気を付けるべきポイントなどをまとめました。 F# と C# で異なる名前を付ける F# では、module に定義する関数や変数の名前は、lowerCamel で付けるのが一般的です (List.map など)。 しかし .NET の世界では、これらの名前は基本的に PascalCase で付けることになっています。 CompiledName 属性を使うことで、この差を埋め、F# からは lowerCamel に、C# からは PascalCase に見える名前を付けることができるようになります。 (* F# *) module Util = [<CompiledName "ToStr">] let toStr x = spri
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる～
C# のコーディング規約としては、オブジェクト倶楽部のもの (PDF) が有名だけど・・・正直、これ使いたくない。 冒頭に「このドキュメントは Java コーディング標準(オブジェクト倶楽部バージョン)、VB.NET コーディング標準を C#用に変更したもの」なんて堂々と書いてる時点で・・・ で、この規約のどこが駄目なのか、なぜ駄目なのか、どうすればいいのかをまとめてみた。 なんだかんだで長文エントリ。 追記： ちなみに、C# の規約としてはクラス ライブラリ開発者向けのデザイン ガイドラインで十分だと思う。 更に追記： ブコメで教えてもらったんだけど、どうやらクラス ライブラリ開発のデザイン ガイドラインの方が新しいらしい。 2. ファイル構成 (1) ファイル名 public クラスはそのクラス名の 1 ファイルにする。 例：public class Customer は、Custom
Java やってる人が C# を使うとはまること - ぐるぐる～
ここでは、Java SE 5.0 以降を知っている人が C# 2.0 を使うことになった場合を考える*1 *2。 あと、ライブラリについては触れないことにする*3。 命名規約 まず、命名規約が全然違う。Java ではメソッド名にキャメル形式*4を使うけど、C# では Pascal 形式*5を使い、Java では定数名に大文字アンダーバー区切り*6を使うけど、C# では Pascal 形式を使う。 C# に関する命名規約としては、ここだとかここだとかにあるので、参考にするといい。 間違っても、オブジェクト倶楽部のは参考にしないこと*7。 struct の扱い Java ではユーザ定義型は全て参照型だけど、C# では値型も作成できる。また、標準ライブラリの中に struct で定義されたものもある。 で、何にはまるかというと、struct は class と違い、「値渡し」される*8、つまりコ
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
