投稿

EP-805A 廃インク吸収パッド交換

イメージ
知人からエプソン製の複合機カラリオ EP-805A が廃インク吸収パッドの交換を促す警告表示(「廃インク吸収パッドの吸収量が限界に近づいています。お早めにエプソンの修理窓口に交換をご依頼下さい。」)が出るようになったと相談を受けた。 事務などでガンガンに使い倒しているわけでなく、基本的に個人用途でのチマチマとした使い方しかしておらず、 純正インク のみで大切に使ってきたものなので、まだ結構新品同様に元気に動いている印象だったが、もうそんな時期なのかと。 実際のところ調べてみると以下のようだった: 発売日 2012-09 購入日 2013-06-17 修理対応期限 2018-07-31 サポート切れまで間近に迫っている。発売から 5 年 11 ヶ月でサポート終了ということのようだ。 ところが、エプソンの 公式ページ を調べてみると、まだサポートを受けられるといっても、その金額に唖然とした。税別で、基本料金 11000 円、廃インク吸収パッド交換費用 4000 円、送料 1500 円と、総額 16500 円也! 新品が 15810 円で購入できたものを、今や 5 年型落ち状態になってなおかつ 16500 円で修理って、そんなアホな……。どう考えても、修理させるつもりないでしょう、エプソンさん。まあ、プリンター産業に関しては、国内企業なので、儲ける側の国益と、消費する側の国益を秤にかけると、単純に一方的に消費者の側の立場だけでエプソンを責める気にはならないのだけど(一方、プリンターが自国産業というわけではない フランスで、エプソンやキヤノン、ブラザー、HPを訴訟する のに何のためらいもないのは当然の話)、これはいくらなんでも酷い。せめて半額程度だろうと思う。 それで、ちょっと調べたら、自分でプリンターを分解して吸収パッドを交換し、ソフトウェア的にカウンターもリセットしている人がいるということを知った。まあ、捨てて別の新品に買い替えることを考えるならば、ダメ元で試しても損はないということで、やってみることにした。 参考 分解方法 :EP-805A の型番のプリントされた前面パネルの取り外し・取り付けにコツがいる。下側を回転軸にして、上部のツメを外しながら外す(取り付ける時はその逆に下側を回転軸にして、上部に被せていくようにして

パケ死

イメージ
先月(昨年)末、友人から中古で iPhone 6s を買い取り、ついに iOS デバイスのオーナーとなった。SIM を挿し替えて、Apple の移行ツールを利用して、ほとんどの設定が Android から自動で移行できた。だがその移行過程で、「モバイルデータ通信」を OFF にする間もなく、アプリのアップデートなどが始まり、数十秒後に気付いて処理を中断したものの、時すでに遅し……。数十秒で 89 MB のデータ通信が発生してしまった。 ドコモ口座を使いたいがためにドコモと契約してかれこれ 1 年と 2 ヶ月になっていたが、契約プランはカケホーダイで、パケット定額は契約せず、スマートフォン側でモバイルデータ通信を常時 OFF にすることによってこれまで何の問題もなく利用してきた。しかし、ほんの数十秒のミスで発生したわずか 89 MB のデータ通信に対するドコモの請求が、これ: 53,972 円 なんでパケット料金が何十年も前の携帯電話が主流の時代の単価のままなんだよっていう。 よく、総務省の有識者会議とかで携帯キャリアの規制について話題になってるけど、パケット単価の問題を放置して、他の何を会議で話し合っても、「何が有識者なの?」「何が国民の利益なの?」ちゃんちゃらおかしいと思う。 夜更ししていて寝る前の最後の一仕事のつもりでやったのがこういうことになって、ショックを受けたが、どうしようもないので、諦めて寝た。翌日、思い直して調べてみると、こういう事態が「パケ死」と呼ばれていることを知った。どちらかというと「パケ死」は、海外ローミングで発生する事態のようで、僕のように、意図的にパケット定額をしないで国内で普通に生活していて起こる事態は主流ではないようだ。 さらに、「パケ死」というキーワードをベースにして調べてみると、他にもこういう目に遭った人は少なくないようで、救済措置が存在することもわかった。ドコモの場合、一回だけ、遡って後付けでパケット定額に加入できるという。早速ドコモのインフォメーション(151)に電話してお願いし、最低額のパケット定額を適用してもらって、どうにか事なきを得た。 一度こういう事故に遭ってしまうと、たとえ以前より慎重に気を付けていたとしても、事故が起ってしまったらパケット料金が青天井であるということは恐しくて仕方がない。

HTTP/1.1 Transfer-Encoding: chunked

Web Scraping 用のプログラムを組んでいて、HTTP レベルの Socket プログラムを自前で組むか、Client レベルの処理は言語環境のライブラリーに任せて HTML を解析・処理する程度のものを組むかという、二択問題によく悩む。これまでの経験上、後者の方が敷居が低く取りかかるのに容易であるというメリットがある。一方、一旦何らかの壁にぶち当たると、ブラックボックスのない前者の環境で試行錯誤を進めた方が、心理的にもまさしく“急がば回れ”の典型のような結果となり、トータルで楽になる。 そんなわけで、今回取り組んでいる物件についても、スタートアップは Java の URLConnection で一通り組み上げてしまって、それで問題なく全体的に動くものが出来上がっていたので、そのまま運用していたものだった。ゼロ状態からのスタートとなるプロジェクトでは、まずはどんな形であれ、全体としてちゃんと動くものへと到達できるかどうかが不明な状態なので、「まずは全体としてちゃんと動くもの」まで辿り着くことが何よりも重要である。そのためには、Client レベルのものは Java のコアライブラリーに任せて、Web Scraping にターゲットを絞った方が確実にプロジェクトを成功まで推進することができる。 それでそのまま動くようになったままで運用し続けていて、プログラムには手を入れていなかったのだが、今度、Lanterna を使って GUI 化したりして、使い勝手が向上したので、さらに前から欲しいと考えていた機能を追加したりした。最終的には GUI 化したらしたで CUI の時は気にならなかった処理速度が気になったので、ネットワークからのデータの読み込みをマルチスレッド化するところまで行き着いた。 このネットワーク読み込み処理のマルチスレッド化で、ある問題が表面化したのだった。 どうやら Java の URLConnection は、スレッドセーフではないようなのだ。とはいっても、このプロジェクトに関して言えば、Cookie がスレッド間で共有されていることが問題の核心であり、それを URLConnection 自体がスレッドセーフではないという話に含めていいのかどうかはわからない。ともかく、Cookie が上書きされてしまうのが原因で、サーバー側が付与する JS