Webシステムを開発していると、ローカルで開発中のサイトに外部からアクセスして確認したいという必要が良くでてきます。スマホ向けのレイアウトを確認したいとき、位置情報を使ったサービスなどの場合は、スマホからhttpsでアクセスして確認する必要があります。（iPhoneのSafariからだとhttpsでないと位置情報へのアクセスが許されないので）

このような場合、今まではngrokという便利ツールを使っていたのだが、無料プランの場合、生成される外部からアクセス可能なアドレスが毎回違ったり、一秒間に許されるアクセスに制限がかかっていたりしてちょっと不便でした。

ngrokに代わってServeroというツールがこれらの欠点がなくて便利だ、という記事をQiitaなどで見かけたのだが、数日前からアクセスできなくなっていました。

そこで、これらに代わるサービスや方法がないかと探していたら、

» Ngrok? You Might Not Need It

などの記事で、何のことはないsshのポートフォワーディングの機能を使えば同等のことが、追加で何かをインストールする必要なくできることを知りました。

ただ、sshのポートフォワーディングだけでは、httpの通信はできるが、httpsの通信を転送できなくて困っていました。いろいろ試行錯誤してみた結果、golang製のCaddyというWebサーバーを使えば簡単にできることがわかったので、その方法を紹介します。

前提

自由にアクセスできるサーバーと独自ドメインを持っていることが前提です。開発者であれば、VPSサーバーの1台や2台、独自ドメインもいくつか持っているんじゃないでしょうか。

もし持っていなければ、Digital Oceanあたりで月額5ドルから借りられます。

ドメインももし持っていなければ、Google Domainsで.devドメインでも取っておきましょう。

sshポートフォワーディング

借りているサーバーにはssh接続できるものとします。

ローカルの3000番ポートで動かしているサービス(http://localhost:3000)に接続したいとして、

ssh -R 3001:localhost:3000 yourdomain.com

をターミナルから実行するだけで、iPhoneなどから

http://yourdomain.com:3001

でアクセスできるようになります。

sshのコマンドの意味は、-Rがリバースプロキシを意味し、次の

3001:localhost:3000

は、続くドメインの3001番ポートに来たアクセスをlocalhost:3000に転送するという意味です。

3000:localhost:3000

とすれば、ポートを合わせることもできるのですが、わかりやすく番号を変えておきました。

これだけでいままでngrokでおこなっていたことができ、しかもアクセス数に制限がなく、またドメインも変わらなくて便利なのですが、https通信をフォワードできないのがいまいちです。

次にcaddyを使ってhttpsを転送する方法を紹介します。

caddyとあわせて使ってhttpsをフォワーディング

借りているサーバーにcaddyをインストールします。

DownloadかLatest releaseのページよりOSにあったビルドをダウンロードしてください。

筆者の場合はUbuntu 64bitなので、caddy_v1.0.3_linux_amd64.tar.gzをダウンロードし、

% mkdir caddy
% cd caddy
% wget https://github.com/caddyserver/caddy/releases/download/v1.0.3/caddy_v1.0.3_linux_amd64.tar.gz
% tar xvf caddy_v1.0.3_linux_amd64.tar.gz

で解凍します。 同じフォルダに以下の内容でCaddyfileを作成します。yourdomain.comには借りているサーバーに向いている自分のドメインに替えてください。

yourdomain.com

proxy / 127.0.0.1:8080 {
  transparent
}

proxy /tunnel 127.0.0.1:8080 {
  transparent
  websocket
}

同じフォルダで、

./caddy

を実行すると、caddyが起動します。caddyは動的に証明書を取得する仕組みがあるため、これだけの設定でhttps接続が可能です。

ブラウザで

https://yourdomain.com

にアクセスしてみましょう。

Caddyfileの設定によると、httpsへのアクセスは8080にプロキシされるのですが、8080には何もサービスがないため、

502 Bad Gateway

と表示されるはずです。

ここで、ローカルマシン上で、

ssh -R 8080:localhost:3000 yourdomain.com

を実行すると、yourdomain.comの8080ポートへのアクセスがlocalhostの3000番にフォワードされるので、

https://yourdomain.com

でlocalhost:3000にアクセスできるようになります。

まとめ

sshポートフォワーディングとcaddyを使い、ngrokやserveoなしでローカルで開発しているサイトに外部からhttpsでアクセスできるようになりました。

途中までは、これどうなんだろう？と思ってたしなかなか読み進めなかったのですが、途中からは展開が加速、一気に読み終わりました。噂に違わず、とても面白かった。いやあ、基礎研究って大事だなあ、と思いました :) （薄い感想ですみません）

