Rubyのクラスで定義されたattr_accessor一覧をそのクラスのインスタンス変数から取り出す方法
一応題名の通りで「Rubyのクラスで定義されたattr_accessor一覧をそのクラスのインスタンス変数から取り出す方法」なのだが、何を言ってるのか書いた本人でも「?」となりがちなのでまずはやりたかったことから説明する。
例えばBookクラスがあって、そこに attr_accessorが定義されている。
class Book attr_accessor :id, :title, :author end
Bookクラスを作ってインスタンス変数を作る。
@book = Book.new
attr_accessorに定義されているように以下のように変数にアクセスできる。
> @book.title "STAR WARS"
やりたかったのはこの@bookを使って中で定義されているattr_accessorの一覧を取り出すこと。
こんな感じ。
> @book.something_something [:id, :title, :author]
結果的にできた方法はこれ
class BaseModel def self.attr_accessor(*vars) @@attributes ||= [] @@attributes.concat vars super end def attributes @@attributes end end class Book < BaseModel attr_accessor :id, :title, :author end
こうしておくと以下のように一覧が出る。やってみれば単純だけど、最初ちょっと悩んだ。
> @book.attributes [:id, :title, :author]
<解説>
クラスメソッドのattr_accessorの処理を上書きし、クラス変数として@@attributesを定義して、そこに一覧を格納しておくようにする。
def self.attr_accessor(*vars) @@attributes ||= [] @@attributes.concat vars super end
インスタンス変数@bookからインスタンスメソッドのattributesが呼ばれたら、クラス変数を返す。
def attributes @@attributes end
もっといい方法をご存知でしたらぜひコメントください。
なんでこんなことをやっているのかというと個人プロジェクトで作っているRailにGoogle Cloud Datastoreをつなげようとしたのがことの始まり。Google Cloud PlatformはJavaやGo、Pythonなんかには初期から対応していたのにRubyはかなり後回し。最近になってやっと対応してくれたと思ったら、その公式サイトから出ているコードがなんとも微妙。
例えばGoogle Cloud DatastoreをつなげたRailsのModelのコード例がこんな感じ。
class Book attr_accessor :id, :title, :author, :published_on, :description # [START to_entity] # ... def to_entity entity = Google::Cloud::Datastore::Entity.new entity.key = Google::Cloud::Datastore::Key.new "Book", id entity["title"] = title entity["author"] = author if author entity["published_on"] = published_on if published_on entity["description"] = description if description entity end # [END to_entity] end
Bookクラスが1つだけならいいけど、後から作るモデルクラスにも全部いちいちentity["なんやら"]って定義する訳にいかない。
初心者向けチュートリアルでわかりやすいといえばわかりやすいけど。
『〈インターネット〉の次に来るもの 未来を決める12の法則』書評
『〈インターネット〉の次に来るもの』を読んで「これはごちゃごちゃ言い訳してないで、とにかくモノ作って公開しよ」と思った。そして今、まーまー高いモチベーションでコードを書いている。たった1冊の本でここまで「やったるぞー」的な気持ちにさせる本は他にはあまり無い。
読んだのはこれ。
The Inevitable: Understanding the 12 Technological Forces That Will Shape Our Future
- 作者: Kevin Kelly
- 出版社/メーカー: Viking
- 発売日: 2016/06/07
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
紹介文の抜粋
「人工知能、 仮想現実、 拡張現実、 ロボット、ブロックチェーン、 IoT、 シンギュラリティ――これから30年の間に 私たちの生活に破壊的変化をもたらすテクノロジーは12の不可避な潮流から読み解ける。WIRED創刊編集長による待望の最新作」
人工知能や仮想現実などエンジニアが職場の同僚と雑談している際によく出るトピックをそのまま扱っている。ただそこはWIRED編集長のケヴィン・ケリーらしく、単なる最新技術の紹介には終わらない。そこに至るまでの過程が論理立てて考察されているのが本書のみどころ。
とても感銘を受けた箇所を私なりの意訳で紹介する。
- 20年ほど前にアメリカのTV会社ABCの幹部達にインターネットの脅威に関して説明したが、幹部達はいまいちピンと来てなかった。
- 最後にせめてものアドバイスとして「abc.com のドメイン名がまだ取られていません。この機会に取っておいたらいかがですか?」と提案した。
- それに反応したABCの幹部はたったひとりだけで、コメントは「ドットコムって何ですか?」だった。
- その後1ヶ月経ってabc.comの取得状況を調べたがまだ誰も手を付けていなかった。
- IT関連で働く人がよく言う「もし1995年にタイムスリップしたら。。。」に続く言葉はこんな感じ。「どんなドメイン名でも取り放題だし、オレがまっ先に検索エンジン作ってスマートフォンも作って巨万の富を得られるのに!」と。
- 実際1995年の世界ではネットはあまり普及しておらずGoogleも存在せず、スマートフォンなんて影も形も無かった。
- 現在では全てがネットで満たされてIT業界を牛耳る巨大企業がひしめき、そこに割って入るスキがほぼ無いように感じてしまう。
- 現在ではビッグワードのドメイン名を取ることなんてほぼ不可能。(abc.comはもちろん取られている)
(ケヴィン・ケリー氏による解説。ここ数年の技術革命がいかにぶっとんでいて、わずか数年で予想もしなかったことがたくさん起きていること。それらは今後もさらにスピードをあげて起こり続けること、が説明される。)
- 未来の2060年の人の生活を想像してみる。2060年に暮らすある人のつぶやき「ああ。いいなー2017年の人たちは。もし2017年にタイムスリップしたらアレ(まだ知らないすげー技術)もまだ無かっただろ。コレ(まだ知らないすげー技術2)も無かったんだろ。オレが作ってやるのに!」
- 2060年になってからそんなこと言うぐらいなら今やりましょう。
とにかく今ほど技術革命を起こすのに最適な時はないよね、と。
言ってしまえばそれだけのことであってもこれだけの最新事例と理路整然とした考察を元に語られたら「はい、そのとおり」としか言いようがない。そして「言い訳してないで、なんでもいいからモノ作って公開しよ」と心に誓った。そう思えただけで、この本の購入値段の何倍もの価値になってエンジニアに返ってくることが保証できる。
おすすめです。という訳でブログ書くのもそこそこにしてコード書くことにする。
日本語版ならこちら
- 作者: ケヴィン・ケリー
- 出版社/メーカー: NHK出版
- 発売日: 2016/07/27
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
The Inevitable: Understanding the 12 Technological Forces That Will Shape Our Future
- 作者: Kevin Kelly
- 出版社/メーカー: Viking
- 発売日: 2016/06/07
- メディア: Kindle版
- この商品を含むブログ (2件) を見る
「世界のITエンジニア向け調査結果 スタックオーバーフロー2017」はいつも興味深い
毎年やってるスタックオーバーフローのIT技術者向けのアンケート結果2017版が出た。これがいつも興味深いので一部を抜粋した。
アンケートに回答があった地域
英語でアンケート取ってるのが理由だろうが、ほぼ英語圏に集中している。日本からの回答は全体の0.4%でしかない。したがって以下のレポートでは主に英語圏のエンジニア達の動向が分かる。
性別
88.6%の男社会。どこの会社も「もっと女性のエンジニアを募集!」とやっているようだが、現実にはあまり女性に人気が無い様子。
民族性
74%が白人もしくはヨーロッパ系。たしかに職場の同僚達もほとんどこれに入っている。これはある意味アジア人である日本人が海外転職する際にはちょっと有利になるかもしれない。どこの会社も多様性を確保しようとしてるし「エンジニアの中では少数派である日本人にも入社して欲しい」と考えるケースがあるかも。
学校での専攻内容
コンピュータサイエンス、コンピュータエンジニアリングなど理工学系の学科がずらっと並ぶ。英語圏の会社で採用活動にかかわると実感するが求人応募者のほとんどがこうした学科のバックグラウンドを持ってやって来る。
プログラミングは単なる仕事か趣味か
73.9%ものエンジニアがプログラミングは単なる仕事ではなく趣味でもある、と。これは素敵なことだと思う。他の職種で7割以上の人がこれと同等のことを言うのは難しいのでは。営業職の人が「趣味で週末に家でも営業してます」って言うところは想像しにくいし。
使われているプログラミング言語
もうこれはここ数年いっつも同じ。JavaScriptが常に1番。
きっと誰もが世界でもっとも洗練された言語とは思ってないのにみんなが使っているという。
使われているフレームワーク、ライブラリ
トップ4技術のうち3つがNode.js、AngularJS、Reactで言語がJavaScript。そりゃ流行るわ。
好きな言語
好きなプログラミング言語と仕事で使う言語は大きく異なっている様子。そんなにRustが好まれているのならやってみるかな。
嫌いな言語
こちらは非常に納得できる結果。
好きなフレームワーク
Reactが好評を得ているのはなんとなく感じていた。栄誉枯渇が激しくなんども入れ替わったフロントエンド界隈がここで一旦Reactで落ち着くのかな?
開発環境
Sublime Textってそんなに人気があるのか。このVimの数字はサーバーに入った時だけちょこっと使う人の分も含まれているように思う。普段からずっとVim使っている人が27%も居ないように感じるのだが。
そんな私はVimを愛するVimmer。
仕事に対する満足度
エンジニアのお仕事には概ねご満足いただいている様子。英語圏のエンジニア給与が比較的高いのも原因のひとつだろう。
エンジニアが求職する際に重要視すべきこと
1番がコミュニケーションスキル。アルゴリズムやデータ構造の知識よりも最も大切なのはコミュニケーションだ、と。どこの国でも仕事のトラブルの原因は常にコミュニケーションにありそう。
元ネタはこちら。
stackoverflow.com
以上、スタックオーバーフローのエンジニア向けアンケート調査結果 2017でした。
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com
tango-ruby.hatenablog.com