登壇のおぼえがき ~しゃべりながらコード書くの難しい!~
今回はVue.jsでした。
反省
そもそもVue.jsを初めて触ったのがこの勉強開催日の2週間前という時点で割と怪しさ満点でしたが、結果的にはなんとかなりました。 当然ですが対象を初心者に絞って扱う技術もwebpackを使わないレベルの簡単なものにしました。 逆にそう決めてしまえば2週間と時間がない中(実質土日だけでしたが…)でも範囲を絞って勉強と準備ができるので結果的によかったと思います。
初めてのライブコーディング
今回の勉強会は前回と違ってスライドを使って話す時間は10分くらいにしました。 スライドで話したのはVue.jsがどんなものかという話と簡単な文法の説明だけです。 残りの時間は実際にVue.jsを使ってTODOアプリを目の前で説明しながら作りました。
当然説明をしながらコードを書くのですがこれが思ったより難しかったです。 緊張するのでtypoはおおいし書き間違えで間違い探しを始めたりと少しグダグダしてしまう場面がありました。 とはいえ何とか完成させることはできたのでよかったです…(本当によかった……)
事前練習で作ったものはこれ↓
GitHub - Vue Todo
ライブコーディングはいい練習になるので、もっとできるようになってから再挑戦したいですね。
Javaのtry-catchを1行で書きたかったのでクラスを作ってみた
こんなことを思った
Javaにあるtry-catch文なんですが、例えばこんな処理を書くとします。 (funcが例外を起こす可能性のある処理だとします)
String str; try { str = func(); catch (Exception e) { str = "hoge"; }
これ長くないですか?こう書きたくないですか?
String str = Try(func()).catchThenReturn(Exception.class, "hoge");
とりあえず書いてみる
処理が値を返すか返さないかで大きく変わってしまうのでとりあえずは値を返すものを対象にします。
まずはResultクラスを定義してその中に結果と例外をまとめるようにします。そして値を取り出すときはunwrap()を呼ぶ形にします。
ここまでの単純なところだけだとこんな感じ。
Resultクラス
class Result<R> { R r; Throwable e; public R unwrar() { return this.r; } }
Tryクラスでの実行部分
class Try<T, R> { public Result<R> eval(T t, ThrowableFunction<T, R> func) { try { return new Result<>(func.apply(t)); }catch (Throwable e) { return new Result<>(e); } } }
これでとりあえず1行で書けるようになったのであとは例外を拾うためのメソッドを定義します。
例外を拾うメソッド自体もResultクラスを返すようにしておけば複数の例外に対処できそうな感じ。
public Result<R> catchThenReturn(Class<? extends Throwable> clazz, R t) { return new Result<>(equals(clazz) ? t : this.r, this.e); } private boolean equals(Class<? extends Throwable> clazz) { return this.e.getClass().getName().equals(clazz.getName()); } }
というわけでtry-catchをこんな感じで1行で書くことができました。
String ans = new Try<String, String>().eval("hoge", func).catchThenReturn(Hoge.class, "aaa").unwrap();
全体像
これです。Try.java · GitHub
new しないと使えなかったり、値を返さない場合のチェーンがやりにくかったりと問題は山ほどありますが、 なんとなく満足したので、これはこれで置いておきます。
SpringBootの概要に触れるコンテンツを作ったメモ
こんなものを作りました。
SpringBoot + Thymeleaf + Bootstrapで構成されています。 モデルの作成から始まって、最後は登録した商品の検索までを行うアプリを作れるようになっています。 本筋から離れてしまう認証(Spring Security)はなしで実装しています。
目的は1dayインターンと社内の新人教育用に作りました。
形式的にはハンズオンとして作っていますが、
自分が口で説明しながらの前提があるので、説明は少なめです。
説明自体はアプリを起動してhttp://localhost:8080/about
にアクセスすると読むことができるので
(もとはmarkdownファイルなのでそれを読んでもいいですが)、
自分で調べながらすすめるといったやり方もできます。
とはいえ、モデルとリポジトリの作成から、 コントローラとビューまでの一連の流れは実装しながら体験することができるので 1日用の想定とは言ってもそこそこの分量があるものになってしまいました。
ちなみに動作イメージはこんな感じです。
実際に使ってみて難易度や乗せるコンテンツを調整できたらいいかなという感じです。 もしダウンロードして動かしてみた人がいたらぜひ感想を教えてください。
ビギナーズLT会vol.1に参加しました
サイトページ
話したこと
資料はこちら
登壇してみて感じたことみたいなことをLTしました。
資料にも書きましたが以下の4つです
- 調べたものをまとめるようになった
- わからなくて放置していたものが減った
- 強い人に教えてもらえる!
- アウトプットが残るので私がどんな人がわかるようになった
ありきたりと言えばそれまでですが、自分が話してみて実際に感じたことなのであえて話ました。 2回登壇して思ってたより話せることが分かったので登壇することはもう少し続けます。 (ちなみに次は30日の予定…)
次にやること
登壇はもちろんしますが、次に以下の二つに挑戦したいです。
- サポーターズColab以外で登壇またはLTをする。
- 教材のようなコンテンツを作る。
一つめの目標は実は11月に達成します。(LTですが…)これをきっかけにいろいろな機会を持てたらいいと思います。 二つ目の目標はUdemyか、最近リリースされたTechpitというサービスがあるので、 そこで教材を提供してみたいなと思ったので次の挑戦することにしています。
勉強会で話した振り返り
ここで話ました supporterzcolab.com
発表資料
内容や感想を垂れ流します
話した内容
勉強会のタイトルにもある通り、オブジェクト指向における設計原則についてで、SOLID原則をメインに各原則の詳細を順番に説明しました。 おまけとしてSOLID原則以外にもある設計に関するパターンや法則などの紹介もしました。 SOLID原則自体を知ったのは2か月ほど前なので、自分の知識が浅い部分がかなりありましたが、 発表資料を作成しながら勉強することでなんとか形にすることができました。
よかったこと
話したおかげで自分の理解度が上がったのが一番大きいです。 もう一つ、発表が終わった後の質問タイムで、回答がわかりやすいと言っていただけたのがうれしかったです。 そもそも内容の濃いSOLID原則ですが、要点をなんとかまとめて30~40分程度の尺にうまく収めることができました。 話してみて実際に35分で話し終わったので、話の分量としてもちょうどよく調整できたと感じました。
改善点
理解度は上がったとはいえまだまだ知識が浅いところが多く、完璧な回答をすることができなかった気がします。 懇親会の中でもより深い話をしていたりしましたが、一部うる覚えだったりするところもあり、その点は復習すべき点だなと感じます。
もう一点は、ISPの説明のスライドでいきなり分離した状態の図にするのではなく、
インターフェースを作って依存を分離 → インターフェスを分割してさらに依存を分離
の順で図を分けたほうが理解しやすかったのではないかという指摘をいただきました。
これは確かにその通りでした。この部分は、とりあえず完成形から見せてしまえという考えでスライドを作っていました…
さらにもう一つ、スライドの構成について区切りのスライドをもう少し活用すべきだったなと感じました。 話の区切りに合わせて区切りのスライドを入れたらもう少し話のリズムが作りやすかったのと思いました。 そもそも本番まで発表練習せずに一発勝負でやったので、手抜きをせずに練習をすべきでした。
全体を通して、どのような説明をすれば本質的な部分を伝えることができるのかをもう少し意識してスライドを見直す時間が必要だったかもしれません。 これは、今回以降の登壇でも言えることなので、次からしっかりと実践していきます。
おわりに
2回目の登壇で、前回と比較すると倍以上の方が話を聞きに来てくれました。 内容はかなり難しいものでしたが、資料を作る過程の勉強含め多くの学びがあったと思います。 10月の終わりにもう一度登壇する予定があるので、この気持ちのまま頑張れたらいいですね… (話すネタはまだ決めていないですが…)
登壇とLTにネタが決まる前から申し込む意味
はじめに
明日勉強会で話します。来週のLTに申し込みました。勉強会は日程は決まっていませんがもう一回話す予定が入っています。 LTと次の勉強はネタが決まっていません。明日話す予定の勉強会も、決めたときにはタイトルしか考えてませんでした。 このような状況でなぜ話そうとするのか、自分の考えをまとめます。
話したいことが曖昧でも日程を先に決める
この状態で何が起こるかというと、基本的に「発表やめます」ということができないので逃げ道がなくなります。 逃げ道がないということはやるしかなくなるので、必ずやり遂げることができます。 また、日程が決まっているのでいつまでに何をしなければならないかの予定決めが楽になります。
知識が完璧でなくても話す
技術的なネタを話す場合、完璧でないからこそ話します。 話すために資料を作りますが、完璧でない部分を資料にすると必ず調べることになります。 調べれば理解度は上がりますし、話すことで記憶にも定着されます。 結果として、発表というアウトプットは自分のためのインプットとなって戻ってきます。
じつは結構楽しい
1回目は不安が大きくなるというのはどうしようもないことだと思います。 自分の場合は初めての時は人数が少なく比較的気楽に行うことができましたが、それでもある程度不安はありました。 しかし、終わってみると。様々な質問に答えたり、懇親会でお話したりということがかなり楽しかったように思えます。 発表することで知識がつき、人から話しかけてもらえ、良い経験となります。 そんな状況を楽しむことができれば、発表を行うという行動はかなり良いアウトプットとしての選択肢になります。
おわりに
こんなことを書きましたが、実際に話した回数はまだまだなので、 これから回数をどんどんこなして良ければうれしいです。 とある人に、「発表駆動開発」と名付けてどんどん発表をしようと言われました。 この言葉の通り、発表駆動開発を実践して質の高い発表ができるになればいいと思います。
資料作成の時に使えそうなこと
10/12(金)にこちらの勉強会で登壇します(露骨な宣伝)
これに向けて資料を作ったのでその時に気を付けたことをまとめておきます。
話さないことから決める
これをやるだけで発表の質はかなり上がると思います。話さないことを決めておかないと、いざ発表するときにあれもこれもと話してしまいます。聞いているほうは、情報が多すぎておそらく混乱してしまうでしょう。発表の最初にこれを話してこれを話しません、と決めておくことで聞く方も心構えができます。
全体の流れ
資料を作り始めたら、とりあえずタイトルだけ書いたスライドを全部作ってしまいます。そうすると、実際に作りこんでいるときに話のイメージが作りやすく、自然と資料の流れにも良い影響を与える気がします。 しかも、この時点ではタイトルだけなので資料の流れの修正も容易に行えます。
話すことの形を同じにする
これは全体ではなく、資料の塊ごとの形を指しています。例えば一つのコンテンツに対して、概要、例、まとめ、という形の資料にしているのであれば、関連するコンテンツもすべて同じ形で作るということです。こうすることで資料は作りやすくなり、話にもリズムが生まれます。
色
3色にします。例えば白い背景色のスライドであれば、黒(文字) + 青(メイン)+ オレンジ(アクセント)とすることでシンプルでわかりやすい資料にすることができます。おそらくこれ以上色を使ってしまうと、全体がうるさくなってしまい見るほうも疲れてしまうでしょう。加えて、色を選択するときに原色は避けたほうがいいと思います。原色は目にきついので、見ていて疲れてしまいます。
枚数
発表に慣れていないのあれば、1枚分の感覚で作るのはかなりおすすめ。1ページに1行にして、何度も切り替えるといった手法もありますが、発表がうまくない限りただのペースの早い発表になってしまう恐れがあります。余白を意識して大きめの文字で資料を作成すると(3~5行くらい)説明を入れると大体1分になるのでよい目安にもなります。
さいごに
資料の質を上げても話で躓くともったいないので最低1回は頭の中で話を流すようにするとなおよし。 あとは動画などでうまい発表をみてそれのモノマネをすると上手な発表に見えるかも?