読み終わって、何かまた新しいWebサービスとか作りたくなった。Twitterとかマストドン、iPhone の初期の頃に興奮したエンジニアの人にはおすすめ。それ以外の人には、うーむ、この面白さはわかるのだろうか。。

六本木ヒルズでこの夏休み開催されているMIRAI SUMMER CAMPのプログラムのひとつ、「機械学習×スクラッチで、どこにもないアプリを作ろう （ダイジェストプログラム）」を見学してきた。

» 【追加開催！】機械学習×スクラッチで、どこにもないアプリを作ろう （ダイジェストプログラム）

青山学院大学 阿部和広先生によっておこなわれたこのワークショップの第一弾は、実は7月末におこなわれ、好評につき再度開かれるようになったとのことだ。開発したML2Scratchが使用されるということで、そのときに様子を見に行ったのだが、使い勝手がいまいちかつ自分がいつも使っているマシンよりスペックが劣るPCではかなり動作が不安定であることがわかったので、大幅に改良してリベンジで臨むことになった。

結論だけ最初に書くと、ワークショップのタイトル通り、どこにもないアプリをたくさん見ることができたし、機械学習を使ったアプリケーションをこどもたちが（アイデアを出し合うアイデアソンという形ではなく）実際に「手を動かして作る」というワークショップ自体、これまでほとんどおこなわれていない、どこにもないものだったと思う。

アイスブレイクはじゃんけんゲームを作るという内容。グーチョキパーの写真を撮り、それらを高速に切り替え、キーを離した時に表示された手で勝負する。表示する写真に自分の手を使ってはいけないというルールなので、グループ内の他の子にお願いする必要があり、またカメラに慣れるという意味もある。

続いてグーチョキパーを人はどうやって見分けているかという問いかけから、画像を認識するプログラムをScratchでどうやって組むかを考える。Scratchには色を見分けるブロックがあるので、ネコが触れている背景が茶色か白かによって、ステージが野球場なのかバスケのコートなのかを識別することができる。

しかしこの方法だと、別のバスケットボールのコートの背景が追加されると、if文を都度追加しないといけない。いろんな見た目の野球場あるいはコートの画像に対応するには、if文がものすごーく長いプログラムになってしまう。あらゆる画像に対応するにはこの方法だとちょっと無理そうだな、と薄々気づくようになる。

次に「学習ってどういうこと？」についてグループ内で考え、意見をpost itに書き出したあと、発表する。「新しいことを見つける」「情報を覚える」「楽しかったりいやだったりする」など様々な意見が出ていた。

このあと休憩。休憩中は、会場で展示されていたScratchの拡張機能からもプログラミングできるロボットtoioや、 USB接続なしでもScratch3.0からスイッチ制御ができるTFabWorksのカシワニキットをこどもたちは体験していた。

休憩後は、いよいよ機械学習をScratchから利用できるようにしたML2Scratchを使ってオリジナルの機械学習アプリを作る自由制作タイム。

ML2Scratchはウェブカメラで撮った写真数枚をラベル付けすることで、機械がそれを学習および認識するようになり、認識結果を簡単にScratchで利用できるようにしたもの。たとえば、ジャンケンのグーの写真を数枚撮り1とラベル付けし、パーを2、チョキを3とラベル付けすれば、その後に改めてチョキをカメラに見せると3と判定してくれる。

