エンジニア向けイベントをやる時に忘れがちだけどやっておいたほうが良いこと

昨日完全独立コミュニティのイベントと、会社が関係するコミュニティのイベントの connpass が両方空いたのは良いけど、同じことを外向けにも会社向けにも両方書く必要はないよなと思ったのでメモ。

思い出したら随時追記するかも。自明なこととかお金の話は書いてません。

登壇者系

  • 接続端子の共有
    • 基本的に最近だと HDMI / Type C をカバーしておけばトラブルが起こることはない
    • 上記が揃っているならその旨を、その上でほかもカバーしている場合や、不足している場合はその情報も添えて共有しておくと良い
  • セッション後の質疑応答の有無の共有・確認
    • 質問タイムがあるかないかで実質登壇時間が変わってくるため
    • セッションの間に 5 分休憩などがある場合、それが休憩なのか質問用バッファなのかがわからないので明確にする
    • そもそも人によって質疑応答の有無は選択できたほうが良いので確認すると良い
      • 自分が登壇者として経つ場合、正解のないテーマの場合は質疑応答で話しても割と仕方ないので個別で話しましょうとする
      • 逆に正解がある技術的なテーマの場合は公の場で質疑応答があったほうが全体の利になるので質疑応答有りにしてほしい
      • などなどテーマによって変わるため
  • ディスプレイ情報の共有
    • 画面サイズ
      • w1920 or w1280 or w1024 あたりだと思うけれど共有しておく
      • デモする人とかだとこれが重要
    • 画面比率
      • 16:9 だと登壇者としても嬉しいとは思うけれどそれはもう会場によりけりなので……

イベント告知後・イベント前日

  • イベントを開けた時にちゃんと告知する
    • connpass のアナリティクス見るとわかるけど大体エンジニアのイベントは connpass / connpass 通知メール / Twitter 以外で人こない
    • connpass をしっかり書いてしっかりツイートすることが重要
      • しっかり is 17~19 時くらいにイベントページを開く
      • しっかり is 翌日 8 時くらいに RT する
    • イベント開催しますブログを書く場合はセルクマしておく
      • 3 ブクマひとまずいくことを祈る
      • 5 ブクマひとまずいくことも祈る
      • ただこれはイベントに人が来てほしいというより界隈に「イベントやっているぞ」という印象を与える目的が強い
  • イベントの前日あたりでリマインドメールを送る
    • 当日の無断キャンセルを倒すため
      • 特に溢れてる場合は前日のキャンセルによって入れる人が増えて幸せ
      • これを当日にやると「今日いきなり繰り上がってもな……」とキャンセルの嵐になったりする

イベント当日

  • オープニングでハッシュタグの連絡
    • これ忘れると何でつぶやいていいかわからなくなって混乱しがち
    • 汎用イベントタグ && その回限定タグを用意する場合はそれも周知
    • ぶっちゃけ運営者がそのタグでつぶやいてないと意味ないのでちゃんと呟く
  • connpass の受付システムを使う
    • 後から本当に何人きたかはちゃんと残しておくほうが良い
      • 例えば最近 forkwell などスポンサーしてくれる企業があるが開催実績を問われるときもあるので
      • 弱小イベントやるぞと思ってたら思ったよりきた時にエビデンスがあると心強い
    • connpass 本体の受付システムが微妙なので https://connpassport.com/ 使うと便利
      • 俺製
      • ログイン情報いるけどこっちのサーバーでは保持してないので安心
  • 登壇者向けにフィードバックできるシステムを作っておく
    • アンケート（自由入力できると良い）
      • イベント開始時に配っておくとか
      • ovrmrwさん がイベントでやってた QR を配布しちゃうのは手
        • 印刷して貼っておくとその場ですぐ答えてもらえる
    • 基本的に登壇者はコストを払って登壇しているのでフィードバックの仕組みを用意できると良い

イベント後

  • 開催した記録が残るようなコンテンツを作成する
    • 一番省エネどころでいうと Togetter
      • ハッシュタグで拾ってまとめるだけでそれなりになんか開催記録っぽくなる
    • もうちょい真面目にやるならスライド埋め込んだブログとか
      • 大変なので気持ちがあれば
  • connpass のスライド一覧にスライドを登録する
    • 善意の人がやってくれたりするけど大変なので運営者が登録すると良い
    • 参加できなかった人にも届くので次以降の参加のモチベーションになる可能性もある
    • 新規でイベントの登壇依頼をする時に過去の肌感こんな感じですと投げやすいメリットも

【書評】「実践TypeScript」のレビューに携わって

本日、6/26 に発売開始された吉井 健文さんの「実践TypeScript ~ BFFとNext.js&Nuxt.jsの型定義~」の執筆に、レビュアーという形で協力させていただきました。

