2021年12月12日日曜日

とある 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%くらいは事実です。

宮本洋一氏は逮捕されなかったからといって、彼の犯罪行為はなかったことにはならないです。むしろ、逮捕されなかったのだから司法などでは償うこともないわけです。罪を償わないという卑劣さと悪質さ、ぜひ死ぬまで犯罪者である自覚を背負い続けてほしいものです。自分の家族は同じようなインターネットのインシデントがあると「宮本洋一が世界にはたくさんいる」といった表現をするようになっていますし、完全に「宮本洋一」という言葉は自分の周りでは悪質な人間を表したり、犯罪行為を表す言葉となってしまいました。これはもう自分にはどうしようもありません。すみません「日本姓氏語源辞典 (人名力)」著者の宮本洋一さん…
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 でのビルドで適用される修正が他のプラットフォームのことも考慮されているものならよいのですが、その確認はまだできていません。

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

あいさつ

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

2021年2月18日木曜日

デブサミのCiscoのブースでDevNetとCMLいうものを教えてもらった

 とりあえずのメモ


DevNet

https://developer.cisco.com/


DevNet 紹介記事

https://gblogs.cisco.com/jp/2018/10/cisco-devnet-introduction/


DevNet 紹介スライド

https://www.slideshare.net/CiscoJapan/cisco-modeling-labs-cmldevnet


公式が提供している DevNet についての日本語の情報ポータル

https://learningnetwork.cisco.com/s/jp-devnet


Cisco Modeling Labs
CML は Cisco Modeling Labs の略

https://developer.cisco.com/modeling-labs/


Cisco Code Exchange

CML でのコード例などはこちらから探せる

レポジトリが GitHub などと結びついている

https://developer.cisco.com/codeexchange/


あとできちんとした記事にする…かもしれない。

2020年12月25日金曜日

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

概要

今年もクリスマスです。Ruby 3.0.0 がリリースされました。
微力ながら Ruby 3.0.0 には自分の変更も取り込まれたのでそのメモです。

 FreeBSD では Ruby 3.0.0 がビルドできない?

3.0.0 のリリースを調整しているチャットで「どうにも FreeBSD 12-RELEASE では Ruby 3.0.0 がビルドできないらしい」という噂を聞きつけたのが24日の18:00くらいのことでした。

3.0.0-preview1 と 3.0.0-preview2 と 3.0.0-rc1 などの 3.0.0 の系列は configure のときに --disable-dtrace を指定しないとバイナリが生成できないなあ、というところまでは24日に実機で切り出して原因を特定しました。

その後はプライベートで Zoom 忘年会があったのでたらふく酒を飲んでしまい修正のことなどすっかり忘れる。寝る。

以下参考。

チケットとしては存在していたもののチケットを追えておらず、たまたまリリース前のワチャワチャでコアメンバーが話題にしているのを見なければスルーしていたと思う。

プラットフォームが FreeBSD のときは DTrace を既定で無効にする

翌日の25日は10:00くらいにモソモソ〜っと configure のときの既定が --disable-dtrace に倒れていた方がよかろうと autoconf のための configure.ac をいじりはじめる。久々にいじったので気持ち悪かった。

11:30 ほどに形が定まって、手元でのテストなども終わった。コアメンバーに報告し、そのまま「コミットしてください」という反応を成瀬さんからもらった。はやい。すごい。聖人。

ところが、いままで Ruby にコミット入れるのは Subversion で ci.ruby-lang.org にアクセスしてやっていたもんだからイマドキの方法が分からん。

GitHub.com からでもよいですか?と聞いたところ、これにも成瀬さんから PR でいいですよ、という返事をすぐにいただけました。

ササッと github.com/takano32 に fork して PR を作りました。ありがとうございます。


ちょいちょい CI の様子をみてもらってそのままマージしてもらいました。助かり。

GitHub.com での主張がデカい

これがマジでマジにリリースの直前の取り込みだったそうで面白いことが起こった。
GitHub.com では git でタグを打つとそのタグについてのページが生成されるのだが、Ruby 3.0.0 のリリースページは以下のように生成されました。


なんか少し笑ってしまった。

これじゃあ、このページを見たひとは Ruby 3.0.0 は @takano32 ってヤツがリリースしたんだってよ。みたいな様子に見えなくもないじゃないか…主張がデカい!!!成瀬さん、リリースありがとうございます。


Ruby 3.0.0 についての所感

さまざまな変更や改善があり期待できる。メジャーな部分については周りのブログなどを見ていただきい。

個人的にテンションが高まったのは Erlang のように読み書きできそうな機能が増えたことです。


最後に

FreeBSD ではこの記事で扱った変更を取り入れる前までは Ruby 3.0.0 をインストールするときに下記のようなオプションが必要な状態でリリースに向く形でした。

CONFIGURE_OPTS='--disable-dtrace' rbenv install 3.0.0

この記事で紹介させていただいた変更によって以下のコマンドで入るようになりました。手元でも動作を確認済みです。

