タグ

ブックマーク / bleis-tift.hatenablog.com (19)

  • 続・そろそろ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#用のテスティングフレームワークを拡張するライブラリとして作られています。 ただ、ざっくり概要をつかむだけであればどちらも知らなくても問題ありません。 このライブラリででき

    続・そろそろPower Assertについてひとこと言っておくか - ぐるぐる~
  • F#でWPFやるときのTipsとか(その1) - ぐるぐる~

    最近、Full F#でWPFしてるので、Tipsてきなものをまとめようと思います。 その2はTipsがたまればあるかもしれませんが、過度な期待はしないでください。 プロジェクトの作り方 基的には、Pure F# WPF GUIアプリ開発に向けてに書いてある通りです。 細かい注意点があるので書いておきます。 .NET Frameworkの選択に関する注意点 .NET Frameworkを4.5.1や4.5.2などのような3桁のものを選ぼうとすると、プロジェクト作成に失敗します。 また、4.6を選んでも4.5として作られるので、その点にも注意しましょう。 初回以外での作成 言うまでもないことかもしれませんが一応。 一回でも「F# Empty Windows App (WPF)」を使ってプロジェクトを作った場合、それ以降は「オンライン」の方ではなく、「インストール済み」のテンプレートを選ぶこと

    F#でWPFやるときのTipsとか(その1) - ぐるぐる~
  • Scalaのnull/Nothing/Nil/Noneはやりすぎなのか? - ぐるぐる~

    Twitterしてたら目に入ったので軽く。 Javaにおけるnull。これまでとこれから この後のスライドで、 Scalaにおける「何もないもの」の分類はやり過ぎ感はある と言われているんですが、ある程度は誤解に基づく意見だよなぁこれは、ということを言っておこうかなと。 Scalaについて 日では説明が不要なくらいScalaって有名になってると思うんですが一応。 ScalaはJVMの上で動作する、(クラス指向の)オブジェクト指向プログラミングと関数型プログラミングを融合させた言語です。 そして、Scalaのコア機能はどちらかというとオブジェクト指向プログラミング寄りです。 オブジェクト指向プログラミングをベースに、関数型の色々なものを実現している感じです*1。 オブジェクト指向プログラミング的な機能として真っ先に思いつくのは何でしょうか? 割と上位の方に、「継承」とか「型階層」とか来るん

    Scalaのnull/Nothing/Nil/Noneはやりすぎなのか? - ぐるぐる~
  • Ruby嫌いがアンダースタンディングコンピュテーションを読んで - ぐるぐる~

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

    Ruby嫌いがアンダースタンディングコンピュテーションを読んで - ぐるぐる~
  • Git と GitHub を体験しながら身につける勉強会行ってきた - 予定は未定Blog版

    9/18(土) 15:30~ GitGitHubを体験しながら身につける勉強会(名古屋) : ATND 行ってきました。 なんかいろいろと話すことになったんですけど、あの場で言いそびれたこととか、もっとこう説明してればよかったなぁ、って部分の補足も兼ねたエントリです。 長文注意。 ショートカット git add の話 git add -p/git reset -p の話 リビジョン番号がない話 ブランチの話 git-completion の話、__git_ps1 の話 コミットの指定の話 reset の話 rebase と merge の話 公開したものの rebase の話 stash の話 TortoiseGit、HG、SVNのはなし 全体を通して git add の話 Git と SVN では、add に限らず、同じ名前のサブコマンドでも意味が異なるものがいくつかあります。 その中

    Git と GitHub を体験しながら身につける勉強会行ってきた - 予定は未定Blog版
  • そろそろPower Assertについてひとこと言っておくか - ぐるぐる~

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

    そろそろPower Assertについてひとこと言っておくか - ぐるぐる~
  • C# 使いから見てうらやましい Java8 の default 実装の使い方 - ぐるぐる~

    Java8 から追加されるインターフェイスの default 実装ですが、C# の拡張メソッドに似てますよね。 実際、このどちらも「シンインターフェイス」を定義するだけで「リッチインターフェイス」が手に入ります。 しかし、C# の拡張メソッドと Java のインターフェイスの default 実装には、それぞれの利点と欠点があります。 拡張メソッドの利点 拡張メソッドの利点は、インターフェイスの実装者だけでなく、 インターフェイスの使用者に対してもインターフェイスの拡張が開かれている点です。 既存の型ですら、後付けでメソッドを追加することができるということです。 using System; public static class StringExtension { // インターフェイスでなくても、どんな型に対しても拡張可能 public static int ToInt(this str

    C# 使いから見てうらやましい Java8 の default 実装の使い方 - ぐるぐる~
  • Java 8を関数型っぽく使うためのおまじないをC#でやってみた - ぐるぐる~

    Java 8を関数型っぽく使うためのおまじない - きしだのはてな Java は大変ですね。 C# さんは、ラムダ式も Func 型(Java の Function 型に大体対応)も Visual Studio 2008 時代(5年前)から使えたので、似たようなことはすでにできます。 上記の記事のパクリなので、上記の記事をまずは読んでから読むことをおすすめします。 Func 型 C# では Func デリゲートというものがあります。名前空間名や型パラメータまで含めると、System.Func<TArg, TResult> です。 こんな感じで使います。 Func<string, string> enclose = s => "[" + s + "]"; これを呼び出そうとすると、こんな感じになります。 // Javaだとenclose.apply("foo")と、applyが必要 Syst

    Java 8を関数型っぽく使うためのおまじないをC#でやってみた - ぐるぐる~
  • 「変数に型がないということの利点について考える」の問題について考える - ぐるぐる~

    id:perlcodesample さんの 変数に型がないということの利点について考える - サンプルコードによるPerl入門 から。 ううむ。 けれども、型がないということは、当に素晴らしいことです。 型がないことによって、たくさんの面倒から解放されるからです。 冒頭のこれが、「静的型付き言語にはメリットが(ほとんど)ない」と言っているように思えてしまいます。 コメントのやり取りを見ても、ある程度そう考えているように受け取れます。 勘違いなどが多く見られたので、補足というか、反論というか、そんな感じのことを書きます。 追記: ごく一部、このエントリを「動的型付き言語と静的型付き言語を比べて、静的型付き言語の方が素晴らしい言語である」ということを言うためのものだと勘違いしている人を見かけました。 このエントリは、そこについては言及していません。 あくまで、元記事で「動的型付き言語のメリッ

    「変数に型がないということの利点について考える」の問題について考える - ぐるぐる~
  • 遅延評価いうなキャンペーンとかどうか - ぐるぐる~

    遅延評価については以前も書いてるんですが、そのときは結論なしでした。 が、ちょっと考えるところがあって、言語を Java に絞って自分の考えを明確にしておきます。 結論から書きましょう。 「Java(とC#) で遅延評価って書いてあるものは遅延評価ではない」です。 Java における「評価」とは まず一番最初に、Java で「評価」って言うと、どういうことを指すのかを確認しておきます。 言語仕様の該当部分を要約すると、こんな感じでしょうか。 プログラム中の式を評価すると、結果は 変数 値 無し のうちのどれかとなる。 評価した結果が値になる、というのはいいでしょう。それ以外の 2 つを軽く説明します。 評価の結果が「変数」とは? コメント欄で指摘が入っています。 代入の結果は変数ではありません(15.26)。 結果が変数となるのは、ローカル変数、現在のオブジェクトやクラスの変数、フィールド

  • Java の語彙で Maybe を説明してみる - ぐるぐる~

    java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます!そう、直和型なんです!とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe? null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの?」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;

    Java の語彙で Maybe を説明してみる - ぐるぐる~
  • JSX の進化速度が半端ない - ぐるぐる~

    気に入らない所を直して pull request 投げたら、取り入れられたので、8 日前に書いたエントリが過去のものとなっちゃいました。 関数型 以前の JSX では、関数型は function(: int): string のように書く必要がありました。 これはこれでそのまま使えるのですが、新たに (int) -> string という形式にも対応しました。 ちなみに、複数引数はカンマ区切りで (int, boolean) -> string のようになります。 カリー化された関数は、 function(: int): function(: number): string の代わりに (int) -> (number) -> string と書けます。 引数を囲むカッコは、(今のところ) 省略不可能です。 これには 2 つの理由があります。 この機能を追加したとき、JSX のパーサの能力

    JSX の進化速度が半端ない - ぐるぐる~
  • JSX のアレな所 - ぐるぐる~

    注意!このエントリは既に古いので、JSX の進化速度が半端ない - ぐるぐる〜もあわせて読んでください。最新のコードを参照するのが手っ取り早いです。 JSX なる言語がリリースされました。 この言語が謳っているのが、 高速 安全 簡単(生産性が高い、とも) という 3 点です。 高速と安全はまぁいいでしょう*1。 問題は、はたしてこの言語は簡単なのか?という点です。 簡単かどうかは人によるのでアレなのですが、まぁ一部の人にとっては簡単とは言えない (というか書く気がしない) 書き方を強制されるのです。 関数型 数値を受け取って文字列を返す関数を表す型は、JSX では以下のように書きます。 function(:number):string これ単体で見ると分かりやすそうな気配はします。 では、これ読めますか? function f(g: function(:number):number):

  • すごい Haskell たのしく学ぼう!は本当にすごいのか? - ぐるぐる~

    すごいHaskellたのしく学ぼう! 作者: Miran Lipovača,田中英行,村主崇行出版社/メーカー: オーム社発売日: 2012/05/23メディア: 単行(ソフトカバー)購入: 19人 クリック: 552回この商品を含むブログ (36件) を見る 今話題の、すごい Haskell たのしく学ぼう!を読んだのですが、ちょっと思ったことがあるので書評と合わせて書いておきます。 思ったこと 関数型言語がこれほど話題になるのはとても嬉しいことです。 しかし、一方で懸念点もあります。 ノリで「すごい」とだけ言う人たちがいる その人たちに乗せられて (自分には合わないのに) 買ってしまって、挫折してしまう人が出てきそう このは、いいです。 翻訳の質も素晴らしく、読んでいて「読みにくいな」と思った部分はありません。 それに加え、訳注と Appendix も素晴らしい。 しかし、誰にで

    すごい Haskell たのしく学ぼう!は本当にすごいのか? - ぐるぐる~
  • 再帰で考える - ぐるぐる~

    再帰は関数型言語を構成する重要な部品の一つです*1。 しかし、手続型言語に慣れたプログラマにとって、再帰で考えるというのは難しいものがあります。 このエントリは、そういうプログラマが再帰で考えることができるようになるために書きました。 言語としては、F# と C# を使っています (推奨は F#。C# の例は実用性が無いに等しい) が、Java プログラマでもある程度読めるでしょう。 前提条件として、これらの言語の文法は知っているものとします。 特に、C# で言う Func デリゲートを多用します。 すごい長いので、時間があるときに一気にどうぞ。 再帰以外の話もちょろちょろと出てきます。 再帰の重要性 いきなりですが、再帰はあくまで最後の手段です。 普通は再帰をカプセル化した関数を使うことになります。 通常使わないのであれば、再帰を学ぶことに意味はないのでしょうか? いいえ、それでも再帰を

    再帰で考える - ぐるぐる~
  • TDD の基礎体力と、TDD に対する想い - ぐるぐる~

    TDD Advent Calendar 2011 の 4 日目の参加エントリです。 前半では、TDD を学ぶ前に身に付けておくといいと思う基礎体力について書きました。 後半は、まぁ、その。後悔はしていません。反論ウェルカム、議論しようぜ。 不安をテストに 「レッド - グリーン - リファクタリング」は、TDD の根っこの部分であり、これ自体が「どう TDD をやればいいか」を教えてくれるものではありません。 それに対して、「不安をテストに」というのは、「どう TDD をやればいいか」という指針を与えてくれる言葉です。 この言葉自体は、TDD Boot Camp で自分のものにできました。 不安については、テスト駆動開発入門では (言及されているものの) 自然に組み込まれていて、最初に読んだときには全然気づきませんでした。 しかし、TDDBC で id:t-wada (和田さん) に短くて

    TDD の基礎体力と、TDD に対する想い - ぐるぐる~
  • デブサミ 2011 で F# について話してきました! - ぐるぐる~

    発表資料は slideshare にあげました。暇ができたらもうちょっと補足とか書きたいですね (書かないフラグ)。 ページ数は 273 ページと、ありえない枚数ですけど、内容としては 90 ページもないはず! C#(VB)プログラマのためのF#入門View more presentations from bleis tift. 発表終了時間を 10 分勘違いしていて、かなり早めに終わってしまった・・・ 発表時の Twitter の様子は デブサミ2011【17-D-7】C#(VB)プログラマのためのF#入門 bleis-tift 氏 - Togetter をどうぞ。 ・・・なんかおかしいのも混ざってますけど気にしない方向で!

    デブサミ 2011 で F# について話してきました! - ぐるぐる~
  • 考え方の違い - ぐるぐる~

    最近、考え方に大きな溝があることに気づいた。 周りのみんなはこんな感じ。 ソースから何かを読み取ろうとはしない プレーンテキスト*1を使うことを退化だと考えている コードを割り当てることが設計だと思っている節がある 同じコードブロックに対するテストが複数箇所に存在しても気にしない*2 ソースから何かを読み取ろうとはしない 真っ先にソース読むべきとは言わないけど、ソースを読まなさすぎるのもどんなもんかと。 つか、ドキュメント同士のつながり云々言うなら、それこそHTMLとか使ったほうがいいんじゃないか、とか思わなくもない*3。 まぁ、あれだけ汚いソースを書いてれば読む気もなくすってもんだろうけど、ドキュメント類はさらにひどいという何のためにドキュメントを作ってるか全くわからない。 プレーンテキストを使うことを退化だと考えている みんななんであんなにExcel*4好きなんだろうと疑問に思ってたん

    考え方の違い - ぐるぐる~
  • Nimbusを試してみた - ぐるぐる~

    とりあえずコンポーネントをぽちぽちと配置して、mainメソッドの先頭で UIManager.setLookAndFeel("com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel"); とすればOK おぉ、かっこいい。Swing Metalとの差は歴然だな。 追記: C:\Program Files\Java\jdk1.6.0_07\demo\jfc\SwingSet2に入っているSwingSet2.jarを、 C:\Program Files\Java\jdk1.6.0_07\demo\jfc\SwingSet2>java -jar^ -Dswing.defaultlaf=com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel SwingSet2.jar としてみた。 これもなかなかいい感じ。

  • 1