たごもりすメモ

コードとかその他の話とか。

RubyKaigi 2017で広島に行ってきた&しゃべってきた

いやー、よかったですね。旅行としても楽しかったし、いいカンファレンスでしたね。

f:id:tagomoris:20170926132255j:plain

rubykaigi.org

自分が出したTalk proposalも通ったことだし、わいわいと広島まで行ってきた。非常によくオーガナイズされて会場では快適に面白い話ばかりえんえん聞けるし、そのへんにいる人達といろんな議論をしていろいろ良いことがあった。すばらしいカンファレンスでした。主催者ならびに運営協力のかたがた、ありがとうございました。前日から最終日まで、夜のパーティーも切れ目なくたくさんあってすごかった。

しゃべってきた

f:id:tagomoris:20170926132812j:plain
(photo by @koichiroo)

自分のトークのスライドはこちら。

動画ももう上がってた、すごい。内容で聞きたければこちらをどうぞ。YoutubeのサムネイルはなぜかDukeがデカデカと映っていますが、これは何かの間違いです。ちゃんとRubyKaigiのトークです。だ、だいじょうぶ……。

内容としては最近仕事でやっているプロジェクトにからめて、その仕事でのRubyの使い方と、ついでにRubyで分散ストレージシステム(のクローン)を書いてみたんだけどそこで感じたRubyに足りない機能、みたいなのをあれこれ話した。
使われかたがやっぱりWebに偏っているせいか、いざストレージミドルウェアを書いてみようとするとあれこれ面倒な書き方をしないといけない部分が多くて、これはもうちょっと言語機能としてどうにかしてほしい、みたいなのをあれこれ挙げたつもり。このへんが良くなるとTreasure DataとしてはRubyで書ける部分がさらに増えてすごく助かる。

で、ちょうどRubyコミッタの人達が周囲にゴロゴロしているので、これ幸いとそのあたりの機能のアイデアについてどう思うか聞いたりしてた。TDにもRubyコミッタは(何人も)いるが、どうしても同僚だとユースケースをよくわかっている分、意見に偏りが出る気はする……ので、外部のコミッタとあれこれ議論できる機会はすごく大事だと思う。
結果的にあれこれチケット登録したりパッチ書いたりしつつ、その内容を議論の結果をフィードバックさせてアップデートさせたりできてすごくよかった。

以下が自分が関わってて、Kaigi中に報告したり作成したり(過去に報告してて)コミットされて修正が完了したチケットとpull requestのリスト

ということで、RubyKaigi中とその前後だけでRuby trunkがだいぶミドルウェア書きやすい言語に向かって進んでいる。自分にとってはすばらしい会期だった。Yay!

行ってきた

参加者側としては、自分のトークが3日目だったのもあったし、周囲の人と話すのを優先していたといえばそう、なので、各トークは聞いたり聞かなかったり。しかし今年はとにかく型の話が多くて、自分も上記リストに含まれてる通りちょっと興味のあるトピックだったから、面白く聞いていた。
全体的にコードの話が多くて、というかコードの話しかなくて、いいなあと思う。ふらっと入ると面白い内容の話をしてるもんね。あとLTで @joker1007 さんと @k0kubun さんが勢いのある変態コードの話をしてて最高。その話、ふつうにメインのトークにproposal出そうよとは思うけど。w

ということで、おおむねふらふらとしつつ楽しんでいた。

で、まあお昼ごはんとかね、当然広島だからお好み焼きも食べるし、汁なし担々麺が名物らしいと聞いたらそれも食べるし。おいしかった。

f:id:tagomoris:20170926134140j:plain

夜はパーティーがあるとはいえ、当然その後もよさそうな店を見付けて飲みに行くわけじゃないですか。なんか*1異常に安いし、すごいおいしいんですよ。天国。

f:id:tagomoris:20170926123733j:plain

