About Gm7add9

Software developer + digital synthesizer enthusiast

trystrams ID CARD HOLDER HUBSTYLE

職場で使っている、IDカードを入れる首掛けホルダーの巻き取りワイヤーがちぎれそうになってきたため、急遽新宿の東急ハンズに赴き新しいIDカードホルダーを物色してきた。

最近はIDカードと一緒に首掛けホルダーを提供してくれる会社が多いので必ずしも必要なものではなく、あえて買いに行くのは女性が多いと見える。デザイン的に、かわいらしいものが多い。どれをみても、地味なオッサンがスーツ姿で首からぶら下げるにはなかなか辛いセレクションである。

自分がIDカードホルダーを探すのは今回が初めてではなく、買うときはだいたい以下のような所を気にしている。

  1. 伸縮ワイヤーがついている
  2. 2枚以上のカードが収納可能
  3. カードを落としづらい
  4. 万が一カードケースごと落としても気づきやすい

1番はセキュリティカードとしては当然で、オフィスに入るのにいちいちカードケースからカードを取り出してセンサーにかざすのはナンセンス。

2番目は割と見落としがちながら重要な点。自社のカードと客先用のカードとか、異なるセクションに入るためのカードが別途あるとか、複数枚のICカードを持ちあることは珍しくない。そうなってくると、カードごとに異なるカードホルダーを用意していては鞄の中がカードホルダーだらけになってしまう。できれば1つで済ませたい。

ただICカードは干渉という問題があるので、まとめるとしてもせいぜい2、3枚。それくらいのキャパシティのあるケースを探すようにしている。プラスチック系など伸縮しない素材の場合、どうがんばっても収納枚数は変らないので特に注意したいところ。

3番目は知らないうちにカードをなくしてしまわないような仕組みか、ということ。安い塩ビのケースとかはちぎれたり、横から落ちてしまったりとかする。しっかりカードをロックできるものが望ましい。

また、4番目として、カードホルダーごと落としたりした時に、プラスチック素材とかだと音がするので気づきやすいとか、鮮やかな色がついていると目立ちやすい、とか、そういったメリットもある。

まぁすべての条件を満たす理想のアイテムはなかなかないので、適当なところで妥協はするのだけど。


今回選んだのは、コクヨのtrystrams ID CARD HOLDER HUBSTYLE。3,000円と値段が高いのがイマイチだが、機能的にはおおむね満足のいくものだったので気にせず購入。プレスリリースが2013年だから結構前からあるモデルらしい。

trystrams01カードはプラスチックの分厚いモノでも2、3枚は入りそう。仕切りがあって前面と後面にカードを挿せる。自分の場合ICカードを2枚いれているので、2枚のICカードの間に干渉を防ぐためのカードをいれて、計3枚。合皮なので、多少の無理は利く。

trystrams03

カードが落ちてしまわないように、カードを出し入れするサイドにはフラップがついている。

trystrams02フラップを中に折り込んでしまえばカードが落ちることはまずないだろう。ちなみにデフォルトでは横向きのカードを入れるようになっているけど、ストラップの留め金を付け替えることで縦型にも変更できるのがこのケースのポイント。

trystrams04弊社は数少ない縦型のIDカードを配っている変な会社であるが、一方客先では横型のことが多いので、どちらにもワンタッチで切り替えられるというのは地味に助かる機能である。まぁ写真が90°回るだけなので、別にどうでもいいんだけど、正しい向きにできるならその方がいいわけで。

trystrams05最近は切り替え可能なモデルも多いけど、クリップ部分を外してつけ直す、というスタイルが多く、それって間違って落としたりする確率があがっていると感じるので、カードホルダーのデザインとしてどうなんですか、と個人的には思ったりする。

ストラップは本体と同じ色の合皮で、ワイヤー部分は巻き取り方式の伸縮ワイヤー。一般的なもので、特筆すべき点はない。先の縦横切替のおかげでこの部分を細工しなくても縦横切替ができるのは利点といえる。IDカードホルダーで一番早く壊れるのがこの部分だから、弄らないで済むに越したこと はない。

trystrams06ネックストラップは強く引っ張ると外れるようになっている。機械とかに引き込まれても安心ということなのかもしれないけど、そういう所はこういうものをブラブラ下げたりしないよね、普通。どういうときに使うのかイマイチよくわからない。

外してしまったら、横からスライドして差し込んであげれば元通り。


以前は、同じくコクヨで、確かデザイナーさんも一緒のIDeoのSmooth Style、これを使っていた。プラスチックのもので、そこそこ重みもあるし落とせば音がするので、気づきやすいのと、しっかり蓋をするのでカードを紛失しづらいというのがメリットだと思う。カラーバリエーションも、好みのは少なかったけど5、6色あった。

trystrams08このモデルはカード2枚OKで、間に干渉防止カードいれてもなんとかはいっていたのだけど、同じ系統と思われるtrystramsのSMOOTHSTYLEではカード枚数が1枚に減ってしまっていたので、今回自分の選択肢からは外れた。

このIDeoのカードホルダーは、2、3年つかってきてついにワイヤーがこんな感じになった。付け根の部分にデコピンでみしようものならたちまちちぎれそうである。

trystrams09本当は同じモデルの色違いでも買おうかと思って出かけたのだけど、あいにくIDeoは東急ハンズ新宿店には置いていなかった。今後はtrystramsの方に移行していくのだろうか。IDeoの2枚入り、結構需要あると思うんだけどなぁ。

