Firebaseを使い、Scratchで相互通信する

Google の Firebase には Realtime Database というものがあって、複数のアプリケーション(デスクトップPC、スマホ、M5Stack などなど)を使って同期ができます。って記事が、あちこちにあるので、ならば、Scratch でもできるのでは?と思って作ってみたのがこれ。

image

1画面にはなっていますが、デスクトップPCからノートPCにリモートデスクトップ表示しているところです。別のPCでスクラッチを起動しておいて(ひとつのPCでは複数起動できないので)、片方のオレンジ猫を動かすと、もうひとつのオレンジ猫が動きます。

直接通信させることもできるのですが、Google の Firebase を経由させます。

image

Scratch なところは、デスクトップアプリ(WPFとか)でもよいし、スマホアプリを Xamarin で作ることもできます。便利かどうか別として、まあ、こんなことができるということで。

Firebase の基本的なところは、

C#でFirebaseを使ってみよう!(1) FirebaseとEmail-Password認証 – こっちみないで(´・ω・`) http://kmycode.hatenablog.jp/entry/2017/02/09/205655

Firebase Realtime Database のデータ保存、取得、ストリーミング受信実験( ESP32 , M5Stack ) | mgo-tec電子工作
https://www.mgo-tec.com/blog-entry-firebase-realtime-database-sever-sent-events-esp32-m5stack.html

なところを参考にしています。Firebase は API KEY を取得してアクセスするのですが、そのままだと誰でもアクセスできてしまうので、一応ユーザー名(メールアドレス)とパスワードでガードを掛けます。

C# や F# から Firebase を扱うときは、NuGet で次の2つを追加します。

  • FirebaseAuthentication.net
  • FirebaseDatabase.net

内部で Rx が使われているらしく、System.Reactive や System.Reactive.Linq などが同時にインストールされます。

先の記事では、C# でサンプルが書かれているのですが、FireScratch の場合は都合上 F# で書いています。まあ、以前作った NetScrattino が F# だったので、それを踏襲したかっただけなんですけどね。

Firebase 自体は NoSql なので、JSON 形式でごっそりとデータを置きます。

image

こんな風に、/scratch/firecat というパス(フォルダーのようなものか)の下に、データが置かれます。謎な文字は識別子みたいなものですね。プロパティとして、From, To, Text, X, Y を置くためには、下記のようなクラスを作っておきます。

type Data() =
	let mutable _from : string = ""
	let mutable _to : string = ""
	let mutable _x : int = 0
	let mutable _y : int = 0
	let mutable _text = ""

	member x.From with get() = _from and set(v) = _from &<- v
	member x.To with get() = _to and set(v) = _to <- v
	member x.X with get() = _x and set(v) = _x <- v
	member x.Y with get() = _y and set(v) = _y <- v
	member x.Text with get() = _text and set(v) = _text <- v

C# だとこんな感じ

public class Data
{
	public string Text { get; set; }
	public string From { get; set; }
	public string To { get; set; }
	public int X { get; set; }
	public int Y { get; set; }
}

このデータクラスを、Firebase に対してアップロードします。F# で作る場合は、こんな風に、各種の関数を作っておくと便利です。詳しい中身は先の記事の C# コードを読んだほうがよいでしょう。

// ログイン
let singIn() =
     let auth = new FirebaseAuthProvider( new FirebaseConfig( apikey ))
     authLink <- auth.SignInWithEmailAndPasswordAsync( email, passwd ).Result
     printfn &quot;サインインに成功しました&quot;

// クエリを取得
let GetDatabaseQuery( path ) =
     let opt = new FirebaseOptions()
     opt.AuthTokenAsyncFactory <- fun () -> Task.FromResult( authLink.FirebaseToken )
     let client = new FirebaseClient( databaseURL, opt )
     client.Child( path )

// データをアップロード
let upload( data : Data ) =
     let query = GetDatabaseQuery( DatabasePath )
     query.PostAsync( data ) |> ignore
     ()
 // テキストを保存
let uploadText( text: string ) = upload( new Data( Text = text ))


 // テキストを取得
let downloadText() =
     let query = GetDatabaseQuery( DatabasePath )
     let results = query.OnceAsync<Data>().Result
     let items = results.Select( fun o -> o.Object )
     items.First().Text

// リアルタイムデータの監視
let startWatchingRealtime() =
     realtimeDatabaseWatcher <- 
         GetDatabaseQuery(DatabasePath)
             .AsObservable<Data>()
             .Subscribe( fun ev -> 
                 if ev <> null then
                     let text = ev.Object.Text
                     match ev.EventType with
                         | FirebaseEventType.InsertOrUpdate -> fireData <- ev.Object | FirebaseEventType.Delete -> ()
                         | _ -> ()
             )
     ()

これを、Scratch から呼び出せるように HTTP サーバーを作っておきます。スクラッチからは、/say/me/you/hello のようなスラッシュで区切られてデータが送られてくるので、これをパースして、Firebase に保存します。

もうひとつの PC では、リアルタイム監視(startWatchingRealtimeで登録)をしているので、これを fireData に保存しておいて、スクラッチのポーリング(/poll)に送られるようにします。

