忙しくなったので朝活とかマインドフルネスとかそういうのをやり始めたよって話。

4月になりました。 最近テクニカルなことがなかなか書けていないなあと反省してるんですが、本業がエンジニアと技術広報という形になったので普通に忙しいです。 あと会計サービスの宿命として年度末年度始まりは大変というのがあるのでそういうものと割り切るしかないなーって思ってます。

で、いままでは夜に自分の時間を確保するように働きかけてたんだけどもこれがうまくワークしなくなってきました。 単純に自分ではコントロールできないタスクが増えてきて、確保できたりできなかったりで安定しなくなってきたので最近朝に自分の時間をとって使うようになったよ…という話です。

元々フロントエンドに課題を感じていたのでそれを学ぶ社内勉強会を1年ほど行ってきました。 その結果として元々は「ES5 is なに?ES6となにが違うかわかってない…。」という状況から React + RecoilでGitHub APIを叩いてモブプログラミングしてみよう!やNextJSがわからんのでGetting Startedをやってみよう!というところまで来ました。

毎週1時間を1年やるだけでそこそこ成長できるんだなってことがわかり大変良いので時間がなかなか取れないかたにはおすすめです。 朝に勉強するのはリモートが前提になったいまだと非常にやりやすくてよいです。

朝活を福岡拠点メンバーが開始しているのをみつけた同僚が真似をして始めたことがきっかけでマインドフルネスに入門しました。 数人でzoomごしにマインドフルネスを毎朝15分〜20分ほど行うだけなのですが脱力によって肩のこりや腹筋など身体のこわばりが解消される感じがあり、胡散臭さを感じていたんですが現在社会は慢性的にストレスに晒されるのでその息抜きをするための訓練なんだなーということがわかってきました。

さきほどとは別の同僚からGoogleの「Search Inside Yourself」がめちゃくちゃいいので未読なら読むといいですよ!という話を聞いていま読んでる最中です。 だいたい3割くらい読みました。マインドフルネスってそういう感じでいいのね!と感じながら読んでるのですが結構いい感じです。今週末あたりに読み切ってしまおうと思います。

あとリモートワークが主になってからまあ運動しなくなったので太りました。 ちょっと本気でまずいなと思うレベルで運動不足になっているので雨以外の日は出来る範囲でジョギングやウォーキング、柔軟をやっていこうと考えて今晩から初めてみました。

無理のないレベルでまずは運動習慣を身につけることを目的としてやっていこうと思います。

なんかそんな感じで最近いい感じに忙しいです。

個人ブログを作ったという話

TL;DR

いわゆる表題の通り…というやつ。

作ったものはこれ。

technogears.dev

構成は以下

  • Hugo@v0.79.0
  • netlify

デザインは MeiK2333/github-style を採用させてもらった。 特にデザイン関係はいじることなくほぼそのまま。

github.com

なぜ今更個人ブログを作ろうと思ったのか?

すごく単純な話で技術情報を載せる投稿先が見つからなかったから。

Qiitaを以前はその用途として使っていたのだけど、いろいろと思うところがありサービスの将来性と自分のやりたいことが交わらないなと感じて退会をしました。

その後zennなどもよいなと思ってアカウントはとっていたのですが最終的に「これも次世代のQiitaになるのではないか?」という点を払拭することができませんでした。

zenn.dev

なのでWordPressは選択肢としてないけど、Hugo + netlifyを最近よく目にするしサクッと作れるらしいのでやるかー!となって作ったのでした。

完全マネージドサービスは諸々楽なんですが、個人の思想が色濃くでる技術ブログには向かないなと感じたから…が見出しの回答になります。

サクッと作れた?

いやそうでもなかった。 Hugoで作る部分はうまくいっていたがnetlifyにあげたところ、CSS/JavaScript/Imageあたりがうまく参照できずなんでだー!となってました。

そのあたりの経緯はログを残しながらついでにPostしているので興味があればどうぞ。

technogears.dev

実際使ってみてどう?

