「コーディングを支える技術」は良い本だ

「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」を読んで、良い本と思った。
ラフなメモ書き。
プログラミング初心者の適当な感想。

【参考】
コーディングを支える技術――成り立ちから学ぶプログラミング作法：書籍案内｜技術評論社

「コーディングを支える技術」著者公式ページ
「コーディングを支える技術」著者公式ページ　補足記事

【1】Javaで開発経験をした後、RubyやPythonを覚えた今、「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」を読むと、ああそういうことか、と気づくことがある。

【2】IF文の裏ではGOTO文が動いている、という内容を読んで、VBのことを思い出した。
VBでは、例外処理などのAPIが貧弱なので、割とGOTO文がよく出てくるので、VBは好きでなかった。
たぶん、APIが貧弱な古いプログラミング言語ほど、GOTO文が幅を利かせている。
その分、何でもできるが、とても読みづらく保守しづらい。

「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」の一節に、大学でC言語を初めて習った人が、「while文があればfor文はいらないのでは？」と思ったらしいと書かれていた。
僕も似たような感覚を抱いていた時があった。
JavaでもRubyでも、なぜ、while文、do-while文、for文、拡張for文など、似たようなループ処理の文法があるのか？と不思議に思っていた。

理由は単純で、当初はIF文みたいにwhile文を使っていたが、カウンタ変数のスコープがブロック外にあるので使いにくいから。
だから、while文からfor文の記法により、カウンタ変数のスコープはブロック内に収まった。
さらに、拡張for文により、カウンタ変数そのものも不要になった。
さらに、ListのforEachメソッド、Rubyのブロックのように、for文はクロージャとして吸収される。
つまり、プログラミングの文法もどんどん進化しているわけだ。

【3】変数のスコープの説明では、Perlで静的・動的スコープをプログラムで説明してくれている。
Perlを初めて書いていた時、なぜlocalやmyを変数に付ける必要があるのか、分からなかった時を思い出した。

Pythonでは、わざわざglobal／nonlocalで変数のスコープを制御できるようにしてくれている。
この文法を見た時、Perlみたいだな、と思ったことを思い出した。

Rubyなら、def～endのブロックとクロージャのブロックで、変数のスコープが異なるように使い分けている。
この文法は最初は理解しづらかったが、このおかげで、Rubyはメタプログラミングでやり放題ができるわけだ。

【4】オブジェクトとクラスでは、JavaとRubyでは考え方が全く違う。
親子で継承関係にあるクラスがあった時、インスタンス変数、インスタンスメソッド、クラス変数、クラスメソッドの挙動がJavaとRubyで異なる。
Javaでは、インスタンス変数、クラス変数、インスタンスメソッド、クラスメソッドは、親子クラスそれぞれで保持する。
ただし、親クラスの変数に、子クラスのオブジェクトを代入した場合、インスタンスメソッドは、子クラスのメソッドを利用する。
つまり、Javaでは、親クラスの変数の振る舞いは、ポリモーフィズムで動的に処理が変わるように見せかけられる。

一方、Rubyでは、親子間でインスタンス変数が共通として扱われる。
親クラスが定義したインスタンス変数と同じ名前のインスタンス変数を子クラスで使うと、親クラスのインスタンス変数は子クラスで上書きされる。
この書き方に慣れると、「クラス（型）は仕様である」を時々忘れてしまう。

資格取得に40代後半からチャレンジ　JavaとRubyを比較（注意しておくことその１）

資格取得に40代後半からチャレンジ　JavaとRubyを比較（注意しておくことその２）

資格取得に40代後半からチャレンジ　JavaとRubyを比較（注意しておくことその３）

資格取得に40代後半からチャレンジ　JavaとRubyを比較（注意しておくことその４）

Javaでは「クラス（型）は仕様である」が、Rubyではメッセージを渡したオブジェクトに全てを委ねる。
Rubyはまさにダック・タイピングなので、例えばdesktop.printが変数なのか、メソッドなのかも動かしてみないと分からない。

【5】多重継承のデメリットをどう解決するか？も、Java、Ruby、Pythonなどで全く違う。
Javaは多重継承を禁止するが、インターフェイスを導入して解決しようとした。
Javaでは、継承の代わりに委譲を進めるが、さらに委譲の参照をソースにハードコードするのではなく、依存性の注入により、設定ファイルを使って動的に変更できるような手法が多くなった。
JavaのフレームワークではDIが多いから、設定ファイルにXMLを用いることが多く、その分、プログラムを書くよりもXMLを書いている時が多くてあまり楽しくなくなる。

Rubyは、多重継承の問題を「どの順番で継承関係を検索するか」という問題に置き換えた。
Rubyでは継承関係は、Objectを頂点とするツリー構造だから、継承ツリーをメソッド検索することで解決しようとする。
include, prepend, refinementsはそういう使い道だろう。
また、Rubyでは、どうしても多重継承したい時は、モジュールでMix-inを使う。

Pythonでは多重継承できる、と聞いていてまだ理解できていなかったが、「コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)」によれば、C3線形化のアルゴリズムで継承関係の検索を決めることで解決しているわけだ。

［Python入門］多重継承：Python入門（1/2 ページ） - ＠IT

Pythonのメソッド解決順序(MRO) - 情報系大学院生の勉強メモ

【6】それから、並行処理のプログラミングの章も非常に分かりやすい。
Windows3.1やMacOS9は強調マルチタスクで、プリエンプティブマルチタスクではなかった、という一節を読んだ時、昔のPowerbookがMacOS9だった時を思い出した。

並行処理の問題点は、競合状態が起きること。
競合状態は3つある。
1つ目は、2つの処理が変数を共有している。
2つ目は、少なくとも1つの処理がその変数を上書きする。
3つ目は、一方の処理が一段落付く前に、もう一方の処理が割り込む可能性がある。

1つ目の対策は、結局スレッドを使っているので、変数を共有しない方向で解決していない。
アクターモデルのように、メッセージを送ることで解決しようとしている。
Erlangがその例だろう。

2つ目の対策は、メモリを共有しても書き換えないようにする方針もある。
全ての変数はImmutableにすればいい。
Haskellなどの関数型言語がそうだろう。

3つ目の対策は、協調的なスレッドを使う。
たとえば、Rubyのファイバー、Cのコルーチン、Pythonのジェネレータ。

あるいは、ロック、ミューテックス、セマフォ、モニタのような機構を使う。
Javaなら、synchronizedブロックで囲むだけでいい。

【7】自分は「プログラミングのできない山羊」出身なので、プログラミングを経験してやっとこういう本の内容が分かってきたという気がしている。
ソフトウェア開発は、数学や物理、経済学、財務会計、心理学などと違って、やっぱり独特の考え方がいると思う。
自分の中で言語化できていない部分は気づいたらブログで残しておく。

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索

「60%の人間はプログラミングの素質がない」記事のリンク: プログラマの思索

プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ: プログラマの思索

プログラミングは「ブロックを組み合わせる」感覚に似ている: プログラマの思索

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る

SECIモデルの状態遷移図を描いて、ようやくSECIモデルを理解できた気がする。
ラフなメモ。

SECIモデルの状態遷移図 from akipii Oga

SECIモデルの具体例(Scrum・チケット駆動開発など) from akipii Oga

パターン言語の構造と事例 from akipii Oga

