PHPerKaigi 2023 にスタッフ・スピーカーとして参加してきました。
はじめに
今年も春の風物詩、PHPerKaigiに参加してきました!
- オフラインは楽しいですね!
- コロナ前の活気が戻ってきた気がしました!
- 今年も去年に引き続きコアスタッフしてきました!
- 今年は登壇もしてきました!
登壇
「データの民主化はじめました」というタイトルで発表させていただきました。
内容としては、組織のデータ活用に対する挫折と、そこから得られた学び、その学びを活かす取り組みについてお話させていただきました。
(PHPの内容は1ミリも入っていませんw)
正直発表前は、「興味ある人いるのかこれ?」、「やばい技術に関する内容ほとんどない...」 などと思って、前日などはすごくソワソワしてました。
が、発表前日の前夜祭にて発表の事前収録を見てくれていたuzullaさんに、「感動したよ」と言われとても自信になり、当日は自信を持って発表できたと思います。
ありがとうございました!
発表後は、スタッフとしてふらふらしていると数人の方に、
「とてもよかったです!」、「発表ありがとうございます!」、「参考になります!」など、
直接声かけいただけてとても嬉しかったです。 オフライン最高です。
内容的にもかなりニッチな内容でしたが、同じような悩みを抱いている方の参考になったようで、発表してよかったなと思いました。
アンカンファレンス
毎年恒例、今年で多分5年連続ぐらいで無限LTという、「時間5分」、「テーマなし」、「飛び込み歓迎」のLT大会をしていて、 今年も開催しました。
事前に数人声をかけましたが、飛び込みでも多くの人が参加してくれて、8人の方が喋ってくれました。
内容は、「カンファレンスで友達の作り方」、「ChatGPTで彼女の作り方」、「マイクロサービスアーキテクチャ」、「北海道の魅力」、etc
バラエティに富んでいてとても面白かったです。
参加していただいた皆様ありがとうございました。
まとめ
コロナ前のカンファレンスの感じが少しづつ戻ってきた感じがして良かったです。
スタッフ業でバタバタしていて、他の人発表がほとんど聞けなかったのが心残りですが、楽しい3日間でした。
ありがとうございました!
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が 発起人となり実施しました。
突発でしたが、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 サポートされより型を意識した開発をするように今後なっていくのだとしたら、
上記のような書き方はさらに恩恵を受けそうだなと思っています。
オンライン/オフライン勉強会を運営してみて思うこと
オンライン勉強会の運営してます
昨今の事情もあり、エンジニアの勉強会もオンラインで開催されることが増え、
自分自身もいくつかのオンラインイベントの運営に携わっています。
オフラインとオンラインではやっぱり勝手が違うので、
運絵する上でのメリット、デメリットも違ってきます。
そんなことを運営の目線で語ってみようと思います。
ちなみにcluster ってVR空間で主にイベントしています。
オフライン勉強会のメリット/デメリット
メリット
- 通話アプリがあれば運営がオンラインでも普通に運営できる
- 以外といける
- discord 使ってます
- 会場を確保しなくていい
- オンラインでいいので実際の場所確保する必要がないのは運営としてはかなり楽
- 会社等のコネがなければこの時点で積むことも
- 懇親会用の料理や、お酒の手配をしなくていい
- こちら手配も面倒ですが、参加費をとっている場合当日キャンセルは運営が負担する必要があったりする
- 参加場所を選ばない
- 会場までいかなくていい、場所を選ばない
- 諸事情で、家ではなく出先で運営作業をする必要がありましが、PCがあれば問題なくできました
- 当日キャンセルが少ない
- 移動の手間がないため?か少ない
- (わかる当日行きたくなくなることあるよね)
- 気軽に参加してもらえる(やっぱり参加人数多い)
- Live配信等もあるので、参加ハードルはオンラインより圧倒的に低いと思われる
- 東京以外の方の多く参加してくれていてとても嬉しいです
- 運営としてはやるたびに発見があっておもしろい
- 問題も色々あるけどね
デメリット
- 懇親会がない
- 懇親会の準備は面倒だけど、こっちも本編と同じくらい大事だと思っています
- YoutubeLive等の配信にはそこそこスペックのPCが必要
- 参加や、登壇者環境はそれぞれ違う
- クライアント起因によるマイクトラブルや、映像トラブルはそこそこある
- 遭遇したことがないトラブルが起こる
- ナレッジ不足はいなめない
- 都度対応することがあるので勘弁して
- 例:) 確認不足で用意したオフラインの会場が突如強制終了する
前提条件
後出しで前提条件を語りますが、
前提として運営の連携がオンラインでも取れるような信頼があること
ということが大事だと思っています。
現在参加している勉強会の運営メンバーは、基本的にオフラインのイベントで一緒に運営として参加したことがあるメンバーが多めです。
オンラインのコミュニケーションは基本、ある程度の信頼があるから成り立つものだと思っているので、初対面とかでいきなりオンラインで運営とかちょっとむずかしいのか?と思っています。
日々改善しています
ナレッジ不足はいかんせんありますが、運営でノウハウをためて
いろんな人に使ってもらおうと公開していますので、ぜひ見てもらえると嬉しいです
github.com
まとめ
オンラインイベントは、オフラインイベント比べると運営負担は少ないし、
開催ハードルも若干低いのかなと感じます。
もっといろんなかたちでオフラインの勉強会が増えてほしいとも思います。
けど、それぞれいいとこもあるのでやっぱりオフラインのイベントもしたいなー、と思う今日このごろです。