PHPerKaigi 2022 やっぱオフライン楽しいね

はじめに

今年も無事にPHPerKaigi 2022 開催できたこと、本当にありがとうございます！
なんと今年はオフラインと、オンラインのハイブリット開催でした！

今回も PHPerKaigi 2021 に引き続き、コアスタッフとして参加させていただきました

オフライン楽しいですね

そしてオフラインはやっぱり楽しいですね！

久しぶりに合った方と近況を雑談したり、
初めて参加くれている方とも話せてとても楽しいものです

ベテラン勢がいつもの感じで、フリースペースで雑談してたり、
みんな血眼になってトークンを探しているを見ると、いつもの感じだなーとほっとしました

↓PHPerの刻印押してドヤって自分です

アンカンファレンス 今年も無限LTをしました

実は2019年から、毎年恒例で無限LTという狂気のLT回を実施しているんですが、
2022年の今年も、現地でアンカンファレンスを実施することができました！

開始当初は 参加表明してくれたのは5人だったのですが、 LTをしているうちに飛び入りで参加したいと手を上げてくれるひとが増え、最終的には10名の方がLTをしてくれました

無限LTにテーマの縛りありません、自分は最近発表された、Lambda Function URLs の話しを当日作って話ました。
他にも、notion、kotlin、Dockerの壊し方、高専、などなど今年もバラエティー豊かでとても面白かったです！

LTしてくれたみなさん、LTを聞いてくれたみなさんありがとうございました！
ぜひ来年もやりたいので、みなさんお待ちしております

無限LTの説明
speakerdeck.com

感想

やっぱオフラインは最高でした、設営等の会場準備は大変でしたが、
久しぶりの再開や、新しい出会いなどオンラインならではの楽しさをたくさん味わえました。

来年あるならぜひ、懇親会でお酒を飲みながら話したいなー

PHPerKaigi 2021 ガヤ担当の感想

まずは

今年も無事にPHPerKaigi 2021 開催できたこと、本当にありがとうございます！

スタッフとして

PHPerKaigi 2020 に引き続き、コアスタッフとして参加させていただきました。 当日はTrack-A の担当として、配信の設定やAsk The Speaker のがや(ファシリテーション)をしてました。

Ask The Speaker ・・・登壇後にスピーカー方へ質問や感想を視聴者が言う場です。 今回はDiscord で実施しました。

Ask The Speaker 楽しかった

3日間 Ask The Speaker をしましたが、配信会場的に1部屋しかなく、
他の音が入らないように部屋の隅っこのほうでブツブツPCに喋っている状況でした。

Ask The Speakerは基本的は視聴者方がスピーカーへ質問や感想を述べる場ですが、慣れない状況やオンラインということもあり、
最初に質問等をするにはややハードルが上がっている状況だったので、
取っ掛かりになるように、自分が積極的に質問やディスカッションをするように心がけました。

話が盛り上がると質問が活発になったり、別の参加者から補足事項が出てき新しい知見があったり、
本来カンファレンスの懇親会でするようなざっくばらんな話をこの場でできたのはとても楽しい体験でした。

スピーカー方からも、「Ask The Speaker 素敵な体験でした」、「Ask The Speaker で新しい発見がありました」等好意的な意見を頂いたので、部屋の隅っこで3日間喋り倒した甲斐がありました。

アンカンファレンス 今年も無限LTをした

実は2019年から、毎年恒例で無限LTという狂気のLT回を実施しているんですが、 今年もおかしょい (@okashoi) | Twitterが 発起人となり実施しました。

fortee.jp

突発でしたが、20人ぐらい参加してくれて、7人LTが実施できました。
参加者のみなさんありがとうございました！

自分は、技術的負債を返し続ける取り組み というタイトルで発表しました。
当日におかしょいさんから依頼があったのでスタッフ業の合間を縫ってこそこそ作ってました。

18:20~ 開催だったためスタッフは解散し部屋を追い出され、
途方にくれた結果、近くの喫茶店に入り隅っこでコソコソ話してました。

無限LTの説明
speakerdeck.com

感想

今年も最高な PHPerKaigi でした！

