Raspberry Pi 2BとScratch 3でデジタルサイネージに挑戦

今の職場にも屋上に太陽光発電システムが導入されていて、その発電状況をモニタリングするための液晶モニタが校内に設置されています。これを使って学校の様々な活動を紹介するスライドショーのようなことができないかということになりました。

この液晶モニタにはDVDプレーヤーがつながっていて、写真をCD-Rに焼いて再生すると液晶モニタに表示されるというシステムになっています。これを使うのが一番手っ取り早いのは間違いないのですが、全く面白くない。今の職場の環境ではデータの持ち出しが厳しく制限されているため、CD-Rに焼くまでの手順が尋常じゃないほど面倒くさいのです。しかも、ミスを修正したり部分的に更新したりすることが容易ではなく、その度に新しいCD-Rに焼く作業をしなければなりません。これでは、効率が悪い上にエコでもない。

幸いなことに、DVDプレーヤーはアナログ3ピン（赤、白、黄）で接続されていて、液晶モニタのHDMI入力が2つもあまっていました。しかも、HDMIケーブルが挿さったまま何にもつながっていません。さらに、液晶モニタの近くには電源も引かれているからまさにおあつらえ向きです。早速、Raspberry PiとScratchでデジタルサイネージを作ってみることにしました。

まずは、表示するものを作ります。Scratch 1.4を使ってご当地キャラクターの動きに合わせて背景の写真が切り替わるという簡単なプログラムを作りました。しかし、出来上がったものを作業をしていたPC画面で確認すると、写真の解像度がイマイチで、かなり画像が荒くなってしまうことが判明しました。これでは、大型の液晶モニタには耐えられないだろうと判断。Scratch 3を使う計画に切り替えました。
＃Raspberry Pi BlogのScratch 3 Desktop for Raspbian on Raspberry Piを参考にさせていただきましたが、結論から言うと、最新のRaspbian（Raspberry Pi OS）を使えばScratch 3も一緒にインストールされていることがわかりました。

(1) Raspbian Buster以降のOSを使うことと、(2) 1GB以上のメモリを載せていることが最低条件らしいので、自宅にある各世代のRPiの中からRPi 2Bをチョイスしました。そして、使い慣れたNOOBSをダウンロードして、解凍したファイル＆フォルダを在庫していた16GBのSDカードにコピーして起動SDカードを作りました。SDカードは、事前にSDFormatterで初期化しておくことをお勧めします。
＃RPi 2Bは、3B以降のようなWireless LANやBluetoothは搭載されておらず、消費電力も抑えられるので割り切った使い方をするのにはちょうどよいと思っています。

NOOBSを入れたSDカードをRPi 2Bに挿して起動すると、Raspbianのデスクトップが表示されて無事に起動することができました。ちなみに、現在推奨されている方法は、Raspberry Pi Imagerを使う方法のようです。最近購入したRPi 4Bのセットアップをするときには、こちらを使おうと思います。

セットアップとアップデート作業（少々時間がかかる）が終わったら、インストールされていたScratch 3 Desktopを使ってデジタルサイネージプログラムの動作確認です。（ついでに、日本語入力環境「fcitx-mozc」もインストール済みでした）実際に動かしてみると、液晶モニタがワイドサイズだったためか、表示画面が小さくて見にくいことがわかりました。せめてタスクバーを隠してその分だけ画面を広くしようと考えて、タスクバー上で右クリックをして、出てきたプルダウンメニューから「パネルの設定」を選んでタスクバーを隠す設定にしました。（「高度な設定」タグの中に「自動的に隠す」という項目があるので、「使わないときはパネルを最小化する」にチェックを入れたら完了です）

なかなかの仕上がりになりました。今後の課題としては、電源を入れるだけでScratch 3まで起動することと、シャットダウンボタンを設置することです。時間を見つけてやってみます。

【追記】シャットダウンスイッチの設定をしました。（2020.6.21）
・Raspberry Pi 2BとScratch 3でデジタルサイネージ（シャットダウンスイッチをつける）

CloudReadyでChromiumOSをインストール（サブノートPCをChromebook化）する