// Scratchから受信するためのHTTPサーバー
let Server( port ) =

    // firebase にログイン
     singIn()
     startWatchingRealtime()

    let listener = new System.Net.HttpListener()
     listener.Prefixes.Add(&quot;http://127.0.0.1:&quot;+(port |> string)+&quot;/&quot; )
     listener.Start()
     while true do
         let context = listener.GetContext()
         let res = context.Response
         let mutable data = &quot;&quot;
         let path = context.Request.Url.PathAndQuery
         match path with 
             | &quot;/poll&quot; -> 
                 data <- data + String.Format(&quot;text {0}\n&quot;, fireData.Text )
                 data <- data + String.Format(&quot;from {0}\n&quot;, fireData.From )
                 data <- data + String.Format(&quot;to {0}\n&quot;, fireData.To )
                 data <- data + String.Format(&quot;x {0}\n&quot;, fireData.X )
                 data <- data + String.Format(&quot;y {0}\n&quot;, fireData.Y ) // printfn &quot;%s&quot; path // printfn &quot;%s&quot; debug | &quot;/reset_all&quot; ->
                 printfn &quot;/reset_all&quot;
                 data <- &quot;ok&quot; | _ ->
                 let pa = path.Split([|'/'|])
                 match pa.[1] with   
                 | &quot;say&quot; ->
                     let me = pa.[2]
                     let you = pa.[3]
                     let text = pa.[4]
                     printfn &quot;say %s %s %s&quot; me you text
                     upload( Data( From = me, To = you, Text = text ))
                 | &quot;sayall&quot; ->
                     let text = pa.[2]
                     printfn &quot;sayall %s&quot; text
                     uploadText( text )
                 | &quot;movex&quot; ->
                     let me = pa.[2]
                     let x = pa.[3] |> int
                     printfn &quot;movex %s %d&quot; me x
                     upload( Data( From = me, X = x ))
                 | &quot;movey&quot; ->
                     let me = pa.[2]
                     let y = pa.[3] |> int
                     printfn &quot;movey %s %d&quot; me y
                     upload( Data( From = me, Y = y ))
                 | &quot;movexy&quot; ->
                     let me = pa.[2]
                     let x = pa.[3] |> int
                     let y = pa.[4] |> int
                     printfn &quot;movexy %s %d %d&quot; me x y 
                     upload( Data( From = me, X = x, Y = y ))
                 | _ ->
                     data <- &quot;&quot;
                 printfn &quot;%s&quot; path
         res.StatusCode <- 200
         let sw = new System.IO.StreamWriter( res.OutputStream )
         sw.Write( data )
         sw.Close()
     ()

スクラッチから送られてくるコマンド(say, sayall, movex など)は自分で定義をします。スクラッチのメニューでシフトキーを押しながら「ファイル」を選択すると「実験的なHTTP拡張の読み込み」が出てくるので、ここで作成した firescratch.json を読み込ませます。

image

{
   "extensionName": "Firebase Scratch",
   "extensionPort": 5411,
   "url": "https://github.com/moonmile/firescratch",
   "blockSpecs": [
     [ " ", "%s と言う", "sayall", "hello world." ],
     [ " ", "%s が %s さんへ %s と言う", "say", "me", "you", "hello" ],
     [ " ", "%s を X座標 %d にする", "movex", "me", 0 ],
     [ " ", "%s を Y座標 %d にする", "movey", "me", 0 ],
     [ " ", "%s を X座標 %d、 Y座標 %d にする", "movexy", "me", 0, 0 ],

    [ "-" ],
     [ "r", "自分", "from" ],
     [ "r", "相手", "to" ],
     [ "r", "X座標", "x" ],
     [ "r", "Y座標", "y" ],
     [ "r", "メッセージ", "text" ],
     [ "-" ]
   ],
   "menus": {
     "OnOffValues": ["ON", "OFF"]
   }
 }

サーバーを立ち上げて、コマンド待ち状態になると「その他」のところがグリーンになります。

image

これを2つのPCで起動させて、スクラッチ同士で通信させたのが、https://twitter.com/moonmile/status/1044440471823478784 にある動画になります。

相互通信にしたいところだけど、ひとまず一方向だけのスクリプトを

送信元のスクリプト

送信先のスクリプト

サンプルコード

https://github.com/moonmile/FireScratch

カテゴリー: Scratch | Firebaseを使い、Scratchで相互通信する はコメントを受け付けていません

夏休みの宿題の読書感想文を星新一ショートショートで書いてみるテスト

中学生もすなる読書感想文というものを星新一ショートショートで記してみるなり、ということで、奥さんに「書けるわけない」言われたので原稿用紙5枚(2000字)ぐらい書いてみるテスト。この位だったら30分位でさっと書けないとアカンよ。

絵本 星新一ショートショート | 星 新一
https://www.amazon.co.jp//dp/4048544519

~~~

星新一といえばショートショートSF作家として有名だが、ショートショート以外のものでは「人民は弱し 官吏は強し」という自伝っぽい本がある。星新一の父親が経営していた星製薬の話なのだが、色々官僚に虐められたという話だ。小学校の頃にSF文庫を読み、中学になってからはアシモフやらディックやら翻訳モノを読んでいた自分にとって、筒井康隆と星新一はちょっと特殊な日本のSF作家という存在で、真面目な印象を受ける星新一とおちゃらけた筒井康隆の文体は対象を為していた訳だが、実像のほうは星新一ほうが波乱な人で筒井康隆のほうが常識人というのが面白いところでもある。作家が内面にあるものを「小説」として表層化するときに、どのようにねじれていくのか(中二病的な言い方をすれば、「コンプレックス」なんだけど)の体現者二人という感じで見ていた。そんな中で、ショートショートという軽めであり、一見思想的なものを含まない星新一のもうひとつの顔として「人民は~」をよみ、再び星新一のショートショートに戻ると、ちょっと違った皮肉が文章の中に込められていることが分かる。同時代的には小松左京、横田順弥、半村良がいるのだけど(ええと、「幻魔大戦」の平井和正はちょっと特殊だし、「グインサーガ」の栗本薫も特殊ではあるので)、あまり作家像がみえないところに星新一のショートショートがある。そういう作家性のないところは、日経の星新一賞にAIをぶつけてみようというアイデアにも表れている。文体というものが作家性の大切な要素ではあるものの、ショートショートという中ではアイデア重視とそぎ落とされた文体の中で、要素だけが残された面白さに焦点が合わされているところにある。加えて言えば、星新一のショートショートの挿絵が一貫して和田誠だったところに奇妙な一致を見ることができる。短い文章は短歌や俳句のようなものではあるけれど、それよりも長く、しかし長編よりは短く、作家性を思わせるところが少ない判明、まさしく「星新一の描く」ショートショートである、と匂わせるような断然とした雰囲気が其処にはある。だから、実は、絵本になったショートショートは奇異ではありつつ、一見して半身を失った星新一ショートショートのような気もしないでもないのだが、いや、それはどうなのだろうか。まだ見知らぬ小説、まだ見たことのない挿絵に対して初めて面するとき、昔の星新一&和田誠ペアのショートショートを知らないのであれば、絵本となったショートショートは、実は本来の星新一のショートショートを真面目に眺める機会なのかもしれない。
実はクレイアニメのような図柄、そして短い物語の組み合わせは、数々の教育テレビ(Eテレ)の10分アニメを思わせる。ニョッキだとかポルタだとかそういうショートアニメにはちょっとしたストーリーが含まれていてちょっとした感動(子供向きだから?)が含められている。実は、これらのショートアニメは10年前以上に作れたものが多く、今のEテレのものを見ると解るけど、サイズが4対3になっている。新作が作られてないのか、それても旧作を発信することでコストを抑えているのかどうかは分からないが、これも初見であればそれが旧作であろうと新作であろうとあまり関係ない。始めてみる子供(大人でも)からすれば、それは興味を引く面白いお話である。それと同じく、絵本として再構成された(文章も再構成されているような気がする)星新一のショートショートは、大人向けのちょぴりとした皮肉(政治的な皮肉とかブラックジョーク)がある。禁じ手がいくつかあって、性行為と殺人と時事風俗は扱わなかったはずだが、「おせっかいな神々」には禁じ手を破っているらしい。ちょっと覚えていないけど。とりあえず、その手の良く分からないブラックジョークは絵本のほうでは省かれている。子供向けだし、内情が分からないとおもしろくないジョークを書き連ねてたって子供には面白くない。いや、大人でも面白くないのである。
だから、いろいろなバックグラウンドを知らなくても面白いSFショートショートが成立するというのがはなかなか珍しいことでもあり、うまいぐらいに3本用意したなとうならせるところがある。そう、ネタバレをすれば毛の生えたタコの話は、前知識がなくても奇妙で面白いし、ちょっぴり怖い感じがする。それは心理学的に怖いのか、ヒトが進化した中で必ず奇妙なものとして見えるのか、そこまでは突き詰めないけど、そういう作風が絵本の中からも出て来るのが星新一ショートショートの普遍性というものだろう。

~~~

以上、これで30分ちょっと。40字50行で2,000文字です。

カテゴリー: 書籍 | 夏休みの宿題の読書感想文を星新一ショートショートで書いてみるテスト はコメントを受け付けていません

Surface RT を引っ張り出して性能を確認してみる

Surface Go が流行りそうですが、手元にある Surface RT を引っ張り出して電源を入れてみる。

Surface RT を購入して初日の所感を | Moonmile Solutions Blog にある通り、2013年3月に購入。直前に初代 iPad を購入しているので、散財といえば散財なのですが、いわゆる「Windows ストアアプリを自前で入れられる」ってのがキーポイントです。今でこそ、Xamarin が使えるようになって iPhone/iPad アプリが簡単に作れるようになっていますが、当時は Objective-C で作らないといけないので、「私にとっては」結構な苦痛だったんですよね。まあ、その分、iPad アプリの商機というものがあった訳ですが…iPad 専用の絵本とかが流行った頃の話です。

中身は ARM なので、通常の Intel x86系の実行ファイルは動きません。しかし、arm でコンパイル&ビルドして実行ファイルを入れれば動作する…ハズなのですが、当時 Surface RT は「安全」のために arm の実行ファイルを直接入れて実行させることを嫌ったのです。脱獄すれば実行はできるものの、通常の状態で arm のバイナリが動かないのは、かなりマイナスでしたね。実際マイナスなので、Surface RT は Microsoft イベントにとっては暗黒扱いになっているようです。

先の記事にも書いてある通り、業務用に使うのであれば Intel CPU が積んである Surface Pro を買ったほうがいいんですよ。Surface RT は Office が付いているとはいえ完全に廉価版扱いで、iPad の値段よりも安かった。おそらく原価割れではないかと思うのですが、定かではありません。

Windows Update が走る?

確か、最後の Windows Update(Windows 8.1のアップデート)をして、電源を落としたはずなのですが、何故か更新プログラムを延々と構成し始めます。

30%を構成しましたの後、リセットがかかって、再び30%構成したあとにリセットが掛かる、という無限ループに陥ってしまったのか?という状態なのですが…なんとか、6時間後位に起動しました。一時は工場出荷にリセットなのか?とも思って回復 USB を用意したりしたのですが、まあなんとか。

Excel 2013 が動くよ

Surface Go でも話題になっていますが、Surface RT は Office 2013 がバンドルされています。これ、MS 社員も「Office がバンドルされているから安い」と言っていた覚えがあるのですが…まあ、タブレットで Office は使わないですよね。メールとかで貰ったときに便利なのかもしれませんが。

当時は、Office 365 は無かったし、Google のスプレッドシートが出たばっかりで動作も鈍かったので、arm のデスクトップ上に Office を載せたのはそれなりに意味があったのですが。これ、Excel VBA が使えなくてですね、キーボードがないと使えないし、やっぱり閲覧オンリーでしかないんですよ。

VLC で動画が見れるよ

動画(mp4)を見るのに、VLC を使うわけですが、当時はストアアプリ版というのがなくてですね。標準装備の「ビデオ」しか使えませんでした。標準のビデオのほうは、コーディックが少ないののと、ストリーミングに対応していないので、いまいちだったんですよね。

今はストアアプリ版(Windows 8.1にもあった)の VLC があるので、ストリーミングを含めて NAS 経由で動画を表示できます。ただし、Surface RT の頃の Wi-Fi が 2.4GHz のほうにしか対応していなくて、帯域が足りなくて少しブロックノイズが発生します。実写のほうはそうでもないのですが、アニメ絵は mp4 の圧縮に不利なのでブロックノイズが走りがちです。

自前の Windows 8.1 アプリを入れる

大抵の人は、Windows 8 から Windows 10 にバージョンアップしてしまったでしょうが、Surface RT は Windows 10 のラインナップから外されてしまって 8.1 までしか動きません。ちなみに、

うちの家PCは、奥さんの希望により 8.1 で止まっています。まあ、普通に使っている分には 8.1 も 10 も変わらないんですよ。むしろ、10 にアップデートするときに中にあるソフトウェアが動かなくなる&個人データが一部消される、というリスクがあって 8.1 のままです(8 から 8.1 のとき結構消されたのよ)。

Windows 10 の UWP アプリ(ストアアプリ)は、別途ウィンドウを開けるようになったので、あまり覚えている人はいないかもしれませんが、8.1 の頃はこんな風に全画面オンリーでした。でもって、分割表示するため真ん中にバーがでるんですよ。

これ、フラットデザインとして UI デザインとしてどうなの?って気もしないでもないのですが、改めて使ってみると「タブレットならば、この全画面が使いやすい」ですね。デスクトップ PC の場合、全画面を占領される(正確にはモニタ1枚)のは、ちょっと…な気もしますが、Surface RT のように比較的狭い画面ではせいぜい左右に2分割するしか余裕はありません。

こんな風に、右画面で動画を流しながら、左画面で Redmine の障害報告を読んだりできます。当時、ツイッターを流し見しながら仕事をしていた人も多いはずです(今でもそうだけど)。当時、iPad はシングルタスクで画面を表示していたので、この Surface RT の並列性は結構な優位点だったハズなのですが、活かされなかったですね。

因みに、Windows 8.1 のストアアプリは、Visual Studio 2015 でビルドができます。これを arm 版でビルドをして Surface RT で動かすわけですが、リモートデバッグツールを Surface RT に入れないといけないんですよ。なのに、最新である Visual Studio 2015  Update 3 のリモートデバッグツールは、x64とx86しかなくて arm 版がありません。たぶん、入れ忘れだと思うんですけどね。仕方がないので、無印の Visual Studio 2015 環境を使ってリモートで Surface RT にアプリを送り込んでいます。

Scratch はちょっと重たい

Surface RT 当時、Scratch がどの程度だったのかは覚えていないのですが、今 Scratch を動かしてみると結構重たい感じです。arm & デスクトップ側のアプリ導入禁止により、ブラウザでのみ Scratch が動きます。ストアアプリ版の IE(Edgeとは違う)の Javascript が不足するのでは?と思ったのですが、そういえば普通に Flash が使われているので、元気に動作しています。

ただし、キーが打てないのと、ブロックの動かし方がタップでは微妙なので、Scratch プログラミングを Surface RT 上でできるか?というと難しいですね。普通に、無線マウスと無線キーボードを付けたほうが利用しやすいでしょう。

当時、iPad から Flash が排除される、Android のブラウザでは艦これが動かない、ということで唯一?艦これが動くタブレット端末だったハズですが、どうだったかな。Surface RT で「艦これ」始めた – だるろぐ を見る限り、遅くて駄目だったらしい。

野球ゲームでは重たい Scratch ですが、マリオフラッピーではするすると動きます。なので、プログラムによるのでしょう。

5年前の機種なのに、これだけ元気に動くのは結構優秀な機種ですよね。初代 iPad は液晶が駄目になり、2台目を買い、その2台目もバッテリーが切れて、Apple で3台目に変えて貰っています(1万円で)。

ノートPC も Windows 98 やら Windows XP が元気に10年以上も動いていたりするので、結構 Windows 機種は長持ちするほうなんですよ。まあ、Linux 機の場合は、30年前以上から使っている vi や emacs が今でも動くので、ソフトウェア互換は抜群です。そういう意味では、Slackware から Linux を使っている世代としては、Ubuntu も大差なく使えます(ターミナルレベルではw)。じゃあ、mac はどうなのかというと、以前からある apple script を地道に継承していたりして、そういう姿勢は各種独特です。

そういうところを踏まえて、Surface Go がどの層を狙っているのかあるいは狙っていないのか、が興味深いところですね :)

