HMDT | HMDT Blog | ページ 8

カテゴリー : HMDT

薄いiMacが来た!


発表されて予約可能になってからすぐ購入した薄いiMacである「新しいiMac」。昨年末に出荷されたんだけど、仕事納めで受け取れなかったので、1月になってからようやくてもとに来た。

新しいマシンが来ると、いつの間にやら社員の人がゾロゾロと集まってきて、お披露目会となる。で、届いたブツを受け取ってみると、なんかいつもと違う。箱がななめってる。

これねぇ、箱が台形になってるんですよ。上の方が細くなっている。分かりにくい?じゃあ、2つ並べてみた。

おぉ、ぴったりだ!こうすることで、輸送時のスペースを節約しているんだな。いや、やってないと思うけど。

で、開封しました。じゃーん!

うーん、正面からじゃよく分からん。少し斜めから見ると、

おぉっ!薄いぜ!

もっと斜めから見よう。

こんだけ斜めでもまだ薄いぜ!

真横から見るとこんな感じ。

あー、こうやってみると、それなりに厚さあるね。しかし、前方から見たときの薄さ加減は、かなりの衝撃ものだ。

Retina MacBookと並べてみた。

いやぁ、遜色ない薄さだ。こうして、デスクトップとノートブックの差はなくなっていくのかもしれん。いや、そんなことはないけど。

新しいiMacは薄いだけかぁと思ってたけど、実際に目の当たりにすると、薄さは正義だった。

あけましておめでとうございます


あけましておめでとうございます。今年もよろしくお願いします。

とりあえず、今年の抱負でも述べてみましょうと思いますが、今年はですね、2013年はですね、えーっと、やることは去年とそんなに変わらないかな。粛々といろんなアプリを作り続けます。

一つだけ違うとしたら、今年はOS Xアプリケーションを作りたいなー、と思っております。実際そんな案件も舞い込んでおりますし。iOSだけだと、どうしてもソリューションとして未完成になるし。だからって、ブラウザ+サーバでやると、みったくないものになってしまうし。どう考えてもOS Xアプリケーションにするのが自然だろ、ってものが色々あるので、そんなやつらはOS Xでやります。いやー、久しぶりだな。

どうでもいいけど、iOSだとアプリで、OS Xだとアプリケーションっていいたくなるね。Appleのドキュメントでも、iOSの方はApp、OS Xの方はApplicationって書いてある事が多いような気がする。気のせいかも。

DropletさんとDropTalk HD


HMDTでは、DropTalkっていうアプリを開発してます。自閉症や言語障害を持つ方のコミュニケーションを助ける、AAC(補助代替コミュニケーション)っていうタイプのソフトウェアです。

これは、Droplet Projectっていうところから依頼を受けて開発しているんですが、先日ATAC2012というイベントがありまして、これは『「テクノロジー」と「コミュニケーション」をキーワードに,社会の中で困難さを抱える人たちを支援する技術と考え方を多くの人と共有する』ってものなんだそうですけど、そこで発表を行ったそうです。

で、ATAC2012は東京で開催されたので、Droplet Projectの方々が、HMDTのオフィスに遊びに来てくれました。Dropletの方々は、いつもは長野で活動しています。そのときの様子が、Droplet Blogで紹介されています。なんか、弊社オフィスとスタッフの写真も載っているし。

で、そこにチラッと書いてありますが、DropTalkのiPad版である、DropTalk HDを開発しています。というか、開発は佳境でもうほぼ出来上がっています。ATACでお披露目されたそうなので、そのときの反響をもとに最後の改善を行って、来年1月にリリース予定です。

iPhoneアプリ「音楽のある情景」が公開


HMDTで企画、開発したiPhoneアプリ、「音楽のある情景」が公開されました。無料です。App Storeへのリンクは、こちら。製品紹介ページは、こちら

「音楽のある情景」は、世界で流れている音楽を感じる事のできるアプリ。このアプリをインストールして、バックグラウンドで起動しておけば、標準のミュージックアプリで再生した曲情報を、どんどんサーバに送ってくれます。その情報は地図上に展開されて、いま世界で聴かれている音楽を、すぐに知る事ができます。

「いま売れている音楽」じゃなくて、「いま聴かれている音楽」ってとこがポイントです。売れている音楽はさ、iTunes Storeのダウンロードランキングとか、いろいろありますよね。でも、聴かれている音楽ってのは、きっと売れている音楽とはまた別だと思うんですよ。売上ランキングの遥か下に沈んでいる曲が、いま聴かれているかもしれない。遠い昔に発表された曲だけど、いまだに聴き続けている人がいるかもしれない。そんな、いま流れている曲を知る事のできるアプリです。

みんなが参加してくれるとどんどん面白くなるアプリなので、ぜひインストールしてみてください。起動したら、そのまま放っておいてくれればいいです。iPhoneでヘビーに音楽を聴いている人は、ぜひ。音楽の聴き方の、新しい楽しみ方につながればよいな、と思っております。

