毎年IBM社内で行ってきた執筆道場を、今年はトライアルとして社外でも行ってみることにしました。次のような活動を半年かけて行っていきます。
- 執筆テーマを考え、メンバからコメントをもらう
- 他の人の執筆テーマについてコメントする
- 執筆してみて、メンバからコメントをもらう
- 他の人の執筆原稿にコメントする
- 良いものができたら、出版社に売り込みに行く
以下について同意できる方のご参加を待ちしております。
- 執筆テーマ、原稿は他の方の著作物です。無断での転用など著作権を侵害しないこと
- 活動は全てボランタリ(無償)活動です
- 外部著作、社外活動について、ご自身所属の会社に規定がある場合には、それに従ってください
- 活動は全てオンライン・ミーティング(Googleハングアウトを予定。人数が多いようであればSkype)で参加可能です
ご興味のある方は、以下からご参加ください。
第7曲は、愛らしいメロディが繰り返される小品。
この曲でやっかいなのは、ここの和音。
右手は広い音域をおさえなければならないので、親指で2つの音を弾くように指定されている。そしてクレシェンドが指定されているが、スラーの最後の音なので音量は抑える必要があり、ここは音を揃えて弾くのが難しい。
第8曲は、終始同じリズムのパッセージが繰り返される中、中声部でメロディが奏でられる。
Apple Musicに入っている方は、以下からもどうぞ。
楽譜引用はエキエル版から
Chopin Prelude No 5, 6
ショパン・プレリュード 第5、6曲
第5曲は、音の洪水の中に、メロディともメロディともつかないような中声部が現れ、もやの中の景色のよう。
第6曲は、右手の伴奏の中に左手で朗々とメロディが歌い上げられる。
途中メロディは爽快な長調に転じ、山を登っているかのよう。最後は最初のメロディに戻って靜かに曲を閉じる。
楽譜引用はエキエル版
第3曲は、軽快な伴奏の上に、これまた軽快な複々符点音符のメロディが繰り返される。ただそれだけなのに、とてもエレガント。しかしこの左手をうまく弾くのは至難の技。
第4曲は、左手の和音の連打の上に、悲壮感と葛藤を感じさせるメロディが奏でられる。最後はそれでも叶わぬ絶望とあきらめの中に靜かに曲を閉じる。
楽譜引用はエキエル版
ノクターン13曲目以降は、まだ終わっていないので、ショパンのプレリュードを取り上げていきたい。
さてプレリュードは、1曲目から謎が多い。
上声部と、下声部は16分音符の3連符だが、問題は中声部だ。もちろん2/8拍子なのだから符点8分音符と16分音符で問題は無いが、開始点がずれているので計算が合わない。では、中声部も実は3連符なのかというと、16分音符の3連符5つ分なので、やはり1つ分計算が合わない。
この曲は、一部だけ5連符へと微妙にリズムが変更されていて、ここも謎かけになっている。こちらは中声部の開始点がずれていないので、計算上、問題無いのだが、逆に他の部分はどういうわけなのだ、という感じ。色々とずれているものを、うまくまとめてみろというショパンからの挑戦状なのだろうか。
第2曲は、左手で重々しい二重音が続く中、右手で同じ旋律が繰り返される。
最後に一瞬長調に転じるが、結局最後は短調で終わる。
楽譜引用はエキエル版
作品37-2は、通称「舟歌」。確かに6拍子の音型は比較的流れの速い川を下っているかのようだ。しかし、曲を通して二重音のオンパレードで、これを軽やかに粒を揃えて弾くのは下手な練習曲より難しい。
次々と調が変わっていくこの曲は、フォーレを想起させるが、もちろん時代的に言えば、こちらの曲の方が先なわけで、もしかしたらフォーレが参考にしたのかもしれない。この次第に調が失われていくところも、段々と色彩が消えていくようで趣深い。
もう1つの主題は素朴で暖い音型で、例によって三部形式かと思いきや、2つの主題が交互に表れる形式になっている。
最後の部分。ここの推移も見事だ。
そして2つ目の主題が少しだけ表れて静かに曲を閉じる。
楽譜引用はエキエル版から。
「プログラミング作法」を送っていただきました。私はずっと「プログラム書法」の方だと思っていて、いただいた時に「あれ、こんな内容だったっけ?」と戸惑ってしまった。
他の言語に関する記載もあるが、基本的にC/C++での作法の本なので、そのあたりは気に留めておく必要があるだろう。というか他の言語の話まで無理に入れなくて良いと思うのだが...
第1章は名前の話やスタイル(インデントなど)の話で、このあたりは(副作用の話あたりを除けば)、他の言語でも通用する話と思われる。あとはマクロの使用方法の注意やコメントの注意。
第2章は、二分探索、クイックソート。その後はデータ構造として動的配列にリスト、ツリー、ハッシュ。
第3章は、マルコフ連鎖を実装していく。Javaやawk/Perlでの実装が出てくるが、Java版はVectorとか使われていて、さすがに古さが否めない。性能比較が出てくるのだが、これも多分JVMの起動時間まで含めて計測してしまっている感じで、参考にはならない気がする。
第4章は、CSVのパースを行うが、strtokを使った簡易版。この本が書かれた時代は、RFCも無かっただろうし仕方が無いだろう。インターフェイスを作成する際に何に気をつけるべきかが記載されている。
第5章は、デバッグの方法。ここまで色々とコツが書かれているケースは珍しいかもしれない。
第6章はテストの話。境界条件など何に気を付けるべきかといった話。そして自動テスト。この時代に自動テストまで書かれているのは先進的だったと思われる。
その後、移行、性能、移植性の話へと続く。というわけでC/C++覚えたての初心者が読むと非常にためになる本だし、絶対に読むべきだと思う。ただ他の言語の例を混ぜ込んで無理に一般的な話にしようとしたのは失敗だったのではないかと思う。
コメント投稿のところに、興味本位でreCAPTCHAを付けてみた。方法はこのサイトが詳しい。ただ、うまくいかないところもあったので補足。
上記の解説では以下のようにsiteverifyでGETリクエストが使えるように見えるが、
https://www.google.com/recaptcha/api/siteverify?secret={Secret key}&response={認証コード}
Googleのサイトでは、POSTしろと書かれている。おそらく昔はGETで可能だったのだろうが、さすがにsecret渡すのにGETは、まずかろうということで変更されたと思われる。
あと、以下のようにコールバックを指定すると、reCAPTCHAがチェックされた時にコールバックを受けられるのだが、
<div class="g-recaptcha" data-callback="syncerRecaptchaCallback" data-sitekey="{あなたのSite key}"></div>
コメント投稿のボタンを最初はdisabledにしておいて、これを使って、disabledを外すようなロジックを入れると、その後、サーバ側でsiteverifyを呼び出しても失敗するようだ。
これは憶測でしかないが、コールバック指定をする場合、認証コードがコールバック関数に渡されることから、そのコールバック内でsiteverifyが実行されることを想定しているのではないかと思われる。このためコールバック関数が終わった段階で、認証(siteverify)のAPIを発行できる期間も終わっており、それ以降のsiteverifyは失敗になるのではないかと。
ところでreCAPTCHAは、機械学習を使うことで、チェックするだけでokになった画期的なCAPTCHAだという触れこみだったように思うのだが、自分がやると毎回画像判定が表示される。はて。
OKです。
Yay!