Windows98マシンを復活させる

うちではオーディオとして保存されているVAIO MX2。

CD, DVD, MD, FMをサポートし、ファームウェアによるオーディオ再生も可能。 スピーカーOUT, PHONE OUT, RCA OUT, OPTICAL IN/OUTを備える本格的なオーディオ機器でもある。 素直で良好なスピーカーとスピーカーケーブルで接続、サウンドカードにはAureal Vortex2 (AU8830)。

システムを再インストールしたのだが、緑の画面にマウスがないと表示されてしまい、進まない。USBマウスを接続しているのだが。 もちろん、Linuxでは問題なく動作する。 「シリアルマウスを接続してください」とあるにも関わらず、USBマウスはサポートしていないようだ

仕方ないのでAmazonでPS/2マウスを購入(もしかしたらドライバCDを入れておけばよかったのかもしれない)。 だが、今度はディスクを認識できないというエラーなより起動不能に。

これまでアダプタを介して2.5inchのIDEハードディスクを接続していたが、この問題により結局起動できなかったため、Amazonで3.5inch IDE HDDの新品を購入した。 私が買って販売終了してしまったようなので、タイミングがよかったようだ。何万円もするようなものが多い。

これで健全な状態となり、無事にWindows 98SEが起動した。 散々ひどい扱いを受けたコンピュータだが、動作してくれて本当によかった。

懐かしいUI、フィーリング、素晴らしいとは思うが、やはり古い。 Ethernetは持っていない。PCカード接続のイーサネットカードが必要だ。USB1.1インターフェイスは低速で、USBペンドライブですら個々にドライバーが必要となる。 UIも全体に古くて不親切。昔のコンピュータを感じさせる。接続規格が古いためどうしようもない部分は大きい。

Linuxならばその性能をーフルに発揮でき、最新のOSが動作する。 メモリーを192MBとしているため、DebianDog Porteusがかろうじて動作する。ただし、nVIDIAごでおカードの関係で、nomosetsetxforcevesaオプションをつけて起動する必要がある。

Linuxにおいてはau8830というのはそれなりに困難なカードのようだ。 そのため、折角の音楽性能だが、VoyageMPDを動作させるのはそれなりに苦労が必要なようだ。 リモコンの対応も考えると、あまりメリットがないだろうか。MPD前提ならば、ジャンクのネットブックと、1万円を切るUSB-DACを接続する方が良いからだ。

Windows98に対応した「超録」を使ってS-YXG50の曲を録音しようとしたのだが、どうも録音できない。 色々試したのだがダメそうだったし、情報もないので、MX2の強みを活かし、Optical OUTで出して録音することにする。 ただ、Opticalケーブルがないので、それはAmazonベーシックに頼る。

Fcitxで定型文入力

少しでも宣伝になればとTwitterで定期ポストすることを考えていたのだが、やはり評判悪いので定期ポストはやめて、手動不定期にすることにした。

だが、やはりそのためには定型文入力が必要だ。定型文入力は当然だが、IMが持っていてくれるのが最もスマートな方法であり、Mozcかfcitxになんかないかなぁ、と思ったところあった。

Fcitx Quickphraseだ。

Fciix QuickphraseはFcitxのアドオンであり、Manjaro Linux(Arch Linux)のfcitx 4.2.8.6-2には標準で含まれていた。 GTKの設定ツールであるfcitx-configtoolによって設定を開いたら、アドオンのタブにQuick Phraseはある。 あとは設定していけば使えるようになる。 私はトリガーをなしにして、Ctrl+@をカスタムトリガーに設定した

どうも長さに制限があるようだが、かなり使える。 というのは、フレーズによって絞り込まれる方式だからだ。 例えばabcというキーワードを設定した場合、aでもう候補としては表示されるが、abと打てばさらに絞りこまれていく。 表示できる候補数に制限があるため、同じキーワードでいくらでも設定できるわけではないが、この絞り込みはスムーズで非常に有用だ。 デフォルトで少数の絵文字(しかも変わったものが多い)と、LaTeXスタイルで入力できる記号が登録されている。

TwitterのQuickphraseなので、キーワードtwiで2つ登録した。Ctrl+@で起動した後、twで完全に絞り込まれる(tだけだとtable throwにひっかかる)。

