はてなブックマーク

今年いっぱいで株式会社オンザロード(以下OTR)を退職することになりました。 有給消化は9月からずっと半休という形で取るという形だったのはちょっと珍しいかもしれません。 OTRに入ったのは2010年1月1日ですから、11年勤めたことになります。 企業のIT化を進める会社(とか開発スタイル)のIT化が当時の自分としては全然進んでいないと感じていたところ、 「そういうこと自分で好きにやっていいよ」と誘われて入社しました。 「少なくともそういう環境が自分の手で作れるまではこの会社にいよう」と思っていたので、 実際に開発面でやりたいことを一通りやった後も留まっていたのは、ふりかえるに次の2点があったからです。 自分にとって理想的なチームで働ける 出来るなら手段は問わないという雰囲気 今回はチーム移籍ということで、1点目の利点は引き続き得られます。 2点目については、OTRにいる中である意味において

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

最近Terraformを勉強してたんですが、日本語でTerraformの文法について説明しているものが見当たらなかったのではまった(?)ところまで書いてみました。 Terraformの文法？ 正確にはHCL(HashiCorp Configuration Language)の文法です。 TerraformというツールにHCLという文法に従って書かれたファイルを食わせると、 その内容(意味)をツールが読み取って実行します。 設定ファイル 設定ファイルのトップレベルに書けるのは、コメントを除くと次の3つの要素です。 属性 ブロック 1行ブロック 設定ファイルにはこれらを複数(0個でもいい)並べられます。 例えば、ブロック、属性、属性、ブロック、1行ブロック・・・のような書き方が許されているということです。 これを公式ドキュメントでは ConfigFile = Body; Body = (Att

先日のエントリの反応として、多値の批判をしているように受け取られた方がいました。 実際には、多値の批判をしているのではなく、Go言語の「多値とそう見えるけど違うものがある」という仕様を批判したものでした。 また、タプルにこだわっているという受け取り方をした方もいました。 このエントリでは、「タプルにこだわっているのではない、多値にこだわっているのだ」ということを説明しようと思います。 このエントリで出てくるコードは言及がない限り妄想上のもので、実際の言語のコードではありません。 長いから3行で。 スタックマシンと多値は仲良し。継続と多値も仲良し。 多値は多値、タプルはタプル、みんなちがってみんないい。 多値とは、カンマで区切られた単なる複数の値だよ。妄想だけどね。 これで満足して仕事に戻っていただいて構いません。以下オマケ。 多値とタプルの違い まず、多値とタプルの意味的な違いについてをは

最近色々あって仕事でGo言語を使っています。 色々割り切っている言語なので、こんなこと言ってもしゃーないんですが、言語設計はミスってるんじゃなかなぁ、と思わざるを得ない点が多々あります。 使い始めて1か月くらいなので間違ったことを書いているかもしれませんので、何かあれば指摘していただけるとありがたいです。 本文ではネガばかり羅列していますが、ランタイムとツール周りは気に入っています。 Goのランタイムを使う、もっと洗練されたAlt Go的なものがあるといいのに(もしくはジェネリクスのったGo2を早くリリースしてほしい)、と思う日々です。 追記: なんか意図とは違った受け取られ方をしている方もいるので追記します。 この記事はあくまで、「Go言語を学ぶにあたって躓いた点」を列挙し、まとめ、理由を考えてみる(教えてもらう)ために書いたものです。 Go言語自体はDisってますが、Go言語ユーザーを

F# Advent Calendar 2017の4日目の記事です。 NGK2017B昼の部でパーサーコンビネーターについてLTしてきたので、その内容について書きます。 ただし、内容は大幅に加筆修正しています。 PCさえあればいい。 from bleis tift 導入 世の中にはパースすべきものであふれています。 例えば、下記のようなものがあります。 ログ 設定ファイル ミニ言語(DSL) プログラミング言語 構造を持ったものはそこら中にあります。 これらを処理するためにどうすればいいでしょうか。 一つの方法として、正規表現を使うというものがあります。 しかし、(本来の)正規表現ではネストする文法などは扱えません。 拡張機能として、ネストする文法が扱えるようになっているような処理系もあります。 しかし、そもそもそんな複雑な正規表現には近寄りたくないですよね。 では、文字列操作関数を駆使して

この記事はC# Advent Calendar 2016の12日目のものです。 昨日(今日)書いた、F# Advent Calendar 2016 11目のC#版です。 今日のリポジトリはこちら。 github.com 実は、F#版だけじゃなくてC#版の実装もあります。 ということで、そのざっくりした紹介です。 型クラス？コンセプト？ F#版では「型クラス(type class)」と呼んでいますが、C#版では「コンセプト(concept)」と呼んでいるようです。 で、コンセプトがあると何がうれしいかですが、例えばC#には現在3つの2要素タプルがあります。 System.Collections.KeyValuePair<TKey, TValue> System.Tuple<T1, T2> (T1, T2) これらの型すべてに対応するためには、現在のC#ではオーバーロードを3つ書く必要がありま

この記事はF# Advent Calendar 2016の11日目のものです。ちょっと遅れてしまいました。。。 ICFP 2016(と併催されたML workshop?)で気になる内容があったので、ちょっとまとめてみました。 Classes for the Masses - ICFP 2016 ざっくり、F#に型クラスを導入してみたぜ、って内容です。 型クラスとは JavaやC#での interface みたいなものですが、interface は侵入的なのに対して、型クラスは非侵入的という違いがあります。 侵入的というのは、型の定義にその interface を実装しますよ、ということを書く必要があることを意味します。 // C# interface Eq<A> { bool Equal(A a, A b); } // intefaceは型に侵入する class SomeClass : E

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

F#でWPFやるときのTipsとか(その1)の続編です。 添付プロパティの作り方 F#で添付プロパティを作るには、添付プロパティの本体はプロパティではなくフィールドに保持する必要があるようです。 // ダメな例 type Sample private () = static member SomeValueProperty = DependencyProperty.RegisterAttached("SomeValue", typeof<string>, typeof<Sample>, FrameworkPropertyMetaData("", Sample.OnSomeValueChanged)) static member GetSomeValue(obj: DependencyObject) = obj.GetValue(Sample.SomeValueProperty) :?> s

最近、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)」を使ってプロジェクトを作った場合、それ以降は「オンライン」の方ではなく、「インストール済み」のテンプレートを選ぶこと

