たまにこういう日もあるよね、という、仕事あるあるみたいなもんですが。
朝、妻とテレビを見ていました。ちょっと遅めに起きた私は妻を仕事に送っていく準備をいそいそとしていました。そして、出かける直前、占いのコーナーが始まる直前、妻はニヤニヤとしていました。占いの結果は、妻が一位、私が最下位だったのです。そして、それを妻はすでに知っていた(1時間前に同じ占いをやっており、妻はすでに起きていたのです)ので、ドヤ顔で仕事に向かいました。
さて、妻を送り終え、家に帰って仕事を始めようと準備を始めました。PCは基本付けっぱなしなので、まずメインマシンで軽くメールのチェックをしながら、今日の仕事ではWindowsがどうしても必要になるので仮想環境のWindowsにログインしようとしました。しかし、ログインできません。画面が真っ暗です。
再起動をしたところ、今度は起動しません。真っ青です。PCがではなく私が。
特にデータを格納してあったりするわけではないので、最悪OSの再インストールで対応できるのですが、それでも再インストールには時間がかかります。しかもOSだけでなくアプリも復旧させるのは相当な時間のロスです。
とりあえず仮想環境で起こっている問題を解決しようとあれこれと調べつつやってみたのですが、何一つ解決に結びつく情報と出会うことなく、もちろん何ら状況が進展しないまま半日が過ぎました。
もうどうしようもありません。再インストールに方針を変えることにしたのですが、次に起こったのはメインマシンの不調です。こちらも突然真っ暗になり、動かなくなりました。私ももちろん真っ暗です。
メインマシンはどうやら不安定だったようで、再起動すると元どおり動き始めましたが、今度はネットワークが見つからなくなりました。以前バックアップ用のTime Capsuleが不調になった際に仮復旧させた状態で、本来ならば不安定になるはずの状況でしたが、問題も起こらなかったのでしばらく放置していたのが今更不安定になるとは。
そして、ネットワークの環境を正常な状態に戻し、やっと再インストールに取りかかれる、と作業を開始しようと思ったら、今度は仮想環境サーバのハードウェアに異常(というかガタ)が発生。HDDを接続するコネクタとケーブルが妙に引っ張られていて抜けそうになっていたり、ファンが異常な音を出し始めたり、CDのトレイが出なくなっていたり。力技で「なんとか」して、なんとか再インストールに成功しました。
が、これで結局さらに半日を費やすことになり、今日予定していた仕事は全く手につかなかった(仕事は資料作成だったので、空いた時間で手書きの資料を作りましたが)という何とも惨憺たる状況でした。
仕事のうまくいかない日、というのは結構ありますが、ここまで不運が続くのはなかなかありません。しかもそれなりに急ぎの仕事を抱えている時に限ってこういうのが連チャンで発生するんですよね。しかも占いが最下位だったし。
本当は、バックアップを取ったりとかしておかないと、こういう目にあうんですよね。考えておかなければ、なんてずっと思っていましたが、実際に実行に移さないのが悪いんですよね。落ち着いたらやろうっと。(←こういう態度が良くないんですね)
40歳を過ぎて会社を辞め、家族からは引きこもりと揶揄される日々を過ごし、 自宅の狭い部屋でMacと壊れかけのギターを愛でるヒゲのおじさんがここにいますよ。 プログラムやらLINEのスタンプやら作ってます。引きこもりマンセー。
2015年11月27日金曜日
2015年11月24日火曜日
小ネタ:Office 2016 for Mac 再インストール顛末
唐突ですが、普段Mac使いな人たちが意外に困るんじゃないかと思うこと。
「資料」が開けないことがある
基本的に世の中の「資料」はWindowsで使うことを前提に作られているようです。ちょっとした資料が送られてきても、PDFで来ることは稀、WordだったりExcelだったり。ちなみに、そのPDFもたまに開けない(または開いても印刷ができなかったりする)ことがあります。システムで自動作成されたやつで何度無駄紙を印刷したことか・・・。
まぁ、WordやExcelはMacでは絶対に使えないというわけではなく、インストールしている人も多いはずですし(特に仕事で使うなら必須でしょう)、最悪、iWorkを使うという手もあるので、全くお手上げ、ということにはなりません。
が、すでにOfficeをMacで使っている人は、それが突然使えなくなると困ってしまうわけです。私がそうでした。
ここ数日くらい前から、Officeの全アプリが起動しなくなりました。起動は開始するのですが、オープニングの画面(スプラッシュ)が表示されず、「応答なし」状態になってしまうのです。また、それ以前から、アップデートがちょっとおかしい挙動をするようになりました。アップデータをダウンロードし、かつインストールが終わったにもかかわらず、その後再度最新版の確認をすると、同じアップデートが表示され、延々と繰り返してしまうのです。
こういう時はお得意の「ググってみる」ことから始めますが、意外にも「Officeが起動しない」事象が発生していたらしく、いろいろな解決法が検索に引っかかってきました。
それで、自分の状況と照らし合わせてみると、1箇所だけ、自分の状況だけがおかしい、という点を見つけました。
実は、利便化のために、Officeに限っては「アプリケーション」フォルダから別のフォルダ(実際にはフォルダ直下)にもう一つOffice専用のフォルダを作ってあり、その中にOfficeアプリを全部放り込んでいたのです。これ自体は非常に都合がいいのですが(Dockにフォルダを登録しておけばわざわざアプリケーションフォルダから探さなくていいので)、おそらく、これが原因でアップデートが妙な挙動をしていたのではないかと推測できます。
#こういう時、本来ならエイリアス、Windows的に言えばショートカットを使うんですよね。
とはいえ、それを元に戻したところで起動しないことには変わりがなく、仕方がないので再インストールをすることにしました。そのやり方は思っていた以上に面倒で(基本的に、MacのアプリをアンインストールするのはWindowsに比べるとかなり面倒です)、詳しくはここを参照していただくとして、ざっくり言うと、
「資料」が開けないことがある
基本的に世の中の「資料」はWindowsで使うことを前提に作られているようです。ちょっとした資料が送られてきても、PDFで来ることは稀、WordだったりExcelだったり。ちなみに、そのPDFもたまに開けない(または開いても印刷ができなかったりする)ことがあります。システムで自動作成されたやつで何度無駄紙を印刷したことか・・・。
まぁ、WordやExcelはMacでは絶対に使えないというわけではなく、インストールしている人も多いはずですし(特に仕事で使うなら必須でしょう)、最悪、iWorkを使うという手もあるので、全くお手上げ、ということにはなりません。
が、すでにOfficeをMacで使っている人は、それが突然使えなくなると困ってしまうわけです。私がそうでした。
ここ数日くらい前から、Officeの全アプリが起動しなくなりました。起動は開始するのですが、オープニングの画面(スプラッシュ)が表示されず、「応答なし」状態になってしまうのです。また、それ以前から、アップデートがちょっとおかしい挙動をするようになりました。アップデータをダウンロードし、かつインストールが終わったにもかかわらず、その後再度最新版の確認をすると、同じアップデートが表示され、延々と繰り返してしまうのです。
こういう時はお得意の「ググってみる」ことから始めますが、意外にも「Officeが起動しない」事象が発生していたらしく、いろいろな解決法が検索に引っかかってきました。
それで、自分の状況と照らし合わせてみると、1箇所だけ、自分の状況だけがおかしい、という点を見つけました。
実は、利便化のために、Officeに限っては「アプリケーション」フォルダから別のフォルダ(実際にはフォルダ直下)にもう一つOffice専用のフォルダを作ってあり、その中にOfficeアプリを全部放り込んでいたのです。これ自体は非常に都合がいいのですが(Dockにフォルダを登録しておけばわざわざアプリケーションフォルダから探さなくていいので)、おそらく、これが原因でアップデートが妙な挙動をしていたのではないかと推測できます。
#こういう時、本来ならエイリアス、Windows的に言えばショートカットを使うんですよね。
とはいえ、それを元に戻したところで起動しないことには変わりがなく、仕方がないので再インストールをすることにしました。そのやり方は思っていた以上に面倒で(基本的に、MacのアプリをアンインストールするのはWindowsに比べるとかなり面倒です)、詳しくはここを参照していただくとして、ざっくり言うと、
- 「アプリケーション」フォルダからアプリを削除
- 不可視フォルダであるライブラリフォルダから特定のファイルを削除
- 再起動後にインストールプログラム起動
と、Windowsのようにアンインストールプログラム一発で削除できるわけではないわけです。
再起動が本当に必要なのかどうかはマユツバですが(私はおまじないレベルだと信じてます)、とりあえず指示通りにやってみました。しかも、これもおまじないと信じてやまないウィルス対策ソフト(我が家はAvastです)の無効化もしてみました。
インストールは無事完了し、一応Wordは起動することがわかりました。その後、アップデートが走り、最新版のOfficeで起動することができたので、問題は解決しました。
Macでも、Windowsのようなアプリの(いわゆる)安全な削除ができるツールを一緒に提供すべきなんだよなぁ、と開発している立場だと思ってしまう、というお話でした。
追記:
Office2016 for Macでの不具合は結構多いみたいです。今回、私は再インストールだけですみましたが、ググってみるとそれだけでは解決しないケースもかなりあるようです。あまり私のケースは参考にならないかもしれませんね。
インストールは無事完了し、一応Wordは起動することがわかりました。その後、アップデートが走り、最新版のOfficeで起動することができたので、問題は解決しました。
Macでも、Windowsのようなアプリの(いわゆる)安全な削除ができるツールを一緒に提供すべきなんだよなぁ、と開発している立場だと思ってしまう、というお話でした。
追記:
Office2016 for Macでの不具合は結構多いみたいです。今回、私は再インストールだけですみましたが、ググってみるとそれだけでは解決しないケースもかなりあるようです。あまり私のケースは参考にならないかもしれませんね。
2015年11月20日金曜日
インターネットラジオの録音に関する考察(その5:進捗状況)つづき01
毎週報告しなくても、と思いますが一応。
実は今週はほとんどコーディングしていなかったので(別のことやってた)、進んでないです。
まずは現時点(11/20)でできたところ。
一人でやるんでのんびりですが。
実は今週はほとんどコーディングしていなかったので(別のことやってた)、進んでないです。
まずは現時点(11/20)でできたところ。
- 番組表作成中。
元となるデータをダウンロードするところまではできました。NHKのデータは3局別のファイルでダウンロードすることになります。radikoは全放送局(もちろん聴取エリア内のみです)が取れます。
それから、デザインはまだやってないですが、少なくともリスト(JavaFX的にはListView)でやってみて、それから他のパーツを使うなり、いろいろ考えられそうです。
以上。
実は、その後処理になる、データを画面に表示させるところがどうしても実装できないんです。データがあればなんとかなると思ったのが間違いだったですね。世の中そんなに甘くないっす。
ということで、来週以降の予定ですが、
- 番組表の画面表示。とにかく画面に出そう。
- 積み残しのうち、デザインと広告あたり。
一人でやるんでのんびりですが。
小ネタ:無料アプリと広告
今日の小ネタはいつもと違い、アプリの収益に関するお話です。とはいえ、これは私が直面している話ではなく、一般的なお話でございます。
無料でアプリを提供する場合にどのように収益化するか、というのは以前のポストでも書いたことがありますが、アプリ内課金、もしくは広告収入、というのが考えられるわけです。というのを前提に。
わたくし事ですが、最近は使っていないスマホのアプリがいくつかあります。数年前、しかもリリースされて間もない頃に、「そうそう、こういうのが欲しかったんよ!」とインストールし、結構使っていたのですが、ライフスタイルの変化とともに、最近では起動することも少なくなっていました。
そのアプリのうちの一つが、テレビCMで流れるようになったのはここ数ヶ月前からでしょうか。職業柄、どうしても「お、この会社、ずいぶん儲かってるんだね」とアタマの片隅で思いながら、いずれにせよテレビCMを見たからといってアプリの起動契機になるわけでもなく、他のテレビCM同様、見過ごしていたわけです。
そして、今日、ふと気がついたことが。そのアプリからのオプトインメールを受信するように設定していた(らしい)のですが、以前よりオプトインメールの来る頻度が高くなったような気がしたのです。今朝、昨日のメールチェックでそのアプリからのメールを削除した記憶があり、週末に向けて夕方にメールチェックをしたところ、そのアプリからのメールが来ていたことで気がついたのです。確かに、この1ヶ月で週に2〜3通、今週は月曜着から金曜日まで毎日届いています。
ちょっとした違和感を覚えました。メールバンバン流してどんだけ広告収入を得ようとしてんのさ、と。でも、すぐにその理由に気づきました。テレビCMです。
アプリの運営会社はもともと、アプリ内にある広告がメインの収入源になっていたと仮定されます(アプリ内課金もありましたが)。でも、アプリがインストールされればされるほど収入が上がる、ということになるため、アプリの認知度を高める必要があるわけで、今までのように口コミだけではユーザー数は頭打ちになってしまう恐れがあったのではないでしょうか。
そこで、大きな認知度アップキャンペーンを行うことにしたのでしょう。そう、テレビCMです。最近はテレビ離れが進んでいるとは言え、テレビを視聴する人はまだまだ多いわけです。当然認知度が上がったでしょう。
ただ、そこにはおそらく大きな落とし穴があったはずです。テレビCMの制作および放送に相当額の広告費が費やされたはずです。そして、仮にアプリがインストールされたことによる売上が上がったとしても、それに見合うだけの利益を上げることができなかったのではないでしょうか。
とすれば、今度は既存ユーザに対してオプトインメールを送ることで、そこからの広告収入を得る、という方法で、なんとか売上(利益)を維持もしくは上昇させようと考えるのは無理からぬ話です。今日気がついたのはある一つのアプリですが、実は同様の理由で削除したアプリも今までに数多くあります。
その方法がダメだ、と否定するつもりは全くなく、利益を上げなければいけない企業の立場としては当然だとは思いますが、無料で使っているユーザー側として、その程度の「不利益」は受け入れなければならない、と、もしその企業が思っているのだとしたら、それはちょっと極論すぎる気はします。
ちなみに今回のアプリを開発した会社(もちろんどこかなんて言いませんよ)、財務状況とか全くわかりませんが、おそらく利益を少しでも前期より上げようとしているんではないかと。そして目指しているのは上場。そんなところでしょう。
それはいいことだと思いますし、素晴らしいことです。が、それによって、ユーザー側に不利益が少しずつ増えていくとしたら、果たしてそれはいいことなんでしょうか。利益を得たいと思うならまずは利益を出してくれる人のことを考えるべきだと思います。
・・・まぁ、会社によっては(今回のアプリの会社もそうかもしれません)大きな「資金源(≠利益源)」はユーザーではなく資本家だったりしますので、そちらをより大切にしてしまうこともあるかもしれませんけどね。
わたくし事ですが、最近は使っていないスマホのアプリがいくつかあります。数年前、しかもリリースされて間もない頃に、「そうそう、こういうのが欲しかったんよ!」とインストールし、結構使っていたのですが、ライフスタイルの変化とともに、最近では起動することも少なくなっていました。
そのアプリのうちの一つが、テレビCMで流れるようになったのはここ数ヶ月前からでしょうか。職業柄、どうしても「お、この会社、ずいぶん儲かってるんだね」とアタマの片隅で思いながら、いずれにせよテレビCMを見たからといってアプリの起動契機になるわけでもなく、他のテレビCM同様、見過ごしていたわけです。
そして、今日、ふと気がついたことが。そのアプリからのオプトインメールを受信するように設定していた(らしい)のですが、以前よりオプトインメールの来る頻度が高くなったような気がしたのです。今朝、昨日のメールチェックでそのアプリからのメールを削除した記憶があり、週末に向けて夕方にメールチェックをしたところ、そのアプリからのメールが来ていたことで気がついたのです。確かに、この1ヶ月で週に2〜3通、今週は月曜着から金曜日まで毎日届いています。
ちょっとした違和感を覚えました。メールバンバン流してどんだけ広告収入を得ようとしてんのさ、と。でも、すぐにその理由に気づきました。テレビCMです。
アプリの運営会社はもともと、アプリ内にある広告がメインの収入源になっていたと仮定されます(アプリ内課金もありましたが)。でも、アプリがインストールされればされるほど収入が上がる、ということになるため、アプリの認知度を高める必要があるわけで、今までのように口コミだけではユーザー数は頭打ちになってしまう恐れがあったのではないでしょうか。
そこで、大きな認知度アップキャンペーンを行うことにしたのでしょう。そう、テレビCMです。最近はテレビ離れが進んでいるとは言え、テレビを視聴する人はまだまだ多いわけです。当然認知度が上がったでしょう。
ただ、そこにはおそらく大きな落とし穴があったはずです。テレビCMの制作および放送に相当額の広告費が費やされたはずです。そして、仮にアプリがインストールされたことによる売上が上がったとしても、それに見合うだけの利益を上げることができなかったのではないでしょうか。
とすれば、今度は既存ユーザに対してオプトインメールを送ることで、そこからの広告収入を得る、という方法で、なんとか売上(利益)を維持もしくは上昇させようと考えるのは無理からぬ話です。今日気がついたのはある一つのアプリですが、実は同様の理由で削除したアプリも今までに数多くあります。
その方法がダメだ、と否定するつもりは全くなく、利益を上げなければいけない企業の立場としては当然だとは思いますが、無料で使っているユーザー側として、その程度の「不利益」は受け入れなければならない、と、もしその企業が思っているのだとしたら、それはちょっと極論すぎる気はします。
ちなみに今回のアプリを開発した会社(もちろんどこかなんて言いませんよ)、財務状況とか全くわかりませんが、おそらく利益を少しでも前期より上げようとしているんではないかと。そして目指しているのは上場。そんなところでしょう。
それはいいことだと思いますし、素晴らしいことです。が、それによって、ユーザー側に不利益が少しずつ増えていくとしたら、果たしてそれはいいことなんでしょうか。利益を得たいと思うならまずは利益を出してくれる人のことを考えるべきだと思います。
・・・まぁ、会社によっては(今回のアプリの会社もそうかもしれません)大きな「資金源(≠利益源)」はユーザーではなく資本家だったりしますので、そちらをより大切にしてしまうこともあるかもしれませんけどね。
2015年11月12日木曜日
インターネットラジオの録音に関する考察(その5:進捗状況)
なんか業務連絡みたいなポストであることをご容赦ください。
昨日(11/11)時点でできていることを列記します。
ちなみに、番組表の実装ですが、このポストを書いた後(この行より上は昨日の夕方書いた)、風呂に入っている時になんとなくアイデアが湧いてきました。実装がうまくいった時点でやり方を公開する予定ですが(失敗したら恥ずかしいので・・・)、ヒントとなったネットの記事をリンクしておきます。
テレビ画面はdiv要素でできている!- Hybridcastとテレビの未来 –
(from HTML5 Expert.jp)
記事自体は、デジタルテレビにおけるデータ放送画面がHTMLで構成されている、というものです。データ放送(記事内ではNHKのHybridcastについての言及ですが)を起動すると、内部ではブラウザが起動し、いわゆるWebの画面が表示されているという仕組みだ、とあります。
この記事は番組表実装の方法を考えるときにさらっと読んだのですが、その時はあまりピンとこなくて、ざっと読んですぐに閉じてしまいました。が、昨晩、まさに風呂に入っているときにふと、「とりあえず番組表をHTMLで書いたらどうなるんだろう?」と思いついたわけです。今回開発している環境では画面の構築はXMLを使っています。だとすれば、考え方は同じ方向を向いているわけで、うまくいくかもしれない、と。
確かに、データ放送画面を良く見ると(たまたま朝の情報番組を普段通り見ていたのですが)、上記の記事にあったようにHTMLで実装されていると言われればそのように見えます。ということは、テレビ自体がHTMLブラウザではないか、と仮定できます。テレビの機能画面は全てHTMLで描かれていると。
もちろん、これが「正解」とは思いませんし、私自身それほどコーディングに自信があるわけではないのでもっといい方法があるかもしれません。が、一つの方向性としてはアリなんだろう、とは思います。とりあえず出来るところまでやってみます。
昨日(11/11)時点でできていることを列記します。
- AFNとNHKは一部の局だけだが再生が可能であることを確認
(AFN:Local/Japan、NHK:東京エリア) - 再生可能な局については録音も可能だと思われるが未テスト
(出力フォルダを作っていないのでめんどくさい) - デザイン作成中。昔のポータブルカセットレコーダーとかサンプラーとかをイメージした、でも今風のデザイン作り中。
- 開発言語はJava。JavaFXで作る予定。正直すごく楽。XMLさまさまです。
次に考えること/やること
- NHKの番組表を作成。番組表をXMLで作るのはどうやってやるんだろう?なんとなくわかるんだけど(データを引っ張ってきてXMLを自動生成的な?)。
ちなみに、AFNは番組表がないのでどうしたもんかと考え中。特にLocal Stationはずっと聞き続けないと番組名わかんなさそうだよなぁ。作りながら聞くにしても絶対聞き流しちゃうだろうし。 - radiko加盟局の再生・録音機能実装
問題点は2つ。一つはradiko特有の「認証」の実装。やり方はわかってるんだけどめんどくさい。もう一つはエリア外聴取への対応(プレミアム対応といってもいい)。そもそも自分がプレミアム加入してないし。 - デザイン(続き)
そもそもそのデザインでいいのかよ、とは思ってますが。 - 広告の実装
そういえばデザイン考えるときに広告の配置を考えてなかったな。ちなみに、広告を貼り付けるだけで儲かるわけではないのだが、他に方法はないので(ないわけではないが自分が嫌なことはしたくないし)。
ざっくりとこんな感じです。
ちなみに、番組表の実装ですが、このポストを書いた後(この行より上は昨日の夕方書いた)、風呂に入っている時になんとなくアイデアが湧いてきました。実装がうまくいった時点でやり方を公開する予定ですが(失敗したら恥ずかしいので・・・)、ヒントとなったネットの記事をリンクしておきます。
テレビ画面はdiv要素でできている!- Hybridcastとテレビの未来 –
(from HTML5 Expert.jp)
記事自体は、デジタルテレビにおけるデータ放送画面がHTMLで構成されている、というものです。データ放送(記事内ではNHKのHybridcastについての言及ですが)を起動すると、内部ではブラウザが起動し、いわゆるWebの画面が表示されているという仕組みだ、とあります。
この記事は番組表実装の方法を考えるときにさらっと読んだのですが、その時はあまりピンとこなくて、ざっと読んですぐに閉じてしまいました。が、昨晩、まさに風呂に入っているときにふと、「とりあえず番組表をHTMLで書いたらどうなるんだろう?」と思いついたわけです。今回開発している環境では画面の構築はXMLを使っています。だとすれば、考え方は同じ方向を向いているわけで、うまくいくかもしれない、と。
確かに、データ放送画面を良く見ると(たまたま朝の情報番組を普段通り見ていたのですが)、上記の記事にあったようにHTMLで実装されていると言われればそのように見えます。ということは、テレビ自体がHTMLブラウザではないか、と仮定できます。テレビの機能画面は全てHTMLで描かれていると。
もちろん、これが「正解」とは思いませんし、私自身それほどコーディングに自信があるわけではないのでもっといい方法があるかもしれません。が、一つの方向性としてはアリなんだろう、とは思います。とりあえず出来るところまでやってみます。
2015年11月6日金曜日
小ネタ:アプリ制作とデザイン
私自身は、自分のことをエンジニアだと思っていて、デザイナーでは決してないと思っています。あくまでもプログラムを作る人で、プログラムのデザインとかあまり関係ない、と昔は思っていました。
そうは言っても作ったプログラムを使ってもらうためには、例えば使いやすさとか、使いたいと思わせるような動きとか、それなりに(実際にはかなり)重要だったりするわけで、どうしてもプログラムの「デザイン」、専門的な言葉を使うならUI/UXとか、そういったことを意識しないと本当はいけないわけです。
では、普通にプログラムをエンジニアが作るとどうなるか?基本的にプログラムの機能を作る人が作るものなので、デザインにはそれほどこだわりがありません。もちろん、ボタンの位置とか(整列していないとかどのボタンが右で左で、的なこと)は意識しますが、ストレートに言えばどんなアプリを作ってもまるで業務用のソフトみたいな(今でいうならふた昔前くらいのデザイン、でしょうか)感じになってしまいます。
私自身、そういったプログラムを作ってきた(そしてそれでよかった時代でありクライアントでした)ので、ある時、上司から「君の作るもののデザイン、ダサすぎるね」と言われた時はショックであり混乱もしました。だって、動くんですよ。必要な機能も盛り込んでいますよ。それなのに、アプリの機能と関係ない部分ですから。
しかし、現在、というより時代の流れでしょうか、アプリはただ動くだけではなく、デザイン面での考慮が必須になりました。ですが、開発をしようとしても、開発環境を普通に揃えた状態では、どうしても昔ながらのダサい画面しか開発できない、という状況に変わりがなかったりします。
もちろん、デザインが素晴らしいアプリの開発ができないわけではなく、それなりの環境を揃えることで実現できるわけです。世の中に優れたデザインのアプリが存在するということがその証拠ですが、ではそれは何か。
私は最近までスマホアプリを開発していたので、Javaを使うことが多いのですが、Javaのみで作ろうとすると、どうしても限界が出てきます。そこでスマホでは(そして調べてみるとPCアプリでも)XMLを使ってデザインをする、という方法があります。これはデザイン面での開発にとっては便利であり、簡単でもあるので、私はやりやすいと思います。
もちろん、開発環境の中で、パーツのデザインを含めて提供するというスタイルもありますが、よく言えばデザインが統一される、悪く言えばダサくなりがちだったりするわけですし、逆に、XMLを使うスタイルでも、ごちゃごちゃしたデザインになりがちなので、それぞれに長短あるのですが、いずれにせよ、機能以外の面でダサいアプリを作ることは、あえてそれを狙うことをしない限り(ネタアプリみたいな感じですかね)、できないししなくていいし、そんな時代になったんだなぁ、と思います。
実は、以前言われた「デザインがダサい」という一言は、今でも心の中に引っかかっています。むしろ、もうそんなことを言われたくない、という気持ちに変化していて、どんなアプリを作るにせよ、多少なりともデザインを気にするようにはしています。どんな簡単なアプリでも、誰かが使うことを考えて作ります。
ざっくりですが、私が考えるデザインの順番は、
・まず見た目。見た目が悪ければ使う気は起こらないはず。
・次に使い勝手。ボタンやらコントロールやらの場所を考える。
というもの。どれだけ使い勝手の良いものでも、見た目が悪いとあまり愛着が湧かないというのは「モノ」を選ぶ際のポイントになってくると思います。確かに世の中には見た目より使い勝手重視と思われるものもたくさんあるにはありますが、その全てが万人に受け入れられているとは思えませんし(しかも受け入れられるためには条件がいくつか必要)、見た目が良ければとりあえず受け入れてくれるわけで、見た目を最初に考えるのが私のスタイルです。
そうは言っても作ったプログラムを使ってもらうためには、例えば使いやすさとか、使いたいと思わせるような動きとか、それなりに(実際にはかなり)重要だったりするわけで、どうしてもプログラムの「デザイン」、専門的な言葉を使うならUI/UXとか、そういったことを意識しないと本当はいけないわけです。
では、普通にプログラムをエンジニアが作るとどうなるか?基本的にプログラムの機能を作る人が作るものなので、デザインにはそれほどこだわりがありません。もちろん、ボタンの位置とか(整列していないとかどのボタンが右で左で、的なこと)は意識しますが、ストレートに言えばどんなアプリを作ってもまるで業務用のソフトみたいな(今でいうならふた昔前くらいのデザイン、でしょうか)感じになってしまいます。
私自身、そういったプログラムを作ってきた(そしてそれでよかった時代でありクライアントでした)ので、ある時、上司から「君の作るもののデザイン、ダサすぎるね」と言われた時はショックであり混乱もしました。だって、動くんですよ。必要な機能も盛り込んでいますよ。それなのに、アプリの機能と関係ない部分ですから。
しかし、現在、というより時代の流れでしょうか、アプリはただ動くだけではなく、デザイン面での考慮が必須になりました。ですが、開発をしようとしても、開発環境を普通に揃えた状態では、どうしても昔ながらのダサい画面しか開発できない、という状況に変わりがなかったりします。
もちろん、デザインが素晴らしいアプリの開発ができないわけではなく、それなりの環境を揃えることで実現できるわけです。世の中に優れたデザインのアプリが存在するということがその証拠ですが、ではそれは何か。
私は最近までスマホアプリを開発していたので、Javaを使うことが多いのですが、Javaのみで作ろうとすると、どうしても限界が出てきます。そこでスマホでは(そして調べてみるとPCアプリでも)XMLを使ってデザインをする、という方法があります。これはデザイン面での開発にとっては便利であり、簡単でもあるので、私はやりやすいと思います。
もちろん、開発環境の中で、パーツのデザインを含めて提供するというスタイルもありますが、よく言えばデザインが統一される、悪く言えばダサくなりがちだったりするわけですし、逆に、XMLを使うスタイルでも、ごちゃごちゃしたデザインになりがちなので、それぞれに長短あるのですが、いずれにせよ、機能以外の面でダサいアプリを作ることは、あえてそれを狙うことをしない限り(ネタアプリみたいな感じですかね)、できないししなくていいし、そんな時代になったんだなぁ、と思います。
実は、以前言われた「デザインがダサい」という一言は、今でも心の中に引っかかっています。むしろ、もうそんなことを言われたくない、という気持ちに変化していて、どんなアプリを作るにせよ、多少なりともデザインを気にするようにはしています。どんな簡単なアプリでも、誰かが使うことを考えて作ります。
ざっくりですが、私が考えるデザインの順番は、
・まず見た目。見た目が悪ければ使う気は起こらないはず。
・次に使い勝手。ボタンやらコントロールやらの場所を考える。
というもの。どれだけ使い勝手の良いものでも、見た目が悪いとあまり愛着が湧かないというのは「モノ」を選ぶ際のポイントになってくると思います。確かに世の中には見た目より使い勝手重視と思われるものもたくさんあるにはありますが、その全てが万人に受け入れられているとは思えませんし(しかも受け入れられるためには条件がいくつか必要)、見た目が良ければとりあえず受け入れてくれるわけで、見た目を最初に考えるのが私のスタイルです。
2015年11月3日火曜日
インターネットラジオの録音に関する考察(その4:番組表の詳細設計(仮))
本当ならラジオの番組表は後で作るつもりでいたので、現段階で書くことはなかったはずなのですが、ちょっとデザインを考えているうちにまとまった考えが浮かんだので、仮の設計をしておこうかな、と。
まずこのブログを普通に読んでいる方はおそらく日本人だと思われます。日本語で書いてるし当たり前ですかね。では、そんなあなたに質問。番組表と聞くとどんなイメージをお持ちですか?
おそらく、新聞のラテ欄と同じレイアウトのイメージなのではないかと。画面上にテレビ局が並び、下に行くに従って未来の番組になっていくものです。当たり前といえば当たり前なレイアウトですよね。新聞に限らず、テレビでもラジオ(というかradiko、らじるらじる)でも同様、局が上に来てます。
ということは、このデザイン以外ありえない、ということになりそうですが、実はそうでもないんです。海外のテレビ、しかも多チャンネルな国(アメリカとか中国とか)だと、テレビの番組表は局が横に、時間は左から右へ進んでいく、というのが多いみたいです。CSのチューナーも昔はそんなスタイルだったような記憶があります。
これはなぜか。私自身、それほど海外の事情に詳しいわけではないのでわかりませんが、おそらくは「慣れ」から来ているのではないか、と推測します。
「番組表」の画像検索をしてみると顕著ですが、日本語で「番組表」と検索をすると、基本的に(日本人には)見慣れたスタイルのアレが出てきます。では、英語で「TV Listings」「TV Schedule」と検索するとどうなるか。まぁ多彩なデザインが出てきます。
先ほど書いた、表が日本と逆(局名が左側にある)のもあれば同じのもあったり、古い新聞だと何時からどこのチャンネルで何をやるかが列記されているだけだったりとか、おそらく共通フォーマット的なものが存在しないんでしょう。
だから、日本の場合はおそらく新聞の表現方法がデファクトスタンダードになり(テレビ・ラジオ雑誌もこの表現を踏襲)、デジタル化された現在でもこの表現方法が一般化しているということは言えるでしょう。もちろん、日本人は文字を上から下へと読む習慣があるので、それに倣って造られた表現方法なのだとも考えられますし、そもそも新聞は縦長の紙面なので、それにマッチする表現方法がこれだった、とも考えられます。
逆に、海外ではそう言った新聞などでの番組表の表現方法が確立されておらず、デジタル化された段階で見やすい番組表を模索した結果、横長の画面であるテレビにマッチしたスタイルである、日本とは逆のスタイルになった、または、文字の読む習慣から考えれば右に目線を動かすタイプの方が読みやすかった、という理由があるのかもしれません。
では、私(純粋な日本人です)が作るとしたらどんなデザインになるのか。おそらくですが、どちらも採用しそうです。ユーザーに任せる部分というか。
これには理由があります。
先にちらっと書きましたが、昔のCSチューナーはいわゆる日本式ではない番組表を採用していました。日本製ですが(東芝だったかな?)。理由はわかりませんが、おそらくは、チャンネル数があまりにも莫大なため(そしてこれは現在の海外の事情ともおそらく合致すると思われますが)、「日本式」の番組表では画面に表示されるコンテンツの数があまりにも少なすぎるため、逆にしたのではないか、と思われます。
さて、ネットラジオに話を戻しますが、今回選びたい局は実はかなりの量になります。私自身は現在東京在住なので、それだけでも結構な数の局になる(radikoだけで13局、NHK3局+AFN Tokyoだけとしても)のですが、そこにコミュニティFMを幾つか加えればなかなかのコンテンツ量です。それを「日本式」で見るのが果たして見やすいのかどうか(もちろん、番組表を取得できれば、という条件はあるにせよ、radiko参加局とNHKは確実に取得できるはずなのだから)。
だとすれば、選局可能なチャンネルが少なければ「日本式」でも構わないし、多くて見にくい、となればそれ以外の方法も選択肢があっていい、という考え方はあっていいと思います。
今回は開発の中でもデザインに特化した内容でしたが(にも関わらず絵を一切掲載しないという暴挙に出ましたが)、アプリを作るときにはどうしてもこういうことも考えないといけないよね、と思い、書いてみました。今後も割とこういうデザインネタは多く書くことになるとは思います。
まずこのブログを普通に読んでいる方はおそらく日本人だと思われます。日本語で書いてるし当たり前ですかね。では、そんなあなたに質問。番組表と聞くとどんなイメージをお持ちですか?
おそらく、新聞のラテ欄と同じレイアウトのイメージなのではないかと。画面上にテレビ局が並び、下に行くに従って未来の番組になっていくものです。当たり前といえば当たり前なレイアウトですよね。新聞に限らず、テレビでもラジオ(というかradiko、らじるらじる)でも同様、局が上に来てます。
ということは、このデザイン以外ありえない、ということになりそうですが、実はそうでもないんです。海外のテレビ、しかも多チャンネルな国(アメリカとか中国とか)だと、テレビの番組表は局が横に、時間は左から右へ進んでいく、というのが多いみたいです。CSのチューナーも昔はそんなスタイルだったような記憶があります。
これはなぜか。私自身、それほど海外の事情に詳しいわけではないのでわかりませんが、おそらくは「慣れ」から来ているのではないか、と推測します。
「番組表」の画像検索をしてみると顕著ですが、日本語で「番組表」と検索をすると、基本的に(日本人には)見慣れたスタイルのアレが出てきます。では、英語で「TV Listings」「TV Schedule」と検索するとどうなるか。まぁ多彩なデザインが出てきます。
先ほど書いた、表が日本と逆(局名が左側にある)のもあれば同じのもあったり、古い新聞だと何時からどこのチャンネルで何をやるかが列記されているだけだったりとか、おそらく共通フォーマット的なものが存在しないんでしょう。
だから、日本の場合はおそらく新聞の表現方法がデファクトスタンダードになり(テレビ・ラジオ雑誌もこの表現を踏襲)、デジタル化された現在でもこの表現方法が一般化しているということは言えるでしょう。もちろん、日本人は文字を上から下へと読む習慣があるので、それに倣って造られた表現方法なのだとも考えられますし、そもそも新聞は縦長の紙面なので、それにマッチする表現方法がこれだった、とも考えられます。
逆に、海外ではそう言った新聞などでの番組表の表現方法が確立されておらず、デジタル化された段階で見やすい番組表を模索した結果、横長の画面であるテレビにマッチしたスタイルである、日本とは逆のスタイルになった、または、文字の読む習慣から考えれば右に目線を動かすタイプの方が読みやすかった、という理由があるのかもしれません。
では、私(純粋な日本人です)が作るとしたらどんなデザインになるのか。おそらくですが、どちらも採用しそうです。ユーザーに任せる部分というか。
これには理由があります。
先にちらっと書きましたが、昔のCSチューナーはいわゆる日本式ではない番組表を採用していました。日本製ですが(東芝だったかな?)。理由はわかりませんが、おそらくは、チャンネル数があまりにも莫大なため(そしてこれは現在の海外の事情ともおそらく合致すると思われますが)、「日本式」の番組表では画面に表示されるコンテンツの数があまりにも少なすぎるため、逆にしたのではないか、と思われます。
さて、ネットラジオに話を戻しますが、今回選びたい局は実はかなりの量になります。私自身は現在東京在住なので、それだけでも結構な数の局になる(radikoだけで13局、NHK3局+AFN Tokyoだけとしても)のですが、そこにコミュニティFMを幾つか加えればなかなかのコンテンツ量です。それを「日本式」で見るのが果たして見やすいのかどうか(もちろん、番組表を取得できれば、という条件はあるにせよ、radiko参加局とNHKは確実に取得できるはずなのだから)。
だとすれば、選局可能なチャンネルが少なければ「日本式」でも構わないし、多くて見にくい、となればそれ以外の方法も選択肢があっていい、という考え方はあっていいと思います。
今回は開発の中でもデザインに特化した内容でしたが(にも関わらず絵を一切掲載しないという暴挙に出ましたが)、アプリを作るときにはどうしてもこういうことも考えないといけないよね、と思い、書いてみました。今後も割とこういうデザインネタは多く書くことになるとは思います。
インターネットラジオの録音に関する考察(その3:聴取・録音機能の詳細設計)
前回のポストで、ストリーミング配信ラジオの聴取・録音方法についてまとめました。で、それをもとに詳細設計をする、ということなんですが、これも前回書いた通り、バックグラウンドで必要なソフトを立ち上げるだけでいいわけです。
もうちょっと細かく言うと、
・選局する(聴取・録音するラジオ局を選ぶ)
・聴取の場合は聴取のためのソフトを立ち上げる
#rtmpdumpだったりffplayだったり
・録音する場合は録音のためのソフトを立ち上げる
#rtmpdump/ffmpeg
聴取するだけなら実は本当にこれでよく、局を変える時もその都度立ち上げたり終了させたり、というだけでいいんですが、問題は録音です。今聴いている局を今から録音する、というシチュエーションは現状では考えにくく(昔のFMではよくやってましたね。好きな曲が流れるまでずっと待っていて、かかった途端に録音ボタンを押したり、あらかじめ録音ボタンと一時停止ボタンを押しておき、一時停止ボタンを解除する、というアレ。懐かしいなぁ・・・)、予約録音をするのが一般的なのではないか、と思います。
すると、予約のための機構を作らなければならない、ということになります。
予約録音自体は、rtmpdumpでもffmpegでも、開始時刻を指定することができないため、アプリ内で予定時刻になったら(実際にはアプリ起動から録音開始まで若干のタイムラグがあるので開始時刻の数秒前に)起動し、そこから指定された時間録音する、というやり方で実装できそうですが、問題はその開始時刻の指定とタイムラグの調整になります(調整レベルの話は内部でごにょごにょになりそうなのでメインは開始時刻指定ですね)。
そこで、番組表の話が持ち上がってきます。
最近のテレビ(地デジ化された後のテレビ、と言い換えてもいいですが)にあるEPG、いわゆる番組表機能は非常に便利です。今何をやっているかもわかりますし、録画したい番組を選んであれこれできたり。個人的にはあれを作りたいですね。やり方がイマイチ見えてないですが。
番組表ができれば、録音のための開始時間はそこから取得できるわけですし、予約などのやり方も簡単にできるようになるはずです。ただ、これについてはおそらくすぐにリリースはできないんじゃないかな、と。だって、やり方が見えないもの。
もう一つ、予約録音に必要な事があります。PCのスリープ解除にまつわる機能です。普段から電源を入れっぱなし、画面も消えない、という状況はまぁ考えにくいわけで、スリープ解除(及び必要があれば録音作業終了後のスリープ設定)をする必要はありますよね。
とりあえず、今できる事は最低限聴取と録音の機能ですね。あとは開発言語をどうするか、というこちらの都合がありますが、まぁそれはどうでもいいことなので。
開発言語の話で一つ思い出したことがあります。最初の設計段階でスマホアプリでは再生機能のみ、としたのですが、この理由は至って簡単。容量の問題が起こるからです。
録音した音源をスマホからその都度PC側に移動させる、という作業を誰もが行うというのであれば、スマホで録音するのは結構都合のいいことのように思えます。が、普段の生活で意識的にPCへデータを移動させることは普通のユーザーはやらないでしょうし、そもそもPCを持っていないスマホユーザーもいるわけで、ずっとスマホにデータを入れっぱなしにしているということは、間違いなくストレージ容量の不足を招くわけです。
もちろん、クラウドへの移行や外部デバイス(SDカードだったりそういうの)への移動も視野に入れるとしても、それでも容量は無限にはなりえない。だとしたら、スマホでの録音は行わないほうが良い、と考えます。スマホからPC側に録画予約ができる機能が実装できるならいいですが、それって相当難しくない?
もうちょっと細かく言うと、
・選局する(聴取・録音するラジオ局を選ぶ)
・聴取の場合は聴取のためのソフトを立ち上げる
#rtmpdumpだったりffplayだったり
・録音する場合は録音のためのソフトを立ち上げる
#rtmpdump/ffmpeg
聴取するだけなら実は本当にこれでよく、局を変える時もその都度立ち上げたり終了させたり、というだけでいいんですが、問題は録音です。今聴いている局を今から録音する、というシチュエーションは現状では考えにくく(昔のFMではよくやってましたね。好きな曲が流れるまでずっと待っていて、かかった途端に録音ボタンを押したり、あらかじめ録音ボタンと一時停止ボタンを押しておき、一時停止ボタンを解除する、というアレ。懐かしいなぁ・・・)、予約録音をするのが一般的なのではないか、と思います。
すると、予約のための機構を作らなければならない、ということになります。
予約録音自体は、rtmpdumpでもffmpegでも、開始時刻を指定することができないため、アプリ内で予定時刻になったら(実際にはアプリ起動から録音開始まで若干のタイムラグがあるので開始時刻の数秒前に)起動し、そこから指定された時間録音する、というやり方で実装できそうですが、問題はその開始時刻の指定とタイムラグの調整になります(調整レベルの話は内部でごにょごにょになりそうなのでメインは開始時刻指定ですね)。
そこで、番組表の話が持ち上がってきます。
最近のテレビ(地デジ化された後のテレビ、と言い換えてもいいですが)にあるEPG、いわゆる番組表機能は非常に便利です。今何をやっているかもわかりますし、録画したい番組を選んであれこれできたり。個人的にはあれを作りたいですね。やり方がイマイチ見えてないですが。
番組表ができれば、録音のための開始時間はそこから取得できるわけですし、予約などのやり方も簡単にできるようになるはずです。ただ、これについてはおそらくすぐにリリースはできないんじゃないかな、と。だって、やり方が見えないもの。
もう一つ、予約録音に必要な事があります。PCのスリープ解除にまつわる機能です。普段から電源を入れっぱなし、画面も消えない、という状況はまぁ考えにくいわけで、スリープ解除(及び必要があれば録音作業終了後のスリープ設定)をする必要はありますよね。
とりあえず、今できる事は最低限聴取と録音の機能ですね。あとは開発言語をどうするか、というこちらの都合がありますが、まぁそれはどうでもいいことなので。
開発言語の話で一つ思い出したことがあります。最初の設計段階でスマホアプリでは再生機能のみ、としたのですが、この理由は至って簡単。容量の問題が起こるからです。
録音した音源をスマホからその都度PC側に移動させる、という作業を誰もが行うというのであれば、スマホで録音するのは結構都合のいいことのように思えます。が、普段の生活で意識的にPCへデータを移動させることは普通のユーザーはやらないでしょうし、そもそもPCを持っていないスマホユーザーもいるわけで、ずっとスマホにデータを入れっぱなしにしているということは、間違いなくストレージ容量の不足を招くわけです。
もちろん、クラウドへの移行や外部デバイス(SDカードだったりそういうの)への移動も視野に入れるとしても、それでも容量は無限にはなりえない。だとしたら、スマホでの録音は行わないほうが良い、と考えます。スマホからPC側に録画予約ができる機能が実装できるならいいですが、それって相当難しくない?
インターネットラジオの録音に関する考察(その2:ストリーミング配信方式のまとめ)
前回のポストでは、とりあえずの設計をやってみました。基本的に一人でやることなので(以前も書いた通り、似非アジャイル開発です)、小さい機能を作って最終的に組み立てる、というやり方になる以上、ざっくりと頭の中に完成図があればいいわけです。
で、機能面でのメインとなるのは、
普段自分が聴取するであろうラジオ局を聴取する/録音する
というものです。まぁ当たり前の機能ですね。では、その方法について軽くまとめましょう(というか、自分も久しぶりにこの機能の実装をすることになるので、以前の調査結果をまとめておかないとわけがわからなくなるんです)。
インターネット上で配信されている(かつ私が普段聴取するであろう)ラジオはおおよそ、以下の形式で配信されています。
・Radiko(民放ラジオ各社)・・・RTMP
・らじるらじる・・・RTMP/WMA(WMAは2015年8月末で配信終了)
・AFN・・・要調査(HLS?)
・JCBA・・・RTMP
・CSRA・・・WMA?
ざっくりいうと、配信形式は3種類に分かれます。で、それぞれの方式に対応した聴取・録音の仕組みを作らなければいけない・・・のですが、これらを一から作ることは私にはとてもできません。で、どうするかというと、それぞれの方式に対応した聴取・録音ソフトをあらかじめ取得しておく必要があるわけです。
ググって調べてみると、RTMPに対応するソフトが「rtmpdump」、それ以外であれば「ffmpeg」が必要になり(聴取・録音ソフトでフリーのものはこれを使っていることを公言しているものもあるし、おそらく有償のものでも同様なんでしょうね)、アプリ的にはこれらをバックグラウンドで実行させることで聴取・録音を可能にしている、と考えられます。
ちなみに、この聴取・録音をするためのコマンドラインはとても簡単で、例えば、今ちょうど私が聴いているAFN Tokyoの聴取ならば、
また、それを録音するならば(例として10分録音)、
と一行コマンドを実行するだけで済むわけです(ffmpegの再生版がffplay)。本当はもうちょっと細かい技が必要になるのですが、それはおいおい紹介するとして(というか私も調べながらの制作を行うので・・・)。
ということで、聴取・録音機能のやり方をまとめることで詳細設計の大枠が出来上がってきました。次回はこの機能について詳細設計をもう少しまとめてみたいと思います。
で、機能面でのメインとなるのは、
普段自分が聴取するであろうラジオ局を聴取する/録音する
というものです。まぁ当たり前の機能ですね。では、その方法について軽くまとめましょう(というか、自分も久しぶりにこの機能の実装をすることになるので、以前の調査結果をまとめておかないとわけがわからなくなるんです)。
インターネット上で配信されている(かつ私が普段聴取するであろう)ラジオはおおよそ、以下の形式で配信されています。
・Radiko(民放ラジオ各社)・・・RTMP
・らじるらじる・・・RTMP/WMA(WMAは2015年8月末で配信終了)
・AFN・・・要調査(HLS?)
・JCBA・・・RTMP
・CSRA・・・WMA?
ざっくりいうと、配信形式は3種類に分かれます。で、それぞれの方式に対応した聴取・録音の仕組みを作らなければいけない・・・のですが、これらを一から作ることは私にはとてもできません。で、どうするかというと、それぞれの方式に対応した聴取・録音ソフトをあらかじめ取得しておく必要があるわけです。
ググって調べてみると、RTMPに対応するソフトが「rtmpdump」、それ以外であれば「ffmpeg」が必要になり(聴取・録音ソフトでフリーのものはこれを使っていることを公言しているものもあるし、おそらく有償のものでも同様なんでしょうね)、アプリ的にはこれらをバックグラウンドで実行させることで聴取・録音を可能にしている、と考えられます。
ちなみに、この聴取・録音をするためのコマンドラインはとても簡単で、例えば、今ちょうど私が聴いているAFN Tokyoの聴取ならば、
ffplay "http://4613.live.streamtheworld.com/AFNP_TKOAAC"
また、それを録音するならば(例として10分録音)、
ffmpeg -i "http://4613.live.streamtheworld.com/AFNP_TKOAAC" -t 600 -vn -c:a copy "~/rec.m4a"
と一行コマンドを実行するだけで済むわけです(ffmpegの再生版がffplay)。本当はもうちょっと細かい技が必要になるのですが、それはおいおい紹介するとして(というか私も調べながらの制作を行うので・・・)。
ということで、聴取・録音機能のやり方をまとめることで詳細設計の大枠が出来上がってきました。次回はこの機能について詳細設計をもう少しまとめてみたいと思います。
インターネットラジオの録音に関する考察(その1:開発再開前夜)
今年初めの頃、Mac用のインターネットラジオ録音アプリを作ろうとしていましたが、他にやりたいこともあり、単体の曲だけ選択し録音機能を実装する、というところでいったん開発が停止していました。
ふだんはMac使いではあるものの、開発の都合からWindowsマシンも持っていたりしますし、仮想環境にもWindowsの古いバージョンが入っていたりするので、実際のところ録音にはWindowsマシンで他の人が作っているアプリを使うことで(あえて何とは言いませんが)何とかなっていました。
ただ、今年の9月からだったか、NHKのストリーミング形式が変わったことで、アプリの録音機能が正常に動作しなくなり、NHKの録音(午後4時からやってる気象通報を録ってました)ができなくなってしまいました。まぁアプリのバージョンアップをすれば済む話なのですが、自分で作ることができるのに他人のアプリを使い続けるのもなぁ、なんて思いながら、しかもNHKの録音した音源に関して言えば、今のところあってもなくてもいいものだったので、とりあえず放置プレイをしてあるわけです。
そうは言っても、「録音できないんだったら自分で作ればいいじゃない」というアントワネット型思考(笑)が頭をよぎる以上、作らなければならないのかなぁ、と思っています。
ということで、ちょっと開発に時間を費やしてみたいと思います。
・・・とここまでならいつもの調子なのですが、その前に、作るにあたっての設計や実際のコードのサンプルなどもブログにアップしてみたいと考えていて、今後しばらくは設計やコードをひたすらブログにあげてみようと思います。
で、とりあえずの設計(いわゆる基本設計、全体像、Perspective)をこんな感じにしてみようと思います。
・一応Mac用アプリとして開発を開始。
・スマホ(iPhone/Android)用アプリも作る予定(ただし録音機能は付けない予定)
・余力があればWindows用も作ってみる
・聴取可能な曲は普段AM/FMで聞いているものを網羅(※)
・番組表は新聞ラテ欄的なデザインで
・プレーヤー自体のデザインもそれなりのものにする
まぁ、他にもいろいろと出てくるのでしょうが、最初のバージョンはシンプルな状態で出したいですね。誰かが使ってくれるのならその段階で要望も出てくるのでしょうし。
それから、もう一つこだわりたいのはやはりデザインでしょうか。直感的なデザインは外せません。機能重視はもちろんなのですが、それによってゴチャゴチャしたデザインになるのは個人的には許せないです。シンプルなのがいいです。シンプルで直感的。
ラジオのデザインと言えば、あくまでも個人的には、ですが、昔のラジカセのデザインは嫌いではありません。同世代(40歳代)のオジサンには共感してもらえると思っていますが・・・。が、あれはシンプルとは言い難いですね。どっちかというとゴチャゴチャ。ボタンがいっぱい付いているのがカッコよかったんですけどね、昔は。
ということで、しばらくラジオネタで引っ張ります。次回はコードを幾つか載せてみますのでお楽しみに。
ふだんはMac使いではあるものの、開発の都合からWindowsマシンも持っていたりしますし、仮想環境にもWindowsの古いバージョンが入っていたりするので、実際のところ録音にはWindowsマシンで他の人が作っているアプリを使うことで(あえて何とは言いませんが)何とかなっていました。
ただ、今年の9月からだったか、NHKのストリーミング形式が変わったことで、アプリの録音機能が正常に動作しなくなり、NHKの録音(午後4時からやってる気象通報を録ってました)ができなくなってしまいました。まぁアプリのバージョンアップをすれば済む話なのですが、自分で作ることができるのに他人のアプリを使い続けるのもなぁ、なんて思いながら、しかもNHKの録音した音源に関して言えば、今のところあってもなくてもいいものだったので、とりあえず放置プレイをしてあるわけです。
そうは言っても、「録音できないんだったら自分で作ればいいじゃない」というアントワネット型思考(笑)が頭をよぎる以上、作らなければならないのかなぁ、と思っています。
ということで、ちょっと開発に時間を費やしてみたいと思います。
・・・とここまでならいつもの調子なのですが、その前に、作るにあたっての設計や実際のコードのサンプルなどもブログにアップしてみたいと考えていて、今後しばらくは設計やコードをひたすらブログにあげてみようと思います。
で、とりあえずの設計(いわゆる基本設計、全体像、Perspective)をこんな感じにしてみようと思います。
・一応Mac用アプリとして開発を開始。
・スマホ(iPhone/Android)用アプリも作る予定(ただし録音機能は付けない予定)
・余力があればWindows用も作ってみる
・聴取可能な曲は普段AM/FMで聞いているものを網羅(※)
・番組表は新聞ラテ欄的なデザインで
・プレーヤー自体のデザインもそれなりのものにする
まぁ、他にもいろいろと出てくるのでしょうが、最初のバージョンはシンプルな状態で出したいですね。誰かが使ってくれるのならその段階で要望も出てくるのでしょうし。
それから、もう一つこだわりたいのはやはりデザインでしょうか。直感的なデザインは外せません。機能重視はもちろんなのですが、それによってゴチャゴチャしたデザインになるのは個人的には許せないです。シンプルなのがいいです。シンプルで直感的。
ラジオのデザインと言えば、あくまでも個人的には、ですが、昔のラジカセのデザインは嫌いではありません。同世代(40歳代)のオジサンには共感してもらえると思っていますが・・・。が、あれはシンプルとは言い難いですね。どっちかというとゴチャゴチャ。ボタンがいっぱい付いているのがカッコよかったんですけどね、昔は。
ということで、しばらくラジオネタで引っ張ります。次回はコードを幾つか載せてみますのでお楽しみに。
2015年9月30日水曜日
小ネタ:ブログにコードを貼り付ける
ブログを書いていて、とてもやりたいことの一つに、ブログで作成したコードの一部とかを公開することでした。自分でプログラム作成をするときに参考にするサイトでも、コードのところだけ別の枠に囲まれていて、色やら行数やらついていたりして、カッコイイじゃん!俺もやりてーなー!とずっと思ってはいたのですが、なかなかそこまでに至りませんでした。
で、ちょっと手が空いたときに調べてやってみたのですが、最初はよく分からなくてうまくできなかったのですが、きちんと時間をとって調べてみると、意外と簡単だったりしました。ということで、このブログにも仕込んで見ました。
ちなみに、ブログでプログラムコードのところが↓こんな風になるのを、シンタックスハイライトというらしいです。
これはブログに限った話ではなく、コードを色付けしたりして読みやすくする、というのがメインの目的です。まぁ私のブログ文字多めなんで、これにコードを入れたらもっと文字多くなっちゃって大変ですがねぇ。 それはともかく。 使い方は他のサイトを参考にしていただくとして(現時点で一番参考になったのはこのサイト。日本語で説明されていることもありますが、元のサイトのリンクも入れてくれていたのは助かりました。感謝いたします)、導入の要点をまとめておきます。
で、ちょっと手が空いたときに調べてやってみたのですが、最初はよく分からなくてうまくできなかったのですが、きちんと時間をとって調べてみると、意外と簡単だったりしました。ということで、このブログにも仕込んで見ました。
ちなみに、ブログでプログラムコードのところが↓こんな風になるのを、シンタックスハイライトというらしいです。
<!DOCTYPE HTML> <html> <head> <title>Online or offline?</title> <script> function update(online) { document.getElementById('status').textContent = online ? 'Online' : 'Offline'; } </script> </head> <body ononline="update(true)" onoffline="update(false)" onload="update(navigator.onLine)"> <p>You are: <span id="status">(Unknown)</span></p> </body> </html>(w3cのサイトからコピペしてきましたごめんなさい)
これはブログに限った話ではなく、コードを色付けしたりして読みやすくする、というのがメインの目的です。まぁ私のブログ文字多めなんで、これにコードを入れたらもっと文字多くなっちゃって大変ですがねぇ。 それはともかく。 使い方は他のサイトを参考にしていただくとして(現時点で一番参考になったのはこのサイト。日本語で説明されていることもありますが、元のサイトのリンクも入れてくれていたのは助かりました。感謝いたします)、導入の要点をまとめておきます。
- 下準備としてスクリプトのリンクを追加しておくこと。参考リンクでは<head>セクションの一番最後(もちろん</head>タグの直前ですよ)に追加、とありますが、これは昔ながらのお約束ですが、近頃(少なくとも2015年の時点)では<body>セクションの一番最後(</body>の直前)に仕込むのが流行りらしいです(速度向上とか)。このサイトでは流行りに負けて<body>セクションの最後に記載してみました。
- 実際に使う場合、コードを<pre>タグで囲むだけでよいみたいです(参考にしたサイトは情報が古めだったので、実際に元サイトに行ってみるとそう書いてある)。
使い方例:
<pre class='brush: ○○; html-script: true;'> コードの内容 </pre>
上記例の「class=brush:○○」のところに使っているコードの名前をここを参考にして記入します。もしhtmlの中のスクリプトだということであればその次の「html-script」項目をTrueにすればよいはずです。 - ただし、<pre>タグに囲まれたコードの中で、一部エスケープ文字を使用する必要があります。各言語で異なると思いますが、上記の例で言えば、HTML(XML)の場合は(少なくとも)行頭の「<」はエスケープ文字(「<」)に直しておく必要があります。そうしないと表示が崩れます。 #本当は「>(>)」もやらなきゃいけないみたいですが、 #Bloggerでは行頭を直したら行末は勝手に修正が入ってしまいましたとさ。
ちなみに、これは私が使っているBloggerの場合ですが、おそらく他のブログサイトでも同様でしょう。ちなみに、スクリプトリンクの追加は(Bloggerの場合)テンプレートのHTMLファイルをいじる必要があります。まぁコードを載せようなんて人は「その筋」の人たちでしょうから、元のHTMLファイルを壊す、ということもないと思いますが(笑)。
まだ使い方があまりわかっていませんが(つか元サイトがあまりにも説明少なすぎる気が)色々と調べてみて、わかってきたらまとめて解説してみようかな、と思っています。
まだ使い方があまりわかっていませんが(つか元サイトがあまりにも説明少なすぎる気が)色々と調べてみて、わかってきたらまとめて解説してみようかな、と思っています。
2015年9月29日火曜日
古いネットブックへのWindows 10導入顛末
仕事、という内容でもないですが、皆さんの参考になるかと思い、古いネットブックにWindows 10を導入した顛末をお知らせしたいと思います。
結論から言えば、成功しました。そして、かなり使えるらしい(私は使っておらず、使用者である妻の弁)とのことですので、押入れに突っ込んであるネットブックや中古で持ち運びに便利なマシンをお探しの諸兄には福音かもしれません。
ただ、そこに至るまでの道のりは実はすごく長かったです。試行錯誤の結果成功したと言っても過言ではないです。なので、その長かった道のりには触れず、最短でインストール成功する方法をお知らせします。
まず、用意するもの。
結論から言えば、成功しました。そして、かなり使えるらしい(私は使っておらず、使用者である妻の弁)とのことですので、押入れに突っ込んであるネットブックや中古で持ち運びに便利なマシンをお探しの諸兄には福音かもしれません。
ただ、そこに至るまでの道のりは実はすごく長かったです。試行錯誤の結果成功したと言っても過言ではないです。なので、その長かった道のりには触れず、最短でインストール成功する方法をお知らせします。
まず、用意するもの。
- ネットブック本体(今回はAsusのEEE PC 1000Hをストック状態で用意)
- メモリを積めるだけ(メーカー公称1GBでしたが2GB積めるらしい)
- SSD(中古とかの安いので十分)
- Windowsのメディア(今回はWindows7とWindows10の二つを用意)
基本的に、Windows7はWindows10にするための踏み台みたいな状態です(もとのネットブックはWindowsXPだったので、そもそもはWindows7をインストールするつもりで買ってあった)。
そして、もしネットブックが現役ならば、データのバックアップをしておいてください。基本、クリーンインストールしますので。
手順を簡単に書くと、
- Windows7インストールの前段階として、BIOSを最新版にアップデートする
- HDDをSSDに交換し、メモリも最大限積めるだけ積む
- Windows7をクリーンインストールする
- Windows7用のメーカー提供ドライバの最新版をインストールする
- Windows Updateを行って最新の状態にしておく(※オプション)
- Windows10にアップデート(引き継ぎ なしで行う)
- 必要に応じてWindows10用のドライバをインストール
直接Windows10をクリーンインストールでもよかったのですが、今回は後で述べる事情があり、Windows 7を一度インストールしたうえでの作業になっています。
注意点を順を追って説明していきます。
- BIOSのアップデート
基本的に、Windows7に対応しているマシンはWindows10にも対応していると考えてよいです。Windows7より上位のOS対応のBIOSアップデートがあればそれをインストールすればよいですが、私の場合はWindows7版が最新でした。 - SSD・メモリ換装
メモリは、あればあるほどよい、とは言いますが、まずWindows7にする時点で、どんなにメモリを積んでも3GBまでしか認識されないという制限があります(ネットブックでIntel Atomを積んでいるマシンは32bit版しかインストールできないらしいので)。したがって、最大でも4GB(OS側が3GBとして認識)を選ぶ必要があると思います。また、Windows10では32bitでも4GBを認識している、という情報もあるのですが、そもそも32bitOSが4GBのメモリを認識するのか(いわゆる「3GBの壁」の解消がされたのかどうか)わかりません。
SSDについては、必須ではないです。SSD自体、読み込み速度は相当早く、例えばアプリ起動など、いわゆるサクサク「動く」という点では非常に有効ですが、書き込み速度(データをダウンロードしたりファイルを保存したりという作業に影響)が遅いということもあり、私は躊躇したのですが、HDDを積んでいるネットブックのHDDスペックは基本的に低速(回転数が遅い=読み書き速度が遅い)であり、SSDへの換装により、書き込み速度も向上しました(どんだけ遅いHDDだったんだ、ということにもなりますが・・・)。 - Windows 7のクリーンインストール
HDDを換装したのであればバックアップはあとでなんとかなりますが、そうでなければインストール作業前にバックアップは必須です。クリーンインストールで注意する点は他にありませんのでこんなところで。 - Windows 7用ドライバインストール
これが意外と大事です。少なくともメーカーで提供しているドライバは全部最新のものを入れておいてください。私はグラフィックスドライバを入れていなかったため、このあとのWindows10インストールで失敗しています。 - Windows Update適用(オプション)
実は、私の環境ではこれをしなくてもWindows 10のインストールはできました。というか、Windows Updateがどうしても動かなかったんです。エラー回避方法はいくつかあるので試してみたのですが、どれもうまくいかず、「諦めた」というのが正解かもしれません。これができていれば、もしかするとWindows 10にはしなかったかもしれませんので、よかったのか悪かったのか・・・(これがWindows7経由でWindows10にした理由です)。 - Windows 10インストール
クリーンインストールではなく、アップデート(OS起動中にインストール作業を行う)で行いました。この時、前のOSの情報を引き継がないオプションでインストールしました。こうしないとインストールができませんでした。また、更新プログラムのダウンロード・インストールもこの時点では行わないように選択しました。やはりこちらもうまくインストールできなかったので。 - Windows10用ドライバのインストール
基本的にWindows7の時もそうですが、実はOSで認識したハードウェアのドライバは正常に動いており、わざわざ変える必要もないかもしれません。どちらかというとハードウェアメーカー側で最適化されたドライバと考えています。私はこの作業を一部しか行っていません(タッチパッドと電源管理のドライバだけはいれておきたかったので)。
このためにかけたコスト概算ですが、
- ネットブック本体:¥15,000
- OSパッケージ:¥12,000(Windows7 Home 32bit)→Windows 10のDSP版はもう少し高かったです
- メモリ(2GB/1枚):¥3,000(中古)
- SSD(128GB):¥8,000(中古)
しめて¥38,000 ナリ。本体をすでに持っているのであれば、最大23,000円で、すでに本体側の改造済ということならOS料金だけで現役マシンになれる、というお話でした。
ちなみに、個人的には古いネットブックではWindows 10の魅力が半減するかなぁ、というのがちょっと使わせてもらった感触です。デスクトップOSとしては今までのWindows(7まで)を踏襲したものなので、可もなく不可もなし、といったところです。また、今回のインストール作業ではクリーンインストールをメインでやっていますので、余計なサービスやアプリが入っておらず、かなり軽快に動作します。
しかし、当たり前の話ですがタブレットモードがなく、さらに画面タッチもできないのは、タブレットモードに慣れている状態の私には退屈というか面倒というか、ちょっと違和感があります。
2015年9月18日金曜日
メインマシン(iMac)の復旧作業顛末:その後
前回のポストは、現在復旧中、というステータスでしたが、今朝、無事にiMacの復旧作業が完了し、「ほぼ」完全に復旧したことを確認しました。
ちなみに、Time Machine経由の復旧作業は2度目。今回取り替えた旧2TBのHDDを入れた時にも使っていて、その時は今ほど使用量も多くなかったし、たまたまTime Capsuleは有線接続していたのでこんなに時間もかからなかった記憶があります。
で、復旧が「ほぼ」完了した、という微妙な物言いをしているのは、復旧がクラッシュ以前の状態に完璧に戻ったわけではない、ということを表しているつもりです。おおよそ、OSレベルでは問題なし、ファイルも(多分)過不足なく復旧、アプリが一部問題あり、という感じではありますが、細かく状況を記しておきます。
○OS・・・復旧OK
OSのバージョン(9/15時点では10.10.5)、ユーザー情報、アピアランス、ネットワーク接続情報などなど、基本的な情報については元どおりになっています。
○ファイル・・・復旧OK
正直、確認のしようがないですが、普段つかっているアプリやメディアなど、動いている・使えている、という状態であれば、大丈夫でしょう。
×アプリ・・・要再設定
これ、当たり前なのかどうか微妙なところですが、とりあえず一部アプリが使えなくなっていたり、再設定を行わなければならなかったものです。
・Office365(これは別の問題も発生していて現在使えない→解消)
・Dropbox(おそらく今回のHDDクラッシュの原因か。プロキシ設定を外して再登録)
・(9/17現在)今の所これだけですが、随時追加していきます。
そもそも、プロキシを繋げている(串を刺している)状態というのも通常の家庭で置かれているPCではないと思いますので、あまり参考にはならないかもしれませんが、本当はバックアップを復元したらアプリの設定情報などもそのまま引き継いで動く必要があるように思います。
それから、前回も触れたとおり、OSに関しては現在使っているもののリカバリディスクは作っておく必要があります。今回はOSをアップデートしてから作業しましたが、やっぱり面倒くさい。来月、新しいOS(El Capitan、ってなんか言葉の意味知らなければかわいい響きだ)が出るようですし、アップデートをするつもりですので、必ず作らなきゃ、と思っています。
ちなみに、Time Machine経由の復旧作業は2度目。今回取り替えた旧2TBのHDDを入れた時にも使っていて、その時は今ほど使用量も多くなかったし、たまたまTime Capsuleは有線接続していたのでこんなに時間もかからなかった記憶があります。
で、復旧が「ほぼ」完了した、という微妙な物言いをしているのは、復旧がクラッシュ以前の状態に完璧に戻ったわけではない、ということを表しているつもりです。おおよそ、OSレベルでは問題なし、ファイルも(多分)過不足なく復旧、アプリが一部問題あり、という感じではありますが、細かく状況を記しておきます。
○OS・・・復旧OK
OSのバージョン(9/15時点では10.10.5)、ユーザー情報、アピアランス、ネットワーク接続情報などなど、基本的な情報については元どおりになっています。
○ファイル・・・復旧OK
正直、確認のしようがないですが、普段つかっているアプリやメディアなど、動いている・使えている、という状態であれば、大丈夫でしょう。
×アプリ・・・要再設定
これ、当たり前なのかどうか微妙なところですが、とりあえず一部アプリが使えなくなっていたり、再設定を行わなければならなかったものです。
・Office365(これは別の問題も発生していて現在使えない→解消)
・Dropbox(おそらく今回のHDDクラッシュの原因か。プロキシ設定を外して再登録)
・(9/17現在)今の所これだけですが、随時追加していきます。
そもそも、プロキシを繋げている(串を刺している)状態というのも通常の家庭で置かれているPCではないと思いますので、あまり参考にはならないかもしれませんが、本当はバックアップを復元したらアプリの設定情報などもそのまま引き継いで動く必要があるように思います。
それから、前回も触れたとおり、OSに関しては現在使っているもののリカバリディスクは作っておく必要があります。今回はOSをアップデートしてから作業しましたが、やっぱり面倒くさい。来月、新しいOS(El Capitan、ってなんか言葉の意味知らなければかわいい響きだ)が出るようですし、アップデートをするつもりですので、必ず作らなきゃ、と思っています。
2015年9月16日水曜日
メインマシン(iMac)の復旧作業顛末
普段の作業は基本的にMacを使っている私ですが、ちょっと動きが悪くなり始めたので再起動しようと思ったのが今週の月曜日の朝のことでした。
そして再起動をしたのですが、一向に起動しない。グレーの画面でHDDを読み込んでいるプログレスバーが途中で止まったまま。
いったん強制終了し、ディスクユーティリティを起動(Option+Rを起動時に押して立ち上げるんですよ念のため)、ディスクのチェックをすると、ファイル階層に問題あり、というエラーが出ていて、しかも修復ができない、という状況。
とうとうHDDが逝ってしまわれたか、と考えたのですが、あらかじめHDDの状態を確認できるツールを入れていて、HDD自体に問題があったとは考えにくい状態ではありました。
そして、幸運なことに(というか当たり前なんだと思うんですが)バックアップはTime Capsule経由で毎日取っていたので、念のため新しくHDDを買い、最新のバックアップからの復元を行うことになりました。ですが、結構手間取って、しかも現段階ではまだ復元ができていないので、復元が完了するまでは久しぶりにWindowsマシン(Windows 10 on Surface Pro2)を使って作業をしています。
我が家には、OSXのメディアはSnow Leopard(10.6)しかありません。それ以降のOSはすべてMac App Storeから購入しているのですが、これが意外と復元の手間を増やしてくれました。そこで、実際の手順と、もっと簡単にできた(であろう)方法を、反省の念を込めてここに書いていこうと思います。何かの参考になればいいですが。
1.手順
まず手持ちのOSXをHDDに新規インストールし、徐々にアップデートをかけて最新のOSにする、という流れになります。我が家のケースでは、
「10.6インストール」→「10.6.8アップデート(Mac App Storeがインストールされる)」→「最新版(Yosemite:10.10)アップデート」→「バックアップデータのリストア」
という手順になります。
ここで思ったのは、10.6(SL)のメディアしかない状態だと、必ずMac App Storeの入手をしなくてはならない、ということ。ダウンロードにそれなりの時間を要してしまうため、実はHDDの入れ替えが終わってからMac App Storeが使えるようになるまで半日程度を費やしてしまいました。
ということは、最新のOSバージョン(今回のケースでいえば10.10)の復旧ディスクがあれば作業の手間はかなり短縮されるのではないか、ということが言えるわけです。以前別件でググって、Mac App Storeから入手したOSの復旧ディスクの作成方法がある、ということまでは知っていましたが、まさかこんな時に使えるのだ、とは思いもよりませんでした。
先日、Windows 10もOSXと同様のOTAインストールを採用し、OSのアップデート作業の手間は随分と減りましたが、復旧作業等のことを考えると、緊急用にメディアは作っておいたほうがよいのかな、と思いました。
2.復元作業
先ほども書いた通り、OSを最新のものにする、という作業自体はそれほど手間がかからない(時間はかかりますが)ので、まぁ片手間でも作業できるのですが、バックアップデータを復元させるのにちょっとした問題が発生しました。
メインマシン、と言いつつ、我が家のiMacにはかなりの量のメディアファイルが格納されています。音楽だけでも40GBとか、動画も昔のテレビ番組を変換した奴とか大量に入っていて、なんだかんだで使用量は1TBを超えていました。整理したり、外付けディスクやNASの導入も検討していたのですが、そもそもHDDは2TBあり、まだ大丈夫じゃね?とタカをくくっていたわけです。
で、当然復元をするデータも1TBを超える容量になっているのですが、実は我が家のTime Capsule、Wi-Fi経由でつなげていて、その状態で復元作業を開始すると、とてつもなく時間がかかりそうな予測が出ていました。ちなみに、リストアを開始してから数時間後、残り時間は550時間。20日とかですか。そんなに待ってられないです、というかかかりすぎにもほどがある(笑)。
そこから一晩寝かせておいて、再度残り時間を見ると、それでも470時間。多少短縮されたっぽいにしても、まだ1%程度の復旧率。寝かせておいた時間を12時間と想定しても、おそらく数週間単位での復旧になりそうな感じ。
そこで、Time Capsuleを直接iMacにつないで復旧、と考えたのですが、そもそも、Time CapsuleはUSB-HDDとしての機能を持っていないわけです。となると、Time Capsuleに入っているHDDを抜き出して、USB-HDDとして認識させられないか、と考えて、実際にやってみた(若干話を端折っていますが、Time CapsuleのHDDを取り出す、または交換する方法はググってみると結構出てきます)ところ、認識せず。
ということは、Time CapsuleとiMacをイーサネットケーブル経由で接続しない限り無理、という結論になるわけです。そして、このポストを書いている段階では、イーサ接続をして復元作業中、というのが今ここ、といったところです。ちなみに、作業開始から約1時間経過して、復元率は3%弱。残り時間表示は40時間。随分時間短縮できたもんです。この割合ならば、まぁ1時間で3%と考えれば、35~40時間、1~2日で終わる、と考えていいでしょう。
ただ、正直そんなに時間をかけたくない、ということもありますし、結局Time Capsuleは普段設置してある場所から移動せざるを得なくなった、ということもあり、非常にややこしいことになってしまいました。そんなことならバックアップはTime Capsuleへ、ではなく、復元作業の時間を考えると直接USBなどでつなげたHDDにとっておいたほうがよかったのかもしれない、とは思っています。
バックアップの取り方は置かれている状況にも寄るので、一概にこの方法がベスト、とかこの方法はダメ、とか言えないのですが、少なくともデスクトップ型のPCで容量もそれなりに、ということだと、NASなどのネットワークドライブにバックアップをとるのはあまりお勧めな方法とは言えないかもしれません。逆にノートPCでHDD容量も少ないのであれば、ネットワークドライブはかなりバックアップ先としては有効でしょう。
しかしまぁ、Windowsを久しぶりにガシガシ使うことになりましたが、一番ネックなのはキーボードですわね。メインのキー配列は変わらないですが、日本語と英語の切り替えや、Optionキー(WindowsでいえばCtrlキー)の場所が違っていたりするのはやっぱり面倒ですね。これはWindows 10のインプレとは何の関係もない話ではあるのですが(笑)。
そして再起動をしたのですが、一向に起動しない。グレーの画面でHDDを読み込んでいるプログレスバーが途中で止まったまま。
いったん強制終了し、ディスクユーティリティを起動(Option+Rを起動時に押して立ち上げるんですよ念のため)、ディスクのチェックをすると、ファイル階層に問題あり、というエラーが出ていて、しかも修復ができない、という状況。
とうとうHDDが逝ってしまわれたか、と考えたのですが、あらかじめHDDの状態を確認できるツールを入れていて、HDD自体に問題があったとは考えにくい状態ではありました。
そして、幸運なことに(というか当たり前なんだと思うんですが)バックアップはTime Capsule経由で毎日取っていたので、念のため新しくHDDを買い、最新のバックアップからの復元を行うことになりました。ですが、結構手間取って、しかも現段階ではまだ復元ができていないので、復元が完了するまでは久しぶりにWindowsマシン(Windows 10 on Surface Pro2)を使って作業をしています。
我が家には、OSXのメディアはSnow Leopard(10.6)しかありません。それ以降のOSはすべてMac App Storeから購入しているのですが、これが意外と復元の手間を増やしてくれました。そこで、実際の手順と、もっと簡単にできた(であろう)方法を、反省の念を込めてここに書いていこうと思います。何かの参考になればいいですが。
1.手順
まず手持ちのOSXをHDDに新規インストールし、徐々にアップデートをかけて最新のOSにする、という流れになります。我が家のケースでは、
「10.6インストール」→「10.6.8アップデート(Mac App Storeがインストールされる)」→「最新版(Yosemite:10.10)アップデート」→「バックアップデータのリストア」
という手順になります。
ここで思ったのは、10.6(SL)のメディアしかない状態だと、必ずMac App Storeの入手をしなくてはならない、ということ。ダウンロードにそれなりの時間を要してしまうため、実はHDDの入れ替えが終わってからMac App Storeが使えるようになるまで半日程度を費やしてしまいました。
ということは、最新のOSバージョン(今回のケースでいえば10.10)の復旧ディスクがあれば作業の手間はかなり短縮されるのではないか、ということが言えるわけです。以前別件でググって、Mac App Storeから入手したOSの復旧ディスクの作成方法がある、ということまでは知っていましたが、まさかこんな時に使えるのだ、とは思いもよりませんでした。
先日、Windows 10もOSXと同様のOTAインストールを採用し、OSのアップデート作業の手間は随分と減りましたが、復旧作業等のことを考えると、緊急用にメディアは作っておいたほうがよいのかな、と思いました。
2.復元作業
先ほども書いた通り、OSを最新のものにする、という作業自体はそれほど手間がかからない(時間はかかりますが)ので、まぁ片手間でも作業できるのですが、バックアップデータを復元させるのにちょっとした問題が発生しました。
メインマシン、と言いつつ、我が家のiMacにはかなりの量のメディアファイルが格納されています。音楽だけでも40GBとか、動画も昔のテレビ番組を変換した奴とか大量に入っていて、なんだかんだで使用量は1TBを超えていました。整理したり、外付けディスクやNASの導入も検討していたのですが、そもそもHDDは2TBあり、まだ大丈夫じゃね?とタカをくくっていたわけです。
で、当然復元をするデータも1TBを超える容量になっているのですが、実は我が家のTime Capsule、Wi-Fi経由でつなげていて、その状態で復元作業を開始すると、とてつもなく時間がかかりそうな予測が出ていました。ちなみに、リストアを開始してから数時間後、残り時間は550時間。20日とかですか。そんなに待ってられないです、というかかかりすぎにもほどがある(笑)。
そこから一晩寝かせておいて、再度残り時間を見ると、それでも470時間。多少短縮されたっぽいにしても、まだ1%程度の復旧率。寝かせておいた時間を12時間と想定しても、おそらく数週間単位での復旧になりそうな感じ。
そこで、Time Capsuleを直接iMacにつないで復旧、と考えたのですが、そもそも、Time CapsuleはUSB-HDDとしての機能を持っていないわけです。となると、Time Capsuleに入っているHDDを抜き出して、USB-HDDとして認識させられないか、と考えて、実際にやってみた(若干話を端折っていますが、Time CapsuleのHDDを取り出す、または交換する方法はググってみると結構出てきます)ところ、認識せず。
ということは、Time CapsuleとiMacをイーサネットケーブル経由で接続しない限り無理、という結論になるわけです。そして、このポストを書いている段階では、イーサ接続をして復元作業中、というのが今ここ、といったところです。ちなみに、作業開始から約1時間経過して、復元率は3%弱。残り時間表示は40時間。随分時間短縮できたもんです。この割合ならば、まぁ1時間で3%と考えれば、35~40時間、1~2日で終わる、と考えていいでしょう。
ただ、正直そんなに時間をかけたくない、ということもありますし、結局Time Capsuleは普段設置してある場所から移動せざるを得なくなった、ということもあり、非常にややこしいことになってしまいました。そんなことならバックアップはTime Capsuleへ、ではなく、復元作業の時間を考えると直接USBなどでつなげたHDDにとっておいたほうがよかったのかもしれない、とは思っています。
バックアップの取り方は置かれている状況にも寄るので、一概にこの方法がベスト、とかこの方法はダメ、とか言えないのですが、少なくともデスクトップ型のPCで容量もそれなりに、ということだと、NASなどのネットワークドライブにバックアップをとるのはあまりお勧めな方法とは言えないかもしれません。逆にノートPCでHDD容量も少ないのであれば、ネットワークドライブはかなりバックアップ先としては有効でしょう。
しかしまぁ、Windowsを久しぶりにガシガシ使うことになりましたが、一番ネックなのはキーボードですわね。メインのキー配列は変わらないですが、日本語と英語の切り替えや、Optionキー(WindowsでいえばCtrlキー)の場所が違っていたりするのはやっぱり面倒ですね。これはWindows 10のインプレとは何の関係もない話ではあるのですが(笑)。
2015年9月10日木曜日
Androidのアプリ公開直前に考えたこと(2015年9月編)
現在、Androidアプリを作っていて、そろそろ基本コーディングだけできたので、α版を公開しようかと考えています。
アプリは、・・・実は自分がプログラム以外にハマっていること、筋トレに関するアプリです。しかも万人ウケするようなものではなく、あるトレーニングメソッドに基づいたもので、そのトレーニングログを取る、というだけのアプリです。
今回リリースを予定しているものは、アプリの機能がメインで、何もデザインをしていない、ある意味使いにくいアプリなのですが、デザイン自体は並行して考えているものがあるので、次回リリースで不足している機能を追加するのと合わせてデザインを載せていこうと考えています。
さて、アプリの公開となるとそのアプリをどのようにマネタイズするのか、というところなのですが、基本的に私はアプリのダウンロード自体は無償でいい、と考えています。ではマネタイズは?
あくまでも一般的な話ですが、アプリのマネタイズは3つの方法に分かれると考えています。
1.アプリ自体の有料化
2.アプリ内課金
3.アプリ内の広告収入
まず、アプリの有料化ですが、私自身はあまりこのやり方では稼げないのでは?と考えています。もちろん、アプリが誰でも使え、世の中の誰もがそのアプリを持ってくれるというのなら収益の見込みも立ちそうですが、私のように、万人ウケしないアプリを作る時点でダウンロードをしてくれる人数に限りが出てきます(いや、仮に世界中の誰もがアプリを持っているとしても、ダウンロード人数には限りがあるのですが)。
会社でダウンロード数に対するアプリの収益を見込めなければ開発にGOサインが出ない、とでも言うならこのやり方で価格設定をせざるをえないでしょうが、アプリダウンロード数=収益、という考え方は今のご時世ではちょっと古すぎる気がします。だって、スマホアプリに限らず、パッケージソフトのバージョンアップに金をかける必要はあまりなくなってきてますからね。
次に、アプリ内課金。あくまでもアプリ内での仕組みがあっての話ですが、本当はこれが一番収益率が高いのではないかと考えています(実際にどうなのかその筋の人たちに聞いてみたいところですが)。一般的には、例えばゲームアプリの中でなんらかの権利(コインだのメダルだの何とか石だのといったアイテム)を購入することでゲームを有利に進められる、という仕組みとして知られていますが、他にもアプリ内広告や機能の制限解除などのために課金をする、というのもアプリ内課金です。
ただ、ゲームならばともかく、機能制限解除のために課金というのはフリーミアムの仕組みとしてはちょっと収益にはつながらない気がします。実際にそのようにしているアプリでは(これはビジネス系アプリに多くみられる傾向ですが)、機能がフリーソフトでもそこそこ充実していて、若干痒いところに手が届かない、というあたりで課金ポイントを設けていたりするように感じます。
最後に広告収入。広告を表示させたりクリックさせたりすることで広告収入を得、その代わりにアプリ自体を無償化するという仕組みで、ほとんどのフリーアプリがこの方法を取っているのではないかと思います。そして広告の表示の仕組み(技術的でなくマーケティング的な仕組み)にもいくつかあるようですが、それはまた別の機会に。
これは、私も調べてみないとわからないのですが、広告を表示させていくら、クリックしたらさらにいくら、的なインセンティブが支払われるのだと思いますので、アプリのダウンロード人数に加え、そのダウンロードされたアプリごとの表示数・クリック数が収益となっていき、かつアプリをずっと使い続ければそれだけ収益が上がっていく、という仕組み担っているはずです。アプリを使いつづけてくれることを前提にするならこの仕組みが一番でしょう。SNS系アプリはこの仕組みがあるのでアプリ自体は無償のものが多いです。
で、これらの仕組みを組み合わせたりして収益を上げていくのでしょうが、私自身、アプリを使う立場から考えると、こうあってほしい、という理想像もあるわけです。
・アプリは安ければ安いほどいいし、できれば無償のものを選びたい
・しかし、安かろう悪かろう、ではなく、使い勝手にはこだわりたい
・機能が限定されているアプリはどこかのタイミングで使えなくなるのが嫌だ
と、作って売る立場から考えれば「こんな客イヤだ」なタイプの人間を満足させるためには、使い勝手を優先し、それ以外のどこかで目をつぶってもらうしかない、と考えると、広告収入によるマネタイズが最善解になる、と考えます。ある程度収益の不安定さ(もしクリックによる収益しか得られないのならば基本的に収益なんて上がらないと考えたほうがいいでしょう。だって自分がクリックすることがないのだから)に目を瞑るなら、アプリがあるだけでほんのちょっとでも毎月お金が入ってくる仕組みを選びます。
話がちょっとずれますが、最近、テレビでもCMが流れている、「東京カジノプロジェクト」というゲームにはまっています。あれはアプリ内課金によるマネタイズですよね。それはともかく、カジノといえばいろんなゲームがあるわけですが、例えばポーカー。役の高いほうが勝てる、のですが、ポーカーの場合、役の高低と収益は必ずしも一致しません。ビデオポーカーは別ですよ。あれは役に倍率が付いていますが、テーブルポーカーだと、例えばワンペアとツーペアのどちらで勝っても、もらえるチップの数はテーブルに置いてある他人のチップの数だけ、なわけです。極論をいえば、ワンペアで勝ったときにテーブルの上に100枚ベットされている状態と、ロイヤルストレートフラッシュで勝ったときにテーブルの上に10枚ベットされている状態が存在する、ということになります。どっちで勝ったほうが収益率がいいですかね?
もう一度アプリの収益化に話を戻しますが。
アプリ自体にとても価値がある(本人がそう思うならそうだ、と考えましょう)ものにお金を払うべきだ、という考え方は自分がロイヤルストレートフラッシュを上がったのだから全員自分が賭けた金額と同額を支払うべきだ、と考えているのと同じだと考えるのです。
逆に、ワンペアでも、最悪役無しだったとしても、少しでもいいからお金が入ってくる、という仕組みはあまり賛同されないと思うのですが、では、そういう仕組みを持っているアプリがあったとしたら?
もっと言えば、アプリ自体は利用する人になんらかのリスクを負わせることになるわけです。ポーカーテーブルで最初に参加費を払うのと同じです。そこに、ロイヤルストレートフラッシュが来たからといって、自分の持ち金全部を賭けたところで、他の人たちが賭けに乗ってくれるはずはないでしょう。むしろ、スリーカードくらいでちょっと賭け金を上げて、他の人も勝てるかもしれない、とみんなが賭け金を上げてくれるほうがいい。アプリ自体に価値があるのではなくて、そのアプリが勝手に生み出す収益に期待するほうが勝ちやすい、と、そう思うわけです。まるでアプリ開発がギャンブルみたいな言い方になりましたが。
真面目な言い方をしてもほぼ同じです。ユーザーは馬の骨ともわからないアプリにお金を支払うくらいなら、ほんの少し不便があってもいいから安いアプリがほしいわけです。アプリ自体に価値があるかどうかなんてユーザー側には関係ない話で、ユーザーにとっては、そのアプリが使えるものであれば有償無償に関わらず「価値がある」と思うのですが、開発側にしてみたら、アプリを作るための開発費用がかかるので、その開発費用を手っ取り早く回収するために、一番簡単で収益の見込みの立ちやすい有償化を選択するわけです(中小企業は特にこのパターンでしょ?ちがう?)。
他人はともかく、私が自分でアプリを作る限り(考えたくないですがそんなアプリを作る会社を作ったとしても)、アプリ自体は無償で提供する、というポリシーは変えないでしょうね。そのかわり、広告は出ます。ちょっとアプリを使うのに都合が悪いかもしれませんが、それくらいは作る側の数少ないワガママとして許してください。
わかってます。自分だって、完全無償で広告も無し、ウザいメール登録がなくてジャンクメールも送られない、しかも機能はフルで自分のやりたいことが完璧に実現できてお釣りまで来る、そんなアプリがあったら使いたいですもん。でも、そんなアプリを自分で作って他の人に使ってもらったら自分にはお金が入ってこないし、むしろすごい勢いの出費が待ってる気がします(フル機能のうちに、無制限のクラウドスペースってのが入ってるから特にねぇ)。
だったらお互い、少しだけ不都合がある状態で手打ちしましょ、って云うのが私の考え方な訳です。その不都合というのが、
・提供側:爆発的な収益は見込めない
・利用側:アプリとは関係のない画面が表示される
というあたり、つまり広告表示、という仕組みな訳です。
アプリ自体はこの1〜2週間で公開してみます。まだ既知のバグもある状態なので、あまりダウンロードはして欲しくないのですが(しかも説明書きとか何もしてないので)、ベータ版になる頃にはバグも少なくなり、多少は使いやすくもなっているはずです。もちろん、そのトレーニングメソッド(囚人トレーニング、というやつですが)のことを知らない人には何のことやら、なアプリなんですが(笑)
それから、他にもいくつか立て続けにアプリの公開を考えていますが、まぁなにぶん一人でやっていることで、他にもやりたいことややらなければならないことをやっていることもあり、なかなか進まないのが実情ですね。一人でこういう仕事をやっていることの限界、と言ったところでしょうか。
そうそう。最後に。
もし、私がどのような形であっても、完全無償で広告無し、完璧な機能をもった、要はユーザに何のリスクもなく提供側に何の利益も生まないアプリを公開したとしたら、それはアプリ開発以外になんらかの収益源を見つけたから、と考えていただけると嬉しいです。そんなことありえないけどね(笑)
Windows10を使ってみて1ヶ月経った・・・らしい
つい先日、Surface(Pro2)をWindows 10にアップグレードしたばかり、と思っていたが、前回のポストはほぼひと月前。しかも、アップグレードから数日経って書いたはずのポストなので、
あれから1ヶ月。
普段がMac使いで、タブレットもSurfaceより小さいの、しかもAndroidだったりして、まぁ使わないんですよ、Windows 10。それでも、いわゆるタブレット端末としての利用は多いわけです。外に持ち出して使うので。というわけで、簡単にですが、1ヶ月使ってみて思ったことを書いてみようかと。
一般的な話ですが、Windows 10(以下W10)とそれ以前のOSの違いや他のOS(Mac/Linuxなど)との違いなど、ネットでググれば出てきそうな話は置いといて、私自身はWindows 10はWindows95以降で確立したスタイルを踏襲していて、良くも悪くもWindowsOSだなぁ、と思いました。
あれから1ヶ月。
普段がMac使いで、タブレットもSurfaceより小さいの、しかもAndroidだったりして、まぁ使わないんですよ、Windows 10。それでも、いわゆるタブレット端末としての利用は多いわけです。外に持ち出して使うので。というわけで、簡単にですが、1ヶ月使ってみて思ったことを書いてみようかと。
一般的な話ですが、Windows 10(以下W10)とそれ以前のOSの違いや他のOS(Mac/Linuxなど)との違いなど、ネットでググれば出てきそうな話は置いといて、私自身はWindows 10はWindows95以降で確立したスタイルを踏襲していて、良くも悪くもWindowsOSだなぁ、と思いました。
ただ、W10に関して言えば、いわゆるPC(デスクトップやノート)だけでなく、タブレットやスマホなど、あらゆるプラットフォームに対応することを前提にしているらしく、Appleの考えるマルチプラットフォームの考えとは真逆(OSXとiOSという二つのOSがあり、それぞれのいいとこ取りをするやり方)なのかな、とは思います。これはタブレット系端末、特にノートPCで画面だけ取り外せるタイプのものを使っていると感じることでしょう。
実際に、Surfaceでキーボードを取り外したり、裏面に折りたたむと、自動的に「タブレットモード」に切り替わる・・・はずですが、最初切り替わらなかったんです。自動切り替えは設定画面から設定します。確か。
「タブレットモード」・・・といっても、WindowsのUIが画面タッチでの操作に適した、Windows8で言う所のMetroモードに変わるとか、アプリが全画面表示になるとか、そんなくらいですが、ある意味思った通りの動作です。ただ、アプリの設定画面がポップアップで出現するタイプのアプリで、その設定画面が最大化されるのはちょっと興醒めですね。
これはアプリにもよるのですが、設定画面の設計はデスクトップ系OS(Windowsに限らずMacでもそうですが)の場合は別の窓で表示する、というのが普通ですし、タブレット(iOS/Androidを想定)ならばポップアップさせられないので最初から 新しい画面を作ることになるわけですが、その考え方の違い(≒画面設計)をどう吸収し、必ずしも斬新ではなくてもいいですが、新しいアイデアが必要だと思います。
それから、これは我が家のSurfaceだけの問題かもしれませんが、タブレットモードにしてから画面キーボードで文字の入力をしようとすると反応しない、または反応がとてつもなく遅い、という事象が発生します(Windows8の頃から稀に反応が遅かったりしたので端末固有の問題かもしれませんが)。
そして、もう一つ大きな問題が。Surface Pro(1/2だけかな?)では、電源に関する大きな問題が発生しているようです。
私はW10インストール後にちょこちょこと使ってはいたのですが、翌日ふと気づくと電池切れを起こしている、という状況が何度か続きました。通常、Surfaceはキーボード(Touch/Type Cover)を閉じるとスリープモードに移行する、という設定ができるようになっており、私もその設定をしてありました。が、閉じ損ねたりするとずっと電源が入りっぱなしになり、電池切れを起こす、ということも起こり得ます。
で、きちんと蓋を閉めた状態を確認した上でしばらく放置してみると、なんかすごい勢いでファンが回っているんです。これはおかしい。ググってみると、海外のフォーラムで幾つかスレッドが立っていたりしました。曰くスリープしないらしいです。フォーラムで挙げられている問題点をまとめると、
- スリープさせてもすぐに(しかも勝手に)復帰してしまう
- Windowsの終了をしないで置いておくとバッテリがすごい勢いで消費される
- しかもSurfaceがものすごく熱くなりファンが回りっぱなしになる
という状態。まさに我が家のSurfaceが直面している状況と同じ。実は、フォーラム内で原因をすでに探っていて、マウスやキーボードのドライバーに問題があるのでは?というのが一つの仮説。打開策として、該当するデバイスの設定でデバイスからのスリープ復帰を「させない」ようにすることで解決する、というものでした。
ただ、このやり方だと、スリープ/復帰は電源ボタンを押す以外できなくなるわけです。とすると、Touch/Type Coverで蓋をすればスリープ、開ければ即使える、というSurfaceのウリにしている機能が使えないんですね。個人的にはかなりションボリな話です。これは是非改善してほしいところですね。
また使ったレポを定期的に書いてみようと思います。
2015年8月6日木曜日
Windows 10 アップグレード顛末
今回は結論を先に書きます。
Windows 10のアップグレードで
0X80070004 - 0x2000D
Windows 10のアップグレードで
0X80070004 - 0x2000D
MIGRATE_DATA 操作中にエラーが発生したため、インストールはSAFE_OS フェーズで失敗しました
というエラーが発生してインストール途中で止まってしまう場合、
ユーザフォルダの名前が日本語(いわゆる2バイト文字)になっている
ことが原因かもしれません。
(解決策は最下部に。ただし、Microsoftアカウントでログインしている人限定・・・かも)
えーと、そして前置きから再度結論へ、という意味のわからん状態になりますが。
ご存知の通り、先月末にとうとうWindowsの新しいバージョンがリリースされたわけです。普段はMac使いの私ですが、当然Windowsも使っているわけで、アップグレードしたいよねー、とは思っていたのですがまぁ面倒なので予約とかしていなかったわけです。
で、手元の作業がひと段落したので、アップグレードでもしてみようか、と、右下にある『Windows 10 を入手する』というアイコンに触ってみたわけです。それが昨日(8/5)の話。
そしたら、今の段階でも「予約」とかなってるわけです。つまり、アップグレードしたい人は予約してね(はぁと)的な。
なるほど。今までのMicrosoftは勝手にアップグレードとかしていたのに今回はさすがにOS全体のアップグレードだから勝手にやっちゃ怒られるもんなぁ、と思いつつ、予約ボタンを押してみたのですが、数分経過しても何の音沙汰もない。リリースされているのだから予約したら即ダウンロードされるんじゃないの?と思っていたのだが(Appleはリリース日以降にAppStoreでダウンロード可能)、どうやら違うらしい。
ちょっとググってみたら、予約してから順番にダウンロードされるとかで、数日から数週間かかる可能性がある、との情報。まぁMacユーザの数倍いるWindowsユーザが全員ダウンロード(Microsoftからのプッシュ)をしたら世界のネットワークがパンクするかもしれん、というのは分かる気もしますが、ションボリですわね。
と、さらに情報を集めていると、手動でアップグレードも可能だとのこと。インストールメディア(データ)が配布されており、それをダウンロードすることでできるらしい。ちなみにサイトはこちら。
このディスクイメージからインストールメディアを作成して、PCにぶち込めばインストール完了・・・、となるはずだったのですが。
ちなみに、今回インストールに使った機種は、Microsoft謹製のSurface Pro 2(OS:Win8.1)。
中古で買った割には結構使えるマシンです。どうでもいいですが。
#今回のインストールの件でググってみたらクソマシンだと宣う方もおられました。
#その方の評価を否定するつもりは全くありませんし、評価されている内容については私も同感ですが、
#個人的にはそこまでいうほどクソマシンではないかなぁ、という印象ですよ。
メディア(DVD)を入れ、インストール開始してからしばらくすると、途中で再起動がかかり、その後、「以前のWindowsのバージョンに戻しています」的なメッセージが表示され、結局もとのWindows画面に戻ってしまうという状態。
ダウンロードされたファイルが壊れていたり、メディアがうまく作れていない可能性も考え、家にある仮想環境でクリーンインストールを試みつつエラーコード(0X80070004-0x2000D)で検索をしてみると、何件かそれっぽいのにぶつかります。
例:
上記のサイトはどちらもMicrosoft提供のQAフォーラムなので、情報の信ぴょう性はある、と仮定して情報を整理すると、
・メディア(もしくはイメージファイル)の破損
・アンチウィルスソフトの存在
・システムフォルダ(Program Filesフォルダとかユーザフォルダとか)がデフォルトでない場所にいる
・なんかのキャッシュが悪さしてる
といった要因が可能性として考えられる、とあります。
ちなみに、アップグレード用のマシンにはアンチウィルスソフトは入れてなく(忘れていたことにこの時気付いた)、インストールに邪魔なほどキャッシュファイルもたまっておらず、システムフォルダはデフォルトのまま使っているので、メディア系の問題かと仮想環境側のインストール状況を見ると、いつのまにかインストールが完了していました。
では、イメージファイルまでは問題なければあとはメディアを作る段階で何か問題が発生したのか、ということなのですが、ここでもう一枚DVD焼いたら負ける気がします(笑)。
インストールが失敗する要素を並べながら考えてみること1時間。
ふと思い出したのが、SurfaceにUnity(ゲーム作るアプリ)をインストールした時に起こったエラーです。実は、エラーが頻発したのでググってみると、2バイト文字のユーザフォルダでは動作が不安定になるとかいう話で、その場合の解決方法は『シンボリックリンク』を1バイト文字のフォルダ名で作り、そこをユーザフォルダとして認識させることでエラーが解消するのです。
まさか、これ?
シンボリックリンクではなく、ユーザフォルダが2バイトだから、ということね。
Windows8からはMicrosoftアカウントでのログインができるようになり、これがノートPC(Surface)とデスクトップ(仮想環境)の2台使いをしていると結構便利だったので使っていたのですが、何も考えずに普通に登録をしたので、名前は日本語で登録をしたわけです。それにより、私のユーザフォルダの名前は2バイト文字で登録をされたわけです。
ちなみに、私の友人でパソコンにそれほど詳しくない人たちが持っているPCをみると、このユーザフォルダが日本語になっているケース、多いです。ログイン名が日本語なのでフォルダを見るまでもなくわかりますな。小さい会社なんかでもこういうケース、多いですよね。ドメインとか使わないと勝手にユーザ名日本語にしちゃうんです。だって日本人だもの。
で、先ほどのフォーラムをもう一度見直し、解決案として提示されているのは、
・管理者権限のローカルアカウントでインストール
・(Win8限定)Windows ストアのキャッシュを削除
・不要なサービス(Microsoft謹製サービス以外のもの)の停止(笑)
とかいったところですが、そもそもこれで解決ができていない可能性もあり(これらの情報により成功した、という追加情報がないため)、試しにユーザフォルダの名前変更(1バイト化)を試してみよう、と考えたわけです。
ただ、Microsoftアカウントで作成したユーザフォルダの名前は変えることができなさそうなので、安直にMicrosoftアカウント側のユーザ名を1バイト(半角ローマ字)に変更し、ログアウト→ログインを行うと、新しいユーザフォルダの元で「ほぼ」元の状態で立ち上がります。
注:本当は、この前にユーザフォルダのバックアップ、例えばブックマークとかドキュメントファイルとかをバックアップしてどこかに退避する必要がありますが、私は面倒なのでしてません。もともと別のところにバックアップしてあるし、漏れてても困らないし。
ここまで昨日の作業でした。
そして、今朝(8/6)からインストールを開始し、途中トレーニングに出かけていたので経過はどうだったかわかりませんが、トレーニングから帰ってきたらインストールが終わっていました。ということで、私の環境下でのインストールエラーの原因は、
ユーザフォルダが2バイト文字だったから
だったようです。
Microsoftさん、これは致命的なミスかもよ(笑)
2015年5月29日金曜日
LINE Creators Market顛末(その2:販売開始編)
しかも、販売はすでに一ヶ月以上前に開始しており、特にマーケティングなどもしてないくせにナゼか売上が立っているという状況。
ちなみに、販売しているのはこんなの。
あえて「買ってください」とは言いませんが、買ってくれたらそりゃ嬉しいですね。
ただ、買ってくれたらなんかします、とかいうキャンペーンは行っておりません念のため(笑)
さて、繰り返しになるが前回のポストは随分前の1月下旬。この時点では、うしまみれスタンプが申請済(12月中に申請)、ちっちきちゃんスタンプは申請直後だった。
そして、もう1種類準備をしていたが、こちら側でネタ切れになっており、申請をしていない状態(それが今現在も続いているのは内緒)。
そして、販売開始が4月中旬だったのだが、その間に各1回ずつ却下(リジェクト)を食らった。理由はどちらも、背景色等の処理がキチンとできていないこと。
ちなみに、他のクリエイターたちのリジェクトの理由を検索してみると、それ以外の理由が意外と多いようで。
似た画像が多い、アスキーアートだ、性的表現、使い道がない、などなど。
同じ構図で文字だけ違う、とかスタンプとして意味がないように思うんだけど、それでも作ってリジェクトされている人、意外と多いのね。
アスキーアートや性的・暴力表現はともかく、「使い道がない」スタンプを作る理由って・・・。
それと、やはり、背景色等の画像処理レベルでもリジェクトは多いようですな。
要するに、リジェクトが起こりうるのは、
・スタンプの企画内容に問題がある
・スタンプの作成過程で問題がある
という流れなのでしょうね。企画自体がキチンとしていれば大丈夫、という見方もできますが。
で、実は二つのスタンプが審査を通ったのはほぼ同時で、数日違い程度。だから1月からと考えて、申請から審査通過(販売開始は通過直後)までほぼ3.5ヶ月かかってる、と考えてよい。
ちなみに、2月からスタンプの収益分配率が変わるというタイミングだったので、1月中にスタンプの申請が殺到したと予想されるが、それでもこの程度で審査通過というのは早い方なのか。
さて、販売開始以降のお話だが、販売当時は、自分(たち)自身も、まぁ売れるとも思っておらず、自分たちのために作ってみよう的な要素も大きかったのでキチンと売り出すこともせず、あえて言うなら嫁が自分のブログに書き込みをちょっとした程度だった。
もちろん、自分たちは夫婦のコミュニケーション用に即購入するわけだが、売上なんて気にもせずしばらく放置していた。
すると、5月に入って、LINEからメールが。売上がたちましたよメールだったのだが、そりゃ夫婦二人で買っただけなので、大した売上でもなかろう、と思っていたら。
「スタンプ2つで1,500円の売上でーす」
はぁ?
細かく言うと、スタンプ1つ(1セット)は50コインで販売される。1コイン税込1.47円が基準。うち、半分がこちらの売上になるので、2人が購入すればスタンプ自体の売上は294円、こちらに分配される売上は147円、ということか。実際にはボーナスコインなんかもあるので、もう少し割りを食うと思われるが。
#その後よくよく調べてみると、スタンプの販売経路で値段が微妙に異なるようで。
#スマホだと50コイン(=120円)、PCからだと120円。
#後述のように、海外でも販売しており、為替レートやら何やらが絡む。
#売上分析という観点からみると非常にわかりにくい。
いくつ売れたのかとかいまいちわかりにくいのだが、単純に売上1500円を倍にして、1セット100円で販売した、と計算するなら、30セット売れた、という計算。へぇ。4月は半分くらいしかないのに30セットも売れたんだぁ。
スタンプ販売数はわからないが、スタンプの利用状況は各スタンプで(セットではなく一つ一つのスタンプで)送受信の数がわかるようになっており、そこからどのような使われ方をしているか、そして、どこの国の人が使っているか、ということが類推できるのだが・・・。
なぜか4月中、台湾で送受信数が多い。ということは買った人も台湾の人たち?
(LINE利用者数2014年7月末時点公式発表・・・日本:5200万人、台湾:1700万人)
ちなみに各国人口当たりの利用率を概算すると、日本:1億2700万人なので約40%、台湾:2300万人として63%となり、普及率と同義と考えれば、台湾の人たちは結構つかってるんだな、と。
まぁ、そうは言っても結局1ヶ月で数十セットしか売れないわけです。何もしてなければ。
だから、マーケティングが大事、と言いたいところだが、個人的にはLINEスタンプについては何もしなくていいかな、と思っていたり。
理由は簡単。世界的なマーケティングなんてできないから(あくまでも個人レベルでは、という意味)。
売上が日本以外の国で立っていた、という事実から考えられるのは、
・LINEの新作スタンプを紹介しているなんらかの媒体が日本以外にもあると考えられる
・日本以外の国で利用率が高い国が存在する(台湾以外にも、タイで40%の利用率が高い国)
・スタンプ自体は言葉の壁を越える(というか、超えられるようなスタンプを作るべき)
・日本に限らず、スタンプの「口コミ」は存在しているはずだ
と、ちょっとまとまっていない考察ではあるが、今後のスタンプの作り方や売り方の参考にはなりそう。
・スタンプは文字より絵。絵だけでなんらかの表情を表しているだけで十分使える
→スタンプの絵はほぼ同じで吹き出しの文字だけで差別化しているのはまぁリジェクト対象だけど、そんなレベルじゃ売れない
・クオリティ重視。よく練られた企画があればこそ(どちらのスタンプも基本は夫婦間でのコミュニケーションツールとして作っていた)
→売れるものを作るのではなく、使いやすいものを作るのが基本で、使えない(=使い所が少ない)スタンプは売れないしリジェクトされる
・でも質より量かも。マーケティングをしないのであればいつかは忘れられていくはず。新しいスタンプを定期的に売り出す必要はある
→一攫千金は運。バズることを前提にマーケティングするのは大変。だったら新しいのを定期的に作るのがいいんじゃないのか
まぁ、面白い収益の仕組みであることには変わりないし、なんとなく稼げるというのもネタとしてはアリ。
だが、こいつで一攫千金はおそらく期待薄。もう少し長い目で収益を見ていきたいとは思っているが、果たしてどうなることやら。
2015年3月6日金曜日
突然プログラムコーディングに目覚める引きこもり(その2:スマホゲーム編)
前回ポストから時間が随分過ぎてしまった。
毎日引きこもりをしているとはいえ、ずっとPCの前にいるわけでもなく、ちょっと出かけたり、仕事とは関係無いことをしていたり。
正直、アイデアだけはたくさん出てくるのだが、アイデアだけではメシも食えないので、具現化すべく行動を起こさねば、と、プロジェクトを同時並行で動かしていたりする。
そんな中、さらに新しい企画を思いついてしまった。というより夫婦の会話の中でふと出てきた、「自分で作ったキャラクターで育成ゲーム作ったら面白いよねー」という一言。随分前の話だが、朝方までLINEのスタンプ作りをチマチマとやっている間に出てきた言葉に、思わず反応してしまった。悪い癖だ・・・(笑)
毎日引きこもりをしているとはいえ、ずっとPCの前にいるわけでもなく、ちょっと出かけたり、仕事とは関係無いことをしていたり。
正直、アイデアだけはたくさん出てくるのだが、アイデアだけではメシも食えないので、具現化すべく行動を起こさねば、と、プロジェクトを同時並行で動かしていたりする。
そんな中、さらに新しい企画を思いついてしまった。というより夫婦の会話の中でふと出てきた、「自分で作ったキャラクターで育成ゲーム作ったら面白いよねー」という一言。随分前の話だが、朝方までLINEのスタンプ作りをチマチマとやっている間に出てきた言葉に、思わず反応してしまった。悪い癖だ・・・(笑)
で、よせばいいのに、ゲームなら最近流行らしい「Unity」だよねーと一人で勝手に脳内変換をしつつ、夫婦でのブレーンストーミングを行ったのだが、終わって早速Unityを起動してみると、・・・「開発言語はC#です」、だとぉ?
これまたObjective-Cと同様、C言語をベースにした開発言語だが、いうまでもなく「異なる言語」なのである。ゲルマン語系列だが全く異なる言語である英語とドイツ語みたいなもんか。それを、今まで日本語しか知らん40過ぎのオッサンが勉強とかでなく、いきなり喋れ!と言われたような状態になるわけだ。混乱するわな。
そうは言っても一応プログラマ上がりのフリーエンジニアですからね。できないことなんてないですよ。なんとかプログラム組んでみましょ。
ちなみに。
こういうポストによくあるのが、「こんな本を読んで勉強してますー」的な言葉の近くにある、アフィリエイトの広告類。本当はそういった広告も載せてみたいと思うのだが、実は、そういった本、滅多に買わない。
プログラムの言語関係で今まで買った本といえば(新しい順に思い出してみると)、
・HTML5の本:1冊
・iPhone開発用の本:1冊
・Pythonの本:1冊
・VisualC++:1冊
・C/C++の本:1冊
・SQLのコマンドリファレンス:1冊
これくらい。しかも、iPhone開発とHTML5の本以外は20世紀に購入した年季モノで、しかもどれもが今でも手垢の付いてない新品同様の品物(笑)。
読まないんだね。読んでも入ってこない、というか、知りたい情報がない、というか。
で、最近はネットでコーディングの情報を得ることが多く、コマンドリファレンスなんかもブラウザで開きっぱなしにしながら見てるとか、昔からやってるVBAのプログラミングなんかでもそういったスタイルだったりする。
でも、ネットでもやっぱり知りたい情報が少ないことが多くて、結構困る。
割と有名どころのサイトでもそうだが、結局のところ教科書以上のことが書いていないのだ。実践的な内容が少ないので、「こういう時はどうしたらいいんだろう」と思う時に不必要な情報しか得られない。
ちなみに。
こういうポストによくあるのが、「こんな本を読んで勉強してますー」的な言葉の近くにある、アフィリエイトの広告類。本当はそういった広告も載せてみたいと思うのだが、実は、そういった本、滅多に買わない。
プログラムの言語関係で今まで買った本といえば(新しい順に思い出してみると)、
・HTML5の本:1冊
・iPhone開発用の本:1冊
・Pythonの本:1冊
・VisualC++:1冊
・C/C++の本:1冊
・SQLのコマンドリファレンス:1冊
これくらい。しかも、iPhone開発とHTML5の本以外は20世紀に購入した年季モノで、しかもどれもが今でも手垢の付いてない新品同様の品物(笑)。
読まないんだね。読んでも入ってこない、というか、知りたい情報がない、というか。
で、最近はネットでコーディングの情報を得ることが多く、コマンドリファレンスなんかもブラウザで開きっぱなしにしながら見てるとか、昔からやってるVBAのプログラミングなんかでもそういったスタイルだったりする。
でも、ネットでもやっぱり知りたい情報が少ないことが多くて、結構困る。
割と有名どころのサイトでもそうだが、結局のところ教科書以上のことが書いていないのだ。実践的な内容が少ないので、「こういう時はどうしたらいいんだろう」と思う時に不必要な情報しか得られない。
教科書レベルであれば各言語のリファレンスを見れば済むことだったりするので、解りやすいリファレンスを作る、というテーマであーいったサイトは作ってんのかなぁ、なんて邪推してみたり・・・。
2015年2月20日金曜日
自宅PCを仮想化する(その2:VMWare導入編)
「自宅仮想化」ネタの第2弾、実際に仮想化を行ったことで感じたことを書き連ねていきます。
#そもそもなぜ仮想化に至ったかという経緯はこちら。
「仮想化」に対してあまり知識がない状態なので、まずは調べ物から。
・・・と調べてみたものの、例えばWikipediaなどの情報だと言ってる意味が全くわからない。イメージが湧かない、というか、そんな感じ。
そんな中、以前「仮想化」という意識をせずに使っていたMacの仮想化ソフト、「VMWare FUSION」の親戚みたいなの(導入時点ではこの程度の認識でした・・・)があり、しかも無償で提供されている、というので、まずはそいつで試してみよう、と相成った。その名は・・・、
「VMWare ESXi」
名前なんてどうでもいいが、要するにVMWareってヤツだね、と。Macで使う前から名前だけは聞いていて、何やら遠隔地にあるサーバをごにょごにょとかマシンがごにょごにょとかどうとか。要するに一つの物理マシン(パソコンの機械)のハードディスクにOSを入れるんじゃなくって、物理マシンを四次元ポケットみたいにしてしまい、その中に「パソコン的なもの(いわゆる仮想マシン)」をいっぱい放り込み、使いたい時に取り出せる、という便利な「未来の道具」なのだ、とドラえもん的発想で考えればそんな感じ。
本来なら他に検討するべきところなのだが、まずはどんなイメージで動作するのかを確認したいので、ちゃっちゃとインストール。特に今回セットアップ等の方法はここには載せないが、参考になるサイトはいくつかあって、
・やってみよう! VMwareの製品をダウンロードしてみよう (VMWare.com)
など。この辺を見たらまぁ大体セットアップはできるはず。
ただし、このソフト(・・・というような代物ではないがまぁわかりやすく言えばソフトだなぁ)、ちょっとした問題点がある。
ハードウェアの対応が厳しすぎるのだ。
基本的に、仮想化するためのハードウェアの条件は、
・CPUが「仮想化技術」に対応していること
・メモリをいっぱい積んでないとダメ
理由:複数OSに対して一つのマシンに積んであるメモリを共有させるから
※後々触れる「メモリ共有」という仕組みはあるが、だからと言ってメモリ最低限、というわけにはいかない
→自宅PC:8GB
※後々触れる「メモリ共有」という仕組みはあるが、だからと言ってメモリ最低限、というわけにはいかない
→自宅PC:8GB
・ネットワークカード(NIC)がないとダメ
普通のPCのようにディスプレイを繋いでも仮想化したOSが表示されるわけじゃない。仮想マシンは別のPCからネットワーク経由で呼び出すし、仮想マシンのOSインストールも同様に別のPCからネットワーク経由で行うのだ
→自宅PC:後述
→自宅PC:後述
というのがある。実はその辺で売っている(いわゆる家庭向け/コンシューマー向け)PCだとこの条件を微妙に満たさない。俺はたまたま(というか仕事だから、というか)チョイとハイスペックな自作PCをWindows用に使っていたこともあり、この条件は満たしていたのだが、ここからさらに細かい条件があり、そのままでは使えない、ということになった。
詳しく言うと、NICがあるのに対応していない、という状況。
使っていたPCはNICがマザーボードに直接繋がっている(いわゆるオンボードNIC)タイプの、「ASUS P5QC」というヤツ。ちなみにNICのチップセットはAtheros社のヤツなのだが、この会社のはVMWareではほぼ未対応だとのこと。
#実は、対応させる方法はあるのだが、ドライバーを自分で作らなければならない。
#そのために時間を割くことはできなかったのでこの方法での対応は却下した。
なので、対応しているNICを買ってくる羽目に。買ったのはIntel社のチップが載っているノーブランドのバルクもので、こいつを入れてあげたらインストールできた。
簡単な手順としては、このソフトをインストールしてから、「Windowsマシン上で」仮想マシンを作成、OSを入れる、という手順なのだが、この時点でWindowsマシンは手元にない。Macしかない。さてどうするか。
とりあえず以前使っていたVMWare FUSIONがあるので、Macにインストールし、そこからWindowsを起動させて、という、かなりややこしいことをして仮想マシンを2台作成することに成功。仮想マシンはMacにインストールした「Microsoft Remote Desktop」を使ってアクセスすることになった。
さて、使ってみると・・・。
これがまた快適。びっくりするくらい快適。
各(仮想)マシンに対してはそれぞれ4GBのメモリを割り当ててあるため、そこそこのマシンを四次元ポケットに2台入れてある状態。ただし、ネットワークの速度に依存するところもあり、たまに我が家の無線が調子悪くなったりすると突然動きが遅くなったりする。
それから、呼び出す端末の速度にも依存するようで、普段使っているMacのデスクトップ(当時はiMacのちょっと古いヤツ)が別の作業をしていると呼び出したWindowsの速度も遅くなったりする。これは、iMacを買い換えた際に判明したこと。
<!--
ちょっと話がずれるが、いわゆるシンクライアントを使う方法もあったと思う。
実際には我が家ではある事情(前回のポストにもある通り、必要以上の端末購入はできない)によりシンクライアントの導入ができなかった。が、上記のように、仮想マシンを使うにあたってのシンクライアント導入については、マシンのメモリがそこそこ積まれていて、かつネットワーク環境が早ければ早いほど快適に使える、ということが言えると思う。
では、そんな条件を満たすのは例えばどんなマシンなのか。その辺で売っているマシンなら、例えばChromebookとかなら快適かもしれないし、ネットブック系の小さいPCを使ってもメモリが増設できるマシンなら有用かもしれない。
そして、実は試してみたいのが、Playstation。2は持っているが、ネットワークに繋げない気がしているので多分無理だろう。では、3とか4とか、たしかブラウザがあるはずなので、それを使ったらどうなるだろうか。もうちょっとお金に余裕ができたら買って試してみたいところではある。
では、そんな条件を満たすのは例えばどんなマシンなのか。その辺で売っているマシンなら、例えばChromebookとかなら快適かもしれないし、ネットブック系の小さいPCを使ってもメモリが増設できるマシンなら有用かもしれない。
そして、実は試してみたいのが、Playstation。2は持っているが、ネットワークに繋げない気がしているので多分無理だろう。では、3とか4とか、たしかブラウザがあるはずなので、それを使ったらどうなるだろうか。もうちょっとお金に余裕ができたら買って試してみたいところではある。
さて、呼び出す端末に依存する部分は解決のしようがあるのだが、呼び出される四次元ポケット側の問題は如何ともしがたい。先に述べている通り、この四次元ポケット(ソフトのことね)はとりあえずハードウェアの選り好みが激しいわけで、NICだけでなく、もう一つ対応できていないものがあった。サウンドカードである。
単純に開発をするだけであれば全く問題はなかったのが、WindowsマシンでRadikoの録音をする、という用途上、どうしても「音がしない」ことで、録音ができない事象が発生。いろんなソフト(こんなのとかこんなのとか)を試してみたのだが、どうもうまく録音ができない。これが結局自分で作ろう、という結論に結びついたのだが・・・。
そこで、何件かもらっていたAccessツールの移植の仕事がひと段落する頃合いを見計らって、他の「仮想化」のための方法を探ってみた。そこで見つけたのが・・・、
・・・
ここで「次回に続く」とかやると、最近のテレビ番組みたいでイヤなんだけどなぁ(笑)
でも・・・、
次回に続く。選定のプロセスもあるのでそこから話を進めようか。
2015年2月12日木曜日
自宅PCを仮想化する(その1:顛末)
いつ頃からか、IT業界では「仮想化」という言葉が流行りだしていたようである。普通の生活をしているとほぼ関係がない用語ではあり、わりと普通の生活をしている俺にとっても、しばらく関係のない用語ではあった。
が、現在では我が家のPCは「仮想化」されることで複数台のPCを一つのマシンにまとめられている、という、一風変わった環境になっている。
この環境にしたのがちょうど1年くらい前なので、その頃の状況を含めてメモを残してみようと思う。
ただし、技術的かつ概念的な話なので、非常につまらないかも。完全なチラ裏ですね(笑)
もともと、我が家ではある「掟」がある。
『PC類はたくさん買っちゃダメ。必要な分だけ。』
今でこそ仕事で使うのでこの制限は随分ゆるくなっているが、1年前はMac1台(自宅用デスクトップ)とWindows1台(Office/VBA開発用)以上は持てなかった。VBAの開発は会社員時代から個人的にチマチマと仕事を受けていたりしたので、Windowsマシンはそれなりにハイスペックな、サーバーと見間違うようなものを持っていた。
で、ディスプレイやキーボード・マウスを2セット用意し、作業部屋の小さい机の上でキーボードをとっかえひっかえしながら作業をしていたのだが、まぁ開発以外にはWindowsマシンは使わないので(実際にはRadikoの録音をしていたので常時付けっぱなし)、大した問題もなく、あえて言うならWindowsマシンがデカすぎて場所をとってしまうくらいのものであった。
そしてある時(これがちょうど1年前)、VBA開発を以前依頼されていた方から、こんな依頼を受けた。
「以前作ってもらったAccessアプリ、Office新しくするから作り直してくれる?」
よくよく聞いてみると、そのアプリを開発した時からもう数年経っていて、マシンを新しくしようとしたのだが、その頃とは環境が随分変わっていて、アプリが古くて動かないかもしれない、ということなのだ。
開発当時は、
・OS:Windows XP
・Office: 2003
で、新しく購入予定のマシンは、
・OS: Windows 8
・Office: 2013
要するに、サポート切れ間近のマシンから最新マシンに変更したい、というところから始まったのだが、その検証段階で、Officeを使っていたアプリがあり、これが動かないのではないか、ということであった。
単純にAccessでデータベースを使っているだけならば単純に変換をするだけで動くはずなのだが、アプリとして作っているので、変換だけでは動かないだろう、という話は当初の開発時に既にしていた。開発時にはもうOffice2010が出ていて、2003との互換性については特にAccessがネックになる、ということだけは分かっていた(詳細はそのうちどこかでブログに載せようと思う)。
しかもそこでOSが新しくなる、という話もあり、そもそもOfficeは一台のマシンに複数インストールすることはできないし(本当は「できる」のだが、複数のOfficeを入れた状態は特殊であり、通常の環境とは異なる挙動をしてしまうことがあるということは経験済)、単純に我が家の開発用Windowsを新しくするだけでは失敗する可能性があるだろう、と考えた。
ということで、新しくWindowsマシンを購入しようとしたのだが、ここでネックとなるのが、我が家の掟。
『PC類はたくさん買っちゃダメ。必要な分だけ。』
いや、必要じゃん?
と思うだろうが、よく考えてみると、この「新しい環境への移植」というのは一時的な作業なのだ。一時的な作業のためだけにマシンをもう一台購入する、というのは認めたくても認められない、というのが我が家での見解。
おまけに言えば、そのための費用。今回の開発に対して支払われる報酬はそれほど多くない。一台のマシンを買うこともできない程度しか支払われない。
かといって、この仕事、受けないわけにもいかない事情があるため、なんとかしようと色々と考えてみた。
この時点(2014年1月)での我が家の状況を整理する。
・Windowsマシンは1台。OSはWin7/Office2003。常時電源を入れておく必要がある。
・Macは1台。OSはLion(10.7)。
・Office2013は持っている(Office365のサブスクリプション)。
ここで考えられる方法はいくつかあった。
1. WindowsマシンにOSを複数入れ、利用の都度切り替えて作業する
2. MacのBootcamp機能でWindowsを入れる(もしくはWindowsのみインストールする)
3. Macに「仮想化」ソフトウェアを導入、Windowsとの共存状態にする
1については、正直にいって面倒なので却下。特に、Radikoの録音予定時間に仕事をしていることがあると録音できないし、だからと言って録音するためのツールを両方のOSに入れておく、というのもちょっと違う気がしていた。
2(Bootcamp)に関しては、普段Mac使いとしてはベストな方法ではある、のだが、これまた「切り替える」という作業が面倒なことは事実。iPhoneとの同期を取ったり、iTunesで音楽でも聴きながら作業、というのができなくなるのでこれも却下。Windowsマシンにするなんてのは論外。
となると、3が最適解に思えてくる。実は以前にこの環境での作業をしていたことがあった。その時はMacのノートPC(Macbook Air:この時点では壊れており使えない状況だった)を使っていたのだが、動作が非常に重くて使い物にならない(特に開発については)、と感じていた。
そこで「仮想化」について色々と調べてみると、OSを複数同時に起動させる方法がある、ということに気がついた。いわゆる「仮想化プラットフォーム」である。これであれば、1台のマシンに2つのOS(および異なるバージョンのOffice)をインストールすることができ、かつどちらも起動した状態にすることができるのだ。
また、そもそもWindows用に使っていたマシンはサーバ用途で使えるスペックであり(しかも拡張性が高く、まだ拡張の余地は残されている)、仮想化に耐えうると判断した。
ということで、ちょっとマニアックな「仮想化」という環境を我が家で構築することになったのだが、実際の環境構築に至るまでの話や、その後の状態、今後の展開については後日改めて・・・。
2015年1月21日水曜日
突然プログラムコーディングに目覚める引きこもり(その1:Macプログラム編)
先週から今週にかけては、外に出ていることが多く、引きこもりでもなんでもない生活。
そしてやっと今日になって、しばらく引きこもりになれる、と思ったら外は雪混じりの雨。ストーブはあるが節約しながら使うのでそんなに暖かくない。体を動かすこともなければほぼ自分の机の周りで生活ができる。この一瞬だけを見たら廃人だなぁ、と思ってしまったり。
さて、前回に続き、これも自分で仕事をやるのだったら作りたくて仕方のなかったことのご紹介を。
現在、Mac版のストリームラジオ録音ツールというものを作るべく、Macの開発言語の一つ(デファクトなのかな?)である、Objective-Cを駆使してプログラムを書き始めている。なぜかと言われると非常に困るが、単に、「自分が欲しかった」からなのだが。
Objective-Cという名の通り、言語としてはC言語の延長上にあるもの、とかなんとか・・・、詳細はWikipediaにでも載っている通りではあるのだが、何しろ今までC言語は数回くらいしか使ったことがなく(本職はVBAなので)、しかも、C言語の入門書も通して読んだこともなければなんか難しくて途中で挫折したこともあるので、果たして作れるものだろうか、と不安になりながら作り始めた。
そもそも、プログラムを作るためには「設計」という工程を踏まないといけない、というのはこの手の業界での基本ではある。ただ、「設計」にもいろいろとあり、大企業で使っている業務ソフトなどのように、顧客とのコミュニケーションに使うような細かい設計書を用意したり、「設計書はオレのアタマの中!」的な設計もある。
ただ、何れにせよ「設計」をするにはその前に完成予想図が必要。イメージのラフ画みたいなの。芸術的な建築家(例えば俺の大好きなオスカー・ニーマイヤーとか)は設計図を書く前にイメージ画が存在するはずなのだ。いきなり図面なんぞひくはずがない。
ということで、一番最初にしたことは、作成するその「ツールで何をするのか」ということ。
頭の中にある、アレやりたいコレやりたいを全て吐き出す。自分で作るので限界なし。とにかくやりたいことてんこ盛り。いわゆるブレーンストーミングである。
#実はまだ終わっていなくて、途中で一旦止めてある。
#アイデアはそのあとも産まれるので書き出してあったりなかったり。
そして、そのブレーンストーミングの結果出てきた言の葉たちを一つ一つプログラムに落とし込む作業を行っていく。まとめてプログラムを作るのではなく、一つ一つ。
例えば・・・。
ストリームラジオの録音をする、というのが範囲が大きすぎるので、これは分解する。NHKのラジオを録音したい、とか、J−WAVEを録音したいとか、細かく分解。
では、NHKのラジオを録音する、となると、これは一つのプログラムに落とし込むことができる単位になる(これはプログラムを書く人の目線なので、非プログラマには分かりにくいかもしれないが)。で、とりあえず録音をするためのプログラムを書く。テストする。録音できたらこれでプログラミングの完了。
技術的にいうと、アジャイルプログラミングの技法を使う、ということになるのだが、なにせ単独作業なので、これがアジャイル?とか自分自身では思ってもいなくて、むしろ、「これぞ日曜プログラム」とか「DIYプログラミング」とか言いたい感じではあるが。
ちょっと話が技法の話にずれていったが、そんな細かい単位での開発に、敢えて(というよりは必要に迫られて)未知のプログラム言語を使ってみたのだが、思っていたほど問題は発生しなかった。というのも、プログラムを作るための例だけであればググればいくらでも出てくるので、それを参考にして(パクるところもそれなりにあるが)とにかく書いてみる。そしてエラーが出たらまたググる。それの繰り返し。トライアンドエラー。
自分の中では、プログラムのスキルを上げようとか思ってはおらず、むしろその前段階の企画設計のスキルが大事だと思っているので、とりあえずプログラムは書ければよし。むしろ思っていた企画からの設計フェーズがきちんとプログラムフェーズ以降に引き継がれ、問題が起こらないようになっていればよし、と考えていた。
ゆっくりですがプログラムの公開もしていきますよ。お楽しみに。
・・・とか言ってるうちにさらに新しい企画を思いついてしまった。来週にでも書こうかな。
・・・とか言ってるうちにさらに新しい企画を思いついてしまった。来週にでも書こうかな。
2015年1月13日火曜日
LINE Creators Market顛末 (その1:申請まで)
自分で仕事をするならかねがねやってみたい、と思っていたLINE Creators Marketでのスタンプ販売に手をつけてみた。
自分自身は絵を描くことが全くできないので、絵の描ける嫁と共同でやってみることに。
ちなみに、その嫁は手書きで絵を描くので、大まかな作業手順としては、
- 絵を描く
- スキャナで取り込みデジタル化
- レタッチソフトで着色や細部の修正
- 申請
という流れ。
レタッチには、Photoshopの廉価版にしては高機能と名高い「Pixelmator」を使用。
そもそもアナログ→デジタル変換をする時点でラスタデータ(ドットで構成された画像ね。線画:ベクターデータでなく)になることは問題なし。ベクター化する必要はない。・・・つまり、Illustratorとか使う理由は少なくとも我が家ではないわけだ。
機械的な作業は俺がやる。取り込んで切り取って、背景の透明化とか共通の色付け、はみ出た線の修正など。
その後、嫁にMacの席を譲り、細かい色付けや追加の描画など、作者ならではの手を加える作業。
最後に俺に戻り、画像ファイルの書き出しや申請手配など。
下絵を描き終わってから申請までおよそ1週間。
フリーで仕事をしているが、それでも他の作業の合間にやっていたりするので、下絵が終わってからの時間だけなら2〜3日もあれば作業が終わるのでは?
ちなみに、嫁に言わせれば、「絵を描くのが一番大変。産みの苦しみってヤツ」とのこと。あちこちで言われている、スタンプの絵の中にあるストーリーとか、そういうのを生み出すは確かに難しいのだろう。理系のアタマではとても思いつかないような奇抜なアイデアとかさ。
申請後の審査の顛末はまた別の機会に。
2015年1月12日月曜日
まだまだ書きかけ、作りかけ
『仕事のブログなんて何書くの?』
と、会社にいる頃にはどこの会社でも言われたものだ。
ブログによる情報発信が、会社のプレゼンスを上げ、より信頼を得ることができる、などと言われたりしているのだが、情報を発信することによるコンプライアンスやプライバシー・セキュリティなどの問題のほうが大切だ、と説得され、提案しても却下されることが多い。そして、最後に言われるのが上の一言。
書くことは決まってる。会社が取り組んでいることやちょっとした情報、たまには仕事から離れたお話をするのも当然アリ。もちろん会社における秘匿事項や顧客の情報などは上手に見え隠れするようにして。
だが、そういうことを考えるのは結構大変。だから会社として、と言うより情報を発信する立場として、そういう面倒なことを考えるくらいならやらない、というのが正直な所なんじゃないのかな、と思っていた。
そして、自分で仕事をするようになり、どうやって自分のプレゼンスを上げ、より信頼が得られるような方法はないものか、と考えると、当然ブログの開設にたどり着くのだが、ふとブログを作ってみると、
『仕事のブログなんて何書くの?』
という問題に突き当たってしまうのである(笑)
確かに面倒クサい。仕事と言ったところで大した仕事もしていない。業務内容なんて言われても、こんな感じでしかない。そりゃ書きにくいよねぇ、と自分自身で思う。
でもね。やらなきゃわからないことなんていっぱいあるのですよ。
何が正しいかわからないのに、最初から正解以外の方法を選んで排除できるわけもないし、可能性を排除して動けなくなるのも違うんじゃないの?と思う。
公開できるような情報は、作るしかない。仕事を作ることと同じ。というかそれも仕事だったりするのだからねぇ。
せめて、1週間に1回は新しい記事を作りたいかな。そして、明日までにもう一つ記事を書いてみようかな。という目標を立てつつ。
登録:
投稿 (Atom)