読者です 読者をやめる 読者になる 読者になる

猫も杓子も記事を書く

140文字ではかけないことをかこうと思います。

【解決した!!!】MongoDBのざっくりとした解説と謎

久々にプログラマっぽいことを書いてみる。

↓ここからMongoDBがわからない人向けのお話パート

今、仕事でMongoDBを触っています。
なんぞや?って方に説明しますと、データベースの一種です。ざっくりいうと、今までのデータベースとくらべてデータの参照・追加・更新・削除をよりちょっぱやにできるようにというコンセプトで作られたもので、MySQLといった従来のデータベースとは仕組みが違います。興味のある方は調べてみてください。

んで、MongoDBの機能の一つに、レプリカセットというものがあります。
これもググってもらったほうが理解が早まる感が否めませんが、複数のMongoDBでひとかたまりとしてデータを共有することで負荷*1をそれぞれのデータベースで分散できるので高負荷に強くなり、万が一、ある1台のデータベースがダウンしても、生きている他のデータベースを代わりに働かせるように設定できる機能があり*2、それによってグループ化されたデータベース群のことをいいます。
勿論他のデータベースにもレプリケーション機能はありますが、MongoDBはとにかく膨大な量のデータを扱うケースが多いため、完全ダウンしないようにデータベースを設計することが重要であり、ですからぼくのようなズブの素人でも簡単にレプリカセットを構築できるように作られているのです。

このレプリカセット、主従関係があります。
マスタースレーブ構成といって、名前のまんまですが、レプリカセットの中で、メインとサブのデータベースを決めてるんですね。メインのデータベースをMongoDBではprimary、サブのデータベースをMongoDBではsecondaryと呼称します。
primaryは1つのレプリカセットに1台だけ存在できる、いわばレプリカセットの中の頭領です。一方のsecondaryは子分みたいなもんなので、構築するレプリカセットに応じて何台でも組み入れることができます。
基本的にデータの追加・更新・削除はprimaryが一人で担い、参照アクセスに対してはprimaryとsecondaryが手分けして対応するイメージです。仲間だもんげ!
この2種類に加えて、Arbiter(アービター)というポジションがあります。データの読み書きには一切参加しませんが、「決定者・仲裁人」という名前の如く、もしprimaryがダウンしたとき、secondaryをprimaryに昇格させる役割を持っています。ただこいつはレプリカセットには必須ではなく、あって損なし、くらいのポジションです。Arbiterがいなかったら、secondaryの中から一人が合議制によって選ばれます。*3
MongoDBのレプリカセットにおいては、とにかくprimaryを存続させることが至上命題です。primaryが落ちると、データの参照以外一切できなくなってしまいますから・・・
なので、primaryがダウンしたら、secondaryのうちの誰かが代わりにprimaryになります。これがレプリカセットにおける大原則です。

↓ここから謎パート

以上を踏まえて、ようやく謎について書きます。
今仕事で触っているMongoDBのレプリカセットは、primary、secondary、Arbiterが各1台ずつ、合計3台によって構成されています。以下のような感じ。

rs.status()
{
        "set" : "testReplicaSet",
        "date" : ISODate("2016-11-29T01:07:44Z"),
        "myState" : 2,
        "syncingTo" : "163.44.166.156:27017",
        "members" : [
                {
                        "_id" : 0,
                        "name" : "xx.xx.xxx.xxx:27017",
                        "health" : 1,
                        "state" : 7,
                        "stateStr" : "ARBITER",
                        "uptime" : 14,
                        "lastHeartbeat" : ISODate("2016-11-29T01:07:43Z"),
                        "lastHeartbeatRecv" : ISODate("2016-11-29T01:07:42Z"),
                        "pingMs" : 3
                },
                {
                        "_id" : 1,
                        "name" : "yy.yyy.yy.yyy:27017",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "SECONDARY",
                        "uptime" : 66420,
                        "optime" : Timestamp(1480315218, 1),
                        "optimeDate" : ISODate("2016-11-28T06:40:18Z"),
                        "infoMessage" : "syncing to: 163.44.166.156:27017",
                        "self" : true
                },
                {
                        "_id" : 2,
                        "name" : "zzz.zz.zzz.zzz:27017",
                        "health" : 1,
                        "state" : 1,
                        "stateStr" : "PRIMARY",
                        "uptime" : 91,
                        "optime" : Timestamp(1480315218, 1),
                        "optimeDate" : ISODate("2016-11-28T06:40:18Z"),
                        "lastHeartbeat" : ISODate("2016-11-29T01:07:43Z"),
                        "lastHeartbeatRecv" : ISODate("2016-11-29T01:07:43Z"),
                        "pingMs" : 0,
                        "electionTime" : Timestamp(1480381583, 1),
                        "electionDate" : ISODate("2016-11-29T01:06:23Z")
                }
        ],
        "ok" : 1
}

rs.status()というのが読んで字の如くなレプリカセットの状態を見られるコマンド
。 stateStrがそれぞれ、primary、secondary、Arbiterとなっているのがわかると思います。
ここから、secondaryとArbiterのMongoDBを停止*4し、primary一台だけにしてみます。
MongoDBを止める際は、Linuxサーバー上であればserviceで問題ありません。

