matarillo.com: UIパターン
UIパターン 追記 この記事の一部を加筆・修正したものを「開発者が知っておくべき、6つのUIアーキテクチャ・パターン」として@ITに転載しています。 MVVMを追加した上で、アプリケーションモデルとMVVMをプレゼンテーションモデルのバリエーションとして位置づけました。 MVPの2つのスタイルとして、監視コントローラとパッシブ・ビューを説明しました。 まえがき Martin Fowlerの"GUI Architectures"を訳したので公開しようと思ったのだが、FAQページに「EAA developmentとかDSLなんかは商業出版するんで例外ってことで」と書いてある。面倒だったので翻訳の公開はやめて、「自分の理解を書く」というスタイルにしようと思う。 Fowler氏が説明しているのは 「フォームとコントロール」、「モデルビューコントローラー (MVC)」、「プレゼンテーションモデル」、
Windows Vista時代の防衛的なWindows Formsプログラミング - Kazzz's diary
大げさな標題になってしまった。ようは今まで、そしてこれからも暫くは作り続けていくであろうWindows Formsアプリケーションを、今後Windows Vistaが普及して行く中でどうしていこうかということだ。 Windows Vista以降のGUIプログラミングの主流はWPF(Windows Presentation Framework)と呼ばれる技術、具体的にはXAMLと呼ばれるマークアップで記述されたGUIと.NETプログラミング言語で書かれたコードビハインドの組み合わせがメインストリームであり、古のWindows FormsはGDI(GDI+)とともに衰退していく運命なのは既定路線だ。(個人的には現在のWPFには未だ懐疑的だ -> Beyond WindowsForms?) このような端境の中でWindowsForms等のGDIアーキテクチャを用いたGUIアプリケーションはどのよ
Foundations: Writing More Efficient ItemsControls
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 基礎 効率的な ItemsControl の作成 Charles Petzold コードは MSDN コード ギャラリーからダウンロードできます。 オンラインでのコードの参照 目次 ItemsControl による散布図 期待外れのパフォーマンス 隠れたループ 値コンバータの使用 Freezable オブジェクトに注意 中継手段としてのプレゼンタ カスタム データ要素 限界 DrawingVisual ソリューション すべての Windows Presentation Foundation (WPF) プログラマには、遅かれ早かれ DataTemplate のすばらしさに気付かされる時がきます。それは、"えっ
WPF: 描画の限界?? データの多い折れ線グラフ
WPF上で折れ線グラフを描画する場合、普通に考えるとPolylineを使うと思います。PointCollectionのインスタンスを渡すだけで、連続直線を描画してくれますので、折れ線グラフを描くにはもってこいです。 今作っているツールが折れ線グラフを描画するものなのですが、こいつがちょっと要求事項が難しく、サンプリング数3600点 x グラフ線20本というアホツールです。最近の高精細なディスプレイでも横ドット数が3600何てありませんから、サンプリング数3600点と言っている時点でちょっと無理があります。また「同時にグラフ20本も見ることはないよ」と思うかもしれませんが、まーこれがツールの諸元なので、大目に見てください。 問題は、この諸元でツールを作ると、全く使い物にならないくらい遅いということです。最初はグラフが変化したらアニメーションさせよう、なんて考えていましたが、論外です。表示する
デスクトップの暗黒面 - NyaRuRuが地球にいたころ
実際に過去の GDI プログラミングをされたことがある方が，Windows XP と WDDM 環境の Windows Vista で実験すれば，Device Dependent Bitmap，通称 DDB の振る舞いが以前と全然違ってしまっていることに気付くだろう． 要点だけを言えば，DDB のパフォーマンス特性が DIB (Device Independent Bitmap) にそっくりになったということだ． 以下何の役にも立たない暗黒雑学 （注：これを読んでも「Vista の 2D 描画は速くなりません」．が，少しだけ世界の絡繰りが分かるかも知れません．基本的には昔の事情をあまりよく知らない開発者向けに書いています．って私も昔のことは全然知らないのですけど．まあ分かる範囲で書いてみました） DDB は，ドライバ依存の正体不明なビットマップ，というのが定義だが，ぶっちゃけて言えば VR
C# で使えるグラフやチャート系ライブラリのまとめ - アジャイルプログラマの日常
概要 C# (.NET) で利用可能なグラフやチャート系ライブラリのまとめです。日本語の情報が少ないので、リストだけ作ってみました。オープンソースをメインに集めていますが、有料・無料などライセンス体系は様々です。 各ライブラリの詳細は、リンク先でスクリーンショットを見たり、サンプルを動かしたりしてください。情報視覚化系ライブラリのサンプルは、見ているだけで楽しいのが多いですね。 Have a fun!! :-) グラフ (ダイアグラム) 系ライブラリ (おすすめ順) Diagramming packages (有料が多いが高機能、各種プログラミング用情報もあり) Graph2 (an enterprise level WPF diagramming framework.) Graphite (a diagramming control with spring embedder layout
Articles by sukram (Articles: 4) - CodeProject
24 Feb 2008 Updated: 29 Feb 2008 Rating: 4.96/5 Votes: 245 Popularity: 11.78
あなたのアプリにはどのインストーラが最適？（1/3） - ＠IT
.NETのセールス・ポイントの1つは、開発したアプリケーション（以下、アプリ）が単にコピー（XCopy）しただけで動作するということだろう（もちろん事前に.NET Frameworkがインストールされている必要はあるが）。そういった点から「.NETでは、アプリ自体をインストールするセットアップ・プログラムは不要」と考えている読者諸氏も少なくないのではないだろうか。 具体的なインストーラの話に入る前に、まずは前半でこの真相について考察してみたい。後半ではインストーラの作成方法について説明し、人気のある3大インストーラの機能を比較する。なお本稿では、主にスタンドアロンのWindowsアプリで活用できるインストーラを想定している。 ■なぜインストーラが必要なのか？ 「ソフトウェアには必ず何らかの役割が与えられている」というのは、誰もがすんなりと理解できるだろう。もちろん、インストーラもソフトウェ
AVATAR製作時、その超巨大データはどのように大陸間転送されたか？ - Wataru's blog
3D映画として現在大ヒットを飛ばしているAVATAR。私の周りでも凄く話題になっていて、IMAXを持つ映画館に近いうちに見に行きたいと思っています。 本日は、AVATAR製作時に使われたITシステムの話を、ご紹介したいと思います。 34ラックという、驚きの超巨大システム AVATARのデータ総容量は、何と、3PB(ペタバイト)!もの大きさだったそうです。毎週、ときには日ごとに数TB(テラバイト)ものデータが出来る上に、それらを色々なフォーマットで保存しなければならないためだそうです。 これだけのデータを処理するために、ITシステムのラック総数は何と34本、そして各ラックには32台のサーバが搭載され、プロセッサ総数は40,000、メモリ合計は104TBに達したそうです。しかも、全てのサーバが10GbEで接続されていたとのこと。 とてつもなく巨大なシステムですね。ここまで来ると小規模なスパコン
アプリケーション・アーキテクチャ・ガイド2.0解説 - ＠IT
第2回 簡潔なコーディングのために （2017/7/26） ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている 第1回 Visual Studio Codeデバッグの基礎知識 （2017/7/21） Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう 第1回 明瞭なコーディングのために （2017/7/19） C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える Presentation Translator （2017/7/18） Presentation TranslatorはPowerPoint用のアドイン。プレゼンテー
)
.NET Framework のサポート概要
更新日: 2013 年 3 月 4 日 本ドキュメントでは .NET Framework のサポートについて全体像をご理解いただくために、概要の説明を行っています。最新の情報および詳細な情報に関しては次のサイトを参照してください。マイクロソフトのサポートライフサイクル ポリシーに関してはライフサイクル ポリシー FAQ、開発ツールのサポートライフサイクル ポリシーに関しては 開発ツール ライフサイクル FAQ をご参照ください。 注: このドキュメントは実行環境としての .NET Framework のサポートについて説明するものです。開発環境である Visual Studio のサポートとは異なりますのでご注意ください。 .NET Framework の サポート ライフサイクル .NET Framework 2.0 以前の各バージョン .NET Framework は最短で 5 年間の
Chapter11 フレンドアセンブリ（1/2） - ＠IT
同書籍は、もともと本フォーラムにて連載していた『C# 2.0入門』、『C# 3.0入門』の記事を整理統合し、加筆、修正されたものです。 手元でまとめて読みたい方は、ぜひ書店などにてお買い求めください。 【注意】本記事は、書籍の内容を改変することなく、そのまま転載したものです。このため用字用語の統一ルールなどは＠ITのそれとは一致しません。あらかじめご了承ください。 11.1 アセンブリ内部のメンバーへのアクセスを許す プログラミング言語の歴史をひもとくと、構造化プログラミングとオブジェクト指向プログラミングの中間に、「モジュール化プログラミング」という言葉が出てくることがある。たとえば、Modula-2が代表的なモジュール化プログラミング言語である。また、C言語はモジュール化プログラミングが可能な言語とされる。 また、説明によっては、オブジェクト指向プログラミングがモジュール化プログラミン
Microsoft Learn: Build skills that open doors in your career
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
スケールアウトからスケールアップへの回帰:Kenn's Clairvoyance
これを書こうと思ったキッカケは、奥一穂さんの「ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない」っていう、最近モヤモヤと感じていたことをうまく説明してくれてる記事をみたこと。 年始からちょくちょくサーバの運用環境を物色しながら考えていたことと見事にシンクロした。だいたいの要旨はTwitterのほうでも書いたのだけれど。 ムーアの法則でどんどん向上する技術にくらべ、人間のキャパシティは変化しない定数項として考えていい。だとすれば、そうやって向上する性能を、人間の労力を削減する方向で使えてはじめて、「技術が競争優位性を生む」といえるだけの破壊的な価値がでてくるということになる。 では、現在の技術トレンドを活用することで減らせる「人間の労力」とは何か。 それは、過去10年あまりで定着した、これまでの（そして今なお）Webアプリケーションの定番構成である、「ロードバランサ、ア
Twitterがスケールに苦しむ理由 - スケールするサイトのアーキテクチャ考
Twitterのスケール関係で、面白い記事を発見したのでまとめ。 一時期「スケールしない」とか「動作が不安定」だとか言われ続けていたTwitter。5月ごろにslashdot.jpでも話題になっていた。論調は総じて「Twitterがスケールしないのは、Rubyを使っているから」というもの。 ところが同じ５月、「Why Can't Twitter Scale? Blaine Cook Tries To Explain（なんでTwitterってスケールしないの？）」という、blog紹介記事がSilicon Alley Insiderに掲載される。記事の元になったblogエントリは、Twitterの前チーフアーキテクトだったBlaine Cook氏によるもの。Cook氏によれば、TwitterのスケールとRubyは何の関係もないという。 Why Can't Twitter Scale? Blai
大規模SNSのボトルネックとソリューション
SNSは比較的データアクセスが多いアプリケーションであり、負荷対策が難しい部類に入る。本稿では、グリーCTOの藤本真樹氏が、GREEというSNSでの経験を基に、SNSの具体的な負荷軽減ソリューションを紹介する。 はじめに 昨今では、地方自治体や企業内でもSNSを導入する動きが活発化しているようです。しかし、SNSは比較的データアクセスが多いアプリケーションであり、負荷対策が難しい部類に入ります。そこで本稿では、前回お届けした「大規模SNS実現のためのGREEのアプローチ」の内容からもう一歩踏み込んで、GREEというSNSでの経験を基に、SNSの具体的な負荷軽減ソリューションを紹介します。 SNSのボトルネック 一定以上のユーザー数、データ量、そして機能を持つSNSでは、普通に構築していくと非常に悩ましいボトルネックが2つ顕在化してきます。1つは、「友達の新着」系の情報取得です。もう1つはア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WPF destroys images when resizing them
Image file that is ~11MB size takes a lot of memory when rendered using WPF Image control
智利经济强劲复苏，今明两年增速将回落-新乡市伟良筛分机械有限公司
テスト駆動開発導入時のよくある質問