参考にするための機械学習を使ったアプリケーションの実例として、パンの種類を判別して瞬時に会計をおこなえるレジと、キュウリの形や色から等級を自動判別するアプリケーションが紹介された。

紙コップや毛糸、紙皿など様々な素材を利用して、各グループ思い思いの機械学習アプリを作っていく。

右や左という文字、あるいは矢印が描かれた札をカメラに見せることによってキャラクターを操作するゲームや、

お弁当箱に盛られたお米の量を判定するアプリや、お皿に乗せられた素材からおすすめのメニューを表示してくれるもの、

症状に関する質問票をみせることで、風邪かどうかなど診断結果を表示する自動診断アプリ、キャラクターが描かれた紙コップで操作するゲームなどなど、オリジナリティあふれる作品の数々が、最後の発表の時間で披露された。

背景など含めカメラに映ったすべてから機械は学習するので、十数枚の写真をラベル付けするだけで学習ができるとはいっても、一筋縄ではいかないということを実際に手を動かすことで実感できる。

しかし、中には、背景など余計な情報が映り込まないように画用紙で小さなスタジオを用意したり、実際の顔の表情を判別することは少ない学習データでは難しいので、代わりに顔の表情のイラストを使うことで、判別の精度を挙げている例もあった。

最初からついたてなどを用意し、背景を消せばもっと認識率が高くなるよとあらかじめ大人の知恵をさずけることもできるのだろうが、そうしたことに自分たちで気づくということも含め機械学習を理解するということなのであろう。とはいえ、認識率がままならなければ、せっかく作った作品がまともに動かず達成感が薄くなるので、そのあたりの「教えすぎない」さじ加減は難しい。

大げさでなくワークショップのタイトル通り、今までにないユニークな作品ばかりだった。Scratchをある程度触ったことがあるという参加者も何人かいたが、機械学習と組み合わせることでScratchあるいはコンピューターでできることの幅が大きく拡がることを少しでも実感できたのではないだろうか。

というよりかは、こんなアプリケーションがあったら便利だろうなというアイデアを、いままではプログラムできる範囲に一部削ぎ落としていたのが、機械学習を使うことでそれがある程度実装可能になったという言い方の方が正しいかもしれない。

機械学習 x Scratch の可能性を感じたとても楽しいワークショップでした。

ML2Scratch が動かなくなり、JavaScript コンソールをみてみたら、tfhub.dev に接続できていないよう。。

.dev は Google が新たに取得した開発者向けドメインなのだが、以前は正式なドメインではなかったため、puma-dev がローカルでの開発環境用に割り当てていた。

https://github.com/puma/puma-dev/issues/194

に、/etc/resolver/dev を削除すれば良い、という解決方法があったので、

cd /etc/resolver
mv dev _dev

ととりあえず、dev を _dev にリネームすることで、tfhub.dev に無事接続できるようになった。

自分であとから検索したときにヒットするようにメモ。

開発環境周りは進化していて、一昔前と比べて格段にわかりやすくつまづきにくくなったが、サーバー周り、環境構築は相変わらずしんどい。

Ruby をアップデートしようと、割と古い Ubuntu 上で、rbenv install を実行したら、

$ rbenv install 2.6.3
Downloading ruby-2.6.3.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/2.6/ruby-2.6.3.tar.bz2
error: failed to download ruby-2.6.3.tar.bz2

というエラーが発生。

ダウンロード先のファイルを curl で取得しようとすると、

curl: (35) SSL connect error

が発生しており、

» rbenv installに失敗する - Qiita

と同じ現象のようだった。curl を最新版に入れ替えれば良さそうだわかる。

Curl のページより最新版のソースをダウンロードしてきて、

./configure
make
sudo make install

でインストールできたのだが、 curl -vV を実行してみると、

Symbol lookup error undefined symbol: curl_mime_init

というエラーが出る。

