カドルドエグ's profileたま(ご)の記録PhotosBlogListsMore Tools Help

たま(ご)の記録

とある個人のニューススクラップ集と成長(?)の記録。

カドルドエグ

Occupation
Location
Interests
社会人歴 = プログラマー歴 = C#歴。
2009年4月で4年目に突入。未だ下っ端です。
元々はグラフィックデザインを学んでました。

HNの意味→coddled egg = 半熟卵。
自分でもつづり間違えるのでカタカナ表記。
本来の発音は「こどるど」の方が近いけど個人的感覚で敢えて「かどる」で。
因みに「半熟卵」は「soft boiled egg」の方がメジャーらしい。「こどるど」の発音だと「抱く」を意味する言葉と似ちゃうそうな。

Custom HTML

Silverlight デベロッパーセンター
MSDN オンライン
.NET Framework デベロッパーセンター
ライトニング トーク登壇者募集

ライトニングトークは、聞くのも楽しいですが発表はもっと楽しいですよ^^

November 06

知らなかったーー

 
モバイル版があったこと自体知らなかった……。。
November 04

もっと上位になるようにしてもいいんじゃないの?

Expression Blend 3の目玉機能である「Sketchflow」。
MSの技術に関してはヘルプと、そしてMSDNを調べるのが基本。
というわけでこれの作り方・使い方も例外ではなく、
調べるときは、ほぼ必ずネットでの検索を行うと思うのだけど……。
 
因みに今回参考になる(少なくとも私は参考にしている)ページはこちら
では、このページはどうやったら見つけられるだろう?
 
 
とりあえずまずは「sketchflow」でだけ検索。
Googleで検索してみた結果↓
 
 
ちょっとスクロールさせてようやくMSDNのチュートリアルページ発見。
もっと上位にヒットさせるようにした方がいいんじゃないかな…。
1ページ目にある分だけマシだけどさ。
 
Bingで検索↓