【1】2014年頃に、SECIモデルでパターン言語を理解しようと考えていた。
確かにパターン言語と相性は良いが、SECIモデルのイメージがまだピンときていない気がしていた。

SECIモデルは、PDCAみたいなマトリクスよりも、知識・経験の状態遷移図で描く方が理解しやすいと考えた。
形式知＝知識、暗黙知＝身体による経験。

【2】知識を使って身体に落とし込むのが内面化。
スポーツ、楽器、お絵描きなどの訓練が相当するだろう。

一方、身体で経験した内容を知識でまとめるのが表出化。
一流のスポーツマン、学者、音楽家、宗教家、哲学者たちは、自分たちの体験を何とか知識として言語化し、みんなに広めようとする。
走る哲学者と言われる為末大さんみたいな感じかな。

他方、形式知を組み合わせて新たな知識を創造するのが連結化。
感覚的に情報を受け取って暗黙知を高めるのが共同化。

【3】知識は経験よりも大切なのか？
経験は知識よりも勝るのか？

僕は両方を経験している。

IT技術者であれば、たくさんのプロジェクトで新技術や業務システム開発を経験した後で専門書を読み直すと、ああ、そういうことだったのか、と気づく時が多い。
中島聡さんは、プログラミングとは、座学で勉強するものではなく、実際にアプリ開発して体験した後で専門書で答え合わせするものだ、と言われていた。
そんな内容と似ている。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

僕がRedmineにハマったきっかけも、XPやアジャイル開発の本はたくさん読んだが、何か腑に落ちることがなくて、Redmineでいろいろ試して初めて分かったという事があった。
知識がいくらあっても、やはり体験しなければ、本当に理解できた、という感覚がない。
肌感覚では分かった気にならなかった。

一方、IT企業やプロジェクトという組織形態では、いつもイライラするものがあって、その原因がなにか分からない時があった。
組織文化はトップが作るのか、ボトムアップで作られるのか、いつも疑問に思っていて、アジャイル開発の影響から、組織文化は現場からボトムアップで生まれるのだろうと思っていたが、診断士の先生に聞いたところ「組織文化を生み出す責任は社長にある。もっと社長が汗をかけ！」と言われて、ハッと気づいた時があった。

制度的リーダーシップの考え方が何となくしっくりきた: プログラマの思索

組織文化はトップが作るのか、ボトムアップで作られるのか: プログラマの思索

同様に、組織論、経営戦略論、経済学などを勉強してみて、メンバーに応じた教育方法ならSL状況理論やPM理論を使ってみたらいい、とか、プロマネとPMOの微妙な対立関係はエージェンシー問題に似ているな、とか、知識を使って、自分なりに理解が進んだ気がした。

管理職に求められる能力はPM理論そのものではなかったのか: プログラマの思索

ITの地殻変動はどこで起きているのか？～今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること: プログラマの思索

また、RedmineでRubyのソースコードは適当に触っていたがRubyはちゃんと理解できてなかった。
RubySilverやRubyGoldを勉強してみて、Rubyはオブジェクト指向言語を徹底しているんだな、と改めて理解し直した。

Ruby技術者認定試験の感想: プログラマの思索

そんなことを考えると、知識と経験の相互作用として、SECIモデルの内面化、表出化を行ったり来たりしながら自然に実践している。
そして僕はたぶん、実際に色々体験して、失敗を繰り返さないと腑に落ちないみたいだ。
そういう感覚はSECIモデルの状態遷移図で整理できるんだな、と改めて感じた。

「RubyやRailsは終わった」という記事のリンク

「RubyやRailsは終わった」という記事があったが本当なのか？
見つけた記事だけをリンクしておく。
自分が後で読むためのメモ書き。

【参考】
“Rubyは死んだ”のか？　まつもとゆきひろ氏が語る「プログラミング言語サバイバル」とRubyの未来 - Part1 - ログミーTech

Ruby2系はチームの幸福度を最大化できなかった - Qiita

「Railsは終わった」と言われる理由 - Qiita

Rubyは死んだというが。流行り廃りに拘らず、便利なものは活用すればいいのに - Qiita

Rubyは果たして死んだのか | 日経クロステック（xTECH）

Rubyは終わった？将来性と今後の展望をまとめてみた│エンジニアハック

将来性のないプログラミング言語5選として「Ruby」が挙がり話題に | スラド IT

個人的にはRubyは好きだ。
「メタプログラミングRuby 第2版」を読んで、色々動かして、やっとダックタイピングの意味が分かった。
やはりRubyはJavaとは違う。
Rubyは究極のオブジェクト指向言語なのかもしれない。

また、Rubyというコミュニティも素晴らしいと思う。

なぜソフトウエア後進国の日本でRubyは成功したのか？～ソフトウェアの成功の秘訣はコミュニティ、そしてコンウェイの法則にある: プログラマの思索

一方、RubyはPerlのシンタックスを受け継ぐ部分があるせいか、初心者には読みにくい記法がある。
慣れないと使いこなせない部分もある。

「Rubyのしくみ」を読んだ後のRubyの感想: プログラマの思索

Ruby技術者認定試験の感想: プログラマの思索

Ruby初心者が間違いそうなこと: プログラマの思索

メタプログラミングRubyの感想: プログラマの思索

Rubyのブロック、Proc、lambdaのメモ: プログラマの思索

RedmineやRubyについては今後も追いかけていく。

ITの技術や知識はツールの習得と表裏一体である

ITの技術や知識はツールの習得と表裏一体ではないか、というアイデアをラフなメモ。
とても当たり前の内容かもしれない。

【1】昨年からもう一度、コンピュータの基本技術を習得すべきと考えて、Ruby、Python、Linux、ネットワーク、機械学習、深層学習、コンパイラなどを勉強し始めた。
でも何か分かったような気がしなかった。
何か真似事しているだけのような気がした。
なぜだろうか？
いろいろ考えた結果、やっぱり基本技術が分かってないなあ、という思いがあった。

【2】ITの技術や知識の習得は、財務や法律、経済学などの分野の知識の習得とは異なる気がする。
具体的には、ITの技術や知識を知っているだけでは意味がなくて、その技術や知識を実装しているツールを使いこなせて、そこから新しいものを生み出すことができて初めて意味を持つのだ、と思う。

理由は、2つある。

【3】1つ目は、ITの技術や知識を知っているだけで、プログラミングの開発環境、Linuxコマンドを動かせるサーバー環境、UMLやデータモデルを描いて実際に画面まで動かす、などの実際に動かせる環境でツールを使いこなせなければ、実際の仕事に使えないからだ。

たとえば、RubyやPythonの文法を知っていると言っても、実際に動くアプリを生み出すには、プログラミングの開発環境を揃えて、デバッグしたり、コンパイルしたり、デプロイする環境が必要になる。
昔なら、VisualStudioでVBやC++を書いていた時も、VisualStudioに数多くのパッチを当てたり、SQLServerなどのバージョン依存に泣かされていたのを思い出す。

今でも、単にRubyやPythonの文法を習ったとしても、実際に開発環境を揃えるのは割と大変だ。
実際、Railsは優れたWebフレームワークだが、VerUpが激しいし、大量のGemが必要になるので、慣れていなければ、バージョン依存ですぐに動かなくなる。
PythonもNumpy、Pandas、MatplotLibのVerUpは激しいので、すぐに古いバージョンのAPIは使えなくなっている。
ただし、Pythonの場合、Anacondaがあるおかげで、以前よりもバージョン依存地獄にはまらなくなったように思う。