バージョン表示のときに表示される curl のバージョンと libcurl のバージョンがあっていないのがどうも悪いらしいと、libcurl を入れ替えようとしてみたり悪戦苦闘したのだが、結局

» 【学習メモ】curl-7.59.0のインストール後はldconfigが必要

にあるとおり、

sudo ldconfig

を実行したら、動くようになった。

ldconfig とは、

» 【ldconfig】共有ライブラリの依存関係情報を更新する

にあるとおり、共有ライブラリの依存関係情報を更新する。

うーん、Unix 力がまだまだ足りない。。

[追記]

別の環境では、上記を実行しても、依然 curl: (35) error が出る。

curl -v -1 https://cache.ruby-lang.org/pub/ruby/2.6/ruby-2.6.3.tar.bz2
*   Trying 151.101.109.178...
* TCP_NODELAY set
* Connected to cache.ruby-lang.org (151.101.109.178) port 443 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.1 (OUT), TLS handshake, Client hello (1):
* TLSv1.1 (IN), TLS alert, protocol version (582):
* error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
* Closing connection 0
curl: (35) error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

sudo apt-get install libssl-dev

を実行して、libssl-dev を最新版にしたところ、接続できるようになった。

curl -v -1 https://cache.ruby-lang.org/pub/ruby/2.6/ruby-2.6.3.tar.bz2
*   Trying 151.101.109.178...
* TCP_NODELAY set
* Connected to cache.ruby-lang.org (151.101.109.178) port 443 (#0)
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Fastly, Inc.; CN=m.ssl.fastly.net
*  start date: Sep 24 16:42:11 2018 GMT
*  expire date: Sep  1 15:02:57 2019 GMT
*  subjectAltName: host "cache.ruby-lang.org" matched cert's "*.ruby-lang.org"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign CloudSSL CA - SHA256 - G3
*  SSL certificate verify ok.
> GET /pub/ruby/2.6/ruby-2.6.3.tar.bz2 HTTP/1.1
> Host: cache.ruby-lang.org
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< x-amz-id-2: CSxKQ4zF5+oGri/uccevgMVR6WPQQsMtjQhgaWhvt4hu92tB++BaSizfF22SF9KolfSE5GgTwA4=
< x-amz-request-id: B53E6653265B2E84
< Last-Modified: Wed, 17 Apr 2019 15:24:47 GMT
< ETag: "9a57b5fd806e5dc0b992a45d21e9c353-2"
< x-amz-version-id: rMhn0_W8iaiOyH_SaOIJVmfaw1UJa12b
< Content-Type: application/x-tar
< Server: AmazonS3
< Accept-Ranges: bytes
< Age: 4737479
< Content-Length: 14509165
< Accept-Ranges: bytes
< Date: Tue, 11 Jun 2019 14:24:42 GMT
< Via: 1.1 varnish
< Connection: keep-alive
< X-Served-By: cache-tyo19928-TYO
< X-Cache: HIT
< X-Cache-Hits: 0
< X-Timer: S1560263082.085898,VS0,VE7
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 2759)
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):

今年も Scratch Day in Tokyo 2019 が青山学院アスタジオで行われました。

いつもどおり担当することになった Show & Tell は、これまでの振り返りで出ていた問題点を概ね解決し、また多くの関係者皆さんの協力があって、これまでで最多の発表作品数であったにも関わらず、最もスムーズにほとんど問題なく進めることができたのではないかと思う。

2012年に参加したScratch@MITの、本家 Show & Tell でこどもたちが壇上で自分の作品をデモしているのを見て、東京でもやりたいと思い、2013年のScratch Dayで始めました。その頃は発表者が集まらず、自分の子どもたちにお願いして登壇してもらったりしていたほど。今回7回目を迎え、作品は過去最多の応募となり、これまで守ってきた応募者全員に発表してもらう、という方針を守るには、時間が足りませんでした。実行委員内で調整を進め、結果、終了時間を30分伸ばし、一部の方には展示にまわってもらい、一人あたりの持ち時間を3分におさえてもらうことで、何とか全作品に発表の機会を持ってもらうことができました。

