コンピュータ

Gmailは、POP3でメールを取ってくる機能がある。 これを使うと、普通のメーラーでメールを読めて便利。しかも、万一の際のバックアップにもなる。 # 送信(SMTP)も同様で、きちんと設定すればメーラーから送信もできる。 で、以前から気付いてはいたけど、Gmailのモノは普通のPOP3サーバと違っていて、「メールをサーバに残す」ということができない。メールを取得したら(たぶん)消すように作られているみたい。 つまり複数のメーラーで、同じメールを受信しようとしても、できない。 Becky2のプロトコルログを見ると、 1回目の接続 >>> Connecting to “pop.gmail.com” (SSL/TLS) [2012/10/18 22:21:18] <<<+OK Gpop ready for requests from xxx.xxx.xxx.xxx mi2pf44702387pbb.25USER 略@gmail.com+OK send PASSPASS ********+OK Welcome.STAT+OK 90 2916698LIST+OK 90 messages (2916698 bytes)1 3280(略)90 13320.UIDL+OK1 GmailId13a3f0059c8b1ce1(略)90 GmailId13a73f1acf2172c2.RETR 1+OK message follows(略)RETR 90+OK message followsQUIT+OK Farewell.2回目の接続 >>> Connecting to “pop.gmail.com” (SSL/TLS) [2012/10/18 22:22:35] <<<+OK Gpop ready for requests from xxx.xxx.xxx.xxx qu6pf44702630pbc.32USER 略@gmail.com+OK send PASSPASS ********+OK Welcome.STAT+OK 0 0QUIT+OK Farewell. RETRしかしていないのに、次回は見事に消えていますね(ぉぃぉぃ)。 というわけで、GmailのPOP3サーバは変です(この機能、あることだけでも有り難いんだけどね)。

まず、Ubuntu12.04LTSにPostgreSQLを導入する。 メタパッケージpostgresqlを入れれば、postgresql-9.1とかが入ってくるので簡単。そのあと、昔と同じ手順で、EUC_JPのデータベースを作ろうとしたら失敗した。こんな感じ。 createdb -T template0 -E EUC_JP dbname createdb: database creation failed: ERROR: encoding EUC_JP does not match locale en_US.UTF-8 DETAIL: The chosen LC_CTYPE setting requires encoding UTF8. 軽くググると、initdbしなおすのだ、とか面倒そうなことが書いてあって、それは面倒だ。さてどうしたものか、とTwitterにつぶやいたところ @PostgreSQL_JP 様からアドバイスを頂けました。ありがたいことです。本当に助かりました。 結論から書くと、以下のようにすれば良い様子。 createdb -T template0 -E EUC_JP –locale=C dbname 昔(PostgreSQL7とか8の前半)と現在では、色々変わっていることも多そうなので、ちゃんと勉強し直した方がよいかもしれません。 「徹底入門」も第3版になって9.0対応になっているみたい(たしか初版は持っている)。

(2012/11/7、加筆) WinSCP5.1.1が出てますね。インストーラから日本語が選べます。 もうこのページへのアクセスも激減することでしょう。 (2012/10/12、加筆修正しました。) WinSCP5.1では、前バージョン4.3.9と違い、インストール時に日本語が選べません。 現在は翻訳が終わったようで、言語パック(?)をインストールすれば日本語が表示できます。 その方法を書いておきます。起動直後の画面(WinSCP Login)の「Languages」ボタンを押す。出てきたリストから「Get More…」を選ぶ。「WinSCP Translations」というページに飛ぶ。ここで「Japanese」をクリックしてダウンロードする。ダウンロードしたzipファイル(jp.zip)を展開し、出てきたファイル(WinSCP.jp)を、WinSCPのインストール先(Windows 7 64bitなら、C:\Program Files (x86)\WinSCP)にコピーする。もう一度「Languages」ボタンを押すと、「Japanese」が選べるので、これを選択する。なんか画面描画が乱れるけど、WinSCPを起動し直したら大丈夫。今後のバージョンではインストール時にJapaneseが選べるようになるかもしれませんね。 WinSCPの開発や、翻訳などの作業をされている皆様に感謝。

