Zennに書いた記事の収益をRubyアソシエーションに寄付しました

お知らせ

以前このブログでもお知らせしたとおり、昨年末にRuby 3.0の新機能紹介の記事をZennに書きました。

zenn.dev

QiitaではなくZennに書いたのは記事の収益をRubyアソシエーションに寄付するためです。

お気づきかもしれませんが、Part 2はQiitaではなくZennを使って書きました。
その理由は読者の方が記事に対してお金を振り込めるからです！・・・といっても僕がそのお金を独り占めするわけではありません。
2021年1月31日までに集まったお金はRubyの普及と発展のためにRubyアソシエーションに寄付する予定です。

【アウトライン版】サンプルコードでわかる！Ruby 3.0の主な新機能と変更点 - give IT a try

上にも書いたとおり、「2021年1月31日まで集まった収益を寄付する」という方針だったので、アナウンスどおり先日Rubyアソシエーションに寄付しました。

お金を出してくださったのは僕一人ではないのでどうしようか迷ったのですが、Rubyアソシエーションの個人寄付名簿に僕の名前も載せてもらいました。

2020年度 Ruby Association Supporters

期間中にZennの記事にサポートを送ってくださったみなさんには心より感謝申し上げます。
どうもありがとうございました！

参考情報：収益の詳細について

さて、このブログを読んでる方は「実際、Zennに記事を書いたらどれくらい儲かるん？」と思う人も多いんじゃないかと思います。
あくまで僕が一記事を書いただけなので一般化するのは難しいと思いますが、今回の記事の収益についてまとめておきます。
（Zennの運営者さんへ：こうした情報の公開がNGであればすぐに削除しますのでご連絡ください）

• 売上総額 = 11,300円
• 受取金額 = 9,458円（決済手数料、プラットフォーム利用料、振込手数料を除いた金額）
• サポート件数 = 15件
• 最大金額 = 3,000円（1件）
• 最頻金額 = 500円（8件）
• 12月中のサポート件数 = 12件（公開当日は8件）
• 1月中のサポート件数 = 3件

と、こんな感じでした。

なお、Rubyアソシエーションの個人寄付は1口5,000円となっているため、受取金額の9,458円に僕の財布から少し上乗せして、10,000円を寄付しました。

もう少し集まってほしかったな、という思いは多少ありますが、それでも売上ベースで1万円を超えることはできました。

まとめ

というわけで、この記事ではZennに書いた記事の収益をRubyアソシエーションに寄付したよ、という話と、収益の詳細についていろいろ書いてみました。

繰り返しになりますが、サポートを送ってくださったすべてのみなさまに心より感謝申し上げます。
また、日々Rubyの普及と発展とご尽力されているRubyアソシエーションのみなさまと、MatzさんをはじめとしたRubyコミッタのみなさまにも感謝します。いつもありがとうございます！

あわせて読みたい

Zennに書いたRuby 3.0の新機能の紹介記事をまだ読まれていない方は、ぜひチェックしてみてください。
zenn.dev

また、拙著「プロを目指す人のためのRuby入門」もよろしくお願いします。

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

最新バージョンと、書籍の内容との差分はQiitaに書いています。
qiita.com

プログラミング初心者はgit commitする前に必ずdiffを自分でレビューするクセを付けよう

プログラミング初心者向けのTipsです。

まあ、タイトルに書いたとおりなんですが、プログラミング初心者は（というか、プログラマならみんな）git commitする前にdiffを自分でチェックするようにしましょう。

それはなぜか？

しょーもないミスを自分で見つけるためです。

しょーもないミスというのは例えば、消し忘れのコメントや、デバッグ用に書き込んだprint文、無駄な空行、おかしなインデント、管理対象外とすべき一時ファイルや隠しファイル等々です。

def create
  @book = Book.new(book_params)
  puts @book.title # ほら、デバッグ用のputsが残ってるよ！！

  if @book.save
    redirect_to @book, notice: '登録しました'
  else
   render :new # インデントが1文字ズレてるよ！！
  end
end

しょーもなくない、深刻なミスもあります。
たとえば、ついうっかり外部APIやAWSのキーとシークレットをdiffに混在させてしまっていた、なんてこともあるかもしれません（怖）。

# これは絶対コミットしてGitHubにpushしたらあかんやつ！！
AWS_ACCESS_KEY=AKIAJTR62TDCMHIFHOGE
AWS_ACCESS_SECRET=9Z/jzM0C+haty7f2hwroK9ADmw06wq/HogePiyoFuga

• 参考：GitHub に AWS キーペアを上げると抜かれるってほんと？？？試してみよー！ - Qiita

こういったミスをしないように、git commitのコマンドを打ち込む前にgit diffでこれからコミットしようとしているコードのdiffを自分でレビューするようにしましょう。
もちろんボーッとdiffを眺めるだけではダメです。
レビュアーになったつもりで自分で自分の粗探しをしてください。

しっかり自分でdiffをレビューしよう！！

この時点できちんとミスを見つけ出し、コミット前に修正しておけば、プルリクエストを出したときにレビュアーからの指摘事項を減らすことができます。

チーム開発をしたりするときにしょーもないミスを連発していると、「この子、このままコードを書かせて大丈夫かな？」とレビュアーを心配させてしまうかもしれません。
ミスを可能な限りなくし、先輩エンジニアに「出来る新人」をアピールしましょう😎

コミット前にセルフレビューする実際の様子を動画で見てみる

