百発百中

あらためてWPFでアプリケーションを作っていくと、 ところどころWindowsFormとは異なる箇所を見つける。 DoEventsがない WPF 上の Application.DoEvents はどこにありますか？ [P10] WPF 体制下における Application.DoEvents() メソッドの代替手段 FileOpenDialogなどはFormのまま [C#] WPFで[ファイルを開]くコモンダイアログを使用する 本質的にFormとどう異なっているのかとか、 そういった特徴を知らないまま、 なんとなく使っているからよくわからないのだろう。 今後の課題の一つです。

6/12(水) 19:00-21:00 PeceptualComputingに参加してきました。 当日Creative＊InteractiveGestureCameraの保持者が0名だったこともそうだし、 開発のための環境などを考えても、 Kinectに比べるとまだまだなと言う気がした。 とは言え、 ハードを持っていないとソフトを作っても提供できない壁を、 UltraBookという前提で超えられるのは大きいとも思った。 でも結局全員には提供できないが。 以下メモ。 ■PerceputualComputingDeveloperセミナー東京 プレゼンターが中村薫さんだった。 環境はVS2012でも、VS2010でもOKとのこと。 当日はVS2012前提だった。 （セミナー会場でインストールしたら、1時間以上かかった・・・、まいったまいった） セミナー内アンケート Kinect知らない人0名 LeapMotion知ってる人50% LeapMotion持ってる人0名 Creative＊InteractiveGestureCamera持ってる人0名 InterPerceptualComputingSDK概要 2013年3月に正式版SDKリリース Creative＊InteractiveGestureCamera　が　UltraBookに標準装備される Sensor Kinectに比べるとかなり小さい IR Depth Sensor 15㎝～100cm （かなり狭い範囲で対応できている印象） VirtualPlane 12インチ（30cm）のところに、センサーの認識箇所がある。 　　一度そこに手をもっていかないと、認識しないときがある。 ■Source UtilPipelineを拡張してCodingすることになる。 イベントドリブンのKinectと同じらしい。 Enablexxで各機能を有効にする。 これもKinectと同じだな。 vitual bool OneNewFrame(void) このOneNewFrameをOverrideしておくと、 Frameが更新されたときに、このイベントが起動される。 つまりここが起点になる。 画像表示の方法だけど、 全体的にKin

良いコードを書く技術　－読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus) 著者 : 縣俊貴 技術評論社 発売日 : 2011-04-09 ブクログでレビューを見る» 新しい発見もあるし、間違っていたとわかることもあるし、 あっていることはあっていると再認識できる。 特に良い仕事をしたい普通のプログラマにとって、 非常に有用な本だと思いました。 この本を読んで、コード書いて、 他の本読んで、コード書いて、 人のコード読んで、コード書いて、 この本を読み直したら、良いコードが書けるようになると思う。 まずは目指せ、達人を目指す中級プログラマ、かな。

6/8（土）に 第1回 Build Insider OFFLINE に参加してきた。 飲食の供給が無料という非常に太っ腹なセミナーだった。 もちろんセミナー自体も無料なのに太っ腹なセミナーだった。 次回もあるならまた必ず参加したいものだ。 4つ参加してきた講演うち特によかった2つを、 以下箇条書きでそれぞれの講演のメモとか感想とかをつらつらと書きます。 ■よりよい開発を目指すための、プロセス＆ツール活用 ※TFSはTFServerで、TFServiceはTeamFoundationServiceと記載しています。 Kinectの本を何冊か出版されている中村薫さんのセミナー。  今日はKinectの話はでなかったが。  一度ご本人を拝ませて頂きと思っていたが、やっと拝見できました。  Blogはもとより、Kinectの本も非常に利用させて頂いております。 セミナー内アンケート TFS知ってる　→　9割 TFS使ってる　→　3割 Scrum知らない　→　2人 TFServiceを知っている　→　5割 結論 状況、環境によって、プロセスツールを使い分ける そのためにはプロセス、ツールの特徴を知る必要がある 使いこなせる武器を複数持つこと 道具の変化 今もTFS、github、Jenkinsを使っているとのこと TeamFoundatuionService バージョンコントロール 作業項目 自動ビルド環境 テスト環境 　→　テストをサポートしているツールは少ないが、TFSなら可能 今年価格の発表がある、らしい 実は3週間に1回更新が入って、機能が増えている TeamFoundationServer2012 pros 割愛 cons 環境構築、運用が手間 Windows環境以外のビルドは難しい リリースのイノベーション 例えばTeamFoundationServiceは3週間に1回リリースされている TFSだって、3か月に一回Updateされている どこだってやろうと思えばできるはずで、やらないといけない時代に来ている TFServiceではもう使えます 分散バージョン管理ができるようになった、らしい いずれT