カテゴリー: 雑談 | Surface RT を引っ張り出して性能を確認してみる はコメントを受け付けていません

サブ開発環境を Ubuntu 18.04 で準備する

手元で使っている業務PC は、2013年に自作(他作でもあるけど)したもので、その記録が 最強.NET開発PCを作るよ(その1) | Moonmile Solutions Blog にある。かれこれ、5年になるけど、メモリ 64GB を積んだ .NET 開発マシンというのは伊達ではなくて、今でも十分可動している。途中で、2回ほど SSD が逝ったのは熱が籠ってしまったのか、Windows 10 にしてハードに使い過ぎたのかは分からないが、SSD を交換して(つまりは OS を再インストールして)現役状態である。

現時点では、主な稼働状況としては、

  • Windows 10 Pro
  • Visual Studio 2017 が3,4枚稼働
  • Word/Excel が3,4枚稼働
  • VMWare が 2つほど常時稼働
  • Amazon Video か VLC が常に動いている

状態で、なんというか、夏は熱暴走が気になるところで常にCPUは50度位。CPU 稼働はこんな感じで、面白いのは OS が乗っている C ドライブはほとんど稼働していない状態(おそらくキャッシュに乗っているのだと思う)という感じです。

image

Windows Update による再起動が困る

確か、Windows 8 の頃にはあまりなかったのですが、Windows 10 では PC がスリープした状態でも夜中に勝手に起動して勝手に Windows Update をして、勝手にシャットダウンしていうことが多々あります。たまに、朝まで電源が付いているときもあるのですが、最近は月一は PC 落ちている状態が多いですよね。

これ何が困るって、作業を途中にしてスリープしているのに、PC を再起動するものだから途中のアプリが勝手に落とされるんですよ。Excel や Word が途中で落ちて、自動修復状態になってしまったり、Visual Studio で大き目のものを開いているのにまた開き直さないといけない訳です。最近では、更に妙なことになって、再起動時に Visual Studio が 10個位勝手に起動したりします(たぶん、以前に画面を復活させようとして、デバッグ中に死んだ Visual Studio も立ち上げてようとしているのが原因)。

一番困るのは、VMWare へのシャットダウンが十分ではなくて、VMWare で仮想環境を立ち上げたままスリープをすると、Windows Update の再起動のおかげで、VMWare が強制終了されてしまうんですよ。これで、何回か VMWare 上の Linux マシンや Windows が修復起動になったりしてます。まあ、まめに仮想環境自体もスリープさせればよいのですが、そのあたりも手間だし忘れるし。

そんな訳で、仮想環境の VMWare 分を何処かに引っ越せないか?と考えていました。

じゃあ、Ubuntu + VMWare の組み合わせを考えよう

正攻法ならば、Windows サーバー機を用意するのがいいんですが、自宅が仕事場所でもあるし、サーバー機のファンがうるさいのも困るところなので、通常の静音型 PC を使いたい。

どうせなので、ベースは Ubuntu にして ROS とか React-Native あたりも試してたい。Android のビルドを VMWare 上でやると遅くて大変なので、実機 PC でやりたい。ということで、Ubuntu を入れる前提で PC の追加購入を考えました。

image

スペックとしては、

  • メモリ 32GB
  • SSD 512GB + HDD 1TB
  • CPU Intel i7-7700
  • グラボは無し
  • OS無し、Office無し
  • 静音ファンで少しだけプラス

ドスパラの Magnate GE(マグネイト GE)ミニタワーパソコン(PC) 7768|パソコン通販のドスパラ【公式】 をベースにして税込みで13万円也です。

ゲームや映像に使う訳ではないので、グラフィックボードはオンボードのみを使う。メモリは 64GB にしたいところだけど、結構な値段がプラスになってしまうので 32GB にしておく。これは、常時 VMWare を動かす予定なので、16GB だとちょっと足りない(仮想で、4GB x3 位動くので、ホスト OS が圧迫されてしまう)。

Ubuntu + VMware の時は UEFI を切る

Ubuntu 18.04 LTS の DVD を使ってインストールした訳ですが、結構すんなり入ります。ブラウザを使ったり、メールや Slack などを使うだけならば Windows じゃなくてもいい感じですね。Mac の場合、どうしてもスペックが制限されてしまうので、メモリを摘んだりして標準以上にしようとすると Windows PC の選択にならざえるを得ないのですが、初心者であっても Linux 機を使える感じにはなっているようです。

ただし、ハマりどころもあります。

image

Windows で VMWare や VirtualBox で仮想環境を作るときはすんなりといくのですが、Ubuntu でハマりました。何故か、VMWare Player をインストールしたあとに、起動しようとすると、/dev/vmmon が無いと云って起動できません。何度か、Ubuntu 自体をインストールし直して Virtualbox を入れたりしたのですが、こちらも起動できません。

要は、マシンが UEFI が有効になっていて、インストールする OS ( Ubuntu 18.04
LTS ) の署名とのずれがある(そもそも署名がない?)らしいのです。そういえば確かに、2,3年前に「もともと Windows が入っていたノート PC に Ubuntu を入れようとした入れられない問題」ってのがあって、それのことです。VMWare や Virtualbox が入れようとしているドライバーに署名が UEFI BIOS の署名と異なっているので駄目ってことですね…たぶん。

ネットを見るとあれこれ解決方法があるみたいなのですが、手っ取り早いのは BIOS の画面を開いて UTFI を使わないで起動することです。この画面ではデフォルトで「Windows UEFI mode」になっているので、「Other OS」に切り替えてしまいます。UEFI その1 – UEFIとセキュアブートについて・UEFI環境でOSを起動するOSローダー・UEFI対応PCとBIOS対応PC – kledgeb を参照してください。