たとえば、WordPressやTracなどのWebシステムを通じて、Webアプリの機能や特徴を理解したとしても、Linux上にソースをデプロイして、負荷分散に耐えられるようなネットワーク設計を行ったり、不正なアクセスを制御するようにアクセス制限を課す、とか、いろんな設定作業が必要になる。
特に、インフラ周りの開発環境は、一昔前まで構成管理できない環境だったから、設定ファイルを一度修正すると、元の環境に戻せないリスクが多かった。
それゆえに、数多くの「○○_backup_yyyyMMdd.ファイル」みたいなファイルがたくさんできてしまって、ゴミファイルなのに消せなくなる、とかいろいろな苦労もあった。
ただし、今なら、DockerなりAnsibleで、環境構築の構成管理が可能になったので、いつでも環境を複製したり、再現することが楽になったのはありがたい。

たとえば、UMLでオブジェクト指向設計を習得しても、データモデリングの手法を通じて業務システム設計が分かったとしても、実際にUMLやDOAのモデルを描けるツールが必要だ。
実際にモデルを描いてみると、数多くのモデル間の整合性を取るのが大変なのが分かるし、実はモデリングの記法に制限がありすぎて、あるべき機能を描きにくい、という気づきもあったりする。

特に、データモデリングの手法は日本では昔から技術が蓄積されていて、そのノウハウも十分にあるし、業務システム設計にとても役立つのに、さほどそのノウハウが普及していないのは、データモデリングのツール自体がオープンソースで提供されていなかったり、使われていないからだ。
ER図を描くだけでも気づきは多いのに、ER図を描けるモデリングツールはそもそも標準がないのが実情。
だから、データモデリングの考え方自体も普及していない。

【4】2つ目は、ITの技術や知識を使ったベストプラクティスは、ツールの一機能として実現されているので、ツールの機能を使いこなすことで、自然に知識やノウハウを身につけられるからだ。

たとえば、Rubyの開発環境で最も優れているのはRubymineだろう。
RubymineでRubyを書いてみると、デバッグもできるし、ブレイクポイントを置いて、実際に動く変数の中身もウォッチできる。
しかも、RubymineにはRubyという動的言語であっても、リファクタリング機能が付属しているので、ちょっとした変数名の置換、ロジックをメソッドで抽出する、などの操作を簡単に行える。
つまり、リファクタリング本で知られているリファクタリングのベストプラクティスがRubymineのツールの1機能として実現されているので、Rubymineを使いこなしていくうちに、リファクタリング技術にも慣れて、きれいなコードを書くノウハウも身に付く。
もちろん、テストユニットのソース支援機能もあるから、自動テストも実装できるから、そういう機能を使っていくうちに、プログラミングの能力も身についていく。

たとえば、CCNAのようなCisco機器の知識、ネットワークの一般的な知識を身に着けたい場合は、Ciscoのルータやスイッチを実際に中古品で購入して、オンプレのネットワーク設計を行いたい。
しかし、実際はそこまでお金を払わなくても、PacketTracerのようなシミュレータ、GNS3のようなエミュレータが無料であるので、それらを使ってPC上でネットワークのトポロジーを作って動かしてみればいい。

実際に試してみると、L2スイッチでVLANやSTPの設定、ルータでRIP、OSPF、デフォルトゲートウェイ、サブネッティングによるIPアドレス付与、などの基本的なネットワーク設計は非常に難儀な作業であることがよく分かる。
IPアドレスの数字がちょっと間違えただけでも、すぐに疎通できなくなる。
100人以上の社員がいる社内ネットワーク構築で、ルータを10個以上配置する場合、ネットワークの冗長化や負荷分散、セキュリティ面をきちんと考えておかないと、すぐにユーザからクレームが来るだろう。
そういう設計を行うための技術は、たとえば、STPやHSRPのような冗長化や負荷分散、ACLやPortSecurity、AAAのようなセキュリティの機能があるので、それらをCisicoコマンドで実際に実現すればいい。
そういうネットワーク設計をルータやスイッチのような実機ではなく、PacketTracerやGNS3のような無料ツールで事前にネットワーク・トポロジーを試しておけば、いろんなノウハウが身に付くだろう

たぶん、クラウドも同じように、実際にAWSで色々試しながら、身につけた方が習得が速いはず。

たとえば、Redmineは単なるITSやBTSではなく、プロジェクト管理ツールとして使われるようになった。
すると、プログラマ出身だが、プロジェクトリーダーの役割は初めての経験で、そんなにチームビルディングに自身がない人であっても、Redmineというツールの機能を駆使すれば、基本的なスケジュール管理や課題管理はこなせるようになる。
また、アジャイル開発のプラクティスとRemdineの各機能は相性がいいので、チームビルディングやコミュニケーション活性化に活用することもできるだろう。
つまり、Redmineの機能を十分に把握できれば、自然にプロジェクト管理力も身についていく。
Redmineのいろんな機能は、10年以上のOSS開発を通じて、世界中の開発者の要望が実現されていて、それらは全て、ソフトウェア開発に役立つように作られたからだ。

逆に言えば、PMBOKのような知識を持っていたとしても、実際のプロジェクトの現場で発揮できなければ意味がない。
Excelで自前でガントチャートによるスケジュール管理を作ったり、自前で工数管理のVBAやEVMのVBAを作り込んだりしていたプロジェクトリーダーを実際に見てきた。
たしかに彼らはそういうツールを作り出すだけのVBA能力があり、マネジメント能力もあったわけだが、僕はOSSのプロジェクト管理ツールとかGitHub、GitLabなどを使いこなすことで自然にベストプラクティスが身についていく、という成長のやり方の方が好きだ。
「ツールがプロセスを改善していく」という発想が僕は好き。

ツールでプロセスを実装すべきか、プロセスを確立してからツールを導入すべきか: プログラマの思索

チケット駆動開発はツールによる改善か、プロセスによる改善なのか: プログラマの思索

ツールがサポートすれば考え方も変わる: プログラマの思索

チームの開発環境が開発プロセスの品質を向上させるのに導入されない理由: プログラマの思索

ツールが開発プロセスを改善する: プログラマの思索

開発プロセスの型をツールで構築する #tidd: プログラマの思索

【4】そんな事を思うと、ITの技術や知識はツールの習得と表裏一体である、という事実を改めて感じている。
換言すれば、プログラミング開発環境、サーバー環境、ネットワーク環境、プロジェクト管理ツール、ソースコード管理ツールなどのツールを使いこなしていけば、そのツールの機能に実装されているベストプラクティスは自然に身に付くのだ。

それらのツールの機能には、長年の蓄積で得られたコンピュータ科学やソフトウェア工学の理論、数多くのプログラマやネットワーク技術者が苦労して導いてきた泥臭いノウハウが数多く詰まっている。

だから、教科書を通じてIT技術の知識を習得するよりも、実際に開発環境を揃えてプログラムを書いたり、サーバーを動かしたり、プロジェクト管理ツールを準備して実際にスケジュール管理や課題管理をやってみる、という体験の方が重要だと思う。
そして、そういう試行錯誤は、20代のような若いうちにやった方がいい。

