保守

iモードIDについてその後

kox@wankuma.com — Fri, 18 Jul 2008 14:14:00 GMT

前回のエントリの後、ちょっと調べてみました。

このiモードIDはSSL通信では付与されないIDですので、

iモードIDを取得する際に流れるデータは暗号化されていないことになります。

mixiではこのiモードIDを導入していて、固体識別番号と併用して使用しているようです。

iモードIDを使用しているサイトがそこら辺にあると考えたほうがよさそうです。

miixを含むケータイWebで多く見られる「かんたんログイン」などは、

iモードID（など）を認証に使用することで実現しています。（mixiの場合は固体識別番号と併用）

このことから自分のiモードIDが他人に知られてしまった場合に、

なりすましによるサイトログインも可能な状態になってしまいます。

（実際には固体識別番号やキャリアIP制限などを併用することで、難しいことだと思いますが

それをユーザが知る術はありません）

日本のインターネットが終了する日

kox@wankuma.com — Wed, 16 Jul 2008 19:10:00 GMT

ネタ元：日本のインターネットが終了する日

ネタ元のエントリはかなり長く難しい内容になっているが、

重要なことが書かれているため一読しておくことをお勧めします。

ここで簡単に説明することもできるとは思いますが、

高木さんの趣旨が伝わらないことを懸念して、あえて説明しないでおきます。

それを踏まえた上で。

iモードIDはデフォルトで「通知する」になっていますので、

ユーザが知らないうちに、既にiモードIDが取得されているかもしれません。

危険だと思う方は今すぐにでも「通知しない」設定にするなどの対応が必要です。

単体テストぐらいやろうよ２

kox@wankuma.com — Thu, 10 Jul 2008 22:09:00 GMT

前回のエントリ後、粛々とテストをしていましたが、

案の定、予定より遅れて完了しました。

テスト中に発覚した仕様洩れ、デグレード、単純ミスなどなど。

一定以上の品質を保つためには、こまめなテストは不可欠です。

もちろんバグを出すなとは言わない。

しかし「バグは出たら都度直せばいいんでしょ。」なんて考えでいてもらっては困ります。

何故そのバグが発生したしたのか、どうしたらバグを減らすことが出来るのか考えてもらいたい。

分業

kox@wankuma.com — Wed, 21 May 2008 15:17:00 GMT

今の現場は、インフラ部隊、セキュリティ部隊、開発部隊など、
その役割が完全に分業されています。
ある意味楽ではあるのですが、横のつながりが希薄なため、
いざトラブルが発生した場合にタイムロスになってしまいます。

保守している立場ではこのタイムロスが命取りになる場合も多く、
この体制はなんとかならんかなぁと思っています。

分業することのメリットは十分わかっているつもりですが、
以前の現場ではほとんど自分ひとりで対応してきたこともあり、
（運用部隊はいたので完全に一人ではない）
分業体制になれておらず、面倒だなぁと思う今日この頃です。

セキュリティ意識

kox@wankuma.com — Mon, 12 May 2008 16:08:00 GMT

まとまりきらない&答えにならないグズグズなエントリ。

開発者であってもセキュリティ意識が低い場合が少なくない。
スケジュールに追われ、考えている余裕がないのかもしれない。
表に見えにくい部分でもあるしテストも難しいからかもしれない。

声高に言っても、現場まではなかなか伝わらない。

ほとんどの場合は、特別なスキルを要することなく、
ちょっとした手間と、常に意識することで回避することができるにもかかわらず。

大変なのは常に最新の動向を捉えておく必要があること。
今まで大丈夫だと思っていた実装方法が、
いつ何時「穴」になる可能性もあるかもしれない。

セキュリティ意識を持たせるにはどうしたらよいのか？

24時間365日サポート

kox@wankuma.com — Mon, 21 Apr 2008 21:55:00 GMT

しっかりとまとまっていないのですが、忘れないように
中途半端な状態でUPします。
こういうのもBlogならで、いいかもと思いました。

