現在時刻をハイジャックする是非について

前の記事に関連して

結論、一般論としてはケース場合ケースですね、というところに落ち着くんだけど、上述のような問題点を理解した上で、個別のケースにおいては「今回雑でいいからXXで」「じゃあそれで」みたいに判断できると良いですよね。こちらからは以上です。

Joda-Timeで現在時刻をハイジャックする

Joda-Timeは便利ですが、時間を扱うプログラムあるあるとして、「ユニットテストとかどうやって書けばええんや」ってのがあります。

Rubyならtimecopなどを利用するところですが、joda-timesはDateTimeUtilsに自前で現在日時をハイジャックする機能を持っています。

Joda-Time 2.9.9 API

setCurrentMillisFixedsetCurrentMillisDifferenceがそれですね。便利ですね。

(Java8のDate-Time APIが出てきた今joda-timeがどれだけ必要とされるのかというのはまた別の話なんで置いておきます)

ジェネリックガルボ

タイトルはブラックサンダーのことです。いや、言いたいことはわかる。正直ガルボブラックサンダーはだいぶ違う。チョコレートの中にココアクッキーが入っていれば実質同じみたいな雑な判断やめろ!!って話である。

ところで、なぜブラックサンダーの話かというと、tmrrさんという方の「ブラックサンダー!」という楽曲について、編曲、打ち込み、ギター演奏、男声パートのお手伝いをした話をしたいからです。

きっかけ

きっかけは以下のツイートでした。

tmrrさんとは荻窪にある「アルカフェ」というアコースティックライブバーで行われているオープンマイクというイベントでお知り合いになりました。そのtmrrさんがブラックサンダーの曲を作ったと聞いて、軽い気持ちで「アレンジしたいな」と発言したのがきっかけです。なぜならぼくはブラックサンダーが好きだから……。安いのにおいしくて食べると幸せな気持ちになるブラックサンダーがぼくのこころをとらえて離さないから……。

しかし、その「軽い気持ち」はデモ音源と楽譜を頂いた瞬間に「本気」にかわることになります。

軽い気持ちが「本気」に変わる

頂いた楽譜とデモ音源は、メロディー譜と歌詞、それに一部仮のコードが振られた状態のものでした。これを受け取ってざっとさらった時点で、ぼくの気持ちは、「軽い気持ち」から「あっこれは本気やるべきだ」に急激に変化していました。それくらい良いものだったのです。

歌詞の面から

本人に確認したわけではないので、どこまでtmrrさんの意図を汲めているのかはわかりませんが、少なくともわたしは頂いたデモの歌詞の書かれ方から、あふれるユーモアと、単なるユーモアでは終わらない「表現されるべきなにか」を感じました。

ブラックサンダー」は、言ってしまえば単なる駄菓子でしかありません(いや美味しいけれども)。それをあえて題材に選んでいる時点で、この楽曲の表現はかなり「力が抜けたユーモラスなもの」となっています。

しかしその一方で、(一聴すればわかるとおり)この楽曲は単に「ブラックサンダーのことをユーモラスに歌った歌」ではありません。注意深く聴けば、「ブラックサンダーが象徴する性質を持った誰かや何か、あるいはそれに惹かれるということ」を間接的に叙情、あるいは叙述していることが見て取れるでしょう。

ぼくはこういう手法に対して一種の信頼感を持っています。というのも、言葉を使うというのは常に無力感と向き合うことである、という気持ちを持っているからです。

ぼくたちの言葉は、あまりに明瞭で、説明的で、機能的で、端的です。明瞭で、説明的で、機能的で、端的な言葉を使って何かを語ってしまった途端に、言葉で表されてしまったその対象は「わかりやすい形に切り分けられてパッケージ化されたなにか」に堕してしまいます。たとえば、「会いたい」と言ってしまったら、それは「会いたい」という感情として切り取られ、理解されやすいパッケージに包まれてしまいます。「会いたい」という言葉の後ろには、おそらく、膨大な整理されていない感情や様々な過去などが未分化のままに横たわっているはずなのに。

それを避けるためには、対象について「直接語る」ことを丁寧に回避しながらも、その周りに共起するなにかに仮託して、間接的に語る必要があります。直接語れば常に毀損されてしまう「主観」は、ユーモアや俯瞰を取り入れたりして、とても迂遠な形で、そのまわりをウロウロとうろつくようなやり方でしか表現され得ない、とぼくは考えています。