rbenv install 3.0.0

FreeBSD で Ruby 3.0.0 をビルドするという特殊な状況に向けての修正ですが、少ない変更の割には多くの方の時間を節約することができそうな修正になったのではないかと思います。

詳しく調べてみると LLVM がデグって DTrace のオブジェクトをリンクできなくなっているようなので、新しい LLVM がパッケージで降りてきたら、これをリバートするような変更を忘れないようにしたいと思います。

では、みなさんもよい Ruby 3.0.0 ライフを。

メリークリスマス!!!

2020年12月12日土曜日

今泉研究室では2006年にプログラミング言語Haskellの洋書を輪読していた

この記事は

Imaizumi Lab Advent Calendar に寄せた記事である。

Haskell との邂逅

 2006年のわたしは Haskell というプログラミング言語に憧れをもっていた。

ところが、日本ではあまり話題になっておらず、Haskell の技術関連書籍はすべて洋書。

そんななか、今泉研究室は研究で英語の論文を読解できるようになるための訓練も兼ね、ゼミで洋書を輪読するという話を聞いた。

その日以来、研究室では周囲を言いくるめ、なんとかしてゼミで Haskell の洋書を輪読する方角へと誘導する私がいたのである…

そして、ゼミでは Haskell を使って関数型プログラミングを理解する Introduction To Functional Programming Using Haskell を輪読する流れにすることに成功したのであった!

当時の Haskell 事情

日本ではあまり話題になっておらず、というだけではイメージがしにくいと思われるので当時の Haskell 事情を簡単に列挙しておく。

  • Haskell の最大派閥となる処理系は GHC ではなく hugs 98
  • hugs 98 の仕様がコロコロ変わっており、書籍のサンプルコードが修正なしでは動かない
  • hugs 98 のキラーアプリは Audrey Tang が実装した Perl 6 の処理系となる pugs くらいしかない
上記のような状況であり、なぜ Introduction To Functional Programming Using Haskell の輪読の誘導に成功したのか分からない…

わりと積極的にやりたいことをやろう!と言えばやらせてもらえたが、言わなければ放置される研究室だったと当時を振り返る昨今である。

Chapter 12: An automatic calculator

Functional Programming Using Haskell のなかでも最難関の章を担当したときの資料とコードがでてきた。
An automatic calculator という証明系の処理系を作成する章である。難易度に容赦がない。
多くはすでに記憶にないのでコードと実行結果のみを示しておく。
書籍でこられのコードについて解説されていたという分量にも驚きだが、いくつかの自明なコードについては記述さえなかったと記憶している。 断片的にそのままの写経では動かなかったため、きちんと証明が動いたときにはうれしかった記憶がある。 そのうれしさにかまけて、後日ラムダ計算の簡約器を作ることになったのだが、それはまた別の話…

所感

短いが、今日の記事は以上である。上記の解説をまとめたスライドとレジュメを作成し 2006年3月20日に研究室で発表を行ったという記録が残っていた。
また、その他にも Functional Programming Using Haskell で担当した章はいくつかあり、すべてについて hugs 98 での動作を確認している。
くどいようだが書籍の写経そのままではコードは動作せず、動かせていた学生は自分だけだったと記憶している。
もっと詳しく知りたいなどのことがあればさらに解説を加えたり、別の章について言及するかもしれない。
記憶がある部分についてでご容赦いただきたいが…

輪読の様子

なお、難しいことが英語で書かれていたのでゼミの発表内容の多くは壊滅的だったもよう。🙈

2018年8月7日火曜日

CoD: BO4 の Private Multiplayer Beta Weekend 1 に参加

Call of Duty: Black Ops 4 の Private Multiplayer Beta Weekend 1 に参加した。

プライベートベータテスト

よくオープンベータテストというのは聞くと思うが、プライベートベータテストというのには耳慣れない方も多いのではないか。

簡単に説明すると、オープンベータテストは参加する意思があれば参加できる、というようなテストになる。それに対してプライベートベータテストは参加するのに対象となるプロダクトの予約などをしている消費者が参加できるテストとなっている。

しかしながら、今回の CoD: BO4 のプライベートベータテストは少し特殊で PS4 については製品の購入をしなくても参加できるものであった。
PlayStation Store でプライベートベータテストの権利が販売されていた様子をみた方もいると思うので補足をすると、この販売は 100 JPY で行われていたものであるが、プライベートベータテストが終わった後には払い込みのあった決済手段に払い戻されるそうだ。
なぜそんなことをしているのか、ということについて憶測にはなるが、これはクレジットカードが使えることを確認することによってレーティングが守れている状態でプレイされているということをシステム的に保証するものだと思われる。
なお、プライベートベータテストの参加については Amazon.co.jp でもプロダクトコードを発行していたのでクレジットカードがなくてもそちらを経由して参加することはできたと思う。

