GitHub CLIでgistを作成する

はじめに

この記事は2020年ふりかえりアドベントカレンダー 6日目です。昨日の記事は Rubyにはオブジェクトを汚染する仕組みがあった - いまブログ です。

GitHub CLIとは

GitHub 公式が提供している CLI ツールです。コマンドラインから Pull Request や issue を管理したり、 gist を作成できて便利です。

cli/cli: GitHub’s official command line tool

GitHub CLI では gist の作成、確認、編集、削除ができます。つまり好きなエディタで gist に上げたファイルを操作できます!

とてもシンプルに gist 管理ができて便利だったので使い方を紹介します。

GitHub CLI のインストール

macOS の場合は homebrew でインストールできます。

$ brew install gh

LinuxWindows などの環境のインストール方法は README に書いてあります。 cli/cli: GitHub’s official command line tool

GitHub CLI のコマンドは gh で呼び出せます。

インストール後、 適当な gh コマンドを打って GitHub アカウントにログインしてください。

$ gh issue list 

gist を作成

コマンド

$ gh gist create [<filename>... | -] [flags]

-p オプションを指定しない場合 secret gist が作成されます。

オプション

-d, --desc      # gist の詳細を記入
-p, --public   # gist を public で作成
-w, --web       # 作成した gist をブラウザで表示

サンプルコード

$ gh gist create test.txt -w
- Creating gist test.txt
✓ Created gist test.txt
Opening gist.github.com/afe55d913bad0dc92f1c41c0f7392f97 in your browser.

$ gh gist create test.txt -d "説明" -p -w
- Creating gist test.txt
✓ Created gist test.txt
Opening gist.github.com/061e2ce872d3e331d1e2f054bd478363 in your browser.

gist の一覧を確認

gist id、説明文、ファイル数、公開状態、最終更新時間を確認できます。

コマンド

$ gh gist list [flags]

サンプルコード

$ gh gist list                           
061e2ce872d3e331d1e2f054bd478363  説明            1 file  public  less than a minute ago
afe55d913bad0dc92f1c41c0f7392f97  test.txt        1 file  secret  about 3 minutes ago

gist を確認

cat コマンドのように gist を表示できます。

コマンド

$ gh gist view {<gist id> | <gist url>} [flags]

サンプルコード

$ gh gist view 061e2ce872d3e331d1e2f054bd478363 
説明
GitHub CLI でアップロードしたサンプルファイルです。

markdown の場合少し色がついた状態で表示されます。

gist を編集

エディタで gist を開いて編集できます。

コマンド

$ gh gist edit {<gist ID> | <gist URL>} [flags]

エディタが開いて gist を編集できます。使うエディタは環境変数 EDITOR を参照しています。

サンプルコード

$ gh gist edit 67353016314581ed675e40e7f89ea422 

$ EDITOR="nano" gh gist edit 67353016314581ed675e40e7f89ea422 

私の環境では、EDITOR="code" (VSCode) を指定するとうまく編集できませんでした。

gist を削除

gist を削除します。特に確認メッセージなどは出てこないので注意してください。

コマンド

$ gh gist delete {<gist ID> | <gist URL>} [flags]

サンプルコード

$ gh gist delete 67353016314581ed675e40e7f89ea422    

参考資料

Rubyにはオブジェクトを汚染する仕組みがあった

はじめに

Ruby 3.0 Advent Calendar 2020 5日目の記事です。

昨日は、【Ruby 3.0 Advent Calendar 2020】Ruby3.0で非推奨から廃止になるメソッドたち【4日目】 - ゲームリンクスの徒然なる日常 です。

また、この記事は2020年ふりかえりアドベントカレンダー 5日目です。昨日の記事は 初学者が Ruby on Rails の広大さに途方にくれたけどなんとかやっていけるようになった話 - いまブログ です。

Ruby 3.0 から $SAFE が普通のグローバル変数になります

The feature of $SAFE was completely removed; now it is a normal global variable.

The feature of $SAFE was completely removed; now it is a normal global variable. ruby/NEWS.md at v3_0_0_preview1 · ruby/ruby