これでTwitterでのプロモーションを投稿しやすくなった。

「コンピュータのなんでも屋」をしています。個人様・団体様・企業様問わず高い技術であなただけのサービスを。家庭教師サービスもやってます! @akiSIpr

作曲家・音楽プロデューサーをしています。一般の方も曲制作・個人授業などご依頼いただけます。 @HARUKASound

ヨドバシ・ドット・コムに足りないもの~ヨドバシ・ドット・コムとAmazonについて

Amazonとヨドバシ・ドット・コム

インターネット通販の王座として君臨するAmazon。 Amazonはとても便利だ。多くの場合、特にほかをチェックすることもなく、とりあえずAmazonで買う。 だいたい安いし、送料や消費税で悩まされることもない。だいたいなんでも揃う。 何よりも迅速な不良対応がいい。不良を報告するとすぐに代わりの品を手配してくれる。 この場合、本当に不良なのかということをチェックしたりもしないし、返品送料もかからない。 さらに、日本郵便との連携で、簡単に返送できる。

この王者Amazonのサービスのあまりの強力さにまともなライバルも登場できない状態だが、それに対抗しうる存在といえばヨドバシ・ドット・コムをおいてないだろう。 そんなことがBusiness Journalにもまとめられている。

ヨドバシ・ドット・コムがAmazonに対抗する強力さについてはその記事にしっかりとまとめられている。 実店舗があることの強み、ショールーミングを逆手にとった戦略、総合性と配送の強みだ。

実際に私は

  • Amazon
  • ヨドバシ・ドット・コム
  • ビックカメラドットコム
  • MonotaRo
  • サウンドハウス

を利用している。ごく一部のものに関してのみYahoo Shoppingやコーナンを使ったりもするが。

ほぼAmazonしか使わないといっていいくらいにAmazonを使っている。ビックカメラドットコムは、Amazonのマーケットプレイスでビックカメラが最も良い時はビックカメラドットコムで買ったほうが良いから、というだけのことだ。

MototaRoは総合性はなく、どちらかというと事務用品などの独自アイテムを購入、サウンドハウスはもちろん購入するものはずっと限られる。 つまり、Amazonで買わずにヨドバシ・ドット・コムで買うことが時折ある、ということだ。

ヨドバシ・ドット・コムの良いところ

  • ポイント還元がつくこともあり、Amazonよりも安い傾向がある。Amazonはポイントが極めてつきにくい
  • 配送のメリットというのは大きい。非常に早い。また、Amazonではプライムですらできないことが多い時間指定が確実にできる
  • Amazonほど扱いやすく優れた梱包ではないが、がっちりと梱包されるため安心感がある

ヨドバシ・ドット・コムの問題点

返送の問題

もうこれが致命的だと思う。

私が妙に運が悪いこともあるが、私が受け取る初期不良率は5%を超える。 そのため、高くてもAmazonで買えば問題があればすぐに交換できる、というのがメリットなのだ。 ちなみに、「他のものへと交換する」ということも可能だったりする。原則、元のものよりも高いものだが。

対して、ヨドバシ・ドット・コムの返品は結構手間だ。やったことはないが

  • ヨドバシ・ドット・コムに対してメールする
  • メール返信にて指示を受ける
  • 着払いで送る
  • 向こうで確認してから、代わりの商品が発送される

らしい。Amazonの場合

  • フォームにしたがって不良を報告する
  • この時点でかわりの商品が用意され、発送される
  • ウィザードにしたがってラベルを印刷し、あとは日本郵便が取りに来てくれる

はるかに楽で、中華ガジェットも買いやすい。

ラインナップと使い勝手

これもかなり根本的なことだ。

一見するとAmazon並みのラインナップを誇るように見えるが、そのほとんどは「販売終了品」で、たいていは買おうと思っても選べない。 検索に販売終了品がひっかかることでものを探すのもだいぶうんざりする。

最近ではパネルヒーター、小型こたつ、こたつ布団、FMアンテナ(アンテナワイヤー)、AMアンテナ(ループアンテナ)でそれを味わった。 掘り出し物も少なく、「選べない」という印象が強い。同じもので比較すればAmazonよりも安価でも、聞いたこともないような安価で協力な商品を見ることもないため、実際に買い物をしようとしてAmazonよりも安いこともあまり多くない。 シーズンに左右される傾向もあり、「こういうものがほしい」と思った時に選ぶ気にはなかなかなれない。

