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

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

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が必要

にあるとおり、

ldconfig

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

ldconfig とは、

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

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

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

今年も 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のおまつりの手伝いをする

技術書典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コードを印刷した紙などなんでも構いません

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

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

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

お金をいただくコンテンツとそうでないブログなどにザッと書いたコンテンツの違いは、どれだけ第三者の目が入り校正がされているかだということは、これまでの商業誌や雑誌の記事執筆で感じていたことだったので、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 ユーザーに向けて販売していこうと思うので期待大 :) です。

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

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開発参加方法まとめ

はてなダイアリーが終了するそうだ。

» はてなダイアリー、2019年春に終了　「苦渋の決断」で「はてなブログ」へ統合

はてなダイアリーは、僕がアメリカに住んでいた頃に愛用していて、多いときには一日に5回くらい更新していた。愛着があったサービスだっただけに残念。

はてなダイアリーの記事は、このRailsで自作しているブログに移行してはいたのだが、日付が一部きちんと移行されておらず誤って1969年に作成した記事となっていたのを、この際にすべて正しい日付に更新しておいた。

このブログの右下のアーカイブを見てもらうとわかるのだが、一番古い記事は2002年4月。17年間も我ながらよく更新し続けてきたと思う。

年を取ってくると時間が経つのが速いといいます。一年なんかあっという間に過ぎ去ってしまいます。

» 最近時間が経つのが早い、と感じたらチェックしたい5つのこと

には、

Bufferは5つの提案をしています。どれも｢時の流れを遅くするには、脳が理解するのに時間を要するような新しい刺激を与えること｣という根本的な考え方に基づいています。

とあって、その5つの提案の一つが

新しい場所を訪ねる：新しい環境では、香り、音、人、色、肌触りなど、多量な情報が脳に流れ込みます。

です。

昨年、これらを心がけて、香港や中国(深セン)、シンガポールなど今まで行ったことのない国に行ってみたりしたのですが、案の定今までよりも一年が長く感じられました。今年も今までやったことのないことにプチ挑戦したり、行ったことのないところに行こうと思っていたのですが、変わったことは特に何もしないうちに一月が過ぎようとしていて、「これはまずい」と思ったのでした。

そこで、いつか行ってみようと思う場所をメモしてある僕のToGoリストの中から、「国会図書館」を選んで行ってみることにしました。

永田町の駅から警備がものものしい自民党本部などの横を歩いていき、5分くらいで着きました。仕事が終わってからの帰りに寄ったので到着は17:30頃。すっかり暗くなってしまいました。

向かいには国会議事堂が見えます。

そしてこちらが入り口の前のオブジェです。

ちなみにだいたいこういうところにはあるだろうなと思っていたら、ちゃんとありました。まちクエストのクエストです。