書籍内に Vue / Nuxt.js における TypeScript の項が存在したためそこからスタートし、それ以外の部分についても一通り読んだ形です。

献本もいただいたので折角なので書評として書籍からうける印象をまとめたいと思います。

どういう本？

間口は広いが完走辛し。本気で TypeScript を書く人のための本

この書籍の印象はこの章題のとおりです。

初学者の人にもわかりやすい入り口を提供していますが、書籍タイトルの「実践TypeScript」の通り、本気で TypeScript を書こう、学ぼうという人のための知識がぎっしりと詰まっています。

古い静的型付けしか知らない人にはぜひ読んでほしい、一番早いスタートダッシュ

たとえばフロントエンド開発者や、LL 言語でのバックエンドのみの経験のあるかたは、そもそも静的型付け言語が教科書的に進めた C や Java だけという人も多いのではないでしょうか。

そういった開発者の方にとっては、例えば「引数の型が違うけれど同名で呼びたいメソッド」があった場合、オーバーロードを駆使して逐次型とメソッドの中身を記述していくようにイメージすると思います。

ですが、教科書的でない実践的な Java や、TypeScript を含むモダンな静的型付け言語では、型を抽象化して扱うことのできる Generics という機能があったりします。 「例えば任意の型を受け取って、その上でフラグ情報を付与して返す関数を作りたい」みたいな抽象的な要件にも、 TypeScript は以下のようなコードで応えてくれます。

function withExistFlag<T>(v: T): (T & { exist: boolean }) {
    const value = {
        ...v,
        exist: true
    }
    return value
}

type User = {
    id: number
    name: string
}

const user: User = {
    id: 1,
    name: 'potato4d'
}

console.log(
    withExistFlag(user)
)

www.typescriptlang.org

もしこういった機能に馴染みのない開発者のかたの場合は、この書籍はこのような新しい型の概念を一気にインプットできる、スタートダッシュの強い味方になるはずです。

高度な型を学ぶためには強い意志が必要

一方で、 Conditional Types による複雑な型の表現（TypeScript の読み書きに慣れている人ならば、初学者につらいことはわかるはずです）など、 Generics のような簡単な構文ではなく、読み書き両方にある程度の慣れを表現する技術もたくさん出てきます。

TypeScript には any という、全ての型を許容する甘い誘惑があります。軽く TypeScript を触ったことがあるというかたの場合、特にそうしてしまうことの楽さを体験してしまっていることだと思います。

そういった中、この一冊はそういった妥協は一切せず、ただどこまでも型を正しくアノテーションしていくことに専念しています。

もしかしたら途中で一旦休みたくなるかもしれません。そういったときは、少し時間をおいて、現場で導入を進めてみて、それから必要になったときにこの書籍にまた戻ってくる。そういった読み方を進めるのも一つの手だと思います。

最終的にはこの書籍に存在する知識は全て必要となるはずですが、TypeScript 自身がそうであるように、少しずつ改善していくのも一つの手です。

界隈における TypeScript の盛り上がりとこれから

まだ TypeScript を学ばないで良いと考えているかたも、これからは事情が変わるかもしれません。

グローバルな事例では、今年リリースを控えている Vue.js 3.0 は TypeScript で全てが書き直されます。おそらく日本で一番使われているであろう JavaScript フレームワークが、 TypeScript の世界を中心として回るように変化します。

また、ローカルの事例では、 TypeScript のコミュニティイベントである TypeScript meetup vol.1 は、参加枠 130 に対して、執筆時点で 600 をこえる参加者が控えている状況であり、国内におけるプレゼンスも確実に高まりつつあります。

もちろんこの世の全てのプロジェクトが TypeScript になるということはありませんが、 SPA 開発におけるデファクトとして変化していく未来へは、少しずつ、しかしながら確実に近づいています。

そんな時代の先端に追いつくきっかけにもなる一冊だと感じました。

おわりに

この本をレビューさせてもらったとき、これは TypeScript を愛する人が TypeScript を学びたい人のために送る、 TypeScript のための本であるということを強く感じました。

フレームワークの事例を載せながらもあくまでも主眼は TypeScript であり、そこで得られる型の概念や考え方は、きっと数年後に React や Vue がなくなったとしてももちこせる「資産」ともいえる技術と知識であることをあらためて実感。この書籍が本当にフォーカスしたいのは、 BFF、特に Nuxt という型が複雑になりやすい技術を倒すべき課題として、TypeScript という武器の魅力をいかに表現するかであり、そこを吉井さんは伝えたかったのではないかというのが、私の中での所感です。

これからも「フロントエンドエンジニア」として仕事を続けていきたい人、そして自社の「フロントエンド」の開発組織自体を強く意識したい人、どちらのケースにも大きく貢献できる著者渾身の一冊ですので、ぜひ一度読んでみることをおすすめします。

私は部署向けにも追加で発注しました。