関数の話 - ( ꒪⌓꒪) ゆるよろ日記
こんにちは、しいたけです。 某所で関数型プログラミングとはリスト処理のことなのか、と燃えているのを見て、関数型プログラミングとは何か、ということを自分なりの考えを述べたいと思いました。春なので。 この資料は2年ほど前にSupershipの社内勉強会で使ったものですが、この中で関数とオブジェクトを対比している箇所があります。 関数もオブジェクトも、変数や関数の引数戻り値として扱える第1級の値であり、状態を持ち(メンバー変数/クロージャ)、組み合わせが可能(delegate, composition/関数合成)、である、と。 ではオブジェクト指向と関数型プログラミングで何が決定的に異なるかというと、設計・実装のアプローチに何を中心に据えるか、ということだと思います。 オブジェクト指向では、クラス・オブジェクトをモデリングし、各種のオブジェクト指向的デザインパターンを用いてオブジェクト同士を組み
ほとんど使われていないマニアックな機能「事前定義 (Early Definitions)」- Scala Advent Calendar jp 2011 Day 5 - ( ꒪⌓꒪) ゆるよろ日記
このエントリは Scala Advent Calendar jp 2011 の5日目です。 Scalaやってる人なら一度はScala言語仕様に目を通したことがあると思います無いとは言わせない。 この言語仕様を見ると、たまに思いもよらない発見があったりしますが、その中でほとんど利用されているところを見たことがない不遇な機能「5.1.6 事前定義 (Early Definitions)」について書こうと思います*1。 事前定義 (Early Definitions)とは? テンプレートを事前フィールド定義(early field definition)節で始めることができ、それにより スーパー型のコンストラクタがコールされる前に、ある特定のフィールド値を定義できます。 次のテンプレート中で { val p1 : T1 = e1 ... val pn : Tn = en } with sc wi
Scalaにおける型パラメータの部分適用 [({type F[X] = G[A,X]})#F] について - ( ꒪⌓꒪) ゆるよろ日記
Tumblrから出戻ってきました。 8/4のLL DecadeのLT大会に出るのでぜひお越しください。 さて、モナってますか? scalazなどでよく出現する[({type F[X] = G[A,X]})#F]のようなコードですが、これが何を意味しているのか最近やっと理解できたので、久しぶりにScalaの事書きます。 この記事はhigher kinded type(高階型)を理解していることが前提です。 結論からいうと、型パラメータの部分適用を行うためのテクニックです。以下のサンプルコードはscalazを使ってます。 用語 まず、この記事で使う用語を定義します。 higher kinded type(高階型) 「いくつかの型パラメータを取る型コンストラクタ」のこと。 例えば、ListはList[Int]のように、「型パラメータをひとつ取る型」なので高階型。 Eitherは、Either[T
![Scalaにおける型パラメータの部分適用 [({type F[X] = G[A,X]})#F] について - ( ꒪⌓꒪) ゆるよろ日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/a32b6ca079c3712cb28916037d8cc602d6bfe520/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12704346814673874946%2F12704591929888370155%2F1343889672)
Scalaでの例外処理 - Either,Option,util.control.Exception - ( ꒪⌓꒪) ゆるよろ日記
今日はScalaの例外処理について解説しますよ。 基本 - try,catch,finally 例外処理の基本は、try,catch,finallyです。これはJavaと同じですね。 ただし、Scalaでのtry,catch,finallyは値を生成します。つまり、実行されたブロックの値が評価されます。 scala> val n = try{ "99".toInt } catch { case e:Exception => -99 } n: Int = 99 scala> val n = try{ "foo".toInt } catch { case e:Exception => -99 } n: Int = -99 上記のように、catch節には "case e:Exception => ..."のようなパターンマッチを書くことで、対応する例外の型に応じて補足することができます。try,
設計を型にエンコードするということ - ( ꒪⌓꒪) ゆるよろ日記
動的型付け vs 静的型漬けのアレでもんにょりしてたのをついったーに放出して会話してたらなんとなく自分なりの考えがまとまったので貼っておく。 ……(ファントムタイプとか型安全ビルダーパターンとかで、型レベルにロジックをエンコードした結果、ライブラリ利用者がテストを書くまでもなく適切にライブラリを利用できるようになる、という意味での「静的型でコンパイラは最強のテスティングフレームワーク」という視点があると思う)— 蒸発プログラマさん (@yuroyoro) 2013年3月11日 @yuroyoro 最初のメジャーなテスティングフレームワークがJUnitなので違和感を感じます。— ぎゃばんぱみゅぱみゅさん (@ledsun) 2013年3月11日 @ledsun メジャーかそうでないかで言われると反論しようがないですが、捉え方というか視点として、ビジネスロジックを型レベルにエンコードして、テス
Jenkinsで外部パラメータで与えたブランチを対象にビルドできるようにしておくと凄惨性あがって墓ドル - ( ꒪⌓꒪) ゆるよろ日記
テストが終わるまでの時間で書いてみる。 Jenkinsでジョブを実行させるときに、外部パラメータで任意のブランチを対象にビルドできると墓ドル。 例えば、自分のローカルブランチをマージするまえに、テストが通るか確認したい場合とか。 そんなのローカルでテストすりゃーいいじゃんって言われるかもしれないが、 テスト全部通すのに時間が掛かるようになってると、とりあえずCIに実行を投げておいてあとで確認するほうがずっと効率がいい。 F.Y.I: Building github branches with Jenkins ジョブの設定 「ビルドのパラメータ化」にチェックをつけて、以下のようにbranchって名前のパラメータを設定しておく。 「ソースコード管理システム」で「Branches to build」のところに、設定したパラメータである"$branch"を入れておく。 ジョブの設定は以上。上記の方
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
