自分語り:ビッグバンドに入団した話

以前、イントロという店にジャズの演奏をしに、脚繁く通い続けていることについて書いた。あれから4ヶ月弱、今度はビッグバンドに入団することになったので、その経緯を書き残しておく。

イントロの頻度は落ちたものの、相変わらず毎週どこかのセッションには通い続けていて、アドリブでこなすことにはすっかり慣れてきた(それこそロストをすることも、急にアドリブソロを振られて慌てふためくことも滅多になくなった)。今年に入ってからは褒められることがあったり、逆にダメだしを食らうこともあったりと一進一退。自分の思い描く音楽的な成長とは、いつまで経っても程遠い。

セッション演奏に感じる課題として、その場の構成メンバー・選曲という仕組み上、数こそこなせても1曲1曲を深められない点がある。しかし根本的には、飽きるほど練習したフレーズですら客前に立つと頭に浮かびもしない自分の技量では、良い演奏(それも自分基準)の再現性は著しく低いので、仮に満足いく演奏ができたとしても、それを振り返って何が奏功したのかは分析しづらい(大抵はプロの共演者が底上げしてくれたことによる錯覚でしかなかったりする)。そんなフラストレーションの打開策のひとつとして、去年末から検討していたのがビッグバンドへの入団だった。

ビッグバンドで活動するアマチュアは決して珍しくないので、ジャズをやっていると自然と話を聞く機会はあるし、時には誘われることもある。が、そもそも大編成のバンドに興味はなかったし(吹奏楽みたいだし)、週末月2回の練習のために定期かつ長期で予定をおさえなければならないこともハードルが高く、現実的に検討したことはこれまでなかった。

が、今の自分の状況と照らし合わせてみると、同じバンドメンバーと、同じセットリストを本番演奏に向けて繰り返し練習し、曲そのものやジャズへの理解を深める場としては当然魅力的だし、大きなアンサンブルの中に身を置くことで、曲に対する分析や自パートに対する客観視をいちメンバーとして求められ(多分)、結果として音楽的に成長できるのではないか、、と捉え直しはじめていた。

そもそもジャムセッションで演奏するようなモダンジャズの歴史的源流には、ビッグバンドやスイングジャズがあるという理解なので、ビッグバンドを知ることとジャズを知ることとは、切っても切り離せないという気づきもあった。

“自分語り:ビッグバンドに入団した話” の続きを読む

聴講メモ:CA.swift #22 〜Swiftの進化を活かした技術基盤への挑戦〜

設計実装のみならず技術浸透のための取り組みも含めて解像度高く紹介されており、どのプレゼンも非常に濃い内容だった。ひとつめのTCAに関するプレゼンは、すでに自社プロダクトにTCAを導入している身としては復習要素もありつつ、Reducerの採用/非採用について感覚的だった部分が言語化されていたため、学びになった。

イベントページ:https://cyberagent.connpass.com/event/342952/


The Composable Architecture (TCA) を用いたAmebaのリアーキテクチャ

@devdazy さん

  • 従来:MVVM + RxSwift、VMは状態持たずデータを流すハブだけ
  • 課題:ロジックの複雑さ。モデル肥大化、可読性低下、保守性拡張性の低下とともに開発速度が低下
  • VM が状態を保持せず SwiftUI と相性悪い、RxSwift 依存が Concurrency と相性悪
  • TCA の概要
  • メリット・デメリット
    • Good:ロジックが明確になり、見通しが良くなる
      • すべてのイベントが列挙される。非同期処理のEffectで状態更新できないため、成功失敗を網羅的に書かざるを得ない
      • テストの網羅生にもつながる
      • e.g. 読み込みだけでなく、読み込み完了後の処理もテスト書かなければ失敗する
    • Good:画面遷移をシームレスに移行できる
      • SwiftUI → UIViewControllerへの遷移
      • TCA x UIKitでは、ほとんど SwiftUI と同じインターフェイスで実現できる
    • Good:ロジック分割が簡単にできる
      • ロジックである Reducer を別の Reducer に分割・合成したりできる
      • Action / State は親からも観測できる
    • Bad:学習コストが高い
      • フレームワーク丸々ひとつに対する理解が必要
      • TCA独自の記法
      • 例を作り、マイグレーションドキュメントを作り、テンプレ機能を活用する
    • Bad:パフォーマンスが最良ではない
      • Reducer を分割しやすい反面、不要な View にも Reducerをつけがち。(Action送る処理は負荷が高い)
      • Action を極力減らすよう吟味が必要
      • View 側での処理完結も選択肢に
    • Bad:Point Freeに依存
      • RxSwiftの例に同じ
    • 記法のブレがかなり抑制されるのは Good

Q&A

  • 分割粒度について:画面の量にもよるが、スクロールしない画面では基本的に1画面 1 Reducer だが、セクション持つような単位ではセクションごとに分割する
  • ロジック持たない限りは Reducer 持たせない(ボタン置いてあるだけとか)、通信して自身を更新するばあいは Reducer を持たせる

SwiftUI導入から1年、SwiftUI導入とVueFluxライクな状態管理

@TyrionJP さん

“聴講メモ:CA.swift #22 〜Swiftの進化を活かした技術基盤への挑戦〜” の続きを読む