[root@secondaryサーバー ~]# sudo service mongod stop
Stopping mongod:                                           [  OK  ]
[root@secondaryサーバー ~]# 
[root@Arbiterサーバー ~]# sudo service mongod stop
Stopping mongod:                                           [  OK  ]
[root@Arbiterサーバー ~]# 

止めた状態で、再度レプリカセットの状態を確認してみます。
MongoDBはprimaryが命。正直primaryさえあれば稼働が止まることはないですから、primaryだけ生き残ってくれさえすればそれでよいのだが・・・

rs.status()
{
        "set" : "testRepl",
        "date" : ISODate("2016-11-29T01:16:50Z"),
        "myState" : 2,
        "members" : [
                {
                        "_id" : 0,
                        "name" : "xx.xx.xxx.xxx:27017",
                        "health" : 0,
                        "state" : 8,
                        "stateStr" : "(not reachable/healthy)",
                        "uptime" : 0,
                        "lastHeartbeat" : ISODate("2016-11-29T01:16:49Z"),
                        "lastHeartbeatRecv" : ISODate("2016-11-29T01:15:18Z"),
                        "pingMs" : 0
                },
                {
                        "_id" : 1,
                        "name" : "yy.yyy.yy.yyy:27017",
                        "health" : 1,
                        "state" : 2,
                        "stateStr" : "(not reachable/healthy)",
                        "uptime" : 66966,
                        "optime" : Timestamp(1480315218, 1),
                        "optimeDate" : ISODate("2016-11-28T06:40:18Z"),
                        "self" : true
                },
                {
                        "_id" : 2,
                        "name" : "zzz.zz.zzz.zzz:27017",
                        "health" : 0,
                        "state" : 8,
                        "stateStr" : "SECONDARY",
                        "uptime" : 0,
                        "optime" : Timestamp(1480315218, 1),
                        "optimeDate" : ISODate("2016-11-28T06:40:18Z"),
                        "lastHeartbeat" : ISODate("2016-11-29T01:16:48Z"),
                        "lastHeartbeatRecv" : ISODate("2016-11-29T01:12:40Z"),
                        "pingMs" : 0
                }
        ],
        "ok" : 1
}

・・・どうしてこうなった。
primaryが何故かsecondaryに降格し、secondaryだけで稼働している状態になっているのがわかるでしょうか?
こうなると、secondaryを経由してのデータの参照以外、なにもできなくなってしまいます。
リスク回避等の目的でそういう「仕様」なのであれば、仕様なら仕方ないよね、としか言いようがないのですが、
今のところ、公式をあさっても、そういった記述はありません。
だから、事象として確認できるだけで、確たる裏付けがないのです。

困ったなあ。

参考

https://docs.mongodb.com/manual/replication/docs.mongodb.com

qiita.com

qiita.com

qiita.com

2017/03/05 追記

あれから数ヶ月たちました。
結局、社内での検討の結果、MongoDBは採用されず、
この件についても有耶無耶になったまま止まっていました。
このままにしておくのも気持ち悪かったので、改めて調べてみたら、何の事はない、ちゃんと公式に書いてありました。

Replica Set Elections — MongoDB Manual 3.4

If a majority of the replica set is inaccessible or unavailable to the current primary, the primary will step down and become a secondary. The replica set cannot accept writes after this occurs, but remaining members can continue to serve read queries if such queries are configured to run on secondaries.

レプリカセットの過半数以上がアクセス不可(or利用不可)の場合はprimaryはsecondaryに降格します。
この状態ではレプリカセットへのデータ書き込みは出来ませんが、secondaryが生存している限り、読み込みは続けることが出来ます。

・・・とのこと。
つまり、上記の例ではarbiterを含め、2台以上生き残っていなければいけなかった、ということですね。なるほど。
しょうもないオチではありましたが、ひとつスッキリする結論に達することが出来ました。
コメントいただいたkabao2003さん、ありがとうございました。

*1:ここでいう「負荷」とは、アクセス負荷をイメージしてもらえばいいと思います。

*2:この機能自体はレプリケーションとか、フォールトトレランスとか言ったりします。

*3:もしsecondaryが全員自分に投票したら当然票が割れるので、Arbiterを組み込むのはそれを防ぐ意味合いもあります。

*4:上記で言うと、上から1番目と2番目ですね。

小噺

デレマスの4thライブに行ってきたはなし

今更の話題にはなりますが、デレマスの4thライブがSSAで行われ、ぼくは運良く2日間とも当選したので行ってきました。
率直な感想としては、「2.5次元に迷い込んだ気分」でした。個々のアイドルが過去のカードをモチーフにした衣裳を着て登場するのは初とのことで、担当アイドルは失神ものだったんじゃないでしょうか。中の人も外の人も個性丸出しで面白かったし、サプライズも両日とも本気でしたね。すごいぞバンダイナムコゲームス、すごいぞサイゲームス。
「誰もがシンデレラ」の名に相応しい、全員が輝いていた素敵な2日間だったんじゃないかなと思います。
デレステの方ではイベントもやっておりますので、程々に頑張っております。やる気・・・

 

ガッキーが可愛すぎるというはなし


[新ドラマ]新垣結衣×星野源の「恋ダンス」 先行映像 10/11スタート 火曜ドラマ 『逃げるは恥だが役に立つ』【TBS】

 

