2019-11-17

侮辱的な報酬額の大学講師の仕事依頼がやってきた。その額なんと月2.7万円

あるミッション系の大学から講師委嘱の依頼がやってきた。その科目は私の個人的な知識と経験から興味深い話がたくさんできるであろう分野で、具体的には、著作権特許権と検閲、電子書籍とDRM、著作権特許権の保護する範囲を越えようとする不自由なソフトウェアライセンス、岡崎図書館事件、兵庫県警Alertループ事件、神奈川県警CoinHive事件、あるいは本の出版事情や再販制度といった内容を取り扱うことになる。

例年70-80人の履修者がいて、1学期間に1コマ100分が14回に加えて内容の理解の確認のための課題と評価だ。

単純計算で一ヶ月に7時間の授業と、準備時間を授業時間と同じぐらい確保し、課題作成と80人分の回答を評価する時間を考えると、最低でも月に20-30時間ぐらいは必要だ。質をあげようとすればもっと長時間の労働になるだろう。大学なので報酬は安くても引き受けるとして、期間を定めた個人請負なので時給1万円ぐらい、月に20-30万円ぐらいならば請けようと思っていた所、提示された報酬額はなんとわずかに月2.7万円。

もはや失礼を通り越して桁違いに侮辱的な額だ。まさか想定より桁が一つ違う失礼な額を提示されるとは思わなかった。東京都の最低時給は現在1013円。最低時給を満たすかすら怪しい。およそ大学講師という知的労働に見合った報酬額ではない。

当然詐欺を疑ったが、残念ながら可能性はだいぶ低いように思われる。大学名、教授名、科目名はすべて実在のものであるし、メールアドレスのドメインはac.jpでこれはおいそれと取得できるものではないし、確かにこのメールアドレスに送信した内容に応じた返信を得ている。私はTLS経由でGMailを利用しているので私とGoogleの間の通信経路の改変はないものと考えると、GoogleとGoogleから通信経路さえ信用できればいい。

挙げ句のはてに、「大学の教員のお給料ってそういうレベル」と返事が来たものだ。

そういうレベルとは一体全体どういうレベルだ。公開されている情報によれば、この私立大学は1年あたり、国公立大学の学費の3倍もの費用を学生に課している。3倍金を払っている学生が70-80人も履修する授業において、税法上優遇されている学校法人が、履修者のたった一人の一月分の学費のそのまたさらに10分の1の額しか講師に出せないとしたら、そのカネは一体どこに消えているのだ?

この大学の学生は、学費を搾取されている情弱か、あるいはカネで学位を買っている詐欺者だろう。

そもそも私に声がかかるのがまずおかしい。私はたまたま該当分野で教育できるだけの知識と経験を持っているが、私はこの分野で有名というわけではない。まともな人間は引き受ける報酬額ではないので、ようするにネット上で適当に検索してある程度の知識を持っていそうな人間に片っ端から声をかけているのではないか。残念ながらそれで釣れるのは山師と詐欺師だ。月2.7万円に見合う仕事というのは何の準備もせずデタラメを話し、課題の提出と評価もさらに安価で他人に丸投げし、ついでに学生をネズミ講にでも勧誘することだ。そうすれば元が取れるだろう。ついでに大学講師をしているという肩書を利用してオンラインサロンでもすると一層元が取れる。

こんな侮辱的な報酬額を提示するのは、これでも請ける人間がいるからだろう。労働力の不当廉売をする者は被害者ではなくて加害者だと心得よ。

2019-11-14

John Carmack、人工汎用知能に取り組むと宣言

John Carmack - Starting this week, I’m moving to a... | Facebook

今日から、OculusのコンサルCTOの立場になる。

まだ開発に口を出すが、そんなに時間は割かない。

残りの時間をどのように費やすべきか。振り返って見るに、私はゲーム、ロケット、VRの分野において成果を上げてきた。ただ、今までは曖昧ではあるが解決策の道筋は見えていた。その当時は非現実的であったりまだ動くと証明されていなかったとしてもだ。そこでたまに考えていたのだが、解決の道筋すら見えない問題に取り組むのはどうだろうと。私が歳を取りすぎる前に挑戦すべき課題であるように思われる。

私は人工汎用知能(Artificial general intelligence, AGI)に取り組むことにした。

AGIは可能で、とても有益で、かつ私は何らかの成果を上げられるのではないかと思っている。そこでPascal’s Mugging(たとえ可能性が極めて低くてもそれによって得られる利益が莫大であれば期待値的には釣り合っているのでやるべきという理屈)に従い、挑戦する。

今のところ、私は「ビクトリア朝時代の紳士科学者」風に研究する。自宅で考え、実践してみるのだ。

AGIの次に取り組むべき価値のある研究は、安価な核融合炉だが、この研究スタイルには合わない課題だろう。

2019-11-10

スキー場のシーズン券の購入を考えている

今シーズンは11月から5月まで全力でスノーボードをする予定だ。週に2回はスノーボードに行きたい。そこでシーズン券を買うことを思いついた。同じスキー場に何度も行くのであればシーズン券を買ったほうが得だろう。前シーズンは旅行会社のツアーで新幹線とリフト券を割安で手に入れていたが、旅行会社でツアーに申し込むのも面倒だったし、前シーズンでは東京-越後湯沢を日帰り往復するだけの割安ツアーもあったので、損はしない。

ではどこのシーズン券を買うべきか。都内から日帰りできるスキー場というと、軽井沢か越後湯沢だ。ただ、軽井沢プリンスホテルスキー場は土日祝日に混むのと、スキー場の作りがそんなに面白くはないので、越後湯沢駅から短時間で行けるスキー場になるだろう。

去年はガーラ湯沢によく行っていた。駅直結で行きやすいスキー場ではあるが、ある程度滑れるようになった今、他のもっと面白いスキー場でもいいだろう。特に今年はコブを練習したいのでコブで有名なスキー場がいい。

かぐらスキー場はコブで有名だ。ただしシーズン券が高い。他のスキー場の倍の値段だ。なぜこんなに高いのか考えていたが、おそらく営業期間のためだろう。多くのスキー場は12月下旬から3月末までの約3ヶ月間営業する。しかし、かぐらは11月下旬から5月下旬までの約6ヶ月営業する。営業期間が倍なので、価格が倍でも売れると踏んでいるのだろう。ただ、かぐらはゴンドラやリフトの設置があまりよくないせいで、移動するのに時間がかかる。シーズンのはじめと終わりに何回か行くだけでいいだろう。

神立高原(今年から名前を変えて神立スノーリゾート)は仮眠室という名前の雑魚寝部屋がある。ここのシーズン券と温泉パスを買うと風呂入り放題雑魚寝し放題滑り放題となる。しかもこのスキー場はナイターもかなり長時間やっている。ここならば、夕方に東京から越後湯沢に行き、軽くナイターを滑って雑魚寝し、翌日も滑って風呂に入って帰ってくることができる。実はかなりいいのではないか。ただし、雑魚寝部屋は休日しかやっていないそうだ。

