とある Rubyist の「次の20年」

Rubyist近況[1] Advent Calendar 2021 の12日目です。前日とか次の日は適当にリンク先からたどってください。

 12月12日を今年のアドベントカレンダーの担当日に選んだのは、先月の同日、11月12日で40歳となったので、そのあたりについて書こうかと思いました。

11月12日は40歳に東京から千葉に引っ越しました。生まれ育った街に引っ越しています。

いまはリモートワークで仕事できますし、生まれ育った街も交通はそこそこよくなっており大手町まで40分くらいで出られるようになっているみたいです。いざという時は出勤もできますが、これからはなるべくなら人がたくさんいるところに行かないようにしたいですね。

このエントリでは11月12日からの人生を「第三の人生」としたときに、いままでどんな人生を過ごしたのか、これからの人生をどうしたいのか、自分が感じている人生の転換を区切りに、簡単に「第一の人生」「第二の人生」「第三の人生」と分けて所感を記録しておこうと思います。

おそらく、これは間違った見解であったり、微妙なところもあるのですが所詮は40歳ほどではこれくらいの感覚だった、ということを残しておこうと思いました。限られた時間で適当に考えて、適当に書いていますしね。

すみませんが、この文章はまとまりがないですし、他人に理解されることを目的としてないです。

自分用の記録ですが、読みたい方がいたらどうぞ。

第一の人生

生まれてから、会社員になるまでの人生。

育った家庭は裕福ではありませんでしたし、家庭環境にも多少の問題はありましたが、特別に劣悪さが飛び抜けているということもありませんでした。総合的には平均より「少し悪い」か「悪い」くらいの環境だったのではないかと思います。

「いや、あなたの家庭はよい環境だったでしょう」と私の家庭を周囲から観測している方に言われるかもしれませんが、そもそも見栄っ張りで世間体を異常に気にするという「悪い」環境でしたので、それが作り出している情報に騙されているだけです。そこまでよい環境ではありません。

裕福ではありませんでしたが、この時期は自分が好きなことに挑戦して、無理なことは無理だと体験したり、自分が将来どんなことをしたいかの選択と集中などをしました。

さいわい、いまはそれほどエンジニアとして大失敗した結果になったわけではない(気がする)ので、苦労が表に出にくいですが、いろいろと挑戦や失敗はあります。

野球に挑戦してプロ野球選手になりたいと思ったことはありましたが体が大器晩成な育ちだったので少年野球ではそれほど活躍できなくて挫折しました。

高校生のときは勉強をろくにせず将棋に熱中してしまって、何かに結びつかないかと思いましたが、別にプロ棋士などになれるほどの棋力はもちろんなくて単なる趣味になりました。しかも、いまはその将棋もメチャ弱くなりました。指さないと弱くなりますね。本当に。時期は羽生善治が活躍していたときですが、自分は米長邦雄の雀刺しばかり刺してました。

ゲーム好きだったのでプロゲーマーのような職種、当時はプロゲーマーという職業は日本ではマイナーだったので、ゲーム雑誌のライターみたいなのが適職なのかもと思ったことなどもありましたが、思っただけでした。

結局は中学生から高校生の時期にパソコンに興味をもちはじめて、高校生のときにはVisual Basic でプログラミングをはじめて、その後に C/C++で仕事をしている人たちが交流しているメーリングリストに入り浸るようになりました。

大学生のときにはソフトウェアハウスでのアルバイトを通して業界の当たり前を知っていくことになりました。

この時期にものすごい量のソフトウェアマネジメントの書籍を読んで、マネジメントというものについて勉強しました。マネジメントは勉強しておくと関わってはいけない上司がすぐにわかるようになるので、プログラマの方々も勉強することをおすすめします。

すでにソフトウェアエンジニアの世界に片足つっこんでいて、惰性でそのままエンジニアになった感じですね。

第二の人生

会社員になってから40歳になるまでの人生。

