kmizuの日記

プログラミングや形式言語に関係のあることを書いたり書かなかったり。

勉強会ドタキャン問題について運営側の立場で考える

conpass.compartake.inatnd.orgといったサービスで、特に無償の勉強会のページを作って参加者を募ったとします。すると、一定以上の規模のイベントでは少なくない割合で、当日になってからキャンセルの連絡(だいたいボタン一発でできるようになっている)もせずに不参加な人が出ます。これは、数年前にも議論されてて、「勉強会 ドタキャン」でぐぐると色々な議論が出て来ます。

ここでは、一応それなりの数の勉強会を主催した事のある立場(あるいは運営側)としてこの問題に対してどう対処すべきか、改めて考えてみようと思います。結論を先に述べると、このようなサービスを利用したときに一定割合のキャンセルが出るのを前提とした上でその場合に余計な手間がかからないような方法を取るべき、というのが私の主張です。

確かに、最低限の連絡なしのドタキャンは懇親会の予約変更を初めとした主催者の負担になりますし、主催者が感情的にやりきれない気分になることがあるかと思います。

ただ、マナーに問題があるといった批判が多くあったにも関わらず、これまでそれらのサービスを使って開催された数々の勉強会において、一定割合の無断キャンセルがどうしようもなく発生しているのも確かです。ですから、現状では一定割合の無断キャンセルが出ることを前提に勉強会の計画を立てるのが無難だと考えます(システム的には無断キャンセル回数などをブラックリスト方式で共有できると良いですが、現状ではそういった機能のあるサービスはおそらくないので)。

感情の問題は、本人的にどうにもならない部分はありますが、経験上、そういう現象だとあらかじめ考えておけばがっかりしなくて済みます。後できっちりと批判を行うことで、改めて問題提起になるということもあるでしょうから、黙っているべきというわけではありません。心構えとしてはそれくらいの方が良いという話です。

会場規模と募集人数は一概に言えませんが、一定割合(2〜3割くらいは普通、悪ければ5割近くになることもあります)の無断キャンセルが発生するため、基本的に、募集人数>応募人数(補欠枠を除く)>>>参加人数になります。募集の仕方もそれを前提にして考えるのが良いでしょう。ここで重要になるのが補欠枠の存在(不存在)です。多くのシステムで補欠枠の人はキャンセルが出た場合に繰り上がりますが、当日(あるいは前日)急に繰り上がってしまっても、既に当日の予定を入れているので行けない、という場合は少なくありません。

募集枠は会場のキャパシティより多少少なめにとっておいて、補欠枠の人数に応じて余裕を持って拡張できるようにしておくのが良い、というのが自分の考えです。当日予想より大幅に参加者が少ないといった事を防げますし、補欠枠の方にとっても、急に補欠枠から繰り上がったけど参加できないということを防げます。また、そもそも補欠枠を考えずに、募集人数(真のキャパシティより少なめ)+ N人に達した時点で、枠を拡張して募集を打ち切るということも考えられます。また、ドタキャンの問題を置いといても、キャパシティぎりぎりだと参加者にとっても窮屈ですから、最初の募集枠は会場のキャパシティより少なめにとっておく事は良いことです。

会場費を参加者で割り勘する場合は、事前に必要な料金を徴収可能なサービスを利用するのが良いでしょう。これは不特定多数が参加することを想定した場合の話で、比較的信頼できる少数の人数だけでやるのは野暮かもしれません。

特にドタキャンによる手間増と金銭的な損失が発生しやすい懇親会については、次のような対応が考えられます。

  • 予約済みでキャンセル料がかかる場合は、事前に必要な料金を徴収する。サービスは事前決済が可能なものを利用する
  • 人数の増減に柔軟に対応できる形にする。たとえば、会場でピザを注文するといった形にすれば、当日参加者が増減しても柔軟に対応可能(会場での飲食が可能な場合)
  • そもそも懇親会の有無を事前に決定しない。当日に先延ばしにする

あくまで自分の浅い経験に基づいた考えですかが、叩き台として参考になればと思います。

こんなことを書いておいてなんですが、自分はといえば、会場は無償で必要な設備を貸してくださる方に頼んで(無償で会場を貸してくださるのはほんと助かります)、懇親会は会場でやる形にするか、飲み屋でやる場合はその場の流れに任せるといういいかげんな運営な事が多かった気がします(特に初期の頃)。こういうやり方は、参加者の方や会場提供者の方に一部負担をかけてしまう場合もあるので、あまり真似しない方が良いです。

『C.J.Dateのデータベース実践講義 - エンジニアのためのリレーショナル理論』 雑感(途中)

実はまだ完読してないのだけど、結構刺激的で面白い本なのでブログ再開ついでに紹介してみよう。