石打丸山スキー場はハーフパイプがある。ただし、おそらく今年はハーフパイプをするほどには上達はしないだろう。

舞子スノーリゾートの早期シーズン券を買うといろいろと特典がついてきてお得だ。

特典という意味では、ガーラ湯沢も捨てがたい。ガーラ湯沢のシーズン券を買うと、なんとスクールの回数券が5000円引きで買えるそうだ。つまり2時間レッスンが実質2千円で受けられることになる。ガーラ湯沢は4月以降もGWまで雪が続く限り営業するので4月になってからも何度かは滑ることができる。

といろいろ考えたが、旅行会社のツアーやショップの割引券などを使えば、リフト券の代金は1日3千円ぐらいになる。それに、今年も白馬八方尾根スキー場などに何度か遠征する予定だ。シーズン券を買って一つのスキー場に縛られるより、いろんなスキー場に行ったほうが楽しめるのではないか。

2019-11-07

Using enum

C++20にはusing enumが入る。この機能、すっかり見逃していた。

どのような機能かというと、scoped enumを名前空間のusing directiveのように使うことができる。

using enumがないと以下のように書かなければならないが


enum struct color { red, green, blue } ;

void f( color c )
{
    switch( c )
    {
        case color::red :
            break ;
        case color::green :
            break ;
        case color::blue :
            break ;
    }
}

using enumを使えば以下のように書ける。


enum struct color { red, green, blue } ;

void f( color c )
{
    using enum color ;
    switch( c )
    {
        case red :
            break ;
        case green :
            break ;
        case blue :
            break ;
    }
}

scoped enumは暗黙の型変換をしないので、従来のenumに変わって使われるべきだが、いちいちenum名を修飾子なければならないのは面倒だ。そこで、名前空間のusingディレクティブのような機能、using enumが追加された。

CADDiのC++勉強会@11月19日

CADDiのC++勉強会が11月19日の19時から行われる。

C++勉強会 #8 - connpass

今回は一時オブジェクトの寿命と、C++20の新機能を時間が許す限り解説していく。

2019-10-25

江添誕生日ボドゲ会@10月27日

自宅ボドゲ会を下記の要領で開催します。

江添誕生日ボドゲ会@10月27日 - connpass

今月は誕生日なので夕方からすき焼き。

2019-10-15

CADDiのC++勉強会

次のCADDiのC++勉強会は10月29日の19時から行われる。詳細と参加登録は以下から行える。

https://caddi.connpass.com/event/151541/

次はtype erasureの続きと、expression templatesについて教える予定だ。

2019-10-12

東京から行けるスキー場のまとめ

シーズンはまだまだ遥かに遠い。早く滑りたい気持ちを抑えるために、またブログ記事でも書くことにする。今回は東京から行ける、個人的に気になっているスキー場について書く。まだ行ったことがないスキー場もある。

フジヤマ スノーリゾート イエティ|静岡県 富士山2合目のスキー場

例年10月下旬にオープンするスキー場。標高が比較的高く涼しい場所に人口造雪機を使って10月下旬に1kmのコースを作り出している。都内から日帰りできる最も早くオープンするスキー場として有名だ。

東京からはバスで片道2時間半かかる。まだ行ったことがない。

軽井沢プリンスホテルスキー場

11月上旬にオープンするスキー場。同じく人口造雪機を使って400mほどのコースを2本作り出している。イエティの次にオープンするスキー場として有名だ。東京からは新幹線で1時間ほどなので、イエティより交通の便が良い。

スキー場周辺は何もない場所であることが多いが、軽井沢は観光地なのでショッピングモールや飲食店街がある。コテージがスキー場の真横に設置されていて、ドアを開けるとすぐにスキー場というお手軽さもある。ただ、スキー場としての面白さはそれほどでもない。もともとそんなに雪が降る場所ではないのを圧倒的多数の人口降雪機で雪を作り出している娯楽施設だ。それに観光客が多くて休日は結構混んでいる。

この他のスキー場は、11月下旬から12月中旬にかけてオープンしていく。

ガーラ湯沢スキー場(新潟県湯沢町)|GALA YUZAWA

東京から新幹線で90分。ガーラ湯沢は東京から日帰りするのに最も手軽なスキー場だ。新幹線に乗る時間だけを考えると軽井沢よりは長い。ただし、軽井沢は駅到着後にスキー場まで移動しなければならないが、ガーラ湯沢は移動する必要がない。JR東日本直営のスキー場で、駅直結の同じ建物内にリフト券売り場、レンタル、更衣室が揃っていて、同じく建物直結のゴンドラで上に上がるとそのままゲレンデにつく。標高が高いので雪質もよい。ただし、そのお手軽さゆえにあまりにも観光客が多く、かつスキー場も狭い。

雪がもてばGWまで営業している。

湯沢中里スノーリゾート

越後湯沢駅からバスもしくは電車で15分。標高が低く天候に恵まれなければあまり雪質がよくない。3月にもなると雪が汚れている。平日は一部のリフトは動いていない。ただし圧倒的に空いている。そしてスノーボード率が圧倒的に高い。幅広で傾斜もほどほどのスノーボードが滑りやすいコース設計になっている。

舞子スノーリゾート

越後湯沢駅からバスで2-30分。スキー場の作りとしては、標高が高い上のコースをぐるぐる回るか、長い下山コースを繰り返すかの二択になる。

神立高原スキー場

越後湯沢駅からバスで10分。だいぶ異質なスキー場。スキー場に浴場と大部屋仮眠室があり雑魚寝をすることができる。土日祝日はナイターが深夜までやっている。

まだ行ったことがない。東京駅に近い場所に住んでいて日帰りの負担が少ないため、正直ここに素泊まりするよりは一度東京に帰ったほうがマシだろうと思われる。

かぐらスキー場

越後湯沢駅からバスで2-30分。例年11月下旬にオープンし、5月下旬までやっているスキー場。標高も高い。もともと3つのスキー場が合体したスキー場で広いには広いのだが、入り口から雪質のよい標高の高い場所に行くだけで20-30分はかかる。

白馬八方尾根スキー場 | HAKUBAVALLEY HAKUBA HAPPO-ONE

新幹線で90分かけて長野駅まで行き、そこからさらにバスで70分かかる。移動だけで半日潰れてしまう。1998年長野オリンピックの会場にもなったスキー場だ。とても広い。ただしスキー場の作りはスノーボード向きではない。

北海道

キロロ、ルスツ、ニセコ、フラノ、トマム、サホロが有名。東京からの交通は、羽田空港から新千歳空港に行きバスとなる。サホロだけは帯広空港が近い。まだ行ったことがない。

