32nd Blogger

とある Rubyist の「次の20年」

2021-12-12T23:03:00.005+09:00

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 でのビルドで適用される修正が他のプラットフォームのことも考慮されているものならよいのですが、その確認はまだできていません。

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

あいさつ

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

来年もよいお年を。

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

2021-02-18T17:45:00.004+09:00

とりあえずのメモ

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/

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

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

2020-12-25T23:20:00.015+09:00

概要

今年もクリスマスです。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 忘年会があったのでたらふく酒を飲んでしまい修正のことなどすっかり忘れる。寝る。

以下参考。

https://bugs.ruby-lang.org/issues/16674

https://bugs.ruby-lang.org/issues/17212

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

プラットフォームが 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 を作りました。ありがとうございます。

Disable DTrace in FreeBSD by takano32 · Pull Request #3999 · ruby/ruby

Ruby 3.0.0 リリースの直前に FreeBSD 12.2-RELEASE では DTrace を無効にしないとバイナリが生成できないという情報に気づき、インストール時に `--disable-dtrace` を必ずつけなくてもよいように既定を無効にした変更をしました。取り込み済みでリリースされています。 https://t.co/kgJwwfV3SW
— カールおじ (@takano32) December 25, 2020

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

GitHub.com での主張がデカい

これがマジでマジにリリースの直前の取り込みだったそうで面白いことが起こった。

GitHub.com では git でタグを打つとそのタグについてのページが生成されるのだが、Ruby 3.0.0 のリリースページは以下のように生成されました。