Hugo、手元で確認してGithubにpush、確認がとれたらマージしたらnetlifyに反映…ということで体感的にはすごくいいです。

netlifyでドメインを取得することができたのでほぼこの3つだけで環境が完結するので管理するコストが低いのが最高ですね。

ただWeb上から直接編集する…みたいなことができないので思いついたときにシュッとブログ書くみたいなことができないのが少しネックかも。 でももともとやってないからこれは無視できるかな。

Notionも検討したけど自分の使い方的にはInkdropのほうが好みだしわかりやすい。

Scrapboxのアプリ(Electron製とか)があれば理想的なんだけどなーという気持ちも無きにしもあらず。

まとめ

ということでQiitaは退会してしまっているのでもう記事の編集やコメント、削除などが行えない状態です。

それでもまるでアカウントが生きている状態のようにみえてしまうのはさすがになんとかしてくれと運営にいいたいところですが、それはさておき新たな旅立ちをしたのでよろしくおねがいします。

購読機能とかあるといいんだけどまあそりゃー無理だよね。

Go Study

TL;DR

この記事はMoney Forward Kyoto Advent Calendar 2020の10日目の記事です。 本日の担当はluccafortでお送りします、なお本日誕生日なのでご祝儀シェアをお願いいたします :bowc:

adventar.org

今日はRailsエンジニアがプロダクトでGo言語を習得するために行ったインプットやアウトプットのご紹介をしたいと思います。

オンラインコンテンツ

  • A Tour of Go
    • 過去にサラッと読んだことはあったのですがどこまで覚えているか不安だったので再入門しました。
    • Rails Tutorialsにも感じたことですが、初心者が学習するために必要なものをチュートリアルとして公式で用意してくれているのは非常に助かります。
  • プログラミング言語Go完全入門
  • uber-go/guide
    • GoにおけるベストプラクティスやよりBetterな書き方、そしてBadな書き方が記載されているので「このケースのときどう書くのがいいんだろう?」がわかりやすくまとめられているのでおすすめです。
    • 日本語版を翻訳していただいてるかたと知り合う機会にも恵まれて最高でした。

イベント

Go関連のイベントやカンファレンス、勉強会などに参加しました。 独学だけでは知ることができない点や議論をすることでより理解が深まることを期待して参加しています。 あと単純になにか新しいことを知ったり、学べることは楽しい!というモチベーションの維持の面もあります。

  • 社内のGoエンジニアの勉強会に参加
    • いままでGo言語は独学&誰かにレビューしてもらう、ということがなかったのでこの勉強会で課題を出してもらい、それを解くという形で進めてもらったのが体験としてよかったです。
    • 課題の答え合わせや質疑応答、議論をGoを習得したい熱量が高いメンバーと一緒に行えたので脱落することなくやりきれたかなと思います。
  • MoneyCon(社内ISUCON)
    • ISUCON10の開催が決まる前に社内ISUCONが開催されました。当時まだGoを学び始めたばかりのメンバー2名+Goを習熟しているメンバー1名で参加しました
    • せっかく学んだ技術なので使わないともったいない!Give it a tryだ!!ということでGo言語を無謀にも選択したのですが結果は思ったより悪くなくて成功体験として実績を積めたのは非常に大きな経験でした。
  • ISUCON10にGoで参加
    • 社内ISUCONでの成功体験に味をしめて同じメンバーで参加してみました……が結果は惨敗でGo言語がどうこうではないレベルとGoの習熟度が高ければもっと貢献できたなという悔しい思いをしました。
    • 社内の他のエンジニアも参加して本戦突破していたので次回は本戦突破できるようきちんと過去問を解いてリベンジしたいと思います。
  • Kyoto.goを主催
    • 関西にはUmeda.goがあります。
      • 京都にも気軽に平日夜に参加できるコミュニティーがほしいなと思って作りました。
      • Goコミュニティーの懐の深さとコミュニティー運営の難しさを実感しています。
  • GopherCon 2020参加
    • 初海外カンファレンスに参加しました、単純に英語わからなすぎる問題やGoの理解度が追いついてない問題など、自覚している課題を強く意識するよい機会になりました。