かわいい!!!!!!!!!!!!
福山雅治が何をしても、何を言ってもかっこよくなるように、今のガッキーなら何をしてもかわいく見えるのでしょう。どんな徳を積んだらこんな可愛い人に生まれることができるのか知りたい。
ぼくはBメロサビ直前の「デ・デ・デデン」のところで首を傾げるガッキーが最高に好きです。かわいい。

 

無性に何かが食べたくなるときの衝動は怖いというはなし

最近、チキン南蛮が食べたくて食べたくて仕方がありません。気がつくと「チキン南蛮 美味しい」「チキン南蛮 おすすめ」「チキン南蛮 都内」などでググってしまいます。
完全に個人の主観なのですが、日本三大大衆ランチというのが自分の中にありまして、豚肉生姜焼き・鶏の唐揚げと並んでチキン南蛮があります。肉ばっかだな。
要は「値段や店によってピンキリはあれど、どこで食べても期待を大きくそれることはない」ご飯です。もしそこで期待がそれるようなことがあればそれはメイン以外の何かが壊滅的にまずいとかそういうやつです。*1
チキン南蛮の何がいいかというと、甘すぎず、すっぱすぎず、鶏の唐揚げに絶妙にマッチする甘酢と、まるで自分が主役であるかのような、下の鶏肉とはまた違った色彩を放つタルタルソース、この組み合わせです。*2
唐揚げといえば、衣はサクサクと、中の鶏肉のジューシーさが一定の指標ですが、チキン南蛮にはそれは当てはまりません。サクッとした衣も良いが、甘酢がひたひたに染み込んだ衣もまた味がある。タルタルソースもまた、下の鶏を引き立てるあっさり感か、ピクルスの食感をアクセントにできる角の立ったソースか・・・どちらも美味しくなるので不思議です。
お店の数だけ、源流から汲み取った我流のチキン南蛮があります。みんなちがってみんないい。同じものばっかり食べていたら病院のご厄介になりそうな懸念はありますが、それでも自分を捉えて離さない魅力が、チキン南蛮にはあるような気がします。

*1:お米が硬すぎてたべられたもんじゃないとか、味噌汁が・・・とかです

*2:余談ですがタルタルソースを考案した人は冗談抜きで人類史に残る偉業だと思うので、銅像を建てて下々の者共に参詣させるべきだと自分は思います

tomorrow is another day.

今日、ベイスターズの2016年シーズンが終了しました。

 

昨年、首位から転がり落ちるように最下位に落ち着いたチームが、今年はどこまでやれるのか。
戦力補強といえるのはルーキーの今永と戸柱、ロマックとペトリックの二人の外国人、監督と何人かのコーチの刷新。つまりは未知数。
「WE PLAY TO WIN」というスローガンは、去年耳にタコができるほど聞いた「あとは勝つだけ」を彷彿とさせる。順位的には、決して期待できるような状態ではなかったと記憶しています。

 

事実、開幕してから4月中は馬鹿みたいに負け続けました。
なにしろ打線が起きてこない。1番白崎はいつの間にかどこかへ消えていき、筒香がホームランを飛ばせど空砲に終わる。
何度好投した投手の頑張りを無にしてきたか。梶谷の復帰だけがファンの心の拠り所。それでも沢山の客がハマスタに駆けつけていましたが、一方でまた今年もパッとしないまま終わるのかという恐怖もよぎりました。

梶谷が戻ってきて間もなく、打線が息を吹き返しました。本人はなれない打順に四苦八苦したり、相変わらず、時折見えるやる気のなさげに見えるスイングはファンを落胆させました。それでも彼の俊足はいくつもの好プレーを呼び、そのプレーに触発されるように、チームは少しずつ噛み合い始めていました。

「監督に就任したらパフォーマンスは封印する」といっていたとおり、エモーションを前面に出す中畑前監督とは違い、ラミレス監督は試合中ほとんど表情を変えず、ウインドブレーカーに手を突っ込みながら試合をじっと見つめていました。その姿にほんのりと、頬杖をつく権藤博監督の面影を感じるぼく。*1
その監督が「交流戦までに借金を返済する」ときた。これは1つ彼に乗せられてみるか。すると5月、あれよあれよと勝ちまくり借金を本当に返済してしまった。
石田や今永が投手陣を引っ張り、熊原が鮮烈に一軍デビューしたり、野川の出囃子でレスキュー!と叫んだのもこの頃でした。

交流戦はなかなか安定して勝てず、連勝したり連敗したりの日々が続きました。5割いけるかと思ったら楽天日ハムにボコボコにされたりとかね。なんとか3位にいるという感じでしたが、いつBクラスに落ちてもおかしくないなと思いながら見ていました。なかなかもどかしい中でチームを支えるピッチングを見せてくれた久保や山口は希望の光でもありました。

そこに現れたのが筒香嘉智。7月の筒香は敵将・緒方監督の言葉を借りるなら”神ってる”状態でした。彼の一振りで勝った試合もたくさんありました。彼のお陰でチームはぐいっと3位の座を引き寄せました。
8月の山崎康晃大乱調、Aクラス攻防の阪神戦被3タテ、ピンチも波も有りましたが、その度に土俵際で踏みとどまって戦ってくれました。そして雨中の9/18を迎えるのです。

 

