放置アプリは注意が必要。3月18日から古いAdMob SDKのリクエストが無効になるもよう

今日ふとAdMobの管理画面にログインしたらこんな表示が。

Starting March 18, 2013, we will no longer support ad requests made through AdMob SDKs released before 2011. Please upgrade to the latest version of the AdMob SDK here.

2013年3月18日から2011年より前にリリースされたAdMob SDKからのリクエストはサポートされなくなります。最新版のAdMob SDKにアップグレードしてください。

だそうです。

これは放置アプリへの死の宣告ですね。
僕のアプリはというと、オープンソースというのを言い訳にずっと放置してる Edhita のリリースが2010年10月だったので、”before 2011″が「以前」だろうが「より前」を意味してようが、がっつり対象のようです。（たぶん「より前」？）

urgent SDK update required

早急なSDKのアップデートが必要

よく見ると警告されてましたorz

ずっと放置しちゃってるので当然雀の涙ほどの収益しかなく、非公開にしちゃってもいいんですが、未だにダウンロードしてくれたり、アップデートの要望をくれたりする方がいるため、ちょっとどうしようか迷い中です。（最大のネックはFTPなんてものをサポートしちゃったこと。面倒くせぇ^^）

真面目にやるにしても、iOSアプリはApple時間で時が進むので、3月18日までって結構きつかったりするんだよなぁ。

NSTableView * NSArrayController && !CoreData

今まで、NSTableViewとNSArrrayControllerを使うときは、CoreDataと一緒にしか使ったことがなかった。
ただ、そんないつもCoreDataが必要ということはないので、勉強もかねてPlainなオブジェクトと一緒に使ってみる。

参考：Takeba.me: ビュー・ベースのNSTableViewをさわってみたよ
※ 記事の本題とは違いますが、CoreDataを使わないサンプルとして参考になりました
なお、サンプルコードのリポジトリがこっちに変わっているようでした。
takebayashi/ViewBasedTableSample · GitHub

下準備

  1. プロジェクト作成
  2. 「MainMenu.xib」を開く
  3. Windowに「NSTableView」を追加。「Columns」を1にしておく
  4. Objectsに「NSArrayController」を追加。「arrayController」としてAppDelegateにOutlet接続

NSTableColumnとNSArrayControllerをBind

  1. ValueのBind toを「Array Controller」に
  2. Model Key Pathを「name」に

Modelオブジェクトの作成

  1. NSObjectを継承したクラスを作成
  2. Publicな「name」プロパティを追加

ArrayControllerにデータをセット

applicationDidFinishLaunching:で以下のようにarrayControllerにデータを設定。

これでTableViewに30件のデータが表示される。

ArrayControllerが面倒を見てくれるので、DataSourceの設定はいらない。
絞り込みとかも簡単にできる。

例えば、NSSearchFieldを使う場合、

  1. Windowに「NSSearchField」を追加
  2. SearchのBind toを「Array Controller」に
  3. Predicate Formatに「name contains $value」を指定

とするだけで、インクリメンタル検索ができるようになる。

うん、シンプルでいい感じ。
ちょっとは理解できてきたかなぁ。

あ、プロジェクトは一応こちらに置いてます。
tnantoka/ArrayControllerPractice · GitHub

それでは。

Macアプリから内蔵辞書を引きたい

自分用のツールを作ろうとして英和辞典を検索したいニーズがあったのでメモ。
ニーズはたくさんありそうなのに思ったより日本語情報が少なかったです。（なぜかPythonの情報の方が多かった…）

Control + Command + d でいいじゃんという突っ込みはなしの方向で。

 

方法1：辞書.appで表示

辞書.appには「dict://」というカスタムURIスキームが用意されているようなので、

とかやれば、検索できます。
辞書の指定とか細かい制御はできなさそうです。

参考：Mac OS X Lionで内蔵辞書を引く #Mac #dictionary – Qiita

 

方法2：アプリ内で表示

こちらが本命。
Dictionary Services Reference によると DCSCopyTextDefinition を使えばできそうです。

という感じでできました。
__bridgeのせいで見づらいですが、意外と簡単でした。

冒頭の宣言と辞書の指定は、OS Xの辞書アプリをコマンドラインから – PC日記 を参考にさせていただきました。（辞書指定しないと英語の辞書が使われてしまいました）
この部分がUndocumentedなので、Mac App Storeの審査に通るかはグレーです。

HIDictionaryWindowShow を使えばControl + Command + dのようなポップアップ表示もできるようです。
参考：日暮れて道遠し: PDFkit（その５）辞書.appで辞書を引く（その３）

 

サンプル

上記2つの方法を試せる簡単なサンプルを作ってみました。左のTextViewで文字列を選択すると、ポップアップで選択されている方法（OpenURL or DCSCopyTextDefinition）で辞書を検索します。DCSCopyTextDefinitionの場合は右のTextViewに結果が表示されます。