書籍

読了したもののみを記載しています。 買ったけどまだ読めていないものはいっぱいある……いっぱい。

  • Go言語による並行処理
    • 同期的プログラミングをいままでしてきたのでgoroutineのような並行プログラミングをあまり経験しなかったので購入しました。
    • どういう点に気をつけるのか?どういうときにgoroutineを使うのが有効か?が知りたくて読了しました。
    • 社内の輪読会イベントがあるのでより理解を深めることができそうだと期待しています。
  • スターティングgRPC
    • GoだけではなくgRPCを理解するため、そしてgRPCを介してGoとRubyをどうやって通信するのか?という点を学習したくて購入しました。
  • Goのポインタを完全に理解する本
    • 技術書典で見かけてGoのなにがわかってないのだろう?というお気持ちになったので購入。少なくともポインタは理解してそうだという確認ができました。

Go言語による並行処理

Go言語による並行処理

booth.pm

まとめ

今年1年を振り返るとそれなりにGo言語に投資してきた感がありますが、まだまだ不足していると感じています。 来年はもっとRubyの比率を減らして、Goの比率を上げていきたいと考えているのでそのときまでに必要なインプットは完了させておきたいと考えています。

反面、手を動かさずに物事を覚えられるほどぼくは頭がよろしくないのでデザインパターン再入門を兼ねてGoで実装してみる、を試してみようと考えています。 ちなみにやろうとしていることはすでに先駆者のかたがいて実践済みだったりしますw

github.com

本を読書する技術

概要

Money Forward Kyoto Advent Calendar 2020の5日目、バックエンドエンジニアのluccafortでお送りします。

adventar.org

このエントリは読書する習慣を身につけるテクニックを紹介するエントリになります。 読書によって得られた知識は経験を媒介することで誰にも盗むことができない財産になります。 皆さんの財産が世の中のマネーをフォワードする一助になるとよいと思い、このエントリを書かせていただいています。

結論から

まず結論から。 このエントリは以下の書籍から得られたことや試したもの、読書を継続するのに重要そうな要素を抽出したものとなっています。

ですので、もし興味があるかたはこれらの書籍をお読みになられるほうが早くより正確だと思います。 ぼく個人としてもそちらをおすすめ致します。

学習効率のよい読書術を求められているかたは↓がおすすめです。

エンジニアの知的生産術は難しくてわかりにくかった、というかたには↓がほどよいかと思います。

想定される読者層

  • 読書が苦手なひと
  • 読書習慣がなく、身につけたいと考えているひと
  • ただ読書をするだけの状態を打破したいひと

発端

以前とある雑談の際に「いつそんなに本を読んでいるんですか?」という質問を受けたことがありました。 (おおよそですが、技術書で月に1〜2冊、一般書籍や自己啓発めいたものを含めると月に5〜10冊ほど読んでいます。読んでいる数そのものは決して多くないです。)

ぼくだけに向けた質問ではなかったのですがそのときたまたま「よく本を読む人」と「あまり本を読まない人」が半々くらいにわかれていて、「何故読書するのか、また読書する習慣を身につけるHowToにも価値がある」という気づきを得ました。 そのうちブログに書いてやろう!と思っていたところ、アドベントカレンダーでチャンス到来したので書かせてもらった、というのが発端です。

ぼく自身は決して読書の虫というわけではないのですが、それでも比較的本を読む習慣があるのでいわゆる「読書を楽しむことができる人間」側に属しています。 そこで現代社会の時間が限られた人間が本を読む時間を捻出するために実践しているいくつかの技術を紹介したいと思います。

前提条件

ここでいう読書とは読むことで「何かしらの知識を得られること」を前提とします。 ですので、娯楽小説などは後述する方法で読む必要はありません。 自分の読みたいように読んでいただいてよろしいと思います。

なんのために読書するのか?

まず本を手にとった、あるいは購入した理由を考えましょう。 なにを期待して本を手にとったのでしょうか?

