カテゴリー別アーカイブ: IT/技術メモ(その他)

update-select文とupdate-for文について

SQLでもっともつまづきやすいupdate-select文というものがある。

select文による結果でupdateするが、その正しいやり方というのを見ると、おそらく誰もが気持ち悪いと思うはず。

SELECT結果でのUPDATE
qa.atmarkit.co.jp/q/98

setでデータを入れるサブクエリ内のSELECT文のwhere句ではなく、updateの更新対象を絞り込むUPDATEのwhere句をしっかり定義しないと、思った通りに動かないことがある...そして、サブクエリ内のwhere句の条件とupdate文のwhere句の条件は往々にして同じような条件になるため、SQLの文法を知らない人が見ると「何で同じような定義を2回しているんだ?」という疑問を持つことになる。更新先の絞り込みをしないと更新元がない時に問題を起こすので、同じような条件を指定しているのだ。これを解決する手段としてpostgresとしてはupdate文にfor文を連結して更新対象と更新結果を出力するselect文を書くことができる。これによりupdate文にselect文のサブクエリを連結せずにスムーズにデータ挿入することが可能になる。

UTF-8のCSVファイルをcatコマンドで連結したら文字化けした!?

以下の様なコードを実行した...。

cat *.csv > convert.csv

出力されたconvert.csvの中身が派手にぶっ壊れている。

もしかしてcatコマンドは古いツールだからUTF-8に対応していないのか?

BOMとかそういうのが悪さしているか?

...色々と考えた結果、

すでにconvert.csvというファイルがあって、
それを*.csvとしてワイルドカードでまとめている、
つまり、マッチポンプっつーか、再入力しているっつーか、
アウトプットファイルがインプットファイルにもなっているため、
壊れていたもよう...。

残念な間違い。

SQL文@データ挿入時の条件付きのIDカウント方法

データ挿入時のID採番が複合キーなどの別条件がある場合なんかもそうだが、
シーケンスなどの別機能を使うより安定性が増しシステムの柔軟性は上がると思う。

#このようなトランザクションで更新してもいいが、、、
INSERT INTO test(a) VALUES (-1);
UPDATE test SET a=(SELECT (SELECT MAX(a) FROM test)+1) WHERE a=-1;

#このような感じで1つにまとめることもできる。
insert into test (a,b) select max(a)+1 from test,'b';

以外にこの情報は少ない。

WebAplicationを柔軟に作成する応用例として必須の考え方だと思うが...

参考にしたURL
7ujm.net/SQL/countUp.html

SE戦記@メールが届かないんですけど

qmail:CNAME_lookup_failed_temporarily

数日前に送ったメールが戻ってきたと社内の人が騒いでいる。

mocha.exblog.jp/11442682/

qmailのDNSが512byte以上のデータをレシーブできないらしい。

パッチを当てれば解決する。

端的にもっとqmailしっかりしろよと言うべきか、
DNSが多くの情報を送りすぎる時代に突入したせいか、
どっちが間違いという話ではないのだが。

qmailを選択することが間違いだーいう人もいるが、
それについてはよくわからない。
枯れていても起こる不具合もある。
これはqmailが作成された当時に問題にはならなかったのだろうから。

qmail-【電子書籍】

qmail-【電子書籍】
価格:2,304円

SE戦記@「メール1通しか送ってないのに2通届くんですけど」