そうすると、無事 VMWare Player が起動できるようになって、ゲスト OS に Windows 7 を使ったりできます。この画面は、もともと業務 PC のか仮想環境を Ubuntu のほうに引っ越して起動させています。

image

この仮想化された Windows 7 へは、業務 PC(Windows 10)からリモートデスクトップができるので、今までと同じように開発ができます。ネットワークを通す分だけちょっと遅くなるけど、Azure などで仮想環境を作るよりも操作は素早くなります。ファイル転送も楽ですからね。

VNC で接続する

Ubuntu + VMWare は基本モニタを使わずに作業をする予定です。業務 PC からリモートデスクトップで仮想環境にある Windows 7 に繋ぎに行くか、Ubuntu へ VNC で接続するかというところです。

Windows 10 から繋げられるように Screen Sharing の設定をしておきます。

image

クライアントは、VNC Viewer や TightVNC を使います。

React Native の環境を作る

さて、Ubuntu を使うもうひとつの目的である React Native の環境を作ります。React,Angular,Vue.js,React Nativeを使って学ぶ はじめてのフロントエンド開発 の第9章だけ見て分かったような気になっても仕方がないので、手を動かします。

ただ、素の環境から作るのは結構手間がかかるみたいですね。これも落とし穴が結構あります。

  • Java SDK のインストール
  • Android IDEのインストール
  • nodejs のインストール
  • react native のプロジェクトを作る
  • アプリを実機で動かす

基本は Getting Started · React Native にある手順に沿って行きます。nodejs は Installing Node.js via package manager | Node.js にあるらしい。

あれこれやって、エミュレータと実機 Android で動かすところまでできました。

$ react-native init aproj

aproj というプロジェクトを作る。

$ adb devices
$ adb reverse tcp:8081 tcp:8081

実機 Android で動かす場合は、adb reverse で 8081 を設定する。

$ react-native run-android

デバッグ実行する。

という手順です。このあたりは再び仮想環境で試してみる予定。

↓は参照先

ReactNative for Androidで実機をデバッグに使うには | Theoretical Cat https://www.yslibrary.net/2015/09/17/reactnative-for-android-debugging-on-real-device/

画面では、こんな感じでやると、実機 Android で React Native が動作します。

image

react native で実機を振ると menu が出るってことになっているんだけど、うちだと出ないですよね。なので画面の更新ができない(苦笑)。エミュレータのほうは R キーが効くので、実機の振動 API の問題ですかね?

“R” キーを2回送ればいいので、adb shell input  を使えばコマンドラインから更新ができます。

$ adb shell input keyevent KEYCODE_R KEYCODE_R

あとは、ラズパイの Android Things に接続するとか、ファイル共有のための samba の設定とかがあるので、それはまた今度。HDD 1TB を何処かにマウントしないといけないので。

カテゴリー: 雑談 | サブ開発環境を Ubuntu 18.04 で準備する はコメントを受け付けていません

高知風素麺とMicrosoft MVP

なんか、7月1日に続々と「Microsoft MVP に落ちました」報告がツイッターに上がっていて、「?」となって「Microsoft MVP bye」で検索するとあちこちで落ちたツイートが発生していしていました。どうやら、6月末に Microsoft から「落ちたよ」メールが届いていたらしいんですね。ちょうど 7月1日は日曜日だったので、合格したよメールが翌日の7/2に届くようになるので、妙な1日だったという。

ちなみに、私の場合は、

  • Visual Studio and Development Technologies を受賞
  • Windows Development は落選

ってんわけで1勝1敗です。Windows Development のほうは、Windows IoT Core じゃだめなんですかね?ホロレンズじゃないとだめ?…な感じもあるにはあるけど、まあ、Windows IoT Core と Android Things を Orange Pi とか Pine64 とかで使ってみようよ、ってなわけで引き続きこっちはこっちでやっていきます。碧蓝航线とAzureの組み合わせとか。

ところどころ「今回はなにもやっていなかったし、さすがに~」のコメントが散見するんですが、何もやってなかったら、受賞できないのは当たり前じゃん!ちゃんとアピールするような実務を積み重ねていた人が受賞するのが筋でしょ!と思うんですが、どうなんですかね?むしろ、やねうらおさんみたいに辞退するのが筋ってもんじゃないでしょうか?何もやっていない、という自覚があるんだったら。

とはいえ、個人でプログラミングやっている限りで MSDN 一式使えるのはありがたいところなので「ええ、20万円分(プロフェッショナル版の分しか使わないので)は働きますよ」気分でやってます。というか、最初の受賞目的がそれなので、8年経ってもそれなのです。その前は自腹で年間10万円以上払っていたし、今になってもその気分は変わらず。というか、それ位払えない現状が…というのもあるのですが、まあ、今年も 20万円分だけは Microsoft MVP のために働かせていただきます。ちなみに、単価で言えば20万円というと当社比で1週間ちょっと位なので、あしからず。つまりは、それぐらいやればいいんですよ。

ちなみに、Microsoft MVP を前面に出して仕事を取れたことは1回しかありません。これ非IT業界では知名度が低いので仕事には繋がらないかも(「営業」活動していないのは重々承知なんだけど)。けど、就職/転職には有利っぽいので、若手の方はどしどし応募して、ところてん形式に上のほうから押し出していくのがベターですね。今回 MVP の総人数もごっそり減ったことですし Microsoft としても「若返り」を図りたいでしょう。

高知風そうめんが美味い

それはさておき、久し振りに TV でケンミンショーという番組を見て「高知風そうめん」が簡単そうだったので作ってみました。

要は、素麺の上にちらし寿司の具をのせる感じなので、誰でもできそう。

高知風そうめん | お美津さんちの赤いサラダ
https://ameblo.jp/akai-salad/entry-11009761599.html

を参考にして「しいたけの甘辛煮」さえ作れば、大丈夫です。これが味のベースですね。あとは、錦糸卵ときゅうりがあれば3色揃うからこれで十分かと思います。ケンミンショーの番組では、レモンの薄切りにもみじおろしがあったけど、それは無くてもok. ゴマをまぶすのは忘れてしまいました。まあ、ちらし寿司なんだから何でもいい気もするけど。

結構、たくさん食べれるので、揖保乃糸一袋(300g)を全て茹でても4名(一人は小2だ)完食できます。お試しあれ。

カテゴリー: 雑談 | 高知風素麺とMicrosoft MVP はコメントを受け付けていません

プログラマの視点から「プログラム教育」騒ぎを見てみる

2年目のプログラミング教室 | Moonmile Solutions Blog を書いたときに思ったことを少し補足。

「プログラミングを何処で学びましたか?」と問われたとき、ほぼ100%「独学です」と答えるしかない世代(大学にはまだ情報科がなかったし、科目としてはIEEEの実数計算を学ぶ位なものだったから)から見れば、「とあるプログラム言語を学び、将来に備える」という発想で、プログラミング教育をしようとするならばナンセンスだろう。小学生時代に学んだプログラム言語そのものが就職する頃にも有利に働く、訳がない。いや、COBOL とか Fortran とかは長く続いている言語だし、そういう意味では Javascript だって C++ だって、将来的にレガシーな「古典言語」として読むことは必要になるかもしれないが、それは古典でしかなく、現代文ではない。

だから、プログラミング教室を請け負うときに考えたのは、将来的に役に立つあれこれの話ではなくて、

  • 今、情報が取り入れやすいプログラム言語を扱う
  • 今、何か実現しやすいプログラム言語を扱う

という同時代性に重きを置いて、Scratch、Python、C言語(Python はまだ取り込んでいないし、C 言語 + Arduino の組み合わせはまだなんだけど)という柱を考えた。ぼちぼちと始まるであろう学校の「プログラミング教育」は、教育要領としてプログラム言語に負うわけではなく「論理思考」に重きがあるので、実際にキーボードをぽちぽちと打つ時間は1,2時間程度でしかない。むしろ、とあるキーワードを Google を使って検索して何かの調べ物をするとか(既に、小中学生レベルでやっている)、マウスを使ってポチポチと学習ソフトを動かすとか(マウスは、4年生ぐらいだと動かせない子が多い)のほうが大切だったりする。スマホでゲームをダウンロード&遊んだり、任天堂DSで妖怪ウォッチのRPGを進めたりすることは、小学2年生でも軽くできることなのだが、「能動的に」パソコンやスマホを使って「調べる」ことはなかなか難しい。Youtube でマリオの動画を見たいときに「マリオ」で検索するとか、攻略で詰まってしまった Wii の毛糸のカービィを調べるために、スマホで「カービィ」と動画を見ていって、ちょっとずつ解いていくとか、そういう間接的な使い方は難しい。そう、昔小学校の頃に「辞書の引き方」という授業があったのだが(今は、何故か学校の辞書を使ってちょっとしかやらない。自分の辞書を買わない)、とある目的を達成するのには少しだけ回り道をして道具を揃えないといけない&道具を使いこなさないといけない、というのが重要になってくる。そう、RPG でいう道具集めみたいなものだ。

