検索

システム開発の現場においてTDDの導入に躓く原因は何か。
それはテストケースの実装と継続的な実施が技術的に難しく極めて属人性の高く、かつプロジェクト毎の独自色が強い為である事が一因と考えられる。

TDD(Test Driven Development)、あるいはテストファーストと呼ばれる開発手法は、まずテストコードを書き、実行させる。この時点では実装コードが無いか、あっても定義だけで中身のロジックは実装されていない為テストは失敗する(Red)。続いてテストを成功させる為のロジックを実装し、テストを成功させる(Green)。次に異なるテストパターン（テストケース）を作成し、実行させる(三点観測)。失敗すれば、中身のロジックを適宜修正しテストを成功させる(Refactoring)。
このサイクルを維持してシステムを構築していくのがTDD/テストファーストと呼ばれる開発手法であると、ここでは定義しておく。以降、TDDに表記を統一しておく。

TDDの良い点は、いつでも動作し、テストをパスするコードが書かれている事から品質向上が期待できる点である。また新機能の追加や既存機能の改修においても、適切なテストツール/ライブラリを用いる事で自動回帰テストの実施が可能になり、追加・修正したコードが原因で既存機能がおかしくなるバグを事前に検出・修正することを容易にする。
また人間的な側面からもメリットがある。新しくプロジェクトにアサインされた人間にとって、テストコード一式はそのシステムを理解する大きな助けとなる。ローカル環境でテストを実施できる仕組みになっていれば、気軽にシステムのコードを実行できるため、理解をさらに助ける事になる。

しかしこれらのメリットはTDDが継続して実施されている事が前提となる。システム開発当初だけTDDを実施し、保守フェーズではテストコードを触らず、テストコードによるテストの実施もしない場合、テストコードは実際の動作するコードを保証せず、よって品質向上にも寄与せず、システムの理解にも貢献しない。
TDDの恩恵を受けるには継続することが重要である。TDDのメリットは昨今喧伝されているにも関わらず、実際にシステム開発の現場で導入が進められているかというとそうでもない。それはTDDの導入の敷居の高さ(学習曲線)もあるし、継続することが難しいという現実もあるのではないか。

その原因として、TDDの継続的実施は極めて属人性の高い活動であると共に、実装面でプロジェクト毎に異なる部分が多く共通化によるコスト低減が難しい、その２点があると考えている。

ここで、これから議論する「システム開発」についてある程度明確化しておく。まずITシステムに関するシステム開発であり、請負開発である。発注者と受注者が存在する。新規システム構築、あるいは既存システムの改修案件とする。発注者側にもシステム開発要員が存在するが、保守フェーズ以降にそのシステムのコードを変更する。逆に受注者側のシステム開発者は納品以降はシステムのコードは変更しない。運用・保守契約は行わないか、行うにしても契約先は受注者とは異なるものとする。
既存システムの改修の場合、既存システムを開発したのは今回の受注者とは異なる場合もあり得るし、同じ場合もあり得るとする。同じ場合でも、実際に作業するシステム開発者まで同じ人間とは限らない。
またシステム開発の規模は問わない。ただし大凡のイメージとして、受注者側のシステム開発要員が二人以上から数十名規模までを想定する。

TDDの導入を考えるにあたり、まずTDDを適用する範囲を考える必要がある。ビジネスロジックまでか、UIは含めるか、UIの場合はWeb経由かプラットフォームのGUI経由か、他システムとの通信部分は含めるか。
まずこの時点で、TDD独特の技術的リスクやトレードオフの問題が発生する。UIを含めるとなるとUIのテストコードを書く為のライブラリの選定や、技術的にどこまでテストコードを書く事が出来るかの見定めが必要になってくる。更にUIのテストコードでDBの前提条件の調整なども必要となり、結果、テストコードを書く事自体のリスクやコストが高くなる。ビジネスロジックまでに抑えた場合はUI部分が無くなる為技術的なリスクや、テストコードの実装コストは低くなる。代わりにUI側のテストは従来と変わらない手動テストになってしまう。
他システムとの通信までテストに含める場合も、実際に他システムと通信する部分までテストするとなると、他システム側の事前条件の設定までテストコードで行う事になりかねず、そこまで実装できない場合も出てくる。
また実際の連携までは行わず、とりあえずデータをやり取りするインターフェイス部分だけに抽象化し、そこだけテストコードを記述する場合も、ソケットを使ったネットワーク通信などを使う場合にどうやってテストコードを書くのか、事前条件を実現するのか、という面で高い技術力が必要とされ、故に属人性も強まる。

