Xamarin バッドノウハウ大全
2016/9/10(土) の「わんくま 横浜勉強会 #08」で @chomado さんと発表したセッションです。 解説エントリーも併せてご覧ください http://ytabuchi.hatenablog.com/entry/2016/09/12/003000 Xamarin.Forms が大変なのは View の調整です。すぐに動くものが必要なプロトタイプやモック、View 要件を調整できる自社アプリやクライアントさんとちゃんと話せて要件を調整できる受託案件などであれば、Xamarin.Forms の利点を最大限生かした効率のよい開発ができます。 私個人としては、地雷を踏む可能性が高くても Xamarin.Forms が大好きなのでこれからも愛を込めてガンガン推していきたいと思います。（Xamarin が Xamarin.Forms を推しているので、どんどん使いやすくなっていくはずという
[雑記] 動的コード生成のパフォーマンス(C# によるプログラミング入門)
概要 .NET Framework のバージョンが上がるたびに色々と追加され、 今や、動的コード生成にもさまざまなやり方が。 ということで、並べて比較してみたいと思います。 「動的 ＝ リフレクション ＝ むちゃくちゃ遅い」というイメージをもたれる方も多いと思いますが、 実際のところ、1度生成したコードをキャッシュしておくなどの工夫をすれば、意外と許容範囲なパフォーマンスが得られます。 （GUI の描画部分やネットワーク通信部分の遅延と比べれば、演算部分の数倍程度の差は取るに足らない場合が多く、 過剰に気にする必要はありません（もちろん、状況次第）。） 比較コード含めたソースコード一式： DynamicPerformance.zip ポイント 毎回リフレクションを呼び出すのはやっぱりかなり（2～3桁）遅い。 キャッシュ機構を使えば、静的なコードの数倍程度までは速くできる。 C# 4.0 の
![[雑記] 動的コード生成のパフォーマンス(C# によるプログラミング入門)](https://cdn-ak-scissors.b.st-hatena.com/image/square/4d1b2b57fc676d21e7f59f354364abeac0ea062e/height=288;version=1;width=512/https%3A%2F%2Fufcpp.net%2Fimages%2Flogo_4.jpg)
C#で高精度なテキストファイル文字コード自動判別（2014年版） - hnx8のブログ
C#（.NET Framework）に限ったことではありませんが、汎用的にテキストファイルを扱うようなアプリケーションを作っていると、よく 特定の文字コードのファイルしか読み出せないのでは困る ⇒文字コードを自動判別し、テキストの内容を取り出したい 読み出したファイルと同じ文字コードでファイルを書き出したい ⇒読み出したファイルの文字コードを知りたい といった場面に出くわします。 ですが、C#（.NET Framework）標準のライブラリではそのような機能は提供されていないため、文字コードを判定するには、 自前で文字コード判定のロジックを実装する 出来合いの外部ライブラリ、Windows版NKF32.dll、ICU4Cなどを利用する IE用の文字コード判別ライブラリ（mlang.dll）を利用する ※COMコンポーネント呼び出し要 のいずれかの方法を取ることになります。 HNXgrepと
Friendlyでお手軽ランタイムIL介入 - 亀岡的プログラマ日記
本記事は、Friendly Advent Calendar 21日目の記事です。 Friendlyの数ある機能の中でも、僕が衝撃だったのはあまりにも簡単にDllインジェクションが可能で、しかもそれをプロダクトプロセス内でキックできるのも容易だ、というところです。 これは、なんというか、衝撃です。 そして、やはり思ってしまう。 これ、テストだけに使うの、勿体無くね？？ Friendlyでお手軽簡単IL介入 てなわけで、やっぱりここまでできるのならIL介入したいですよね？やりますよね？ とはいえ、欄ライムのメソッドで事はもうJITコンパイル後、静的なDLLを事前書き換えするのとは結構次元が違います。 とはいえ！やはり先人はいるものなのです。 .NET CLR Injection: Modify IL Code during Run-time - CodeProject *1 詳しくはリンク先を
C# 2.0で、InternalsVisibleTo属性を用いてアセンブリ内でのみ使用される機能を単体テストする方法 【▲→川俣晶の縁側→ソフトウェア→技術雑記】
これは、即座に存在に気付いてリアクションすべきだった機能です。他のどのような機能強化よりも、私にとっては重要です。 いろいろ時間を取られて目が行き届いていないのがバレバレ (汗。 問題・単体テストとinternal § プログラムの複雑度を低減するという観点から言えば、あらゆる箇所から参照できる"public"の利用は、全く好ましいことではありません。 これは、インテリセンスで表示される候補が不必要に増えるという意味でも生産性を低下させる要因となります。 C#において、これを解決するための手段は十分にあるとは言えません。 強いて言えば、"public"ではなく、"internal"が解決策となります。これを使うことで、特定アセンブリ内からのみアクセスを許可することを明示できます。 ところが、"internal"は、単体テスト(テスト駆動開発)との併用で決定的な問題を引きおこします。テストメ
2013-11-06
emacs に F# モードがあったのでメモ。 M-x package-install fsharp-mode init.el に以下を追加。 README は ココ にある。 %SystemRoo%\Microsoft.NET\Framework\v4.0.30319 は使用している .NET Framework の msbuild.exe の場所に変更すること。 ;; README では inferior-fsharp-program, fsharp-compiler を setq するよ ;; うにガイドされているが、そのように設定しても動作しない. PATH を通す ;; と、fsi, fsc, msbuild を自動認識する. ;; https://github.com/fsharp/fsharpbinding/issues/136 (mapc (lambda (path) (a
Groovyから.NETのアセンブリを呼び出したりしてみた - 亀岡的プログラマ日記
某勉強会で発表できなかったので、現状報告 & メモがてらに。 動機とか まぁ、一言でいうと「Spock」使いたい！！なんですが。 もっと言うと、「表現力の高いテストライブラリが使いたい」、になるんですが。 C#だとSpecFlowという手もあるし、個人的には嫌いではないんですが、いかんせん二種類のファイルを使わないといけない辛みとか、そこらへんでガンガン進めるまでには至ってないな～、と。 んで、ふとJVMの世界を見ると、やっぱSpockが魅力的に見えるんですよねー。 というわけで、大きな目的は、SpockでC#のテストを書くなんですが、そこはまぁ一旦おいておいて、それの大前提となる、Groovy上から.NETのライブラリを使う、というのに対してのアプローチをご紹介。します。 Groovy上で.NETのライブラリを使う JVMから.NETのライブラリを使えるようにする 結局JVM上で.NET
Type Provider によるコンパイル時プログラミング - ぐるぐる～
ハワイにいる間、魔導書の書評以外にもちゃんとハワイらしいことしてきたという報告です(嘘 F# 3.0 で使えるようになる予定の Type Provider ですが、これをさっそく使ってみました。 今回のプログラムは Visual Studio 11 Developer Preview を使用していますので、実際に動かしてみたい人はインストールしてください。 Type Provider って？ まず、Type Provider って何なのよ、ということについてです。 Type Provider というのは、 コンパイル時に(プリプロセスとかではない・・・と思う) コード生成に頼らずに 型を生成する仕組み のことだと理解しています。 F# 3.0 Information Rich Programming(PDF) を見る限りの TypeProvider の一番の目的は、「コード生成によらない型
neue cc - C#の強み、或いは何故PHPから乗り換えるのか
特にPHPディスりたいわけでは、あるのかないのかはともかく、やっぱり実際に使ってきて良いところというのも分からなくもない感じです。会場でも話したのは、短期的な開発速度には有利なのは間違いないのかな、と。デプロイとかも、とりあえずポン置きでいいし、開発も、なんかもう複雑なことやると面倒だし、どうせ文字列だらけになるしで、開き直ってハードコーディングでバカバカ作っていくから速い、とか。ただし勿論あとで苦労するわけですがそれはそれとして。けれどやっぱC#良いよね、って。 言語も色々なトレードオフで成り立つわけですが、その中でもC#は、バランス良くて好きだなーというのが私の個人的なところです。Visual Studio良いよねー、でもいいですしLINQ良いよねー、もいいですし、IntelliSenseがないと生きていけないですし。うん、そう、IntelliSense指向言語が好きなわけです。 ほと
Modern C# Programming 現代的なC#の書き方、ライブラリの選び方
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。
About - Nemerle programming language official site
Nemerle is a general-purpose, multi-paradigm programming language for the .Net platform. It is as easy to learn and use as C# or VB.NET but Nemerle is by far more powerful. One may start using it as an advanced C# and then, as learning goes on, employ a range of cool features enabling metaprogramming and functional programming. The metaprogramming is based on macros bearing some similarity to Lisp
.NETでのカバレッジ計測ツールOpenCover - Yasuo's Notebook
2011年のうちに記事を書こうと思います。 C#で開発する際のカバレッジ測定ツールとしては、NCoverやPartCoverが有名ですが、今回はOpenCoverというツールを紹介します。 OpenCoverは、@scubamukiさんが開発しているカバレッジツールで以下から入手可能です。 https://github.com/sawilde/opencover インストールは、セットアップを実行するだけです。 OpenCoverの他にレポート生成ツールも導入しておきましょう。 以下から入手可能です。 http://www.palmmedia.de/Net/ReportGenerator ダウンロードしたファイルを適当な場所に解凍しましょう。 日本語の紹介はまだないようなので、ここで紹介しておきます。 サンプル：OpenCoverSample.dll ファイル：Class1.cs name
C# REPL | Mono
C# GUI Shell This documents the features available in the C# interactive shell that is part of Mono’s C# compiler. An interactive shell is usually referred to as a read eval print loop or repl. The C# interactive shell is built on top of the Mono.CSharp library, a library that provides a C# compiler service that can be used to evaluate expressions and statements on the flight as well as creating t
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Photo Tourism: Microsoft Research, Interactive Visual Media Group
Async in C# and F#: Asynchronous gotchas in C# (Japanese translation)
CodeProject