Windows 8 へのアップグレード

5年前発売の VAIO type L (VGC-LJ91S、2008年 1月発売の Vista モデル、Core2 Duo T2750、メモリ 2GB) を Windows 8 にアップグレードした際に気づいたことをメモ書きしておきます。 これも早めに記事にしないとまずい内容でしたね。

準備など

まずは Windows 8 アップグレードアシスタントを実行して、致命的な問題がないことを確認します。 互換性リストを保存しておけば、メーカーサイトへのリンク等を含めて保存することができます。

今回は Vista 32ビット版から Windows 8 への 32ビット版へのアップグレードで DVD パッケージを購入しました。 この場合、アプリケーションはインストールし直しになります。 「Windows の設定」は引き継ぐオプションを選択することにしました。 アプリケーションは再インストールとなるので、Adobe 製ソフトウェアのようにライセンス解除が必要なものは忘れずにしておきましょう。

インストール

インストール自体は特に問題なく進みました。 インストール中に既存アカウントを Microsoft アカウントに変換するよう聞かれますが、これは後からでもできるのでまずは変換せずに進みました。 ちなみに後から変換する場合はコントロールパネルのユーザーアカウントメニューで「PC 設定でアカウントを変更」を選んで行います。

インストール後の設定

まず、キーボードが 101キーボードと認識されたので、106キーボードに直しました。 Windows 7 と同様にレジストリの設定を行っています。 参照先記事にある remapkey.exe による Ctrl と Caps Lock の入れ替えも同じようにできました。

また、SkyDrive アプリは Windows 8 に含まれているのですが、デスクトップ用 SkyDrive はダウンロードしてインストールが必要でした。 ダウンロードページを見るとインストールが必要なのは Windows 7 までのようにも読めるのですが、Windows 8 でも追加インストールが必要でした。

アプリケーション関連

既にサポートが切れているので互換性リストでは「互換なし」になっている Office XP Personal や Bookshelf Basic 3.0 なども無事動きました。 私の使い方では特に問題なさそうです。 Windows 7 だと Office XP のライセンス認証は単体の「ライセンス認証」アプリケーションで実施しなければならないという話もあったようですが、今回はアプリケーション内から実行して特に問題ありませんでした。

使用感

動作は Vista の時よりも快適になりました。 しかし、それは単純に Vista と 8 の差というわけではなく、プレインストールされていた諸々が動かなくなったからというのも大きいと思います。 動作は軽くなったものの、やはりタイルとアプリの使い勝手というのはこれまでとだいぶ違います。

私はもっぱらデスクトップを使うのでスタートメニューが無いのがかなり違和感ありますね。 いろいろとショートカットキーを活用せねばならず、とりあえず Windows ロゴキー単発のデスクトップ切り替えと Windows ロゴキー + R のファイル名指定実行を良く使っています。 Windows ロゴキー関連のショートカットキーは押さえておいた方が良さそうです。 あとこの辺も。

デスクトップ上のショートカットもこれまでより使っていますね。

その他

Windows Media Center のプロダクトキー発行は 72時間以内と言っていますが、それ以上かかってから来ました。 どうも人力で対応しているように思えます。 Windows 8 からの初回申請以外はエラーになるようですが、今一つこの辺りの動作がはっきりしません。 無料提供キャンペーンが 1/31 までなので、メールが届かないのが気になるのであれば早めにサポートに連絡するのが良いと思います。 ちなみにプロダクトキー通知メールには 2/1 までにアクティベーションするよう記載されています。

WordPress のリビジョンについての間違った認識と正しい対処

WordPress のリビジョン機能は冷遇されているようで検索すれば無効化する方法がたくさん見つかります。 一方でこの機能が「使える」ものだったらやっぱり使いたいよなあ、という人も多いのではないでしょうか。 ブログ記事は書き捨てというやり方だけでなく、注目を集め反応が多かった記事に情報を追記していく場合もあるでしょう。 また、WordPress のビジネス利用も増えていますが、そうであればなおさらリビジョン管理は重要です。 そこで今回は現行のリビジョン機能の何が問題でどうすれば解決するかをまとめたいと思います。

まあ、リビジョン機能止めて別に困らないという人はそれでいいのですけれど。

まずは正しい認識を

