notepad.exe

つまり覚え書き

ビギナーズLT会vol.1に参加しました

サイトページ

supporterzcolab.com

話したこと

資料はこちら

登壇してみて感じたことみたいなことをLTしました。

資料にも書きましたが以下の4つです

  • 調べたものをまとめるようになった
  • わからなくて放置していたものが減った
  • 強い人に教えてもらえる!
  • アウトプットが残るので私がどんな人がわかるようになった

ありきたりと言えばそれまでですが、自分が話してみて実際に感じたことなのであえて話ました。 2回登壇して思ってたより話せることが分かったので登壇することはもう少し続けます。 (ちなみに次は30日の予定…)

次にやること

登壇はもちろんしますが、次に以下の二つに挑戦したいです。

  • サポーターズColab以外で登壇またはLTをする。
  • 教材のようなコンテンツを作る。

一つめの目標は実は11月に達成します。(LTですが…)これをきっかけにいろいろな機会を持てたらいいと思います。 二つ目の目標はUdemyか、最近リリースされたTechpitというサービスがあるので、 そこで教材を提供してみたいなと思ったので次の挑戦することにしています。

勉強会で話した振り返り

ここで話ました supporterzcolab.com

発表資料

speakerdeck.com

内容や感想を垂れ流します

話した内容

勉強会のタイトルにもある通り、オブジェクト指向における設計原則についてで、SOLID原則をメインに各原則の詳細を順番に説明しました。 おまけとしてSOLID原則以外にもある設計に関するパターンや法則などの紹介もしました。 SOLID原則自体を知ったのは2か月ほど前なので、自分の知識が浅い部分がかなりありましたが、 発表資料を作成しながら勉強することでなんとか形にすることができました。

よかったこと

話したおかげで自分の理解度が上がったのが一番大きいです。 もう一つ、発表が終わった後の質問タイムで、回答がわかりやすいと言っていただけたのがうれしかったです。 そもそも内容の濃いSOLID原則ですが、要点をなんとかまとめて30~40分程度の尺にうまく収めることができました。 話してみて実際に35分で話し終わったので、話の分量としてもちょうどよく調整できたと感じました。

改善点

理解度は上がったとはいえまだまだ知識が浅いところが多く、完璧な回答をすることができなかった気がします。 懇親会の中でもより深い話をしていたりしましたが、一部うる覚えだったりするところもあり、その点は復習すべき点だなと感じます。

もう一点は、ISPの説明のスライドでいきなり分離した状態の図にするのではなく、
インターフェースを作って依存を分離 → インターフェスを分割してさらに依存を分離
の順で図を分けたほうが理解しやすかったのではないかという指摘をいただきました。 これは確かにその通りでした。この部分は、とりあえず完成形から見せてしまえという考えでスライドを作っていました…

さらにもう一つ、スライドの構成について区切りのスライドをもう少し活用すべきだったなと感じました。 話の区切りに合わせて区切りのスライドを入れたらもう少し話のリズムが作りやすかったのと思いました。 そもそも本番まで発表練習せずに一発勝負でやったので、手抜きをせずに練習をすべきでした。

全体を通して、どのような説明をすれば本質的な部分を伝えることができるのかをもう少し意識してスライドを見直す時間が必要だったかもしれません。 これは、今回以降の登壇でも言えることなので、次からしっかりと実践していきます。

おわりに

2回目の登壇で、前回と比較すると倍以上の方が話を聞きに来てくれました。 内容はかなり難しいものでしたが、資料を作る過程の勉強含め多くの学びがあったと思います。 10月の終わりにもう一度登壇する予定があるので、この気持ちのまま頑張れたらいいですね… (話すネタはまだ決めていないですが…)

登壇とLTにネタが決まる前から申し込む意味

はじめに

明日勉強会で話します。来週のLTに申し込みました。勉強会は日程は決まっていませんがもう一回話す予定が入っています。 LTと次の勉強はネタが決まっていません。明日話す予定の勉強会も、決めたときにはタイトルしか考えてませんでした。 このような状況でなぜ話そうとするのか、自分の考えをまとめます。

話したいことが曖昧でも日程を先に決める

この状態で何が起こるかというと、基本的に「発表やめます」ということができないので逃げ道がなくなります。 逃げ道がないということはやるしかなくなるので、必ずやり遂げることができます。 また、日程が決まっているのでいつまでに何をしなければならないかの予定決めが楽になります。

知識が完璧でなくても話す