4年ほど前にAcerのサブノートPCをChromebook化するのにかなり苦労をしたのですが、ここへ来てChromebookへの注目度が高まってきたので、久しぶりにメンテナンスをしてみようかと思い立ちました。そもそも、ChromeOS自体は公開（無償配布）されておらず、Chromebookを使いたいならChromebookを購入するのが一番の近道です。自分でChromebook（のようなもの）を作ろうと思ったら、無償で配布されているChromiumOSをインストールして使うしかありません。これがなかなか厄介で、簡単に使えるとは言い難いものです。そこで、今回はCloudReadyを使ってみることにしました。

必要なのは、CloudReadyの32bit版です。Chromebook化しようとしているサブノートPCが32bitにしか対応していない（CPUは、Intel Atom N280を搭載）からです。残念なことにCloudReadyのWebサイトでは、32bit版のサポートは終了していて配布も行われていません。いろいろと探し回った結果GetMyOSというサイトにCloudReadyの32bit版が残っているのを見つけました。早速これ（.zipファイル）をダウンロードして、サブノートPCへインストールすることにしました。

インストール方法は、Easy Innovation Zoneの「CloudReady Home のインストールと設定」を参考にしました。使ったのは、Google ChromeブラウザとGoogle Chrome上で動く「Chromebookリカバリユーティリティ」です。両方ともGoogle検索ですぐに見つけることができました。（先にGoogle Chromeをダウンロード＆インストールしておいてから、Google ChromeでChromebookリカバリユーティリティを検索して「chromeに追加」ボタンでインストールします）ダウンロードしておいたCloudReadyの.zipファイルをリカバリユーティリティで読み込みます。「歯車（ギア）」マークをクリックするとメニューが表示され、「ローカルイメージを使用」を選択することでダウンロードした.zipファイルを読み込むことができるようになります。（.zipファイルは解凍する必要はありません）このあと、8GB以上のUSBメモリを挿してインストールUSBメモリを作ります。少々時間はかかりますが、待つだけですので以前のような苦労はありませんでした。

出来上がったUSBメモリをサブノートPCに挿して起動します。難なく起動して設定画面が表示されました。どうやら、USBメモリからの起動で使い続けることもできるようでしたが、設定完了後の画面からHDDへのインストールを選択して作業続行。32bit版のサポートが終了していることを警告しているらしきものが出てきたのですが、完全に無視をして作業を続けました。長くなりそうなのでしばらく放置していると、いつの間にかインストールが終了していました。起動してGoogleのアカウントでログインすると、無事にChromiumOSが起動しました。デスクトップに表示された「ChromiumOS 76.3.33」というのが今回使った32bit版のバージョンなのだと思います。

古いPCを再生させることにどれだけの需要があるかはわかりませんが、Chromebookを試してみたいけど、既にPCがあって製品のChromebookを買うほどではないという状況の人たちには、USBメモリから起動するというのは需要がある気がします。（学校現場では、この行為が制限されている場合が多々ありますが…）私のように古いPCを不良在庫レベルで持っているような者にとっては、32bit版のサポート終了が痛く思われます。これからも、細々とではありますがChrome（Chromium）OSで何ができるか試してみたいと思っています。

カブトムシの世話（2020春）〜蛹化前のギリギリのタイミングで

新型コロナウイルス感染症拡大防止のための緊急事態宣言が延長され、まだまだ予断を許さない状況もあり、Stay Homeということで、GWを含めた休日はできるだけ外に出ないようにしておりました。そんな中、ふと「カブトムシの世話をする時期はいつ頃だったかな？」と気になり、このブログを見直して、概ねGWの時期には夏前の世話をしていることを確認しました。（あれもこれも変更に次ぐ変更で、自分の中の季節感が狂ってしまっています）冬眠から目覚めた時期は、カブトムシたちが蛹化に向けた準備に入るため、最後にしっかり餌（クヌギと腐葉土）を与えて蛹化を待つことになります。
#冬眠前にしっかり太らせておくと良いようです。