どうやら、自分は世間の人と比べるとちょっと変わり者だったのでかなり苦労がありました。

この「変わり者」という言葉は誤解されやすいのですが、変わり者だからといって勝手に何かの才能が芽生えたり、天才になったりするわけではないです。単に他の人とどうにも違う考え方などをしがちだった、ここではただそれだけの意味で「自分は変わり者」と記録しています。なんのことはない、ただ普通とは違うというだけのことですが、それだけで自分にとってはいろいろな経験や苦痛になりました。

新卒で大企業に入るも馴染めず、社会的なストレスから愚痴っぽくなり、インターネットにそういったことを書いていたら「宮本洋一」という人間から、繰り返し犯罪行為をされました。このときはとてもつらかったです。どんな犯罪行為であったのかは機会があったのでまとめてあります。ちょうどこの時期、宮本洋一氏からの嫌がらせによる風評被害で落とされた採用があったのでこういった文書が残ることとなったのですよね。実害は発生しています。実害を防ぎたい意図で書ききってしまったところがあり、いま読むと焦りからの誇張が散見されますが95%くらいは事実です。

インターネットにおける悪評 - 高野光弘編 from TAKANO Mitsuhiro

宮本洋一氏は逮捕されなかったからといって、彼の犯罪行為はなかったことにはならないです。むしろ、逮捕されなかったのだから司法などでは償うこともないわけです。罪を償わないという卑劣さと悪質さ、ぜひ死ぬまで犯罪者である自覚を背負い続けてほしいものです。自分の家族は同じようなインターネットのインシデントがあると「宮本洋一が世界にはたくさんいる」といった表現をするようになっていますし、完全に「宮本洋一」という言葉は自分の周りでは悪質な人間を表したり、犯罪行為を表す言葉となってしまいました。これはもう自分にはどうしようもありません。すみません「日本姓氏語源辞典 (人名力)」著者の宮本洋一さん…
2024年3月15日追記。「日本姓氏語源辞典」という著作と「在日通名大全」という著作が新たに確認できました。以前の著作はリンク先がなくなっていましたが、単に「人名力」を表題から取り除いて出し直したみたいですね。「人命力の宮本洋一」は犯罪を犯したということがインターネットに掲載されるようになったのでそのようなことをしているのかもしれません。許されることではないと思います。「日本姓氏語源辞典の著者、宮本洋一は犯罪者」で「在日通名大全の著者、宮本洋一は犯罪者」です。警察がきちんと犯罪と認めた行為を過去に行いました。これはもう揺るぎない事実なのです。罪を背負って生きなさい。

他の会社経験では明確なパワーハラスメントについてCTOに相談するも「仕事ができていないからハラスメントを受けて当たり前、仕事でパフォーマンスを出してからそういった相談をしなさい」というアドバイス(パフォーマンスが出ないのはハラスメントが起因なので、これは無限に解決に結びつかないアドバイス)が返ってくる会社でのつらい労働と会社都合退職。

技術力のないCTOが率いるベンチャー企業でハラスメント(後に冤罪であることを伝え聞いている)の疑いをかけられて会社都合退職。

いろいろとありました。

だいたい疲れる話ですね。何か掘り返されたときにそれらしい自衛ができそうな音声やメモなどの記録は残してありますが、可能であれば使うことなく墓まで持っていきたいです。

全体として第一の人生で豊かになった人生をすり減らして生計としていた時期なのだろうと、いまとなっては感じています。

仕事だけではなくてプライベートもすり減ることが多かったです。

基本的に悪人に騙されやすいんですよね。

どうしてこんなことになったんだろう…って思うこともありますが、変わり者なのだから仕方ないと思っています。たまに「変わり者だから」などの理由で済ませるのではなくて、諦めずに気合いを入れて変わり者をやめなさい、というようなことを言ってくる人がいますが、できたらやってますし、人の根幹について簡単にアドバイスをしようとするのは頭がおかしいと思っていますので、頭がおかしい人たちは相手にしないことにしています。すみません。

