並列/並行基礎勉強会でasync/awaitをDisってきた - ぐるぐる～
async/await不要論 from bleis tift 3/23 に開催された、並列/並行基礎勉強会で「async/await 不要論」という発表をしてきました。 一番言いたかったこと 一番言いたかったことは、実は並列とかとは全く関係ないことです。 それは、言語への機能追加に関することです。 C# は 5.0 で非同期処理のための専用の構文として、async/await を導入しました。 これは、F# が計算一般という抽象度の高いものための汎用的な構文として、コンピュテーション式を採用しているのとは対照的です。 専用の構文を用意するかしないかは、その言語を取り巻く環境次第です。 専用の構文の利点と欠点 専用の構文の利点は、その使用用途が明確であるというところにあります。 そのため、書き方さえ覚えてしまえば、その裏で何がどうなるかなどを一切気にせずに使えてしまえたりします。 欠点は、専
Maybe のエントリの補足 - ぐるぐる～
昨日書いた Java の語彙で Maybe を説明してみる - ぐるぐる〜 に予想以上の反響があってびっくりです。 色々反応もらったので、ちょっと補足を。上のエントリを読んでない人は読んでからどうぞ。 @CheckForNull でいいのでは？ はい、確かに FindBugs の CheckForNull アノテーションは便利です。 でも、これが提供してくれるのは null チェックの強制です。 先のエントリは、「null より安全な Maybe」という説明でした。 ですので、それだけを達成するのであれば CheckForNull アノテーションでもいい*1のですが、後半でちょっと見たように「null より便利な Maybe」という側面もあります。 先のエントリでは bind と or だけ追加しましたが、他にも色々と追加してみましょう。 // Java8だよ！ package maybe
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
JSX の型を整理してみた - ぐるぐる～
JSX の型はかなり複雑なことになっている気がしたので、整理してみました。 プリミティブ型、オブジェクト型、可変型、未定義許可型 JSX における型は、この 4 種類に分類されるらしいです。 プリミティブ型 プリミティブ型は現在、 boolean int number string の 4 種類があります*1。 これらの型を持つ変数には null を入れることができません。 var x: int = null; // compile error! また、これらの型の値は変更不可能 (イミュータブル) となります。 3 がいつの間にか 4 に変わっていたりしてほしくないですよね？ "hoge" という文字列の o という文字がいつの間にか a に変わっていて "hage" とか悲しいですよね？ これらの型の値では、そのようなことは起こりません。 オブジェクト型 オブジェクト型は例えば、 st
SCM Boot Camp in Nagoya に行ってきた・・・と見せかけた SML# の多相レコードの話 - ぐるぐる～
SCM Boot Camp については他の型方が書いてくれると思うので、違う話を書きます。 SCM Boot Camp 開始前の雑談や懇親会で話題になった SML# ですが、幸か不幸か .NET 系の言語と勘違いされがちです。 でも SML# の # は、多相レコードを扱う際に出てくる # が元になっています。 ちなみに、.NET Framework は 2000 年リリース、SML# の前身である (でいいのかな？) SML# of Kansai が 1993 年開発と言うことで、なんと .NET よりも歴史があるのです。 で、懇親会で SML# すごいよ、って話をしたら「多相レコード？何それ美味しいの？」って人がほとんどだったので、(ぶっちゃけ自分もそんな理解してないですけど) SML# の多相レコードを紹介してみようかな、と思い、このエントリを書いています。 環境は Windows
Agile Japan 2012 行ってきた - ぐるぐる～
有給取って行ってきました。 午前 午前のセッションで一番心に残ったのは、「全体最適のマネジメント改革」〜変えるのは現場ではない、マネジメントである〜でした。 全体最適に関しては、ERP 大嫌い人間なので毛嫌いしてたんですが、この人の「全体最適」は ERP などが実現しようとしている「全体最適」とは考え方が違っていて、興味深かったです。 このセッションの中で、複数の作業を並行して行うよりも一個一個片付けた方が効率がいいことを示す実験をしました。 内容としては、 1〜20 までを順番に縦に書く作業 a〜t までを順番に縦に書く作業 △、○、◇ を繰り返して 20 個縦に書く作業 を、最初は「1 を書いたら次に a を横に書き、それが終わったら△を書き、それが終わったら 1 の下に 2 を・・・」というように 3 つの作業を並行してどれだけかかるかを計りました。 次に、1〜20 まで書く作業を終
TestCase 属性などによるテストコードのリファクタリング - ぐるぐる～
昨日のわんくまの昼休みに TDD 道場があったんですが、テストコードのリファクタリングについて賛否あったのでちょっと自分の考えをまとめておきます。 それに加え、C# と NUnit でどのようにテストコードをリファクタリングできるか、というのも紹介します。 というかこちらがメイン。 テストを追加した際に追加したテストだけを実行するか全部実行するかというのも意見が分かれたんですが、主に個別に指定するのが面倒という理由で全部実行する派です。 全部実行すると時間がかかる？それはもはや単体テストじゃないですね。重いテストは分割して分離しちゃいましょう。 これに関してはレガシーコード改善ガイド (Object Oriented SELECTION)をどうぞ。機会があればここら辺についても書きたいところです。 テストコードのリファクタリングについて まず、テストコードのリファクタリングはありだと思いま
再帰で考える - ぐるぐる～
再帰は関数型言語を構成する重要な部品の一つです*1。 しかし、手続型言語に慣れたプログラマにとって、再帰で考えるというのは難しいものがあります。 このエントリは、そういうプログラマが再帰で考えることができるようになるために書きました。 言語としては、F# と C# を使っています (推奨は F#。C# の例は実用性が無いに等しい) が、Java プログラマでもある程度読めるでしょう。 前提条件として、これらの言語の文法は知っているものとします。 特に、C# で言う Func デリゲートを多用します。 すごい長いので、時間があるときに一気にどうぞ。 再帰以外の話もちょろちょろと出てきます。 再帰の重要性 いきなりですが、再帰はあくまで最後の手段です。 普通は再帰をカプセル化した関数を使うことになります。 通常使わないのであれば、再帰を学ぶことに意味はないのでしょうか？ いいえ、それでも再帰を
コンフリクトが発生しなくても壊れる場合 - ぐるぐる～
push したら誰かが先に push していたので失敗した。 なので pull したが、コンフリクト (競合) は発生しなかったので何も確認せずにそのまま push した。 何も問題なさそうですね。 ・・・本当ですか？ 例えばこんな状況を考えてみましょう。 最初の状態 A さんと B さんと C さんが登場します。 作っているのは Web ページで、コードはこんな感じ。 <html> <head> <title>hoge</title> <style> .menus { overflow: auto; } ul { margin: 0; padding: 0; list-style-type: none; } .button { float: left; width: 100px; margin: 0; padding: 10px 0; text-align: center; backgr
TDD の基礎体力と、TDD に対する想い - ぐるぐる～
TDD Advent Calendar 2011 の 4 日目の参加エントリです。 前半では、TDD を学ぶ前に身に付けておくといいと思う基礎体力について書きました。 後半は、まぁ、その。後悔はしていません。反論ウェルカム、議論しようぜ。 不安をテストに 「レッド - グリーン - リファクタリング」は、TDD の根っこの部分であり、これ自体が「どう TDD をやればいいか」を教えてくれるものではありません。 それに対して、「不安をテストに」というのは、「どう TDD をやればいいか」という指針を与えてくれる言葉です。 この言葉自体は、TDD Boot Camp で自分のものにできました。 不安については、テスト駆動開発入門では (言及されているものの) 自然に組み込まれていて、最初に読んだときには全然気づきませんでした。 しかし、TDDBC で id:t-wada (和田さん) に短くて
Git 基礎最速マスター - ぐるぐる～
id:repeatedly から無言の圧力を受けたので書きました。 タイトルは釣り。そもそも自分が Git マスターしてないし。突っ込み歓迎。超歓迎。 一応、このエントリだけで一つの Git リポジトリをそれなりに操れるようになることを目指してます。なので、コマンド一つ一つに対する説明じゃなくて、やりたいこと一つ一つに対する説明が中心です。え？それ最速マスターじゃない？きーこーえーなーいー。 あと、他のバージョン管理システム、例えば Subversion や Mercurial が使えることを前提としています。誰か「バージョン管理システム基礎最速マスター」とか書かないの？ インストール Windows と Debian しか分かりませんので、自分のシステムに読み替えて行ってください。あと誰か Mac ください。 インストールも設定も終ってるよ！って方はリポジトリの作成までひとっ飛び。 Wi
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