OS Xのお仕事は楽しみ


久しぶりに、OS X向けの開発のお仕事ができそう。嬉しいなったら、ランランラン。

やっぱりアレだよな!OS Xだと燃えるよな!iOSは、もちろん嫌いじゃないし、大好きだけど、なんつーか、画面が小さくて入力デバイスが限られているから(タッチインタフェース)、どうしてもシンプルになる、というと聞こえはいいけど、実際のところは低機能になるっていうか、どうしてもオモチャ感があるというか、App Store通すとなると好き勝手できないというか。なんか、言い訳が多い。

その点OS Xは、遠慮せずにできるってとこがいいね!CPUだってメモリだって、使いたい放題だし!思う存分高機能に振ってやっていいし!App Store通さなくとも配布できるし!あーこの、思いっきりブン回しても構わない、って感覚が嬉しいねぇ。

Amazonってやっぱりすごいね


いまさらながら、やっぱりAmazonってスゲーなー、と思った事。

nasneを買おうと思ったんですよ。もうすぐVitaにtorneが出るってんで、ようし、そろそろ用意しないとな、と思って。で、そうすると、うちの環境だと分波器を買わないといけないのかな。あと、たしか有線のLANもつながないといけないんだっけ。あー、そうなるとハブもいるのか。調べないといけないな、めんどくせーなー、と思ってたんですよ。

ま、とりあえずAmazonでnasne検索してみるか、と思って検索したら、「この商品を買った人はこんな商品も買っています」のところに、全部出てきてるじゃないすか。結局検索したのはnasneだけで、その他必要なものは、芋づる式にリンククリックするだけでそろっちゃった。これじゃあ、リアル店舗行かなくなるわな。

思った事。疑問に対する回答を得るには、実際に行動した人に聞くのがいちばん早い。「nasneを使うために何が必要なの?」よりも、「nasneを買った人は他に何を買ったの?」の方が、適切な質問なわけだ。

もう一つ。行動を記録するという事は、苦労が伴わないから、みんながやってくれる。ブログを書くのも、Facebookに書くのも、Twitterにつぶやくのも、文字を書くという苦労が伴うから、なかなかみんなやってくれないし、情報もたまらない。でも、買うという行動はそれ自体が目的だから、みんなやってくれる。そういうとこには情報が集まって、そこから強みが生まれる。

HMDT JOURNAL Vol.010配信開始


Vol.009から約5ヶ月、ようやくHMDT JOURNAL Vol.010の配信を開始しました。あまりに間が空いてしまったので、ひっそりといきます。

Vol. 010では、3つの記事を掲載。1本目は『iOS API探訪:第8回 Core Image(3) ブレンドモードフィルタ(続)』。Core Imageでのブレンドモードフィルタの続きだ。フィルタを紹介しているんだけど、今回取り上げるのはHard LightとかSoft LightとかDeifferenceとかExclusionとか。使い方によっては、派手というかサイケデリックな効果になりますぜ。

2本目は『Store Kitによるコンテンツのホスティング』。連載記事じゃなくて、単発記事になるよ。iOS 6から可能になった、Appleサーバへのコンテンツホスティング。その手順とコーディングを詳しく解説した。

ちなみに、HMDT BOOKSアプリでもコンテンツホスティングをやろうとしていろいろ試したんだけど、結局見送った。そのときの考察した結果が、この記事の結論部分に反映されてるよ。

3本目は『フォントとコードの話:第6回 UI Kitで属性付き文字列』。これもまたiOS 6で、UILabelとかUITextFieldで属性付き文字列が使えるようになった。その話を取り上げているぜ。

どうにか再開にこぎつけたので、これからもがんばって続けていきます。絶対毎週出す!とは、なかなか断言しづらいけど、がんばりますです、はい。

HMDT BOOKS 2.0登場〜iOS 6とiPhoneに対応


HMDTが送る電子書籍ストアアプリHMDT BOOKSですが、このたび2.0が登場!

2.0では、ようやくiOS 6に対応。遅くなってしまってご迷惑をかけました。ついでなので、iPad miniでも動作確認済み。HMDT JOURNALはiBooks Authorでオーサリングしているんで、iPad miniで表示させると、ジャストフィットだよ。miniは、ほんと電子書籍と相性がいいねぇ。

miniっぽさを強調するために、手と一緒に写真撮ってみた。

さらに、いままで要望の多かったiPhoneへの対応もやりました。画面が小さいのでちょっと読みにくいけど、ちゃんと読む事はできるよ。

あと、いままで出した全部のコンテンツを更新しました。すでに購入したユーザの方も、ライブラリ画面のボタンが「更新」になっているはず。これを押すと、第二版が手に入りますぜ。電子的なアップデートこそ、電子書籍の優位点だ。

その他にも細かい修正が色々とあるので、既存ユーザの方はアップデートを、もちろん新規ユーザの方もどうぞ。

