アトピーがほぼ全快したのでメモ(閲覧注意!)

一時期かなりアトピーがひどかったのだが、今はほぼ全快し、誰が見てもアトピーには見えない状態まで改善している。病院で採血するときにもよく「肌綺麗ですね〜」と言われるくらいである。たまに少し痒くなってきたときにステロイドの塗り薬も使うが、5年で小さめのチューブ一本も使い切らないくらいの量である。

知り合いにもアトピーに限らずアレルギーで苦しんでいる人がいるし、誰かの役に立てば、ということで恥ずかしながら自分の写真もさらしつつメモする。悪質な業者のアフィリエイトブログ記事でないことを示すために、ソフトウェア開発が主題だったこのブログに載せてしまう。

(以下、アトピーの超汚い肌の写真があるので閲覧は自己責任でお願いします。)

症状が一番ひどかったのは2004年ごろ。今から20年近く前で、年齢としてはたぶん29歳くらい。24時間常に痒みが襲ってくる。肌からは黄色い汁が出てきて衣服がガビガビになる。ステロイドの塗り薬を毎日せっせと塗るがとにかく辛い。顔はつねに腫れ気味。床屋は痒くて座ってられないので長いあいだ髪も切れず、この写真の通り、だいぶ具合が悪い感じだった。

image1

↑ふくらはぎがかゆいのでカメラにピースしながら掻いてる。

もっともひどいときの肌の写真がこれ。↓

IMG_2173

当時、よくこんなの写真に記録する気になったな…と思うが、今となっては貴重な激闘の記録である。全身こんな皮膚で覆われていて、まともなところはない。

アトピーが悪化してくる中、なんやかんやダマシダマシ生活を続けていたのだが、好きな海釣りすら集中できなくなってしまった。ある日堤防の上でかゆみに対して「完全にブチキレ」て、「絶対にアトピーを治す」と自分の中で決意を固めた。釣りに集中できずに怒りが自分の中で頂点に達し、西伊豆の海辺を車で移動(帰宅)しながら「絶対に治す…絶対に治す…」と決意を固めた。そのときの記憶は未だ鮮明である。

その日からネットでひたすらアトピーに関する情報を収集した。悪質な業者のページからまともなお医者さんのページ、また2chなど、来る日も来る日もひたすらアトピー情報に目を通した。大量の情報を浴びる中で色々と共通のアトピー対策要素が見えてくる。例えば、揚げ物はあまり良くないとか。しかしそれらを実践してもそれほどは改善せず、しばらくは、「アトピーを治すと決心したものの何も改善しない」という日々が続いた。あちこちの皮膚科にも行ってみたが、どこもぱっとせず、親身になって相談してくれるところも少なかった。毎日シャワーを浴びるのが死にそうにつらく、機嫌も悪い日が続いた。文句ひとつ言わず、この汚い肌の僕を見捨てずに薬を塗るのを手伝ってくれたカミさんには感謝しかない。

転機となったのは友人の結婚式だった。真夏なのにディズニーの近くの開場で、なんと挙式は屋外でやるという。こちらは全身アトピーかゆいマンなので暑さは拷問のようにつらい。しかも半袖短パンならまだしも、スーツである。繰り返すが真夏である。本当に失神するかというくらい痒くて辛かったが、何とか屋外パートを乗り越えた。その後は冷房のきいた会場内での進行になったので何とかなった。

家から1時間30分くらいの距離の会場だったので、二次会も終わって家に着いたのは夜遅くだった。そこで異変に気づいた。何だか痒みがものすごく弱くなっており、また全身の肌の腫れがいつもよりだいぶマシなのである。何かアトピーを大幅に改善するためのヒントが、この日の行動に含まれていることは間違いなさそうだった。

その後色々と考えたり試してみたりした結果、自分が身につけていた服がソレであることが判明した。結婚式ということで、クリーニングに出してからそのままにしていたワイシャツとスーツで出かけていた。普段と同じ服は、パンツのみ(靴下もそうだったかもしれないが、忘れてしまった)。暑くて痒すぎて死にそうになることを予測し、ワイシャツの下に肌着は着ていなかった。この、「普段着ている服を(パンツ以外)身につけていなかった」ことが重要なポイントだったのだ。

