フロッピー改竄?

大阪地検で起こっているフロッピー偽造問題で、あれこれ言われています。
http://117vcc002.blog12.fc2.com/blog-entry-89.html などなど
マスコミは絵になる部分しか報道しないので、実態が見えないです。

・フロッピー内のデータの作成日が重大な意味を持つ

・作成日は特殊なソフトを用いないと更新されない

・作成日は簡単に変更できる/できない。

・作成日は特殊技術を持った人なら簡単に変更できる。

・作成日を偽造して、立件を図った。
うーん。的外しなメントが多いと思った。

世間一般の意識はそうかもしれませんが、情報提供者であるマスコミは、一寸詳しい人に確認してから記事にして欲しい。

そもそも、電子データの作成日に「証拠能力」があるいう前提がおかしい。意図しなくても、CPU日付を変えるだけで、どうにでもできるし、変更日より作成日を未来にすることも可能です。

写真に埋め込まれる日付にしても、カメラ側の設定で変わるのは、知れ渡っていますよね。
「編集が可能だから、ビデオ資料は証拠能力がない」としているのは法曹界ですよね。その法曹界がデータファイルの作成日を証拠能力ありとするのだろうか。
マジでそう考えているなら、寒いなぁ。
　もっとドロドロしたことを隠すために、作成日問題で目くらまししているのだろうか(そういった深読みは外れますが)

随時に変更可能な日付属性の一点だけで、有罪/無罪/冤罪が左右されたのでは、たまったものではありません。

「作成日はこのように改竄された」ではなく、証拠能力の高低や電子データの信憑性をキチンと伝えて欲しいと思った。
当の検事が、何の意図でこの行動をしたのが皆目判らない。事件を捏造するにしては、お粗末すぎるので、なんか闇問題を感じてしまう。

国内最高齢

今日は敬老記念日...敬老は常に意識すべきで特定の記念日にすべきでない...という話はさておき。
ニュースでは、「長谷川チヨノさんは、明治２９年１１月２０日生まれの１１３歳で...」と流れてました。
http://www.nhk.or.jp/news/html/20100920/t10014090391000.html

昨今の、行方不明高齢者問題で、「高齢者不明：長崎に２００歳」http://mainichi.jp/select/jiken/news/20100828k0000m040055000c.html

というニュースもあるので、「国内最高齢」の判定基準がよくわからない。>

生存確認できている人の最高齢ならば、生死不明 or 仮想生存の状態が把握できているとも言えそうです。現実には漏れがあったのでしょうね。ならは、113歳を最高齢と判定するのは無理がありそうな気もします。

実際に生存されてなく、死亡届が未提出なので戸籍上の生存なのでしょうが、とっても疑問。

戸籍上生存しているのなら、実在の国内最長老者の決定プロセスは、どのように判断したのでしょうね。

戸籍と住民票の二重管理の矛盾を感じますし、住民登録がしっかりしていれば、今年もあります国政調査の一部の世帯数確認は不要だとも思うのです。

縦割り行政の悪い面かもしれませんね。物議を醸すかもしれませんが、総背番号制にしてIDを発行したほうがスッキリすると思います。
年金制度で実質上、総番号になっているのだから、反対する根拠は薄いとも思うし、弊害よりも不備が引き起こす不公平感のほうが大きいように思います。

高齢者行方不明問題はスッキリしないし、親の死を悪用しているなら猶更後味が悪いです。死体の腐敗臭を誤魔化したというのも不思議だし......
いままで、問題視しなかったのも不思議。見ない振りをしていたのかなぁ。

内部クラスのStatic

C#やVBでネスト構造のクラス(内部クラス)を定義することがあります。そのとき、内部クラス内に静的メンバーを持たしたりします。

public class 外側
    {
        public class 内側
        {
            public static int a;
        }
    }

このスタイルが身についているので、 Javaで、同様にコーディングしたら、コンパイラに怒られました。


●エラー: フィールド a は static として宣言できません。static フィールドは、static またはトップ・レベル型においてのみ宣言できます
意味が理解できず、あちこち頁をめくっていくと、「内部クラスではStaticメンバーは使えない」ですって。
処理系が異なるので、「そんなものだ。」ですが、.net系とJava系でのクラスに対する思想の差を解間みた気がします。


C#をメインにしているので、情けないことにJAVAで書くと混乱してばかりです。JAVA7でプロパティ構文が入る...と楽しみにしてたのですが、どうなったのでしょうね。