第三の人生

先月の11月12日が40歳です。第三の人生と書いているのは、40歳からの人生の予定とまでは言わないですけれど、生きていて感じていることですね。

ちょっと第二の人生での仕事が格闘技で例えるなら、有刺鉄線デスマッチや極真空手みたいな刺激の強い仕事が多くて疲れを感じました。

第三の人生ではスポーツチャンバラのような楽しい仕事を主軸にしていきたいと思っています。

すり減った人生を豊かにすることを主軸にしたいというわけです。

第一の人生で育んだようなものを再び取り戻さないと今後に不安があります。

60歳くらいになったらまた心をすり減らせるような人生を送る必要があるかもしれませんが、それはそのときに考えます。

楽しく過ごせて、それが続けられればいいんですけどね。

直近、なにやってんの？と言われるとフリーランスで仕事をしたり、していなかったりします。その時の気分によって体力や精神のすり減りがなるべくないことを重視しています。仕事を続けることよりも健康の方が大切です。

なんだかんだで精神的な豊かさがいちばん大切なのだな、と思うようになりました。

観測範囲では、同世代のエンジニアが頑張って知識を身につけていたり、技術力を向上させていたりする傍ら、なにか大切なものや精神をすり減らして言動がおかしくなってしまう方たちをたくさん見るようになってきてそう思うようになりました。第二の人生のわたしも何かおかしかったのでしょう。そう思って苦労やおかしかった言動は過去のものにしていきたい。だいぶ、この文章も苦いものがありますがね。

さしあたりは生まれ育った街で平穏に生きたいと思います。

この文章はツッコミどころある感じで書いてしまいましたが、どうせ所属している会社がないのですから会社に回りくどくこの記事をどうにかしてくれとか連絡されることもないし、たまにはいいでしょう。

40歳にもなって脇が甘いことがわかっている文章を適当にインターネットに書くくらいには稚拙です。でも、それが自分なのです。

今年の Ruby

Rubyist のアドベントカレンダーですし、Ruby committer なので Ruby についても書きたいと思います。

予定は未定とはいえ、今年に入れたい、入れられればよいと考えている修正があります。

振り返ると、昨年に FreeBSD の Dtrace 対応を無効にしないとコンパイルできないので規定を無効にするというコミットを入れました。

Ruby 3.0.0 のリリース前に微力ながらコミットした話

それから、じっくりと三ヶ月ごとくらいに調べていたのですが、どうやら FreeBSD のツールチェインが変わったのでリンクができなくなった、というような内容をどこかでみました。

しばらく、ツールチェインが元のように修正されないのか LLVM の動向を追っていたのですが、どうにもそういった雰囲気はなく、次のバージョンの LLVM 12 でも同じ挙動でリンクに失敗することを確認しました。FreeBSD のバージョンアップを待っていても解決するような問題ではなさそうです。

どうしたものか、と考えていたのですが、ふと ports の状況はどうなっているのかを見たら、Ruby と Dtrace についての議論を見つけました。比較的大きな修正を make する前にパッチして Dtrace を有効化してコンパイルが通るようにするというような処理が ports に入っていることを確認できました。

Bug 257527 - lang/ruby27: add DTRACE option

クリスマスまで残り少ないですがこの修正を Ruby の本体に入れることができないか見てみようと思っています。パッと見ではこれを取り込んでもライセンス的には問題ないはず。

留意するべきこととしては FreeBSD の ports は FreeBSD のバイナリを作ることができればうまく機能しているということになりますが、これを Ruby 本体に入れるとなると Dtrace が提供されている他のプラットフォームでも妥当性のある修正かどうかを判断する必要があります。

FreeBSD はおそらく ports で適用される修正をそのまま適用した状態で Dtrace が機能するのでしょう。Dtrace は他にも Solaris や macOS でも提供されている機能なので、その修正が Solaris と macOS で Dtrace を有効化したときに正常に機能するのかを確認したいところです。