前回の世話から約半年、この間にも、追加で腐葉土を入れたり加水したりと軽い世話をしていましたが、本格的にひっくり返して状態を確認しながらマットの交換を行いました。2017年から飼育マットをクヌギマット＆腐葉土にしたのですが、この3年間でノウハウがだいぶたまってきました。腐葉土は、カブトムシの栄養源としては効率が悪く、かさばるけれども消費も多いということや、カブトムシ自体もこぶりなものになりやすいということがわかりました。それを補うためにクヌギマットを併用したり、朽木を年に7〜8本くらい入れて補ったりしています。そのためか、全体の1/3程度の個体は、かなり大きく育っています。

腐葉土自体の分解が進み、クヌギよりも早く黒土化してしまうということもわかりました。カブトムシのフンは、黒土そのものなのですが、細かく粉砕する前は、粒ガムよりちょっと小さいくらいの大きさ・形をしています。（クヌギばかりで飼育するとクヌギの匂いがしますが、腐葉土を混ぜているので土の匂いです）これを花の肥料として使っているのですが、腐葉土飼育になってからは、フンの粒だけでなく腐葉土が黒土化したものも出てしまうので、入れ替え作業が大変です。今回は、コンテナの半分ほどのフンと黒土を取り除き、クヌギマットと腐葉土を加水して敷いたところに使えそうなマットとカブトムシの幼虫を戻しました。加水したクヌギマットと腐葉土は、蛹室づくりのことも考えて予め少しつき固めておきました。カブトムシの幼虫は、69頭いました。（死骸が見つかったのは、1頭だけでした）

これで何とか蛹化前の世話を済ませることができました。あとは、夏に向けて約1ヶ月半ほど成虫になるのを待つだけです。新しい職場では、今の所カブトムシも花の肥料も必要な感じがしませんが、何かできることはないかと思っているところです。

macOSとLinux Mint 19.3でSambaの設定（ファイアウォールを含む）をしてmacOSや別のLinux機から共有フォルダを使えるようにするまでの試行錯誤

macOSがCatalinaになって、ファイル共有の動きがイマイチな感じになっていました。AFP（Apple Filing Protocol）で共有フォルダを開くと、macOSジャーナリングでフォーマットした外付けHDDの中身が見えなくなってしまったのです。これにはかなりパニック状態になりました。なぜなのかわからず、長いこと試行錯誤しました。

ドライブのフォーマットの問題かと思い、exFATでフォーマットしてやってみました。これで、中身は見えるようになりましたが、ファイルを開くことはできても保存がうまく行かないなどのアクシデントがありました。仕方がないのでSMB（Server Message Block）で開き直してみると、exFATでは、アプリケーションが開いたファイルの位置を見失う状態になりました。ならばということで、macOSジャーナリングでフォーマットしたドライブをSMBで開いてみました。すると、中身も見えるし問題なく使えるようになりました。いつの間にか、macOSのファイル共有は、SMBが基本になっていたのですね。
＃どうやら、FAT系フォーマットのドライブの扱いが、何か変わったのかなという感じです。

ならばと思い、先日設定をしたHTPC（IntelのCeleron J1800を載せたGIGABYTE製GA-J1800N-D2H）のSamba（SMB）設定を強化すべく、設定をいじることにしました。Sambaは既にインストールしてあるので、HTPCのホームディレクトリが共有できるようになっています。「/etc/samba/smb.conf」には、以下のように書き込んであります。

[homes]
comment = Home Directories
browseable = no
read only = no
valid users = %S

ここまでの設定で使えることは使えるのですが、最低限のセキュリティとして、ファイアウォールは必須と考えてLinux Mint 19.3のファイアウォールの設定をONにしました。すると、HTPCにアクセスすることができなくなりました。macOSとは違って、ファイル共有とファイアウォールの設定は、自動的に関連付けられてはいないのです。そのため、ファイアウォールの設定をいじらなければななりません。先程、ファイアウォールをONにした設定ツールからルールを追加します。

Linux Mintの「ファイアウォール設定ツール」を開いて「ルール」タグの窓の下方にある「＋」ボタンを押して、以下の設定を追加します。