検索性や閲覧性もあまり良くない。 通販でサイトの使い勝手が悪い、というのはもう致命的なことだと思う。 楽天やYahoo Shoppingよりはマシだが、Amazonには遠く及ばない。

Cinnamonでディレクトリを開くとVLCが立ち上がるようになった

Cinnamonでディレクトリを開くとVLCが立ち上がるようになった

特に変更した覚えもないのだが、Cinnamonでディレクトリを開くとVLCで開かれてしまう。 デバイスマネージャアプレットから開いても、Autorunで開いてもそうなるためかなり不便だった。

結局

xdg-mime default nemo.desktop inode/directory

で解決した。

アップデート不能

シングルディスク構成にしてもgrub-probeのunknown filesystemエラーによってmkgrub-configがコケるため、アップデートできなくなった。

しかも、アップデートでコケるとカーネルが壊れていると言われて起動できない。

早くManjaro 0.9.0を出してくれないとどんどんひどいことになる。

COWON M2で64GBのSDXCカードを使う

ポータブルデジタルオーディオプレーヤー・COWON M2はSDカードスロットを備えるが、その仕様は
「32GBまでのSDHCカード」
とあり、64GBのSDXCカードには対応しない。

検索してみると、英語のフォーラムで、特殊なフォーマッタを使えば利用可能だ、というような話が出ている。

やってみた。

SDXCカードは通常、出荷状態でexFATでフォーマットされているため、GPartedで再フォーマットする
(mkfs.fatを使ったが、ミスがあったため、直した)。

問題なく使えた。

MailDeliver2 : 完全にプログラマブルなフィルタ機能を持つMDA

MailDeliver2がついに完成した。 おおよそできてはいたのだが、テストできておらず、テストしたらまだまだ足りない機能があることに気づき、 また不完全な部分が多かったため、2日かけてデバッグ、テスト、修正を繰り返した。

概要

保存・配送

Mail Deliverは完全にプログラマブルなフィルタを持つMDAと、それを補助するユーティリティ群である。 フィルタ、ソーター、通知の基本機能を備える。

基本的にはLinuxあるいはUNIX向けで、MH形式のメールフォルダに対して保存することになっている。

localdelivがMDAだ。その役割としては、フィルタを呼び出し、フィルタに従って処理することにある。 フィルタはメールの保存の機能を兼ねる。もしフィルタがメールを保存も破棄もしなかった場合は、localdeliv自身がデフォルトのメールフォルダへと保存する。

デフォルトのメールフォルダもフィルタ同様の方法で決定することができる。 MailDeliver2はRubyで書かれており、保存先メールフォルダの決定はRubyのprocオブジェクトによって行われる。このprocオブジェクトにはメールのヘッダの情報に加え、それを取り扱いやすくした情報を加えたメールオブジェクトが渡される。 そのため、静的な文字列ではなく、より動的に保存先を決定することができる。 ほとんどの場合、これで事足りるだろう。

例えば、設定サンプルでは次のように書かれている。

DefaultRule: ->(mail) { "inbox/address/#{mail.in || "Default"}/#{mail.domain || mail.address }/#{mail.address}" },

これはつまり、

inbox/address/<ユーザーのアカウント名 | Default>/<相手のドメイン名>/<相手のメールアドレス>

というフォルダに保存される、ということを意味している。 多数のメールアドレスを使用して使い分けている人は、そのメールアドレスによって相手の意味は既に分かれているだろう。まず、自分のどのアカウントに送られたものかをフォルダで分けてしまうことで相手を分類でき、この3段階の分け方があれば「だいたい分かる」。

ちなみに、副次的な効果として、詐欺にひっかかりにくくなる。受け取りアドレスとドメインを必然的に意識するからだ。 メールの「名前」をAmazonにしてお知らせを装った詐欺メールを大量に受け取っているが、ドメインがAmazonでないためすぐ分かる。 銀行関連もすぐわかるだろう。なぜならば、名前はメールを開くまでわからないが、アドレスは到着した時点から既に意識しているからだ。