まず、WordPress のリビジョン機能について正しい認識を持ちましょう。 あまり理解されていないように思われるのは以下の点です。

  • 自動保存は 1世代のみ
  • リビジョンが作成されるのはポストテーブル (wp_posts) 内容のみ。 wp_postmeta や wp_term_relationships などの関連テーブルは (プラグイン等を用いない限り) リビジョンが作成されない。

つまり、デフォルトの 60秒間隔自動保存でバンバンリビジョンが増えていくというわけではないです。 また、ポストテーブルのリビジョンのみ、すなわちカテゴリーやタグの付け替え履歴は残らないので、WordPress のリビジョン機能は、基本的に記事にしたテキストデータの変更履歴を取るための機能と捉えるのが良いと思います。

データベース関連についても一言言っておきます。

  • 通常の一記事表示ではインデックスを使用した検索になるので、ポスト数が増えても検索時間は比例しない。 なので、個人ブログレベルであれば、リビジョンを作成したからといって (よほど作りの悪いテーマやプラグインを使っていない限り) パフォーマンスに影響が出ることはまずない。

まあ、データベースの容量に関しては確かにリビジョンを作成することでその分使用領域は増えます。 しかし、所詮テキストデータなので、画像に比べればたかが知れています。

あっ、まさかリビジョンを作成するとそのページで使った画像まで何世代も保管されちゃう、なんて思っていたりします? 念のために言っておきますが、それはないです。 イメージデータそのものはデータベースに入らないですし。

もう一度書きますが、リビジョンが作成されるのはポストテーブルの内容のみです。 ポストテーブルの内容を知らなければこちらで確認しておきましょう。 タグやカテゴリーの情報はポストテーブルに入っておらず、別テーブルから post_id を使ってポストテーブルを参照するようになっています。

でもリビジョン多くね?

と、ここまで読んでも「実際には多数リビジョンが出来てるし、嘘書いてんじゃねーの?」と疑っている人もいるでしょう。 確かにリビジョンが多く作成されてしまうのは事実です。 これは WordPress の以下の動作によるものです。

  1. 下書きの状態 (公開前も含む) でプレビューをするたびにリビジョンが作成される。
  2. クイック編集や一括編集でもリビジョンが作成される。

1. については思い当たる方が多いのではないでしょうか? 公開前はプレビュー操作を行って最終的な見栄えをチェックしながら文章を調整することがあると思いますが、そこでプレビューする度にリビジョンができてしまうのです。公開された記事のプレビュー操作では自動保存リビジョンとなるのでどんなにプレビューしても 1世代なのですが、公開前だと何世代ものリビジョンができてしまいます。 たいていの場合は公開初版のリビジョンだけあればよいですよね。

2 については更に不要です。 このような編集方法を採るときはタグやカテゴリーを直す場合が多いと思うのですが、そうなるとポストテーブルの項目に変更は発生しないことが多いにも関わらずリビジョンが作成されてしまうということになってしまいます。 ですので、リビジョン比較をしても「同じ内容です」というちょっと悲しいリビジョンばかりできてしまいます。

どうすりゃいいのさ?

さて、これらの不要なリビジョンを保存せずに、意味のあるリビジョンだけ残すにはどうすれば良いのでしょう? ちょっと考えてもどうしようもなさそうですね。 でも簡単な解決策があるんです。 それは…。

(縦に長い空白地帯)

じゃーん。 リビジョン管理用のプラグイン「Thin Out Revisions」を使えばよいのです。 以下の手順で不要なリビジョンとおさらば!

  1. あなたのサイトのプラグイン検索画面から Thin Out Revisions を検索してインストール、有効化する
  2. 「設定」-「Thin Out Revisions」とメニューを選び 3項目全て ON にして保存する

えっ? 作者が日本人っぽい? どっかで見たアイコン?

…実は私がつくったのです。

ステマではありません。作者による告知です! それとこんな機能もあります。 気に入ったら是非つぶやいたり、「いいね!」したりしてください。お願いします! お願いします!

(後半雰囲気を変わってしまいましたが、同じ著者によるものです。セッティング項目の見出しは一応読んでね。)

Facebook for WordPress と Social Interaction Analytics

今回は Facebook と Google の Social Interaction Analytics の話です。 Facebook 関連シリーズ (1回目2回目) も今回で一区切りです。

初期化コードとイベントリスナー

詳細は Social Interaction Analytics のページに書いてあるので簡単にすませますが、Facebook の「いいね!」ボタンが押されたのをトラックするには以下のようなコードでイベントリスナーを登録します。