そういう「道具」としての「プログラム言語」の場合は、今昔に置いて古くなったりするものだから直接的に扱っても仕方がない。しかし、何かを実現しようとするときに、道具としてのプログラム言語を扱う(あるいは検索サイトを使う、将来的には音声を通じてAIに尋ねる)ための「組み合わせ」としての論理能力は重要である。いや、そもそもが、プログラム言語というものはロジックの合わせであり、とあることを実現するために引数を与えると、何らかの処理が行われて結果を返すという「関数」的な使い方に終始することになる。

なので、プログラム言語自体の選定にあれこれするのは無意味である。無意味ではあるもし、特殊過ぎる性能(とある手段をクリアするために作られた道具)を扱うためにプログラム言語を選定しようとするのも間違いである。直前(2年後に就職とか)ならば別なんだけど。

だから、教える側が馴染みに深いプログラム言語を扱って(この場合は「教師」となる)、生徒や児童のサポートができればよい。たとえば、プログラム言語の学習書のように「int x;」とは何かとか、宣言とは何かとか、for文とは何か、とかみたいな文法的なものはいらない。そのあたりは道具立てでしかない。同じことは Scratch の様々なブロックを扱うときにも言える。

それよりも、もっと目的となること、例えば「猫を端から端まで動かしてみよう」みたいなことが必要で、Scratch で言えば、繰り返しのブロックを使って端に触れたかどうかを判定するとか、C 言語で言えば width を設定しておいてfor文で最大値に達するまで繰り返すとか、Unity ならどうするとか、Python を使うとどうなるとか、というのが問いとして適切になる。つまり、教える側としては「繰り返しのブロックを使ってみましょう」というようなプログラム言語の文法から入るのではなく、「地球を太陽の周りを回らせてみましょう」という何かを達成させるために、道具としてのプログラムを使うというスタイルをとるのがベターであるし、それがプログラミング教育の本質であろうと私は思う。

ちょうど、数学の問題を解くのと同じなんだけど、異なるのは答え(正確には試行過程なんだけど)はひとつは限らない。例えば、Scratch で、

  • 猫がマウスカーソルを追うようにしてみよう

としたとき、正解ははひとつではなく、実際に3種類ぐらい皆(小学3-6年生)が作ってくる。ああ、なるほど、そういう方法もあるのかと感心するぐらい様々な方法がある。といういことを覚えておいて欲しい。だから、教科書通りの解き方をしてないからといって「×」にするのは、それこそ「×」だ。これを実施するためには、

  • 目的(達成条件、クリア条件)が明確になっていること
  • 道具立てを縛らないこと
  • でも、わからない場合は、ヒント(補助線のようなもの)を出しても良い

を教える側が念頭に置く必要がある。逆に言えば、児童/生徒の「何をすれば正解なの?」の意識を壊す必要があるということ。何をやっても、正解に至る≒目的を達成することは可能であるということに気付かせる必要がある。

カテゴリー: 雑談 | プログラマの視点から「プログラム教育」騒ぎを見てみる はコメントを受け付けていません

ノートパソコンの電源アダプタから5Vを取り出す

電子工作をしていると、5V電源をよく使うのですが、これは乾電池2個だと足りなくて昇圧するか電池3個を使う。同時にサーボモータやモニタを繋げるときは9Vが欲しくて、高価な500円の9V乾電池を買ってくるか、電池6個を使って9Vを取り出すか、ということをやっている。

電池だと消耗してしまうので(充電タイプを使うけど、連続運転という訳にはいかない)、5V のほうはスマホの充電器をつかうのはいいとして、9V はなんとかしたいところであった。

ふと、手元にあるあまりのノートパソコンの電源アダプタが使えるのでは?と、探してい見ると 【ACアダプタを減らしたい】デスクLED照明のACアダプタを減らす | Beヨンド なところがある。これはパソコン電源をつかっているけど、ノートPC のアダプタも直流で16V や 19V のものがあるので、適当に降圧してやれば 5V なり 9V なりが取り出せるだろう。

アダプタを加工し、降圧回路で下げる

ノートPC のアダプタは、各社様々でなんで統一しないのだろうか?ってほどたくさんある。勿論、それにはそれなりの理由があるのだが(これは後述する)、電圧も電流も様々である。高最近のノートPCだと、19V あたりが主流かもしれないが、手元にあるパナソニックの16Vの電源アダプタ―を加工する。このアダプタはノートPCを廃棄に出したときに、出し忘れてしまったものである。秋葉原とかで適当なのを中古で買っても同じことができると思う。

image

電源アダプタのコネクタは外形と内径が様々で、これにあったレセプタ(メスのほう)を秋月とかでかってくるのが正統なんだけど、どうせ使えるノートPCも捨ててしまったことなので、コネクタ部分を切ってしまう。コネクタは大抵の場合はセンターがプラスになっているが、逆のこともある。これはアダプタの裏に書いてあるので、それに注意して配線する。

降圧回路って、昇圧と違って比較的安い。Amazon.co.jp: zmart DC1.3-37V 2A 可変 DCDCコンバータ 5個セット LM2596 レギュレータ ステップダウン: おもちゃ 思い立ったが吉日ということで、amazon の御急ぎ便で届けてもらう。aliexpress で買うと100円/個ぐらいなのだが、早くためしたいので。ちなみに、降圧回路のいくつかのレビューを見ると、「壊れる」とか「不良品が」というのが頻発するので、予備を持ったほうが良いらしい。

あと大電流を流したいときは、ヒートシンク付きとかを買わないと熱くなりすぎるのだろうけど、電子工作の場合はせいぜい1,2A程度しか流さないので、これで十分。

可変抵抗をドライバーで反時計回りに回して降圧する。テスターで測って、だいたい9V になるようにしておく。これで、16V から 9V への降圧が完了する。

降圧、昇圧について解説はこっち
DC/DCコンバータ回路設計ガイド(1/10) | 電源ICのトレックス・セミコンダクター(TOREX) https://www.torex.co.jp/technical-support/application-note/design-guide-for-dcdc-converter/whats-dcdc-converters/

パルスでちびちび電流を流してやって、コイルで平滑化というパターンで、ここで時間差が発生するのがミソ。電子回路はやってないけど、電磁誘導とか電磁学を学んでいると解るんだけど、話は別だがオブジェクト指向のメッセージングに関係するときの「時間」絡みもここがポイントになる。設計時にはメッセージングって時間0で伝達するものと考えるけど(特に、MVVM のプロパティとかリアクティブとか)、実際はタイムラグがあるわけで、その時に DB 的なデッドロックとか遅延評価とかが関係してくる。なので、シーケンス図は必至なのだ、という話に繋がる。

16V から 9V と 5V を利用する

せっかくなので、降圧回路を2つかって、モニタ用の9V電源と、Pine64などの基板のための5V を同時に出すようにしてみる。

image

このモニタのバックライトに9Vが必要なのと、Pine64上で Android 7.x を動かすのに 5V2A が必要になる。程よく、戦闘少女R が動いているので大丈夫そうな感じ。

ラズパイ + Android Things を動かしても大丈夫。こっちは、5V 一本でいける。

image

これで、電源アダプタから 9V と 5V が長時間に取り出せるようになったので、電池のように電池切れの心配がなくなる。当然、モバイルにする場合はモバイルバッテリにすればよい。

手元のロボットアームも 9V 電源が必要なので後日試してみることにする。

何故コネクタの形状が異なるのか?

これ、5V と 9V を同時に作ってみて分かったのだけど、電源供給自体は両方とも micro USB なので、間違って 9V のほうを基板に差してしまうと基板が壊れてしまう、というミスが発生する。いくら気を付けても、コネクタの形状が同じだと間違って差してしまうことは避けれられない。

この対策としては、基板のほうに保護回路を入れるのもよいのだが基板のコストが高くなってしまう、ならば、間違えないようにコネクタの形状を変えてしまえばよい、ってのがノートPCアダプタの乱立というところだろうか。実は、同じ会社のものであれば同じ電圧のアダプタは同じ形状をしていたりする。また、ものによっては、IBM の電源アダプタが VAIO で使えたりする(同じ電圧であれば)。完全に互換性があるとはいえないけど、相互に似た電圧/電流であれば、同じ形状を使っていたりする。逆に、16V アダプタと、19.5V アダプタの形状は外径と内径が異なり、間違って刺し込めないようになっている。

と、これが理由だと思うんだけど、実際のところはどうなんでしょう?

おまけ、USB ハブに 5V 供給する

上記では、USB ケーブルの micro USB のコネクタだけを残して、反対部分はコネクタに変えていたのだけど、これを基板の数分作るのは面倒くさい、じゃあ、USB ハブに 5V 流してしまえばいいんじゃないか?と思って作ったのがこれ。

image

USB ハブのオスコネクタのほうを切り取って、ブレッドボードに差し込めるように加工してしまう。プラスマイナスは、あらかじめテスターで調べておく。

で、USB ハブのほうに、通常の USB – micro USB のケーブルを刺し込めば基板(ラズパイや Pine64など)への電力供給が楽になるのでは、ひょっとしたら4つ同時に供給できるかもしれない、と思って造ってみたのだが。