Keep（来年も続けたいこと）

• 第1部MC御家さん、質問を会場の皆さんから聞くようにして、以降第3部までずっと続けたが、圧倒的に前席に座っている登壇者からポンポン質問が出てきて、日本の大人社会ではなかなか見られない光景で大変良かった。

• CoderDojo吉祥寺の山浦さん発案で登壇者用に名札を受付で配布したのだけど、出欠管理になるし、一目でわかるし、そして帰りには名札ケースは返してもらって中身は持って帰っていいんだよ、その名札は登壇者だけの特別なものだよ、と言ったらとても喜んでいたので凄く良いアイデアだった。

• 三部構成で普段の数名での運営は無理そうということで手伝ってくれる方を募集し、MCの御家さん、グッチ、サンダース、竹中さん、そのほか進行を手伝ってくださった皆さんのおかげで運営はスムーズだった。フォーラムでの募集に応えてくれた方々に当日呼びかけることができずごめんなさい。

Problem（問題点）

• 準備できるワイヤレスマイクが一本しかなかったのは大変だった。登壇者用にはマイクしたまま操作できるように、ヘッドセットタイプのマイクがあると良さそう。

• Scratch 3のオフライン版は結構バギーで、オンライン版と同じようには動かず登壇者にはせっかくの自慢機能が動かなかったりしてストレスだったよう。WiFiが一応使えたので全編オンラインでいきたかったが、途中通信状況が悪くなりオフラインにスイッチせざるをえなかった時が厳しかった。

Try（来年改善したいこと、やってみたいこと）

• 後から気づいたのだが、それぞれの部の全作品を、オンラインでつながっているうちに別タブで開いてしまっていれば、進行はかなりスムーズだったはず。

• 来年の予想応募作品は50近くと思っていて、これまでの方法ではShow&Tellが開催できない。主観で作品を選択するのはやりたくないので、今のところ一番有力なのは、先着順で30作品を採用し、残りは展示コーナーにまわってもらうか、当日自由発表エリアで自主発表してもらうというもの。

• ここ数回のShow&Tell登壇者は性別、年齢幅広く参加してもらっており素晴らしい限り。今回初めて、香港からの参加者が英語で発表してくださった。Scratchコミュニティ全体の英語ユーザー比率を考えると、Scratch Day in Tokyo はもっとインターナショナルなイベントであってもおかしくはないのにとは思う。

ScratchやCoderDojoのコミュニティに参加して僕が楽しいと思うのは、そこに若く新しい明るい未来を垣間見ることができるからだ。加えて様々な国籍の人が生活していて各国言語が入り乱れている未来を僕は想像するので、まずは手の届くScratchおよびCoderDojoのコミュニティを国際化していくことを個人的なTryとしていこうと思う。

[2019/05/14追記]

展示スペースのShow&Tell出展者ブースの方は、イベント中はほとんど立ち寄れず様子がわからなかったのだが、展示ブースの方をおもに見ていてくれた @togazo さんが振り返り記事にまとめてくれました。

» とが、Scratchのおまつりの手伝いをする

前編では、頒布物をオンラインコンテンツに決まるまでの経緯を書きました。後編では、コンテンツをどうやって制作していったか、そして、技術書典当日の振り返りを書いていきたいと思います。

コンテンツ自体は、かねてから構想していたというのもあって比較的順調に書き進めていくことができました。

お金をいただくコンテンツとそうでないブログなどにザッと書いたコンテンツの違いは、どれだけ第三者の目が入り校正がされているかだということは、これまでの商業誌や雑誌の記事執筆で感じていたことだったので、Kaori Han、uchiyama2000 にお願いしてレビューしてもらいました。おかげで、独りよがりではない、広く誰にでもわかってもらえる説明に改善されていきました。

