「数学ガールの秘密ノート／学ぶための対話」感想

この記事は2020年ふりかえりアドベントカレンダー 3日目です。昨日の記事は Rubyリファレンスマニュアルを修正する方法 です。

ノナちゃんたちと僕と、「私（あなた）」の対話

数学ガールの秘密ノート/学ぶための対話 (数学ガールの秘密ノートシリーズ)

読んだきっかけ

udzura さんにオススメしてもらって読みました。 udzura さんのポッドキャスト On The Pavement • A podcast on Anchor vol.4 でも紹介されています。

「わからない」ことへの気持ち

今まで正直なところ、わからないことをオープンにしたくないと感じていました。

質問がいいことである、という知識は知っていますし、現在私が学び舎としているフィヨルドブートキャンプは質問を歓迎してくれる場所です。

それはそれとして「わからない」を表明するのは怖いです。未だに慣れません。

自分だけがわからないんじゃないかーとか、

実はググったらすぐ解決することなんじゃないかとか、

説明してもらってるのにわからないと申し訳なくなるし、

説明してもらってる内容に追いつけないときとか、ゆっくり理解したいって伝えるのは怖いし、

わからないことをなにがわからないのか言葉にして伝えるのも難しいし、もう大変大変！と思います。

そういうとき自分の場合は わかり を後回しにすることが多いです。わからんから後で自分一人で落ち着いて考えよう、と考えがちです。

ですが本書を読んで、そういう心持ちはなんだか違うかもなあと思いました。

自分の理解に関心を持つ

今は、「わからない」と思ったときにもっと自分の理解に関心を持つほうが良いのかなと思っています。

自分の理解に関心を持つとは、学ぶときに自分が本当に理解しているだろうかとたしかめることです。慣れないうちはむずかしく感じますが、理解したかどうかに誠実であることが大事だと思いました。

理解しているか確かめたいときには、「例示は理解の試金石」という言葉を使うことができます。これは、

• 具体例を作ることができれば、理解している。
• 具体例を作ることができなければ、理解していない。

という判断に使える、とても素敵な贈り物です。

「例示は理解の試金石」で、理解できているかを判断し、わからないときにはわからないことを伝え、「全部わからない」ではなく、「ここまではわかる」と言語化していく練習が必要だと思っています。

「先生」になる

本書では教わる側だけではなく、教えるということもテーマとして書かれています。その中で出てきた「先生」の定義がとても良かったので紹介します。

先生は、相手の理解を助けることを目的にしています。答えを教えることが目的ではありません。

私は人に教えるときに、どういう心持ちで教えればいいんだろう..と悩むことがありました。例えばプログラミングの質問であれば、うまく教えられなくて安易に「こう書けば動く」みたいな回答をしがちでした。ですが「相手の理解を助ける」という指針を持てば方針に迷わず対話できそうです。

また、自分自身が自分の先生になることもできます。この記事も、うまく言語化できなくてなんもわからん…という気持ちになったときに自分の中の先生に「何がわからないの？」と問いかけてもらってなんとか書き進めることができました。

自分自身が自分の理解を助ける先生になる、ということは「自分の理解に関心を持つ」ことにもつながるのでいいんじゃないかなと思います。

Rubyリファレンスマニュアルを修正する方法

この記事は2020年ふりかえりアドベントカレンダー 2日目です。昨日の記事は 2020年の終わりと2021年に向けての準備をするぞという気持ち - いまブログ です。

Ruby リファレンスマニュアルとは

Ruby の日本語版の公式ドキュメントです。略して「るりま」と呼びます。Ruby を書いたことがある方なら一度は読んだことがあるのではないでしょうか。

オブジェクト指向スクリプト言語 Ruby リファレンスマニュアル (Ruby 2.7.0 リファレンスマニュアル)

るりまは GitHub 上で管理されていて、誰でも修正したり、議論することができます。今回は、るりまを修正したい、気になる点を挙げたい、と思ったときにどうやったらいいのかということを書きます。

るりまのリポジトリ：rurema/doctree: Repository of Japanese Ruby reference manual

ちなみに「るびま」は Rubyist Magazine の略で使われることが多いです。面白く勉強になる記事がたくさんあるのでおすすめです。

るびま

るりまを修正する方法

GitHub に issue を立てたり、PR を送ることで修正できます。

issue を立てる方法

誰でも GitHub 上で issue を作成できます。

issue の内容は、