素晴らしいセッションもたくさん聞けて、明日からのモチベーションをかなりもらいました！

オンラインということもあり、多くの人とはコミュニケーションが取れず、ちょっとさみしい気持ちもありますが、とても楽しかったです。

来年は懇親会でみんなで酒を飲みたいな！！！！！

Vue.js $emit 使わないで props で method 渡したほうが良くない？

概要

Vue.js で 親コンポーネントの method 実行させたい場合、$emit 使ってイベントを発火させるより、
props に method をコールバックとして登録しておいて実行させたほうが以下のメリット上げられるので「こっちのほうが良くね？」って話です

• props の成約をつけられる(requird, etc)
• $emit の文字列を管理しなくていい
• IDEで補完が効く

実際のコード

ボタン押したらカウントアップしていくようなやつ

呼び出し側の親コンポーネント

<template>
    <div>
        <div>{{ count }}</div>
        <child
                :handle-add-number="addCount"
                @addNumber="addCount"
        />
    </div>
</template>

<script>
    import child from "./child";

    export default {
        components: {child},
        data: () => ({
            count: 0
        }),
        methods: {
            addCount(number) {
                return this.count += number
            }
        }
    }
</script>

子コンポーネント

<template>
    <button @click="countUpProps()">count up props</button>
    <button @click="countUpEmit()">count up emit</button>
</template>

<script>
    export default {
        props: {
            handleAddNumber: {
                type: Function,
                required: true // required をつけて必須に
            }
        },
        methods: {
            // Prop で渡した function を実行
            countUpProps() {
                this.handleAddNumber(1)
            },
            // emit を使って function を実行
            countUpEmit() {
                // emit の event は 文字列で管理
                this.$emit('addNumber', 1)
            }
        }
    }
</script>

props で定義しておけばこんなふうにIDEで補完が効きます

こんなかんじで、props を使うと、
requird で縛れて、method の渡し忘れを防げたり、
$emit の文字列管理しなくていいかつ、IDEで補完が効くのでその分typo が防げる という点で開発しやすくなるかなと思います。

TS でやると

Vue も Vue3 から、TypeScript を正式にサポートということで未来を見据えて、
同じ処理を Vue3 + TypeScript で書いてみます

呼び出し側の親コンポーネント

<template>
    <div>
        <p>{{ count }}</p>
        <child
                :handle-add-num="addNumber"
                @addNumber="addNumber"
        />

    </div>
</template>

<script lang="ts">
    import {defineComponent, ref} from 'vue';
    import child from "./child.vue";
    import AddNumberInterface from "../types/AddNumberInterface"; //function の Interface

    export default defineComponent({
        components: {
            child
        },
        setup() {

            const count = ref<number>(0)

            //Interface を指定して関数を定義
            const addNumber: AddNumberInterface = (num: number) => {
                return count.value += num
            }

            return {
                //data
                count,

                //function
                addNumber
            }
        }
    })
</script>

props で渡す関数の Interface 定義

export default interface AddNumberInterface {
    (num: number): number
}

子コンポーネント

<template>
    <div>
        <button @click="countUpProps()">count up props</button>
        <button @click="countUpEmit()">count up emit</button>
    </div>

</template>

<script lang="ts">
    import { PropType, defineComponent , SetupContext} from 'vue';
    import AddNumberInterface from "../types/AddNumberInterface";

    type Props = {
        handleAddNum: AddNumberInterface; //Prop の Interface を定義
    }

    export default defineComponent({
        props: {
            handleAddNum: {
                // PropType を使って Prop の type に使いたい関数のInterface を指定
                type: Function as PropType<AddNumberInterface>,
                required: true
            }
        },
        setup(props: Props, context: SetupContext) {
            const countUpProps = () => {
                props.handleAddNum(1)
            }

            const countUpEmit = () => {
                context.emit('addNumber', 1)
            }

            return {
                countUpProps,
                countUpEmit,
            }
        }
    })
</script>

PropType(これは Vue2.6 からあったはず?) と TypeScript を使うことにより、props の Typeを独自のInterfaceに変更することができ、
どんな functionを渡せばいいか、明示することができました！
「Vue ぽくない」とか言われそうですが、型 という概念が好きな私にとっては、とても書きやすく感じました。

