変奏現実

６００ｇとちょっと重かったi padが3割もダイエットしCPUもパワーアップすることになった。
モニタ解像度も　2,048 × 1,536　と　ぐっと細かくなっている。
日本では５万１８００円から　と、旧製品より１万円高くなる予定。
なんと云うか
ステイタス・シンボルっぽいブランドになろうとしているようだ。
故人の恩恵にあやかろうとすれば・・・
価格を上げるのは普通なのかもしれない。
だが、
本当のところ、安いデバイスでサービスを拡大していく路線はかなり厳しい。
本当に安いチップは性能も半端なく劣るし、記憶容量も少なく、アクセス速度も遅く、そして寿命も妙に短い。
だから、ユーザの不満（おっそい、電池がすぐなくなる、電波が途切れる・・・など）を打ち消すようなスペックのデバイスを発売すれば
大抵は価格が上がってしまう。
それに閉口しだすと、そこそこのものがそこそこの値段で出てくる。
要は、その時々の売れ筋次第なのだ。
 
ただ、おねだりばかり口にしていると、超高級品ばっかりになってしまうのが、e-コマースの最大の弱点である。
 
 
 

そうしているが、やはり、覚えきれるわけがない。
どっちかと云えば
面倒になってしまい
「いつものサイトだけ買い物する」ようになるだろう。
つまり、これは実質的な

既成e-コマースサイトの囲い込み策

である。
最近はアカウントのアタック騒動が多いと思っていたが
そういう裏があったと思えば納得できる。
 
クラウドビジネス真っ盛りなので
アカウント・アタックを仕掛けても大した金はかからないハズだ。
だが、儲けがないなら、やるだけの意味はない。
そこが不思議だった。
 
それは、コンピューター・ウイルスをどんどん作ってる輩も同じ。
最初は趣味でやってたのかもしれないが、それでは、当の昔にさびれているはずだった。
だが、軍やら諜報組織が裏に付くようになり今でも盛んにやっているようだ。
 
そう、裏に何かが付いているハズ。
そう思ってた。
 
やっと、判った。
 
ま、呆れた話ではあるけどね。

質量を与える挙動を見出すのは大変らしく最近まで発見されなかった。
よくヒッグズ粒子は素粒子の行く手を邪魔をする。＝移動速度の制約＝質量の発生。と説明される。
だが、よく見てみれば、おかしな絵だ。
最初に一回だけ邪魔をすれば、運動量が保存されているハズ（？）なので、移動速度は確定する。
そう何度も何度も素粒子の行く手を邪魔する必要はない。それでは素粒子は勝手に減速して静止してしまうではないか？
という疑問が生じる。
まず疑問に対する自問。
運動量保存はどうやって成り立っているのか？
もしかすると、ヒッグス粒子が邪魔しつづけないと、すぐに素粒子は光速度までスピードを上げてしまうのかもしれない。（大笑
ありえない現象な気もするが、ヒッグス粒子が充満する空間でしか生活していないので、ヒッグス粒子が存在しない空間での素粒子の振舞は想像するのは難しい。
物質界での速度は構成要素（素粒子）の総体の速度（個別の素粒子の移動ベクトルの合計）なので、０から光速度まで幅があるが、もしかすると、本来、素粒子単体（宇宙の最小？の構成要素）の速度は光速度しかないのかもしれない。
その結果、ヒッグス粒子の力場を光速度でくぐり抜けるだけのエネルギーが必要になり、ヒッグスと相性が悪い素粒子はそれだけエネルギーが必要になり、結果として反応が鈍い＝質量ということになるのだろう。
もっとも、このモデルには無理がある。１０ｇと１００ｇの球体を正面衝突させた場合の結果をまったく証明できない。
例えば、2個の原子の塊（電子雲の一部を共有している）と1個の原子が正面衝突したとしよう。
２個の原子核の周囲の電子雲の電荷は2倍あるので電子雲はあまり変形せず、1個の原子の方の電子雲の方が大きくゆがみその形を復元するクーロン力で自らはじき出され、結果として1個の原子の電子核も移動速度を上げて遠ざかることになるが、両方の原子核の1個あたりの質量が同じなら計算式上は両辺にかかってくるので、原子核の質量は相殺され結果質量の影響は０。この現象に介在するのは電子雲の持つクーロン力だけで、ヒッグス粒子の存在を感じることはない。つまり存在していない様に見えるのだ。この辺が質量の無量間が強いものの、何かの変化（変な反応）が見つかればヒッグス粒子の発見（確率はかなり低いが目立つから）につながりやすい。
次に、質量の異なる原子同士の正面衝突を考えると、原子核の質量というより周囲に何層もある電子雲の重厚さがものを云うし、１電子当たりの原子核の質量の割合が一定なら、質量そのものの出番はやはり無いのだが、原子核には陽子の他に中性子もあるとされ、原子番号が大きい原子ほど中性子も多いので、やっと質量の出番が回ってくる。衝突が終わった後（電子の雲が向きを変えたあと）に電子が原子核の方向を変える（引きずる）難儀度としてやっと質量が出てくるわけだ。電子曰く「何で俺だけ、あいつより重い原子核を押し戻さないといけないんだ」と云うつぶやきこそ質量なのだ。
この様に古典的な物理現象（衝突や移動など）の反応は大方が原子核の周囲を回る電子同志の話し合い（反応）で方が付くため、本当のところは質量は直接には介在しない（衝突の後の反応にからんでくるだけ）。そして物質の重量を計測しやすいので単に質量の目安として使われているのだ。
こう書くと身も蓋もない感じがするが、質量が絡む物理反応（物質同志の衝突など）と重量が絡む物理反応（地球の引力など）は全く違うものだ。しかし、おおむね物理での質量は実際には重量を意味するし、詭弁と云えなくもない。だが、その質量と称する重量によって正面衝突の結果が大体予測できる（軽い方が跳ね飛ばされる）ということに間違いはない。
ヒッグス粒子の云うところの質量は静止質量という素粒子の反応に限定した特定条件下での質量で、何トンなどの大質量（多数の素粒子の総体）としての質量は説明できていない。
つまり、ヒッグス粒子は物質界にとってはほぼ無縁、実態は短命な中間子の一つと考えた方が無難だ。
但し、分子の構成（電子雲の動き方）が変わる場合はかかわってくる（電子のエネルギー変異があるから）ので、全く無縁という訳では無い。
 

