setterとgetterというバカバカしいものがありまして。クラスの中のメンバ変数をわざわざprivateにして、publicメソッドのsetXXX()やgetXXX()を作ってその変数にアクセスさせるという。結果、メンバにアクセスするコードはこうなる。
ログ取得ツールa.getXXX().getYYY().getZZZ().setAAA(1);
これ、外からprivateメンバにアクセスしてるんですよ。こういうイリーガルなコードが世間に流布していて、あまつさえ書いてるやつらは正しいことをしてると思ってるんです。クソが。
まあ、そういう文化と称するものがあるんですよ。何でもかんでもprivate変数にpublicなgetter/setter。これをIDEが自動生成するからいいんだそうです。おめでとう、人類はそこまで思考停止するようになった。例えば将来、最高に頭のいいコーディングAIが出てきたとして、そいつが書くコードがgetter/setterの嵐になっていることを想像できるでしょうか？ なってるわけないですよね。
最近だとセルフレジの他に、商品登録は店員さんがやって、支払いのところだけ顧客がやる支払いセルフレジというシステムがあるじゃないですか。
小杉の東急スクエアの中のマルエツが支払いセルフレジというのを結構前に始めて、最初は「こいつら迷走してやがるな」と思っていたんですが、宮内ライフでセルフレジが始まって、セルフも経験してみると、私はマルエツの方が優秀だなと判定した。
あれは多分ライフのシステムが悪いんじゃないかと思いますが、結構厳しく作ってあって、ちょっと手間取るとすぐに「勝手に入れないで」みたいな感じの反応をされてしまうんですよね。小さなビニール袋の使用やレジ袋内の配置とかを考えてレジを通す順番を決める必要があるのに、そこで意外な反応ばかりされると調子が狂ってしまって、あー、みたいな感じになる。そして順番を間違えたせいでレジ袋の中を少しいじるとまた「勝手に入れないで」的な反応をされて…うーん。新城にある西友(ウォルマート系)のセルフレジではそんなに戸惑わなかった気がするんだけどな。あっちでは生鮮食品や惣菜を買わないからなのかもしれない。セルフは買う商品が1個とか2個とか、お菓子だけとか、そういう時だけにしておこうと思った。雑多なものをたくさん買うときには全く向いてない。
GitLab.comでバックアップが機能してなかった事件の話を見て、まあよくある話だよね、と思ったんだ。実際に私の人生においても、周囲にいるベテランのエンジニアが機能しないバックアップによってデータロストをする、という経験が複数回あるんだよね。自分はさすがにそういうポカはやってなくて、それはそもそもバックアップしてなかったからだ、という…基本、手で作ったファイルは全部リポジトリかクラウドサービスに入れるようにしてるからね。
そんな私が、その「リポジトリに入れる」ために自宅内gitサーバとしてgogsをRaspberryPiで動かしているんだけど、gogsはgogs backupというコマンド一発でバックアップすることができる。しかし当然のようにgogs restoreコマンドはない。まあその辺はいざとなったら自分で何とかできるだろう。いつの間にかgogs importコマンドができていた。これでいけるのかな？ 試してないけど。
最近私に知られた事実があるんですけど、それを皆さんに知っっていたただきたいいので、ここでお教えしましょう。 それは、、、
冬場にジーンズが破れていると寒い
です。 いやーまじで寒い！ どうしてくれる。夏場はあんなに暑かったのに。どうした太陽、もっと頑張れ。 まあ破れたジーンズで仕事しに会社に行くなよ、という話でもあるんですがね。千代田区に通う服装じゃない、という認識はあるんですが、ジーンズ冗長性を確保していなかったため、故障しても使い続けなければならず…流石にパンツ一丁はもっと寒いし…買いに行きたいとは随分前から思っているんですけれども。
かねがねから私は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つがあるわけだ。
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の方が進んでいるということも言えなくて、今回のマージ済みブランチ削除ボタンもgiteaにはまだマージされていない。gogsでマージされたパッチをcherry-pickして作られたPRはできていた。ただgiteaの方はもうすぐLFSサポートも入りそうな気配で、gogsには当分入らなさそう。まあ、この辺も単なる期待でしかない。 …という感じなので、割と悩ましい状態が続くようだね。