ポリシー：Allow
方向：In
カテゴリー：すべて
サブカテゴリー：Service
Application：Samba

ここまで設定したら「追加」ボタンを押します。すると、自動的にルールが書き込まれるので、これで設定が完了（「閉じる」ボタンを押して良い）します。ここまでやった後、iMacやMacBook Proからアクセスしてみましたが、問題なくHTPCにアクセスすることができるようになり、ホームディレクトリが使えるようになりました。

ついでに、別のLinux機（うちの場合は、多くはMintで動いているけれども、様々なLinux機でも同様です）からアクセスできるようにしてみました。次のようにクライアントの設定をします。

$ sudo apt install cifs-utils

「cifs-utils」は、Windowsのネットワークに入るためのもので、必ずしもSamba専用というわけではありません。Windowsでファイルサーバを運用しているところで、Linuxからアクセスする場合にも、「cifs-utils」を使います。使い方は難しくありませんが、ちょっとしたコツが必要です。（Linuxユーザなら特に問題はないでしょう）

はじめに共有するフォルダをマウントする場所（マウントポイント）を用意します。

$ sudo mkdir -p /mnt/〈任意の名前〉

このコマンドで、/mntフォルダの中に、任意の名前のフォルダをつくるというイメージです。マウント後は、このフォルダの中に共有先のファイルやフォルダが見えるようになります。続いてマウントコマンドで共有先をマウントします。

$ sudo mount -t cifs -o username=〈username〉,password=〈password〉 //〈serverのPC名〉/〈共有フォルダ名〉 /mnt/〈任意の名前〉

〈username〉と〈password〉は、Sambaを動かしているサーバ側で設定したものを入力します。〈serverのPC名〉と〈共有フォルダ名〉も、サーバ側で設定したものです。これで、/mnt/〈任意の名前〉に共有先のフォルダがつながってファイルやフォルダの共有ができるようになります。
＃「Narrow Escape」のLinuxMint 19: SMBクライアントのcifs-utilsをインストールするを参考にしました。

これらの一連の操作をシェルスクリプトとして保存しておいて、起動と同時に自動で走らせるという方法もありますが、セキュリティ上どうなのかという心配があります。（やる場合は、自己責任で）

調子の悪いMacBook Pro(Mid 2012)からMacBook Pro(2019 Two Thunderbolt 3 ports)へ移行作業をする

新しいMacBook Airの方が話題になっていますが、そんなこととはおかまいなしで、ちょっと前にMacBook Proを買ってしまった私は、仕事の合間を縫ってセットアップをすることにしました。今までは、壊れてから買い替えるパターンが多かったMacBook系のマシーンでしたが、今回は、調子は悪いものの動かないという状態ではないので「移行アシスタント」で使用環境をそのまま移行してみることにしました。
＃だいぶ以前にiMacで経験済みですが…。

まずは、新しいMacBook Proのセットアップを進めます。言語の設定やネットワークの設定などを終えたところで、「移行アシスタント」を使うかどうかという選択肢が出てきます。ここまでやったら、今度は古いMacBook Proの電源を入れて、同じく「移行アシスタント」を起動します。ここでは、「別のMacへ」を選択します。古いMacBook Proは安定していないことが買い替えの理由でしたが、この作業中に2回ほどフリーズしました。最初は、「移行アシスタント」が起動せず、黒い画面のまま固まりました。2度目は、全ての移行が終わって再起動しようとしたところでフリーズ。既に新しいMacBook Proへの移行が完了していて、動作確認ができていたため事なきを得ましたが、きちんと移行ができているのか心配になる状態でした。（ヒヤヒヤしました）

その後は、古いMacBook Proも見違えるほど普通に動くようになってしまいました。アプリケーションソフトがきれいに整理整頓されていたり、新しいmacOSで動かなくなっているものが消えてなくなっていたりといった状態が確認できました。いろいろ動作の邪魔をしていたものが綺麗サッパリなくなって身軽になったのかもしれません。「移行アシスタント」には、移行に邪魔なものを整理したり正常に戻したりする機能があるのかもしれませんが、正確なところはわかりませんでした。
#移行のために古い方も使っていると、やはり次第に調子が悪く、動作が不安定になっていきました。両方使えるかもとも思いましたが、やめた方が良さそうです。

