.NETの標準ライブラリと仲良くする話 - ぐるぐる～
F# Advent Calendar 2013の9日目の記事です。 昨日の記事は、id:nenono さんの「F# でリフレクション/式木に触れてみる」でした。 リフレクション、扱いにくいですよねぇ・・・ リフレクションといえば、LangExtシリーズの一つとしてReflectionExtなんてのを作っているんですが、 時間がないうえにいろいろ問題もあって滞ってます・・・ さて、今回は.NETの標準ライブラリと仲良くする話(もしくはBasis.Coreの紹介)です。 はじめに F#は.NET Frameworkの資産が使えるため、標準状態で色々なことができます。 これはF#の利点の一つですが、.NET Frameworkは関数型言語のために作られたわけではありません。 そのため、F#から.NET Frameworkの標準ライブラリを使うと、F#の標準ライブラリとは違った使い心地を体験するこ
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
Git と GitHub を体験しながら身につける勉強会行ってきた - 予定は未定Blog版
9/18（土） 15：30～ GitとGitHubを体験しながら身につける勉強会（名古屋） : 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 に限らず、同じ名前のサブコマンドでも意味が異なるものがいくつかあります。 その中
プログラミングの魔導書 Vol.1 発売前レビュー - ぐるぐる～
人生初献本・・・と書くとこっちが送ったみたいですね。そうではなく、もらったほうです。ありがとうございます。 と、いうことで、プログラミングの魔導書 〜Programmers' Grimoire〜ですが、Vol.1 は C++ オンリーの構成です。なんとすっぽすっぽ先生のインタビューも載っています。 なので、当然メインの対象読者は C++er になるわけですけど・・・これは面白い！ C++ がよほど嫌いじゃない限り、これはほかの言語のユーザにも是非読んでほしい本です。 この本には、C++ 使いが何を考え、どういう思考 (試行) を経て問題を解決するのか、といったことが詰まっています。 これは、ほかの言語を使っている人にとってもとても参考になるはずです。複数の言語が使えるような人は、是非読んでほしいですね。 まぁ、「なんで俺の使ってる言語にはこういう機能がないんだ！」などと思ってしまうかもしれ
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる～
C# のコーディング規約としては、オブジェクト倶楽部のもの (PDF) が有名だけど・・・正直、これ使いたくない。 冒頭に「このドキュメントは Java コーディング標準(オブジェクト倶楽部バージョン)、VB.NET コーディング標準を C#用に変更したもの」なんて堂々と書いてる時点で・・・ で、この規約のどこが駄目なのか、なぜ駄目なのか、どうすればいいのかをまとめてみた。 なんだかんだで長文エントリ。 追記： ちなみに、C# の規約としてはクラス ライブラリ開発者向けのデザイン ガイドラインで十分だと思う。 更に追記： ブコメで教えてもらったんだけど、どうやらクラス ライブラリ開発のデザイン ガイドラインの方が新しいらしい。 2. ファイル構成 (1) ファイル名 public クラスはそのクラス名の 1 ファイルにする。 例：public class Customer は、Custom
流れるようなインターフェイス - ぐるぐる～
なんか単に this を返せばいいって思っている人も多いようけど、ただ this を返せばそれが使いやすいかって言われると、正直微妙。 例えば、 public static class StringUtil { public static SubstrInfo Substr(this string str) { return new SubstrInfo(str); } public sealed class SubstrInfo { public SubstrInfo From(int from) { ... return this; } public SubstrInfo To(int to) { ... return this; } public SubstrInfo Length(int length) { ... return this; } } } なんてクラスは、 "hoge
バイブルというか、良書および必読の書 - ぐるぐる～
寝ようと思っていたら、その言語で「バイブル」と呼ばれる書籍を教えてくださいなんて質問を見つけてしまい、書いてたら長くなる長くなる・・・ 言語バイブル - Strategic Choiceが元らしく、いくつかかぶってるけど気にしない方向で。 Java Java言語仕様 第3版 (The Java Series) 何かと便利 Java仮想マシン仕様 (The Java series) 同上 Effective Java 第2版 (The Java Series) Effective なのに Java やるなら必読 Java Puzzlers 罠、落とし穴、コーナーケース Java の落とし穴にはまりたくなければ読むべき Javaプログラミングの処方箋 (Programmer’s foundations) 今となっては内容がちょっと古いけど、十分通用する。Effective の次に読むような本
カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる～
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