まず断っておく必要があるのは、この本は、SQLや特定ベンダのRDBMSの取り扱い方のノウハウ本ではないということ。その意味でこの本を読むことで即座に実践に何かを活用できるかは不明である。彼は関係モデルの祖であるCoddと共同作業をしていた時期があったこともあってか、この本では本来RDBの基礎であるべき(と彼が主張する)リレーショナルモデルをきっちり理解しなければならないという主張で一貫しており、この本のかなりの部分が関係モデルの説明とそれを理解することがいかに実践で役に立つかの説明に費やされている。ある意味、関係モデルの教科書的な本でもあるのだが、彼は随所で非常に強い主張をしているので、それが本書の面白さにつながっている。

たとえば、彼は現在の多くのRDBMS、特にそれらを操作するための言語である(標準)SQLにとても批判的で、テーブル、行、列といったSQLで一般的な用語と関係、タプル、属性というリレーショナルモデルの用語の違いを理解すべきであると口を酸っぱくして説明している(やや誇張気味)。

書籍の中では説明のために必要に応じて(標準)SQLが使われているのだが、その事を断るときですら、いちいちSQLが単純な概念をわざわざ複雑化していることに文句を言いまくる始末。こういう、その分野の専門家による自己主張の強い書籍は読み物としてとても楽しい。

無論、SQLに単に文句つけてるだけではなく、リレーショナルモデルの原理を含めて学ぶところはたくさんあるのだけど、その原理を学ぶことこそが実践につながるのだという彼の主張はとても力強い。本当に実践的なのかどうかについては判断しかねる部分があるけど。

個人的な感想では、既存の製品や言語への強力な批判や実践においてこそ原理を重視する姿勢などは、Bertrand MeyerのOOSE/2ndにおける語りによく似ているように感じた。Meyer程激しくはないけど。

完読していないので固有の論点に関する感想は後日気が向いたら書くが、一つ注意点をば。この本は形式的な事柄を扱う論文ほど厳密ではないが、出てくる用語については概ね最初に定義をしてから話を詳細化していくので、そういう話の進め方に慣れていないとやや読みにくく感じるかもしれない。

Scala DaysにおけるKeynoteの歴史(或は、Rod Johnsonの"Scala in 2018"について)

注:このエントリの結論は、これまでScala Daysに参加してきた経験と、一連の騒ぎにおける対応から推測したものであり、決定的な証拠があるわけではないことをお断りしておきます

さて、皆様いかがお過ごしでしょうか。近頃、海外のScala界隈では、Scala Days 2013におけるRod JohnsonのKeynoteである"Scala in 2018"が発端となって、海外のScalaコミュニティを中心に、Twitter上での炎上が起きています。

特に、

  • Typesafeのboard(顧問?)の一人であるRod Johnson(彼はEJB批判やSpring Frameworkの作者としてJavaコミュニティではよく知られた人物です)がKeynote中で、Scalaコミュニティの主要コントリビュータの一人が開発したHTTPクライアントライブラリdispatchを例としてScala界隈における記号の濫用について批判したこと
  • 批判点はdispatch-classicに対するものであって、現在のdispatchでは既に指摘の問題点は改善されていること
  • その他の問題点についても、Scalaコミュニティでは既知のものが多く、既に改善に向けた努力および実際の成果があるにも関わらず、その点について言及しなかったこと

などがあり、「個人攻撃だ」「特定ライブラリのAPIについて語るなら、最新のAPIを調査すべきであって、昔のAPIに語るのは的外れ」「Scalaはエンタープライズ言語になるべきではない?」など様々なツイートが飛び交っています。実のところ、私も彼のKeynoteは現地で聴いているのですが、それに関する感想は既にツイッターにつぶやいたので詳しくは述べません。

このエントリでは、Scala Days 2010から全て参加してきた一人として、ちょっと俯瞰してこれまでのScala DaysにおけるKeynoteについて語ってみることにします。

Scala Days 2010

  • Martin Odersky, Scala: Where we are, where we go to. *1
  • Kunle Olukotun, A Domain Specific Language Approach to Heterogeneous Parallel Programming Using Scala

Scala Days 2011

  • Martin Odersky, State of Scala
  • Doug Lea, Supporting the Many Flavors of Parallel Programming

Scala Days 2012

  • Martin Odersky, Where is Scala going?
  • Guy Steele, What Scala and Fortress can learn from each other
  • Simon Peyton-Jones, Towards Haskell in the Cloud
  • Anthony Rose, Re-inventing the Media and Television industry

Scala Days 2013

  • Martin Odersky, Scala with Style
  • Rod Johnson, Scala in 2018