北海道の有名なスキー場は圧倒的に広く、雪質もよいと聞いているが、東京からは交通の便が悪い。東京から羽田空港まで電車で30分、新千歳空港まで旅客機で1時間半、空港からバスでスキー場まで2時間以上。しかも搭乗手続きの関係上、空港にはフライトの一時間前には着いていたい、スキー場に到着するまで6時間以上かかる計算になる。行くだけで1日潰れてしまう。

月山スキー場

山形の豪雪地帯にあり、ハイシーズンは雪が深すぎて営業していない。4月になるとようやくオープンする変わったスキー場。7月頃まで雪が持つので、どうしても夏に天然雪を滑りたい中毒者がやってくるスキー場。今では珍しくなったTバーリフトもある。

乗鞍岳

スキー場ではなく夏でも雪が残っているだけの場所にすぎない。標高2600mぐらいの地点までバスでいくことができる。リフトはない。自力でハイクアップする必要がある。

早く滑りたい。

2019-10-07

Caddi C++勉強会@10月9日

CaddiのC++勉強会が10月9日に開催される。参加は以下から。

https://caddi.connpass.com/event/150414/

今回は派生と継承という、C++の原点に戻ったような内容を説明する。そしてtype erasureを説明する。時間があればexpression templatesなども説明するが、おそらく次回になるかもしれない。

2019-10-06

スキー/スノーボードの怪我統計の考察

そろそろシーズンが近づいてきたのでそわそわしている。去年は3月末で滑るのを辞めてしまったのでもったいないことをしたと反省している。4月も滑ればよかった。とはいえ、右膝に痛みもあったし辞めておくのは正解だったのだろう。

滑りたいのにまだ滑ることができない憂鬱を紛らわすために、全国スキー安全対策協議会のスキー場障害報告書を読んでいる。

全国スキー安全対策協議会

統計は1998年から始まっている。調査に参加したスキー場には増減があるので、単純に年ごとに比較することはできないが、時代の変遷を感じる面白さがある。

1998年は、カービングスキーに主流が移ってきた時代で、スノーボードが流行り始めた時代でもある。カービングスキーによってアスリートではなくてもカービングターンができるようになり、スノーボードがもたらしたパークをスキー場が設置するようになってきた。

1998-1999シーズンではスノーボードはスキーの2.5倍の受傷率があった。これはどんどん下がり続け、ところが前回の2018-2019シーズンではスノーボードの受傷率はスキーの1.4倍になっている。スノーボードはだいぶ安全になったと言える。

具体的な受傷率はスキースノーボード合わせて1万分の1だ。同じ1年で比較すると、年末ジャンボ宝くじの一等が2000万分の1、雷に当たる確率が1000万分の1、交通事故が3万分の1、裁判員に選ばれる確率が1万分の1となる。それほどウインタースポーツの受傷率は高くない。

怪我の中でもかなりの割合を占める頭部への損傷であるが、ヘルメットを着用していれば防げた怪我がおおい。海外では8割にもなるヘルメット着用率は、日本では未だに低い。2018-2019シーズンでは、スキーのヘルメット着用率が初めて4割を超え、スノーボードでは22.9%だという。ヘルメットは着用すべきだし、各部位へのプロテクターもつけるべきだ。

昔の統計はストレートスキーとカービングスキーを分けていたが、今の統計は一緒になっている。今ではすっかりカービングスキーが主流になり、ストレートスキーを使っているスキーヤーはまれになってしまったからだろう。

受傷時刻は毎年決まって11-12時と14-15時が多い。昼に下がるのは昼食のために人口が減るからで、単に人口が多いから受傷率が高いだけだろう。同じように天候も晴のときが受傷率が高い。特に休日の晴れは受傷率が高い。これも単に人口が多いだけだろう。性別や年齢も、単なる人口比としか思えない結果になっている。ただ、1998-1999シーズンの統計ではスノーボードの年齢は20代が大半だったのに、20年たった今では40台まで広がっている。

受傷者の技能をみると、初めての人の怪我はそれほど多くない。初級者から中級者の怪我が圧倒的に多い。スキーはスノーボードの倍ほど上級者の怪我が多い。この理由はなぜだろう。

怪我の部位を見ると、スキーは圧倒的に膝の捻挫が多い。スノーボードは長らく手首、次いで肩だったのだが、最近は肩の怪我の方が多くなっている。手首の怪我はプロテクターをつけていれば防げるが、肩の脱臼はプロテクターで防ぐことができないためだろうか。

怪我をした理由としては、自分で転倒、人と衝突、人以外と衝突、その他があるが、圧倒的に自分で転倒して怪我をする割合が高い。実は人と衝突して怪我をする割合はスキーのほうが高い。去年滑っていて、リフトから落ちたらどうしようとか、崖から落ちたらどうしようなどと不安になったものだが、転落による怪我の割合は極めて少ない。

自分で転倒した怪我の内訳として最も多いのは単に「バランスを崩した」ためだが、スキーは9割を占めるこの理由、スノーボードでは75%しかない。スノーボードはスキーよりトリックを決める文化が強いせいか、ジャンプ失敗やトリック失敗といった理由が増えてくる。スノーボードでは逆エッジによる転倒もある。

人と衝突した場合、何にぶつかったかという統計が出ている。ぶつかる可能性があるのは、スキーヤー、スノーボーダー、それ以外の人だ。スキーヤーはスキーとスノーボードとの衝突がそれぞれ半々ぐらいだ。スノーボードでは圧倒的にスノーボードとの衝突が多い。

人以外との衝突でぶつかったものについては、立木が最も多いようだ。

日本のスキー、スノーボードで気になっていることとして、スキー場で堂々と酒が販売されているということだ。そして多くの客が飲んでいる。ただ、受傷者の飲酒の割合は2.2%で、それほど高くはないようだ。

受傷場所は緩斜面か中斜面が多く、急斜面での怪我は少ない。

リフト付近での怪我は、リフト乗り場とリフト降り場の怪我が大半で、リフト乗車中に怪我をすることはめったにない。何故か私はリフト乗車中に落ちてしまったらどうしようという不安が常にあるのだが、リフト乗車中に落ちて怪我をすることはまずない。リフトから落ちるのは子供が多いようだ。リフトが子供の体格に合わせて作られていないのが問題なのだろう。

スキーでは講習中に怪我をする割合も高い。スノーボードで講習中に怪我をする割合は少ない。報告書はスキーのほうがスクール受講率が高いのだろうとしている。

障害の程度だが、スキーよりスノーボードのほうが若干軽症が低く、中等傷が多い。重症の割合は余り変わらない。

「頭を強く打った疑い」については、スキー、スノーボードともに割合が変わらない。どちらもヘルメットを着用すべきだ。

受傷時の滑走速度の割合は、単に滑走速度の人口を表しているに過ぎないようだ。