TechFieldersのコラムが上に来てるのは特に悪くないと思うんだけど、
問題は、後述のように検索単語を変えて(増やして)いっても、
結局BingではMSDNのページが(通常検索行為を行う範囲内:個人差あるけどだいたい3ページ以内に)なかったこと。。。
MSの技術なのにMSの検索エンジンでひっかからないってどうなの。。。
そりゃ後発だしまだまだ問題はあるけど、自社のページくらい優先的にヒットさせようよ。。(´・ω・`)

以下検索に使った単語と組み合わせ
・sketchflow
・sketchflow MSDN
・MSDN sketchflow
・MSDN sketchflow プロトタイプ
・MSDN sketchflow プロトタイプ作成

もしかしたらもっと別な単語や組み合わせ等々でヒットするのかもしれないけど、
汎用的な単語及び組み合わせでヒットするようにしないと意味がないような。
因みに、このプチ実験は2009年11月4日14時に行いました。

もちろん、個人のブログ上にある情報が悪いというわけじゃない。
でも、本家がしっかりしてないと普及するものもしないんじゃないかなと。

October 29

何を以て

時間があるとひどくどうでもいいことについて考えるもので。
 
 
Twitterにて、
洗い物.do
というつぶやきを発見。
 
その後すぐ思いついたのは
家事.洗い物();
 
でもこれって、
 
家事.洗う(食器);
家事.洗う(衣類);
 
と表現するのもありなんじゃないかと思ったり。
 
ただ、わざわざメソッドを一つにまとめて引数で使い分けすることに
どんなときに一体何のメリットがあるのかにもよるんだけど。。。
 
てかそもそも「家事(クラス)」に何を実装させるか(= どんな類を家事とするか)という話になるんだけれども。
 
…以上どうでもいい話でした。

イノベーションセンターでのLINQセミナーに参加してきました

 
昨日未明にたまたまキャンセル待ちで入ることができたので急遽参加。
ちょうど、LINQについての知識がほとんど皆無だったので非常にためになりました。
 
一応、正式に.NETに組み込まれたときから存在だけは知っているし本もちょこっと持ってはいるものの、
積読しっぱなしだわ聞きっぱなしだわで。。。
今回はハンズオンもあり、基本の部分を少しだけではあるけど書けるようにはなりました^^;
 
以下、知ってる人からすればあまりにも「今更」なメモ。。。。
----------------------------------------------------------------------------
・LINQは、「全て一つで事足りる」ことに依存せず、「操作」について共通利用する。
 「構造」について平準化するものではないことに注意。
 
・LINQといえば必ず紹介されるこういう↓スタイル(クエリ構文
 IEnumerable<string> result = from p in places
                                                    where p.Legth == 2
                                                    order by p
                                                    select p.Substring(0,1);
 は、以下の表現を簡素化したものである。
 IEnumerable<string> result = places.Where(p => p.Length == 2).OrderBy(p => p).Select(p => p.Substring(0,1));
 →これを「糖衣構文(シンタックスシュガー)」と呼ぶ。
 
・LINQはコンパイルされると最終的に拡張メソッドに変換される
 →クエリ構文ではLINQの全機能を使うことはできない(クエリ構文でカバーされてないものが多々ある)
 
・LINQというか拡張メソッドのイメージ(前述のメソッド構文を例にした場合)
 places:元のコレクション > Where:データの絞り込み > OrderBy:データの並び変え > Select:データを加工し新しいコレクションとして返す
 左から右へ値が引き渡され、フィルタリングされているイメージ:パイプライン処理
 
・前述で書いたようなLINQ処理は、その場で行われて(今回の場合)resultに格納されてはいない。
 この後で、foreachなどでresultが使用されるときにはじめて動作する
 結果セットをインメモリで保持しないので別途保存(ToArray()など)が必要。
 
・C#及びVB:手続き型プログラミング = 問題の解法を記述
 →LINQは、そこに宣言的プログラミング(= 問題そのもの、必要とする結果を表現)を持ち込んだものである。
  問題の抽出方法はLINQの実装側が考えること。
 
・従来との対比
 <<LINQなし>>
 List<String> companyNames = new List<String>();
 List<String> result = new List<String>();
 
 foreach(string c in companeNames)
 {
   if(c ==  "Microsoft")
  {
   result.Add(c);
  }
 }
 
 <<LINQあり>>
 List<String> companeNames = new List<String>();
 
 return from c in companeNames
              where c == "Microsoft"
              select c;
 
 やってることは同じでも表現がとてもすっきりしている
 
・C#内でのLINQは、C#2.0~3.0にかけての新しい技術で成立している。
 →デリゲートや匿名メソッド、拡張メソッド、ラムダ式など
 
・クエリ構文で使用される「句」はメソッド構文にしたときの「演算子」に相当。
 ※一部除く。詳細はMSDN等を見てください
 
・クエリ結果は、RangeやAll、Anyといったメソッドで活用させることができる。
 ※詳細はMSDN等で。
 
・よくあるLINQプロバイダ…
        LINQ to Object:配列やListなど
                          LINQ to SQL:SQLServerへのアクセスをサポート。
                                          対象は2000~2008及びCompact 3.5。
                                          DataContextがポイント。
                                          ストアドの呼び出しも可。但しどんどん遅延していくので注意。
                          LINQ to XML:3.5から加わったSystem.Xml.Linq名前空間内のクラスを使用。より直感的に扱えるようになった。
                                          Xmlをインメモリで取り扱う。
                                          VBではXMLリテラルなどの機能で直にコード内にXMLが書けるが……。
                                          LINQ to Objectにあった標準的なクエリ拡張メソッドの他、XML用のも用意されている。(System.Xml.Linq.Extentionクラスで定義)
 
October 27

HTML5概要

 
こうやって見ると、
より「開発言語」としての側面を強めた感じ。
 
確かにプラグインなしでも~、というのは魅力の一つだと思うけど、
最終的には使い分けになるような気がするなぁ。

Windows 7 開発秘話?

 
MSだけじゃなく、Windowsを入れるメーカー側とも協力し合って作り上げたのかー。
なんだかそういうのを知ると、別に自分が関わったわけじゃないのに特別な思いが入るようなww
 
…というか今まで完全自社オンリーだったいうのがあまりにイメージ通りすぎて驚き。。
October 24

.NET Framework開発ガイドブック

 
こういうのってもっと前からあるのかと思ってたけど、そうでもなかったのかな?
それともリニューアルに伴って書きなおされたクチかすら?
 
ともあれネット上でこういうのが読めるのは良いよね。

第1回.NET中心会議に参加してきました

詳細はこちら
 
今回は久しぶりにがっつりメモってきたので掲載しようかと。
…ただ、相変わらず飽くまで「メモ」なのでそこはあしからず。
 
また、あまりよく理解できてない個所に関しては間違った表現があるかと思います。
その時は発見次第コメントでご報告頂けると助かります。
---------------------------------------------------------------------------------------------------------
@IT編集長 デジタルアドバンテージ おがわさん
前身は「VB研」:名前がVBオンリーっぽいので「.NET開発者中心」
ロゴもお金かけてます:イメージは「野武士」 日本の開発者を元気づけたい
★なんかしりきれとんぼ
宣伝:太陽生活 補助金サーチ クロールアプリ開発にえんどうさんが携わっている
大手建築会社「そのサービスほしい」最初は人使ってやろうとしたけど断念
→これがITの原点:人だけではできないこと ニーズにあったソフトを開発すること
パネラー
おがわさん
インサイダー.NET編集長 えんどうさん
副編集長(助手)
グレープシティ やまきさん
インサイダー.NETライター  日立ソフト みやざきさん(こぐまさん)
MS 赤間さん(こんさる) 新村さん(製品マーケティング) 鈴木さん(同じ)
Silverlight、クラウド、Azureは時間なければカット
大テーマ:Winアプリ&Webアプリ>データアクセス>>.NET FrameworkとVSは一括で

<3分間で「現状」を説明> 
【Winアプリ】
やまきさん:
Winフォーム:1からあるUIテクノロジ 2から大きくアップデート
3.5でもWinフォームは2.0と変わらず おそらく一番使われているUI技術
3.0からWPF:Vistaと同時に投入 実際は出た当初は移行ではなく使い分けで説明していたが……
最近は「WPFに移行推奨」 Winフォームはメンテモードに。
4.0でも、Winフォームは存在こそしているが機能追加等はない
Silverlightのブラウザ外:動きが一緒なだけ
えんどうさん:
印象=WPF少ない 現場は?
WPFはグリッドが別ダウンロード:4.0から含まれる→この現状が要因の一旦?
VSの開発でWPFでもWinフォームでもぺたぽてができる
じゃぁ、移行は必要ない?なんのためにWPF?デザインぐらい?
みやざきさん:
現場でも実際少ない。WPFの方がリッチだとは思うけどやっぱりまだまだ。
コンポーネントでもWPF版が出てないなど、外部環境が整ってない
今の業務アプリ:グリッド中心 日本は紙ベースの帳票見やすいという文化が根付いてるので
簡単に移行の流れには持っていけない
WPFへの移行の理由:デザイン性、美しさ、センスの問題
作業分担はわかるけど現場でそういう仕事があんまりない 環境が整ってない→普及しない
やまきさん:
少しはWPF版あるけどメインでは出てない。鋭意開発中。来年以降にいくつか出る…?
レイアウト:WPFで解像度の差の埋め方が楽になった
WPFはやらない理由のひとつ:開発環境が追いついてない コンポーネントも少ない
では、WPFで作るメリットって何?という問題に。
WPFのUIの基盤:自由度高い 柔軟性ある→デザイン性の自由度だけじゃない 
ちょっとしたボタン配置変更などは、Winフォームだとプロパティになければ自分で描画だったのが、WPFであれば
データ扱うための基盤もWPFは整ってる:UIだけの頭でっかちだけでなくデータ扱うのと分割
洗練されてる
移行は難しくても新規案件であれば検討の価値あり
すずきさん:
WinフォームとWPFとの違いを理解してる方少ないんじゃないの?
Winフォーム:歴史的にいうと、C++やってるとわかるけどGDIというAPIをラップしたもの。
GDIという技術はWin2(16bit)の時代から。画面上にドットを打つ、色を塗る、というAPI
ビットマップを扱う部品の集まり
広範囲のハードをサポート
WPF:その下に流れているAPIテクノロジが違う。DirectX=ゲーム用のグラフィックアクセラレータに
近いとこで動く。3D扱ったりかなり高速でやるためのAPIをラップしたもの
ベクターベースの描画するためのAPIをラップしたもの
比較的新しいハードが持ってるものをサポート
赤間さん:
.NET=ピクセルベースUIはWinフォームやGDI+ 2次元絵
   ベクターベースはDirectX
   ドキュメントベースのUI:HTML、ASP.NET
→これらをまとめて扱える技術
UIと技術が一本化してた→今は複数技術を織り交ぜる
現在開発される高度なWinアプリ=UXはこれらを混在させなくてはいけない→XAML=WPFの根幹
開発手法はどう変わる?→VB6:ぺたぺたはりつける 
WPFやSilverlight:レイアウトという概念のもとに作られる CanvasはWinフォームとほぼ同じ
しかしそもそもそんな高度なUIいるんか?というのもある。
ニーズのバランス
ぱわぽみたいに勝手にサイズごとにレイアウトかわるアプリが作りやすくなった
要は「絵じゃない」
現場でそもそも高度なUIを必要とするものがあるのかという問題
誰しも「かっこいい」とは思うけど自分の日常業務でやるのかというとそうでもない コンシューマー向けくらい
→でも最近、高度なUIを必要とするのは、業務でも参照系だと必要かも。 データ分析系だと、PCに詳しくない人向けに直感的にわかるUIが必要
→Winフォームだと行き詰まる
今まで使えなかった人が使えるようになる、マニュアル見なくても直感でわかるUIへのニーズ
コンサル現場でも、WPFデモ見せると驚かれる→思いつかないらしい
協業があるケース:デモPG作るときとか
しんむらさん:
2008:XAML編集めんどい
2010:DataGridおよびデータバインディングD&Dなど、Winフォームで簡単にできたことがWPFでも
できるようになる→追いつく
デザイン:Expression デザイナが作ったものをブラッシュアップ 元々はデザイナと開発者のコラボがテーマ
デベロッパがすべてをやる必要ない:作業の切り分け→WPFだとそれができる
マーケットの状況:これまでは開発者の生産性を重視してきたが、今の景気等でエンドユーザーの生産性を上げる必要性も出てきた→リッチなUIが求められている
WPF移行するのはいいけど金ない、といわれる→実際はWPFはWinフォームの一部としても使える
アプリ全部直す必要はない
すずきさん:
実際はWPFにいきにくいという環境まだ多い
こちらとしては新しいものを薦めたいが……。
Winフォームもこれからすぐ使えなくなるわけじゃなし。但し将来的にはWPFをおすすめしやすい環境がそなわってくる たとえば3年後、5年後どうなってるかを考えてみてほしい
MSの人間だからというのもあるけど、必ずWPFの時代が来る。
Q&A
WPFとWinフォームでは後者の方が生産性が圧倒的に高いのでは?
→社内のツールであれば十分。しかし、ITリテラシー低い人向けだとWinフォームだけでは足りない場合がある。
生産性にかんしては、ツールが多い等環境の違いもある。本来はWPFの方が使いにくい作りにくい、というのはない
WPF勉強するとSilverlightでも使える:サブセットだから
パフォーマンスやリソースの消費は?
→パフォーマンスという観点では、描画スピードは圧倒的に速い。但しハードに近いとこで動いてるのでハードのスペック次第になる。
但し、今普及しているハードの性能を考えると、Winフォームの方が早い可能性大
チューニングが進んでるのはWPF
【Webアプリ】
みやざきさん:
ASP.NET:ぺたぽて&ドラッグアンドドロップなど、Winフォーム作ったことある人にとってはすごく楽。しかし、これまでのWebアプリ作ってきた人=HTML書いて~という人にとっては使いづらかった
→そこで出たのがMVCというFramework:より大規模な開発にも耐えられるように
よりリッチな表現→Silverlight
3年後:今のWeb界はどれが標準になるかわからない混沌とした状況なので不明
ギャップが激しいといっても、今実際Webアプリをリッチにしようとして使うのはjavaScript
ViewState:かなりたくさんの情報持ってる→体感的に遅くなる
MVCは現状、VSのSP1入れても使えない(MSのサイトからだうそして使う)ので、そもそも存在知られてないのかも
大規模に耐えうる=テストしやすくなった
2が出るにあたって、考え方は無駄にならないけどこれまでの「モノ」は無駄になるかも…。
SilverlightはSilverlightでブラウザ内全画面別個で
やまきさん:
比較的小さいもの=Webフォームが向いてる しかし、ViewStateなど、使い方によっては重い
MVCであれば軽いしきれいなHTMLをはいてくれる
コントロール=中にVとC 考え方がちょっと合わない
体験:病院で、CT写真表示のアプリがなぜかIE…→Webアプリにする必要あるの?
Javaからきてる流れ?
えんどうさん:
1.0だと基本手書き:ギャップが激しい
ViewState:手間暇かけた割にチームでの調整が必要
MVCとASP.NETの混在はできないの?
MVCに新しいコントロール:それできれいなHTMLはけるの?
3年後は??
Silverlightで全画面アプリは?それだとWinフォームとかいらなくなる?
赤間さん:
MVC出た時「今更先祖帰りしてどうする」
素でのHTML→コンポーネントベースという流れから出たのがASP.NET:対話型アプリ作りやすい
確かに参照系ならMVC役立つところ多いと思うけど、使い分けるべきだと思うしViewStateが何でもかんでも悪いわけじゃないしそもそもViewState大きくなってるってのは設計的にそもそもどうなの?
→ViewStateでかくなるからMVC、は危険
URLマッピング:アマゾン=スラッシュ区切りでISDN 検索で引っかかる カタログデータをネット上にさらす分には便利 でも…?
どこで切り分けるべきか:素のHTMLをきれいに出したい&コンポーネントベースで開発したい&javaScriptとか使ってリッチにしたい の3つ
きれいに出したい:生産性は犠牲にせざるを得ない
コンポーネント:きれいさを犠牲 更新タイプだと威力発揮
操作性高めたい:ASP.NET Ajaxなど 但し、AjaxでjavaScriptがりがりは生産性高くない
コントロールつかって「吐き出させる」ならまだしも。→そこまで高度なUIを実現させるべきなのか、という話
日本では、ActiveXインストはOKなのに.NETはだめとかなんでもWebアプリであれば案件とれるとかいう土台がある
漏れるものについては.NETで、というお客さんも。
混在:できる
コントロール:対話型処理のハンドリングで発揮 
新村さん:
Webフォーム:URLの問題点
MVC:URL指定で確実に表示したいページが確実によべる RESTの考え方 インターネットで使う
鈴木さん:
ASP.NETは結局HTMLはく技術 Web系はHTMLに依存して進化してきた→MVCが出た理由の一つ
HTMLを生で書くというのを正とすべきか否か:
HTMLを生で=WinフォームでいうならAPIを直書きするのと同義
→だからASP.NETが出てきた
どちらか一方で行く、という話にはもっていくべきではない
なぜ、「Webアプリを作る?」を考えてみよう なぜ「ブラウザを使う」かを考えてみよう
例)今からHTML5のアプリ必要?
まだSilverlight開発がほかに追いついてない
確かにインストが面倒なら、Silverlightフルスクリーンもあり
Q&A
工数や開発者の確保:
→何をゴールとするのか でも基本、JavaScriptごりごりは薦めない 
書かないとなると、RIAみたいなランタイムが対抗馬に
Java
→Javaって思い込みで作られてるとこがある Winアプリ:操作性ちょっとかわる
最近はJavaも.NETも両方できる人が増えてる
【データアクセス】
赤間さん:
SQLべた書き
ウィザードベース
LINQ ORマッピング 単なるウィザードベースではない
エンティティ
上2つが大半
性能的な話するとちょっと複雑:べたがき<LINQtoSQL<ADO.NET Entity 重い
アプリケーション処理の中の「比率」で見る 業務に依存する
アプリケーションを選んでしまう
大規模案件の場合:様々な状況に対応できることを重視 参照系:生産性を重視
うまく併用することをすすめる
技術的にみた場合:LINQtoSQL ダイレクトにSQLがマッピング ADOetc:一旦概念モデルにマッピングしてから 上位のデータモデル概念を扱いたいときに向いてる MSとしてはこれに重きおいてる
LINQtoEntity以外は消えてくんじゃ…?→LINQtoXXX=言語構文 SQL:汎用概念 EntitySQL:概念モデルに書く:言語に依存しない 開発中心に使われていく
「なぜ」LINQtoEntityを使うか どこに使うメリットを見出してるか
概念データモデルだと2の方がよいけど
開発者にとって身近なのは論理データモデル:区別つかない人多い 
概念モデルから落としておくべき:概念→論理→物理の順がベスト 実際の現場では論理からはじめるのでインピーダンスミスマッチ発生
究極は概念だけを書けば全部おkをめざす
トランザクション設計、アプリケーション設計大事
データセットが非常によく出来てた:普通だとそれだけでできてしまう。
変更履歴をまとめて一括で扱う スマクラ的
POCOに対するニーズを満たすための概念=LINQtoEntityなど
履歴が持てない→外部に持たせるということでデータコンテキスト 
昨今のPOCOのニーズにこたえるのが課題
使いやすさ、わかりやすさでいえばデータセット
えんどうさん:
新しいもの使うとパフォーマンスは?
今から安心して使えるの?
画面から作ることの方がわかりやすいからだと思う。概念からというか概念自体作るのが大変
やまきさん:
みやざきさん:
実際は画面設計中心→データ関連は後付けになりがち 学術的順でいこうとすると厳しいのが現状
【.NET Framework 開発言語】
ここから進化していくための足がかり
COBOLがいい、という人の理由:上から下に向かってやるのがよい
利用バージョンの比率;グレープシティの商品利用者のアンケート
思ったより早いスピードで3.5が普及している(少なくともグレープシティの商品利用者の中では)
VSと.NETのバージョンは同じような感じで推移
2003は2002のバグフィックス版的位置づけだったのもあって移行が早かった
昔はVB6からの移行の関係でVB.NETの案件が多かったが、最近はJavaからのというのもあってC#が増えてる
今VB使ってても将来的にC#にしたい、という人が少なからずいる、ととれる結果→理由は?
でも両方存在するしVBなくならない ただ、ベータ版のサンプルコードがC#多いのは事実 開発側で使ってるのがC#だから;なので、読めるようになるくらいはしといたほういいかも
今後、VBとC#は仕様をそろえる流れ
VBの方がインテリセンスのききは良い:MyとMeとドットがわかればカーソルで、という話さえ
VB:初心者向け 思想の違い
2010からWPF使い始めてる:フルWPFモードもある
Winに標準で入ってるアプリにフルWPFがない:ExpressionはフルWPF
電卓はWPF
2010のうり:テストが使いやすい Pro版以上 Winフォームの自動化機能がついた 動きを記録して再生→自動化 テストセンター:テスト専用ツール
最新を追いかけるのもいいけど、幅をもたせるのも大事:視点ごとに触る技術を変える 別なアプローチをとってみる
開発環境として進化を期待:かゆいところに手が届くツールに
Winフォームの開発は変わらないだろうけど、WPF、Silverlightの開発は2010でスタートラインに立った感じ
・WPFは今後のコントロールや生産性の関係で先がある。新規案件であればぜひWPF
・ASP.NETに関しては、WinフォームとWPFの関係とは違って、MVCなどと共存・使い分けになってくる
また、そもそもブラウザを使うことが適しているのかも考えるべき
・「適材適所」が重要なキーワード 存在している技術には存在している理由があり、何ができて何ができないのかを理解して使い分けるべき。また、新しく出現したエリアにも目を向ける。
同じ5%生産性を高めるなら、まったく違うとこに目を向けて生産性を上げる努力をしてみる
・自分の得意なところを深くしつつ、視界は広く。いかにT字型に成長するか
・「作る」は本来楽しいものであるべき ポジティブな感情で使ってくれるとうれしい
 
October 13

ImageのSource

画像類は一つのフォルダ下で管理したい:プロジェクト直下がごたつくのが嫌
という私にとって、この流れ↓は何気に鬱陶しかったりする……。
 
前提)別途フォルダを用意してその中に画像がある。プロジェクト直下に画像はない。
 
1)ダイアログから上記フォルダ内を表示
 
3)無事設定されるのは良いけど(結果として)画像がだぶって存在することにorz
 
手入力で
fol/blogRed.png
って入れればもちろん、きちんとフォルダ内の画像を参照してくれるけど、
それは正直めんどう。。。
 
確かに何の下準備もない状態でも、指定さえすれば勝手にプロジェクト内(というか直下)に
置いてくれるのは便利だとは思うけど……。。
あるいはこういうのはまた別な管理方法があるのかな…?
「リソース」がよくわからないのもあってちょっと怪しいと思ってたり…。。。
 
ま。時間はあるのでちまちま調べてみるか。
 

しょーとかっと~BlendとVSとIllustrator~

私はただ、Blendでプロパティウィンドウを表示したかっただけなんです。( ´_ゝ`)
↓プロジェクトタブをひらいてました
 
で。
プロパティを確認(というかImageのSourceを設定したかった)しようと、VS使用時のくせでF4を押したのね。
↓うをー!全部引っ込んだ!!
因みにもう一度F4を押すと戻ります。
 
さて。
この「全ウィンドウ/タブ引っ込み機能」(←造語)、イラレ(我が家はまだCS2…)だとタブキーで同じようなことができます。
では、同じデザイナー向けとして出たBlendはどうだろう??
と思ってやってみたらF4と同じ機能が。
うーーん………。。これって意味あんのかな……??
 
じゃあ、
イラレ(CS2)でF4は?というと……
↓(前面に)ペーストでした。これもまたどうなの……?^^;
 
「編集」を選択したときに出てくるショートカットは「Ctrl+F」。F4は隠れショートカットなのかすら。
 
Blendはデザイナー向けってことでAdobe系ソフトと同じような感じにしたのだろうけど、
BlendってVSとの親和性の高さが売りの一つなわけで……。(と少なくとも私は思ってる。。。)
ウィンドウ表示系は、キーが空いてたらでいいので;、VSとそろえてくれると使いやすいなー、と思ったり。