FB.Event.subscribe('edge.create', function(targetUrl) {
  _gaq.push(['_trackSocial', 'facebook', 'like', targetUrl]);
});

先の記事に書いた通り、fb_xd_fragment の件もあって WordPress で「いいね!」ボタン等 Facebook の機能を使うのであれば、Facebook for WordPress プラグインがお勧めです。 しかし、ここでの問題は上のコードをどこに置いたらよいかということです。 Facebook for WordPress を使用すると以下のようなコードがページに埋め込まれます。

<script type='text/javascript'>
/* <![CDATA[ */
window.fbAsyncInit=function(){FB.init({"channelUrl":"https:\/\/hetarena.com\/wp-content\/plugins\/facebook\/channel.php","status":true,"cookie":true,"xfbml":true,"appId":"my_app_id"});}
/* ]]> */
</script>
<div id="fb-root"></div><script type="text/javascript">(function(d){var js,id="facebook-jssdk",ref=d.getElementsByTagName("script")[0];if(d.getElementById(id)){return;}js=d.createElement("script");js.id=id;js.async=true;js.src="http:\/\/connect.facebook.net\/ja_JP\/all.js";ref.parentNode.insertBefore(js,ref);}(document));</script>

これは非同期のスクリプトファイル読み込み処理と初期化コードです。 非同期のため、何も考えずに先のイベントリスナー登録コードを書いてしまうと FB という変数が未定義でエラーとなってしまいます。 プラグインの出力する window.fbAsyncInit の関数の FB.init の後に先のイベントリスナー登録コードを埋め込むことができれば良いのですが、プラグインに手を加えたくないですね。 どうすれば良いのでしょう?

facebook_jssdk_init_extras フィルター

実はちゃんと ‘facebook_jssdk_init_extras’ という名前でそれ用のフィルターが用意されています。 ここにコールバックを登録しておけば目的の位置にコードを出力することができます。 プラグインの readme.txt の中で以下のように説明されています。

* `facebook_jssdk_init_extras` – add extra JavaScript to the `fbAsyncInit` JavaScript function called after the Facebook JavaScript SDK is loaded

というわけで以下の様なコードを function.php に書いておけばオッケーです。

add_filter('facebook_jssdk_init_extras', 'my_facebook_init');

function my_facebook_init() {
  return
"
  FB.Event.subscribe('edge.create', function(targetUrl) {
    _gaq.push(['_trackSocial', 'facebook', 'like', targetUrl]);
  });
";

}

readme.txt やソースを読むといいことがあるよということで。

フィルタじゃNG! fb_xd_fragment の問題への正しい対処の仕方

「fb_xd_fragment が Google Analytics のログに残るのは Facebook の「いいね!」ボタンのバグなので、Analytics 側でフィルタの設定を行いましょう」という記事が世の中に溢れています。 ちょっと気になったので調べてみたところ、根本的な対処が必要であることがわかったのでメモ書きしておきます。

どうすればよいのか

先の現象のことは実は Facebook JavaScript SDK のドキュメントできちんと説明されています。 詳細はそちらを読んでいただくとして結論だけ言うと、対策は channelUrl というパラメータを設定して対応するページを用意することです。 channelUrl を設定するとパフォーマンスが向上し、逆に設定しないと以下のような問題が発生するので、設定することが強く推奨されています。 Facebook からするとこれらの問題はバグというよりも仕様なのでしょう。

  1. フレームを使うと Social Plugins が表示されないことがあります。
  2. 自動再生ビデオやオーディオを埋め込むと 2つのストリームを再生してしまいます。
  3. channelUrl パラメータを設定しないと fb_xd_bust や fb_xd_fragment といったパラメータつきのログが残ります。

というわけで fb_xd_fragment がログに出ているときの正しい対処法は channelUrl を設定することです。 ログのフィルタはそれができない場合の次善策ではありますが、1 や 2 の現象に関しては全く効果がありません。

具体的な対処方法は

JavaScript SDK ドキュメント からの抜粋ですが、以下のようなページを用意します。 PHP での例です。

 <?php
 $cache_expire = 60*60*24*365;
 header("Pragma: public");
 header("Cache-Control: max-age=".$cache_expire);
 header('Expires: ' . gmdate('D, d M Y H:i:s', time()+$cache_expire) . ' GMT');
 ?>
 <script src="//connect.facebook.net/en_US/all.js"></script>