特にこの松茸と鱧の土瓶蒸しがもう大変にけしからん味で、この汁だけで日本酒がいくらでも飲める。けしからん。最高。最高でした。

f:id:tagomoris:20170917221142j:plain

Kaigi後の観光

せっかく広島まで行ったので、1日帰りを遅らせて2日間つくってちょっと観光してきた。広島城とか宮島とか呉とか。広島城はコンクリ城だけど、まあ、まあ。どっちかというと平城のくせに堀のあたりに風情あってよかった。

f:id:tagomoris:20170926134227j:plain

宮島は厳島神社*2修学旅行で行ったのでほどほどにして、裏にある弥山をガッと登った。思ってたよりハードだったけど、なんとか。こちらも巨大な岩の下をくぐって山頂に到達するなど、独特の趣があってよい。

f:id:tagomoris:20170926131708j:plain

呉は雨が降ってたので、資料館をぶらぶらするのを中心に。街中の空中に突然潜水艦が登場するのとか、東京ではちょっとありえない趣がいいねえ。海上自衛隊の資料館をぶらぶらしたり、大和ミュージアムを回ったり、埠頭の展望台から馬鹿デカいコンテナ船が整備中(?)だったり建造中だったりするのを眺めて一人で盛り上がったり。いやー、港の街はいいなー。

f:id:tagomoris:20170926131720j:plain

で、観光したらおなかが減るじゃん?

f:id:tagomoris:20170926131729j:plain

もうね。

f:id:tagomoris:20170926131743j:plain

来年の仙台も楽しみですね!!!

*1:東京と較べると

*2:小学校の頃だけど……

Stream Processing Casual Talks 2 にいってきた & しゃべってきた

開催されたので参加してきた。
ついでにちょっと前に社内でのやりとりで思い付いてそのまま温めてたアイデアがあったので形にしてしゃべってみた。

connpass.com

しゃべってきた

社内でしゃべってたのは、ストリーム処理クエリって結局自分がもってるデータしか参照できなくて、じゃあ3年前のデータとJOINしたかったらクエリを3年走らせつづけないといけないの? 無理じゃね? みたいなあたり。過去データを参照したいケースは(特にビジネス要件のクエリで)普通に存在するいっぽう、現行のストリーム処理エンジンはクエリを開始した時点から受け取ったデータそのものしか参照できない*1

んで、いやよく考えたら過去データからストリーム処理クエリの計算中の状態を再現できれば、クエリ開始時に3年前からのデータをどこかからもってきて処理を起動できる、ストリーム処理系の脇にあるバッチ処理系を前提にしてこれができたらどんな過去データを扱うストリーム処理クエリも書き放題で、しかも好きなタイミングで再起動できるじゃん!!!! すげえ!!!! みたいなアイデアがある。SQLならできる。

これはいろいろ制約があって汎用の分散処理エンジンではなかなか難しかったりするのと、そもそもストリーム処理系とバッチ処理系で同じデータと同じ処理を前提に……これはラムダアーキテクチャというやつだ! ということでがーっとアイデアをまとめた。このアイデアの副産物として、同じ処理を内包する複数のストリーム処理クエリがオペレータ(とその内部状態)を共有できるというメリットもおまけについてきて、これが実現できればさらに基盤全体のスケーラビリティが上昇する。これはきた!!!!

まあ、分散処理版のNorikra(通称Perfect Norikra)はまだ1バイトも存在しないんだけど。スライド最後にちょっと書いたが、実は名前は既に決まっている。英語で普通の単語に聞こえ、かつユニークネスがある程度ありそうな単語を探すのは骨なので、プロダクト名が既にあるということはプロダクトを書き始めるまでの最大の問題が解決しているということだ。すばらしい。

いってきた

NiFiねー、とか、Hortonworks Streaming Analytics ManagerはUIよくできてんなー、とか。しかし全体としては面白技術という感じでもなくなって、みんな細かい改善がんばってんなあ、という気分。Apache Beamに乗るのはこれだから嫌なんだという感じがする。
ともあれ最近リサーチもサボってるので界隈の話題をひとさらいできてよかった。