技術的なネタを話す場合、完璧でないからこそ話します。 話すために資料を作りますが、完璧でない部分を資料にすると必ず調べることになります。 調べれば理解度は上がりますし、話すことで記憶にも定着されます。 結果として、発表というアウトプットは自分のためのインプットとなって戻ってきます。

じつは結構楽しい

1回目は不安が大きくなるというのはどうしようもないことだと思います。 自分の場合は初めての時は人数が少なく比較的気楽に行うことができましたが、それでもある程度不安はありました。 しかし、終わってみると。様々な質問に答えたり、懇親会でお話したりということがかなり楽しかったように思えます。 発表することで知識がつき、人から話しかけてもらえ、良い経験となります。 そんな状況を楽しむことができれば、発表を行うという行動はかなり良いアウトプットとしての選択肢になります。

おわりに

こんなことを書きましたが、実際に話した回数はまだまだなので、 これから回数をどんどんこなして良ければうれしいです。 とある人に、「発表駆動開発」と名付けてどんどん発表をしようと言われました。 この言葉の通り、発表駆動開発を実践して質の高い発表ができるになればいいと思います。

資料作成の時に使えそうなこと

10/12(金)にこちらの勉強会で登壇します(露骨な宣伝)

supporterzcolab.com

これに向けて資料を作ったのでその時に気を付けたことをまとめておきます。

話さないことから決める

これをやるだけで発表の質はかなり上がると思います。話さないことを決めておかないと、いざ発表するときにあれもこれもと話してしまいます。聞いているほうは、情報が多すぎておそらく混乱してしまうでしょう。発表の最初にこれを話してこれを話しません、と決めておくことで聞く方も心構えができます。

全体の流れ

資料を作り始めたら、とりあえずタイトルだけ書いたスライドを全部作ってしまいます。そうすると、実際に作りこんでいるときに話のイメージが作りやすく、自然と資料の流れにも良い影響を与える気がします。 しかも、この時点ではタイトルだけなので資料の流れの修正も容易に行えます。

話すことの形を同じにする

これは全体ではなく、資料の塊ごとの形を指しています。例えば一つのコンテンツに対して、概要、例、まとめ、という形の資料にしているのであれば、関連するコンテンツもすべて同じ形で作るということです。こうすることで資料は作りやすくなり、話にもリズムが生まれます。

3色にします。例えば白い背景色のスライドであれば、黒(文字) + 青(メイン)+ オレンジ(アクセント)とすることでシンプルでわかりやすい資料にすることができます。おそらくこれ以上色を使ってしまうと、全体がうるさくなってしまい見るほうも疲れてしまうでしょう。加えて、色を選択するときに原色は避けたほうがいいと思います。原色は目にきついので、見ていて疲れてしまいます。

枚数

発表に慣れていないのあれば、1枚分の感覚で作るのはかなりおすすめ。1ページに1行にして、何度も切り替えるといった手法もありますが、発表がうまくない限りただのペースの早い発表になってしまう恐れがあります。余白を意識して大きめの文字で資料を作成すると(3~5行くらい)説明を入れると大体1分になるのでよい目安にもなります。

さいごに

資料の質を上げても話で躓くともったいないので最低1回は頭の中で話を流すようにするとなおよし。 あとは動画などでうまい発表をみてそれのモノマネをすると上手な発表に見えるかも?

ABC112参加記録

久々にABCで全完できた回でした。 今回は練習もかねて初めてRubyで出ました。

A - Programming Education

問題ページ

1行だけ受け取って分岐して出力するだけの問題。

提出コード

B - Time Limit Exceeded

問題ページ

時間T以内に帰れる方法でコストが最小なものを出力する問題。
入力[c, t]のペアでリストをもってT以下でフィルターをかけます。 残ったリストの中にあるcの最小値を出力して、 フィルターをかけた時にリストの長さが0であればその時はTLEを出力して完成。

提出コード

C - Pyramid

問題ページ

ピラミッドの高さと中心座標を求める問題。
中心座標は101*101個なので全探索できます。 各候補座標に対して仮の高さを一度計算してその高さとしたときに与えられているすべての座標に矛盾がないか調べます。 矛盾がないか調べるときに候補座標から十分に距離が遠いもの(本来は高さがマイナスになるもの)を都度除外してから矛盾のチェックをしないとWAになってしまうので、その点で苦労しました。

提出コード

D - Partition

問題ページ

 N個の整数の和が Mになるときにそれらの整数の最大公約数の最大値を求める問題。  a_i kの倍数であるとき M kの倍数であるので、 kの候補は Mの約数となります。
 k Mの約数であるとき、 N \leq \frac{M}{k}であれば問題の制約を満たせるので、約数を全探索すれば答えを見つけられます。約数の片方は必ず \sqrt{M}以下であるので1から \sqrt{M}までループすれば十分間に合います。
