京都でプログラミング勉強会を2ヶ月程運用し続けていて思ったこと

桐生あんずです。タイトル通りのお話です。

1, はじめに

6月の始まりくらいに「プログラミング勉強会を開いてほしい」という声を友人から受け、色々面白そうなのでやることにしました。気が付けばもう8月に入って、運用方法も定まってきたのでどんなことをやっているか紹介していきたいと思います。

以前から「プログラミングを勉強したい/Webサービスを作ってみたいけど、どう進めたらいいか分からない」という相談を複数の友人から受けており、個別に対応していたのですがそういった人たちを一つの場所に集めて私が以前参加していたid:hidesysさん主催の「1ヶ月でWebサービスを作る勉強会」のような座学と実習を交えたやり方で進めてみたら私でもうまく進められるのではと思い、こういうことは何でも早い方が良いので6/8に初回の講座を開き、始動しました。

2, 基本的な流れと運用方法

 ・講座内容

私がある程度教えられてかつ、参加者側が作りたいもののイメージが掴みやすいやり方を考えた結果、

1, RubyでFizzBuzzを書いてもらうなどしてプログラミングの基礎的な流れを掴んでもらう

2, HTML/CSSを学習してもらってオリジナルの静的サイトをマークアップし、パブリックに公開するまで行う(AWS S3で静的ホスティングを行う)

3, ProgateのRailsレッスンやRailsチュートリアルを毎週課題として出しながら、作りたいWebサービスをアイデア出ししてイメージして勉強してもらう。最終的にはオリジナルのWebサービスを開発・完成。

という流れでいくことにしました。

1では私が作ったスライドを見てもらいつつ実際に簡単なコードを書いてもらってプログラミングがどんなものかを知ってもらいます。

2ではHTML/CSS(余裕があればJavaScriptも)について簡単な概要を説明した後、自分でアイデアを出してオリジナルのホームページを作る課題を1~2週間の間でやってもらっています。こちらで個別の教材は用意せず*1、おすすめのリファレンスサイトをこちらで教えたり、参加者各自でHTML/CSSの入門書を買ってもらい基本的に一人で進めてもらいます。

定期的にコードレビューを行って加えた方が良いところや変えたら面白そうなところなどをアドバイスしています。

3の段階は最近始まったところですが、参加者の学習状況によってRailsチュートリアルかProgateかを選んでもらい、毎週1~2章分やってもらうようにしています。一から全部やってもらうのは特にRailsチュートリアルの場合だと大変だと思われるため、Slackの方で専用チャンネルを作って質問を随時受け付けたり、章ごとの注目ポイントについて私がまとめるなどしています。

最終到達目標は「オリジナルのWebサービス開発を行う」と設定しているので、Railsの基本を勉強してもらいつつ実際に集まる際にはどんなサービスを作ってみたいか・どう作っていったらいいかをヒアリングしてサービスのアイデア書き出しやER図を書いていくことなどを一緒にしていこうと考えています。

そんな感じの流れで2ヶ月続けています。上記には書いてはいませんが、勉強会の時間中にRailsGirlsガイドのハンズオンを行うといったこともしてみました。ただ、コーチ1人と参加者5,6人はかなり大変だったため、もしRailsGirlsの教材を使う際は参加者の学習状況に合わせてリモートで個別に質問対応するといった方式を取っています。

ちなみに開発環境に関してはWindowsの方はAWS Cloud9、Macの方はターミナルで基本的に進めてもらっています。

・場所

現実で集まれる場所がないと始まりませんよね。大変運が良いことに、知り合いでオープンシェアハウスを運営している方がいて、勉強会参加者の何人かがそこの居住者ということもあり、そこを使わせていただけないかお願いしてみたところ快く承諾してくださりました。ということでそこに集合してみんなでPCを出し合って活動しています。

勉強会場所として貸していただいているリビングが宴会場と思えるぐらい広い上に大きめなテレビもあるのでそこにHDMIケーブルを繋げてPCの画面を写すことができ大変ありがたいです。もちろんWi-Fiもあります。

・活動時間

できるだけ週一で集まった方が良さそうと思い金曜日の19時~21時に行っています。終わった後も雑談したりゆるくコードを書いたりしながら終電までゆっくりしています。近所のスーパーに半額以下の値段になったお惣菜をみんなで買いに行くこともあります。

・情報共有ツール

 情報共有方法は、日程やリマインドに関してはLINEのグループチャット、講座内容のまとめや個人のアイデア置き場はScrapbox、技術に関する質問対応・アドバイス・雑談に関してはSlack、といったように使い分けています。

3, 大事にしていること

・プログラミングによる物作りの楽しさを知ってほしい

参加している方の中には、「IT系のアルバイトや就職活動のために勉強してみたい」といった方も何人かいられるのですが、個人的には「そういう話は一旦置いといてまずはプログラミングの楽しさとか物作りの面白さとかアウトプットした時の快感さを知ろうぜ！！！」ということをやりたいのを最初に伝えました(私が勝手に言っているだけという部分もあって基本的に考え方は自由ですが)。

まずは、オリジナルでWeb制作を行う楽しさをできるだけ知ってもらいたくて最初の個別課題として上記に書いた通りオリジナルの静的サイトを作ってもらうことにしました。

結果として、自身が運営しているVtuberのHP*2や、自分の絵を紹介するHP、昔作った厨二病的なものをHPにまとめてみたいという人など、多種多様で面白い感じになっています。私も自分のインターネット活動のポートフォリオサイトを作りました。*3

そんな風に今後も物作りの楽しさが分かるような実践型の取り組みができたらと考えています。

・参加者の学習状況に合わせて柔軟に対応する

参加者は、以前から授業や本でJavaやPythonを触った経験のある人、Progateで入門的なことは触ったことがある人、プログラミング自体まだ触ったことがない人など、様々な人がいます。

最初はスライド講義&簡単な実践学習の方式で行っていましたが、「既にある程度の知識がある人たちに初歩的なことばかり座学で教えるのはちょっと勿体無い、それでも基礎的なことをこれから勉強すべき人たちをちゃんと大切にしなければ…」などと色々考えてみて、週一で個人のレベルに合った課題を毎回出す方式を取り入れてみました。

Progate、実はちゃんと触ったことはなかったのですがこれを機に触ってみたところこれは初学者の教材として相性が良さそうだなと思ったので始めたての人にはこれをやってもらいつつ、先ほど話したオリジナルの静的サイトに取り組んでもらっています。

進度が早い人にはRailsチュートリアルを最初から触ってもらっている流れを取り入れてますが、ただやるだけだと厳しそうなのでSlackやリアルで集まる日に重要ポイントや解説などを行っていく必要があると思います。今のところSlackで#rails-tutorialといったチャンネルを作ってそこで重要ポイント情報を流して質問対応を行っている状態です。

今後も新しい人が入ってくる可能性があるのでその度に柔軟にアドバイスできたらなーと思います。

・コーチ側が教える立場に満足しないようにする

 プログラミングスクールで3ヶ月ほどバイトしてた時期があるんですが、そこだとカリキュラムの内容に沿って教えるだけで満足して自分で何かを新しく得られない状況に陥っていた部分があったので、それは絶対に繰り返したくないなと思いながらやっています。

今の所、一緒にオリジナル静的サイトの課題に取り組んでオリジナルのポートフォリオサイトを作ってみたり、新しいWebサービスのアイデアを練ってみるなどして自分も物作りを楽しむ流れを作って実際に楽しんでいます。

4, やっていて気付いたこと・得られたこと

・基本的には個人で取り組んでもらう感じでも割と大丈夫

参加者が勉強熱心かつ調べ上手な人が多いおかげなのか、割とみんなちゃんと自分で課題をこなしてくれて何か作ってきてくれています。すごく良い振る舞いだなあと思うのでその度にめちゃくちゃ褒めています。

何か作ってきてくれた際には、「ここはこうした方が見栄えがよくなるかもしれない」「せっかくここまで作ったんだし、独自ドメインと独自SSLも実装してみたら面白いからやってみようか」と言った風にコードレビューやアドバイスを行う流れを作り、参加者が更に良いものを作れるようなコミュニケーションを行っていくことで参加者の学習を支援しています。 