*1:もちろんコードを何でも書ける処理エンジンであれば独自に外部データを参照してそれとJOINすることはできる、が、それはストリーム処理クエリがサポートしているとは言えないと思う。何でも書けるコードの中で勝手にやっているだけで、つまりそれはクエリ処理エンジンが分散をよろしくやれる範囲の外ということ。

System.nanoTime() をJMockitで乗っ取る

Javaミドルウェアなど書いていると必然的に内部でタイマーを作ったりすることになってその制御に System.nanoTime() とかを使うことになると思うんだけど、じゃあテストどうしよっかと思うと、テストでは、まあ好きなタイミングで時間を進めたり好きなところで時間を止めたりってことが普通したいじゃないですか。どうすんのという話。

JMockitを使う

とりあえずJMockitを使っとけという話っぽい。static methodをモックできるのはこれしかない*1

JMockitは理想的なモックフレームワーク - じゅんいち☆かとうの技術日誌

ちょいちょい調べると例が見付かるので真似る。

import org.junit.Test;
import static org.hamcrest.Matchers.is;
import static org.junit.Assert.*;

import mockit.Expectations;
import mockit.Mocked;

public class FooTest
{
    @Test
    public void testTimer(@Mocked System unused)
    {
        long current = System.nanoTime();
        new Expectations() {{
            System.nanoTime(); result = current;
        }};
        assertThat(System.nanoTime(), is(current));
    }
}

JUnit4に怒られる

コンパイル通ったぜー、と思うとなんかテストでコケる。

java.lang.Exception: Method testTimer should have no parameters

調べてみたらこんなのが見付かった。要はJUnitよりも前にJMockitを書いておけと。えー、と思いながらとりあえず build.gradle を変更してみた。

dependencies {
    // jmockit should be written before junit
    // http://robertmarkbramprogrammer.blogspot.jp/2013/03/eclipse-and-jmockit-method-should-have.html
    testCompile group: 'org.jmockit', name: 'jmockit', version: '1.33'
    testCompile group: 'junit', name: 'junit', version: '4.11'
    testCompile group: 'org.hamcrest', name: 'hamcrest-all', version: '1.3'

    // ...
}

そしたら期待通り動いてしまった。えー。ジャバむずかしいな。

(追記) なんか期待通りに動かない

複数のテストケースでそれぞれ違う値でモックしようとしたら結果がおかしくなる……みたいなのが多発してこれはやばいということになった。調べるとJITが走ったらダメになるみたいな話もあるし、ここで苦労するべきではないと判断。撤退。

*1:今でもそうなのかな? まあ、たぶんそう

okhttpで非同期リクエストを実行するとき実行スレッドはどうなっているのか

複数のホストに並行してHTTPリクエストを送るコードをJavaで書く必要があって、Undertowをサーバに使ってるんでUndertowの http client でもいいかなーと思ってたんだけど、okhttpにも非同期リクエストの機能があるみたい。

ただパッと見て実行スレッド数の設定とかどうなっとるんや、というのが全くわかんなかったのでちょっとコードを追ってみたところ、以下のような感じのコードを発見しました。
呼び出し順としてはの以下ような感じ。

  • OkHttpClient.newCall(Request req)
  • Call.enqueue(Callback callback)
  • RealCall.enqueue(Callback callback)
  • client.dispatcher().enqueue(new AsyncCall(responseCallback)); ココ

なんで、この dispatcher() で返ってくるやつの正体を見ればどう制御してるかわかるだろ、って追ってみたらこんな。

https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/Dispatcher.java#L63

  public synchronized ExecutorService executorService() {
    if (executorService == null) {
      executorService = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60, TimeUnit.SECONDS,
          new SynchronousQueue<Runnable>(), Util.threadFactory("OkHttp Dispatcher", false));
    }
    return executorService;
  https://github.com/square/okhttp/blob/master/okhttp/src/main/java/okhttp3/Dispatcher.java#L63}