そして「いいね!」ボタン等を設置するページに以下の JavaScript を埋め込み、非同期 js ファイルロードのコードと組み合わせて使います。 channelUrl のところに作成したページの URL を指定します。

<script>
  window.fbAsyncInit = function() {
    // init the FB JS SDK
    FB.init({
      appId      : 'YOUR_APP_ID', // App ID from the App Dashboard
      channelUrl : '//WWW.YOUR_DOMAIN.COM/channel.html', // Channel File for x-domain communication
      status     : true, // check the login status upon init?
      cookie     : true, // set sessions cookies to allow your server to access the session?
      xfbml      : true  // parse XFBML tags on this page?
    });

    // Additional initialization code such as adding Event Listeners goes here

  };
</script>

JavaScript の書かれたページと channelUrl のページとで document.domain およびプロトコルを合わせておかなければならないとのことなので、環境によってはサーバーサイドで処理が必要かも知れません。

WordPress を使用しているのであればずっと簡単に解決する方法があります。 Facebook for WordPress プラグインを使うのです。 これをインストールするだけで先の 2つの処理を加えてくれます。

余計なひとこと

今回、ちょっとがっかりなのは fb_xd_fragment について書いた記事は多いものの、channelUrl の対策をきちんと説明した記事は見つからなかったことです。 だからこそこうして記事にしているというのはありますが、残念です。

WordPress で簡単に OGP の設定を行う方法

Open Graph Protocol (OGP) についての記事は小難しいものが多いように見えたので触らないでおいたのですが、とりあえず対応するにはセマンティックな meta タグを埋め込むぐらいの話のようなので、これは対応せねばと思いました。 今回は WordPress を OGP に対応させるためにしたことをまとめます。

Facebook for WordPress プラグインを使うのがお手軽

OGP 対応で一番簡単なのは公式プラグインである Fackbook for WordPress をインストールすることです。 インストールしただけで特に設定をしなくても OGP 対応タグを記事中に埋め込むようになります。 「いいね」ボタン等の機能は無効にしておくことができ、埋め込む App ID の指定もできます。 公式プラグインという安心感があるので OGP 対応が目的の場合も Facebook for WordPress を選択するのが、良いように思います。

私の場合、App ID は今回初めて取得しました。 まだ、十分に調べることが出来ていませんが、App ID を記事に埋め込むことで様々な機能が有効になるので、きちんと設定しておくべきです。

以下 Facebook のサイト上で行うアプリ設定についての話です。 記事に埋め込んで機能させるためには、その記事を公開するサイトのドメイン (ここなら hetarena.com) を App Domains として設定しておかねばなりません。 また、App Domains に設定するためには、そのアプリと Facebook 統合方法でその URL が使われていなければなりません。 何にも設定しないと App Domains 登録でエラーになるので、例えば「Website with Facebook Login」のサイト URL として https://hetarena.com/ を設定しておきます。 こうすることで App Domains にも hetarena.com を設定できるようになります。

できるだけシェイプアップしたい

本当に簡単に済ませるのであればここまでで、ここから先はこだわりの話です。 OGP 対応のみが目的のとき、Facebook for WordPress の出力する余分な JavaScript が記事に埋め込まれるのが気になります。 そこで、Facebook for WordPress のソースを見てみると、OGP 対応は open-graph-protocol.php というファイルの Facebook_Open_Graph_Protocol というクラスだけを使えば済むことに気が付きました。 app_id と locale は呼び出し元クラスの情報を使っているのですが、以下のように強引に書き換えてしまいます。 my app id は自分 App ID です。 locale については特にデバッガーもエラーを吐かないので、省略しました。

--- a/includes/open-graph-protocol.php
+++ b/includes/open-graph-protocol.php
@@ -121,12 +121,7 @@ class Facebook_Open_Graph_Protocol {
                        self::OGP_NS . 'type' => 'website'
                );

