give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

Ruby 2.7関連の解説記事や情報源のまとめ

Ruby

はじめに

Rubyは毎年12月25日に新バージョンがリリースされます。
今年も12月25日にRuby 2.7.0がリリースされました。

ちなみに、なぜ12月25日なのかというと、Matzサンタからのプレゼントという意味があるからだそうです（という話を以前どこかで読んだ気がするのですが、要出典・・・）。

このエントリではRuby 2.7のリリースを記念して、Ruby 2.7関連の信頼できそうな解説記事や情報源をあれこれまとめておきます。
Ruby 2.7について詳しく知りたい、という方はここに載せたページを参考にしてみてください。

【もくじ】

主要な変更点や新機能を知りたい（またはチェリー本の読者です）

隅から隅までチェックするのは時間がかかるので、主要な変更点や新機能を知りたいという方は僕が書いたこちらのQiita記事をどうぞ。

qiita.com

上の記事は、拙著「プロを目指す人のためのRuby入門（チェリー本）」に書いた内容との差異を説明したものですが、チェリー本自体がRuby初心者向けの本なので、Ruby 2.7の変更点や新機能がいい感じに浅く・広くピックアップされていると思います。

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

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

  • 作者:伊藤 淳一
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/11/25
  • メディア: 大型本

また、「はじめに」の項でも紹介した、ruby-lang.orgのリリースノートの説明にも主要な変更点や新機能がまとめられています。

Ruby 2.7の新機能や変更点を一通り知りたい

いや、概要だけじゃなくて、どんな新機能や変更点が入ったのが全部知りたいんだ！という方は、僕が書いたこちらのQiita記事をどうぞ。
サンプルコードと僕独自の視点を交えながら、Ruby 2.7の新機能や変更点を一通り説明しています。

qiita.com

また、Rubyコミッタの笹田さんと遠藤さんが書かれたこちらの記事でも同じようにRuby 2.7の変更点を詳細に説明されています。
こちらはRubyコミッタから見た、開発の裏話や設計の意図が豊富に含まれているのが特徴です。

techlife.cookpad.com

こちらはRuby 2.7の新機能や変更点を毎日紹介していくアドベントカレンダーです。（執筆者は、とみたまさひろさん）
上の2つの情報源にはない新機能の解説も載っていたりするので、こちらもチェックしておくとさらに網羅性が向上します。

qiita.com

最後に、Rubyの開発リポジトリにあるNEWSページを紹介しておきます。
英語の情報源かつ、説明も比較的シンプルですが、公式の情報源なので信頼性はほぼ100%です。

パターンマッチ構文について詳しく知りたい

Ruby 2.7で新たに導入されたパターンマッチ構文についても、僕独自の視点で書いた解説記事があります。
「プロを目指す人のためのRuby入門」と同様に、簡単な内容から徐々に高度な内容に発展させていくスタイルで執筆しています。（前編、後編の2部構成）

qiita.com
qiita.com

Rubyにおけるパターンマッチ構文の提唱者および開発者である辻本さんによる資料や動画もあります。
正式リリース版とは一部内容が異なる点もありますが、大半の内容は正式リリース版でも有効です。

[RubyConf2019]Pattern matching - New feature in Ruby 2.7 - Speaker Deck

[JA] Pattern matching - New feature in Ruby 2.7 / Kazuki Tsujimoto @k_tsj

また、有料の情報源になりますが、「n月刊ラムダノート Vol.1, No.3(2019)」という技術雑誌に載っている辻本さん解説も、パターンマッチ構文を理解するのに非常に役立ちます。

キーワード引数の仕様変更について知りたい

Ruby 2.7ではRuby 3で実施されるキーワード引数の仕様変更に向けて、特定の条件で警告が発生するようになっています。
この仕様変更についても僕が書いたまとめ記事があります。

qiita.com

このほかにもRubyコミッタの遠藤さんが執筆された記事や資料があります。
コミッタの視点から見た、より詳細な背景や意図についてはこれらの資料を確認することをお勧めします。


techlife.cookpad.com

また、既存のコードの修正方法に迷った場合は、公式の移行ガイド（英語）を参照すると解決するかもしれません。

番号指定パラメータについて詳しく知りたい

Ruby 2.7で導入された番号指定パラメータ（Numbered parameter）について詳しく知りたい方は、僕が書いたこちらの記事をどうぞ。

qiita.com

Rubyコミッタさんの開発裏話も聞きたい

新機能の話ばかりでなく、コミッタさんたちが何を考え、どう開発してきたのか、といった点も気になる！という方は、こちらの2つの記事が参考になると思います。