6/6（木）に DBエンジニアのための技術勉強会 に参加してきた。 やっぱり外に出て、勉強会に参加することがすごく大事だなと思った。 講演するような人は非常に知識も豊富だし、話もおもしろい。 すごく勉強しているし、本も読んでいるな～。 以下箇条書きでそれぞれの講演のメモとか感想とかをつらつらと書きます。 ■SQLアンチパターン SQLアンチパターンの本の紹介だった。 読んだことあるか持ってる人が会場で3割程度だった。 これは多いのか少ないのか・・・多いか。 他人の失敗を学ぶことで、自分の失敗を回避することを目的にした本 各アンチパターンの紹介 各アンチパターンには名前がついている これが結構重要で、名前がついていることで、 知識の共有が簡単にできるようになる。 これはこの講演内でも何回か出てきた、一つのキーワード。 最初はふーんと思っていたけど、たしかに知識を共有するってコストは高い。 それを考えると難しいことを一言で理解しあえるのは大きいと感じた。 これは他のことにも言えるだろうな。 全てのアンチパターンが、目的、解決策などを含む定型フォーマットで書かれている、らしい。 この定型になっているのも、知識を共有する上で大切。 Wiki作るにしてもある程度のフォーマットはあったほうがいいんだろうなと思った。 論理設計、物理設計、SQL、アプリケーションに分かれている。 各詳細は割愛。 ■やはりデータ設計は大切です データ設計の設計目標 全然意識していなかったけど、当然設計にも目標がある。 なんとなくやっているってことは恐ろしいと思った。 業務忠実と　　 ユーザ業務、要求事項を忠実に理解し、データ構造に表現すること。 忠実な理解とは、業務の目的、意味などが正確になっていること。 データ品質を目的に 業務忠実を検証しやすいこと 専門家とは、駄目なもんはダメと言えること　 あの機能もこの機能も入れたいし、性能は出したいし、品質は良くしたいし、 スケジュールは短いほうがいいし、お金も安いほうがいいし。 ちゃんと見切ってあげることが大切だと思う。 マーチンファウラーは両方とものセミナーに共通して出てきた。 やっぱり偉人だな。 本はアナリシスパターンだったが、読ん

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化 David Farley アスキー・メディアワークス 発売日：2012-03-14 ブクログでレビューを見る» 顧客に価値を届けるということは、 本番環境にソフトウェアをリリースし、 サービスが稼動しているということ。 つまり手前の状態では価値は無い。 価値を測る基準はリリースまでの期間となる。 もちろんミスやバグは許されない。 品質の高いものをリリースする必要がある。 品質を作りこみ、リリースまでの期間を短くするために、 ビルド・テスト・デプロイメントを自動化する。 当然最初の自動化するために痛みを伴うことになる。 自分たちはどこまでできているのだろうか？ 皆さんの構成管理およびリリース管理の成熟度モデル（P.487）は、 レベルいくつですか？ （以下抜粋。○：完全抜粋、●：簡略抜粋） ○ケントが率いる統率されたチームには興味深い特徴がいくつもあったが、 　そのひとつがソフトウェアを毎晩本番にデプロイしているという事実だった。（P.22） ●アンチパターン：ソフトウェアを手作業でデプロイする（P.41） 　・広範囲にわたる詳細な手順書を作成し、リリースに必要なステップを記述する。 　　また考えられる間違いについても記述する。 　・アプリケーションが正しく動作していることを確認するために、 　　手動テストに頼る。 　・リリース当日にデプロイメントがうまくいかず、 　　その理由を開発チームに対して頻繁に問い合わせる。 　 ○大きな組織では、デリバリープロセスは別々のグループに分類されている。 　たとえば、データベース管理者、運用担当者、テスターなどだ。 　こうしたサイロをまたいで協力しあうコストは膨大で、 　申請書地獄のせいでリリースが遅くなってしまう。 　このような場合、開発者やテスターそれに運用担当者はデプロイメントを行うときに、 　常に申請書を提出しあうことになる（あるいはメールを送りあうことになる）。（P.45） ○ストレスを軽減するための鍵はこれまで説明してきた 　ある種の自動デプロイメントプロセスを準備することだ。 　そしてそのプロセスをこまめ