最近気づいたが、年齢を取るほど、PCの前に長時間座ってコマンドを叩くのが割ときつくなってくる。
いくらツールを通じて知識を習得すればいい、と言っても、ツール自体もどんどん進化するから、それらにキャッチアップしていくのも大変。
視力が落ちてくるし、老眼になってくるし、体力面も厳しくなる。

昨今のDXというバズワードの流行を見ると、ビジネスも生活もあらゆる場面で、全てがソフトウェアで代行されていくだろう。
そういうソフトウェアを自分のものとして制御していくためにも、ソフトウェアの基本的な知識や技術は習得しておきたい。だからこそ、ツールの機能を習得することで、自然に知識やベストプラクティスが得られるように、そのやり方にも慣れておきたい。

JRubyの終焉

一時期流行したJRubyについて、JRuby on Rails は難しい、という記事を見つけた。
ラフなメモ。

【参考】
JRuby on Rails は無理かもしれんね、という話｜Seahal

Redmine on JRuby: プログラマの思索

Redmine on JRuby part2: プログラマの思索

Redmine on JRuby part3～RedmineはJRuby＋Tomcatで動かす方が簡単: プログラマの思索

JRubyでRedmineBacklogsプラグインを動かす: プログラマの思索

（引用開始）
かつて JVM のメリットとされた ‘Write once, run anywhere’ というメリットも Vagrant や Docker といった仮想環境や、Go言語のように多種の環境に対応したバイナリを吐き出せるコンパイラが出てきた今、それほど JRuby に対するメリットを感じるのが難しくなってきたような気がする。
（引用終了）

Redmineでも、Ver4からJRubyが外されたので、何かあったのかな、と思っていた。
10年前は、Railsのwarファイルが作れるし、JavaのWebサーバーも使えるぞ、と思っていたが、今となってはCRubyも十分高速化されてきたし、DockerやAnsibleなどで仮想環境を構築するのも簡単になった。
Windowsでも、WSLを入れれば、Ubunts上でRuby環境を作った方が安全だ。

こういう状況を振り返ると、OSSのライブラリや言語は時代の流行り廃りはどうしても発生することを痛感する。
10年前は、JavaからRubyへ、というキャッチコピーが流行り、ドメイン特化言語に適したRubyが非常に脚光を浴びていた。
今は、機械学習や深層学習、データ分析にスポットが当たっているので、PythonとRが注目されている。
昨年、大学の生協の本屋に行ってみたら、プログラミングコーナーにはPythonとRでほとんどが占められていて、他言語は申し訳無さそうに少しだけ飾られていたのが驚きだった。

PythonとRubyの違い

PythonとRubyの違いの記事が参考になったのでメモ。

【参考１】
PythonとRubyの違い | Qrunch（クランチ）

記事の内容は同意する。
個人的感想では、Pythonの方がより実用的な気はする。

実際、Javaはelse if、Rubyはelsifだが、Pythonはelsifと一番短い。
Pythonは予約語も一番少ない。
from モジュール import 関数で書くと、モジュールやオブジェクトは意識しなくていいので、関数っぽく書ける。

【参考２】
【Ruby】PythonプログラマーがRubyを触って感じたこと - 歩いたら休め

Pythonプログラマから見ると
「Rubyはオブジェクト指向にこだわりすぎている」
「変な記号がいっぱいある」
「ブロック（ラムダ式）が強力すぎる」
であるらしい。
確かに、変な記号は多すぎるので最初は慣れるのに時間はかかる。

下記のアドバイスも参考になった。

（引用開始）
逆に、RubyのプログラマーがPythonを勉強したいなら、以下の3点を押さえておけば、ちゃんとしたプログラムが書けると思います。

リスト内包表記
ジェネレーター（遅延評価）
ふつうに定義した関数がオブジェクトであること
（引用終了）

【参考３】
Rubyのリファクタリングでイケてないコードを美しいオブジェクト指向設計のコードへ改良するための方法 - Qiita

Python のリファクタリングでイケてないコードを別に美しいオブジェクト指向設計ではない普通のコードにする方法 - Qiita

個人的感想では、Rubyのリファクタリング例はとても綺麗で参考になる。
Rubyの威力を見せつけられる感じ。

一方、Pythonの例はもう少し意義が感じにくかった。
もっといい例があるのかも知れない。

Ruby技術者認定試験の感想

Ruby技術者認定試験Silver・Goldに合格したので感想をメモ。
Ruby初級者なので、間違っていたら後で直す。

【参考】
Ruby技術者認定試験

Ruby技術者認定試験のGoldに受かったので感想 - 模索中

Ruby技術者認定試験（Silver && Gold）合格体験記 | Avintonジャパン株式会社

ruby gold 2.1 - Qiita

Ruby技術者認定試験のGoldに受かったので感想 - 模索中

新人プログラマがRuby技術者認定試験(Gold 2.1)に1ヶ月半以内で合格する勉強法 - IT女子ブログ

Ruby初心者だけどRuby Association Certified Ruby Programmer Silverを取得した！ - suusan2号の戯れ

Ruby技術者認定試験 Goldを受験しました - ZENET Tech Blog

【1】Ruby技術者認定試験Silver・Goldは、とても良い試験だったと思う。

Rubyの文法やライブラリを一通り知っておく為に勉強せざるを得ない環境にできること、そして、初級者はSilver、中級者はGold、というように、レベルも上手く設定されているからだ。
特にGoldは、メタプログラミングの知識や経験がないと合格は難しい。
Ruby経験者、Rails経験者であっても、一夜漬けでは合格できないだろうと思う。

【2】試験対策は、Ruby技術者認定試験にあるオンラインの模擬試験を100点が取れるまで解くこと、推奨の書籍3冊を読み込むことだった。

オンラインの模擬試験はたぶん、Ruby実務経験があっても試験慣れてしていないと取りこぼすかな、と思う。
間違えた問題は、ミスした原因を分析して、理解できていないのか、分かっているのに勘違いしたのか、でふるい分けて、Webや書籍で調べて納得するまで腹落ちさせることが大事。

【3】お勧めの書籍は5冊ある。
「Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応」
「メタプログラミングRuby第2版」
「Rubyのしくみ　Ruby Under a Microscope」
「改訂2版 Ruby逆引きハンドブック」
「Effective Ruby」。

【3-1】「Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応」に記載の模擬試験は必ず解いておくべき。本試験でも割と同じ問題が出るときもある。

【3-2】「メタプログラミングRuby第2版」はとても良かった。
Rubyにあって、Javaにはない特徴がメタプログラミングにあると思う。
Rubyの面白さはここにあると思う。
Javaの経験に引きずられていたので、サンプルを写経してようやく、ダック・タイピングのイメージがつかめてきた。

たとえば、io.print　という処理では、ioはFileオブジェクトかもしれないしIOオブジェクトかもしれないし、printはインスタンスメソッドではなくインスタンス変数かもしれない。
つまり、的確にオブジェクトを定義すれば、ポリモルフィズムが背後で上手く動作して、たった一つの表現で複数パターンの処理を実現できる。
さらに、Rubyは読みやすさを重視しているので、処理がそのまま英文であるかのように読める。
特に、内部DSLをRubyで表現する時はそうだ。

「メタプログラミングRuby第2版」の良かった点は2つある。
まず、Railsの仕組みを紹介してくれていること。

