猿頁

先日から使い始めてみました、Microsoft Bluetooth Mobile Keyboard 6000。

周囲部が小さめで、フルキーとテンキーが分離した作りになっているので、机が広く使えます。
また、Microsoft Keyboard 中で最薄と謳うだけあり、キーストロークが浅いので、大量の打鍵がスムースに行えます。キータッチもなかなかキモチイイ感じです。

そんなこんなでただいまなかなかのお気に入り、コーディングに文章書きに楽しく使わせていただいておるわけですが。あんまり使ってて楽しいので、自宅のも仕事場のもこれで統一しちゃったわけですが。

先日、自宅のマシン前でゼリー食ってたら、シロップがはねて、キーボードにちょっとかかってしまいました。
こりゃいかん、とあわててティッシュで拭いたんですが、どうも翌日あたりから調子がおかしくなってしまいました。

なんとなくシロップを飛ばしたあたりのキーが固い。他のキーより強く押し込まないとキーが下がってくれず、押し込んだ時の感触も若干ぬるり、とした感じです。
だばだばと打ち込んでいると、そのキーだけ押し込み切れずに、文章入力に失敗してしまい安くなってしまいました。接触自体ができなくなっているわけではないんですがストロークのタッチが違うので、どうもキモチヨロシクない。

ということで、キーを外して掃除してみることにしました。

全文表示 »

ぼく、オタリーマン。という漫画がありまして。
先日 4 巻を読んでいたら、

今の若いのは VB なんか知らないから

というエピソードがあったわけです。

そっかー、もう今の若いのは VB  なんか知らないんだー。と、ちょっと寂しくなりましたよ。

いやそんなことないよ、VBだってまだまだ魅力的だよ、と言おうと思ったんですが。

全文表示 »

本 blog 「猿頁」は、WordPress システムを使って運用しています。
のでエントリの投稿は WordPress のオンラインエディタに Dean’s FCKEditor カマして書いているわけですが。

一応ひと通りのことはできますが、やはりオンラインサービスならではのもっさり感はぬぐえません。
Web ページでの作業特有の制限や使いにくさもありますし。
ということで、ローカルでエントリの作成ができるツールはないものかと探してみました。

Writer - Windows Live

全文表示 »

MS IME を超えてツカいものになるかどうか、ただいま絶賛お試し中の Google 日本語入力。

使い込もうとしてちょいと困ったのが、カスタマイズ性の低さ。
というか、正確には カスタマイズに関する情報の少なさ。もっと言っちゃうと、そもそも何ができて何ができないのかの情報自体が少ないんです。

あまたの紹介ページでは辞書の語彙数や変換時の候補の表示状況ばかりがクローズアップされていますが、私にとって大切なのは、トータルとしての文章作成時の生産性です。

つことで、キー設定の情報を吸い出して、どんな機能が設定できるのか≒どんな機能が用意されているのかをあぶり出してみることにしました。

全文表示 »

着々と使い込んでおりますGoogle Chrome。
いろいろとまだアマいところもありますが、今のところクリティカルなバグはありませんし、操作に対する反応の小気味よさにはなかなかの手放せない感を日々感じているわけですね。

さて。

これで一体何度目だというメインブラウザの乗り換えですが、いい加減ブックマークとか移行するのに飽きてきました。
今後もまた乗り換えることもあろうかと思うと、めんどくささもひとしおで。
また、私は仕事上の調べ物を自宅ですることも多いので、自宅でメモしといたサイトを仕事場でもう一度閲覧するためにメモったりメールで送ったりするのもめんどくさく。

つことで、この際もーメインのブックマークを Google ブックマークにしてみることにしました。

全文表示 »

なんだかんだいって Sleipnir を使い続けているさるべーじですこんばんは。
だって他の発展途上ブラウザよりもかゆいところに手が届きやすいですし、いくつか自作のスクリプトもカマして便利な小技効かしていたりするもので。他のブラウザに乗り換えるのは私にとってはまだまだ現実的ではなく。