興味深いのは、傷害保険、賠償責任保険の加入有無について、わからないとする回答が4,5割いるということだ。保険に入っているかどうかぐらいわかりそうなものだがどういうわけだろう。統計を報告したのは各種スキー場なので、聞きそびれているだけなのかもしれない。

受傷時の雪面は圧倒的に圧雪されていることが多い。ただ、日本のスキー場の大半は圧雪されているし、パウダーやコブでそんなに速度は出せないし、転んでもパウダーやコブに引っかかってすぐ止まることが多いので、当然といえば当然なのだろう。

雪質の割合もあまり意味のある統計には思えない。

2019-10-03

また初心者にプログラミングを教える機会があった

プログラミングでわからないところがあるので教えてほしいと以下のようなことを聞かれた。

こういうJavaScriptの関数がある。

// valuesは配列
// elementはvaluesの要素型の値
// 配列valuesに値elementと等しい要素があるならばそのインデックスを返す。
// それ以外の場合、-1を返す
function find_index( values, element )
{
    for ( let i = 0 ; i !== values.length ; ++i )
    {
        if ( values[i] === element )
            return i ;
    }
    return -1 ;
}

質問は、「なぜreturn -1にelseはいらないのか」というものであった。

似たような問題に、昔遭遇した気がするが、別人だ。

まずここにelseを書くべき文法はJavaScriptに存在しない。if文で何らかの条件を切り分ける必要もない。なぜならば、return -1が評価されるとき、すでにforループを抜けているわけで、その場合要素が見つからなかったということだ。逆に、要素が見つかったのであれば、すでに上のreturn iが評価されているので、すでに処理は関数の呼び出し元に戻っており、return -1は評価されることがない。

ただ、このような机上の説明を繰り返しても理解ができない様子であったので、さらにデバッガーでステップ実行してみせるなどして説明した。

この問題は、逐次実行という概念と、逐次実行がfor文やif文やreturn文によって変わるということ、そしてプログラミングにおける関数の理解が必要だ。しかし、筆者はこのような概念の理解に苦労した覚えはないし、周りの職業プログラマーに聞いても、やはり苦労した覚えはないという。

しかし不思議だ。質問者は数学の素養があり、数学における関数なら理解しているはずだ。聞けば再帰も理解しているという。それならと以下のように再帰で書いてみた。


function find_index( values, element )
{
    function solve( i )
    {
        if ( i === values.length )
            return -1 ;

        if ( values[i] === element )
            return i ;

        return solve( i + 1 ) ;
    }
    return solve(0) ;
}

これを何の説明もせずに見せたところ、「これはとても良くわかる。なんでみんなこう書いてくれないのか」とのことであった。質問者はJavaScriptの初歩の初歩しか学んでおらず、このようなコードは見たことがないはずだ。しかしわかりやすいと言う。再帰は正しく理解できていることが確認できた。

質問者にはHaskellのような純粋関数型の言語のほうが向いているのかもしれない。

2019-09-22

江添ボドゲ会@9月29日

自宅ボドゲ会を下記の要領で開催します。

江添ボドゲ会@9月29日 - connpass

2019-09-20

江添亮のC++入門の出版記念の勉強会告知

江添亮のC++入門の出版を記念した勉強会を開催します。参加登録は以下から。

https://kbkz.connpass.com/event/148247/

勉強会の内容としては、江添亮のC++入門の執筆について軽く話した後、その場で書籍の販売をしつつ、交流会をする。特に発表者はつのらない。というのも勉強会の価値は交流にあると考えているためだ。

2019-09-19

MSVCのSTLがGitHubで公開

https://github.com/microsoft/STL

MSVCのSTLがGitHubで公開された。ライセンスはLLVM例外条項付きのApache 2.0。更に興味深いことに、今後のSTLの開発はGitHubに移行する予定だそうだ。マイクロソフトも変わったものだ。

C++のテンプレートの都合上、STLのソースコードはMSVCに付属していて、読むことは誰にでもできた。理論的には、MSのEULAに縛られない読み方もできたはずだ。例えばEULAに同意せずにMSVCを入手し、インストラーを実行せずに手動でアーカイブを展開すればソースコードを読むことはできたはずだ。もちろん、わざわざそんな手間をかけてまで不自由ソフトウェアのソースコードを読みたいとは思わないし、民事上のリスクも背負いたくない。

そのため、私がC++を教育するときは、MSVCの存在は単に無視していた。libstdc++とlibc++は自由ソフトウェアであるので、その実装も含めて教育することができるが、MSVCは不自由なので、リスク回避のためにソースコードを読むこともできずにいた。MSVCを無視するなという声に対しては、不自由ソフトウェアに時間を浪費したくはないし、仮に私が教えたいにしても 、マイクロソフトは教えたがらないようだという都合のいい言い訳が成り立っていた。しかし、今後はそういう言い訳は通用しないようだ。

江添亮のC++入門が出版された

江添亮のC++入門が出版された。もうすでに一部書店では店頭に並べているところもあるようだ。

この本はタイトル通り入門書だ。C++のソースコードのコンパイル方法から初めて、GNU Makeによるビルドシステムを少し触り、基本的な文法を解説し、一部のライブラリの仕組みまで解説する。

この本の執筆にあたっては、知識のブートストラップを意識した。私は一から物を教えるという性質の本で、まだその本では説明をしていない知識を何の説明もなしにいきなり出す本を読んだことがある。巷では絶賛されている本ではあるが、著者自らもうその本で教育をしないと宣言した本だ。そのため、すでに説明した知識のみを使って次の知識を説明するようにした。

ただ、これは思いの外大変だった。入門書を書いている間、なぜ変えたいの知れないよくわからないもどかしさに包まれながら解説を書いていた。そしてとうとうポインターを解説した後、あらゆることの説明がとても簡単になっていることに気がついた。なぜならポインターの知識を前提にしてよいからだ。つまり、ポインターが知識の依存関係の割と根本的なところに存在するらしい。なぜポインターの解説がこんなに送れたかというと、現代のC++は生のポインターを直接使わずして実用的なコードが書けるからだ。

今回の本の表紙には私の写真が印刷されている。これは今まで2冊の本を出した際に、なぜ著者の写真がないのだ、ぜひ載せるべきだと言われていたので、3冊めとなる今回は、では載せてみようということで実現した。いまのところ、Twitter上での言及が今までの2冊に比べて多いようで、宣伝効果はあるようだl.写真の撮影は古くからの友人でプロのカメラマンの三浦大に依頼した。

Photographer - Masaru Miura

私の本のライセンスはGPLv3だが、写真はライセンスされない。写真の著作権は撮影者のもので、撮影者がGPLv3に同意しなかったためだ。撮影者は芸術家気質なので自分の作品を改変されたくないという気持ちは理解できる。

EzoeRyou/cpp-intro: Beginner's guide for C++