漢和辞典 は語学辞典?

英和は「英語」=>「日本語」の変換辞書です。和英、日独、独日....各国とも対になってます。
なのに、「漢和」は有りますが、「和漢」はありません。「漢和辞典は漢字を調べる辞典」と漠然と理解してますが。字面から解釈すると、「漢語=>和語」の辞典になりますよね。

だとすると、「和語=>漢語」の辞典があってしかるべきでは。

漢語は今の中国語と解釈すれば、「日中辞典」「中日辞典」が、該当するのでしょうね。

「漢和辞典」は語学辞典でなく、「漢字」を調べるものでしょう。そのように習った記憶もあります。でも、先人の方が指摘されてるように、大陸生まれの漢字は掲載されてますが、日本生まれの国字の扱いは軽いようです。辞典編集者には「漢和辞典は漢文の理解用の辞典」という意識があるらしいのです。

でも、日常に接する「日本語としての漢字」を調べる時に使いたいというケースが多いと思うのです。そこで「漢和辞典」とは違う「漢字辞典」が最近は出回っているようです。

学生のころ、「漢文」の授業がありましたが、「漢語という語学」という意識はなかったです。「漢文読み下しの日本語」の授業でした。
「漢語」の学習でなく、活字である「漢文」を読むことが重要視されていたんですね。(漢文が素養だと実感しないのはなぜだろう?。)

「英語」も会話教育より「英文」を読むことを重要視しているのは、漢文の学習姿勢が根底にあるのか....と妙に納得。

つゆだくだく

(牛丼常連には常識ネタでなんでしょうね)
牛丼屋でオーダーするとき、「並み(大物でもよいのだけれど)」だけだと、汁が少ない時があります。(店や店員によって量は不定の様です)
汁を多く欲しい時は、「つゆだく」と言えば、多くついでくれます。

もっと多く汁が欲しいとき「つゆだくだく」「つゆだくだくだく」と発注すれば、お茶漬状態にしてくれます。
吉野家、松屋、なか卯、すき屋ともに共通なようですね。業界用語として定着しているのかも。

店員の復唱も「だくだく一丁」のよで。「汁多く」と発注したら「だくだく一丁」と翻訳してくれました。業界用語のようですね。

白黒画像をカラー化

白黒画像をカラー化
坂本竜馬の有名な写真のカラー版を見ました。適当に着色したのだろう...と思っていたのですが、どうも実際に近いらしい。
ググっていくと、カラー化技術の頁を見つけました。 ここ

昭和60年に考案した..とあるので結構昔からあるのですね。

探してみると、カラー化ソフトまで出回っていますね。Photo-Colorizer 2.0などからあるようです。

adobeの頁に 「白黒の画像をカラー化する」がありました。白黒写真から「色相・彩度」特性を抜き出せば、カラー化が可能らしい。

その昔、写真にFFTを適用して成分分析をしたことがありすが、似たような技術なんでしょうかね。違う特性かもしれませんが。
銀板白黒写真が「色相・彩度」を隠し持っているから可能なのかなぁ。RGBで保持するデジタル白黒写真からは無理な気がします。(根拠のない私見です。)

恐竜などの皮膚の色は想定できないらしいですが、特定できる日がくるかも知れませんね。

Cannon MX870

前回、プリンタが壊れた事を書いたのですが、必要に迫られて、急遽購入しました。

至急に必要だったので比較検討する暇がなく、使い慣れたメーカーが無難かなと安易な判断でMX870にしました。

買ってから驚いたのですが、無線ネットワーク対応で、結線なしに、家中のPCから共有できるではありませんか。
スキャナー機能も、プリンタイベントで、スキャナーを単独操作しても、PCがキャッチしてくれる(立ち上げておれば)。
PC非経由で、USBメモリに格納もしてくれる。

その他便利機能がいっぱい。これで、3万弱とは、安くなったものです。(ここのところ、買い物をするたびに「安くなった」と驚いてます。)

ただ、インクの種類が機種によって別々で、今回のは、320/321です。　インクの粒や粘性で、共通化するのは難しいのかもしれませんが、専用インクになるのは、どうも釈然としない。
各社共通規格のインクにすれば、インク単体も安価になるのになぁって思うのです。