• ドキュメントの単純な誤り指摘（バージョン間違いなど）
• ドキュメントをより良くするための提案（説明文追加など）
• サンプルコード提供
• 既に上がっている issue に対するコメント

など、なんでもOKです。

PR を送る

具体的に修正したい箇所が決まっている場合は、PR を送ると反映されやすいです。

このとき、リファレンスマニュアル用の記法を使わない場合（誤字修正、サンプルコード追加など）は GitHub 上で直接修正すると楽です。

リファレンスマニュアル用の記法を使う場合（バージョンによって違う書き方をしたい場合など）は fork して修正して HTML を確認して push するとよいです。

GitHub 上で直接修正する方法

fork していない場合は先に GitHub で rurema/doctree を fork しておきます。

るりまで編集したいページの右上の方にある [edit] リンクを押します。

GitHub 上で修正します。

差分を確認します。

commit メッセージを書きます。

あとは Propose changes を押せば PR を送れます。簡単ですね！

fork してローカルで修正して PR を送る方法

Tutorial · rurema/doctree Wiki にとても詳しく書いてあります。抜粋してここでも書きます。

fork します。

ローカルに clone します。

$ git clone https://github.com/自分のアカウント名/doctree.git rubydoc
$ cd ./rubydoc

ブランチを切ります。

$ git checkout -b ブランチ名
Switched to a new branch 'ブランチ名'

好きなエディタでドキュメントを修正します。

リファレンスマニュアルの書式のまとめは ReferenceManualFormatDigest · rurema/doctree Wiki にあります。

bitclust をインストール、セットアップします。これでるりまのファイルから HTML ファイルを生成できるようになります。

$ gem install bitclust-core bitclust-dev refe2
$ bitclust setup

HTML ファイルを生成します。

bitclust htmlfile コマンドで生成できます。たとえば、

$ bitclust htmlfile ./refm/api/src/_builtin/Array --target=Array#pop --ruby=2.5.0 > /tmp/Array_pop.html

とすると、 Array#pop の Ruby 2.5.0 版の html が /tmp/Array_pop.html に作成されます。このファイルをブラウザで開くことで、生成されるHTMLを確認できます。

bitclust htmlfile の詳細についてはこちらにまとまっています。BitClust · rurema/doctree Wiki

html が問題なく生成できることを確認します。

commit します。commit メッセージは日本語でも英語でもかまいません。

$ git add .
$ git commit

remote に push します。

$ git push origin <ブランチ名>

PR を作成します。

push すると rurema/doctree から Compare & pull request できるようになっています。 そこから PR を作成します。

PR は日本語でOKです。

できました。

困ったことがあれば

Slack の ruby-jp に #rurema チャンネルがあり、質問することができます。

まとめ

るりまを読んでいて、この説明よくわからないな〜とか、もっとサンプルコードがほしいな〜とか、誤字かも？と思ったそのときがコントリビュートチャンスです！

るりまは OSS ですが日本語で issue や PR をつくっていいので、気軽にコミュニケーションができます。また、OSS に PR を送る一連の流れの練習にもなります。

どんどんるりまをよりよくしていきましょう！

参考資料

• HowToContribute · rurema/doctree Wiki
• Tutorial · rurema/doctree Wiki

2020年の終わりと2021年に向けての準備をするぞという気持ち

こんにちは。ima1zumi です。2020年がもう終わるなんて信じがたいです。今年はフィヨルドブートキャンプで勉強した１年でした。来年からはがらりと生活が変わるので、今年のふりかえりを兼ねて近況を書きます。主に就職活動まわりの話です。

フィヨルドブートキャンプの進捗

2019年10月末からフィヨルドブートキャンプに参加し、やっと「自作サービスを作る」プラクティス以外のプラクティスが終わりました。最後の山場です。進捗としては98%ですが、「自作サービスを作る」は1-2ヶ月くらいかかる人が多いのでまあまあ大変なものが残っています。

学習と並行して就職活動していまして、ありがたいことに就職先が決まりました。わーい。2021年1月からWebエンジニアとして働きます。

就職先はフィヨルドブートキャンプ経由で紹介していただきました。ちなみに、フィヨルドブートキャンプを卒業しても必ず紹介先企業に就職しないといけないわけではありません。そこは生徒の自由です。

就職活動の感想

2社受けて1社から内定をいただきました。就職活動期間は1ヶ月半です。新型コロナウイルス感染症が流行していることもあり、面接はほとんどオンラインでした。就職先の企業も現在は全員在宅勤務しているとのことで、入社後も当分の間在宅勤務になりそうです。通勤電車に乗らなくていいのでとてもありがたいです。