TDDとはこれまで人間が手作業で行ってきた「事前条件の設定」と実行、そして「事後状態の検証」をプログラムにより行わせる事に他ならない。
従ってTDDを実施するには、テストパターン毎に異なる「事前条件の設定」を効率的に行えるようなライブラリの整備や、TDDの適用範囲に見合ったシステムのソースコードレベルでの構造（アーキテクチャ）を整備しておく事が必要である。
それにはデータベースの知識とオブジェクト指向の知識が必要であり、言語毎のオブジェクト指向プログラミングの実装のクセやバッドノウハウを掴んでおく事が必要となる。
さらに実際に開発し、テストコードが増えていく中でテストコード自体を整理し、事前条件の設定や事後状態の検証に関わる部分をプロジェクト単位で最適化する必要も出てくる。
いずれにせよ、全般的に高い技術力とTDDの継続実施の為の高いモチベーションが必要である。故に、属人性も強い。システム開発要員が2人以上の場合はTDDの実装を横方向に展開する事も必要であり、テストコードそれ自体のレビューやプロジェクトローカルに最適化された事前・事後用のライブラリの整備など負担が高くなる。
さてこうして開発側の属人性に支えられて構築されたシステムであるが、今回考えているシステム開発の形態では保守以降は発注者側のシステム開発要員しかソースコードを変更しない前提である。
発注者側も予めTDDについて高いモチベーションを有し、プロジェクトローカルに最適化された事前・事後用のテストコード専用のライブラリの扱いに長けていれば継続的なTDDの実施につながり、TDDのメリットを享受できる。
しかし発注者側がそうでない場合は、受注側でコストとリスクをかけて構築されたテストコードは保守されず、よって、TDDのメリットも享受できない。

まとめるとTDDの継続的な実施には高い技術力とTDD実施のモチベーションが必要であり、属人性が高くなる。従って組織を跨ぐシステム開発では継続的なTDDの実施は難しく、よってTDDのメリットは享受できない。

ここで、受注側の視点からテストコードについて考えてみる。テストコード、特に事前・事後用のライブラリ化された部分はプロジェクトローカルに最適化されている。再利用しづらいため、プロジェクト又は顧客単位での使い捨てになりやすいと予想される。すなわち、TDDの実施でコストとリスクがかけられるのはこの部分であるが、かけた分を回収しづらい事を意味する。TDDのメリットである品質向上についても数値化が難しい。
多数のTDD実施事例を積み重ねれば、それでも全体としてノウハウが蓄積され、かけたコストに見合うメリットが享受できる可能性はあるが、短期的にはTDD実施にかかるコストやリスクは、そのメリットを上回ってしまうだろう。
TDDの範囲もプロジェクト毎に当然異なり、TDD導入当初はプロジェクトローカルに最適化されたコードは汎用性を持たず、プロジェクト毎にゼロベースでの構築となるだろう。
また既存システムに対する改修の場合も、既存システム側のテストコードは存在するのか・無い場合は作成するかなどなどTDD固有の意志決定が発生する。

このようにプロジェクトローカルに最適化される性質は、TDDの導入事例が充分積み重ねられない限りはTDD導入にかけられたコストの回収を難しくするだろう。

以上見てきたように、受発注双方のシステム開発要員が納品を境に分断され、受注側として継続して同じシステムに携わる期間が短い場合、TDD導入にかけたコストの回収がプロジェクトローカルに最適化される性質から難しく、またTDD導入と継続実施に要する技術水準およびモチベーションの面から属人性が高くなりやすい。この２点が、TDDの導入が思うように進まない原因の一つであると考えられる。

