きまぐれ　ぷろぐらま語録

健康診断で良くない結果(※１)
↓
就業時間後とか、昼休みに行ける、会社近くの病院が良いよね(※２)
↓
会社近くの病院に通院。投薬治療。
↓
会社が数駅隣に移転
↓
ま、この程度なら、就業時間後に行けばいいかな
↓
ある意味長期出張決定おめでとう
↓
3ヶ月分の薬を処方して貰う
↓
超多忙
↓
薬が切れる←まもなくここ。

さて、どうしたものか・・・

※１
ちなみに、健康診断の結果が悪かったのは肝機能。
みんな、脂っこい物やアルコールには気をつけようね。
その他、ついでに受けている治療も少々。

※２
会社の近くの病院は、「整理番号の順番通りに呼ぶ」で、
「外出する旨を伝えると、番号を保留しておいてくれる」ので、
昼に整理券をとって夜にいくと、すぐに診療には入れるので助かっていた。

某、遠隔操作事件のウイルスの解析結果の一部が、警察によって公開されている：
http://www.keishicho.metro.tokyo.jp/jiken/jikenbo/enkaku/sub4.htm

あまり時間もないのでチラ見をした程度だけど
・C#一筋という人ではなく、どちらかというとJava等の畑の人。
・少なくとも一定水準のプログラム知識がある
と言うことが見て取れる。

前者は、命名方法がC#で一般的な方法では無いことから容易に推測出来る。
C#一筋の人ならば、AaaBbbCccといった、最初の文字も大文字にしたキャメル型を好んで使うけど、
Java畑の人ならば、aaaBbbCccというった命名規則を好むからね。

後者については、使っている英単語がそれなりに専門である点。

たとえば、「fetch」なんて、そこそこ深い部分の実装をしないと覚えない単語だと思う。
「sanitize」はWebサイトの開発を結構やっている事を示唆している。

これを見た感じとしては
・C#は恐らく初心者だけど、C/C++でのマルチメディア開発経験があって、Web開発にも長けている中堅技術者
といった印象を受ける。

特に、「Tick」と言う単語。
自分の中で、Tickという単語を使う命令はマルチメディア系の命令ではよく目にするけど、
それ以外で使うことはまずないと思っている。
単純に犯人が英語に堪能というのも否定は出来無けれど、
そうじゃ無いならば、Tickという単語をわざわざここで使うというのは、
マルチメディア系の開発経験があるんだろうなと。

ちなみにWindowsAPIだと、
OS起動時の通算ミリ秒を取得する命令として、
GetTickCountという命令がある。

プロファイリングって面白いなぁ・・・

昨日の続き。

で、郵送でパスワードが送られ来たわけですよ。
案の定、自分がメモっていたパスワードと比較したら、
1文字だけでした。

・・・というか、この通信会社、仮パスワードとは言え、パスワードを平文で保存しているのかよ！

という、驚きはさておき、ユーザーの本登録っと♪

「このログインIDはログインロックがかかっています」orz

再度、サポートに電話。
サポート「ロックの解除ですね。ではお客様を確認するために、郵送したパスワードを口頭でお伝えください。」
おいら「いや、口頭で伝えたくないから郵送にしているわけですが・・・」
サポート「あぁ、そうですね。では、生年月日とご住所と（ry」

なんだ？
通信会社では、パスワードを口頭で聞き出すというのが流行っているのか？

でも、こういう会社が多いと、ITリテラシーが少ない人が、
訪問してきた事象銀行の人が、銀行の暗証番号を事件は絶えないだろうなと。

そんなことを思う、サポートへの連絡でした。疲れた・・・

昨日の続き。

というわけで、サポートに電話したわけですが・・・

サポート「料金確認ページに最初にログインするときに、ID/PASSの変更をして、本登録しないといけないのですがお客様はされてないですね」
サポート「この状態だとパスワードリマインダーも使えないです。」
サポート「登録時の仮パスワードを入れて初期登録をして下さい。」
おいら「ログイン画面では、自分が使いそうな番号は全て入れたのですが・・・」
サポート「では、それらの番号を、今ここで、口頭でお伝え下さい。正しいのがあれば「それです！」と言いますので。」
おいら「えっ？」
サポート「ですから、お客様がよくお使いになるという、パスワードを順番におっしゃって下さい。」
おいら「いや、そうじゃなくて、銀行とかいろんな所のパスワードを口頭で伝えろと？」
サポート「ええ、私からパスワードを申し上げることは出来ませんので」
おいら「もっと、たとえば、そちらでログインロックを解除してもらって、私の方で色々試すとかできないですか？」
サポート「できますよ？」
おいら「すみません、まず、それでお願いします。」
～でしばらく思いつくパスワードを入れて歩く～
おいら「やっぱり駄目ですね。ロックされてしまいました。タイプミスか何か登録時に自分がしているんだと思います。」
サポート「そうしましたら、どうしましょう？」
おいら「パスワードの再発行はできませんか？」
サポート「できません。お電話で、パスワードは伝えられませんので。」
おいら「いや、パスワードを口頭で伝えるのは絶対にナシだと自分も分かります。郵送でも良いのですが」
サポート「あ、それならできますけど、お時間かかりますよ？」
おいら「すみません、それでお願いします。」

もはや、どこから突っ込めば良いやら。

ユーザー登録後、料金明細を見る機能を初回利用する際に、
ID/PASSの変更が求められますとは記載があったけど、
それをしないと、パスワードリマインダーが使えないならば、
会員登録のフローとして、初回ログインまでしっかりやらせるべきだろ・・・