たとえば、ActiveRecord::Baseでは、インスタンスメソッドが300個以上、クラスメソッドが500個以上も含まれている巨大なクラスだ。
著者が言う通り、Javaプログラマならば、こんな設計は狂っている、スパゲティコードだ、と最初は思うだろう。
しかし、むしろRailsでは読みやすく変更しやすい設計になっているのだ。
つまり、著者の言う通り、設計技法は絶対的なものではなく、設計技法は使用言語によって変わる。

その他に、ActiveSupport::Concernは進化的設計から生まれたし、alias_method_chainは廃止されてprependが使われる設計に変わった。
つまり、最初は問題解決のためのシンプルなコードを書いて、その後、ゴーストメソッド多用に対するパフォーマンス改善やalias_method_chain多用に対するスパゲティコード対策などのために、どんどんフレームワーク設計そのものを変えていった。
すなわち、Rubyのやり方は、最初から正しい設計を行うよりも、後から機能改善やパフォーマンスを改善していく進化的設計、つまりアジャイル開発がとても向いている。
その理由は、Rubyが徹底したオブジェクト指向言語でありメタプログラミングしやすい特徴を持つので、とても柔軟性の高い言語だからだろう。

【3-3】「メタプログラミングRuby第2版」の付録「よくあるイディオム」は、Ruby初級者が暗記すべきテクニックと思う。
参照したいので、イディオムを載せておく。

O’Reilly Japan - メタプログラミングRuby 第2版

アラウンドエイリアス（Around Alias）
ブランクスレート（Blank Slate）
クラス拡張（Class Extension）
クラスインスタンス変数（Class Instance Variable）
クラスマクロ（Class Macro）
クリーンルーム（Clean Room）
コードプロセッサ（Code Processor）
コンテキスト探査機（Context Probe）
あとで評価（Deferred Evaluation）
動的ディスパッチ（Dynamic Dispatch）
動的メソッド（Dynamic Method）
動的プロキシ（Dynamic Proxy）
フラットスコープ（Flat Scope）
ゴーストメソッド（Ghost Method）
フックメソッド（Hook Method）
カーネルメソッド（Kernel Method）
遅延インスタンス変数（Lazy Instance Variable）
ミミックメソッド（Mimic Method）
モンキーパッチ（Monkeypatch）
ネームスペース（Namespace）
nilガード（Nil Guard）
オブジェクト拡張（Object Extension）
オープンクラス（Open Class）
Prependラッパー（Prepended Wrapper）
Refinements（Refinements）
Refinementsラッパー（Refinements Wrapper）
サンドボックス（Sandbox）
スコープゲート（Scope Gate）
自己yield（Self Yield）
共有スコープ（Shared Scope）
特異メソッド（Singleton Method）
コード文字列（String of Code）
SymbolのProc変換（Symbol To Proc）

メタプログラミングRubyの感想: プログラマの思索

【3-4】「改訂2版 Ruby逆引きハンドブック」は、Rubyのライブラリを一通り説明してくれているので、APIを調べたい時に便利。

特に、RubyでもJavaでも、どんなプログラミング言語でも、配列Array、連想配列Hash、文字Stringのメソッドは最低限必ず覚えておくべき。
なぜなら、配列やハッシュ、文字を自由自在に操れないと、自分がやりたいことを実現する手間が多くなりすぎて、イライラするから。
もちろん、それ以外にもファイル処理、Web操作、クラス設計なども必要。

Java経験者から見ると、RubyはArrayやHashのライブラリが非常に多いし、便利な使い方が多いように思う。
Rubyはブロックが使いやすいので、ArrayやHashの各要素に何らかの処理を一括操作したい時に、1つのメソッドで1行で書ける場合が多い。
VBやJavaならば数行もまどろっこしく書いてしまう部分が簡単に書けるのは素晴らしい。
但し、たとえば、mapとcollect、selectとfind_all、injectとreduce、findとdetectなどのように、異音同義語が多い点は注意。

「改訂2版 Ruby逆引きハンドブック」は今も愛用している。

Ruby初心者が間違いそうなこと: プログラマの思索

SmalltalkとLispから来たメソッドmap と collect、reduce と inject: プログラマの思索

【3-5】「Effective Ruby」はRubyらしい書き方の解説本。
最初はRubyらしい書き方が分からず、VBやJavaみたいな書き方になってしまっていた。
その原因は、Rubyのライブラリを幅広く深く知っていないこともあったが、Ruby独特の考え方や書き方が分かっていなかったからと思う。

僕は、下記が参考になった。

項目1　Rubyは何を真と考えているかを正確に理解しよう
項目2　オブジェクトを扱うときにはnilかもしれないということを忘れないようにしよう
項目6　Rubyが継承階層をどのように組み立てるかを頭に入れよう
項目12　さまざまな等値の違いを理解しよう
項目15　クラス変数よりもクラスインスタンス変数を使うようにしよう
項目18　要素が含まれているかどうかの処理を効率よく行うために集合を使うことを検討しよう
項目19　reduceを使ってコレクションを畳み込む方法を身に付けよう
項目24　リソースはブロックとensureで管理しよう
項目28　モジュール、クラスフックを使いこなそう
項目29　クラスフックからはsuperを呼び出そう
項目30　method_missingではなくdefine_methodを使うようにしよう
項目31　evalのさまざまなバリアントの間の違いを把握しよう
項目32　モンキーパッチの代わりとなるものを検討しよう
項目33　エイリアスチェイニングで書き換えたメソッドを呼び出そう
項目34　Procの項数の違いに対応できるようにすることを検討しよう
項目35　モジュールのprependを使うときには慎重に考えよう
項目47　ループ内ではオブジェクトリテラルを避けよう

全てのイディオムを掲載しておく。

Effective Ruby（長尾高弘 arton PeterJ.Jones）｜翔泳社の本

第1章 Rubyに身体を慣らす
項目1　Rubyは何を真と考えているかを正確に理解しよう
項目2　オブジェクトを扱うときにはnilかもしれないということを忘れないようにしよう
項目3　Rubyの暗号めいたPerl風機能を避けよう
項目4　定数がミュータブルなことに注意しよう
項目5　実行時の警告に注意しよう

第2章 クラス、オブジェクト、モジュール
項目6　Rubyが継承階層をどのように組み立てるかを頭に入れよう
項目7　superのふるまいがひと通りではないことに注意しよう
項目8　サブクラスを初期化するときにはsuperを呼び出そう
項目9　Rubyの最悪に紛らわしい構文に注意しよう
項目10　構造化データの表現にはHashではなくStructを使おう
項目11　モジュールにコードをネストして名前空間を作ろう
項目12　さまざまな等値の違いを理解しよう
項目13　""<=>""とComparableモジュールで比較を実装しよう
項目14　protectedメソッドを使ってプライベートな状態を共有しよう
項目15　クラス変数よりもクラスインスタンス変数を使うようにしよう

第3章 コレクション
項目16　コレクションを書き換える前に引数として渡すコレクションのコピーを作っておこう
項目17　nil、スカラーオブジェクトを配列に変換するには、Arrayメソッドを使おう
項目18　要素が含まれているかどうかの処理を効率よく行うために集合を使うことを検討しよう
項目19　reduceを使ってコレクションを畳み込む方法を身に付けよう
項目20　ハッシュのデフォルト値を利用することを検討しよう
項目21　コレクションクラスからの継承よりも委譲を使うようにしよう。

