考え方を考える！！

さて、またまたサーバーのお引っ越し。

今度はcore miniからcore aへ！

今回の引っ越しの理由は、オンラインデータベースを使ったアプリ開発に伴い、将来にわたるデータ容量がcore mini(10GB)では心許なかったのと、負荷率やメールの配信上限にも不安が…

そんなわけで、core Aへ

引っ越し対象は、メインのドメインとブログドメインとアプリケーション用のドメインだ。
ここで問題となるのが、ブログのデータベース。
前回の引越では、引越先にWordPressを再インストールし、WPの機能を使ってデータの保存と復元を行ったように記憶しているが、これだとうまくいかなかったので、今回は違う方法にした。
作業手順は以下のとおり。

(1)引越直前の作業

　Coreserverのアクセスログを取得
　引越対象のメールを受信

(2)DNS設定を変更

　当該ドメインを一時的に使えなくする（引越先には設定しない）。
　引越元のCoreserverのドメインウェブの設定を削除

(3)DBの保存

　引越前のCoreserverのDB管理画面からDBのデータを保存し、Coreserverのファイルマネージャを使って保存したファイルを自PCにダウンロードする

(4)サーバー間のデータコピー

　引越先のCoreserverのサーバー間コピーから、各ドメイン（サブドメイン）のデータを引越元からコピーする。
　WEB用データのみで、メールのデータはあきらめる。（←　やってみたが動かなかった）

　※引越元のFTPのアカウント情報が必要

　サーバー間コピーを使用すると、パーミッションもそのまま引き継がれるようだ。

　コピーの進捗はわからないので、同時に色々やらない方がよい。
　コピー中は、おとなしく待ち、時折、ファイルマネージャでどの程度コピーされたか確認するのが無難。
　

(5)DBの復元

　引越先Coreserverで、引越前と同じ文字コードのDBを作成（名前は異なってもよい）
　引越先Coreserverのファイルマネージャで、自PCに保存したDBのファイルをアップロード
　引越先Coreserverのデータベースで、復元先のDBを選択し、「復元」ボタンでデータを復元する。

(6)DNSを引越先サーバーに変更

(7)引越先Coreserverで、ドメインウェブの設定

おしまい。

顧客先からマレーシアでインターネットが使いたいとの要望が…

現在顧客先ではe-mobileの国際ローミングが使用できるようにしてあるのだが、概ねどこでも使える反面、従量制の料金体系がいただけない。
そこで、GLOBAL DATAに目をつけた。

GLOBAL DATAでは、いろいろなタイプのサービスがあるようだが、カントリータイプのUSBタイプのものを借りることに…
私が借りるならWi-fiのものを借りるのだが、ご年配の顧客には、Wi-fiの設定やトラブル時の対応が困難だろうから、USBタイプを薦めた。
USBタイプはソフトウェアのインストールはあるものの、バッテリー切れの心配がないので、トラブル時の原因究明が比較的容易だろうと考えたからだ！！

結局、保険等を入れて4日間で6,000円弱となった。
出国日の2日前までの申し込めばOKという点も助かりました。

今回は、成田発、羽田着なのですが、空港での受取、返却もできるので、けっこう利便性が高いです。
もちろん、郵送での受取・返却も可です。

あとは無事につながることを祈るだけです。

ちなみに、申し込みの際には、往復の便名，往路の発時刻，復路の着時刻を入力する必要があるので、事前に用意しておいた方がよいですよ。申込み途中でタイムアウトでやり直し…なんてことにならないように…

Windows環境でドイツ語入力が必要に…
「ドイツ語入力」とYahoo!で調べたら、わかりやすいサイトを発見！！

http://wm.tamagawa.ac.jp/manual/Bb/user/FirstStepMyPC_ja_JP/appendix/FirstStepMyPC_c14appendix_13.htm

先日発生したJX日鉱日石エネルギー水島製油所の海底トンネルでの事故…
いたたまれません。
被害者が早く発見されることを願ってやみません。