TDDのメリットを得ようとするならば、属人性が高くとも問題ない環境である事と、プロジェクトローカルであっても問題ない環境である事が少なくとも必要条件となる。
技術力が高くTDDへの強いモチベーションを有する人材が長期にわたり、特定プロジェクトに参画し続ける場合は、この二つの問題は問題でなくなる為、充分にTDDのメリットを享受できると思われる。
属人性に問題はなくとも、プロジェクト毎に異なる最適化が必要になる場合は中心人物が疲弊する可能性がある。
プロジェクトローカルが問題にならない場合でも、技術力と高いモチベーションを有する人間が居なければそもそもTDDが始まらない。

TDDの継続実施は品質向上やシステム理解の面で効果のある手法だが、これまで見てきたように開発形態によっては属人性の高さとプロジェクトローカルな最適化問題により充分なメリットを得られない場合がある。雑誌やWeb記事の喧伝に振り回されず、自分の居る組織やプロジェクトの性質を勘案した上でTDDの導入と継続実施を図る事が今後重要になるだろう。

時々自分の葬式、どうしようかと考える時があり、「やっぱり墓は要らないし戒名も要らない、余計な儀式は抜きで散骨してお仕舞いにしてほしいな」と考えているのだけど、同じような考えが増えていたようだ。