初めて入館するということで、利用カードを発行してもらいます。氏名や住所を用紙に記入して提出し、発行まで5分ほど待って下さいと言われ、その間に荷物をコインロッカーに預けます。この時間帯は空いていたので、発行には5分もかからなかったと思います。初期パスワードが書かれた用紙と案内のパンフレットもあわせてもらいました。 普通の図書館と違って国会図書館には、書棚が全くありません。かなり大きな館内ですが、デスクや閲覧スペース、そして端末ばかりです。発行された利用者カードをPC端末の横に置かれたリーダーの上に置くと、IDが表示され、初期パスワードを入力すると、[NDL ONLINE(国立国会図書館オンライン)](https://ndlonline.ndl.go.jp)にログインできます。そして読みたい本を検索し、「資料の請求」をおこないます。 国会図書館では、本を借りることはできず、この資料の請求をおこなうと、少し経つと受け取りカウンターよりその本を受取ることができ館内で閲覧することができます。しかし、[納本制度](https://ja.wikipedia.org/wiki/%E7%B4%8D%E6%9C%AC%E5%88%B6%E5%BA%A6)により、国内で出版されるあらゆる本・雑誌が所蔵されているので、ここで読めない本はないというのが凄い。 国会図書館は19:00までやっており、到着時17:30だから十分時間があるなと思っていたのですが、初期登録に時間がかかったのと、資料の請求は18;00 までということで、端末にログインしたときには請求できる時間はあと10分ほどしか残されていませんでした。とりあえず自分の本「Scratchで楽しく学ぶ アート&サイエンス」と「Raspberry Piではじめる どきどきプログラミング」を検索してみました。

それで気づいたのですが、「どきプロ」の方はこどもの本に分類されており、こどもの本は国際こども図書館に所蔵されています。こちらは実は上野にあるのですね。「アート&サイエンス」の方は、大人の本に分類されており、こちらは国会図書館の本館に所蔵されていました。カートに入れて、「資料の請求」ボタンをクリックしたのは締切3分前くらいでした。

「ここで読めない本はない」と書きましたが、厳密にはこどもの本は上野に行かないと読めないなど、ほかにも分野によっては別のところに所蔵されているのかもしれません。NDL ONLINEは、実は図書館内に限らずどこからもアクセスできるので、心配なら事前に検索しておいて、所蔵されている場所を確認しておくといいのかもしれません。Scratch 関連の本だと、ほとんどが国際こども図書館所蔵ですが、昨年のもう一冊のおとなシリーズ「おとなも学びたいプログラミング Scratch入門」や「Scratchではじめよう! プログラミング入門」は国会図書館所蔵です。

10〜15分、しばし待つと、受取カウンターでリクエストした本を受け取ることができるようになります。資料が受け取れるようになったかどうかは、NDL ONLINEでステータスを確認することができ、スマホでも確認することができるので便利です。カメラは持ち込み禁止ですが、PCやスマホはOKですし、利用することもできます。撮影は禁止なので、館内の写真を撮りたかったのですが一枚もありません。

リクエストした自分の本を受け取り、「自分の本が国会図書館に所蔵されているぞ」という感慨にしばらくひたったあとは、新たに本をリクエストすることはもうできなかかったので、少しぶらぶらして、本を返却し帰途につきました。もう少し時間があれば、絶版になってしまった読みたかった本など閲覧したりといろいろと楽しめたと思います。

本好きな人には楽しめる場所なのではないでしょうか。ぜひ機会があれば、訪れてみて下さい。

» セブンとローソン、成人誌販売中止へ　8月までに

だそうだ。

2002年か2003年頃、サンフランシスコに住んでいて、長男がまだ2歳頃に日本に遊びに帰ってきたときにコンビニに成人雑誌が売っていることにとても違和感を覚えた。カリフォルニアではありえないことだったからだ。公共サービスの整備のされかたや、街の清潔さとかは東京の方が上だなあとは思ったのだけれど、そこだけとても後進国に思えたものだ。それから15年経って、ようやく成人誌を公共の眼に触れるところにおかないという点では先進国レベルに追いついたと言える。

今、アメリカや他の先進国では当たり前で、まだ日本では採用されていない事柄を列挙してみると、これから日本で起こることを予測できるかもしれない。10年〜15年経ってから、「ほら、僕の未来予測あたっていたでしょ」と言えるように、いくつか挙げてみよう。

満員電車がなくなる

満員電車、そもそも乗車率200%といった状況を許しているのがいけない。エレベーターと同じように100%以上になってしまったら、ブザー鳴る、発車しない、などすれば、皆んな別の解決方法を考えだすのでは…

— Junya Ishihara (@jishiha) 2019年1月17日

サンフランシスコの地下を走るBARTはめったには混まないのだけれど、2000年のおおみそか、新世紀を祝うための花火を観に行こうと市街に向かう列車に乗ろうといたときのこと。そこそこ混んではいるのだけど、東京の感覚ではまだまだいけるでしょ、という混雑具合において、列車に乗り込もうとしたところ、「もういっぱいだから乗らないで、次の電車を待ってね」というようなことをすでに乗っている乗客に言われた。なるほど、そういう感覚なのか、ととても新鮮だった。昨年、旅行した台北においても、すこし混んでいる地下鉄のホームに入ってきたら、入り口のところに並んでいた人たちは無理して乗ることはしなかった。おそらく、これが先進国の常識なんじゃないだろうか。赤の他人に触れる、なんてことは相当失礼なことであり、触れていなくても半径数十センチくらいのパーソナルスペース以内には入らないようにするのがマナーと考えられている。

そこそこ満員のエレベーターが来たら、人を押してまで入る人はいないだろう。そんな人は非常識だ。電車でも同じことになるのではないだろうか。

横断歩道で歩行者が立っていれば停車が徹底される

カリフォルニアで横断歩道に歩行者が横断待ちしていれば、常識的な運転者であれば必ず停車していた。日本でも教習車では、そうするように習うのだけれど、皆がやっているということで、卒業してしまえばほとんどの人がこのルールを守らない。カリフォルニアで徹底されていたのは、破ると厳罰が待っているからなのかは理由は良く知らないのだが、本当に良く停まってくれて感動したものだ。

自動運転になってそれが徹底されるのか、あるいはいたるところに監視カメラが置かれて、ルールを破ったときにすぐに摘発されるようになることによってかはわからないが、希望とともにそうなるのではないかな、と予想しておく。

緊急自動車が通行するときに、他の自動車は避けることが徹底される

横断歩道の問題と似ている。カリフォルニアでは、緊急車両のサイレンが聞こえたら、一般の乗用車は道の端にピタリと寄って停車するのが徹底されていた。またスクールバスが停車して、そのことを合図するライトが点滅しているときも同様だ。これは確か自動車免許の筆記試験の頻出問題だった。無視して、あるいは気づかず追い越そうものなら容赦なくスクールバスの運転者にナンバーをひかえられ、違反チケットを切られるという話だった。

緊急自動車の方は、もしその走行を邪魔しようものなら蹴散らすような勢いで、もの凄いスピードで走り去っていく。人命最優先という態度をこれでもかと見せつける。ひるがえって日本（東京）だと、サイレンが鳴っていても素知らぬ顔で走っている乗用車がたまにいて、緊急自動車もそういった車がいることを想定した遠慮がちなスピードで走っている。赤信号の交差点に進入するときには、「すみません、すみません」なんてスピーカーで断りながらノロノロと走っていく。自分が患者やその家族だったら、もっと急いで欲しいと思うものだ。

何を優先すべきかを考え、その優先事項を達成するためには、ほかのリスク（サイレンが鳴っていても停まらない自動車と衝突して事故してしまうかもしれないというリスク）は負うという考え方に少しずつ変わっていくのではないだろうか。

こうした日本以外の先進国では常識であることが、数年後は日本でも常識となっていくことは多い。現在、海外在住の人が予想する、近いうち日本でも起こるかもしれない未来をぜひ聞いてみたい。

拙著「Scratchで楽しく学ぶ アート&サイエンス」で紹介しているプロジェクトが、Scratch 3.0でもちゃんと動くかどうかを検証しました。

結論から言うと、書籍に載っている説明通りにプロジェクトを作って、問題なく動くことを確認しました。

ただいくつか3.0ならではの注意点があったので、それらをコメントとして追加して、書籍に載っているプロジェクトの完成例をScratchのスタジオとして公開しました。

» Scratchスタジオ - Scratchで楽しく学ぶアート&サイエンス(3.0対応)

各プロジェクトのリミックスは大歓迎、質問や、間違いの指摘はスタジオのコメント欄に残してくれても良いですし、Twitter ID: @jishiha でも受け付けています。

動作確認をしているときに気づいたScratch 2.0と3.0との違いとともにそれら注意点を紹介したいと思います。

塗りつぶしの色は、カラーパレットで指定できなくなった

コスチュームを塗りつぶすとき、Scratch 2.0では以下のようなカラーパレットで色を指定していた。

Scratch 3.0では代わりに色、鮮やかさ、明るさをスライダーで選択できるようになった。

細かく色を指定できるようにはなったのだが、色をあたり判定などに使うときにスプライトをまたがって同じ色を指定する、という場合にパラメーターの各値を正確に合わせる必要があるのでややとまどう。例えば赤色ならば、色:0、鮮やかさ:100、明るさ:100 のように各パラメーターの数値をそろえる必要がある。

色を正確に再現できるように、各プロジェクトで色の指定が必要な箇所では以下のようにコメントで説明を追加しておいた。

直線は、ビットマップに変換しないと塗りつぶせない

Scratch 3.0では、ビットマップに変換しないと直線や枠線を塗りつぶすことができない。これはScratch 2.0と挙動が異なる。直線や枠線自体の色を指定すれば、色を変えることはできるので、問題ないように思えるのだが、Scratchでは色を当たり判定に使うことが多いため、画面上にすでにある色をスポイトで吸って同じ色で塗りつぶしたいということがよくある。

たとえば、以下のコスチュームは直線部分をほかのコスチュームで使っているまったく同じ黄色に塗りつぶしたい、というケースでは少し困ってしまう。

三角関数の演算プロックに違和感

sin 60° や cos 120° を演算ブロックで表現するとき、Scratch 3.0は以下のように「60のsin」「120のcos」となるのが違和感を感じる。

Scratch 2.0では以下の通り読みやすい。

もとの英語での表現が「sin of 60」「cos of 120」と変わったことに日本語訳もひっぱられた形なのでいたしかたないように思えるが。。

数値しか受け付けないはずの入力欄に日本語が入力できてしまう

Scratch 3.0では、「○歩動かす」や「○度回す」など、数値しか受け付けないはずの入力欄に日本語が入力できてしまう。

最後の「○度に向ける」だけは、日本語の入力を受け付けず、しかも入力欄が赤色にハイライトされてミスタイプしたことが一目瞭然なので、可能ならこのUIに統一してほしい。

上記「１０歩動かす」は、１０が全角数字のためブロックは動作しない。日本語入力をオフにし忘れて数字を全角のまま入力してしまうというミスは良く起こるので、結構影響が大きい気がする。

Scratch 3.0のソースコードを管理しているGitHubのレポジトリのIssueに追加しておいた。

» Number fields should not accept non-number characters(ex. Japanese) · Issue #1857 · LLK/scratch-blocks

OpenなIssueはすでに200を超えていて、すぐに対応してもらえるのかはわからないのだが、もしこのIssueは影響が大きくてマズいと思われる方は、このIssueに+1のリアクションをおこなってほしい。もしかすると、賛同者が多いということが開発者側に伝わり優先度が上がるかもしれない。

以上、動作確認中に気づいたScratch 2.0と3.0との違いを紹介しました。2.0で作った自分のプロジェクトを3.0で動かすときの参考になればと思います。