utf-8環境のemacs -nwで●とか▼とか。
昨今のutf-8が標準な環境で、端末でemacsを-nwで使おうとすると、●とか▼とか○とか□なんかが、幅が誤認されているのか、重なってしまいます。
一般的な文章では特に問題ないかもしれませが、伏せ字が頻発する業種なので、これでは使えません。
emacs22でビットマップフォント(っていうかアンチエイリアスが効かない)で使う分には問題は出ませんが、emacsは端末で使いたい(好みでしかありませんが)。これの、確実かつ本末転倒な解決方法を見いだしました。
- set-terminal-coding-system euc-jp-unix
- set-keyboard-coding-system euc-jp-unix
- set-buffer-file-coding-system utf-8-unix
わはは。どうだ! 本末転倒でしょorz。しかし、オ○○コであろうと、オ▼■コであろうと、予定通りに表示、編集でき、かつ。utf-8で保存できます。なんということでしょう! euc-jpが標準だったシステムと同じじゃありませんか(w
もちろん、そのままの状態だと、まともに日本語が表示されないので、端末の文字コードをeuc-jpにします。昨今の端末はタブ式だったりして、タブごとに文字コードが変更できるので特に問題は出ません。タブが嫌いなら、screenで encoding eucのバッファを作れば同じことができます。
ただし、scim経由で入力すると、○とか▼とか■なんかが化けるので、emacsでanthyとかcannaとかお好みのIMを呼ぶやつで入力しないといけません。
これで気分よくエロサイトと一般雑誌サイトのカスタマイズができます。
と、あれこれめんどくさいことをして仕事が終わってから気がつく、後の祭りorz
こうですか? わかりません。
PCの時計を見たら、なにやら見覚えのある数字が……。
なんだっけ? 誕生日パーティーはこないだやったしな……。
と、思ったら、普通に誕生日でした。先日は息子の誕生日で、日にちが近いので合同誕生パーティーだったのでした(w。マジボケぎみです。年は取りたくないものです。ははは……。
なんというか、こう、42ですよ。世が世なら隠居していて当たり前な年齢(まぁ、平安時代ですけど)。まったくエラいことになったものです。
茄子買った。
ファイル置き場が逼迫して来たので、外付けHDDを買いにいきました。
500GBを二台ミラーにして、もう一個を諸々バックアップの場所に。で、3本か……。
何でそんなにいるかというと、ミラーの片割れは、いっぱいになったら外して、しまっておくわけです。残った片割れが死んだら、もう一台買ってきて、まるっとコピーして、またしまう。これで、流用の可能性があるデータをなんとなく保持しているわけです。もう一台は進行中のバックアップ用。バックアップは、内蔵の片割れに一つ、外付けに一つ、ミラーになってるサーバに一つで、物理的に4ヶ所に取ります。なんでそんなに取るかというと、こんなことがあったり、ヘッドが着陸して禿げしく昇天したりという現場に遭遇したからです。
ということで、買いに行ったんですが、1TBのNASが11万じゃありませんか! なんということでしょう! 最近幸いなことにHDDが壊れなかったので世間相場に疎くなっていました。ここで数万ケチると、あっという間に一杯になってしまうのは会社のサーバで学習しましたので、根性で2TBのやつとスペアディスクを1台買いました。
置き場とかタコ足とかを考えると台数は少ない方がいいし、別々の機械にしてみたところで、イクときは一緒にね(はーと)みたいな亡くなり方を見てきたので、冗長性という意味ではこんくらいだと大差ない気もして……。本格的な冗長性が必要なほど重要なデータは入校前のデータくらいだし……。
起動して設定画面を見ると、どこかで見たデジャブ……。
あ、ここだ。
CLさんとは違ってキャバクラには行かないので(wいくらか大丈夫だとは思いますが、買って2ヶ月か……。明日は我身……。
転ばぬ先のスペアディスクも用意してあるし……。だ、大丈夫かな……。まぁ、HDD。特にATAとかSATAは当たり外れが激しく大きいので、年明け早々かもしれないし、5年後かもしれないのでなんとも言えませんが……。
それはそうと、中の人はnetatalkだと思うんですが、うちのnetatalkタンと似たようなファイル名でのエラーが出ますね。自分で作ったファイルはその辺を気にしてるので大丈夫ですが、よそから来たファイルで頻発。88FFの豆腐とOS9で見ると全角スペースな83がよくあります。何でできるんだろ? 他にもいろんな組み合わせの豆腐がダメ。OSXからだと大丈夫だったりもするのでOS9→netatalkの問題っていうか、iconvタンが文字コードを変換するとこなのかな?
コピーできないファイルをうちのnetatalkタンにエラーを出していただくと、
Nov 16 10:05:04 kurone afpd[18953]: Conversion failed ( MAC_JAPANESE to CH_UCS2 )
っていうエラーが出てるので、ファイル名の文字コードを変換しようとして失敗してるっぽいです。
あと、同時にコピーしようとするとダメだけど、個別にコピーすれば無問題とかいうのがあったり……。OSXserverなら何事もなかったようにコピーするんで、このへんのファイル名のどうでもよさはOSXserver最強なのかもしれません。
ちなみにIllustrator8.0.xのバックアップも取れません。ハイフネーションファイルの名前が長い奴(フィンランド語とか)で、「ハイフネーシ」で止まってる奴がコピー不能です(w。まぁ、この辺は設定さえ取っておけば、再インストロールすればいいわけですが……。
python最強伝説
もっとも信頼できる情報源によれば、数多あるプログラム言語の中で、pythonが最強だそうです。
JAVAとPerlを比較の対象外の彼方まで付きはなしています。一般的には速いと思われているCですらPythonの敵ではありません。
JAVAは続きが書けないので試していませんが、っていうか、エクなんたらの使い方すら知らんし……。
Cは出典と似たような環境で試してみました。確かに、10秒ちょっと(壁掛け時計による正確な目測)かかりました。遅っ!
Perlに至っては、あまりの遅さに途中で試すのをやめました。待ってられません。忙しいんだから(w。
それに引き換え、Pythonの爆速さ。コードを書くよりも先に答えが出ているくらいです。素晴らしい。さすがPython。やっぱ最強です。極論すればpythonなら、コーディングすら不要。
これほどまでに公平(w)なベンチマークテストがあったでしょうか?
やっぱ、これから勉強するならAppleScript日本語版ですね。うん。