・勉強したいことを一緒になって楽しむこともできる

私が今企画している勉強会自体はRailsでWebサービスを作ろうという内容のものですが、参加者の中に機械学習にも興味のある人が多かったため、夏休み中は勉強会がある日の15時から機械学習の入門勉強会もやることになりました。今週からスタートする予定なので楽しみです。

 以下の本を使いながら実践的に学ぶ予定です。 

カラー図解　Ｒａｓｐｂｅｒｒｙ　Ｐｉではじめる機械学習　基礎からディープラーニングまで (ブルーバックス)

・自分のためにもめちゃくちゃなる

 実際のところ、人々に教えるという取り組みをやってみると予想以上に得られるものがあります。

教える側に立つことで、改めて基礎的な話に振り返ってちゃんと細かく教えられるぐらい復習をしてみたり、教える際にどういった教材が使えるだろうかと模索しながら実際に使えそうな教材に改めて触ってみたり、質問で自分がまだぶつかったことのなかったエラーについて聞かれてこういう現象もあるんだなあと勉強になるなど色々得られています。

また、周囲が物作りしている姿を見て自分も刺激されて何か作りたい気持ちに駆られ、実際に何か作ることができたりと、モチベーションアップの効果にもなっています。

上記のように、参加者と一緒に機械学習を触ることも始められたりと、勉強会を始めていなかったらやっていなかっただろうなあという出来事もあります。

5, まとめ

手探りで運用を開始したプログラミング勉強会ですが、思った以上に参加者の方々が積極的に学習に取り組んでくれて何か物を作っている姿を見るとこちらもすごく楽しいし、私も頑張って勉強していこうと思えるので始めて良かったと思います。(みんな吸収力の高い人たちばかりなので何もしていなかったら追い抜かれそう……)

また、勉強会を続けて1ヶ月経った際に気付いたことがあります。

講義中、サンプルコードやチュートリアルをただ触らせて終わるのではなくて、その後参加者が自主的に動けるような流れを作って、自分が作りたいものに関する知識の学び方を身につけてもらうことがすごく大事ということです。

人にプログラミング教えるの、ただ基本を教えたりチュートリアルを触らせて終わるんじゃなくて、その後に受講者が自主的に学べる流れを作ってあげて作りたいものを作るための知識を身につけてもらうことが重要な気がしてきた

— 桐生あんず (@anzu_mmm) July 19, 2018

という気付きもあり、今現在は課題としてネットに公開されているチュートリアルをやってもらいつつも、自分が作りたいもののイメージを見据えて実際に取り組んでもらい、こちらはアドバイスをし続けることで支援していくという方式を取っています。

よく考えたらプログラミングってつきっきりで教えてもらうものではなく、自分で進めて得ていく局面が多いものだよなあと改めて気づかされました……。

教える側がやることとしては、主に学習方法のアドバイスやオリジナルのものを作り方のアドバイスやコードレビューなのかなと今は考えています。あとは、エラー文の読み方やデバッグの流れについてももうちょっとしっかりと教えていきたいです。

まだまだ始まったばかりですが、参加者がオリジナルのWebサービスを完成できるよう応援していきたいです。そして私も新しいWebサービス作るぞ！！！

そんな感じです。楽しい活動だと思うので今後も良い感じに取り組んでいこうと思います〜。