携帯本体料金をが通話料で回収しているように、プリンター価格をインクで回収していると思えてなりません。本体が安価なだけに、インクが高く感じます。

プリンタ昇天

プリンタが突如「プリントヘッドの種類が違います。正しいプリントヘッドを装着してください」と表示して、使用不能に。
機種はCanon MP770です。機嫌よく印刷していたのに、紙がジャムったので、給紙部分を開閉しただけなのに。突如と意味不明なメッセージ。
　何度か初期化するものの改善しない。

ググってみると類似の報告はあるものですね。
参考

どうやらプリントヘッドが壊れたらしい。仕方がないのでプリントヘッドを購入しようと探したのですが、置いていない。通販にも該当品がない。
キャノンの頁を探していると、販売終了したらしい。ここ
どうすりゃいいのよ。と問い合わせると、修理依頼すると受け付けてくれるらしい。費用と期間を聞くと、部品代込で最低\12,000は要して、7日から10日掛かるとのこと。

\20,000前後で新品が買える時代に、約5年前の機種を\12,000費やして修理する価値があるか...ないだろうね。
報告記事をみていると、「プリントヘッド」は消耗品のように思える。これの部品販売を中止するなんて、なんか営業方針が見えない。

ダメ元で、プリントヘッドを洗浄してみた。出るは出るはこびりついたインクの山。インクジェットプリンタは、電源を入れた時、各タンクから噴射するらしく、印刷しなくても、インクは減って行きます。その時のインクがへばり付いているのかな。
小一時間かけて、綺麗にしました。いざ装着。ダメでした。同じエラーがでます。

諦めの境地。
プリンタは紙屑製造機と思っていて、極力印刷しないようにしてしてますが、ある程度は印刷しますし、コピー機としても使用する機会が多いので、壊れると困るものですね。

使えないと思われる「市民トイレ」

昔は、公園や街角に公衆トイレを見かけたものですが、最近では減っています。マナーの悪さや、風紀その他の諸々があり、維持に多大な工数が掛かるらしい。
嘆かわしいなぁ...という話は置いといて。
　神戸市や他の都市では、コンビニ等の開放型店舗のトイレを「市民トイレ」という名前の「公衆トイレ」にしています。
年間謝礼金が出るようですが、善意に基づいています。...なのに、トイレットペーパーの盗難が多いって聞きますね....ああ。
http://www.city.kobe.lg.jp/life/town/toilet/info05.html
閑話休題。
利用している電車の駅のトイレも、「市民トイレ」の文字が書かれています。しかし、このトイレ、駅校内なんですよ。
昼間は、駅員さんが常駐しているので、一言声をかけたら、使わせてもらえます。でも近くのコンビニも「市民トイレ」なので、わざわざ構内に入る人は少ないと思います。
夕方以降は無人状態になります。なので、構外の人は使うことができません。
　そもそも、駅のトイレは、半ば公衆トイレ状態なので、「市民トイレ」化する意味は薄いのではないかと思うのです。

トイレの入り口には、「市民トイレです。どなた様もご自由にお使い下さい」と書いてあります。
夕方以降は、無人の自動改札機が立ちはだかって、利用を拒んでいます。不合理を感じるのだが。

サイゼリア CM

イタ飯屋のサイデリア。有名なのに、テレビCMしないんですよね。「CMに投資するより、単価をさげる」と聞きましたが。該当記事はみつけられませんでした。

CMが流れていないのに、知名度は高く、人も結構入っているようです。
　料理単価も確かに安い。........下種の勘繰り.....マックもCMをやめたら、単価を安くできるのでは..とフト思った。

広告費用と効果と単価設定は、単純な計算では成立しないとは思いまずか、マックぐらい知名度が高くなると、CM量を半分にしても、差が出ないように思うが、どうなのだろう。

サイゼリアとは異なる業界のリフォーム関係の「サイデリア」という会社があり(倒産しましたが) こちらのCMが結構インパクトがあり、混同している人もいるようです。

類似名称を利用して、CM効果に結びつけたとしたら、凄い策士な気も....偶然なのでしょうね。
CM効果の金額換算って難しそうだなぁ。

ApplicationException は非推奨です