-               if ( isset( $facebook_loader ) ) {
-                       if ( isset( $facebook_loader->locale ) )
-                               $meta_tags[ self::OGP_NS . 'locale' ] = $facebook_loader->locale;
-                       if ( isset( $facebook_loader->credentials ) && isset( $facebook_loader->credentials['app_id'] ) && $facebook_loader->credentials['app_id'] )
-                               $meta_tags[ self::FB_NS . 'app_id' ] = $facebook_loader->credentials['app_id'];
-               }
+               $meta_tags[ self::FB_NS . 'app_id' ]  = 'my app id';

                if ( is_home() || is_front_page() ) {
                        $meta_tags[ self::OGP_NS . 'title' ] = get_bloginfo( 'name' );

あとは functions.php に以下を入れます。 open-graph-protocol.php へのパスは適切に書きましょう。

require_once( '/path_to_ogp/open-graph-protocol.php' );
add_action( 'wp_head', array( 'Facebook_Open_Graph_Protocol', 'add_og_protocol' ) );

これで余分な出力はなくなり、OGP の meta タグのみ出力されるようになりました。

…とここまで書いてアレなのですが、埋め込まれている JavaScript に重要な働きがあることがわかりました。 fb_xd_fragment がログに残る件がらみなのですが、詳細は別記事でご確認ください。 そういうわけでこのようにクラスを切り出して使うのはお勧めしません。 Facebook for WordPress をそのまま使いましょう。 (この段落は 2012/12/4 追記)

アイキャッチイメージを記事に設定する

Facebook for WordPress (Facebook_Open_Graph_Protocol クラス) の動作では、記事に設定された「アイキャッチ画像」の情報を image プロパティとして埋め込みます。 Facebook のデバッガーによれば縦横 200px 以上のイメージをきちんと設定しておくことが推奨とのことです。 これまでアイキャッチ画像は使っていなかったので、新たに 200px 四方のロゴをアップロードして全ての記事のアイキャッチ画像として設定することにします。

(2013/1/20 追記: もっと手軽な方法がありました。)

まず、記事に見える形で表示したくないので、テーマファイルから以下の行を削除しました。

<?php the_post_thumbnail(); ?>

続いて記事へのアイキャッチ画像の設定ですが、面倒なので SQL で実行することにしました。 以下の SQL 文はアイキャッチ画像が設定されていない post/page に対して ID 654 の画像をアイキャッチ画像として設定するためのものです。

START TRANSACTION;

INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
SELECT id, '_thumbnail_id', 654
FROM wp_posts
WHERE post_type IN ('page', 'post')
AND NOT EXISTS
(SELECT * FROM wp_postmeta
 WHERE meta_key = '_thumbnail_id'
 AND wp_postmeta.post_id = wp_posts.id);

COMMIT;

何か失敗したときに Rollback ができるようにトランザクションを有効にして実行しています。 これで image プロパティも meta タグとして埋め込まれるようになりました。 これらを実行する時は、画像 ID だけでなくテーブル名も自分の環境に合わせてください。 マルチサイト環境ならば wp_2_postmeta、wp_3_postmeta、… となりますね。

これで「簡単な」なのかという声が聞こえそうですが、やっている内容に比べたら簡単にやっているのではないでしょうか…。(苦しい)

WordPress 用プラグイン Standard Widget Extensions を公開しました

WordPress のウィジェットの動作を拡張するためのプラグイン「Standard Widget Extensions」を公開しました。 既にWordPress.org のリポジトリに登録済みです。 私にとって Thin Out Revisionsに続く 2つめの WordPress プラグインです。

現バージョンで提供している機能はウィジェットというよりサイドバーの拡張用という感じですが、以下の内容をお手軽に実現できます。 Twenty Twelve/Twenty Eleven であればデフォルト設定のままで動きます。

  • Accordion Widget (開閉するウィジェット)
  • Sticky Sidebar (スクロールが止まるサイドバー)

スクロール関係については世の中にサンプルやら部品があふれているのですが、境界でぎこちない動作になるものが多く、レスポンシブ Web デザインやサイドバー伸縮との組み合わせを考えると結局自分で作った方がよいと思い開発しました。 ちなみにレスポンシブ Web デザイン対応という点では、ウィンドウ幅が指定された値より小さくなると機能が無効化されます。

開閉動作もありふれてますが、見出しのアイコンを変えたりできるので JavaScript の苦手な人がちょっと使うのには便利だと思います。 独自の CSS は最低限にしてテーマのスタイルをそのまま使用するようにしています。 以下は Twenty Twelve/Twenty Eleven/Twenty Ten に適用した場合の例です。 そのままではマージンが大きいので微妙かも知れませんが、最低限の追加スタイルということを理解していただけると思います。

Standard WE

動作についてはこのサイトの左側にあるサイドバーを見ていただくのが一番早いと思います。 WordPress 標準テーマの Twenty Twelve/Twenty Eleven/Twenty Ten で動作確認していますが、メインカラムとサイドバー、ウィジェットの ID/クラス名を設定することができるので、標準テーマと同じつくりのテーマであれば対応できると思います。 もし、興味があれば、是非 WordPress の管理メニューから検索してインストールしてみてください。

以下、プラグインのホームページです。

SoundCloud と WordPress

SoundCloud にアップロードしたトラックを WordPress のブログ記事に埋め込むには公式の SoundCloud Shortcode プラグインが便利です。 しかし、iOS の Safari でも表示可能なように HTML5 で出力するには気をつけなければならない点があります。 以下手順をまとめます。

SoundCloud プラグインをインストールすると「設定」-「Sound Cloud」でセットアップ画面を表示できるようになります。 まず、この中で Widget Type を HTML5 に選びます。

Setting

しかし、これだけでは不十分です。 リンクの形式は http://soundcloud.com/hetarena-com/saw-square ではなく、http://api.soundcloud.com/tracks/69089521 の形式でなければなりません。 この数字を見つける簡単な方法としては、SoundCloud.com 上の該当トラックで「Share」-「WordPress Code」で示されるコードを確認すれば良いです。

Share Track

「WordPress Code をそのまま貼り付けては?」という声も聞こえてきそうですが、油断すると「iframe="false"」というパラメータが入っていて Flash の埋め込みになってしまいます。 ちなみに私は設定画面で Auto Play = false、Show Comment = false として以下のようなタグコードを埋め込んでいます。

[soundcloud]http://api.soundcloud.com/tracks/66034316[/soundcloud]

というわけで見やすくなったので「ソフトシンセ時代のシンセサイズ入門」を是非ご覧ください。 あと、リバースシンバルの作成例つきの「Groove Agent ONE でマイキットをつくろう」も!

以下の記事を参考にさせていただきました。

エプソンプリンターとうまく付き合う

エプソンのパーツセンター

子供達は印刷するのが大好きです。 特に 5歳の娘はシルバニアファミリー等のサイトの塗り絵で遊んで大人には違いのわからないほど繊細な(?) 作品をたくさん出力しています。彼らはインク代など気にしませんから、きちんと制限枚数を伝えておかない大変なことになります。 しかも、手書きのお絵かき用紙もプリンタの用紙カセットから取り出したりして、結構乱暴に扱っています。 誰かは定かでないのですが (こういう時、子供達は皆そろって「知らない」と言います)、気がつくと排紙トレイのツメが折れてしまい、すぐに抜けてしまう状態になっていました。

うちのメインのプリンターは 2008年発売のエプソン製 EP-901A です。 部品を取り寄せようと思い、最初は修理窓口に連絡したのですが、そこでは部品の提供はしていないとのことで「パーツセンター」の連絡先を教えてもらいました。 パーツセンターに連絡を取ると代金引き換えで送付してくれるとのこと。 排紙トレイは 4段で 1セットとなり、それより細かい分売はしないそうです。

パーツセンターの連絡先は Web では公開されておらず、受領書返送用封筒も一緒に送られたりするのでエンドユーザーというより販売店向けのようです。 代金は全部込みで、1,186円也。 この 1,186円の内訳は聞かなかったのですが、ほとんどが配送料+代引手数料のようなので、余裕があれば店舗で取り寄せを頼むと良いでしょう。

いずれにせよ、パーツセンターの存在は知っておくと良いと思います。 必要があれば修理窓口で問い合わせてみてください。

ちなみに排紙トレイのパーツは EP-901A のものと現行品で溝の部分が若干変わっていて、3段分付け替えると用紙カセットの中に落ちやすくなります…。

買い換えのタイミング

先日、喪中葉書を印刷しようとして給紙がうまくいかず、焦って新しく EP-804AR を購入してしまいました。 この時は、

  • 印刷品質が劇的に向上することはなさそう
  • 無線 LAN 対応やメモリーカード類からの直接プリント等周辺機能も飽和気味

と考えて、1世代前のものでも十分と判断し昨年モデルの EP-804AR にしました。 16,000 円台で十分安く買ったと思いきや、価格.com の履歴を見ると 1世代前のモデルでも 11月から値上がりしていることがわかります。

ADF が調子悪かったり、出力に筋が入りやすくなったりしていて「使えるけどどうだろう…」というような場合は、どうせ買うのであれば季節変動で最安値の 8月~10月を狙って買い換えると良いと思います。

ちなみに赤モデルなのは Amazon のお急ぎ便で買えるのがこれだけだったからです。 ADF は ScanSnap があるので、不要としました。

その他いろいろ

その他、気づいたことをざっくばらんに書きます。 今更というのもありますが。

  • マニュアルを良く読むと出ていますが、インクは抜いてもオッケーなのですね。 昔の記憶で抜いちゃまずいと思いこんでいました。
  • 購入直後は製品付属のセットアップ用インクでないとダメですね。 EP-901A の使いかけインクで EP-804A をセットアップしようとしましたがエラーになってしまいました。
  • 今年のモデル (EP-905A/EP805A) から使用インクが変わっています。
  • 今更ながら下トレイにも葉書を入れられることに気づいたのですが、自動切り換えはしてくれないですね。
  • ソフトウェアをインストールする時に、既に旧製品用のソフトウェアが導入済みだと標準インストールを選んでも個別の製品についていちいちアンインストールの実行確認をされるので、放置しておくわけにいきません。 最初に古いソフトウェアをアンインストールしておくと良いのかも知れません。

エプソンプリンターと喪中葉書の相性はかなり悪い

この年末・年始は喪中なので欠礼の葉書を出さねばなりません。 郵便局の喪中欠礼用葉書 (胡蝶蘭) を買って宛名・文面はプリンタで印刷しようとしました。 我が家のプリンタは EP-901A です。 カミさんが文面データを作り出力していたのですが、給紙がおかしいと言い始めました。 様子を見ると確かに紙送りされません。 音から判断すると、ローラーが空回りするだけで紙を吸い込んでくれないようです。

4年使っていることもありプリンターの故障を疑ったのですが、結論としては買った葉書がまずかったようです。 こちらにも苦労されている方がおられますが、胡蝶蘭の葉書とEPSON のインクジェット複合機は相性が悪いみたいです。 今までこんな経験はなかったので、プリンターのせいにするのはちと酷な気がします。

で、今回はどうしたかと言うと…。

korokoro

クリーニング用の粘着ローラーが役立ちました!

見た目ではわかりませんが、先のリンクで「粉が付いている」という情報があったので、試しに葉書の裏表をコロコロしてみたところ、100% とはいかないものの大分まともに給紙されるようになりました。 ただし、そこら辺をコロコロして、粘着力を弱めてからでないと大変なことになってしまうので気をつけましょう。

何にせよ、EP-901A/801A 系プリンターのユーザーは日本郵便の (印刷用でない) 普通紙の葉書は避けて、各社からインクジェット用として売られているもの買った方が良さそうです。 一度使ってしまうと問題なかったはずの紙の給紙も怪しくなります (元に戻りますが)。 喪中葉書も早めに出さなければと思うと焦りますよね。

そう、焦って EP-804A 買っちゃったんだよなあ。 まあ、新品買ったからわかったってのもあるけど…。

perl Expect を Windows で使用する

私は TeraTerm マクロよりも Expect 派なのですが、「今さら Tcl ってのもねぇ」というところもあるわけで、最近はもっぱら perl の Expect モジュールを使っています。 布教活動を行うには希望があればすぐに他の人の使っている Windows にインストールできるようにしておかなければならないので、今日は perl Expect を動かすための作業をメモ書きしておきます。 と言っても何が必要か知っていれば結構簡単に動いちゃうんですけど。

ActivePerl には該当するパッケージが無いので Cygwin で cpan コマンドからインストールして使います。 Strawberry Perl にはビルド環境があるようなので、IO::Tty が用意できれば同じように Expect もインストールできると思いますが未検証です。

Cygwin 関連パッケージインストール

Cygwin のデフォルトインストールで不足しているものは次のパッケージです。 これらを追加インストールします。

  • make
  • perl
  • perl-IO-Tty

Expect のインストール

あとは cpan コマンドで Expect をインストールするだけです。 cpan コマンドの初回起動時はいろいろありますが、あっちこっちで説明されているのでここでは割愛します。

$ cpan

cpan shell -- CPAN exploration and modules installation (v1.960001)
Enter 'h' for help.

cpan[1]> install Expect

これで Expect を使えるようになります。 コマンドを打って出力結果を整形する場合などは、本家 Expect より perl を使った方が楽だと思うので、興味があれば試してみてください。