なにか現状を変えること、あるいは変える可能性を期待して手に取るかたが多いかと思います。 その当初抱いたゴールを付箋やホワイトボード、ブログ……etc 媒体は何でもよいですがしっかりと言語化しておくことでより深く、脳がゴールを意識し効率がよくなります。

またゴールをしっかりと明確にすることで漫然とただ読むことを防止する効果があります。 可能であれば読書する前後でゴールが確認できるようになっているとよりよいでしょう。

ぼくはホワイトボードにカンバン形式でいま読んでいるもの、次に読もうとしているもの、読んだものを管理しています。 (カンバンがわからないかたは下記のwikipediaをご覧ください。)

ja.wikipedia.org

他にも制約として1ヶ月の間に買える技術書は3冊まで、ただし読了した技術書2冊につき追加で1冊購入できる…という縛りを課しています。 これらの管理や制約によって読む技術書の冊数や読みたいものをコントロールするようにしています。 ただこれはぼくにとって最適化されている手法なので人によっては合わないです。

他にも挫折してしまうケースとして、購入した書籍によっては自身が望むレベルに達していない、あるいは難解過ぎるということがあります。

そのようなケースで無理をして読む必要はありません。 いま読んでいる本はゴールに向かっているか?読書の前後で振り返りができるようになっているとレベルがあわなかったときの気づきを得るきっかけを作ることができます。

何故習慣化させるのか?

まれに勘違いされるかたがあるのですが、本をたくさん読むことが大事なのではありません。 本を読むことでゴールを達成することができるのであるかどうかが重要なのです。 その結果としてたくさんの本を読むことはあるかもしれないですが、たくさん読むことが目的化しないように注意しましょう。 大事なのは量を増やすことではなく、質を高めることです。 質を高めるのに量が必要でなければ量は必要ありません。

いつ読書するのか?

いつ読書するか?これは難しい問題です。 というのも読書する習慣がついているかたごとに「いつ」が異なるからです。

一例としてぼくの場合ですと以下のときによく読書しています。

  • 駅や電車、病院などの待合室
  • 休日の昼間、なにも予定がなくゆっくりしたいとき
  • お風呂に入っているとき

読書する習慣がないかたはあらかじめ本を読むルーティンを決めてしまうことをおすすめします。 読書する時間を決める、というよりは「就寝する30分前に読む」「通勤電車の中で読む」などの何かしらのアクションをトリガーとして読む時間を確保すると続きやすいです。

このとき「毎日22時から1時間読む!」としてしまうとできなかったときにネガティブになったり、 義務感になってしまい疲れてしまいます。

仮に今日は5分しか読めなかった、というケースでも問題ありません。 30分だけ読もうと思ったがもう少しで読み切れるので5分延長するなど人間は思った以上に時間にルーズです。 ですからゼロにさえしなければ習慣化され、ストレスなく読むことができるようになっていくでしょう。

まずは2週間、可能であれば1ヶ月続けてみましょう。 途中どうしても時間を確保できず中断してしまったとしても問題ありません。 できる範囲で習慣化していきましょう!

何故1ヶ月か?についての根拠は以下のTEDにおける動画が非常にわかりやすく、やる気を促してくれるのでおすすめです。

Matt Cutts: マット・カッツの30日間チャレンジ


マット・カッツの30日間チャレンジ

ただし可能なら1週間以上間を空けるべきではありません。 個人的な経験による確信ですが1週間やらなかったことは脳内で「やらなくてもよいこと」として認識されてしまうように感じています。

読書しても忘れてしまう…

読書しても前回から間が空いてしまって忘れてしまうことはないでしょうか? ぼくはよくあります。

忘れてしまうこと自体は決して悪いことではありません、ありませんが良いこととはいいがたいですよね。 特に読書した内容についてであれば、なおさらです。

忘れたくて忘れているひとはまれだと思うのでどうすれば忘れにくくなるのか?というアプローチを紹介します。

