はてなブックマーク

ちなみに今回は面倒なので MainWindow.xaml は名前空間 TimeInputSample から移動してません。本当はこれも TimeInputSample.View の配下に移動すべきなんでしょうが…。 で、「最終的に」と書きましたが、何でかというと、この最終形態はあくまで実際に動いているところを見せるための使用例に過ぎず、今回のトピックのメインはあくまで時刻入力コントロールの実装方法だからです。 時刻入力コントロールの実装 XAML まず、プロジェクト上にユーザーコントロールを新規追加すると、デフォルトでは <UserControl> 要素に d:DesignHeight やら d:DesignWidth やらとありますが、これらは WYSIWYG エディタ上での表示の大きさが設定できるだけみたいです。固定サイズのウィンドウやコントロールに対して WYSIWYG 操作で編集す

(投稿直後に追記: この問題は既に解決しております…) ご無沙汰しております…。決算期が近づいて参りましたね。今期はほとんど売上立ってませんが… orz それはさておき、新しい仕事で使うことになりそうな技術の調査がてらプロトタイプ作りを進めようとしているのですが、HTML5 のインライン SVG を DOM から操作する際、 ID から要素を参照してその写像を表示する <use> 要素の扱いについて疑問点があったので、ちょっとメモしておくことに。 <use> エレメントについてはW3C の仕様勧告にサンプルがあるのですが (インライン SVG として簡略化して書くと以下のような感じ)、 <svg width="10cm" height="3cm" viewBox="0 0 100 30"> <defs> <rect id="MyRect" width="60" height="10"/>

文字列リテラルではさらに u8 という接頭子も使えます。 u8"Copyright \u00a9 2011 Harapeko, Inc." // \u00a9 は UTF-8 のオクテット列 [C2 A9] に変換される u"\U0002000bは「丈」の字にクリソツ" // \U0002000b は UTF-16 の該当するサロゲートペアに変換される…ハズ 対応関係の表は、…面倒くさいからもういいか。 あとさらっと流しちゃいましたが、 Unicode 用のエスケープ文字も追加されました。\uNNNN は 16bits の、 \UNNNNNNNN は 32bits の UCS を表現できます。上記の例のように、適切な文字列リテラル内で使用すれば、対応する文字セットの数値列に適宜変換されるはずです。この辺の説明はドラフトの 2.3 にありますが、以下の説明の通り、あくまで UCS の文字値を

あけましておめでとうございます。またしてもブログがおざなりになってしまいました… orz 直接お金になる仕事ではないのですが、ここしばらく、某所の BBS を開発するため、 Perl をいじっております。正直、 .NET や JavaScript 、ケータイアプリの開発なんてことばかりやっておりますと、たまにいじる Perl が楽しくて楽しくて、ついついこっちばかりやってしまう、という日々がしばらく続いております。いかんですな。 で、こちらの開発がとりあえずキリの良いところまで進んだので、一旦お蔵入りにしようと思うのですが (といっても年単位で寝かせるわけではないですが)、その前にこれに関連する技術的なメモをしたためておこうかと思うのであります。 作っているのは、さくらの共有レンタルサーバーサービス上で動作する CGI なのですが、レンタルサーバの性質上、 CPAN から最新のモジュールを

会社サーバー絡みで最近行った設定に関するメモです。 サーバー全体の動作が重くなるのをどうにかする さくらの VPS を利用するようになってから、サーバー全体の動作が重いのが気になっていました。結論から言うと、 Apache がメモリーを食いつぶし、スワップを引き起こしまくっていたからでした。 Trac のページやこのブログ、会社のトップページでさえ、表示するのにやたらと時間がかかるので、 ssh で接続して状況を見ようとすると、その ssh での応答も非常に時間がかかるという状態。まさかこれが単体の専用サーバーと VPS の差だとは到底思えなかったので、 ps -AF するなり top するなりして軽く状況を見てみると、メモリーどころかスワップ領域もほぼフル回転で httpd が食いつぶしていた。こりゃああかんと言うことで、ネットで調べつつ設定を修正…。 起動するプロセスの数を減らす とり