*1:コストがかかる(めんどくさいから

*2:https://nugum.net/

*3:今週中にはパブリックに公開したい……

「どもる体」(著: 伊藤亜紗)を読んで思ったこと

 

どもる体 (シリーズ ケアをひらく)

 

5月の後半に出た本で、ずっと気になっていたのだけれどなんとなく時間が取れなかったり近所の書店で探そうとしても見つからなかったので今日になるまで読むことができていなかった。もう電子書籍で読んだ方がいいな、と思って医書.jpにアカウント登録して電子版を購入してみた。

本書で印象的に残った話

 本の大まかな内容としては、「当事者へのインタビューを行いつつ、吃音のメカニズムと向き合い方を身体から探って捉えていく」といったものだ。具体的には、吃音の原因、人間の言葉の発生のメカニズム、連発から難発へ、難発から言い換えへの転換の心理状態、本書に登場する当事者たちの吃音への向き合い方などについて書かれている。

吃音治療のメソッドが書かれた医学書ではなく、吃音のメカニズムを理解しつつ当事者たちがどう吃音を捉えて行動しているかを分かりやすく考察されている。

中でも、吃音のメカニズムとして「身体がコントロールを外れた状態」にあって、自分の言いたいことが頭の中にあっても発声を思い通りに行えない状態に陥っていると説明されているのがすごく腑に落ちた。

吃音はいわゆる連発と呼ばれる、「たまご」と言いたくても「た、た、た、たたまご」と最初の言葉が何度も出てきてしまう状態から始まるとされている。

その状態に対して恥ずかしさを強く覚えたり、コンプレックスを強く感じるようになると「難発」といった、「……っ、……っ、たまご」と「連発」をできるだけ避けて言葉が出なくなる状態がしばらく続きやっと言葉が出る話し方に移行する。この状態になるととてもストレスを感じさせられる状態になると書いてあって、ちょっと共感する部分があった。

その次に、「言い換え」とされる、「たまご」が言えないために別の言葉(例えば、「鶏卵」という言葉が使えるだろう)ですぐに言い換えて吃るのを避けてコミュニケーションを円滑に図る行動に至るようになる。また、言い換えをする際はすぐに発話できるように頭の回転を高速化させて0.0001秒単位で言い換えの言葉を思いつく作業を頭の中で行なっている人もいるとのこと。

この流れに関しては、ネットに置かれている様々な文献で述べられていて多少納得はしながらも「本当にそうなんだろうか」と今まで思う部分があった。だけれど、本書では心理状態と振る舞いを細かく分析しながら連発→難発→言い換えの流れに至る過程が述べられていて大変分かりやすかった。

また、吃音を回避する手段として普段とは違う自分として演技して振舞ったり、メトロノームを使ってリズムをとって発声するといった行いを模索している当事者の人々について書かれていたのが興味深かった。実際にそれで完全に克服できるかは難しいところで、特定の人と会話する時に吃ってしまったり、中々うまくいかない状況が存在するとのこと。

「緊張しているわけではないんだけど特定の人と話すとなぜか吃音がよく出てしまう」といったシチュエーションに関してはすごく分かるものがあった。そういったことが起きるとその人といると緊張しているように相手に思わせていそうで、申し訳ない気持ちになってしまうというのもすごく共感してしまった。

また、吃音について意識しすぎて、言い換えや演技を行うことで普段の自分が出せなくなってしまう、どちらかが本当の自分かわからなくなってしまうことについて「二重スパイ」現象として説明されていたのが面白かった。

その現象から逃れるために「言い換え」をやめて多少変でもいいから「連発」をしてもいいと思うようにし、精神的に負担をかけずに生活を考える当事者の話も興味深い一方で、「言い換えをする自分もまた自分である」だと考える当事者もおり、皆吃音の克服に対して様々な対応を取っていることが最後の前の章と最後の章で言及されていた。

吃音は「身体のコントロールが効かない状態」から起きうるものだと考えられるが、吃音を気にしすぎることで、難発や言い換えを行なったり演技を行うような、所謂「乗っ取り」といった状態の流れがあることが本書を読んで強く実感させられたのだけれど、「どこまでいっても言葉がうまく出ないことに自分を振り回されまくるのって身体的にも精神的にも相当負担デカくないか……？」と一応自分も当事者の身でありながらかなり引いてしまった。それが日常的になってるから否応なしに適応しなきゃいけないのだけれど。

上記の本書に書かれた印象的な話を思い返していくと、吃音の症状は表面的には言葉が出ないといったものだが、総合的に捉えていくと吃音症とは「自己との乖離」を擬似的に引き起こし続けるものなのではないかと考えるようになった。

自分の吃音について

私も小五の頃から吃音がある。なんでそうなったのかはよく覚えてないけれど、いつの間にか連発が出るようになって、上記の流れ通りに難発が出るようになり言い換えをするようになって今に至る。

吃音についてからかわれることが多かった中学時代が一番症状が顕著に出ていた記憶があるのだけれど、高校に入ってからじわじわと克服が進み、自分に対して自信がつくスキルが得られたり、吃っても気楽に話せる友人が増えていったことで、ある程度吃る癖は残っても「話せる時は話せるし吃る時は吃るものだから色々考えすぎても仕方ないな」と普段考えるぐらいにはなった。*1

そんな風に捉えるようになってはいるけれど、実際のところ未だに現実の場で自分の吃音について話すのも話されるのもまだちょっと苦手です。話す時は基本的に空気が微妙に暗くなるし、話される時はどう反応を返したらいいか分からなくなるからだと思う。また、許容はしつつあるけれど、多分まだある程度のコンプレックスになっているのだと思う。

本書を通して、自分の吃音のことも意識して共感しながら読むことが多かったのだけれど、一方では実際のところ「体のコントロールが効かない」という土台は一緒でも、吃る頻度が全く違ったり、吃音に対しての捉え方が違ったりで、もし本に登場されている当事者の方々と実際にお会いできたとしても強い仲間意識が湧くといったことはないかもしれない、と感じている。

本書の中で当事者の一人として出てくる京都大学卒の八木智大さんとお会いしてお話したことが実はあるのだけれど、彼の吃音の傾向と対策方法と私の吃音の出方は全く違うように思えて、確かに医学的には同じ「吃音症」として診断されるのだとしても「同じ辛さと悩みを持った人」と感じられることはあまりなかった記憶がある。

なので、皆それぞれ、自分一人で自己の吃音と向き合って精神的な負担を減らしたり、克服していく道しかないのだと思う。

でも、自分以外にいる一個人の吃音者と関わることである程度の知見は得られると思うので、本書において「演技」について強く興味関心を持たれている当事者として描かれていた東大スタダリングの山田舜也さんとは一度お話をしてみたい気持ちになりました。

まとめ

全体的に自分との距離感が近い本であったので多少学術的な話が多めではあっても理解しながら読めたと思います。

読み終わってからすぐに「あっこれは感想書きたい本だな〜」と思って本を読んでからすぐにPCに向かって無我夢中に感じたことを書きちらしてしまいました。

デリケートな話題だとは思うのである程度真面目に書きましたが、この本を読んで吃音を客観的に捉えながら素で思ったことは「えっなんで人と話すためだけにこんな言い換えとか話しやすい演技とか毎回めんどくさいことずっと考えさせられなきゃならないんだ！？！？！？よく考えたらめっちゃだるくないか！？！？」ということでした。

吃音と約10年ぐらい付き合うようになって無意識にそのようなことをやっていましたがよく考えたらめちゃくちゃだるいしすごいし頑張ってますね。(褒めてくれる人がいなそうなので自分で褒めちぎる)

そういったストレスから逃れるためにも本書では「二重スパイ」の状況から逃れて自分から敢えて吃ることを避けないで、自分に負担をかけずに生きることを選ぶ人がいることも納得しました。

自分の吃音の向き合い方は今後も変化したりしなかったりだと思いますが、できるだけ吃音のことを考えてもだるくならない生き方を考えられたらいいなあと思いました。そんな感じです。

おまけ

本書の著者である伊藤亜紗さんが公開中の「志乃ちゃんは自分の名前が言えない」のレヴューをされていました。というか、今日この記事を発見して「早く『どもる体』読まなきゃだな」と思い本書を読んだのでした。

wired.jp

この記事では、「どもる体」を持った志乃ちゃんの周りにいる人々、所謂「どもられる体」の人たちの振る舞いについて言及されています。

人が吃っている姿を見て色々な対応をする人が世の中にいると思うんですが、「落ち着いて」「ゆっくり話して」と気にかけてくる人や、どもる姿を見て面白がってツッコミを入れる人もいたり、本当に色々な人がいると思います。

よく吃る側からみて「そういったことを言われるとちょっと傷つく」みたいに思うことが時折あります。でも、よく考えたら「どもられ」る人々はどもる人と関わるたびに普段あまり行われないコミュニケーションの場に遭遇しているとも言えるんですよね。

だからこそ、そんなイレギュラーな状況において完全な正解のコミュニケーション対応を常にできる方が難しいし、それに対して考えすぎてしまうのも良くないな、と最近思うようになりました。

この記事でも述べられてますが、そもそもこれらのコミュニケーションに完全な正解はないんですよね。皆人それぞれ言われて気にしないことと傷つくことがある気がするし、突き詰めていくとそれは吃音の枠を越えた話になってくるのだと思います。

「志乃ちゃんは自分の名前が言えない」、原作が本当に好きなので早く映画見に行きたい。京都だと、京都シネマで8/18~に上映開始とのことです。(宣伝)

志乃ちゃんは自分の名前が言えない

*1:これは、症状の度合いというよりは自己の吃音に対する捉え方が変化したとも考えられる

ゆるゆるライフハック第二弾 −生活習慣を色々改善してみる−

桐生あんずです。タイトルの通り今回は生活習慣を色々変えてみたお話です。

下が第一弾の記事です。ここでは部屋の中で役割分担を決めてみた話について書いています。

kiryuanzu.hatenablog.com 

変えたいこと

私は結構ふとした時に忘れ物をすることが多いです。また、よくあまり考えずに目についたところに物を置いてしまって忘れたり行方不明になってしまうケースが多いです。

例えば、カバンを持たないでコンビニに行った際に、財布や家の鍵をカウンターに置いたまま帰りそうになったり実際忘れて店員さんに届けてもらったことが何度かありました。あと逆に商品やお釣りをもらわないまま帰ってしまいそうになることもよくあります。

もう一つ例を上げると、家の中で大事な物が行方不明になる事件が発生しやすいです。帰った時、家の鍵をこたつの中になぜか入れてて探すのに10分かかって家を出るのが遅くなることが冬に頻発します。同じようにクッションの下になぜか置いていたりよくわからない場所から発掘されることがちょくちょくあります。

そういった不注意現象が多発しているので、どうにかして事前に防げないかと思い色々対策を考えて実践してみました。

以下が実践内容です。

1, 部屋の床に物を置かないようにする

とにかく床には絶対余計な物を置かないルールを実装してみました。床にゴミや本、大学のプリントなどの小物類は、ちゃんとすぐに処分したり本棚にしまったりファイルに入れておくようにしました。

特にスマホはよく使うわりに適当に床に置いて探すのに5~10分かかるようなことをしてしまうので、テーブルの上に置くようにしました。

また、ベッドの上にもよくメガネやスマホを適当に投げて探すのに時間がかかるので、このマイルールを適用して余計なものを置かないようにしました。

やってみた結果

めちゃくちゃ効果がありました。今まではつい部屋の掃除を怠ると本や大学のプリントやペットボトルが散乱してしまう悲惨な状態が発生していたのですが、このマイルールを意識するだけで部屋がめちゃくちゃ綺麗になります。スッキリしすぎて怖いレベルです。

「そんなにずっと意識してるとめんどくさいんじゃ？」みたいな意見もありそうなんですが、小学生の時によくやっていた「白線からはみ出したらゲームオーバー」みたいな遊びの感覚で物が落ちてるのを目にしたら条件反射で捨てたりテーブルにすぐ置くといったように身体に染みつかせていくと意外と癖になっていきます。

癖になりすぎて、知り合いのシェアハウスのリビングでゴミが散乱しているとすぐに掃除を実行してしまいたくなる身体になってしまったのはやりすぎな感じな気がしますが…。

応用編

これを応用して「自分の持ち物は使う必要がなかったら適当な場所に置かずすぐカバンにしまう」というマイルールを実装して、大学や友人の家等で実行するようにしたら、ものを忘れそうになることが極端に減りました。身についてくると「こんなところに置いてるのヤバいのでは」といった切迫感が発生して自然に身体が動くようになってきます。

2,重要な物は定位置に置く

元々ベッドの横にあった棚を玄関スペースへのドアのすぐ横に置いて、そこに鍵やバスの定期券を必ず置くようにしました。出かける時にはここを確認して忘れないようにし、帰った時はそれらの重要物を定位置に戻すルールを作りました。

やってみた結果

これもかなり効果があって、鍵と定期券を忘れることが全くなくなりました。今までは適当に置いていたせいで探すことになるタイムロスがあったり、「ちゃんとカバンに鍵入ってたっけ」と確認してつい手間取ってしまいがちだったのですが、ここに置くことであるかないかをすぐ判別できるようになりました。いい話。

3,重要なものはポーチに集めて入れておく

上記の2つのマイルールを作ったことである程度のことは改善されてきました。だけど、外で重要物を扱う時にまだ心もとない感じがありました。

普段はリュックサックで行動しているのですが、それに加えて小さなポーチを下げてみることにしました。

実家で買い物をしていた時に手頃な見た目でしかも1900円のものを見つけたので、まずはものの試しということで買ってみました。

この中に、財布やスマホ、定期券、自転車の鍵などすぐに使うことのあるような重要物をとにかく突っ込んでみます。

やってみた結果

最初はどうなるか不安でしたが、思った以上に生活が向上しました。何が楽かというと、リュックサックだと会計の時に財布を取り出したり、バスで定期を取り出す時にも一手間かかるのですが、ポーチの中に入れておけばすぐに手が届くし、使った後もすぐしまうことができます。

不注意を防止することにももちろん役立っていると思いますが、それよりかは外で行動する時にスムーズに動けるようになったのがかなりのメリットだと思います。

ただ一つデメリットがあります。

見た目がダサくなる!!!!!!!!!!!!!!!!!!!!!!

他にやってよかったライフハック

・Todoistでタスク管理

別にTodoistの回し者ではないのですが、Todoistでタスク管理を始めてみました。

https://ja.todoist.com/tour

タスクを「仕事」「プログラミング」「プライベート」といったように振り分けて管理することができるのがすごく便利。しかもPCとスマホ両方で使えます。

今まではiPhoneに元々入っていたリマインダーアプリでしのいでいたんですが、さすがにそろそろ限界な気がしていたのでこれを機に導入しました。当たり前ですがとても便利。*1

・B5ノートを一冊だけ用意してアイデアや仕事の細かいフローをメモする

生活習慣を直していくために色々本を読んでいたんですが、このライフハックが紹介されていて結構いいなーと思って実践することにしました。

今まではアイデアが出た時はルーズリーフやメモパッドにメモしていってファイルに挟んでおく方法をとっていて、メモがどこにあるかわからなくなることがそこそこあったので、そこらへんの問題が改善されそうだなと思います。

今は大学が夏休みなのでノートに書くことはプログラミングのことがメインですが、もう1冊用意して後期受ける授業の板書を全部そのノートにまとめておくと良さそうな気がしています。大学の授業にいくのはめんどくさいけどそれを実践したいという気持ちだけで少し大学に行きたいです。

まとめ

思ったよりもボリューミーになってしまいました。 

こうやって実践していて気付いたのですが、一回ルール化してしまうと今まで深刻に悩んでいた不注意でも思ったより簡単に改善ができます。

そう考えると、じゃあなんで今までやらなかったんだろうとなるんですが、「ミスをしても自分で深く気にすることがあまりなかった」ということが一番の理由なのかなと思います。

これは私だけではないと思うんですが、ある人がつい気にしてしまうラインの話があったとして私からみると「別に気にしない」と思うような事柄だったりで、つまりは「何かを気にするライン」が下の方にあることが多かったのかなとマイルールを作って習慣化するようにする中で気づいていきました。

そういった性格のおかげで、悪いことを深く考えずにすぐに行動を起こして得することはたくさんあったと思うし、逆に先ほど書いたような不注意を起こしてしまうもよくあって両極端だなあと思いました。

そんな風に今まで生きてきて、私自身はこのままで良くても、来年社会人になる可能性があり、もしすぐに社会に出なかったとしても何も対策を打たずに不注意を連発して今後の生活や仕事に支障が出ることがあったら思うと、今のうちにある程度直した方がいいのではと考えるようにになりました。

あと、当分先の未来になると思いますがもし結婚したり子供ができることがあって、こうした不注意を続けてパートナーを幻滅させてしまったり子供を危ない目に合わせてしまうようなことがあったらやっぱり嫌です。これは考えすぎかもしれませんが。

そういった将来のことを考えてみて、もし根本的に直すことは無理でもある程度事前対策を打つこと自体はやってて損はしないんじゃないかなと思いました。

親や友達に相談すると、「そんなに深く考えなくてもいいし、あなたはあなたのままでいいんだよ」と言ってくれて、許容してくれる人もいます。すごくありがたいし、そういった人たちのおかげで今までずっと自分らしく生きることができていると思います。（これは現在進行形ですね)

