旧gaaamiiのブログ

間違ったことを書いている時があります。コメントやTwitter、ブコメなどでご指摘ください

RubyのブロックとProcとlambdaとMethodについて

RubyのブロックとProcとlambdaとMethodについて書きたいけど自信がないです。容赦のないマサカリやツッコミをお願い致します。

ブロック

ブロックははじめてRubyを触ったときから慣れ親しんでいるものです。

%w(:Yoshida, :Tanaka, :Suzuki).each do |name|
  puts "Hello, #{name}"
end

# または

%w(:Yoshida, :Tanaka, :Suzuki).each { |name| puts "Hello, #{name}" }

do と end というキーワード、あるいは波括弧{}で行いたい手続きを囲みます。

yield

yieldは渡されたブロックを実行します。 例として、「誰かに何かする」というメソッドを定義してみます。

def do_for(name)
  yield(name)
end

do_for(:Tanaka) { |name| puts "Hello, #{name}" }
do_for(:Suzuki) { |name| puts name.upcase }

Proc

1回きりならdoとendで囲んどきゃいいけど、その手続きを変数に入れたりして保持したいこともあります。 Procクラスのコンストラクタに同じブロックを渡せば、その処理をいつでも呼び出せるようになります。

hello_proc = Proc.new { |name| puts "Hello, #{name}" }
hello_proc.call :Nishikori
%w(:Yoshida, :Tanaka, :Suzuki).each { |name| hello_proc.call name }

lambda

「ラムダ」と発音します。Procとほぼおなじですが、違いもあるようです。ただlambda式を実行して返ってくるものはProcクラスではあります。

hello_lambda = ->(name) { puts "Hello #{name}"}
hello_lambda.call :hoge
hello_lambda.class #=> Proc

Procとの違い

「Procとほぼおなじ」というからには、何か違いがあるわけですね。コメントを頂きましたのでそれをここでも共有させていただきます。

引数チェック

# Proc は引数チェックしない
hello = Proc.new { |name| "Hello, #{name}" }
hello.call :Tanaka, :Suzuki #=> "Hello, Tanaka"

# lambda は引数チェックする
hello_lambda =  ->(name) { "Hello, #{name}" }
hello_lambda.call :Tanaka, :Suzuki #=> ArgumentError

returnの処理

[TODO: サンプルコード]

Method

自信が無いのでドキュメントそのまま引用します。

Methodとは、

Object#method によりオブジェクト化され たメソッドオブジェクトのクラスです。

メソッドの実体(名前でなく)とレシーバの組を封入します。 Proc オブジェクトと違ってコンテキストを保持しません。

とのこと。


まとめ

利用の場面を経験しないとなんとも言えない感じがするので、Ruby熟練者が書いたコードをたくさん読んでいきたいです。

なにかいろいろ物足りないのでちょこちょこ書き直します。

参考リンク

参考書籍

メモ

ツールはいろいろあるけれど、それが解決している問題とかアイデアに注目すると立ち向かえそうな気がしてくる。一つ一つのコマンドを覚えるとつらいけど、もっと大きい枠組みで見ていくと楽しい。技術がわかると、普通に使っているものが、どうやって実現されているのか理解することができて楽しい。ただ頭が悪いので、時間止まればいいと思ってる。

もっとも楽しいのは、普段使っているものをバラバラに砕いて理解できたとき。なので、例えば以下の様なことについて、上から順に疑問を潰せていけると楽しい。

  • プログラムを書いてから実行されるまで
  • リンクをクリックしてからページが表示されるまで
  • git clone でプロジェクトが手元にコピーされるまで
  • cd hogeディレクトリを移動するときに起きていること

1年職場でソフトウェア開発に関わってみてわかったのは、余計なことを自ら知ろうとしないと、ツールを使う手順にばかり精通してしまって内側については何も習熟しないということ。普通に使ってるツールをいつでもバラバラに解体したり仕組みを説明できるようになりたい。

バージョン管理システムってなんだ

職場でSubversionを使ってるはずなんだけど、自分含めてみなさんかなり理解が怪しい。そもそもバージョン管理とは何か、というのをまとめたいのでこっそり書き足してまいります。

バージョン管理史ざっくり

RCS(Revision Control System)

  • 初版:1982 年

CVS(Concurrent Version System)

  • 初版:1990年

Subversion

  • 初版:2000年

