F# - 七誌の開発Wiki
七誌の開発Wiki プログラミングについてのWiki。 トップページページ一覧メンバー編集 F# 最終更新： n7shi 2010年12月25日(土) 23:24:59履歴 Tweet このテキストはpublic domainです。出典を明記せずに転載していただいても構いません。編集は自由に行っていただいても結構ですが、このことに同意した上でお願いいたします。 C#経験者が手っ取り早くF#を使おうとすると、クラス定義の文法がかなり違うことに戸惑うと思います。そこでクラス定義を中心にC#からF#への変換方法をまとめました。なお、F#からC#への変換は逆コンパイラを使えば可能です。 可能な限り出典としてMSDNのリファレンスを示しました。詳細はそちらを参照してください。 出典: Keyword Reference (F#) F#の例はすべてlight書式（Pythonのようにインデントでブロッ
MVCは死んだ。MOVEするときがきた - きしだのHatena
Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ？ 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
NUnitでBDD - スペックリスト (^_^) - NAgilerの日記
BDDとは、コードを書く前にビヘイビアを明示することだ。つまりそれは、「コードが正しく機能しているかを先に確かめる」のではなくて、「コードがどの様に正しいのかを先に定義する」ということだ。 では、いつビヘイビアを明示すればよいのか。それはコードを書く直前がベストのタイミングだ。なぜならゴールに到着するのに十分な情報を手にしているのはコードを書く直前であるはずだからだ。 このあたりについては、A NEW LOOK AT TEST-DRIVEN DEVELOPMENTを参考されたい。 そこで、テストを書く直前にビヘイビアをマインドマップで明示する方法をお勧めする。このマインドマップをスペックリストと命名した。スペックリストでは、まず中心に[ストーリー]を置き、そこから伸びるBOIとして[コンテキスト]を分岐させていく。さらに各BOIに[スペック(仕様)]を記述して枝を伸ばしていく。マインドマッ
年末だからこそ ASP.NET MVC のモデルの作り方について考えてみる - しばやん雑記
Project Silk とか EFMVC とか Maintainable MVC Series を読んでると、どれもモデルが非常に厚いんですよね。 よくサンプルコードであるような EF の DB Model を直接 View に流し込むような作り方は使われていないわけですよ。 そして、今朝 MVVM Framework の Livet 作者で MVVM パターンのプロフェッショナルである尾上さんが ASP.NET MVC を学んでいるとの情報が入ってきました。 やるぞ http://t.co/6BVBUCSh MVC！— 尾上 雅則 (@ugaya40) 2011, 12月 29 自分としてもモデルの作り方で悩んでた部分があるので、これを機にちょっとまとめてみようかと思いました。年末に昼まで寝てゲーム三昧とか人間としてダメすぎるので。 とりあえず ASP.NET MVC の M,V,C
PAC(Presentation Abstract Controller) - とあるプログラマの日記
先日、MVCモデルについて調べていたらPACというのがでてきた。 PACってなに？初めて聞いた。と思って調べてみるといろいろでてきた。 わかりやすかったのがこの2つ↓ 浜村拓夫の世界 http://hamamuratakuo.blog61.fc2.com/blog-entry-432.html ジャズと育児とオブジェクト http://blog.goo.ne.jp/meiamipapa/e/2eea546b3cf9d5e524d9ae9c7850179f 要するに 『PAC は MVC の階層的アーキテクチャとみることができます。』 『ある程度複雑・大規模なシステムに適用するアーキテクチャとしてはPACの方が向いていると思われる』 ということらしい。 『Drupal、Firefox、Eclipse でも採用されている』ということから、けっこうメジャーな方法なのかもしれない。 自社フレームワ
Unit of Work パターンと永続性の無視
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 実践的なパターン Unit of Work パターンと永続性の無視 Jeremy Miller 目次 Unit of Work パターン Unit of Work を使用する 永続性の無視 (Persistence Ignorance) データベースとは無関係にビジネス ロジックを実行できるか データベース モデルとは無関係にドメイン モデルを設計できるか ビジネス ロジックに対する永続化戦略の影響 Unit of Work に関するその他の考慮事項 2009 年 4 月号の MSDN マガジン (「永続化のパターン」) では、ある種のオブジェクト/リレーショナル マッピング (O/RM) テクノロジを使用し
InfoQ: ドメイン駆動設計・開発の実践
ドメイン・モデルと開発に注力しないと"太ったサービス・レイヤ"と"ドメイン・モデル貧血症"によるアプリケーション・アーキテクチャになってしまいます。この場合、ファサード・クラス(通常はステートレス・セッション・ビーン)にどんどんビジネス・ロジックが溜まっていき、ドメイン・オブジェクトがgetter/setterからなる単なるデータの運び屋のようになってしまいます。このアプローチをとるとドメイン固有のビジネス・ロジックやルールが複数の異なるファサード・クラスに散在(時には重複)することになります。 "ドメイン・モデル貧血症"はたいていの場合、コストに見合いません。他の企業と比較して利点があるわけではなく、このアーキテクチャの下でビジネス要求の変化を実装するには開発と本番環境へのデプロイするのに時間がかかり過ぎます。 DDD実装プロジェクトにおけるいろいろなアーキテクチャや設計について見ていく
ドメイン モデル パターンを使用する
In this article, we’ll go through the reasons to (and not to) employ the domain model pattern, the benefits it brings, as well as provide some practical tips on keeping the overall solution as simple as possible. Contents What Is It? Reasons Not to Use the Domain Model Technology Reasons to Use the Domain Model Scenarios for Not Using the Domain Model Scenarios for Using the Domain Model More Comp
『リファクタリング: Rubyエディション』を読んで思い出したこと
2000年(日本語版)の『リファクタリング―プログラムの体質改善テクニック (Object Technology Series)』から10年後の2010年(日本語版)に出た Ruby エディションを読んだ。 月末の kanazawa.js v1.7 - Back to Basics - : ATND の JSTDD Intro の準備の過程で、本当に言いたいことってなんだろう？とずっと振り返りをしていた。せっかくなので気になってた本を読んでみた。そしてようやく思い出した。自分のやりたかったことはリファクタリングだったのだと。 年代的にも日本語版で言うと 2000年 リファクタリング2003年 テスト駆動開発入門であり、Red/Green/Refactoring のサイクルはこのリファクタリングの中に出てくる。1 コードの振る舞いを変えずに中をクリーンアップする。重複を削り、責務を明らかにす
かっこ悪くて面倒でもテストコードを書こう - 今川館
Python | 10:08わたしはプログラマーではありませんが、いくつかの仕事でテストコードを見たり書いたりすることがあったので、その過程で思ったことをメモとして残しておきます。コーディングとテストを分けて工数を言う癖をやめようどっちもコードを書くのだから分けて考える必要はないテストコードの重要性は理解しているけど、工数も厳しいし客がテストコードを書くことに工数を割くことを認めてくれない。ありがちな話ですが、それがテストを書かないことの根拠であるならば少し考え直しましょう。コーディングとテストを異なる工程と考えるのをやめてしまえばそんなことに悩む必要はなくなります。つまり、「テストを書きながらコーディングする」のです。だいたい、普段プログラムを書いているときだって手元で動かしながらものを作っているでしょう。それと同じことをプログラムを書いてやればいいだけです。客がテストを書かせてくれない
書評（数理論理学）
教科書など 準備 数理論理学を習得するためには、その前に、数学の言葉を操り数学の考え方を駆使できるようになる必要があります。数理論理学は数学の一分野ですので、それについては数学の他の分野と変わることはありません。 幸い、数学の言葉と数学の考え方を学ぶことに特化して使える教科書が出版されています。目についたものを並べてみます。おそらく、他にもあるでしょう。 個人的に特に気にいっているもの 嘉田勝：論理と集合から始める数学の基礎，日本評論社, 2008. (版元による紹介) 鈴木登志雄：例題で学ぶ集合と論理, 森北出版, 2016. (版元による紹介) その他 渡辺治・北野晃朗・木村泰紀・谷口雅治：数学の言葉と論理, 朝倉書店, 2008. (版元による紹介) 中島匠一：集合・写像・論理—数学の基本を学ぶ—, 共立出版, 2012. (版元による紹介) 石川剛郎：論理・集合・数学語, 共立出版
xUnit Test PatternsのTest Doubleパターン(Mock、Stub、Fake、Dummy等の定義) - 千里霧中
最近、昔作ったTest Doubleの解説資料を参照・引用してくれる方がちらほら出ていて恐縮しているのですが、見直してみると結構わかりにくい資料なので今回文章としてまとめたいと思います。内容は世間一般的に言われているMock、Stub、Fake、Dummyといった言葉の定義になります。 Test Doubleとは Test Doubleとは、テスト実行時に、テスト対象が依存しているコンポーネントと置き換わるものです。「テスト代役」と訳されることもあります。世の中でMock、Stub、Fake、Dummyなどと呼ばれているものの総称に位置づけられます。 簡単な例を以下に示します。このコードでは、テストメソッド「テストコード()」がメソッド「テスト対象()」をテストしています。また「テスト対象()」は、中でメソッド「外部メソッド()」を実行しています。なお「外部メソッド」はテスト対象でないとし
codeなにがし::プログラマにおくる英語の冠詞の使い分けの法則 Wiki版
日本人が英語の文章を書くときに困ることの一つに、冠詞の使い分けがあります。 どういう時に冠詞を付ける／付けないかがイマイチわかりづらく、結局、何となく雰囲気でつけたりつけなかったりしてしまっているのではないでしょうか。 実は冠詞の使い分けに関しては、プログラムを書く人間であれば即座に理解できる法則があります。もちろん英語は人間が使う言葉の一つのため多少の例外はありますが、ほとんどの場合通用します。少なくともここ一年のネイティブチェックで誤用を指摘されたことはありません。 その法則とは、「冠詞と名詞は classとインスタンス」と考えるということです。下記で順番に見ていきましょう。 a/an を付ける場合 - インスタンスを生成 I have a book. この文では book クラスのインスタンスを生成し、そのインスタンス自体のことを指しています。メモリやヒープが確保されているため、当然
TDDを学ぶべき10の理由 #TddAdventJp - やさしいデスマーチ
かなり香ばしいタイトルですが、TDD Advent Calendar jp: 2011のエントリーとなります。前日の@bleisさんのエントリーの次になります。 はじめに TDD（テスト駆動開発）とは、「テストファーストを原則とし、テストが成功するようにプロダクションコードを書くというサイクルを繰り返す開発手法」です。XPのプラクティスの１つとして10年近く前に紹介され、ここ数年で再び１つのムーブメントとなっています。これは、TDD Boot CampがTDDへの敷居を下げ、体験する機会を提供した事も１つの大きな要因でしょう。 自分もTDDに魅せられたエンジニアの１人です。ぶっちゃけ、TDD信者とかTDD厨とか言われても可笑しくはありませんし、むしろ嬉しいくらいです。一方で、TDDを嫌う人もいるのも事実です。しかし、自分もTDDを銀の弾丸とは思っていませんし、適用しにくい領域もある事も理解
高速な安定ソートアルゴリズム "TimSort" の解説 - Preferred Networks Research & Development
先日、TimSortというソートアルゴリズムが話題になりました。TimSortは、高速な安定ソートで、Python(>=2.3)やJava SE 7、およびAndroidでの標準ソートアルゴリズムとして採用されているそうです。 C++のstd::sort()よりも高速であるというベンチマーク結果1が話題になり(後にベンチマークの誤りと判明)、私もそれで存在を知りました。実際のところ、ランダムなデータに対してはクイックソート(IntroSort)ほど速くないようですが、ソートというシンプルなタスクのアルゴリズムが今もなお改良され続けていて、なおかつ人々の関心を引くというのは興味深いものです。 しかしながら、オリジナルのTimSortのコードは若干複雑で、実際のところどういうアルゴリズムなのかわかりづらいところがあると思います。そこで今回はTimSortのアルゴリズムをできるだけわかりやすく解
三項演算子の正しい書き方
C・C++・Java・Perl などのプログラミング言語では、条件演算子として三項演算子?:が用意されている。条件演算子の書き方として、以下のような説明がされることが多い。 condition ? true-expression : false-expression この説明は、以下のプログラムと同じ程度、間違っている。 #include <stdio.h> main( ){printf ("hel" "lo, world\n" );} 条件演算子は、正しくは以下のように書く。 condition ? true-expression : false-expression 使い方の例を示す。 compare = obj1 == null ? obj2 == null ? 0 : -1 : obj2 == null ? 1 : obj1.toString().compareTo(obj2.to
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Templates and Images - Watch “ppt157: Everything in this video is a PowerPoint Template”
APIに著作権はあるか?
カスタムプロバイダーを作ってみよう その１
言語擬人化