そんな就職活動でしたが、感想を一言でいうと「そこそこ準備したほうがいい。アウトプット重要」です。

そこそこ準備する

フィヨルドブートキャンプは「現場の人間にとって、戦力になるプログラマー」となることを目指したスクールです。カリキュラムは濃厚で卒業までには1000時間ほどかかる人が多いです（個人差はあります）。もし卒業したら、人生で達成したことリストに「フィヨルドブートキャンプ卒業」を加えたくなるようなそんなスクールです。

しかしフィヨルドブートキャンプを卒業した/卒業できる見込みがあるからといって就職が楽勝になって引く手数多だぜ〜〜〜ってなるわけではないです。当たり前ですが、採用してもらうには企業にこの人を採用したい！と思ってもらう必要があります。

人を採用するときには技術スキルだけではなく、企業に欲しいポジション、人柄やエンジニアとしての方向性、企業文化とのマッチ度、今後の成長見込みなどすべてひっくるめて判断されます。自分を判断してもらうために、面接の限られた時間の中で自分のことを伝える必要もあります。できれば自分のキャリアビジョンや企業研究もして、会社に入ってから何がしたいかは伝えられるようにしていたほうがいいと思います。こういうことは、普段はなかなか意識しないこともあり結構準備に時間がかかります。

というわけで就職活動はそれなりに準備しておいたほうが後悔しないと思いました。ただマッチングは時の運もあるので、どれだけ準備しても希望通りにはいかないこともあります。気持ちを入れ込みすぎない程度の準備をしていくといいのかな、と思います。

アウトプット重要

せっかくフィヨルドブートキャンプで勉強しているので、どのような形でもいいのでアウトプットはしておくと良いことにつながります。善行みたいなものだと思います。

ここでのアウトプットは勉強会での登壇、ブログやQiita, zenn などに記事を投稿することだけに限りません。twitterのつぶやき、Rubyコミュニティに参加する、GitHubにコードを上げるなど、自分の存在をオープンな場に示すことすべてがアウトプットだと思います。それらのアウトプットは企業から見る目を「フィヨルドブートキャンプの人」から「ima1zumiさん」に変えてくれて、自分を知ってもらいやすくなります。

私はRubyコミュニティによく参加していたため、就職活動時に「相手が自分のことを既に知っている」ということがありました。とてもありがたかったです。折角の学習なので、自分の頑張りを見てもらえる場所に公開しておくといいと思います！

その他

履歴書の証明写真はカメラのキタムラの簡易証明写真で撮ってもらいましたが、エンジニア転職でそれほど履歴書重視されない気がしたので、証明写真機でもよかったかも..と思いました。

ちなみに履歴書はyagishで作成し、職務経歴書はmarkdownで書いてpdfにして送りました。yagishとても便利です。

2021年に向けて

そんなこんなで就職活動を終えたので、来年からはいよいよエンジニアとして働くことになります。コードいっぱい書けると思うと楽しみです。

入社まで１ヶ月ほどあるので、いろいろやりたいことをやっていこうと思います。まずはフィヨルドブートキャンプを卒業したいですし、自作キーボードを作るとか、部屋を整理するとか、C言語を学習するとか、やりたいこといっぱいあるんですが、せっかく時間があるので１２月はブログを毎日更新してみようと思います。まとまった分量の記事を書く練習もしたいですし、この１年で学んだことを書き残しておきたいと思います。がんばります。

find_or_initialize_by と find_or_create_by の違い

find_or_create_by は引数に渡した条件のレコードがなければ create する。

find_or_initialize_by は引数に渡した条件のレコードがなければ new する。

返り値はレシーバのmodel。

引数に渡した条件は AND で検索されるので、このメソッドだけで create_or_update みたいに使うことはできない。

 Book.find_or_create_by(id: 5)
 # <Book id: 5, title: nil, created_at: "2020-09-28 04:13:23", updated_at: "2020-09-28 04:13:23">
 
 Book.find_or_create_by(id: 5, title: "fuga")
 # id:5, title: "fuga" のレコードはないのでcreateしようとするが、id重複でエラーになる
 ActiveRecord::RecordNotUnique (SQLite3::ConstraintException: UNIQUE constraint failed: books.id)
 
 Book.find_or_initialize_by(id: 5, title: "fuga")
 # new するだけなのでエラーにならない
 
 Book.find_or_initialize_by(id: 5, title: "fuga").save
 # id:5, title: "fuga" のレコードはないのでcreateしようとするが、id重複でエラーになる
 ActiveRecord::RecordNotUnique (SQLite3::ConstraintException: UNIQUE constraint failed: books.id)