去年のことがありましたので、CSなんて決めるまでは信じないぞと思っていましたが、1つ勝つたびに現実味を帯びてくる「3位」というポジションは、CSという制度が始まってからずっと、自分たちにとって「無縁だった」ところで、それがだんだん「喉から手が出るほどほしい」に変わっていくのを多くの人が感じていたのではないでしょうか。今までだったら、「今年のドラフトどうする?」を居酒屋で論じていたはずなのに、まだ応援できるなんて。
ぼくはスタジアムのファンの声援からそれを感じていました。”君たちは今までどこにいたの?”というくらいたくさんの、ベイスターズファンがスタジアムを埋め、ネットの中継に集い、攻撃しているときも、守りについたときも、いつ何時でも声援を送り続けていました。間違いなく、チームの力になったことでしょう。

 

3位から、ある意味真の挑戦者として挑んだCSは、巨人戦も広島戦も、文字通り激闘でした。
エース山口俊の影に隠れながらも、しっかりと自分のピッチングでチームに勝利を呼びこんだ第二のエース井納。攻守で要としてチームを底上げしてくれた倉本。ファームでずっとやってきた努力を決勝タイムリーという形で実らせヒロインを掻っ攫う嶺井。骨折してもなおハッスルプレーを見せる梶谷。最終盤で肉離れにより離脱し、今季絶望かと思いきや必要なときに颯爽と戻ってきてピシャリと抑える須田。筒香の次を任され、重圧の中天性と努力の打法でヒットを積み重ねてきた宮崎。スタメン起用即2ランで終戦を止めたエリアン。
2冠王になった筒香や、9月の大ブーストでコンディションを上げているロペスはまともに勝負してもらえないかもしれない。そんなプレッシャーの中で、ここに名前を挙げていない選手を含め、一丸となって必死に戦っている姿は多くのファンを揺さぶりました。

それでもカープとの間には、チームとしての力に大きな隔たりがあったように思います。本当に強かった。
ジョンソン野村にほとんど無抵抗のまま打線がやられてしまったこと。ロペス筒香が完全に封じられてしまったこと。田中広輔というシリーズ男の存在もあったように思います。
この差をあとどれくらいで追いつき追い越し、ひっくり返せるのかどうか、ぼくには分かりません。それでもチームにとって、負ければ終わりという環境下での戦いが、選手にとって貴重な財産になり、この経験が土台となってこれからのベイスターズに活きていくと思います。というか、常勝球団になるならそれしかない!

ぼくはこの短期決戦の中で、何年ぶりかに「負けるのが怖い」という感覚を味わいました。シーズンが終わってしまう。あのプレーが水の泡になってしまう。それでもファンにできることは選手たちを信じて、応援すること、それしかない。
恐怖と隣り合わせにある快楽に、ぼくは酔いました。そしてそれは、勝つことでしか報われない、あまりに明確で、残酷な世界でもありました。しかしそれでも、このチームにとって新たな足跡を残してくれたこともまた事実です。

暗黒時代からの脱却。偶然にも杜野まこさんが今日のモバマスのライブ中、同じ言葉を使っていましたが*2、「脱皮」です。ファンもチームも、次のステージに向かって行くために、ようやく新しい皮を手に入れました。それを誇りに、来年は「本当に強いチーム」としてのベイスターズが見られることを楽しみにしています。

 

最後に、今年本当に頑張って、ぼくらファンに夢を見せてくれたナインの皆さんに、この歌からお借りして届けたいと思います。

www.utamap.com

泣いて 泣いて またいつか泣きやんだら

小さな胸をはってもいいんじゃないか

どうやったって 毎日は過ぎるし

くやしさ 少ないほうがいい 

 

*1:そういえば権藤監督も、優勝したときはルーキー監督でしたね。結局、監督としてチームを率いたのは横浜での2年間だけだったわけですが、今のベイスターズをどう見ているのか、気になるところですね。

*2:衣装のブーツが壊れてしまったことをこう表現していた。やはりあの方は素敵指数が高い。

河口湖で楽しかったことと、反省しないといけないこと

茅原実里ファンにはもはや恒例となりましたが、8月の6・7日と、河口湖ステラシアターで野外ライブが行われるというわけで、参加してきました。

chiharaminori.net

この場所での野外ライブは8年目ですが、過去、いろいろとスケジュールや予算があわず、ようやく参加できるようになったのは3年前からでした。
まだその頃は学生でしたので、日帰りで2日間往復ということもできたのですが、流石に年齢による衰えを隠しきれなくなってきまして、今回は宿を取りました。
・・・半分どうでもいい話なのですが、この宿を取るというのが地味に大変で、発表前から開催を見越したファンが次々に宿をおさえており、自分が探し始めた頃にはすでに会場近くの安宿は全滅でした。
奇跡的に会場から徒歩30分ほどで行ける場所が空いていたので速攻で予約したのでよかったのですが・・・