ThreadPoolExecutorの引数は corePoolSize, maximumPoolSize, ... なので、なんかもう無限に(ではないけど)スレッド作る感じですね! 気合いが入っている!!

で、これはねーなと思いかけたんだけどちょい上のほうを見ると Dispatcher(ExecutorService executorService) というコンストラクタがあるので、外で設定済みのexecutorServiceを渡してDispatcherを作り、それを OkHttpClient.Builder.dispatcher() に渡して build() すれば設定済みクライアントが作れそう。
ちょっとめんどいな。

EmacsでJava開発をする @ 2017

お仕事でそれなりにまとまったJavaのコードを書くので、ちょっと真面目に手元の環境をアップデートしようと思ったらいろいろあったので、メモを兼ねてまとめる。なお手元の環境のアップデートにともない、次のエントリを大きく参考にさせていただきました。多謝。
qiita.com

なおそれまでの環境は EmacsでJavaを書く - nekop's blog を元にだいぶ前に整備したもので malabar-mode をずっと使ってたんだけど、Java8 Lambdaでインデントが崩れるとかいろいろあってちょっとストレスフルだったのが主なアップデート動機。

環境は OS X El Capitan *1 + Emacs 25.2 で、全面的に MELPA をつかってパッケージ管理やっている。

結論

最終的には ENSIME (の ENJINEモード) を使っている。これでコンパイルエラーを出すとかメソッド名を補完するだとかのエディタ上で最低限欲しい機能はだいたい揃った。ちょいちょい動かない機能とかEmacsを巻き込んでクラッシュする機能とかがあるけど、自分は元々エディタ上で操作を完結させたいとか思わない*2ので、まあこれくらいでいいやと。

その上でコードの自動フォーマットをチーム内で揃えるため、別途コマンドラインツールと git pre-commit hook の組み合わせで自動フォーマッタをかませることにしようとしている。これに使えるものもいろいろ考えたけど、IntelliJ IDEAにコードフォーマッタがあることを知ったのでこれを使うことにした。IntelliJ IDEAはエディタとしては使いたくないけど、コマンドライン起動するためにインストールするくらいはなんでもないぞ。

#!/bin/sh

CURRENT_DIR=$(pwd)
SETTING=$CURRENT_DIR/misc/airlift-codestyle.xml
FORMATTER="/Applications/IntelliJ IDEA CE.app/Contents/bin/format.sh"

exec 1>&2

# .java files to be committed
files=$(git status --short | grep -E '^[AM] .*\.java$'| cut -c4- | sed -e "s|^|$CURRENT_DIR/|")
echo "$files" | xargs "$FORMATTER" -s $SETTING
echo "$files" | xargs git add

こんな感じのスクリプトを書いて pre-commit hook として使う。設定ファイルを与えられるんだけど、ここではPrestoとかでも使われてるAirliftの設定ファイルを与えることにしている。なぜか。まあ自分にとってもこのスタイルはそんなに悪くない。あんまり主張が強くないし。

問題はあって、なにしろ(Javaのコードを含んだ)commitのたびに裏側で IntelliJ IDEA を起動するので、遅い。あとなんかログとか警告とかも流れてきてちょっと邪魔い。けどcommitの頻度自体そんな高いもんじゃないし、まあいいかなと思っている。好きなエディタ使えるほうが大事。

ENSIMEの環境設定

正直、これはだいぶ大変だった。が、たぶん最適解が分かってればすぐ終わるんじゃないかなという気がする……。たぶん。基本的には Installation · ENSIME に従えばよい。あとプロジェクトが gradle を使っているので Gradle · ENSIME も。

