2013/09/30

DLLとLIBの両方が欲しい

例:VC++のソリューション内にMyLibというライブラリのプロジェクトと、A.exeのプロジェクト、B.exeのプロジェクトがある。
A.exeはMyLibをMyLib.dllとして使いたい、B.exeはMyLibは組み込んでしまいたい、という場合。

なんでそんな場合があるかというと、例えばこんな時。
A.exeは32ビット版、64ビット版をそれぞれ配布したい、MyLibはdllとして、32ビット、64ビットそれぞれ同梱して配布。さらにB.exeを同梱するがB.exeは両方とも32ビット版を同梱したい。このとき64ビット版の配布イメージではB.exeが動かない(32ビットexeから64ビット版MyLib.dllの呼び出しになるので)。
そこで「B.exeだけはMyLibを静的リンクしちゃおう」ということになる。

で問題が起こる。VC++のプロジェクトはdllプロジェクトならdllが作られ、libプロジェクトならlibが作られる。
 dllプロジェクトで作られるlibファイルはlibプロジェクトの物とは違うらしく使えない。

そこで、MyLibプロジェクトはdllプロジェクトとしてdllを作りつつ、ビルド時にカスタムビルドでlibを作るようにしておく。
そしてA.exeは普通にプロジェクト参照で、B.exeはMyLibプロジェクトの参照はしないでヘッダーのインクルードとリンク時にカスタムビルドで作成したlibを入力するよう設定。

モチロンこんな面倒なことをしないでA,BどらちもMyLibを静的リンクするという選択が一番だ。

カスタムビルドでlibファイルを作るときのバッチファイルは単に以下のコマンドを打つ感じ。
「"<VCのBinフォルダ>\lib.exe"   /OUT:"<出力先フォルダ>\MyLib.lib" "<中間ディレクトリ>\hoge.obj" "<中間ディレクトリ>\stdafx.obj"  」
モチロンこんな面倒なことはしないで済むような構成にした方が良い。

2013/09/27

Bar of Adzuki‐Bean jelly

練羊羹ってすごくサイバーパンクな食べ物だと思う。
黒色で遊びの無いモノリス的な形状にヌメッとした質感。あずきの香りは有るものの、単純に栄養素の糖分を固めただけのようなストイックな食べ物。
blameというSF漫画で描かれてる長方形のよく分かんない保存食(実は食べ物でなく固形グリス!)に雰囲気が似ている(あっちは白っぽくてシャキ、サクという音がしてたが?)。

touch typing

仕事上、周りにタイピング速度が遅いかも?、とか一本指打法?!という人はまず居ない。ただ、そうかと言って正しいフォームと運指でタイピングを行っている人も少ない気がする。また、タイピングは早いもののキーボードと画面を交互に見て打つ人も居る(おもむろにID欄にパスワードを打ち始めて「何打ってるんだ?」と思ったらキーボードを凝視してた、とか)。
自分もバックスペースを薬指で押す癖がある。

今更思うのはやはり基本は大事なのでタイピングの練習もたまにはやってはどうかなと。いつもの半分の速度で良いので多少力を込めて、教科書通りのホームポジションと運指で、30分も打てば案外簡単に矯正出来るはず(日本国憲法を打ち込むタイピングソフトとかで)。
スピードはある程度で良いと思う(思考に追い付くくらい打てれば便利だけど)。

バックスペースを薬指で押すのは言い訳もある。小指にしろ薬指にしろホームポジションから大きく外れるし。状況的にカーソルキーを小指で操作してからバックスペースキーを押すことが多く、薬指の方が自然だし。消したい文字数だけ狂わずに連打することが求められるのでコントロールの効きやすい薬指の方が良いし。など
まぁこれから小指連打を鍛えるか・・

タイプ速度について。
みんながどんな環境で作業しているか分かんないけどとりあえず海外ドラマのようにパーティションで区切られらたスペースとか、個室で作業ってことは滅多にないと思う(そういうとこで作業させてくれるオフィスがあれば是非教えてほしい)。
んで普通に開放型のデスクで作業する場合、KPM400くらいのスピードでタイプしてたらかなり近所迷惑な音がするはずだ・・・