そういうこともあり、確かに自分の不注意は良くないけど気を付けすぎて今までの自分の良さが失われてしまうのも良くないと思うので、表面的に生活で困っていることがあったら直していこう、とゆるく考えるぐらいの気持ちでライフハックしていったらといいと思っています。

そんな感じのライフハックのお話でした。このエントリを読んで参考になった方がいたら幸いです。

*1:ちなみに一瞬だけWonderlistを使ってみたんですが、もうすぐサービス終了するとのことでやめました。Todoistにタスクをインポートできたので助かった。

「苦しんで覚えるC言語」でC言語を入門してみた

桐生あんずです。今年のRubyKaigiに行った際に、発表の中でC言語の話がたくさん登場し「これ、C言語を勉強した方が良いことが多いのでは…」と思い立って「苦しんで覚えるC言語」という本を買って読んでいました。

苦しんで覚えるC言語

 今までRubyしかまともに書いたことがなかったのですが(最近になってJavaには触ってみた)、C言語を触ってみて色々発見があったので書いていきます。

・インタプリタ言語とコンパイル言語について

「インタプリタ」と「コンパイル」という言葉は実際に聞いたことがあり、それらの意味をちょっと調べてみたこともありましたが、コンパイル言語(C言語)を触る自体は今回が初めてでした。

この本を読みながらC言語を実際に触っていくと、C言語は「コンパイラ」というC言語で書かれた文字列ファイルをマシン語に翻訳するソフトを使い、最終的に翻訳した機械語プログラムがリンカというソフトで結合(リンク)されることで、マシン語のデータが実行可能ファイルとなりアプリケーションとして実行できるという流れがあることを知りました。

このコンパイラの仕組みによってC言語のプログラムがより高速に動作するようにマシン語に翻訳されていくとのことです。*1

また、Rubyはインタプリタの仕組みを利用しています。インタプリタはコンパイラとは違って同時翻訳を行いすぐに実行することができます。インタプリタは速度が低速ではありますが、柔軟な構成が可能とのこと。(P46から参照)

(そして、RubyKaigiでは、コンパイル言語であることで高速なC言語よりもRubyが高速に動作するように実装を考えていた人々がいた)

実際にXcodeを使ってコンパイルしつつC言語のコードを動かしていましたがRubyとはかなり違ったやり方で新感覚でした。ターミナルを使ってgccコマンドを使ってコンパイルすることもしてみましたが、こんな手間があるのか…！ということに驚き。

・main関数は特別

Rubyを触っていると本当にカルチャーショックな話なんですが、C言語はmain関数が一番先に実行されるという決まりがあります。

#include <studio. h>

int main(void) 
{
  printf("Hello World");
  return 0;
}

こういう感じのやつです。このmain関数を軸にコードは展開されていくのですが、他の関数を呼び出す際には、プロトタイプ宣言*2しておく必要があったりなどこれらに関しても普段Rubyを書いている身からするとびっくりな出来事でした。

・静的型付けであること

これらに関しても、Rubyは動的型付け*3なので、型宣言をせずともコードを書くことができますが、C言語は静的型付け*4なので毎回変数や関数の戻り値や引数に型宣言をすることが求められます。ここもRubyではあまり出くわさないシチュエーションですね。