第4章 例外
項目22　raiseにはただの文字列ではなくカスタム例外を渡そう
項目23　できる限りもっとも対象の狭い例外を処理するようにしよう
項目24　リソースはブロックとensureで管理しよう
項目25　ensure節は最後まで実行して抜けるように作ろう
項目26　retryでは回数の上限を設け、頻度を変化させ、オーディットトレイルを残そう
項目27　スコープから飛び出したいときにはraiseではなくthrowを使おう

第5章 メタプログラミング
項目28　モジュール、クラスフックを使いこなそう
項目29　クラスフックからはsuperを呼び出そう
項目30　method_missingではなくdefine_methodを使うようにしよう
項目31　evalのさまざまなバリアントの間の違いを把握しよう
項目32　モンキーパッチの代わりとなるものを検討しよう
項目33　エイリアスチェイニングで書き換えたメソッドを呼び出そう
項目34　Procの項数の違いに対応できるようにすることを検討しよう
項目35　モジュールのprependを使うときには慎重に考えよう

第6章 テスト
項目36　MiniTest単体テストに慣れよう
項目37　MiniTest仕様テストに慣れよう
項目38　モックオブジェクトで決定論をシミュレートしよう
項目39　効果的なテストを追求しよう

第7章 ツールとライブラリ
項目40　Rubyドキュメントの扱い方を覚えよう
項目41　irbの高度な機能を使えるようになろう
項目42　Bundlerでgemの依存関係を管理しよう
項目43　依存gemのバージョンの上限を指定しよう

第8章 メモリ管理とパフォーマンス
項目44　Rubyのガベージコレクタの動作に慣れよう
項目45　Finalizerでリソースリークを防ぐセーフティネットを作ろう
項目46　Rubyプロファイリングツールを使おう
項目47　ループ内ではオブジェクトリテラルを避けよう
項目48　コストの高い計算をメモ化することを検討しよう

Effective Rubyを読んだので感想を書いてく - WEB SALADの記事も参考になる。

【3-6】「Rubyのしくみ　Ruby Under a Microscope」はRubyのインタプリタYARVの仕組みを解説しているディープな本。
普通はこの本のレベルまで理解する必要はないと思うけれど、僕はRubyの定数探索のアルゴリズムと特異メソッドがどうしても腹落ちできなかったが、この本で何となくイメージできた。

たとえば、Rubyのメソッド探索は継承チェーン上に1本でたどる一方、定数探索は最初にレキシカルスコープで検索してから次に継承チェーンをたどる。
よって、定数検索の方がやや複雑だし、ソースを上から読み込むので、そんな挙動になるのかという発見もあった。

たとえば、Rubyのオブジェクトの特異メソッドやクラス本体のクラスメソッドは、特異クラスという別のクラスに存在する。
よって、特異メソッドやクラスメソッドが存在する場所は別のクラス、特異クラスにあるので、特異クラス系列の継承ツリーが別途存在する。

なお、「メタプログラミングRuby第2版」にも特異クラスの絵が掲載されていて詳しく説明してくれているのだが、通常のクラス系列の継承ツリーと、特異クラス系列の継承ツリーを混ぜ込んだ絵で記載しているので、僕には分かりづらかった。
一方、「Rubyのしくみ　Ruby Under a Microscope」では、メモリ上にRubyのオブジェクトがどのように配置されるのか、絵が書かれているので、僕には理解しやすかった。

結局、プログラミング言語を理解するには、メモリ上に変数やオブジェクト、配列、ハッシュがどのように配置されるのか、を自分の頭でイメージできなければならないから。

下記の章がお勧めと思う。
Rubyがメモリ上にどのように展開してくれているのかをイメージしやすくなる。

第5章 オブジェクトとクラス
第6章 メソッド探索と定数探索
第8章 Lisp から借用したアイデア
第9章 メタプログラミング

Rubyの定数のお話 | media.growth-and.com

Rubyの定数探索の個人的な謎に迫る - Qiita

「Rubyのしくみ」を読んだ後のRubyの感想: プログラマの思索

【4】Rubyを実際に実務に使う場合は、事実上、Railsをマスターすべきだと思うので、Redmineのソース解読もしながらちょっとずつやっている。

Javaや.NETのWebシステムの開発経験からRailsを見ると、Web開発でまどろっこしい共通処理やWeb特有の処理をRubyのメタプログラミングで上手く隠蔽して、コーディングルールを強制することで数行で書けるようにしている部分はすごいな、と改めて思う。

僕がRailsですごいなと思う点は、特に、JavaScriptとの相性が良い点だ。
Railsが生まれた当初から、prototype.jsやJQueryとの連携はスムーズだったし、JavaScriptを駆使することでWebのUIを豊かにしてくれた。
最近のRailsは、JSライブラリの発展とともに、VueやReactとも親和性が高い。
つまり、クライアントサイドのUI改善も取り込めるので、JavaやPHPなどの他の言語よりもRailsの優位性は高いような気がする。

【5】Rubyを勉強している時の僕の脳みそは、錆びついた機械時計に油を挿しながら、回転させようとしている感覚だった。
こういうことをRubyで実現したいんだ、要件や設計は分かっているのになぜすぐに書けないのか、という苛立ちを感じながらRubyのライブラリを覚えて、動きに慣れようとしていた。

「プログラミングのできる羊とできない山羊を区別する方法」の記事のリンク: プログラマの思索にある「プログラミングができない羊」みたいな地点から登っている感じだった。

でも、初めてのプログラミング言語を習得するには、どんな手順を踏めば良いのか、どういう点に注意すれば習得速度を上げられるか、という感覚はつかめてきた。
今は次のプログラミング言語としてPythonを習得しようとしているが、Rubyの習得経験や、RubyとPythonは考え方が似ているメリットもあって、割と楽に習得できそうな感じ。

結局、プログラミング言語が分かったという感覚になるには、自分の脳みそがコンパイラになりきって、メモリ上に変数やクラスがどのようにロードされて値が変わっていくのか、イメージできる必要がある。

こんな経験は誰でも知っているのだろうが、20代の若い年齢なら簡単であっても、40・50代と年齢を取るごとに、新しいプログラミング言語の習得はどんどん難しくなる。
しかも、プログラミング言語の隆盛は10年おきに移り変わるから、そのたびに以前の言語を捨てながら新しい言語に慣れていかないといけない。
たとえば、FortranやCobolからC/C++/VB、そしてJavaやC＃、さらにRubyやPHP、そしてPythonやR、へどんどん変わってきている。
JavaもKotlinで書くのが普通になってきているようだし。

そんな事を考えると、アジャイル開発は常識だ: プログラマの思索にも書いた通りだったのを思い出す。

（引用開始）
ソフトウェア業界の特徴の一つは、一度高い能力が得られてもそれを完全にやり直さねばならない点がある。
Cobolで一流であったとしても、JavaやC#のプログラミングは一流とは限らない。むしろ、オブジェクト指向の概念を知らない可能性も高く、オブジェクト指向の初心者かもしれない。
Javaを知っていても、RubyやiPhoneやAndroidアプリは初心者かもしれない。
様々な言語を学び、共通部分があったとしても、技術の変化によって常に立場は悪くなり、完全に分かったという状態にはならない。
また一から勉強して成長しなければならない。
（引用終了）

最終的には何かアプリが作れればいいな、と思っている。

「Rubyのしくみ」を読んだ後のRubyの感想