タイプ速度について追記
常時KPM400は要らないにしても、騒音気にせず本気でタイプすればKPM350くらいの速度が無いとやはり不便だと思う(400超えると忍者だ…)。そしてタッチタイプが出来ないと誤変換、打ち間違いに気が付かないなど通常作業に相当不利だ。個人的に仕事でPCを使う全ての人は
 タッチタイピング:必須
 タイピング速度:そこそこで良い
だと思う。どうだろう。

2013/09/25

CharArrayWriter vs StringBuilder

古いソースだと思うが
   CharArrayWriter caw = new CharArrayWriter();
   PrintWriter pw = new PrintWriter(caw);
   pw.append("hoge").append("hage");
   ...
   caw.toString();
というコードを見てしまった。やってることは文字列をどんどん連結しているだけなのだが、その目的の場合、ちょっとしたテストコードなら +(プラス演算子)で連結、ちゃんとしたコードならStringBuilderを使うのが定石だろう。Javaで文字列を連結するときプラス演算子はパフォーマンスに問題がある。そこでスレッドセーフでなくていいならStringBuilderを(文字列連結は大抵ローカルで行うのでこれで良い)、スレッドセーフが必要ならStringBufferを使う。
cawという牛のような変数名を見て若干おののいたが、CharArrayWriterも名前の通りそれと同様のことをやっているようだ。
では何でStringBuilderではなく見慣れないCharArrayWriterを使ったのか。

( ゚д ゚)分かりませんでした。

ちょっと検索しても違いがイマイチ分かんないし、こんなとき自信を持ってStringBuilderに置き換えても問題無いですと言い切れないのが経験の浅さでしょうか・・

CharArrayWriterは知らなくても困んなかったしStringBuilderだけ覚えておけばいいと思う。また、似たようなのでは万能なByteArrayOutputStream + OutputStreamWriterを覚えておくと便利。

2013/09/19

UAC云々

UAC:WindowsVista以降で管理者権限が必要な操作の時に暗転するあれ。
そのUACとドラッグ&ドロップの意外な関係。
意外っていうか、知ってる人には常識?
ドラッグ元とドロップを受け付けるアプリは同じUAC権限でないといけないというもの。
つまり「メモ帳」を管理者権限で立ち上げ、普通にエクスプローラーからテキストファイルをドロップすると開かれませんよ。という話。
一応エクスプローラーを管理者権限に上げれば良いのだが、そのためにはエクスプローラの設定を「プロセスを別で立ち上げる」にしないといけません。いろいろ面倒、というかそんなテクが必要なアプリ受け入れられないでしょうと思うので、結局、管理者権限が必要なアプリにドラッグ&ドロップ機能を付けてもダメってことだと思います。

コマンドラインで動かすCUIアプリで管理者権限が必要な場合、動かすアプリでなくコマンドライン(cmd.exe)に管理者権限が必要となる。
管理者権限でないコマンドラインで動作させると管理者権限が必要な処理のとこで何らかのエラーが起こり、そこで初めて「管理者権限じゃないせいでうまく動かないのかも?」と分かる。しかもこれだけでは別な原因のエラーかも知れない。さてそこで、プログラムの最初に管理者権限かどうかを判断してやりたくなる。
その判断はあんまりいい方法が見つからなくて、%SYSTEMROOT%下に適当なファイルを書込みするようにオープンしてみて出来るかどうか、って判定した。
(いやこんなことしないでもマニフェストでRequireAdministratorとすれば大丈夫なのか?)
#include <fstream>
std::fstream ofs("%SYSTEMROOT%\\new_file", std::ios::out);
if (ofs == NULL) {
   doc->addTextline(L"管理者権限が必要です。");    
}

UACそのものについてですが、「UAC無効」の方がセキュリティ下がるとか、動かなかったものが動くようになるって思ってましたが違います。 「ユーザーアカウント制御を使用している場合の注意事項」 が分かり易いですが、UACが有効だとユーザ権限でも管理者権限に昇格できて動かせます。
逆にUACが無効でユーザ権限の場合は、今まで昇格の確認が出てOKを押すときちんと動いてたものが、昇格確認が出ないで動かないとか、動いても書込み時にエラーになるとかになります。
なんか分かりずらいシステムですねぇ。

