かねがねから私はJavaのDIを信奉する人々を信じていなかったのだが、決定的なクソ仕様を発見したので、嬉々としてご報告する。

ソースがこんな感じになっているとする。パッケージが異なる同名のクラスね。

package org.abc.def;
@Component
public class Xyz extends BaseX {

package org.abc.efg;
@Component
public class Xyz extends BaseX {

これ、エラーになってプログラムは起動すらしません(ConflictingBeanDefinitionException)。component scanにゴテゴテに書けばどうにかなる可能性もあるけど、こんなんウンコでしょう。ネームスペースのことを理解していないんですよこいつら。パッケージが違ってクラス名が一緒なんてそこら中に転がってることでしょう？ java.util.Optionalとcom.google.common.base.Optionalとか、タイムスタンプ系の各種DateだのTimestampだのTimeStampだのとか(すでに忘れてるけど、要するにたくさんある)。それはDIの世界では決して許されない。

以前に下駄を買った話を書いたけど、よくこれで散歩や買い物に行くようになっているんで、しばらく使った結果、わかったことを書いておきます。世界に下駄ユーザーが一人でも増えますように。 履き心地。これ、かなり良い。慣れると非常に快適。音、足への衝撃、視点が若干高くなり、足の指への力のかかり具合、包まれていないフリーな感覚。とにかくさわやかな、清涼感？ みたいなものを感じます。 冬の寒さ。木でできた下駄は意外と温かいものです。木のぬくもりとはよく言ったもので、足の裏は靴＋靴下よりも暖かいという感覚がある。冷たい地面から離れているし、木の層が厚いので、これはなるほどと思った。ただ、足の裏以外は冬場は寒いです。 頑丈さについて。まず鼻緒の裏側の結び目部分に金属でカバーが釘でつけられているのですが、これはあっという間に外れました。貫通しない短い釘は100円ショップで見つけることができなかったので、仕方ないとガムテープで止めてます。豪快ｗ そして、底の減り方はちょっと気になるね。砂というか小石が突き刺さってくっつくのと、歩き方の問題で、前列の外側が削れてくる。足が疲れた時に引きずり気味になっていたのが悪化を進ませたんでは、という気もした。下駄には左右の区別がないので、たまに左右を入れ替えて均等化してます。この感じだと、持って1年くらいかな、とも思える。まあやばくなったらまた買いに行こう。底を皮と金属で補強した下駄があるといいじゃないかな。←なぜかセルジオ越後みたいな口調になってますが。 モビリティについて。通勤にも使っているランニングシューズと比べるとモビリティは落ちますが、ちょっとした駆け足くらいはイケます。疾走はできません。あと靴よりも疲れるので遠出はできない感じ。急激な動きにも向きません。まあ、そんな時は下駄を脱いで裸足で走ったほうがいいです。 苦手な地形。ツルツルと下り階段は苦手です。底まで木なので、摩擦抵抗が少ないため滑りやすい。スーパーの店舗の中など、ツルツルな床というのが街には多いんだな、ということに気づかされました。そうじゃなくてもトイレに行くといきなりツルツルになる建物があったりする。こんなところで転べるかよ！ 世間様においては、もっとバリアフリーに努めてほしいところ。それから、階段の下り。手すりを掴まないと怖い。高速に下ることができないため、急いで下に降りる用事がある時は下駄を履かないほうがいいです。あとぬかるんだところには行きたくないね。大事な下駄もそうだけど、足が汚れるからね。これはサンダルと同じ。なるべく濡らしたくないな、という感覚もある。 ファッション性は抜群です。まずバッタリ会った知り合いには下駄について突っ込まれますからね。子供に指さされたりもしますしね。みんなの憧れ。

MacのHomebrewは我々のようなクリエイティブな人間にとっては必須とされるツールだ。 だが、ちょっとした悩みも生じるんですよね。 Macには最初からPythonとかが入っているんですけど、Homebrewにもpythonがある。2系と3系があって、共存できるようになっている。ただPython使ってる人はシステムに最初から入ってるPythonを使うか、pyenvで入れるだろう。pyenvで入れとけばsudoしなくても済むし、いろんなバージョンを切り替えて使える。pyenvからpypyを使ってもいいしJythonやIronPythonを使ってもいい。私も普段はpyenvで普通のCPythonを使っている。pyenv自体はHomebrewで入れている。つまり、以下の3つがあるわけだ。

• システムのPython
• HomebrewのPython
• pyenvで入れたPython

pyenvはpyenvで問題はあって、やれzlibだのreadlineのヘッダがないとかで新しいバージョンのインストールがコケることが多発するのだが、それは置いておいて、問題はHomebrewのPythonだ。 ansibleやmercurialもHomebrewに入っているんだけど、こいつがHomebrewのPythonに依存しているのだ。つまりHomebrewのPythonを使わずにpyenvを使い、ansibleやmercurialはHomebrewで入れたい、と言ったことができない。pyenvならpyenvにどっぷり入って、pyenvが用意しているpipでpip install ansibleだのpip install Mercurialだのする必要があるわけ。 私はbrew update ; brew upgrade ; brew cleanupを毎日実行していて、パッケージをなるたけ最新に近い形で保っている。そこにgemだのpipだのnpmだのは入ってきてほしくないんだ。開発するモジュールに依存したpackage.jsonだのGemfileだのrequirements.txtは開発するモジュール側に入っているわけで、アップグレードして古いのを消す、みたいなのを回すとやばいと直感が俺にささやく。 だけどさ、ansibleやmercurialは最新に保ちたいんだよ！ つまり、、、

まじか。よりによって大阪開催の年に決勝進出しなくても。俺たちのフロンターレの初タイトルが… 毎年思うんだけど、天皇杯の制度ってどうにか変わらないもんですかね。まずホームアンドアウェーにしてほしいし、元旦決勝ってセンスがなさすぎる。どうやったって移動が帰省ラッシュとぶつかるし、むしろ帰省できなくなるし、元旦にわざわざサッカー見に行かないですよ。天皇杯って名前なのに天覧試合が絶対に不可能になってるというアホさ加減。元旦サッカーの歴史や伝統なんて大してないんだから、スパッと変えちゃえばいいんですよ。 というわけで新横浜に行ってきました。とにかく寒かった。でかすぎてガラガラ感があったけど、2万人以上入ったんですってね。これ等々力なら超満員の人数だったのに。しかし準決勝進出したのにここを使えないマリノス、かわいそうに。 まあ今日の勝利は後半のあの大ピンチで大宮のFWが外してくれたおかげですよね。ありがとう… そして谷口の谷口らしい決勝ゴール。いつもDFとして身体能力を駆使したギリギリのクリアを繰り返していただけあって、あの体勢から正確なシュートを繰り出すキックを瞬時に選択。頼りになるね。 サッカーとしてはあまりうまく行っていた印象がない。立ち上がり一発目のエウシーニョ→大久保のシーンで慢心してしまったのかも。全体的にはさすが大宮、相手の良さをしっかり消してくるな、と思いながら見ていた。試合前は大宮と比べて交代選手に不安を感じていたけど、三好や大島はうまく試合に入って活躍してましたよね。そういうのも次に繋がりそうだし、今日のあの大ピンチのシーンとか、鹿島の選手だったら決めてたよね。そういうアラートを感じられたというのも収穫だと思う。勝利こそが何もかもを好転させてくれる。

うちのルンバがすぐに「ルンバを充電してください」と悲しい声を響かせるようになった。本当に悲しそうな声。聞いてるこちらが泣きそうになってくる。電池がヘタってきてるのかな…と思って、とりあえず分解掃除。まあ、年末の大掃除の一種ですね。 このルンバという機械はとてもよくできていて、いつも分解してみるとさらに「こりゃよくできてる」と感心してしまう。プラスドライバで外れる部分は外しても良くて、ホコリがたまるところはそれで全て対応できる。外しちゃいけない部分は三角の特殊なドライバが必要になる。この辺はいかにも良きアメリカ製品という感じがする。 あいつらはアリゾナの砂漠でこいつを売らなきゃいけないんで、つまり修理センターなんて洒落たものを整備できない。ユーザが自前で整備できるようにしよう、という作り方をする。日本の製品はこういう思想を持ってないですよね。壊れたら電話かネットで依頼して宅急便で送って直してもらう。もしくは自分で持ち込ませる。私もなんか直しに都内に持ってたことがあるなぁ。何直したのか忘れちゃったけど。とにかく、精密機器をユーザが分解するなんてとんでもない。日本製品はそういう作りになっている。そのせいで、無理やり分解してみるとナンジャコリャ、ということになりがちなんだ。Macとかはだから、アメリカの製品だけどもすごく日本っぽい作りをしてるんだと思っている。 それはそうと、分解掃除してみるとルンバの隙間には毎度のことホコリがたくさんたまっていて、よく動いてたなこれで、という感想を抱いた。そして今、彼は元気に働いています。頑張れよ。電池はまだいけるか。前回はいつ電池交換したか調べてみたら、2012年だった。まあいずれまた電池を交換してあげよう。

gogsについにPRの画面でマージしたブランチを削除するボタンが出てくるようになった！ …何を言ってるかわからない人は、すみませんがこのページを閉じてください。 とにかく便利になった、ということなんですが、gogsの作者は結構厳しい人みたいで、リリースノートから参照されている当該PR(https://github.com/gogits/gogs/pull/3225)にしても、どう見ても必要で実装されていなかった機能の追加をするPR。これをレビューしたあとpingに反応しなかっただけで一度はマージせずにクローズしている。まあパッチに問題があったにしても、こいつはクローズしたあとこの必須機能をどうするつもりだったの？？ そして、gogsはいつの間にかforkされてgiteaというプロジェクトができていた。まあどういう関係にあるのか知りませんが。以下は想像のための材料だけど、

• giteaはgogsをforkしたという説明だけで、gogsとの住み分けとか位置付けを示す文章は見当たらない
• gogsのメンバーは現在2人で、ex-team members(“元"チームメンバー)と表現されている3人はcontributorsページで見ると貢献度は2-4位
  • 1位の奴はメンバーに残っていて、2-4位だったメンバーがごっそり抜けた感じになっている
  • そしてgiteaのメンバーに2位と3位だった人が入っている
• ただ、1位の奴のコード行やcommit数は他を圧倒して余りある数字

giteaの方が進んでいるということも言えなくて、今回のマージ済みブランチ削除ボタンもgiteaにはまだマージされていない。gogsでマージされたパッチをcherry-pickして作られたPRはできていた。ただgiteaの方はもうすぐLFSサポートも入りそうな気配で、gogsには当分入らなさそう。まあ、この辺も単なる期待でしかない。 …という感じなので、割と悩ましい状態が続くようだね。

久々のゲームは味スタで天皇杯。メリークリスマス。なんとこの馬鹿げたスケジュールよ。しかしスタンドはかなり埋まっていた。よく来たねこんな日に、こんなところまで。 監督は来季相手方に移籍が決まっている大久保を先発させた。やりにくさはないとの判断か。実際に大久保は先制点を含む精力的な働きでその信頼に応える。それもあってほぼ川崎がゲームを支配したかなと。それでも終了間際に失点して冷や汗をかくところが川崎らしい。最後はしっかり2-0のまま締めないと。ガンバ戦の手痛い教訓を思い出せ。 登里はちょっと心配か。痛んで交代する時でもピッチに一礼してから出て行くところはまあ、絵に描いたような好青年ですね。 次は大宮と新横浜で、暮れも押し迫った29日。我々が行くスタンドはホーム側？ アウェイ側？ よく分かりませんが、このカードと場所と日程は…ガラガラになる可能性も。とにかく、調べてチケットは買います。 あとはまあ…寒かった。ハーフタイムの売店も並びまくりで、何も買えねーよこんなんじゃ。

以前にMacの日本語入力を絶賛したわけだが、最近Google日本語入力に戻ってしまった。

• OS Xの日本語入力が良くなったと聞いて
• macOS Sierraによる神アプデ
• OS Xの日本語入力の続報

なぜかというと、これはAtom(githubのテキストエディタ)のせい。Atomの最近のアップデートがMacの日本語入力と組み合わせると最悪のエクスペリエンスを与えることになったため、泣く泣くGoogle日本語入力を入れ直すことになった。確定のタイミングとかが違うからキーストロークが変わってやりにくいんだよね…やめてほしい まあこれをもってmacの日本語入力をウンコ扱いするのはとんだ「とばっちり」もいいとこなんだが、現実としてテキストエディタでAtomを常用している私としては、Atomが直るまではmacの日本語入力を使えなくなってしまったのだった。この気持ち悪い中黒カタカナと付き合わなければならない身にもなってほしい。これAtomにissueを上げるべきなんだろうけど、なんて書いたらいいのだろうか。スクリーンキャストで表現しないと伝わらないような気がするな。 中黒カタカナというのは、例えばGoogle日本語入力で、「コンピュータ」で確定、「サイエンス」で確定、と打ってみて下さいよ。サイエンスを自然に確定させようとすると先頭に中黒がついて「コンピュータ・サイエンス」になっちゃうじゃないですか。油断していると「データベース」とか「ウェブサイト」にも中黒を挿入しようとするんだこいつは！ そしてこの機能をオフにする方法が分からないんだ。中黒くらい「/」キー一発で打てるんだから、わざわざ補完してくれなくてもいいんだよ。 …と思っていたところ、さらに最近のatomのアップデートでこの挙動が直ってる？？ ちょっと戻してみようっと。いま使ってるのはmacOS Sierra 10.12.1とatom 1.12.6です。 あとOpenSCADのテキストエディタもコメントとかに日本語入力しようとすると変なことになるよね。これもGoogle日本語入力にすると少しはマシになるが、完全には治らなかった。入力場所がおかしくなったり、あーと思ってundoしても、undo自体がバグってしまって、消したい奴が抜けて残ったりするのよね。

明日というのは明るい日と書くんだよ。 こないだヤマダ電機に行った時に見かけたLED蛍光灯。丸いドーナツ型のやつで、普通の天井についてる器具に取り付けられるというものを売っていた。ヤマダのオリジナル商品？ いくらだったか忘れたが結構安かった気がする。一見してこれはバカ売れするだろうな、と思ったが買わなかった。まーでも今度切れたらビックやノジマじゃなくてヤマダ電機がファーストチョイスだな。忘れそうだからどこかにメモしておこう。 LEDの照明は宮内の街灯も徐々にLEDにリプレースされていて、おかげで宮内の夜道はかなり明るくなっている。ちょっと明るすぎるんじゃないかと思えるくらい。だいたい都会の夜は明るすぎるんですよ。これじゃ天の川も見えないわけだよ。夜歩いてても危険を感じないのは、それはそれでいいことなんだろうけど、ちょっと残念に思う気持ちもあるんです。

今日はあのマイアが…というニュースがあったが本当だろうか。まあ嘘である理由はないだろうけど、間違いということはないんだろうか。 小林悠の残留…果たしてこれはどう出るか？ 実は私は彼がいなくなるものだと思っていたので、来季の前線は森本を軸に三好と大塚あたりに新戦力を混ぜて回していくのかなと思っていた。大久保・小林悠がいなくなっても無理やり今年と同じサッカーをしようとすれば、憲剛をFW起用するくらいしか手がないけどもったいないし、エドゥの動向にもよるがブラジル人FWを入れるか…といった感じ。まああの2人がいなくなったら攻撃はだいぶ変質するのは当然だよね。 ＃ ちなみにうちの子供は小林悠が大好きです。なんかグッズが当たるんだよね。運命かもしれないね。 だが小林悠が残留となれば同じサッカーができる。大久保は点取るところとキープやプレスが上手く怪我もせずシーズン通して90分走り回っても平気だけれども、常に相手DFに脅威を与え続けチャンスの山を作り出すという点ではJリーグでは小林悠の動きがナンバーワンだ。やはり森本を中央に置く形か、2トップか…さらに他の強力なFWを獲得したら…鬼木新監督も頭を悩ますだろうな。相馬監督時代も小林悠の攻撃力を最大化するために色々悩んだわけだけど、どう整理していくんだろう。予想もつかない形になる可能性もある。