運用・保守という作業は、開発があれば必然的に発生します。
運用・保守がなくなることは考えられず、
会社にとって長期的で安定的な売上を見込むことができます。

そこで24時間365日のきめ細かいサポートをすることはできないか。
ということを考えてみます。

24時間365日常時対応するとなると、最低7･8人必要になります。
・1日3人超（24時間=3人*8時間だが引継ぎ時間など加味する必要がある）
・土日のことも考えるとさらに数人が必要
ということは、単純に月700万程度の人件費がかかることになります。

月700万の保守費用は1案件で賄うことはできないので、複数案件を掛持ちする必要があります。
複数案件の掛持ちになると、同時にトラブルが発生する可能性が出てきてしまいます。
きめ細かいサポートを行うためには人員を増やす必要が出てきてしまい、
さらに人件費が増すことになってしまいます。

こうして考えてみると
24時間365日サポートは非現実的で収益モデルとして成り立たなくなってしまいます。
どうにか、24時間365日サポートの収益モデルを確立したいなと思っています。

いろいろ案はあるのですが、まとまりきれていません。

Yahoo!'s Latest Performance Breakthroughs

kox@wankuma.com — Wed, 26 Mar 2008 17:58:00 GMT

Yahoo!DeveloperNetWorkBlogにて

Webサイトのパフォーマンス向上させるための資料が掲載されていたのを見つけたのでメモ。

改善箇所は既存で14種類あったようで、さらに20種類追加された模様。

#YSlowというチューニング用のツールの存在も知らんかった。

既存の14種類のうち13種類はパフォーマンス・チューニングBlogにて既に翻訳されている。（感謝）

if条件判定はどちらがよい？（その２）

kox@wankuma.com — Fri, 15 Feb 2008 18:03:00 GMT

ネタ元：if条件判定はどちらがよい？（以前のブログエントリ（古い））
　　　　：文字列をequalsで判定する時(@IT)

いままで、僕は以前のブログに書いてあるように、
if(変数.equals("定数"))
のほうが、
if("定数".equals(変数))
より保守の観点では優れていると思っていました。
しかし、この考えが120度くらい変わってしまったので、
再エントリをすることにしました。

どちらのケースでも
nullの対応がきちんと行われているのであれば、それほど問題となりません。
しかし実際にはnullの考慮をし忘れて、不具合となるケースが少なくありません。

以前までの僕は、以下のように考えていました。
if(変数.equals("定数"))
を使用していれば、その箇所でNullPointerExceptionが発生するため安全です。
if("定数".equals(変数))
を使用してしまうと、nullの場合に処理をしないだけなので、
処理は正常に動作し、最悪の不具合の場合にはデータの破損や、
不具合箇所の特定が困難になります。

そして以下が考えを改めた理由です。
単純に
if(変数.equals("定数"))と使用していれば、
上記のようにバグはその時点でNullPointerExceptionが発生し問題ありません。
しかし多くの場合は、
if(変数!=null && 変数.equals("定数"))
と書かかれています。
まるで、枕詞のように頻繁に。
であるならば、
この書き方は、
if("定数".equals(変数))
と等しく、以前までの僕が懸念してきたことは、
まったく意味のないものとなってしまいます。

どちらの場合でも同じような懸念が残ってしまうのです。

意図的に
「変数!=nullを使わないようにし、変数.equals("定数")のみで記述するようにすれば・・・」
とも思いましたが、
そもそも意図的に「変数!=nullを使わない」部分に気をつけるのであれば、
「null時の対応を考慮し忘わすれない」部分に気をつけるべきなのだろうと考えました。

if(変数.equals("定数"))と
if("定数".equals(変数))を
比較したとき、
今までの考えと変わらず前者が安全だと思っています。
しかし
if(変数!=null && 変数.equals("定数"))と
if("定数".equals(変数))を
比較したとき、
後者のほうが分かりやすいと、僕は考えます。

考えた末出した結論は、
ケースバイケースで。
・・・
・・・
結論になってないですね。