無効にしてAdministratorグループのユーザで動かすのが一番楽です。
有効にしてユーザグループのユーザだと昇格の確認が出るのが面倒だけどきちんと理解していれば確認が出るので安全です。
でもUACの確認が出たらノータイムでOK押しちゃうような人だと結局全部管理者権限になるので意味無いし面倒なだけです。
無効にしてユーザグループのユーザだと制限がかけられるので不便な代わりに安全です。 

2013/09/10

_

何の映画だったかなぁ~
刑事ものだと思うんだけど、印象的で好きな場面がある。
若手の刑事が証拠物件のファイルを手に、「何も怪しいところはありません」と言う。
とベテランの刑事が「何も無い?ほんとにそのファイルを全部見たのか?全部見て何も見つからなかったらもう一度頭から全部見直せ。それでも見つからなければもう一度頭から全部見直せ。それでも見つからなければもう一度だ。10回でも20回でも見直せ。見つからないなんてのはその後で言え」
的な会話をする場面。もっと繰り返してたかもしれない。

デバッグ作業(特にプログラム的には明らかにうまくいくはずなのにうまくいってないところの修正)とか、まさにこんな気分。一日中たった一つのconfig.xmlを、直して再起動、直して再起動、直して再起動…。
で何してもうまく行かないでPCごと再起動したら最初の方に修正したファイルで動くようになってたとか。

ファウンデーション  銀河帝国興亡史」という超有名なSF小説がある。早川SFの中でもかなり有名な方なので読んだことのある人は多いはずだが、第3巻(?)くらいまであり、全部読破した人は少ないと思っているw(3巻まとめ買いしたが2巻の途中で読まなくなり、3巻は読まずに売っちゃった)
その中に原子力に関して好きだったシーンがある。
惑星間で戦争が始まったり始まらなかったり、という未来で宇宙的に辺境の場所に学業に専念するアカデミックな惑星を作る、という話で第1巻はかなり面白い。
周りは戦争してるがその惑星だけは学業に専念している。そこへ戦争中の横暴な将軍様(?)が訪れ、何か援助しろと言うがあるのは歴史の本だけ、とか化学実験の施設でも戦争に役立ちそうな研究は何も無いという状況。しかし将軍様はその惑星に原発があるのを知って顔色を変え、考え込んで帰って行く。
その後の応対した学術惑星の人達の会話「原子力燃料の話を出した時にえらく驚いてたのに気付いたか?」「あいつら、石炭と石油の時代に逆戻りしちまったってのか?」
その時はまさか日本の原発が全部止まって石炭と石油の時代に逆戻りするとは思ってなかった。小さい事故を繰り返しながらどんどん安全になってくんだと思ってたけどなぁ。
今は原発ゼロとか言ってるけど100年後とか200年後は絶対また原発使ってると思うな。

2013/09/07

Crimson Pig

紅の豚 見ました。
オープニング、ねずみがタイプライターのカーソルみたいになってて、何ヶ国語かで文字を打って行く場面が懐かしい。一匹だけアラビア語のやつが右から左に行くのが面白くて日本語の文字なんか全然見てないの。その場面で思い出したけどこれ公開の時に家族で劇場に見に行ったんだ。すごい必死でお願いしてやっと見に行くことになったんだけどその割にあんまり面白くなくて悲しい気持ちになったのを思い出したなぁ。。
改めて見たけど、ラピュタとかナウシカみたいに話が壮大になってく奴の方が好きなんだなぁ。魔女とかトトロとか紅の豚とか最初と最後であんまり変化が無い話は好きじゃないのかも。

2013/09/06

Tomcatで文字化けを直した

TomcatというかServlet APIかな?役に立つか分からないが一応載せてみる。

ちょとしたWebアプリでUTF8のページから日本語文字列をパラメータで送信すると文字化けするようになった。多分Tomcatを新しくしたタイミングで発生したと思う。
前のTomcatでは request.setCharsetEncoding("UTF8"); をやっとくと文字化けしなかったが、これはTomcat5では無視されるらしいのでserver.xmlでuseBodyEncodingForURI属性をtrueに指定して対応した。
ところがTomcat7ではuseBodyEncodingForURIは不要になったとか。
でわけ分かんなくていろいろやって以下のようにすると文字化けしなくなった。もうTomcatの設定とか関係ない感じ。
    String comment = request.getParameter("comment");
    if (comment != null) {
        comment = new String(comment.getBytes("8859_1"),"UTF8");
    }