この入門書を読み終えたならば、少し古いが「C++11/14コア言語」や、未だに大多数の現場では使われていない最新の「江添亮の詳説C++17」も読むとよい。紙書籍、電子書籍で出版されている他、GitHubで公開されている。

EzoeRyou/cpp-book: C++11 textbook
EzoeRyou/cpp17book: textbook for C++17

数年後も同じ仕事を続けているのであれば、おそらく「江添亮のC++20」のようなタイトルの本が出るだろう。

近いうちに前の本でもやったように、本の出版記念の勉強会でも開きたいところだ。

2019-09-17

CADDi C++勉強会5回目

CADDi C++勉強会の5回目が9月25日に開催されます。

C++勉強会 #5 - connpass

今回はオーバーロード解決とテンプレートの実引数推定について解説する。

2019-09-11

CADDi C++勉強会、11日に延期

CADDiのC++勉強会が、台風の影響による電車の劣悪な運行状況から、11日に延期された。

https://caddi.connpass.com/event/146851/

当日はみんなの疑問に答える形で規格上の用語を解説していく。

2019-09-03

CADDi C++勉強会4回目

C++勉強会 #3 - connpass

今回は式と文の違いといった、C++の用語の解説をする。

今回の勉強会の動機は、CADDi社員がうっかり未評価式の文脈でラムダ式を使ってしまったところ、つまり

using type = decltype([]{}) ;

のようなコードを-std=c++17でコンパイルしたところ、「未評価の文脈でラムダ式は使えない」というそのままのコンパイルエラーメッセージが出力されたが、はて、未評価とは?という疑問でこのエラーメッセージの意味するところを理解するのに相当苦労した経験をしたことが元となっている。なぜC++コンパイラーがこのようなエラーメッセージを出すかというと、未評価という言葉は規格上の用語なのだ。ちなみに、Clangのほうがエラーメッセージは親切で、「未評価オペランドの中のラムダ式」としている。これは規格そのままの表現だ。GCCの表現は規格どおりの表現ではないが、規格に沿った表現であることに変わりはない。C++コンパイラー開発者は当然C++規格を参照しているのでC++規格に沿った表現を使う。そのために、コンパイラーのエラーメッセージを解釈するには、規格の用語の知識が必要になる。今回はそのような知っていると役に立つかも知れない規格の用語を解説していこうと思う。

2019-08-27

CaddiのC++勉強会3回目

Caddiによる3回目のC++勉強会が8月30日に開催される。

C++勉強会 #3 - connpass

今回はメタプログラミング。Boost.Hanaを解説する。

最近、私自身はメタプログラミングをしていない。というのも、C++のメタプログラミングは本来計算に使うはずではなかった言語機能を無理やり計算に使っているので、いろいろと無理がある。メタプログラミング機能はコア言語に入るべきだ。C++20ではrequires式がはいる。後は静的リフレクションがはいればBoost.Hanaなど用済みになる。静的リフレクションはC++23かC++26には入るはずなので、あと5年ぐらい待てばいいと思うのだが、そこを待てないのが悩みどころだ。D&Eにも書いてある通り、今使える技術が重要なのであって、来年使える技術には価値がない。

勉強会の内容としては、Boost.Hanaのユーザーマニュアルがよくかけているので、これに沿って解説していくことになる。

2019-08-16

江添ボドゲ会8月25日

以下の要領で自宅ボドゲ会を開催します。

江添ボドゲ会@8月25日 - connpass

2019-08-13

P++: 静的型付けをめざすPHP

PHP: pplusplus:faq

PHP 8から、PHPは「PHP」と「P++」という2つの言語を提供するようになる。P++はPHPとの下位互換性を削りながら除々にPHPを静的型付け言語にする試みだ。

PHP開発者の中には2つの流派がある。PHPの源流であり現在の形である動的型付け言語としてのPHPを良しとする流派と、PHPをより強い静的型付け言語へと発展させたい流派だ。良い悪いの問題ではない。どちらの流派も正当な理由がある。しかし、ゆるふわな動的型付け言語とガチガチの静的片付け言語は同じ一つの言語として同居できない。

そこで、コードネームP++として、PHPを静的型付け言語に発展させる新しい言語の開発が提案された。P++はforkではなく、PHPと同じコードベースを共有する。PHP 8のバイナリはPHPとP++を同時に実装する。言語の切り替えは何らかの宣言によって指定する。

P++はPHPの厳格な下位互換性を諦め、少しずつ下位互換性を切り捨てつつ、PHPを静的片付け言語にしていく。

これはPerl 5/6やPython 2/3という過去の失敗に学んだのだろう。

PHPとP++は同じコードベースであり、ほとんどのコードは共有するので、PHPの開発リソースが2倍必要になることはない。

PHP 7.4をLTSにしてPHP 8から介護感性を切り捨てるのは良いアイディアではない。言語を分断させてしまう。Python 2/3がすでに犯した失敗だ。

PHP 8はPHPとP++を含むので、PHP 8をインストールするとP++もついてくる。同じコードベースでPHPとP++を共存させることもできる。

PHPの開発が止まるわけではない。ただし静的型付け機能はPHPには入らずP++に入る。PHPは下位互換性を重視する。

Hackとはどう違うのか。Hackは一企業による開発であり、コミュニティの意見によって設計されなかった。またHackは流通や知名度の問題で難がある。P++はPHPと共存するので、PHP 8をインストールしたならばもれなくP++もついてくる。

PHPに静的型付けは必要か? 現在、PHPを仕事で使っているプログラマーの中には、本来ならば静的型付け言語を好むが、仕事なのでPHPを使っている人もいる。PHPが静的型付けを提供する意義はある。

2019-08-07

キャディC++勉強会8月21日、テンプレート基礎

C++勉強会 #2 - connpass

8月21日に株式会社キャディでC++勉強会が行われる。今回はテンプレート基礎だ。参加登録は上記connpassから行える。

前回はポインターと、時間が余ったので即興でリファレンスについて学んだ。今回は初歩的なテンプレートの使い方を学んでいく。

テンプレートといえば、昔はクラスと関数だけだったのだが、今では変数、エイリアス宣言もテンプレートにできる上に、C++20ではコンセプトも追加される。今回の勉強会では初歩的なテンプレートの使い方を一通り学んだ上で、時間があれば未来か過去の話をしようと思う。未来の話はコンセプトやメタクラス。過去の話はテンプレートの歴史だ。初歩を学ぶという点では過去の話をしたほうが良いと思う。

2019-07-19

キャディ株式会社のテクニカルアドバイザーになった

C++勉強会 #1 - connpass

Ta-da:ドワンゴは辞めていない。キャディでテクニカルアドバイザーとしてC++教育もすることになった。7月30日に最初の勉強会をする。