ここの部分の文章を書く際に動的型付けと静的型付けについて書かれた記事をいくつか見て回りましたが、どちらかが良いと断言できる話ではないと思うので私レベルの入門者がどう書くべきなのかめちゃくちゃ難しい…。
ただ、動的型付けだと書きやすいケースもあるし、静的型付けだと安心なコード設計がしやすい、と色々なメリットやデメリットの話を展開することができて本当に奥が深い話だなと思います。

RubyKaigiでも型付けの話はMatzのKey Noteで話題になっていましたね。ふと思い出して探していたらQiitaの記事でレポートされている方がいた。

静的型付け言語(typescript等)が巷では流行っているが、Rubyでの型付けについてどう思うか？という質問への回答が興味深かった。
matz曰く、静的型付けのメリット(流行っている理由)は理解しているつもり。ただし、Rubyでは型宣言できるようにする予定はないと答えた。
なぜならコンパイラがもっともっと頭がよくなって行ってコンパイル時に型を予測してくれる未来が見えるから。
もしかしたら、2040には静的型付け言語はダサい、古いと言われているかもしれない。
Rubykaigi2018 - Matz keynoteまとめ より引用

・ポインタ変数という存在

「ポインタ」という概念を知ったときもRubyでは知ることのなかった話だったので新鮮な感覚で読み進めていました。このポインタについて説明されている15章では、最初に変数とメモリの関係性についても述べています。

一言で言ってしまうと全ての変数はメモリに作られていて、番号をつけて区別しているとのことです。これも今まで意識したことのない話で、目から鱗でした。

もしかしたら基本情報技術者試験のテキストでも見たかもしれないけど、この本ではメモリの構造についての解説がわかりやすくなされていてよかったです。(メモリは巨大な1列ロッカーであり、オンとオフで管理されているという例え話がすごいわかりやすかった)

本題のポインタ変数ですが、ポインタ型*5で宣言された実際の変数です。この変数には、その元となった型の変数のアドレスを自由に代入できます。
変数のアドレスの値を記憶することができるもので、記憶しているアドレスのメモリを読んだり書き換えたりすることができます。
ここで一気にメモリやアドレスなどの概念を一気に意識することになるので、理解するまでに何回も読み返していました…。

使い方としては、「ショートカット」のようなものとのこと。
詳しく掘り下げて行くと、ポインタ変数に実際に存在する変数のアドレスを記憶しておけば、そのポインタ変数が使える場所であれば、元の変数が使えない場所であってもポインタ変数を通常変数モードに切り替えれば、元の変数と同じく使うことができるとのこと。

つまりは必要なデータを扱うための便利ショートカットツールというような扱いっぽい。
これらに関しては本当に知らなかったのでびびりました。調べて行くと、「リスト構造*6」なんてものがあったりと(よく探してみると基本情報技術者試験でもこれに関する問題出てますね)、もっと深めていくと良さそうな感じがあります。

まとめ

構造体についてやmalloc関数とfree関数についても掘り下げていきたいところなのですが、文字数が無限に増えていきそうなのでここで一旦止めておきます。最近作った技術ブログでゆるっと補足するかもしれない。

最終的に何を書きたかったかというと、C言語の実態を知ることで、Rubyだけでは知ることが難しかったプログラミング言語に関する基礎的な概念に触れることができたということです。また、Rubyの書きやすさを改めて思い知らされました。どこかのエントリで似たようなことを書いたかもしれないけど、他言語に触ってみることでRubyがいかに初心者が触りやすい言語であるかをちょっと知ることができました。

また、Rubyの学習に関しては「プロを目指す人のためのRuby入門~言語仕様からテスト駆動開発・デバッグ技法まで~」がすごくお世話になりました。これを読むとRubyの基礎がじっくり学べます。Railsをやっている人向け。

プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)

ソフトウェア開発をしていく中では、C言語に実際に触れることはなかなか少ないと思うのですが、新しい言語を習得していく中でC言語を触った経験があると学習コストが低くなっていくのではと感じました。直接的に役立つことは少ないかもしれませんが、知って損はないのかもというのが今の感触です。今後何か役立つことがあってほしい。

C言語入門が終わったところで、次は家にある「新・明解C言語で学ぶアルゴリズムとデータ構造」を読むとアルゴリズムについて深く学べて良さそうだなという気持ちがしているので、他の読みたい本と並行しつつ読んでいこうと思います。

もしくは、今サークルの活動でゲーム開発に関わろうとしているので、C#やJavaなどを改めて入門してみるのも楽しそうだなと感じています。
という感じに、今後も興味がある分野に関してどんどん掘り下げていきたいです。

*1:C言語にもインタプリタ式の環境はあるとのこと。

*2:あらかじめ先頭で関数の形を宣言しておくことで、ほかのすべての関数からその関数を使えるようにすること

