今から始める、Windows 10＆新.NETへの移行戦略
変わらない 聞いてた方からの感想で「『変わらなくていい』なんですね(笑)」などというお言葉もいただきまして。 まあ、僕個人の意見は元々、「使いたくないやつが使う必要はない。」「LINQもvarも、使う・使わないとかで論争すること自体どうでもいい。」「でも、使いたいやつに使わせないような統制取るやつは滅びろ。」ですからね。もちろん、コードレビューなんかで「LINQ使うとこれだけシンプルになるよ」→「そっちの方がいいですね」ってような流れはあるけども、強制するものではないと思う(11ページで書いているように、privateな部分のコードはうるさく言ってもしょうがない。LINQやvarはそのprivateな部分の機能)。 選べる自由が大事。選ばせないやつは本気で滅びろ。 変えれない 開発者の声としてよく聞くのは「変えたいんですけどもなかなか大変で」ってやつです。みんなほんとは新しいもの使いたい。
C# Design Note
Roslynがオープンソースになって、仕様が固まる前のディスカッションとかも見えるようになったよというのの紹介と、正式な文法をどうするか悩んでる新機能があってどういうところで悩んでいるか2例ほど挙げて説明。
ソースコード共有と#if
いわゆるifdefコードの難しさ。 昨日、クロスプラットフォームな開発をしてる人から、「universal Windows apps の共有プロジェクトって、#if を正しく認識してるの？リネームとかのリファクタリング的な意味で」という疑問をいただいたので試してみた結果。 ダメでした。ええ、ダメでした(とりあえずConnectに登録済み)。 クロスプラットフォーム開発してて、どうしても#if/#elseするしかない場面ってごろごろあって、「動く」という意味では全然問題ないものの、こういうリファクタリングでいつも困るそうで。手元の環境で #if の対象になってない部分のコードで、どうしても修正ミスが残って、後から問題が発覚するという。
.NET Native
.NET Nativeとかいうものが公開された模様。.NET言語（さしあたってはC#のみがサポート対象）からNativeコードを直接作る仕組み。 公式ページ: Microsoft .NET Native MSDN Library 内のヘルプ: http://msdn.microsoft.com/en-us/library/dn584397.aspx 去年の暮ぐらいから噂にはなっていたもの。//build/ の初日キーノートでは出てこなかった（初日は OS 関連。WP8.1とかの話題）ので公開明日かと思ったらもう。 概要 以下のようなもの。 WP8が使ってるMDILに基いた技術 クライアントデバイスには完全にネイティブ化した状態で配布 クライアント上で余計な電力消費しないし、初回起動も早い 当面のターゲットはストアアプリのみ。ただし、ターゲットは今後広げていきたい 前にプロ生勉強会で話した通
100倍速くなる開発
資料はSkyDriveでも公開しています。 もう悪意しか感じない釣りタイトル。 まあ、今回はセッション概要の時点でネタバレ（釣りです宣言）してるので、自分の中では良心的。今回、そんなに余裕がなかったのでぬるいです（本気で釣りに走るのはそれなりに体力使う）。 100倍速くなりました（実話） 実話の中ではP●Pだったからといって、必ずしもP●Pが悪いわけではないのでご了承を（この点が「釣り」）。 言語を変えて変わる実行速度なんてせいぜい5倍程度で、残り20倍は設計からきっちりやり直したことにある、という、設計のお話。 ただ、だからって「C#でなくていい」ってわけでもなくて、きっちり設計するにはよい機能多いですよ、C#は。そういうクオリティのコードを他の言語でそう簡単に書ける気はしていません。 この釣りタイトルに対して「100倍速くなるのは開発速度という落ち？」みたいなこと言う人もいましたが、そ
Xamarin 2.0
Xamarin 2.0 のアナウンスがあったわけですが。 Xamarin 2.0 の内容 単に、メジャー バージョンアップに合わせて、ブランド名を統一したという内容。今まで、Mono Touch、Mono for Android だったものが、Xamarin.iOS、Xamarin.Android に。 メジャー バージョンアップによって、Visual Studio 使って Windows 上で iOS 開発できるようになったりも。新 IDE の Xamarin Sudio は世界で一番の Android UI ビルダーだという自信もあるそうで。 クロス プラットフォーム クロス プラットフォームというと割と夢見がちな意見と、それを警戒する意見にたどりつきがち。 Xamarin 2.0 のニュースを見て、知り合いから「こういうツールって使い物になるの？」とのご意見も求められてしまったので、
Keep Yourself Up To Date
先週土曜の業開中心会議で講演してきたわけですが。 イベントのページ: https://itmedia.smartseminar.jp/public/seminar/view/465 ustream 配信: http://www.ustream.tv/recorded/28809059 自分の発表資料: Keep Yourself Up To Date 同上、プロット段階: プロット Keep Yourself Up To Date 補足というか 会のテーマとしては、新しいことを導入するメリット、デメリットについて、とありました。 が、僕の講演的には、デメリットなしというか、新しいもの取り入れるのが前提で、やりたいけどやれてないだけという姿勢。 時代 パネル ディスカッションでやっていたような、フレームワーク、ライブラリのレベルではもちろん、要件に合わせてどれを選ぶべきかって議論はあると思い
for Desktop, for Phone, for…?
商標問題で Metro が使えなくなって久しいですが。「My アプリ for Windows Store」も嫌だし、そもそも商標問題なくても「for Metro」も微妙よなぁという話。 Windows Phone 8 の方が Windows 8 とコアの共通化したのでなおのこと。 Metro 改め ちなみにまあ、商標的なところに使わなければ割と平気で、開発者通称的には Metro で通せなくもなさそう（アプリ名とかに使えないことに変わりはないですが）。 商標的なところにおいてどうなったかというと、 Metro アプリ → Windows ストア アプリ Metro デザイン → Microsoft Designe Language でしたっけ。 for Windows Store おい、お前、デスクトップ アプリも Windows ストア上に並べてるくせに（リンクのみ。ストア上からの[イン
デスクトップ アプリからのWinRT API利用
How to call WinRT APIs from .NET desktop apps Windowsストア アプリでない、通常の（デスクトップ版の）.NETアプリからWinRT APIを呼び出す方法。 WinRT利用のために、.NET Framework自体に手が入っているので、.NET 4.5を使うなら、別にWindowsストア アプリでなくたってWinRT APIを呼べるわけですが。それのやり方、というか、Visual Studio上でいろいろ（[参照の追加]ダイアログにWinRTコンポーネントの追加ペインを出したり）やるためには、csprojファイルを1行手動で書き換えないといけないというお話。 一部簡単に日本語で説明しようかというのと、元がVBなので、C#でさらっと書いてみたものを出しておこうかと。 C#ソースコード一式 WinRT APIとは WinRTは、Windows
Windows 8時代のGUI開発/Windows 8時代の.NET
金曜日に、@ITで以下のような記事が公開されました。 特集：XAMLファミリ共通開発のすゝめ（前編） Windows 8時代のGUI開発を考える そして、Silverlightを囲む会で以下のような発表をしてきました。 https://r.office.microsoft.com/r/rlidPowerPointEmbed?p1=1&p2=1&p3=SD5C622397E11C979D!3402&p4=&ak=!AFg49XomaSVgLM4&kip=1&authkey=!AFg49XomaSVgLM4 https://skydrive.live.com/#!/view.aspx?cid=5C622397E11C979D&resid=5C622397E11C979D%213402 1万字程度の原稿に加えて、25分間のプレゼン発表って、何この学術発表スタイル。 公約数 VS プラットフォーム
今月は MSDN が非同期処理の記事だらけ « ++C++; // 未確認飛行 C ブログ
非同期だらけだった BUILD の後というのもあって、MSDN Blog も MSDN Magazine も非同期だらけですねぇ、ほんと。 というか、BUILD のセッション内容がそのまま記事になった感じ。 いくつかの記事に関して、概要をメモ書き程度に： Easier Asynchronous Programming with the New Visual Studio Async CTP http://msdn.microsoft.com/en-us/magazine/hh456401.aspx そもそも async が必要とされる理由に関して。応答性良くするために他にどういう手段が考えられて、その手段だと何が問題かを説明。 解1: スレッドたくさん作る 確かに応答性は改善 リソース無駄食い （ほとんどは待ち時間なのに）客の数だけウェイター雇い、オーダーごとに2名ずつコック雇うような無駄
Windows 8、WinRT « ++C++; // 未確認飛行 C ブログ
BUILD、まだ基調講演くらいしか見れていませんが、それだけでもなかなかに素敵。 そして、公開されて間もないWindows 8の開発者プレビュー、さっそく使ってみているわけですが。 開発者的に気になっていたのは、うわさのWinRT。 コードネームとかじゃなく、正式名称的にもこの名前でよかったわけですが、実物見るとなかなかに楽しそう。 Metroアプリ vs 既存デスクトップ 開発スタイル的には全く別系統でした。いわば、Silverlight と WPF みたいなもの。 Metro アプリ タブレット向け、タッチUI たぶん、ARM版で快適に動かそうと思ったらこっち App Storeで配布できるのはこっちだけ WinRTを使って作る（ネイティブ、.NET、JavaScriptから使える） 感覚的に、一番近いのはWindows Phone 7向けSilverlight（が、.NET 4.5相
WinRT に関する誤解
まあ、ます先に、ダウンロード リンク一覧を Microsoft Visual Studio 11 Developer Preview (ISO) http://www.microsoft.com/downloads/ja-jp/details.aspx?FamilyID=415c1589-a7b1-4b25-93fa-11bb6f29a5be Microsoft Visual Studio 11 Developer Preview (Web インストーラー) http://www.microsoft.com/downloads/ja-jp/details.aspx?FamilyID=99a58e56-fcb2-4264-bce7-3311cf0d1806 Microsoft Visual Studio Team Foundation Server 11 Developer Preview
開発者にとってのWindows 8
Windows 8 上の開発環境について、ようやくきれいに整理された情報が。 Windows 8 for software developers: the Longhorn dream reborn? といっても、公式アナウンスではなくて、リークした Windows 8 （もちろんβにも満たない開発途上版）の解析結果から得られた知見。 少々私見も込みで、要約: .NET がもたらしたもの まず少々歴史の振り返りを。 .NET Framework 登場以前、90年代に置いて Windows 開発がどういう状況だったかというと、「C++ と VB のパリティ（あっちを立てればこっちが立たず的な偶奇性）」という深刻な問題がありました。 Windows の機能を最大限使いたければ Win32 API を使う必要があって、それは VB では難しかった。あと、パフォーマンスの問題もあり、大規模で応答性
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