そうだ Git、移行 (Reposurgeon編)

今年の春に、それまでプロジェクトで長年つかってきたSubversionをGitに移行した。比較的少人数での開発だしリモートで作業している人もいないし、分散SCMであるメリットは実はそれほどないのだけれど。やっぱり技術者として世の中の流れについて行きたいというのもあるし、リリース管理者としてリリースの度に実施するSubversionでのマージ処理が辛くて辛くて(追加/削除がディレクトリ操作になるので、ディレクトリ配下の一部だけをマージしたい時に余計なものまで一緒にマージされてしまって自動化の妨げになる)何とかしたかったのもある。

まぁ、正直なところSubversionもとても良くできた、そして何より実績が多いソフトウェアでなので、別にGitがなくても死にはしない。今Subversionでうまく回っているなら、急いで乗り換える必要は多分、ない。

だけど、これだけGithubがメジャーになって「OSSの管理といえばGit」っていう流れができあがってしまうと、個人的にはSubversionってもう、「移行するかべきか否か」ではなくて「いつ移行するか」を検討するくらいの時期には来ているとも思うわけで。十数年前にCVSとかVSSとかが主流だったSIerも、最近では大半が少なくともSubversionくらいには移行しているわけで、この先10年とかを考えると、SIerだからGitなんかいらないとかいうことはないのではないかと信じている。実際、最近書店にはデザイナーさん向けのGitの書籍が並んでいるくらい、Gitの認知度が上がっている。

そして何より、プロジェクトに新しく若者が入ってきたときに、Subversionという古の構成管理ツールの使い方を教えてあげるとかいうのは、お互い得るものが少なすぎて悲惨である。どうせ同じ時間を使うなら、その場限りのスキルなんかよりはいろいろなところで役に立つスキルを身につけることに時間を使いたい。まぁ、みんながみんなそういう気持ちではないかもしれないのだけど。

移行ツール

まぁ本音は「実は俺がGit使いたいだけ」でそこまで深い意味はなかったかもしれないけど、とにかくGitへの移行方法の話。かつてCVSからSubversionへの移行がスクリプトでサポートされていたように、Gitにも移行ツールがついている。それがGit-SVNというサブコマンドである。

Git-SVN

Git-SVNは事実上Subversionから移行する人のほとんどが一度は通る道だと思う。Git-SVNは移行ツールの一種ではあるのだけど、実際の所は「GitでSubversionのRepositoryにアクセスすることができる」というもので、GitへSubversionから取り込むという流れはもちろんのこと、逆にGit側からSubversionへ変更を送ることもできる。

Git-SVNについては↓こちらで@DQNEOさんが大変きれいにまとめられているので、詳しくはそちらを参照されたい。これは移行の時にじっくり読ませて頂いて、本当に参考になった。Git-SVNを使うかどうかを別としても、事前にSubversionのリポジトリをきれいにしておくとかサイズを小さくするとか、既存のコード資産を移行する人にとっては有益な情報が山ほど詰まっている。

仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ

自分のプロジェクトでも最初はこれでいく想定で進めていた。でも、どうもGit-SVNの変換処理が結構遅いとか、できあがったGit Repositoryでテストしていたら、追加でコマンドをたたかないとSubversionにあったはずのブランチがみえないとか、あと(作業手順が漏れていただけなんだけど)そもそも移行されていないブランチがあったり、移行元が初期はtrunk/branches/tags構造じゃなかったのでそこが移行されずに落ちているとか、いろいろ課題とか問題が見えてきた。

それでほかにもう少しいい移行方法はないものか、と少しまじめに調べてみることにしたのだけど、その時に見つけたのが、ESRことEric S. Raymond大先生のRepository移行ツール、Reposurgeon

Git-SVNは言ってみれば双方向でGitとSubversionをつなぐツール。Subversionから一気にGit移行するのにも使えるけど、一部のメンバーだけ、あるいは一部のプロジェクトだけ、など段階的に移行することもできる。その気になれば移行以外の目的でも使える、案外汎用性の高いツール。

構成管理ツールを変更するときというのは、チームの規模が大きければ大きいほど混乱が伴うもの。だから一部のメンバーだけを段階的にGitに移行でき、しかも移行中もSubversion-Git双方向でお互いの変更が双方向に共有できるというメリットは非常に大きい。

Reposurgeon

対してReposurgeonはRepository編集を行うためのツールである。正規のツールが提供する通常のオペレーションでは絶対に実現できないような変更を履歴に対して加えることもできる。まさにRepositoryに対する外科手術。これもGit-SVNとは別の意味で、移行以外の目的で使えるツールだ。

Reposurgeonでの移行はRepositoryを一気に移行してしまう。そのため、Git-SVNのように同時並行稼働で双方向にいったりきたりすることはできず、Subversionから段階的にGitに移行する、という計画では基本的に使うことができない。ここがツール選択のポイントになるケースも多いはず。

その代わりに、より移行に適した形で、より高速に移行を済ませてくれる(と思う)。全員が一度に移行するなら個人的にはこちらのが良いのではないかと思う。ツール自体が難しく情報量もGit-SVNと比較するとかなり限られるので、自分で調べて問題を解決できる人向きではあるけど。

何れにせよ、絶対的にどちらのツールが優れているとかそういう類のものではない。リポジトリの分割方針とか利用者の数やスキルを考慮して適切なツールを選びたいところ。