結果的にライブは最高に楽しかったです。自分はどうしてもライブの最初から全力で盛り上がるというのができなくて、内なるテンションが上がってくるのを待つしかないのですが、
今回のセットリストはちょうど本編終盤~アンコールが山場になるように、自分にしっくりと合う構成になっていました。おかげで次の日からまた仕事が始まるということを暫し忘れられるくらいには盛り上がることができました。
なにより、みのりんもバックバンドも、そしてバックダンサーもみんな楽しそうにパフォーマンスしていて、気づいたらこっちまで楽しくなってしまうというのがこのサマドリの常であり、どんなに行くのが面倒でもやめられないところだなあと思います。
やはりIAツアーからそれほど日が経っていないからなのか、初日と2日目でセットリストが変わったのは2~3曲程度で、そこは少し残念だったのですが、sfやpn,fdなどのサマドリ定番曲はもとより、lm(紫のほう)やfhnなど、ライブで久しぶりに聴く曲が多かったのもおお~っとなりました。salの曲が多かったですね。
ちなみに自分はアルバムではparadeが一番好きなので、アンコールでVoyager trainのイントロが流れた瞬間意識が一瞬飛びました。来年は花束とかprism in~とか期待したいですね・・・

帰りに乗った満席のスーパーあずさ36号の中で、真っ暗な車窓を見ながら、走馬灯のようにライブを思い出していました。来年はこの電車も争奪戦になるのでしょうか・・・

ともあれ、無事1泊2日の旅程を終えて東京に戻ってくることができたのですが、来年以降の反省に繋がるところも多々あったので最後に挙げておこうと思います。

  • 旅館は早めに取る

f:id:umincyu11:20160809163338j:plain

聞くところによると、毎年あそことかあそことかは争奪戦になっているようです。
今回お世話になったホテルは敷地内にコンビニが有り、また大浴場と客室にマッサージチェアがついていたのが良かったです。チェックアウトが早いのと、Wi-Fiが繋がりにくかったのがちょっとアレですが。*1
また、同好の士がちらほらといらっしゃったようですが、中には「僥倖」とプリントされたTシャツを着ている方もいて、ちらりと見た瞬間命の危機を感じました。

  • 車を使うならノープランは重罪

せっかく泊まるので、どっか観光したくない?と連れが言うので、ついでに会場⇔ホテルの行き来もしやすくしたいなと思い、突発的にレンタカーをチャーターしました。
突発的にした割にはいい車が残っていたのですが、自分が車の運転免許を持っていないので連れに運転を任せっきりにしてしまったのと、お互いにそれほど行きたい場所がなかったのでぐだる、という有様でした。計画性は重要。結果的に河口湖畔周辺をぐるぐるしたり、POKEMONGOを片手に密林を探検したりしました。

  • 現ナマこそが正義

手元の現金が枯渇していたので、クレジットカードで乗り切りたいところでしたが、無理でした。
何かしようと思うと、クレジットカードが使えないところばかりで、結局観光するなら現金ないとダメだなと痛感し、結果コンビニやチェーン店に依存するという、観光感0の旅行?になりました。河口湖周辺に三菱東京UFJ銀行の誕生が待たれる。

 

思い返すに、8年もこんな僻地河口湖で野外ライブを続けてきてマンネリズムを生まないのは、ひとえに瀬野さんを始めとしたスタッフ陣の努力にあることを忘れてはいけないなと思いました。今年でステラシアターという会場では通算公演回数が単独最多らしいです。すごいな。
来年もやるということなら、ぜひ行きたいと思います。でもウインタードリームも楽しそうね・・・

*1:ここまで言うとバレそうな気もする

765のプロデューサーです。

更新がまたしても滞ってしまったにも関わらず月間100PVとか、なにもしてない荒れ地同然のブログに・・・本当にありがとうございます。

最近、PS4熱がまた再燃しつつあり、BD再生専用機と化していたPS4でゲームをする日々がやってきています。
オーバーウォッチやウイイレなどで遊んでいたのですが、今週、ついにアイドルマスターの新作がPS4で発売されました。

 

platinum-stars.idolmaster.jp

 

個人的に本格的にアイマスに触れ始めたのが、シンデレラガールズからだったので、アーケード含め、純粋な「アイドルマスター」シリーズのゲームに触れるのは、恥ずかしながら、今作が初めてでした。
せっかくPS4を買ったわけだし、やらないわけにはいかんだろうということで、ちょこちょことプレイしています。

やはりぱっと見て一番の変更点は、アイドルたちのグラフィックの変化ではないかと思います。みんな目がくりっと大きくなって、かなり現代のアニメーションに寄せてきている印象を受けます。自分はこれぐらいファンタジーに寄せてくれたほうが好みですかねえ。

今日、ちょうどリーダーである我那覇ひびきんのアイドルランクがDに上がったところなのですが、ライブも何回か行って、ゲームの流れが少しずつわかってきたところです。

ライブ中、トリオやカルテットを組んでいると、組んだアイドルによってちゃんとボーカルが変わる仕様になっているんですね。ここが一番すごいと思いました。
たとえば、リーダーに響を設定していると、リーダーの歌パートのところで響の歌声が流れるというような感じです。つまりライブ曲については、13人全員のソロバージョンを収録して切り出しているんですね・・・
言葉では説明しづらいところですが、よく出来てるなあ・・・とおもったところでした。
ライブ会場独特の音響も再現されていて、臨場感を感じさせます。ファンのコールもちゃんと入っています。このゲーム用の新曲も遊べるのですが、そのコールも入っています。練度が高いですね。