実は、自宅の洗濯機の内部にカビが発生しており、そこで洗濯した服にそのカビがつき、そしてそのカビがついた服を24時間肌に触れさせていたことが、僕のアトピーの最大(割合で表現すれば95%くらい)の要因だったのだ!

結婚式の日に身に着けていた服は、パンツ以外はクリーニング屋でしか洗濯していないものだったのである。

このこと(洗濯機のカビが原因であること)を確かめるために、シャツ・パンツ・ズボンなどすべて新しいものを買ってきて、2〜3日まったく洗濯せずに着続けてみた。すると明確にアトピーが改善した。どんな塗り薬を塗ったときよりも強烈に、24〜48時間程度で明らかに体感できるくらいに痒みと腫れが引いた。これは間違いないな、ということで洗濯機を買い替え、服もすべて買い替えたところ、一気に全身が同時に治っていって、あっという間に塗り薬も不要になった。これが基本的にはこの記事の主題である。

これに気づいたので洗濯機はシャープの穴無しの洗濯機にしているが、それでもしばらく使っているとやはりどこかしらカビは発生するようなので、5〜7年くらいで肌の調子と相談して買い替えている。今もたまにアトピーが少し出てくるときはあるが、そのときは一度服を全部捨てて買い換えると、あっという間にまた治る。(この、少しアトピーになってきたな…というサイクルが短くなってきたら、洗濯機も替える)

食事や運動にも気をつかい、また酒もタバコもやらない等、生活習慣全般をアトピーを悪化させない方向にしているが、とにかく先述したように僕のアトピーの95%の原因は洗濯機のカビが洋服経由で肌に触れることであることは間違いない。インターネット上や医者からのアドバイスに「洗濯機のカビが原因だから、洗濯機か服を買い換えろ」というアドバイスはなかったというのがまた何ともアレである。自分で気づけたから良かったが、もしこれに気づけていなかったら地獄が続いていたと考えると恐ろしい。

この記事を読んでいる、自分や、あるいは身近な人のアレルギーを改善させたいと考えている人へのアドバイスを以下に列挙する。

アレルギーの原因は人によって様々なので、あなた(あるいはあなたの身近な人)のアレルギーの原因が僕と同じように洗濯機のカビである可能性はそれほど高くない。事実、僕と血縁が近い人物のアレルギーはこの方法では改善しなかった。洗濯機のカビが原因であるかどうかを切り分けするのは簡単で、単に安い服を一式揃えて、それを一度も洗濯せずに2〜3日過ごせばよい。(寝るときのシーツなども肌に触れるので、これも買い替えを考慮してもいいかも。)これで全然改善しなければ、洗濯機を買い替えてもおそらく無意味である。一方で、2〜3日で明らかな改善が見られたなら、洗濯機の買い替えも検討しても良いだろう。

原因を見つけると、突破の道が開ける。そのため、普段からかゆみの増減とその日の行動などを注意深く観察し、僕が結婚式で成功したように、「何がアレルギーのキーとなる要素なのか?」という視点を常に持ちながら生活するとよい。そして、候補が出てきたらそれを切り分けるための行動をとる。

原因を見つけるには自分の行動を常にモニタリングする必要があるので、自分しか出来ないと考える。医者などに頼らず、自分の頭をひたすら使おう。ダニ・カビなどが原因であることが多いと思うので、特にそのあたりを意識しよう。毎日、気温も天気も食べ物も少しずつ変化していくので、切り分けは難しいことを覚悟し、根気よく続けよう。こまめに記録し、思いついた仮説もメモしよう。