Reposurgeonのメリット

  • 移行機能は基本的に一括移行
  • 追加手順なく、最初から意図した形の移行結果になりやすい
  • 通常のツールではできない、履歴に対する各種変換処理が可能

Reposurgeonのデメリット

  • Unix系プラットフォームのみサポート
  • Subversionとの相互運用不可
  • 情報が少ない、コマンドや作業フローがわかりづらい

ReposurgeonはUnix系のツールなので、Windowsでは動かない。ここは注意が必要。でも、WindowsでホストしているSubversionのリポジトリをMac OS XにもってきてGitに移行し、完成したGitリポジトリをWindowsに戻してWindowsのGitで運用する、といったことは問題なく行えるので、実際にはそれほど大きな制約ともいえない。実際、自分はOSXで移行したリポジトリをWindowsのGitで動かしてもうそろそろ1年だけど、何も問題になっていない。

Reposurgeonの導入

自分はOSXでしか試していないんだけど、きっと大抵のパッケージマネージャでサポートされていると思う。Homebrewがはいっていれば

brew install reposurgeon

これだけ。

conversion.mkによる変換

Reposurgeonのコマンドは最初は取っつきづらいと思う。そのため(かどうかは知らないけど)、SubversionからGitに移すだけ、を簡単に実現してくれるmakeファイルが配られている。

http://www.catb.org/~esr/reposurgeon/conversion.mk

makeファイルをダウンロードしたらエディタで開いて以下の2行を変更する。PROJECTは最終的に作られるGit Repositoryの名前になるけど、まぁ多分このMakefileで作成したリポジトリをそのまま使うことはないんじゃないかと思うので、あまり気にしなくていいと思う。SVN_URLはデータを取ってくる場所になるのでちゃんと書かないとダメ。

PROJECT = code-repo
SVN_URL = http://192.168.1.100/svn/code-repo

これでmake -f conversion.mkすれば、勝手に変換が行われてcode-repo-gitというディレクトリにgitのRepositoryが完成。

ちなみにGitに移行したときにリビジョンが数字からSHA1ハッシュに変わるのだけど、Subversionのリビジョン番号に依存する他のツールと連携しているような場合、Subversion側でのリビジョン番号を記録として残すことができる。この場合makefileを少し編集する必要がある。

44: # Build the second-stage fast-import stream from the first-stage stream dump
45: $(PROJECT).fi: $(PROJECT).$(SOURCE_VCS) $(PROJECT).lift $(PROJECT).map $(EXTRAS)
46:    $(REPOSURGEON) $(VERBOSITY) "read <$(PROJECT).$(SOURCE_VCS)" "authors read <$(PROJECT).map" "prefer git" "script $(PROJECT).lift" "fossils write >$(PROJECT).fo" "write >$(PROJECT).fi"

これを、

44: # Build the second-stage fast-import stream from the first-stage stream dump
45: $(PROJECT).fi: $(PROJECT).$(SOURCE_VCS) $(PROJECT).lift $(PROJECT).map $(EXTRAS)
46:     $(REPOSURGEON) $(VERBOSITY) "read <$(PROJECT).$(SOURCE_VCS)" "authors read <$(PROJECT).map" "prefer git" "script $(PROJECT).lift" "fossils write >$(PROJECT).fo" "write --fossilize >$(PROJECT).fi"

こんな感じにする。最後のwriteコマンドに–fossilizeオプションをつけるのがポイントだ。RedmineのようなIssue管理システムとRevision番号で連携を取っているような場合は、Gitのリビジョン情報で過去の関連づけを上書きできると理想的だけど、その材料となる大事な情報となる。

インタラクティブなコマンド実行による変換

conversion.mkによる変換はなにもわからない状態でも2、3行編集するだけでさくっとSubversionからGitに変換できてしまう手軽さがポイントで、できあがったGitリポジトリを見ていると結構ちゃんとしていて感激する。

だけど、変換処理について細かいカスタマイズをしようと思うと、結局最後はmake fileの中で呼び出されているコマンドを調べることになる。Makefileを読むのって結構面倒くさいのだけど、このツールについて言えば、説明を読むよりもまずはこれを見てみるのが効果的だと思う。いきなりオフィシャルの説明を読んだところで、普通の人は動かせないと思うので。

一連の流れは次のセクションを見てもらうとして、Reposurgeonを使うには基本形を知っておく必要がある。

  1. read <[ファイル]
    Subversionのダンプや、Reposurgeonや各種Version Control System (VCS)からwriteで書き出したfast-import形式のファイルを読み込む。ここで読み込んだファイルに対して、各種コマンドを実行してリポジトリの内容を編集していく。基本的にはReposurgeonを起動して一番最初に呼ぶコマンドになるはず。
  2. write >[ファイル]
    編集した内容を、exportする。自分は編集作業後のバックアップとしてしか使っていないけど、編集したリポジトリを他のfast-importできるツールにインポートする場合はその元ネタになる。
  3. rebuild [リポジトリ]
    編集後のリポジトリを実際にVCSで使えるリポジトリとして再構築する。

基本形はこの、read→編集→rebuildもしくはwriteという流れで、readからrebuildの間には好きなだけ編集コマンドを挟めばいい。例えば正規表現にマッチするファイルを含むリビジョンを探して、該当ファイルだけ削除してしまうとか、不要なタグを消し去る(削除コミットができるのではなく、履歴のどこにも登場しなくなる)とか。

