- 白米(茶碗1.5杯分)
- 納豆2パック
- インスタント味噌汁
- カレイの開き
- 冷奴
カレイの開きはハナマサで買ったやつなのですが、予想以上に美味しゅうごいました。
Togetterに全部まとめたけど、備忘録としてこっちにも貼っておく。
コマンド2回叩くだけでリリースできてとても便利なので、Sonatype OSSRHで自作Scalaライブラリをリリースしている人は、使うといいと思うよ!
ちなみに、Sonatype OSSRHに自分のアカウントを作る方法は、pab-techさんのブログ記事、自分が作ったScalaライブラリをMaven Centralリポジトリに登録する方法 (GaedsをSonatype OSSRHにデプロイしたよ\(^o^)/)が参考になるかと。1年以上前の記事だけど同じような手続きでいけるはず。
Vol. 2の時に記事を寄稿した関係もあり、事前にPDF版をいただいていました。ようやく一通り目を通したので、簡単な紹介をしたいと思います。なお、注文はこちらから。
魔導書Vol.3の副題は「“Parallel, Concurrent, and Distributed Programming”並行世界の魔物に人類はどう立ち向かうのか。」です。
目次は以下のようになっています。各記事は、最初の2ページ程度試し読みが可能ですので、興味をもった方はそちらを読んでみるのも良いかと思います。
今回のテーマは並列・並行・分散プログラミングです。並行プログラミングの世界には、直列プログラミングとは異なる原理的な難しさが存在します。直列プログラムとは異なるレベルの「プログラムの正しさ」の定義すら必要になります。本書はそのようなテーマを正面から取り扱っていますから、決して「お手軽」でも「簡単」でもありません。
一方で、並行プログラミングはとても「面白い」世界です。並行プログラミングは私たちプログラマにとってとても身近な話でありますが、同時にとても不可思議な世界でもあります。そのような世界の一端を除いてみたい知的好奇心旺盛な方に是非読んでもらいたいです。
また、並行プログラミングでは、直列プログラミングでは起き得ない様々なトラブルが容易に発生します。そこで重要なのは単なる対処療法だけでなく(それももちろん必要ですが)、原理を知ることです。本書はそのような原理を知りたい方にとって特に助けになる一冊だと信じています。
また、Erlang, Scala, ML,Haskell等における並行・並列プログラミングモデルが紹介されていますので、既に並行・並列プログラミングに関して基礎的な知識をお持ちの方にとっても有用な一冊です。
私が特におもしろかったいくつかの記事をピックアップして簡単に紹介します*1。
まず、真っ先に挙げたいのが熊崎さん(@kumagiさん)の『Lock-free 入門』です。いわゆる「Lock-free」アルゴリズムの入門記事ですが、必要となる前提知識をきっちり説明しています。他の記事を読む助けにもなるので、並行プログラミングの用語に馴染みのない方はまずこの記事を読むことをお勧めします。並行・並列の違いや、並行プログラミングにおける正確性や安全性について丁寧に説明してあり、私自身も自分の理解を再確認するのに役に立ちました。日本語の通常の技術書籍で、並行プログラミングの用語についてきっちり解説しているものは少ないので、それだけでも貴重です。やや難解に感じるかもしれませんが、その場合は一度飛ばして必要に応じて読み返しましょう。
肝心のLock-freeについてですが、Lock-freeなStackのC言語の実装を通して説明していく形式になっています。ナイーブな実装から開始して、その問題点の指摘→改善を繰り返す形になっており、非常にわかりやすく丁寧な説明です。最後には、ベンチマークによる性能の測定もあります。
次に挙げたいのが幾太さん(@cooldaemonさん)の『ErlangとScalaにおけるアクターモデルの紹介』です。タイトルの通り、ErlangとScalaのアクターモデルと実装について、その差異を交えながら紹介しています。id:xuweiさんの記事でも触れられていますが、この記事の著者である@cooldaemonさんはScalaとErlangのアクターモデルに詳しい方です。Scalaのアクターモデルに関しては私も多少理解しているつもりですが、Erlangについては、個々のアクターがメモリ空間を共有していない事、それによってスケジューリングの方式が異なる(であろう)ことを除いてあまり知らなかったため、Scalaのアクターとの差異は勉強になりました。
なお、この記事で説明されているScalaのアクターモデルは、Scala 2.9まで標準ライブラリに含まれていたscala.actors
パッケージ以下のものである事に注意してください。Scala 2.10では、scala.actors
は標準ライブラリから分離され*2、Akkaが実質的なScala標準のアクターライブラリになっています。Akkaも基本的な原理はscala.actors
と似ていますが、Akkaはより直接的にErlangのアクターモデルを参考にしているため、細部は異なっています。
石井さん(@mr_konnさん)の『Real World STM ~作って学ぶSTM~』も楽しかったです。Software Transactional Memory(STM)という単語には聞き覚えのある方は少なくないでしょう。この記事は、STMを用いたプログラムを実際に作っていきながら学ぼうというものです。実装言語はHaskellですが、Haskellについてあまり知らなくても十分読むことはできる…かはちょっと自信がありません。少なくとも、公開されているサンプルコードをいじるには、Haskellのコード(実用的でなくてもよい)を書いた経験が多少必要かなというのが正直な感想です。しかし、前提知識さえあれば読み通すことはさほど難しくありません。
以上、『プログラミングの魔導書 〜Programmers' Grimoire〜 Vol.3』について簡単に紹介してみました。私の紹介や書籍ページの試し読みで興味を持った方は是非買いましょう!
イベントの宣伝です。
今年の春、カンファレンスカンファレンスというイベントが開催されました。これは、「カンファレンス運営に興味がある人のためのカンファレンス」ということで、各種カンファレンス運営者側が発表者となって、例年どのようにカンファレンスを運営しているかを発表・議論したものでした。
さて、今回のカンファレンスカンファレンス大反省会ですが、カンファレンスカンファレンスよりもう一歩踏み込んだ形の話になります。特に、各種カンファレンスの主催者が、今年のイベントを振り返って(会場確保、スタッフ間のコミュニケーションの方法、等)具体的にどのような運営を行ったかについてノウハウを共有し合います。
今年開催されたカンファレンスについて生の情報が聞ける貴重な機会なので、カンファレンス運営に興味のある方は参加を検討してはいかがでしょうか。私も、今回のイベントの発表者側ということで、Scala Conference in Japan 2013の運営について、座長としての立場から色々喋ります。
なお、イベントの詳細および参加申し込みについては
カンファレンスカンファレンス 2013 大反省会 - connpass
からお願いします。参加費(ビアバッシュ代)として1500円を前払いする必要があるのでご注意ください(詳しくは上記ページをご覧ください)。
少し前に、茂木健一郎に騙されて通信制高校からAO入試受けた結果wwww
というまとめが盛り上がっていました。人格批判が混じった酷いコメントや、AO入試のことを想像だけで語っているコメント*1があまりにも多くて辟易しました。辟易したので、実績が無くても合格できた私の昔話を書いてみることにします(その時点での基礎学力はあったからカウンターとして弱いのは残念です)。
まず、自分の経歴から。2002年度の筑波大学の情報学類AC入試*2合格者で、その後筑波大学大学院への進学を経て、現在は渋谷のスタートアップ企業に居ます。
筑波大学のAC入試を知ったのは、高等学校3年の秋でした。一応、中高一貫の進学校*3に通っており、学力も平均よりは上くらいでした。ですが、それまでに実績といえるものはありませんでした。コンクールで入賞した事もプログラミングコンテストで上位に入ったことも、所属していた生物部*4で主導的な立場にあったこともありません。
当時の私は歴史学に情熱を持っており、将来は歴史研究者になるという夢を持っていました。2年の時の文系・理系コース分けがあったときは、当然のように文系コースを選びました。
しかし、3年になってから、理系のクラスに転向したくなってきました。色々な理由はありますが、JavaHouse-Brewersという当時最大級のJavaメーリングリストでの殺伐とした議論を読みあさった結果、プログラミング言語というのは与えられるだけでなく、自分で仕様を考えたり作ったりできるのだ、という事を理解して感激した事が最大の理由でした。それから自分でプログラミング言語を作りたいと思うまでにさほど時間はかかりませんでした。
問題は、私が既に文系コースを選んでしまっていることでした。文系でも理系でもプログラミングの勉強はできますが、自分のプログラミング言語を作るために必要な知識を仕入れるなら情報系学部に行きたい。理系へのコース変更は可能でしたが、理系カリキュラムに途中から入るというデメリットを背負う必要がありました。
そのように悩んでいたタイミングで、弟から筑波大学にAC入試という制度があることを教えてもらいました。最初は消極的でしたが、これで受かれば情報系学部に行けるという魅力に抗えず、その数週間後にはAC入試を受験することを決心しました。筑波大学は国立大学で、そこそこ以上ではあったことと、AC入試に落ちても通常の試験は受けられることから、親からは簡単に許可をもらえました。
問題になったのは実績の無さ…以前に時間の無さでした。AC入試受験を決心したのは金曜日で、その翌週の水曜日が自己推薦書を含む各種書類の提出締め切り(必着)でした。提出書類の一部には担任からの推薦(形式的なもの)が必要でした。その日の内に職員室にダッシュしたところ、幸運な事に担任の先生が居たため、必要な書類がなくてゲームオーバーという事態は避けられました*5。
金曜の夜からは時間との戦いでした。募集要項にある、「問題解決能力を重視する」という言葉を信じて、生物部での活動やちょっとしたJavaプログラム、文化祭で使用したクイズプログラムといった事を元にして、どのような知見が得られたか、どのような点が失敗だったか、筑波大学に入って何をやりたいかを必死で書きました(たとえば、ぷよぷよもどきのプログラムを作ることで初めて再帰の意義が理解できたことなど)。また、プログラミング言語作成における初歩の初歩である四則演算のパーズ・評価を行うプログラムをなんとか作って、それに対する自己評価も書き込みました。
月曜の朝には書類は完成し、自分がこれまで作ったプログラムをCD-Rに焼いたものを揃えて提出することができました。この時点では、あくまで最低要件が揃ったに過ぎず、「運が良ければ合格できるかもしれないな…」くらいに考えていました。ところがどっこい、書類選考(一次選考)を通過した旨と面接日程の通知が1週間後くらいに来ることになりました。何故通ったのかは不思議でしたが、これはチャンスということで面接の前日・当日は学校を休んで京都←→筑波大学を往復しました。
いよいよ面接当日。緊張しながら、面接2時間前には待合室に来ていました。自分の先に面接を受ける二人が待合室に居ました。この二人とは合格後も長い付き合いになるのですが、それはまた別の話。三人で雑談することで多少は気持ちが落ち着きましたが、とにかく面接の内容が全く想像が付かないので対策も何も考えていませんでした。
面接本番、始まってみるととても和やかな雰囲気。書類についての説明を求められた後は、単なる世間話のような雰囲気になっていました。この時点で合否が確定していたのかわかりませんが、その後は、プログラミング言語を作る夢の直接の動機になったfj.comp.oopsやJavaHouse-Brewersでの議論について夢中で語っていただけでした(今思うとドン引きです)。
そしてそれからさらに1週間後か2週間後、面接当日に会った内の一人がつくば在住だったので、受験番号を教えて合否を確認してもらったところ、合格していたのでした。評価されるべき実績など無かったのですが、それで合格できた理由を考えると
辺りなのかなあと思います。ともかく、華々しい実績が無くても合格できることはできるのです*6 。自分一人だけだと偶然性が高いですが、情報系ACで入学前に目立った実績を持たない人は、多数居ました*7
以下は、AO/AC入試についての簡単な比較です。昔話ではないですが、一口にAOとか言っても色々あるんだなということがわかってもらえればと思います。
AO入試というと、とかく華々しい実績が必要という認識が先行しがちです。しかし、実際には大学によって同じAO入試という名前でも求める学生は異なります。その事は、北海道大学と筑波大学の二つを比べてみただけで明らかです。
北海道大学では「AO入試では、学力を含めた多様な個性・能力・資質・適性・目的意識や意欲を、提出書類や課題論文また面接等によって総合的に評価します。一芸一能入試ではありませんので、基礎学力のあることが条件です。」と書かれており、一般のAO入試のイメージと異なるタイプの学生を求めているようです。特に課題論文があるというのは、AO入試のイメージとは異なるのではないでしょうか。
筑波大学のAC入試に関しては、一般的なイメージに近いような事が書かれています。学力に関しても合格者には、結果的に成績がよい人が多くなっていますが、出願要件ではありません。主として、入学後、志望する学群・学類のカリキュラムに支障なく適応できるかどうかを確認するための参考として使われます。と書かれているくらいです。その他の質問に対する答えを見てもわかりますが、北海道大学のAO入試と比較すると、学力以外の比重が高く、特別な実績を必要としてない事がわかります。そして何より、ここに書かれていることは、私自身と周囲を見た結果からもそれほど外れていないと言えます。
その他の大学のAO入試についても調査してみたいところですが、長くなり過ぎるのでとりあえずここまでにします。
*1:コンクール出場などの実績が無くては合格できない等
*2:AC入試とはアドミッションセンター入試の略称で、名前こそ違いますが、AO入試の一種と呼んで差し支えありません。筑波大学では、特色を出すためか、学「群」や学「類」といった他大学と違った用語が多用されます
*4:ちなみに、自分でテーマを立てて研究する方法の初歩は生物部で学んだのではないかと今になると思います
*5:金曜の夕方に担任の先生が居なければ自分の運命は変わっていたでしょう
*6:入学後についてはまた別の話ですが、総合的にみると情報系ACな人はそれなりの実績出してる人は少なくありません
*7:2003年度の登さんや吉田さん、2006年の古橋さんをはじめ、受験前の時点で実績を持っている人が大量に来る年もありました。
conpass.com、partake.in、atnd.orgといったサービスで、特に無償の勉強会のページを作って参加者を募ったとします。すると、一定以上の規模のイベントでは少なくない割合で、当日になってからキャンセルの連絡(だいたいボタン一発でできるようになっている)もせずに不参加な人が出ます。これは、数年前にも議論されてて、「勉強会 ドタキャン」でぐぐると色々な議論が出て来ます。
ここでは、一応それなりの数の勉強会を主催した事のある立場(あるいは運営側)としてこの問題に対してどう対処すべきか、改めて考えてみようと思います。結論を先に述べると、このようなサービスを利用したときに一定割合のキャンセルが出るのを前提とした上でその場合に余計な手間がかからないような方法を取るべき、というのが私の主張です。
確かに、最低限の連絡なしのドタキャンは懇親会の予約変更を初めとした主催者の負担になりますし、主催者が感情的にやりきれない気分になることがあるかと思います。
ただ、マナーに問題があるといった批判が多くあったにも関わらず、これまでそれらのサービスを使って開催された数々の勉強会において、一定割合の無断キャンセルがどうしようもなく発生しているのも確かです。ですから、現状では一定割合の無断キャンセルが出ることを前提に勉強会の計画を立てるのが無難だと考えます(システム的には無断キャンセル回数などをブラックリスト方式で共有できると良いですが、現状ではそういった機能のあるサービスはおそらくないので)。
感情の問題は、本人的にどうにもならない部分はありますが、経験上、そういう現象だとあらかじめ考えておけばがっかりしなくて済みます。後できっちりと批判を行うことで、改めて問題提起になるということもあるでしょうから、黙っているべきというわけではありません。心構えとしてはそれくらいの方が良いという話です。
会場規模と募集人数は一概に言えませんが、一定割合(2〜3割くらいは普通、悪ければ5割近くになることもあります)の無断キャンセルが発生するため、基本的に、募集人数>応募人数(補欠枠を除く)>>>参加人数になります。募集の仕方もそれを前提にして考えるのが良いでしょう。ここで重要になるのが補欠枠の存在(不存在)です。多くのシステムで補欠枠の人はキャンセルが出た場合に繰り上がりますが、当日(あるいは前日)急に繰り上がってしまっても、既に当日の予定を入れているので行けない、という場合は少なくありません。
募集枠は会場のキャパシティより多少少なめにとっておいて、補欠枠の人数に応じて余裕を持って拡張できるようにしておくのが良い、というのが自分の考えです。当日予想より大幅に参加者が少ないといった事を防げますし、補欠枠の方にとっても、急に補欠枠から繰り上がったけど参加できないということを防げます。また、そもそも補欠枠を考えずに、募集人数(真のキャパシティより少なめ)+ N人に達した時点で、枠を拡張して募集を打ち切るということも考えられます。また、ドタキャンの問題を置いといても、キャパシティぎりぎりだと参加者にとっても窮屈ですから、最初の募集枠は会場のキャパシティより少なめにとっておく事は良いことです。
会場費を参加者で割り勘する場合は、事前に必要な料金を徴収可能なサービスを利用するのが良いでしょう。これは不特定多数が参加することを想定した場合の話で、比較的信頼できる少数の人数だけでやるのは野暮かもしれません。
特にドタキャンによる手間増と金銭的な損失が発生しやすい懇親会については、次のような対応が考えられます。
あくまで自分の浅い経験に基づいた考えですかが、叩き台として参考になればと思います。
こんなことを書いておいてなんですが、自分はといえば、会場は無償で必要な設備を貸してくださる方に頼んで(無償で会場を貸してくださるのはほんと助かります)、懇親会は会場でやる形にするか、飲み屋でやる場合はその場の流れに任せるといういいかげんな運営な事が多かった気がします(特に初期の頃)。こういうやり方は、参加者の方や会場提供者の方に一部負担をかけてしまう場合もあるので、あまり真似しない方が良いです。
データベース実践講義 ―エンジニアのためのリレーショナル理論 (THEORY/IN/PRACTICE)
実はまだ完読してないのだけど、結構刺激的で面白い本なのでブログ再開ついでに紹介してみよう。
まず断っておく必要があるのは、この本は、SQLや特定ベンダのRDBMSの取り扱い方のノウハウ本ではないということ。その意味でこの本を読むことで即座に実践に何かを活用できるかは不明である。彼は関係モデルの祖であるCoddと共同作業をしていた時期があったこともあってか、この本では本来RDBの基礎であるべき(と彼が主張する)リレーショナルモデルをきっちり理解しなければならないという主張で一貫しており、この本のかなりの部分が関係モデルの説明とそれを理解することがいかに実践で役に立つかの説明に費やされている。ある意味、関係モデルの教科書的な本でもあるのだが、彼は随所で非常に強い主張をしているので、それが本書の面白さにつながっている。
たとえば、彼は現在の多くのRDBMS、特にそれらを操作するための言語である(標準)SQLにとても批判的で、テーブル、行、列といったSQLで一般的な用語と関係、タプル、属性というリレーショナルモデルの用語の違いを理解すべきであると口を酸っぱくして説明している(やや誇張気味)。
書籍の中では説明のために必要に応じて(標準)SQLが使われているのだが、その事を断るときですら、いちいちSQLが単純な概念をわざわざ複雑化していることに文句を言いまくる始末。こういう、その分野の専門家による自己主張の強い書籍は読み物としてとても楽しい。
無論、SQLに単に文句つけてるだけではなく、リレーショナルモデルの原理を含めて学ぶところはたくさんあるのだけど、その原理を学ぶことこそが実践につながるのだという彼の主張はとても力強い。本当に実践的なのかどうかについては判断しかねる部分があるけど。
個人的な感想では、既存の製品や言語への強力な批判や実践においてこそ原理を重視する姿勢などは、Bertrand MeyerのOOSE/2ndにおける語りによく似ているように感じた。Meyer程激しくはないけど。
完読していないので固有の論点に関する感想は後日気が向いたら書くが、一つ注意点をば。この本は形式的な事柄を扱う論文ほど厳密ではないが、出てくる用語については概ね最初に定義をしてから話を詳細化していくので、そういう話の進め方に慣れていないとやや読みにくく感じるかもしれない。