*3:プログラミング言語で書かれたプログラムにおいて、変数や、サブルーチンの引数や返り値などの値について、その型を、コンパイル時などそのプログラムの実行よりも前にあらかじめ決めるということをせず、実行時の実際の値による、という型システムの性質のことであること。(( 動的型付け - Wikipedia より引用

*4:プログラミング言語で書かれたプログラムにおいて、変数や、サブルーチンの引数や返り値などの値について、その型が、コンパイル時など、そのプログラムの実行よりも前にあらかじめ決められている、という型システムの性質のことである。 静的型付け - Wikipediaより引用

*5:アドレスを記憶する変数の型

*6:ポインタ型（アドレス指定型）のデータをつないで、全体を操作できるようにしたデータ構造

父親に自分のインターネット活動を見られるようになった話

 桐生あんずです。

今週のはてなブログのお題が父の日に因んでなのか、「おとうさん」らしいです。

最近、父親とインターネットに関わることで書きたい話題があるので一筆したためてみようと思います。

今年の春休みにに実家に帰った時のことです。ふと父親のスマホを覗き込むと、Google履歴にとても見覚えのある文字列が見えました。

「桐生あんず」

私のハンドルネームやんけ！！！！！！！！！！！！！！！！

父親が「桐生あんず」ってGoogle検索してることを知ってしまって笑うしかなくなっている（このツイートもいずれ見られます）

— 桐生あんず (@anzu_mmm) March 2, 2018

2018年3月、7年近くインターネットでの活動をこそこそと続けていた私でしたが、ついに父親にインターネットの発言を見られるようになる生活に突入してしまいました。

Twitterアカウントを鍵垢にするか一瞬悩みましたが、インターネット活動が既にプライベートのものから今後のエンジニア活動に関わってくるものになり始めていたのもあり、様々な人に見てもらうために続けていきたいと考えていたので、諦めて父親にも見てもらうことにしました。今までも一応誰に見られても困らないことをアウトプットしているつもりだったし。

ということで、22歳になってついにインターネットの発言を父親に見られる日々が始まりました。

ここからは父親にインターネットを見られていることが公認になってからの印象的だったエピソード集です。

オフ会の一番最初にするような会話を父親とすることになる

インターネットのオフ会で初対面する時って「あっ！◯◯さんのことは◯◯の記事で知ったんですよね〜！」のようなどこから存在を知ったかどうかみたいなトークを改めてすることがありますよね。

最初に聞いたのはまずそこからでした。

あなたはどこで「桐生あんず」を知ったんですか…？(実際の会話のノリは「えっどこで分かったの？笑」という軽いノリでした)

あまりその時の会話のことはもう覚えていないのですが、ばつの悪そうな顔をしながら「立命館大学ラーメン研究会って調べてたらブログが出てきた」という返答をされたことは覚えています。

この記事か！！！！！！！！！！！！！！！！

kiryuanzu.hatenablog.com

思わぬところから身バレに繋がる行為をしていました。ラーメン研究会の人たちとは飲み会や旅行に行くこともあって、その話を父親にちょくちょくしていたもんね…。でも、そこから気になってインターネットで自分の娘の所属するサークル名をググり出すのは今時の父親っぽくて好きです。

子供の身辺を心配して子供が所属している団体をサーチする活動、今時の心配性なお父さんお母さんはよくやってそう。最近どっかの大学の体育会系団体が大変なことになっていたし…

心配性というと、私が1月に就職活動の一環でいくつかのWeb企業へ会社訪問を行った際に明らかに社名がわかるような写真ツイートをしたところ、「ネット活動には気をつけろよ」という忠告をボソッとされたことを覚えています。

いや、違うんだ、分かるんだけど、この界隈だとそういう発信を行ってもいい空気があるんだ…。

きっとこの頃から「桐生あんず」を追い続けていて陰ながら心配をしていたということなので、ありがたい一方で「あんなツイートやこんなツイートもチェックしていたのか…」と震え上がりそうになります。

ツイートが少ないと心配LINEが飛んでくる

体調が悪かったり、多忙だとツイートがどうしても少なめになる時があるんですが、その時にいつも「大丈夫ですか？」というLINEが飛んできます。完全に数時間単位で見られている…。

LINEを返さないとTwitterが生存確認ツールになっているらしく、Twitterでも投稿がないと心配になるらしいです。ちゃんと生きているので大丈夫です。

何らかのアウトプットをするたびにレビューが飛んでくる

父親からスクショ公開の許可をもらったのでアップしますがブログ記事を書くとこんな感じに感想が送られてきます pic.twitter.com/JA7e6D7rQG

— 桐生あんず (@anzu_mmm) June 6, 2018

RubyKaigiの時のブログの感想をLINEで送ってきました。この記事投稿して10時間も経ってないはずなんですが…。

プログラミングの勉強会を行なっている時の感想ツイートもバッチリ補足しており、ここでもやはりLINEが飛んでくる。

こうやってネット活動に対するフィードバックをもらえるのは嬉しいんですけど、それが実の父親だと地味に恥ずかしくなってきます。いや、見てくれるのはとてもありがたいのですが。

まとめと父親との関係について思うこと

主にこんな感じです。このようなやりとりがほぼ毎日ある現状です。

人によっては「こんなの恐ろしい、耐えられない」みたいに実の親にネット活動を見られることに恐れを感じる人がいると思うのですが、ちょうどプログラミング活動を行うにあたって「誰に見られても良い」というスタンスでインターネット活動をした方が都合が良いということに気付いて切り替えていた段階だったので、私の場合は今までのネット活動を非公開か全て削除したくなるぐらいのような大きなダメージは受けませんでした。

でも、初めて会う人に「桐生あんずさんですよね！◯◯の記事とかで◯◯のWebサービスで知ってます」と言われるより、実の父親に「桐生あんず」という存在をチェックされて知られているのは結構不思議な気持ちになります…。

このような関係性に関して、今も抵抗がないのはもう一つ理由があると思います。

この記事を読んでもうお気づきの方はいらっしゃると思うのですが、うちの父親、「超がつくほどの過保護」なんですよね。

それに関しては、生まれるのが遅かった子供だった(結婚して8年目でやっと生まれた)り、一人娘だったり、昔から何かと忘れ物やケアレスミスをする人間なので見ていないと不安だったりと様々な条件が重なってこうなっていると思います。

小学2年生の頃に行ったディズニーランドでどこの場所でも絶対手を離してくれなかったことを今でもすごく覚えています。小学校高学年に上がるまでずっとそうだったんじゃないかな。

また、父親は公務員といった堅実な職についており、幼少期から「公務員になったら絶対人生が安定するから」と言い聞かされて、そのまま私は深く考えずに法学部に入って最初は公務員になることを考えていました。

ただ、プログラミングを知ってしまったことで大学4回生になってからWebエンジニアになりたいという気持ちを抱くようになり、Web企業の夏のインターンシップにこっそり応募して、書類選考が通ってこれから面接をしないといけないと話をした時、今までにない以上にめちゃくちゃ怒られました。

細かく話すと面倒なので簡単に要約すると「プログラマーなんて不安定な職業は絶対にやめろ」という話でした。

その時、父親のあまりにも保守的な振る舞いに絶望して本人の前で大泣きしながら反抗の言葉を何度か放った後、と実家の自室でもう一度泣きました。

なんでここまで悲しかったのだろうと今思うのですが、やっと見つけられた自分の一つのあり方を否定されて、興味のない他の職業の選択肢を強引に提示されるという行為をずっと信頼していた父親にされたことがすごくショックだったのだと思います。

私のことを思っての行為だったのかもしれませんが、私のことを信用してくれないように感じてしまい、感情を大きく動かされたのかもしれません。

その翌日、すぐに謝られました。(父親は、私に嫌われたくないので私に落ち度がある話であっても毎回すぐに向こうから謝ってきます。本人が読む記事でこんなこと書くものではないんですが。)

その後、私が初めて作ったWebサービスを見せたり、RubyKaigiのことを詳細は隠して話して子供の頃から好きだったサービスのエンジニアの人たちと仲良くなれたことを話すと、そこそこ嬉しそうな反応を返してくれるようになりました。(こういうことを口頭やLINEで話すからネット活動バレの原因になるんですよね)

またまたその後、今のバイト先にジョインすることが決まった1月の時には、「こういうアプリがあれば面白いと思うんだけど〜」といったアイデアをどんどん話してくれるようになったり、技術者としての心得(父親は高専卒なのでそこらへんの話も好きなようです)について会話を交わすようになったりと、私がWebエンジニアになることについて肯定的な態度を示すようになりました。

その結果、今は毎日のように私のインターネット活動を監視してレビューしてくるようになってしまいました。

こう考えると様々な流れがあって面白いなあと思うのですが、反対されるよりはマシかなあと思います。多少シュールな関わりに見えますが。

留年したり、急にプログラミングをやり出して東京や広島や仙台に行き出したり、今も何かとマイペースにやろうとしていたりと、不安ばかりの娘かもしれませんが今後ともよろしくお願いいたします。

今週のお題「おとうさん」

京大マイコンクラブに4月から入会しました&OB会でLTをしました

桐生あんずです。近況エントリです。

4月から京大マイコンクラブに入会しています。

www.kmc.gr.jp

どんなサークルかということですが、上記の公式サイトの入部案内ページによると

KMCはコンピュータを使って何かを創るサークルです。

具体的にはコンピュータを使ったゲーム制作、音楽制作、イラスト制作、 Webサービス開発、電子工作をはじめとする創作活動や、 競技プログラミング、情報分野の勉強会、 そしてサーバいじり等を行っています。 また、2010年からは部誌を毎年制作し、 上記の活動等を書籍という形で公開しています。

これらの活動を部員のそれぞれが思い思いに行いながら、 仲間と意見交換し、先輩から助言をもらい、互いに切磋琢磨して行く場がKMCです。

 といった物作りサークルです。「マイコン」*1というネーミングからプログラミングサークルなのかな？と一瞬思ってしまいがちですがゲーム、イラスト、DTMなど「ものづくり」に関係することなら何でもやっているものづくりサークルです。なので物作りが好きないろんな人たちがいます。

1, 入った経緯

 大学5回生になってまで、なぜ新しいサークルに入ろうかと思ったかというと、私がプログラミングに触れるきっかけになった「1か月でWebサービスを作る勉強会」の主催者のid:hidesysさんがKMCのOBの方であり、京都のWeb界隈周りで知り合うことができたid:Pasta-Kさんやid:uiureoさんやid:sora_hさんも関わっているサークルで、そういったWebに強い人たちがワイワイしていて面白そうだなーと2017年の冬頃から思っていました。

そのような強い人たちがたくさんいそうで私のような初心者が関わっても大丈夫かな〜と思いつつ、4月に新歓があるという情報を聞き、「まだ一応大学生*2なんだしここはせっかくだから入ってみちゃおう」という半ば衝動的な気持ちで入部を本格的に考えることにしました。

ということで、Twitterの公式アカウントにDMを送り部室で行われていた新歓イベントに参加し、話を聞きつつ、周囲を見渡すとみんなパソコンをいじってゲームをしていたりコードを書いてて楽しそうだなあと思ったのでそのまま会費を払って入会しました。その後そのまま部室でコード書いてたか何か作業してた気がする。

あと、5回生だけど新入生扱いということでご飯を奢ってもらえました。良い話。

2, 入って良かったこと

KMCに入部してそろそろ2ヶ月が経ったという感じですが、その間の入って良かったことを紹介します。

2.1, ゲームを1日で作る企画に参加できた

5/6(日)にラピッドコーディング祭りという企画がありました。これは1日(実質発表時間の関係で4時間くらい)でゲームを作っちゃおうというイベントで、KMCの既存会員に方々にメンターをしてもらいながらコードを書くことができます。

今までゲームプログラミングをしたことがなくちゃんと作り終えるかどうか半ば不安な状態でこの企画に参加したのですが、id:tenさんやid:asRagiさんの手厚いアドバイスのおかげで、Processingで「アイドルの女の子が上下に移動して曲が30秒間流れていいねを稼ぐゲーム」を作ることができました。

www.nicovideo.jp

当たり判定の幅の計算で絶対値を利用するのが、しばらく数学自体から離れていた自分からするとすごい知見でした…。

そういった発見もありつつ、ゲームの流れに必要な変数や関数を定義していくことでゲームが作り上げられていくのが面白かったです。

Webサービスは目に見えてちゃんと動くものを作るのに多少時間がかかることもありますが、ゲームプログラミングの場合は、コードを書いてはデバッグを繰り返していく作業が多く、目に見えた変化がたくさんあって面白いなと思いました。

あと、発表後にお好み焼きを食べに行ったのですが、女子の新入生も混じった10人ほどの集まりで「大学最近どう？」といった世間話の会話は一切発生せず、食べ終わるまで「最初に触ったプログラミング言語」の話からそれらに関連する技術の話しか発生しない空間になっていたのがめちゃくちゃ良かったです。（言い方がアレになっていますが悪いことを言っているつもりではありません)

今はRubyKaigiの余波でC言語の基本を勉強しているので、この流れでC#でゲームを作ってみることにも挑戦できたらと野望を企てています。（アイデアはあるけど、またまたオタサーの姫ネタなので万人受けするかは分からない)

2.2, Slackでのコミュニケーションが楽しい

KMCはコミュニケーションツールとしてPukiWikiとSlackを利用しています。

後者のSlackですが、何でも質問ができる「#beginners」チャンネルやメイン雑談の「#active」チャンネルを始めとして、「#◯◯(会員のID名)-memo」といった会員の分報チャンネルといったものまで存在します。もちろん競プロやゲーム作り、お絵かきについても好きに話せるチャンネルもあります。そのほかにも、たくさんのチャンネルが存在しておりとても賑やかです。KMCのSlackを覗くのが最近の良い暇つぶしになっています。

また、バイトや他の用事の関係でリアルの活動に参加できなくても、会員の方々がどのようなことをされているかをネットでチェックすることができるのでとてもありがたいです。

後、自分も「#kiryuanzu-memo」という分報チャンネルを作ってみました。Twitterで呟くほどではないけど言いたいことがある時に気楽に使えるので楽しいです。進捗報告などにも使ってます。 また、自分が作っているサービスについての助言やフィードバックをもらうこともできて、パブリックに出す前にも人から反応をもらうことでモチベーションを保って開発を進められるというメリットがありました。

2.3, 部室と新歓飲み会とOB会

リアルでのKMCとの関わりですが、バイトや授業の関係で平日の20時以降に部室に遊びに行ってコードを書いたりお酒を飲ませてもらったりボードゲームで遊ぶといったことをちょくちょくやっています。今月はまだ行けてないのでそろそろ遊びに行きたい。

部室に遊びに行くと、ゲームに集中している人もいれば、コードを書いている人、技術の話をしている人、お酒を飲んでいる人、ボードゲームをやろうという誘いを人々に持ちかける人、色んな人がたくさんいます。

その中で好きにコードを書いたり、何か別のことをしたくなったら他の人に構ってみたりすることができて居心地がとてもよくて好きです。

交流系のイベントだと、新歓飲み会とOB会にも参加させてもらいました。新歓飲み会では、SlackやTwitterでしかまだちゃんと関わっていなかった人と話すことができたり（オフ会っぽい)、2次会では京都Web界隈おなじみと噂のDEN-ENでタワービールを眺めることができました。