こんな感じです。

ソースはGithubに置いておくのでご自由にどうぞです。
tnantoka/DictionaryServicesExample · GitHub

しかし、Macアプリ作成は全然上達してる気がしないなぁ…。 もっと頑張ろうっと。

それでは;-)

KindleでTideSDKの入門本を出版してみた話

昨年末、TideSDKの最新版が出ていることを知って、試しに単純なMarkdownエディタを作ってみたら、思ったよりハマらず作れました。

で、いつもなら「Hello, TideSDK! Markdownエディタを作ってみた」みたいなエントリを書いて済ませるんだけど、なんかワンパターンで飽きたし、どうせ無料でやってもdisられるポイズンな世の中だし、どうしようかなぁと考えてたら、Kindleさんの存在を思い出した。

というわけで、TideSDKについて知り得た情報をまとめたものを、AmazonのKindle ダイレクト・パブリッシング (KDP) で出版してみました。

こちらです。


TideSDKでつくる！Macデスクトップアプリ（v1.3.1-beta対応）

価格は、ロイヤリティ70%オプションを選択した場合の最低価格（ドル）です。
※ Kindleストアはほんとに1クリックで買えてしまうのでご注意ください。

ストアの説明にもある通り、クオリティはこのブログ上の記事と同等のレベル、ということであまり期待しないでください。それでもなお興味があるという方はお手…じゃないな、ご端末にとってみていただければと思います。

超ニッチな内容のため売れて10冊ぐらいと見込んでいます。作業時間を考えると完全に赤字ですが、万が一利益が出た場合は、一部をTideSDKのプロジェクトに寄付する予定です。（大企業がたくさんスポンサーについてるので、端金かもしれませんが…。）

ちなみに以下がiPadでとったキャプチャですが、実際に端末で見れるのを確認すると、不覚にもちょっと感動してしまいました^^

以下、やってみた感想とか。
思いつくままに書いてたら長くなってしまいました、すみません。
KDPで出版しようと思ってる人には、もしかしたら参考になるかもしれません。

ePub作成はsigilが無難だと思う

KDPではHTMLやdoc(x)ファイルもサポートしていますが、一番無難そうだったePubを選択しました。

PagesがePubを吐けるという情報を得たので、はじめはその方法でやってみました。
（何も考えずにWordで書き始めちゃったので、それをPagesに読ませてePub出力）

確かにそれなりに見た目も整えてくれるし、Kindle Previewerでも特に問題なく閲覧できるようでした。しかし、ソースコードなどを見やすくするためには、出力されるXHTMLを修正する必要が出てきます。で、Pagesはどんなタグを吐くかというと、

のように、変なspanや空白のpがあったり、急にstyle属性使ってみたりとか、調整するにはしんどそうな感じです。

かといって、1から全部自分で書くのはもっとしんどい、ということでsigilの登場です。

ごく普通のWYSIWYGエディタの感覚で書いていけば、段落はp、見出しはh1〜6、リストはul/olと、素直なマークアップを出力してくれます。preとかblockquoteは自分で書きました。classやstyleは特につきません。見た目はCSSで整えましょう。

sigilで困りそうなところ

僕がつまったところを列挙しておきます。

  • 表紙の設定
    Imagesを右クリックして、「Add Existing Files…」から画像を追加。
    追加した画像を右クリックして、「Add Semantics」→「Cover Image」をチェック。 
  • 論理目次の作成
    端末の移動機能などで使われる目次。
    メニューバーの「Tools」→「Table Of Contents」→「Generate Table Of Contents…」から作成できる。 
  • HTML目次の作成
    ページとして表示される目次。
    メニューバーの「Tools」→「Table Of Contents」→「Create HTML Table Of Contents」から作成できる。
    CSSの読み込みなどの修正は最後にやるのが無難。（途中で目次が変更になった場合やり直しになるので）
  • 改ページ
    <mbp:pagebreak/>というタグでできるらしいけど、sigilがそんなの知らないということで消してしまう。（xmlnsを書いてもダメだった。）
    代わりに、CSSでpage-break-after: always;を指定すると、その要素の後ろで改ページしてくれる。
    HTMLが別ファイルになれば、そこでも改ページされる。
  • 落ちる
    0.6.2はダメだったので、Downloadsから0.6.1を入れて使ったら、落ちることはなくなりました。（僕の環境はOS X Lionです。）
  • 選択範囲がおかしくなる
    なります。我慢です。
    プログラミングの本に関しては、フォーマットも凝る必要はないし、見出し・本文・コード・画像・引用と、必要なパターンも決まってるので、良い感じのオーサリングツールが出てくるんじゃないかと思います。それまでの辛抱です。

Kindle Previewerに注意