techlife.cookpad.com
employment.en-japan.com

まとめ

というわけで、このエントリでは先日リリースされたRuby 2.7関連の解説記事や情報源をあれこれまとめてみました。
Ruby 2.7は「今までこんなに大量の新機能や変更点が入ったことってないんじゃないの！？」と思うぐらい、たくさんの見どころがあります。
巷では「Rubyは死んだ」みたいな噂が定期的に上がってきますが、まだまだ開発は活発なようで安心しました。

また、来年はRuby 2.8ではなく、いよいよRuby 3.0がリリースされるようです（参考）。
こちらも非常に楽しみですね！
Ruby 3.0でのさらに大きな進化を期待しつつ、それまではRuby 2.7でプログラミングを楽しみましょう😄

TokyoGirls.rb Meetup vol.2 スライドまとめ #tokyogirlsrb

Ruby イベント参加

はじめに

2019年12月22日にTokyoGirls.rb Meetup vol.2という、「女性も参加しやすい（でも女性限定ではない）Ruby勉強会」を開催しました。

techplay.jp

この勉強会について書きたいことは山ほどあるのですが、時間がかかりそうなのでいったん登壇者のみなさんのスライドをこのエントリにまとめておきます。
当日イベントに参加できなかった人もここに載せたスライドをぜひチェックしてみてください！

【もくじ】

Ruby on Rails 最初の一歩（ただあき）

Ruby on Rails 最初の一歩 - Speaker Deck


事業知識を深掘りし、より人の役に立つサービスに改善する（Kubota Nao）

事業知識を深掘りし、より人の役に立つサービスに改善する - Speaker Deck

note版

note.com


Rackミドルウェア入門のためのRackミドルウェア（塩井美咲 / しおい）

Rackミドルウェア入門のためのRackミドルウェア - Speaker Deck


エンジニアとチームを組んで見えないものをデザインする（羽野めぐみ）

エンジニアとチームを組んで見えないものをデザインする / team-building-with-engineer - Speaker Deck


プロジェクトマネジメント沼にようこそ！（浪川舞 / まいどる）

20191221_TokyoGirlsrb - Speaker Deck


いつもの開発のようにOSS開発をしよう（makicamel）

OSS is great but not special - Speaker Deck


時短勤務ママエンジニアの要件ヒアリング力（ちょうかおり）

時短勤務ママエンジニアの要件ヒアリング力/mamahearing - Speaker Deck

登壇レポート

note.com


強いエンジニアという灯（大場寧子）

強いエンジニアという灯 - Speaker Deck


当日のツイート

togetter.com

まとめ

登壇者のみなさん、とても素晴らしい発表をどうもありがとうございました！

イベントそのものに対するブログはまた後日執筆予定ですので、もうしばらくお待ちください🙏

予備校で習った「現代文の読解テクニック」を使って、Web記事から「筆者の主張」を抽出してみた

よもやま話

はじめに

元の記事は削除されてしまったのですが、昨日Qiitaで「Webエンジニア業界に感じた違和感」という記事を読みました。
内容の方は「まあ、言わんとすることはわからなくはない」という感想だったのですが、それ以上に「なんか読みにくい文章だな」「話が右へ左へ大きくブレていて（＝褒めたりdisったりを何度も繰り返していて）、結局何が言いたいのかよくわからないな」という印象を強く受けました。

そこで、本エントリでは昔僕が予備校で習った「現代文の読解テクニック」を使って、「筆者が主張したい内容」を抽出してみることにします。

予備校で習った「現代文の読解テクニック」とは？

僕が予備校で習った「現代文の読解テクニック」は、ざっくりいうとこんなテクニックです。

  • 「だが」「しかし」など、逆接の接続詞が登場したら、そこから後ろが筆者の主張なので、「だが」「しかし」の前に書いてある内容は無視して良い。
  • 「〜ではない」と書かれていたら、その直後に筆者の主張が書かれていることが多い。
  • 「〜ではないだろうか」という疑問文は純粋な疑問ではなく、むしろ筆者が強調したい内容である。
  • 「たとえば」で始まる具体例は主張を補足する役割しかないので無視して良い。筆者の本来の主張は「たとえば」以外の箇所に書かれている。

と、だいたいこんな内容だったと思います。

上記のテクニックを使って元記事の文章を分析してみる

では、上記のテクニックを使って、元記事の文章を分析してみることにします。
ただ、残念ながら元記事自体は削除されてしまっているので、下記のWeb魚拓ページから本文を引用します。

【魚拓】Webエンジニア業界に感じた違和感 - Qiita