当初は静的サイトで公開しようかと考えていて、Golang製のHugoなど検討したのですが、自分でカスタマイズしたくなったときのことを考えRuby製のJekyllに落ち着きました。

ところが、

• コンテンツを更新したときや、続編を書いたときに連絡できるよう読者のメールアドレスが欲しい。
• クーポンコードを入れると閲覧できる仕組みにしたい。
• コンテンツの一部は誰でも読めるように公開したい。
• ゆくゆくは英語版、中国版を用意したいので、言語切り替えが欲しい。
• 技術書典ではクーポンコードが印刷されたカードを販売すればよいが、いずれはクレジット決済に切り替えたい。
• コンテンツは Markdown で書きたいんだか、例えば Scratch プロジェクトの embed タグが簡単に書けるような独自拡張も欲しい。

などなど、やりたいことが増えてきて、これら全てを満たすCMSや、ASPサービスを見つけることができなかったので、システムをRuby on Railsで自作することにしました。

これを決意したのが技術書典2日前の金曜日夜でした。

また、その頃勉強していた Docker も使いたいなと思い、Docker コンテナ上で開発し、本番環境用のコンテナは DigitalOcean 月額5ドルのサーバー上に配置することにしました。

このブログシステムも Rails で自作しているのもあって、コードをあちこちから拝借して何とか当日の2:00頃にはコードを名刺シートに印刷するところまで完成し、ようやくロゴを作ってサークルカットをアップロードしたのが3:00頃。見た目を重視しないにもほどがある。

結局のところ、多くの方が本の装丁、デザインに情熱をかたむけるところを、僕の場合はシステムの方に傾けたかったということなんだと思います。時間との闘いでシステムを構築していくのは、1人開発合宿をしているようで、楽しかった。

さてさて、無事にシステムは出来上がり、技術書典の振り返りは以下の通りです。

Keep(次回も続けたいこと)

• 技術書典的には邪道か傍流かもしれませんが、新刊をオンラインコンテンツに絞ったのは正解でした。かかるコストは自分の人件費くらいなので、赤字になることはないですし、僕のように自作するという方法を選ばず、既存のCMSやASPサービスを使えばもっと手際よく用意できるはずです。お手軽に、とりあえず最初の一歩を踏むには最良の選択肢ではないでしょうか？
• とはいえ、オンラインコンテンツのみだと引きが弱い。今回一緒に頒布物として展示していた「Scratch で楽しく学ぶアート&サイエンス」を手にとってくれる方が多く、その内 Scratch を知ってそうな方には「Scratch 3を改造しよう」を薦めてみるということをしてみたのですが、まあまあうまくいったかと思います。

Problem(問題点)

• 一番の問題点は、ほぼ一人売り子体制だったため、ほとんどほかのサークルを見ることができなかったこと。とはいえレビューしてもらった uchiyama2000 には一緒に手伝ってもらい、とても助かったのですが、交代して一人で他を回ってくるのはなかなかに気が引けて、結局ほぼ飲まず食わずで、おじさんの身体には応えました。
• 装丁もそうですが、展示の仕方ももうちょっと工夫のしどころがありそうです。

Try(次回チャレンジしたいこと)

• 売り子としてだけで手伝ってくれる方をお願いするのはどうしても気がひけるので、誰か一緒にコンテンツを提供する側として参加することを募集したいです。機械学習関連で何か書きたいと言っている uchiyama2000 に期待。
• 隣のブースの方が、ポシェットがついた布をブースに敷いており、そのポシェットにおつりなど様々なものを入れることができていて凄い賢いなと思って聞いたら、「あの布」という名前で売っているらしいという情報をゲット。次回は絶対それを用意します。

さて、売り上げの方はというと、アート&サイエンスは、定価 2100円 + 消費税のところをおつり用意するのがめんどいということで 2000円で販売し、

2000円 x 16 = 32000円

オンラインコンテンツの「Scratch 3 を改造しよう」の方は、

500円 x 30 = 15000円

で合計 47000円でした。