メインマシンではなくノートパソコンの方にも MinGW を入れていたはずなのですが、何故か msys.bat が消えていたりとなんだかいろいろと崩壊していたので、この際だからと最新の物をインストールすることにしました。 ところが、MinGW のダウンロードサイトにて「Download Now!」と書かれたリンクボタンをクリックすると、インストーラの exe ファイルではなく、何故か zip ファイルがダウンロードされ、展開すると謎のディレクトリ構成が…。 試しに生成された bin ディレクトリ下の mingw-get.exe ファイルをダブルクリックしてみますが、一瞬コマンドプロンプトが表示されるだけで、何も行われません。こいつはいったい何なのか? ぐぐってみたところ、MinGW ポータルの Getting Started ページに行き当たりました。どうやら、上記で落としてきたファイルを

まず文字セットですが、 UTF-16LE とはリトルエンディアンの UTF-16 エンコードのことで、 Unicode を表現するためのファイル形式です。ファイル形式であるということは、すなわちファイルに保存する方法を定めた形式であるということです。それに対して、 UCS4 はあくまで Unicode そのものであり、内部データ形式として扱えるものです。 具体的に何が違うのかというと、 UTF-16 の場合は配列内の数値 1つが必ず 1文字を表現するものであることを保証しません。実際、UTF-16 ではサロゲートペアを気にする必要があり、この処理を誤ると文字境界に破綻を来して文字化けの原因を作ってしまうことになります。これに対し、 UCS4 の場合は単に 31bits 以下の文字セットであり、それより拡張されないことが保証されています (万一拡張された場合は新たに UCS8 が規定されて包

Boost ライブラリの Ubuntu へのインストールは容易でした。単に libboost-dev パッケージを aptitude install してあげるだけです。 問題は、前回も書いた通り、 apt からインストールできる Boost のバージョンは通常で 1.34.1、最新のものを選んでも 1.37.0 になってしまう、ということです。 そこで、 otoco の開発に影響する範囲で、バージョン間にどの程度の差異があるのか、調べておくことにしました。 Boost ライブラリ – バージョン間の差意について とりあえず今思いつくのは正規表現まわりだけだったのでまだそこしか調べていないのですが (空文字列マッチは何気に影響範囲大きそうですが…古いバージョンで統一しておけばとりあえず問題にはならないかな…)、実際に開発が進めば利用範囲が広がり、都度気づく部分も増えていくかもしれません。上

はじめに 自社開発で作ろうとしていた物が実は mod_perl に対応した Web アプリなのですが、そういえば mod_perl ってまともに弄ったこと無かったなぁとか思ったので、風邪も引いて頭も回らないことだし少し脱線するかとばかりに遊んでみました。 世間一般においてはちっともはやらない mod_perl 。かろうじて拾う話題もせいぜい Apache::Registry を用いた既存 CGI の高速化とかその程度の話で、本格的に Perl で Apache モジュールを作ろうみたいな話になると本を買うか英語で情報を探すしかなかったりするのが現状のようです (あるいはおいらの探し方が悪いのかも知れませんが…)。参考にしたのは mod_perl の公式サイトにあるドキュメントでした。 mod_perl: mod_perl 2.0 Documentation これ全体をぼえ～っと眺めてみても

とりあえず、このサーバーを立てる (建てる? どっちの方が正しいんだろう?) に際して行った作業や費用などについて、ここでまとめておこうかと思います。今回は、サーバーのレンタルと、ドメインの取得および設定についてです。 サーバーを借りる 今回借りたのは、ファーストサーバさんとこの、デルタ1・シリーズというやつです。このサービスは、ソフトバンクIDC のデータセンターに置かれたそこそこのスペックのマシン (Celeron420 1.6GHz / 512MB RAM / 80GB HDD) をまるまる一台自由に使わせてもらえるというものです。但し、マシンは CentOS (後になって FreeBSD のコースもできたようですが) をインストールしただけの (そして ssh 以外のサービスを一通り停止させた) 状態で納品され、設定用の特別なツール (Web から操作できるコントロールパネルとか)