話を戻すと、この「ブラックサンダー!」という楽曲を一聴したとき、ぼくは「あ、これは"軽い"形をしているけど、本気で取り組むべきものだ」と思ったのでした。それは、この楽曲がまさに「ユーモアとマジの間」「俯瞰と主観の狭間」にうまくボールを落としているように見えたからです(繰り返しになりますが、あくまでこれはぼくが勝手にそう感じたというだけで、どれだけtmrrさんの意図と一致しているかはわかりませんが)。

音楽的な面から

いくら歌詞が優れていたところで、音楽的に面白くなければ音楽はおもしろくありません。デモからは、音楽的にもぼくが「これは良いものだ!!!」と感じる点がありました。パッと聴いただけで、

  • 要所要所に出てくるブルーノート
  • Bメロ前半の半音で下がっていくベースライン
  • そこから続く、男声パートと女性パートが入り乱れる2拍3連フレーズ

が、気に入りました。全体的にポップでありながら、ちょっと「不安定さ」を感じさせるこのような要素が、前述した「ユーモアに仮託された、ユーモアからはみ出ていくなにか」に説得力を与えているのです。これはいい。メロディーとベースラインからも、「基本的には快活なユーモアにあふれているのにひょいとその裏に潜んでいる"表現されるべきなにか"」が顔を覗かせる。名曲じゃないか。

というわけで、結構気合をいれて編曲作業をさせていただきました。

成果物

soundcloud.com

出来上がったのがこちらです。デモ時点で素晴らしかった上述の内容をなるべく活かす形にまとめ上げることを意識して編曲、打ち込み、演奏をしてみました。

ぼく自身はあまり「イチから創作物を作ること」が得意ではないのですが、作詞作曲家として0から1を作り上げる能力のあるひとを、編曲や演奏でサポートするのはとても楽しくやりがいのあることですね。今回は本当に楽しく編曲をさせていただきました。また機会があったらやりましょう。しかしこうして聴いてみると、男声ボーカルの下手さが際立ちますね!永遠の課題です。

クソコードを別の言葉に言い換えるのあんまり意味なくて

それよりも互いに信頼関係を築くほうが大切だと思う。

たとえばおなじ「ばか」という言葉が親密な関係で発せられるときとそうでないときに発せられるので意味が180度かわるように。

「このような言い方は避けましょう」みたいな感じで言葉狩りするよりも、「ここがクソコードだから直そうぜ」「そうしようぜ」と言い合える関係を目指したいです、すくなくともぼくは。人間関係はとてもむずかしいね

hayajoさんとの思い出

hayajoさんがはてなに入社されたそうです!

http://hayajo.hatenablog.jp/entry/2017/11/05/055756

ところで、hayajo さんというエンジニアと新潟で出会ったのは、ぼくが新潟に引っ越してすぐだった。2011年のことだ。そのときの記録は http://d.hatena.ne.jp/nkgt_chkonk/20110804/1312460118 に書いてある。この記事はエモくてちょっと面映いんだけど、まあ、当時の素直な気持ちがよく出ている文章だな、と改めて他人事のように思ったりする。

新潟にいる間、Niigata.pmを通じて @civic さんの主催するNDSという開発者コミュニティに非常にお世話になった。東京に比べるとやっぱりプログラマ人口がそもそも少なすぎる新潟で、ぼくがプログラマとして腐らず、発信し続けられたのはNDSのひとたちがぼくにたくさん刺激を与えてくれていたからだ。

その中でも、 @hayajo さんはひときわぼくに刺激を与えてくれたエンジニアだ。

なんといっても、決して環境に恵まれていたわけではない中で(そりゃ東京のスターエンジニアたちが集まるところと比べたら、新潟で随一環境がいいところであったとしても「環境に恵まれている」とはいえない)、ストイックに自分が興味のあること、自分のやるべきことについて深く学んでいく姿勢がとにかくかっこよかった。そして、それらの成果を対外的に発表するときにも、決して必要以上に自分を大きく見せようとはせず、淡々と、でもその内側にすごい熱量をもって発表していく姿は、自分にとっては「憧れ」のひとことだ。

そういえば、もうひとつ。hayajoさんは決して「若いエンジニア」ではない。年齢的にはむしろこの界隈としてはかなり高めの層だと言えると思う。けど、hayajoさんはそんなこと関係なく、貪欲に学び、そして挑戦していく。そういう姿を見ていると「エンジニア35歳定年説とは……」という気持ちになれるし、学ぶ気持ちや挑戦する気持ちがあるかぎり人間はいくらでも大きな舞台に立てるんだ、年齢のことなんて言い訳にならない、ということを考えさせられる。ほんとうに尊敬すべき姿勢だし、心からかっこいいと思う。ありていな言葉で言えば、「web系エンジニアとして年を重ねる」ということについて、hayajoさんがぼくにとってはひとつのロールモデルになっている、といえる。

