C-FRONT

エモくありたい

初めてのサンフランシスコ/海外カンファレンス〜KotlinConf2017に行ってきた〜

初めて海外カンファレンスに行ってきた。次行く機会に自分でも見直せるように書き残しておく。

www.kotlinconf.com

きっかけ

  • ちょうどGoogle IOがあった時でTLでtwitterでいつも見ている人が皆Google IOに行っていることを知る
  • 自分の会社、他の部署・他の関連会社では同じ年くらいの人も行っていたのでいいなーと思う。
  • 会社で行かせてもらうほど自分に技術やスキルに自信がなかったのですぐには行けないけど、いつか行きたいなと思っていた
  • シリコンバレーや海外で働くことに対して漠然とした憧れはあったけど実際に何が良いのかうまく自分の中で説明できなかった。
  • 「とにかく海外カンファレンス行ってみたい!」何が良いのかも一回行ってみないとわからないでしょう、一回行ったら気が済むのでは、と思っていた。

自腹でもいいから買おうかなと言っている人を見て、そうか。自腹で行っちゃうという手もありなのかと思う。 ということで会社の経費が落ちるかは全くわからなかったけど勢いだけでチケットを買ったところからが始まりだった。(結局会社からいけることになった。本当にいい会社です)

英語とKotlin

仕事で使うこともなく英語/Kotlinは「しようしよう」と言いながらできてなかった。いつかしなきゃな、と思っていたのでKotlinConf行くのを目標に英語/Kotlinのキャッチアップをするというのを11月までの目標にした。

5月にチケットを買ってからDMM英会話に登録した。1日30分ずつレッスンを受けていた。週に5日くらいはできていたと思う。朝早く起きてレッスンを受けることが多かったので早起きできるようになってうれしかった。 CLEMというイベントにいったのがきっかけで英語でLTすることにもなった。

chiiia12.hatenablog.jp

Kotlinは業務で使ってなかったので趣味で自分で書いていた小さいアプリをKotlin化したりしていた。小さいアプリかつ難しいことも何もやってないので、Kotlinができるとは程遠いけど…ここはもうちょっとできたなぁと反省している。

Day1:移動・MountainView訪問

カンファレンスの前日にサンフランシスコ入り。昼すぎに着いたので、直接マウンテンビューに向かいGoogleオフィスを訪問。たまたまGoogleに務める知り合いがマウンテンビューにいたので少しオフィスの中のほうまで見せてもらった。 以下メモ

  • googleのキャンパスは大学みたいな感じ
  • 田舎で車がないと生活できないらしい
  • 知り合いはSF市内に住んでいて、googleが専用のバスを出してくれてるからそれで通勤しているらしい
  • 朝夜は渋滞がすごいらしい。空港からMTVも1hくらいと教えてもらっていたけど実際30分くらいでついた
  • SF市内にもオフィスがあるのでSFオフィスとMTVオフィスを曜日ごとに通い分けているらしい
  • MTVには偉い人がいるからそういう会議を出席するのにMTVに週何日かくる必要があると言ってた
  • キャンパス内にジムや食堂あり。フリードリンクでスナックや飲み物はいつでももらえる。3時くらいに行った時は何人かジムを使ってた。やることやってれば昼間でも自由にジムにいける
  • Google Storeは日曜休み。Tシャツとかマグカップとかgoogle homeとか。Droidくんのぬいぐるみに手を出しそうになったがやめておいた
  • google社員だと1割引きになるらしく知り合いのカードで支払ってもらった(社員証を見せて私の支払いはダメらしい)
  • レジにNo cashと書いてあるのが印象的だった。

f:id:chiiia12:20171119223616j:plain
GoogleStoreでの戦利品

Day2-3:Kotlin Conf参加

Day2-3は本命のカンファレンス参加。受付を前もってしておくpre-registrationというのが前日行われていたらしいが、自分はしていなかったので少し早めに向かったが、受付は一瞬で終わった。写真つきのIDを見せてシールを発行。

f:id:chiiia12:20171119223740j:plain
KotlinConfでのノベルティ達。他にTシャツがある。

セッション

色々わからないことも多かったけど、とにかく全部の時間でセッションを聞きに行った。以下感じたことのメモ。