レコードがなければ CREATE し、存在する場合は UPDATE という挙動にしたいなら、find_or_initialize_by と update を組み合わせて使う

 # レコードがなければ INSERT になる
 book6 = Book.find_or_initialize_by(id: 6, title: "piyo")
 book6.update(title: "piyopiyo")
 # INSERT INTO "books" ("id", "title", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["id", 6], ["title", "piyopiyo"], ["created_at", "2020-09-28 04:21:17.337137"], ["updated_at", "2020-09-28 04:21:17.337137"]]
 
 # レコードがあれば UPDATE になる
 book6 = Book.find_or_initialize_by(id: 6)
 book6.update(title: "piyopiyopiyo")
 # UPDATE "books" SET "title" = ?, "updated_at" = ? WHERE "books"."id" = ?  [["title", "piyopiyopiyo"], ["updated_at", "2020-09-28 04:21:55.998472"], ["id", 6]]

参考

RailsのActiveRecordでcreate_or_updateを分岐なしでスマートにする方法 - ウェブエンジニア珍道中

ActiveRecord::Relation

ActiveRecordのsave()の挙動、あるいはcreate()とupdate()の挙動の違いについて - Qiita

Machida.rb #04 に参加

Machida.rb #04

Machida.rb #04 - Machida.rb | Doorkeeper

今回のテーマはRubyのコードを持ち寄ってワイワイコードレビューする会！

ということで私も自作プログラムをレビューしていただいた。

レビューしてもらったコード

Slackのメッセージをコピペするといらない情報を落としてくれるCLIツール slack_message_to_plaintext を作っているので、それをレビューしていただいた。

ima1zumi/slack_message_to_plaintext

slack_message_to_plaintext を作った経緯と、出来ること

slack_message_to_plaintext はSlackのメッセージをコピペすると整形後のテキストを標準出力に返す100行程度のプログラム。

FJORD BOOT CAMPでは学習した日は毎日日報を提出する必要があるのだけど、私はSlackに分報を書くことが多い。分報と日報両方書くのが面倒だったため、分報を綺麗にコピペしたら簡単に日報できるんじゃないか？と思った。しかしSlackはそのままコピペするとusernameとかreactionとかいらないものがたくさんついてきて、綺麗に直すのが面倒だったのでプログラムで整形してみることにした。

SlackのAPIを使えばjsonでデータ取得ができてもっと簡単な処理にできるのだけど、FJORDのSlackの管理者でもないし、貴重なApp枠（無料版のSlackでは10個までしかAppを入れられない）を取ってしまうのでコピペしたデータをinputにすることにした。

（余談だが、分報を日報にするという試みは失敗に終わった。気軽に今思ったことをポンポン書いていく分報と、ドキュメントとしての体裁をある程度整えたほうが読みやすい日報とでは、文体が全然違ったのだ…。今は分報は分報で気軽に投稿し、それを見ながら日報を別途書き起こすようにしている。）

機能としては以下の4点。

• 名前を消す
• reactionを消す
• （編集済み）を消す
• URL展開された文字列を消す
  • うまく消せないことがある...

こういったSlackのスレッドのメッセージを、

そのままコピペするとこうなるので、

こういうデータにして返している。

レビューの仕方

レビューしてもらいたいプログラムを軽く説明して、Machida.rb の esa に気になった点を書いてもらうスタイル。

時間は約30分で、気になったところがある人から口頭で随時指摘をもらうという形。

レビューの感想

良かったところ

コードに具体的なアドバイスをいただいてめちゃめちゃ勉強になった。書き方で悩んでいたところを「こう書けるんじゃない？」と提示してもらって、そう出来るんだ！と気づけたり新しい書き方を知ることができた。

また、人前で自分のコードを説明して見てもらうという初めての経験が出来た。自分のプログラムを短い時間で説明して見てもらうのはなかなか緊張することと、自分はアドリブの説明がうまくないので事前準備しておいたほうがいいと分かった。FJORD生が多くて話しやすい Machida.rb でこういう経験ができて良かったと思う。

改善点

次にレビューをしてもらうなら改善して挑みたい、と思ったのは以下の点。

• ソースコードの共有
  • Machida.rb開始後にGitHubに貼ったので参加者が読み込んだり動かしてみる時間がなかった。
  • レビュー時間が30分程度と時間に限りがあったので、読む時間の余裕がなかった。
