みんなのコード Tech Blog

NPO法人みんなのコードのエンジニアによる技術ブログです。

公倍数コースの最終ステージでグラミンがしゃべるようになりました(Chrome限定)


こんにちは。 みんなのコードのエンジニアの板東です。

この度、プログル 公倍数コースの最終ステージ(ステージ15)にて、
「〇〇と言います」ブロック実行時に音が出るようになりました!(Chrome限定です)

(実は5月からこの機能は追加されたのですが…お知らせが遅くなってしまいました)

下に示すような、音声ON/OFF切り替えボタンをONにすることで、グラミン(吹き出しが出ているロボット)が「〇〇と言います」の「〇〇」を喋ってくれるようになります。
下に示している場合だと、1から10まで数を数える毎に、「プロ!」と読み上げてくれるようになります。

f:id:hanawasakuyon:20200618144357p:plain
公倍数コース 最終ステージ(ステージ15)

f:id:hanawasakuyon:20200618144538g:plain
公倍数コース 最終ステージ(ステージ15)にある音声ON/OFF切り替えボタン

本記事では、この音声読み上げ機能について

  • どのように開発が進んで行ったのか
  • どのような技術を使っているのか

等について書かせていただきます。


開発のきっかけ

使っていただいた様々な方からのフィードバック・感想の中で

先生方から

「公倍数コースで〜〜と言いますブロックがありますが、この時グラミンがほんとにしゃべったら絶対おもしろいですよね!子どもたちも喜ぶと思います!」

という声をいただいたり、実際の子どもたちからも

「グラミンにしゃべってほしい!」

という感想をもらったことが、一番のきっかけです。

開発チームとしても、「〇〇と言います」の「〇〇」を、グラミンの吹き出しに表示するだけでなく、「〇〇」を実際に喋ってくれるようになれば、プログルを使ったプログラミング学習が、もっと面白くなりそうだなと思い、この機能を開発するに至りました。


用いた技術

音声を再生する方法はいくつかありますが、今回は、Web Speech API の構成要素の一つである、 SpeechSynthesis を用いました。

developer.mozilla.org

SpeechSynthesis とは、音声合成機能を利用するためのインターフェースです。
SpeechSynthesisUtterance インターフェースに読み上げてほしい文字列を渡すことでできたインスタンスを、SpeechSynthesis の speak メソッド の引数に渡してあげることで、
ブラウザはその文字列を読み上げてくれます。

例として、以下のようなコードを挙げます。
以下の2行を実行することで、ブラウザは「あいうえお」と読み上げてくれます。
ブラウザのコンソールを開いて、そこに以下の2行を打ち込んでみると、(IE以外の)ブラウザは「あいうえお」と読み上げてくれると思います。

const utterance = new SpeechSynthesisUtterance("あいうえお");
speechSynthesis.speak(utterance)

プログルでは、「〇〇と言います」の「〇〇」を SpeechSynthesis に渡してやることで、この音声読み上げ機能を実装しました。


Chrome限定とした理由

まず、Web Speech API の SpeechSynthesis はIE未対応であるようです。

f:id:hanawasakuyon:20200618160003p:plain
Web Speech API の SpeechSynthesis は IE未対応

また、音声読み上げ機能をONにして、SafariやEdgeで動作を検証してみたところ、 プログルでのブロックプログラミングの処理が時々止まってしまうという不具合が発生してしまいました。

現在、Web Speech API実験的な機能であるということなので、 この不具合に起因するものがプログルのプログラムなのか、Web Speech APIの仕様なのか、調べきれてはいないのですが、まずはリリースを優先して、不具合が確認されなかったChromeのみの機能とすることにしました。

Chrome以外のブラウザではそもそも音声ボタンが表示されないようになっています。


開発を振り返って

プログルに音声読み上げ機能が追加されたということで、この機能を楽しんでくださる方々がいらっしゃればとても嬉しいなと思います。

また、自分はこの開発をする前は主にバックエンドの開発をしており、フロントエンドの開発は実務であまりしたことがなかったのですが、
この開発を経て、実務でのフロントエンド開発に慣れてき始めた感じがあり、良い機会だったなと思います。


We Are Hiring!

特定非営利活動法人みんなのコードでは一緒に働く仲間を募集しています

最後に、みんなのコードでは、一緒にプログラミング教材「プログル」を開発してくれる方を募集しています。この記事を読んで興味を持っていただいた方、ぜひお気軽にご応募ください🙂

www.wantedly.com

Proguru is out of beta - プログルのロゴから「β」を取りました


しれっと変更していました

みなさんこんにちは。みんなのコードCTOの田中です。

実は今年4月初旬…

プログルのリリース前から、この時期にやろうと決めていた、ある小さな変更を行いました。

それが、タイトルにもある通り、プログルロゴから「β」を外したことです。

f:id:codeforeveryone:20200511113658p:plain