ウェブの技術は大変面白かったのですが、そこである大きな違和感を感じもしました。

逆接の接続詞「ですが」のうしろ、「そこである大きな違和感を感じもしました。」が筆者の主張。

常に数字や営業的な雰囲気に包まれている企業向け製品開発にはない、純粋に技術を楽しむ雰囲気がとても楽しかったです。
　
ですが、よくよく観察しているとWeb業界には「何が凄いのかよくわからないけど有名な人」もいました。

「よくよく観察しているとWeb業界には「何が凄いのかよくわからないけど有名な人」もいました。」が筆者の主張。

ツールやライブラリをスクラッチで自作した本人じゃなければ評価されちゃいけないと言ってるわけではないです。
　
ですが、Web業界では「ライブラリを作った人」より「上手く紹介した人」の方が有名になっている、といった違和感を感じました。

これも「ですが」のうしろが筆者の主張。

技術とその価値は「具体的な成果物を出して世の中にどれだけの影響を与えたか？」ではないでしょうか？

ここは純粋な疑問ではなく、むしろ筆者が強調したい点。

その成果物は技術の紹介ブログ記事やTwitterやカンファレンスの発表やQiitaのGood数やGitHubのスターの数ではなく、「直接、あるいは間接にでも売上に貢献した目に見えるプロダクト」であるべきです。

「ではなく」の後ろが筆者の主張。

極端かもしれませんが、これが基準にならなければ評価の基準も曖昧になります。

「これが基準にならなければ評価の基準も曖昧になります。」が筆者の主張。
なお、「これ」が指すものは、前文に出てくる「直接、あるいは間接にでも売上に貢献した目に見えるプロダクト」のこと。

最後に、私はWeb業界の雰囲気が嫌いではありません。
Qiitaを見ていると新しいことを学ぶモチベーションが高まります。
　
ですが、Qiitaやブログの記事を一つ読むにしても、その人は「本当に価値のあるアウトプット」をしている人なのかを考えながら接する必要があると思っています。

「ですが」のうしろが筆者の主張。

上記の分析をもとに、筆者の主張だけを抽出してみる

このように「現代文の読解テクニック」を活用すると、筆者の主張だけを抽出することができます。
以下がその抽出結果です。

私はウェブ系のカンファレンスである大きな違和感を感じました。Web業界には「何が凄いのかよくわからないけど有名な人」がいました。「ただツールやライブラリの使い方を紹介するだけで有名人になっている人達がいる」ように見えてきたのです。Webカンファレンスのほとんどの発表内容は、「このツールを使えばこんなことができる」という使い方の説明であり、多少の業務経験がある人が英語リファレンスを読み解けば、比較的容易に発表できてしまう内容が多かったです。

　
さらに業界を観察していると「新しい技術を紹介したもの勝ち」的な雰囲気が蔓延しており目的を見失ってそのスピードの速さ、紹介するレトリックの巧みさが競われているような文化さえ感じたのです。

　
そして周囲から有名になると、まるで芸能人のように祭り上げられます。Web業界では「ライブラリを作った人」より「上手く紹介した人」の方が有名になっている、といった違和感を感じました。

　
技術とその価値は「具体的な成果物を出して世の中にどれだけの影響を与えたか？」です。その成果物は「直接、あるいは間接にでも売上に貢献した目に見えるプロダクト」であるべきです。これが基準にならなければ評価の基準も曖昧になります。

　
Qiitaやブログの記事を一つ読むにしても、その人は「本当に価値のあるアウトプット」をしている人なのかを考えながら接する必要があると思っています。

さらに言うなら、筆者の一番言いたいことは最後の2段落に集約されていると思います。

技術とその価値は「具体的な成果物を出して世の中にどれだけの影響を与えたか？」です。その成果物は「直接、あるいは間接にでも売上に貢献した目に見えるプロダクト」であるべきです。これが基準にならなければ評価の基準も曖昧になります。

　
Qiitaやブログの記事を一つ読むにしても、その人は「本当に価値のあるアウトプット」をしている人なのかを考えながら接する必要があると思っています。

さらに：過剰なエクスキューズは読者を混乱させる

ところで、元記事を読んでいると、

常に数字や営業的な雰囲気に包まれている企業向け製品開発にはない、純粋に技術を楽しむ雰囲気がとても楽しかったです。

ですが、

とか、

ツールやライブラリをスクラッチで自作した本人じゃなければ評価されちゃいけないと言ってるわけではないです。

ですが、

とか、

私はWeb業界の雰囲気が嫌いではありません。
Qiitaを見ていると新しいことを学ぶモチベーションが高まります。