ちょっと意外だったのは、Movies、Music，Picturesの3つのフォルダの中身が引き継がれなかったこと。データ量が多かったので、USB接続の外付けSSDドライブを使ってデータを移動させました。（ついでにいらないものを捨てて、すっきりしました）もしかすると、iCloudで共有しておけばこんな手間をかけなくてもよいのかもしれません。

最後に、メーラーとして愛用しているThunderbirdの移行を行いました。これがちょっと面倒くさい。まず、Finder（macOSのデスクトップ）の「移動」メニューをoptionキーを押しながらクリックすると、プルダウンメニューの中に「ライブラリ」というメニューが現れます。これを選択して開くと、その中に「Thunderbird」という名前のフォルダがありますので、「Thunderbird」→「Profiles」とたどって、「.default」という文字列が含まれるフォルダをコピーして、新しい環境の同じ場所へ移動します。今回は、「.default」が付いているフォルダを、USBメモリに保存して新しいMacBook Proに移動しました。
＃この方法は、MacからWindows等別のOS間でも使えるようです。

ここで1つ問題が発生。この新旧MacBook Proの移行作業を数日かけて行っていたため、無意識的に古いMacBook ProのThunderbirdをアップデートしていて、新しいMacBook ProのThunderbirdとバージョンが合っていない状態になっていました。この状態だと、データのバージョンが違うので引き継げない旨のメッセージが出て、設定やメールの内容などが引き継げません。そのため、Thunderbirdのバージョンを揃えておく必要があったのでした。新しいMacBook ProのThunderbirdをアップデートして、無事に作業を終えました。

これでようやく実用的な状態にはなりました。新しいMacBook Proの使い心地ですが、薄さの犠牲となった打鍵感と使い所がイマイチなTouch Barの問題はありますが、その他の操作については古いMacBook Proのときのようなつまずき感やフリーズがないので快適です。速度も申し分ない。USB-C機器を揃えていないので、今まで通りに使用するにはちょっと工夫は必要ですが、Appleストアで使える18,000円クーポンがもらえたので、USB-AやHDMIに変換する（ついでにSDカードも読み込める）コネクタや純正のDVDドライブを購入して使っています。新macOS Catalinaへの対応が遅いソフトウエアが多くて（というより、Macのソフトウエアの需要が少なすぎるor対応が難しい？）完全に今までと同じことができるとは言えないのですが、Linuxで動くPCを使うなど様々なアプローチでより快適な作業環境を実現したいと思っています。

Linux版Scratch 1.4で作ったプログラムがScratch 3.0でコードが見えない現象（謎の文字化けが起こる）を検証する

前回までに、常用しているLinux MintのWine上で、Windows版Scratch 1.4を動かして、Scratch 3.0でスクリプト（コード） が見えなくなる原因を突き止めました。Linux版Scratch 1.4では直接日本語入力ができず、テキストエディタなどの別のところで日本語文字列を作り、それをコピペして日本語を入力するという手順を踏まなければなりません。この過程で変換不可能な文字列（これが何かはわかりませんでしたが）が紛れ込み、これをScratch 3.0で開くとコードが見えなくなることがわかりました。Scratch 2.0は、この不具合を解消する処理をしているらしく、Scratch 1.4で作ったものを2.0で読み込んで保存もしくはアップロードすると、3.0でも問題なくコードが見えるようになるのでした。

検証した環境と結果は以下のとおりです。（改行コードのせいもあると考えて、改行を含むものと含まないものとを並べてみました）(1)アルファベットのみ、(2)日本語（改行なし）、(3)日本語（改行あり）の順です。

• Linux Mint 19.3 Tricia（MATE 64bit）
  
  • 〈Wine上のWindows版Scratch 1.4で見ると…〉
    
• Raspbian 9.8
  
  • 〈Wine上のWindows版Scratch 1.4で見ると…〉
    
