一応Swift基礎勉強の成果かと

 昨春、まだ新校舎にチャイムがなかったために急ぎ作ったチャイムアプリ。 macOSアプリ初挑戦とはいえド素人らしい永久ループにはまり、終了は強制終了するしかなかありませんでした。
 
 そのうち新校舎でもチャイムが鳴るように施設が改善されて必要性も無くなったのですが、今回のリモート授業ではZOOMの画面と音声共有を使って自宅にいる学生に授業開始を告げる役目が回って来ました。

 ちょうどその直前、自分の基礎勉強も兼ねたSwift Playgroundsを終えたばかりで、本当に永久ループを解決できないのか改めてXcodeでチャイムアプリの中身を久しぶりに開いてみると。
 なんてことはない、毎秒毎秒時刻判定のためにインスタンスを生んでいたTimerクラス自体に指定した時間毎に自動的にコールを繰り返す引数があるではないですか。

 Timer.scheduledTimer(withTimeInterval: 1, repeats: true, ...

 もちろんこれを使って永久ループの問題は解決し、終了時もごく普通にCommand+Qが使えるようになりました。 

Chime

 今になってみたら最初になんでこんな簡単なことに気がつかなかったんだろう、と首をひねるばかりですが、当時はとにかく新学期に間に合わせようと慌てていたのもありつつ、こういうさらりとコードがわかるようになったのは、やはりPlaygrounds(の「コードを学ぼう」)のおかげかと改めて基礎の重要性を痛感するやら感謝するやら。

 あと付け加えると、こいつの鐘を鳴らすと木魚の音が途絶えるのもインスタンスを複数立てることで簡単に解決しております。 こちらはもろSwiftでのクラス利用方法(文法)を理解した結果でした。
 
 う〜ん、なんだかとっても納得できた。

| | コメント (0)

あらら、macOS 11の波に乗れない

 先日行われたAppleのWWDCで発表されたmacOS 11、なんと私の二台のMacには共に非対応であることが判明しました。

Bigsur

 ということはこれら二台の最新OSは10.15 Catalinaで打ち止めとなるのですね。
 と言われても、MacBook proは現在10.13 High Sierra、iMacはさらに古くて10.11 El Capitan。 使用目的から現状別にこれで困らないし、外付けSSDにはSwift Playgrounds用にCatalinaのシステムを組んであるので、まぁいいか、って感じです。

 ただ心配なのは開発関連のバージョン。
 以前にも書いたように、XcodeとmacOS、iOS、WatchOSは要求するバージョンが非寛容で、今回発表されたiOS 14とWatchOS 7が要求するXcodeのバージョンは12。
 デベロッパーサイトで確認すると12のβ版はCatalina 10.15.4で動くとあるので、最短で来年のWWDCまでは手持ちのMacでいじれそうです。
 
 でもこれが最後でしょうねぇ...

画像引用:Apple

| | コメント (0)

コードを学ぼう 1 & 2の初心者解説完成

 休校中の専門学校生への課題として提案していたSwift Playgrounds「コードを学ぼう 1 & 2」の解説と参考コードのGoogle driveへのアップロードが終わりました。
 
 全内容のクリアは1ヶ月前に終わっていたものの、他人に解説するとなると改めて書き直したり、言葉の確認をしたりして良い勉強になりました。
 
 対象としているレベルは、まずはコードを学ぼうを始めたけど途中で分からなくなった人。
 
 web制作に絡んでいる人で、htmlを中心としながらもphpやらJavaScript、Pythonなどの領域に入ることが多く、とりあえずネット記事の切り貼りや先輩のアドバイスで切り抜けているような人。
 
 その度に、オブジェクト指向だとかクラスとかインスタンスとか出て来るので一応調べて見るんだけどやっぱりわからない、と言うような人。

 教員や指導的立場にある人で、子供達にプログラミング指導を通して論理的思考を学ばせなければならない、学ばせたいと思う人。
 
 に向けて、子供向けゲーム風に解説しています。
 参考コードはあくまで参考で、これでなければならない、というものではありません。
 どうやっても自力でクリアできない場合にただ諦めるのではなく、参考コードを貼って、自分のコードとどこが違うかを調べるための材料として用意しました。
  
 ときどき意味不明の冗談が入っていますが、これは私が教えている学生たちに向けてのものです。 本質には関係ないので無視してください。

 アップロードしたGoogle driveへのファイルアクセスはこちら
 著作権は放棄しませんが、編集も使用も自由です。 txtとpngのみなのでウイルスの心配は無用です。
 明らかな間違いなどありましたらコメントでお願いします。
 

| | コメント (0)

Swift Playgroundsの◎

 やたら重い、遅いが目立ったMac版Swift Playgrounds ですが、GPU性能の高いマシンで扱うとサクサク動くので、もっぱらFLOPSが3,000GのiMacでやり込み(重い重いと嘆いていたMacBook Pro.は333Gなので9倍早い!)、本日めでたく「コードを学ぼう2」まで終わりました。
Pg3 
 さすがに2の後半は難しくて、最後の最後、「違う方法で配列を作る」では画面右下のヒントを辿って、なんとその最後に正解コードが用意されているのを知り、おかげでコンプリート。
 というか、その段になるまでここに正解が用意されているとは知らず、ま、よくここまで自力で何とかなったな、と自分を褒めておくことに。
 
 で以前書いたように、1と2を終えたらswiftの仕事ができるんじゃない?というのは無理としても、かなりいい勉強になりました。

 何より今ひとつどこに書いていいかわからなかった関数(func)、swiftのドットシンタックス、何より難解で何度本で読んでも会得できなかったインスタンスの使い方に救われました。(characterとCharacter()の違いとか)
 2の配列から急に無機的な内容になったのは、さすがのアプリケーション制作者もアイデアに困ったのかとも思えますが、中身を確認するのが面倒な配列を何とかわかりやすく解説してくれています。

 で、今改めてXcodeを立ち上げ、自分の書いたプログラムを見直してみると、あぁ、なるほどここがおかしいな、とか、こうすりゃもっと反応が早いのか、とかなり違って見えてきました。 もちろんまだまだswiftの道は険しいのですが、なんか適当にネットからコピペして泥縄でやってた頃よりは少々スマートにかけるようになったんじゃないかと思います。
 
 とりあえずこれは休校中の学生の課題にすることが決まっていて、ネット上で私がワンポイント解説を添えて指導してゆく予定です。
 多分緩んでいるであろう学生の学習のモチベーションを回復できれば、という願いを込めて。

| | コメント (0)

Swift Playgroundsの○と×、そしてCatalistの?(2)

 さてPlaygroundsの○ですね。
 これはもう文句言ったらバチが当たるくらいの充実度です。
 
 「コードを学ぼう1」から始まりその2へと続いて、さらにレベル別や目的別に多数の課題が用意されています。
 私はXcode上での様々なxxkitの利用方法が今ひとつで、この悩みも「Bluの大冒険」くらいまで終えれば何か光が見えてきそうな期待を抱いています。
Pg1_20200402220101 
 さらに仮にここにキャプチャーしている課題を全てクリアするころには、老若男女問わずSwiftの仕事を請け負えるくらいのスキルが身につくかもしれません。
 たまたま今は外に出るのがはばかられる社会情勢ですから、特に学生は家でこれに没頭してみてはいかがでしょうか。

 ただ、それにしても惜しむらくはGPUに深く依存する動作の重さ。
 ちょうど今年度から小学校のプログラム授業が始まりますから、これを使ってif, for, while文などの基礎を学ばせるのに良いのでは、と思われる教育関係者もいると思いますし、それは間違いでは無いと思います。(実際には、学校へ出入りする業者はApple嫌いが多いので実現しにくいですけどね。 正確にはAppleでは利益が上げにくいからなんだけど)
 
 とはいえ、もしPlaygroundsが導入されるならハードはおそらくiPadになるでしょうから、Playgroundsをインストールした実機でどれくらいの速度で動くかを確認することは必須でしょう。
 もしかするともとはiPad OSで開発されたものなので、iPadでならサクサク動くのかも、と淡い期待を持ってはいますが。(でもiPad proとかを要求する気がする)
 
 せめて3Dアニメーションを止めるとか、レンダリングクオリティを選べるようにするとかのハードへの負担軽減措置が取られれば、また大きく使用感が変わると思うんですけどねぇ。
 
 んで、せめてものお遊びとして、「コードを学ぼう」では主人公を三人の中から選ぶことができます。 とはいえ全員ある種不気味なんですが、私は緑色のホッパーが好きです。
 これ、多分女の子じゃないのかな。 ミッション成功したら嬉しそうな顔をして頭を左右に振るところがお気に入りです。
Hopper

| | コメント (0)

Swift Playgroundの○と×、そしてCatalistの?(1)

 MacFan 4月号にSwift PlaygroundがMacに移植されたという記事がありました。
 これまでXcodeでアプリを作成し、いくつかは実際に公開していますが、その間にXcodeの言語は、Objective-C、Swiftとの混在、Swiftのみ、と変化してきました。
 正直、Objective-Cは私には難解で、Swiftへの移行がなければ私はXcodeを諦めていたと思います。

 しかし一方で、ネットに上がっているライブラリやQ&A、市販本がこの変化についてゆけず、独学で学んでゆくことが難しくなったのも事実です。 もちろんSwiftを教える教室はオンライン・オフライン共にありません。
 そんなもどかしい思いを携えていましたから、Playgroundでもう一度基礎から勉強し直せるかも、と惹かれた記事でした。
 
 ただしPlaygroundをMacで動かすには最新OSのCatalinaが必要。 いや、あれ重くて、さらにネットワークとか色々トラブル多いのを学校で経験しているので、あまり気が進みません。
 それなら、と余っている外付けSSDにCatalinaをインストールし、それから立ち上げてPlaygroundを動かすことにしました。

 まずはEraly 2013のMacBook Pro. Retina 13で動かしてみると...
 重い!重すぎるわ!
Pg1

 いや、この愛機、今では少々古いけど、ポートは多種類ついてるし、何よりBTOで3.0G i7(デュアルだけど)にしたので、新しいMacBookと比べても体感的にそれほど遜色を感じません。 なのに、たまたま共にPlaygroundを始めた娘の1.6G i5のMacBook Airと変わらぬ鈍重ぶり。
 え? なんで? なんで? なんで?

 いや、落ち着いて検証だ、と外付けSSDを外して同じi7ながらクアッドのiMac 27から立ち上げてみる。 するとあれ?なんてことなくサクサク動くぞ? デュアルとクアッドの違いはあっても、アクティビティモニタの振れも全く違う。
 
 そこで気づいたのがGPUの違い。
 牛歩のごとく遅い私のMacBook Proと娘のMacBook Airは共にGPUはCPU内蔵のIntel HD graphics 。 対してサクサク動くiMacはNVIDIA GeForce GTX680MX 。 それぞれのFLOPSは333G、770G、3000G。 iMacは桁が違います。
 ちょっとショックだったのが二年発売が遅い娘のMacBook Air。 CPUは1.6G i5デュアルに過ぎないのに、さらにクソほど遅いかというとそうでもないのはIntel HD graphicsが倍以上速くなっており、要するにPlaygroundを快適に動かすにはGPU性能が大きくかかわっているということです。

 ×はそれだけではありません。
 「コードを実行」というボタンを押した後、MacBook Pro. RetinaとMacBook Airでは丸い矢印が延々と回って待たされます。 つまりコンパイルエンジンの出来が非常に悪いとわかります。 Xcodeなら、もっと複雑で重いプログラムでも実行と共にSimulatorというバンドルアプリが引き継いでストレスなく表示されるのに、もかかわらず。

 Playgroundっていうくらいだから、お下りの少し古いMacで子供が使うことも考えたら、こんなに忍耐を強いる仕様じゃダメだと思わないの?>Apple
 いや、それはあんたのMacが古いから、と言われるかもと最新のMacBook Air 2020を調べてみたら、GPUはCore i5-1030NG7というもので、GPUはIris Plus Graphics、FLOPSは1000Gとわかりました。
 確かに娘のAirの770Gに比べると進歩しているとはいえ、1.3倍ではPlaygroundは快適には動かないでしょう。

 なんでこんな中途半端なことになってるんだろう?と考えてみるに、このPlayground OSX版はもともとのiPad OS版からCatalistという一種のコンバーター的技術を利用して移植されています。
 もしPlaygroundがiPad上ではそこそこ軽快に動いているものであれば、このMac版の醜態はつまるところCatalistがダメだからなんじゃなかろうかと想像します。 横着せずに最適化しろよ>Appleプログラマー、と。
 
 すでに定期刊行されているMac雑誌が一誌しかないなかで言ってもしかないけど、数冊競い合っていた頃は、アプリケーションを実際に動かしてみてより便利な使い方や欠点をレポートするコーナーがありました。(実は私はそういうライターをしていた) しかし今はリリースに肉付けしただけのような、いわゆる利用者視点の評価が姿を潜めてしまったのが残念です。
 そんなものネットにあるだろう、と言われるでしょうけど、メジャーなサイトも似たり寄ったり。 利用者の本当の声を聞きたければブログやSNSを深く探し回らないと見つかりません。

 あ、×だけで長くなってしまった。 ○は改めて続きで書きます。
Pg2

| | コメント (0)

HyperTalk的Swiftの解釈

 さて、この盆灯篭アプリの話もそろそろこれで終わりにしましょうか。
 
 以前にも触れたように、私の本格的なプログラム体験はHyperTalk & LINGOです。 これが当時からすでにオブジェクト指向だったそうですが、そんなことは全く意識していません。

 

 どこかでボタンをクリックするとコールを起こし、これを仮に"action"という名前にすると、それを別のところで"on action"というハンドラが検知し、そこに書き込まれている機能を実行する、つまり定義されたfunctionを実行する、というのがとても手に馴染んでいました。
 
 ところがこの感覚がSwiftに馴染まず、よって私のようなHyperTalkあがりには使いにくいというか理解しにくい原因の一つであったのは事実です。
 そこでここでも触れた"viewDidLoad()"の上書き。
 
 "viewDidLoad()"自体は、そのスペルの通り、「アプリがロードされたら以下のことをします」というまさしく関数というかfunctionで、普通にSwiftでプロジェクトを立ち上げたら必ずviewController.swiftに最初から書き込まれています。
 変な話、アプリが立ち上がった後、何もさせたくなければここに何も書かなければ良いだけ。
 
 で、私はずっとこれは、アプリが立ち上がった直後のみにしか反応しないハンドラ(じゃないんだけどHyperTalk的に)だと思い込んでいたのですが、@objcをキーワードとしてiOSデバイスの画面上にボタンを用意し、それが押されたら... つまりHyperTalk的にいうと"on mouseUp"に"viewDidLoad()"を書き込んでみたら。
 
 あら、アプリが立ち上がった直後と同じ動きが始まりました。
 あ、ちょっとHyperTalk的。 あ、これがオブジェクト指向だったという証?
 この辺り、クラスやらインスタンスと何度参考書を見ても完全に理解できなかったのが、かなり氷解。
 
 私のこのアプリは、SceneKit、さらに全90回にも及ぶ篤志な記事に触れた方であれば想像がつくように、例のくるくる回る宇宙船を元にしています。
 こいつを灯篭にし、最初から回転させるようにしたのですが、"runAction(SCNAction.repeatForever())"を使っているので、"viewDidLoad()"自体はループしているわけではなく、すでに終了しています。
 ところが灯篭の絵柄を変更した時には別の".scn"ファイルを読み込み直させているため、この"viewDidLoad()"を再度呼び出さなくてはならなかった、というわけです。
 
 え?なんでそんな原始的なことをしているか?
 そうです。 背景を変更する時にはスマートな命令で処理しているので、".scn"を読み込み直すことはなく、よって画面推移も比較的スムーズです。
 なのになぜ灯篭絵の変更はそれができなかった?
 いえ、恥ずかしながらDiffuseを変更するのに"scene.background.contents = UIImage(named:"xxx.xxx")"に相当する命令を見つけられなかっただけ、というポンコツぶり。
 
 仕方ないのです。 今年のお盆に間に合わせたかったのです...

| | コメント (0)

Xcode、シミュレーター、実機、メモリリーク

 なんかSEOのタグ付けみたいな題名になってしまいました。
 要は、「シミュレータでは動くのに、実機で試したらメモリリークが起きて起動できなかった。実機テストが重要なのはわかってるけど、さりとていくつも実機を用意するわけにもいかず」という話です。

 このアプリはシミュレーターでは主にiPhone XRで、実機は自前のiPhone SEでテスト、iPadはシミュレーターのみで行っていました。
 ただiPadは、もし安いのがあれば、今回設定iOSの一番古いバージョンである9.3が動く古いのを手に入れてもいいかな、とも。
 ネットで調べると、iOS9.3の3rd gen.が一万円ほど。 え?高くない? と思いつつ、ポイントを使い倒して支払い5千円ほどにしました。 ちょっと勿体無い買い物だったなぁと思いつつ、Xcodeに登録して実機で走らせると...
 スタートアップが一瞬垣間見えた後、画面が真っ白になって異常終了。

 おりょ?

 なんどやっても同じで、あ〜、もう完成したと思ってたのにぃ。 所詮私の人生こんなもん。 としばし絶望。
 が、ここまで来て諦めるのも悔しい。
 と、今度はiPad実機を接続したXcodeを眺めながら何度もトラブルを再現することに。 すると使用メモリが一時1GBを超えることに気づきました。 そのあとは数百MBに落ち着くので、もしやと思い、ネットで今度はiPadの搭載メモリを検索。
 すると3rd.gen.は1GBだと判明。 
 アプリ自体のサイズは二十数MBだし、考えられる原因といえばこれか、と考えを巡らすことに。

Memory

 一旦1GBを超えたあとは一気に落ち着くことを考えると、立ち上がり時の問題、例えば読み込みに問題がある可能性が高く、デフォルトでbackgroundに銀河の写真を設定したことに気づきます。 まぁ、その方が見栄えもいいし。
 SceneKitの仕様で、立体を取り巻く周囲の画像は、仮に視覚固定で一方向しか要らないときでも正六面体で包む仕様となっています。 ただ、少しでも画像容量少なくするために背景以外の5面は真っ黒にして圧縮が効くようにしてありますし、せめてもの対策としてPNG24からPNG8にしてみるも改善せず。

 ん〜、とさらに検索すると、
scene.background.contents = UIImage(named:"xxx.xxx")
 という命令を発見。

 あ、ならば、とGUIの方でデフォルトはblackにし、ボタンを押すことで銀河の画像に切り替えるよう変更。
 するとこれが功を奏して、無事実機iPadでも立ち上がるようになりました。

 でこのbackground、さらに面倒なことに、iOS9.3では表示されないこともこの実機で判明。
 おかげでアプリの紹介文にはその旨書き加えることができて、めでたしめでたし。

 ではないのである。
 確かに今回はたまたま助かったものの、全対象デバイスを実機で試すのは不可能。 が、非常に重要。
 もちろん世の中にそういうテストをする業者があるのは知ってるものの、そもそもそんな大掛かりなものじゃないし、さりとて例え120円でも買ったわ立ち上がらんわ、となったら批判爆発でしょうから、それも避けたいし、いや、そもそも余ったiOSデバイスで仏壇のお飾りをと思ったから仕方ないとはいえ、古いiOS、イコール古い端末を相手にするのはほどほどに、ということでしょうかね。

| | コメント (0)

盆灯篭アプリ公開

Bonicon ここしばらくいろいろと事が順調に進み、忙しさよりも達成感を感じる方が多いというありがたい日々を送っています。
 実は今日、第二種電工検定の実技試験が終わったのが最大の解放感なのですが、ここしばらくの書き込みの流れから、ずっと懸案だったiPhoneアプリが完成、公開されたのでこちらを先に書くとしましょう。

 ここをiOSデバイスでお読みならダウンロードはこちら 。 iOSデバイス上のAppStoreアプリから「盆灯篭」で検索してもすぐに見つかります。
 あ、有料なのは、絵やら音を複数お金払って購入したからです。 ご理解のほどを。

 すでに使わなくなったiOSデバイスを仏壇に供えっぱなしにできるよう、古いiOS、今回は9.3から動くようにこころがけ、結果iPad3でも稼働できるようにしております。 実機テストはしていませんが、iPad2でも動くのではないかと。

 元はと言えば五年前の母の初盆の折、あぁ昔家にあった盆灯篭をずっと回していたかったな、と思ったのが始まりです。
 仕掛け的には3D技術を使って、とまではわかりつつも、プログラム的に全く未知の分野だったことと、何よりメインとなる灯篭絵が思うように手に入らないまま、iPhoneのリマインダーにずっと塩漬けになっていた案件でした。
 てな話は、ほんの少し前にここに書いて、技術的にはネットにしっかりと書かれたほぼ日本語の公式資料とも言える記事を大いに頼りにしたというのも既述のとおり。

 で今回、Swiftを理解したとは言えないまでも、一つ大きな進歩だったのはsuperクラス、具体的にはどのViewController.swiftにも決め打ちで書いてあるsuper.viewDidLoad()を@objcとかの関数から好きなタイミングで呼び出すことができるという発見でした。

 これって、昔のHyperTalkやらLingoのonハンドラー的な使い方を連想させて、「なんだ、これができるんだ」と思わずニヤリとしながら呟きました。 とはいえ、調子に乗ってこれを使い込もうとするとまた別の問題にあたるんでしょうが、多分それもなんとかなるんじゃないかと、なぜか最近は少々強気になっております。

 とりあえず今年こそはお盆に間に合わせたかったのもあって、コードそのものは洗練されたとは決して言えないレベルなので、もっとすっきりしたものに整理し、さらにすでに浮かんでいるアイデアを加え、来年に向けてのver2.0にしてゆきたいと思っています。
 
 あ、古いiOSデバイスの搭載メモリによるエラーってネタもありますが、これは次回にて。

| | コメント (0)

日本のSceneKitの原点

Bontourou1

 お盆に的を絞ったiOSアプリ、ver.1はほぼほぼ完成で、あとは公開申請に必要なマーケティングサイトを整備すれば終了です。
 このアプリについての詳細はAppStore公開時に改めて書くとして、今日はこの核となった技術のAppleのSceneKitというフレームワークについて。

 今回のアプリには3D技術が必須であるとはわかりつつ、swiftの知識も今ひとつなのに、さらに3Dなんてなぁ、と遠い目で途方にくれること数年。
 とりあえずSceneKitというフレームワーク(3DCGライブラリ)がiOS上での3D空間開発に必須というのがわかり、いつものようにジュンク堂へ。 というか、それ以前にネットでも書籍検索をし、日本語で書かれたSceneKitの参考書がないことは薄々わかっておりました。 そして案の定、頼りのジュンク堂でも発掘できず。

 これにはiOS開発言語がここ数年でObjective-Cからswiftへと徐々に、しかし確実に移行しているのも原因の一つで、書棚の下の方にデッドストック的に残っているiOSの3Dやらゲーム関連の書籍はObject-Cベースのものばかり。 さりとて出版業界も今さら全面swiftに対応した改訂版を出す気もないようです。 たぶん、もう多数の素人がXcodeを立ち上げてiOSやらのアプリを作る時代は終わったという(商売にならない)との見切りもあるのだと想像します。
 
 Appleは盛んにデベロッパー参加を煽り、日本の小学校でもプログラミング教育が始まろうという昨今ながら、戦場は先鋭化したプロしか売れるアプリが生み出せないほど高度化しているという乖離が透けて見えます。(売れるアプリを作れるプログラマーを養成しようっていうだけじゃないのはわかっていますけど)

 ま、それはさておき、日本語で書かれた専門書がないのは辛い。 と改めて具体的なキーワードでネット検索すると、はてなで全編90回に渡るSceneKitの解説記事を発見。 あまりに膨大すぎて題名をエクセルで別途管理しないと大変、なんて罰当たりなことを言ってしまいそうなほどの貴重な資産です。 本当にありがとうございます。

 読み進むうちに、SceneKitにはSceneEditorというのが用意されていて、GUIで3D空間を用意できることがわかり、これが先日書いた、たった数時間の自習時間の監視で大きく開発が進んだ理由でもあります。
 といっても最終的にはそれらのシーンをswiftで繋ぐのに苦労するんだけど、それすらネットの他の方の記事を参考に確実に乗り越えることができました。

 WatchOSの開発時にも同じくネット上の先人にお世話になりましたが、あれも紙じゃなくてKindleベースでしたっけ。 いやほんと、今更ながら改めてデジタルの恩恵を再確認した次第です。

| | コメント (0)

より以前の記事一覧