以上が、これまでのScala DaysのKeynote一覧です。発表者はそうそうたる面子です 。ただ、Martin*2の発表は基本的にKeynoteと呼ぶのにふさわしいものでしたが、彼以外のKeynoteは驚く程一貫性がありません(これは、Scala Days 2010から毎年参加していた人間としての実感です)。

Kunleの発表はScalaに関連していたものの、軸は彼の研究にありました。Doug, Guy, Simonについても同様です。Dougの発表はScalaに関係ない並列プログラミング一般の話がほとんどでしたし、Guyの発表はFortressとScalaの構文的な類似と相違という観点で興味深い発表でしたが、軸は彼が開発した言語Fortressにありました。SimonにいたってはScalaについての言及はごく一部で、内容のほとんどがHaskellに関するものでした。AnthonyはZeeboxにおけるScala採用事例を語っていたという点でやや他と異なっていましたが、Scala Daysの「Keynote」の一貫性のなさという印象をより深めるだけでした。


さて、今年のRodによるKeynoteです。彼が単にこれまでと同様、Spring作者でありJavaコミュニティの著名人物という立場で「招待講演者」という事で発表したのなら大して問題にならなかったのではないかと思います。問題は、彼の現在の立場がTypesafeのboardであることです。このため、彼によるdispatch(-classic)批判をはじめとした、やや古いScalaコミュニティ批判に対して、Typesafe社が公式的にScalaコミュニティの主要なコントリビュータに対して不適当な批判をしたと捉えている人が少なからず居るようです。

ただ、これまでのScala DaysにおけるKeynoteの歴史(あるいは一貫性のなさ)を踏まえると、「Typesafeのboard」であるRod Johnsonが、不当なScalaコミュニティ批判をしたという問題のとらえかたは正しくなくて、実は単にRod個人としての見解なのではないかと思います。だとしても、Rodが現在のポジションでKeynoteで発言したことがどう捉えられるかをちゃんと把握してなかったことになるわけで、それはそれで別の問題がありそうですが。個人的にはTypesafe Blogで公式的な見解出した方が良いんじゃないかと思う次第。TypesafeでScalaやAkka、Playの開発を行っている開発者がTwitter上でのリプライに多少なりとも時間を割いているのをみていると、とても不毛だと思うので*3

*1:正確にはこの回のみ、"Opening Talk"となっていますが、位置づけは変わっていないので、Keynoteに含めることにします

*2:以下、基本的にファーストネームで呼称します

*3:近いうちに収束するとは思いますが

HerokuでOpenJDK 7を使う方法

といっても、公式ドキュメントに全部書かれてるわけですが。ポイントは、

  • java.runtime.version=7 を書いた system.properteis ファイルをプロジェクト直下に置いてコミットする
  • heroku上のPATHに /app/.jdk/bin を追加する (既存のPATHより前になるようにすることに注意)

くらいでしょうか。

モバイルSuicaとPasmo定期券と自分の脳みそ

※自分は脳の専門家でもなんでもないので、原因についてはテキトーな憶測です

今日、自分にとっては新鮮な発見があったので、せっかくなので書いてみます。

ここ一年くらいどうしてこうなるのか…と思っていた事が一つありました。それは、「9割くらいの確率で、モバイルSuica(Android携帯)とPasmoの通勤定期を取り違えて改札機にかざしてしまう」ことです。

ちょっとそれ頭ヤバイんじゃね?と言われそうなので、前提条件を補足します。自分は通勤に

  • 行き
    • (1-a) 半蔵門線O駅 - 渋谷駅 + 京王井の頭線渋谷駅 - K駅
    • (1-b) 半蔵門線O駅 - 田園都市線I駅直通
  • 帰り
    • (2-c) 京王井の頭線K駅 - 渋谷駅 + 半蔵門線渋谷駅 - O駅
    • (2-d) 田園都市線I駅 - 半蔵門線O駅

の経路のいずれかを使っています。

Pasmoの定期はO駅からI駅までです。通勤費は全額出るため直通で行った方が明らかに安いです。ただ、田園都市線I駅から職場までは上り坂なのと若干時間がかかるので、だるいときはS駅で乗り換えます。この場合、渋谷駅 - K駅間は自費になります。この通常の通勤経路では、どの組み合わせでも間違えることは「ほぼ」ありません(もちろん、全く自慢になりません)。

ただ、週一のミーティングが京王井の頭線の神泉駅付近で行われるため、