コマンド実行する場合には、Reposurgeonを起動してreposurgeon>プロンプトにする。SubversionからGitに移行するには、以下のような流れでコマンドをたたいていけばよい。

  1. readコマンドを使って、Subversionのdumpファイル(code-repo.dmp)からリポジトリ情報を読み込む。dumpというのはもちろんsvnadmin dumpで作成したもの。ちなみにdumpと一言でいってもSubversionのダンプにはバージョンがあり、バージョンが高すぎるとreposurgeonが読み込めないときがある。–deltaとか特殊なオプションをつけるとバージョン指定が厳しくなったりするので、Reposurgeonに食わせる場合はオプションをつけずに出力するのが良いと思う。
     reposurgeon> read <code-repo.dmp

    ちなみにreposurgeonのリダイレクトはシェルのリダイレクトとは異なり、記号とファイル名との間にスペースをいれると動かない。必ず<とか>とファイル名を空白で区切らずに続けて書く。

  2. author map ファイルを読み込む (subversionのuser idをgit user name + emailにマッピングするファイル、git-svnで使うのと同じものがそのまま使える)
    reposurgeon> authors read <users.map
  3. 移行先VCSをgitに指定。
    reposurgeon> prefer git
  4. Subversionリビジョンと日付/コミットした人の一覧を出力(optional)
    reposurgeon> fossils write >dev.fo
  5. Repository名のリネーム(これもoptionalかな?実はどこに効いているのかよくわかっていない)
    reposurgeon> rename code-repo2
  6. Subversionからgitに間違ってtagとして認識されてしまうゴミタグの削除
    reposurgeon> =T & /(emptycommit-.*|tipdelete-.*|.*-root$)/n delete
  7. ここまで編集した内容でgit-fast-import用のファイル(dev.fi)を書き出す
    reposurgeon> write --fossilize >code-repo.fi
  8. とりあえずここまでで準備完了。あとのRepository作成はこんな感じ。
    $ reposurgeon
    reposurgeon> read <code-repo.fi
    reposurgeon> rebuild code-repo2
  9. ここまでの手順で作業コピー付きのGitリポジトリが作成される最後にbareリポジトリ作ってpush
    $ cd code-repo2
    $ git remote add origin ../code-repo2.git
    $ git push --all origin
    $ git push --tags origin
    $ git init --bare code-repo2.git
  10.  git gcでとどめの圧縮をしておく。
    $ git gc --aggressive
    Counting objects: 104054, done.
    Delta compression using up to 4 threads.
    Compressing objects: 100% (91278/91278), done.
    Writing objects: 100% (104054/104054), done.
    Total 104054 (delta 60931), reused 32576 (delta 0)

自分が作業しているとき、あまりReposurgeonの記事見かけなかったので、今後移行する人の参考になればということで記録を残しておく。自分もそれほど深く理解できていないので説明なんか書くのもどうかと思うけど、何もないよりいいだろう、と。

 

Javaで12500を1.2500にフォーマットする