Day1最初のKeynoteではKotlinの最新事情や今後の展開などが話された。KotlinをMultiplatform化することにすごく力をいれているということが伝わった。サーバサイド・Android・JSだけでなく、iOSの公式サポートが発表されて会場はドっと湧いていた。CommonModuleというフロントとサーバサイドでKotlinコードを共有できるという概念は興味深かった。ちょうど自分のチームが少ない人数でフロントからモバイル・サーバサイドまで開発していかなきゃいけない体制になっていきそうなので、Kotlinで開発することでクロスファンクショナル化をより進められるのかも?などと考えていたりした。

Kotlin1.1から導入されたコルーチンの話題が多かった印象。非同期処理行う時のコールバック地獄をスッキリ書けるんだよみたいな話をIntroduction to Coroutinesでしていたと思う。Springでコルーチンをどう使うかというセッションもあったり、Kotlin製のWebフレームワーク「Ktor」でもコルーチンを使った非同期処理を利用していたり推されている機能のように感じた。何が良さでどう使い分けるのか自分でもわかってない部分があるので、今後ちゃんと理解したいトピックだなと感じた。非同期処理を書く時にはRxJavaを使うことが多かったところをコルーチンが代替するかも、という点で皆の関心度が高かったのではという話を参加者としていた。

Introduction to Coroutines @ KotlinConf 2017

Springの話も多かった。Bootiful Kotlinというセッションが大変人気なようだった。2017/9にリリースされたSpring Framework5にSpring WebFlux機能の追加とKotlinのサポートが入ったことがポイントと理解している。Spring WebFluxのプログラミングモデルの一つである「Router Functions」というアノテーションではなくラムダを通して設定していく書き方とKotlinの組み合わせの相性がよく、よりシンプルに書けるというところが好評どころだった、と私は理解している。

KotlinConf 2017 - Bootiful Kotlin by Josh Long - YouTube

Kotlin製のテストフレームワークであるSpekの話も興味深かった。JUnitでは「コードの繰り返し」「メソッド名が長くなりすぎる」「何のテストをしているかわからない」状態に陥ることが多くSpekはそういった問題点を簡単に解決してくれるといった内容だった。JUnitでもテストの構造化やパラメータ化はできるが、JUnitよりもより覚えやすい・書きやすいというところが良いところなんだと思う。おそらくSpec系のテストフレームワークとできることは一緒なのでは、という認識。なのですが 、Kotlinで書けることがプロダクションコードとのスイッチングコストをより少なくできる点で良いところなんだと理解している。

Testing Kotlin at Scale — Spek #KotlinConf2017 // Speaker Deck

準備と心づもり編

実際にサンフランシスコに行く前に準備していたことと、もっとこう準備しておけばよかったことを備忘録として書いておく。

  • 日中と夜の寒暖差が激しいと聞いたので冬用のコートを用意。会場は屋内だったが、すごく寒かった。一日中コートを着ていても顔が青くなるくらい寒かったので、カイロか何かをいくつか持っていけばよかった。
  • 向こうでの移動はほぼUber/Lyftと聞いていたのでアプリをインストールしておく。空港からすぐ使えるよう、スマホの充電を十分にしておく。
  • テンダーロインという地域は危ないので近づかないよう気をつける。テンダーロイン以外にも重厚なシャッターが閉まっているところがあるので地面を見つめながら黙って早歩きで通り抜ける(とアドバイスをもらった)
  • 21時以降は出歩かない、そもそもあまり一人で出歩かない。気をつけていたけど、夜中の2時まで参加者のみんなで外で飲んだりしたので、みんなで一緒なら大丈夫。
  • ホテルに歯ブラシがないことがあるので持っておく。当然あるものだと思っていて気づいたのが夜中だったので朝コンビニで買えるまで地獄だった。
  • 時差ボケひどいので無理しない。サンフランシスコについた日の夜は夜中に目が覚めてしまいそのまま朝まで寝れなかった。日本と違って体調も崩しやすい& ただのビールだと思ったらアルコール度数10%でした、というパターンがあるのでお酒はいつもより少なめにしておく。夜は寝れないが昼の2.3時の眠気がヤバい。
  • 会場のWifiや電源は日本と違ってあまりアテにできない。