周りで転職が頻発しているので、私もにわかに転職熱をだし、自分の転職市場における価値を確かめるためにも、いくつか企業に話を聞いてみた。その結果としては、私を給料据え置きで雇いC++の仕事をさせたいという企業はあった。しかし、教育一辺倒というわけでもないし年収も現状維持、そしてドワンゴでまだやりたい仕事も残っているときている。転職も興味ぶかい人生の選択ではあるが、しばらくはドワンゴにとどまろうという判断を今回はした。

その話を聞いた企業の一つがキャディ株式会社だ。奇しくもちょうど1年前、もうC++17を現場で使っている企業があるというので話を聞きに行ってブログに書いたことがある。

C++17をすでに現場で使っているというキャディ株式会社に話を聞いてきた

キャディは板金加工の受注生産をしている会社だ。板金加工というのは一枚の金属板を切断したり曲げたり削ったりと様々な加工をして、顧客の望む形状の金属製品を作り上げる仕事だ。従来、板金加工の依頼をするとなると、板金加工業者と話をして、望む形状を伝え、熟練の職人が長年の経験と勘で必要な加工を決定していた。これは時間のかかる作業であり、価格の見積もりだけでも長時間かかるものであった。

キャディは見積もりを自動化することを目指している。顧客がキャディのWebサイトに生産したい形状の3Dモデルデータをアップロードすると、それをソフトウェアで処理し、あたかも折り紙を展開するように、1枚の板から目的の形状を作り出すための加工を決定する。必要な板金加工が自動的に決定できるのであれば、価格の見積もりもできる。従来の板金加工業者が、何日や何週間もかけてようやく見積もりを出していた作業が、自動化をすることによって一瞬で見積価格を顧客に提示することができる。これがキャディの目標だそうだ。

板金加工の見積もりを自動化する。こう書いてしまうととても簡単に読める。しかし似たような計算である折り紙の展開というのは数学的に難しい問題である。自動化の実現には、数学力とアルゴリズム力とコーディング力が必要だ。キャディは自動化の要となる処理の実装について、最新のC++を選択した。古いC++で生産性を下げている余裕はない。問題は、最新のC++を知っているプログラマーは労働者市場では希少だということだ。

しかも、単にC++を知っているだけではダメで、数学力とアルゴリズム力も問われる。しかし、これについては朗報がある。AtCoderのような競技プログラミングコンテストを定期的に開催しているWebサイトの興隆で、今や競技プログラミングは盛んに行われている。高レートを維持している優秀な競技プログラマーは本物の数学力とアルゴリズム力を持っているので、数学力とアルゴリズム力を持ったプログラマーは労働者市場に多数供給されている。

AtCoder:競技プログラミングコンテストを開催する国内最大のサイト

好都合なことに、競技プログラミングではC++が使われることが多い。問題は、単に競技プログラミングで好成績を出すためだけであれば、C++を理解する必要はないということだ。一部の突出した競技プログラマーは、プログラマーというよりはもはや数学者に近く、彼らにとってC++というのはプログラミング言語ではなく、都合のいい計算機でしかない。そのため、必要な数学力とアルゴリズム力とC++力を兼ね備えた人材は労働者市場に極めて稀にしか存在しない。労働者市場に即戦力がいないのであれば教育するしかないが、最新のC++がわかるプログラマーに数学を教えるのと、競技プログラマーに最新のC++を教えるのはどちらがマシかというと、確実に後者だ。そもそも、労働者の人口としてもC++プログラマーより競技プログラマーの方が多い。

キャディは最新のC++を現場で使う興味深い企業であるので、強い興味を持ちながらも、ドワンゴの環境も捨てがたく、結局転職はしなかったのだが、つい先日、技術顧問として月2回ぐらいキャディの社員向けにC++教育をしてくれないかという話がきた。キャディ社内には私と同等以上にC++に詳しい人間がいる。ただし彼には数学力もあるので教育よりは現場の開発に労力を費やしてほしい。単発の勉強会で30分ぐらい話してくれというのであればともかく、定期的に月2回も社員向け教育をしてくれというのは流石に無償では引き受けられない。では報酬も支払うという話になった。

ところで、今私が雇用されているドワンゴでは兼業申請が通れば兼業をしてもよいということになっている。兼業申請が認められるための条件はいくつかあるが、特に重要な条件に、ドワンゴと競合関係にないという条件がある。ドワンゴが板金加工事業をしているという話は聞いたことがないし、その他の条件も問題はないだろうと考え、兼業申請を出してみたところ承認された。

そしてこのたび、キャディ株式会社のテクニカルアドバイザーとなった。

当面の予定としては、月2回、勉強会を開くことになっている。勉強会でキャディの社内情報がかかわらない内容については、聞きたい人がいれば社外から少し人が聞きに来てもいいだろうということで、connpassで勉強会の告知を行うことになった。

C++勉強会 #1 - connpass

勉強会の内容としては、さしあたって、テンプレート、メタプログラミング、ムーブセマンティクスを理解できるようにする目的だが、記念すべき第一回目では、ポインターについて話すことになった。

なぜポインターなのか。私はちょうどC++入門書を書いている。この入門書ではC++知識のブートストラップを試みた。参考書ではすでに教えた知識だけを使って、次の知識を教えるようにした。このような入門書を書くのは初めてなので手探りで牡蠣進めていった結果、ポインターを教えるまではなんともいいがたい教えにくいという違和感があったのだが、ポインターを説明してからは、ポインターの知識を前提にできるので圧倒的に教えやすくなった。そのため、もしポインターが理解できていないのであれば、まずポインターを理解するべきであると考えた。そのため、今回はポインターだ。

https://github.com/EzoeRyou/cpp-intro

ポインターの難しさは複合的な要因がある。アドレスや関節参照という概念の難しさ。C++の型システムの難しさ。C++の文法の難しさがある。この3つを意識しながら7月30日は2時間、ポインターについて話をする。

江添自宅ボドゲ回@7月28日

7月28日に自宅ボドゲ回を下記の要領で開催します。

江添ボドゲ回@7月28日 - connpass

2019-07-15

標準C++規格が3年おきに制定される理由

現在、C++の標準規格は3年おきに制定されている。このスケジュールはC++14から厳しく守られていて、C++20は2020年に制定される予定だ。

なぜなのかを議長のHerb Sutterが解説している。

Draft FAQ: Why does the C++ standard ship every three years? – Sutter’s Mill

まず現状認識として、C++の標準規格は3年おきに制定される。ドラフトにバグがあるので遅らせるべきではないのか。ダメだ。そのために2年間の機能追加と1年間の機能フリーズとバグ修正の期間が儲けられている。

しかし、ある「機能」はあと数回の会議を経たならば完全に合意できて入れられる状態になっている。この「機能」のためにC++20を少しだけ遅らせられないのか? ダメだ。期限までにC++20に入れられない「機能」はC++23に回される。