利益で計算すると、アート&サイエンスの方は著者割りで仕入れているとは言え、値引きしているのでトントン。オンラインコンテンツの方は原価はかかっていないので、そのまま100パーセント利益です。

「アート & サイエンス」は、初版分はすでに印税をいただいているので売れても売れなくても変わりはないのですけど、印税8パーセントとして計算すると、

2100円 x 0.08 x 16 + 500円 x 30 = 17688円

でした。

これから英語版、中国語版を用意し、日本人ユーザーの100倍はいる全世界の Scratch ユーザーに向けて販売していこうと思うので期待大 :) です。

技術書典、結論としては参加してとても楽しかったので、次回も絶対出るつもりです！

技術書典6に初めて参加しました。アルバイトを含め、接客業をこれまでやったことがないので、何か物をお客さんに売るという経験は初めてでした。

Maker Faire などには参加したことがあるので、お隣の方には「慣れていますね」なんて言われましたが、でも、お金を受け取り、お釣りを渡して商品を渡すというのはたぶん初めて。

技術書典4と5に一般客として行ってみて、漠然と楽しそうだな、僕も技術書を書いて売ってみたいなとは思っていたのですが、直接のきっかけとなったのはCoderDojo界隈で有名なTGZNさんが「技術書典6の募集始まってますよー」って親切に教えてくださったことでした。

とはいえ、原稿の執筆もそうですが、製本したりするのも大変だろうなあとは思っていてかなり迷ったのですが、自分のコンフォートゾーンを抜け出す経験を月に一回はやるということを心がけているので、思い切って参加を申し込みました。

昨年執筆した商業誌のScratchで楽しく学ぶ アート&サイエンスも一緒に頒布しようとは思っていたので、それにあわせて中級者、大人向けのScratchネタにすることに決め、どうせならマニアック過ぎて出版社からはNGが出そうなテーマにしようということで「大人のためのScratch - Scratch 3を改造しよう」というコンテンツに決めました。

とはいえ、「実践ARKit」を書かれた堤さんの技術書でご飯は食べられるのか？ #技術書典を始め、いろんな方の技術書典関連ブログエントリーを読んでいて実感していたのは、コンテンツもそうですが皆さん本の装丁、デザインにとてもこだわって作られているということ。

本は好きなのですが、電子書籍でもいいやと思っている派の僕には、手に取るモノとしての本にそれほどのこだわりはなく、果たしてそれを作ることに情熱を注ぐことはできるのだろうかと思っていました。

外注するか、誰かそういうことが得意な方と一緒にチームを組むという選択肢もあったのですが、勝手が良くわからない初参加の身としてはそこまで他人を巻き込んだり、コストをかける勇気がありませんでした。

一方、Scratchをネタにした場合、Scratchがグラフィカルなプログラミン環境であるゆえ、たとえばブロックの操作は目で見れば一発でわかるのに、それを文章にするとどうしても冗長になったりわかりにくくなる面があります。

グラフィカルな環境が主体ということでScratchと似た面があるUnityを学んでいたとき、is8rさん作成のLearn-Unityが、どの技術書よりもわかりやすかったのですが、その一因にGifアニメが多用されているというのがありました。その記憶が強く残っていて、ハリーポッターの世界に登場する新聞のように、動く本が一番Scratchに向いているのになあ、と思っていたのです。

• 製本しなくてすみそう
• 動く本が作りたい

この2つを満たすものとして、オンラインコンテンツを読めるサイトを作り、パスワードロックをかけ、そのパスワードを頒布すれば良い、という結論にいたりました。

技術書典的には、少し邪道な気もしたのですが、サークル参加要項を確認してみても、

頒布形態は、紙の書籍（いわゆる同人誌）、デジタルコンテンツ、QRコードを印刷した紙などなんでも構いません

とあったので、この方針に決めたのでした。（後編に続く）

Amazon の購入履歴を見たら、2014年3月となっていて、購入直後から少しずつ読んでいた記憶があるから、かれこれ5年近く経ってようやく読了したことになる。僕の今年の一大ニュースだ。