脳は「2週間に3回使った情報は、長期記憶される」という性質があるそうです。 これは冒頭で紹介した「学びを結果に変えるアウトプット大全」の中で「アウトプットの基本法則1」で紹介されている内容になります。

面白いのは1度きりだと2週間でも1ヶ月でも大きな差がなかった、という結果がでているそうです。 (1週間と2週間では明確に数値が違うのに!)

ぼくは基本属性が怠け者なので予定として抑えておかないとすぐに怠けてしまう傾向があります。 そこで本当に大事で忘れたくないと考えているときは同じ本の特定の章だけでを初日、7日後、14日後の3回読むようにしています。 翌日にはその次の章を、更に翌日にはその次の次の章を…という感じで特定の章だけを読む日を設けるようにしています。

可能であれば2週間後にこのインプットした情報をブログでもノートでも付箋紙でも構わないのでなにかにアウトプットするとより高い効果が見込めます。 これも「学びを結果に変えるアウトプット大全」の中でアウトプットの基本法則2として紹介されている内容となります。

インプットの反復だけではなくアウトプットすることでより強固に「脳にこれは重要な情報である」と教える必要があります。 機械学習は詳しくないですが仕組みとしては強化学習と同じだと考えています。

まとめ

完全に自己啓発する怪しい話になってしまった気がします。 「読書する」ことはスキルで補えます。

昨今だと「努力するものは楽しむものに勝てない」という論調があります。 これ自体は事実であると思いますが、努力することは無価値ではなく、それどころか素晴らしいことです。

楽しめるようになるために努力していくというアプローチもあるでしょう。 本を読書する技術を身につけることで「努力する」から「楽しむ」ことができる一助になるとよいなと思い今回アドベントカレンダーに参加させてもらいました。

本は買うことに意味があるのではなく、本を読み、知識として取り込むことで価値を最大化します。 この知識には「知らなかったことを知る」ことや「自分がわかっていないことがわかった」ことも含みます。 もちろん本に書かれた内容が全て理解できる必要はありません。 いままで認識できなかったことが認識できればそれは十分に読書の価値を得られていることになります。

最後に宣伝

マネーフォワードでは福利厚生の一環として「書籍購入補助制度(まねふぉ図書館)」というものがあり、理由が常識的なものであれば同じ書籍を複数冊購入してもよいという非常に嬉しい制度があります。 このおかげで輪読会や読書会なども活発に行われているのではないかと思います。

その他にもさまざまな福利厚生や制度があるので気になるかたはこちらを御覧ください。

corp.moneyforward.com

この話をみて興味を持っていただけたかたは是非カジュアル面談などでお話をしてみてください!お待ちしてまーす!

マネーフォワード京都開発拠点のサイトがあります。 もし京都拠点に興味を持っていただけたらこちらもみていただけるとよりぼくらを知ってもらえるのではないかと思いますので、年末のお供にご利用ください。

kyoto.moneyforward.com

明日はマネーフォワード京都でインターンをしてくれている Ken さんのインターン生から見た京都拠点のお話です!お楽しみに!


今年も本家アドベントカレンダーもやっています!

adventar.org

京都アドベントカレンダーはこちらです。

adventar.org

京都開発拠点では引き続き積極的に採用を行っております。ご応募お待ちしております!

マネーフォワード京都開発拠点

kyoto.moneyforward.com

中途採用 | 株式会社マネーフォワード京都開発拠点

kyoto.moneyforward.com

インターン | 株式会社マネーフォワード京都開発拠点

kyoto.moneyforward.com

GopherCon2020の個人的注目ポイントなどを抜粋してみた…の巻。

TL;DR

先日社内で↓のようなエンジニアブログを書くので協力お願いできませんか?という話があり「よっしゃ!!!」と二つ返事をしたところ、思った以上の量になってしまった。 会社ブログのほうは抜粋されたものが掲載される、ということだったのでより詳細なものは個人ブログで書いてしまおう、ということになりこっちでも個人的なGopherCon2020の「これは聞いておきたい!」と思ったものを勝手に紹介していきます。