X-FRAME-OPTIONS

を設定すると、
WordPressの「画像の編集」の画面が真っ白になる。
と云うことは、「画像の編集」は別ドメインということになるのか？
実は、URL無しで中身を書いても、やはり真っ白になるようだ。
なので有害な設定でしかないので

X-FRAME-OPTIONS

は外すことにした。
でも気になるので、
Header always append X-Frame-Options SAMEORIGIN
で妥協。
ところが、FF14用のサイトは変化なし。
ＩＥで見てみると設定がまだどこかに
Header always append X-Frame-Options DENY
が、残っているらしい？
# find /****/****/****  -type f | xargs grep -i x-frame-options
で、検索してみると、ココもFF14も
function send_frame_options_header() {
@header( ‘X-Frame-Options: SAMEORIGIN’ );
}
が出てきた。バージョンアップでWordPressが自発的に付ける様になったらしい。
だが設定は同じハズ。（謎
 

仕様書を読むと
テーブルとフィールドの名前のオンパレードってことが多い。
どうやらER図が原因らしい。
ER図とはテーブルを縦長の矩形で表し、従属関係を線で記入して、まとめた表だ。
本来はDB管理やプログラマが扱えるテーブルを扱いやすい形にまとめたものなのだ。
しかし、これが一人歩くしはじめると・・・
図にはテーブルしかないので、勢い外部設計書は、コレばっかしってことになる。
そして残念なことに、アレとコレとソレを組み合わせて、更にAとBを除外し・・・
とか馬鹿なコトを書いてある仕様書がはびこることになる。
 
そのくせインデックスの指定は一切無い。
いったいコイツの頭の中はどうなっているんだ？
これでは、テーブルは早々にインデックスでグルグル巻きにされてしまうではないか！
 
まず、
外部設計書とは

何をしたいのか？

と云うことを書くものだ。

テーブル云々なんてどうでもいいのだ。

• やりたいコトはコレです。
• こんな操作をしたら
• こんな結果が欲しぃ。

 
これが外部設計書のハズなんだ
そうしないとｘｘｘ画面って名前を付けるだけで安心してしまうんだ。
 