まとめ

公式のリファレンスや、色々な書籍でもVueで親のmethod を実行した場合は、$emit を使う、
というのは当たり前のように記載されていますが、実際書き比べてみたり、実際のコードを運用してみた観点からしても、
props で method を渡したほが、明示的かつケアレスミスを減らすことができて、とても良いと感じています。
$emit を使う意義を感じなくなってきているので、$emit を使う理由や、もっとよい方法があれば教えてもらえるとありがたいです。
未来のことはわかりませんが、Vue3 からは TypeScript サポートされより型を意識した開発をするように今後なっていくのだとしたら、 上記のような書き方はさらに恩恵を受けそうだなと思っています。

オンライン/オフライン勉強会を運営してみて思うこと

オンライン勉強会の運営してます

昨今の事情もあり、エンジニアの勉強会もオンラインで開催されることが増え、
自分自身もいくつかのオンラインイベントの運営に携わっています。

nyamucoro.connpass.com

study-in-virtual.connpass.com

オフラインとオンラインではやっぱり勝手が違うので、
運絵する上でのメリット、デメリットも違ってきます。
そんなことを運営の目線で語ってみようと思います。

ちなみにcluster ってVR空間で主にイベントしています。

cluster.mu

オフライン勉強会のメリット/デメリット

メリット

• 通話アプリがあれば運営がオンラインでも普通に運営できる
  • 以外といける
  • discord 使ってます
• 会場を確保しなくていい
  • オンラインでいいので実際の場所確保する必要がないのは運営としてはかなり楽
  • 会社等のコネがなければこの時点で積むことも
• 懇親会用の料理や、お酒の手配をしなくていい
  • こちら手配も面倒ですが、参加費をとっている場合当日キャンセルは運営が負担する必要があったりする
• 参加場所を選ばない
  • 会場までいかなくていい、場所を選ばない
  • 諸事情で、家ではなく出先で運営作業をする必要がありましが、PCがあれば問題なくできました
• 当日キャンセルが少ない
  • 移動の手間がないため？か少ない
  • (わかる当日行きたくなくなることあるよね)
• 気軽に参加してもらえる(やっぱり参加人数多い)
  • Live配信等もあるので、参加ハードルはオンラインより圧倒的に低いと思われる
  • 東京以外の方の多く参加してくれていてとても嬉しいです
• 運営としてはやるたびに発見があっておもしろい
  • 問題も色々あるけどね

デメリット

• 懇親会がない
  • 懇親会の準備は面倒だけど、こっちも本編と同じくらい大事だと思っています
• YoutubeLive等の配信にはそこそこスペックのPCが必要
• 参加や、登壇者環境はそれぞれ違う
  • クライアント起因によるマイクトラブルや、映像トラブルはそこそこある
• 遭遇したことがないトラブルが起こる
  • ナレッジ不足はいなめない
  • 都度対応することがあるので勘弁して
  • 例:) 確認不足で用意したオフラインの会場が突如強制終了する

前提条件

後出しで前提条件を語りますが、
前提として運営の連携がオンラインでも取れるような信頼があること
ということが大事だと思っています。
現在参加している勉強会の運営メンバーは、基本的にオフラインのイベントで一緒に運営として参加したことがあるメンバーが多めです。
オンラインのコミュニケーションは基本、ある程度の信頼があるから成り立つものだと思っているので、初対面とかでいきなりオンラインで運営とかちょっとむずかしいのか？と思っています。

日々改善しています

ナレッジ不足はいかんせんありますが、運営でノウハウをためて
いろんな人に使ってもらおうと公開していますので、ぜひ見てもらえると嬉しいです github.com

まとめ

オンラインイベントは、オフラインイベント比べると運営負担は少ないし、
開催ハードルも若干低いのかなと感じます。 もっといろんなかたちでオフラインの勉強会が増えてほしいとも思います。

けど、それぞれいいとこもあるのでやっぱりオフラインのイベントもしたいなー、と思う今日このごろです。