Web屋をやっていれば、社内に数えるほどのメール送信システムがあったりするものだ。

 余談だが、LINEとかSkypeとか伝達手段なんかいくらでもあるのに何でメールなんだろう?なんて思うことがある。共通の電信プラットフォームがあれば事足りると思うのだがわざわざメールサーバを立ててビジネスパーソンは日々せわしくメールを送受信している。個人情報がサーバ管理者に拾われるMSのSkypeならともかくLINEなんか韓国の法人なんだから信用できるか!とネトウヨが言うたりするが、それならメールのリレー中に途中経路で盗聴されていないかとか心配したほうがよっぽど重要なんじゃないだろうか?メールサーバのサーバ管理者が悪巧みしているかもしれないということをなぜかメールを使う人は考えない。ふしぎである。自社で管理しているメールサーバならともかく大きな会社でも安価なレンタルサーバで済ましているなんてざらにある。社会的信用がある企業がLINEみたいなのを作る例はあるだろう。skypeもそうだしKDDIも似たようなものを作成していたと思う。でも流行らない。重要なのはセキュリティうんぬんじゃなくて大勢がプラットフォームを使っているか否かということなんだろう。
 そういえば何の意味もないのに、メールを2通に分けて、パスワードをかけたZIPしたデータと、パスワードがかかれたメールが送らられてきたりする。まだ違うメールアドレスから送信したものというなら経路による頭頂は防げるかもしれないが、サーバ管理者や送信者のネットワークが乗っ取られてたら盗聴されるんで、なんにも意味がないのだが…なんでこんな原始的な方法がとられているのだろうか?何度も言うが、セキュリティが守られているかもしれない!という「かもしれない」で行動を起こしてはいけない。車を運転する時は…「轢き殺すかもしれない」で運転してはダメだし逆に「轢き殺さないかもしれない」で運転してもダメ。

--

そんなことより、
ある日のこと私が作成したとあるメール送信システムの不具合が報告された。

「すみません、メールを1通しか予約していないのに2通届いているんです…」
社内のメール送信システムを使う女の子が早口で言った。この人をAとする。
Aさんはイライラを隠しているのがひしひしと感じた。
「そりゃおかしいネ」わたしはとぼけながら、
すぐに送信ログを調べてみたが、メールは1通しか送信していなかった。

1通しか送信していないものが2通送信されるものか。
だいたいなんで2通とどいたとわかるんでしょう?。疑問に思った私は、
「お客様が2通届いたと言ってきたんですか?」とたずねた。

Aさんは答えた「いえ、私に2通とどいているんです」…なにそれ。
なんで自分に送っているのかしら。状況がつかめない。話を聞いてみると、
内容を確認するために、自分宛てにBCCでメールをクライアントに送信しているとのことだ。
用心深いんだか、システムを信じていないのか、面倒くさい感じ、、。

繰り返しになるが1通しか送っていないのに2通届くなんてあるんだろうか?

メールの受信が2回動いている?そんなバグがあるんだろうか。
そんなことは設定ミス/転送ミスでならあるかもしれないが運用はずっと前からしていて、
設定はいじっていないのでその線は消える。

メンテ不足によりメールプログラムがご動作しているってわけでもないようだ。

Aさんのメーラを確認させてもらったところ、たしかに2つBCCのメールがとどている。

さて、何が問題なんだろう???

答えの前に…

メールを見ると本文も宛先も送信先もdiffったが同じものだ。
ただし若干容量が異なった。ヘッダがほんの少しだけおかしいようだ。
・・・見比べてみると2行だけ見たこと無いメールサーバが転送したという情報が書かれていた。
そのヘッダそのものはなにか意味があるものではない。

ここでわかった。

自社のメール送信サーバでお客様Bに送信した。
その時に運用のAさんはBCCに自分のアドレスを入れて送信した。
お客様BのメールアドレスはメーリングリストでAさんもそこに含まれていた。

こっちは自分の送信プログラムが2通送っているのか?という事実にビビっておたおたしていたのに、
…原因は実にくだらなかった。

BCCとかメーリングリストとか、使い方が変なんじゃね?

[教訓]メールが2通届く時に設定ミスでない場合は、BccやMLの設定で転送されていないかチェックスルこと。

--

更に余談だがBccとはクライアントに届く時に余計なヘッダを極力消してしまう。
それが問題をさらにわかりずらくする。Bccって機能じたいどうなの?という議論は昔からあるけど、
そうだな。いらないよな、Bcc。

.tar.gz, .tar, .zip, .gzの圧縮と解凍をする方法

linuxでよく使われる圧縮方法に.tar.gz(.tar), .zip, .gzがあります。