サンフランシスコ/海外事情

Day1のパーティ後に海外の参加者達と一緒に二次会・三次会に繰り出した。 この思い出が特に印象に残っていて、海外でのエンジニア事情について聞けたことが新鮮で刺激的だった。(知人のおかげで一緒に混ぜてもらえた、ありがたい🙇)

カンファレンス参加について

会社で行ってるので帰ったらフィードバックしなきゃいけない、という話をした。 (すべての会社ではないと思うが)話した人の会社では年に100万くらい(金額は曖昧)研修やカンファレンスなど自分で何に使うか決めていいお金があって、それを使って今回のカンファレンスに来たと言っていた。 なので、今回のイベント参加は別に会社にFBする必要もないし、この費用はカンファレンスでも本でも何にでも比較的自由に申請できるんだー、と言ってたのが印象的だった。 今回出会った人たちは、かなりカンファレンスに参加に積極的らしく、日本にもDroidKaigiで来てくれていたらしい。日本でもコミュニティがあると、「次は日本に来てよ!」「いくいく!」て繋がっていくのがうれしかった。恋人同士エンジニアで一緒にカンファレンス参加している人も多い。

エンジニアのキャリアについて

  • ネットフリックスのエンジニアは皆すごい給料高くもらってるらしい。
  • アメリカだとCSを持ってないとエンジニアなれないって聞いた。→「そんなことないよ。本当に今エンジニアの職たくさんあって、特にSFがエンジニアの求人が本当多い」「実際に自分は大学の学士持ってないよー」
  • エンジニアの立場が下になってしまうことがよくあって・・・→アメリカはエンジニアの立場が絶対上。
  • やっぱりエンジニア、コード書かなくなっちゃうことが多いのかな→エンジニアからマネージャーいくこともあるけどエンジニアはそれはそれで評価されてるみたいな。プロダクトマネージャーとかになるエンジニアも多いかも。自分もマネージャーだった時は全くコード書けなかった。けどそれが役割だからit's ok

振りかえり

セッション選び

わかりやすいセッションもあったし、自分の英語力不足であまりついていけないセッションも多かった。 エモい系のセッション(プロセスとか、心持ちとかのことを語る内容だとニュアンスが聞き取れない)はついていけなくなることが多いことにDay1で気づいたのでコードベースで説明してくれそうなセッションに変更したりした。

リスニング

参加前GoogleIOの動画をいくつか見ていてなんとかついていけるかもと思っていたが、自分の想像以上についていけなくて愕然とした。話す練習をしようと思ってDMM英会話を続けていたけどまずはリスニングで聞き取れるようにならないとな、と感じた。(Google IOは皆に理解されやすいように特に英語の表現気をつけてくれているという話をチラッと聞いた)

その他

  • 知らないことばかりだったけど大量の新しいinputの機会になった
  • カンファレンス来ている人皆息を吐くようにコード書いてた
  • githubintelliJの画面しか開いていなかった印象
  • 日本人的には英語喋れないので消極的になりがちだけど本当無駄で向こうの人は全然気にしていない。ウッっとなって喋れないのは誰の得にもならない。
  • KotlinConfに参加していたことがきっかけで同じように参加されている日本の方(話してみたかった)人ともお話ができたのが嬉しかった

最後に

長くなったが、刺激的で色々と感じるものが多かった良い海外出張だった。 もっと頑張らなきゃなという気持ちしかないけど、また日本で頑張って海外出張行かせてもらえるように成長するしかない。

Groovy入門して躓きメモ

Java→Groovy初日で出会ったエラーたちやメモたち。 syntaxもよくわからない中で出会って、解決するのに慣れなかったのでメモしておく。

メソッドの呼び出し間違い

メソッドの呼び出しが間違った時

Caught: groovy.lang.MissingMethodException: No signature of method: hogepackage.hogefile.hogemethod() is applicable for argument types: (java.math.BigDecimal, java.util.ArrayList, groovy.sql.Sql) values: ...

特にクロージャの中でエラーが起きるとクロージャのどこでそれが起きているのかよくわからなくて慣れるまで時間がかかった。

変数の宣言のスコープ

http://d.hatena.ne.jp/Kazuhira/20120318/1332083318