が、いろいろ試したところうまく動かない組合せが多く、唯一動作したのは ENSIME 0.2.8 (stable) と gradle 3.3 の組合せだけだった。unstable (0.3.0-SNAPSHOT) を使うケースだと gradle 3.5 ではバグってて動かず gradle 3.4 では動くように見えるんだけど、Emacs側で melpa から unstable 版を入れて読み込もうとすると .ensime の形式がおかしいとか言われて動かない。
stable版はどうかと ENSIME 0.2.8 を使おうとしたら gradle 2.4+ との組み合わせだとバグってて動かないので gradle 3.3 までダウングレードしたら動いた。これを melpa-stable 経由でインストールした ENSIME 0.2.8 と組合せるとなんとか全体が動作するようになった。

今のところはバッファ開くたびに M-x ensime して有効にしている。しかしなんか同じプロジェクトのクラスを見付けてくれないことがあったり、build.gradleに設定してある依存ライブラリを見付けてくれないことがあるように見える。なんだかなー。まあ、自分にとってはそこまで致命的ではない。

Meghanada

他の選択肢は? というと、いくつか試してはいる。最初に試したのは Meghanada-Mode で、実際にこれはすばらしくセットアップが楽だった。が、最初に試したときは meghanada-mode を有効にしたあとで C-i したらEmacsごと固まる、という状況で、ちょっとこれは……という感じでいったんやめた。
その後に init.el の大掃除をしたあとでもう一度試してみたら動くには動いたんだけど、機能によってはやっぱり何のデバッグメッセージも無しに固まる症状がちょいちょい見られたりして、きびしい。あと手元ではコンパイル時警告が出てる場所の色付けみたいなのも動いてなかったので、機能として無いのか単に何かがおかしくて動いてないのかは知らないが、あまり便利とは言いがたい状態だったのでいったん使用をやめた。

何しろインストールが楽なので、使えれば使いたいんだけどなー、という状況でした。コードの自動フォーマット機能があるのはすばらしいけど、フォーマッタをどうにかして設定できないかなあ、という気もする。
今後に期待。

Google-java-format

エディタはどうにかするとしてコマンドラインフォーマッタはどうか、と思って見付けたのが google-java-format なんだけど、デフォルトのコーディングスタイルがちょっとアレすぎて使うにはアレ……。2スペとか。

なお --aosp というオプションが最近のバージョンで足されてて、これはどうも Android Open Source Projects 用らしいぞ、ということで試してみたら4スペだし、これはこれでいいかなと思いかけたんだけど、やっぱりちょっとクセが強い感じがした。主張つよくバリバリ修正されるんだけど、改行をやたらアグレッシブに入れるし、その割にここ改行しないんだ? みたいな納得いかない部分がちょいちょいあるし、lambda使ったときにインデントがやたら深くなる傾向があるし、ということで、きびしい。
途中まで使いかけたんだけど IntelliJ IDEA のフォーマッタを見付けたのでそっちに行った。

まとめ

がんばるしかないがちょっとつらい。

(5/29追記)

前のスクリプトだと modified だけど add されてないファイルまでpre-commit hookがgit addしちゃってたのでちょっと直した。

*1:まだSierraにしてない、したくないよう

*2:ビルドもテスト実行もコンソールに戻ってやっている

「そのデータ分析基盤、作るか? 使うか?」という話をしてきた

ファンコミュニケーションズさんが自社オフィスで勉強会をはじめるということで、第1回でしゃべりませんかというお誘いを受けたので参加してきた。お誘いありがとうございました!

eventdots.jp

内容はどうしようかなと思ったんだけど、相談してみたら過去のこのエントリのスタートアップ限定じゃない話とかどうかというものがあり、自分でも面白そうだったので、そんな感じで内容をまとめてみた。