MSNの産経ニュースを読むと、「異常出水」、「想定外」という言葉が目につきました。
本当に異常だったのかもしれません。
本当に想定外だったのかもしれません。
しかしながら、昨今の建設事情を考えると、事前の（地盤）調査が軽視される風潮があるのも事実です。
十分な調査が行われず、それを想定外と呼ぶのは原発問題と同じ構造と言えそうです。

地盤調査は、有効に活用できそうな既往のデータがあれば、そのデータや既往文献などを参考にして、ある程度は省略することができます。
そして、一般的には、重要構造物については詳細な調査が必要とされており、そうでないものについてはそれなりの調査でよいとされていますが、重要かどうかは相対的な指標でしかありませんので技術者にその判断がゆだねられます。

今回の場合は、上述の意味での「重要」な構造物かというと、この海底トンネルの目的次第となりますが、完成後の重要性には配慮するものの、建設途中の重要性が軽視されがちなのも、このような事故の背景にあるのではないかと考えています。

今回のプロジェクトでは、地盤調査をしていないとの報道もありましたが、なぜこのようなことが起きるとかというと、地盤調査の費用が馬鹿にならないほど高額だから…と言えます。とはいえ、割高というわけではありませんのであしからず。調査にかかる資機材や人件費等を考えれば、決して高くはありません。
私が、数年前に担当した某所のLNG備蓄基地の地盤調査では、約50箇所、延べ？千mのボーリング調査で約1億円でした。調査数量・金額的には大規模な調査プロジェクトですが、調査方法はごく一般的なもので、これといって特殊な調査はありませんでした。それでもこの価格です。そして単価で見るとそこそこ安い方でした。

調査の目的は、設計（施工）に必要な情報を得るためと言えます。しかしながら、地盤調査は高価な投資をしても「物」としは報告書以外、何も残りません。それなのに高額であることが、事業主や設計者の判断を鈍らせているのでしょう。ましてや近くで行ったデータがあったりすればなおさらです。

勝手な推測になりますが、今回の事故の原因としては次のことが考えられます（※思いつきです）。
(1)トンネルの土かぶり厚（トンネルから地上までの土の暑さ）が十分に無かったためにトンネルが崩壊した。
(2)トンネル周辺の地層構造が、既往のデータと異なっていた。特に止水層となる粘性土層が異なり、水理条件が想定よりも悪かった。
といったことが思い当たります。思いつきですので、きっと他にも原因があると思われます。
詳しいことは、土木学会や地盤工学会、建設コンストラクションあたりが近いうちに詳細を掲載してくれるかもしれません。

ともかく、地盤調査を行っていないのであれば、それが原因であると云わざるを得ません。
事故を起こした鹿島建設の管理が悪いのはもちろんと言えますが、それだけで片付けられたくはありません。この背景には、技術的な裏付けもないのに、金額に重点をおいているであろう発注者側にも問題意識を持っていただく必要あります。
今回のように事故になったから明るみにでたものの、似たようなプロジェクトは他にもあると思います。
このような事故を回避するためには、発注者は、設計・施工者と施工監理者を同一業者にしないことに加え、設計～施工までの技術的な監査役として発注者側の立場で技術的なリコメンド行うオーナーズコンサルタントを使うことが必要になると言えるでしょう。
医療でいうセカンドオピニオンみたいなものですね。

VB.NETにおいて、文字列を整数型の数値に変換する関数として、Cint，Clng，Valといったものがあるが、
Val関数とClng関数は同じ結果になると思いこんでいた。

実際は、Clng関数は、Long型の数値に変換される。
一方、Val関数は、17桁まで有効なLong型の数値に変換されるようだ。

ex)
Dim v as String = “120002112365008889” ’18桁の数字文字列
dim lngV as Long = Clng(v) ‘120002112365008889
dim valV as Long =Val(v) ‘120002112365008880　←　18桁目が0になる