ということで、 $SAFE という特殊変数が普通のグローバル変数になります。ところで $SAFE とはなんでしょうか?これは Ruby のオブジェクトを汚染するセキュリティの仕組みに関わっていた特殊変数でした。

Ruby のオブジェクト汚染の仕組みについてざっくり説明し、$SAFE がなんだったのか、なぜ取り除かれるのか、というところをまとめてみます。

オブジェクトを汚染する仕組み

Ruby にはオブジェクト汚染という仕組みがありました。これは、オブジェクトの汚染とセーフレベルという仕組みで「外部から与えられた信頼できないオブジェクトを安全に取り扱う」こと、「信用しているオブジェクトを信用できないプログラムから守る」ことを目的としていました。CGI 時代に入力フォームから受け取ったデータを信頼しないようにしたい、という使われ方をしていたようです。

ちなみに、汚染という考え方は Perl 由来の機能です。Taint checking - Wikipedia

オブジェクトを汚染する

オブジェクト自体に汚染フラグを持つ仕組みです。汚染に関連するメソッドはこのようなものがありました。

  • Object#taint オブジェクトを汚染する
  • Object#tainted? オブジェクトが汚染されている場合に真を返す
  • Object#untaint オブジェクトの汚染を取り除く

これらのメソッドは Ruby 2.7 より非推奨となりました。 taint untaintself を返す挙動に、 tainted? は常に false を返すようになっています。 似たような trust untrusted? untrust メソッドもありますが、こちらも非推奨です。

これらのメソッドは Ruby 3.2 で削除される予定です。

セーフモデル

信用できないデータで危険な操作( eval やファイル操作、外部コマンド実行など) を行えないようにするための仕組みです。セーフレベルはレベル0〜レベル4まであり、レベル4ではプログラムを自由に終了することもできませんでした。セーフレベルはグローバル変数 $SAFE で設定することができました。

なぜこの仕組みは消えることになったか

汚染という仕組みには、

  • Ruby と関係するすべての C コードの汚染レベルとセーフレベルをチェックする必要があり、メンテナンスコストも嵩む、パフォーマンスも悪くなる
  • セキュリティを担保するレベルが粗い。汚染の仕組みを使ってセキュアなプログラムにしようと思うと多くのプログラムが動かない
  • 汚染を適切に運用していないオブジェクトがあるとセキュリティを担保できない

といった問題がありました。

また、 セーフレベル4は安全な sandbox 環境のために使えると思われていましたが、実際には脆弱性がありました。

汚染の仕組みは CGI で活用されていましたが、Ruby on Rails の台頭により CGI の必要性が下がったという理由もあったようです。

今までの流れとこれから

Ruby 2.1 でセーフレベル4が廃止されました。ruby/NEWS at v2_1_0 · ruby/ruby

Ruby 2.3 でセーフレベル2, 3が廃止されました。ruby/NEWS at ruby_2_3 · ruby/ruby

残ったセーフレベルは0(すべて信頼する)1(汚染されたオブジェクトは evalやファイル操作、外部コマンドの実行を禁止する)でした。

Ruby 2.7 を前に、汚染の仕組みを完全に廃止してはどうかというチケットが立てられました。Feature #16131: Remove $SAFE, taint and trust - Ruby master - Ruby Issue Tracking System

廃止の理由は

  • この仕組みを使っている人がほとんどおらず、ライブラリもサポートしていないこと
  • 脆弱性があり、メンテナンスコストがかかっていること

です。

このチケットで議論が行われ、

  • Ruby 2.7で 汚染の仕組みを使えないようにする。 $SAFEtaint 系のメソッドで警告を出す
  • Ruby 3.0 で $SAFE をふつうの変数にする
  • Ruby 3.2 で taint 系のメソッドを削除する

ということが決まり、削除されることになりました。

参考資料

初学者が Ruby on Rails の広大さに途方にくれたけどなんとかやっていけるようになった話

これは「フィヨルドブートキャンプ Part 1 Advent Calendar 2020」の4日目の記事です。