moneyforward.com

あまり意識したことはなかったけども、RubyKaigiやPHPConferenceなどの大きなカンファレンスに参加するときは無意識に「これをみる、何故ならこういうことが知りたいから」みたいなメモを書いてることが多い事に気づきました。 まあこれはあとでブログ書くときのネタにするため、という側面が強いけど。

GopherCon2020で何を得たいと考えているか?

期待することとしては大きくエンジニア視点で3つ、個人として2つ。

Goに対する理解を深める

どういう課題を解決したいのか? 何故そうなったのか? その背景はなにか?

これらを理解することで実際に自分たちがそれらの言語仕様を使って何かを実装するときにとり得るアプローチに差が出ると思います。 知識の補強、そして背景への理解、よりよい最適解への道筋などの知識理解度を深めることを期待しています。

GopherConに参加することを通してMF内でGoのプレゼンスを上げる

マネーフォワードの京都開発拠点では主に同僚が主体となって活動してくれていますが やはり世間一般のエンジニアにとってマネーフォワードといえば?と聞くとどうしてもRuby/Railsなイメージが強い。 それ自体は悪いことではないけどマネーフォワード内外におけるGoの存在感をより光を当てていく。 それによって今後あとに続くひとが社外だけでなく社内からも増えることを期待して、その一助になればと考えています。

そもそもGoが好き

Goの何が好きか?と言われると返答に困るのですが、普段Ruby/Railsを書いている反動なのか型があり、無用なところで議論が発生しにくいGoという言語が好きです。 また簡潔に書きやすいところが個人的に気に入っています。 テストがrspecに比べて愚直になる傾向があるのでそこはもう少し頑張ってほしいなと思うことはありますけどね! (↑同僚から炎上しそうだから消したほうがいいかも、と言われたw)

海外のカンファレンスに参加する敷居を下げる

ぼくは頭が良くないので英語に対してどうしても苦手意識があります。 いままでは現地にいくしかなかったわけですが、言葉が通じないという不安がつきまとうので敬遠してきた過去があります。 ただ今回、飛び込む機会を得られたこと、日本にいながらにしてイベント参加ができることでだいぶ心理的ハードルが下がりました。 これが契機になって次回以降海外カンファレンスにも臆せず参加できるようになれば、知識の吸収する場がグンと増えるのでそうなるとよいなと期待しています。

英語学習に対するモチベーションのブースト

前述しているように英語が苦手です。 得意だ!というかた以外は概ね賛同いただけると思うのですが、英語学習ってとにかく続かないですよね。 モチベーションの維持がしにくく、また日本国内で生活していると上達具合もなかなか体感しにくいです。 以前知り合いのエンジニアが「海外カンファレンスに行って英語が全く聞き取れなかった、悔しい」といってその悔しさをバネに1年後カナダへ留学するほどの熱意を発揮していました。 留学がしたいわけではないのですが、人間お尻に火がつかないとなかなか頑張れないので、そういう意味で発破をかけていきたいと思ってます。

ぼく的GopherCon 2020の見どころ

本題です。

TOP3 in GopherCon 2020 all days

まず結論から。

  • Day1の「Write Once, Use Many: A Simple & Useful Package to Call Internal APIs」
  • 同じくDay1の「Reordering 59 Million New York Times Publishing Assets Using Go and BadgerDB」
  • Day2の「How to Write a Self-Hosted Go Compiler from Scratch」

全日程を通して特に期待しているのは上記3つになります。 理由は後述してありますが、これら3つのセッションはタイトル、そして説明をみているだけでワクワクしてくるものがありました。 他にも魅力的なものはあり、悩んだのですがどうしてもTOP3を選べ、と言われたらこうなるかなと。

以降、各日程ごとに期待しているセッションTOP3を記載しています。

Day1(11月11日)

Typing [Generic] Go

f:id:luccafort:20201105003525p:plain

いままでRob Pikeの思想によって散々議論されてきたGenericsがついにGoに採用される。 これは今までのGoの世界にとって大きなパラダイムシフトになり得る、そういう意味でみんなが注目しているだろうけどもぼくもやはり注目している。