が週一の割合で発生します。9割くらいの確率で定期とモバイルSuicaを取り違えるのは、まさにこのときです。最低限の額しかチャージしていない通勤定期をK駅で間違ってかざしてしまうのです!今まで変だなあと思いつつ、元々ボーっとしててドジりやすいからだとか自分を納得させていたのですが、よく考えると妙です。それなら、似たような(2-c)や、それ以外で乗り換えが発生する(1-a)でもかなりの確率で取り違えが発生しているはずです(ただ、(2-c)は、(3-a)ほど頻発はしないものの、一定確率で取り違えが発生しているように思います)。

整理してみると、(1-a) (1-b) (2-d)のいずれも、最初に乗る電車でまず「Pasmoの通勤定期をかざす」動作を行っています。改札機で引っかかるパターンは「モバイルSuicaをかざすべきところを、Pasmoの通勤定期をかざしてしまう」パターンしかありません(逆パターンは引っかからない上に残額が減るので、すぐ気づきますが、ほとんどありません)。そして、主な通勤ルート(行き帰りの両方含む)では、「Pasmoの通勤定期をかざす -> モバイルSuicaをかざす」あるいは「Pasmoの通勤定期をかざす」のどちらかになります。

ここまで考えて、「まず最初にPasmoの通勤定期をかざす」というのが行動としてプログラミングされているために、(3-a)で高確率で間違うのではないかと考えるに至りました。

しかし、(3-a)で取り違える確率が圧倒的に高くて、(2-c)のK駅で取り違える確率がだいぶ低いのは不思議です。(2-c)の経路も週2回、多いときは3回くらいで使うので、帰りの経路で「まず最初にモバイルPasmoをかざし、次の乗り換えでPasmo通勤定期をかざす」という行動がプログラミングされているのかもしれません(3-a)は週1回で、しかも「通勤」ではないためか、うまくプログラミングされず、頭の中で「デフォルトの処理」として「まず最初にPasmoの通勤定期をかざす」という行為が反射的に行われているのかもしれません。

何はともあれ、自分の脳が改めて興味深く思えてきました。日々の生活の中でこういう事を考えるのもいいものですね。

ところで何故こんな面倒な切り替えを行っているかというと、モバイルSuicaでは乗車駅がJR沿線でないと定期券を買えず、Pasmo(Suicaが使える場所では普通使える)でオートチャージをするには、鉄道会社のクレジットカード等を別途契約する必要があるためです*1

最後に当たり前ですが、私は脳の専門家でも脳について特別に勉強をしていたわけでもないので、行動が「プログラミングされている」といった表現はあくまでイメージであって、的外れな考え方かもしれません。

ではでは。

*1:とても面倒くさいですね。せめてモバイルSuicaでJR沿線が乗車駅でなくても定期が買えるか、Pasmoでオートチャージが簡単に設定できればいいのですが…

部分適用をカリー化と呼ばないで

カリー化と部分適用の違いについては、過去のエントリ カリー化 != 部分適用 で既に述べており、決着もついているので改めて書きません。

カリー化 != 部分適用のエントリを書いたのは2009年12月です。もう3年以上前の話になります。ですが、JavaScript界隈などをみると、未だにカリー化と部分適用の違いについての誤解は残っているようです。一方で、静的型付き言語界隈でそのような誤解をほとんどみかけません。カリー化が関数の「型」を変換する操作(関数)であるために、動的型付き言語にのみ慣れ親しんでいると、両者の違いがわかりにくいのかもしれません。

ある技術用語が指すものを誤解する事自体は仕方ないことですし、責めるものではありません。また、用語が指すものは時代を経ると変わっていくものだという主張もあるでしょう。ただ、カリー化という用語の定義は明確に定義されており、数十年もの歴史があります。ここ10年くらいのいわゆるLightweight Languageの台頭によって、本来の意味で「カリー化」という用語が使いにくくなるのは嬉しくありません。

というわけで、今回のエントリのタイトルにつながります。好き好んで間違った用語の使い方をする人は居ないと思いますが、

最初に、カリー化に関する誤解をした状態で、カリー化に関する記事を書く ->
別の人が最初のエントリをみて、誤解した理解でカリー化に関する記事を書く -> 
さらにそのエントリを読んだ人が…

のような状態になるのは珍しいことではありません。

一方、カリー化(を行う関数)と部分適用(を行う関数)では静的な型が異なるため、静的型付き言語ではこのような勘違いは起きづらいです。カリー化という用語の正しい使い方について調べるときは、動的型付き言語のサンプルコードを用いた解説ではなく、できる限り静的型付き言語(Haskell, OCaml, Standard ML)を用いた解説を読む事をお勧めします。

もちろん、動的型付き言語のサンプルコードで正しい「カリー化」の解説をしている記事も多数あるのですが、間違った記事や、ある言語の標準ライブラリが間違った「カリー化」関数を提供していることすらあるので(!)、カリー化について調べているときにどちらが正しいか判断するのはやや難しいです。