キャラでびっくりしたのは、りっちゃんこと秋月律子がまだ19歳だということ(あずささんが21というのも大概だと思うのですが)、アニメを少しかじった程度の状態で見ると(年端もいかない女の子が事務員やってたの・・・)とアイマスの時間軸ってどうなってるんだろう・・・と思い、アイマスに詳しい友人に聞いてみました。

  • りっちゃんはもともとアイドルに乗り気でなかった(どちらかと言うと事務員・プロデューサー志望だった)からアイマス2で事務員になった。アニメはその辺を踏襲していたんだとおもう。
  • シリーズに時間軸の互換性は殆ど無いと考えていいと思う。だったら毎回765の面々がひよっこアイドルなのはおかしいでしょ。

なるほどと思いました。シリーズにつながりはないんですね・・・
もうすでにトップランクまで上げているプロデューサーもいるようですが、自分はまったりとやっていきたいと思います。

Javaの日付処理のはなし

最近、とある客先に配属されて仕事しているのですが、勤怠の登録システムがすこぶるめんどくさいのです。

「月末に出退勤時間書いたCSV渡すからそれ見て勤務時間計算して日報データに書いて!その勤務時間とDBの勤怠時間が合ってるかどうか確認して!」 って・・・
仮にもIT企業なんだからそれぐらい自動でやってくれてもよかろうに・・・というかDBの勤怠時間を使わせてもらうわけにはいかないのか・・・ 15分刻みで計算とか、いろいろ計算条件も多くて、月末忙しい時にこれをやらされるのは手間です。

こういう時、プログラマーはどうするか。 真面目に計算する人もいますが、そんな時間は身にならないし、何よりめんどくさい。

というわけで、計算プログラムを自作するのです。

CalcWorkingTime.java

Java案件担当中なので、Javaで書きました。 1,2時間でさくっと作るつもりが、丸一日ちかくかかってしまった・・・
まあ今は暇を持て余している状況なので、いい暇つぶしにはなりましたが。
(変数名とか大目に見てね・・・)

PHPでは似たようなことしたことあったんですが、Javaは時間の計算がすこぶるめんどくさいですねー。
今回は勤怠システムなので、記録される時間に合わせて生のデータに手を加えなければいけなくて、型変換とか考えるの大変でした。半分くらいIDEのおかげです。 まあ、いい勉強になったということで・・・
ちなみに上司はVBAでやってました。それ正解。ぼくできないけど、VBA

・・・そして、このプログラムを読んで、ふと気になったことがひとつ。
このプログラムでも使っているgetTime()あたりのメソッドは、UNIX時間にもとづいて時間を取得していますので、
いわゆる、"2038年問題"とかどうなんだろう、とか思ったわけです。

2038年問題とは、乱暴な言い方をすれば、UNIX時間から経過した秒数が、プログラムの中で扱える範囲を2038年に超えてしまうため、 システムの時間がおかしくなっちゃうよ、ということです。
そして、その影響をもろに受けるのがC言語。 若干古めの言語では有りますが、まだまだ現役ですし、
日本のコンピュータシステムは、根っこの部分でC言語を使っている(金融系とかそうじゃないかな?)のも多いので、 社会インフラ混乱するんじゃね?とか言われていたりするんです。
まあいろいろ対策はあったりするみたいですけどね。詳しく知りたい方はウィキってみるなどしてみてください。

んで調べてみたら、やはりUNIX時間なので、このメソッドで取れる時間にも限界があるみたいです。
え?いつかって?
・・・2億9千万年後に。

2億9千万年問題 ‐ 通信用語の基礎知識

・・・まあ、考える必要も無いレベルの次元の話ですし、
そもそももし2038年におかしくなるとしても、そこまで動かすプログラムを書いたつもりもないですし・・・
ただ、さっきも書いたとおり、Javaってほんとに日付・時刻の計算がめんどくさいので、
なんかないかなーと思っていたところ・・・

見た瞬間、目からウロコがぽろぽろ落ちてきました。
Javaってこんなんあるんやん!
ぼくが調べた時にはDateクラスとかCalendarクラスの記事しか出てこなかったので、完全に盲点でした・・・

acro-engineer.hatenablog.com

この新API(といっても3年近く前ですが)、Oracleにとってかなりの肝いりのようで、従来の日付関係のクラスとは比べ物にならないほど進化・充実しています。
とはいえ、基本的な使い方は従来のクラスと変わらないので、学習コストもそれほどかかりません。
イミュータブル(変数に入れた値が変わらない)でスレッドセーフ(同時に複数同じメソッドを実行しても互いの処理結果に影響しない)のもよい!

というわけで、調べながら、プログラムを新API仕様に書き直して完成させる、はずだったのですが、

CalcWorkingTimeWithNewAPI.java

Exception in thread "main" java.time.format.DateTimeParseException: Text '9:15' could not be parsed: Unable to obtain LocalDateTime from TemporalAccessor: {},ISO resolved to 09:15 of type java.time.format.Parsed
    at java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:1920)
    at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1855)
    at java.time.LocalDateTime.parse(LocalDateTime.java:492)
    at DateTimeAPIPractice.CalcWorkingTimeWithNewAPI.main(CalcWorkingTimeWithNewAPI.java:105)

・・・絶賛詰んでます。
APIの一つであるDateTimeFormatterクラスが結構曲者で、 パターンの判定がけっこう厳格なんですよねー。
とはいえ、条件を緩やかにしても変わらないし・・・
エラーメッセージで調べても、英語のstackoverflowばっかりだし、
内容も