食事やサプリメント等の、食生活の改善などによっても痒みは結構違ってくる。僕の場合は果物を頻繁に食べていると明らかに痒みが増す。また、えごま油を日常的に摂取していると痒みが明らかに減る。先述したように基本的に僕は洗濯機が全てというくらい大きなファクターだが、一応下記のような生活習慣をして体調を万全に整えるようにしている。

  • 血糖値が急激に上がるとアレルギーに良くないので、糖質のみバカ食いしないようにする
  • GI値を意識した食事を心がける(とはいえパン大好きマン)
  • 食後にステッパーを踏んだり、自転車みたいなフィットネス器具で軽く有酸素運動する
  • サプリメントでビタミンB/C/D/亜鉛をとる
  • 週に2回ジムで走る
  • (上に書いたとおり)えごま油をとり、果物はたまにしか食べない
  • ヒスタミン摂取量を少なめにすることを心がける

この記事が誰かの役にたてば幸いです。

image3

AtCoderでアルゴリズムの勉強をして効率性でつまづいている

僕は四捨五入すると50歳になるおっさんであるが、いわゆる教科書的なアルゴリズムを真面目に勉強したことがなかったので、ちょいちょい本を読んだりコードで実装してみたりしている。

そしてAtCoderに流れ付き、少し時間を使って楽しませてもらった。といっても子供の面倒をみる時間が断続的に発生する生活なので開始時間が決まっている競プロのコンテストに出場するような形ではなく、過去問をのんびりと解くスタイル。

AtCoderを使わせてもらって本当に驚いたのが、この過去問で勉強するスタイルが無料で可能だということ。多くの言語がサポートされているし、他人の回答を見ることができる。同じ問題をまったく違うアプローチで解く人のコードを見ると面白いし、何より勉強になる。また、コードが消費する時間やメモリのリソースがかなり正確に計測されるので、こちらも実際の業務のコードを書く上で役に立つ。普通にかなり課金したいサービスである。

さて本題だが、ある程度AtCoderでやってみたのだが、壁にぶつかった。なかなか解けない問題で、なぜ解けないのかがわからないのだ。提出したコードが最初の3つくらいは問題ないが、そのうちTLEとなってしまうようなパターンが多い。おそらく根本的に別のアルゴリズムで計算量を少なくする必要があるのだろうが、このTLEとなる際の入力が秘密の情報であるため、それを推測してみて自分のコードで試す、というサイクルがなかなか廻せない。

僕はもう20年以上仕事でプログラミングをしているが、いわゆるデバッグ作業では、再現性があればかなり楽だが、再現性がないともう諦めたくなるくらい難しくなる。いわゆる「エスパーする」みたいなノリになる。

AtCoderで自分のコードが途中でTLEになるのは、僕の印象では「再現性がないデバッグをしている」ような形になる。手元で、そのアルゴリズムが遅い状態で動かせないのだ。

もちろん頑張って想像し、問題を起こす(TLEになる)ようなデータを自分で探り当てることも何度かやったが、異常に時間がかかってしまうし、心が折れやすい。