このスケジュールは厳しすぎる。なぜ3年という固定の期間で物事が進むようになったのか。なぜならば、プロジェクト管理をする方法は2つしかない。長年の経験により、この方法が別の方法よりマシだとわかったからだ。

プロジェクト管理をする2つの方法とはなにか? 完成品をリリースするタイミングを決定する方法で、2つある。一つは機能に合わせること。もう一つは期間に合わせること。どちらか一つしか選ぶことはできず、一報を選んだならば他方を選ぶことはできない。

リリースを機能に合わせる場合、機能が完成しなければリリースできない。そのため、リリース期間を決めることはできない。結果としてリリース期間が際限なく遅延する。

リリースを期間に合わせる場合、期間に間に合わなかった機能は今回のリリースには含まれない。

リリースを機能に合わせる場合というのは、C++98とC++11だった。C++98規格は本来1994年までに制定されるはずだった。Bjarne Stroustrupは1994年までに制定できなければ失敗だとまで言った。結果、1998年になった。C++11は200x年までに制定されるはずだった。結果として2009年にすら2年間に合わなかった。

ある機能が、あと数ヶ月で完成するという時、それは数ヶ月で完成しないし1年でも完成しない。にもかかわらず、あと数ヶ月で完成するからという言い訳でリリースを延々と引き伸ばすと、当初の予定より大幅にリリースが遅れてしまう。

C++の規格制定が遅れると、C++コンパイラーの実装も遅れる。C++コンパイラーベンダーとしては、せっかく実装した機能が、規格の変更によって変わってしまうということを考えると、まだ変更されているうちはわざわざ労力を費やして積極的に実装する理由がない。規格を制定することでようやく実装にかかることができる。

C++98とC++11でこのような失敗をしたのは、我々は経験不足だったからだ。経験を得た我々は、プロジェクト管理に厳格な期間を定めることによって、スケジュール通りに規格を制定するようになった。3年の期間に間に合わなかった機能は次回以降の規格に回す。

2019-07-14

AMDのZen 2でRDRANDが-1を返すので最近のGNU/Linuxがブートできない問題

AMDのZen 2アーキテクチャの新製品が発売されて沸き立っているが悲しいお知らせがある。最近のGNU/Linuxディストロはブートしない。例えばUbuntu 19.04はブートしない。

理由は、ハードウェア乱数を返す命令、RDRANDに不具合があり、常に-1を返すのだという。このため、rdrandを直接使っているsystemdが失敗し、結果としてブートできなくなる。

AMDによればこの問題はBIOSアップデートで修正可能であるという。しかしこれはとても怪しい陰謀論を考えたくなる。なぜRDRANDが常に-1を返すような不具合が未然に発覚せずに製品リリースまでこぎつけてしまったのか。なぜファームウェアのアップデートで修正可能なのか。まさかバックドアなのではないか。

陰謀論はともかくとして、もう一つの問題は、なぜsystemdはRDRANDを直接使っているのかということだ。Linuxカーネルの提供する/dev/urandomではなぜだめなのか。

その理由は他ならぬsystemdのソースコードにコメントとして記載されている。

https://github.com/systemd/systemd/blob/f90bcf8679e8708788290519dc09371e60c6fc82/src/basic/random-util.c#L34

Linuxカーネルのブートの直後では、十分なエントロピープールが溜まっておらず、/dev/urandomへのアクセスすらかなり長い時間ストールする可能性がある。特に組み込みやVMといった環境では問題になる。このため、systemdはブート直後かつ、UUIDとハッシュテーブルのシードの生成のみにrdrandの値を直接使っている。

UUIDはユニーク性さえあればよく、セキュアなRNGは必要がない。

ハッシュテーブルは攻撃者が恣意的な値を多数登録することで、オーダーをO(1)ではなくすることができてしまう。そのためにハッシュ計算のシードに乱数値をつかている。

当初はsystemdはRDRANDを直接使うなんて馬鹿げたことをするものだと思っていたが、どうもこの状況を考えるに使いたくなる気持ちもわかる。systemdはRDRANDがない環境もサポートしているため、フォールバック実装はあるのだが、rdrandがあるが壊れている環境ではどうしようもない。

現在、systemdにworkaroundがコミットされているほか、ファームウェアアップデートが予定されているそうだが、問題はマザーボードベンダーがアップデートを提供するには時間がかかるため、しばらくはこの問題に悩まされそうだ。

結論としてはAMDが悪い。

2019-07-12

GPLv3でライセンスされた自由な技術書の電子書籍を買う理由

江添亮の詳説C++17の電子書籍の売上に対する印税の通知書がアスキードワンゴから送られてきた。額としては微々たるもので、9ヶ月かけて執筆した労働力に対する収入としては圧倒的に少ない。私がドワンゴに雇用されていて安定した給与所得があるのでなければ割に合わない。回らない寿司が何度か食べられる程度の額だ。

アマゾンで江添亮の詳説C++17を購入:https://www.amazon.co.jp/dp/4048930605

ところで、この本はGPLv3でライセンスされた自由な本だ。当然ソースコードが公開されている。

https://github.com/EzoeRyou/cpp17book

にもかかわらず電子書籍に金を払う理由はなぜだろう。しかも、その電子書籍の中にはAmazonのKindleのような不自由な本も含まれているのだ。

AmazonのKindleで多くの本を読んでいるので、不自由ではあるが同じデバイスで本を読みたいという人はいるだろう。

販売している電子書籍はプロの編集者によって組版されている。ここに価値を見出しているのかもしれない。

あるいは単に筆者に対するお布施かもしれない。

気になったのでTwitterで聞いてみた。

どうやらお布施目的が多いようだ。

技術書の出版が商業的に成立するにはお布施目的だけでは成り立たない。難しいものだ。

それはそうと、私の書いたC++入門書の出版作業をいましている。近いうちにアスキードワンゴから出版できる見込みだ。

https://github.com/EzoeRyou/cpp-intro

今回は、古くからの友人のプロのカメラマンである三浦大に依頼して、著者近影を撮影した。

http://www.masarumiura.jp/

著者近影の写真の著作権は撮影したカメラマンのものだが、それ以外の本はGPLv3だ。

また、C++と並列処理について書かれたAnthony WilliamsのC++ Concurrency in Actionの翻訳もアスキードワンゴから出版される予定だ。こちらは私が査読をする。

2019-07-09

C++20 Deprecate implicit lambda capture of this

C++20 deprecated the implicit lambda capture of this. What does it mean and how can we keep up with the change?

As of now, you probably don't need to do anything. Because it's just the deprecation, not the removal. But in the future, it will eventually be removed so be prepared.

So what is "implicit lambda capture of this" anyway? The following code relies on that behavior.

struct S
{
    int x ;
    void f()
    {
        // C++17: Well-formed
        // C++20: Deprecated.
        [=]{ std::cout << x ; }
    }
} ;

