Toy と帽子と ADP BE

主にプログラミングに関わる話をゆるくエモくやっていきます

PARANOiA BDP の MFC を狙うための自分用メモ

しばらく DDR をプレイする機会がなさそうなので、将来の自分のためにこれを記す。

基礎知識

判定

PARANOiA の判定は色んな意味でずれている。ただし、これは個人の感覚によるところが大きいので人の言うことをあてにしてはいけない。

八分

八分の「間隔」が大きく分けて二つある。サビで多用されている印象的な SE 「ててん」を基準にするとわかりやすい。すなわち、音に合わせるとき「ててん」と踏むと合うところと、「」と踏むと合うところが存在する。

自分でも何を言っているのかよくわからないが、それで実際に光らせているのだから仕方がない。

見た目

音と矢印がずれているところと、矢印と判定がずれているところがある。自分でも何を言っているのかよくわからないが、それで実際に(以下略

ついでにいうと、旧筐体とX筐体で、見た目の判定が顕著に違う場所が存在する。自分でも何を(略

距離

これは PARANOiA に限らず DP 全般においてそうなのだが、矢印の配置により足の移動量が都度大きく変化することがある。そのため相対的に急いだりゆっくりしたりしなければならなくなる。ここに判定のズレが加わるのでなかなか大変である。

個別の注意点

開始前

次項で詳細に述べるが、PARANOiA BDP は最初からクライマックスである。よって、スタートボタンを押すところから集中し始めないといけない。立ち位置などの準備を怠ってもいけない。

ちなみに、私のルーティンは

  • 中央後方に立つ
  • 垂直ジャンプを数回(身体のバランスを調整するため)
  • かかとでバーをちょんちょんと触って立ち位置を確認・調整

である。

最初の一歩

f:id:mdstoy:20180607225009p:plain

この曲にかかわらず DDR のスコアアタックにおいて一歩目が大きな難所であることは言うまでもないが、この曲に関して言えば、いきなり1P↓・2P↓の遠配置で始まるのでその難しさは他の曲の比ではない。前述のルーティンを忘れてはいけない。

しばらく足踏み

f:id:mdstoy:20180607225254p:plain

最初を抜けたら、しばらくは 1P 側で足踏み→2P側で足踏みするだけ。判定も特に気にするところはない。ただ、1P から 2P に移るところは遠い上に同じ足(右足)を使わって移動しないといけないので地味に面倒。

同時踏み二つ

f:id:mdstoy:20180607225615p:plain

足踏みのあと、1P→2P←、1P側↓↑と同時踏みが続く。まあまあ距離があるので気を抜かない。判定はまだ気にしなくていい。後のことを考えて1P側↓↑は右を向く。もっともこれは DPer ならば考えずとも自然にできる動きなので問題ない。

また足踏み

1P 側でしばらく足踏み。何もない。

初めての渡り

f:id:mdstoy:20180607225724p:plain

特記することはない。ただの渡り。体が覚えている。

またまた足踏み、からの音合わせ

f:id:mdstoy:20180607225828p:plain

「てっ、てっ、てってれー」この音合わせは完全に音に合わせて気分よく踏めばいい。

四度足踏み

f:id:mdstoy:20180607225934p:plain

徐々に判定が狂い出す。

判定

この足踏み中はずっと遅い。足踏みのあと2P側で一周するが、そこも多分遅い。

1Pへの渡り

f:id:mdstoy:20180607230036p:plain

曲中ベスト3に入ると思われる難所。

配置

この渡りは渡り終える部分の同時踏み←↑が、ホームポジションからのロングジャンプかつ上が絡む同時踏みなので思った以上に遠く感じる。また続けざまに↑→で戻ってこなければならずまた上が絡む同時踏みが続くので結構なバランス感覚が要求される。

判定

渡り始めはそれまでの遅めから判定が一瞬普通に戻る。で、同時踏みでまた狂う。

感覚的には、←↑は早く、次の↑→は遅い。そもそも前述のとおり配置が曲中屈指の難易度であるため、単に判定だけの問題ではない気もするが。

3拍休符

f:id:mdstoy:20180607230128p:plain

上記難所のあとはしばらく何事もないし判定もおとなしくなるのだが、そのあとに3拍休みがくる。ここはぼーっとせずにリズムを取り続けること。そうでないと、次でミスる可能性が高くなる。ようするに一歩目問題と同じようなこと。

変な同時踏み3連

f:id:mdstoy:20180607230215p:plain

3拍休みの少しあとに、1P↓→、1P→2P←、2P←↓、という他の譜面にあまりないパターンの同時踏みの連続がある。珍しいだけで難しいわけではないので、この譜面をやりこんでいればたいして問題でもないけれど。

渡りの連続

同時踏みで渡ったあとは、同じようなパターンの渡りが連続する。SP だと連打地帯だが、BDP の場合は難しいことは何も考えず、ただただ DP ならではの渡りを楽しむところ。

厳密に言えばちょっと気持ち悪い判定のところがないわけではないが、1クレもやれば(私は)調整できるはず。むしろ1クレやっても調整できない日は、それはもうだめな日なのであきらめて別のことをしたほうがよい。

音合わせ

f:id:mdstoy:20180607230350p:plain

ドラムに合わせるところ。完全に音に合わせてよい。

いわゆるチュンリー*1地帯

f:id:mdstoy:20180607230520p:plain

判定的に超難所。

配置

DP っぽく1P↓を右足、2P↓を左足で踏もうと思えば踏める配置なのだけど、チュンリーで特におかしなことになるわけでもないしリスクを冒す必要もないので、正面向いてチュンリーが安定。途中で混ざる八分もそのほうが踏みやすくなる。

判定

ものによっててんでばらばらなので困る。

まず同時踏みの判定がすべて明らかに変で、音ではなく「見た目を基準にして」早め。つまりここは普段通りの目押しは利かない。どうでもいいけど、私はずれていることを前提として目押しの位置をここだけアジャストしている。さらにどうでもいいことだが、これが旧筐体の場合「見た目を基準にして」超遅めになっている。

途中で混ざる八分は、全般的に音を基準にして「すべて」遅め。相当ゆっくりを意識しないとだめな気がする。

チュンリーで取る部分は多分普通の判定。いやでも体で覚えている部分があるのでどうなんだろう?

ビジステップ地帯

f:id:mdstoy:20180607230716p:plain

地帯、といっても二つしかないけど。判定がえぐい。

判定

ひとつめのビジスッテップから「だんだん」遅くなっていく。そして、ふたつめのビジステップが曲中でもっとも(?)遅い部分となる。とにかくゆっくりを心がける。

遠配置の渡り

f:id:mdstoy:20180607230917p:plain

配置

渡りの連続。かなり遠配置の部分があるにはあるが、配置自体は大した問題はない。

判定

先のビジステップが終わった瞬間から、いきなり早めになる。(遅いところから連続的に普通〜早めではなく、いきなり「早い」ゾーンに入る)そして、さらにだんだん早くなっていく。もっとも遠配置の部分(右足を2P↓から1P↑にぶん回すところ)が一番早くなっているような気がする。遠いから相対的に早くしないといけないだけかもしれないけど。

サビの直前

f:id:mdstoy:20180607231043p:plain

配置

チュンリーでこなすのが無難。

判定

先の渡りを終えたところから相対的に急速に遅くなるので要注意。

サビの入り口〜サビふたつ目の八分まで

f:id:mdstoy:20180607231226p:plain

最大の難所。

配置

PARANOiA といえば同方向三連打というイメージがあるのだが、なんと BDP だけはそれが一つもない。二連打もここ一箇所にしかない。

そこから、猶予はあるが強烈な左右振りが待っている。とはいえ 1P 側の同時踏みを踏んだあと右足からスタートして 2P 側に歩いていけば次の 2P→にぴったり合うので、ぼーっとしてなければ何の問題もない。

判定

連打は、ひとつ目が遅くふたつ目が早い。二連打はただでさえタイミングが取りにくいのにひどい仕打ちである。で、同時踏みは遅い(ような気がする)。手前が八分でなおかつ早いので、体感的には同時踏みはものすごく溜めて踏まないといけない(ような気がする)。

そこから 2P 側にすみやかに移動して→↑と踏んだあとの八分は「ててん」。

1P への渡り

f:id:mdstoy:20180607231416p:plain

配置

美しくないのは承知の上で、ここは右右左左と踏み、同時踏み二つは正面向きで平行移動するのが無難。

渡ったあと

f:id:mdstoy:20180607231531p:plain

判定

八分は「」。そこから少し遅くなっていく。八分三連のところが一番遅い。その後しばらくは判定は戻る。

休符のあと

SP だと連打が終わって譜面が落ち着くあたり BSP は二拍休みが入る。

配置

何ということはない四分の連続だが、足運びをこだわると結構面倒くさい。正面を向いて、素直に出た方の足で踏めばいい。

判定

休んだあとの判定はかなり遅い。とにかく落ち着くこと。

最後の同時踏み三つ

f:id:mdstoy:20180607231638p:plain

MFC を狙うという観点でいえば間違いなく最大の難所。個人的には、短期間で P1 を 3 回出してしまったうちの 2 回がラストの一歩だった程度には難所。

配置

超遠配置の同時踏み。必要なのはとにかく気合。あと、体の軸は真ん中で保ったまま足だけ振り回すことを意識すると、最後の同時踏みが楽かも。

判定

感覚的には「早い・早い・ほんのちょっとだけ遅い」。ふたつ目の早いは、超遠配置なので早く感じるだけなのかも。最後の一歩は遅いといえども、目押しのタイミングをずらすほどは遅くない。気持ちだけゆっくり踏む。本当に微妙。

本当に大切なこと

何度も何度もプレイして、攻略を積み上げて、それを体で覚えて、さらに少しずつ内容をアップデートして、また何度も何度もプレイして、攻略が極まっていくと、無意識にこなせる領域が増えていく。

それが完全に煮詰まった時、いわゆる「ゾーン」に入って、MARVELOUS を狙って矢印を踏むのではなく踏んだ場所に矢印が吸い込まれていくような奇妙な感覚に襲われるときがくる。

20 年近く DDR をプレイしていて、「ゾーン」に入れたことは片手で足りるほどしかないけれど、私はもう一度あの感覚を味わいたいがために DDR を、PARANOiA BDP のスコアアタックをやめられずにいるのかもしれない。

*1:DP攻略 Wikiを参照のこと

「構文解析ハンズオン 関西出張版」に行ってきました

lang-impl.connpass.com

に行ってきました。

水島さん (@kmizu) による、構文解析ハンズオンです。ここ最近はずっとこれに参加できることを心の支えにしてました。

ハンズオンの流れと思考の変遷

いくつかのトピックについて、水島さんの講義 -> ハンズオンの流れをテーマごとに繰り返して進んでいきました。 トピックは順を追って少しずつ複雑な概念を含むようになっていて、BNF が講義の中で示されるのでそれをもとにハンズオンの時間で皆が実装するという形式です。

数値の構文解析

一桁整数の構文解析

一文字を数値であるかどうか判定するというもの。これ自身はまあさすがに大丈夫でした。これ自身は。

余談

ch - '0' って昔は入門書にも載っていたようなテクニックじゃなかったかと思うんですけど、意外と反響があるようだったのでびっくり。(老害並感) まあ、さすがに今時はもう使うようなことはないでしょうし私もまず使いませんけど。

非負数値の構文解析

与えられた文字列が数値であるかどうかを判定するというもの。 これは、0 は許されるけど 012 などは許されないために最初に 0 (zero) であるかどうかを判定する、ということを気をつけていれば問題ありません。数値であるかどうか判定は前回のを流用できますし。

と、この時点では軽く考えていました。

余談

前(左)から順番に読み込む実装をしているにもかかわらず、一の位から順に計算しているかのように

result += ch *  Math.pow(10, i);

のような実装をしていて恥ずかしながらしばらくはまっていました。

それ以前に、Java には累乗の演算子がないことをすっかり忘れていました。私はもうだめだ・・・。

単純算術式の構文解析

かっこなし、演算子は一度だけ出てくる (1+1 のような) 算術式の解析です。

BNF はこちら

expression = addition | subtraction
           | multiplication | division | integer;
addition = integer '+' integer;
subtraction = integer '-' integer;
multiplication = integer '*' integer;
division = integer '/' integer;

ここでちょっとつまづきました。

演算子を判別する時点で failure だったときと右側の数値を取る時点で failure だったときどうするかという点がまずひとつ。 左側の数値は解析済みで返せる値なので、そこまで戻ってやらないといけない。

もう一つは、前段の非負数値の構文解析がすぐに流用できなかったこと。ひとつ目の問題と関連しますが、そこまではリストアすることを意識していなかったのでここに至って今までのソースがすんなり流用できなくなってしまいました。

そこでようやく、@kmizu さんの模範実装が try-catchthrow Exception を多用していたことの意味をあらためて意識しだしました。ただし動くものは作れましたが、この時点で理解はまだ正しくできていません。

算術式の構文解析

かっこや複数の演算子が登場する算術式の解析。

BNF はこちら

expression = additive;
additive = multitive 
           {'+' multitive | '-' multitive};
multitive = primary
           {'*' primary | '/' primary};
primary = '(' expression ')' | integer;

ここであらためて、@kmizu さんの講義の内容や模範実装の意味を咀嚼し直しました。 また、周りの人たちが「なんかわからんけど BNF 通り実装したら動いた」(意訳)と口々に言っていたので、私も邪念(?)を捨ててとにかく BNF を書き下すことに専念することにしました。あと、前述の、数値の解析が足を引っ張っているのをなんとか潰す。

そうしたら、なんかわからんけど BNF 通り実装したら動きました。その瞬間、私も「やったー」より「お?おおおお?」という感覚になりました。 また、何も考えずに実装した結果としてなぜそのような実装をするのかをようやく理解したというよくわからないことに。

JSON構文解析

書いている途中でタイムアップ。あとで続きやろう・・・。

特に印象に残ったこと

「なんかわからんけど BNF 通り実装したら動いた」

いろんな方が言っていた、これ。

よくよく考えたらなんかわからんなんてことなんかなくて、BNF という絶対的な仕様があるのだからそれを自然に書き下したらそりゃ動くんじゃないかなぁ、って後で思いました。普段そういうコーディングをすることがそうそうないからなんかよくわからんように思えるだけで。

日々の業務も BNF 的なもので書き下せれば簡単にプログラムで書き下せるようになるのかしらん?って、その BNF 的なものをどうやって作るんだよって話ですけど。

締め

とにかく楽しかったし勉強になりました。 プログラミング欲も満たされた、というかむしろ増大して飢えがひどくなったかもしれません。 懇親会も二次会もいろいろな話題で楽しめました。

関西出張して今回の機会を作っていただいた @kmizu さん、スポンサードしていただいたエフ・コード様、会場提供していただいたはてな様、本当にありがとうございました。 次の機会にも期待せざるを得ない!

DevLove関西「カンバンによるムダのカイゼンの事例」に行ってきました

devlove-kansai.doorkeeper.jp

に行ってきました。

前置き

内容に沿った話は私の手には余るので(おい)、かろうじてメモが取れて印象に残ったこと、忘れないようにしたいことをつらつら記していきます。 実際ぷーさにさんの話は面白くて密度も濃いので、私の処理能力ではちょっとうっかりすると咀嚼できずにただただ楽しく聞くだけになってしまってました・・・。なんとかしたい。

振り返りのテーマを絞る

自分が直接は関わってないんですが、予めキープしているミーティングの時間をよく踏み越えている(ようにはたから見えている)チームがあるんですけど、確かにいろんなことを一度にやろうとしている(ようにはたから見えている)と思いました。

少なくとも、今後この点を意識して関わる必要はありそうだと思いました。

型にこだわらない

プラクティスを実行するのが目的ではないとか、カンバンの型は現場の状況に応じて臨機応変に変更べきとか、そういうお話。 あと、デジタルのツールでできること(できないこと)による制限によって、やりたいことをやらなくなるのは本末転倒であるとか。

分析する

問題が起こる傾向を雰囲気じゃなくて、統計をとって分析して対策を練る、と。 そういえば私もマネージャーにそういうこと言われたばかりだった。

モード

コーディング中には気づけない観点が、コードレビューのときには気づくとか、テストケースを作成中には気づくとか。 じゃあ漏れないようにするには、漏れないモードに予めなっておけばいいのではないか、というような話。 だいたいテストケースを作成するモードでは抜け漏れをなくそうとするので、ようするに TDD なのでは、ということだったと思います。

これは実感としてよくわかりますね。テストケース考えてたらあれもないこれもないってなりますもんね。

全員で対処

いろんな文脈でこの話が出てきたように思いますが、私が一番気になったのは全員で設計する際に public のメソッド定義、シグニチャまで決めてしまうという話。たしかにそこまで全員で設計して合意が取れているなら、レビューでの手戻りも減るはず。

できることなら是が非でもやってみたい。やってみたい。

方針ややり方を変える(変えたい)ときは全体の振り返りで TRY として変える

これも全員で対処の文脈に入る話ですね。例えばリーダーが(単独で)頑張って上から変えてしまうのはよくないと。

まとめというかとても余談

途中から、私のカイゼンの心の師匠が言っていたこと(「結果的にスクラムになってる!なのがいいと思う!」)に似ているなー、と思いながら聞いていました。 これが、カイゼンに向き合った人は結果として自然とそういう方向性を選ぶようになるのか、私がそういう考えに感化されているからそう思うだけなのかは、今の自分にはまだちょっとわからないのですが。

「春のLT祭り」に行ってきました

connpass.com

に行ってきました。

そして、人生初の LT もしてきました!!

ざっくり感想

本当に楽しかったです。(語彙)

本当にゆるーい雰囲気で和やかに進行していって、どの LT もスベり知らず。ていうか、そもそもあの空間に「スベる」などという概念自体が存在していませんでしたね。まさに幸せな空間でした。

自分の LT のこと

無職になったので料理をしてみた話

speakerdeck.com

なんのことはない、諸事情で少しの間仕事がない期間が生じてしまったおじさんが、ただただ家族のために作った晩ごはんを公開するというだけの話です。人生初の LT がこんな話ですいません。

初めての LT だし、ただただ作った晩ごはんを紹介するだけだし、ネタ自体は実は前日の夜に思いついて資料は当日の朝に作ったし、正直うけなくても仕方ないとは思っていましたが、自分の予想を遥かに超えてうけていたようでありがたい限りです。 あと、単にうけたからよかったというだけでなく、自分ではまったく意識していなかった「PDCAサイクル回ってる!」みたいな解釈を聞けたのも嬉しかったですね。 こういうのが、まず自分の考えを表明してみることのメリットなのだなぁというのを身を持って実感できました。

どうでもいいけど言いそびれたこと

さすがに初めての LT なので、ネタとして準備していけど言いそびれてしまったこともあるのですが、せっかく考えたので公開しておきます。

  • いまどきスーパーのレジ袋は有料なわけですが、今回の経験で恥ずかしながらようやく家から袋を持って行くというルーチンが身につきました。
  • 私は基本料理するときに調味料の分量を計らないし味見もしないです。そもそも何を入れるかも気分で変わります。だいたい雰囲気です。

いや、本当にどうでもいいなこれ。

本当の京都の話

資料は作ったものの、話をふくらませる自信がなかったのでお蔵入りにしようと思っていたところ、たまたま周囲の雑談が京都人の話題になったので被せて発表させてもらいました。これも自分の予想を超えていい反応をもらったのでありがたい限り。

また、「空気を読む」って概念は非難されたりもしますけど、状況に合わせて話を繰り出すという意味においてはやはり重要なのではないかなぁと再認識したりしなかったり。

真面目な振り返り

初めてなのでまあしゃあないとは思っているのですが、聴衆の方をほとんど見れなかったのはやはり反省点です。やる前から意識はして いたんですけど、さすがに実際には余裕がなかった。ただ、自分の現時点での能力が測れたという意味では十分かなぁ。

あと、自分も特に意識しなくてもあんなテンションで人前でしゃべれるんだというのは(場の空気がそうさせたという要因はきっと大きいだろうと思いつつも)ちょっと驚きとともに自信になりました。

まとめ

そんなわけで、主催の皆さん、参加者の皆さん、会場提供のはてな様、本当にありがとうございました。 貴重な貴重な経験を積むことができました!!

「関西Javaエンジニアの会(関ジャバ) '18 4月度」に行ってきました

kanjava.connpass.com

に行ってきました。 うらがみさん、だいくしーさん、じゅくちょーさんの、キャリアのお話です。

うらがみさん

コードを書き続けるということ

  • 自分のやりたいことはいつまでも楽しくコードを書くこと
  • 自分の仕事は、お客様に価値を届けること

という前提で、これを両立させるために動く、楽しくコードを書くことが結果としてお客様に価値を届けることに繋がるように「していく」というお話がありました。

私もできることなら生涯プログラマでありたいと思っている人であります。 ただ、お客様に価値を届けるという命題を前にして、また今の自分が提供できる価値(あるいは自分の存在価値)ってなんだろうと自分に問いかけてみて、それはコードを書くことではない他の何かかもしれないと思うようにもなっています。 それを受け入れるにしても、プログラマであることを貫き通すとしても、それ相応の努力やスキルや環境やその他もろもろが必要で、どこを通っても楽な道なんかないんだよなぁなんてことを考えてながら聞いていました。それはたとえばうらがみさんが GitHub に草を生やし続けたような、地道で大変な努力だったりするのでしょう。

あと、最初に挙げた二つの事柄をつなげることは仕事という観点においてはとても重要で、つまり職業としてプログラマをやっているのであれば「何のために」コードを書くのかは常に意識しなければならないということを忘れてはいけないのだと思います。 残念ながら、プログラマ(エンジニア)であり続けたいという人の中にはコードを書くことだけが目的になっている人がちょいちょいいるのが現実ですので。なにより、かつての自分もそうだったかもしれませんし。自戒も込めて。

だいくしーさん

プレイングマネージャーは管理職なのか?

だいくしーさんいわく、それは厳密には違うということ。それは確かにそのとおりで、自分が手を出してしまうのなら結局自分がやったほうがはやいというところから抜け出せていないということですから、そりゃマネジメントしているとは言いがたいですねぇ。

また、「信頼できる有能なエンジニアに恵まれているから」というような趣旨のことを言われていたように思うのですが、恵まれなかったらどうするのだろうと思ったり思わなかったり・・・。いや、そんな仮定の話をしても仕方ないのか、とか。有能な人に恵まれることもスキルのうちなのか、とか。 仮に理想と現実にギャップがあったとしても、それを埋めるために「マネジメントスキルという技術」があるのだよ、という話なのかもしれないし、とか。仮に恵まれない環境があったとして、そこから自分の力で抜け出すことも含めてキャリア形成ということなのかなぁ?とか。 まあなんかいろいろ考えてしまいました。

でも私はまだその領域に足を踏み入れていないので、やってみないとわからないことはあるだろうし、だいくしーさんとは違う私なりの方法論がきっとあるのだろうし、そのときそのときで対応していくしかないのかなとは思います。

管理職は資質が必要?

だいくしーさんいわく、後天的に習得可能な「技術」である、ということ。また、エンジニアリングのマネジメントはエンジニアリングの勘所がわかっていないと難しいということ。

言われることは本当によく理解できるのですが、それって誰でも習得できる技術なのだろうか、という疑問が。好き嫌いもあるし向き不向きもおそらくあるしどうなんだろう・・・。 いや違うか、そもそも(やっても)できない人にマネジメントさせる時点でおかしいのか・・・。でもじゃあそれって生存バイアスなのでは、という気がちょっとしました。

じゅくちょーさん

ちょっと公にできない話が多くてあれなんですけどw、まああれですね、控えめに言ってど変態ですね。いい意味で。

真面目な感想としては、行動を起こさないとチャンスは来ないし結果も出ないということがよくわかりました。 あと、自分(たち)のサービスを自分で責任を持って仕事できないといろいろつらいというのは本当にそう思います。

まとめ

今、まあまあ人生の岐路のようなところに立っていて、今日の話はなにかの参考になるはずという考えと、もしかして迷いが深まるんじゃないかという懸念の両方があったんですけど、見事に両方当てはまってました。

ただ、はっきり言えることが一つあります。経験豊富な人たちのキャリアの話はとても興味深いしためになりました。けど、それは私のキャリアではありません。そして、わたしはうらがみさんでもだいくしーさんでもじゅくちょーさんでも他の誰でもないのです。 なので、結局のところ自分のキャリア(人生)は自分にしか決められないし、自分で考えて自分で決めるしかない、ということです。

六年目のジンクス

というわけで、先月末に 5 年半ほど勤めていた会社を退職して、無職になりました。

無職?

無職になったといっても、次の仕事までちょっと間が空くだけなんですけどね。ただまあ、結果的に毎年熱望してやまなかった春休み、すなわち花粉休暇が図らずも取得(?)できることになって喜んでおります。

六年目のジンクス?

今の業界に入って三度目の退職・転職になるのですが、三度とも六年目なんですよね。 なんなんでしょうか、だいたい次のステップに進みたくなったり環境を変えたくなったりする周期が自分の場合はそれなんでしょうか? とはいえ、退職・転職に至る理由自体は、三度ともばらばらだったりします。

エンジニアとして更に上を目指したくなったこともあれば、リーマンショックやその他諸々がかさなってぼろぼろになって転職に活路を見出したこともありました。

そして今回は、まあ再度上を目指す感じです。ただ、それは今までの自分の進路の一直線上にある「上」ではなく、今まで自分が目指してきたところとは違うもっと別の何かになるはずです。ていうか、実際にそれを要求されております。

具体的には、Twitter のプロフィールに今は「職業プログラマ」と書いていますが、別の何かに書き換えないといけなくなるなぁ、みたいな。 また、例えば

kanjava.connpass.com

これに参加させていただきますが、数カ月前までの私なら、うらがみさんのお話を間違いなく一番楽しみにしていたに違いないです。しかし今はどちらかといえばだいくしーさんのお話のほうが楽しみで仕方がないのです。そんな感じです。

次の六年後

六年目での転職は、たまたま三度続いただけかもしれないです。とはいえ、三度も続くと、やはり次の六年後というのをいやでも意識してしまいます。 もっとも、次のお仕事は六年継続するだけでも大変だと思われます。しがみつくだけならわりと容易にできるかもしれませんが。(どっちやねん) ただ、しがみつくだけだとお互い幸せにはなれないので、そういうことはするつもりはないですけど。

なにより、今 44 歳なので、六年後はもう 50 歳という事実に一番驚ろかされます。その頃には子供ももう成人してますし。

まあ、座右の銘「なるようになる」でここまでやってきたので、これからもなんとかなる、なるようになるんじゃないかなー。

「Tech Deep Dive #2 in Osaka」に行ってきました

techdeepdive.connpass.com

に、行ってきました。

なんか怖そう

いやー、本当に参加するまでは本当にビビっていたわけですよ。前提とされる知識のハードルが高そうで。

その上で、以下の知識があると、説明の内容を十分に理解できることでしょう。

データベースサーバの表ロック・行ロックによる問題を説明できること

Java のスレッドの状態を知っていること

アプリケーションサーバのスレッドプールとコネクションプールのリソース枯渇による問題を説明できること

これらを説明せよと言われても、正直できないので。

ただ、私の場合、たまたま身近に #0 に参加した人がいたので聞いてみたところ大丈夫との回答を得たので特攻してきました。

怖くなかった

実際は、お二人のセッションは非常にわかりやすく丁寧でしたし、内容は今の私が知りたいかつ知るべきであろう事柄にとてもはまっていたのも幸いでした。 また、なにより難易度が事前に予想していたよりは高くなかったです。むしろ、ぶっちゃけ私にはちょうどいいけど物足りないとかもっと濃ゆい話がほしいと思う人もいっぱいいるんだろうなと思うくらいでした。

いろふさんがブログで

経験が浅い人にこそ聞いてほしい話なんじゃないでしょうか。この知識がx年前にあれば、あの時もっと楽できたのになぁ、なんて。

という感想を述べられていましたが、まさに私はそれに該当しているのかもしれないです。実際にセッション中にもこの話が近い将来生きてくるのかなぁなんて感じながら話を聞いていました。 主にインフラのスキル的な意味だったり、仕事における立ち位置的な意味で私はまだまだ途上で、それでもこれからはアプリを支えるインフラも含めた上でのサービスというものをいやがおうにも意識していかねばならない立場になりそうなので。

具体的には

  • クラウドでは、アプリの性能が悪いと余計なコストがかかる
  • 本番を想定したデータで性能テストをすることは重要
    • 例えば特定の商品に注文が集中するなどの特別なケースなどもちゃんと考える
  • 安易なスケールアウトは問題の解決にならないばかりか危険
    • 解決のためには問題を正しく分析することが重要
  • 負荷は、変わる(増える)
    • サービスの成長とともに負荷は増大する
      • しかも、それは比例とは限らない
    • 特殊な状況での負荷
      • EC サイトだったらセールとか
  • コストを考えると、スケールアウトだけでなくスケールインについてもよく考えるべき
  • データストアのロックをアプリ側のスケールアウトでは対処できない
  • 非同期は要件次第
  • キャッシュは条件が揃わないとさほど有効な手段とはならない
  • リカバリの範囲(トランザクション単位なのか、テーブル単位なのか、データストア全体なのか)を意識する、影響を最小限に抑えられる適切な範囲で切り戻せるようにする

などなど、ためになるお話がたくさんありました。(独自解釈が入っているかもしれないのでご注意を)

怖くないよ

少なくとも今回の内容は、言われたことをコーディングするだけの人では、たとえそれなりのプログラムがかけたとしても辛いかと思いました。しかし、そのもう少しだけでも先の段階に行っている人なら十分受け止められるのではないかと思いました。 具体的には、自分でコードが書けてアプリケーションの一つや二つは作れます、インフラは正直よくわからんけど作ったアプリケーションを動かす環境を自分で構築するくらいはできます、というレベルの人なら多分大丈夫なのではないかと。ていうか、少なくとも自分はそうです。

なので、もし私のようにハードル高そうだ、うっかり侵入したら穴だらけにされてしまうのではないか、と思って敬遠した人がいたとしたらそんなことはない「かもしれません」よ、とお伝えしたいです。

でも(余談気味に)

とある構文解析ハンズオン に「Java SE 9(Java Platform (JDK) 9)をダウンロード・インストールしておいてください。また、javacにパスを通しておいてください。(中略)誤って、JREのみをダウンロードされる 方がこれまでも一定数見られましたので、注意してください。」と書いてあって、大木こだま師匠ばりに「JDKJRE を間違うなんて、そんなエンジニアおらんやろー」と思って見ていました。 しかし、今回 TDD になぜ一見厳し目のハードルが設けてあるのかの理由を実際に伺ってみて、そういう(レベルと意識の)人が本当ににいるんだな、それは仕方ないな、と思いました・・・。