DENENでタワービールを眺めています pic.twitter.com/wHQlm6eCIk

— 桐生あんず (@anzu_mmm) May 19, 2018

OB会では、恥ずかしながら先月開発したCrash ChatについてのLT発表をさせていただきました。

OB会の数週間前にSlackでLT発表者を募集しており、よくわからないままノリで手をあげたのですが、会場に入ったところ有名企業に勤めていらっしゃるエンジニアの方々や自分で会社を運営されている方が沢山いられる空間でめちゃくちゃびっくりしました。

その空間の中、「サークルクラッシュをご存知ですか？」というスライドを見せてウケが取れたので私は満足です。

(最近のKMCについての紹介LTが続く中、謎の制作物についてプレゼンをする発表をしてしまい他の発表者の方々に申し訳なかった気持ちもある)

Crash Chat制作話 from Kyoka Fujiike

www.slideshare.net

そんなことがありつつも、この発表のおかげでOBの方々に顔を覚えてもらい「面白かったよ」とのコメントを数人の方からいただくことができました。

また、来月も大阪Ruby会議01でLTをする予定(今からめちゃくちゃ緊張している)なので大人数の前でLTをする時の感覚を多少つかむことができて良かったです。

ちなみに、新歓飲みでもOB会でも飲み会終わりに鴨川に行きました。他のエンジニアコミュニティでもあるけど、なんだかんだで最終的にみんな「川」へと集まってしまう流れ、個人的にとても好きです。ちょっとしたエモさに溢れてる。

4,まとめ

今までIT系のコミュニティに関わる時は、勉強会やカンファレンスがメインだったので現役エンジニアさんなど少し年の離れた方々と関わる機会が多かったのですが、KMCに入ったことで同年代で物作りに興味のある人たちと関わる機会を作ることができたのが本当に良かったなと思います。

同年代といっても様々で、プログラミングだけに限定しても、これからプログラミングを始める新入生や既に高校生の頃からコードを書き続けている新入生、ゲーム制作をバンバンやってパブリックに公開している会員の人、競プロをやりまくっている人、電光掲示板を作る人、ISUCONやCTFに興味がある人、SlackBotを作っている人、インフラにとても強い人たち、Javascriptに強い人、PythonやRubyをメインに書いている人、多種多様です。ぶっちゃけ全部紹介しきれません。

関わり始めてまだ2ヶ月ほどですが、会員の人それぞれがみんな何か興味があって面白いな〜と思います。もちろん物作り以外にも、ゲームやアニメ、Vtuberなどを追いまくっている人もいて、好きなことを追求してて良いなあと思います。

なので、思い切って入ってみて良かったです。夏休みも近いので今後も良い距離感で活動に関わっていけたらと思います。

そんな感じの近況でした。

*1:マイクロコンピュータの略称。いわゆる今のパソコンみたいな存在。私のお父さんの世代で使われていた言葉の模様

*2:なお、KMCは大学生じゃない人も入れるらしいです

Ruby歴1年の文系大学生がRubyKaigi2回目に行って感じたこと

桐生あんずです。タイトルがなんか長々しい感じになっててすみません。

1,はじめに

去年のRubyKaigiでの出来事に心打たれて、5/30(木)~6/2(土)に仙台で行われた今年のRubyKaigiにも参加してきました。

rubykaigi.org

また、今回は永和システムマネジメントさんの学生支援により交通費・宿泊費・参加費等を全額負担していただき参加することができました。本当にありがとうございました。

また、宿に関してもえもり(@emorima)さん主催の貸切ゲストハウスに泊まらせていただくことができ、女性Rubyistの方々と楽しく5日間を過ごすことができました。関わっていただいた方々本当にお世話になりました。去年も行われていたRailsGirlsJapanさんの支援で来られていた方々にもそこでお会いすることができ大変嬉しかったです。

今回の記事では、去年感じたことと比較しつつ個人的な話も含めて思ったことを書いていこうと思います。