フィヨルドブートキャンプ Part 1 Advent Calendar 2020 - Adventar

昨日は hogucc さんの Rubyでリファクタリングをやってみよう でした。

Part2 もあります。

フィヨルドブートキャンプ Part 2 Advent Calendar 2020 - Adventar

また、この記事は2020年ふりかえりアドベントカレンダー 4日目です。昨日の記事は 「数学ガールの秘密ノート/学ぶための対話」感想 です。

今日はフィヨルドブートキャンプで最も苦しんだプラクティス、Ruby on Rails についての思い出を書こうと思います。随分長くなってしまいましたが、ふわっとした話なので暇なときにでもどうぞ..

フィヨルドブートキャンプで Ruby on Rails を学ぶまで

フィヨルドブートキャンプでは全体の中盤くらいに Ruby on Rails のカリキュラムがあります。

学習内容 | FJORD BOOT CAMP(フィヨルドブートキャンプ) でプラクティスのタイトルは公開されており、赤く囲った枠が Rails です。プラクティスは基本的に順番通り進めることが推奨されているため、Rails は全体の中盤くらいから学びはじめることになっています。ちなみにプラクティスの内容・順番は随時更新されているので最新版はリンク先を参照してください。

f:id:imaizumimr:20201204223758p:plain

私はフィヨルドブートキャンプで学習をはじめてから4ヶ月程度で Rails のカリキュラムに到達しました。

Rails エンジニアになるぞ!!と思ってフィヨルドブートキャンプに参加したので、やっと Rails だー嬉しいー!と思った記憶があります。また、フィヨルドブートキャンプの現在のプラクティスでは Sinatra で web アプリをつくってから Rails に入る流れなので、Rails で web アプリ作るの Sinatra よりめちゃくちゃ楽じゃん...と感動しました。

しかし、そこからが大変だったのです…

rails new したらたくさんディレクトリが出来るけど、なにもわからない

私が Rails を学んだ初日の日報にこんなことを書いていました。

Railsディレクトリ構成がよくわからない。やっていたらいずれ分かるものだろうか?

これは、例えば app/models とか app/controllers がよくわからない、どこに何があるかも分からないし、何かを参考にしようにもフルパスで書いてないとどこに何を書いていいか分からないという状態でした。

分からないので調べよう、と思って調べてみても、その時点の知識レベルでは Rails ガイドに何が書いてあるのかもさっぱり分からない状態です。

日報で「わからないまま進めることに不安がある」と書くとフィヨルドブートキャンプの先輩の id:NMP300 さんから、

結局は自分で手を動かして、悩んだり苦しんだりしないと、本やサイトを読んだだけでは、あまり理解できないのかな、と思いました🤔

とアドバイスをいただいたので、とりあえず手を動かして悩んだり苦しんだりすることにしました。

Rails なにもわからない

過去の日報に悩んだり苦しんでいる様子がいろいろあったので抜粋して紹介します。Rails の学習をはじめて2〜3ヶ月間のコメントです。

  • Rails はどこに何が定義されているのかわからない
  • i18nt メソッドって何?と思ってもどこにコードがあるのかわからない
  • Rails で意味があるファイルなのかただのサンプルファイルなのかぱっと見で見分けられなくて難しい
  • devise の課題で、これどうやって理解しよう…と思って悩んでしまって手をつけられない時間が長くなってしまった
  • devise のルーティングがわからない
  • devise が分からないまま動いていることにモチベが下がる
  • devise がなんか resource ってオブジェクト使ってるけどこれはなんなんだろう
  • テスト周りで、自分が使いたい機能が何のgemの機能なのか把握するのが大変
  • i18n で翻訳するにはt ".email"のようにI18n.tメソッドを使うものだと思っているのだけど、シンボルだけで翻訳できているパターンがあって理由がわからない
  • Rails 何も理解できてないんじゃ…という不安感が常にある。どうしたものかな🧐
  • Rails 理解してスッキリ Rails のコードを書きたい!
  • Railsに対する苦手意識が生まれてしまっている気がするので、苦手意識をなくしたい🤔🤔