さくらのVPSを借りてみた。いちばん安いプラン、980円/月のやつ。 軽く使ってみたので感想を。 電源やコンソールがWebから管理できるのは、超便利CPUもI/Oもネットワークも速い。専用サーバのCeleron 2GHzより体感で快適かも正式契約前は帯域制限とOP25Bがかかっているので注意はじめは適当なホスト名がふられている逆引き名も簡単に変えられるけど、まずは正引きができないとダメ逆引き名を変えてからOSをインストールすると、ホスト名などちゃんと設定される。これには感心したやろうと思えば現在使っている専用サーバ(これは1万/月くらいかかっている)を丸ごとのっけられそう。 これで月980円か。すげえ。 関西電力の従量電灯A(普通の家庭)の2段目料金で計算すると、おおむね57Wを24時間30日使うと1000円くらいになる。つまり、普通のPCをつけっぱなしにするよりもお金がかからない、という感じになる。 もう少々様子を見て、問題なさそうなら本気で専用サーバを解約してVPSにしようかな。コストが違いすぎる。

ジャストシステムのインターネットディスクのコースを変更して、iDiskバックアップを容量無制限にしてみた。 以前から知ってはいたけど、コースを上げると315円/月から840円/月となる。これはちょっと高いなあと躊躇していたけど、今回思い切って申し込んでみた。 普段、データは別のHDDにバックアップしているけれど、これだと災害に対してはあまり意味が無い。遠隔地にバックアップしておけば安心だよね、ということで。 ところが、使い始めると色々といけてない。 拡張子の制限が多い詳しくはジャストシステムの該当ページをみて頂けばわかるが、簡単に言うと、「拡張子によってバックアップされないファイルがある」のだ。exeとか、デジカメで撮った動画とか、ISOイメージとかが該当する。そういうものはzipにでもするしかない。 これで「容量無制限」か、ひどいなあ。 転送速度が超遅いバックアップツールの転送速度がどうやら1Mbps程度に制限されている。自宅は安いADSLで上り1Mしかないので、実家のFTTH環境も使って試してみたけど、転送速度に差がない。これは悲惨としか言いようがない。 1Mbpsだと、理論値でも400MB/時間。24時間かけても10GBもバックアップできない。ここまで遅いとなかなか厳しいものがある。今走らせているバックアップは、2-3週間くらいかかりそう。 バックアップしたファイルを戻す速度は、そう遅くないらしい(未確認)。 というわけで、このサービスを利用しようという方は、これらの制限にお気をつけあれ。

今月のSoftware Designの特集である「ITエンジニア 生き残りの条件」を読んでの感想。 タイトルの割に内容は凡庸だな、と思いつつも、従事者(一応ね)としてはやっぱり意見しておきたい。 記事でも指摘している通り、ITゼネコンの重層構造は確かに崩壊しているのだろう。僕の周りでもそういう実感はある。 一方、記事中で、ITゼネコン(SIer)の凋落と、ネット関連企業を並べているのには違和感を感じた。後者は今まさに激しい勝負の真っ最中であって、勝者しか生き残らないような戦いをしている。そこに優秀なエンジニアが必要なのはもちろんだろうけど、少々次元の違う話だろう。 僕は、これまで、この産業でこれだけの人数を養えていたことが異常だったのではないかと思う。 ソフトウェア開発というのは高度に知的な作業だから(だよね?)、個人の能力によって生産性は激しく異なる。これは関係者なら誰でも同意するだろう。なので、今は「全体としてちゃんとした能力をもつ会社」が選別されていく過程にあるのだろうと理解している。 あと、記事中ではオフショアについても言及されていたけれど、僕はオフショア開発にはあまり肯定的ではない。 ソフトウェア開発の期間はビジネス上の要請でどんどん短くなっている。そして、それは実現可能になっている。僕は環境や要素技術などの進歩によって可能になっていると言いたいが、単に現場が無理をしているだけということもあるかもしれない。 そういう状況の中で「外国に出す」というオーバーヘッドは許容できないケースの方が多いだろう。なので、オフショア開発がどんどん増える、ということにはならないと思っている。 もちろん、大規模なシステム開発においてはこの限りではないだろう。 ただ、大規模なシステムもこれからは減っていくだろうと思っている。それは計算機の能力向上、銀行や自治体の統合、この国の人口の減少、など色々な理由があるから。 結果として、顧客企業の発注コストの低下は、単純にIT産業従事者全体の給与原資の低下につながるだけだろう。 産業の規模を縮小するか、給与減少を甘んじて受け入れるか。今、この産業が転換点にあることは間違いない。

