« 2019年4月 | トップページ | 2019年6月 »

久々にMac雑誌を買ったのは

Macfan

 Mac雑誌って今では滅多に買わないんだけど、Appleが広告で使った曲の特集があったのでMacfan 6月号をレジに。

 特集そのものと同時に惹かれたのが、各曲紹介ごとに二つずつついているQRコード。 これをスマホで読み取ると、一つはiTunesストアに、残りはYouTubeにリンクするようになっています。
 つまり記事を読みながら紹介されている曲と映像を確認できるわけで、なるほどこういう方法があったか、と。

 YouTubeへのリンクに特に許可がいるわけでもなく、iTunesの方もアプリで数十秒視聴できるシステムと同じだし、これなら印刷媒体で音楽やら映像に触れる可能性がずいぶん広がると思いました。 今更ながらQRコードのメリットを再確認したという話です。
 
 ただ…
 なんか面白い曲と出会えるだろう、への期待はハズレ。
 全三十余曲あって、これは、というのは全て古めのロック系ばかりで、新しいのにもう一度聴きたくなるようなのはありませんでした。

 いや、良い曲はもう無い、なんて厚かましいことを言うつもりは全く無いんですよ。
 主に夕風呂と炊事時間にはこんな方法で音楽を聴きながら、お!っというのに出会ったら即曲名メモしてiTunesストアで探して、という努力は続けています。
 が、それもよくよく見たら二十年くらい前の曲だったとか、う〜ん、って感じ。

| | コメント (0)

他人のWindows10からMacのパブリックに接続させる方法

 これ、何を今更、というネタに見えて、実は難解でした。
 ポイントはMac側のパブリックを誰に公開するかで、単にファイル交換目的で自分しか使わないのであれば、ネットやら本に載っている方法でいいんだけど、例えば教師用MacのパブリックをWindows10を使っている学生に公開する(まさしくバプリックな使い方)となると、途端に情報がなくなります。
 Macユーザーであれば、他のMacのパブリックフォルダーにはノーパスで簡単にアクセスできるのに、Windowsからはパスワード認証が必要であることが問題のポイントです。

 うちのコースは、入学とともに個人用MacBook Proを購入させますが、転コースや留学生など、どうしても手持ちのWindowsマシンしか用意できないという例も稀にあります。
 今年度がまさしくそれで、前例から多分5〜6年ぶり。 その間にMacもWindowsもOSが変化し、当時はなんとかなっていたMac-Win間のパブリックフォルダーを通してのデータのやりとりができなくなっていました。(Windowsがsmb1をデフォルトでオフにしたという話は関係なし)

 家に帰ってからEl Capitan(MacOS 10.11)のパブリックにWindows10から接続するテスト環境をセット。 結果、少し手こずりつつも解決策が見つかりました。

 ポイントはユーザー管理。
 ネットで一般的な情報では、システム環境設定の「共有」しか触れていませんが、ここの「オプション...」で出てくるユーザーは、同じシステム環境の「ユーザーとグループ」でコントロールされています。
 ですから、普通はここには管理者(多くの場合は自分)が表示され、そのパスワードはログインもできるレベルですから、そのまま他人に教えるわけにはいきません。(逆に自分だけが他のマイWindows10マシンからアクセスするならなんら問題はない)

 そこで「ユーザーとグループ」左下の+ボタンから、例えば「windowuser」(仮)という共有のみに権利を絞ったユーザーを作り、パスワードも「pass」みたいな簡単なものをセットします。 ログインはさせず、ローカルエリアだけのパブリック公開なのでこの程度のゆるさでも問題はありません。
Winpub1

 それから「共有」の「オプション...」を押すと、Windowsからアクセスを許可するユーザーのリストが出るので、windowuser左のチェックボックスをON。 するとパスワードの設定を迫られますので、ここに「ユーザーとグループ」で設定したパスワードを入力します。
Winpub2

Winpub6

 次にWindows10でエクスプローラーを立ち上げ、上部のフィールドに、¥¥192.168.1.1¥的なMac側のローカルIPアドレスを入力。(.localのホスト名でも可)
 するとユーザーとパスを聞いてくるので、先ほどMac側で設定した「windowsuser」の情報を入力。 これで上がりです。
Winpub3 Winpub4 Winpub5

 注意したいのは、ここでWin10上に現れるのはMac側の「共有」で管理者が恣意的に設定したフォルダーであって、「windowuser」のパブリックでない、ということ。 落ち着いて考えるとわかることながら、煮詰まっているときには意外とハマるややこしさかと。

| | コメント (0)