そこは、50歩譲っていいとして、
「おまえの知っているパスワードを全て答えろ」というのは
通信会社のサポートとしては致命的だろ（汗

実は、未だ＜続く＞

昨日の続き。

某、通信会社のサポートでの先週～今週の問い合わせ事例。

■前振り
この会社、請求書はWebで確認するんだけど、
どうがんばっても、確認サイトにログイン出来ない。

そうこうしているうちに、ログインロックがかかってしまった。

ログインロック画面には
「ロックを解除するにはパスワードリマインダーを使用して下さい」
と言う記載があったので、パスワードリマインダーを実行。

氏名と、生年月日と、電話番号と、登録したメールアドレスと、顧客IDを入れて送信
↓
契約が確認出来ませんでした

( ﾟдﾟ)ﾎﾟｶｰﾝ

何度か試してみる
↓
「何度も間違えているためこの顧客IDのパスワードリマインダーを停止しました」

( ﾟдﾟ)ﾎﾟｶｰﾝ

そこで、ユーザー登録に電話したわけです・・・＜続く＞

今日は、色々忙しくて出来なかった、いろんなサポートへの連絡を一つ一つ潰す。

その中で酷かったサポートの事例を2つほど掲載。
まず今日は、某マルチメディアソフトのメーカーの例。

某ソフトの技術サポートに昨年10月末から何度か連絡を入れている。
けれど・・・一向に返事が無い。

このメーカー、時期によってサポートの対応が乱高下するんだよね。
たぶん、細菌だとこの10月頃のサポートが一番酷くて、
サポートに連絡しても梨の礫、のれんに腕押し、糠に釘。

そんななか、先日、このメーカーのサポートフォームが、
外部委託になったのに気がついたので、再度問い合わせを送ってみたけど、
回答ちゃんと来るかなぁ・・・

ちなみに、過去にこのメーカー(の当時の日本代理店)は
・問い合わせフォームの入力はユーザー登録必須
・問い合わせフォームに、ユーザーID・PASSの入力必須
・PASSを3回間違えたら、そのユーザーは不正コピー利用者としてサポートを打ち切ります。
という酷い規約でサポートサイトを運営していた。
なんだかなぁ～

いくら何でも、忙しすぎるわ。
体調も芳しくないわで。

不定期更新にしたいと思います。

以上、業務連絡でした。

伯母の家からすぐ近くに、
良い入札物件が出たので、入札をしてみた。

最低落札価格の２割増しぐらいで。

過去の、この地域の入札状況を見ても、
不落ばかりだったので、いけるかなーと思っていたら・・・

応札者８名で、自分たちは落札できませんでしたorz

やっぱり、過去の物件と違って建物有りというのが以外と効いたようで、
あの地域は国立公園内だから、建築許可とか大変。
住民では無く、法人とかだと特に大変なので、
そのあたりもあって、応札者が結構いた者ではないかと推測。

というか、最低落札金額の7倍で落札って
いくら何でも太刀打ちできません＞＜

あ～がっくし。

「変数に型は無い」はメリットか？
http://developers.slashdot.jp/story/13/03/01/0228235/

./ネタが続いて申し訳ないけど、非常に論争になるこの話題が./に載っていた。

自分は、変数に型があるべき派。

確かに、小規模なプログラムならば、変数に型があるのは煩わしいのはわかる。

でも、型をしっかり管理した方がエラーが事前に見つけやすいと自分は思う。

特に、業務案件でこれは大切。
書いているそばから型がおかしいと言われれば、直すわけだし。
一度完成したプログラムを修正したら、芋づる式に、影響範囲が分かって、修正漏れが無い。

いや、逆に、型が無い言語は、ちょっとした修正も、プログラム側が勝手に推論して、
恐らく正しいと思える動きをしてくれるから楽だろうという意見もわからなくはない。

でも、それって、言語の型の推論機能が優秀なだけで
たまたま動いているんだよね？
優秀というか、たまたま、自分が望んだ通りに動いただけだよね？
と思っちゃう。

そういえば、某Webサービスからデータを取り出すときに、
WSDLを喰わせて、それを元に最終的にDBに格納する処理を、C#とPHPで書いたけど、
そのWebサービスのとあるデータが数値型から文字列型に変わったことがあった。

C#は、WSDLを喰わせなおしただけで、
コンパイルエラーが出て、その場所を重点的にチェックすれば良かったけど、
PHPだと、プログラムの仕様書から、影響範囲を調べるだけでも一苦労。
みたいなことも。

なので、自分は断然、型有り派です。

まぁ、プライベートでコード書くときには、
アセンブラレベルで書くことがあったり、
Cのライブラリを作ってC#から使うとかしたりもするので、
データがどうなっているかが分からないと
気持ち悪いという気持ちもあるのかも知れない。

./から：
RSA暗号の生みの親曰く「暗号化の重要性は薄れてきている」
http://security.slashdot.jp/story/13/02/28/0722256/

との記事が。

要するに、暗号化で全てが守れていた時代は終わっているので、
暗号化に代わる別の手法もどんどん考えないとね。とのこと。

RSAといえば、暗号化の世界では最後の扉とも言える、
公開鍵暗号方式の扉を開けた方式で、
非常に解読が困難な暗号化方式。

でも、個別攻撃などによって暗号化する前に攻撃されたりと言った部分や、
ソーシャルハッキングなどをすれば、暗号化は関係なく、情報は盗めるので、
暗号化がセキュリティーの全てでは無いわけだ。

とはいえ、他にどんな防御策があるのかと言われると、それはそれで画期的な方法は思いつかない。

でも、シーザーから始まった暗号の世界も、
次のステージに進む必要がそろそろあるのかも知れない。