※tarはテープ媒体で保存するためにファイルをまとめたアーカイブ形式にする処理コマンドである(圧縮技術ではない)。gunzip(gzip,gzと同じ意味)は複数ファイルをまとめることができないためtarでまとめた後にgunzipで圧縮している、このファイルの拡張子がtar.gzである。

他の圧縮方法もあるが、私の経験上ではこの3つが多いように思う。これらの圧縮形式の圧縮方法と解凍方法を心得ておけば日常のサーバ管理には困らない。その他の圧縮形式を使わねばならぬ場合は個別に調べてください(日常的によく使うので解凍方法と圧縮方法は手で覚えてしまったほうがよいでしょう)。

【.tar.gz圧縮】

tar -cvzf file.tar.gz file

【.tar.gz解凍】

tar -xvzf file.tar.gz

※解凍時は圧縮したフォルダ(ディレクトリ)がそのまま上書き展開される。すでに同名のファイルやフォルダ(ディレクトリ)がある時は上書きされるので注意すること。

----------

【.zip圧縮(ファイル)】

zip file.zip file

※ディレクトリを保存する場合は-rオプションを指定すること。

zip -r dir.zip dir

【.zip解凍】

unzip file.zip

(つづく)

※圧縮処理のアルゴリズムについて詳しく知りたい方は以下の書籍を参照ください。

ネットワーク機器はbpsやppsで性能を計れない。

参考(このブログエントリーの本質については書かれてないけどbpsがあてにならないことは説明されている)
itpro.nikkeibp.co.jp/article/COLUMN/20090617/332116/

標題の通り。ハブもルータもコンピュータに過ぎない。

小さいパケットが複数飛んだりすれば、それだけCPUが動いてメモリに展開され角ポートに振り分けるので、いくらハード全体のbpsやppsがギガビット対応であっても実測値はでません。100BASEのプラネックスのL2ハブの方が1GBのコレガハブより複数ポートを指して利用したら固まらず快適だったことがある。ギガビットという表記に騙されてはいけません。安いギガビットハブより高い100BASEハブの方がみんなでインターネットするなら快適です。

つまり、理論値だけ見ても使えるかどうかわかりません。

特にメモリが小さければさばけず重くなりやがて落ちざるをえなくなるこれが現代型コンピュータの宿命。

だいたいppsなどの総パケット店総数は決まったサイズのパケットを飛ばした最速の理論値に過ぎず、安価なハードはその価格程度の力しかないのは明白です。ちょっと話が逸れますが、この「理論値と実測値は違う」という言い方は、マジックワードというより無意味で曖昧な理解になってしまう原因ではないかとすら、私は思うようになりました。理論値は実測値に伴なわないということは、理論値そのものの出し方に問題があるということだし(bpsは平均値に過ぎないと分かった上で言っています)、とにかく理論値はそもそもあてにならないという理解は変だ。

理論があてにならんと言うのは身も蓋もない。

理論は理論でそれそのものは大変役立つものである。
というスタンスをいわゆる理系/技術者ならとらないとダメでしょう。

理論を実践以下に貶めてはならない。

じゃあなんて言えばいいか?

「ネットワーク機器のマニュアル記載の情報だけでは正確なスループットはわかりかねる」こういう方が理論的でしょう。

RFCではスループットを出すにあたってbpsでもppsでもよいと書かれているらしいですが、
httpでWebサイトを閲覧するとなるとだいたい細かいパケットが沢山飛ぶので64bitで算出した値はでるわけがない。

参考
detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1218091427

本質を理解しないとRFCも読み間違えるような気がします。

コンピュータは奥が深いというか、
本質の受け取り方を間違えると長く迷走する世界だと思う。
他の業界/世界もそうかもしれませんけどね。。

※変に職人技を経験則のせいにしたてあげるのではなく、
 きちんとマニュアルにかかれていない理論が分かれば、
 職人にすぐになれるのだということを私は言いたい。