AppStoreで異なるバージョンのアプリを共存させる

 うん、Appleのアプリを開発してる人じゃないと全然意味が通らないタイトルだ。
 
 今回のAppleWatchアプリのアップデートは、Watchがシリーズ4となったことが発端でした。 一方で、最も古いWatchではこのシリーズ4用にアップデートしたバイナリは動きません。
 シリーズ1〜3は多分両方が動くんじゃないかと思いますが、残念ながら現物もなく、Watchを震わせるエンジンはシミュレーターでは限界がわからない、つまりあまりテストの意味がない。 よって、最も古いのと取り敢えず現時点で最新のバージョンをAppStore上で共存させたかったのです。

 AppStoreへの言わば業務用入口となるAppStore connectに新しいアプリをアップロードするとき、まずはマイAppから+ボタンを押して新規Appの項目を作らなくてはならないのはご存知の通り。
 ここに「バンドルID」という項目があり、結論から書くと、これがAppStore connectが、アップロードされたバイナリが新規なのかアップデートなのかを判断する根拠となります。
Con1 
 でも、はて? バンドルIDって何だったろう?って思いますよね。 それを助けてくれるのが、この「新しいバンドル ID を Developer Portal で登録します」という一行。
 ここのリンクをクリックすると、突然Appleのデベロッパーサイトに飛ばされます。

 ここが非常にわかりにくくて苦労したのですが、答えとしては、左のサイドバーの「Identifiers>App IDs」をクリックすると、自分のXcodeで作ったアプリのID、つまりバンドルIDがずらりと出てきます。 つまり、このデベロッパーサイトは開発者のXcodeとも裏で繋がっているのです。 あなおとろしや。
Con2


 今回のWatchアプリの場合、シリーズ4用と言っても、初期型の言わば別名保存版ですから、IDは同じ。 これを見てAppStore connectはアップデートと判断します。
 よって、今度はXcodeでTARGET>General>Bundle Identifierあたりを別の名前にすることで、上の「新しいバンドル ID を...」云々で別アプリとして登録できる、ということがわかりました。
Con3
 Swiftやそれ以前のobjective-Cを含むXcodeの情報は多数ネットにあるのに比べ、このAppStore connectを含むアプリ管理に関しては希薄で、やっとプログラムから解放された後の疲れのだめ押しをされます。

| | コメント (0)

AppleWatch用メトロノームアプリ、シリーズ4に対応

Main_icon_round_ol やっとBeat on WristというAppleWatch用アプリがシリーズ4に対応しました。
 
 シリーズ4から要求OSのバージョンが上がり、それまでのが動かなくなっているのはわかっていながら、Xcodeの持病的バグである"signal SIGABRT"に苛まれて今になったという理不尽さ。
 おかげでAppStoreにネガティブなコメントがついてしまいました。
 
 ま、それはさておき、今回、初代AppleWatch用に最初のバージョンをStoreに残したままにすることにしました。 が、実はこれが難しく、普通にXcodeからApple Connectにアップロードすると、どうやってもアップデート、つまり先代(無印だけど強いていうならver.1)を置き換えようとします。
 いやいや、それじゃこまるんだって、とあれこれやって、新旧バージョンを両方残した、という話はまた改めて。
 
 でも長い間気になってたことが解決してすっきりしたわ。 ビールもうまい。

| | コメント (1)

Timerクラスとバックグラウンドの面倒

 ま、やっぱり私がすることだもんなぁ、そんなに上手く行く訳がないさ。
 テストしていた孤立校舎のチャイムアプリ、バックグラウンドに回ったら動かないことが判明。
 
 え?と思って調べたら、そうか、Timerを使っている限り避けられないのか、と今更になって納得。 簡単にいうと、このクラス、アプリがバックグラウンドに回った途端に動作が止まるしまう仕様なのです。
 以前AppleWatchのアプリでも苦労したにもかかわらず、再びドツボにはまったのかと、自分の思慮と知恵の浅さに呆れるばかり。
 
 そもそもなんでswiftというかAppleのOSはことごとくバックグラウンドでのアプリの動作を制限したがるのかというと、単なる横着とは責められない面もあります。 曰く、バックグラウンドでフォアグラウンドと変わらない動作を提供すると、例えばキーロガーなんてのがこっそりやりたい放題になる、つまりはセキュリティ思想が元になっています。
 
 とはいえ、多くのmacOS市販アプリは裏に回っても普通に動いていますから、当然回避策はあります。 ただ、ネットで出てくる対策は、対象がiOS,macOS曖昧で、かつ非常に難解。

 そこでポンコツな私は思案した。
 このチャイムアプリは私の勤めるたった一つの校舎のたった二つの教室でしか使われません。 しかも使用するのは教師のみ。(最悪私のみ) 一方で、すでに授業は始まっており、完璧を求めて長い時間を費やしている場合ではありません。
 しかも今はXcodeからAppStoreを経由せずともローカルでアプリの生成が可能。
 
 そうだ、クソで良いんだ。
 いや、良い訳ないんだけど、良いのだ。

 そう決めたら、話は早い。
 Timerを使わず、while(repeat while的なもの)で毎秒時間を拾い、条件が合えばチャイムを鳴らすように改造。 えっ?と思われたそこのあなた。 プログラムのエキスパートですね。
 そうです。 whileは無限ループへの近道と要注意の超初心者技法。
 確かに一旦動き出すと、チャイムに関しては期待通りの働きをするものの、レインボーカーソルぐるぐる、quitも含めて後は一切の入力を拒否します。 つまり明確に無限ループしてる、と。

 ただ、それを予想してこちらも速度制限目的のsleep()を一秒毎にかませたため、cpuの限りループすることはなく、半日稼働させてもアクティビティモニターでcpu/メモリ負荷共、全く問題はないことを確認。

 アプリの終了すらできないので、Command + option + escで強制終了するしかありません。
 でもきっちりと期待した通りにチャイムは鳴っている。 仕込んだイースターエッグも息災だ。
  
 とりあえずはこれでええやん?
 教員、下手すると私しか使わんやん?
 コンピューターが人の役に立ってるやん?
 
 ほんと、クソアプリでごめんなさい。