でもこういうのはWebAppサーバの設定で何とか対応するのが正しい気もする。StringからStringを新しく作るとか酷く効率悪そうだし。。まぁちょとしたWebアプリなので気にしてない。
(ついにJavaカテゴリを新設)

2013/09/05

Complain

ITproの記事でこんなことが書いてあった。日本のソフトウェア製品について、
アーキテクチャーが崩れていても、テストを重ねて品質を磨くので、問題が表に出ることがない。
その結果、アーキテクチャーはさほど重要ではない、と思われてしまった。

「テストを重ねて品質を磨く」ってことが、「設計を見直すことも含めたプログラムの修正」なら良いんだけど、「ちょっとしたバグの修正」と「『if』で条件分岐を増やす」だけなことが多いんだもんなぁ。設計上どうしてもダメなら「設計から大きく変えないとダメだから無理、出来ない」ってよく聞くんだけど、なんで「じゃ設計から見直して作り直すよ」にならんかな…
プログラムってそんなに作るの大変かなぁ?

建築物の建造なら、一度木材をある長さに切っちゃったら、もっと長いのが必要だったってときは新しい木材が必要だし、壁を作って壁紙張った後で中の配線を変えるときは壁を壊さないと出来ないし、配線直して新しい壁を作るのにはまたコストが掛かるし。それに下手に壊すと周りの新品の床に傷が付くとか厄介なことが多いんだけど、プログラムって「Ctrl+A」「Ctrl+C」「Ctrl+V」で今あるのを壊さずに新しいのを作り直せるんだよね。 今あるのを活かして作り直すとかも簡単に。
建築物なら納入時は壁も床もピカピカの状態でお客に渡さないとダメだけど、プログラムは傷とか、雑に扱ったから品質が悪くなるなんてこと無いんだから、作って壊して作って壊してガンガンやりゃーいんだよね。コーディングの前にきっちりした仕様書が必要だという主張はプログラムを建築物のようなものだと勘違いしてるんじゃないかという話。
どちらかというと「建築物の設計図」こそが「プログラム」に相当するもので建築物の建造はコンパイルに相当する、と考えた方が正しい。とすると、あとは建築物の建造とコンパイルの違いを考えると、ほんとうはプログラム作成とはどう向き合うべきか分かりそうだ。
と、建築物との比較の例はある本の内容そのままなのでこれ以上はまずい。面白いしそんなに高くない本なので是非。
さて、どんなに酷いプログラムに見えてもテストで全て「○」が付いた製品は正しい…
ましてや正しい製品なのにプログラムを修正してテストをやり直す手間を発生させるなど許されるはずもない…
この開発方針は正しいのかな?という愚痴でした。

「保守性の向上とか潜在バグの回避とか幾らでも説得材料はある」
 VS
「客にとって大事なのは、動いてる部分の維持保障とコストの増大を防ぐこと」
「壊れていないものを修理するな」
この辺は2chのまとめ。みんな不満を持ってるのだ。

ListLength(std::list<> )みたいな関数が有った。 中身は
long ListLength(std::list* list)
{
 return (long)list->size();
}
だった。わーぉこの方法なら無限にコード行数を稼げるね!!凸(ー_ー)

2013/09/02

Bit演算

組込み系でアセンブラってるとか、ゲーム系でパフォーマンス重視とかの人だと結構使うのかもしれないけど、Web系とか業務系では避けて通れるやつ。
でも普段避けて通ってる人もイザって時にビット演算使ってみて劇的にメモリ節約、パフォーマンスアップしたりすると最高に気持ち良いですよ。

飛び道具的な、「しょうがねぇ、あれやるか」的な、厨二病的な。
でも普段避けて通ってるもんだからグダグダなプログラムになったりw
C++やってるとき、もうちょっとパフォーマンスが欲しくて「しょうがねぇ、アレ、やるか」とインラインアセンブラに手出したときはさっぱり出来なくて挫折した。大学で習ったんだけどなぁ。
アセンブラはともかくビット演算だけでも使えるようにしとくと便利で良いです。