Javaのバグやで!最新のJavaダウンロードしな!」(今使ってるのもうそれよりだいぶ後なんですけど・・・)

みたいなのもあって、うーんって感じです。
日付系の処理は今後も間違いなく使うので、この機会にすっぽり覚えてしまいたいんですけどね。うまくいかないなあ。


6/24追記

試行錯誤して、なんとか動くところまではきました。
実際のところどうなっているのかは不明ですが、時:分形式のFormatterにこだわるのをやめて、

DateTimeFormatter csvFormat2 = DateTimeFormatter.ofPattern("yyyy/MM/dd []H:[]m");

LocalDateTime shukkintime = LocalDateTime.parse(time1, csvFormat2);

こうしました。そうしたら認識してくれました。
H:mではなぜparseできなかったのか、は謎のままです。うーむ。

あと、意地悪な上司に言われたのですが、 生データをいじられるということを想定してなかったので、DateTimeParceExceptionを書いてませんでした。
客先の勤怠時間を記録するDBには正しい時間が入っているはずなので、勿論ここをいじったぐらいで実際の勤怠時間を改ざんすることはできませんが、止まっちゃうのも嫌なので、手元のコードはExceptionを追記して使っています。

ベイスターズの2勝1敗力は本物か

丸2ヶ月間が空いてしまいましたが、そんなことは素知らぬふりをして書いていきます。

 

遂に野球狂い共が跋扈するプロ野球ペナントレースが今年も開幕し、すでに2ヶ月が経とうとしています。気がついたら交流戦です。早くない?

謝罪

さて、開幕前、今年の順位について、ぼくは以下のように予想しました。

 

 正直、パ・リーグについてはわからないことも多く、ソフトバンクの独走とオリックス楽天の逆独走は止まらんだろうということぐらいしか頭にありませんでしたが、セ・リーグについては割りとガチめで見てみたつもりです。
まだ開幕して50試合前後、1/3強の日程しか消化していないのでどうとでも転ぶと思いますが、それでもセ・リーグの順位が現時点でひとつもあてられていないことは申し開きのしようもありません。まあこんな素人に言い当てられるようなリーグじゃつまらないからね。これでいいよね。

当初、「この選手が引っ張っていくだろう」とみていた主力選手がどのチームも軒並みいまひとつという現状もあります。
まずぼくが優勝候補に上げた阪神は、オープン戦で好調だった江越横田やルーキー高山の若手力に藤浪メッセンジャー能見の3本柱が安定すれば首位に行く力は充分あるだろうと思っていたのですが、今のところ3人で貯金2つしか作れていません。個人的には鳥谷のあんな姿は見とうなかった。育成出身の原口が正捕手1番手筆頭として躍動しているのがプラス要素でしょうか。

同様に昨年王者のヤクルトも思わしくなく、さらなる投壊を招いています。野手陣唯一のウィークポイントだったセンターに坂口がいい形で埋まり、山田は相変わらず怖いほど絶好調、川端バレンティンも好調であるにも関わらず、投手陣が悲惨です。
小川とルーキーの原に依存せざるを得ない状況で、館山、石川、成瀬といった実績あるメンバーが思うように結果を残せていません。中継ぎにものすごい皺寄せがきています。打ち勝つチームというスタイルは1999年のベイスターズを髣髴とさせますね。

反対に広島は、マエケンの抜けた穴をカバーするだけのエースと呼べる存在がいなくなるのがネックになると思い、3位に留まるだろうと見ていたのですが、蓋を開けたら打撃陣が絶好調。菊丸はともかく、エルドレッドリーディングヒッターとはとても予想できませんでした。

そんな中、我らがベイスターズは現在5位にいます。5位と言っても、5月に入ってから急に投打が咬み合いだし、借金は二桁もあったところから2まで減らし、首位広島とも3.5ゲーム差まで詰まっています。
チーム状況だけ見れば上向きになりつつある中で鬼門の交流戦に突入というのがなんとも意地悪な感じですが、今年はチームスタイルががらりと変わっており、「今年は期待できる」というファンの方は多いように思います。

データに見る2016年のベイスターズ

いつもならぶっちぎりのブービーか、あるいは昨年のように謎の団結力による首位か、どちらかだなと思っていたのですが、4月の大コケを乗り越えて、現時点ではしたたかに上を狙える位置にいます。
今年のベイスターズの何がいいのかというと、(まさかこんなことを書くとは夢にも思いませんでしたが)投手陣の調子がいいという点、および守備がかつてに比べ安定してきているからというところがあるように思います。
印象論をうだうだ言ってもしょうがないので、データで見てみましょう。ヌルデータという、いろんなデータを収集しているサイトをチェックしてみます。

※以下、データはすべて6/3閲覧時のものです。

http://lcom.sakura.ne.jp/NulData/php/stat_disp/stat_disp.php?y=0&leg=0&tm=Sta&fp=1&dn=53&dk=1

印象から言うと、今年のベイスターズ投手陣を引っ張っているのは井納・今永の2枚看板です。

井納は、山口俊の怪我による代役とはいえ、呪いのごとく毎年勝てていない開幕投手で見事白星を上げるピッチングを見せると、巨人戦ではプロ初完封をあげました。もともとタフな選手なので、スタミナには定評がありましたが、こういう形で結果に結びつくのはいいことです。5月は勝ちに結びついていませんが、4月のどん底期を下で死守していたのは間違いなく彼でしょう。