Write Once, Use Many: A Simple & Useful Package to Call Internal APIs

f:id:luccafort:20201105003710p:plain

正直なところタイトルで釣られた感があるが紹介文をみてより強く興味を引かれたのがこのセッション。 実務として使うことが予想されるInternalなAPI、それをシンプルに書き、拡張や保守を容易にしている、という文言に自分が今後作る、あるいは保守をするサービスに活かせる知識を知る、あるいは補完することができるのではないか?と期待しています。 (自社の素晴らしいパッケージ紹介で終わってしまう、という可能性を少しだけ危惧しています、少しだけね!)

Reordering 59 Million New York Times Publishing Assets Using Go and BadgerDB

f:id:luccafort:20201105003811p:plain

世界でも有数の記事データ量を誇るNYT、その5900万件のイベントをどのようにしてメモリ内で並べ替えたのか?というセッションのようなのでこれはMFという巨大データを抱える我々にとってもよい教訓が含まれているのではないか?ということで期待しています。 BadgerDB というのは寡聞にして聞いたことがないので軽く調べたのですがGoだけで作られたKeyValue型のDBのようです、これがどう活かされているかはセッションの中で語られることでしょう。いまから楽しみです。

https://github.com/dgraph-io/badger

Day2(11月12日)

Deterministically Debugging Go Programs

f:id:luccafort:20201105003902p:plain

あまりGo開発者にも知られていないデバッグの簡単&パワフルなdelvesについて、そのエレガントな問題解決を紹介してくれる、ということでGoビギナーなぼくにとって知りたい&実務で役立つ知識になりそうと判断しました。 効率の良いデバッグを知ることは効率の良い開発が出来ることにつながるので期待しています。

Pardon the Interruption: Loop Preemption in Go 1.14

f:id:luccafort:20201105003941p:plain

Go 1.14では、スケジューリングとガベージコレクションのためにゴローチンが先取りされる方法が大幅に変更された、ということでその詳細から言語仕様、設計思想、ベストプラクティスを学べる機会だと感じたため、恐らく難解であることを覚悟で聞きたい!と思いました。

How to Write a Self-Hosted Go Compiler from Scratch

f:id:luccafort:20201105004038p:plain

タイトルをみてメルカリのDQNEOさんだ!と気づいてしまったやつ。 DQNEOさんはPHPを書かれていた頃からウォッチしているエンジニアの1人であり、今回登壇されると知って絶対に聞きたい!!!と思っていたので当然聞く。

それだけではなくGoのエクスパートでもコンパイラのエクスパートでもないDQNEOさんがGoでコンパイラを実装し、そこから得た学びとは何なのか? それはぼくにとってもエンジニアとして還元することが出来るものではないか?というエンジニアとしての成長につながるなにかがあるのではないか?と期待しています。とても楽しみ。

Day3(11月13日)

Functional Programming with Go

f:id:luccafort:20201105004114p:plain

関数型プログラミングが現実問題をどう解決するのか、関数型プログラミング特有の概念をどうGoで表現するのか?を理解することを期待。 Ruby/Rails(OOP/MVC)とは思想からして異なるのでいまいちど原点に立ち返るのはよいかもしれないと考えたのが理由です。

Working with Errors

f:id:luccafort:20201105004228p:plain

プログラミングはエラーとの戦いだと思う。 そのエラーについて過去の経緯やどうあるべきか、なども含めて知ることが出来る貴重な機会。 紹介文をみていると丁寧にエラーについて話す予定のようなのでそれだけでも価値があると考えました。

Optimizing Performance using a VM and Go Plugins

f:id:luccafort:20201105004241p:plain

みんな大好きパフォーマンス改善! Goにぼくらマネーフォワードが期待することの1つにパフォーマンスの向上があります。 だが如何に言語のパフォーマンスがよくても実装したコードが駄目だと無用にパフォーマンスを劣化させてしまう。 そこでこのセッションで避けるべき実装、真似るべき実装を学ばせてもらう。