残念ながら、ラズパイ+Android Things の場合、立ち上げりのところで電流が足りなくて落ちてしまう。これはハブの定格を超える電流を流そうとしているからじゃないかなと思う。普通は500mA しか流れないので、ラズパイのように 2A 程度使う場合は無理なのだ。それでも Arduino を連結するときにはまくできるんじゃないかな、と考えたりするのだが。配線の太さが非常に細い(8本ぐらいしかない)ので、あまり大電流を流すと焦げてしまうかもしれない。

そのあたりは注意して。

カテゴリー: 組み込みボード | ノートパソコンの電源アダプタから5Vを取り出す はコメントを受け付けていません

2年目のプログラミング教室

上板橋あいキッズで、去年(2017年4月)から隔週でプログラミング教室を担当している。板橋の「あいキッズ」というのは、いわゆる「学童」で共働きの家の子供が親が帰ってくるまで「預け」られる場所になっている。預けられるとはいっても、昨今では小学生の半分の親は共働きなので、当然のことながら児童の半分はあいキッズにやってくる、ってなわけで、昔とは違ってかなりの人数が集まってくるわけだ。板橋区の「あいキッズ」制度は、学童単位でそれぞれの民間業者に委託しているので、小学校によってあいキッズ内で行う「プログラム」に差がある(それぞれの業者が何らかを企画するためだ)。そんな中で、上板橋あいキッズを担当している放課後NPOさんから話を請けて「プログラミング教室」ってのを隔週で1時間ほどやっている。

ちなみに無償ではなく報酬は貰っている。「子供のためだから」といってボランティアでは続かないと思われたのと(続く人もいるんだけど、どうも私は続かない)、実際なにがしかの時間が掛かっているためだ。十分とは言えないし、半分ボランティアな感じなんだけど、持ち出さないようには注意している(苦笑)。

以下、いくつか去年の話を書き留めておこう

ノートパソコンを用意して貰う

特に Scratch がという訳でもなかったのだが、念頭にはあったのと、できれば Python とかを教えたかったのでノート PC を用意して貰うことにした。ひとり1台が望ましいのだが、最低限でも2人で1台が使えるようにしたい。募集人数もそれに絞って欲しい旨を伝えて、中古のノート PC を購入して貰う。予算が潤沢にあれば(都なり区なりから出して欲しいよね)新品とかを買えるんだろうが、そうもいかないので、中古で1.5万円程度の Windows 7 を購入して貰う。これ、こちらで代理で探してもいいのだけど、その費用は貰っていないのであいキッズ側で探して購入して貰っている。

最初は8台からスタートしたと思う。機種はばらばらだが、ほどよく大き目のノートPCが用意できて、無線LANを使えるようにする。…が、ここで問題があって、プログラミング教室をやる部屋があいキッズ内の無線が届かない位置にになっていて、一応ブースターを購入&設定して貰ったものの、あまり接続状態がよくない。なので、初めの2回はブラウザでの Scratch だったが、急遽ダウンロード版の Scratch を使うことにする。学校の教室で Scratch をするときも同じ問題が発生するし、無線ルータの状態によっては人数分(ひとクラス30名とか)一斉に繋げると接続状態が確保できなかったりするので、今後も課題になる。

ただし、ネットワークが全然駄目というわけではなくて、個人持ちの無線ルータの設定をしているので本家の scratch.mit.edu に繋げないこともない。ただし、一斉に繋げたり大量にダウンロードするとパンクしてしまうので、「スクラッチのサイトだけ」という限定にしている。つまり、Youtube とかは駄目。即座に、プチンと切ることにしている。そこはルールだからね。

実に騒がしく統率できない

あいキッズなので、3年生から6年生までを対象にしている。初年度ということ双方ノウハウがないので、半年ぐらいは様子見な感じで進めていた。ちなみに、本来は1年単位の契約なんだけど、撤退しやすいように半年契約にして貰っている。

私自身、社内研修とか勉強会での発表とかをこなしているので、解説とか講師っぽいところは慣れているのだけど、蓋を開けてみれば小学生3-6年生には通用しなかった。というか、学校の教室で教えるようにはいかんわ、これは、な感じなスタートであった。これにはいくつか理由があるのだけど、いわゆる発達障碍児が3人ほど含まれていたのと、プログラミングのような「面白そうな興味のあるもの」だと騒がしくなるのは当然で運動部のようにはいかない。授業っぽくやろうかという話もあったのだが、到底無理なことがわかったので、それぞれで自由にやらせる/やってもらうことにした。

最初の思惑としては、プリントを配って解説をして、それに沿ってスクラッチで作ってみる、そして半分は遊びとか思っていたものの、無理無理。たぶん、中学生か高校生ならば「学習するスタイル」ができているのだが、小学生ではまだまだで、騒がしいことこの上ない。

実はプログラミング教室に参加する場合には何がかのお金を取ることになっている(300円ぐらいだったか)。印刷物の問題もあるけど、参加人数を制限したかったのと、なにがしかのお金が払って「プログラミング」するならば、親もなんらかの形で真剣になるだろうという思惑であるが、そうなったかどうかは定かではない。ちなみに、ひとり300円何某の分は私は貰っていない。印刷物のプリントアウトはあいキッズ側に任せたかったのと、講師料がちょっと増えたぐらいでは半分ボランティなのは変わらないからだ。まあ、気分的にも楽なので。

そんな訳で、プログラミング教室に出席させるにはなにがしかのお金を払っているので、プリント代として返そうという訳である(これは、区への申請を通すためでもある)。スクラッチの説明やらブロックの説明やらを書いたプリントを私が2,3枚で作って、隔週で印刷して貰っている。

半年過ぎたら、人数が半減した

前期(10月頃)までは、16名体制だったのだが、後半になって8名位に減った。いわゆる、面白くないからやめたのだが(途中でおもしろくないから来なくなった子もいる)…まあ、営利業務ではないので、半分に減ってちょうどパソコンの台数と子供の数が等しくなったので結果オーライというところである。

おもしろくないの理由のひとつとして、課題が簡単すぎて何をやっていいのかわからない子と、課題をほっぽっといて絵とか好きにやっていきた子が、混在している。16名は抱えきれない(補佐で1人ついて貰っているけど)のと、本格的なプログラミング教室(月謝が1万円ぐらいのやつとか)や CodeDojo とは違うので、子どものモチベーションは様々だ。そして、あいキッズ側の主目的としては「プログラミングを学ぶ」のではなく、「安全に子供を預かる」なので、それに沿うことにしている。ほかにも、将棋教室とか音楽教室とかサッカー教室なんてのもあるので、プログラミングだけではないのだから、気に入らなかったら他のところで遊べばよい。

と割り切ることにして、後半は

  • 20分ぐらいだけ課題をやる
  • 残りの時間は、Scratch で遊ぶ

ことにした。ちなみに、課題は Scratch の簡単なプログラムをあらかじめ私が書いておいて、それ改造するという手順にしていた。いわゆるリミックスという奴なのだけど、今年はサンプルを作ることをやめている。というのも、サンプルを作るとそれを動かすだけで満足しちゃうんだよね。まあ、ゲームを動かすとかそれはそれでもパソコンに触れる(キーボードを打つ、マウスを動かす)こと習熟できるのだけど、もうちょっと自分だけでやってほしいのと、個々人で学習度合いは異なるのだが、子ども同士で教えあうほうが良いみたいだから。

今年は課題シートを作った

なんやかやと、去年はサンプルコードを作っていたので、かなり蓄積ができた。遊ぶ子はそれを眺めて貰うとして、自分で学習したい子のために課題シートを作ってみた。プールとか縄跳びの級みたいに、ちょっとずつ目標をこなしていく感じ。

image

これも、集まった子たちの性格にもよるんだろうけど、男子は完全無視というか適当にぱらぱらやって飽きてしまって Scratch ゲームを探してやっている(野球とバブルを消すゲームがブームだ)が、女子3名が熱心に課題をこなしているという具合だ。そこは男女の性格があるのかどうかわからないし、5年生の男子はプログラムが初めてなので熱心にブロックを積み上げているし、4年生の子は既に Scratch を知っているので勝手に拡張してあれこれやっている。まあ、それはそれでよい。

ちなみに、プログラミング教室の子ども面子はごっそりと入れ変わっていて、また最初から Scratch でということにしている。まあ、隔週だし、ほどよく出来たら家でもできるしね。あと、6年生は卒業してしまうし、5年生は中学受験があってというパターンもある。なので、1年周期で考えるといいんじゃないかと思う。

ちなみに、去年と今年のサンプルは 1-1 矢印キーで上下左右 な感じで作っている。去年の一番人気は いらいらボール だった。

Scratch 以外を導入したい

去年からずっとタイミングを見計らっているのだけど、Arduino か Python を導入したいとは思っている。のだが、それは「大人の都合」でしかなくって、子どもの興味/楽しみからしたら隔週でノートPC使って Scratch ゲームで遊ぶほうが楽しいかもしれない。

と、去年の最後に Arduino とサーボモーターを使った電子工作モノを持っていたところ、6年生の子が Arduino IDE でバシバシとコードを打っていたんだよね。一度、書いてあるものを写経っぽくキーボードで打ち込むのは、それはそれで楽しい作業らしい。そう、昔 BASIC マガジンからマシンコードを打ち込んだ感じとか、N88Basic のゲームを雑誌から打ち込んでいる感覚なのかもしれない。

