読者です 読者をやめる 読者になる 読者になる

どこかのだれかへ

職業ゲームプログラマ。気になったニュースのピックアップや開発日記などを書いています。

Adornerを利用して、プレースホルダを表示する

プレースホルダって検索すると「(UIデザイン的に)プレースホルダは止めておけ」という記事があるけれど、それは気にせず実装してGithubにアップしたので紹介しておく。

GitHub - Tepp91/WPFSampleCollection
にPlaceholderサンプルを追加した。

プレースホルダはAdorner(MSDN:装飾の概要)を使用して実装している。 Adornerを利用することで、対象のコントロールにオーバーレイする形で描画することが可能だ。 MSDNのサンプルではOnRenderを利用しているが、今回はTextBlockを利用してプレースホルダを表示している。

実装して厄介だったのは、AdornerLayerの取得タイミングだ。

Adornerは直接対象コントロールに設定できず、対象コントロールのAdornerLayerに設定する仕組みとなっている。 今回はBehaivorで実装したので、最初はOnAttachメソッドのタイミングで生成しようとAdornerLayerを取得しようとしたが、このタイミングではnullが返ってきてしまった。

色々試して、最終的に対象コントロールのOnLoadメソッドのタイミングならうまく出来ることが分かったが、思わぬところで躓いてしまった。

Boseのイヤホンが壊れたら、直営店に持って行こう

今日Boseのイヤホンが壊れたので、直営店に持って行ったら、
その場に在庫があったので、すぐに有償交換することが出来た。

普段、作業するときはBoseノイズキャンセリングヘッドホンを使っている。
会社では、Quiet Comfort 20(イヤホン)、自宅ではQuiet Comfort 15(ヘッドホン)を使用している。

今日、会社で作業しようとイヤホンをしたら「ブツッ」というノイズが頻発、 さらに左耳側は低音がやけに響く。どうも断線系の故障っぽかった。

Boseのヘッドホンなどは保証期間後に故障した場合、新品と有償交換*1することが可能だ。 実はQC15のほうは一度壊れたことがあり、その際はサポートセンターに郵送して対応した。

とりあえずサポートセンターに電話したが、混んでいるのかまったく出る気配がない。
ググってみると、直営店から送ってもらうことも可能(むしろ郵送代もかからなくて楽ちん)らしく、 帰りにBoseの直営店に行ってきた。

表参道のBoseに行って話をしたところ、直営店から送ることも可能、 さらに今回は在庫があったためなんとその場で有償交換することが出来た (郵送すれば、きっと1週間はかかっていただろう)

Boseノイズキャンセリングは非情に高機能で、今は作業する上では欠かせないガジェットの1つだ。 正直、明日からイヤホンがなくて憂鬱だと思っていたところだったので、この対応は非情に嬉しく、Boseへの信頼が増した出来事だった。

*1:税込み15120円。本体のみで付属品はなし。また保証が1年付く。

開発ネタ:Excelのシートビュー

時間があったら作りたい。

会社の仕様書はExcelなのだが、たまにシート数がかなり多い場合がある。

既存の機能ではシートのすべてが常に一覧として表示されているわけがないので、
これを一覧できるアドオンがほしい。

データ自体は共有データなので、変更したくない。

ちゃんと探せば既存でありそうなものだが。

Doxygenで出力されるドキュメントを確認

家でC++のコードを書く時はコメントをDoxygenJavaDocスタイル)で書いている。

ふと普段書いているスタイルでちゃんとドキュメント化されるてるのかが気になったので、確認用にプロジェクトを作ってみた。

GitHub - Tepp91/TryDoxygen

P.S.

なんとなく開発用のTwitterアカウント作った。
@DevTepp

GitHubで見る注目すべきOSSなゲームエンジン

GitHubから「Discover interresting projects on GitHub」というメールが飛んできた。

内容はExploreページ(GitHub内の注目プロジェクトの紹介)へのリンクで、その中に「Game Engine」項目があったので興味がある人は見てみると良い。

Game Engines · GitHub

色々と面白そうなものがあるので、レビュー勉強会みたいのを会社でやると面白いかもなと思った。またはそういうオフ会があってもいいなと感じた。

気付いたら命名に1時間(CategoryかTypeか)

今日仕事でデータの命名に1時間かけてしまった。データの名前はあとで変更が出来ないので変数の命名なんかよりも数倍気を使う。

気を使うにしても1時間は使いすぎだろとは思うけれど、
この1時間の大半は「○○Category」か「○○Type」のどちらがよいか、というかそもそもCategoryとTypeってなにか違うかをずっと調べていた。

100件のほどのデータがあり、この中からとある種類によって処理を分ける必要があったので、データに識別用の情報を付加することにした。命名するときは既存のデータなどに合わせて命名することがベターな手法なひとつだが、既存のデータには「○○Category」「○○Type」がありどちらが良いのかが迷ってしまった。

英語のWebサイトなどを見て、色々調べた結果、個人的な理解としては以下のように落ちついた(まだ全然すっきりしていないけど)。

  • Categoryはグループ分けする際の括りで、入れ物という意味合いが強い。1つのデータが複数のCategoryにまたがることはない。

  • Typeは性質・特性であり、Categoryに分ける際の指針の一つとなりえる。Typeが違う場合、内部も大きく異なる可能性有り。1つのデータに複数のTypeが当てはまる場合もある(またはそれを1つのTypeとする)。

これが英語的に正しいかは知らない。分かりにくいのはCategoryはTypeで分けることもあるとうことだ。

英語のサイトに紹介されていた一つのチップスで「Categoryはinを使い、Typeはofを使うと考えるとうまく行く」というのがあり、これが大きなきっかけとなった。

実際の仕事では、結局Categoryを使うことにした。が、どちらかというと自然とこの識別データをCategoryと皆で呼んでいたので、それに合わせた感が強かったりする。

初級プログラマによくある「The XY Problem」とは

とある掲示板で「The XY Problem」という単語が目についた。
ぐぐってみるとあまり日本語ではヒットしないのだが、考えとしてはよくあるものだ。

The XY Probremは、端的に言えば、問題の本質を見失っている状態だ。

よくあるコピペがその良い例だ。

アメリカのNASAは、宇宙飛行士を最初に宇宙に送り込んだとき、無重力状態ではボールペンが書けないことを発見した。これではボールペンを持って行っても役に立たない。
 
NASAの科学者たちはこの問題に立ち向かうべく、10年の歳月と120億ドルの開発費をかけて研究を重ねた。
 
その結果ついに、無重力でも上下逆にしても水の中でも氷点下でも摂氏300度でも、どんな状況下でもどんな表面にでも書けるボールペンを開発した!!
 
一方ロシアは鉛筆を使った