before

def sql = Sql.newInstance()

Map.each{k,v->
    searchUuidByUser(k,v,sql)
}

eachの中からsqlは呼び出せない。

Caught: groovy.lang.MissingPropertyException: No such property: sql for class: hogepackage.hogefile
groovy.lang.MissingPropertyException: No such property: sql for class: hogepackage.hogefile

after

sql = Sql.newInstance()

Map.each{k,v->
    searchUuidByUser(k,v,sql)
}

def をつけているとクロージャ内やメソッド内から呼び出せない。

列名が無効

before

def SELECT_USER_POINT_HISTORY = "SELECT ID,POINT,INSERT_AT from POINT_HISTORY where ID = $userId ORDER BY INSERT_AT"
        List<Point> pointList = new ArrayList()
        sql.eachRow(SELECT_USER_POINT_HISTORY){
            Point dto = new Point()
            dto.type = it.type
            dto.point = it.point
            dto.insertAt = it.insert_at
            pointList.add(dto)
        }
警告: Failed to execute: SELECT ID,POINT,INSERT_AT from POINT_HISTORY where ID = ? AND TYPE != 0 ORDER BY INSERT_AT because: 列名が無効です。
Caught: java.sql.SQLException: 列名が無効です。
java.sql.SQLException: 列名が無効です。

てっきりSQLが悪いのかと思ってタイポかどうか必死に探したけどSQLが悪いわけじゃなかった

after

def SELECT_USER_POINT_HISTORY = "SELECT ID,POINT,TYPE,INSERT_AT from POINT_HISTORY where ID = $userId ORDER BY INSERT_AT"
        List<Point> pointList = new ArrayList()
        sql.eachRow(SELECT_USER_POINT_HISTORY){
            Point dto = new Point()
            dto.type = it.type
            dto.point = it.point
            dto.insertAt = it.insert_at
            pointList.add(dto)
        }

eachRowの中で参照しているit.typeがselectするものに含まれてないため。 エラー行数をよく見るとit.typeを使っている行を指しているのでわかる

for文の抜けかた

https://stackoverflow.com/questions/3049790/can-you-break-from-a-groovy-each-closure 次のイテレートに入るならeachのままcontinueしてもOK そもそもループを中止したい時(Javaでいうbreakをしたい時)はfindにしてその中でtrueを返してループを終わりにする

pointList.find{
                Data data = new Data();
                if(nowPoint<it.point){
                  //breakと同じ。ループを抜ける
                    return true;
                }else{
                    //continueと同じ。
                    return false;
                }
}

TDDBCに参加&ペアプロデモをしました #tddbc

tddbcにスタッフとして参加&ペアプロのデモをしました。

tddbc.connpass.com

ペアプロのデモとは

TDDBCではTDDのやり方を学んだ後、参加者がペアになってペアプロをしながらTDDを実践するプログラムになっています。 このペアプロでどうやって進めていくのか、のデモを行いました。 今回は@yattomさんとFizzBuzzを題材にペアプロしました。

やってみて

ある程度台本があるので安心です。ここでこういう説明が入るとか。 でも後はその場の雰囲気です。実際のペアプロをやってみせてるだけなので疑問とかもガンガン言っちゃっていいので気は幾分楽です。 今回は@yattomさんがリードしてくださり説明などもしてくれたので、なんとかなりました。 自分の開発環境を前のスライドに映しながら行うので自分の開発環境へのツッコミも新鮮でした。

今回@PoohSunnyさんから煽られてデモをすることになったけど、「人前でライブコーディングするのが一番成長するからやってみな」と言ってくれたと聞いて感謝してます:pray: (FizzBuzzをライブコーディングして成長するかは置いておいて、新しい経験だったので楽しかったです!)