なので、1,2台に Arduino IDE を入れて、電子工作ができるコーナーを作るのもよいだろう。手元には Aliexpress で購入した互換 Arduino があるし、ブレッドボードとかLEDとか妙に大量に手元にあるので。

カテゴリー: 雑談 | 2年目のプログラミング教室 はコメントを受け付けていません

アズルレーンを PINE64 で動作させるまで

艦これ系のスマホアプリとしては、(Android の動作確認ができそうなのが)戦艦少女R か アズルレーン な訳ですが、ボトムズコラボということで、アズルレーンを入れてみます。ちなみに、大陸版の碧蓝航线を使ってもいいのだけど、biiibiliや百度のIDが必要であったりあれこれとややこしいので、日本語版のアズールレーンを使う。

ちなみにボトムズは本放送を中学生の頃に見ていた世代なんだけど、アズレンのユーザーとしては何処にいるのかは分からないw ターゲットは謎だ。ちなみに↓はボトムズではない。

Pine64 + Android 上でアズレンが動くと↓なように HDMI 接続で液晶モニタに表示できるようになる。操作はマウスなんだけど、WiFi でのキャストと違って映像が直結するのでスマホ画面との遅延は皆無になる。まあ、なったところで何か意味がある訳ではないけど、もっと大き目の TV に繋げばデモ的には面白い?

PINE 64 とは?

組み込みボードだとラズパイが有名なのところだけど、いくつか互換機がある。互換機とはいっても、本家?ラズパイよりも性能が良かったり、様々な拡張が為されていたりして使いようによっては面白いことができる。手元にあるのは「PINE A64」で、個人輸入したものなんだが(普通に本家からクレジットカードで買うだけなんだけど)、最近は秋月でも売っている。ラズパイは5,000円位かかるのだが、PINE64 はモノによっては3,000円位で安く購入ができる。

Android 6.0 を PINE 64 に入れる

Pine A64 Software Release – PINE64 から、Android 6.x の image をダウンロードする。最新版は、Android 7.1 なんだけど、手元の実機が 6.0 なので、それにあわせる…と思っただが、6.0 だと動きがいまいちなので Android 7.x に切り替える。

Win32DiskImager を使って microSD カードに焼いたら、PINE 64 のボードに入れて起動させれば ok. ちっとばかり、起動に時間がかかるが、↓な感じで起動できれば大丈夫。

Android 6.x のディスクイメージは 8GB、16GB 等と揃っているのだが、16GB を使っている。8GB だとなんやかやとアプリをインストールすると足りなくなってしまうのと、最近のラズパイでも 8GB だと足りなくて 16GB を使うことが多くなっているので。PINE 64 には USB が付いていて、USB メモリを差し込むこともできるから、大き目のアプリ(*.apk)は USB メモリからインストールすると楽だったり。

Google のアカウントを登録すれば Google Play からもダウンロードができる。

PINE 64 へ adb で接続する

この手の組み込むボードで Android を動かす目的のひとつとして、root が簡単に取れるというのがある。実機の Android だと root を取るのにあれこれやらないと駄目だし、復帰させるのも結構大変なのだが(実機は実機で便利なのだけど)、組み込みボードに Android を入れたときには、microSD カードを直接除くとか、動作時に既に root 化されている(Android Things も含めてそういう目的なので)のが普通だったりする。そうそう、エミュレータを利用して、〇〇を抜き出すというのもあるのだが、そういうこともできる。microSD カードを直接除けばいいわけだし。

この画像は「戦艦少女R」の場合

以下は、Android 6.0 の時の場合。7.x の場合は、最初から adbd が立ち上がっているので、起動直後から adb connect できる。Android 7.1 Community Image [v0.3.10-r66] をインストールしている。

~~~

root 化はさておき、vysor を使って画面をリモートで操作したり、アプリを adb 経由で入れたいときになどには、なんとかして PINE 64 に接続しないといけない。が、PINE 64 ボードに差し込む micro USB や電源供給だけなので、実機の Android のように OTG できない。なんじゃこりゃ?ってことになるので、↓のようにシリアルケーブルで接続する

Cubieと過ごす日々: PINE64にadbで接続
http://donadona-memo.blogspot.com/2016/07/pine64adb.html

ことになる…のだが、別な方法があった。SSHDroid をインストール&起動させた後に、Tera term の SSH から root/admin で接続。その後に

# setprop service.adb.tcp.port 5555
# stop adbd
# start adbd

する

image

この後、PC から adb connect <AndroidのIP> すれば ok.

image

ただし、Android Things のように、初めから adbd が start しているものもあるので、Android 側の init.rc を書き替えれば起動時に adb connect を受け入れるようになるはず。これは後から試してみる。

~~~

Google Play からインストールして起動

あとは、Google Play からインストールするか、あらかじめ *.apk ファイルをダウンロードして adb install でいれるか、USB メモリを使って入れるか、いくつかのパターンがある。

タッチパネルな機能は使えないので、あらかじめ実機でアズレンのチュートリアルをすました後に、PINE64 側で ID の引き続きをすればよいだろう。

Android 7.1.2 の場合は、有線LANが使えるのでコネクタにLANケーブルを挿し込んで高速にダウンロードができる。

image

アズレンの場合、自動的な戦闘(自律戦闘)が可能なので、戦闘中は眺めているだけでいい。マウスを使うのは、途中で何かを選択するときになる。

image

GPU の動きはちょっとぎこちないので、3Dアクションゲームみたいなのは難しいかなと思う。パズルゲームとかカードゲームならば大丈夫じゃないだろうか。

あと、CPU がかなり熱くなって熱暴走するので、ヒートシンクは必須っぽい。実機 Android でもかなり熱くなるから、Unity の CPU/GPU ぶん廻しは相当なものなのだろう。ちなみに adb shell で top を調べると、アズレン(com.YoStarJP.AzurLane)がどれだけ CPU を消費しているのかが分かる。20%弱位消費している。まあ、これだけ消費していればバッテリーの減りも早いのではないだろうか。

image

せっかく GPIO が使えるので、物理的なジョイスティックとか繋げて操作できないかなと思ったりするのだが、何か良い方法はないものだろうか。Android のサービスアプリを作ればいけそうなんだが。

カテゴリー: 開発, Android, アズレン | アズルレーンを PINE64 で動作させるまで はコメントを受け付けていません

VB6 業務アプリの移行を考える

予算さえあれば、新規作成 or 完全移植してしまうのがベターなのだが、多くの場合予算の関係で VB6 の業務アプリをそのまま使い続けることがある。旧来の PC(Windows 2000やXPも含む)にインストールされている VB6 の業務アプリを専用機器のまま使う(あるいは、PC から吸い上げて仮想モード内のみで使う)方法もあるのだが、いくつかのネックがある。

  • 既存バグが解消されない
  • 新規システムと接続できない(修正できない)
  • 既存PCの CPU 速度に引っ張られて遅い

こともあり、 VB6 の業務アプリから何らかの形で引っ越したいところなのだが、予算がない、あるいは既存の業務アプリが複雑怪奇すぎるための引っ越しの予算が掛かかるかもしれない、という理由から、なんとか既存 VB6 コードを弄ろうとする。それは試算は試算なのだから、工場の機械よろしく使い潰すのがベターともいえる。

で、まったく移行予算が取れない場合は論外なのだが(社内等で VB6 のまま弄るしかない)、なんらかの予算が取れれば移行を外注することも可能ではないか?…という「仮定」のもとに考察してみる。

移行先のフレームワークを考える

VB6 の業務アプリの場合、C/S 方式が主なものになる。SQL Server か Acesss にデータを集めるために(当時の予算枠の具合で SQL Server か Access かが決まってくる)、ODBC, RDO, ADO を使って VB6 からデータベースサーバーへアクセスする。ユーザーが入力する画面では、旧文化オリエントのコントロール、スプレッドシートが使われていることが多い。実際、2002年頃に VB.NET が出てから、VB6 から VB.NET へ移行するために、各種の既存コントロールを .NET 化させたものが発売されている。ただし、VB のコンバートツールがあるものの、これらの .NET 用のコントロールまで網羅してくれてはいない。あくまで標準的なコントロールのコンバートのみとなり、スプレッドシートでかなりの部分をあれこれしている場合には、自動コンバートしたときにもアレコレしないといけないという「手間」が掛かってくる。イコール、移行予算が跳ね上がるのである。

また、2002年当時であれば、VB.NET や .NET の業務アプリも素朴なフレームワークなものが多かったのだが、今となっては、VB6 で作ったフレームワークをそのまま VB.NET に持って来るとコーディングの効率の悪さやメンテナンス性の悪さも引きずってしまう可能性が高い。たとえば、RDO や ADO で延々と SQL を書いている部分は、今であれば LINQ に直してしまうのが望ましい。特に Entity Framework と組み合わせてしまうと、INSERT/DELETE/UPDATE のコードはほぼ1行で済んでしまう。