ちなみに、オープンベータテストやプライベートベータテストとは別にクローズドベータテストという言葉もよく耳にすると思うのだが、これはオープンベータテストやプライベートベータテストが原則的に参加する意思があれば参加できるというものであるのに対して、クローズドベータテストでは参加する意思がある希望者からさらに抽選されたりする場合が多い。

おすすめのプレイ

閑話休題。

自分は CoD: BO シリーズについてはプレイ経験はあったものの、家庭用ゲーム機で参加という経験は浅かった。パソコンで慣れた操作に比べるとぎこちない。率直に表現すれば死にまくる、殺されまくる、ということになる。

プレイリストにある Search & Destroy は実力がないと同じチームメンバーに迷惑をかけてしまいそうと感じる。Chaos TDM(Team Death Match) については撃ち合いがうまくないとゲーム内経験値が蓄積されにくいと感じる。

個人的に初心者におすすめなのは Control だ。これは新しいゲームモードでなかなか他でも見かけない感じがするけれどもスプラトゥーンでいうところのガチエリアみたいなヤツである。ポイントを占領して維持することで戦績となる。

Control が初心者におすすめできる理由はその目的が故にキルデスに依存しなくてもゲーム内経験値を稼ぐことができる、ということである。
ポイントの占領と維持が目的なので占領に参加するだけでも経験値を積むことができる。
ポイントの占領は敵チームメンバーを排除して一定時間、ポイント付近に滞在すること、滞在の間にキルされない、という行動で可能になる。
これに貢献すればよいので、味方がクリアーしてくれたポイント付近に一緒に残り、防衛するという、初心者にとって比較的難易度が低い消極的な参加方法でも経験値を積める。
初心者すぎて狙いがままならないようなプレイヤーでも索敵をして相手に撃たせて、すぐに逃げるといった行動でも十分に貢献できるのでよいと思う。
逃げ回って占領だけするキャンパーになれというわけではなく、貢献しつつ育っていけばよいのではないか、ということだ。

おすすめのスペシャリスト

同じような理由で CRASH くんがいい。

あとでかく

2016年8月11日木曜日

Linux に慣れてきたと感じる方たちに贈りたい心構え

さて、夏ですね。

春にはブログ界隈も「新入社員に伝えたい〜」とかそんなタイトルでたくさんのエントリが書かれていたものです。
しかしながら、現実的なことを考えてみますと、人間というのは馬鹿なんです。春にそんなこと言われても、実際に新入社員が春にやることと言えば、分厚い仕様書をドンと渡されて「把握しておいて」くらいのものです。
実務的にオペレーションをしたりするのはこの時期くらいからなんではないか、と思うわけです。何でああいう記事を春に書くんですかね。まあ、それはいいや。

タイトルの通りなんですが、そろそろ UNIX や Linux を使いはじめたぞ、という方たちが心がけるとよいのではないかと思うポイントについて、自分の考えをまとめてみました。

「なぜ?」なのかを考える

SI-er とかになって、オレってば RedHat Enterprise Linux に Oracle の環境を作成して、それを使いこなしてどんどん成長してるぜぇ。って感じのお年頃の方もこの季節多いのではないかと思います。

だがしかしですね。きちんと本質を捉えて今後も同じ業界でやっていくためには「なぜ?」をきちんと考えましょう。たとえばですが、上述みたいな作業をした方は、たいていの場合は手順書に従ったりするわけです。その手順書というのが先人たちの知恵でもあり、自身の成長を遮る壁なのです。

ついうっかり何も考えずに SELinux を disable にしたりしてませんか?たぶん、そんな経験あるでしょう。周囲に聞いても「SELinux はトラブルの元だから」とか言われた、とか並の職場ではそんな感じなんじゃないですかね。
では、なぜトラブルの元が規定の設定になっており、有効化されているのでしょう。そういったところからきちんと「分からない」「なぜ?」を調べていくことが、いつも利用している道具の仕組みを知るチャンスになります。