Javaで12500って整数を1.2500って文字列にフォーマットする必要があったんだけど、そのために浮動小数点の除算+Formatterとかバカっぽいなー、とか思っていくつか試してみた。

  1. String.format(“%.4f”, float)
    float除算→Formatter
  2. String.format”%d.%d”, int, int)
    整数部と剰余に分割→Formatter
  3. DecimalFormat.format(“#.0000”, float)
    float除算→DecimalFormat
  4. String.replaceFirst(“(\\d{4,4})$”, “.$1”)
    String.valueOf(int)→正規表現で後ろ4文字の前にピリオド追加
  5. 4.のプリコンパイル版(Pattern.compile…)

正確に言うと値としても1.2500とか1.5000とかを扱うのだけど、浮動小数点の値を扱っているわけではないので本来使うべきはBigDecimal。しかしながら、演算子オーバーロードがないJavaでnon-primitiveな数値クラスとか使いたくないから、内部の処理は12500とか15000とか整数値でもっておいて、表示だけ小数点付きにすることにした。

いくらでもやり方ありそうだし、きっともっとかっこよくて速い書き方があるだろうけど、別にものすごい速度を求めているわけではないから5.のRegexpでいこうかと。

import java.text.*;
import java.util.regex.*;

public class Hoge {
 
  private static Pattern p = Pattern.compile("(\\d{4,4})$");
  private static int loops = 0xFFFFF;

  public static void main(String... args) throws Exception {
    long start = System.currentTimeMillis();
    System.out.printf("StringFormat Float : %s %d%n", formatter1(), System.currentTimeMillis() - start);

    start = System.currentTimeMillis();
    System.out.printf("StringFormat Integer : %s %d%n", formatter2(), System.currentTimeMillis() - start);

    start = System.currentTimeMillis();
    System.out.printf("DecimalFormat : %s %d%n", decimalformat1(), System.currentTimeMillis() - start);

    start = System.currentTimeMillis();
    System.out.printf("Regexp : %s %d%n", regexp1(), System.currentTimeMillis() - start);

    start = System.currentTimeMillis();
    System.out.printf("Precompiled Regexp : %s %d%n", regexp2(), System.currentTimeMillis() - start);
  }

  private static String formatter1() {
    String x = null;
    for (int i = 0; i < loops ; ++i) {
      x = String.format("%.4f", 12500f / 10000f);
    }
    return x;
  }

  private static String formatter2() {
    String x = null;
    for (int i = 0; i < loops ; ++i) {
      x = String.format("%d.%d", 12500 / 10000, 12500 % 10000);
    }
    return x;
  }

  private static String decimalformat1() {
    String x = null;
    DecimalFormat f = new DecimalFormat("#.0000");
    for (int i = 0; i < loops ; ++i) {
      x = f.format(12500f/10000f);
    }
    return x;
  }

  private static String regexp1() {
    String x = null;
    for (int i = 0; i < loops ; ++i) {
      x = String.valueOf(12500).replaceFirst("(\\d{4,4})$", ".$1");
    }
    return x;
  }

  private static String regexp2() {
    String x = null;
    for (int i = 0; i < loops ; ++i) {
      x = p.matcher(String.valueOf(12500)).replaceFirst(".$1");
    }
    return x;
  }
}

おおざっぱに傾向がつかめればいいかなーくらいの感じで書いているのでプログラムはかなり適当。正規表現のプリコンパイル部分なんかは測定対象から落ちちゃってるし。

[~] java -classpath . Hoge
StringFormat Float   : 1.2500 1617
StringFormat Integer : 1.2500 1155
DecimalFormat        : 1.2500 591
Regexp               : 1.2500 651
Precompiled Regexp   : 1.2500 306

にしても、String.formatは相変わらずヒドい。

dunhill Bourdon Oxblood Slim Briefcase

2014年も早いもので半分が終わった。そんなわけで、今日は半年間がんばった自分にご褒美、dunhillのBourdon Slim Briefcase。

slimbriefcase01

普通は「1年間がんばったご褒美」かもしれないが、世界のトヨタを応用したジャスト・イン・タイム購入方式、すなわち「欲しいものを欲しいときに欲しいだけ買う」を実践しているので、1年間もがんばり続ける必要はない(意味不明)。

Slim Briefcase

さて、Slim Briefcaseという名称だが、これは割と最近でてきたもので、元々は色鮮やかなラインアップが展開されていた2013年秋モデル、Bourdon Bright Collectionの1つだった。dunhillのラインだとSingle Zipとよばれる通常のスタンダードなブリーフケースが40cm x 30cm x 10cm程度のサイズであるのに対して、36cm x 28cm x 5cmと一回り小型・薄型であるのが特徴で、数多くあるdunhillのラインアップでも、メッセンジャーバッグとブリーフケースの中間に位置するこの形は初めてではないかと思う。

外寸で36cmというと、A4ファイルがギリギリはいるサイズ。書類鞄である以上これが入らないということはさすがにないが、まち幅もせいぜい5cmなので、PC、ノートや印刷物、傘くらいいれるとすぐにいっぱいになる。容積をメリットと取る人にとっては向かない。

最低限のモノをコンパクトに美しく持ち運ぶ。個人的にはこれはビジネスが紙からPC中心になってきた電子化の流れだと思っている。昔のように大量の資料を日常的に持ち運ぶという人が減り、逆にPC1台と少々の書類が持ち運べれば十分仕事になる、という人が増えてきた。その結果、このような小型の書類鞄が一定数売れるくらいの市場が出来上がってきているのではないかと。

2014秋モデル

Bourdonシリーズの2014秋モデルではそのSlim Briefcaseに、Navy、Oxbloodというダークカラー2色が追加されたようだ。ちょうど今入荷しはじめたくらいのようで、2014/07現在、まだdunhillのWebsiteにも出ていない。

自分はもともとオレンジ色が美しいCognacを買うつもりで店頭に出向いたのだけど、店員さんから2014秋カラーを紹介され…店頭で写真を撮らせていただいて、近所で昼食をとりながら写真を眺めて迷うこと1時間。結局青みがかったダークカラーのNavyは服装と合わせるのが難しそうな気がしたので、ワインレッド系のOxbloodを選択した。実際にはどちらもかなり暗い色合いでありそんなに気にするほどのものでもないかもしれない。

ちなみに2013年の方のCognacは大変人気があったようで、もう完売していて追加で入ってくる予定はないとのこと。町中でもっている人とかは一度も見たことがないけど、やっぱりあの色が一番人気だったんだなー。

詳細など

右下にはAlfred DunhillをあらわすADロゴプレート。ブランドを主張し過ぎないなかなかいいデザインではないかと。日本ではLouis Vuittonの柄が歩いてます、みたいなのをよく見かけるけど、高い金払ってブランドの宣伝して歩くみたいなみっともないことはしたくないものである。広告っていうのは金をもらってやるもんだ。slimbriefcase02裏はポケットとトロリーバッグの持ち手を通す口がある。てっきり裏面はトロリーバッグ専用かと思っていたのだけど、それとは別にポケットがついているのは買うまで気づかなかった。ポケットはトロリー側とはつながっていないので、小物を入れても落ちたりすることはない。それからポケットには真ん中の上の方に磁石がついていて、ピタッと止められるようにもなっている。まぁ薄いポケットなので、せいぜい新聞紙や週刊誌を挟む程度の使い方しかできないだろう。

ちなみにトロリーバッグと一緒に持ち運ぶなんて自分は海外出張のときくらいかなーと思うんだけど、そういうときはこんな高価な鞄持って行かないので、多分永遠に使うことはない。
slimbriefcase03

斜めから見るとこんな感じ。シンプルでいい形だと思うけど、個人的には縦方向がもう少し短いと完璧だったかな。縦方向は通常のブリーフケース並みなので、割と正方形に近い形の印象。

slimbriefcase04

金属パーツはよく見れば至る所にADのロゴ入り。細かい。

slimbriefcase05

横から。5cmということでノートパソコン、傘、厚さ2cmくらいまでの本なら持ち歩けそうな感じ。ファスナーは2方向に開くタイプ。ほかのブリーフケースと違ってショルダーストラップ用の金具はついていないけど、このサイズで肩から提げると見た目のバランスが悪いとは思うので、デザイン上あえてつけていないのではないかと思っている。

slimbriefcase06

写真はちょっとぶれちゃっているけど、実際にMacBook Pro 13″ with Retina Displayを入れてみた。革製のインナーケースに入れていることもあり、横方向にはほとんどスペースはない。なかのポケットは裏側に大きめのファスナー付ポケットが1つと、写真にもあるとおり3つの小物用ポケットが3つ。スマホ2つと名刺入れくらいは入る感じだけど、厚みのあるものは入らないと思った方がいい。

slimbriefcase07

ちなみに鞄の内側は柔らかい素材ではあるものの、中のものを守るような分厚いクッションになっていたりするわけではないので、PC用にはインナーケースを用意するのが基本形だと思う。

ところで今まで

今まではTrionのA113を使っていた。当時はMacBook Air 11″をメインで使っていたためこれをコンパクトに持ち運ぶ鞄が欲しくて、こちらなんかを参考にまち幅を極限まで削ったこの鞄を選んだ。あのときは薄いことがすべてだったので、それなりに満足していた。しかもTrionの鞄は1万円程度で購入できる割には安っぽく見えないし、作りもとてもしっかりしていて、用途さえあっていればとても満足度の高い良い鞄だと思う。

しかしまぁ実際に使い始めてみると、自分の場合は仕事上やっぱりMacBook Airだけしか入れないというわけでもないので、まち幅に余裕がないのは案外使い勝手が良くないことに気づいた。当然余計なものは持ち歩かないような努力はするのだけど、どうにもならない日もある。

しかも途中でMacBook Pro 13″ with Retina Displayに乗り換えてしまったので、普段から鞄が膨らんで見えるようになってしまって、せっかくのスリムデザインがだいなしになっていた。そこら辺の教訓というか、課題を解決するため今回は5cmというそこそこのまち幅を確保することにした次第。

そんなわけで

Alfred DunhillのSlim Briefcase、オッサンも安心のダークカラーNavyとOxbloodの2色から選べてお値段はなんと104,000円(税別)。…dunhillともなるとやはりいい値段する。年がら年中買えるものではない。とはいえ、シンプルでシックなデザインは大事に使えば飽きもこなくて長く使えるものだと思うし、ビジネスマン向け鞄特集の定番ブランドTUMI、吉田カバン、Orobiancoなんかとは一線を画したい向きには良いのではないかと。

MacBook TrackPad USB化計画

MacBookについている入力デバイス、Track Pad。昔はホイールマウスが一番だと信じて疑わず、正直各社が搭載するこのデバイスを見る度に「こんなの使えるか」って思っていた(実際、この頃のトラックパッドはコスト重視の出来の悪いのが多かったのは事実だと思う)。

MacBookについているのはこれしかないから仕方なく使っていたのが、面積の拡大やトラッキング性能の向上で徐々に使いやすくなり、マルチタッチが実現したあたりでなくてはならないものになっていた。

そんなMacBook ProについているTrack Padを、単品のUSBデバイスとして改造するという素敵な情報を公開しているbounavさんという人を見つけた。どうやら以前のMacBook Proでは、フレキシブルケーブル経由でUSBの4本の信号線がそのまま入ってきているらしく、その4本を引き出してUSBコネクタにつけちゃえばUSBデバイスとして使える、ということらしい。良くそんなこと調べたな、ほんと感心するわ…

Macbook pro trackpad conversion – http://bounav.free.fr

そんなめんどうなことしなくても、Magic Track Padがあるけど?

そう、外付けしたいだけなら同じくApple純正のMagic Track Padがある。面積も一番広いし、Bluetoothでケーブルレスなのでデスクがスッキリ。MacBook Proの操作環境をデスクトップPCでシミュレートしようとすると、このMagic TrackPadしかないというのが現状。

もちろんこれはこれで悪くないのだけど、キーボードの右端に置くというスタンダードなレイアウトだとちょっとホームポジションからの距離が遠い。ホームポジションから離れたくないとまでは言わないんだけど、MacBook Proの親指を伸ばせば操作できる形の方が理想に近い。

それでMagic Track Padをキーボードの下に並べてMacBookみたいなことをしようとすると、縦方向に大きすぎるのと、電池ボックスのせいで距離が遠すぎて使いづらいことに気づく。また、Bluetooth接続なのでKVM切替器を通す切替ができず、ペアリングも1台分しか覚えてくれないので基本的にコンピューターの数だけTrackPadを用意しなければならなくなる。そんな馬鹿な。

そんなわけでMacBook ProについているTrackPadがそのまま外部USBデバイスになるなら俺もそれほしい、と思ったので、実現できるかどうかの確証もないままMacBook Pro Early 2008 (A1260)のTop Case中古品を取り寄せた。新品のがいいけど、新品は$240くらいする。たかがTrack Padに2.5万円というのはあまりにもばかばかしいし、何より改造に失敗したときの精神的ダメージが大きすぎるので、まずは中古をPowerbook Medicから取り寄せた。動作確認済みの在庫が1つ$36ほど。

Powerbook Medicの中古品は、美品とはいえないけどまぁ自分できれいに掃除すれば気にならないレベル。ところどころ髪の毛がついていたりお菓子のクズみたいなのが見えたりはするけど、まぁ海外の中古品なんてこれが普通だろう。神経質な方はご遠慮ください。

Top Case Trackpad Assembly for MacBook Pro

MacBook Pro 2008年モデル

ちなみに数あるMacBook Proの中から、あえてbounavさんが改造しているのとは異なるこの2008年モデルを選択したのにはもちろん理由がある。それはマルチタッチに対応した機種だということ。今時マルチタッチ対応しないTrack Padなんてほとんど意味がない。bounavさんが公開しているのはマルチタッチ対応する前のモデルで、基板上のパーツの配置が結構違っているので少し調査が必要にはなるが、基本形は同じである。

ちなみにここでいう「基本形」というのは、USB ControllerがTrackPad側の基板にのっている、ということ。最近のMacBook ProではTrackPoint側にはUSBコントローラーが載っておらず、Logic Board側に移動してしまっているようで、Track Padの外だし改造をするにはLogic Board側も必要になるらしく同じような改造は簡単にはできないらしい。

写真左に見えるCY8C24794がCypressのUSB Controller。CY8C24794のデータシートを見ると、以下のような割り当てになっている。

  • Pin19 : Vss
  • Pin20 : D+
  • Pin21 : D-
  • Pin22 : Vdd

パターンをたどると使えるテストポイントがわかる。
usb_board1

bounavさんのまねをしてボード上のテストポイントに半田付けするなら、5V0/DP/DNのところと適当なGND(例えば下の写真のコネクタ右に見える金色の点)につなげばいい。でもねー、これ、写真だと簡単にできそうに見えるんだけど、超マクロ撮影でようやくこんな感じなので、実際には間隔が1mmあいていないパーツもザラ。割と人間業ではない。老眼でもないのに、作業用にルーペ買ってきてしまったくらい。極細のこて先も持っているけど、もうそういうレベルの問題じゃないというか。

なので、これはコネクタ側の方までたどってピンアサインをしらべて、フレキシブルケーブル側に半田付けする方が楽だし、失敗しても基板が死ぬこともなく安全という結論に達した。コネクタの並び順はCY8C24794からGND以外については基板上のパターンで追える。GNDはテスターで確認。本体につながる8ピンコネクタの左から4本がUSBで、GND/Data-/Data+/5Vという割り当てになっているようだ。

usb_connector

ちなみにこれがフレキ。ケーブルはUSB標準に合わせて黒(GND)、白(Data-)、緑(Data+)、赤(5V)を用意。電源系の黒赤は0.5mm、信号線の白緑は0.26mmのジュフロン線を使った(下の写真は全部0.5mmだけど)。

ribon_connector4

フレキの方が作業が楽、とはいっても、パターンは極細なので全部コネクタ付近に集めるのは無謀。どうしてもここから取らざるを得ないData+/Data-だけコネクタ付近に取り付ける。当たり前だけどフレキは絶縁されていて電気が通らないので、表面をパターンを切らない程度にカッターナイフで削って金属面を露出させて、そこにはんだを盛る。ここが一番難しい。

ribon_connector5

難しいとかいってもこの写真だとどうってことない半田付けにみえるかもしれない。実際には超細かくて0.5mmのシャープペン芯と比較するとこんな感じ。シャープペン太い!

ribon_connector8

電源系はパターンが太く、面積も広いのでよりどりみどり。GNDを表の後ろの方から取る。

ribon_connector6

5Vは表側から取れなくもないのだけど、面積が少なくData系と近いので裏面のここから取った。ちなみにデータ系は裏にもパターンがあるので、フレキのオレンジ色のテープを剥がしてData-もしくは+のいずれか一方を裏につけることもできる。これをやるとData系のはんだ付けが楽ちんなのだけど、Track Pad本体に取り付ける際にTrack Pad本体と触れてしまうのでやめた方がいい。ribon_connector7

引っ張ったケーブルは直接USB Aコネクタとかにつなげてしまうとケーブルの長さが固定になってしまいユースケースが限られてしまうので、USB Micro Bのメスコネクターにつなげて配線はUSBケーブルを使うことに。Micro Bのコネクタは表面実装とかこれまた作業が辛いのが多いので、素人も安心な変換基板付きを秋月電子で買ってきた。もっとも、上記のフレキはんだ付けしたあとでは、表面実装くらい全然問題なくできるんじゃないかって気もしてきたけど…usb-micro-b

今回の工作の全貌。Track Pad本体には全く手を入れていない。

ribon_connector9

完成図。ケースとかがないのでちょっと頼りない見た目だけど、とりあえず動作確認OK。TrackPad

実用化に向けてはケースをどうにか自作しなければならない。金属木材プラ、どれも加工経験がなく厳しいところだけど、とりあえずプラか木材かな。ハンズいって簡単に加工できそうなものがないか見てくるとしよう。

部屋の照明修理 Season 2

 

 

部屋の照明は20年くらいになろうかという年代物。過去にはコンデンサが噴いてしまってチカチカするばかりで点灯しなくなって差し替えたりもしたけど、だましだまし直しながら使い続けてきた。

しかしついに先日全く点灯しなくなった。トランジスタが焼き切れたっぽい。どの足にテスタを当ててももれなく通電。ご臨終だな…でもまぁ、そこまで原因がわかっているならパーツ交換で何とかなるだろう、といういつもの軽いノリで、往生際悪く修理作業することに。

それで早速Webから同じパーツをオーダーしようと思ったのだけど、調べてみるとこれがおもしろいくらい売られていない。すべてディスコン。まぁ製品自体が20年前のものなのだから、当たり前か。

仕方がないので代替品を用意することに。トランジスタ系の交換は初めてでサッパリわからないので、アナログ回路の入門書を見ながらデータシートの見方をちょこっと勉強して、データシートとにらめっこしながら適当に3つの品を選定した。

回路シミュレータでスッキリわかる! アナログ電子回路のキホンのキホン

今回差し替え対象となったのはこの3個。

  • Panasonic 2SC4559
  • Panasonic 2SK1605
  • Fuji Electric 2SK1819

それぞれ以下で差し替えた。

  • ST Microelectronics BUL58D
  • ST Microelectronics STF6N52K3
  • ST Microelectronics STF8NM50N

本当にスペック的にOKなのかは知らない。でも、割と近いスペックだと信じている。素人なりに。

写真は、上が元々ささってたパーツ、ヒートシンクに取り付けてあるのが新しいパーツ。

1st 2nd交換したらフツーに点灯した。むぅ、まだまだいけるw

 

EWI3030mのバッテリー交換&ホルダー化

 

EWI3030mのバッテリーホルダー化。別にたいした作業じゃなかったのだけど、Webで検索してもあまりみあたらなかったので、記録として残しておこうかと。

シンセとバッテリー

80年代、90年代のシンセはエディットした音色を取っておくためのメモリがFlashとかではないため、SRAMを維持しておくためにCR2032とかのコイン電池をのせていることが多い。これが10年も20年も立つとさすがに切れているわけで、SRAMのデータを維持できなくなると例の「おきのどくですがぼうけんのしょの1ばんはきえてしました」みたいなことになる。

電池が切れると変更した内容が保持されなくなるのは当然のこととして、メモリーされていた内容もおかしくなるので、時には音が鳴らないなど深刻な誤動作をするようになる場合もある(リセットすれば直るけど)。中古でシンセを入手したりしたときに、ピロピロと変な音しか出ない、とかも案外電池切れが原因だったりするので結構重要。

直付け時代

詳しい理由は知らないのだけど、この頃の機材では電池が基板に直付けされているケースが割と多い。ドライバーで開けてコンビニで買ってきた電池を入れ替える、では済まず、残念ながら半田付けし直さないといけない。

そんなわけで、電池交換するときはこんな感じの電池ホルダーを買ってきて、次からは蓋を開けて電池を入れ替えるだけで良いようにしておくのが一般的。

ホルダー取り付け作業

開けるとこんな感じでフロントのコントローラー関連と液晶、メインと電源という感じ。本気で作れば半分くらいのサイズのケースで作れそうなものだ。ウィンドシンセなんてたいした数は出ないだろうから、多分サンプラーのSシリーズと箱を共用にしていたのだろうけど…ewi3030m-01

ちなみに配線はかなりギリギリで、基板をひっくり返すには6箇所のネジを外した上で、上の写真でいうと手前の方のコネクタを全部抜く感じになる。配線はこんなにピーンと張らなくてもいいと思うんだけどなぁ…

コネクタやネジって調子に乗ってがんがん抜いていくとあとで戻せなくなったりするけど(俺だけ?)、間違って違う場所にさせそうなのは3ピンの青と赤のコネクタくらい。これらはソケットにもコネクタにも色がついているから余程のことがない限り間違えることはない。分解初心者フレンドリーだ。

電池は真ん中あたりにある、黄色く丸いこれ。EWI3030m ROMの真上についている。システムROMをICソケット化しているのに、電池は直付けというよくわからない実装。当時としてはROM交換の方が頻度が高いと読んでいたのかな。
ewi3030m-02

電池ホルダーが入らない

以前マルツで5個くらいまとめてかっておいた電池ホルダー。なんと、ROM手前のセラミックコンデンサーにぶつかってしまって取り付けられない(写真ではうまくささっているように見えているけど、実は右側の足がささってない)。さすがにこれは予期していなかった。ewi3030m-03 C5というのが実際にぶつかっていたコンデンサー。片方の足が電池ボックスの真下にきてしまうので、仕方なく一度コンデンサーを引っこ抜いて先に電池ホルダーを取り付けた。ewi3030m-05取り外したコンデンサ。

ewi3030m-04

 

残っている足もあまり長くはないけど、めいっぱい伸ばして、基板に気持ち斜め向きで差すようにして再度はんだ付け。めんどくせー。でもまぁ、これくらいなら多分言われないと誰も気づかないだろう。

ewi3030m-06

ちなみにこの配置、実は電池が出て行く方向を3方からコンデンサに囲まれているので、電池ホルダー化したにも関わらず相変わらずバッテリー交換が面倒くさい。バッテリー外すときにコンデンサ破壊したりとかしたら笑えない。

オールクリア

最後にメモリクリアする。EWI3030mの場合SOUND LEVELとLABELボタンを両方押しながら電源ONすると、メモリオールクリアになるらしい。プリセットからMIDI設定からなにからすべてが出荷時の状態に初期化される。部品の実装作業が終わっちゃうと満足しちゃうんだけど、ここ結構重要。

 

 

ewi3030m-07