はてな入社おめでとうございます。今後さらに大きな舞台でぼくの目標でありつづけてください。

ScalaMatsuri2018のトークに応募した

Building native apps with Scala.jsというタイトルでScalaMatsturi2018に応募しました。

2018.scalamatsuri.org

ここのところ、GUIアプリケーションをScalaで記述したいという素朴なScala愛を大切にしたいという思いから、Scala.jsとJSプラットフォームを利用してGUIアプリケーションを書くという試みをしてきました。「Scala.jsでGUI」とパッときいたときの「えっまじで?冗談じゃなくて?」という印象に反し、それらは一定の成果を挙げているという実感があります。

このトークでは、それらの経験からJSプラットフォームのツールキットを利用してScala.jsでGUIアプリケーションを記述する勘所について共有したいと思っています。採択には、SNSなどでのシェア数が考慮されるとのことなので、応援してもいいよって方や聴きたいと思ってくれる方はがんがんシェアをおねがいします!!!!

2018.scalamatsuri.org

2018.scalamatsuri.org

2018.scalamatsuri.org

2018.scalamatsuri.org

ReactNative + Scala.jsファーストインプレッション

ちょっと訳あって仕事の一貫としてReactNative + Scala.js の技術検証している。あたまには「全部C#」のライフベアさんの事例がある。弊社、最近メンバー増えてきたけどまだこの規模だと「あのひとはあれができるけどあのひとはこれができなくて」がボトルネックになりうるので、 筋の良い 共通の基盤技術を持つという選択肢のひとつとして検証したいというのがモチベーションとしてある。というわけで、

  • Reduxは使ってない。「Scalaを基盤技術にしてどこまでできるのか」が検証の目的だから。
  • Vue.js + Scala.jsでElectronアプリ作ったときと同じ感じで、MVWhateverのVとWhateverの部分は素直にJSで書いている。分厚いMをScalaで書き、UIだけReactNativeで記述する。

以下ファーストインプレッション

  • pros
    • Vue.js + Scala.jsでいろいろやったときと同程度にはドメイン層はきれいにScalaで書けている。よいと思う
    • 「Viewの定義の書き方がHTMLじゃくて各プラットフォームのUIコンポーネントの抽象」ってのは、HTMLでGUIアプリ作ろうとする筋の悪さと比べたら圧倒的に筋が良いという印象
    • 注意深く設計することで、少なくともモデル層以下はScalaのコードをAndroidiOSで共有できそうな実感がある
    • Scalaビジネスロジック書くマンとRNでネイティブよりの部分書くマンの分業はかなり現実的にできるなという印象
      • それってファウラー先生が言ってたPDSのメリットのひとつだよね
  • cons
    • ReactNativeは比較的簡単にネイティブに降りられるんだなということはわかった。が、普通にJSで書いていても、インフラストラクチャ層では「JS -> ネイティブのバインディングを自分で書く」という必要がある(コレ自体には納得感があり、筋の良さすら感じる)上に、それをScala.jsから利用するために「Scala -> JSのfacadeも自分で書く」あるいは「RNで使われるライブラリへのfacadeも自分で書く」というのは結構発生する雰囲気で、そこは正直だるさ感じるのがある
    • そもそもswiftとかKotlinで書けばよくね?
    • ていうかScala.jsもReactNativeも「枯れた技術」から遠すぎるよね
    • prosと鏡合わせだけど、HTMLの知識役に立たん。むしろネイティブの知識が役立つ

という感じです。

わたしは「クライアントサイドのアプリケーションの寿命はサーバーサイドのアプリケーションの寿命より短い」ということを信じているので、クライアントサイドでは「枯れた技術」にこだわる必要ないのではないかという立場(異論反論あろうとは思います)なんだけど、そういう立場であってもプロダクション投入に対してはかなり慎重にならざるを得ないなこれ(頑張ればなんとかなるけどその頑張りはペイするか…?)って感じです。とはいえ、夢はあると思います、Scala.js + ReactNative。様々なプラットフォームに、少ない人間で対応していくという目的に対して、Redux + JSによるマルチプラットフォームを基盤技術にするよりずっと筋がいいという感じがしているのもたしかです(動的型付け言語で複雑な状態管理をするとか正気か!?)。一方、「たとえ合理的だったとして、そんなニッチな技術選択して誰が採用できると言うのだ……」という問題はある。

こちらからは以上です。