逆に、4月の間好投しながらもずっと打線に見殺しにされ、勝ちから見放されていたのが今永ですが、ここに来て援護を呼び込めるピッチングができるようになってきました。直球に見た目以上の伸びがあり、奪三振を取れるというロマンあふれるピッチャーです。
その今永の先輩に当たる石田健大も5月はいい内容を見せてくれました。一昨日の試合は四球から崩れるという勿体無い内容でしたが、5月の反転攻勢は彼がいなかったら成し得なかったのも事実です。

先発が開幕からずっと5回を投げ切っているという事実はPRという数値にも現れています。

ttbo.cocolog-nifty.com

防御率をより投球回を重視して評価する指標ですが、この指標ではベイスターズが2位のジャイアンツに1.5倍近い差をつけています。それだけ各先発陣がしっかりと仕事をしているということです。

一方で、守備という意味では、デルタの出している数値を見るとわかります。

1.02 - Essence of Baseball | DELTA Inc.

これを見ると、UZR(リーグにおける同じ守備位置の平均的な選手が守る場合に比べて、守備でどれだけの失点を防いだのかという指標)はセ・リーグトップの+11.8。
今年はピッチャーも送りバント処理を悪送球、というシチュエーションが減ったように思います。気のせいかもしれないけど。
またキャッチャーに戸柱、石川と倉本の二遊間、センター梶谷と、センターラインがポジティブに固定できているのがこれまでにない堅守を呼び込んでいる気がします。梶谷が戻ってくる前も桑原が懸命に守っていましたし、守備に対する意識は格段に上がっているのではないでしょうか。
とりわけ、倉本は未だ打率3割をキープしていますし、攻守ともにベイスターズを引っ張る存在となっています。川端慎吾さんには頭が上がりませんね。

www.zakzak.co.jp

また、打率が今ひとつ上がってきませんが、サード白崎の守備も評価されて然るべきでしょう。エリアンが入ってきてどうなるかわかりませんが、現状のベイスターズで一番サードの守備が上手いのは白崎だとぼくは思っています。内野安打で失点の傷になりそうなあたりを、見事なフィールディングでアウトにする姿を今年は多く見ます。大型内野手と期待されて入団しただけありますね。あとは打撃が上向いてくれればいうことなしです。

ベイスターズの終戦はいつなのか

時が経つのは早いもので、もう交流戦に突入した今年のプロ野球ベイスターズは、早速、埼玉西武ライオンズにコテンパンにされて久々の負け越しとなりました。来週のソフトバンクオリックスのビジター6連戦を考えると、今日からのロッテとの3連戦には勝ち越して、タイで臨みたいところですが、果たしてどう出るでしょうか。

個人的にはこの交流戦、5割ではなく、貯金を作るところを目指して欲しいと思います。大それた目標に聞こえるかもしれませんが、投手力が高いということは、安定した試合展開を想定しやすいということでもありますから。ソフトバンクや日ハムにはある程度白星を献上したとしても、それ以外のところで負け越した分を取り返すぐらいのチーム力は期待していいと思います。

また、今後のシーズンを見据えた時に、選手層の若いベイスターズは、有利不利、どちらにも転びうるような気がしています。とりわけ先発投手陣、2年目の石田はともかく、今永はルーキーです。去年は山崎康晃、一昨年は三上朋也がルーキーながら守護神定着とはまっていましたが、本来はルーキーを即戦力としてみるのは少々危険だとも思っています。
特にシーズンの疲労が溜まってくるであろう夏場から秋口にかけて、ベイスターズの調子を、またルーキー選手たちの今後を見据えてどうやりくりするかは重要です。そこを、今2軍で調整している選手たちがどう補っていけるか。少し気が早いかもしれませんが、最終的なチーム成績を上げていくためにはその連携が必要不可欠です。


チームの大半の試合でスタメンマスクをかぶる戸柱も、長いシーズンのことを考えると、疲労によるコンディションの低下は心配なところです。彼の存在が投手陣の好成績を引き出している要因の1つであることは疑いようがないので、ただでさえ捕手の層が薄いベイスターズにおいて、来るべき事態に備えておくことは重要です。

ラミレス監督の采配については、正直なところ、先発投手を引っ張りがちな傾向にあり、それが今後どう転ぶかが気になります。
観に行った試合で言うと、5/20(金)の井納に関しては、7回でもう充分という球数を投げていましたし、8回は代えるかなと思ったところを続投で、結果山田に勝ち越しホームランを打たれ、その後も安打の後四球四球でピンチを広げ、今浪に適時打を打たれて万事休すでした。
どこで先発投手を代えるかというのは難しいのかもしれません。先発投手が「行きます」といえば続投なのかもしれませんが、継投次第で流れを戻すことができたかもしれない試合を落としてしまうのはすごくもったいないという気がしています。
代打采配に関しては、結果論ですが、数字も残せていますし文句なしでしょう。下園が代打の切り札として新たな役割を得つつあるのはずっと見てきた者からすると嬉しい限りです。

今年はせめてオールスターゲームまでは夢を見たいので、交流戦は厳しいと思いますが、なんとか戦い抜いて欲しいところです。