※自宅にもいつかアライドテレシスの機器でいいから欲しい。

crondでphpのfgetcsv関数が正常に動かない

叩いて動かす分には問題ないが、cronだとCSVの日本語がfgetcsvで動かない。

cronの設定ではよくある話。

パーミッションも問題ないのでおかしいなーと思ったら、
LANGという環境変数に応じてfgetcsv関数は動作がかわるとのこと。

export LANG="ja_JP.UTF-8"
batch.php

※cron設定時に(自分で叩いてデバックしてうまくいくことは確認すると思うが)、
 その時にcronで失敗する時は以下2点を疑うこと。
・環境変数の違いがないか。
・パーミッションに間違いがないか。

【参考】結構事例あり。
www.yuigahama.org/?p=370
tkuchiki.hatenablog.com/entry/2013/04/23/224125
yassu.jp/pukiwiki/index.php?crontab%A4%C7fgetcsv

javaScriptでonChangeでアンダーバー入りの関数が動かない/未定義になる。

タグ上のonChangeに定義済の関数xxxxx_bbbbb_ccccc()というような、
アンダーバーが上記のように2つ入った関数を呼び出すことができなかった。
not defined functionみたいなエラーになってしまう(FireFox33.0.2)。

以下のブログと同じような現象かと思います。
ragranje.blog73.fc2.com/blog-entry-25.html

アンダーバーをなし、または1つの関数にしたり、a_b_c()というような関数にしたら動いた。

意味がよくわからない。アンダーバー無くした関数にして回避したが、注意が必要。

DNSの切り替えは短く見積もっても1カ月

DNSの安全な切り替え方について。

(ドメインに対応するIPアドレスの切り替えで、Webサーバを切り替えた場合の例)

店舗や中小企業のWebページを制作している人は、
ドメインに対応したIPアドレスを変更した場合、
DNSの浸透は数時間せいぜい1、2日で済むと思っているかもしれない。
(というか、私はそう思っていました。)

ところがクリティカルなWebサイトやクリティカルなメールサーバの移行の場合は、
そういったアバウトな感じで行うことはできません。
DNSのゾーン変更でも1~3カ月の長い期間を見て行わないといけません。

なぜでしょう?以下のような理由があげられます。

1.世の中のDNSサーバがTTLを気にしているとは限らない。
  (BINDなどではなく独自実装のプログラムが無いとも限らない)
2.ルータやクライアントサイドのアプリケーションなどのDNSキャッシュは、
  DNSサーバのTTLなぞ気にせず自分のタイミングで廃棄したりもする。

つまり、端的にいえばTTLは相手にキャッシュ保持期間を
マストでコントロールできるものではないのです。

DNSの伝播の仕組みは堅いものではありません。
TTL値が利用されるべきことは相手の性善説に基づくものであって、
それをビジネス上の「正しくアクセスできない」理由にはできないのです。

ですから、DNS切り替えは以下のような手順で行われなくてはいけません。

【DNSサーバの切り替え手順の例】

(1)DNSサーバの変更するゾーンのTTLだけを10分に設定して1,2カ月放置する。
  (世界中のDNSサーバにゾーンの書換えを素早く行ってもらうための情報をばらまく)
(2)ドメインに対するIPアドレスを変更する。
(3)しばらく放置(目安は1~2週間)し、
   Webサーバのログを見てアクセスが無ければ、移行元サーバを停止する。
(4)TTLを常識の範囲(1時間~1日程度?)に戻す。

DNSの安全な切り替えは最低でも1カ月ほどかかります。。

Webサーバでもメールサーバでも切りかえた時は、
1カ月とはいいませんが1週間程度は移行元サーバにアクセスされることがあります。
メールサーバのDNSキャッシュ時間が長いということもあるということなのでしょう。

甘く見ていると痛い目に合うのが「DNSの浸透」です。

慎重に余裕を持って作業をしましょう。

インターネットを支える仕組みとして、
DNS(ドメインネームサーバ)の仕組みが分かるようにしましょう。