PHP4からPHP5へ移行していて、send_mail()ではまったので、メモしておく。 まず、これまでのコードはこんな感じ。 send_mail(“宛先”, “件名”, $body, $name, $address); 宛先はメールアドレス件名は普通に日本語(スクリプト自体はEUCなのでそれ)$bodyはEUCのはず$nameはEUCで、氏名$address は、メールアドレス第4、5引数は、こう書いておくとFromヘッダを適当に作ってくれていた。 今後は、以下みたいのをスクリプトの先頭付近に書く。 mb_language(“Japanese”);mb_internal_encoding(“EUC-JP”); php.iniに書けるらしいけど、個別に書く方が無難だろう。 僕はスクリプトをEUC-JPで書いていて、内部でも文字列をEUC-JPで扱っているのでこう書いたけど、今時書き始めるならUTF-8のがいいかも。 次に、メールの本文をISO-2022-JPに変換しないといけない様子。 $body = mb_convert_encoding($body, “ISO-2022-JP”); そして、メールの送り方はこんな感じで。 mb_send_mail(“宛先”, “件名”, $body); 件名はよしなに扱ってくれているので、そのままで。 第4引数にオプションのヘッダ(Fromなど)を渡せるけど、ちゃんとした形で渡さないといけない様子。 今回のスクリプトは、そこまでの必要性は無かったので、ここは捨てちゃった。 # 間違いがあれば教えて下さい > 識者 

HDDの内容を潰したいけど、FDDしか無い人に向けて。 まずはdban(Dark’s Boot and Nuke)をダウンロード。ダウンロードするのは、dban-1.0.7_i386.exe 最近のバージョンはCD-ROM用のISOしか無いみたい(当たり前か)。1.0.7というのがFDDでも使える最後のバージョンの様子。 Windowsなら、ダウンロードしたexeをそのまま叩けばFDDの作成ができるようだ。ただしそれは試していない。 Linuxだと、以下のようにすればFDDが作成できる。 $ unzip dban-1.0.7_i386.exe$ dd if=dban-1.0.7_i386.ima of=/dev/fd0 bs=1024$ sync (デバイスとかは適当に読み替えて) こうして作ったFDから起動して、Enterを押してしばらく待てば操作画面になる。消去方法と対象のパーティションを選択すれば、消去が始まる。 ちょっと面倒なことに、一度の操作がおわると、ログを保存して終了モード(電源切ってくれ)になってしまう。普通はそれで良いと思うけど、いくつかのパーティションを潰したい人は何回か起動しなおすのが手間かも。 デフォルトの消去方法はDoD-shortなので、まあこれくらいでいいんじゃないかな。 操作方法は、@ITの「ハードディスクの内容を安全に消去 - DBAN」が分かりやすい。 Linuxベースでちゃんと動くので、そこそこの速さで消去ができる。これはなかなか便利なツールだと思う。 最近のバージョンのISOなんか焼いて手元に置いておけば、HDD削除ツールとしてはなかなか良いものじゃあないかな。 最後に気がついたけど、PC/AT互換機のことしか考慮していないので、ご容赦を。

