エタメロ10周年

しばらく使っていなかったロックミシン、BL66(ブラザー製)をひさしぶりに使おうとしたところ、はずみ車が全く回らない状態に。

どこが壊れた！？と思って検索すると、どうもしばらく放置したロックミシンにはよくある症状のようで、駆動軸が固着してしまっているようです。

「ちょっとでも動くなら注油しましょう」とあったけど、微動だにせず。プラのノブは僅かに動く(ねじれる？)ものの、底板を外して中を見てみると、まったく動いてない。

油を差して一晩置いても改善の気配無し。

ためしに駆動軸の中央付近にあるカウンターウェイトのところを叩いてみたところ、90度ほど回ることは回ったけど、それでもまったく緩む気配無し。

仕方がないので、CRC556を駆動軸が密着してそうな箇所にひととおり吹いてから、駆動軸の赤丸で囲んだあたりをウォーターレンチでつかんで、グイと回したところ、固着が解消。それ以後は、はずみ車がいつもぐらいの重さで回るようになったので、CRC吹いた各部にミシン油をたっぷりさしてから蓋をして終了。

レンチでつかむ際には布を噛ませてたのですが、軸に若干傷が入ってしまいました。。。。


とりあえずは、今後こまめに動かすようにしないとね。

というわけで、尻Pの新刊、「南極点のピアピア動画」を読了。1本はミク表紙のSFマガジンで既読だったものの、連作というかシリーズでどんどん規模がでかくなっていくのが面白い。



で、作品としての「南極点の〜」はそれはそれで大変面白く読ませてもらったのですが、ちょうどアゴラでこちらの記事を読んだところだったので、ちょっと別のところに考えがいったのをメモ。

アップルの70万人雇用〜新卒6割就職と初任給1000万円の差の理由　（新 清士）

このコラムは、ざっくり「IT企業は上位エンジニア1000人ぐらいの雇用は生み出すけど、製造業のような数十万人クラスの雇用は生まないよね。どうしようね」という内容だと読みました。

ソフトウェア産業は限界費用が0に等しくなっていくと言われていて、ダウンロード配信がこれだけ普及してくると確かにその通りだと思うわけです。限界費用が0ということは、つまり、増産にヒトも資源もいらないということで、つまり雇用創出力はないわけです。ゲームだろうがOSだろうが、売れようが売れまいが「製造」コストはサーバに上げた時点で確定しているわけです。


そこに「南極点のピアピア動画」です。


ネタバレしたくないのでアレですが、本作の中でモノが増えるシーンがいくつかあるのですが、驚いたことにどれも工程に人間がほとんど絡んでない。デリバリーとかフィードはするけど、製造そのものに手は動かしてない。

野尻先生がどういった意図でそう描いたのかはわかりません。職人を使うと「夏のロケット」的な感じになるから避けたのか、あるいはボカロ的世界観にあわせたのか。あるいは、特に意図はないのかもしれません。

ただまあ、SFの中でも、宇宙時代も雇用は増えないんだなあ、とシミジミしてしまいました。

確定申告をe-taxでやっていますが、必要なのが住基カードを読ませるためのICカードリーダー。

住民基本台帳カードには、接触型と非接触型がありますが、ある自治体で手持ちの接触型専用リーダーが使えるかどうか調べようとして一苦労したのでメモ。

そこの自治体、発行しているカードの種類を書いてないんですよ…

それに個人でカードがどうこうというのを書いてる方も見当たらず。

さらに調べてみたところ、公的個人認証サービス都道府県協議会の公的個人認証サービスポータルサイトに、自治体ごとの対応ICカードリーダー一覧があるのを発見。

とりあえず接触型リーダーも使えるような記載だったので一安心。引っ越ししても買い換えずにすみそうです。

cronでJavaアプリを起動してバッチ処理させようとして、上手く動かない（リソースバンドルが読まれてないっぽい）という現象に遭遇しました。

リソースバンドルの呼び出し方としてはまあごく普通にこんな感じ。

ResourceBundle rb = ResourceBundle.getBundle("hogehoge");
String URL = rb.getString("URL");

hogehoge_ja.propertiesというリソースをWEB-INF/classesに置き、クラスパスとか設定していたのですが、どうやっても読んでくれない。起動用スクリプトでcdしてカレントディレクトリを設定したりしていたので、そこにhogehoge_ja.propertiesへのシンボリックリンクを置いたりしたのですが、全然ダメ。

結局直せたのですが、バッチの起動用スクリプトの中で、LANGを設定していないのが原因でした。

export LANG=ja_JP.UTF-8

の1行をスクリプトに挿入することで、hogehoge_ja.propertiesを読んでくれました。

英語版のリソースファイルを探しに行ってたんですね…

IPアドレスとかWi-Fiアクセスポイントか、そういった各種情報から位置情報を推定する仕組みがすでにいくつかあるわけですが、こういうデータを「買わずに何とか作れないか」という話になったときに、どうやったら推定していけるんだろう、と考えてみました。

まあ、もとになるデータが無いときは直球しかないので、「サイト利用者に現在位置を入力してもらう」ということになると思います。

この場合、場所を入力してもらう必然性が必要です。

たとえば、回線速度とかの測定サイトだと、地域ランキングを機能に持つことで、郵便番号とか市町村とかを入れてもらいやすくする。

天気情報を表示しますよというデスクトップツールとか作って、地名を設定してもらってもいい。（このとき、すぐに送信しなくても、そのIPアドレスから地域IDを含むクエリが飛ぶわけで、あとからいくらでも集計できる。設定時にはむしろ何も報告しない方がいい）

通販、IPアドレスと送り先。

購入した商品のユーザー登録、IPと設置場所情報。

ぐるなび系というか地域情報系、おおざっぱな位置の把握が限界かなあ。会社で探すとして、会社のまわりばっかりとは限らない。（ターミナル周辺とかで探すことの方が多いよね？）。

あとはクーポン「リアル店舗系」は地域がモロに反映されそうだけど、こちらもサンプルが少ないうちはおおざっぱな地域把握が限界か。

店舗検索系は、地域の指定操作は自然だけど、どのくらい「地元」を探すのかが分からない。他地域のような気がするが、業種業態によるか。マッサージとか病院は地元？コンビニはどっか外出先？銀行は？



。。。あー、めんどくさいから「ホントに必要なら買えば？」ということになりそうな気がしてきた。そういう話が出たら、そういうことにしよう。

ちなみに、動的割当のIPに対して、逆引きを地名を含む名前にしているISPとかもあるので、そういうのも使えると思うけど、どれぐらいメンテナンスされてるかが分からないと頼るのは怖いな。

国道昇格、というワードで検索すると、いろんなサイトが見つかるのですが、

国道477号

のあたりは、なかなかすごいです。

なんでそんなワードで検索しようかと思ったかというと、

山行が　国道101号線　五里合狭区

を読んだからですが。コレに限らず、ヨッキれんさんのレポートは、すごい。おかしい。