「Rubyのしくみ」の感想とRubyの感想をラフなメモ書き。
主張は特になし。
間違った点は後で直す。

【参考】
書籍紹介『Rubyのしくみ Ruby Under a Microscope』

『Ruby のしくみ』を読んだ - blog.kymmt.com

『Rubyのしくみ -Ruby Under a Microscope』の読書メモ＜第1~5章＞ - kenju's blog

『Rubyのしくみ -Ruby Under a Microscope』の読書メモ＜第6~7章＞ - kenju's blog

『Rubyのしくみ -Ruby Under a Microscope』の読書メモ＜第8~9章＞ - kenju's blog

『Rubyのしくみ -Ruby Under a Microscope』の読書メモ＜第10~11章＞ - kenju's blog

『Rubyのしくみ -Ruby Under a Microscope』の読書メモ＜第12章＞ - kenju's blog

Rubyの定数探索、instance_evalやmodule_evalの挙動、特異クラスの性質について、分かったような気がしないので、「Rubyのしくみ」を買って読んでみた。
「Rubyのしくみ」の中身はかなりDeep。
まだ全部は分からない。

RubyがYARVというVMベースのインタプリタ言語であることも、この本を読んで初めて知った。
JavaがJavaVMで動いているのと似ているが中身は全く違う。

「Rubyのしくみ」を読んで、良かった点と自分の気づきをメモしておく。

【1】下記の章が読みたかった部分だった。

第5章 オブジェクトとクラス
第6章 メソッド探索と定数探索
第8章 Lisp から借用したアイデア
第9章 メタプログラミング

Rubyは、他のプログラミング言語に比較すると、ほぼ完璧なオブジェクト指向言語と思うので、メモリ上にオブジェクトやブロックがどのように実現されるか、というイメージがないと、本当に理解できた気にならない。
ソースコードを解釈したイメージの絵を多用しているので、理解しやすくなっているのは良い。

【2】「Rubyのしくみ」を読んで、include/prepend/refinementsの仕組みが腑に落ちた。

Rubyのモジュールは、内部ではクラスと同じ。

includeの実装は、インクルードしたモジュールをクラスとしてコピーして、継承チェーン上に挿入するイメージ。
prependの実装は、prependを含むクラスをoriginクラスとしてコピーして、継承チェーンの最下部に挿入するイメージ。
prependを使えば、簡単にオーバーライドできるので、エイリアスメソッドチェーンを多用する必要もない。

refinementsも、refineしたクラスを無名クラスとしてコピーして継承チェーンの最下部に挿入するイメージ。

【3】Ruby特有の仕様がある点に注意する。

RubyはJavaと違って、インスタンス変数とクラスインスタンス変数は明確に異なる。
それぞれインスタンスメソッド、クラスメソッドでアクセスして編集する。

Javaと違って、オブジェクトは必ず特異クラスも持つ。
クラスメソッドは、該当クラスの特異クラスに住んでいる。
もちろん、特異クラスにあるクラスメソッドとインスタンスメソッドは異なる。

Rubyのメソッド検索は、継承チェーンを下から辿ってマッチするまで探す。
マッチしなければ、method_missingで補足されて、NoMethodErrorになる。
他方、動的プロキシでは、method_missingでゴーストメソッドを補足して、別メソッドに変換してしまう。

Rubyの定数検索は、まずレキシカルスコープで定数を検索し、その次に継承チェーンで定数を検索する。
レキシカルスコープで定数検索するロジックは、Module.nestingの順に検索すること。
この仕組みを知らずに何度も引っかかった。

ブロックはRuby特有の書き方の気がする。
Rubyのブロックに慣れたら、JavaScriptやPythonよりも直感的で、読みやすく感じる。

メタプログラミングはRubyの真骨頂。
JavaやC#がXMLを多用するのとは違い、Rubyは内部DSLで全てRubyで実現できるのは素晴らしい。
JavaやC#が嫌になる時は、XMLばかり書かされている時と同じだから。

instance_evalもclass_evalも、evalと仕組みは一緒。
但し、処理は異なる。
instance_eval内のメソッド定義(def～end)は特異メソッドになるので、インスタンスメソッドを定義したい場合は動的メソッド(define_method)を使う。
一方、class_eval内のメソッド定義はインスタンスメソッド。

また、instance_eval do～endと、instance_eval(<<-EVAL)：ヒアドキュメントでは、定数検索が異なる。
Module.nestingで出力してみると、前者は[]なのでトップレベルの定数、後者は[特異オブジェクト]なので、特異オブジェクトに属する定数になる。
この点も知らずによく引っかかった。

Proc#[]という書き方があるのもびっくりした。
「改訂2版 Ruby逆引きハンドブック」を読んでいたら、メソッド呼び出しに似せるためにProc#[]のように書く、という説明があって、なるほどと理解できた。

【4】Rubyには異音同義語が割と多くある。

mapとcollect、injectとreduce、selectとfind_all、detectとfind。
lengthとsize, count。
他にもいっぱい。

aliasはキーワードで、alias_methodはModuleのprivateメソッド。
undefはキーワードで、undef_methodやremove_methodはModuleのprivateメソッド。
module_functionで、メソッドを関数化できる。

RubyはVerUpで言語仕様がどんどん機能追加されているので、その歴史による経路依存性のせいかもしれない。

【5】Ruby初心者が悩みがちな特殊記法も多い。
慣れれば、短く書ける。

Ruby初心者を脱した人が悩みがちな、ちょっと特殊な記法・演算子・イディオム - Qiita

*args：配列で受け取る可変長引数。splat引数。

**opts：ハッシュで受け取る可変長キーワード引数。

*変数：splat演算子で配列要素を展開する。

&block：ブロック引数。

&:method_name：メソッドに & とともにシンボルを渡すとto_proc が呼ばれて Proc 化され、それがブロックとして渡される。

なお、メソッドオブジェクトを呼ぶ場合、&method(:メソッド)を使う。
動き方は、(1)Object#method でオブジェクトにあるメソッドをオブジェクトにする。(2)メソッドオブジェクトには、Object#to_proc があるので、&演算子でブロック引数に渡すことができる。(3)メソッドをブロック引数に渡すことができる、になる。

_変数：使わない変数名を宣言。だから、Rubyのローカル変数は「英小文字かアンダースコア(_)始まり」になる。

||=：通称「nilガード」。初期化イディオムとして使う。

<=>：宇宙船演算子、UFO演算子

->：lambda式で用いる「lambdaリテラル」や「アロー演算子」と呼ぶ。

「::」：スコープ演算子。ネームスペースで使う。定数探索でよく出る。

=>：「ハッシュロケット」と呼ばれ、ハッシュリテラルを書く際にキーと値を区切るもの。

「&.」：呼称はSafe navigation operator、通称ぼっち演算子。obj&.my_method形式でのメソッド呼び出しで、objがnilでなかったらmy_methodを実行。

「!!」：すべてをtrueかfalseにする。

Ruby初心者が間違いそうなこと

Ruby初心者が間違いそうなことの記事に共感したのでメモ。
適当なラフなメモ書き。

【参考】
Ruby初心者が失敗しがち/間違えがちなこと5選 | Workship MAGAZINE(ワークシップマガジン)

1. 範囲演算子の範囲を読み違えがち
=> 範囲演算子「..」「...」は異なる。点一つで意味は全く違う。

