この画面は、簡易表示です
FireFoxに入っているSQLiteはデータベースをファイルロックで競合管理しているので、何かと使いにくいので、
ブラウザのLocalStorageをDataBase代わりに使えないかなぁ？と
phpMyAdminでINFORMATION_SCHEMAを見ながら
チョコチョコとJavaScriptに焼直してます。
Select A.fld1, B.fld2 From XXX A Left Outer Join YYY B On A.key = B.key Where A.fldX = xxxxx
とか使えたらいいな。
一通り動いたら、LocalStorage用サーバー・パッケージとJScriptやJDKのツールでNode.jsっぽく動くサーバー・パッケージに分離して、どこでもデータベース化できたらいいな。できれば１つのスキーマを別々のパソコンに分散できたらいいな。
JavaScriptにclassというモノは無いけど、
クラスっぽくていいから使いたい時もある。
参考１（Google流）、参考２、参考３
コンストラクタは 普通に関数の文法で
function aaaa (param) {
this.p = param;
}
と書いてもいいけど、
ドコかで名前aaaが重なると、かなり厄介なことになるので、
var aaa = function (param) {
this.p = param;
}
と、後でパッケージする気が起きやすい書き方にした方が良さそうだ。
クラスの継承に関しては、function を作成すると 自動生成される function の prototype を使って
Object.setPrototypeOf(子クラス.prototype, 親クラス.prototype);
※2015/04/09 現在、リンク先はまだ和訳されていません。
が良さそう。
# find / -name reboot
/usr/sbin/reboot
自宅サーバーで、ブログやphpMyAdminその他諸々にログインすると
ブラウザに
An error happended while saving credentials
と、エラーが表示される。
【対策】
インタネットオプションのコンテンツタブで、「SSL状態のクリア（S)」を実行するといいらしいのだが、
FireFoxにはそんな設定はなく、cookieを消しても直らない。
普段使っていないIEやChromeでphpMyAdminにログインするとエラーが出ないので、SSL状態の何かが変らしい。
※2015/04/10 勝手に治ったらしい。しかし完治したかどうかは判らないので、また再発の恐れがあります。
※2015/04/19 再発したが、FireFoxのキャッシュ不整合の対策で治った。
最近寒暖が激しいせいか、花粉症でもないのに涙目、咳、クシャミが止まらない人が多い中、
鼻も痛くなく鼻水も出ず「まるで花粉症が治った」のかと思ったのだけど・・・
目の周りが突っ張るような感じがとれず、眼科に行ってみたらドライ・アイになっていたようです。
涙の量が減って、鼻水が出ず、鼻が乾いていたらしい？
FF14などのオンラインゲームから遠ざかり、
回線速度なぞ気にも留めなかったが・・・
最近、Google検索の反応が、ブラウザのタイトルが「＊＊＊＊＊-Google検索- Mozilla-FireFox(応答なし)」と
タイトルが変わるくらいトロい！
怪しいCAの対策で、ミスった影響なのかな？
単に回線が重くなっただけなのかと思ったけど、BIGLOBEの通信速度診断の結果は、23.435Mbpsといつもより速めだった。
これは、Google検索の反応が遅すぎて、いつもより回線が空いているのかもしれない。
だったら、１Gbpsの回線に切り替えてもダメそうだ。
しばらく様子見するしかないのか・・・
以下、記憶がかなりあいまい。
SQL SERVER のUPDATE文で設定する値にSELECT文が使えるけど、SETに計算式は使えないらしい。
しかしMSDNを見ると・・・
expressionはあちこちに書いてあるけど、SELECTなんて書いてなかった。 orz
ま、ゴチャゴチャに補正値が入っているテーブルから系統ごとに補正値をまとめて加算するんだけど
データが多すぎるから、SQLでパパッとやってみたかった！だけなんだけどね。（笑
UPDATE 更新テーブル
SET 系統計1フィールド1 += WHEN CASE 集計キー = 1 THEN 計算式1 ELSE 0 END
,系統計2フィールド1 += WHEN CASE 集計キー = 2 THEN 計算式2 ELSE 0 END
FROM 更新テーブル INNER JOIN
(SELECT 補正値テーブル名.キー,集計式 FROM 補正値テーブル名
GROUP BY 補正値テーブル名.集計キー・・・) 補正値 ON 更新テーブル.キー=補正値.キー
WHERE 更新テーブル.対象時刻=XXXXX
のように書けば、計算式1で
SUM(補正値.フィールド1名) – SUM(補正値.フィールド2名)
も使えるのかもしれない。
でも、素直にカーソル使ってループした方がマシかな？（笑
※まだ調査中。
VisualStudio 2008の起動自体も遅いが、デバッガはもっと遅い。
基本的に、VisualStudio 2008を終了する時には、
・Start画面を閉じる。
・ブレークポイントを全部削除する。
の２つは必ず守らないといけない。
そうしないと、起動やデバッグ開始の度に、１０分くらい、デスクトップを人質に取られるからだ。
要は、ネットワークのコネクションやレスポンスの遅さ（タイムアウトまたはレスポンス1秒 × 1000カ所≒16分）を甘く見るからこうなるので、某社の開発支援ツールでも同様な目にあっている。
要は、使い込まない奴が作った開発環境やツール類は、全て同様の問題を内包している。
とは云え、それで開発しなければいけないなら、
マネージャの画面では、ずばり「プログラム」に分類されている。
と云うのも、その場でパラメータを打ち込んで実行することも可能。
この辺はIISでWEBサービスをデバッグするのと雰囲気が似ている。面々と続く、N88-BASICっぽい仕組みである。
この辺は単に実行するにも単にデバッグにも単にテストするにも、延々と事前作業が必要なEclipse系Java開発環境とは全くの別系統だ。
こんなに手軽に実行できるなら、VisualStudio2008から逃げ出して、延々とストアードプロシージャのデバッグに勤しむのも、理解できると云うものだ。
勿論、他人のN88－BASICコードは、難解です。
@A int AS DECLARE @AP1 INT(3) , @AP2 INT(3) , @AP3 INT(3) SET @AP1(1)=1, @AP2(1)=2, @AP3(1)=3, @AP1(2)=10, @AP2(2)=20, @AP3(2)=30, @AP1(3)=100, @AP2(3)=200, @AP3(3)=300 EXEC PROCEDURE_1 @AP1(@A), @AP2(@A), @AP3(@A)
と、分岐が大っ嫌いなコンパイラーが出力しそうな結果をイメージしたソースコードが書かれていたら、どうします？
（＠＠/ と・・・すがすがしく感じていただけるだろうか？（大笑
もしかしたら
@A int AS DECLARE @P1 int, @P2 int, @P3 int IF @A = 1 THEN SET @P1=1, @P2=2, @P3=3 IF @A = 2 THEN SET @P1=10, @P2=20, @P3=30 IF @A = 3 THEN SET @P1=100, @P2=200, @P3=300 EXEC PROCEDURE_1 @P1, @P2, @P3
と、あるべきなのでしょうか？
ぼくは
@A int AS IF @A = 1 THEN EXEC PROCEDURE_1 1, 2, 3 IF @A = 2 THEN EXEC PROCEDURE_1 10, 20, 30 IF @A = 3 THEN EXEC PROCEDURE_1 100, 200, 300
で十分じゃないかと思います。
今思えばOS/2のVisual-Ageがリリースされた後に、インタープリターみたいなモノを作る仕事が多かったのは、やはり『開発環境が重かったせい』だったのかな？
※上記のコードは雰囲気を表現したもので、文法的に正しいかどうかはチェックしていません。
2014年11月から外付けHDDに保存してあった番組は2.2TBまで増殖していた。
土日にHDDからBDへダビングしてみた。
CM抜きをしなければ、そう手間がかかるものではないが、ダビングがかなり長くなってしまうし、地味にメディアを消耗してしまう。
そんな訳で、HDD使用量は1.8TBと５０％以上のまま・・・
BDメディアは残り２０枚、残弾数が全く不足している状況を改善しなくてはいけないし・・・
今週からBS11の追撃が本格化するので次の土日も手が抜けない。
こうなっては超兵器BD-RE XL(100GB)の出番か？
でも、お高いので、50GBをポチりました。
薄厚のダイを重ね積層する技術の要めはダイ同士の配線をどうやって結合するかだ。ドンドン重ね続けると配線作業がしんどい。
そこで平らなダイを折り立たせた様な構造でダイを製造し、面積あたりの記憶セル数を稼ぎ、積層する手間を減らすのが3D-NAND技術らしい。
しかし、それなら、もっと薄いダイを作り、ミウラ折りっぽい折り目を付け、バンド状の熱収縮素材を貼って加熱し折り目に沿って収縮させ、最後は専用クリップで挟むか端子を露出させる穴のあるケージに入れるといいような気がする。
端子は畳んだ後に外側に出る位置に配置しておくと、熱収縮素材がいい感じでダイをカバーし、小さいけど固体コンデンサーっぽいコロっとしたNANDメモリ・コアが出来き、端子にハンダを乗せ、超音波で基盤に貼り付け出来上がり・・・ダイ同士を配線するより楽な気がするし、力任せに大量に載せて大容量のSSDも作れそうだし、搭載するコアの数が多いなら逆の発想で少しづつ容量を増やすことも出来そうだ。
eMMCの代替品としてSoCに搭載というのも良いかもしれない。
難点を云えば、そんなメモリを積んだタブレットの開封の儀をやったら、メモリらしきものが見当たらないコトだろうか。
もっとも、印刷で電子回路を作る技術で、普段は極薄の回路を作り折りたたんだ状態で使用し、壊れたら折り目を伸ばして修理できて便利そうだね。（大笑