というのもですね。
いまどき Linux のカーネル(譲歩して Lion's 本で PDP-11 のカーネルとかでもよい)を読破してから、システムを俯瞰的に見れる状態で実務に投入されている人材なんていないし、そんなこと社会人になってからではできないんですよ。
ならば、システムを俯瞰的に見れるようになるにはどうするか、というと、ユーザの視点から「先人たちが作った仕組みであるはずなのに、なぜこのようなことになっているのだろう?」という視点をもつことが大切になってくると思います。上から部分的に謎を解いていき、どんどん謎を埋めていく、という作戦です。

SQL などでも JOIN とか VIEW を使うときも「こうするとできるから使う」ではなくて、 JOIN や VIEW を使うべき理由を考えることが大切です。考えた結果、割とそういったものは必要なかったりしたりして、他のクエリーで代替えすることで無駄な複雑性がなくなり、 KISS な状態でシステムを維持できるようになります。

「なぜ?」を繰り返していればそのうち 0x7C00 までたどり着くのではないでしょうかね。

師が何をしているか理解する

たいていの場合は上司というのは自分よりもよりスキルセットが高いものです。
それを利用しない手はありません。

ターミナルの操作からプログラムの書き方まで、身近な先人が身につけたのもを盗む、というわけです。このとき重要なのは一挙手一投足について「何をしているのか」を理解して師と同期することです。ターミナルでよく分からないカーソルの飛び方や補完が発生したら何をしたのか聞きましょう。聞かなければ自分はいつまでも非効率なままですが、一時の恥を忍べば、これからは思考のバリエーションが増えます。

与力のある場合は「いまこういう操作をしたけど、自分だったらこうするな」みたいなことを考えてみたり、師と仲がよければ提案してみましょう。いつも質問して盗んでいるばかりではなく、恩はきちんと返していくべきです。

人が造りしものを恐れない


近頃はオープンソースのライブラリを使ったシステムなどを構築していたりすることも多いのではないかと思います。そのときによくありがちなのが、エラーメッセージをきちんとみる、というのは実践しているが、そのさきの深みについては避けるといった行動があります。

どんなシステムも人が造ったものです。たいていのシステムはごく一部の「頭の中が理解できねぇな」って人が造ったもので理解できなかったりしますが、たいていのシステムは読み解くことで理解ができます。「これはオレの仕事じゃないから」はやめましょう。積もり積もった後回しで技術や知識がない自分を形成していくというプロセスに陥ります。

もちろん、時と場合を選ばなければなりませんが、大いに深みにハマり、大いに先人たちが作った仕組みに憤りを感じましょう。そして、願わくば先人たちよりもよいものをフィードバックしてオープンなシステムに反映していくのがみなの幸せにつながるのです。

所感

ですます調で書いたらえらく仰々しい文章になった。
しかし、成長したい、という人にはこれくらいしてもらいたいと感じる昨今です。

さて、手元の FreeBSD も 10.2-RELEASE から 10.3-RELEASE に上がったことだし、そろそろ外出するかな。

2016年7月20日水曜日

英字配列を好んで使う指向があまり自分には理解できない件

キーボードの話題です。
表題の通りなんですが、英字配列が「カッコいい」という意識高い感じのプログラマが理解できない。

理由はいくつかあるんですよね。まず、自分がかな打ちで日本語入力しているというのが理由のひとつではあるんですが、これは決定的な理由ではない感じですな。英字配列でもだいたいどこに仮名の文字がマッピングされるか頭に入ってるので、モバイルデバイスとかで英字配列のキーボードしか使えない、というときでもかな打ちで日本語入力しています。

じゃあ、なんで英字配列を愛用している人が理解できないかっていうと、なんか使っている人たちの意識を見ていると気持ち悪いことが多いんですよ。「デザインがいいので英字配列使ってる俺カッコいい」みたいなワナビー系の感じとか「プログラマならやっぱり英語でしょ」というようなよく理解できない主張がとても気持ち悪い。

だって、普通に不便じゃないですか。英字配列。キーの数が少ないんですよ。
それに、いくつかのプログラミングでよく使う英字について入力しやすいという主張も見かけるんですが、だとしたらなんで日本語の文章を書くときによく使う日本語入力について効率がよいかな打ちをしないんですかね。よく分かりません。

あと、文字コード的に英字配列気持ち悪いじゃないですか。man できる端末があったらたいていのマシンに ascii(7) あると思うので、 man ascii なり man 7 ascii で文字コードを見てみてくださいよ。0x2a が * で 0x2b が + てですよね。日本語配列だときれいに並んでますよ。
「いくつかのプログラミングでよく使う英字について入力しやすい」英字の代表として挙げられることがあるダブルクォートなんかも 0x22 に位置していて、隣の 0x23 が # なんですよ。日本語配列のマッピングと一致していてとても気持ちいいんですよ。なんでダブルクォートごときで英字配列を選択しているのかよく理解できない。だいたいにおいておまえらはあまりC言語とか書かないだろうから、リテラル文字列に使うのはシングルクォートでいいじゃねぇか、という気もします。そんなシングルクォートは 0x27 なわけですが、これまた隣の 0x26 が & で日本語配列だと隣です。なんという整合性のとれた配列なんでしょう。

日本語配列は JIS 配列なんて呼ばれたりもしますが、最近は同様の記号の配列で他国のキーボードも作られていたりするわけで、ようするに英語圏で英字配列を使い続けているのは MKS単位系が国際標準の世の中で、やれフィートだポンドだ、ガロンだみたいな気持ち悪い単位系を使ってるのと同じようなもんなんですよ。
なんで日本人であるところの君らがわざわざ標準から外れていくの?という感じでこれもまた意味が分かりません。

他にも MacBook などの日本語配列だと A の横に Ctrl がきていて規定の設定でも UNIX らしさがマシマシになってよりハッカーにとって優れていると思うんですがね。なんでわざわざ英字配列を選択しちゃうの…もったいない…

最後になんですが、わたくしはそこまで何かに偏るってことはないので、基本的には英字配列も使えますよ。使うときもありますさ。しかし、あえて英字配列を選択しなければ英字配列のものが手に入らないという状況で、ここまで気持ち悪くてよく分からない理由で英字配列を選択する意味ってそんなにあるんですかね?という感じです。

みんながもっと日本語配列のキーボードを使ってくれると、しいてはかな打ちとかしてくれれば、日本語配列のキーボードから仮名刻印を削ってオサレ!みたいな狂った製品が出回ることもなく平和なんですけど、あれはどうにかなりませんかね。

あー、なんか書き殴ってたら収集がつかなくなったんですけど、ふと思ったので書いておきました。なんかこれくらいのノリのほうがブログっぽいでしょ。たまにはいいんじゃないかな、と。

じゃあの。

2016年7月1日金曜日

kcm89 をコンパイルできなかった記録

結論。挫折した。

ドキュメント少ないし、 autotools ないな。
暗黙的なルールあるんだろうな。
が第一印象。

トップでバーンと make

% make
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C src build
cc -Wall -Wextra -O2 -DDEBUG -ansi -pedantic -MMD -MP -I. `llvm-config --cflags | sed 's/ -DNDEBUG / /g'` -Wno-long-long -c main.c -o main.o
/bin/sh: llvm-config: command not found
main.c:2:10: fatal error: 'llvm-c/Analysis.h' file not found
#include
         ^
1 error generated.
make[1]: *** [main.o] Error 1
make: *** [build] Error 2

はい、聞いてないヘッダでてきたぁ。
とりあえず、 brew で探して info してみる。

% brew info llvm
llvm: stable 3.6.2 (bottled), HEAD [keg-only]
Next-gen compiler infrastructure
http://llvm.org/
Not installed
From: https://github.com/Homebrew/homebrew/blob/master/Library/Formula/llvm.rb
==> Dependencies
Build: xz ✔, cmake ✘
==> Options
--universal
Build a universal binary
--with-clang
Build the Clang compiler and support libraries
--with-clang-extra-tools
Build extra tools for Clang
--with-compiler-rt
Build Clang runtime support libraries for code sanitizers, builtins, and profiling
--with-libcxx
Build the libc++ standard library
--with-lld
Build LLD linker
--with-lldb
Build LLDB debugger
--with-python
Build Python bindings against Homebrew Python
--with-rtti
Build with C++ RTTI
--without-assertions
Speeds up LLVM, but provides less debug information
--HEAD
Install HEAD version
==> Caveats
LLVM executables are installed in /usr/local/opt/llvm/bin.
Extra tools are installed in /usr/local/opt/llvm/share/llvm.
This formula is keg-only, which means it was not symlinked into /usr/local.
OS X already provides this software and installing another version in
parallel can cause all kinds of trouble.
無難どころと思われるオプションで install しますかね。

% brew install llvm --with-clang --with-clang-extra-tools --with-compiler-rt --with-libcxx --with-lld --with-python --with-rtti

がんばれー

これた。ちょっとこれ以上はいま時間取れそうになくて頓挫。


コンシューマの FPS ゲームに手を出したら痛い目にあっている

いやぁ、PS4 - PlayStation 4 をついに購入してしまいましたね。5月。
理由としては

  • 日本の動画配信サービスなどと相性がいい
    • システムに手を入れず、PS4が単体でゲーム実況などができる機能を持っている
  • ビッグタイトルがそれなりにある
    • スクエニとか頑張ってますし、Steamで配信されているようなインディーズゲームもいくつか配信されています
    • たとえば、スマートフォンでプレイして「操作感がゴミだなぁ」と感じてしまった Minecraft や Downwell が人類の叡智である十字キーで遊べます
  • 後輩の誕生日プレゼントに PS Vita クロスバイの製品がふくまれた
    • ウィッシュリストに入れていなくても砂が 2t とか送れるテクニックを使って送りつけてきたやつがいます
    • 先輩としては沽券にかかわるので PS4 くらい一発でポチるぜといきました
買ったモノなんですが、初音ミクマニアの私としては初音ミクモデルいったと思うでしょ?でもタイミングが悪かった。それはまだ発表されてない時期にポチった。

かといって普通のモデル買ってもつまんないでしょ、というわけで Call of Duty : Black Ops III モデルを購入して「Ubuntuカラーだ!」と気分をよくしたわけです。その後、初音ミクモデルが発表されて、ぐぬぬったわけですが、まあどうせ Play Station 4 は E3 の前後で 4K モデルが次期に発売されることがちらつかされたので、現在のやつで Play Station 4 に慣れたら、艦これモデルだかかすみちゃんブルーがきたときに書い直すかもしれないですね。

閑話休題。
PS4 の購入とともに魔の契約と思っていた Play Station Plus についに今月から加入しました。ということで、 FPS ゲームのオンライン対戦や格闘ゲームのランクマッチをガンガンしていかないと使わないだけ損という貧乏根性がでてきております。
契約はガッツリ12ヶ月契約ですね。後ろは振り返らない。ところが、Call of Duty : Black Ops 3 のオンラインプレイしてみたら、ぜんぜん相手を倒せない!!!
驚くほど倒せないんですよ。

自信はあったんですよ。それなりに。PC の FPS で動きには慣れているので、基本的な「死んで覚えろ」系のことはできるんですよ。丁寧にクリアリング、パイカッテッイングしながら周囲の安全を確認してエンカウントポイントでの警戒、足音で敵の位置を探るなどなど。
しっかし、圧倒的にAIMが定まらない、つまり狙いがガバガバ。
マウスなら一発で敵の頭らへん、武器によっては「こっから腰撃ちで勝てるはず」というところに入るんだけど、アナログパッドきつすぎ。

何が言いたいかというと、基本的な立ち回りができていて、慣れているような動きをするんだけど、妙にトロい動きをしているヤツがいたら、それは私なんで接待してください。
嘘です。温かい目で見てください。

くっそぉ、武器のカスタマイズとかしたいけど、勝てないとぜんぜんポイントが入らなくてスコープとかも気にいるような性能のものが手に入らない…
11月には Call of Duty の次回作出ちゃうんで、それまでにはなんとかアナログパッドの右で AIM ができるようになっておきたい、欲を言うならスナイパーライフルでクイックショットしたり、壁抜きで相手を抜くようにはなっておきたいんだよなぁ。

ん?オーバーウォッチ?知らない子ですね。

PCのグラボ?ぶっ壊れると面倒なので自作には関わりたくないですね?

そんなこの頃です。よろしくお願いします。

2015年12月17日木曜日

Smalltalk ではどれくらいまで長いクラス名が標準で使われているものなのか

Smalltalk Advent Calendar 2015 #Qiita の 12月16日の記事になります。

仕事で結構長いクラス名ついてるなー、っていう感じのヤツが Seaside にふくまれてい
て、コードを書くなどしていました。まあ、それはそれとして「標準で配布されているイメージで定義されているクラスの名前のうち、いちばん長いものってどれくらいの長さなの?」って気になっちゃったんですよ。

気になったら調べてみよう。ということで、やってみました。
環境は Smalltalk Pharo 5 です。



コードとしてはこんな感じ。
| allClasses |
allClasses := Smalltalk allClasses collect:  [ :each |  each name ].
allClasses sort: [ :a :b | a size < b size ].
allClasses inspect.
はい。他の処理系で試してみると違う結果が出るかもしれませんね。

Pharo 5 での結果は以下のようになりました。

どうやら
RBLiteralArrayContainsSuspiciousTrueFalseOrNilRule
というクラスがいちばん長いクラス名のようです。50文字です。2位は48文字で2文字差でのトップとなりました。

上の方だけみていると、フォントがプロポーショナルなためか、これより横幅が長く表示されているものがあって、ほんとうにこの結果あってるの?と思いましたが、下位の方をみてみると確かにきちんとソートできている模様ですね。



こういったシステム全体を俯瞰してすべてに対しての見通しがよいというのも Smalltalk のよさですね。

みなさんも「どんなメソッド名がいちばんよく使われているか」など気になったら調べてみると面白いかもしれません。

2015年12月15日火曜日

Smalltalk でシステムの基幹部を作っている会社に転職した話

pyspa Advent Calendar 2015 の 12月14日のエントリでありつつ、Smalltalk Advent Calendar 2015 の12月22日のエントリです。

「pyspa のこと、ナニ書こうかな?」って思ってたんたけど、よく見たら自分の好きなことでよかった。

こんなワタクシは数学における四択問題の解答欄に数式を細かく書いて不正解となるようなバカでした。人の話はちゃんと聞く、見る。大切ですね。はい。

そして、記事を書き終え、クリスマスを迎えた本日12月25日に Smalltalk の話でもあったな、ということで Smalltalk Advent Calendar 2015 12月22日のエントリとしました。

転職

わたくしの今年のトピックはなんといっても転職ですね。
今年の8月まで水色の六角形の会社で働いておりましたが、実際のところ、一昨年の夏くらいから、紫色の楕円をみると痙攣しそうになる病気になってましたね。いま思うと。

しかし、全部丸投げしてもらったものは赤い宝石で大勝利できたり、今年の頭くらいからちょくちょく赤いコードのレビューもしていたんですよね。さすがに紫の楕円だけではみな痙攣するようになってきたか、と思ったんですがレビューすると赤い世界では `SomeObject#true_or_false?` 的なものが `SomeObject#isTrueOrFalse` とか書いてありまして、クソ真面目にレビューで「これはなんか赤くないので治せってば」ってマサカリ投げてみたりすると「移植性を優先します」みたいなコメントが返信されてきちゃったりなんかして、クソワロスでした。

はー、もう。人海戦術の世界では何かがおかしくても、みなおかしいと分かりつつ、自分の船だけ前に進めようとして、全体として前に進んでいなくてもいいっていう雰囲気になるんだなぁって思ったんですよね。意思統一が計られていて、きちんと郷に入れば郷に従えを守るメリットを知ったるステージで仕事したいなぁと思うようになったんですよ。

そんなときに、 Smalltalk 界隈の重鎮から Smalltalk-er が不足していて困っている、という連絡をいただくことができまして、そのまま Smalltalk で仕事している会社に転職してしまいました。
ちなみに、誘っていただいた方とは15年くらい前にはじめて知りあった感じです。大学生時代にアルバイトしていたソフトウェアハウスが自社製の Smalltalk の処理系を作成し、それを用いて Linux 向けや Windows 向けのアプリケーションを動作させ、高速化させる必要のあるリリース版の作成には各プラットフォーム向けに C言語 のコードを生成するっていうヤツ作っていたんです。そんなもんで、たぶん自分がプログラミングしてはじめて給金してもらった仕事は「独自 Smalltalk 処理系向けに GTK のバインディングと Win32 API のバインディングを書きながら、 Smalltalk VM の修正した」というヤツになりますね。我ながらクレイジーですね。これは。

そうそう、15年前ほどの付き合いという話でしたね。まあ、そのクレイジーな大学時代に、独自 Smaltalk 処理系によるプロジェクトについてのコンサルというような感じでわたしがアルバイトしていたソフトウェアハウスにきてくれていたのが尊敬する師、というわけでした。その師に誘われて断る理由もなく引きこまれていったという感じてす。
しかも、ちょうど自分が悩んでいた「郷に入れば郷に従えを守るメリットを知ったるステージ」がほとんど Smalltalk という処理系が保証していますよ。だって、 Smalltalk って鎖国してガラパゴス化してるもん。

いま、うちの会社はまだ開発環境とかも「これでなんとかなるのでやってきた」という状態なので、ガンガンと「ごくある普通の近代的な開発」になるようにバシバシやってます。上にあまり人がいないし、自分がいちばんインフラとか暗黒UNIXテクノロジーに詳しいようなので、すんなり意見が通るのがラクですね。マルバツ表みたいなの書かなくても仕事できる!!!
ちなみに、エンジニアも採用しているので興味のあるヤツらはなんか連絡するといい。

来年

よくわかんないけど、年末だし最後に来年についてとか書くといいのかなってふと思ったので「来年」って書いてみたんだけど、とりあえずいまの仕事について期待されているくらい、あるいはそれ以上の成果を求めて仕事していくっていうのと、落ち着いたらコミュニティ活動とかも積極的に顔出せるようになるかなって思います。

あれ?

主にみどり色のトグロについてのアドベントカレンダーだった気がするのだが、でできたのが紫色の楕円と赤い宝石と気球ですね。
気球といえば、わたしは中田さんとかアラン・ケイとか梅澤さんを勝手に自分の師として尊敬しているんですが、うまい具合に気球つながりで弟子入りできた気がします。いや、まだ公式に弟子にしてもらってないし、リアル気球しないと中田さんの弟子にはなれない!まだまだやることはたくさんあるな!!!

ということで、これからもヨロスク!

2015年12月6日日曜日

BlockClosure の引数の数に対してことなる引数の数を与えてよしなに呼び出す

Smalltalk Advent Calendar 2015 - Qiita の 12月5日の内容です。
Smalltalk のブロッククロージャについて書きます。
このエントリで使用している Smalltalk は Pharo Smalltalk ですが、他の処理系でもだいたい同じのはずです。

BlockClosure をみてみる

Smalltalk では [ と ] で囲まれている部分がブロッククロージャとなります。



[ ] を inspect it してみました。
BlockClosure の詳細をみたい場合はどうすればいいんでしょう。っていうときに、 Smalltalk が他の言語と大きく異なる動的な評価という特徴を生かすことができます。

BlockClosure のインスタンスに対して browse というメッセージを送ってみましょう。


BlockClosure のインスタンスを inspect している下のペインで self browse と打ち込んで do it します。

システムブラウザに BlockClosure を表示することができました。ラクチン。

BlockClosure に引数を与えてみる

Ruby のブロックのように BlockClosure も引数を受け取ることができます。
たとえば、ふたつの引数を受け取って、ふたつの引数を Transcript に出力してみましょう。

BlockClosure にふたつの引数を設けて、ふたつの引数を与えるには BlockClosure でふたつの引数を受け取ることを明示的に記述して、BlockClosure>>#value:value: を使います。

出力できました。

BlockClosure が受け取る引数の数とはことなる数の引数を与えてみる

ちょっと意地悪をしてみましょう。
ふたつの引数を受け取る BlockClosure に BlockClosure>>#value: でひとつの引数を与えるとどうなるんでしょうか?
ありゃりゃ、 Error が発生してしまいました。
Ruby ではこういった意地悪をするとふたつめの引数には nil が入って例外が起こらないという挙動をするので、わりと適当に書きたいときは便利な挙動だったりします。
% ruby -e '[1,2,3].each{|i,j| p i; p j}'
1
nil
2
nil
3
nil
うーん、厳密なのもよいけれど、柔軟に受け取る引数の数より少ない引数を与えて呼び出したときにエラーが出ないのも魅力的ですね。
BlockClosure で受け取る引数とはことなる数の引数を与えてもエラーが発生しないようにできないものでしょうか。

BlockClosure の受け取り引数をよしなに処理するためのメッセージ

cull: というメッセージを使うと BlockClosure が受け取る引数の数よりも多い引数を与えても平気な挙動になります。

cull も万能ではないです

この cull: を使えばブロックの引数の数と不一致な数の引数を与えて呼び出すことができるわけですが、欠点もあります。
それは何かというと、組み込みの状態からいじっていない BlockClosure では、よっつの引数までしか扱えないのです。
原因は単純によっつまでしかメソッド定義がないからです。まあ、よっつ以上の引数なら別の方法を使った方がよくないか?という気もしますので、自然な気がします。

多くの引数をブロックで受け取りたい場合はどうすればいいのか

value: メッセージを送信して、引数に OrderedCollection とかを与えればいいんじゃないですかね。

おわりに

今回の話のネタ、ほとんど梅澤さんにアドバイスしてもらったことをまとめただけだったりします。
すみません。すみません。すみません。

2015年12月5日土曜日

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 のカレンダーの内容を書くことになっているんだけど、わりと余裕なかった。

これから書きます。

2014年10月28日火曜日

@keitahaga 先生が Chrome for Android の脆弱性で貢献 x 2

更新が滞っていたため、二件もスタックしてしまいました。

WEDNESDAY, JULY 16, 2014


http://googlechromereleases.blogspot.jp/2014/07/chrome-for-android-update.html
Security fixes:
[$3000][352083] High CVE-2014-3159: Omnibox URL Spoofing (Android). Credit to Keita Haga.

WEDNESDAY, OCTOBER 8, 2014

This release also contains the following security fix: 
[$1500][406593] Medium CVE-2014-3201: Content spoofing with scrollbar. Credit to Keita Haga.


2013年9月19日木曜日

@keitahaga 先生が iOS 7 にも貢献

ハガ先生が指摘された脆弱性の修正が iOS 7 に取り込まれたようです!


APPLE-SA-2013-09-18-2 iOS 7
Safari
Available for: iPhone 4 and later,
iPod touch (5th generation) and later, iPad 2 and later
Impact: Visiting a malicious website may allow an arbitrary URL to
be displayed
Description: A URL bar spoofing issue existed in Mobile Safari. This
issue was addressed through improved URL tracking.
CVE-ID
CVE-2013-5152 : Keita Haga of keitahaga.com, Lukasz Pilorz of RBS

私も帰ったらハガ先生のおかげでまたひとつ安全になった iOS 7 にアップデートしてみたいと思います。

2013年5月27日月曜日

@keitahaga 先生の Yahoo!ブラウザー についての脆弱性の指摘が JVN に掲載されました

@keitahaga 先生の脆弱性報告が掲載されました!
以前に調整されたら掲載されるものがある、と伺っていた件だと思います。

JVN#31817913: Yahoo!ブラウザーにおけるアドレスバー偽装の脆弱性

謝辞
この脆弱性情報は、情報セキュリティ早期警戒パートナーシップに基づき下記の方が IPA に報告し、JPCERT/CC が開発者との調整を行いました。
報告者: keitahaga.com Keita Haga 氏
次は異なるタイプの脆弱性にも挑戦されるかもしれないコメントをいただきました。
期待は高まります!

2013年5月7日火曜日

@keitahaga 先生がアドレスバー偽装についての脆弱性を二件報告!


ハガ先生のなかでいまアツいのは Android のようです!

謝辞
この脆弱性情報は、情報セキュリティ早期警戒パートナーシップに基づき下記の方が IPA に報告し、JPCERT/CC が開発者との調整を行いました。
報告者: keitahaga.com Keita Haga 氏
Nice report.

2013年4月24日水曜日

@keitahaga 先生が Sleipnir の脆弱性を報告

オレたちのハガ先生。

Sleipnir for Windows におけるアドレスバー偽装の脆弱性

Sleipnir Mobile for Android において任意のエクステンション API が呼び出される脆弱性

この脆弱性情報は、情報セキュリティ早期警戒パートナーシップに基づき下記の方が IPA に報告し、JPCERT/CC が開発者との調整を行いました。
報告者: keitahaga.com Keita Haga 氏
 いま、 keitahaga.com を訪問して何もコンテンツがないことを確認しようと思ったら、コンテンツが存在して吹いた。
Hi, I'm Keita Haga, a hikikomori living in Kanagawa, Japan.
hgkn ...

2013年2月15日金曜日

Computer History Museum から Adobe PhotoShop のソースコードが公開されました

米国のコンピュータ歴史博物館(Computer History Museum)にて Adobe PhotoShop  バージョン 1.0.1(開発当時は1990年)のソースコードが公開されました。

Computer History Museum | @CHM : Adobe Photoshop Source Code