フィルタは完全にプログラマブルであり、Rubyで自由に書くことができる。 もちろん、保存と破棄はよくある処理なのでそれを助ける機能がある。

さらに、保存してそのメールの処理を完了するかどうかは自由に選べる。 例えば複数のフォルダに保存するとか、特別に直ちに通知するとか、あるいは保存はするけれど通知の対象からは外す、ということも可能だ。 destroymail()は通知のためのファイルを削除するため、savemail()のあとdestroymail()すると通知はされない。

フィルタは条件自体がプログラマブルなので、例えば差出人によってのみ判定できる、というようなことはない。条件に単にtrueと書けば、常に適用されるフィルタが書ける。 現在デフォルトではclamAVしかサポートしないが、もっと強力な何らかのフィルタによって判定することもできる。その場合は、その判定処理を条件式に書けば良い。条件式に渡されるメールオブジェクトから完全なメール本文を得ることも可能で、IO.popen$?を用いて外部プログラムを条件として使用できる。

そのためにルール記述がやや難しいことは否定しないが、最低限であればマニュアル通りに記述することで、常識的に判断できる人ならば動かすことはできるだろう。

通知

通知機能はプラグイン方式を取っている。

そのため、して欲しい通知方式を好きに組み合わせることができる。 現在はnotify-sendを用いたGUI表示機能と、play(SOX)を用いた音声通知機能を備える。

ディスプレイ表示機能はプログラマブルではない。選択式だ。 「アドレス」または「Fromの値」のどちらかで、各差出人あたりの通数か、 または総数を通知する。

音声通知機能はプログラマブルだ。 音声ファイルは静的に指定しなければならないが、適否に関してはProcオブジェクトなので、その気になれば判定とは関係のないプログラムを書くこともできる。

その重要性は、アドレスのマッチングにしても

  • 完全一致
  • case insensitiveな一致
  • Glob
  • 正規表現

とそれらの否定から選べることにある。また、論理和、論理積も使用可能だ。 一致だけでは大量のルールを書かなくてはいけない場合に、同じファイルを再生させる場合も楽になる。 設定ファイルの中でインスタンス変数を定義しておくことで、例えば複数のアドレスをマッチさせる、というようなことも可能だ。 マスター設定ファイル内でアドレスごとのグループを設定しておくこともできる。

何がしたかったかというと、「ケータイメールのような使い心地」だ。 ケータイならば、着信音で相手が分かる。通知で、メールを開かなくても誰から来たかも分かる。 「着メロ」機能があるMUAは極めて少ない。着メロ機能と強力な振り分け機能を兼ね備えるものはない。 そもそも、振り分けのルール記述が極めて面倒だ。

そのような、大量のメールを受け取る人が、効率的にルールを書くことができ、メールを確認したり処理するための効率を大幅に向上させる、画面にかじりついていなくても、その時がきたことをアクティブに教えてくれる、という使い心地を、MUAではなく、MDAで実現した形となる。

1からの変更

まず、完全にRubyになった。 フルプログラマブルにするために、今まで開発効率からZshを使用していた部分に関しても、全てRubyとした。外部プログラムでなく、ライブラリの呼び出しとすることで、連続したマッチングも高速化でき、また渡せる情報も大幅に増えた。

一部手段としてUNIX系OS固有のものを使用しているが、恐らくWindowsに対して移植可能なものになったというのもメリットだろうか。 問題はKernel.forkを使用していることと、playコマンドやnotify-sendを使っていること、Sound Notifyはログを/dev/nullに書いていることだろう。

当然、このこととセットになって、よりプログラマブルになった。 そもそもの出発点が、フィルタが保存する内容には関与できない(保存するフォルダを出力するだけだったため、必ず保存されるし、保存内容を加工することもできない)という点が要求を満たさないケースがあったことについてだ。

これに対応したため、メールの破棄や、保存内容の加工も可能になった。 メールオブジェクトがメール全文を持っており、それがそのまま書き込む内容でもある。 メールを破棄した場合は、通知にも残らない。

構造がすっきりして、手を加えることもしやすくなった。 これまで通知系はプログラム自体を変更して、手元で専用のものにしていたが、汎用性があるものとなり、 単にプラグインフォルダに入れているものが適用されることとなった。