かなり悩んでそうな感じになっています。実際、一時期は自分は Rails わからなさすぎて Rails エンジニアに向いてないんじゃないかと考えていました。

日報に書いたところはメンターさんから都度アドバイスや回答はいただいていましたが、自分としては根本的に Rails への理解が足りないなあという不安がしんしんと積もっていきました。

一つ何かを理解すると、その周囲にあるわからないことがどんどん見えてくるんですよね。例えると、真っ暗なところをろうそくの灯火でうっすらと道を見て歩いている…と思っていたのに、懐中電灯をゲットしたので使ってみたら、道じゃなくて原っぱを歩いているしまわりには得体のしれないものがいっぱいあって、ろうそくを使っていたときより明るくなっているのに逆に不安になるような、そんな気持ちでした。少しずつ分かっていることは増えているはずなのに、わからないことのほうが増えていく状態がとても不安でした。自分が立っている場所もよく見えないようなそんな感じでした。

Rails の gem のコードを読める環境をつくって読んでいったり、Railsガイドを読んだり、手を動かしてプラクティスを進めたりしていましたが Rails への苦手意識はつのるばかりでした。

そうこうしているうちに Rails を学習しはじめてから数ヶ月がたち、スッキリコード書けないまま進めたツケなのか完全に Rails が嫌になってしまいました。AtCoder やってみたり、英語学習してみたりと Rails からの逃避をはじめました。

ラクティス的には進めようと思えば進められる状況でした。やろうと思えば..コードの意味を追わなければ..コードは書ける、でも、そうやって書きたくない…という気持ちでもやもやしていました。日報を書く回数も減っていって、周りからは少し心配されていたような気がします。

Entaku.rb

Rails の進捗は悪くなっていっていましたが、そのころから Ruby コミュニティに参加しはじめていました。フィヨルドブートキャンプの先輩の id:s4na さんから、「Rails のプラクティスを始めたら地域 Ruby コミュニティに参加するといいですよ!」と勧められていたので、私も Rails を学び始めたから参加してみるかぁという軽い気持ちでした。2020年4月〜5月頃です。当時新型コロナウイルスが流行しており、勉強会は休止かオンラインになっていました。

そんな中で、twitter で Entaku.rb という勉強会の存在を知りました。

Entaku.rbは日本語での技術ディスカッションをメインとしたコミュニティです。名前に".rb"とあるようにRuby周辺の話題を主に取り扱いますが、参加者の方が話題を決めるため、何を議論するかは都度変わります。 議論は4人ほどの少人数グループによって行われます。各グループによって何を議論するかは異なり、最後に全グループで何を話し合ったかや何を得られたかを共有します。

Entaku.rb | Doorkeeper

Entaku-rb/minutes: 議事録

ここで Rails の学習に関する悩みについて質問したことがきっかけで、Rails スランプを抜け出せました。

Rails は gem の集まり

当時の自分のモヤモヤを要約すると「Rails について「こうしたらこうなる」は分かるが、なぜそうなるかが分からず壁を感じている」でした。

その問題に対し、参加者でワイワイ議論したのですが私としては「Rails は個々の gem が集まって出来ている。細かいコードを追うのではなく、大きな gem 同士の関係性を知ったほうが理解するのに役に立つかも」という回答がとても参考になりました。

これまでは Rails を使っていてわからないことがあるとまずコードレベル、メソッドレベルで追いかけて「ようわからんなあ」と思っていました。

しかし各々の gem がどういう役割なのかを知ることが大事だと分かりました。また、プロのエンジニアでもコードレベルで細かい処理の流れを追うことはほとんどないということを知れたのも良かったです。それまで自分は Rails をコードの集合体としか見れていませんでした。プログラムはコードから成り立っているものだからコードを見れば分かるはずだと思っていました。でも、もっとレイヤの高い視点で見ることができて、Rails は gem が協調して動いているということが Entaku.rb のおかげで分かったんですよね。それは、自分にとっては目から鱗が落ちるかのような発見でした。