とはいいながら。
なんだか最近、お気に入りリストから Web ページを開くと、ロードの途中で一度真っ白になり、リロードがかかるようになりました。
重いページなどを見ようとした時に約 2 倍の時間がかかるのはイタいです。ざくざくいろんなページを読みたいような場合は、けっこうイラッと来ます。
IE や他のブラウザではそんな動作にはならないんですが。

しかし、原因も対処もよくわからず。我慢して使っておったわけですよ。

で、先日、どうもこのへんが原因なんではないかと思うようになってきました。

タブブラウザ Sleipnir オンラインデータベース(テスト版バグトラッキング/60)

あまり歯切れのいい結論になっていないのがちょっとアレですが、どうやら

個別設定したお気に入りのエンコーディングと実際のページのエンコードが異なる場合に再読み込みをかける

という動作を行っているようなんですね。

全文表示 »

先日、自宅のメインマシンの CPU を Core2Duo E7400(2.8GHz) → Core2Quad Q9400(2.66GHz)に交換しました。
マザーボードやメモリもまるまるとっ替えたので、そのへんのパーツがマシン 1 台分浮いてしまったんですね。

そいえば Web サーバは Celeron 420(1.6GHz)・メモリ 1GB だったよなー。
交換したら少しは速くなるかしら。

ということで、CPU とメモリを交換してみることにしました。

全文表示 »

データベースの設計を完了させてからプログラムの設計へ進みなさい、とはよく言われることではあるんですが。

実際には、ユーザー要望の変更や追加・削除、連携している外部システムからのインターフェイス変更、旧システムからのしがらみやデータ移行時等に判明する驚愕の新事実、関連法規の改正等々ありまして、とてもじゃありませんがそんな理想論につきあっちゃいられません。

データベースの構造は常に変わり得るんです。
それを前提に設計・製造、運用開始後のメンテナンスまで含めて考えていかにゃならんのです。
完全内製で周囲のしがらみに一切影響されない、ってんなら理想論を通せる可能性もあるかもしれませんが。

ではそんなこんなで DB 構造の一部が変わっちゃった時に、データセットデザイナで作ったテーブルアダプタ等はどうなってしまうのか。

気になりませんか私は気になります。

ということで、そのへんを調べてみました。

全文表示 »

データセットデザイナの反応が遅い、とお嘆きのあなた。

そりゃまあ、何か操作をするたびに DB サーバに確認に行ったり取得に行ったりするわけですから、ある程度時間がかかってしまうのはやむを得ないとして。
でも数秒～数十秒、ヘタすると数十分待たされてしまうのでは、とても実用的とは言えません。

ということで、データセットデザイナの反応を劇的に上げるチューニングをお話ししてみたいと思います。

…劇的、はちょっとハッタリかもしれませんすいません。

全文表示 »

データセットデザイナは、作業中、頻繁に DB サーバとやり取りをします。
これは、その DB サーバに登録されている Table やView 等の情報を取得してるんですね。

ので、テーブル設計書とか参照しながらコツコツと文字列で SQL 文を組む必要がなく、型や桁の設定ミスも防げ、簡単に高品質なアクセスロジックを組めるというスゴいメリットを持っているわけです。

が、当然これはあらかじめ DB サーバにそれなりの状況をあらかじめ構築しておくことが前提となっておりまして。
かつ、デザイナに DB サーバへアクセスできる設定を入れてやらなければならない、ということでもあります。

具体的には、デザイナを新規作成して右クリック → [追加] → [TableAdapter] で新規テーブルアダプタを作成するような場合、構成ウィザードの第一画面が

みたいな感じになります。
これは、「これからテーブルアダプタを作るにあたって、どの DB サーバから情報持ってくればいいっすか？」とウィザードが訊いてきているわけですね。
ここで指定した情報を 接続文字列 として保存し、後続の作業を始めていくわけですが。

気になるのはその次の画面で、

接続文字列をアプリケーション構成ファイルに保存しますか？

と訊いてくるんですが、保存したら/しなかったら、どんないいこと/悪いことがあるのかよくわかりません。

ということで、このへんをちょっと調べてみたいと思います。

全文表示 »