Skip to main content

ログ取得ツール

川崎1-1水原 (ACL2017初戦)

平日夜の等々力。久々のサッカーです。当然の権利を行使して会社を早退、等々力に向かう。この感じだよ。待ってたんだ。寒かった。

報道されてきた通り、1Fのバックスタンドと2Fの座席の一部(一番後ろと通路の手前の列)を交換されていた。あとはゴール裏1Fが閉鎖というACL仕様。アウェイの1F席もバックスタンドの一角だった。水原は人気チームという話だけど、確かに結構来てたね。

背番号にはまだ慣れない。視力も衰えて見にくいし、車屋が7番なんだよなぁ。サイドでついつい20番を探してしまう。あとは最後の方で出てきたハイネルね。なんとなくパトリックっぽい動き。小さいけど。まあブラジル人のプロサッカー選手らしく、わかってる感じはあったよ。

シーズン開始でこの試合だと悪くないと思いますね。内容的に見れば勝ってしかるべき試合だったとは思うんだけど、相手もなかなか技術は高いし、さすがにここに出てくる相手、実績もある奴らだけあって、次々に脅威は与えてくるからね。ただ今日は川崎が上回っていたと思う。チャンスはあったし…勝てたよなー。

最近の電話のゲーム事情2017-02

最近の通勤電車の立ち時間のゲームのラインナップ。座ってるときは読書、立ってるときは電話でニュース閲覧かゲームっすね。 Swipe Brick Breaker これはmonthly23という別名からもわかる通り、作者が月に1個のゲームをリリースすると宣言して作った23番目のゲームらしい。Shoot Bubbleとブロック崩しを融合させたようなゲームで、なかなかに秀逸。どんどん数が増えていくのもいい。 難点は、1回のゲーム時間が長いこと。下手すると通勤時間丸々使ってしまうくらいだ。 面清倶楽部 名前の通り、面前の清一色の待ち牌を当てるゲーム。横持ちなのであんまり電車の中ではやりにくい。ので、座ったときで本を持っていないときにこれをやることが多いかな。時間制限もないのでゆっくり考えられる。おそらくランダムで問題を出しているため、ノーテンが多いのはご愛嬌。麻雀も長いことやってませんが、懐かしくはある。訓練にはいいと思います。まあ清一色で悩むのは、待ち牌以外が来た時にどれを切ったら広くなるのか、フリテンを防げるのか、といった点ですけどね。 Kuromasu ゲームの正式名称は良く分からないが、パズルゲームの新星。ゲーム性は結構いい感じに思えているが、難易度が上がったときにどうなのか。正解が一意ではないような気もするんだけど、どうだろう。あとクリア画面が地味なので、クリアしてるのかどうか不安になる。 (追記) Kuromasuはニコリの「黒どこ」でした。

徒歩

前回の健康診断で引っかかったため、減量プログラムが組まれるに至りました。食事には気をつけます。ついでにてくてく歩いてカロリー消費…ひっそりそのような活動をしています。長らく痛めている足首も、サポーターを使えばどうにか騙せる。疲れ切って若干遅めに家に帰るといかにも激務のリーマン、って感じがして大人になった気になりますしw

私は故あって都心に勤めているんですが、あの辺だと一駅歩こう、とは言っても、都会なんで一駅っつっても何キロもないんですよねぇ。毎日一駅歩いてたんですけど、調べたら1kmとかそこいらでした。そんな…10分ちょいじゃんか。どおりで歩いた気がしないわけだよ。まあ新丸子←→武蔵小杉(500m以下)ほど近くはないが。それで、試しに二駅歩いてみたんです。それでも物足りないので、調子に乗って次の日は三駅歩きました。しかし通勤に使っている地下鉄はちょうどその辺でくねっていて、直線に近いルートを使えば四駅と三駅はあまり変わらないということをグーグルマップが教えてくれた。じゃあ四駅だ!

GarageBandの入力

いやーまさかCommand(⌘)+クリックで入力できるとは思いませんでした。ずいぶん悩んだけど、ググればすぐ分かったんだよこんなこと!

気合いでキーボードでタイミングを合わせて打ち込むのかと、暗澹たる思いを持ってしまっていた。まあそこまでやるならabc2midiかなんかでテキスト入力していくけれども。慣れてしまえばGarageBandのこのインタフェースは便利と思える。スコアに直接入力することすらできる。まあスコア直接は使いにくいのでピアノロールかな。これでMacでも耳コピ作業をできる環境にあるってことが分かった。次はピアノロールの幅がちょっと狭いので、縦方向に拡大する方法を知りたい。横幅は拡大縮小できるということは理解した。

しかもそのままエンコードしてiTunesに送れるというね…いや別にそこまでは期待していないのだが。便利な世の中になったもんだねー。ただ難点は.midiファイルを書き出せないので、作ったデータを保管するのが面倒な話になるっぽい。あとMac版はコード入力ができないと。ふーん。

Java民によくいるsetterやgetterの信奉者はその罪深さを知るべきでは?

setterとgetterというバカバカしいものがありまして。クラスの中のメンバ変数をわざわざprivateにして、publicメソッドのsetXXX()やgetXXX()を作ってその変数にアクセスさせるという。結果、メンバにアクセスするコードはこうなる。

a.getXXX().getYYY().getZZZ().setAAA(1);

