hirax.net::Keywords::「Microsoft」のブログ



2008-11-06[n年前へ]

Technology Preview of Ruby SDK for Microsoft 

 Technology Preview of Ruby SDK for Microsoft

2008-11-19[n年前へ]

Rubyで「シリアル通信スレッドクラス」を作る 

 Rubyで「(Rubyシリアル通信ライブラリ(Windows用)TEXCELL を使った)シリアル通信スレッドクラス」を作りました。ソースコードとサンプルはここに置いておきます。”Microsoft Windows VISTAではほとんど見捨てられているような”シリアルポートでの送受信をRubyでスレッドを使って行うクラスです。Queueにデータを突っ込めば「シリアル通信スレッドクラス」から自動的に送信されます。また、受信した文字列が「(指定した改行コードで)一行になるたびに」receiveイベントが呼ばれるので(また、その際にQueueを指定しておけば受信行が自動的にそのQueueに追加されていきます)、読み込みのタイミング・必要な情報がまだ途中までしか読み込まれていない場合などの処理を気にすることなく使いたい、と考えながら作ってみた「シリアル通信スレッドクラス」です。
 たとえば、COM3で受信した内容をコンソールに出力するだけであれば、このようなコードで動くはずです。

require 'comThread'
receiveComThread=ComThread.new({:icomno=>3})
receiveComThread.start({:receive=>true, 
        :receiveMonitor=>true})
sleep 60
receiveComThread.stop
 シリアル通信モニタプログラム(シリアルポート間で送受信されている内容を眺めるプログラム)も、多分10行くらいで書けると思います。チェックせずに書いてしまうと、こんな感じになると思います。
  require 'comThread'
  q=Queue.new
  receiveComThread=ComThread.new({:icomno=>3,:rq=>q})
  sendComThread=ComThread.new({:icomno=>4,:sq=>q})
  receiveComThread.start({:receive=>true,
    :receiveMonitor=>true})
  sendComThread.start({:send=>true})  
  sleep 60
  sendComThread.stop
  receiveComThread.stop

 以前、こんなことを書きました

 「計測・解析ソフトウェア/ハードウェアのハック」が実験系技術者の一番のLifeHackかもしれない…と思っています。その思いを逆に言うならば、実験系技術者が費やす多くの時間を、計測・解析処理が消費していると思っているからです。そして、一番時間を消費している部分の高速化をすることが、全体の高速化に効果的だろう、と思っているわけです。

 そんなこんなで、何を今更…という、Perlで「シリアル通信とユーザインターフェース自動制御」のやり方を整理しておくことにしました。なぜかというと、経験的に(既成機器をを使わざるえないことが多い)「計測・解析ソフトウェア/ハードウェアのハック」は、シリアル通信制御とユーザインターフェース自動制御でほとんどの場合対応できる、からです。
 というわけで、先週末はこの「Perlでシリアル通信とユーザインターフェース自動制御のやり方を整理しておくことにしました」の部分を「Rubyでシリアル通信とユーザインターフェース自動制御を書いて整理しておくことにしました」ということをしてみたわけです。この「シリアル通信クラス」と「ユーザインターフェース自動制御」があると、結構便利な実験屋さんもいるかもしれません。

2008-11-20[n年前へ]

Microsoft,ロボット用アプリ開発ツールの最新版「Robotics Developer Studio 2008」公開  

 Microsoft,ロボット用アプリ開発ツールの最新版「Robotics Developer Studio 2008」公開

2009-03-25[n年前へ]

エクセルのワークシート・サイズを広げて欲しい!? 

表計算ソフトであるMicrosoft Office Excel を使わざるをえない状況になった時、ワークシートのサイズ上限が小さくて困ることがある。あるいは、めんどくささを感じることがある。次に示すように、最近のバージョンでは、サイズ上限が広げられてはいるものの、それでも少ないと感じてしまう。

  • バージョン2007: 65536行(縦)×16384列(横)
  • バージョン97,2000,2002,2003: 65536行(縦)×256列(横)
 たとえば、横(列)が256=8bit 符号無し整数で表わされていると、2次元画像をエクセルで扱おうとした時に困ることになる。なぜなら、多くの測定器は(デフォルト設定では)1024×768という大きさのデータを出力することが多いからだ。だから、以前のエクセル、バージョンで言うと97,2000,2002,2003までのエクセルでは、2次元データの扱いを簡単に行うことができなかった。もちろん、画像データをエクセルで扱うわけがない・・・という実に的確な正論もあるだろうが、理想と現実は違うのが世の中というものである。だから、65536行(縦)×256列(横)では、困る人たちもいたわけである。

 では、バージョン2007以降、つまり、1048576(修正前:65536)行(縦)×16384列(横)であれば良いか、というと時系列データを扱うには、データ数が1048576(修正前:65536)行個では全然足りないということが多いと思う。たとえば、1nsごとにデータを取得したデータがあったとしたならば、1048576(修正前:65536)行個のデータはたった1.048576秒(修正前:0.065秒)に過ぎないのである。

 データ解析をするときには、「数は力」である。「力」というと誤解を生むかもしれないが、データは多くの量を扱えば扱うほど、とても素直な性質を見せてくるのは、事実である。

 エクセルをメインで使う人が(まだまだ)とても多いこの世の中、エクセルのワークシート・サイズをもっともっと広げて欲しい、と思う。

 (Ver.2007 行数の修正を行いました)

2009-03-27[n年前へ]

Google Chromeのフォントやグラフィックレンダリング機構 

 Google Chromeのフォントやグラフィックレンダリング機構

 グラフィックス描画エンジンも、独自ライブラリを使っている例だ。Google Chromeではテキスト以外のグラフィックのレンダリングには、2005年にグーグルが買収したSkiaという会社の同名のエンジンを使っている。なぜ、WindowsのGDIではないのか? ChromiumコミュニティのSkiaの解説ページには、その理由がいくつか書いてある。1つは、Windowsが提供するAPIのGDIが、SVGやCanvasの実装には機能が不十分であること。もう1 つは、マイクロソフトによるGDI+の開発が止まっていて、ほとんどのグラフィック操作でSkiaよりも遅いことを挙げている。



■Powered by yagm.net