Release v3_0_0: Disable DTrace in FreeBSD (#3999) · ruby/ruby

Ruby に駆け込みというのもおこがましさのあるギリギリさで FreeBSD の対応をコミットしたら、タイミングがまさにタグ打ちの直前で、 https://t.co/IXkjVfF339 のタグをみると目立つ位置になんか表示されとる！！！ https://t.co/UyKphYO43Q pic.twitter.com/xqZUGy6kqx
— カールおじ (@takano32) December 25, 2020

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

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

Ruby 3.0.0 についての所感

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

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

Ruby 3.0.0 ではだいぶ Erlang に近い特徴が増えたと感じる。Ractor というアクターモデルが導入されたということは言うまでもないが、find パターンの追加はより Erlang っぽいコードを書く手助けになりそう。具体的にはバイナリのパターンマッチでパーサが書けそう。 https://t.co/uSIzS61LrT
— カールおじ (@takano32) December 25, 2020

最後に

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 ライフを。

メリークリスマス！！！

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

2020-12-12T22:19:00.005+09:00

この記事は

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 での動作を確認している。

くどいようだが書籍の写経そのままではコードは動作せず、動かせていた学生は自分だけだったと記憶している。

もっと詳しく知りたいなどのことがあればさらに解説を加えたり、別の章について言及するかもしれない。

記憶がある部分についてでご容赦いただきたいが…

輪読の様子

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

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

2018-08-07T04:36:00.001+09:00

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

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

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

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

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

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

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

2016-08-11T10:58:00.000+09:00

さて、夏ですね。

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

タイトルの通りなんですが、そろそろ 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-07-20T10:32:00.001+09:00

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

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

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

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

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

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

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

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

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

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

じゃあの。

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

2016-07-01T07:30:00.000+09:00

結論。挫折した。

ドキュメント少ないし、 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 ゲームに手を出したら痛い目にあっている

2016-07-01T07:24:00.004+09:00

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

日本の動画配信サービスなどと相性がいい

システムに手を入れず、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のグラボ？ぶっ壊れると面倒なので自作には関わりたくないですね？

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

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

2015-12-17T13:47:00.001+09:00

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 のよさですね。

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

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

2015-12-15T00:15:00.000+09:00

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

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

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

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

転職

わたくしの今年のトピックはなんといっても転職ですね。

今年の８月まで水色の六角形の会社で働いておりましたが、実際のところ、一昨年の夏くらいから、紫色の楕円をみると痙攣しそうになる病気になってましたね。いま思うと。

しかし、全部丸投げしてもらったものは赤い宝石で大勝利できたり、今年の頭くらいからちょくちょく赤いコードのレビューもしていたんですよね。さすがに紫の楕円だけではみな痙攣するようになってきたか、と思ったんですがレビューすると赤い世界では `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テクノロジーに詳しいようなので、すんなり意見が通るのがラクですね。マルバツ表みたいなの書かなくても仕事できる！！！

ちなみに、エンジニアも採用しているので興味のあるヤツらはなんか連絡するといい。

来年

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

あれ？

主にみどり色のトグロについてのアドベントカレンダーだった気がするのだが、でできたのが紫色の楕円と赤い宝石と気球ですね。

気球といえば、わたしは中田さんとかアラン・ケイとか梅澤さんを勝手に自分の師として尊敬しているんですが、うまい具合に気球つながりで弟子入りできた気がします。いや、まだ公式に弟子にしてもらってないし、リアル気球しないと中田さんの弟子にはなれない！まだまだやることはたくさんあるな！！！

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

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

2015-12-06T00:10:00.000+09:00

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 とかを与えればいいんじゃないですかね。

おわりに

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

すみません。すみません。すみません。

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

2015-12-05T23:16:00.001+09:00

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

2015-12-05T22:05:00.003+09:00

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

これから書きます。

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

2014-10-28T22:28:00.000+09:00

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

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

http://googlechromereleases.blogspot.jp/2014/10/chrome-for-android-update.html

This release also contains the following security fix:

[$1500][406593] Medium CVE-2014-3201: Content spoofing with scrollbar. Credit to Keita Haga.

@keitahaga 先生が iOS 7 にも貢献

2013-09-19T15:01:00.000+09:00

ハガ先生が指摘された脆弱性の修正が 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

http://lists.apple.com/archives/security-announce/2013/Sep/msg00006.html

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

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

2013-05-27T18:22:00.000+09:00

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

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

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

次は異なるタイプの脆弱性にも挑戦されるかもしれないコメントをいただきました。
期待は高まります！

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

2013-05-07T11:19:00.000+09:00

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

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

Nice report.

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

2013-04-24T20:54:00.003+09:00

オレたちのハガ先生。

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 ...

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

2013-02-15T13:33:00.000+09:00

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

Computer History Museum | @CHM : Adobe Photoshop Source Code

要所の抜粋です。

With the permission of Adobe Systems Inc., the Computer History Museum is pleased to make available, for non-commercial use, the source code to the 1990 version 1.0.1 of Photoshop. All the code is here with the exception of the MacApp applications library that was licensed from Apple. There are 179 files in the zipped folder, comprising about 128,000 lines of mostly uncommented but well-structured code. By line count, about 75% of the code is in Pascal, about 15% is in 68000 assembler language, and the rest is data of various sorts. To download the code you must agree to the terms of the license.

要所を訳すと以下のように書かれてます。

コンピュータ歴史博物館はAdobeシステムから許可を得て、非商用の利用につき、1990年当時のPhotoShopバージョン1.0.1のソースコードを保管することができました。Apple社がライセンスを保持している MacAppアプリケーションのライブラリのコードをのぞき、すべてをここに公開します。ソースコードはファイル数にして179であり、ZIPフォルダに梱包されています。ソースコードの行数は128,000行もあり、ほとんどすべてのコードにはコメント行がありませんが、よく構造化されている（のでコメントがなくても可読な）ソースコードです。行数をベースにして中身についてどのような構成になっているかを述べると、およそ 75% は Pascal による記述であり、 15% は 68000 のアセンブリ言語となっています。また、残りさまざまな種類のソースコードから構成されいます。ソースコードはライセンス規約の条項に同意の元にダウンロードしてください。

所感

多くの部分が Pascal で書かれているという事実に歴史を感じました。また、コンピュータの歴史に大きなひとつの足あとを残し、現在も現役で活躍しているプロプライエタリなソフトウェア PhotoShop のソースコードがコンピュータ歴史博物館に保管されたことには大きな意味があると思います。
あいにく、いままでこのような事例があったのかはわたしは存じ上げていないのですが、これからも商用の利用としては役目を終えた、さまざまなブラックボックスの過去が公開されていくかもしれないと考えるとワクワクします。

余談ですが、わたしが好んで使っているプログラミング言語 Ruby はオープンソース・ソフトウェアで歴史についてもさまざまな形でオープンになっています。こちらについて、ソースコードで詳しいく知りたい方は、ぜひ温故知新という @mrkn さんの書かれた記事もご一緒にどうぞ。

「OpenFlow 実践入門」を読んで Trema で面白いスイッチを作ろう

2013-01-08T21:12:00.001+09:00

InternetWeek 2012にてOpenFlow チュートリアル＆ハンズオンでOpenFlowのプログラミングフレームラーク、Tremaについてのハンズオンに参加し、調子に乗って開発が止まっているバージョンのTremaにpull requestしてしまったりなどしつつ、講師の高宮さん、鈴木さんと名刺交換をさせていただきましたところ、OpenFlow実践入門の献本をいただきました！

非常に恐縮です・・・

さて、いただいたOpenFlow実践入門ですが、それについてお話する前に OpenFlow について簡単に説明しますね。

OpenFlowとは

L2スイッチ（ハブとか呼ばれる）とかL3スイッチ（ルータとか呼ばれる）は大きく構成する要素をふたつに分けることができます。

ひとつはデータプレーン。こいつはパケットの転送を扱う部分です。目に見える部分でわかりやすく言うと足の部分ですね。ケーブルが生えててピコピコしてたりする部分らへんとかです。

もうひとつはコントローラプレーン。こいつはデータプレーンの制御を行なっている部分です。イメージが沸かないと思いますし、ぼくもよくは知らないんで、適当に想像すると、よく箱を開けるとワラワラとでてくる黒いムカデみたいなやつなんだと思います。

OpenFlowというのは、このうち、コントローラプレーンをソフトウェアによって擬似的に作成するために用意されたデータプレーンとのインターフェイスです。
要するにOpenFlowに対応したスイッチを買ったり、作ったりするとTremaなどで書いたコントローラプレーンを使うことができるよ、というわけです。

これは革新的なことで、いままでは細かいルールを設定してネットワークの実験がしたいな、というときにはハードウェアのスイッチが依存している制御ソフトウェアにそのルールを記述する設定がなければいけない、という状況でした。逆に表現すると、実験に利用したいアルゴリズムを実現するために、どのハードウェアの制御ソフトウェアが実験に必要な処理に対応しているか調べて購入する必要があったんですよね。

OpenFlowとその対応スイッチを使えばOpenFlowの枠組みの中での処理は自由に記述して動かすことができます。つまり、ハードウェアに付属するソフトウェアの仕様をひとつひとつ調べなくても、自分で処理を記述することで、ハードウェアのコントロールができるのです。画期的！！！

今回はそのOpenFlowの、たぶん、日本初な書籍であるOpenFlow実践入門という書籍をいただきました、という話なんです。ありがたや〜！

OpenFlow実践入門

実はおおよその内容はすでに知っていました。というのも、この本はGitHubで本文内容のおおよそが公開されているのです。~~と思ったら、オープンな場所からは消えてるような気がするので、買え！！！~~

Tue Jan 8 23:02:38 JST 2013 追記。著者の高宮さんからコメントでご指摘頂いたとおり、高宮さんのレポジトリにて、発刊以前よりずっと公開されていました。勘違いしてしまって申し訳ないです。

以下、特に良いと思ったことについて箇条書きっぽくあげてみます。

Rubyで記述することができる

これは書籍ではなく、この書籍で紹介されているOpenFlowフレームワークTremaそのものの特徴なのですが、Tremaではコントローラプレーンの内容をRubyで記述することができます。

あらかじめ必要なクラスなどの定義をロードすることでDSLな記述でパケットのコントロールを記述できます！これはとても分かりやすくて心地良い！！！

解説が分かりやすい！

解説がとても分かりやすいです。特に、ネットワークとソフトウェアの両方についてそれなりに素養のある技術者というのは限られてきますから、読者層を広げるためにはさまざまな試みが必要だったのだと思います。

ソフトウェア技術者向けにはサポートセンターをメタファにしたスイッチの内部でのやりとりについての解説があったり、ネットワーク技術者向けにはRubyのワンポイント講座のような解説が設けてあります。

日頃、よく中身を知らずに使っている機器でもTremaによる記述例があるので「MACアドレス学習型スイッチってこんなアルゴリズムで記述できるのか〜」とか勉強になりそうです。

上級者にも対応！

この本、完全におかしいです。市販品のスイッチを買ってきてメーカー保証外のファームを焼きこみ、OpenFlowスイッチを作成する方法まで掲載されています！知らなかった！これはうれしい！！！

なんといっても、自分で書いたOpenFlowの制御をシミュレーションするだけではなく、物理的なOpenFlow対応のデータプレーンを作成し、動かすことができるのですから。

ほかにも、ケーススタディとしてOpenFlowがどのように応用されているかが記されていますので、OpenFlowがもつ可能性の一部をみることができます。

まとめ

OpenFlow実践入門(原稿)を読んで、マニアックな挙動をするスイッチをTremaで作ろう！

「ヱヴァンゲリヲン新劇場版:Q」を鑑賞した

2012-11-18T05:25:00.001+09:00

で「ヱヴァンゲリヲン新劇場版:Q」をみてきたわけだが。
ネタバレについて書くかもしれないので各位注意で。

鑑賞し終わったとき、主人公に感情移入してしまって、普通に泣いてしまっていた。そんなときに次回予告するもんだから、あんまり内容が頭に入ってない、というより最後の次回タイトルですべてが吹っ飛んだ。

音がでるものに触ったものなら誰しもが意味を知っている記号がついている。

次回もすっきり終わらないことが予想される。

世界観について一言だけ

どっかの作品でこの監督はやらかすだろうなぁと思っていたが、これでやりましたか。

当たっていた予想

14年というタームが重要なものとして扱われている、ということなどを友だちなどと話していて、今回もそれが関係する可能性はあると踏んでいたが、重みつけすぎです。

ロンギヌスの槍、ちゃんと伏線回収しましたね。ああ、あと見事なまでに綾波は三人目っぽくなってますね。

んー、まー。「ネルフ関係者の幽閉」についてゲンドウが大きく関わっていたというのはアタリといっていいのかなぁ、もはやどうでもいいですね、これ。あとは「果たして生きることを望む人々の物語は何処へ続くのか」についてのもう一回あるでしょっていうのは、次回作タイトルにでてる。

外れた予想がとにかく多い。

マギに至ってはまったくでてこないし、次回に登場することも期待できない！

外れていた予想

まったくもって、式波アスカ・ラングレーのピンチなし。

世界観で外れた予想がかなり多い。

使徒に関係する予想はもう世界観が壊してしまったので全部ハズレ。

本部のバックアップとして松代があるはずなのにまったくもって登場しないのは納得がいかない。説明があってよい。

とにかく外した予想でショックだったのは量産型らしき話がひとつもなかったことですかね。よく考えると破の終盤の時点で量産型がQでは不要というフラグたってた、とも解釈できるので不覚。しかし、ダミープラグのシステムが基盤となって動いているということで、この伏線も回収したことになるのかな。

疑問とか不満

とりあえず、大きな疑問としては私立第三新東京中学校は特別な存在であったはずなので、あそこらの連中ふくめて今回の作品のとばっちりくらってたらウケる。サザエさんと同じ次元で笑える。

加持リョウジがまったくもって無視されているのも酷い話であった。死んだのはわかるよ。でもさ～、墓参りしてあげるシーンとかあったもよかったんじゃないの・・・入れようと思えば入れられたでしょ・・・

あとは金のはなし。NERVのときはきちんとゼーレがパトロンしてましたっていう筋書きでやってるのに、新しい組織について金の出処をまったく解説していないし、作品として不均一な形と感じざるを得ない。

ただ、ひとつだけ次回作について言えること

しっかし、次回の話でマギでてきたらやだな～。

俺だったら死んでも保守したくないレガシーシステムだよ。

「ヱヴァンゲリヲン新劇場版:Q」を予想する

2012-11-17T09:24:00.001+09:00

新世紀エヴァンゲリオン新劇場版: Q をみるにあたって

先週に序と破をみるなどしたり、電子版のパンフレットを読みふけり、ダラダラと周囲のファンと語りあったりした。
予習したわけですな。
せっかく予習したことだし、ここはオタクらしく劇場に足を運ぶ前に内容の予想でもしてみようかなって思ったので、いまこれを書いてます。

予想

式波アスカ・ラングレーは凹る可能性が高そう

これ、超適当な予想っていうか、いままでの劇場版とかの傾向からの予想なんですが。最近、アスカの扱いかなりよくなりすぎなんじゃね。というわけで、そろそろバランスをとるためになんかありそう。

とくに予告などでの扱いはアスカ中心の展開が多く、アスカ活躍するんだなーって期待するわけですけど、そののまま順当に活躍してはい！おしまい、では面白くないっていうか、ギャップがないわけですよ。

なのでアスカはなんか噛まれる可能性が高そうな気がする。

昔からのファンからすると「最後の最後はまた綾波かよ」ってなると思うんだが・・・あそこまでアスカびいきな予告とか作られるとねぇ・・・ちょっとアスカが心配ですよ。

予告から考察する

せっかくありがたいミサトさんのお言葉があるので、これに触れないわけにはいかないよなぁ。

レイとシンジを取り込んだまま凍結されるエヴァ初号機
廃棄される要塞都市
幽閉されるネルフ関係者
ドグマへと投下されるエヴァ6号機
胎動するエヴァ8号機とそのパイロット
ついに集う､運命を仕組まれた子供達
果たして生きることを望む人々の物語は何処へ続くのか
次回ヱヴァンゲリヲン新劇場版Ｑ
Quickening
さぁ～て､この次もサービス､
サービスゥ！

レイとシンジを取り込んだまま凍結されるエヴァ初号機

一行目はそのままの意味だろ。たぶん、アニメでは零号機が侵食型の使徒におついめられたときに解除されているアレのはず。なんか条件があるとしたら、アニメではS2機関の捕食が凍結の条件でレイを救うことが解除の条件であったように思える。
新劇場版ではレイを捕食した使徒を取り込むことで融合してしまっているが、間違いなくS2機関をふくめて捕食されているのだと感じられる。凍結の条件については破の終盤にあるシーンであり、Qの序盤での予告と捉えると事象としては自然ですね。
凍結解除の条件については難しいな。何しろ、アニメではレイを助けるために凍結が解除されているようなシナリオになっているが、そのレイを劇場版ではS2機関とともに捕食ずみとなってる。
そうなると、別にレイの救出が凍結の解除の条件ではなかったんではないか、って筋になりますよね。あのシーンで初号機の凍結が解除されてレイとは別に副次的に守られるもの、それについて考えればわかりそうなもんだが・・・なんかありましたっけ。自然に考えると侵食型の使徒について、侵食を食い止めたことで使徒の進化、ありかたを停止させたことが凍結の解除の条件になるのだろうか。だとすると、劇場版で精神を侵食するタイプの使徒が現れ、人とのコミュニケーションを望むような事態とその状況での凍結解除が予想できる。
なんか一行目について軽く書くつもりがだらだらと長くなった。まとめよう。

レイとシンジは関係なく、S2機関を取り込んだので凍結された
凍結解除の条件はレイとは関係ない
心に入り込もうとする使徒が現れたときに初号機が動く

こんなところかな。

廃棄される要塞都市・幽閉されるネルフ関係者

まあ、適当な分け方なんだけど、このふたつの予告はひとつの扱いでいいんではないかと思っている。

アニメではそろそろヒト対ヒトの対決がされる時期なので、幽閉する組織などが動いてもいい頃合いなのでは、というような予想しかできない。

廃棄される要塞都市は第３新東京市の廃棄ってことだと思うんだけれど、これがイマイチよくわからんのよね。劇場版だと松代の方って使ってないからそっち使うようになるのかなぁ。あれ、松代の方を使うようになった理由ってなんだっけ。マヤがなんだか使いにくい、みたいなことを言ってたことしか思い出せないな・・・

考えてはみたものの、よくよく考えるとネルフ関係者が幽閉されるんしょ？ってことは松城は今回は出番なしかもな。要塞都市の廃棄についてはゲンドウがいろいろと条件を握っていそうではある。本部やセントラル・ドグマ、サード・インパクトについて詳しく、実権があるのがゲンドウくらいなもんだからなぁ。

ドグマへと投下されるエヴァ6号機

素直に考えるとアニメの2号機に相当するヤツですね。

カヲルくんと一緒に降りていくんではないですかね。そのとき、アニメでは初号機がいたわけだけど、今回は凍結とある。

ここらへん、どうなるのかちょっと興味深い。もしかしたら、弐号機と衝突することになるのかな、くらいに考えてる。

しかし、マミっちゃうシーンはシンジがやるはずなんだよな。そう考えると、この時期には初号機の凍結が解除されていて、再び衝突、という流れにも期待できる。

なんにせよ、投下と、その空中戦がみれそう。

胎動するエヴァ8号機とそのパイロット

これはほぼ真希波・マリ・イラストリアスの8号機ってことなんだとは思うんだよな。その理由については次で。

ただ、胎動するという表現が気になってしょうがない。「胎動」・・・新しいパイロットの登場を予感させるが、そうなると三人目のレイだろうか。しかし、公にレイは量産できまーすってなっちゃう展開になるのでそれはないような気がするんだよなぁ。

ついに集う､運命を仕組まれた子供達

これ。アニメではトウジがパイロットになっているけれど、新劇場版ではパイロットになっていない。

かわりに、といって問題ないのかわからないが「真希波・マリ・イラストリアス」がエヴァンゲリオンに搭乗してる。

あとは、まぁ、カヲルくんいらっしゃい、くらいの意味しかとれないな。

果たして生きることを望む人々の物語は何処へ続くのか

新劇場版が二週目だとしたら、三週目。ちょっと入るんじゃないかな。

アニメとの対応から予想

なにしろ出ている情報が上の予告くらいのもので、あとはアニメのストーリーで必要となった条件などが異なるタイミングで満足されているというくらいのもの。これをみていくしかない。

量産型の登場

量産型エヴァンゲリオンはかなりのインパクトがあったものの、いまだ劇場版では未登場である。そういうわけで、こいつらそろそろでてくるんじゃないの、っていう気がしている。

破できちんとダミープラグのシステムも完成されつつあることを示している。

しっかし、やっかいなことに登場するとしたら目的がわからない。アニメのほうでは弐号機と衝突したわけだが、このイベントは新劇場版では参号機の起動実験のときに満足されていると認識してる。

だとすると、8号機との衝突になるのだろうか。わからない。

マギの活躍、あるいはピンチ

新劇場版、いままでマギがぜんぜん登場してない！のでくるのではなかろうか。

オゾンで弱まるような侵食型の使徒に襲われたっていうエピソードも飛ばしたのかなんなのかわからん。物語的にはコアのシステムで、マギを死守するストーリーなんだから、十分に登場さてもよいピースだと思うんだが、まったくそのシーンがない。っていうか、ちょっとくらいリツコさん活躍させてもいいんじゃないの。

まとめ

登場してない重要物が多すぎてどうなるのかわからん。

ロンギヌスの槍もいまんところ無視して進んでるし、アダムが登場してカジがちょっとヒヤッとなるようなエピソードはぜんぶすっ飛ばしてる。

とにかく伏線がありすぎるのだが、新劇場版ではケロっとなかったことになるのか、そこらへんキチッと辻褄をあわせてくるのかは気になりますね。

ぼくはもう、これは伏線はりすぎで崩壊パターンだと思ってますね。監督がやりたい放題やっておしまい。ファンはいろいろと考察する、その繰り返しでおしまいなんではないでしょうかね。

いまだからこそ、もう一度みよう。「ぼくらの七日間戦争」を。

2012-09-17T00:08:00.001+09:00

もう一度みた「ぼくらの七日間戦争」

たまたま動画配信コンテンツの一覧から「ぼくらの七日間戦争」というタイトルをみかける機会があり、そのまましばらくそのタイトルをみて考えにふけった。

ぼくは「ぼくらの七日間戦争」については映画での上映が終わり、地上波で放送した機会にみたことをよく覚えている。しかし、当時は芸能などにまったく興味がなく、帰宅すれば外で遊び、外での遊びから帰宅すればゲームに夢中という小学生だったことを覚えている。

ぼくが小学生だったころについての話をすると、とにかく芸能にうとく、小学生ということもあってか、女性というものにまったく魅力を感じていなかった。むしろ、周囲が女性という存在、あるいはその恋愛の話について盛り上がっているのを冷静に傍観してしまっていた。そのためか、芸能関係についてもあまり興味はなく、よく困った質問が「タレントで例えると誰が好み？」という質問だったことが鮮明に思い出される。

要するにまったく芸能については聞かれても困るというレベルで「ぼくらの七日間戦争」のような、当時の話題のキャストによる映画が地上波で放送され、タダで鑑賞できると言われても、姉につきあわされて断片的にみた記憶しかない。

生まれつきストーリーを記憶する能力が弱く、何かを読んでもすぐ忘れていたというのもあるし、自分に対してインパクトがある事象についての記憶は強いのだが、他人のことについては興味が薄かったのである。「ぼくらの七日間戦争」についても例外ではない。鑑賞した記憶は鮮明にあるが、すべてを通して鑑賞した記憶はない。すぐに飽きてしまい、当時の自身が関心のあることに取り組むために自室に籠もったのではないかと思う。「名作と言われており、普通は喜んでみる作品なんだろうが飽きた」という自身へのインパクトが主となり、鑑賞した記憶は鮮明だが内容はさっぱりわからないという事態になっているのだろう、と今となっては振り返ることができる。

閑話休題。映画の話をしよう。調べてみたところ映画での放映は1988年であり、当時のぼくは小学生だったらしい。地上波で放送されるころの時期には中学生になっていたかもしれない。

繰り返す歴史

なぜ「いま」「もう一度みよう」なのかについて説明したい。それは繰り返す歴史を痛感することができるからである。この物語では社会の矛盾として中学校を舞台にしているが、その取り巻きの発言が恐ろしいほどに日本社会における教育についての議論の方法論に変化がないことを裏付けていると言ってよい。
戦争の早期、つまり籠城の時期に、生徒の保護者は突然の息子や娘の行方不明に不安になる。そして、学校に押し寄せている。ここでの保護者と学校側がやりとりするシーンがまさに「日本社会における教育についての議論の無変化」そのものである。
保護者は「学校側の教育に何か問題があり、このようなことが起こったに違いない。」という旨を主張し、教員側は「学校での教育は完全なものであり、保護者が家庭でのしつけを怠っている」と主張する。これは果たして「当時」と「現在」で何か相違するものがあるのだろうか。
前段で「現在」と「当時」において類似性をみてとったわけだが、考察を少し深めると、「当時」と「当時からの過去」についての類似性をみてとることもできる。
映画での放映時期の後、自分が通った中学校では、受験を意識した教育というものはなされており、劇中にあったような重い体罰などは観測されなかったものの、体罰はやはりあった。「そういう時代だった」 −−− その一言で済まされる問題であるのか、そうでないのかという議論はここではしないが、明確な事実として軽い体罰はあったし、受験を意識した教育、あるいはいじめ社会（首謀者がコミュニティ形成するため、ぼくには観測できても止める勇気はなかった）に鬱屈としたものをもっていたような生徒も散見された。表現に誇張はあったものの、それぞれが抱える心情や時代背景におけるシチュエーションとしてそれほど矛盾は感じられない。
それをふまえて考えてみるとスタッフの年齢層からして学生運動を当時の価値観で「現代化」した作品だと思えてくる。実際、終盤ではまさにそのような闘争めいたものを感じさせるシーンが登場している。これが「当時」と「当時からの過去」についての類似性である。
学べることは、人というものはたいして本質が変わらないということだろうか。とにかくこれに尽きる。鑑賞する機会のある方は再帰的に繰り返されるとも思われる歴史の輪廻を体感してほしい。そして、また忘れたころに再会してみたいと思わずにはいられない作品となった。

雑感

レビューらしいものはここまでであり、以下は雑感となる。

宮沢りえ

ぼくはポニーテールが好きです。大好きです。そして、主演はポニーテール姿の宮沢りえです。ちょうどこの長さが実にいいんです。女性の方で「あの」ポニーテールと同じ長さの方にお会いする機会もちょくちょくあるんですが「外見は女性らしさを気にとめつつも、自身の中に太い芯が通っていて話していて心地よい。しかも、面倒見が良い。」というポニーテールの長さなんです！

「現在」の宮沢りえはぼくからすれば、姉という年齢でとても気軽に叱ってくれそうな年齢差のはずが「当時」の宮沢りえはポニーテールの中学生で、上記の性格だといいなぁということを想像してしまい、えも言われぬ幸福感に満たされますね。さらには学級委員という設定がよい。ぼくもこの立場にはよく立ったものなので、各シーンでの感情面におけるシンクロ率がおそろしく高い。全体的に宮沢りえが演じる「中山さん」に神経を移入してしまった。

ついでなので、~~気持ち悪い話~~生徒の当時の髪型や服装についてをここにまとめておく。劇中では当時の宮沢りえの体操服姿をみることができ、下は当然旧式のブルマーであり、もはや完全武装である。これで夏を舞台にしていることにつけ込み、水着のシーンでもあればマニアはさらに垂涎したことだろう。他、時代的にポニーテールが流行っている時期であり、モブキャラでも強気ポニーテールというど真ん中ストライクな出演がみられるので、ポニーテールファンはそこらへんについても注目して鑑賞してされたい。

スカート丈

劇中のシーンでは校則の厳しさを表現するために、定規でスカート丈を測っているシーンがある。このシーンがまた時代を感じさせる。当然のことのように下から30cm ± 2cmという基準で規則を設けており、当時の価値観として品行方正がよろしくない女生徒においてはスカート丈を「長くする」のが普通であったということを懐かしめた。

参考としてはスケバン刑事の斉藤由貴などの服装を参考にされるとよい。

青葉区

作者によればモデルとなったのは宮城県仙台市青葉区らしいが、実際には生徒と警察が闘争するシーンで千葉県警のパトカーらしきものが到着している。これは制作の都合、撮影のロケーションが千葉県だったのだろうな、と感じた。

不明な処罰

散々あれだけのことをして、戦争といってもおかしくない事態になっています。劇中では最後に大勝利のジャンプをして終了ですが、彼ら、彼女らはあのあとどのような罰を与えられ、どれほどの苦しみをともなったのでしょうか。想像すると少し残酷ささえも感じてしまいます。あまり考えないことにしましょう。

Huluで鑑賞しました

Hulu というサービスが Apple TV をサポートしはじめてます。
Huluというのは海外で成功している動画配信サービスで、Huluで配信されているコンテンツならば、月極の固定料金で好きな時間に閲覧できるというサービスです。
Apple TV がいよいよ便利になってきたので過去の名作をたまにみようと思っていますが、ここまでのレビューを書くことはないと思います。なにしろ、今回の鑑賞は相当な感動でしたから。

Factor 0.95がリリース、@keitahaga も個人のコミッターとして掲載されています。

2012-08-21T09:34:00.003+09:00

Factor 0.95 now available

32nd Blogger

とある Rubyist の「次の20年」

第一の人生

第二の人生

第三の人生

今年の Ruby

あいさつ

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

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

概要

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

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

GitHub.com での主張がデカい

Ruby 3.0.0 についての所感

最後に

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

この記事は

Haskell との邂逅

当時の Haskell 事情

Chapter 12: An automatic calculator

所感

輪読の様子

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

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

おすすめのプレイ

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

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

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

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

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

所感

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

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

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

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

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

転職

来年

あれ？

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

BlockClosure をみてみる

BlockClosure に引数を与えてみる

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

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

cull も万能ではないです

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

おわりに

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

普通の使い方

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

偶数と奇数を判別する

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

所感

2015年に参加する Advent Calendar

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

WEDNESDAY, JULY 16, 2014

WEDNESDAY, OCTOBER 8, 2014

@keitahaga 先生が iOS 7 にも貢献

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

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

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

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

所感

「OpenFlow 実践入門」を読んで Trema で面白いスイッチを作ろう

OpenFlowとは

OpenFlow実践入門

Rubyで記述することができる

解説が分かりやすい！

上級者にも対応！

まとめ

「ヱヴァンゲリヲン新劇場版:Q」を鑑賞した

世界観について一言だけ

当たっていた予想

外れていた予想

疑問とか不満

ただ、ひとつだけ次回作について言えること

「ヱヴァンゲリヲン新劇場版:Q」を予想する

新世紀エヴァンゲリオン新劇場版: Q をみるにあたって

予想

式波アスカ・ラングレーは凹る可能性が高そう

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