f:id:codeforeveryone:20200511105934p:plainf:id:codeforeveryone:20200511105901p:plain
今までのロゴ(左)と4月からのロゴ(右)

(これ気づいた人がいたらすごい…!😁)


βに込めた想い

このベータ表記ですが、実はリリースの直前、急遽デザイナーさんに頼んで入れてもらったものです。

f:id:codeforeveryone:20200511111303p:plain
当時のデザイナーさんとの会話…懐かしや

これは、Google Apps(現GSuite)が長らくベータ版であった件へのオマージュでもあり

また、2017年4月のプログルリリース当時、これから必修化に向けてがんばろうというタイミングだったプログラミング教育を、一緒に盛り上げていきたいという想いを込めていました。

そして、小学校でのプログラミング教育必修化のタイミングまで、無事プログルが存在していたら(リリース当時からすると、存在していない可能性も大いにあったわけです…🤭)、このベータ表記を取り、名実ともに正式版として、次のフェーズを迎えられるようにしようと考えていました。

リリースして3年、無事こうしてベータ表記を外し、このような形でお知らせできるのは、何より日々プログルを利用し、ご支援いただいている皆さまのおかげです。

本当にありがとうございます。

さて、めでたく正式版を迎えたこのタイミングにふさわしい、新機能のリリースがありましたので、担当のきょんしーにバトンタッチします!

これからもプログルをよろしくお願いいたします!

f:id:codeforeveryone:20200511112444p:plain


プログル多角形コースが英語に対応

きょんしーです🐧

twitter.com