この時点でプロジェクトが、どっちを向いているのか
おおよそ察しが付くものである。（大笑
 
テーブル？
 
そう云うものは・・・
 
ミドルウェア、すなわち、インタフェース（I/O）仕様上の話だ。
その中身がお粗末ならデータベースから組み替えないといけないのだから・・・（大笑
 

このサイトの閲覧者の半分は
google検索で間違ってココのリンクを押した人が多いようだ。
TOPページは45.7 KB (46,863 バイト)と結構でかい。
一応WordPressがスマフォ対応しているので以前に比べれば軽くなってはいる。
といってもデフォの軽いテーマになってるだけ
Multi Device Switcher
も、入れてみたが効果なし。

Strange Little Town

の作り方のせいで、うまく働かないのだろう。
 
 

開発のスケジュールを見ると結構余裕あるな？と思ってみると、
査読とかレビューの時間が大半だったりすることが多い。
つまり、ｘｘｘを作るスケジュール＝ソースを作る＋テスト＋ソースレビュー
なのだ。
困ったことにレビュワーの時間なんて都合が付かないことが多い。
なぜなら、レビュワーとして参加する時間はスケジュールに１秒も入っていないのだ。
ま、それはそれで文化なんだろけど、
文化の始まりにはsvnどころかcvsも無かっただろうから・・・（笑
ソースの組み込みはすべて手作業であっただろう。
故にレビューしておかないと知らないうちに
変てこなモノがシステムに組み込まれてしまうからだ。
だから、必要だったのだろう。
長いソースを印刷してレビューすることもある。
しかし、今はsvnやcvsがあるからコミットし、レビュワーに事前に読んでもらうこともある。
そこが一大事。
ソースを配布してからレビューすることになる。
たまにソースが真っ赤っか（シンタックスエラー）なんてことも共有しているソースなんだから起こりうるのだ。
コンパイルできません。
今日は帰るか。
なんて云うこともある。
※云うだけだけどね。
つまり、しっかりレビューをする文化は容易にsvn上でシンタックス・エラーを起こしてしまうのだ。
そんな訳で、安全策として、自分用のローカル・リポジトリと共有リポジトリを分けてるようなものが、だんだん増えている。
GitのGitHubみたいにね。
だが、レビュワー視点でものを考えると、
シンタックスエラーなソースをコミットした奴が悪い程度にしか思わないから、
それで割りを食っているその他大勢のことは無関心で、
そんなものは導入することなぞ、考える余地がある訳もない。
 
そう先の「後で名前を揃えればいいや！」と同じである。
 
このように非常に非効率的な仕事のやり方は一般的でドコでもやっている極普通なやり方である。
マネージャ研修でレビューの重要さを叩き込まれても
スケジュール管理の難しさを教えられても
マネージャの都合に見合ったクリティカル・パスを引く。
はっきり云えば何かのイベントをスケジュールに上塗りするだけ。
都合の悪いところにクリティカル・パスを絶対引かない。
スケジュールが送れる予想が付くのが嫌なのだ。
はっきり云えば、スケジュールが間に合うかのようにクリティカル・パスを引いてしまうのだ。
当然だが、
その文化は、毎日せっせと元気良くデスマーチの道を歩むためのものでしかないのである。
南無南無。

ここまで来ると
本気っぽい
言ったもの勝ちと云う中華人民共和国のローカルルールは
その国内でしか通用しないがキニシナイんだろうな。
フラッシュに大きく I5って文字が入っているのが厭らしいが・・・
i-phoneも中国などアメリカの国外で大方の部品を調達しているので、
i-phoneの筐体部品などの横流しがあれば容易に偽物が作れてしまう。
多少サイズに微妙な差があり、i-phoneの方がちょっと厚めなのは
微妙な曲線を取り除き安価にしたGoophone専用劣価パーツを使っているのだろう。
しかし、中身は高性能なので、「偽物＝出来が悪い」訳ではない。
多分、ソコが強気になっている原因なんだろう。
似たような出来事でブラジルのメーカーが同名のスマフォの販売をしている。ブラジル国内のi-phoneの商標登録は数年前にしていたようで商標上の問題は無いハズだが、去年の１２月頃から販売を始めているので、実に怪しい。
不況なのでi-phoneあやかり商売も多いが、強気なものは呆れてしまう。