またの名を入門コンピュテーション式(嘘 この記事は、「コンピュテーション式ってどうやって作ればいいの？」に対する自分なりの回答です。 matchのネスト optionを返す3つの関数f, g, hがあったとします。 で、このような処理がしたいとしましょう。 let niceFunction (arg1, arg2, arg3) = match f arg1 with | Some x -> match g arg2 with | Some y -> match h arg3 with | Some z -> Some (x, y, z) | None -> None | None -> None | None -> None この関数は、3つの関数すべてが成功したときだけ、その結果をまとめて成功として返しています。 それ以外は何もせずに失敗として返しています。 このように、「すべて成功した

この記事はF# Advent Calendar 2015の17日目の記事です。 今日はコンピュテーション式の Combine について取り上げます。 詳説コンピュテーション式をある程度理解していると分かりやすいかもしれません。 内容を簡単にまとめると、 Delay の中で受け取った関数を実行する場合、副作用を考慮したときに問題が起こらないか考えること ゼロ値がある型で Combine を実装するときは、Delay の中で受け取った関数を実行せずに、Combine の中で実行すること ゼロ値がない型で Combine を実装するときは、Combine の実装は Bind に流し、Zero は M<unit> を返すように実装すること です。 Combineの目的 Combine は、コンピュテーション式の2つの式を繋ぐために使います。 コンピュテーション式中の変換対象となる式を ce プレフ

この記事はF# Advent Calendar 2015の13日目の記事です。 タイトルは釣りで、今回はMicrosoft/visualfsharpリポジトリをウォッチしている中で見つけた個人的に面白かったIssueを取り上げます。 名前空間内でのprivateの意味 現状のF#では、名前空間内でprivateを使った場合に、privateっぽくない挙動を示します。 同じプロジェクト内に、M1.fs, M2.fs, M3.fsを下記の内容のように作ってください。 (* M1.fs *) namespace NS module private M1 = let x = 10 (* M2.fs *) namespace NS module M2 = let x = M1.x (* OK *) (* M3.fs *) namespace NS.Child module M3 = let x =

この記事はF# Advent Calendar 2015の5日目の記事です。 4日目は@n_enotの「F# でTDDした話 前編？」でした。 ※業務連絡。F# Advent Calendar 2015の参加者の皆さん、今年は登録順ではなく、申請順になってしまっているようなので、イベントページに登録はしたけどまだ書く日付が決まっていない方は、イベントページを編集して書きたい日に自分の名前を書いておくようにしましょう。 関数型の何かと思った？ 残念、クラスベースオブジェクト指向プログラミングの話でしたー。 今までF#のクラス定義に関する機能がよくわかっていなかった(まともに使ってこなかった、といってもいい)ので、ちょっとまとめつつ勉強してみました。 基本的に、言語仕様の「8.6 Class Type Definitions」をまとめた内容になっています。 より実践的な方向から再構成しているの

元ネタ: 僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記 OOPの文脈で見ると、元の記事が言っていることもわからなくはないのですが、対象が広すぎていろいろと不正確になってしまっているので、ちょっとまとめてみます。 元の記事が対象にしているのは、Maybe / Optional / Nullableの3つです。 対応する型を持つ言語を見てみると、下記のようになります。 Maybe(Haskell) Optional(Swift/Java) Nullable(C#) これらは、「値がないこと」を表すもの、という見方では同じですが、それぞれ異なる価値観の元に作られています。 Maybe/OptionalとNullable これらはすべて型パラメータを取ります*1。 しかし、この中でNullableだけは型パラメータに

centerclr.doorkeeper.jp 直前で定員を増やしてもらえたので、参加できました。 会自体について 内容は主にILの話と式木の話で、ディスカッションというよりは講義に近い感じでした。 個人的にはディスカッション寄りの会を期待していたのですが、知識レベルにばらつきがあったのと、初めての取り組みということで仕方ないのかな、と。 次回以降で、もしディスカッション寄りの会をやりたいなら、「この本を読了しており内容についてもある程度理解していること」とかにした方がより濃い内容のディスカッションができると思います。 聴講のみの席も用意すると、「ディスカッションに参加するのは怖いけど話は聞きたい」って人も参加できますし*1。 最初にKPTをして今回の方向性を決めよう、という試みは面白くはありましたが、会の最初にKも何もないので、KPTにとらわれずに「知りたいこと」「議論したいこと」みたい

シャドーイングのない言語と、イミュータブル中心のプログラミング(以下イミュータブルプログラミング)の相性って悪いのでは？と思ったのでブログに残しておきます。 シャドーイングとは 既存の変数と同名の変数を定義して、そのスコープで既存の変数にアクセスできなくする機能です。 例えば、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) {

連載目次 再帰関数のスタックオーバーフローを倒す話 その1 CPSとCPS変換の話 再帰関数のスタックオーバーフローを倒す話 その1.5 F#での「末尾」についての話 再帰関数のスタックオーバーフローを倒す話 その2 .NETにおける末尾最適化の方法についての話 再帰関数のスタックオーバーフローを倒す話 その2.5 継続モナドと、F#の残念さの話 再帰関数のスタックオーバーフローを倒す話 その3 ← 今回 すべてをあきらめて再帰をwhileに書き直す方法の話 はじめに 再帰関数のスタックオーバーフローを倒す話 その2の続きで、最後です。 前回はCPS変換じゃスタックオーバーフローが回避できない場合もあるよという話でした。 前提知識は、F#と、スタックについてです。 これまではCPSの話を中心にしてきましたが、この記事ではCPSの知識とか不要です。 F#で再帰関数によってスタックオーバーフロ

連載目次 再帰関数のスタックオーバーフローを倒す話 その1 CPSとCPS変換の話 再帰関数のスタックオーバーフローを倒す話 その1.5 F#での「末尾」についての話 再帰関数のスタックオーバーフローを倒す話 その2 .NETにおける末尾最適化の方法についての話 再帰関数のスタックオーバーフローを倒す話 その2.5 ← 今回 継続モナドと、F#の残念さの話 再帰関数のスタックオーバーフローを倒す話 その3 すべてをあきらめて再帰をwhileに書き直す方法の話 はじめに 再帰関数のスタックオーバーフローを倒す話 その1ではCPS変換について、 再帰関数のスタックオーバーフローを倒す話 その1.5では末尾呼び出しについて、 再帰関数のスタックオーバーフローを倒す話 その2では2種類の末尾呼び出しの最適化について話しました。 今回は、継続渡しスタイルがつらい人*1をモナドで救う話をします。 最初

連載目次 再帰関数のスタックオーバーフローを倒す話 その1 CPSとCPS変換の話 再帰関数のスタックオーバーフローを倒す話 その1.5 F#での「末尾」についての話 再帰関数のスタックオーバーフローを倒す話 その2 ← 今回 .NETにおける末尾最適化の方法についての話 再帰関数のスタックオーバーフローを倒す話 その2.5 継続モナドと、F#の残念さの話 再帰関数のスタックオーバーフローを倒す話 その3 すべてをあきらめて再帰をwhileに書き直す方法の話 はじめに 再帰関数のスタックオーバーフローを倒す話 その1の続きです。 前回はCPS変換することでスタックオーバーフローが回避できるよやったー！という話でした。 今回は、CPS変換じゃスタックオーバーフロー回避できない場合もあるよ、という話をします*1。 前提知識は、その1の記事を理解していることと、ILがなんとなくわかることです。

連載目次 再帰関数のスタックオーバーフローを倒す話 その1 CPSとCPS変換の話 再帰関数のスタックオーバーフローを倒す話 その1.5 ← 今回 F#での「末尾」についての話 再帰関数のスタックオーバーフローを倒す話 その2 .NETにおける末尾最適化の方法についての話 再帰関数のスタックオーバーフローを倒す話 その2.5 継続モナドと、F#の残念さの話 再帰関数のスタックオーバーフローを倒す話 その3 すべてをあきらめて再帰をwhileに書き直す方法の話 はじめに 前回は、CPS変換によって再帰関数のスタックオーバーフローを回避する方法を紹介しました。 その中で、「末尾呼び出し」という言葉が出てきましたが、詳細については触れませんでした。 この記事では、本題からはちょっと脇道に逸れて、F#においては何が「末尾」で何が最適化の対象となる「呼び出し」なのかを説明します。 前提知識として、上

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

再帰関数のスタックオーバーフローを倒す話を何回かに分けてします。 連載目次 再帰関数のスタックオーバーフローを倒す話 その1 ← 今回 CPSとCPS変換の話 再帰関数のスタックオーバーフローを倒す話 その1.5 F#での「末尾」についての話 再帰関数のスタックオーバーフローを倒す話 その2 .NETにおける末尾最適化の方法についての話 再帰関数のスタックオーバーフローを倒す話 その2.5 継続モナドと、F#の残念さの話 再帰関数のスタックオーバーフローを倒す話 その3 すべてをあきらめて再帰をwhileに書き直す方法の話 はじめに 継続渡しスタイルもしくは継続渡し形式(Continuation Passing Style、以降CPS)という言葉を聞いたことがあるでしょうか。 今日はCPSの話をします。 前提知識は、F#のみです。 継続とは CPSの前に、まずは継続の話です。 継続と言って

テストの自動化を考える前に from bleis tift 発表してきました。 テストツール編なのに、Javaにもテストツールにも関係のない、テスト自体の話です。 それなりに反応は良かったかな？ 資料作ってる時に、盛り込み過ぎだったので資料から抜いたものを独立して別の資料にしたので、時間があったらそっちも発表しようかなー、と思っていたんですが、なかったので公開だけしておきます。 効果の低いテストの話 from bleis tift 異論は認める。

FSharperならこう書く(A Poker Game Program) #FsAdventというエントリがF# Advent Calendar 2014の8日目の記事として公開されました。 この記事自体は、主に設計よりな話をしていますが、ここでは実装寄りの話を中心に、 勝手に添削してみました。 また、記事の中に書かれていた疑問にも回答したりしています。 添削その1(全体) 型とモジュールの名前 元のコードでは、モジュールの中にTという型を入れるスタイルのようです。 (* 柄 *) module Suit = (* 柄 *) type T = | Spade | Heart | Diamond | Club (* 全ての柄 *) let values = [Spade; Heart; Diamond; Club] 自分も昔はこんな感じにしていたのですが、現在のところこのスタイルはやめ、モジ

.NET系開発者から見たJava from bleis tift なごやかJava第一回で、「.NET系開発者から見たJava」というタイトルで発表してきました。 Javaのこの機能って.NET開発者から見てどうなの？というような内容です。 大阪から参加してくれた方の感想を載せておきます。 おかしい、終わった後の感想が「F# すごい！」だ…… #ngojava— irof@Javarista (@irof) 2014, 11月 30