これ、外からprivateメンバにアクセスしてるんですよ。こういうイリーガルなコードが世間に流布していて、あまつさえ書いてるやつらは正しいことをしてると思ってるんです。クソが。

まあ、そういう文化と称するものがあるんですよ。何でもかんでもprivate変数にpublicなgetter/setter。これをIDEが自動生成するからいいんだそうです。おめでとう、人類はそこまで思考停止するようになった。例えば将来、最高に頭のいいコーディングAIが出てきたとして、そいつが書くコードがgetter/setterの嵐になっていることを想像できるでしょうか? なってるわけないですよね。

セルフレジ

最近だとセルフレジの他に、商品登録は店員さんがやって、支払いのところだけ顧客がやる支払いセルフレジというシステムがあるじゃないですか。

小杉の東急スクエアの中のマルエツが支払いセルフレジというのを結構前に始めて、最初は「こいつら迷走してやがるな」と思っていたんですが、宮内ライフでセルフレジが始まって、セルフも経験してみると、私はマルエツの方が優秀だなと判定した。

あれは多分ライフのシステムが悪いんじゃないかと思いますが、結構厳しく作ってあって、ちょっと手間取るとすぐに「勝手に入れないで」みたいな感じの反応をされてしまうんですよね。小さなビニール袋の使用やレジ袋内の配置とかを考えてレジを通す順番を決める必要があるのに、そこで意外な反応ばかりされると調子が狂ってしまって、あー、みたいな感じになる。そして順番を間違えたせいでレジ袋の中を少しいじるとまた「勝手に入れないで」的な反応をされて…うーん。新城にある西友(ウォルマート系)のセルフレジではそんなに戸惑わなかった気がするんだけどな。あっちでは生鮮食品や惣菜を買わないからなのかもしれない。セルフは買う商品が1個とか2個とか、お菓子だけとか、そういう時だけにしておこうと思った。雑多なものをたくさん買うときには全く向いてない。

gogsのバックアップの罠

GitLab.comでバックアップが機能してなかった事件の話を見て、まあよくある話だよね、と思ったんだ。実際に私の人生においても、周囲にいるベテランのエンジニアが機能しないバックアップによってデータロストをする、という経験が複数回あるんだよね。自分はさすがにそういうポカはやってなくて、それはそもそもバックアップしてなかったからだ、という…基本、手で作ったファイルは全部リポジトリかクラウドサービスに入れるようにしてるからね。

そんな私が、その「リポジトリに入れる」ために自宅内gitサーバとしてgogsをRaspberryPiで動かしているんだけど、gogsはgogs backupというコマンド一発でバックアップすることができる。しかし当然のようにgogs restoreコマンドはない。まあその辺はいざとなったら自分で何とかできるだろう。いつの間にかgogs importコマンドができていた。これでいけるのかな? 試してないけど。

新事実

最近私に知られた事実があるんですけど、それを皆さんに知っっていたただきたいいので、ここでお教えしましょう。 それは、、、

冬場にジーンズが破れていると寒い

です。 いやーまじで寒い! どうしてくれる。夏場はあんなに暑かったのに。どうした太陽、もっと頑張れ。 まあ破れたジーンズで仕事しに会社に行くなよ、という話でもあるんですがね。千代田区に通う服装じゃない、という認識はあるんですが、ジーンズ冗長性を確保していなかったため、故障しても使い続けなければならず…流石にパンツ一丁はもっと寒いし…買いに行きたいとは随分前から思っているんですけれども。

JavaのDIを愛する奴にロクな奴はいない

かねがねから私は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円ショップで見つけることができなかったので、仕方ないとガムテープで止めてます。豪快w そして、底の減り方はちょっと気になるね。砂というか小石が突き刺さってくっつくのと、歩き方の問題で、前列の外側が削れてくる。足が疲れた時に引きずり気味になっていたのが悪化を進ませたんでは、という気もした。下駄には左右の区別がないので、たまに左右を入れ替えて均等化してます。この感じだと、持って1年くらいかな、とも思える。まあやばくなったらまた買いに行こう。底を皮と金属で補強した下駄があるといいじゃないかな。←なぜかセルジオ越後みたいな口調になってますが。 モビリティについて。通勤にも使っているランニングシューズと比べるとモビリティは落ちますが、ちょっとした駆け足くらいはイケます。疾走はできません。あと靴よりも疲れるので遠出はできない感じ。急激な動きにも向きません。まあ、そんな時は下駄を脱いで裸足で走ったほうがいいです。 苦手な地形。ツルツルと下り階段は苦手です。底まで木なので、摩擦抵抗が少ないため滑りやすい。スーパーの店舗の中など、ツルツルな床というのが街には多いんだな、ということに気づかされました。そうじゃなくてもトイレに行くといきなりツルツルになる建物があったりする。こんなところで転べるかよ! 世間様においては、もっとバリアフリーに努めてほしいところ。それから、階段の下り。手すりを掴まないと怖い。高速に下ることができないため、急いで下に降りる用事がある時は下駄を履かないほうがいいです。あとぬかるんだところには行きたくないね。大事な下駄もそうだけど、足が汚れるからね。これはサンダルと同じ。なるべく濡らしたくないな、という感覚もある。 ファッション性は抜群です。まずバッタリ会った知り合いには下駄について突っ込まれますからね。子供に指さされたりもしますしね。みんなの憧れ。