ePubをKindleで使われるmobi形式に変換、エミュレータで表示までしてくれるありがたいツール、それがKindle Previewerです。Amazon.co.jp:Kindle ダイレクト・パブリッシング:ヘルプ からダウンロードできます。（日本での名称はKindleプレビューツール）
※ 変換は同梱されているKindleGenが行います。というわけで、コマンドラインでやりたい人以外はKindleGen単体のダウンロードは不要です。

僕の使ったVersion: 2.751は、font-family: monospace;を解釈してくれなかったり、KDPのサイトで提出時に変換されるファイルとfont-sizeが違ったり…と結構くせがありました。
あと、TideSDK/TideSDK · GitHubとかで使われている「·」が文字化けしてaになりました。これはPreviewerの問題ではなく、実機でもなるのかもしれません。

そしてコンパイルにそれなりに時間がかかるので、修正・確認のサイクルがげんなりしてきます。

と、いろいろ書きましたが、いちいち実機に転送することを思えばはるかに楽ができるので、これなしではやってられません。今後のさらなる進化に期待します。

提出から出版までの時間

1/14の18時に提出して、翌日1/15の16時45分に出版されました。
Appleのレビュー速度と比較すると半端ない早さです。

ただ、出版されましたメール内のリンクが.comのサイトになってたり、KDPのサイトから書籍のページに飛ぶ方法がよくわからなかったり（未だにわからない。Kindleストアを検索する方がはやい。）、まだ荒削りですw

税金の手続きがめんどい

書類を出さないとアメリカで源泉徴収されるので二重課税になります。（昔のApp Storeと同様の手続きが必要。僕はまだやってません。Web上で完結するようにならないかなぁ。）

手続方法（不備があるらしいので、実際にやる前に他のサイトも参照することをお勧めします。）
Amazon.co.jp:Kindle ダイレクト・パブリッシング:ヘルプ

本を書くのは勉強にいいかも

ブログの記事なら、「〜についてはよくわかりませんでした^^」ですませるところですが、「あかん、もっと調べないと」という思いが襲ってきます。

例えば今回、App Storeへの提出は現状難しい、というデメリットを書いたんですが、難しいって書くからにはそれなりに裏を取らないと…ってなりました。

それでも間違ってたらごめんなさい。

広告モデルの本もあっていいんじゃないか

最後の最後、これは売るほどのものなのか…？という激しい葛藤がやってきました。

僕みたいなチキンな著者向けに、広告とか、あとから課金とか、読者が値段を決めれるとか、そういう電子書籍ならではの売り方ができてもいいんじゃないかと思いました。

Kindleが変えたのは出版であって執筆じゃないよ

確かに、コネもなにもない矮小な僕でもAmazonに本を並べられるようになりましたが、書く作業自体は何も楽になってません。むしろ手続きとか校正とか自分でやらなきゃいけないので、手間が増えているのかも知れません。

というわけで、「2〜3時間とかそんなんでできるわけじゃないよ」と、年始に軽い気持ちで始めた過去の自分に突っ込みを入れたいです。

“コード”より、“コンテンツ”を生み出す

いきなりまじめになりますが、今年というかこれからの僕の個人活動について。

皆さんは、以下の記事を読まれたでしょうか？
日米で半年ニートをするまで気付かなかった、「お金・理念・コード」より大切なこと【連載:上杉周作⑤】 – エンジニアtype

僕は以下の部分にとても衝撃を受けて、未だに頭のなかで鐘が鳴り響いている感じです。

エンジニアにとって、「コードを書くか、もしくは記事やスライドなどのコンテンツを作るか」は永遠の二択問題だ。

中略

1. 自分に影響を与えたエンジニアを何人か思い浮かべる。
2. どのようにして自分がその人から影響を受けたかを考える。
3. その人の素晴らしいコードに影響されたならコードを書く。反対に、その人の素晴らしいコンテンツに影響されたならコンテンツを作ればいい。

この二択は確かに僕の中にもあって、その時々の気分でコードを書いたり、入門記事を書いてみたりしてたんですが、この解決方法の発想はなかったなぁ、と。
これの基準で考えると、完全に僕はコンテンツを作るべき。
Encode.pmのコードは読んだことはないけど、404 Blog Not Foundは大好きだ。Matzさん、結城浩さん、amachangさん…影響を受けた人はたくさんいるけど、彼らの書くコードより文章から受けた影響の方が大きい。

というわけで、しばらくはものを作るためにコードを書く作業より、コンテンツを作るためにコードを書く作業を優先しようと思っています。

勢い余ってブログのタイトルもKindle JUNEとかにしようと思ったけど、そんなダジャレはもう誰かが言ってそうだし、Amazonアソシエイトから怒られそうな気がしたのでやめました。

そんなこんなで、いつもどおりグダグダですが、本年もよろしくお願いいたしますm(_ _)m

1 … 9 10 11 12 13 … 27  Scroll to top