• 動作するバージョンの共有
  • Ruby 2.7以降でないと動かないことを直前にアナウンスした。
  • もしRuby 2.7が入っていない場合は時間がなくて手元での確認が出来なかったかも。
• 説明する準備
  • 知り合いが多い中でも結構緊張した。
  • コードの説明は慣れていないので、LTのように事前に練習しておけばよかった。
• テストコードを書く
  • テストは書こう！！！！
• 最初にやりたいこととやっていることを分かりやすく説明したほうがコードに入りやすい。
  • もっと丁寧に動作を説明できればよかった。ざっくりしすぎて理解しづらい説明をしてしまっていた気がする。
• 見てもらいたいポイントを明確にすればよかった
  • このメソッドのこの書き方を変えたい！とか明確に見て欲しいところを提示できればよかった。

感想

今回レビューしていただいて、色々な学びや気付きがあった。実際にレビューしてもらわないと気づけなかったことだと思う。また他の方のレビューにも参加できて楽しく学ぶことができた。こんな機会をくれたMachida.rbに感謝しています！

git commit でコミットメッセージ入力画面からコミットを取りやめる方法

コミットメッセージを消して保存すると取りやめることができる。

コメントは残っていても良い。

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   new file:   hoge
#

上の状態で保存すると、コミットメッセージが空なのでコミットに失敗しました、というメッセージが出てコミットされない。

$ git commit                     
Aborting commit due to empty commit message.

Webエンジニア勉強会inVR 第3回 テーマ「生産性アップの推しツール」 の録画を見た

【初参加歓迎】Webエンジニア勉強会inVR 第3回【YouTube Liveあり】 - connpass

2回目の参加。当日は終盤しか参加できなかったので録画を見た。

今回のテーマは「生産性アップの推しツール」

内容と感想

clusterの操作説明

clusterで参加している人向けの操作説明があって親切！ cluster使ってみたいけどスペック的に厳しそう…

マイクといえば某オンライン勉強会で、果物リンさんがマイク良いものにしたら音質がすごくよくなったと仰っていた。

そのときはあまり違いがわからないと思っていたのだけど、Webエンジニア勉強会のように一人が登壇して発表する形式だとすごく個々人の音質の違いを感じる。音質良いと話にも集中しやすくなる気もするのでオンライン勉強会の登壇ではマイク重要かも…と思った。オンライン面接にも言えることかも

身近なツールを正しく使う：ういろうさん

• VRアバターの手が動いててすごい!
  • 環境構築に25万😇
• 効率化するとき、最も使う時間が長いものから効率化していくと効率がよいよね
  • コミュニケーションツールを最も使うのでは？
    • コミュニケーションツールでは視覚情報が大事. 図とか
    • まとめや図は大事！！
• 対面ならホワイトボード
  • ホワイトボードノート
• 今何の話してるかわからない問題
• Marp
  • 別の勉強会でMarp使ってる人がいて、あれどうやってるんだろう…と気になっていたので知れてよかった！即インストールした
  • Marp for VS Code - Visual Studio Marketplace

時間を意識する推しツールたち：kulunaさん

• アークナイツ気になる

• Focus To-Do

  • レポートすごい！！
    • 自分が集中している時間帯見れるのいい
  • 普段 Focus を使っているのでそっちを活用していこうと思った
    • Focus To-Do は無料でいろいろできてすごいし使いたいのだけど、 Apple Watch のインフォグラフ文字盤に対応していないので Focus を使っている
      • インフォグラフでない普通の文字盤には対応している
    • 私のApple Watch の文字盤はこれ、ここにFocus To-Do を表示させたかった

    

• 頭痛〜る

  • 「頭痛始まる前に仕事を終わらせる」という発想がなかったので参考になった
• meeting is moneyすごい
  • time is money...

Slackを中心に世界は廻っている ：jiyuujinさん

• 個人slackに情報ぽいぽい投げてくの便利そう
• IFTTTとエゴサ相性よさそう
• デモがあると分かりやすかったかも

ノンデザイナーズ・デザインツール：おとべさん

• Figma 便利そう！！
  • 公式でAWSのアイコンいっぱいあるのすごい
• 今後Webサービス作るときに使えそう
• プロトタイピングツールというカテゴリをはじめて知った

行動に移したこと

• Marps をインストールした
• Focus に課金した
  • レポートも見れるようになりかなり使いやすくなった