それまでコードの狭い世界で見ていたものが、もう一段広い gem 同士のつながりという世界で見られるようになりました。文字通り世界が広がったような気持ちでした。木を見て森を見ずという言葉がありますが、まさに自分がその状態でした。森という概念を知らないまま、全体像が分からないよ・・・と木ばかり見ていた感じです。

それ以外にも、「Railsの思想はSimpleでなくてEasyで「とにかくこのように書け」というものなので、ある程度の諦めは肝心かもしれない」とか、全てを「理解している」まで持っていかなくてもよくて「知っている」でも良いとか、非常に学びの多い勉強会でした。

当時の議事録です:minutes/Railsの勉強法.md at master · Entaku-rb/minutes

そして現場 Rails

Rails の見え方が変わって気持ちを新たにした私は、とりあえず『現場Rails』を読んで基礎を学ぶことにしました。

現場RailsRails の学習開始1ヶ月くらいで少し読んでいたんですが、そのときは書いてある内容が全然ピンときませんでした。

それが、4ヶ月くらい悩んだり苦しんだりした後に読むと全然見え方が変わっていて、知りたかったことがたくさん書いてあって読んでてめちゃくちゃ楽しい本に見えるようになっていました。

現場Rails を読み終わるころには Rails への苦手意識もなくなり、プラクティスを進められるようになりました。

結局は自分で手を動かして、悩んだり苦しんだりしないと、本やサイトを読んだだけでは、あまり理解できないのかな、と思いました🤔

これは最初にいただいたアドバイスですが、本当にこのとおりでした。

悩んだり苦しんだりして、ようやく分かること、気づくこともあります。Rails のプラクティスではスランプになったり、Rails エンジニアやっていけるのか悩んだり、いろいろありましたがそのおかげで理解できるようになったことがたくさんありました。悩みを質問する過程でたくさんのことを学びました。自分では気づけなかった視点を持つこともできました。

Rails はまだまだ分からないことだらけですが、今の自分はあのときの自分よりたくさんの武器を持っています。いろいろな角度で問題を眺めることができるようになりました。これまでの学びを血肉としてなんとかやっていっています。でもまだまだこれからが本番です。今後もなんとかやっていきたいなあと思います。

謝辞

Entaku.rb でアドバイスいただいた id:okuramasafumi , id:osyo-manga ,参加していた皆様にとても感謝しています。あの Entaku.rb から Ruby コミュニティにハマって今に至るので、あの会がなければ今の自分はありませんでした。ありがとうございます。

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

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

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

読んだきっかけ

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

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

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

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

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

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

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

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

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

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

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

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

自分の理解に関心を持つ

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

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

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

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

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

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

「先生」になる

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

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

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

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

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

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

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

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

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

f:id:imaizumimr:20201202213058p:plain

オブジェクト指向スクリプト言語 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 していない場合は先に GitHubrurema/doctree を fork しておきます。

f:id:imaizumimr:20201202215006p:plain

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

f:id:imaizumimr:20201202214901p:plain

GitHub 上で修正します。

f:id:imaizumimr:20201202221450p:plain

差分を確認します。

f:id:imaizumimr:20201202221552p:plain

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

f:id:imaizumimr:20201202221656p:plain

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

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

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

fork します。

f:id:imaizumimr:20201202215006p:plain

ローカルに 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#popRuby 2.5.0 版の html が /tmp/Array_pop.html に作成されます。このファイルをブラウザで開くことで、生成されるHTMLを確認できます。

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

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

f:id:imaizumimr:20201202233403p:plain

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

$ git add .
$ git commit

remote に push します。

$ git push origin <ブランチ名>

PR を作成します。

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

PR は日本語でOKです。

f:id:imaizumimr:20201202233140p:plain

できました。

困ったことがあれば

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

まとめ

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

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

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

参考資料

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

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

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

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

f:id:imaizumimr:20201201233833p:plain

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

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

就職活動の感想

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

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

そこそこ準備する

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

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

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

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

アウトプット重要

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

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

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

その他

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

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

2021年に向けて

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

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

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_byupdate を組み合わせて使う

 # レコードがなければ 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