まとめ

ここであげた以外にも気になるセッションはありましたが全日程で3つ、各日程ごとで3つという縛りを課して選んでみました。 業務に近い、あるいはエンジニアとしての成長につながるだろうと感じられるセッションが多く選出された傾向を感じています。

逆にインフラやSREな領域のようなセッションへの興味は薄めだったかなと感じています。 興味はあるけどあまり前のめりじゃない、そんな雰囲気でした。

さて、初めての海外カンファレンス!(オンラインだけど)に参加できるというだけでいまからワクワクしてきますね。 当日が楽しみです!!!

よければ皆さんもGopherCon2020で期待している内容をブログに書いてみませんか?!

地道にご当地コミュニティーを運営していたら知らない間に紹介してもらえて報われた

2020年10月17,18日に開催していたGDG DevFest 2020のLT大会でぼくらが運営しているKyoto.goが「日本のGoコミュニティ活動状況 [2020年10月版]」として紹介されました。

www.slideshare.net

正直なところ東京やUmega.go、Fukuoka.goなどに比べてまだまだGo力が低いのが京都の現状だと思います。 低いからこそ継続が大事だなと思い、月2回(第2、第4水曜日開催)を初期に決めて定期的に行う、というように運営した結果が報われたなと感じて嬉しくなりました。

これもひとえに参加してくれるかたがいるから続けられたことだと感じています。 1人しか参加者いなかったら泣いて途中でやめちゃってたと思う。

これからもっと良くしていきたい、もっとGo力をあげていきたい、Goを通してKyoto.goという場が成長につなげていきたいなどなど思うところは諸々ありますが今後もやっていきの精神で継続していこうと考えています。

日付的には変わってしまったけど今日でuber-go/guideの輪読会は完走になりました。 次回は TheAlgorithms/Go で実際に手を動かしながらアルゴリズムの復習と実装をやっていこうと考えています。

よければご参加ください。

github.com

来月のイベントページはこちら。

kyotogo.connpass.com

kyotogo.connpass.com

気づいたら3ヶ月くらいブログ書いてなかった。

割とブログを書くネタはいっぱいあったんだけど忙しかったり、会社のテックブログ(みてね!)を書く方に注力していたら全然個人のブログを書いてないことに気づいた。

moneyforward.com

以下、雑に直近やってたこと。

  • 技術書典9にまねふぉ執筆陣として「まねふぉテックブック」に寄稿しました。

techbookfest.org

  • とある事情でGoを2ヶ月くらいみっちり書いてました。大変だったけど楽しかった。この辺の話は会社のテックブログに経緯とかその成果とかをそのうち書こうと思ってる。

  • Kyoto.goを細々と毎月2回くらい開催している。いまはUber社のGoガイドを読む輪読会している。

  • ISUCON10予選に出場したがほぼなにもできずに敗退してしまった。この話はもう少し落ち着いたらブログにするかもしないかも。

  • 知り合いの Nkzn に頼んでフロントエンドの勉強会&ハンズオンを開催してもらった。テックブログに経緯とかも書いたので良ければどうぞ。

moneyforward.com

  • ヴァイオレット・エヴァーガーデンを観た。最高に美しいストーリーだったので観てない人は早くみるのだ!

  • Fire HD 8 Plusを買った。思ったより純粋のAndroid OSと違ったりアプリがなかったり(Youtubeとか)で結構面倒だなと思って早くも公開し始めてる。

  • 星を継ぐものを読んだ。これはいい名作SF。

  • Go言語による並行処理を読了した。並行処理について少し知識が身についたが体得したとはいえない状態なので実際にコード書いて覚えていく必要があるかなって感じてる。

  • PS5争奪戦に敗れて今年中に手に入らなそうだったのでヨドバシでGoPro9 Black買って徳を高めた。

みたいなことをしてました。 他にも多分いろいろやってて書けることはあるんだけど書きすぎてもダルいし時間がかかるので今日はこれくらいにしておく。