その他

  • 午後は参加者に混じってペアプロやってた。1年目、2年目のフレッシュな方とペアを組んでみて自分も気づきがあって何より楽しかった。
  • tddbcの参加者の方々は話がうますぎる。どんなコードを書いたかを前で発表する時間があるのですが、皆さんプレゼンがうまくて引き込まれる。
  • 他の言語チームのコードを見たり話を聞いたりするのがとても楽しかった。Spock使ってみたくなったり、良い興味の入り口になったと思う。次は覚えたての言語で参加したい。
  • 皆テストについての興味や悩みが共通事項としてあるので、質問タイムも懇親会の即興LT大会もすごく盛り上がって楽しかった。こんなアットホームで参加者同士でこんなに仲良くなれるコミュニティはすごい。

  • ペアプロしている同士ではすぐ疑問解決されるから良いけど他のチームメンバーに逆に伝わらなくなったりしないの?な質問だったと思う。
  • PRのコメント/質問をgithub上で返すのではなく、コードのコメントに反映して設計意図を伝える方法良いと思った。

最高だった。

楽しかった!!!

Tokyo Android Meetupで初英語プレゼンしてきた

Tokyo Android Meetupというイベントで初めて英語でプレゼンしてきました。

speakerdeck.com

#11 Tokyo Android Meetup - July Edition - Tokyo Android Meetup (東京都) | Meetup

Meetup内のイベントは日本開催でも外国の方が参加するイベントが多いらしく、hotchemiさんのブログを見て以前からmeetupのイベントに参加してみたいなと気になっていた。

参考:hotchemi.hateblo.jp

そんな時にCLEMのイベントに参加したことがきっかけでmeetup参加したことないけど喋ってみることになりました:bow: clem.connpass.com

準備編

初めての英語プレゼンだったので、アドバイス貰った通りどんなことを話すかスライドとそれに合わせてスクリプトを作成していました。 keynoteのnoteのところにスクリプトを書き出してそれを見ながら練習していました。 英語に関しては、先輩に単純な文法のミスや、言い回しのアドバイスなどをレビューもらいました。

また、内容に関しても直前に社内でLTする場があったので日本語で同じ内容を発表してなんとなく内容について雰囲気をつかんだりしました。

当日行って気づいたこと

英会話のレッスンとネイティブの人が話す速さ、全然違うので聞き取れなかった
  • 特に単語と単語がつながりすぎて人によっては全く聞き取れなくて辛かった
  • 1ヶ月半英会話続けて単語レベルで英語が聞き取れるようになったと思ったけど速く話されるととたんに駄目だし、はっきり発音されないと何も聞き取れないということがわかった。
DMM英会話で女性の先生のレッスンばかりを受けていたことを後悔した
  • DMM英会話初めて1ヶ月半くらい経つのですが、「なんか安心できる」という理由だけで女性の先生ばかり選んでレッスンしていた
  • 実際エンジニア界隈は男性が多いのでハードルばかりがあがってしまい当日場が和むまで最高にコミュ障だった
だんだんBGMになっていくのがわかる
  • 最初は頑張ってついていってたつもりだけど、途中から完全に頭がついていかなくて全然話が入ってこない
  • 自分の今のキャパシティはここなんだなということがわかった。これをどんどん伸ばしていけたらいいなと思った。

感想

  • レッスンで話される英語と実際の会話で話されてる英語はちょっと雰囲気が違うのでそれを味わう。本当の会話にどれだけ太刀打ちできるか試しにくる意味ではmeetupのイベントとても良いと思った
  • meetup参加すると、「英語ができるようになりたい」じゃなくてこの人たちと話がしたいという思いになってモチベーションアップに良い。
  • 参加している外国の方、だいたい日本語も知ってる人が多いので日本人に対して色々な事情理解・配慮してくれているなと感じた
  • デベロッパーが使う言い回しなどを覚える貴重な機会。同じ境遇の人が多いから真似できる言い回しなど多いなと感じた。
  • 今回はすごくアットホーム。10人くらいの小さなイベントで最初の英語プレゼンをするには良い場所だったと思う。たいしたことない話だったと思うのに、ウンウンうなづいて聞いてくれたのがすごくうれしかった。
  • 日本の勉強会とも一緒だが、speakerしたことで日本人だからと関係なく話しかけてくれる人もいて助かった。楽しかった。
  • まだ私が来るには早かった、と思ったけど参加してみたらすごく楽しくて参加してよかった。

だいぶ楽しんだ模様。定期的に腕試し&モチベーション維持の意味でも良いと思いました。

Spring Bootのキャッチアップにバージョンアップで理解を深めた話