ということで、以下のような僕にとって都合がよいアルゴリズム勉強サービスを探している。

  • 自分のコードをアップロードすると勝手に動いてくれて採点してくれる
  • テストが失敗した場合はその入力を見ることができる
  • Javaで提出できる(w

だれかそういうの知ってたら教えてください…

あるいは、サービスではなく、手元のマシンで動かすような問題集(データを自分でダウンロードするようなもの)でもいいかも。

『Wizard Bible事件から考えるサイバーセキュリティ』執筆プロジェクト について

こちらの件、無事にクラウドファンディングが成立したとのことで、おめでとうございます(私も1部購入しておきました)。

ここで取り上げられるであろういくつかの事件について、僕はざっと見た程度で細かく情報を確認はしていないけれど、何人かの方が警察によって(おそらく不適切な形で)精神的にひどい目にあわれたことについて、非常に残念なことだったと思います。

事件の当事者以外のIT技術者(僕も含む)にとっても、特にセキュリティ関係の情報発信をしている人からするとまったく他人事ではなく、簡単に言うと「怖い」状況があるために、クラウドファンディングが成立したという側面もあるだろうと思います。

僕個人の話では、かつてはWizardBibleに大量に記事を投稿させていただいていましたし、今もScutumやVAddyというセキュリティサービスにおいて、主にブログの形でセキュリティ技術の記事を投稿しています。やはり上記の事件を受けて情報発信については非常に慎重になりましたし、会社でも「こういうブログ記事を投稿すること自体はどうだろうか?」といった会話をしたこともあります。

さてここからが本題です。うまく書いて僕の意図を伝えることができるかどうかが心配ですが、書いてみます。

『Wizard Bible事件から考えるサイバーセキュリティ』を書く方に、下記の視点も持って、可能であれば取材して欲しいという点があります。非常に難しいと思いますが。

上記の一連の事件をうけ、「ちょっと乱暴すぎるのではないか」「これはあまりにも強引なこじつけだろう」といったIT技術者を中心とした大きな(警察に対する)反発がありました。そしてその後、同様の事件が減ったように見えます。(本当に減ったのかどうかは私の情報収集能力ではわかりませんが)

仮に減ったのだとすると、やはり警察内部でも、それなりに世間のフィードバックを受けて冷静な判断がなされるような変化があったのではないか。もしあったのなら、それは前向きなものであると思うので、評価してもよいと思います。

もちろん不適切な形で警察に逮捕されたりひどい目にあった人は「警察憎し!」という感情になるのは当たり前なので「警察についてよい評価をする」というのはものすごくイヤだと思います。しかし誰かこの執筆プロジェクトにおいて警察組織のなるべく上のポジションにいる人から、この「変化」があったのかどうか、あったのならばどのような形なのか(トップダウンで指示があったのか、あるいはそれぞれの組織のレベルでそれぞれそういう方向になったのか)等についてインタビュー等をしてもらえると、非常に面白いだろうなと思います。

サイバー犯罪は本当に悪いやつらが跋扈しはじめており、一方で警察もたまにすごいレベルの捜査と検挙を行っているケースを見るようになりました。最終的には日本国内のIT技術者と警察の間のギャップが埋まり、お互いに協力して使いやすいインターネットが実現されることが理想なので、この執筆プロジェクトがその方向にもうまく作用するようなものになれば最高かなと思います。

ということで書いてみました。あくまで個人のなんとなくの考えを書いただけなので、適当に読み飛ばしてください…

 

 

 

Ubuntuバックアップの理想形に到達した

メインの開発マシン(Ubuntu20.04LTS、GNOMEデスクトップ環境、主にEclipseでJava開発)のバックアップがようやく理想形にたどり着いた。

Linuxにおけるバックアップという概念はそれこそ何十年も前から存在するが、今回到達したのは商用ソフトウェアのVMWare Workstation(2万5000円くらい)を使う、少し亜流な方法である。

このバックアップで想定する障害は、下記のようなもの。

  • 単体のストレージデバイス(SSD)の物理的な故障
  • 誤操作による意図しないファイル、データの消去/上書き
  • 誤操作や意図しないソフトウェアアップデートによってOS等が起動しなくなる障害

想定しない障害は下記

  • 同時に複数のストレージデバイスが物理的に故障する(地震や火災でPC全体が壊れるような状態)

内容を簡潔に書くと、下記のようになる。

  • ゲストOSを作成し、そこにホストOSのデータをコピーする。
  • ゲストOSとして起動できるようにする(/etc/fstabの編集など)
  • ゲストOSを停止した状態で、仮想ディスクをホストOSにマウントする
  • 任意のタイミングで、ホストOS上でrsyncにより差分バックアップを取る
  • たまに、仮想ディスクをアンマウントし、ゲストOSとして起動させ、システム全体として稼働できる状態が保たれていることを確認する
  • ある時点のスナップショットを取りたい場合には、VMWareのスナップショット機能を使う
  • バックアップ全体をさらに(スナップショットも含めて)バックアップしたい場合は、ゲストOSが存在するディレクトリをまるごとどこかにコピーする

この方法のメリットは

  1. rsyncを使うので、差分バックアップとなり、軽量
  2. rsyncを使うので必要な場合の小回りが効く
  3. 任意の時点のスナップショットを取ることができる
  4. 基本的にはデータが1ファイルに入っており、物理デバイスにそのままddすることでリストアできるものであるため、将来的にVMWareの使用をやめるとしても大きな問題はない(スナップショット関連機能は失われる)
  5. シンプルである
  6. バックアップされたデータがシステム全体として整合性を保ち、起動・稼働できる状態になっているか、をバックアップ対象となるメインマシンの上で手軽に確認できる
  7. 大きめのソフトウェアアップデートなどについては、まずゲストOS上で先に適用して、問題ないかを確認できる。確認後はその状態を破棄して適用前の時点(スナップショット)に戻すことができる
  8. ホストOSにマウントできるので、任意のファイルのみ復旧させるなども容易

(7については、もはやバックアップの仕事ではないが、とりあえず出来るということで)

上記のメリットのうち、個人的に最も重要なのは6。システム全体のリストアのテストを、1台のマシン上で、超簡単な操作だけで、ほんの1〜2分で行うことができる。今まで色々なバックアップ方法を試してきたが、これを達成できるものには巡り合っていなかった。

この方法のデメリットはほとんど無いが、強いてあげれば下記の2点。

  • VMWareを買う必要がある
  • バックアップ先が圧縮されないので、バックアップ対象より少し大きいくらいのストレージ領域が必要

具体的な方法は細々とは書かない(興味があるひとがいたら@kinyukaに質問してください)が、下記の点がポイントになる。

  • 最初はフルバックアップをデバイスイメージ全体に対して行うので、バックアップ対象のデータのサイズは、別デバイス上に配置可能なサイズにする必要がある。(まぁ、当たり前だが…)
  • バックアップ先はもちろん、別の物理デバイスにする
  • バックアップ先のVMWareの仮想ディスクは、preallocatedな単一のファイルにする。これによってVMWareが使えない状態になっても(普通はならないが)単にファイルをddでデバイスにコピーするだけで復旧が可能になる
  • ゲストOSとして起動できるようにするため、/etc/fstabはバックアップ対象外とするか、uuidを記述しない形にする(詳しくは書かないのでそのへんはググってくだちい)

それでは皆様、快適なバックアップライフを。

二分探索木の平均探索回数(失敗時)に関するメモ

Isolation Forestの論文に出てくる

c(n) = 2H(n-1)-(2(n-1)/n)

を理解するためにあちこち調べて苦労してしまったのでメモ。

これは二分探索木の平均探索回数(失敗時=外点に到達)を意味している。そのため二分探索木について詳しく記述されている文献や発表資料を見ると、あちこちで証明つきで説明されている。

結局僕が理解できたのは日本語書籍の「アルゴリズムの基礎とデータ構造」のおかげ。Isolation Forestの場合には内点と外点の数え方の関係なのか、上の式は右側がn-1を中心に構成されている。仮に1つずらしてn-1をnとした場合には

c(n)=2H(n)-(2n/n+1)

となる。そしてこれは「アルゴリズムの基礎とデータ構造」で導出される

c(n)=2H(n+1)-2

と同じである。

この式の導出には「アルゴリズムの基礎とデータ構造」のP.99上の方にある

c(n+1)=c(n) + 2/(n+2)

という式がキモになるのだが、この式に至る過程は(この書籍に紹介されている以外のものも含めて)結構面倒くさい。

しかし実は上の式は直感的に理解できるので、その内容をここにメモしておく。

c(n)はn個の内点から構成され得るさまざまな形の、すべてのパターンの木におけるすべての外点のパス長の平均値である。上の式に出てくるのはどちらもcであるので、平均値についてのみ考えればよい。

n個の内点から構成される木(Tnとする)がn+1個の内点から構成される木(Tn+1とする)に変わるときには、Tnでは外点だったある1つの点(vとする)が内点に変わり、さらにその内点に2つの外点がぶら下がることになる。

前述したように「平均についてのみ考える」ことにする。実際には根に近い(浅い)ところにいる点も、深い所にある点も存在しているのだが、それらを全て仮の平均化、均質化された世界に移して考えてみる。するとTnのすべての外点のパス長はc(n)である。このうちの1つがvである。

Tn+1では、vは内点になってしまったが、その内点の先に2つの外点がある。この2つの外点のうち1つは、Tnで外点だったvが移動した先だと考えよう。すると平均値+1の長さの外点となる。もう一方の外点はnがn+1になった際に追加された外点だと考える。こちらもvと同じように平均値+1の長さの外点である。(ここでの平均値はTnについてのものであり、Tn+1ではない)

この2つの外点以外の全ての外点は、まったく長さが変わっていない。つまりすべての外点について平均からの変動を考えると、全体で2だけ増えているのである。

この「増えた2」も平均値として考える場合は全ての外点において平均的に増えたと考え直す必要がある。そのため2を外点の数すなわち「n+2」で割った2/(n+2)が、その差となる。

つまりc(n)に2/(n+2)を足したものがc(n+1)になるのだ。

おしまい。

XBOS Anomaly Detection

What is XBOS?

Cross interaction based outlier score (XBOS) is a cluster-based algorithm for unsupervised anomaly detection. It uses k-means clustering for the first stage, and then calculate cross interaction between clusters as the second stage. Because of this second stage, A small cluster near another large cluster is treated as if that is a middle cluster, so that the data points belong to the cluster is scored ‘not so anomalous’ as a result.

XBOS assumes independence of the features as same as HBOS. XBOS shows very good performance on Kaggle credit card dataset compared to Isolation Forest and HBOS.

kaggle1.png

XBOS is a really simple algorithm and implemented in just 55 lines of Python code.

Source code is available at GitHub.

Stravaヒートマップで米軍(?)の裏道ぽいの

Stravaのヒートマップが面白い。筆者は横浜市港南区在住で、たまに鎌倉・逗子・田浦あたりのハイキングに出かける。神武寺駅の北側にはいい山があるのに、米軍施設であるため探索することができない。

山レコの地図でこのエリアを見てもらえればわかるが、基本的にハイカーがこのエリアに入っている様子は無い。

Stravaでみたところ、どうやら米軍関係者にも山を愛するものがいるようで、下図の紫の矢印の2つの裏道が存在するようだ。どちらもハイキングコース(紫矢印の上、斜めに地図を横切る、やや明るいオレンジのライン)に到達している。実に興味深いw

繰り返しになるがこの2本のラインは山レコ登録者が通っている形跡はない。

この2つの道に一般人が入ると、おそらく怖いひとに怒られるのだろうと思う。今度、合流点がどうなっているのか気にしながら歩いてみようと思う。

strava_ikego

単純なラベルよりもスコアや確率で表現する方がよい…説

いわゆる教師有り学習の「ラベル」は、例えば

  • このインスタンスはクラス2です
  • このインスタンスはクラス3です
  • このインスタンスはクラス3です

という形で与えられる。これは一般的なので皆あまり疑問に思わなくなってしまっているかもしれないが、実は情報量としてはかなり少ない状態だ。

  • このインスタンスは明らかにクラス2です。
  • このインスタンスはクラス2に近いが、クラス3です
  • このインスタンスは明らかにクラス3です。

という形の方が、より情報量が多い。

普段ベイジアンネットワークを使っていると「迷いのない状況」と「迷う状況」が確率の値として出てくるので、個別にチューニング等がうまくいっているか(=モデルが良くできているか)を把握しやすくかなりいい。
そのため、前者のような「単純なラベルのみが付与されたデータに基づくデータサイエンス」が圧倒的に良く使われている状況に疑問を持っていた。もっとスコアや確率的な情報が与えられる方が良いのではないか、と。

今日偶然アノマリ検知について調べていたら

http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0152173
の「Anomaly Detection Algorithm Output」の項目で(つまり正確には教師有りデータのラベルではなくモデルの出力に関する項目だが)

First, a label can be used as a result indicating whether an instance is an anomaly or not. Second, a score or confidence value can be a more informative result indicating the degree of abnormality.

という記述に出会うことができて、自分がモヤモヤ思っていた事が間違いではなかったと確信できてよかった(興味ある人はこの項全体を読むことをオススメ)。