• Puppy Linux 5.1.1 Wary（日本語版にScratchなどを入れたものを使用）
  
  • 〈Wine上のWindows版Scratch 1.4で見ると…〉
    

今回は、Raspbianだけ不具合がありませんでした。MintとPuppyでは、改行ありだと明らかに見た目がおかしいので、気づくのではないかと思います。とは言え、改行なしでも文字化けが含まれてしまうのですが。

今後のScratch 1.4での開発は、Wine上のScratch 1.4か、RaspbianのScratch 1.4で行うようにするか、日本語を使わないようにするかという選択になりました。

Linux MintのWineでWindows版Scratch 1.4を動かす

Macの新しいOS（macOS Catalina 10.15.x）でScratch 1.4が動かないため、Linux MintやPuppy Linuxなどの力を借りて、Scratch 1.4での開発をしている続きです。先日、Linux MintのScratch 1.4で作ったプログラムが、Scratch 3.0上で「コードが見えない」という不具合を発見しましたが、全てダメということではなく、どうやら日本語の扱いに問題があるということがわかってきました。

毎度のことながら、@abee2さんに助けていただき、Windows版のScratch 1.4で開いてみると「化けた文字」が含まれていると教えていただきました。自宅にあるパソコンは、デスクトップ・ラップトップ合わせて数十台にもなりますが、残念（意図的）ながら（我が子の学習用以外で）Windowsで動くものはありません。そこで、MintのWine上でWindows版Scratch 1.4を動かしてみてはと勧められたので、やってみることにしました。幸いなことに、別の需要があってWineはインストール済みでした。（「ソフトウエアの管理」からインストールしました）
＃他にも、PlayOnLinuxもインストール済みですが、今回はあまり関係がありません。

Windows版Scratch 1.4のインストーラーをダウンロードして、Linux Mintでダブルクリックすると、難なくインストール作業が始まり、無事に完了しました。後は起動するだけ。ちょっとドキドキしましたが、無事にWindows版Scratch 1.4が起動しました。しかし、日本語が表示されず全て豆腐（□）になっています。これでは不具合を確認することすらできません。そこで、過去にWineの設定をしたときのことを思い出しました。Wine 4.0以降は、割と日本語表示が簡単になったという噂を目にしましたので、過去の経験を頼りにやってみましたが、うまくいきません。「Wine設定」自体がすべて日本語表示になっているし、デフォルトでインストールされている「メモ帳」もメニューの日本語表記や入力が日本語でできるというのに、Scratchだけは頑なに日本語を受け付けてくれないのです。

もう打つ手はないのかと絶望感に苛まれつつも、これはScratch 1.4自体のフォントの設定が問題なのではないかと考えました。過去の記憶を頼りに、フォントの設定を変えることができたような気がしてきたのです。localeの.poファイルにフォントの設定を書き込めることを教えていただき、過去にそんな設定をやったことを思い出しました。ja.poとja_HIRA.poの以下の部分を書き換えました。

• 〈変更前〉

  # Font to use on a Windows system
  msgid "Win-Font"
  msgstr "Tahoma"

• 〈変更後〉

  # Font to use on a Windows system
  msgid "Win-Font"
  msgstr "Takaoゴシック”

日本語フォントに何を使っているかによって設定が変わると思いますが、私の環境（Linux Mint）では「Takaoゴシック」が入っているためこのようにしました。これで、問題のあった.sbファイルを開くと、日本語文字列の後に豆腐（□）が見えるようになりました。デフォルトで日本語表記になっているもの（スプライトの名前など）には、特に問題がないため、Linux版Scratch 1.4で日本語入力ができないことと関係がありそうだと当たりをつけました。次は、なぜこのようなものが混じってしまうのか検証して行きたいと思います。

【追記】Windows版Scratch 1.4で日本語に豆腐（□）が交じる現象が起きる環境を特定しました。（2020.3.15）

• Linux版Scratch 1.4で作ったプログラムがScratch 3.0でコードが見えない現象（謎の文字化けが起こる）を検証する