2,「RubyKaigiはRubyistによるRubyistのための祭典である」

最初から何を言っているんだという話なのですが、登壇されている方全員が本当にRubyが「大好き」なんだなということが伝わってくるカンファレンスです。

去年は正直、Rubyに対する知識もあまりなく「なんだかめちゃくちゃ難しいことをしているんだな…」という気持ちで発表を唸りながら眺めていることがたくさんありました。今回も、難しい内容がたくさんあり、全員の方の発表内容を完全に理解したとは到底言えないのですが、毎回強く感じることがありました。

「ああ、この人たちは本気でRubyに関わるあらゆることに対してよりよく、面白くしようとしているんだ…」

RubyのC言語拡張、iSeqへの追求、JITコンパイラの最適化手法、irbに関わる実装など、Rubyの内部のあらゆるものに探求し、よりよくしようとOSS開発や実装を行なっている人たちが何を考えてどんな取り組みを行なっているかを発表を通して生で見聞きすることができるのがRubyKaigiの最大の特徴だと思います。

MatzとRubyコミッターの方々によるトークタイムのイベントもあったのですが、ここでもRubyの機能の実装の裏側でどんなやりとりが繰り広げられているかを垣間見ることができる大変面白い時間でした。

去年は「なんか面白そうなことをしているんだなー！」とワクワクフワフワした気持ちで眺めていることが多かったのですが、「あっこの人たちはRubyに対して本気(マジ)になって向き合っているんだな…」と去年よりもRubyに対する知識が深められていたからこそスピーカーさん達の恐ろしさを知ってしまう場だったと思います。

3,技術学習に対するモチベーションが上がった

参加して感じたのは、Rubyのカンファレンスではあるけど「あっこれC言語のこともっと知るべきだな」ということでした。 

Rubyは本当に書きやすい言語で、初心者にもオススメの言語としてよく紹介されており、私も最近、JavaやGoに触れてみてそう紹介されている理由が分かってきました。最初にRubyを始めるのは良い選択だと個人的には思いますが、RubyのありがたさとRuby独自の特徴を根本から理解するためにはのはC言語等の他言語のメリットやデメリットを知ってからなのではと今回のカンファレンスを通して強く思いました。

会期中もRubyの処理のスピードに対してC言語の処理スピードと比較している発表が何個もありました。それらの発表を見ているうちに、Rubyの便利さや特徴をもっと知るためにもまずC言語と仲良くしたいな、という気持ちがじわじわと強まっていき、我慢できずに帰り道に立ち寄った本屋で「苦しんで覚えるC言語」を買いました。

苦しんで覚えるC言語

今100ページ近くまで読んでいますが、簡単な概要のパートでも「えっこんなことも用意して書かなきゃいけないの…?Ruby簡単に書けすぎなのでは…!?」と驚きの連続にぶつかっています。（こういうこと適当に書いて怒られたら怖い)

4,同年代のRubyistと知り合うことができた

会期中は私と同い年のRubyistの子達とも会うことができました。

その中で知り合った女の子の2人は、高校の頃からRubyを知って高校卒業してすぐエンジニアになってRuby技術者認定試験Goldも持っているとのことで、大学4年でRubyを知った自分からするとカルチャーショックを受けました。

そういった比較的早く学習して実際に仕事をしている子と自分を比べて焦るのはあまりよろしくないとは思うのでそれでマイナスなことを考えるのはやめましたが、同い年でここまでやっている子がいるのだから、私もこれからも頑張らなきゃとつい思ってしまいました。

なので先ほどのC言語教本と一緒に「Ruby技術者認定試験合格教本」を買いました。Silverの問題をさらっと見た感じ、そこまで厳しい内容ではなさそうだったので、近いうちに試験を受けてみようかなと思います。(実は前ブログに書いた基本情報技術者試験も就活の忙しさに流されて受けられてないので両方ともちゃんと受けたい)

[改訂2版]Ruby技術者認定試験合格教本(Silver/Gold対応) Ruby公式資格教科書

 また、同年代のRubyistとしてインパクトがある存在はやっぱりそらはーさんでした。同年代として比べて良いかすらも分からない存在のお方なんですが。(中学生からRubyのコミッターをやられている方です)

会期中に会うたびにネットワーク班の人たちと一緒になってワイワイ話したり、ESMのドリンクアップの時に酔っ払いのノリでツーショットで写真を撮りました。すごく楽しかったです。次はKMC(京大マイコンクラブ)のOB会で会えるとのことなので楽しみです。(ブログではまだ言ってませんでしたが最近京大マイコンクラブというコンピュータサークルに入りました。それに関する記事もまた書きます)

5,「物作り初心者」じゃなくて「物作りをする人」と言えるようになります

これは個人的な話（言ってしまえば「エモ」い話)なので、そういうのが苦手な人は読み飛ばしてもらって大丈夫です。

去年のRubyKaigiでは当時開発していた「布教箱」の初期段階を見せたところ、様々なフィードバックをもらうことができて、「独学で一人でここまで作ろうとしてて偉い」といった初心者ゆえの頑張りを褒めてもらう機会に恵まれ、今まで頑張ることができました。

最近2週間ほどかけて作った「Crash Chat」(オタサーの姫の人工知能APIと会話することができるRailsで動かしているWebアプリケーションです。好意的な会話をしすぎるとブロックされる仕様のネタがあります。)

www.crash-chat.net

のベータ版に対しても会期中に直接好意的な反応をもらえて大変嬉しかったです。実際今の所約800回以上は遊んでもらえている模様でherokuのデータベースの無料枠を超えそうになっていてどうしようか悩んでる状況です。

そんは話は置いといて、プロダクトを完成させてパブリックに公開できることまでやるようになったけど、フロントエンドやデザイン周りのスキルもまだ乏しい状況で、「遊び」で作った感が強いプロダクトしか私はまだ作れていない状況だと思います。

今回のRubyKaigiでもエンジニアの方々に「発想が面白いからもっとフロントやデザインにこだわって作ったらもっと良いものが作れると思う」といったアドバイスをいただくことがありました。

その言葉を受けて、もう「作るのが偉い初心者」の段階は終わって、「高い品質のプロダクトを作ることを心がける技術者」の段階にそろそろいかなければならないんだと気付きました。

そうなっていくとCやRubyの学習意欲も高まってきたけど、フロントエンドやデザインの勉強も必要だという感じです。これに関しては個人開発以外にも今のバイト先でも頑張らなきゃいけない部分なのでまだまだやること盛りだくさんです。

でもまだ学生なのでほどほどに勉強する時間はあります。やっていきましょう。

6,終わりに

今回のRubyKaigiを通して思ったのは、すごい人たちと関われて話せるだけでもすごく嬉しいけれど、その人たちともっと深みのある技術の話やプロダクトの話ができるようになりたいということでした。

前回は「初心者なのにすごい人たちと話せてる、めっちゃ嬉しい」という手の届かない人たちと関わって気持ちが高ぶっている感覚で過ごしていたと思います。

でも、前回知り合った方々や今回初めて知り合った様々な技術者の方々と関わってみて「自分もこの人たちのように自分が好きな技術を追求できるエンジニアになりたい」と強く感じ、イベントに参加してすごい技術者の人と仲良くなるだけではなく、今後も良い影響を沢山もらって自分自身が技術のことをもっと追求する人になっていこうと強く思いました。

という感じに、今までは人に触ってもらえるコンセプトのサービスを作ることに焦点を当てて、コードを書いていたけれどプログラミング言語の内部構造や処理速度の話にもアンテナを張って勉強していきたいと思うようになったのが今回参加してみて一番大きな心境の変化だと思います。

その取り組みがプロダクトに直接繋がるかどうか分からないこともあると思いますが、品質の高いプロダクトを作ることにいずれ繋がっていく気がしています。

そんな感じで今後もプログラミングと楽しく付き合っていこうと思ったRubyKaigi2018でした。

あと、今年は風邪引いて川に行けなかったので来年は絶対川に行きたい！！！！！！！！！！！！！！！！！！！！