どちらにしろ、この手の記述がある際には
その状況などを考慮し注意する必要があるぞと、
胸の奥にとどめておく程度でよいかと思います。

IE7 ズーム機能におけるスクロールの挙動

kox@wankuma.com — Fri, 25 Jan 2008 16:45:00 GMT

IE7のズーム機能によりレイアウトが崩れることはよくあります。
大概の場合はIE7のズーム機能でバグる(http://gyauza.egoism.jp/clip/archives/2007/05/ie7-haslayout-bug/)で対応できます。
また、IE7.jsを使うことでも対応できそうです。

しかし、
スクロールがついているテーブルの挙動の制御ができません。
<div>タグ内に<table>タグが入った状態でのスクロールです。

  <div style="width:300px;height:100px;overflow:scroll;">
    <table style="width:500px;" border="1">
    <tr>
      <td>あいうえおかきくけこさしすせそ</td>
      <td>たちつてとなにぬねのはひふえほ</td>
    </tr>
    <tr>
      <td>まみむめもやゆよ</td>
      <td>abcdefg</td>
    </tr>
    <tr>
      <td>あいうえおかきくけこさしすせそ</td>
      <td>たちつてとなにぬねのはひふえほ</td>
    </tr>
    <tr>
      <td>まみむめもやゆよ</td>
      <td>abcdefg</td>
    </tr>
    <tr>
      <td>あいうえおかきくけこさしすせそ</td>
      <td>たちつてとなにぬねのはひふえほ</td>
    </tr>
    <tr>
      <td>まみむめもやゆよ</td>
      <td>abcdefg</td>
    </tr>
    </table>
  </div>

結果（拡大・縮小してスクロールしてみてください）

あいうえおかきくけこさしすせそ	たちつてとなにぬねのはひふえほ
まみむめもやゆよ	abcdefg
あいうえおかきくけこさしすせそ	たちつてとなにぬねのはひふえほ
まみむめもやゆよ	abcdefg
あいうえおかきくけこさしすせそ	たちつてとなにぬねのはひふえほ
まみむめもやゆよ	abcdefg

倍率100%以外にした場合、
縦スクロールに関しては正常に動くのですが、横スクロールはテーブルの罫線のみ移動し中身が移動してくれません。
（倍率を100%に戻すと元に正常に動作します。）現状で対応策を見つけることができませんでした。
何か方法があるのでしょうか？

ダウンロードファイル名の文字化け（実際にはServlet名になる）

kox@wankuma.com — Thu, 10 Jan 2008 11:25:00 GMT

担当しているサイトのダウンロード機能のファイル名は文字化けが起こっていたのだが、
IE7になり、いつの間にか解消されていた。

ダウンロードファイル名の文字化け自体は、かなり有名な話で対応策などはそこら中サイトで見つけることができる。
ちなみにファイル名は日本語ではない。

この事象が発生していたのは、
WindowsXP IE6 SP2がでて間もない頃の話。

通常は、ファイル名を指定したい場合に
　response.addHeader( "Content-Disposition", "attachment; filename=ファイル名 );
とする。
しかしこの対応策は取れなかった。
Content-Disposition: attachment でファイルをダウンロードするとフレームが更新されなくなる。
この障害に見事にマッチし、回避策もとることはできなかった。
エンドユーザの大半はまだIE6 SP2を使用しておらず、
このエラーはランタイムエラーが発生してしまうため、使用するわけにはいかなかった。

結果として
　response.addHeader( "Content-Disposition", "inline; filename=ファイル名 );
とすることにした。
この場合、WindowsXP IE6 SP2 よりも前のバージョンであればファイル名を取得できるが、
WindowsXP IE6 SP2以降はファイル名を取得できない。
圧縮さえかかっていなければファイル名を取得できるのだが、
データ量が大きかったため圧縮をかける必要があった。
そのため、「まあ大きな害はないよね。」ということでこのまま運用することにした。

あれから数年。
IE7となり、気がつけばファイル名が取得されるようになっていた。
めでたし、めでたし。

保守