最近の納品物のソースに、ApplicationException が点在していました。
当初の.netでは、例外はカスタム例外を使うか、汎用的例外(ApplicationException)を使うようにガイドがありました。
FrameWork2 のとき、「潜在バグがあるから、Exceptionを使うように。」とお達しがあり、話題になったように記憶しています。
でも、この手の通達は徹底し難いらしく、知らない開発者もいたり、 FrameWork1.x 時代の保守から入ったりすると、浦島太郎状態になる人もいるようで、当然のように、ApplicationException　を使う人もいたりします。
で、何の不具合たったんだろう。忘却の彼方。
http://csharper.blog57.fc2.com/blog-entry-34.html
が上手く説明されていました。
　途中で非推奨になった技やツールなどは、知らなければ、使い続けることになります。我々が伝えるにしても限度があったり、開発標準がそのようになっていたら、補正ができなかったりします。
ASP.AJAX.Toolあたりも、JQUERYに移行し、非推奨になりましたが、意外と知られてなかったりします。
周知徹底って難しいのかも知れませんね。

エラーを握りつしちゃダメ

VB6システムは、まだまだ現役で、新規開発もあったりします。開発者の思いとは裏腹に。
当然なから、改修の仕事も時折発生するわけです。とあるシステム改修現場でのこと。

「納得できない妙な動作をしています」との訴え。

確かに、業務仕様とは異なる動作をしている。いままで動作していて、急におかしくなるときは、データに起因することが多い。
データを閲覧すると、想定外の規約コードや、桁オーバーの値がチラホラ。

エラーログにもエラー状況は書かれていない。異常データだから、落ちてもよさそうなのに落ちない。

内部仕様書をみても埒が明かないので、ソースを見ることにした。

　　　Public Property Let xxx(ByVal yyy As 区分)
　　　On Error GoTo ErrHandler
　　　 xx区分 = 区分
　　　　 Exit Property
　　　ErrHandler:
　　　End Property
関数やプロパティのすべてに on Error goto ErrHandlerが入っている。これはいい。でも

　　　ErrHandler:
　　　End Property
で握りつぶしている。そりゃないよ。半分ほどは、Logに書いているけど。
　　　ErrHandler:
　　　　　　　Log出力
　　　End Property

これじゃ、正常終了したのかどうか、いちいちログをみなきゃだめだし、ログにもかかれず葬られた処理があるかもしれない。
とりあえず、全部のErrHandler: のあとに、Log出力を咬ませた。
不具合が出る出る......いままで正常とされていたのも、実はおかしかった...というのも発覚。


開発元を捕まえて、文句をいうと、「当時の開発指針に則っています。」との返事。
開発指針には、「各関数には on Error goto ErrHandler を咬ますこと。」と明記はされているが、握りつぶせとは書かれてない!!!
「サラリーマン開発者はプロではないのか」と愚痴りたくもなった。

落ちないシステムは大事だか、不正データの対策は、安全に回避ルーチンに陥るのが望ましいが、結構考慮点が多岐にわたるので、工数増になります。
予算と工期がないとき、素直に落とすほうが、よほど後々のデバッグが楽になります。
どこで落ちたか、解る仕組みの実装するのがプロです。
不確か状態で継続動作するより、落ちたほうがマシと思うのだが。
(*)もちろん、Try catch処理の時も握り潰しちゃだめですよ。

9:00～9:59 6ch , 10:00～11:00 8ch

ビデオ予約で、１時間番組が連続して(他チャンネル)放送される時の予約設定の仕様の件です。

Video業界の共通仕様なのか、我が家の機種固有の仕様なのか、知りません。
9時代の6Chと10時代の8chを連続して録画したいとき、

9:00～10:00 6ch , 10:00～11:00 8ch と指示すると、「時間が重複してます。」と叱られます。

9:00～ 9:59 6ch , 10:00～11:00 8ch と指示すると、正常にOKになります。が。9:59:00～9:59:59の１分間が抜けるようです。

開始<= 動作 <=終了　と解釈しているようです。 連続帯で指定すると、終了1と開始2が同じ時刻指定になります。

開始1 <= 動作 <= 終了1

開始2 <= 動作 <= 終了2

どちらにも、含まれてしまうので、エラーとしているのね。その結果、１分間の録画不能時間帯が生じることに...

単純に
開始1 <= 動作 < 終了1

開始2 <= 動作 < 終了2

にすれば、問題は発生しないと思うのですが、なぜそうしないのだろう。
録画と録画の連続してチューナーの切り替え作ができないから、ワザとGapを入れているのだろうか。それにしたら、1分間のギャップは大きいような。