Git

  • 初版:2005年

参考

http://psyto.s26.xrea.com/misc/svnbook/svnbook.ja.pdf

Emulsification ってなんだ

パスタをゆでて食おうと思ったときにレシピ検索をしたら Emulsification(乳化)って言葉を知った。英単語で呼ぶとかっこいいっす。

r.gnavi.co.jp

まず、乳化とは何かというところなんですが、本来混ざり合わない水と油が、均一に混ざり合った状態のことを言います。

とは言っても、水と油だけでは完全に混ざり合いません。ドレッシングをイメージすると分かりやすいでしょうか。

市販の瓶に入っているドレッシングって、普通に置いておくと下の部分に水分、上の部分に油分があって、食べる直前に振りますよね。振ると水と油が混ざり合ったようになるけど、またしばらくすると分離する。

しかし、マヨネーズは酢(水分)と油が混ざり合い、戻ることはありません。それは、たんぱく質(たまご)が入っているからです。たまごが乳化を安定させる役目をしています。

では、パスタソースの場合はどうなのかと言うと、茹で汁に溶け出したパスタのでんぷん質が、その役割を担います。

この乳化によって、オリーブオイルと水分が混ざり合い、とろみのあるソースとなり、麺によく絡んで美味しく食べられるというわけです。

わかりやすい。

Ruby技術者認定試験(Gold)落ちた

前からRuby触ってるし大丈夫だろうと思ってて、前日にちょろっとやって受かる予定だった。結果は56点だった。馬鹿だった。

ポイント

リンク

試験前に読んだものや、試験終わった後にもやもやを解消するのに役立ったリンクなど。

kakakakakku.hatenablog.com

qiita.com

qiita.com

本はこの三冊がいいと思う。3冊ちゃんと読み倒せばGoldなんて簡単すぎるくらいかもしれない(自分はというと、Effective Rubyは読みかけ、メタプロRubyは読んでない。あと頭が悪い)。

公式問題集はいろいろひどかったから載せない。

もう1回くらい今月末に受けて受かりたい。1万5000円もかかるのが苦しい。とはいえ勉強やはり楽しい。しかし1万5000円...(以下無限ループ)

何で難しいのか・難しいものとどう向き合うか

難しさについて。

前提を知らない

前提を知らないと、難しいと感じる。=> 遠くにある高級そうなものではなくて、自分が理解できる近場の疑問を一つずつ解消していく。

訓練を必要とする

訓練を必要とするものは、素でいきなりやると難しく感じる。 => 訓練に時間を費やす決断をする。

必要がない

自分に必要がないものを理解するのはとても難しい => 必要が無いならやらない。必要だと感じたときにやる。

頭字語コマンドを展開するwdimというコマンドラインツールをgemとして公開しました

wdimという名前でgemを公開しました。ダブリューディムとかダブディムって読んでください。意味は What does it mean の略です。

シェルでwdim ls と打つとlist segmentsが返ってきます。つまり、頭字語やら略語やらジャーゴンになっていてひと目では理解しづらいUNIX/Linuxコマンドを展開してくれるコマンドラインツールになります。

使い方

インストール

gemコマンドが使える環境で以下を打ち込んでください。

$ gem install wdim
(権限がないとかいわれる場合は)
$ sudo gem install wdim

つかう

$ wdim cd
change directory

経緯

こちらに書きました。

shgam.hatenadiary.jp

今後

正直、まともに使えるようになる前にgemとしてリリースしてしまいました。ローカルでインストール作業(git cloneしてgem build してgem install)してくれる人は少ないと思うので、ちょろっと試す際に試しやすくするためだけに公開しています。

今後はディクショナリを充実させたり、シェル作業中にパッと目につくような装飾をつけたり、また、起動の速度が気になってきたりしたらrubyではなくCで書いてHomebrewで配付したりとかそういうことを考えています。

ディクショナリ(現状はlsのようなコマンドに対してlist segmentsのような意味が記述されているymlファイル)がなにより大事なのです。この頭字語コマンドの意味知ってるよ~という方からのプルリクお待ちしてます。頭字語の意味は検索すればたいてい出てくると思いますが、議論があるものもあり、微妙なものはIssuesで話しあえたりしたら楽しいなと思ってます。

UNIX/Linux初学者にやさしい世界をつくりましょう。

github.com

UNIXコマンド ls とか mv とかのソースコードの場所