また、当時から PC での C/S アプリをブラウザ形式の WEB アプリにすることが盛んであった。失敗には終わったが、Java アプレットや Siverlight、Flex のようなブラウザ上でのコンポーネントに移行してしまうというパターンもいくつかある。となると、既存の VB6 の C/S 形式のアプリを、何も考えずに C/S に直すというのもちょっと問題がある。潤沢ではない限られた移行予算となる場合は、

  • 移行時のコード量が、元のコードよりも大幅に減り、開発時間を減らす。
  • 移行時のテスト期間を何らかのツールを使って、大幅に削減できる。

という点に注視する必要がある。たとえば、移行コード量が移行前のものと同じでしかないのであれば、開発期間も同じぐらいかかり、単純に同じ程度の開発/移行コストが掛かるという見積もりになる。移行予算が潤沢に取れればよいが、そうもいかないであろう。IT 業者としては、新しい機能を盛り込むという理由を付けて、それなりの予算を取りたいところであるが、移行を頼む側から言えば、「同じ機能を実装してくれればよい」ので、余分に予算を取りたいわけではない。ある意味では、移行前も移行後も「同じ機能」でしかないので、できることなればい移行はゼロ円で済ませたいところなのだ。

一般的にソフトウェアは、劣化しないものとされているが、そういう意味では長期でソフトウェアを資産とするには、経年劣化があり資産価値がゼロになるということだ。このあたり、IT業者も非IT業者もあまり真面目に考えていない。

なので、旧来の VB6 の業務アプリは、OS がサポートから外されている、既存バグを直す人がいなくなっている、という理由から新しい業務アプリに移行するのが主な理由になる。そうなると、既存の VB6 と使用感は変わらないほうがよい。つまりは、「既存の VB6 アプリを Xamarin でタブレットアプリに移行しませんか?」というのはムダである。できることなれば、そのままでいいのだ。既存の不具合は直したいところだけど。

そうなると、移行先のフレームワークは限られてくる。ユーザーの特に新しくない使用感に合わせるためには、

  • VB6 業務アプリで C/S 風に使える

というのがベターである。この場合、ブラウザでぽちぽち入力するのも許容範囲であれば、

  • 現状の C/S をそのままのシステム移行
  • 内部で Web API を利用する C/S 方式へ移行
  • ブラウザ方式に移行

というパターンに落ち着く。既存の VB6 では RDO/ADO 等が使われているが、C/S 方式であっても EF+LINQ を利用する(コード量やテスト効率を含めて)、あるいは C/S でストアドプロシージャ等が使われていれば Web API/REST に移行するのもよいだろう。画面が多少パタパタしてもよいのでれば、HTMLを使ったブラウザアプリ(ASP.NET、PHP など)でも構わない。少なくとも、既存の C/S 方式をそのまま自動コードのコンバーターを使って移行するのは得策とはいえない。

移行先のプログラム言語を考える

2002年当時、VB6 から自動コンバートすると VB.NET のコードが出力される。今でもそうだけど、VB6 から C# へのコンバートはされない。先の理由から、自動コンバート自体おすすめできないので、なんらかの手作業による移行が必要になる。手作業であるから、移行できるコード量と、移行後のコード量というのが開発/移行コストに大きくかかわってくる。

既存の VB6 のコードで、標準モジュール(いわゆるライブラリ)が多ければ、*.bas なコードをそのまま VB.NET に持ってきても良いだろう。モジュールのままでもよいし、適当なユーティリティクラスでラップしてしまってもよい。特に複雑なロジックが入っているのであれば、*.bas なコードをそのまま流用できるならば、移行的にはかなり楽になる。

…ハズなのだが、実は、VB6 業務アプリでロジックが重要ということはあまりない。科学計算を必要とするとか、ブラックボックス的な業務ロジックを組む場合には、既に C++ であったり、C# に移行してしまったり、ストアドプロシージャで整理されていたりするので、VB6 自体には *.bas で移行する部分はほとんどないといってよい。*.bas なコードを眺めると、文字列の編集だとかデータのコンバートだとか、いまであれば .NET クラスライブラリに入っていそうなものばかりである。なので、VB6 だから VB.NET が有利である、というプログラム言語が同じであるというメリットはかなり低い。

そうなると、プログラム言語は、C# であっても VB.NET であっても構わない。C# の場合 VB6 から IF文や FOR文を移行するときにかなり書き替えなければいけないのだが、LINQを使うとかラムダ式をつかうとかイベントを多用するとか、を考えると VB の冗長なところが面倒だったりする。

なので、移行先のプログラム言語は、プログラマ自身が得意と思われる(チームが得意と思われる)言語がよい。C# か VB.NET のどちらを選んでもよい。まして、ブラウザアプリに切り替えてしまうのであれば、PHP でも十分なはずだ。

データベースを考える

C/S 方式の場合、サーバーにデータベースを据えることが多い。実際、VB6 での業務アプリの場合はサーバー側は十中八九 SQL Server となる。SQL Server のカラム名が日本語であったり、ひとつのテーブルのカラム数が50位あったり、正規化が不十分だったりすることは多いのだが、実は、データーベースの寿命はデスクトップアプリのそれよりも長い。

となれば、データベースの構造は、目をつぶってそのまま使うのひとつの方法である。よほどひどいモノでない限り、SQL Server のものを SQL Server のまま扱うのがよいだろう。このほうが EF + LINQ との相性もよいからだ。

ただし、EF を使うときに制限があり、テーブルに「主キーがひとつ」必要になる。LINQ が主キーを頼りに SaveChange するためなんだが、これはADO.NET Model のデザイン対象となるデータベースを仮に作ってしまい、主キーを付けることで回避できる。

印刷/帳票機能を移行する

旧来の VB6 では印刷機能が貧弱であったため、旧文化オリエントのスプレッドシートやレポートツールを使っていることが多いのだが、現在もそれを使い続けないとけない理由はない。

  • PDF に直接出力する
  • Excel や Word に出力する
  • HTML形式で出力する

最終的に紙に印刷するにしても、.NET から PDF に出力するライブラリはたくさんある。データをリスト形式で印刷するならば、HTML 形式を通して印刷してもよいだろう。

また、Excel や Word であらかじめテンプレートを作っておいて、データを埋め込む方法もできる。こうすると、微妙なフォントの大きさや印刷位置の調節をあらかじめ Excel や Word 上で確認することができる。

移行時の予算を考える

先に示した通り、現状の機能を移行する「だけ」なので、発注側にとって移行コストはゼロ円が望ましい。しかし、実際のとこころは資産価値が減少するのであるから、使い続けるためにはなんらかのコストを掛けるのは否めないというところだろう。

目安として、移行コストは新規開発の予算の半分から1/3といったところだろう。これは、機能はそのままでの移行案件の場合、

  • 要件定義、設計工程を省くことが可能
  • テスト工程で、正しい動作(既存の業務アプリ)が確認できる

ことになるためだ。多少の既存バグを修正する場合はよいのだが、移行時に機能追加をする場合には、その分のコストは別途見積もるのがよい。

また、これ以下の予算しか取れないばばあいは、コードを修正するような移行は諦めて、仮想環境への移行など延命処置に切り替える。この場合、当然のことながら VB6 の内部コードを弄ることはしないので、既存バグは既存バグのまま残ることになる。どちらを選択するかは顧客が選ぶことなる。

移行スケジュールを考える

大抵の IT プロジェクトの場合、予算が決まればスケジュールが決まる(人月で割るから)なのだが、VB6 からの移行の場合は、それは当てはまらない。というのも、単純に安めの移行予算を人月で割ってしまうと、超短期なスケジュールになってしまい納期遅延が必至になってしまうからだ。なので、移行スケジュールは、予算とは関係なく3か月から半年程度取ってしまうのがベターだ。

半年のスケジュールとなると、通常開発であれば(中小企業にとっては)相当な金額になってしまうものだが、実はフルタイムで移行プロジェクトに関わらなくてもよい。いや、むしろフルタイムで関わってしまうほうが移行プロジェクトのリスクが高くなってしまうとも云える。

プロジェクトの各タスク/WBS/チケットを出した後は、適当に順番にこなしていくのが移行プロジェクトを推進するときのノウハウになる。というのも、機能だけ移行する場合は、機能追加などの要件の調査や概要の再設計などが必要ないので、一種のウォーターフォール的な開発にバラすことができる。つまり、ひとつのチケットに対していつ開始していつ終了しても全体コストが変わらないパターンとなる。

適用条件としては、

  • 大幅な機能追加がないこと。「移行」だけに専念でき、要件定義、設計はそのままとする。
  • 既存のシステムが正常に動く(既存バグは除く)こと。

ということになる。この範囲であれば、顧客との交渉を減らすことのができ所謂コミュニケーションコストを減らせる。そして、週報等も省略し、適度なマイルストーンのみを配置する。全体的に緩くスケジュールを組み、別のプロジェクトと平行にこなす(保守プロジェクトとか)ことにより、チケット駆動開発が有効に働く。

これらの条件が揃ったときに「移行プロジェクト」の成功率は格段にあがる。

カテゴリー: 雑談 | VB6 業務アプリの移行を考える はコメントを受け付けていません