Shotofchime_1

| | コメント (0)

macOSアプリ初挑戦

 うちの学校に新学期に向けて新たな校舎が建設され、どこのコースがどう使うんだろうと思ってたら、なんと我々グラフィックデザインが使えることとなりました。 何はともあれ、新しいことは悪くありません。

 校舎規模そのものが大きくないのでエレベーターはガラ空き、仮に誰か乗っててもみんな顔見知り。 廊下の照明やらトイレやらは全て人感センサー連動で、当然ヒーター、ウォシュレット完備。 手洗いも自動&エアタオル付き。

 が、本校舎から離れているのでチャイムが鳴らない。
 そこで、教師用のMacで簡単に鳴らせないかとみてみたら、これが案外できなかったりするのに気づきました。 毎日決まった時間になんらかの音で授業始まり・終わりを教えてくれるだけで良いのにね。

 PHPをどこかのサーバーにあげて、とも考えたけど、ブラウザを常に立ち上げておかなくてはならないのは色々不便。 てことは、macOS上で動くアプリを作って、ログインしたら自動的に立ち上がるようにすれば良いのかぁ、とまではすぐ思いついたけど、これまでiOSとwatchOSでの開発(ってな大層なもんじゃ無い。単なるポンコツプログラミング)ばかりで、Mac本体で動くmacOSアプリは未経験。

 ただ、やらなければならないことは単純だし、不特定多数に使ってもらうための配慮、例えば好みの時間を入力して保存するなどは不要なので、なんとかなるかも、とも考えました。

 んで今は丁度、日雇い殺しの十連休。 その空き時間を利用して、ではありません。 実はこれが幸か不幸かほぼすべて出勤。 しかし出勤しても仕事はほとんどなく、全く鳴らない電話の番と留守番のみ。 目の前にはMojabeで動くiMac。 そしてこの間何をやってても良いという、拘束なのか非拘束なのかよくわからない時間を過ごしています。

 そこでこのマシンにもXcodeをインストール。 やっとXcodeのくそ持病から回復したwatchアプリの仕上げをしながら初macOSアプリの開発も始めました。

 とは言っても、終わってみると実はwatchOS→iOS→macOSの順で簡単になるんじゃね?というのが正直な感想です。 気になったのは、ネット上にあるSwiftに関する記事の多くがiOSに絡んでいることくらいで、実際、フレームワークをインポートする際に「そんなものはない」と警告が出て気づきます。
 
 中身はというと、watchのメトロノームでも使ったTimerという機能を使って時間をチェックし、switch文が指定時間に適合したら音を鳴らす、という、「夏休み子どもプログラミング教室♪」なんてのに丁度良い程度のヌルさ。 未だに把握しきっていないdeligateなんて一切使っていません。
 鳴らす音はGaregeBandで作ろうかとも思いつつ、結局はフリーの英ビッグベンの鐘の音を拾ってきました。
 
 あらかたXcodeで試した後、AppStoreを経由せずに直接アプリをローカルに書き出して現在テスト中。
 これで問題なければ連休明けから実際に授業に使えるってもんです。
 
 ちなみにそれ以外の機能は全くないので、見た目はこんな感じ。 でも生成されるabout画面はちょっと一人前の気分。
 
 と思ったら? おや?
Shotofchime

| | コメント (0)

« 2019年4月 | トップページ | 2019年6月 »