自分でコマンドラインツール的な何かを作りたい時に参考にするために、ls とか mv とかのソースは手元に置いときたい。

Coreutils - GNU core utilities の Downloads というとこからダウンロードできます。ダウンロードしたものは以下のコマンドで解凍できます。

$ tar Jxvf coreutils-8.25.tar.xz

さて、早速 coreutils-8.25/src/mv.cとか読むぞーとおもむろにタグファイルを作って(ctags -R)中身を読もうとしたところ、オプションをパースする場所を見つけました。getopt_longか〜。中身が見たいぞ〜。と思ってタグジャンプしようとしたら、できないですね。これを見るには getoptというライブラリを見ないとだめですね。というわけで今度は The GNU C Library からglibc をダウンロードします。getopt.c が glibc-2.23/posix 下にありました。getopt_long という関数は同ディレクトリの getopt1.c にありました。めでたしめでたし。 coreutils-8.25/lib/getopt1.c にありました。めでたしめでたし。

「日本のWebエンジニアの大半が、変化に対応しきれなくなっている件について。」を読んだ感想

以下の記事がはてなブックマークで盛り上がっていました。TOEIC940点の人すごい。。。

d.hatena.ne.jp

中でも以下が一番ぐっと来ました。

UNIX/Linuxコマンドを英語で学習すると、pwd は「Print Working Directory」の略なので、そのまま英語の意味からコマンド名を覚えることができるなど、様々なメリットがありました。

名前はたいていそのツールが何を解決するのか、とかどんなアイデアなのか、とかを表しています。それを理解すると覚えやすいし、コマンドにどんなオプションが存在するのかも予想しやすい。だけど、UNIXコマンドのようにやたら頭字語になっていたりギークっぽい専門語となるとスルーしたくなります。僕はman コマンドを使う時しばらくそれを男性のことだと思っていたし(正解はman manでわかります)、Linux再帰的な頭字語(Linux is not unix)って聞いた時、なんだよそれって気持ちになりました。

変化激しいとこでやっていくのにはたくさん覚え続けなければいけないのはわかってるんですが、ツールの使い方を覚えて覚えて覚え続けるというのは人生を浪費しているような気もします。ツールの名前なりそれが作られた経緯やアイデアなどに着目して効率よくキャッチアップできるマンになりたいです。そういう時にコンピュータサイエンスなりはたまた別分野の教養なり知性なりなんやかんやが役立つと思うんだけど、結局どう考えても自分には無いものだらけなので今のところは「頑張る」以外になさそうだなと思いました。

もう今年24歳になるというのに「頑張る」しか言えることがなくてつらい...。以上です。

あわせて読みたい

karur4n.hatenablog.com

追記

github.com

UNIXコマンドで頭字語やわけわからん名前付けのものを取り出して意味を出力するCUIツールの試作をつくりだした。たぶん難しいことはないので、CUIツールの基礎とパッケージの公開の仕方を学んで、あとはひたすら辞書を充実させて、自分と同じように頭字語に悩む人にとって役立つものにしたい。

何が難しいのかを切り出すだけでも難しい

他人が書いたソフトウェアを動かして困ったことが起きると、問題の特定に7割くらいの時間を使う。経験があったり仕様が把握できていたりすれば時間は短くなると思う。簡単なスクリプトならまだしも、20本のスレッドが一つのプロセス内で互いにタイミングをはかってやりとりしているような複雑なソフトウェアを改修するとなると、何が難しいのかを切り出すだけでも難しい。ソースコードの行末コメントに /* bug */ とだけ付け加えられていて恐怖を煽ってくるものもある。それを書いた人はもうこの職場にいない。

問題の特定に(自分の頭の回転が遅いというのはあるけども)時間がかかると何が辛いのかというと、仕事をしてない感がすごい。仕事をしてない感がすごいと自己嫌悪に陥る。すると、冷静な判断を下したりとか長期的な視野を持つことができなくなっていく。良いソフトウェアは書けず、書こうとする気力も失っていく。

何か複雑なものと向き合うときに、何が難しいのかを切り出すだけでも難しいということを認識する努力も必要なのかもしれない。優秀なエンジニアでさえ Yak Shaving を避けられないのだから、停止しているような時間にいちいち後ろめたさを感じていたら、精神がもたない。

あわせて読みたい聴きたい

rebuild.fm

postd.cc