最近Androidアプリ開発からサーバサイドの開発に移り、移って早々SpringBootのバージョンアップをする案件にアサインしてもらった。SpringBootはじめてです!の段階でプロジェクトのSpringのバージョン担当することもなかなかない話かと思うので、Spring Bootのキャッチアップという点からバージョンアップで対応する時に学んだことをここにまとめる。

前提

  • 業務で経験していたのはAndroid開発のみ
  • そういえば今まで業務でライブラリのバージョンアップを経験したことはなかった

要約

  • プロジェクトのSpringBootバージョンを1.2系から1.5系まであげた
  • SpringBoot始めたばかりで通常のエンハンス案件をやっているだけでは知らなかったと思える経験・感覚をつかめたので、学習の導入になった

バージョンアップを経験してよかったこと

SpringBootの導入には「はじめてのSpring Boot」でキャッチアップしていたが、そこでは知れなかったこと&もしこのままエンハンスをやっていたら知るのが遅くなってたであろうと思うことをいくつか。

ライブラリの依存関係について

バージョンアップ作業中に一番対応したのがライブラリの依存バージョンの解決だった。 //TODO:例えば AライブラリとBライブラリが中でCライブラリに依存してるが、AとBはバージョンによって依存するCのバージョンが違う、みたいなことが起こる。バージョンの違うライブラリに依存していると、順番はわからないがどちらかの依存versionしか参照できず、NoSuchMethodErrorで怒られる。この仕組みについて最初わかってないので困惑した。 mvn dependency:treeやpom.xmlDependency Hierarchyをみながら各ライブラリの依存ライブラリの整合性を修正していく作業が多かったかと思う。 ライブラリの依存関係を理解する過程で不要なdependencyなどを見つけたり、pom.xmlの整理の仕方も多少は身についたかと思う。

Android開発の時はライブラリのバージョンアップの経験がなくてライブラリ間の依存関係について意識することがなかったので勉強になった。

エラーログに向かう感覚の醸成

SpringBootを初めて触れた時、自分が書いたClassとは全く違うClassからエラーが吐き出されることにとても困惑した。今までは、基本的には自分の書いたコードからExceptionが吐かれることが多かったので、原因もわかりやすかった。 バージョンアップの対応にはたくさんのこうしたエラーに対応しなくてはいけないので、数をこなして慣れることができた。最初に感じていたゲッという気持ちはバージョンアップ経験後ではなくなったので非常によかったと思う。

参考にできるネット上のページの感覚

上にも関連することだが、たくさんエラーが出る中でわからないことを調べる時に参考になるページが集中的にインプットされる。最初はどうぐぐったらヒットするのか模索するのでとても効率が悪かったと思うので。 - Maven Repositoryの各ライブラリのDependency部分 - 公式ブログ - Release Note - Githubのissue - Javadoc - その他QiitaとかStackOverflowなどは普通に。。。 こう書いてみると当たり前なリソースな気がするが、これを経験する前はこれができなかったのである。

Springの各種プロジェクト間の関係性について

恥ずかしながら色々あるSpring系のFrameworkについて全く認識しないまま開発に入ってしまった。例えば以下などがバージョンアップを通して気づき経験した。 - starter系はversionが一緒になるのでそれを踏まえて依存関係を解決しなくてはいけない。 - Bootが依存しているSpring Frameworkのバージョンも変わるので、Spring Frameworkの変更点も確認しなくてはいけない。 - パッケージの変更などで新しくspring-securityをimportしなくてはいけなくなったり。 エンハンスだけしていたらあまり意識してなかったと思うので、いいきっかけにだった。まだ理解してないこともあるのだけど少しだけ。

バージョンアップするにあたり個別に対応したところ

どこで動かなくなったかがわからなくなるのが不安だったので、ひとつずつバージョンをあげて「ここまでは動く」を確認しながら進めた。 意外とボリュームが多かったので別記事にまとめる。うん。まとめる。

まとめ

キャッチアップ材料として「バージョンアップしてみる」選択肢としても考えてみるのも良いかもしれないと思った話。状況と必要性もあるが。 エラーのデバッグを集中的に数こなす意味ではSpring Bootの仕組みに慣れるのでよかった。エラー出ても少しは怖くない! プロダクトの設計や仕様把握はまた別なので、エンハンス始まって泣きながらキャッチアップしてる。