答えの候補ですが、 k Mの約数であるとき M/kも答えの候補になりうることがあるので、それを忘れるとWAになります。

提出コード

Future Meets You Contest、ARC103/ABC111 参加記録

同日に開催されたのでまとめて書きます

Future Meets You Contest (ふみこん)

サイトページ

オンサイトにて参加しました。

ラソン形式のコンテストに参加するのは今回が初めてでした。そもそもマラソン形式をやるのが初めてだったので事前準備としてChokudai Contest 001だけ試しに解いて参加しました。

まず簡単な感想を述べると、アルゴリズムとは考えるべきことが違っているように感じてしまい、だいぶ苦戦しました。コンテストが始まる前までは0点を取ってしまうのではないかという不安があり、緊張してしまいましたが、本番では何とか点数を取ることができました。
通したのは適当な貪欲をランダムにした程度のものなので点数はあまり高くないですが、マラソン形式の感覚を感じることができたのよい経験になったと思います。

コンテスト終了後には懇親会と面談にも参加しました。懇親会では何度かお会いしたことある方や初めてのお会いする方含め、楽しくお話をさせていただきました。面談ではフューチャー(株)様での想定なオファー金額を提示していただけるもので(詳細は割愛します)、自社以外での一つの目線を感じることができたのでとても素晴らしい機会でした。

今回の企画をしていただいた、つかもさん、当日のスタッフをしていた社員の皆様、本当にありがとうございました。

ABC111/ARC103

サイトページ

こちらは言えることは何もないです。そもそも自分の参加記録を見ていたらRatedに参加したのが約1か月半ぶり、リアルタイムのコンテストに参加したのが約1か月ぶりとサボっていたのがバレバレで、結果もその通りになりました。

今回の問題は問題に対する考察はある程度あっていたものの実装がうまくいかず正解をすることができなかったパターンでした。

本当に言うことが何もないので、とにかく精進の流れを取り戻します。

Elmハンズオンに参加しました

こちらのイベントに参加しました

elm-jp.connpass.com

やったこと

こちらのスライドをなぞりながら実際にElmのコードを書きました https://gitpitch.com/ababup1192/elm-handson2

ハンズオンの後半では、同スライド内にある「Incremental Search」を自分で考えながら実装しました。 時間は1時間ほどだったのですが、発展問題の実装まで終わるには至りませんでした。ただ基本問題まではすんなりと実装することができたのでよかったと思います。(15分か20分くらい?)

ハンズオン後には4名の方によるLTを聞きました。
なんど一名スペシャルゲストで外国から来た方(!!)がLTをしていました。

やってみた感想

ハンズオン前

  • elmは5分くらいちらっと見た程度
  • 実際にコードは全然書いてない
  • なんかわかりにくいなと思ってた

ハンズオン後

  • 実際に説明を聞きながらコードを書いていたのですんなりと理解できた
  • 分かりにくいと思っていたものが実際に書いてるときに見るとむしろわかりやすかった
  • コード自体も本当に必要なものだけ書くのですっきりとしたコードにすることができた

この3つの中でも説明を聞きながらコードを書くというのが一番自分のElmに対する理解を深める手助けになりました。 (ハンズオンなので当然といえば当然ですが…)

Elmそのものについてもドキュメントを見てもわかる通り覚えるべきことが少なく、むしろプログラム初心者に向いているような気がしました。かといって必要なものがないかと言われるとそうでもなく、(少なくとも今自分が書いている段階での認識ですが)洗練された言語である印象を受けました。

LTについて

LTの内容はそれぞれ以下の通りでした。

どれも内容は素晴らしかったです。全員に言えることですが、本当にElmが好きなんだなという気持ちが伝わってきました。

最後に

Elmは本当に書き始めたばかりなので、もう少しコードを書いて理解度を深めます。 少しだけ書いた程度ですが、とても書きやすいので楽しくWebアプリの作成ができそうです。

スライドにも書かれていることですが、もう一つ。 Webアプリを作るよりによくあると思われることですが、コンポーネントが増えたり、ページが増えたりすると、だんだん破綻してきてひどいコードになってしまうという問題があります。これはどのフロントエンドのフレームワークを触っていても気になる所です。また、実際の業務でも苦労する所です。この問題をElmではどのように解決するのかを、実際に書きながら理解することでElmの真の力を見極めていきたいです。

本日のハンズオンを企画、運営いただいたABAB↑↓BAさん、ありがとうございました!!