先日、プログル( https://proguru.jp ) 多角形コースが英語に対応しました。 開発に取り掛かった経緯は、日本のみならず海外の先生から「英語対応してほしい」という意見があったためです😀

いろんなライブラリがあるのですがReactでも使いやすそうだったので i18next( https://www.i18next.com/ ) を用いました。

ブラウザが持っているユーザの言語設定を取得し英語と日本語を切り替えるようにしています。 中国語、ポーランド語とかの設定とかだと日本語になります💦

日本語設定であっても英語に簡単に切り替えて学習できるように、ヘッダーに言語設定の切り替えボタンも設けています。

f:id:k-nagao:20200511115424p:plain

ステージの課題文や、チュートリアルなどの文言を英語対応させるのは i18next を用いれば翻訳用の yaml, json, jsファイルなどを作成して対応させるだけなのですが、いくつか知見もたまりました。

英語と日本語の文法の違いで語順が異なる場合

よくある "利用規約に同意して" など文章の場合、"利用規約" に aタグでリンクが貼られると思うのですが

"Accept Terms of Service" となり "Terms of Service" にリンクを貼ることになるので、注意しておかないと文法が崩れてしまいます。


Blocklyブロックの英語対応

https://developers.google.com/blockly/guides/create-custom-blocks/localize-blocks にも記載されている通りに作成したら良さそうです。 しかし、Blockly関連とそれ以外で翻訳ファイルをまとめるために i18next を使用しました。問題なく使用できました。


リリースを振り返って

スウェーデンの方から、ありがたいお言葉をいただきました。

Great job, we finished it! Will there be even more in English? It's a really good idea! 🙂

現状、多角形コースだけなので、公倍数などの他のコースも取り掛かっていかねば...

それより先にトップページも英語に対応させないと... トップページは React を用いずに pug で静的ページを生成しているので実装案を検討中です。。。


We Are Hiring!

特定非営利活動法人みんなのコードでは一緒に働く仲間を募集しています

最後に、みんなのコードでは、一緒にプログラミング教材「プログル」を開発してくれる方を募集しています。この記事を読んで興味を持っていただいた方、ぜひお気軽にご応募ください🙂

www.wantedly.com

プログルのCI/CDをCircleCIからGithub Actionsに移行した話


自己紹介

みんなのコードのエンジニアの板東です。

2020年1月にみんなのコードに入社し、現在は主にプログルのバックエンドの開発をしています。

みんなのコードに入社する前は、大学院で宇宙ロボットについて研究したり、メーカーで勤務したりしていました。

Webエンジニアとしては未経験という状態でしたが、入社3ヶ月目で、プログルのCI/CDをCircleCIからGithub Actionsに移行する というプロジェクトを担当させていただきました。

今回は、CI/CDを移行することになったきっかけや、移行後の所感などについてお話させていただきます。


CircleCIじゃダメなの?

プログルは、そのリリース時から長らくCircleCIを利用していました。 実際のところ、機能的な問題は全くありません。

ただ、開発メンバーが増えていくにつれ、大きな問題が出てきました。CircleCIの料金です。

circleci.com

CircleCIはクレジット料金の他に、プロジェクトに関わるユーザー数に応じて課金されるようになっています。

開発チームの人数を考えると、Performanceプランの

最初の 3 ユーザーまで月額 $15

ではどうがんばっても収まらず、少なくとも$70は超えてしまいました…。 (CircleCIにはNPOプランも無さそうでした…)


そこでGithub Actionsですよ

そこで目をつけたのが Github Actions でした。

弊社はGithubNPOプランに入っており、GithubのTeamプランを無料で使わせていただいています。

GithubのTeamプランでは、Github Actionsの利用時間の10000分が含まれているため、 弊社では Github Actionsを10000分まで無料で使用できる とのことです(ありがたや…🙏)。*1

github.co.jp

よって、Github Actionsを使わない手は無いなと感じました。

また、GitHub Actionsのワークフロー構文に関するページを、以前CircleCIでCI/CDするために書いていた config.yml ファイルと照らし合わせて読んでみたところ、CircleCIと比べてそんなに使い勝手に大差ないのかなと感じたのもあり、CI/CDをGithub Actionsに移行することにしました。


CircleCIと比べて感じたこと

pushするブランチごとにyamlファイルを作成する必要があるらしい

例えば、テストや構文チェックをmasterブランチにpushしたら実行、デプロイをproductionブランチにpushしたら実行するようにしたいとします。

この時、CircleCIなら workflows キーを用いて1つのyamlファイルでこれらを定義できますが、Github Actionsだと、workflows キーみたいな記法がないので、 masterブランチにpushしたら実行するワークフロー・productionブランチにpushしたら実行するワークフロー、それぞれのyamlファイルを作成する必要があるようです。

push先の各ブランチごとのワークフローを1つのファイルにまとめるのか別々のファイルに分けるのか、この辺は好みが分かれるのかなと思いました。

ジョブ内各ステップの途中経過を確認しづらい感

CircleCIのUIだと、CI/CD実行時に、そのステップで行われる処理の途中経過をサクサク表示してくれるので、その点が良いなぁと感じました。

ただ、issueやプルリクの画面から、タブを切り替えるだけでCI/CDの様子を確認できる点は非常に便利です。

とはいえそこまで大きな差は無さそう

色々好き勝手書き連ねましたが、実際のところ、使い勝手はGithub Actions・CircleCI双方で、そこまで大差ないような気がします。

むしろ、GitHubNPOプラン内に収めることでコストダウンできたので、Github Actionsに移行してよかったなと思っています!


本プロジェクトを振り返って

Github Actionsは、去年の11月にGenerally Availableになったという新しめのサービスですが、このような 新しめのサービスを積極的に取り入れられる環境に身を置けているのは幸せなこと だなと思いました。

また、今後も何か新しくて良さそうな技術やサービスが出てきた時は、積極的に取り入れられるようにしたいなと思います。


We Are Hiring!

特定非営利活動法人みんなのコードでは一緒に働く仲間を募集しています

最後に、みんなのコードでは、一緒にプログラミング教材「プログル」を開発してくれる方を募集しています。この記事を読んで興味を持っていただいた方、ぜひお気軽にご応募ください🙂

www.wantedly.com

プログル理科電気コースの開発秘話


みんなのコードエンジニアの きょんしー です🐧

twitter.com

2月3日、プログル理科電気コースをリリースしました。

rika.proguru.jp

プログル理科電気コースは、チュートリアルに沿って回路の組み方、プログラムの作り方や考え方までを授業の中で学ぶことができる、micro:bitのプログラミング環境です。プログルボードと組み合わせて使うことを想定しています。

2019年の9月くらいから取り掛かり始め、週に1, 2時間ほどの時間を取りつつ実装してきました。

無事にリリースし、リリース後の細かい修正の対応も終えたので、

  • プログル理科電気コースの開発がどのように進んでいったのか
  • どのような技術を使っているのか

について書かせていただきます。


micro:bitリポジトリを fork

2019年の5月に『プログル6年理科電気キット』の提供を開始しました。

Makecode(https://makecode.microbit.org/) の機能として提供されているプロジェクトの共有機能を用いて、6年生の単元「電気の利用」で使用するブロックを使えるようにしていました。

Makecode には、カスタムブロックを読み込む機能やプロジェクトを共有する機能など様々な機能があるのですが、実際にどのくらいのユーザが使用してくれているのかの正確な値を知ることができませんでした。

また、プログルの開発において意識している点は

  • プログラミング教育の必修化を受け、初めて児童に教える先生でも使える教材

です。 そのため、チュートリアルを用意することで先生にとって使いやすく、児童にとって理解しやすくすることを意識しました。

まずは MicrosoftGithub で提供しているリポジトリを fork するところから始めます。

これらの3つのリポジトリを fork してきました。 環境構築に関しては https://github.com/microsoft/pxt-microbit#readme に示されているので参考にしていただけたらと思います。


makecode→プログルらしいデザインへの移行

fork が終わった後は、プログルのデザインに合わせるため、CSSファイルを探っていました。

pxt-microbit/theme/site/globals/site.variablesprimaryColor など、色の定義がされていたのでプログルらしい色に変えました。

@primaryColor: @green;

/* Proguru Color */
@blue: #439ef9;
@green: #30bf55;
@white: #ffffff;

メインビジュアルの画像やヘッダーの画像・リンクを変更し、トップページのデザインが完成しました。

レスポンシブデザインなのですが、メインビジュアルの画像が画面の横幅によって押しつぶされることがあったので、修正する作業が地味に大変でした。


チュートリアルの追加

Makecode にも初めて使う人向けに簡単なチュートリアルが用意されています。

チュートリアルの追加は、先ほどのデザインの変更とは違って TypeScript を書けそうな臭いがしたので、ワクワクしていました。

しかし、現実はそう甘くありませんでした。 こちら がMakecodeの「点滅するハート」のチュートリアルです。

なんとmarkdown でした。

規則に沿って同じようにファイルを作ることでチュートリアルが作れます。 実際にプログル理科電気コースの最初のチュートリアルは以下のような内容が書かれています。

# スイッチを作ろう

## Introduction @fullscreen
プログルボードとmicro:bitを接続し、電池や豆電球をつないだ回路を作ろう!最初にプログルボードを使う準備をしよう!
![接続済の写真](/docs/static/rika/proguruBoardCircle.jpg)

## Step 1 @fullscreen
micro:bitとプログルボードをつなごう!
![micro:bitとプログルボードをつなぐアニメーション](/docs/static/rika/setMicrobit.gif)

## Step 2

まずは Firebase Hosting ではじめてみた

低コストかつ運用の手軽さから、インフラ環境は Firebase Hosting に決めました。

ローカルの環境ではMakeCode共通パッケージの pxt を使った pxt serve コマンドでサーバが立ち上がるのですが、ビルドするには pxt staticpkg コマンドを叩く必要があります。

どちらでも同じ結果になると思いきや画像ファイルのディレクトリが異なるため、実際にホスティングする際にはリダイレクトを適用する必要があります。

firebase.json はこのような感じです。

{
  "hosting": {
    "public": "built/packaged",
    "ignore": [
      "firebase.json",
      "**/.*",
      "**/node_modules/**"
    ],
    "redirects": [
      {
        "source": "/static/:path*",
        "destination": "/docs/static/:path*",
        "type": 301
      }
    ]
  }
}

リリース直前に襲いかかるIEの魔の手

リリース前に、都内の小学校で実際に使ってもらう機会をいただき、みんなのコードのメンバーも数名授業を拝見しに伺っていました。

授業では Google Chrome を使用していたため大丈夫だったのですが、 実は当日朝、IE11で動作させたら組んだブロックのコンパイルができないことが発覚していました。

授業中は動かなかったりしないか、バグが出てくるのではないかとヒヤヒヤしていました。幸いにも授業はスムーズに進行しました。この時点だとIE11で動作していませんが....


Cloud Run に移行

その後、複数環境での動作検証を行い、どうやらFirebase Hosting環境下のみ起こる現象であることがわかりました。

そこで、Firebaseの代替となる環境として、Google Cloud Platform が提供している Cloud Run を使うことにしました。

Cloud Run は2019年4月ごろに発表された、Docker コンテナをサーバレス環境で実行するというモダン(大事!)なサービスです。

Dockerコンテナを使うことで自由な環境を用意できる点と、サーバーレスなのでインフラを意識しなくて良くなる点から、今回導入することにしました。

Cloud Run を用いると、以下の手順を実行するだけでアプリケーションをデプロイすることができます。

  1. アプリケーションコードを含んだ Dockerfile を定義
  2. Cloud Build を用いてイメージをビルドし、Container Registry に保存
  3. 保存したイメージを Cloud Run にデプロイ

このように手軽にデプロイできるのも大きなメリットだなと感じました。


無事にリリース

2月3日、無事にリリースしました。 リリース後も色んな方々から使ってみての感想をいただきました。

みんなのコードのメンバーや活動に熱心に関わってくださる先生方には、年末年始で落ち着きたい時期にも関わらずレビューしていただきたりしました。 この場を借りて感謝申し上げます。


ファイルサイズ大きいので学校で使うには...

小学校で使ってもらおうと思った時に、このままだとファイルサイズが大きくて待ち時間が発生するという問い合わせがありました。

15.4 MB × 20人 = 308 MB 確かに大きいですね。

SPAということもあるのでファイルを取得完了してからの時間も加えるともう少し時間がかかりそうです。 gzip圧縮やチュートリアルで表示されるGIFファイルの圧縮、キャッシュする期間の調整などをして3分の1くらいになりました。


リリースを振り返って

他の開発と並行してプログル理科電気コースの開発を進めていたため、がっつりと時間を割くことは出来なかったですが、使わない機能を省いて必要な機能だけを提供できるように心がけました。

IEでのバグが出たときのリリース判定会議では学校で一番使われているブラウザに対応できないとダメだよなぁということで落ち込んでいましたが、無事にリリースでき、まずは一安心です。


We Are Hiring!

特定非営利活動法人みんなのコードでは一緒に働く仲間を募集しています

最後に、みんなのコードでは、一緒にプログラミング教材「プログル」を開発してくれる方を募集しています。この記事を読んで興味を持っていただいた方、ぜひお気軽にご応募ください🙂(カジュアルにランチ🍴からでもOKです!)

www.wantedly.com

オブジェクト指向を理解するJava使い小学生にコンピュータクラブハウスで出会った話


みんなのコードエンジニアの きょんしー です🐧

twitter.com

今日は絶賛クラウドファンディング募集中のコンピュータクラブハウス加賀に行ったときのことについて、お話したいと思います。

www.furusato-tax.jp

加賀と東京の距離は遠い

みんなのコードがふるさと納税のスキームを活用して設置したコンピュータクラブハウス加賀(以下、クラブハウス加賀)が5月25日のオープンから約半年が経つのですが、東京と加賀市で距離が離れていることもあり、日々の細かな気づきや子ども達の成長を見ることが出来ていませんでした。

現地のメンバーからの写真の共有や口頭で日々の活動の一部は知ることはできていましたが、東京にいるみんなのコードのメンバーですら、なかなか日々の活動内容や現地のコミュニティマネージャーの末廣さんの想いを共有できていませんでした。

そのため、実際にクラブハウス加賀に行って子ども達と一緒に過ごす時間を2度ほど取らせていただきました。

初めて加賀に行ったんですが...

1度目は6月上旬に。 オープンして間もないこともあり、まだ来る子ども達は少なかったですが、朝から夕方までずっと居てくれる子もいました。

そのとき、小学生ながらプログラミングをしている少年に出会いました。おじいちゃんから貰ったというパソコンでMinecraftで遊んだのがきっかけでMODを作りたいと思ったそうです。その少年は、ネットで調べた情報を頼りにJavaの勉強を始めたそうです。(私たちの間では、通称“Java少年”と呼んでます)

ボクが訪れたときには、ちょうどJava Swingでシューティングゲームを作っていました。JFrameやJLabelの扱い方に困っていたようだったので助けようと見ていたのですが、Java少年は公式のJavaドキュメントを漁りながら問題を解決していました。

Java少年
Javaのドキュメントを見てる様子(唯一撮っていた写真)

その彼は、クラスとインスタンスの概念を理解していたことも勿論ですが、ちゃんとドキュメントを見る習慣がついてるのには驚きでした。高専に入ってからプログラミングを始め、クラスで挫折した頃の自分が懐かしいです。笑

Java少年だけでなく、高校1年生の男の子( ふるさと納税ページ のOGP画像左の子)もクラブハウス加賀 に来ていたのですが、テクノロジーを使ったさまざまなことに、とてもやる気がありました。 その彼は、当時は、まだプログラミングを始めていなかった(始めなければならないという意識は強かった)ため、アイデアを語ってくれたのですが、内心ボクは「どうやって実装するんやー!」と思ったりもしました。 しかし、紙に設計を起こしてイメージをどんどん書いていく姿を見てると、ボク自身もすごく楽しかったことを覚えています。

エンジニアとしては、良くも悪くもどのような技術を使ってどのくらいで実現可能かを考えてしまいがちなのですが、彼自身がアイデアをたくさん出すだけでなく、プログラミングが必要だと分かってることは1歩目としては良いなぁと感じました。

また訪れた、加賀に行ける機会

2度目のクラブハウス加賀の訪問は、8月のお盆に。 夏休みということもあり、たくさんの子ども達が遊びに来てくれてました。Scratchで自分が描くストーリーを作ってる子やmicro:bitのさまざまな機能を試して遊んでる子など、みんな夢中になっていました。

高校生の男の子もいたのですが、その子はクラブハウス加賀においてある本を写経してJavaの勉強をしていました。勉強する中で困った時は、Java少年に聞いて教えてもらっているそうです。男の子にとっては、教えてもらう相手として年下であることに意識はあるようでしたが、年下であろうと自分よりも詳しい相手から学ぼうとする姿勢は素晴らしいなと感じました。

自走できれば勝ち?きっかけを作らなきゃ!

コンピュータクラブハウス加賀を訪れる子ども達に会って、まだ始まったばかりではあるけど成功してるような感じがしました。 ずっとなぜだろうか考えていたのですが、誰から言われるわけでなく自走できるようになっていたから成功してるように感じたのだと気づきました。

学校で勉強していて、はじめはやりたいと思っていたことでも、ただ教えられたことをすることより、何かを自発的に行えるようになる段階に持っていくことが大事じゃないですか。 それがプログラミングに限らず、スポーツであっても趣味であっても同じだと思ってます。

こういう子ども達がきっかけを掴み、自走できる環境をCoderDojo42 Tokyoなどでも提供されていますが、ボク自身も地方出身であることもあり、特に地方になるときっかけを提供するのが難しいのかなとも感じています。

Java少年でさえ、PCはおじいちゃんからのお下がりでスペックが低くて困ってると言ってました。だから、クラブハウス加賀に来ればヌルヌル動かせれるから来ているそうです。

きっかけを持っている子ども達だけが来るわけではないので、PCや3Dプリンタといった機材だけでなくふさわしいメンターとなる人が必要にもなります。

ふるさと納税、お願いします🙇‍♂️

ふるさと納税のページはここからアクセスできます。

www.furusato-tax.jp

設備の拡充は勿論ですが、クラブハウス加賀に来て成長する子ども達が少しでも自分のキャリアを描くきっかけにもしていきたいと考えているので、ご支援お願いします。

ワンストップ特例制度を使うと(適用条件はありますが)、決済完了日の翌年の1月10日までに申請すれば住民税控除を受けることができます。今回ボクも初めてふるさと納税を利用しましたが、5分ほどで寄付の手続きが終わりました。

ぜひ、今年のふるさと納税は今年のうちに。

Googleさん、日本でIE11は根強く生きてますよ。

※ この記事は2019年7月にWantedlyフィードに掲載した記事を加筆修正したものです

小学校のデバイス・ブラウザ事情

みんなのコードエンジニアの きょんしー です🐧

twitter.com

来年の4月から小学校でプログラミング教育が必修化されます。

実際にPCを用いる学校もあれば、PCに比べ手軽に使えるということでタブレットを導入している学校もあり、使うデバイスは実に多種多様となっています。しかし、問題はブラウザに潜んでいます。

プログルのユーザが用いるブラウザの約7割はIE11で、このこと自体が悪いわけではないのですが、エンジニアとしてはリリースの際に注意して検証する項目が増えてしまいます。

また、タブレットといってもiPadを使用する学校もあれば、Windowsタブレットの使用も想定されます。 このように、様々なデバイスやブラウザでの動作検証の大変さをひしひしと感じています。

全国の学校現場のブラウザ事情を考慮するとIE11には対応させなければなりません。 入社してすぐにあった中央値・最頻値コースのリリースで、IE11対応のissueやバグ修正と向き合ってきました。

code.or.jp

あれ、バグがあるぞ。

そんなとき、IE11で発生するBlockly本家のバグを発見しました。

ブロックに対応するコードをステップ実行する際に、実行されている箇所のブロックがハイライト表示されるのですが、IE11ではアンハイライトされないことが分かりました。

Blocklyのminifyされたコードから原因を探りました。 バグの原因を特定し修正用のパッチも当てました。

ただ、BlocklyはGoogleが管理しており、オープンソースで世界中(まだまだニッチなBlocklyコミュニティ)の人の手によって機能の追加やバグの修正がされています。

そして、Blocklyを使って開発されているプロダクトも多く存在するため、貢献できたらと思いプルリクを作成しました。

このバグに関するプルリクはこちら。 気合を入れすぎてIE10でもOperaでも検証しました。

プルリクメッセージを書く上で、英語が得意なパートナー担当のメンバーにお願いしました。 自称言語オタクということもあり、特に Reason for Changes に関してはとても素晴らしい文章を書いていただきました。

In Japan many online materials of STEM classes for elementary schools are based on Google Blockly, so the case where children use Goolgle Blockly is not rare. Moreover most of Japanese schools are not equipped with Chrome/ Microsoft Edge nor Safari. They use Internet Explorer, even though IE has not supported. We would like to make it clear to children that which code is to debag.

バグは修正されたが...

結果としてはBlocklyのコントリビュータになれませんでした笑 しかし変更は別の形できちんと反映されたので良かったです。

Googleの方が新たにプルリクを作成して変更を加えてました。diffを見ると自分の出したプルリクと少し変更点が異なっていたのもあったので、レビューが面倒だったのかもしれないです。

形は違えど、Blocklyユーザや開発者に貢献できたので良かったです。 また、Googleの開発者もIEが嫌いということが分かりました。

Blockly開発は楽しい

9月に開催された技術書典7に「楽しいBlockly」という名前で出してきました。PDF版に関してはBOOTHで購入可能です。 ReactとBlocklyを用いたアプリケーション開発について書きました。もちろんテストも書いてます。

kyoncy.booth.pm

前回書いた記事 https://techblog.code.or.jp/entry/2019/11/08/183000 でも触れたのですが、Blocklyが公式にnpm公開しており、VueやAngularでの開発の例も紹介されています。

「楽しいBlockly」ではnode-blockly, react-blockly-drawer というライブラリを使ってるのですが、現在移行中です。

プロダクト開発をする中で「NPOだけど面白いベンチャーだなぁ」と感じてます。 「全ての子どもがプログラミングを楽しむ国にする」 ためにプロダクトを開発しているからでしょうか。


We Are Hiring!

特定非営利活動法人みんなのコードでは一緒に働く仲間を募集しています

最後に、みんなのコードでは、一緒にプログラミング教材「プログル」を開発してくれる方を募集しています。この記事を読んで興味を持っていただいた方、ぜひお気軽にご応募ください🙂(カジュアルにランチ🍴からでもOKです!)

www.wantedly.com

プログルを支える技術

※ この記事は2019年6月にWantedlyフィードに掲載した記事を加筆修正したものです

こんにちは。特定非営利活動法人みんなのコード(以下、みんなのコード)CTOの田中です。

今回は、私達が開発しているプログラミング教材「プログル」がどんな技術で支えられているかを紹介したいと思います。

proguru.jp

プログルは、2020年の小学校におけるプログラミング教育必修化に合わせて、「学校の授業ですぐに使える」ように設計されたプログラミング教材です。先生の意見を取り入れて開発されたシンプルな画面構成と、教科学習に特化したドリル型のコースで、誰でも簡単にプログラミング教育を実践することができます。

プログルを2017年4月にリリースしてから約2年が経過し、利用者累計40万人を突破しました。対象学年の小学校5年生の年間人数100万人で割ると、2.5人に1人が使っているという計算になります。

技術的には、React.jsを利用したSPA(Single Page Application)で、GoogleのFirebase Hostingで提供しているサーバーレスのプロダクトになります。

この「プログル」を支えるため、以下に紹介するような技術を利用してサービスを展開しています。

f:id:codeforeveryone:20191118141844p:plain
プログル周辺技術の概観図


プログルのインフラを支える技術

元々、リリース当時はAWSメインで運用していましたが、2017年11月にGoogleのFirebase Hostingに環境を全面移行しました。

移行して1年以上経過しますが、特に大きな問題もなく稼働しています。

しいて言えば、Basic認証を実装しづらく、社内確認用のプレビュー環境の構築には不向きなところでしょうか。 

Firebase Hostingを選定した理由

FirebaseはGoogleが運営しているmBaaSです。iOS / Androidアプリのバックエンド環境として利用しているケースが多いかもしれませんが、Webアプリでも使用することができます。

Firebase Hostingはその中でもGoogleCDNを利用した静的ホスティングサービスです。

開発チームが当時私ひとり(かつ週2日のパートタイム稼働だった)という状況で

インフラに裂けるリソースが無く、なるべくアプリケーションの開発に専念したい インフラまわりの経験が浅めなため、なるべくインフラのことを考えなくて済むようにしたい という理由や

  • SPAとの相性が良さそう
  • 費用が安い
  • 面白そう

という(個人的なモノも含む)様々な理由から、Firebase Hostingで運用することにしました。

移行時の懸念点

CDNでリソースを配信するようになるため、配信元のサーバが国内に限らず世界中に存在することになります。

そのため、学校内のフィルタリングソフトにひっかかり、アクセスできない…という残念なケースが発生する可能性がありました。

公立の小学校は学校内のコンピュータにフィルタリングを設定していることが多く、海外のサーバは基本的にアクセス不可…ということもしばしばです。

一応Googleのサポートに問い合わせたところ、やはり弊社側でフィルタリングを回避する方法は無いとの回答を受け(まあそうですよね)ました。そこで、弊社と交流がある小学校の先生グループに協力を依頼して、フィルタリングの影響を受けないか報告してもらう…という事前確認をして、ようやく環境を移行することができました。

AWSで運用していた時期は、ELBにEC2というオーソドックスな構成に、自作のデプロイスクリプトをのせていました。Firebase Hostingに移行することで、サーバの管理費を大幅に削減でき、デプロイの自動化もしやすくなり、サーバ管理も不要と良いことづくめで、かなり運用が楽になりました。

その他、Route53やS3といったAWSのサービスも平行して利用しています。


プログルのサーバーサイドを支える技術

ぶっちゃけサーバーサイド実装はありません🤭

Cloud Functions for Firebase すら使っていません。

なぜサーバーサイド実装していないのか

この理由はシンプルで、「実装要件がないから」です。

プログルはユーザー登録不要で使えるようにしています。特に永続化しなければならない情報も現状無い(アクセス解析Google Analytics、お問合せフォームなどのユーザー入力情報はGoogleフォームにそれぞれ集約)ため、サーバーサイド実装をせず、フロントエンドだけで完結するSPA構成にする意思決定を行いました。

サーバーサイド実装があると追々便利になることもありますが、要件が無いまま実装してもそれだけ気にしなければならないことが増えてしまいます。

インフラの項でも記載しましたが、少ない開発リソースをなるべく必要なところに注力できるよう、なるべく不必要な実装はしないようにしてきました。


プログルのフロントエンドを支える技術

プログルを支えるGoogle Blockly

プログルのフロントエンド技術の中で核となるライブラリがあります。

それが、Googleが開発しているビジュアルプログラミング開発環境の Google Blockly です。

https://developers.google.com/blockly/

プログルの右側(画像赤枠)にあるプログラミングスペースのUI構築を担うライブラリです。

f:id:codeforeveryone:20191118142442p:plain

この「〇〇前に進む」などのブロック一つひとつにJavaScriptのコードが埋め込まれており

f:id:codeforeveryone:20191118142636p:plain

ユーザーがブロックをつなげていくと、その組み合わせ方に合わせて、JavaScriptコードのコンテキストが出来上がり、evalなどを介して処理系に渡して実行する…というフローで、ビジュアルプログラミングを実現しています。

プログルの開発を始めるにあたり、似たような機能を持つライブラリが無いか調査しましたが、プロダクション投入レベルで安定感のあるライブラリは、Blockly以外に見つかりませんでした。

日本語の情報はほぼなく、ベストプラクティスもなかなか見つからない中、試行錯誤しながら開発を進めています(おそらく日本で一番Google Blocklyに触れていると思います)。

上記の実行フローからお察しの通り、少々クセがあるライブラリで、npmの公式リポジトリがイマドキJSのモジュールインポートに対応していない(モジュール対応をサポートする非公式ライブラリはあります)*1などレガシーな部分があるため、プログルのフロントエンド技術は、このBlocklyとの相性に焦点が置かれています。

React.js

UIライブラリは、個人的な好みと海外の採用実績から、React.js を採用しています(MITのScratch 3.0や、Code.orgのHour of Codeが React.js と Blockly を組みわせて使っています。他にもBlocklyをReactから扱いやすくする小規模なOSSがあったりします)。

合わせて、ルーティングにReact Router、状態管理に MobX を使っています。MobXは実装がシンプルなところと、Blocklyの実行内容も含めた状態管理がしやすそうだったことから採用しました。

また、Reactアプリケーションの構築に create-react-app、カスタマイズに react-app-rewired を使用しています。

React.jsはViewを構築するライブラリのため、実装する要件に合わせて、様々なライブラリを組み合わせる必要が出てきます。それら組み合わせるライブラリのことをいちいち考えていくのが億劫だな…という思いから、なるべく時間をかけずにReact Wayに合わせられそうな create-react-app を使うことにしました。

create-react-app で賄えない実装要件については、react-app-rewiredで設定を上書きすることで、対応しています(ejectしても良いのですが、それだとせっかくcreate-react-app流に乗せたメリットが無くなってしまうので一旦やめました)。

その他、フロントエンドで使用している技術をまとめると、以下になります。

  • モジュール管理・タスクランナー
    • yarn
  • モジュールバンドラー
    • webpack
  • トランスパイル
    • babel(es2015〜、react)
  • フレームワーク
    • React.js
    • MobX
    • Blockly → node-blockly 経由で呼び出し(CommonJSモジュール対応をサポートしてくれる)
  • アニメーション
    • CreateJS(Blocklyの実行結果を描画するために使用します。もう少し使いやすいライブラリ無いか探し中…)
  • その他
    • Bootstrap 4
    • ESLint
    • Jest(ほぼ導入しただけで終わってしまった…)
    • FlowTypes(ほぼ導入しただけで終わってしまった…)

プロダクトの規模が大きくなるにつれて、ソフトウェアテストなどの基盤部分を整えていく必要性をひしひしと感じています(このあたりの知見がある方、ヘルプミー😢)。


その他開発を支える技術

その他、プログルの開発で使われている技術要素やサービスもご紹介します。

  • GitHub
  • Kibela
  • CircleCI
  • Heroku
    • 社内のプレビュー環境に使用しています
  • Google Analytics
  • Google Tag Manager
  • Google Form
    • お問い合わせフォームなどで利用しています。便利
  • Google Apps Script
    • お問い合わせフォームの通知や、SlackにGAの計測情報を送ったり、いろいろなところで使っています

その他、みんなのコードで使っているツールを↓にまとめたので、よかったらご覧ください。

www.wantedly.com


最後に

使っている技術スタックから選定時の思想まで、一通り書かせていただきました。これからも要件に合わせて積極的に新しい技術を取り入れ、エンジニアの「新しいものを作りたい」という想いと開発のモチベーションを大切にしていきたいと思っています。

とはいえ、ここまで技術選定から、環境構築、実装まで自分ひとりで行ってきたため、未熟な点だらけだと思っています。プログルをより良いプロダクトにするためには、まだまだやりたいことがあり、仲間が必要です。

この記事を読んで興味を持っていただいた方、ぜひお気軽にご応募ください🙂(カジュアルにランチ🍴からでもOKです!)

www.wantedly.com

*1:前回の記事に公式対応した話が書いてあります!techblog.code.or.jp