TechNet バーチャルラボ始まる

(^^

Microsoft Conference 2006 大阪

Neutral Scent

.NET XAML系

The Next Web Now - video

Vista . WPF . Web を利用してブラウザにとどまらない、よりインパクトの強いビジネスの可能性を示している。

2006年紅白、出場歌手決定

（ﾟーﾟ☆キラッ

遺伝的アルゴリズム？

明確な評価基準を設定してやれば、確実に強くなる。

復活

やっと悪夢から目覚めました。
巷で噂の"ノロウィルス"ではなかったようですが、結構大変でした。

風邪でダウン

ぐふ・・風邪にやられた…
もう…両足がしびれるというか…だるいというか…
夢の世界へ旅立ちます…

BUMP OF CHICKEN - 涙のふるさと

おおおおお、いい感じです。
歌い易さも抜群で、すっきり・気持ちいい・心地良い系です。

フォルダを右クリックしてPowerShellを開く

GJ

Windows Imaging Component 対応コーデックの作成方法

うひょ！
プラットフォームレベルの画像Pluginがサポートされているらしい。

Windows Vistaで導入される画像のコーデックを書くための方法

神原日記 - フリーハンドでベジェ曲線

Willustrator というWebドロー系ツール作者さんのブログ

IPA:未踏ソフト にて認められた人らしい！

Vector PickUp win グラフィックス関係

なんとなく（＾＾；

『プログラミングMicrosoft .NET Framework 第2版』

いい本がでるみたい。
2006/12/08 に発売予定。

Windows Vista 技術資料一覧

パッション!

蛙男商会 kaeruotoko.com

た～か～の～つ～め～

トップランナーに登場した FROGMAN さんのサイト

Web における WPF : XAML ブラウザ アプリケーション

（＾＾ｂ

Neutral Scent - WPFを理解するためのおすすめビデオ

了解！

Microsoft .NET Framework 3.0 Community (NetFx3)

Galleryあたりをチェックするといいらしい。

Windows Presentation Foundation Station

WPFについて載っている

ラーニング - ホーム

試験・勉強系

マイクロソフトプレス オンライン

書籍

Microsoft TechNet

技術情報

第 3 章 コントロールと XAML

Japanese Blogger Update Info

日本語のBlogger ブログの更新情報

クローバー？

にょきっ

ベジェ曲線 - Wikipedia

どのように描かれるかがよくわかる。
考えた人しゅごごご！

Photoshop でベジェ曲線に挑戦

日本語プログラム言語「なでしこ」

日本語でプログラムできるんだって！
すげげげ！

成長するコツ？

・本来の目標
・小さな目標
・リスク
・集中

この４つが明確に与えられた時、急激に成長します。

例えば、中学のサッカー部に所属している少年がシュート力に悩んでいたとします。
少年は帰宅後、練習することにしました。
部活中と同じ格好で家の近くにある空地にやってきた少年。

ところが、この空地には問題がありました。
地面には土ではなく大きい砂利が敷き詰めてあったのです。

シュートに失敗すれば、痛い思いをすることになります。
少年はボールを蹴る位置・蹴る体勢を注意深く確認しました。
うまく蹴れれば足にダメージを受けることはなさそうです。

さて、空地の１辺にだけあるブロック塀に的を設定します。
しかし、ここにも問題がありました。
ブロック塀は、ブロック６段の上に２ｍのフェンスが付いているもので、
フェンスの向こう側には、送電線を通す鉄塔がそびえ立っていたのです。

ブロックとフェンスで高さ５ｍはあり、多少コントロールが狂ったとしても
まずボールが飛び越えることはないように思えます。
しかし、万が一飛び越えてしまった場合、ボールは回収不可能となります。
なるべく低い弾道にしたほうが無難です。

少年はシュートフォームを再確認しました。
準備完了！！
シュート！　シュート！　シュート！（あ痛っ）　シュート！　シュート！（うぐ・・）　シュート！
スパイクを履いていても大きい砂利に指先が当たれば結構な痛さです。
足全体・足の甲・足の指先に神経を集中させ、的への低い弾道をイメージし、シュート！！

成果は３日程で現れ、少年は以前とは比べ物にならない強烈なシュートを打つことができるようになりました。
部活のメンバーからも注目を集め、ちょっとした人気者になりました。


というわけで、ここでの４つの条件を見ていきます。

・本来の目標　…　「シュート力UP」
・小さな目標　…　「ボールを的に当てる」　「蹴ったとき痛い思いをしない」　「ボールをなくさない」
・リスク　…　「シュートに失敗すれば大きい砂利に足をぶつけてしまう」
　　　　　　　　「ブロック塀をボールが飛び越してしまったら回収不可能」
・集中　…　「集中しなければリスクを負ってしまう」

となります。
本来の目標を意識するというよりは、リスクを回避することに神経を使っている感じですね。
でも、リスクを完全に回避できたときは、本来の目標を達成できていることに注目です。

集中しなければ回避できないリスク、けれど 集中すれば回避できるリスク。
このバランスのリスクを設定すれば、様々なことに対して自分を成長させることができるかもしれません。

Microsoft Expression

画面のデザインツール

「Web・アプリ・絵」と３つの分野ごとにEditionがあり、デザインをサポートする。

Trash Microsoft Expression Graphic Designer
Expressionのページ

ドロー系もペイント系も別段意識したことがないおいらにとっては、見る物すべてが新鮮（＾＾；

CodeZine

技術情報

Window Handle

　・・
のカバー！！

LUA Buglight public [pre]-release

『Vistaの新機能「Least User Access（LUA）」に関連するバグの特定を目的としている』 ツールらしい。

MS、Vista向けにセキュリティ上のバグ発見ツールを開発中 (2005/12/19)

Windows PowerShell

次期コマンドラインシェル

.NET Framework のクラスを利用できる。
パイプなどでのデータのやりとりは文字列ではなく、「オブジェクト」で行われる。

様々なアプリ・スクリプトをより簡単に連携させることができるので、素敵な結果を得られるかもしれない。

PowerShell Memo
次世代Windowsシェル「Windows PowerShell」を試す

Windows Vista Team Blog

IEBlog

Internet Explorer 開発チームのブログ

Technorati (テクノラティ) ブログ検索

ブログ検索

Microsoft Windows SDK Blog

Windows SDK Team のブログ

Google Analytics

導入しました。

.NET Framework 3.0 リリース

次期 Visual Studio の機能を先行リリースした感じかな？

ふと思ったけど、WFはCodeDomによる実行時コード生成術 のビジュアルツールかも。
おおおお、なんだかよくわからんけど、しゅごい気がしてきた！

寒い！

めっきり冷え込んできました。

ファイル復元･抹消

Smart Data Recovery 3.2

ファイル復元ソフト。(デジカメ可)
フリーでありながらすばらしい復元率を誇る。

プログラミングの丘

http://jet.breeze.jp/program/tips/atl_rgs.htm

レジストリスクリプトについての書式と説明が載っている。

DirectX でゲームを作ってみよう(6)

サーフェスロックの注意点が載っている。

具体的なアドオンの作成方法が載っていた。（現在キャッシュのみ）

Read more!
Creating an IMG SRC handler
I've  investigated the mechanism of Internet Explorer's <IMG SRC>  handler for these days. And I've found it is very easy to create  my own IMG SRC handler! In this document, I explain the procedure  to create your own one.
  
Step 1
  You must create a empty ATL object, which adopts the  single thread apartment. And add the interface entry of  IImageDecodeFilter.
  If you're working with Visual Studio .Net Environment, your ATL  wizard creates quite a simple files without good old IDL files.  It would be like as:
  
  
    
      
class ATL_NO_VTABLE      CMyImageDecodeFilter :
        // <Prior version of      VC++ inserts many ancestor classes here>
        public IMyImageDecodeFilter,
        public      IImageDecodeFilter
      {
      public:
        CMyImageDecodeFilter()
        {
        }
      
        DECLARE_PROTECT_FINAL_CONSTRUCT()
      
        HRESULT FinalConstruct()
        {
          return S_OK;
        }
      
        void FinalRelease()
        {
        }
      
      BEGIN_COM_MAP(CMyImageDecodeFilter)
        COM_INTERFACE_ENTRY_IID(IID_IImageDecodeFilter,      IImageDecodeFilter)
      END_COM_MAP()
      
      public:
        // The methods we've      inherited from IImageDecodeFilter class
        STDMETHOD(Initialize)(IImageDecodeEventSink      *pIDES);
        STDMETHOD(Process)(IStream *stream);
        STDMETHOD(Terminate)(HRESULT);
      };
    
  
  I've removed many extra staffs that may confuse you to  understand what's going on.
  
Step 2
  Now All we have to do with this class is to implement 3 methods.  Initialize, the first method, is called at first.  The caller provides us the most important parameter  pIDES.
  Although IImageDecodeEventSink class is too large  for me to analyze whole of it, it is very clear that  pIDES knows everything about the canvas (they call  it surface) on which we are going to draw. We must use this instance  pointer in the other methods, so keep this pointer to some member  function and also increasing reference of it by calling  AddRef method. And this is just the time to call the  important method, IImageDecodeEventSink::OnBeginDecode.
  
    
      
  HRESULT IImageDecodeEventSink::OnBeginDecode(      DWORD* pdwEvents, ULONG* pnFormats, BFID** ppFormats);
    
  
  The first parameter seems to return the events to be invoked by us.  It seems that it returns the list of acceptable pixel formats as  the second parameter. And the third parameter indicates the number  of entries. In the sample below, we checks the existence of RGB  24-bit format, BFID_RGB_24 and if there is not,  immediately return E_FAIL, otherwise return S_OK.  
  
    
      
STDMETHODIMP      CMyImageDecodeFilter::Initialize(IImageDecodeEventSink      *pIDES)
      {
        m_pIDES = pIDES;
        m_pIDES->AddRef();
      
        if(FAILED(m_pIDES->OnBeginDecode(&m_dwEvents,      &nFormats, &pFormats)))
        {
          m_pIDES->Release();
          return E_FAIL;
        }
      
        // find the prefer BFID      (Colorspace) to use
        ULONG i;
        for(i = 0; i < nFormats; i++)
          if(IsEqualGUID(BFID_RGB_24,      pFormats[i]))
            break;
      
        if(i == nFormats)
          return E_FAIL;
        return S_OK;
      }
    
  
  
Step 3
  The next step is to implement  CMyImageDecodeFilter::Process.
  
    
      
  HRESULT CMyImageDecodeFilter::Process(IStream *stream);
    
  
  This function is called when Internet Explorer want to process an image of  the our image type, and we can read the image file by using the parameter  stream.
 There's an important notice, although this  parameter is IStream based class, we can not make random  access codes rely on it. It only accepts sequential Read  method calls. No other methods are implemented; you can not get  the size of the file.
  To make matters worse, the Block read using Read  methods does not notify me the correct EOF. For example, reading  1024-bytes each time, the last block, which is no more than  1024-bytes, can not be obtained. A file that is 2060-bytes is  corrupted into 2048-bytes file. So we must read the file  carefully.
  
Step 4
  When we've loaded the file, draw the image onto the surface that  can be obtained by the  IImageDecodeEventSink::GetSurface method. If you are  an experienced DirectDraw programmer, calling this method is  quite easy. Unfortunately I've never experience programming  DirectDraw, I may write something wrong in this section. If you  notice something bad in this article, please inform me of them.
  Anyway, the interface of this function is defined as follows:
  
    
      
  HRESULT IImageDecodeEventSink::GetSurface(
          LONG width, LONG height, REFGUID      bfid, ULONG nPasses, DWORD dwHints, IUnknown **ppUnk);
    
  
  To get the surface, we pass the parameters, width, height and  pixel format of the image. For some reason, Internet Explorer can  not handle large images and we have to do something if the  image is quite large. And it also seems that Internet Explorer now  supports only 24-bit RGB surfaces (BFID_RGB_24).  GetSurface method gets 2 more parameters except the  pointer to the buffer to get interface. nPasses  seems to be the passes to decode the image, but I'm not sure of  the real usage of this parameter, indeed, the multi-pass decoding  can be done even if the parameter set to 1. dwHints  is the flags to specify some additional attributes. The details  about this parameter are also unknown. We set  dwHints to IMGDECODE_HINT_BOTTOMUP |  IMGDECODE_HINT_FULLWIDTH. The one thing that is apparent to me is  that IMGDECODE_HINT_BOTTOMUP indicates the usual bottom-up DIB.  But I don't know about IMGDECODE_HINT_FULLWIDTH. What's this?
  
  
Step 5
  OK, anyway, we've get the IDirectDrawSurface  interface pointer. That's the time to paint on it! But there're  also some restrictions on this interface. Almost all methods are  not implemented. The only one method we can use with this interface is  Lock/Unlock. We must build images on  DIB by using raw pointers! I'm sorry but there seems to be only  one way to do it. IDirectDrawSurface::Lock method is  defined as follows:
  
  
    
      
  HRESULT Lock(
          LPRECT rc, LPDDSURFACEDESC pddsd,      DWORD dwFlags, HANDLE hEvent);
    
  
  The first parameter rc is region to paint on.  Although it can be the whole of the surface, as far as DirectDraw  reference, locking the large part of the image long time causes  poor system performance. Anyway we set the whole of image to  paint on it. The next parameter is to get the details of the  surface. All we have to do with it is to set  DDSUTFACEDESC::dwSize to  sizeof(DDSUTFACEDESC). And set dwFlags  to DDLOCK_WAIT, don't ask me about it. The last one,  hEvent is set to NULL.
  If the method succeeded, we get the pointer to the raw DIB buffer  on DDSURFACEDESC::lpSurface member. The row-stride,  the bytes per line, is obtained in  DDSURFACEDESC::lPitch. For the image manipulation  basics, refer to other resources, I don't want to explain what is  row-stride or pitch.
  After drawing images on the buffer, we must unlock the buffer by  calling Unlock method with the region passed to  Lock method.
  Now we must inform the Internet Explorer of updating the image by  using IImageDecodeEventSink::OnProgress method that  is defined as follows:
  
  
    
      
  HRESULT OnProgress(LPRECT      rc, BOOL bComplete);
    
  
  We call this function only if the m_dwHints, the  first parameter of  IImageDecodeEventSink::OnBeginDecode contains  IMGDECODE_EVENT_PROGRESS. The first parameter  rc is updated region, same one to previous calls.  The second one, bComplete indicates whether the  drawing of the image is finished or not. If this is not  FALSE, there will be some subsequent calls after  that.
  Call IImageDecodeEventSink::OnDecodeComplete method  when finishing all of the drawing process. This method has a  HRESULT type parameter to indicates errors. If the  drawing process is success, simply pass S_OK.
  As already you've noticed, the image format we are now reading  supports progressive feature or something like it, we can show  the image progressively to the user.
  
Step 6
  To register this handler, we create an entry like below:
  
  
    
      
      HKCR\.some_extension
    
    
      
 
      
(Default)
      
REG_SZ
      
"someImageType"
    
    
      
 
      
"Content Type"
      
REG_SZ
      
"some_image_type"
    
  
  
    
      
      HKCR\SomeImageType\CLSID
    
    
      
 
      
(Default)
      
REG_SZ
      
      "{25336920-03F9-11cf-8FD0-00AA00686F13}"
      
(1)
    
  
  
    
      
      HKCR\MIME\Database\Content Type\some_image_type
    
    
      
 
      
"Extension"
      
REG_SZ
      
".some_extension"
      
    
    
      
 
      
"Image Filter CLSID"
      
REG_SZ
      
      "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}"
      
(2)
    
  
  
    
      
      HKEY\MIME\Database\Content Type\some_image_type\Bits
    
    
      
 
      
"0"
      
REG_BINARY
      
See Below
      
(3)
    
  
  The entry (1) is needed to view the direct link (<A HREF>)  to the image in the browser. (2) is string notation of the CLSID  of your component.
  (3) is a binary string that identify the image file. For Windows  bitmap files, this is
  
    
      
02 00 00 00 ff ff 42 4d
    
  
The first 4-bytes are the size of identifier. The next is  0xff padding, which size is specified by the first 4-bytes. The  last 2-bytes are actual identifier of the bitmap file, "BM". In  the same way, GIF file has the following one:  
    
      
04 00 00 00 ff ff ff ff 47 49 46      38
    
  
The last 4-bytes are "GIF8". WMF (Windows Meta File) file  have the following:  
    
      
04 00 00 00 ff ff ff ff d7 cd c6      9a
    
  
PNG has a longer one.  
    
      
08 00 00 00 ff ff ff ff ff ff ff ff      89 50 4e 47 0d 0a 1a 0a
    
  
But the most confusing one is JPEG. JPEG has 2 entries  "image/jpeg" and "image/pjpeg". Each entry has same one.  
    
      
02 00 00 00 ff ff ff 8d
    
  
Pay attention to the third 0xff. This is a part of file  identifier, not the padding. If you know something related this  article, please inform me by e-mails. I appreciate your opinions.  mailto:espresso@ff.iij4u.or.jp  

IEプラグイン解析日記

画像プラグインの作り方が載っている。

Browser Extensions

アドオンを書く場合の情報源

例えば、IEがサポートしていない画像形式を表示させるには
「IImageDecodeFilter」で定義されているインターフェースに沿ってコードを書けばＯＫ。

リモートデスクトップのまめ知識

見慣れた環境で作業できるのは素敵。

マインドマップ

自分の脳の中を探検しているみたいで楽しい。

付箋を大きめの紙に貼り付けていって、分類が違うやらなにやらあーだこーだ付箋を移動しながら作り上げていくと、
ＰＣで作るのとは違うものが得られるかもかも。

読書術

「マインドマップ読書術」という本の著者でもある松山さんのことをTVでﾐﾀ。
スーパーサラリーマンと呼ばれている方みたいで、とある会社の部長さんらしい。
（朝5:00ごろの始発にて出勤 ～ 17:30に仕事終了）

往復の通勤時間（3時間20分）の間に１冊を読み終え、その書評を自分のメルマガで発行してるんだって。
驚くべきことに365日発行しているらしい（＾＾；
１日１冊読破するだけでも凄いと思うのに、メルマガ発行とは…凄すぎます。

やっぱ やってみるまでわかんねぇって

「サービスウェア」の項が個人的に秀逸だと思う。
理想といえば理想だけど、決してできないわけではない点に力を感じる。

Read more!
サービスウェア
2006年10月25日、2:21:09 相馬純平

見積もりは果たして当たるのだろうか？使ったことのある技術で、経験のあるクライアントとビジネスであればかなりの高確率で見積もりを的中させることは可能だろう。

もし2年後新しい技術やフレームワークが登場し、新しいビジネスの案件が出てきたら見積もりは当たるだろうか？答えは「解らない」である。「やってみるまでわかりません」と答える他無い。そして、次が今作ってるソフトウェアは果たしてクライアントの商売の利益になるのだろうか？答えは「解らない」である。「やってみるまでわかりません」と答える他無い。

全世界で「見積もりしろ」「やってみるまでわかりません」という押し問答が繰り返されている。

エンジニアリングの世界ではソフトウェアの見積もりを行うために様々な理論や方法論が考案されてきた。しかし、未だかつて完璧だと世の中が認める何かは存在していない。

なぜ見積もりが正確に当たらないのだろうか？それはそんな方法は世の中に存在しないからである。

そんな方法が世の中に無いにも関わらず強引に見積もりをして、または、強引に見積もりをさせて、外れるとほとんどの場合は現場が残業をしたり、責任を取らされる羽目にある。果たして今から開発するシステムが爆発的な収益を上げることが可能だろうか見積もれと言われて、見積もれるとしたらそれは未来人くらいだろう。それと同じく、ソフトウェア開発の見積もりをしろと言われても、一体どんな作業が発生するのか？どのくらい調査にかかるのか？アルゴリズムの問題点に気がつくのにどのくらいかかるのかなんて、正確にわかるはずはない。

何を作ったらよいのか？
どのように作ったらよいのか？

この2点はやってみるまで解らないので見積もりはムリである。

ではそもそもなぜ不可能である見積もりをさせるのだろうか？それはソフトウェアというモノをどのような仕様かを決定し、それを作るというモノづくり的な考えでシステムが作られるからである。モノ作りにおいて見積もりは絶対である。例えば建築物とか・・・

では、システムは本当にモノなのだろうか？実はシステムという名のソフトウェアはモノではなく、サービスなのである。サービスというのは、需要があり、それを管理運用する組織が存続する限り延々と存在する。だから、サービスの完成を見積もることはできない。

サービスの完成を見積もる　という言葉はおかしい。システムをサービスと考えるならば、明らかにモノでは無いから見積もるという行為自体がミスマッチなのである。資本主義社会においては、サービスの進化が停止するときは、そのサービスに対する需要が無いことを意味する。したがってシステム開発も終了する。このようなシステムを表現するソフトウェアをサービスウェアとここに命名する。

モノという概念ではないサービスウェアに対する要求は刻一刻と変化する。しかし、何が市場から歓迎されるのか最初から知ることはできない。だからといって何もしないわけではない。まず作る。そして市場に投入したら効果測定を行い、更なる要求を得るといフェーズが絶対条件となる。

モノとしてあらわされていたソフトウェアは、最初に要求を確実にしようと考えるため、効果測定はあまり重要ではない。それどころか、効果測定をした結果、使われないと失敗プロジェクトとなり、投資してきた全てはごみとなる。一方で、サービスウェアは効果測定からの要求の精緻化が必要不可欠なのである。そして、新たな要求が実装され続ける。

システムの進化の速度(T1)にビジネスの進化の速度はあわされてしまう。そしてビジネスにおける投資対収益率(T2)は効果測定からの要求開発の精度とT1に合わされる。

ROI = ( T2/T1 - OE ) / I

ROI=投資収益率
T2=要求に対する経済的効果
T1=開発に要する期間
OE=要求の実現にかかる費用
I=何もしなくてもかかる費用

この2つのカオスが2次的に作用するサービスウェアの世界において、見積もりや計画が入り込む余地など存在しない。

今までソフトウェア開発計画を軸に置き、ソフトウェアを開発するという考え方が一般的だったため、あまり気が点かなかったかもしれないが、システムの成長速度を軸にして開発計画を従わせるならば、おそらく無駄が0になる。

それと同様に過剰に作りこむ前に市場の反応に合わせて価値を作りこむモデルでは無駄な要求を実装するムダはほぼ0になる。

日々刻々と要求が反映され続けるシステムに対し、経営的判断でリリースを決定すること事体が経営行為となる。これは開発という不確実性に抵抗するのではなく、従うべきという発想である。

開発者に対して目標は設定するが、それが守られなくてもその自然の法則に逆らってはならない。サービスウェアを健全に永続的に進化させたいなら、この進化の鼓動をコントロールしようとなんて考えてはいけない。さもなくば成長の鼓動は停止し、市場競争力を失ってしまう。計画という軸にサービスウェアの進化の速度を従わせるという考えは捨て去るべきである。サービスウェアの進化の速度に全てを従属させることが長期に渡って成長し続けるシステムを維持する、つまり経営し続けることに必要不可欠なのである。

サービスウェアを健全に長期に渡って成長させ続けるためには下記の条件が必須となる。

テストが自動化され、テスト工数が指数関数的に増大することを防ぐ仕組みが入っていること。

ソフトウェアの責任範囲がインタフェースやアスペクトによって分断されていること。
常に何かしらの価値が提供される状態が維持されていること。

これらが守られるにはコードは組織内で共有され、修正前にはリファクタリングされ(当然自動化テストが実行可能)、誤解の無いわかりやすい名前が付けられ、ユーザインタフェースの実装が限りなく減らされ、画面同士の状態依存が限りなく無い設計が検討されなければならない。

そしてこれらのモラルが疲労や眠気などから破られないよう、最適ペースで作業は進められなければならない。サービスウェアの考え方において開発速度は非常に重要な競争力を持つ。コードで表現できることと同じ事をドキュメント化することは意味が無い。

そしてこの考え方は何も何かのサービスを開発するということに限らない。今までソフトウェアで表現されていたモノのほとんどは実はサービスウェアに当てはまる。行政のシステムはその国家が繁栄し続ける間進化する。ハードに組み込まれるソフトもハードの進化に伴い進化する。たとえプラットフォームが変更されたとしても、何を表現すればよいかという概念は知識を通じて進化し続けるのである。

経営行為が続く間サービスウェアは進化し続ける。つまり開発が終了するということは経営行為が止まるということを意味する。

米MS：「IE7」用アドオン開発コンテストを開催

どうやって作るんだろ

ハンゲーム - スタイリッシュアクションＲＰＧ「アラド戦記」

経験地が手に入るMAPへの冒険回数が制限されており、過度なLV上げができない仕組みになっている。

＠nifty:@search:瞬！ワード

http://www.nifty.com/search/shun/index.htm

現在webで検索されているキーワードのランキング。

ひらめきの素

物体や動画を見ているときに、自分の予想していなかった形状変化をすると
脳が活性化され、ひらめきが起こりやすくなるらしい。

「かわいい」「綺麗」「かっこいい」

「かわいい」「綺麗」「かっこいい」と思うものを見ることは、脳にとっては美味しい食事をしていることと同じらしい。