Intel 64 macOS はどうにかなりそうな気配がありますが、M1 macOS ではどうなのかということや Solaris での確認に少し不安が残りますね。ports でのビルドで適用される修正が他のプラットフォームのことも考慮されているものならよいのですが、その確認はまだできていません。

ちょっとここまで積み残してしまったというか、気付くのが遅かったので今年に間に合うかは微妙ですが、手をつけたことについては最後まで追っていきたいと思っています。

あいさつ

今年もさまざまな方のおかげで、無事に年を越せそうです。

来年もよいお年を。

Ruby でブロックを使ったメソッドを定義してみよう

Ruby Advent Calendar 2015 - Qiita の 12月5日の内容です。

Ruby のブロックとかについて書きます。

毎年アドベントカレンダーがある言語だし、同じような内容がたぶんあると思うんですけど、全部の内容を見直してかぶってないか確認するのとかしんどいので、ブロックのネタ書きます。

普通の使い方

みなさんもよく使うのは Array#each とか Range#each あたりでの使い方ですかね。
たとえば、 1 から 10 の数字を画面に表示するコードとかは下のような内容になります。

(1..10).each do |i|
  puts i
end

このときに使ってる do と end の間にある部分がブロックと言うヤツです。

わりとコイツは便利なんですが、組み込みのクラスや用意されたメソッドなどに対してのブロックは使えるけれど、自分でブロックを与えるメソッドを定義するということに慣れていないユーザが多いような気がするので、今日はその方法について書きます。

ブロックを受け取るメソッド

結論から言ってしまえば、  block_given? というメソッドと yield という式を使えば扱うことができます。
たとえば、整数について偶数か奇数の集合ということを意識したクラスを作ってみます。
名前は EvenOrOddNumbers とします。

class EvenOrOddNumbers << Array
end

ちょっと横着して EvenOrOddNumbers は Array のひとつ、という関係があるとしました。

偶数と奇数を判別する

さて、この EvenOrOddNumbers の Numbers に 偶数がふくまれているかを調べるメソッドと奇数がふくまれているかを調べるメソッドを追加してみましょう。

class EvenOrOddNumbers << Array
  def include_even?
    each do |i|
      return true if i.even?
    end
    false
  end
  def include_odd?
    each do |i|
      return true if i.odd?
    end
    false
  end
end

こんな感じで書くことができます。
利用例は以下のような感じです。

eoon = EvenOrOddNumbers.new
eoon << 1
eoon << 3
eoon << 5
p eoon
puts "include even: #{eoon.include_even?}"
puts "include odd:  #{eoon.include_odd?}"
puts
eoon = EvenOrOddNumbers.new
eoon << 2
eoon << 4
eoon << 6
p eoon
puts "include even: #{eoon.include_even?}"
puts "include odd:  #{eoon.include_odd?}"
puts
eoon = EvenOrOddNumbers.new
eoon << 1
eoon << 2
eoon << 3
p eoon
puts "include even: #{eoon.include_even?}"
puts "include odd:  #{eoon.include_odd?}"

実行結果はこんな感じになります。

[1, 3, 5]
include even: false
include odd:  true
[2, 4, 6]
include even: true
include odd:  false
[1, 2, 3]
include even: true
include odd:  true

ここまでは普通にブロックを使うとこんなメソッドが作れて便利ですよ、みたいな感じで別にブロックを渡すメソッドは作ってないです。

偶数のみや奇数のみを扱うメソッドを作ってみる

本題ですね。偶数のみの each や奇数のみの each を定義してみましょう。

普通はひとつの定義にまとめますが、ブログ的に面倒なので先ほどのクラス定義のあとに以下のコードを記述してもメソッド定義できるので、こんな感じに書いてみました。

class EvenOrOddNumbers
  def each_even(&block)
    each do |i|
      yield i if i.even?
    end
  end
  def each_odd(&block)
    each do |i|
      yield i if i.odd?
    end
  end