JJUG CCC 2017 Springで登壇しました~新卒2年目が鍛えられたコードレビュー道場~ #jjug_ccc #ccc_l3

JJUG CCC 2017 Springで登壇してきました。

JJUGについては以下。 www.java-users.jp

発表内容については以下を参照ください。 speakerdeck.com

ここからは忘れないうちに感想文。 外部イベントで2回目の発表でした。(1回目はこちら。)

chiiia12.hatenablog.jp

20分の発表は話の構成のしかたがすごく難しいなと思った。今回はストーリー作りもそうだし、スライドでの伝え方に結構苦戦して、結局最終的なストーリーに行き着くまでに何回か潰した気がする。20分のボリューム感、どこまで話広げるべきかがわからなくて、結局最後の練習まで17分で終わってしまうボリュームだった(本番はなぜかぴったり20分になった)。

本番は小さい部屋でしたが、満員で部屋に入れなくなるほど人が来てくれたり、発表後に質問に来てくれた方もいた。発表してよかった。。。 ちょっと今後気をつけようとおもったのは、新しいmacとアダプター経由でのプロジェクターへの接続が悪くてヒヤッとした。やっぱりしばらく旧macも一緒にもってないと怖いかも。

あとは他のイベントと比べてtwitter実況が少ないイメージ。どんなところが刺さったんだろう?ちゃんと伝わってたかな、心配です。

また登壇後、コーディングスキルアップの仕方について後輩と話したりして、結局今回レビューしてくれていた先輩がすごかった&かなり恵まれてたんだなぁということに気づく。 多分若手にとってもどんな知らない世界があるのかわからない、先輩にとっても若手がどこまで知らないのかわからない、このお互いの状態をつきあわす機会があって、うまく知識を整理してインプットしてくれる先輩がいて今回の内容に繋がったんだとおもった。 恵まれてる環境だったのは確かなんだが、より横展開しやすい形にできたらもっと良かったなと感じた。

あとは初めてはてなホッテントリに入って感動!準備してる時は地獄だとおもったけど、こういうアウトプットにできて今回CfP出してみてよかった。

ちなみに2017年の目標は「社外のイベントで登壇する」にしていて、これで叶ってしまったのでまた新しい目標を立てるとする。 自分のアウトプットに反応が返ってくる意味で登壇するのすごくよかったので、これからも機会あったらどんどん出してこ!

Node学園25時限目でLTしました〜初めての社外LTの振り返り〜 #tng25

Node学園というイベントでLTをしてきました。

nodejs.connpass.com

内容はこんな内容になります。

speakerdeck.com

ちょこちょこ社外のイベントには出てきましたが、自分でLTをするのは初めてだったので、振り返り&感想を書いておこうと思います。

準備編

スライドのトンマナ

社外でしゃべるのが初めてということもあって自分のパワポテンプレートを作りたいなーと思っていた。できることなら、スライドであっこの人だ!とブランディングできたら理想だなーと思っていた。 例えばtwadaさんはtwitterでslideのリンクが流れて来た時に、サムネイルだけでtwadaさんのスライドだとわかるので、ちょっとそういうのに憧れている。 なので、多少今後も改良はしていくだろうけど、ある程度今後も使うぞっていう前提でスライドのベースを作ってみた。

話を組み立てる順番

自分はイラレを使ってスライドを作っているので、あんまり話が固まってないままスライドのdetailを作り始めちゃうと結局時間が足りないだの、喋ってみたらちょっと違った、みたいなdiffが出てきてせっかく作ったスライドが無駄になるという知見を聞いていたので以下の順番で進めてみた。

  • だいたいのストーリーを組む
  • パワポで雑にスライド作る
  • スクリプトを組む
  • 時間におさまるか、ストーリーに合わないスライドは修正していく
  • 最後に詳細なデザイン

トーリー組むのって結構憂鬱なのではやく詳細なデザイン作り込みたくなってしまうのだけど、そこはぐっと我慢で最初にスクリプトまで決めてしまうのが一番無駄がなさそう。できればデザインに入る前に人にみてもらってストーリーラインを壁打ちするのがGoodだと感じた。

