FC2ブログ

平方根

何年ぶりだよっていうくらい久しぶりにMS-Excel VBAを触っている。

VB自体もうかなり触ってないから忘れてる忘れてる...
『あぁ、VBAでもクラス使えるんだった...』、とか、もぉそんなレベル。

そいで平方根。
『BASICだから、えーと、SQRT()か!?』...アウツ!
え?えぇ?(・・;ここでちょっとパニック。

『...あ!ワークシート関数か!?』
Application.WorkSheetFunction.Sqrt ...アウツ!

どうにも思い出せずネット検索。

Sqr()

MSのあほー

っていうか、^(1/2)でいいんじゃね?>俺
スポンサーサイト

電子データでの写真納品

またまた時事ネタだが、

国道工事完成写真、受注業者が修整 全国で疑い1千枚



測量写真や施工管理上の写真をデジカメによる電子データとして納品できるようになって久しい。
導入当初は改竄が懸念されていたが、特別騒ぎが起こった様子もなくそれなりの対策がなされているのだろうと思っていたが、何の対策もとられていなかったようだ。

国交省は10月に、全国約100の国道工事などについて調査。約20万枚の写真を確認したところ、パソコンの画像などにデジタルカメラの機種や撮影日などの記載がない不自然なものが約1000枚あった。

確かに見聞きするところでは、
  • ヘルメットを被っていない作業員にヘルメットを被せる
  • 黒板に書いた文字の間違いを修正する
程度の修正は日常行われているようである。が、この程度の修正は実害が無いし、撮り直しの手間が省ける程度のものである。しかし、これが例えば高止まった杭の高さを低く偽装するなんてことにまでエスカレートしない保障はどこにもない。
加えて上記引用部のようにその偽装を見抜く手段が、画像データに埋め込まれたインデクス部を見る程度であるなら、これはもぉダメかもしれんね、ってくらいダメなのである。そんな部分の書換えなんぞ職業プログラマでなくとも簡単にできるレベルだし、探せば書換え用のツールなんぞ山ほど出てくる。

偽装/修正の定義も難しい。一般のデジカメのデータ保存形式はJPEGかPNGあたりかと思うが、JPEG自体非可逆圧縮で元データそのものは存在しないし、画質を良く見せるためにカメラ自体でシャープやソフトのフィルタ処理をかけるのもごく普通に行われている。明るさやコントラストの調整もものによっては偽装となる場合もあるだろう。その線引きはどこにするのか難しいと思うのだが。

偽装/修正する側にも問題はあるとは思うが、電子透かしなどの技術もいろいろあるのだから、その辺もちっとちゃんとしないとあかんのではないかと。

耐震強度偽装問題

耐震強度偽装問題
しばらく世情に疎くなっていたが、世の中を騒がせているのは朝日新聞の表現ではこういうことらしい。
思うところはいろいろあるが、注目すべきは、設計者が『建築基準法違反』に問われるところにある。

件の問題は設計者が故意に構造計算を改竄したとされていることから、建築基準法第二十条(構造耐力)に違反したものとして、第百一条の五の規定により50万円以下の罰金となると思われる。また同時に建築士の資格取消し処分も課せられる。

ソフトウェア開発の世界にこういう仕組みは今のところ無い。設計がどんなにタコであろうがバグがどれだけ潜んでいようが、社会的にどれだけの被害を与えようが、契約違反でさへ無ければリスクは負わない仕組みになっている。

それ故に、開発側が最も注力するのは工期の遵守になってしまう。実際問題として大幅な工期遅れが発生しさえしなければ契約違反とはならない。だから特に業務系システムでは、『出来上がりがどれほどショボかろうが収めてしまえばOK』というような風潮さへ出てくる。殆ど詐欺に近い。

なんか悲しすぎてこれ以上書く気が起きなくなってきた(--;

CSV

以前にもどこかで書いたような気がするが...

CSV(Comma Separated Value)
フィールド区切りをカンマとした可変長テキストデータ形式のことを指すんだが、実はこれがまた非常に曖昧。
規格として定まっているものではないので、開発要件として『CSV形式』と提示された場合は確認すべき項目は多い。

レコード(行)のデリミタはCR+LFですね?
Linux/UNIXではLFのみ、DOS/WindowsではCR+LFが標準。
さらにCR+LF+CR+LFであったり、アプリケーションによって差異がある部分なので必ず確認。
フィールド(項目)のデリミタはカンマ(',')ですね?
CSVなんだからカンマだろうよ、と決め付けてはいけない。意外な落とし穴に落ちないよう必ず確認したい。
文字列はダブルコーテーション(")で括りますか?
要は項目に属性を意識させるかという事に繋がるんだが、とりあえず相手に判りやすいように(")の話を持ち出すことが肝心。
これがダブルだろうがシングルだろうが構わないんだが、括るということになれば、それを文字列内で使用する場合のエスケープの方法を検討しよう。
先頭レコードは項目名(見出し行)にしますか?
これ意外に盲点。メジャーなアプリケーションでは選択できる部分だが、特定用途のアプリケーションや業務系システムへの吐き出しの場合はそちらの仕様を確認する必要がある。
出力したCSVは他のアプリケーションで利用しますか?Excel?Access?
データによってはExcelとAccessのCSVの扱いは異なるし、それ以外のアプリケーションなら尚のこと。
検証用のアプリケーションを明確にしておこう。


データベースからの抽出の場合は、文字列項目にデリミタが含まれるかどうかを検査する必要がある。多くのデータベースでは文字列項目にカンマも改行も登録可能であるので、CSVとして吐き出す時には適切なエスケープや変換が必要である。またそれを読み出す時には同様なエスケープや変換が必要となる。

たかがCSV、されどCSV、であって仕様が不明瞭なまま安請け合いして欲しくない。
がしかし、所詮CSVでもある。データ仕様さへ明確になれば、それに合わせてちゃちゃっと作っちゃえばいいのもまた事実。事前の確認をちゃんとして、金も手間もかけたくない。こんな部分に。

※ちなみに客や若いSEさんに質問する場合は『~についてはどうしますか?』という聞き方は時間の無駄である。
『○○ですね?』と確認するだけで済むような準備をして臨もう。

DBの正規化ってぇのは

データベースを基本にしたシステムでは、昨今、データの正規化ってのが流行り言葉なんだが。

そもそもデータの正規化なんちうのはデータ構造を考えた時に最初に頭の中にあるべきもので、出来上がったものをどうこうっていう話じゃぁないはずなんだが、あれこれいぢくりまわして「はい、正規化しました」、なんてケースが結構ある。

基本的には、
  • マスタ系にはできるだけ一意になるIDを振ろう
  • トランザクション(日々追加型)テーブルでも、冗長なプライマリキーを持たせるのはやめよう
  • 重複したデータを持たせないようにしよう

ぐらいのものでとりわけ難しい考え方なわけではないんだが、「正規化しました」と言われるテーブルには、なぜか三つ巴参照が多く発生する。例えば、

A-TABLE
A_ID
CODE
ATTR
B-TABLE
B_ID
A_ID
NAME

なんて構成になってて、参照側はCODEに対応するNAMEが欲しいだけなんだが、B-TABLEのA_IDでA-TABLEに紐付けて、A-TABLEのCODEとで結合したB-TABLEのNAMEをとってこないとならない、っちうなんというか...
SQL書くと、

SELECT B.NAME FROM A, B
WHERE A.CODE = '0001' AND A.A_ID = B.A_ID

こんな感じ。まぁこれだけなら大した話ではないんだが、こういうテーブルが幾つもあると、クエリーが曖昧になっちまってしょうがない。
少なくとも参照の多くが CODE-NAMEでの対応が必要であるなら、CODEがB-TABLEにあるか、もしくはA-TABLEにB_IDがあるべきなんじゃないか?

とりあえずクエリーを無視した正規化なんてものは正規化とは呼べるわけがねーよ、と、そこを強調したい。
頼むぜよぉ>マスター

検索してみた

出張も長くなるとさすがに疲れる。

ホテルに戻ってからも、いろいろしなきゃならない事が多いんだけど、ついついダラけてしまって...
何の気なしに、自分の名前をググってみたりする。

ほぉ、って感慨もなしに見ていくと、

なかやまきんにくん


いや、確かに。でも一気に萎え。寝る。orz

水理計算

その昔、土木設計技師であって、水理計算なんかをガシガシやってたはずなんだけれど...

一応、水周りの計算は2次元までは一通りこなしてきたと思う。
流出解析みたいな水文から、河床変動解析みたいな偏微分方程式とか。不等流計算なんか日常だったはずなんだが...先日そっち方面の関連書籍を随分処分してしまって、手元にあるのは水理公式集のみ。それも昭和60年版。orz
例題集も捨てちゃったし、他の標準資料やなんかもすっかり処分済。

とりあえず困った顔しながら開いて読んでたら子供が寄って来て、
『わかんの?そんなの見て』
てめこの、お前ら生まれた頃はコレで飯食ってたんだぞ、と言っても誰も信用せず(^^;

すでにすーっかり忘れてるし...
限界水深出せないよぉぉぉ、まぢかぁ俺ぇ...(;;
suirikousiki

単位系

メールにファイルを添付する際に最低限本文にファイル名とサイズを記述するようにしてるが、そのサイズの単位はいつもByteと書くようにしている。
大きな単位を使うと2進数と10進数で誤解が生じるかもしれないからだ。
この業界でも混乱はあり、1MB(いちメガバイト)が10^6なのか2^20なのかで差異が生まれる。

IEC(国際電気標準会議)では、2進数を基本とする単位を10進のSI単位系と区別するため、
Ki(kibi=2^10), Mi(mebi=2^20) という接頭語を使うことを提案している。(http://physics.nist.gov)

でもねぇ10年近く経っても浸透しないし、使わないよきっと(^^; テビワロス?

ちなみにSI単位系での「キロ=10^3」は小文字のkであり、2^10の場合は大文字のKを使うのが通例となっているので、いい加減に使うことのないよう注意注意。
またちょっとニュアンスは違うが、大文字のBはバイト、小文字のbはビットの省略として使うのが通例なのでこれもきちんと使い分けるようにしないと。(KB=キロバイト、Kb=キロビット)

※大文字のKを使った場合、本来はキロではなくてケーと読む。KB=ケーバイトなのだが、既にどこにもそう呼ぶ人は存在しない...

バランス

業務系システムの仕事を永らくやっていると、一般ユーザの意識からどんどん離れてしまうので、PCのメンテや相談などできるだけ受けるようにしている。

んで、ちょっとしたツールを作る依頼を受けたんだけども、なかなかイメージが出来上がらない。というより使う側の気持ちになるまでに随分時間がかかってしまうようになった。

これが衰えなのか慢心なのか良くわからんのだけど、何事も少々周りを巻き込まねばできない人間にはなりつつある...寂しいけど

人間としてバランスがとれてきたということなのか、技術屋としてアンバランスになってきたということなのか。
あーやだやだ

東証ストップは手順書の不備

東証のシステム障害による一時取引停止は、先のソフトウェア更新におけるFの手順書の不備によるもの、との報道。

やべーよ、手順書なんて嘘だらけだよ
ちうか設計書がすでに実装と違うよ
てかさ、要件満たしてるのかも怪しいよ
でも動いてるよぉ

テラヤバス

ワンクリック

なんかオモろいとこないかいなと巡回してたら、半端なアダルトのワンクリック踏んでしまった(__;

妙に画質荒いインストール窓が出て、「登録完了しました」「3万9千円振り込め」と。
まぁ業者もいろいろ考えるんだろうけども、懲りないというかなんと言うか。せっかくJava-Scriptとか使ってんだからもちょっとマシにすりゃいいものを、どっかで拾ってコピペで済ませようとするもんだから、ザラザラのダイアログ(風ブラウザの新規窓)で信憑性ゼロじゃん。(^^;

これでちゃんとメールでもくるならまだいいけども、環境変数しか抜いてなかろうが。「追跡します」とか「債権取立業者に」とか書く前に、もう少し美しく作って欲しいもんだと。

いやアダルト物を見ようと思ったわけじゃないのさ、TVのハプニング動画のリンクだったんだけども...
腹立つんでサーバ潰してやろかとも思ったけども大人気ないのでここは無視無視。(^^;

毒を盛った彼

出張続きでニュースにとんと疎くなってるので最近のニュースを漁ってると彼のブログに行き当たった。

実の母親に毒を盛りその日記をつけていたと報道されている彼。彼女と呼ぶべきか。その彼のブログの一部を読んだ。
これがまた魅力的なんである。

化学はさっぱりだし薬品の名前なんぞ何も知らないけれど、彼のつづる文章に引き込まれそうになる。たかが子供の日記なんだけれど。

彼の尊敬するなんとかという人物や、その人物が傾倒したナチズムを否定する気はないし、家庭環境や彼の生い立ちにも興味があるわけでもない(まるで無いわけでもない)が、ブログ(の一部)を読んだだけでもそのバランスが悪いのがわかる。とても魅力的だがバランスが悪い。危うい、といった方がいいのかな。

もうちょっと体系立ててバランス崩さずに書けるようであったなら良かったのに。

自分の子供と重ねたりして客観的に見ようとしたりはしたんだけども、それでも彼の文体はやっぱり魅力的で。
もっと読ませて欲しいんだがなぁ。

※関係の方々が目にされると嫌悪されるかもしれませんが、他意はありませんし事件そのものへの感想でもありません。ご容赦を。

風邪抜けね~

ここんところの出張続きですっかり弱った体には抵抗する力も無く、風邪菌にいいようにやられてる。
それほどひどくは無いんだけれども、もうちょっと休養が必要かな、、
と思ってるところへ電話が鳴る。
応対しているところへメールがくる。そうこうしてる間にメッセが飛んでくる。

PC落として寝ろよ、ってな話なんだが(^^;
それが楽しみだし(^^;;

データの検証

いつも手間取るのはIn/Outのデータの検証。
テスト計画がちゃんとしてればテストデータからIn/Outの結果まで用意しておいて比較すればOKてな感じにもできるんだけれども、いつも行き当たりばったりの個人情報保護なんてどこ吹く風の現地での実データでのテスト。
Outのデータが仕様どおりなのか正しいのかズレているのか、16進ダンプで吐き出したり、専用のチェッカを作ったりして対処しているんだが、そろそろ汎用のデータ閲覧ソフト作らねばという気になってきた。
だって100万/月の人間が1週間かかってダンプ追うなんてどう考えても馬鹿らしいし結局そのツケはこちらに回ってくるんだし。

ほいでどういったもんが必要かというと、In/Outのデータはたいてい構造体で定義されている。だから構造体が定義されているヘッダファイルを食わせて、データファイルをアタッチさせればほれこのとおり中身が一目瞭然と。まぁそういうの。

それでまず構文解析機を、と思うのだがこれがまたCのヘッダファイルってのがややこしい。コメント程度は問題ないとしても、#ではじまるプリプロセッサへの指示、ネストした構造体、不完全な宣言への対応、とまぁK&Rスタイルを考慮するとなんとまぁ複雑な。コンパイラメーカー尊敬します。

とりあえずトークン分割からちまちまやり始めたとして、できあがるのは1年後だなぁ...歳とると勢いないし。

うーむ、誰か若い人作ってよ。
LR法とか興味ないかねぇ?

東証取引停止

あらら、やっちまいましたね>F
http://www.asahi.com/business/update/1101/153.html

詳細はようわからんが、月次処理を行ったところ、10月11日より稼動している新システムが証券会社のデータを見失った模様。
REINDEXで空き領域の整理したのに対し、新システム側が独自に保持していたINDEXで参照できなくなった、てことかなぁ。
『各証券会社の端末を照合する手続きが』ってあるから単なるアクセス障害と同じだったのかも知れないし、照合できないことで不正な取引が成立した可能性があるのであればそれはそれでまた大変な作業だ。

どちらにしても現場のみなさん、死んだ方がマシだと思うこともあるでしょうが、生きて帰ってください。

幅指定子

意外に知らない人が多くてビックリするのは、printfの幅指定。

業務系システムに限らず、コード中にベタで数値を指定することは嫌われるんだが、例えばこんなの。

sprintf(buf, "%04.4d", n);
strncpy(dest, buf, 4);

この4を直接記述するのはバグの温床になるので

strncpy(dest, buf, sizeof dest);

と書け。
なぁんてことを言われたりするんだが、その上に%04.4dがあるんじゃ同じやないかと。

4が気に入らんなら、

sprintf(buf, "%0*.*d", sizeof dest, sizeof dest, n);
strncpy(dest, buf, sizeof dest);

とか書かないと意味なくね?

printf("%-*.*s", sizeof dest, sizeof dest, dest);

とか毎度書く?

後で読む方としちゃ4書いてもらったほうが見やすいんだけど...

### 2006/12/24
ありゃりゃ、%02.2d って..orz
%dではピリオド以下は無視されますよ、おい。

文字列

VBやJavaといった割と高水準系からC言語へと流れてくるプログラマが時々いて、特に文字列の処理についてあけてビックリってことがままある。

VBやJava、またはその他最近の言語では大抵文字列用のオブジェクトが用意されていて何も悩むことはないのだが、C言語の場合は基本的に文字列という型がない。
C言語でいう文字列とはCスタイルの文字列であり、\0を終端とした符号付1Byte変数の配列というなんとも微妙なものなんである。

まぁ自分一人で閉じている世界であれば、文字列=Cスタイルの文字列として0で終端処理されていることを前提としてプログラミングしても何ら問題はないんだけれども、他機や他プロセスとのインタフェースとなると終端処理されない単なるバイト列として扱わなければならないケースが多い。

例えば先頭4ByteがID、続いて6Byteが数値、いずれもASCIIで数値はゼロサプレスしない6桁のASCII、なんて場合、
XXID000456
受信側のモジュールが数値を数値として扱うために、

char buf[8];
strncpy(&p[4], buf, 6);
buf[6] = '\0';
n = atoi(buf);

なんてぇ処理が必要になるんだが、こんなつまらないところでのバグの多さたるや、もぉ、ね。
それ以外にも、

sprintf(&p[4], "%06.6d", n);
sprintf(p, "%-4.4s", sid);

なんて事も平気でやっちゃうわけで。
『Cスタイルの文字列ってのは終端が..』って説明を毎日毎日何度してることか...

それとは逆に、文字列オブジェクトの場合、例えばOracleで使うVARCHAR2なんかはPro*CではVARCHARで定義されていてC言語から使えるわけだが、終端処理されていない=サイズを保持していて、オブジェクトの先頭にサイズを持たせている。なのに平気でバイト列をオブジェクトの頭にmemcpyしちゃう。

なんかもぉ言語に対する思想が違うのね。
C言語を使える人間はもの凄い勢いで減ってきている、と思って間違いないんだろうな。
プロフィール

f_yamaki

Author:f_yamaki

アクセスカウンタ
最近の記事
最近のコメント
最近のトラックバック
月別アーカイブ
カテゴリー
ブロとも申請フォーム

この人とブロともになる

ブログ内検索
RSSフィード
リンク