Kyoto.goでgolang/goのIssueやproposalを眺める会をやったら言語仕様や提案している背景が理解できたという話

TL;DR

  • 自分が主催するKyoto.goのイベントで golang/go のIssueを読み漁る会に参加した
  • 割とぶっつけ本番でやったが意外といい企画だった
  • よいイベントなので継続してやりたいと言いう思いと誰にとってもいい企画だったのでもっと周知したいなと思った。

kyotogo.connpass.com

今回の企画はujiさんプレゼンツだった。 元々はGoCon運営もあるし、毎月継続しているけど10月難しそうだなーというところから 10月は忙しくて開催できないかも〜という話やイベントの立て方が定型化してきていることを議題に上げました。 定型化していることに大きな課題感を感じたというよりはたまに味付けを変える変化をつけて、いつもと違うメンバーが参加しやすいイベントを目指したいね…という話しをメインでしてました。

あとはアンケートをそういえば取れてないから取りたい、Kyoto.rbでは新しく参加したメンバーがブログを書いてくれていた、Umeda.goみてると我々の運営メンバーは少ないのでは?…という話をしていました。 実際にKyoto.rbのるりま読書会で書いてもらったブログは↓

fuga-ch85.hatenablog.com

詳しい内容を知りたいかたは議事録を公開しているのでこちらを読んでください。

scrapbox.io

当初、イベント企画していたときはOSSにコミットできるといいよね〜という夢の話しをしてました。 会が始まり、まず読みたいIssueを探そうという話になったのでDiscordのスレ機能を使って気になったIssueを収集しよう!というチャレンジをしました。 その際、Issueの探し方もスレに書いてもらうようにしました。「 label: NeedsFix から探している」「 label:Proposal が面白そう」「NeedsFixが多いから label:help wanted みてみる」という個々人で別々の動きが生まれて面白かったです。

Issueのうち、これが気になる!というものが見つかるとスレにURLを貼る方針で30分 + 10分ほど時間を取りました。 時間後はどういう点が気になって、そのIssueを選んだのか?を軽く説明してもらい、絵文字リアクションで投票の多いものからみていく…ということをしてみました。

気になったIssueをみていると次のような会話が生まれました

  • 提案内容で挙げられている実装で課題そのものは対応できそうだが、セキュリティ要件が含まれるので迂闊に実装するのが不安
  • 普通にこれ直せばコントリビュートいけそう。日曜のお供にどうぞ。
  • 初めてGoのリポジトリにPR作ったとき、GitHubで完結すると思っていたものがGerritで議論されたりしていて驚いた
  • errors.As() のこの挙動は知らなかった。普通に罠っぽいので直ってほしい→直されてる…どういう変更をしたんだろう?→変更されたPRのコード眺める
  • Proposalのラベル面白い。error-handlingのラベルも面白い。
  • Rejectされているけど then keywordの提案は正直旨味がないし、いらない。
  • いまのままだと難しいのでもうひと工夫ほしいけど check keywordが欲しくなる理由はわかる。
  • chaining method や pipeline 演算子みたいな機能が欲しい気持ちはわかる。でもエラーの処理が難しすぎる。いまの提案のままだと難しい。

などなどの会話が生まれて非常に楽しい1時間半になりました。 その後も30分ほど居酒屋トークをおこない、あーでもないこーでもない、この場合はこうしたい、言語仕様にエラーの文脈を入れると途端に難易度が跳ね上がる、Rejectされた label: error-handling をみるとやりたいことは一緒だけどちょっとGoにはあわないかもね…とGo言語コミュニティらしい会話が生まれて非常に楽しめました。 運営者目線でこのイベントを振り返っても初心者から上級者まで楽しめる企画だなと感じることができ、今後も定期的に開催したいねという元々のマンネリ化してるかも?という課題を克服することができました。 また運営側がなにも用意する必要なく、参加者も事前になにかしておかなければいけないということがなく非常に低コストでイベントを開催できる割に学びを得ることができる点が魅力に感じました。

↓開催後の参加メンバーの感想。

運営者の1メンバーなので少しポジショントークな感じもして、純粋な意味での参加レポートという感じではないのですが、他のコミュニティでも応用ができそうな企画案だったことと先日イベントに参加したらレポート書いてね!という話しをしたのでとりあえず雑に書いてしまおうと考えてこの記事を書いています。 Kyoto.goではGoに関係する全てのひとが楽しめるコミュニティを目指しています。 もし、こういうことがしてみたいんだけど?や運営のボランティアしてもいいよ!というかたがいたらGophers Slackの #kyoto チャンネルに投稿いただければと思います。