以下の動画は僕が実際にRailsのプログラミングをする様子をスクリーンキャスト形式で録画したものです。
動画の8分あたりを見ると、僕がコミット前にdiffを確認している様子がわかります。
僕はRubyMineを使ってdiffを確認していますが、考え方自体はRubyMineを使わないときも同じです。

【お試し版】プログラマがコードを書きながら考えること 〜動画でわかるWebクローラー開発〜

なお、こちらの動画の完全版はBOOTHで販売中です〜。（番宣）
booth.pm

RuboCopのようなツールで自動チェックさせるのももちろんOK

目視によるチェックだけでなく、RuboCopやESLintのようなツールを使ってしょーもないミスを自動的に検出するのももちろんOKです！

ただし、ツールだけに頼るのはやめましょう。
ツールでもチェックしつつ、目視によるチェックも併用すべきです。（ツールで検出できないミスもあるので）

また、ツールの自動修正機能を使う場合もどこがダメだったのか、それがどう修正されたのかを確認して自分のコーディング力アップに役立ててください。
（ツールがないと綺麗なコードが書けない、ということにならないように！）

まとめ

というわけで、このエントリでは「プログラミング初心者はgit commitする前に必ずdiffを自分でレビューするクセを付けよう」という話を書いてみました。

ちなみにこれは僕がソニックガーデンに入社したときに先輩エンジニアから教えてもらったTipsです。
それまでは僕自身もそういう習慣を身につけていませんでした。
実際、この習慣を実践するようになってから、しょーもないミスが格段に減ったのを実感しています。

誰でも簡単に実践できる習慣だと思うので、プログラミング初心者のみなさんはぜひ実践してみてください！

あわせて読みたい

フィヨルドブートキャンプのメンター、 id:beta_chelsea さんが書かれたブログです。
ここでもほぼ同じ内容が書かれています。（そして僕もフィヨルドブートキャンプのメンターの一人です✌️）

beta-chelsea.hatenadiary.jp

「あ、入力中の文章が消えちゃった！😱」を避けるためにテキストエディタからブラウザにコピペする

簡単なTipsの紹介です。

みなさん、ブラウザのテキストエリアに長文を書いていたら、何かの拍子にページ遷移が発生してしまって、「あー、入力してたテキストが全部消えたー！！！！😱」っていう経験をしたことはありませんか？僕は何度もあります😅

この問題を避けるため、「これは途中で消えたら泣く」というような文章を書くときはテキストエディタを使って書くようにしています。
そして、文章が書き終わったらテキストエディタからブラウザにコピペします。

テキストエディタで書くメリット

テキストエディタを使うと、書きかけの文章を失うという事故を防げるだけでなく、以下のようなメリットも一緒に付いてきます。

画面が広く使える

ブラウザのテキストエリアは枠が小さくて長文を書くのに向いていない場合があります。
テキストエディタを使えば、広々とした画面で文章を書くことができます。

エディタの編集コマンドを自由に使える

僕はテキストエディタとしてVimを使っています。
Vimにはたくさんの便利コマンドがあるので、ブラウザ上で文章を書くよりもスピーディにテキストを編集できます。

qiita.com

等幅フォントなのでコードが書きやすい

テキストエディタは等幅フォントで表示されるので、サンプルコードを伴うような文章を書くときはブラウザのテキストエリアよりもコードが書きやすいです。

シンタックスハイライトが効く

テキストエディタにはシンタックスハイライトを付ける機能があるので、Markdownで文章を書くときはMarkdown用のシンタックスハイライトを有効にしておくとテキストの視認性が上がります。

編集内容が自動保存される

これはテキストエディアの設定次第ですが、編集内容が自動保存されるように設定しておくと、何らかの原因でテキストエディタが異常終了したり、パソコンがハングアップしてしまったりした場合でも編集中のテキストを失わずに済みます。

ちなみに僕はvim-auto-saveというVim用プラグインを使っています。
https://github.com/907th/vim-auto-save

テキストエディタで書くデメリット

テキストエディタを使うデメリットはほとんどないのですが、挙げるとすれば1つあります。

画像だけ別にアップロードする必要がある

ブラウザ上に画像をドラッグアンドドロップで貼り付けられる機能が付いている場合、その機能はテキストエディタ上では使えません。

画像を貼り付けたい場合は以下のような手順を取る必要があります。

1. 画像だけ先にブラウザにドラッグアンドドロップする
2. 生成された画像URLをテキストエディタにコピペする

またはこういう手順になります。

1. 先に文章だけを全部完成させる
2. 文章をブラウザにコピペする
3. 画像をブラウザにドラッグアンドドロップして文章全体を完成させる

Markdownエディタを使うのも便利

ここまで僕はVimを使って書く方法を紹介しましたが、テキストエディタは別に何でも構いません。
Markdownで文章を書くことが多い人は専用のMarkdownエディタを何か持っておくといいかもしれません。
Markdownエディタを使うとテキストを編集しながらプレビューすることができます。

僕はQuiverというMardownエディタを使っています。

もしくはMarkdownをリアルタイムでプレビューできるアプリを使う

Vimで編集しながらプレビューもしたい、というときはMarked 2というMacアプリを使っています。（右のウインドウがMarked 2）

Marked 2を使わずにVim内でMarkdownをプレビューするプラグインもあるようなので、Vimユーザーの人はいろいろとプラグインを探してみるのもいいかもしれません。

まとめ

というわけで、この記事では「あ、入力中の文章が消えちゃった！😱」を避けるためにテキストエディタからブラウザにコピペする方法を紹介してみました。

後悔先に立たず。「しまった！！」と思う前にツールの使い方を見直してみましょう〜。