え?HMDT JOURNALの続きはどうなっているかって?これも、中断してしまっていてすいません。最新号のVol.010は、近日登場します!本当は、HMDT BOOKS 2.0の登場と同時に出したかったんだけど、予想より速く審査が通ってしまったんで、後になってしまったです。とにかく、Vol.010ももう少しで出るので、あと少しだけお待ちを。

iPhone 5のディスプレイサイズ


その昔、最初のiPhoneが登場したときは、ガラケーのコンテンツ制作者に対して、「いやー、iPhoneアプリ作成は1モデルしかないから、楽勝っすよー」と、鼻高々だったわけですよ。iPhoneの新しいモデルがでても、画面解像度は同じだったから、「うんうん、分かってるよねー、Appleは」という感じだったんですよ。

iPadが出たときは、「うぐっ」となったけど、「まぁ、あれは別のデバイスだからね。1つのデバイスに凝り固まるのはよくないしぃ。これで、アプリの売上が倍になってくれれば…」といって対応したんですよ。ぜんぜん倍にならなかったけど。

Retinaディスプレイのときは、「ぐはぁっ」って感じだったけど、「さ、さすがApple!画像ファイル名に@2xを付けるだけでRetinaに対応してくれるなんて。わ、分かっているはずなんだよな?はぁはぁ」といってごまかしたんですよ。@2x付けるだけじゃ、ぜんぜん駄目だったけど。

そして、ついに来ました。もう、なんのいい訳もできないときが。iPhone 5の登場です。その解像度は、640×1136。なにそれ?!1136って、ねぇ、なあに!?いままでのものよりも、176ピクセル増えたって。176って何?

「ふ、解説しよう。176とはRetinaディスプレイでの値で、通常ディスプレイならば88ピクセル。これは、44ピクセルの2倍ということだ。44というのは、iPhoneの中では重要な意味を持つ値で、ユーザが指で操作可能な適切な大きさが、44ピクセルなのだ。ナビゲーションバーの高さなどはこの値になっている。その2倍の大きさだけ増やすとは、さすがApple、分かって…」

分かってねーよ!

ま16:9ってことなんだけど、ビデオ屋さんはいいにしても、整数値で割り切れてくれないとアプリ屋は困るんだよなー。

mergeChangesFromContextDidSaveNotification:って何のために?


先日は、MOSAでCore Dataセミナーをやってきました。参加された方々、お疲れさまでした。

で、そのとき質問があって、NSManagedObjectContextのmergeChangesFromContextDidSaveNotification:に関する事だったんだけど、そのとき「このメソッド、あんまりよく分からないんだよねー」と答えてしまいました。そしたら、アンケートで「このことが聞きたかったのに残念だ」という意味のことを書かれてしまったので、ちょっとこの場でフォローします。

まず、前提。状況としては、複数スレッドからCore Dataにアクセスしている。スレッド毎にmanaged object contextを作成し、同一のpersistent store coordinatorを使う。

まず、サブスレッドを立てて、managed objectを追加したとする。そうすると、そのスレッドのmanaged object contextでは、追加される。でもこの追加は、メインスレッドのmanaged object contextからは検知されない。どうもオブジェクトの追加は、managed object contextレベルで行われているらしい。サブスレッドが終了すると、この追加もそのまま消えてしまう。

そこで、サブスレッドでオブジェクトを追加した後、保存を行う。そうすると、追加されたオブジェクトがデータベースに保存される。データベースに保存されるので、永続化される。この変更は、メインスレッドのmanaged object contextからも知る事ができる。保存後にフェッチすれば、追加されたオブジェクトを取得できる。

で、保存すると、NSManagedObjectContextDidSaveNotificationが通知される。それを捕まえて、Appleのドキュメントによれば、managed object contextのmergeChangesFromContextDidSaveNotification:を呼んでやれば、変更がマージされる、ということになっている。でもねー、保存した時点でデータベースに変更が反映されているんだから、マージする必要あんの?ってのが疑問としてあった。だから、「Appleのドキュメントに、このメソッドを呼べって書いてあるから呼ぶけどさー、これ別に呼ばなくても構わないんじゃないの?なんのためにやるのか、よく分かんないんだよねー」って思ってた。

そのときの質問は、mergeChangesFromContextDidSaveNotification:はメインスレッドで呼ぶ事になっているけど、そのときに時間がかかったりしないか、パフォーマンスは大丈夫か、というものだったんだけど、基本的には重い処理は保存のところなので、それは別スレッドで呼ばれるから大丈夫だと思う。

この、mergeChangesFromContextDidSaveNotification:を呼んだときの、別managed object contextのオブジェクトのマージって、どんなことが行われるんだろか。いまメモリ上に保持しているmanaged objctに限ってマージされる、ってことなのかな。であれば、リフェッチすれば、そもそも気にしなくていいのかな。