このあたりは、自分用だったものが、使ってもらうことを考えた変更が加えられたといっていい。

このほか、開発効率を優先して非常に複雑な構成(トリッキー)だったプログラムが、しっかりと設計されたものに変更されたため、挙動を把握しやすく、プログラマブルな部分がちゃんと活かせるようになった。 従来はフィルタが動くはずのものを書いても動かないことが多く、デバッグも難しかった。 今回はデバッグしやすいようにログもわかりやすいしてある。 これは、プログラマブルなためにユーザー定義部分でプログラムのエラーがでる場合が多いからだ。

プログラム

見どころは多いが、いくつか紹介。

プラグイン

単純にロードしているが、

class StandardNotify
  PLUGINS = []

と名前に約束を作り、プラグインは自身のオブジェクトをStnadardNotify::PLUGINSにpushする。 プラグインはfireメソッドをインターフェイスとして義務付けられている。

メールの準備

ヘッダとボディは次のようにして取得。

head, body = NKF.nkf( "-w -Lu -m", mailstr ).split(/\r?\n\r?\n/, 2)

ヘッダは次のコード

    head.each_line do | l |
      if l =~ /^\s*$/
        break
      elsif l =~ /^\s+/
        headerlines.last.concat(l.lstrip)
      else
        headerlines.push(l)
      end

    end
    
    headerlines.each do |i|
      if i =~ /\A([-_A-Za-z0-9]+)\s*:/ # match header format?
        mailobj[$1.upcase] = $'.strip
      else
        next
      end
    end

caseやspaceなどを守らない変なメールに対応するための措置を取っている。

メールアドレスの抜き出し

恐らく最もテクニカルだ。

  def extract_addr(f)
    if f =~ /(?:[^"<]*(?>"[^"]*"))*<([^>]+)>/ # Do From term have NAME<addr> format?
      address = $1.delete("\" \t/")
    else
      address = f.delete("\" \t/")
    end
    
    address
  end

単に仕様だけでなく、実際に使われている形式に則っている。 アドレスをクォートしているものに対しては対応しない。

メール方向の判定

    if @maildeliv_conf[:MyAddress].any? {|k, v| in_k =k; File.fnmatch(v, from) }
      mailobj.direction = :send
      mailobj.address = to
      mailobj.in = in_k
      
    elsif @maildeliv_conf[:MyAddress].any? {|k, v| in_k =k; File.fnmatch("*" + v + "*", mailobj["TO"]) }
      mailobj.direction = :recieve
      mailobj.address = from
      mailobj.in = in_k
      
    else
      
      mailobj.direction = :unknown
      mailobj.address = from
      mailobj.in = nil
    end

fromtoもアドレスを抽出したものだ。 差出人アドレスがマイアカウントとして定義されたものと一致するか?をチェックしている。 ちなみに、Toは単一とは限らないので、Fromを先に判定するのが確実で好ましい。

「これからの時代はアセンブラが必須」という意見に対して

週アスプラスのiPad教育の危うさとは 教育ハックの光と影という記事を読んだ。 ツッコミどころが多かったので、ちょっとこれについて言及したい。

機械語が必須だ、機械語を知っている人だけが高級をとる時代になる、というのは、単なるノスタルジーだ。

低レベルが重要だというが、実際のところ機会を直接叩く場合でもアセンブラでさえ書くことは今やまずない。 というよりも、ドライバであってもかなり複雑なコードになっているため、そのようなことは不可能だと言っていい。

実際、Linuxではドライバも見ることができるが、これをアセンブラで書けるかというと、極めて現実的でないことは一目で分かる。 仮に書いたとしても、クオリティが低下する上に移植性のないコードができあがる。 ドライバの移植性というのは難しいところだが、今やx86だけとは限らないのだし、クロスプラットフォームデバイスが前提となるだけにどのみち各アーキテクチャ向けに書くことになるのだから、いずれにせ移植性は必要だ。 例えそのまま動かないにしても、ベースとなるコードがあるかどうかの差は大きい。

もっとも、これはコーディングやエンジニアリングと全く別の次元にある問題だ。 話している内容が全く的を射ていない。 本当にプログラムが書けるのかすら疑問な発言だと私は感じた。