Ruby(1.8)についての雑感。というか落書き。 # 嘘を書いていたら、教えてください。 スクリプト言語で、かなり遅い(1.9で改善されたし、そもそも実行系が色々出てるので、もう触れなくていい問題かな)。制御構造は、ALGOL族の末裔なので、慣れてるはず。クラスベースのオブジェクト指向なので、慣れてるはず。ビルトインのライブラリが充実していて便利。破壊的なメソッドが区別されてて分かりやすい。全ての文法が互いによく考慮されており、非常に扱いが良い。Rubyは非常に動的な言語。Objective-Cに近い感じ(実はSmalltalkに近いのだろうか)。 たとえば、いわゆる「ダックタイピング」。型構造でメソッド呼び出しを縛るC++/Javaなどとは違って、その名前のメソッドがあれば呼んでやれ、ということ。 これはC++/Javaなどから見ると静的チェックがしにくいともいえる。ただ、ちゃんとテストをすれば潰せる問題のはず。 あとはちょっと細かいけど、 includeでインスタンスに特定の操作を追加できる。「import Math」とかにちょっと感激。selfにメソッドを追加するんだ!!既存のクラスライブラリもHackし放題。まあ、ほどほどにしとかないと。イテレータは強力。Javaのイテレータとはもちろん違う。ALGOL系言語の構文を利用して作っているけど、内容は高階プログラミング。関数型言語(LISPやML)などと同等のパワーを持つ。僕は頭が弱いので、うまく使えていないけど。 行末のセミコロンが必須じゃないのは良いかも。慣れてくると他の言語でセミコロンを打ち忘れそう。# セミコロンに関しては、C/C++/JavaとPascalでもどうせ違うし Perlとできることはそんなに変わらないかもしれないけど、よっぽど綺麗なコードが書けるんじゃないかな、と思う。 落書きついでに他の言語についてもちょこっと書いておくと、 C 今では、Cは普通のプログラミング言語では無いのかもしれない。OSとか制御とか特殊用途に使われる言語だ、とか書いてしまおう。 この頃はJavaとかRubyから入門する人も増えたと思う。とりあえず初学者がCをやって挫折、というパターンが減ってきたのは良いことと思う。 でも、一度は勉強しといた方が、いろいろな意味で理解が深まるとは思う。 C++ 機能豊富、なんでもできるかわりに相互作用が悲惨で、素人には使わせられない。 # なんと適当な書き方だろう、一時期ずっと使っていたクセに。 Java C++よりもランタイムで行なう部分が大きい(特にGC)し、プログラマの裁量も低いので、ずいぶん扱いやすい。もちろん見方によっては全く逆の意見になる。 単一継承/インタフェースを強要させられるため、どうにもコードがごてごてする。ただし、エンタプライズ開発では、これは悪いことばかりではない。 Perl Rubyの1ヶ月前らしい。ネイティブPerl人が書いたコードはまさに暗号文で、一行解読するのに一日かかったりする。ちょっと言い過ぎか。

もうずいぶん前の話になるけど、Ruby技術者認定試験に合格したので、その話を書く。 僕は未だにRubyはあんまり使ってないけど、今後は使うことも増えてくるだろうし、会社のプッシュ(=報償金)もあったので受験した。ちなみに合格は 2009/6/13 だから、今とは変わっている所があるかもしれない。Gold試験は昔は無かったし。なので、たぶんSilver試験(Ruby Association Certified Ruby Programmer Silver)の話になる。 他の試験との一番大きな違いは、届く認定証が「出雲民芸紙」という手漉き和紙なこと(これ本気)。風合いが良いし、地元志向感がとっても良いなあと思った。 これが認定証の「紙の説明書」。うちの安物スキャナでは色合いがきれいに出なくて残念。こんな認定証は初めてなので、大切に保存しておこうという気持ちになる。 試験の内容に触れておくと、Rubyをバリバリ使っているぜ、という人が落ちるようなものじゃないと思う。短いコード片や基本的な文法、ライブラリなどについて問われる。 受験料がもったいないので、絶対に一度で合格したい！という人は、以下の本をやると良いと思う。 どんな感じで出題されるか、非常によく分かる。というか、出題者とこの本の作者は同じなんじゃないかな。これをぱぱっと解ける人なら、よほどミスらない限り合格すると思う。 Rubyをまったく知らない人は、まずRubyを軽く勉強した方が良いと思う。上記の本でも文法の説明など少しはあるけど、そういう種類の本じゃない。 要注意なのは、試験は(たぶん)Ruby 1.8について問われること。もう既にRuby 1.9がリリースされていて、文法面でも色々改善された点が多いけれど、試験対策にはRuby 1.8の本を買うように気をつけよう。 僕が読んだのはこの「たのしいRuby」第2版。すでに第3版が出ていて、そちらはRuby 1.9にも触れているみたいなので、実用には第3版の方がいいかもしれない。 この本はどちらかというと初級者向けの本。なので、他言語の経験者は少しまどろっこしく感じるかもしれない。僕はこの本を一通り読んで、気になる所は実際にコードを書いて試して、軽く流した。その後上記の公式ガイド本を読んで、受験したという感じ。 その後、以下の本も買ってしまった。 「初めての」とあるけど、これは初級者向けではない。他の言語をちゃんと経験した人が「初めて」Rubyに向かうための本。だから記述もあっさりしている。こちらの本の方が薄くてページは少ないけど、情報量は多い。ちなみにRuby1.8とRuby1.9と両方に触れている。 どちらの本も内容は良いと思う。どちらか一冊にしようとして悩む人は、amazonで目次を見比べてほしい。後者の本の目次をみて「こっちの方が良さそう」と感じる人には、そっちの方が良いと思う。