最初と最後の方は一気に読み進めることができたのだが、読むのに時間がかかったのは中盤、チップの話あたりだろうか。

コンピューターの仕組みの概要を知るには良書だと思う。自分で設計したプログラミング言語を作ってみようかな、と少し思わせてくれたり、コンピューター周りの仕組みを少し気にするようになるかもしれない。読む前と後では、コンピューターやソフトウェアを見る目が少しだけ変化したと思う。

ml5.js という機械学習のJSライブラリのことを調べていて、機能が足りないと思ったので Pull Request を送っていたところ、先ほどマージされた。

» Show the version number of the library. by champierre · Pull Request #283 · ml5js/ml5-library

ml5.return とWebコンソール画面に入力すれば、今現在使っているml5.jsのバージョンを返してくれるというごく簡単なものなんだが、シンプルな実装方法で提案できたので、なんだか褒められていてうれしい。

1つ目のコメントをくれている Daniell Shiffman 先生はThe Nature of CodeというProcessingの本を書かれていたり、The Coding Trainという人気のプログラミング学習動画シリーズを続けられていて、僕はちょっとしたファンだったので、有名人に会えたみたいなうれしさだ。

僕のオープンソースプロジェクトに対する貢献はそれほど多くはない。

今では、たいていの種類のソフトウェアはオープンソースになっていて、ソースコードが手に入ります。ソースコードを見て、ある機能に興味があったとき、自分が実現するとしたらどう実現するかを知る。そうした「知る」ための能力は、エンジニアの武器になります。優秀なソフトウェア開発者は、だいたいソースを読むことが好きだったり得意だったりします。

» 「オープンソースへの取り組みはエンジニアにとって強力な「武器」になる」（後編）Ruby言語開発者 まつもとゆきひろ 氏 |ギークアカデミー より

とあり、僕はWebサービスやプロダクトを作ることは好きなのだが、ソースを読む方はあまり得意ではないので、優秀なソフトウエア開発者でないことは自覚している。

でも、サラリーマンからプログラマーそしてフリーランスのエンジニアに転身していくきっかけを与えてくれたのはオープンソースプロジェクトへの貢献だった。

2003年にPOPFileというオープンソースの迷惑メールフィルターの日本語化に貢献し、プログラマーになりたいと強く思うようになった。

» POPFile 関連のエントリー

その後、スタートアップのウノウに転職し、そのウノウからPOPFileの製品版であるクイックPOPFileを出すことにもなった。

先に紹介した 「オープンソースへの取り組みはエンジニアにとって強力な「武器」になる」（後編）Ruby言語開発者 まつもとゆきひろ 氏 |ギークアカデミー にはこう書かれている。

例えばですが、Rubyのプロジェクトに参加してメジャーコントリビュータになれば、有名になって、上司からの扱いが変わる可能性もありますよね。転職もできる。

今までは、仕事は会社から与えられるもので、面白い仕事が当たればラッキーだけどそうじゃない場合もあったわけです。ところが、オープンソースの活動で自分の名前が表に出れば、今までとは違って「武器」を手に入れることができる。 

POPFile への貢献は、30を過ぎ経験がない僕でもプログラマーとしてスタートアップでやっていけるんじゃないかという自信を与えてくれたし、何よりプログラミングの楽しさを教えてくれた。

POPFile のときは、SourceForge にホスティングされているcvsでバージョン管理されたプロジェクトにパッチを送るという方法で、今は GitHub のレポジトリに Pull Request を送るという洗練された方法に変わったが、自分が書いたコードがマージされたときの喜びは何ら変わっていない。

GitHub にホスティングされているオープンソースのプロジェクトに参加する方法は以下のQiitaの記事に良くまとまっているので、興味がある人はこれを読んでOSSの開発にぜひ参加してみてください。僕のように人生が変わるかもしれません :)

» 意外ととっつきやすいOSS開発参加方法まとめ