ですが、

といったように、「持ち上げておいて、落とす」レトリックが多用されています。

これは僕個人の推測ですが、筆者なりに気を遣って文章を書いた結果、こうなったんだと思います。
ただ、意地悪な見方をすると、「自分は悪者になりたくない、自分はあなたたちのことを十分理解しているつもりだ。だからその点をまず理解してもらいたい」というエクスキューズ（弁解）を散りばめただけ、と言うこともできます。

しかし、過剰なエクスキューズは読者を混乱させ、筆者の主張が正しく理解されない原因となります。
また、エクスキューズの部分を「込み」で評価する人と、そうでない人に分かれてしまい、人によって記事の評価が大きくブレる原因にもなります。

ぶっちゃけ、僕は元記事を読みながら「お前、ほめてるんか、けなしてるんか、いったいどっちやねん！」と心の中でツッコんでしまいました。

先ほどやったように、余計なエクスキューズは省いて「筆者の主張」だけを抽出してみると、「ふーん、なるほどね」と、筆者の言いたいことがすっと理解できました。

まとめ

というわけで、このエントリでは「現代文の読解テクニック」を使って、とあるWeb記事から「筆者の主張」を抽出してみました。

ここで紹介したテクニックは文章を読むときだけでなく、文章を書くときにも活用できます。
なぜなら、自分で書いた文章を読み直すときに読者の視点でこのテクニックを使えば、自分の主張がちゃんと論理立てて展開されているか、チェックできるからです。

また、本エントリの後半ではエクスキューズを過剰に散りばめることの弊害についても説明しました。
文章におけるエクスキューズは「用法と用量を守って使えば、文章のよいクッション材になるけど、使いすぎには要注意」という感じですね。

みなさんも文章を読み書きする際は、こういったポイントに着目してみてください！

Re: 「Webエンジニア業界に感じた違和感」

このエントリ自体はあくまで「国語」の話にフォーカスしているので、ここから下の話は蛇足です。
が、ついでに元記事に対する僕の感想も書いておきます。

冒頭で書いたように、僕の感想は「そうですねー、言わんとしていることはわからなくもないですね」という感じです。
筆者が言うところの「Web業界の何が凄いのかよくわからないけど有名な人」には僕も入ってるのかなー？たぶん入ってるんだろうなー、と思いました。

ですが、そのへんの評価基準は個人の自由なので、ここではとやかく言うつもりはありません。
元記事の筆者さんが「技術者は直接、あるいは間接にでも売上に貢献した目に見えるプロダクトでのみ、評価されるべきである」と考えているのであれば、それはそれで良いと思います。
（ただし、僕がその考えに完全に同意しているかどうかは別問題です。そもそも「私が考えた最高のエンジニア評価基準」は往々にして各人のポジショントークになりがちです。）

僕の反論

ただ、ひとつだけ反論するなら、僕は「周りから評価されて有名になりたいから」とか、「新しい技術を紹介して、他の人に勝ちたいから」とか、そういう理由でアウトプットをしているわけではありません。

僕が新しい技術をQiitaやブログで紹介するのは、「早かれ遅かれ、みなさんも僕と同じようにいろいろ調べるでしょ？だったら、僕が先回りして調べて説明しておけば、みなさんの時間が節約できますよね？」という思いからです。

「英語リファレンスを読み解けば、比較的容易に発表できてしまう内容」であっても、世の中にはやっぱり英語が得意な人と不得意な人がいます。
「母国語は英語です」という人でなければ、結局英語で読んで（人によっては苦労しながら）日本語に翻訳すると思います。

そこのインプットとアウトプットがどの人にとっても同じものなのであれば、誰かがそれを日本語でわかりやすく紹介しておくことで、日本全体でかなりの工数削減になるはずです。
もちろん、最終的なよりどころは「英語で書かれた原典」になりますが、それを理解した上であえて日本語で書かれた情報源を読んで時間を節約するというのは、全然アリだと思います。

また、英語の情報源を右から左へ翻訳するだけでなく、自分で使ってみて、自分なりの解釈や説明を加えた上でネット上に技術記事を公開することもよくやっています。
これも「単純に英語のREADMEを読んで理解するより、こうやって説明した方が、みんな理解しやすいんじゃないか（その結果、みんなの開発がよりスムーズに進むのではないか）」という思いからやっていることです。

こうした思いを持ってネット上で活動してきた結果、いつのまにかなんか有名になってしまった、ということろは事実としてあります。
ただ、有名になることを第一の目的としてやってきたわけではないので、その点についてはちょっと誤解されているんじゃないかなーと、僕は感じました。