end

使い方はこんな感じです。

eoon = EvenOrOddNumbers.new
eoon << 1
eoon << 1
eoon << 2
eoon << 3
eoon << 5
eoon << 8
eoon << 13
puts "EvenOrOddNumbers: #{eoon}"
evens = []
eoon.each_even do |i|
  evens << i
end
odds = []
eoon.each_odd do |i|
  odds << i
end
puts "evens: #{evens}"
puts "odds:  #{odds}"

出力はこんな感じ。

EvenOrOddNumbers: [1, 1, 2, 3, 5, 8, 13]
evens: [2, 8]
odds:  [1, 1, 3, 5, 13]

上の定義の例ではブロックが渡されなかったときの挙動を考えていないのですが、ブロックが渡されなかったときの挙動を記述するには block_given? を使います。

class EvenOrOddNumbers
  def each_even(&block)
    raise 'No block given' unless block_given?
    each do |i|
      yield i if i.even?
    end
  end
  def each_odd(&block)
    raise 'No block given' unless block_given?
    each do |i|
      yield i if i.odd?
    end
  end
end

超適当なんですが、ブロックが渡されなかったとき、いきなり Exception を発生させるという処理を入れるとこんな感じです。

each という名前がつくメソッドだとブロックがなかったときの挙動というのは、どんなものか考えるのか面倒なんで、マネしちゃだめです。

所感

ブロックの扱いについて、複数の引数を受け取るブロック、たとえば Hash#each_with_index とかはどうやって作るか？とか考えると面白いと思います。

今日の内容はこんなところで。

っていうか、最後まで書いて気づいたけど、数年前に同じネタをアドベントカレンダーに書いた気がしてきた・・・まあ、気にしない方針で。

2015年に参加する Advent Calendar

Ruby と Smalltalk と Pyspa のカレンダーに参加しています。
今日、余裕あると思って Ruby と Smalltalk のカレンダーの内容を書くことになっているんだけど、わりと余裕なかった。

これから書きます。

いまこそ Ruby の力じゃ！ Capybara を使え！！！

この記事はRuby Advent Calendar jp: 2011 : ATNDの4日目です。前日は@hiro_asariさんのRubySpec を走らせるでした。
こんにちは、最近コミットできていない幽霊Rubyコミッタとなりつつある@takano32です。はやく復帰できるようリハビリしています。

さて、今日は Capybara というものを使ってWebでのテストなどを自動化する方法について簡単に説明したいと思います。
と、いいたいところなのですが、面倒なので説明は特に設けることなく、コメントとして説明を入れました。
なんか不足しているモジュールとかがあって走らないようでしたら、空気を読んで gem install hoge すれば動くんじゃないかな。たぶん。

本来はWebサービスのテストなどに使うのですが、今回は分かりやすいように日記やAdvent Calendarで使っているみんなも大好きな「はてな」に自動でログインするスクリプトを書いてみました。


こんなかんじで気軽に記述することができます。ヤバイですね。
特にヤバイかなぁ、ってポイントをふたつほどあげてみます。

• Capybara.register_driver で Android端末などのUser-Agentを使うことができる
• 「どうせ高度なアクセスはAndroidからはこないだろう」って思ってるサイトは危険かもしれません。ってーか、危険ですよ。
• val = evaluate_script('JavaScriptVariable') のような記述をするとJavaScriptの変数がRubyの変数として使える。
• JavaScriptの変数の中に次のサイトへの遷移のURLを入れていたりしてませんかね。危険ですよ！普通にJavaScriptの変数にアクセスしてブラウザの訪問先を変えたりできます。

今回は Ruby でブラウザの自動操作などができる Capybara を紹介してみました。最後に危険という話ばかりしていますが、よい子のみなさんはテストなどに使いましょう。ダメ、絶対。

５日目はZonu.EXE, tadsan.による記事の予定です。楽しみですね！