まあトピックと自分の現在の勤務先からしてどうしても内容にバイアスがかかると思われるのはしょうがない……ので割り切った宣伝スライドはまあ1枚入れるとして、それ以外はいちおう公平な議論を目指したつもり。
で、中にも書いてあるけど、明確な結論なんてものはなくて、各社個別の事情にあわせてやりましょう。ただしこのくらいはどうせやらないといけないから、作りだす前に考えといた方がいいですよ、という内容になっている。まあ、やっぱり大変なので大きな企業で数十人単位のチームを作ってやってるところが多いですよねー、という。
やらないといけないことのバリエーション(==complexity)は企業の大小によらないので、どうしてもあまりエンジニアリングチームの大きくない会社だと難しいんじゃないかなとは思います。

とまあ、そんな感じのことをしゃべったり、DokkuやAkkaの話を聞いたり、あとは参加者の人のデータ分析関連のお悩みを聞かせてもらったりで、楽しいイベントでした。

プログラミングを始める動機はどこにあるのか、の話

あるいは「高校生からはじめるプログラミング」の話。

こちらの本をKADOKAWA様からいただきました。ありがとうございます。なぜ自分に……*1などと思わなくもなかったけど、ありがたく眺めさせていただきました。今となってはこういうガチ初心者向けの教本を眺める機会なんて皆無だしなあ。
SAOのコンテンツ力が表紙/裏表紙と章立てのページに発揮されてるけど、他のページはごく普通のプログラミング教本で、特に中身との連携はなかった。これで売上とか変わるのかな。変わりそうだなあ。

で、ざらっと眺めたあと、タイミングよくプログラミングを始める動機ってなんなんだろうな、と思ったので、それに絡めて書く。

本の中身

最近のプログラミングの導入ってそもそも何をやるの、みたいなのがぜんぜん分かってなかったので、ちょっと新鮮だった。思えば技術要素を特定しない「プログラミング入門」の本というのは人生で初めて読んだかもしれん。
章立てとしては以下のような感じ。

  1. 環境設定とHTMLの基本 (Chrome, VS Code)
  2. JavaScriptの初歩
  3. CSS
  4. JavaScriptによるアプリケーション作成

アプリケーションといってもWebブラウザ上で動く簡単なスクリプトで、要するにすべてがブラウザ上で完結する範囲。読みはじめるまでから読んでる途中でも、これどこまでやるんだろう、というのが分からないまま進んでたんだけど(なにしろ表紙に「N高校のプログラミング教育メソッド」と書いてある)、あとがきに書いてあった。最初の4月から6月のうちにやる部分だそうで。

まあ言ってしまえば本当に初歩の初歩なので、プログラミングというものを全く知らない人がこれに沿って体験してみる分にはいいんじゃないかと思う。演習問題も細かい単位で用意してあって、それも良さそう……たぶん。

プログラミングを始めたい人

ところでこの本を眺めててずっと不思議だったんだけど、これを読む人はどういう人なのだろう? ということ。つまり、対象のよくわからない「プログラミング」とは、誰がやりたいものなんだろう。
もちろんこの本もオビに「Webプログラミングの基本が身につく」と書いてあって、そうかWebプログラミングかと思いながら開いたんだけど、内容には(自分が無意識に期待していた)Webアプリケーションのサーバサイドのコードは登場しなかった*2
まあそりゃそうか、環境構築とかも大変だからな、とは思うものの、つまり何を学ぶかがわかっていない人がとりあえず開く本として作られている、ということで、そういう本を誰が選ぶの? ということ。

N高校のプログラミングコースの生徒か。そりゃそうだ。

で、じゃあそもそもなんでその人はプログラミングがしたいの? それがわからない……のは、自分にそういう経験がないからなんだけど。

ところで、将来に何をやりたいかという希望が全く無い人に、プログラマはいい職業ですか? と聞かれたら、自分はいい職業だと答えると思う。今の時代、「普通の」プログラマでもあちこち足りてないからまともな勉強をすればまともな給料が(たぶん)もらえるし、職にあぶれることもまだしばらくは無いし、もし向いていて能力を発揮できるならいい待遇もゲットできるから。
あと、たぶん他の高給取りの職業と較べて人生におけるストレスはわりあい低いんじゃないかなとも思うし。