So above code use the variable x. this name x is a data member of class S. So "x" in this context means "this->x". Above code works because lambda capture implicitly capture this pointer. That's why we can use "x" inside the lambda expression.

You may not realize it but this "x" is not captured by copy. In fact, "x" is not captured at all. What lambda capture instead is this pointer. So we can use "x" via the this pointer. So "x" is effectively captured by reference. We can change the value of x.


void f()
[
    auto change_x = [=]( auto value ) { x = value ; } ;
    change_x(123) ;
}

This behavior breaks novice's assumption that lambda capture clause "[=]" means capture by value. People may write code like this:

struct S
{
    int x ;
    auto get_closure()
    {
        return [=]{ return x ; } ;
    }
} ;

int main()
{
    std::function<int()> f ;
    {
        S s{123} ;
        f = s.get_closure() ;
        // s's lifetime ends here
    }
    int result = f() ;
}

Assuming that it's safe because of captured by value and get caught by Undefined Behavior.

C++17 partially fixed this by introducing the explicit capture of this.


struct S
{
    int x ;
    void f()
    {
        // capture this pointer by value, x is reference
        [this]{ x ; } ;
        // catpure *this by value, x means x is value
        [*this] { x ; } ;
    }
} ;

"[*this]" copy the this pointer which means x is accessed through this pointer. "[*this}" copy the *this, that is the value of class object S. Since it copy the class object, x is copied too.

C++17 retained the implicit capture of this.

In C++20, it is decided that the standard deprecate the implicit capture of this via [=].


struct S
{
    int x ;
    void f()
    {
        // C++17: well-formed, it means [=, this]
        // C++20: deprecated, it still means [=, this]
        // C++??: if removed, ill-formed.
        [=] { x ; } ;
    }
} ;

The behavior of "[&]" doesn't change. It still implicitly capture this pointer by value. So the data members are effectively captured by reference. There should be no confusion on this.

2019-06-18

江添ボドゲ会6月30日

以下の要領で6月30日に自宅ボドゲ会を開催します。

江添ボドゲ会@6月30日 - connpass

2019-05-26

ダンスを学び始めて一ヶ月がたった

超会議でダンスを見て、にわかにダンスを学びたいと思ったものの、体が一切動かないので、ダンススクールに通い始めて早一ヶ月、未だに踊れるようにはなっていない。

向上を実感したことはある。まず拍子が認識できるようになった。裏拍もおぼろげながら認識できるようになった。

レッスン中のルーチンの振り付けを覚えられるようになった。始めた当初は、眼の前でインストラクターが実演する8拍や16拍程度の動きが全然覚えられなかった。今はある程度覚えられるようになっている。

ただ、拍子が認識でき、振り付けを覚えられるようになったからといって、体が動くわけではない。手足で表裏を交互に取るような動きは未だに難しい。ヒザで表を取りクラップで裏を取る動作だけは練習して少し体を慣らしたが、汎用的ではない。また、表と裏を交互に切り替えていくような動きも苦手だ。

手と足を同時に動かすことができない。足を正しく動かそうとすると手が動かなくなり、手を正しく動かそうとすると足が動かなくなる。そして、手と足が連動して動いてしまう。例えば歩くように右足と左手、左足と右手を交互にあげていく動きは、右足と右手が同時にあがるナンバ歩きのような動きになってしまう。

BPMが早いと拍子に体がついていかない。全力で無理やり体を動かしてもまだ拍子が速すぎるように感じ、それでも無理やり体を動かそうとすると、途中の動きを1拍飛ばしてしまい、拍子を追い越してしまう。

すでに練習した動作が出てきた場合は、少しはマシに動くことができるので、結局どこでもでてくるような有名な動作は一通り練習して慣れるしかないのだろう。

柔軟は一向によくならない。昔からあぐらをかけないほど股関節が硬かったが、毎日柔軟しても全く変らない。また肩の関節も硬いので、背中で手を組むことができない。しかし、よくわからないことに前屈はできる。なぜここまで体が硬いのに前屈だけはできるのかがよくわからない。

ここ数年は習慣的に運動していたことも幸いして、連日でダンススクールに行けるほどの体力はある。ただし、一週間ほど連日でレッスンを受けると、関節が痛むので、休まなければならない。連日レッスンを受けると、筋肉は問題ないが、関節が限界になるようだ。関節は一度痛めてしまうと回復に時間がかかる。ボルダリングも週に何度もしたいのだが、関節に負荷がかかるために、今は週1にとどめている。

自分の体について考える時、常に体質について意識させられる。どうも自分の体は筋肥大しやすい体であるようだ。単関節の単純な筋トレは自分でも驚くほど短期的に向上するし、見た目にわかるほど筋肥大する。問題は、運動神経が伴っていないということだ。昔から多関節を使う複雑な運動が苦手だった。

筋肉とは名前の付けられた筋肉であっても、すべての筋繊維が一斉に動くわけではない。筋繊維が数十本、数百本と集まった運動単位で動く。筋力を出した質の高い運動をするには、単に筋肥大をするだけではなく、多くの運動単位を一斉に動かす必要がある。そして多関節の運動では、適切な運動単位の一連の動きが必要になる。どうも自分は俗に運動神経と呼ばれている筋肉の動かし方が下手なのではないかと思う。

ダンスのジャンルだが、ダンスを学びはじめる前は、非人間的な動きがしたいのでPOPに興味があった。今通っているダンススクールでもPOPのレッスンはあるのだが、まだあまりにも踊れないので特定のジャンルを銘打たないリズムトレーニングのレッスンしか受けていない。リズムトレーニングのルーチンの動きはだいたいとても簡単で基礎的なものばかりなのだが、一人だけ毎回LOCKでルーチンをするインストラクターがいる。結果的に今は特定のジャンルで言うとLOCKだけを少し練習した状態になっている。

ダンスを学ぶ前に各ジャンルのダンスの動画をひと通り見たのだが、LOCKは地味で良さがわからないという印象を持った。ところが、LOCKをわずかにかじった今、同じ動画を見返してみると、以前は地味に見えたはずのダンサーはとてつもない技量を持っていることがわかり、しかもかっこいいと感じるようになった。

どうもこれは私だけではないらしく、動画サイトで素晴らしいLOCKダンスにも、ダンス未経験者から「地味」とか「同じ動きを繰り返していて単調」みたいなコメントが付けられている。

というわけでダンスを学び始めて一ヶ月だったが、まだ踊れるレベルには達していない。向上が実感できる部分もあるが、まだ時間がかかりそうだ

さしあたってはダンスの経過観察のための動画撮影用にカメラを買いたいが、今の所他の運動でも使い回すことができるので、GoProを買おうと思っている。ただ、今年の秋頃に出るはずの次の製品を待つつもりだ。