初心者向けでも楽しんでもらうために

Node学園というイベントは結構内容がギーク向けで、その中で初心者が初心者向けの発表をする時に、どうやったら聞いてよかったなーと思ってもらえるんだろうということは気にしていたきがする。 スライドシェアでスライドが見れるこの時代に生で聞けてよかったと思える発表は個人的にはストーリーの面白さ(笑えるポイントがあるとか)なんじゃないかなーと個人的に思っていて、ちょこちょこ笑えるポイント作れないかなーと思いながらストーリーは考えていたりしました。

  • 自己紹介で何か場がほぐれる掴み(ちょっとウケた)
  • 背景画像を地味に意味ありげな写真にしとく(誰にも気づかれずにすべった)
  • みんなが知ってる人のネタを仕込むとか(ちょっとウケた)

こんなかんじかしら。自分も笑いポイントってどういれていいかわからずLT経験豊富な同僚にアドバイスもらいながら最後仕込みました。 あとは、「初心者向けですよ」と最初に宣言することで期待値を調整するようには心がけたつもり。多分そこがズレていると厳しいまさかりが飛んできそう、お互いにとってよくない。

当日編

話している間はあっという間だったのであんまり覚えてない。けど楽しかった!!

拡散量がはんぱない

今までアウトプットのメインはブログだったけど、登壇&スライドの共有の拡散量はすごいなーと感じました。 あと当たり前だけどフィードバックの量が多い。どこらへんが共感してくれて、ほーと思ってくれたのかがわかるのはうれしいなと思ったり。自分が世に出したもので、はてぶ30とかはじめてもらった。あと内容が初心者向けでかつ想定読者層が広いといろんな人にひっかかるというのもあったのかも。

意外とtwitterの通知気づかない

結構どうでもいい話な気もするけど、今回まで気づかなかったので。 自分へのリプライ全然気づかず、あやうくとりこぼすところだったので注意深くみておかないと・・・。

あとは自分のスライドをシェアしてくれているツイートについては、短縮URLになっちゃったりのでタイトルも一緒でつぶやいてくれている人以外は検索にもひっかからない。自分の知らないところでつぶやいてくれてたりすることも多々あり、たまたま見つけたもののできれば全部拾いたいなーと。自分は登壇内容タイトルで検索かけてニヤニヤしていたのですがなんかもっといいエゴサの方法あるのかしら。

次に繋がる

Node女子学園でこの内容話してほしい。みたいに言ってもらったりして、次の機会につながった。 初心者向けって誰が参考になるんだろうかと思ってたけど、初心者向けの発表も新しい人が入って来やすく、学びやすい環境を作る意味で大事ですよと言ってもらえて本当発表してよかったなーと。今までJava/Android界隈の勉強会にしか行かなかったので新しい世界で知り合いが増えたのもすごく楽しかった。

LTの形にまとめることで知識の整理に

今回一つテーマを切って人に伝えられるレベルに色々組み直してLTと言う形にするプロセスがすごくやってきたことの整理にいいなと思った。意外とスライドにしてみたら、ここって本当はどうなんだっけとか間違ってること言ってないよね?の確認をする過程でも知識を深められたり。 これはブログでもできると思うけど結構自己満でいつも書きなぐっちゃうので、直で目の前に人がいて自分の言葉で喋らなくてはいけないLTのレベルまで思考を整理するのは大事だなと。

おわりに

今回初めてLTをしてみてこれはエンターテイメントだなとえもくなってしまった。個人的な話だが、昔ダンスで舞台に立っていた時、このイベントにはこのネタをやろうとかコンテストだからこういうネタにしようとか次はどのネタやる?みたいな感じで次はなんのネタを踊るか決めていた。それと同じことがこういう技術的なイベントに立つ時でも起きているなと思っていて、イベントに合わせてネタ変える感じとか自分のネタがどんどん増えていく感じとか、ちょっと昔を思い出した気がした。ダンスで舞台に立つのが好きだった時と同じ感覚が、もしかしてイベントで登壇することで味わえるんだとしたらこの世界には自分はすごくはまるし相当楽しめると思った。

こういうのを後押ししてくれる会社だったり、今の環境最高である。

次はこれに出ます!準備がんばります

www.java-users.jp