最後に告知です。 弊社マネーフォワードの関西拠点でミートアップをおこないます! ぼくは登壇しないのですが、関西拠点で働くメンバーが参加しています。 「カジュアル面談するほどではないけど話だけ聞いてみたい」や「マネフォって関西拠点あったんだ?」というかた向けのイベントになっています。 関西で働くことに興味がある、マネフォってどんな会社なの?ただのミートアップと何が違うの?と思われたかたは是非ご参加してメンバーに質問してみてください! 少しでもぼくたちマネーフォワード、その中でも関西拠点で働くメンバーや拠点のことに興味を持ってもらえれば嬉しいです。

moneyforward.connpass.com

テックコミュニティーの運営としてお願いしたいこととCfPの応募に関する告知

来週遅めの夏休みを取る予定なので積ん読になっていたプログラミングElixirを読もうと考えているluccafortです。

みなさんはGoConというテックカンファレンスをご存知でしょうか?

次回GoCon 2021 Autumnはぼくが運営するご当地コミュニティであるKyoto.goとfreeeさんで働くhatajoeさんたちが運営するUmeda.goの共同運営で諸々進行をしています。 京都と大阪という2拠点のコミュニティによってオール関西なメンバーが主導するかたちで次回のカンファレンスは運営されています。 (実は今回からGo Conference Tokyoではなく、Go Conferenceになってより地域に縛られないという進化を遂げています。気づいてたよ!というかたがいたらマジですごい。)

kyotogo.connpass.com

umedago.connpass.com

大規模カンファレンスの運営は初だというメンバーが多いなか、tenntennさんはじめさまざまな企業に所属しているかたが企業の垣根を超えてGoコミュニティのために日々奮闘しています。 GoCon運営メンバーには本当にさまざまな面で助けられています。

hatajoeさんとtenntennさんのアカウントはこちら。

twitter.com

twitter.com

GoCon 2021 Autumn のCfP締切は8月末だぞ!☆|彡サ

そんな忙しいメンバーのスケジュールの合間を縫っていろいろ企画したり、準備したりしているGoConですが、実はCfPが公開されています。

このCfPの締め切りが8月末までとなっており、もしかするとご存知ないかたもいるかもしれないと考え、ブログで告知をさせてもらおうと考えてこの記事を書いています。

CfPだけでなくスポンサードの締め切りも8月末となっています。 Goルドとシルバーはすでに満枠になってしまいましたが、ブロンズとグリーンに関しては締め切りギリギリまで応募を受け付けています。 もし興味があるかたは締め切り前にご応募いただければと思います。

gocon.jp

GoCon 2021 Autumn に参加するひとに1コミュニティ運営者がお願いしたいこと

Umeda.goとKyoto.goと異なるコミュニティが共同でおこなうはじめてのイベントになります。 運営するメンバーはそれぞれいろいろな企業に所属しています。

中には競合他社でライバル関係というようなメンバーもいますが、それも含めてお互いを高め合うライバルであり、助け合う仲間、Gophersだと考えています。 このように書くとポジショントークっぽくみえてしまいますが、もっともっとGo Forwardな世の中にしていきたいと個人としても考えていますし、他のメンバーも同じだと信じています。

そして更なるGoの発展、より人類がGopherへと近づくためにも皆さんのご協力が必要です。 ぜひともGoコミュニティへのコントリビュートをお願いしたいと考えています。

でもコントリビュートって難しんじゃないの?と考えるかたもいらっしゃると思います。 なんと、とても簡単にGoコミュニティへのコントリビュートをする方法があります!

それはブログに参加レポートを書くことです!

ぼくはかつてPHPカンファレンスというテックカンファレンスで「ブログを書くまでがカンファレンス!ブログを書いてコミュニティやカンファレンスにコントリビュートしよう!」と言われたことがあります。

これは実に素晴らしい文化であり、全てのテックコミュニティで継承していきたい考えだと思っています。 しかしながら残念なことにコロナ禍でイベントがオンラインになったことで、参加する特別感が薄れてしまい、この素晴らしい文化が徐々に途絶えようとしているようにみえます。 ぼく自身もイベントやカンファレンスの参加レポートを書く機会が薄れてきてしまっています。

これは非常にもったいないことだと考え、今回CfPの応募告知とあわせて参加者のかたにブログを書くお願いをしようと考えました。

「このセッションが楽しかった!」「GoConに参加してよかった」など一言だけでも立派なコントリビュートです。

Twitterで盛り上がってもらうのもすごく嬉しいのですが、ブログを書くことで参加できなかった人たちへ向けたメッセージを書いてもらえればなと考えています。

ぜひ皆さんのフィードバックをコミュニティや登壇者のかたに届けてあげてください。

GopherCon 2020の A Rainbow of Gophers Building A More Diverse Community でも紹介されたようにGoが大事にする文化を伝えていくのもテックコミュニティの大事な責務です。

www.dropbox.com

強制するようなものではありませんが、参加されたかたはぜひブログや企業のテックブログで感想や学んだこと、得られたことなどを書いて次のGopherにバトンをつなげていただければなと考えています。

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

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で期待している内容をブログに書いてみませんか?!