つまり、そういう話を聞いた人がプログラマになるための第一歩としてこの本を読むのかなあ。そうなんだろうなあ。

なにかを作りたい人

プログラマになりたい人」のことが自分にとってよくわからないのは、たぶん、そう思ったことが自分にはなくて、そもそもやりたいことが目の前にあって、そのための明らかな道具としてプログラミングという手段があったから、しょうがない勉強するか、という経験しかしたことがないからだと思う。そういう人は世の中にけっこう多いんじゃないかなあ。
なんか黒い画面に線が引けるのが面白かったからN88BASICをやったし、Windowsであれこれデータを処理するアプリケーションが作りたかったからVisual Basicやったし、ゲーム作りたかったからC++をやったし、という感じ。そのうちプログラミングをしてるのが割と自然になっちゃって、そのまま仕事に選んだから、仕事を片付けるために、その仕事に対して適切な言語と技術スタックを学んでやっつける、というのを繰り返して今に至ってしまった。

個人的には、プログラミングは作りたいものがあるという状態で、そのための手段としてプログラミングをやる、というのがいちばん効率がいいんじゃないかと思う。技術を学ぶなら目的意識がはっきりした方が問題を発見しやすいし、難しいところでつまづいた時に、それを突破する意欲が湧くから。
とか、ぼんやり考えてたら、今日こんなエントリがTLに流れてきた。

プログラミングが出来れば自分の欲しいソフト作れるからなー。

今あるソフトを弄る事だって出来るし。

たとえば今だとマストドンのクライアント次々に生まれてるじゃん?

プログラミング出来ないと人が作ってくれたものをただ使うしかないんだよね。

でもそれだと自分がピンポイントで欲しいものが無かったり、セキュリティ的に難があったりする。

あープログラミング出来る様になりたかったー。

プログラマーになればよかったー

やればいいのに! 今すぐ始めろ! 作りたいものがあるなら作れ! それはプログラマにとって一番大事なものだぞ!

動機と技術と時間の話

結局のところ、適切な時に適切な方向と量の動機を持てるかどうか、という話なんだろうなという気がする。
働いているときに、それと全く別の趣味としてプログラミングが始められるか、それだけの時間と気分の余裕を持てるかどうかというと、多くの人には難しいかもしれない。大学生ならどうか、高校生ならどうか、中学生なら……と考えてみても、それぞれ人に個別の事情があるだろうから、単純な時期の問題でもないと思う。

だから、目的に特化していない「プログラミング」一般として高校生の頃にやっておくのは、そう考えると、悪いことではないんだろうなと思う。自分だって働きはじめてから必要になった数学やら英語やらの能力については、それこそ高校生の頃にやっておいた下地があるからなんとかなってるわけで、考えると基礎教養というものはそういうものだ。何かをやりたくなって、それがある技術や知識を必要とするときに、しかしその技術や知識をゼロからやり直す時間がその瞬間にあるとは限らない。
将来に作りたくなったものができたとき躊躇せずに実際の作業に飛び込んでいくために、時間がある段階でやれることをやっておく。そういう話なのかなと思うと納得できる。

なんかボヤけた感想だけど、そんなことをあれこれ考えてた。

余談

完全に余計な話だけど「高校生からはじめるプログラミング」というタイトル、これは早いうちから始めるぞ! というニュアンスでつけたんだろうか。
いろいろ話を聞いていると*3小学生の頃にはなんらかのコード片を書いていた、という人もそんなに珍しくはないので、人によって受け取りかたが変わるタイトルだなあという気がする。

*1:まさかSAO関連のtweetが見られていたのだろうか

*2:あとがきによるとN高校では7月以降でやるようだ

*3:もちろんいろんな人がいるんだけど