• 痛いニュース(ﾉ∀`):「葬式はいらない」という人が急増…「誰にも迷惑かけずに消えてなくなりたい」
  • http://blog.livedoor.jp/dqnplus/archives/1310388.html
• 【直葬　～消える弔い～】（上）消えてしまいたい(産経新聞) - goo ニュース
  • http://news.goo.ne.jp/article/sankei/nation/m20090922003.html

現代の葬式は死者と生者の間で境界線を引く為のオマジナイの一種と自分は捉えている。
儒教的な部分や、日本古来の（どちらかというと神道寄りの）死生観とかが混ざった上に、江戸時代に広く庶民の間にまで浸透した「オマジナイ」の形式が、親戚・知人を一同に集めて戒名貰って埋めて貰った後も○回忌の毎に法要を執り行う、というスタイル（お作法）だと考えている。
まぁ、京極先生の完全な受け売りだけど（爆。↓↓

ただ「オマジナイ」もそれが意味を持つ時代や文化・風習の中でしか効果を発揮しない。ようするに8bitマイコン用に作られた実行コードを32bitWindows上で実行しようとしてもエラーになるのと一緒だ。あるいはPHP4ではXMLを扱うのにPEARの助けを借りる必要があったが、PHP5でsimplexmlが使えるようになったのでPEARのXML関連パッケージが不要になったのに似ている。PHP3ではセッション管理を自前で行う必要があったが(PHPLIBとか)、PHP4以降組み込みのsession関数が使えるようになるのとも似ている・・・ってちょっと違うか。
生者と死者の間で、生者側から一方的に境界線を引くのが「お金と手間のかかる」葬式であるとすると、もしも生者側が居ない場合、当事者は死者だけとなるので境界線を引く意味を持たない。

親しい知人・友人・家族が居ない、あるいはひどく遠方に住んでいたりしてつきあいが少ない、というような人間は、高齢・壮齢・若年関わらず増えていくとするならば、お金と手間のかかるお葬式は「境界を作るオマジナイ」としては意味を失うのでは無かろうか。
境界線をわざわざ引くのは、「けじめ」を付けるほどに生者が死者と精神的な関わりがあり、思いが強いからだろう。
逆に言えば、そこまで関わりが強くなく思いも薄い人達しか生者に居ないとすれば、わざわざけじめをつける必要は無くなる。境界線を引かずとも、死者は既に彼岸に居る事になる。

社会構成も文化も、もはや江戸時代/明治/大正/昭和初期/大戦中/経済復興期とは違ってしまっているのだから、これからもこの記事のように、かつての「オマジナイ」「お作法」「スタイル」が意味を失い、無効化するケースは増えていくだろう。

まぁでも、当然で自然の事なんだから後は自分はどうしようかという好みの問題になるだろうなぁ。

さしあたり、今の時点ではそうした葬式に関する簡略化要望は遺書にしたためておかないと、残された家族の周囲からの視線を考慮すると困るようだ。
いっそのこと「葬式よりもこれからの生きる人間の為に金を使え、もし葬式で10万円以上使ったら、『何故儂の言う事を無視した～』と末代まで祟ってやるぞ」くらいの遺言を残しておいた方がよいのかも知れない(w。

正確には読み終わってないんだけど、途中で放棄した（爆。

Amazonのレビューでも指摘されているが、誤植が多い上に索引が無い。
WindowsやLinuxでNASM/gas/gdbを使ったアセンブラプログラミングを始める良いきっかけ/手引きになる事は確かだが、少なくともC言語のポインタを理解していないと説明を追うのはキツイと思う。

放棄したのは、Linux上でのアセンブラの後半、バッファオーバーフローのexploits辺りでどうしてもshellcodeへの組み込みASMでのJMPでSegmentation faultが発生してしまい、今の自分では先に進めなくなった為。さらに後半にはWindows上でのアセンブラプログラミングの話も出てくるのだけれど、正直お腹一杯で食べきれなくなった。

他気になった点：

• C言語とアセンブラの境界部分が沢山出てくる。
  • →「C言語の文法を把握している」だけじゃ駄目で、オブジェクトファイルやリンカ等のレベルまで把握していないと振り回される。
  • →C言語のポインタとアセンブラ上でのメモリアドレスがどう関連するのかの説明が少ない。逆に言えばC言語のポインタをきっちり理解していないと、サンプルコードが理解できないかも知れない。
• 誤植が多い。サポートページに載っていない箇所もある。exploitsのshellcodeなど、"\x.."がなぜか"vx..."になってたりする箇所があった。
• スタックの説明が冗長
  • 230p(3章32ビットプログラミング, 数値カウントプログラム)でESPやEBPの挙動と絡めて丁寧に解説されているが、その後294p(3章32ビットプログラミング, スタック)でさらに簡略化されてもう一度説明がされている。
• "LEA"の説明が無い。
  • 読み間違いだったら御免なさい。でも、巻末付録のアセンブラ命令の一覧にも"leal"は出てこない。その割にはbbs.s辺りでいきなり使われてたりする。

と言う感じです。
他にも、いきなり

.globl main
main:
...

と出てきて、gccでコンパイルしてどうのこうのという進め方ですが・・・これ、絶対「え、".globl main"って何なの？なんでそれで、main以降が実行されるの？」って疑問に思いません？この辺りも、".globl main"はリンカから見えるシンボルで、こうする事でリンカがCの標準ライブラリが要求しているmain関数の呼び出しを解決できる、という予備知識がないとキツイと思います。まあ「おまじない」って言ってしまえばそうなんでしょうが、そもそも「おまじない」で済ませていた部分が見えてくるからこそアセンブラ言語に興味があるのであって・・・。

自分の場合は西田亙の「GNU DEVELOPMENT TOOLS」で一応、glibcを使わないhelloworldとかやっていたので、C言語とリンカとアセンブラの境目の予備知識があったので何とか流せました。
その辺を押さえておけば、逆にWindowsやLinux上でのアセンブラプログラミングを広く浅く取り扱っている有意義な書籍として読めると思います。

というかexploits周りのコードで

L2:
    call L1
    .string "/bin/sh"

っていきなり出てきて、さらにL1の方でいきなり

L1:
    popl %esi

と何の説明もなく書かれていたのにはかなり悩みました・・・。これ、L2側がcallなので、L1に来た時にはスタックの先頭にはL2のcallの次の命令、つまり"/bin/sh"の先頭アドレスが入ってる(".string"でそのまま"/bin/sh"が展開されている)。なので、それをpopしてESIレジスタにセットしてるんだねー、ということが分かったのはGDBで色々ダンプしてからの事でした・・・。

アセンブラのコードにコメントが入ってないのがキツイ。

文句ばっかりですみません・・・。

今更ながらお仕事で使うので、自宅のVMware上のCentOS5.xにも入れてみた。

• "CentOSにmemcacheをインストールする方法"
  • http://blog.veryposi.info/server/server-setup/centos-memcache-yum/
• "仙人の心得 » CentOS：memcachedをインストール"
  • http://blog.mktime.com/archive/55.html

で、試しにメモリサイズを8MB位まで縮小してmemcachedを起動し、以下のようなPHPで8MBを超えてsetさせてみた。

<?php
$cache = new Memcache;
$key = 'cache_test';
$cache->connect('localhost', 11211);
 
$data = str_repeat('A', 1024);
for ($i = 0; $i < 10; $i++) {
        for ($j = 0; $j < 1024; $j++) {
                $k = sprintf('cache_test_%d_%d', $i, $j);
                $r = $cache->set($k, $data, 0, 0);
                if (false === $r) {
                        echo "breaked at $i, $j\n";
                }
        }
}
$r = $cache->get('cache_test_0_0');
var_dump($r);

してみると、最後のget()がfalseになる。恐らく8MBを超えたsetが始まった辺りで、古いのから順に消されていったのだろう。

個人的にはmemcached自体よりは、それでソケット接続で使っているlibeventの方が気になった。
とりあえず以上。

今度の現場はSubversionをバリバリに使っている。自分もSVNは使っていたとはいえ、ぶっちゃけYakiBikiなど個人レベルでしか使っていないため、担当者毎のbranchをtrunkに統合したり、間違ってcommitしたのをrollbackしたりなどは行っていない。(rollbackだって、-r付でco下のをバックアップした後、最新版に上書きしてcommitするで済ませてた（;´Д｀）)

以下のまとめは、次のURLから当座必要な「trunkの変更をbranchにマージ(or その逆)」「commitしたファイルをロールバック」のやり方を抜き書きしたもの。

• "Subversion メモ"
  • http://www-aos.eps.s.u-tokyo.ac.jp/~takagi/subversion.html

trunkの変更をbranchにマージ

マージの基本：

svn merge -r <From>:<To> <マージ元> <作業コピーパス>

"<From>", "<To>"はリビジョン番号で、"<From>"から"<To>"の間に行われた "<マージ元>" に対する変更を "<作業コピーパス>" に対して適用する。<作業コピーパス>省略時は、カレントディレクトリに適用される。

例えば "file:///opt/SVNREPOS/repo1/trunk" 以下に行われた r100から最新版(HEAD)までの変更を、"repo1/branch/abc" をcheckoutして作業中のカレントディレクトリに対して適用するのであれば、

svn merge -r 100:HEAD file:///opt/SVNREPOS/repo1/trunk

となる。作業コピーパスはカレントディレクトリなので、省略している。

逆に、カレントの作業コピーがtrunkで、 repo1/branch/abc をマージしたい場合は

svn merge -r 100:HEAD file:///opt/SVNREPOS/repo1/branch/abc

となる。

commitしたファイルをロールバック

「未来から過去に向かっての変更点」をマージすると考える。
すると、例えば作業コピー中の foo.txt というファイルを間違ってcommitして、commitする前のバージョンに巻き戻したい場合は、以下のようにmergeコマンドを実行する。

svn merge -r COMMITTED:PREV foo.txt

「直前」などではなく、明確に「リビジョンXXX」に戻したいという場合は

svn merge -r HEAD:XXX foo.txt
or 
svn merge -r COMMITTED:XXX foo.txt

というようになる。

単純に以前のバージョンを見たいだけの場合(svn cat)

svn cat <対象>@<REV>

例：commitする前のバージョンを見たい

svn cat foo.txt@PREV
or
svn cat -r PREV foo.txt

新しい現場で用意されたキーボードがどうにも手に馴染まない。キーボードやマウス位であれば自分の好きなものを持ち込んで良かったので、今日、秋葉原のクレバリーまで行ってきてようやく指先が「吸い付く」キーボードを買ってきた。

現場のキーボードが馴染まなかったのは、「スペース」キーが短くて、丁度"V"と"B"の間くらいに収まっている。自分の場合「スペース」は右手の親指でタイプするため、これだとスペースを押そうとする度に右手親指をやや意識して伸ばさなければならない。それが原因か、今の現場に移って一週間後の週末は右手親指が何だか腱鞘炎にでもなったような感じだった。

今度買ってきたFKBN91Mは、次の写真のとおりスペースキーが右手方向にも伸びているので、問題ない。キータッチについても、パンタグラフに馴染んだ手にも違和感ない。こういった「高級」っぽいキーボード（実際値も張るのだけど）の場合、キーを押した時の機械音も結構大きいと思っていたが、それほどでもない。「カチカチ」という音だと気になってしまうが、「パコパコ」という感じなので自分としては平気。

ELECOMのTK-UP289のキー配列はネ申

自分はPCの経歴がノートPCから始まっている為、どうしてもパンタグラフタイプのキーボードが手に馴染んでしまう。自宅で使っているのは今は製造が終わってしまったELECOMのTK-UP289である。

パンタグラフタイプの、コンパクトキーボードは今でも新しい製品が投入されている。
ところが、キー配列がどうしても気にくわない。

そこで改めて声を大にして言いたい。
TK-UP289 のキー配列はネ申であると。

コンパクトキーボードの場合、制御キーの幾つかを "Fn"キー(大体左下、Ctrlキーの横に配置される)との組み合わせで実現し、それによりキーの数を減らす。
最近見かけるコンパクトキーボードの場合、例えば次のような組み合わせになる。

• "Fn" + "←" ： "End"キー
• "Fn" + "→" ： "Home"キー
• "Fn" + "↑" ： "PageUp"キー
• "Fn" + "↓" ： "PageDown"キー

これだけで実に４つのキーを削る事が出来る。
他にも "Fn" + "Backspace"で"Del"キーにしている場合もある。
さらに "Ctrl"キーを左側だけにして、右側の"Ctrl"キーを省くのも多い（というか最近のコンパクトキーボードは全部このタイプだった・・・）。巻き添えで"Alt"キーまで左だけになるのもある。

ここら辺はまだ可愛いレベルで、ひどいのになるとバックスラッシュ(日本語106だと「ろ」が印字されてるキー)や"["(日本語で「む」印字キー)キーが、右端や最下段の制御キーに混ざって配置される事すらある。

ブラインドタッチでタイピングし続けるプログラマをバカにしてるのか！？

ここで改めて上に掲げたTK-UP289のパッケージ画像を見て欲しい。
コンパクトキーボードであるにもかかわらず、"Home", "PageUp", "PageDown"の３キーがきっちりと配置されており、なおかつ、"Ctrl"と"Alt"キーがちゃんと左右揃っている！それでいて、Backspace/Enter/Spaceキーは十二分な大きさを保っており、しかも文字キー配列は標準に則っている。
TK-UP289で "Fn"キーを組み合わせねばならないのは、僅かに "End", "NumLock", "ScrollLock" 位である。このうちNumLock/ScrollLockはプログラマとしては殆ど使わない。よって "End" キーのみが "Fn"+"Home"という組み合わせを使う特殊扱いになる。

右側の"Ctrl"キーがあり、なおかつPageUp/PageDownが単独で存在する事は Firefox で複数のタブを開いてブラウジングするときも便利である。 右手だけで、右側 "Ctrl" キー + "PageUp"/"PageDown" でタブを切り替える事が出来るからだ。

最近のコンパクトキーボードだと、右側 "Ctrl" キーが無く、さらに "PageUp"/"PageDown"が "Fn"+"↑"/"↓"の組み合わせになる。 すると、タブ切り替えをする時に右手と左手を両方使わなくてはならない！ 空いた片手でコーヒーカップを傾けながら・・・とはいかない！

最近のコンパクトキーボードがやたらと "Fn" キーの組み合わせでキー数を減らしたり文字キーの配列をずらしたりするのを見ていると、本当にあきれ果てる。
TK-UP289 は何も最新の製品ではない。５～６年前の製品である。５～６年前で既にこれほど無駄のないキー配列を実現しておきながら、何故今更"Fn"キーの組み合わせを増やそうとしたりするのか！

TK-UP289は、自宅で使っている一枚と、同じのがもう一枚予備であるだけである。従って今使っている一枚が壊れてしまえば、残りは予備一枚だけになってしまう。製造は終了している為入手も難しい。
最後のTK-UP289が壊れるまでに、同じキー配列のパンタグラフタイプコンパクトキーボードが販売される事を願って止まない。

ELECOM様お願いです、TK-UP289の製造を再開して下さい。 今度は10枚ほどまとめ買いしますから！もしELECOMの人見てくれていたらぜひお願いします！

あと、現在コンパクトキーボードを開発している各社におかれましては、ぜひともTK-UP289のキー配列を参考に新製品を投入して下さい。 気に入ったら10枚ほどまとめ買いしますから。

まぁ確かにTK-UP289は制御キーを省かなかったために、個々のキーサイズは小さめになってしまっている。
ある程度制御キーを犠牲にしても、キーサイズの大きさを確保しようとすれば、最近のコンパクトキーボードの形になるのは仕方ないのかも知れない。
でもな～"PageUp"/"PageDown"という、一般的にも日常的に使いそうなキーが "Fn"キーの組み合わせになるのは納得行かないな～・・・あ、マウスのホイール機能を使うのか、普通の人達は・・・。

自分の場合Logicoolのマーブルマウスだから、マウスホイールを使わないんだよな・・・。（というのも、オートスクロールやユニバーサルスクロールをサブボタンに割り当てているから。このスクロールは横方向も普通に対応してくれているので滅茶苦茶便利。何時だったかマイクロソフトが、ホイールを左右に傾けると左右スクロールできますってマウスを宣伝してたけど鼻で笑ったね。）

ちなみに、マーブルマウスの場合は６個ほどまとめ買いしてあるため、製造が停止しても困らない。
・・・というか、マーブルマウスって光学式トラックボールタイプなので可動部分が無い。ということで、ものすごい持ちが良くて壊れないんだよね・・・。自宅で使っているのなんて、7年位前に買った、まだ白い塗装がされてるタイプの奴なんだけど全く問題なく動いてます。(可動部分がないから当然だけど。)

引っ越してからこっち、３週間ほどE-Mobileで頑張っていたのだけれど、ようやくADSLが開通した。

今更ADSLかよ！ってところだけど、引っ越した先のビルが集合住宅向けの光回線が引かれていなかった。
となると、個人向けの光回線を引くか・・・って金額がそれなりにかかる。

別にP2Pやるわけでもなし、巨大なファイルのUPやDLを日常的に行うわけでも無し、自宅鯖を立てようとしてるわけでも無し、そもそも昼間は職場に居るわけで、インターネットを使うのは朝とか夜の数時間。

というわけでADSLでも特に問題ないし、やってみたところそんなに遅い感じもしない。
当然のことだがE-Mobileよりは断然速い。

というわけで、ようやくADSLも開通し、PC周りも落ち着いた。

• [ Prev ]
• [ Next ]
• [ 技術 ]

日本語関連の主な文字集合やエンコーディングスキーマの流れをざっとまとめてみたメモ書き。
下図には書き忘れたが、JISX0201/0208/0212/0213は、文字集合であるとともに、文字に振られた区点番号がそのまま文字コードとしても使えるため、「符号化文字集合」と呼ぶことがある。

• [ Prev ]
• [ Next ]
• [ 技術 ]

長かった。というか今更こんなところで足踏みしているのも恥ずかしいモノがある。
自分が持っているのは2006年8月第四刷なので、多分2006年後半～2007年にかけて購入したと思う。
ISO8859-1辺りのセクションまで読んだ段階でずっと放置してしまっており、この度転職と引っ越しの合間にちょこちょこ読み進めたりしてようやく読み終わった。

ようやく、文字化けや文字コード関連の記事を読むときの基礎知識が身に付いた、という感じ。文字集合やら符号化文字集合やらエンコーディングスキーマやら、区点番号など、今までなぁなぁで何となくで済ませてきたのがちゃんと落ち着いた。

で、以前自分が書いたJava関連の記事で、誤解を元に記述してしまった箇所があったので直したり。

読んでおいて良かった～という本でした。