2. 引数にProcをそのまま渡しがち
=> Procをブロック引数として渡すために、&演算子を使う。
　　さらに、シンボルで渡す方が簡略化できる。
　　injectが良い例。
　　＆演算子を使う部分はPerlに似ている。

3. Array#mapのブロック引数で、途中結果を返却するためにreturnを書きがち
=> mapやselectなど、ブロック引数を受けとるタイプのメソッドを使用する際、「ブロックの途中で得られた値」を「そのブロックで得られた最終結果」として返却したい場合では、「return」ではなく「next」を使う。
結構間違える。

4. 正規表現のマッチ結果を思うように取得できない
=> （）でグループ化した正規表現に対し、組込変数$1,$2...に、マッチング結果が格納される。
　Perlと同じ。Javaとは異なる。Javaの方が面倒。

5. privateなクラスメソッドを定義しようとしてpublicにしがち
=>
　privateの考え方はJavaやC#と全く異なるので、最初は混同してた。

JavaやC#の常識が通用しないRubyのprivateメソッド - give IT a try

[Ruby] privateメソッドの本質とそれを理解するメリット - Qiita

Javaならば、親クラスのprivateメソッドは子クラスでは呼び出せない。
しかし、Rubyでは「privateメソッドはサブクラスからも呼び出せる」考え方が最初は分かってなかった。
「privateメソッドは呼び出す際にレシーバを指定できない」「子クラスでは、親クラスのメソッドをレシーバ無しで呼び出せる」ことを組み合わせれば良い、という記事を読んでようやく理解できた。

6. スコープゲートが厳しい
=> Rubyのスコープゲートは厳しい。
　Rubyは、class、module、defのスコープゲートは乗り越えられない。

ローカル変数をスコープ内側へ - 【旧】PerlerのRuby日記->はてなブログに移行しました

　Perlは、myを付けなければ、ローカル変数はメソッド内でも使える。
　Javaならば、クラス内ではprivateな変数はどのメソッドでも使える。
　この点をよく間違えていた。

　一方、Rubyでは、ブロックならスコープゲートを越えられる。
　たとえば、define_method do～end、Class.new do～endのような書き方でスコープゲートを回避する。
　つまり、フラットスコープ。

メタプログラミングRubyの感想

「メタプログラミングRuby 」を一通り読み終えた。
まだ全ては完全理解できていないが、やっとRubyの面白さを感じ取れた気がする。
理解したことをラフなメモ書き。
まだ初心者なので間違っていたら後で直す。

【参考】
メタプログラミングRuby - ククログ(2010-09-13)

メタプログラミングRubyを読んだ - razokulover publog

「メタプログラミングRuby」オススメです - UUUM攻殻機動隊(エンジニアブログ)

「メタプログラミングRuby」ことはじめ?開発本部・TechLunch? - Medley Developer Blog

【1】JavaやC＃、VB等と違って、Rubyの特徴や面白さはどこにあるのだろうか？
「メタプログラミングRuby 」を読んで、自分はRubyの威力を完全に理解できていないことが分かった。
特徴は3つあると思う。

【2】一つは、ArrayやHash等の基本ライブラリが十分揃っていること。
VBはリストやハッシュのライブラリが貧弱で、ちょっとした操作にかなりの行数が必要になる。
JavaはArrayListやMapなどにはライブラリは揃っているが、Rubyほどないように思う。

Rubyならmap, collect, find, select, inject, reduceなど、配列やハッシュの単純な操作を短く書ける。
オープンクラスだから、後でいくらでも機能追加できる。

後から発展してきたプログラミング言語ほど、リストやハッシュのような基本的なデータ構造を扱う機能は豊富だ。
昔のプログラミング言語ほど、リストやハッシュの簡単な操作だけに色々考えさせられて疲れてしまう。
だからこそ、低いレイヤで考える部分が少なくなり、本来の機能のレイヤを考える方へ労力を費やせる。

【2】Rubyのオブジェクト指向はJavaとかなり違う。
Javaはクラス重視だが、Rubyはメソッドを重視しているように感じる。

Rubyと大クラス主義とダックタイピング、そして名前重要 - ゆとRubyist日記

つまり、Rubyはメソッドを実行するレシーバよりも、メソッドというインターフェイスを重視している。
Rubyでメタプログラミングを読んでいると、メソッドなのか変数なのか最初は判別できない時がある。
たとえば、シンボルを渡して、ブロックに変更して処理を実行させる、とか。
むしろ、わざわざそう書いているとしか思えない。

オブジェクト指向の技術としては、Javaでは継承や委譲くらいしかないが、Rubyには、incude, prepend, extend, refineなど色んな技法が多い。
Javaはオブジェクト指向言語と言いながら、実際のプログラムは手続き型言語の気持ちで書いてる。
手続きで書いていって、ソースが長くなったら、OOPの技術でリファクタリングする、みたいな感覚。

一方、Rubyでは、メソッド探索や継承チェーン、method_missingのように、常に継承関係を意識しながら書いている。
Rubyの方が複雑な機能をスマートに書ける場合が多いように思う。
RailsのValidationで、フック処理と特異メソッド（クラスメソッド）を上手く使いこなしている解説を「メタプログラミングRuby 」で読んで、なるほどと思った。

【3】Rubyのライブラリは、メタプログラミングに向いた機能が多い。
むしろ、すごく多すぎてやり過ぎなくらい。
class_eval, define_method, instance_evalくらいならまだ良かろうが、evalで文字列のプログラムを実行評価できるのはやり過ぎなくらい。コードインジェクションのリスクもある。

でも、そのおかげで、似たような操作で名前の違うメソッドを一括処理することで、プログラム行数を相当短くできる。
たとえば、メソッドを文字列でGrepして、ヒットしたらある処理、ヒットしなかったら、ゴーストメソッドでmethod_missingで一括処理、とか。

また、Rubyでは、privateメソッドも外部から自由に扱えてしまうので、テストコードが書きやすいはず。
JUnitもリフレクションを多用しまくっていたし。
たぶん、Rubyの方が自動テストに向いているのだろうと思う。

一方、JavaやC#でメタプログラミングっぽいことをやろうとしたら、XML地獄になる。
XMLを書いている時間の方が長いくらいだ。
つまり、Javaは外部DSL、Rubyは内部DSLが扱える、ということなのだろう。
その分、Rubyだけで全て書ききれるから、ストレスも低いと思う。

そういう設計思想の元で、「メタプログラミングRuby 」では、Rubyは進化的設計に向いている、という解説があり、なるほどと思った。
たとえば、RailsのライブラリもVer1.0からVer4までVerUpするたびに、メタプログラミングで書いた部分をオブジェクト指向で書き直したり、method_missingを多用して性能悪化した部分を性能改善していくなど、色んな手間がかかっている。
そういう進化的設計は、アジャイル開発と相性が良い。
最初はまず機能をリリースして、ユーザに使える機能を提供し、VerUpするたびに機能を改善したり、性能を改善していく、というやり方だ。
そういう開発スタイルは、開発プロセスがフレームワークとして運用できるだけでなく、ソフトウェア開発技術そのものもレベルが高くなければ、コントロールできない。

つまり、Rubyはメタプログラミングとオブジェクト指向という2つの技術を使いこなすことで、適用できる場面をスムーズに変えることができ、スピード感のある開発と柔軟な開発という相反する手法をコントロールできているのだろう、と思った。