HMDT Blog | ページ 8

『大辞泉』3.0リリース時に問題発生、現在3.0.1を申請中


daijisen_icon

大辞泉の最新バージョン3.0リリース時に問題が発見されました。現在、一時的にApp Storeから削除している状態になっています。ただいま3.0.1を申請しておりますので、ご迷惑をおかけしますがいましばらくお待ちください。

iOS 8対応大辞泉準備完了


ご無沙汰しております。しばらく音沙汰なしだったのは、手持ちのアプリのiOS 8対応を進めていたり、新規プロジェクトを進めていたりしたためです。忙しくなると、どうしてもこちらが更新できなくなっちゃいます。

そうこうしているうちに、iOS 8とiPhone 6が登場しておりました。まだiPhone 6予約すらしてないんですよね。6にするかPlusにするか迷ってますので、とりあえず両方買おうと思っています。

大辞泉アプリなのですが、iOS 8公開にあわせてのリリースを目指して開発を続けていましたが、申請にとまどって残念ながら間にあいませんでした。残念です。申し訳ないです。Extensionはarm64必須だなんて、申請するまで見落としていたよ。だってarmv7sでも開発では動いていたもん。

現状のバージョンである大辞泉2.1は、iOS 8でもとりあえず動きます。そして、iOS 8の新機能に対応し、iPhone 6のRetina HDにも対応した、大辞泉3.0が準備できています。App Storeの申請通すだけです。近日中に出るはずなので、少しだけお待ちください。

とりあえずスクリーンショットを紹介しておきます。見た目を変えてきました。

daijisen3

 

アニメーションエフェクトも追加しています。これがヌルヌル動きますよ。

新機能もざっと紹介しておきますと、

  • アクション機能拡張に対応して、Safariから大辞泉で検索可能
  • キーボード機能拡張に対応して、手書き認識キーボードが他のアプリからも使用可能
  • ユーザインタフェースを改善、アニメーションエフェクト追加
  • Retina HD対応
  • 画像画面でサムネイルの大きさが調整可能、一画面で数百の画像が確認可能
  • 新語追加
  • その他パフォーマンス改善

といったところです。もう少しだけ待ってください。早く申請通りますように!

 

 

Swiftについて最初に思ったこと


swift-hero

WWDC 2014において、電撃的に発表された新言語Swift。その瞬間、Twitterの開発者TL上では爆笑が巻き起こった。まったく予想してなかったよ、うひー。

Swiftに関しては早速、言語仕様が公開(iBooks Store)されたりしている。それらはこれからすべてしゃぶりつくすとして、とりあえず基調講演が終わった時点での感想とかを書いてみたい。

Swiftのコンセプトは「Objective-C without the C」。Cベースではないモダンな言語である。その上で、CocoaとObjective-C runtimeを使うので、フレームワークのサポートも問題ない。ここだけ聞けば、夢のような話だよね。

Swiftの特徴として上げられていたのは、Modern、Safe、Interactive、Fast。これらを検証してみよう。

swift0

「Modern」に関しては、文法がモダンになった。これは言語仕様を見てもらえば明らか。昨今のトレンドを十分に取り入れたものになっている。Genericまであっててんこ盛り気味。Objective-Cにない仕様として紹介されたのが、名前空間(笑。聴衆は喝采。いかにObjective-Cが古臭かったかという例だな。

swift2

「Safe」は、変数が初期化される、配列のインデックスがチェックされる、ARCによってメモリが管理される、ポインタがない、と言ったとこだろう。初心者にとってはありがたいところだ。熟練者は、ほぼオートマティックにこれらは対処しているので、あぁ言語仕様レベルでサポートされるのね、というもの。

swift3

「Interactive」は、Playgroundと呼ばれる新しい実行環境を指す。基調講演のデモでも印象的だった、グラフを表示したり、アニメーションを動かしたりしていたものだ。確かにデモとしては見栄えがいい。でも、開発ワークフローを考えると、使うシチュエーションがあるかどうかは疑問だ。

swift5

で「Fast」なんだけど、これが悩ましい。普通に考えれば、C言語ベースからスクリプトになったら、実行速度は遅くなる。でもSwiftは、PythonやObjective-Cより速くなったと主張している。

swift1

まず考えられるのは、Swiftは純然たるスクリプトというよりは、コンパイルする言語であること。ビルド時か実行時か知らないが、ネイティブコードに変換する。これでPythonなんぞよりはバカっ速になる。

しかし、Objective-Cより速いとはどういうことか?基調講演では、ソート処理がObjective-Cより速いと主張していた。ソートはアルゴリズムが固まっているので、純然たる実行速度の差だ。Objective-Cのボトルネックとしてまず考えられるのは、メソッド呼び出し。objc_msgSendだ。Swiftはこれを使わないで、もっと効率的なメソッド呼び出しをやっているのでは?たとえば動的束縛をやめたとか?そうだったら、Objective-CではなくSwiftを使う積極的な理由が出てくる。

ソートのグラフでは、「Complex object sort」とある。つまり、複雑なオブジェクトで、比較するときにメソッドをいくつか呼び出す必要があるのかもしれない。だからObjective-Cでは遅くなってSwiftでは速くなるんだよ…というシナリオなら、納得できる。(Complexが複素数ってことはないよな?)

あと、既存のObjective-Cコードと混在もできるらしい。こちらで詳しく解説されている。これは朗報。

 

swift4

つまり、モダンな言語で、いまあるフレームワークをサポートできて、過去の資産も引き継げる。結論としては、乗り換えを検討する価値はある。もしかすると、絶対に乗り換えるべきかもしれない。では調査に入ります〜。

Eclipseに対する不満のいくつかの解消


昨日の記事「Xcode使いがEclipseにぶちまける10の不満」に対して、コメントやTwitterなどで色々教えていただきました。また、hd 4.0さんはエントリも書いていただきました。ありがとうございました。これで、いくつかの不満は解消されました。

「1. メソッドの一覧表示および絞り込み検索」について

MacではCmd + Oでポップアップが表示される、と。これだよ!これが使いたかったんだよ!

eclipse_popup

テキストフィールドに入力する事で絞り込みもできる。これは前方一致のみなのかな。部分一致だったらもっと好みだったんだけど。

「2. 補完入力」について

Ctrl + Spaceでいつでも補完入力できるよ、と。これはさすがに、検索したらいろいろでてきました。Mac環境では、Spotlightのショートカットとぶつかるので、気をつけろと。

「4. シミュレータ」について

スナップショットを活用しろ、またはGenymotionを使え、と。まだ試してないですが、やってみようと思います。やっぱりみんな、純正のものは遅いと思ってたんですよね。あー、よかった。

「5. Subversionとの統合」について

Subversiveプラグインをインストールしろ、と。これもまだ試していないですが、やってみようと思います。

「6. エディタの2画面表示」について

エディタのタブをドラッグすることで分割表示ができる、と。なるほど。

eclipse_divide

単純にエディタを並べるだけで、特に連携とかはしないってことですね。まぁ、並べるだけでも使い手はあります。

Android Studioを使え

もうEclipseは古くて今後はAndroid Studioになるからそっちを使え、と。そうなんですね。developer.android.comに行って、Developer ToolsのDownloadでいちばん目立つものをクリックしていったら、Android Developer ToolsとEclipseがインストールされたので、これかと思ってました。次のプロジェクト作るときは、Android Studioを使ってみようと思います。またいくつかの不満が解消されますように。

7、8、9は?

「7. インスペクタ」「8. 操作をアニメーションで確認する」「9. スタックトレースを見やすく表示する」に関しては、反応がなかったですね。そもそも、これらは不満に思っていない、ってことなんですかね?

なんとなく、どう言われるかは予想できるんですよ。インスペクタに関しては、layoutファイルなんかは直接XMLを編集するから、別に凝ったプロパティ画面はいらない。操作のアニメーションでの確認は、一度動きを理解できれば必要ない。スタックトレースは、見れているんだから問題ない。

ただね。私が個人的に、Eclipseに対してどうしても我慢できないのは、この点なんですよ。色々挙げた不満のうち、メソッドの絞り込み検索や、補完入力などに関しては、機能としてないわきゃないんですよ。単に私の調べ方が悪いだけで、あるに決まってんですよ、機能は。

「機能(Feature)」と「見た目(Appearance)」

何が言いたいかっていうと、ソースコードを編集するエディタとしての「機能(Feature)」は十分にある。機能の数だけ数えたら、XcodeよりEclipseの方が上でしょう。でも、編集内容や結果の「見せ方(Appearance)」に関しては、ぜんぜんなっちゃいない。というか、より良い見せ方を考える事を放棄しようとしているんじゃないかと。むしろ、そんなこと考えるのは恥である、とすら考えているのではないかと。開発環境なんだから、素早くコードを編集できればそれでいいじゃないかと。

それに対してXcodeは、バージョンアップするたびに派手なユーザインタフェースを導入して、おいおい開発環境のくせにここまで凝っていいのかよ、って思わせるんですよ。でも、それが「使い物」になるんですよ。Inteface Builderでのレイアウト、Core Dataモデリング、Subversionのdiff表示、XcodeではないですがInstrumentsのプロファイリングなんかを使ってプログラミングすると、冗談抜きで素のテキストエディタのみでやるよりも50倍くらい速いんですよ。

Eclipseはほぼテキストエディタのみだし、レイアウトのGraphical Layout編集は、まぁ正直に言ってお粗末なものです。コマンドラインアプリ作るならいいけど、スマートフォンアプリをこれで作るのかぁ、と思うとげんなりします。8割くらいユーザインタフェース関連のコーディングでしょ。Android Studioだとましになっているのかな。

完成品とガレージキット

Twitterであった反応の中で、

これは今の私の気持ちにピッタリくる、と思ったのはこのつぶやきでした。

Xcodeは塗装完成品で、Eclipseはガレージキットである、と。つまり、Eclipseはそのまま使うものではなく、プラグインをどんどん導入して自分なりの環境を構築していくところに価値がある、ということなんでしょう。これはLinuxの文化ですよね。Android開発も、その気質を受け継ぐところがあるかな?

私の個人的な気持ちは、プラグイン拡張を前提とした場合、足りない機能をその都度補えるのは確かに良い面と言えるでしょう。だけど、ほとんどの場合、それは一貫性、使いやすさ、美しさを損なうものです。それが、構造的に宿命的に、いらつかせるのです。

良い悪いではなく、好き嫌いで言えば、モノリシックな美しさの方が好きだよ、私は。

Xcode使いがEclipseにぶちまける10の不満


最近Android開発をやらされてます。「やらされている」というのは、特定の案件のためというより、時流としてもういい加減無視できないので会社の方針としてやることにした、でも非常に嫌々な気分満載、というニュアンスを含んでいます。

私も大人になりましたし、仕事ですから、Android端末を手にとっても、それを7階のオフィスから投げ捨てるようなことはなくなりました。ニッコリ笑って操作しますが、左上に戻るボタンが見つからない瞬間に、床に叩き付けてしまいます。ハードウェアボタンかよ、くそっ。あーもう正直にいいますが、嫌いっすよAndroid。iPhoneラブですよ。

当方生粋のMacユーザなので、ものの見方にバイアスがかかっていることは自覚しています。いまのAppleからは想像もできませんが、Macを昔から使っている人は虐げられていた期間が長いので、ひねくれてねじまがっているんですよ。その世界観では、悪の帝国Googleに立ち向かうジェダイの騎士Appleです。iPhoneを携えてAndroidを駆逐しなくては!という義憤にかられます。ですが、最近のAppleのビッグプレイヤーぶりを見ると、隔世の感というか、自分がジジイの繰り言になっているのがよく分かります。Appleはもう俺たちなんか必要としていないんだ。しゃーねーなー、Android開発もやるか。ちなみに、Microsoftはすでに滅んだ過去の帝国です。

で、Android開発をやると、最初に立ちはだかる壁がEclipseですよ。開発環境。当方OS XおよびiOS開発を生業としていますので、開発環境はXcodeこれ一本。前身であるProject Builderから使い続けていますよ。毎日12時間は使い続けているXcodeは、もう自分にとって体の一部です。

そんな私がEclipseを使いました。もうね、言っちゃいますけどね、ホントの気持ち言っちゃいますけどね、最悪ですよこれ。起動からクラッシュするまで、最悪の気分ですよ。まずアイコン、ださっ。起動、遅っ。画面表示、無駄っ。ツールバー、汚っ。エディタ、重っ。プロジェクト管理、訳分からん。ガベージコレクションの最中にクラッシュ、バカじゃねーの。

いや、知ってます。知っているんです。Eclipseを使い続けてきた人がXcodeを使ったら、これとまったく同じ感想を抱くことを。EmacsやVisual Studioを使っている人がXcodeに抱く感想も、同じことを。みんな、自分が慣れ親しんでいる環境が一番なんです。「使いやすさ」に対する絶対的な尺度はないんです。「慣れ」が最も大事なんです。開発者が、他の環境にあわせるのは、並大抵のことではないんです。

あれですね。開発環境を移すということは、ある意味海外に移住することに似ていますね。言葉が違う。習慣が違う。文化が違う。何をやるにもストレスフルです。でもそれは、別の視点を獲得することでもあります。違いを認め、新たな考え方を習得することで、より豊かな生活を送れるようになります。

よーし。Eclipseを使うという事は、異文化への挑戦である。ここはひとつ、腹を据えて触ってやろうじゃないか!………(触っている)………(触っている)………(触っている)。分からーーーん!ぜんぜん思い通りに動かないーーー!海外で迷子になったけど、看板も読めないし、誰にも話しかけられない気分だーーー!

なぜこんなにイライラするのか?それは「この操作はXcodeだったらこうするのに、Eclipseだとやり方が分かんない、または結果が期待と違う」からです。だから、やり方が分かればいいんだけど、マニュアルもドキュメントも量だけ膨大で、そのくせ大したこと書いていなくて、もう何をどう探せばいいのか分からんちんです。

そこで!Eclipseの操作で何が分からないのか、または気に食わないのか、まとめてみました。Xcodeをずっと使っていた人が、Eclipseのここでつまずいているよ、というのをまとめてみました。でもこれって、とても基本的な操作ばっかりなので、たぶんEclipseでもできると思います。ってか、できてくれよ。なので、これを読んで解決方法が分かる人がいたら、「こうすればいいんだよ、愚か者め」と教えてください。

1. メソッドの一覧表示および絞り込み検索

エディタでソースコードを編集するとき、そのクラスに含まれるメソッドの一覧を素早く表示、かつ絞り込み検索もしたい。

Xcode

エディタの上部にあるポップアップメニューをクリックすることで表示できます。

xcode_popup1

表示順は、ソースコードに書かれた順です。ポップアップを表示した状態でキーボードから文字を入力すると、絞り込み検索ができます。

xcode_popup2

絞り込みは、前方一致ではなく部分一致です。だから、メソッドの名前の一部を覚えていればオッケー。つまり「あのメソッドの編集したいな、えーっと名前なんだっけ、viewが含まれていたっけ」といううろ覚えな感じでも、素早く検索および移動ができます。

また、#pragma markを使う事で、メニューの中に区切り線や特別な文字を追加できます。上の図における”View Life cycle”とかですね。これにより、自前でメソッドをカテゴリに分けて管理できます。

Eclipse

Eclipseでのメソッド一覧表示は、これかな?Outlineの表示。

eclipse_outline0

一覧表示はありました。メソッドだけじゃなくて、スタティック変数なんかも出てくるところはXcodeより機能は上ですね。絞り込み検索を行うのは、Filtersでしょうか?

eclipse_filters

Fitersの画面で、キャラクターマッチングが行えます。でもこれ、「パターンにマッチした名前を隠す」なのね。なんで?マッチしたものを表示するなら分かるけど、なんで隠すの?どんなシチュエーションでこれ有用なの?結局、絞り込み検索はできないの?

2. 補完入力

クラス名、メソッド名やキーワードを補完入力したい。私は、補完入力肯定派です。

Xcode

あるメソッドの中で、次のコードを入力してみます。

self = [super initWithNibName:nibName bundle:nil];

まず、’s’を入力しまう。すると、’self’を補完するための候補がポップアップで表示されます。selfが出てこないときは’se’まで入力します。

xcode_comp5

そこでselfを選択して、タブキー(またはエンター)をヒット。文字列が補完されるので、続いて’ = [su’までを入力します。すると’super’を補完するための候補が表示されます。

xcode_comp1

タブキーをヒット。文字列が補完されます。続いて、’ i’を入力。iで始まるメソッドの候補が表示さます。

xcode_comp2

‘in’まで入力すると、絞り込まれる。ここでわざと、’initWithCoder:’を選択。タブキーを押します。

間違えたので、’initWith’まで削除してエスケープキーを押します。または、’initWit’まで削除して’h’を入力します。すると再び、候補が表示されます。

xcode_comp3

今度はinitWithNibName:bundle:を選択。最後に引数を入力して完了。このときローカル変数であるnibNameや、defineであるnilも補完されます。

まとめると、selfやsuperといったキーワードが補完されます。メソッド名が補完されます。一度削除して、再度入力するときも補完されます。あと、インスタンス変数やローカル変数も補完されます。

Eclipse

あるメソッドの中で、次のコードを入力してみます。

super.onCreate(savedInstanceState);

まず、’s’を入力します。何も補完されません。なんで?キーワードは補完されないの?どっかで設定する必要があるの?しょうがないので、’super’まで入力します。そして’.’を入力します。メソッド名を補完するための候補がポップアップで表示されます。

eclipse_comp

ここで’onCreate()を選択してエンターを押します。すると、’onCreate(savedInstanceState);’まで入力されます。これで終わり。ふむ、素晴らしい。

でも、ちょっと変更したいと思って、メソッド名を’onCrea’まで削除します。このとき、どうやっても補完ポップアップが表示されません。なんで?エスケープキーを押すとかして、この状態から候補を表示できないの?しょうがないからメソッド名を全部削除して、再び’.’を入力すると候補が表示されます。つまり、一度間違えると全部消さないといけないのか。

また、引数の’savedInstanceState’は自動入力されましたが、これも一度削除して、もう一度’s’と入力しても補完候補は表示されません。なんで?ローカル変数は補完の候補にならないの?

まとめると、superというキーワードが補完されません。クラスの後にドットを入力すると補完候補が表示されますが、候補を一度決定すると途中から補完させる事はできません(もう一度ドットの入力からやりなおす)。インスタンス変数やローカル変数は補完されません。

Xcodeは、クラス名、メソッド名、インスタンス変数名は、宣言のときにただ一度書くだけで、あとはフルに入力する事は無いです。だって補完されるから。したがって、Xcodeではシンタックスエラーはありえない。だって補完されるから。一度入力したメソッドを変更したいときも、一部を削除するだけで、またすぐ補完候補が表示されます。

Eclipseも補完はされるんだけど、一度間違えると修正するには全部消してもう一度ドットの入力からやり直さないといけない。これがとってもストレス。

3. APIドキュメント

各種フレームワークのAPIドキュメントを表示したい。そして、クラス名やメソッド名で検索したい。

Xcode

Helpメニューから「Documentation and API Reference」を選択します。専用のツールが表示されます。検索バーにクラス名、メソッド名、変数名などを入力します。インクリメンタルサーチされます。

xcode_apiref

選択すればその項目が表示されます。こんだけ。疑問の余地無く単純です。

Eclipse

Eclipseにはドキュメントをブラウズするためのツールが、、、ない!?ないの?ないこたないと思うんだけど、見つからないよ。

しょうがないので、Webブラウザを使います。Webブラウザを起動して、http://developer.android.com/reference/を開きます。パッケージ一覧が出てきます。右上の検索フィールドから、クラス名が検索できます。インクリメートサーチできます。

eclipse_apiref

クラス名は検索できるんだけど、メソッド名は?メソッド名での検索の仕方が分からない。できないの!?そんなバカな。ないわけないよね?そんなオブジェクト指向開発環境あるはずがない。きっと秘密の方法があるんだよね!?

4. シミュレータ

テストのために、Mac上で動作させたい。シミュレータまたはエミュレータを使いたい。

Xcode

動作するスキームとして、iOSシミュレータを選択します。

xcode_scheme

ビルドして実行します。シミュレータが起動して実行されます。以上、おしまい。

Eclipse

Android Virtual Device Managerから、Android Virtual Deviceを作成します。選択して実行します。エミュレータ起動画面が表示されるので待ちます。

eclipse_emu

待ちます。待ちます。待ちます。5分待っても画面が変わらないので、強制終了します。以上、おしまい。

なんかネットで検索すると、Intel製?のエミュレータがあるらしくそれを使えという事らしいけど、純正でこんなにも使い物にならないってのは、どうよ。ダメすぎじゃん。

iOSはシミュレータ。Androidはエミュレータ。つまり、iOSはOSおよびアプリをx86にネイティブコンパイルしたものを使います。だから速い。AndroidはARMチップをx86上でエミュレートして走らせます。そりゃ遅いに決まってます。純正でまともな速度で動作するエミュレータ(もしくはシミュレータ)作ってよ。

5. Subversionとの統合

開発環境と、各種SCMを連携させたい。うちの会社はSubversion使っているんで、Subversionが動けばいいです。

Xcode

新規プロジェクトを作成して、Subversionに入れる。その状態でプロジェクトを開く。これだけで連携します。リポジトリアドレスの入力などは必要なし。プロジェクトにファイルを追加すると、Subversionにaddされますし、削除するとdeleteされます。編集したら、commitします。

Eclipse

EclipseでのSubversion統合は、できるんだよね、きっと?ちゃんと調べれば、どこかにやり方が書いてあるんだよね?ただXcodeみたいに設定なしでできるというわけではないのかな?

6. エディタの2画面表示

Xcode

Xcodeでは、エディタを2つ並べて連携させる事ができます。このとき、右側のエディタはアシスタントと呼ばれます。

xcode_assistant

アシスタントにはざまざまな表示が可能ですが、カウンターパートと呼ばれるものがあります。これを使うと、左側に.mを表示するとき、右側に自動的に.hを表示させることができます。その逆で、.hを選択したときに.mを表示する事も可能。

また、左側で.xibや.storyboardを表示して、右側に対応するコントローラクラスを表示する事も可能。インタフェースをデザインしながら、対応するソースコードを実装できます。

Eclipse

Javaはヘッダファイルがないから、この機能への要求が低いのは分かります。でも、layoutを編集しながらActivityのコードをいじれたら、便利だと思うんだけどな。

7. インスペクタ

Xcode

Xcodeの、ユーザインタフェース編集のためのインスペクタ画面です。

xcode_inspector

Eclipse

Eclipseの、ユーザインタフェース編集のためのプロパティ画面です。

eclipse_property

なめとんのか。手抜きだ手抜き。

8. 操作をアニメーションで確認する

XcodeもEclipseも、基本的に一画面をタイル分割して各種情報を表示しています。そのタイルを隠したり表示したりできるんだけど、Xcodeはそのときにアニメーションが伴います。Eclipseは伴わない。正直Eclipseだと、何がどこに移動したのか分かりません。操作をした直後は完全に動揺し、そのまま30秒画面を凝視した後で、何がどこに動いたのかが理解できます。これがアニメーションがあれば、その瞬間に分かるものです。

アニメーションはただの派手な演出ではありません。ユーザを導くガイドラインです。Eclipseは、それがまったくないです。

9. スタックトレースを見やすく表示する

Xcode

Xcodeのスタックトレースです。

xcode_stack_trace

Eclipseのスタックトレースです。

eclipse_stack_trace

ぐは。ログかよ!

これは悪意のある比較で、Eclipseにもちゃんとリストで表示するスタックトレースは見つけました。

eclipse_stack_trace1

でも、ログで吐くスタックトレース(しかも改行されてリストで表示)は、衝撃だったな。これしかなかったらどうしよう、と思った。

10. ワークスペースを複数開く

Xcodeでは、開発は「プロジェクト」が基本。プロジェクトを複数まとめた「ワークスペース」も作成できます。ワークスペースは複数作成し、同時に開く事ができます。

Eclipseでは、開発は「ワークスペース」が基本。ワークスペースで複数の「プロジェクト」をまとめます。ワークスペースは複数作成できますが、同時に開くことはできません。なんでじゃ!しかもワークスペースを切り替えるときに、一度Eclipseが終了します。なんでじゃ!

これたぶん、LinuxやWindowsでは別プロセスとしてEclipseがもう一つ立ち上がるんだと予想。OS Xだと、同一アプリを複数プロセスで起動することができないので、こうなってしまっているんじゃないかな。

道具は思考を規定する

こうやって不満に思ったところを書き出してみましたが、これで分かったのは、私の考え方は完全にXcodeに支配されているということです。もうちょっと穏当な言い方をすれば、開発スタイルがXcodeに合わせて最適化されている、ってことでしょうか。もし始めからEclipseだけを使っていれば、それに合わせた思考体系になっていて、ここで挙がった不満は生じない、そもそもそういう欲求が起きないのでしょう。

そしてそれは、その道具を使って開発されるアプリにも影響を及ぼさないはずがないです。つまり、Xcodeの思考体系に慣れたプログラマと、Eclipseの思考体系に慣れたプログラマは、どうしたってそのスタイルに引きずられながらアプリを開発します。これは、ボタンのちょっとした挙動や、設定画面に必要な項目などで、ちょっとした、ほんとにちょっとした差として表れるでしょう。

それらが積み上がっていった結果、どちらがより良いアプリになるか?その辺りを意識しながら、Eclipseを使い続けてみようと思います。

 

『大辞泉』2.1リリース


daijisen_icon

大辞泉』2.1がリリースされました。このブログで紹介するのは遅れましたが、4/28からリリースされています。

2.1は辞書データのアップデートなので、いろいろな数字を並べておきましょう。

  • 最新の時事用語など2,900語を追加して、総項目数27万200語
  • 大辞泉プラスは3,500語を追加して、項目数6万7,500語
  • 大辞泉と大辞泉プラスを合わせると、33万7,700語
  • 画像は万2,190枚
  • 地図情報は1万3,200件
  • 関連リンク(URL)は5,000個
  • 季語表示は5,000件
  • 漢字項目は3,500件
  • 類語は3万4,280語

「笑っていいとも!」の「国語辞典をアップデート 目指せ!言葉の達人」で作られた作品も加わっています。「大人」の項目で検索してみてください。大辞泉プラスを購入している方は、「森田一義アワー笑っていいとも!」で検索しましょう。

waratteiitomo

『大辞泉』2.1リリース間近。新語2,900語追加。「笑っていいとも」レギュラー陣の作品も


daijisen_icon

大辞泉』2.0が出たばかりですが、近日中に2.1がリリースされます。

2.1は、恒例の新語追加になります。2014年4月期では、最新の時事用語など2,900語を追加。これで総項目数27万200語。大辞泉プラスは3,500語を追加して、6万7,500語になります。合わせると、33万7,700語!どこまで増えていくんでしょう。

さらに『大辞泉』は、画像や地図情報など、内容を補填する情報が多いことも特徴です。画像は1万2,190枚。地図情報は1万3,200件。関連リンク(URL)は5,000個。季語表示は5,000件。漢字項目は3,500件。類語は3万4,280語。類語辞典としても充分使えますよ。

また、先日放送を終了した「笑っていいとも!」で、小学館大辞泉編集部の板倉さんが「国語辞典をアップデート 目指せ!言葉の達人」に出演していました。そのときにレギュラー陣が作成した作品も、今回のアップデートに含まれます。

隠れた才能を発揮した木下優樹菜さんは、「大人」の作品が大辞泉本体に。最終回で放送されたレギュラー7人の作品は大辞泉プラスに、それぞれ収録されます。

審査が通り次第の公開となりますので、しばしお待ちを。

『大辞泉』2.0リリース。無料モデルの終息とその総括


daijisen_icon

iOSアプリ『大辞泉』ですが、バージョン2.0をリリースしました。そして、とても大切なお知らせがあります。『大辞泉』は2.0から有料アプリになります。

『大辞泉』は、バージョン1では無料アプリとして配信し、ソーシャルゲーム的な利用回数を設定しました。これは好評を得たのですが、その成果を収益に結びつけることができず、このままの状態では事業の継続が困難となりました。ライセンサーからも現状を憂慮した強い働きかけがありましたので、無料での配信は終息し、有料アプリとして再出発することとなりました。

いままで無料で使っていた方は、利用可能回数がなくなり次第、検索結果の表示ができなくなります。引き続き利用する場合は、「利用可能回数制限の解除」ライセンスを購入してください。詳しくは、こちらのFAQをご覧ください。

有料化となりましたが、まだまだ開発は続きますので、引き続き『大辞泉』をよろしくお願いします。

——–

ということで、『大辞泉』の無料化は終わったのですが、そもそも無料でリリースしようとした背景には、強い危機感がありました。どういうことかというと、スマートフォンのアプリ市場は広がっているものの、売れているのはソーシャルゲームばかり。有料アプリのダウンロード数はどんどん下がっている。ユーティリティアプリの開発をメインとする弊社は、このままではジリ貧ではないか。この状況を打開するには、無料で配布して後で課金する、いわゆるフリーミアムモデルを、辞書のようなユーティリティアプリでも導入するべきではないか。

思い描いていた戦略は、こうでした。まず、アプリを無料化してユーザ数を確保する。そして、ソーシャル的なつながりを演出することで、アプリの稼働時間を長くする。これにより、ヘビーユーザが課金してくれる。

「ソーシャル的なつながり」として、他のユーザが検索した言葉を表示する「コトバストリーム」であるとか、小学館の編集部が行った「あなたの言葉を辞書に載せよう。」キャンペーンであるとか、自分の考えた言葉を投稿できるようにした、「みんなのコトバ」機能とかを実装しました。

その結果は、どうだったのか?結論を言えば失敗だったのですが、ここで総括したいと思います。具体的な数字も出していきます。

まず、最初の目標であるユーザ数の確保。これはどうだったのか?『大辞泉』は、2013年の5月17日に公開して、2014年の4月7日まで無料でした。11ヶ月弱というところです。この間のダウンロード数は、151,186。15万を超えたところでした。

この数が大きいのか?辞書アプリとしては、充分に大きいと考えています。長らく辞書アプリに携わってきましたが、『大辞泉』のようなフルサイズの辞書が一年かからずに十数万ダウンロードされるというのは、トップレベルだと思います。やはり辞書の需要は強いのだと感じました。もともと2,000円で販売されていた物が無償になった、というインパクトもあったでしょう。

もちろん、無料アプリにさえしてしまえば、ある程度のダウンロード数があるのは想定できました。重要なのは稼働時間です。結構多いのが、無料だからダウンロードしたけど、その後も一回も使われずに削除される、っていうパターンです。どのくらいのユーザが使い続けてくれているのか、というのが気になるところです。

これは統計を取れるようにしています。コトバストリームを実装したときからです。コトバストリームを有効にしていると、サーバに検索した語句を登録します。これを使って、大体の稼働率を推測することができます。コトバストリームの稼働を始めたのが去年の11月からなので、4ヶ月程度での統計となります。

まず、総検索語句数。これが、約400,000。一日平均にならすと約3,000。30秒に一回、誰かがアプリを使って検索してくれている、という計算です。確かにコトバストリームを確認すると、一分とたたずに誰かが新しい語句を検索していますからね。

次にユーザ数。4ヶ月間で実際にアプリを使って検索をしたユニークユーザ数は、約41,000。総ダウンロード数の27%になります。1/4強のユーザが、ちゃんと使ってくれていました。一日平均を求めると1,250。直近7日間のユニークユーザ数は5,000。

これらの数を少ないと見るか、多いと見るか。辞書アプリとして考えれば、充分に多い。有料のユーティリティアプリならば、この程度の数は充分に多いと考えていい。でも、無料サービスとして考えるならば、多くはないですね。

そして、最後に最も重要な課金率。製品の購入と同等となる「利用回数の制限を解除」を、どれだけのユーザが購入してくれたか。その課金率は、ズバリ0.5%。1%いきませんでした。正直にいって、これはかなり低い。採算とれるかどうかのラインは5%程度なので、まったく届いていない。

ここまで低いと、宣伝がうまいくいかなかったとか、製品のできがどうとかの前に、戦略が間違っていたとしか言いようがないです。ここで言い切ってしまいますが、辞書アプリでのフリーミアムモデルは、戦略的に間違いでした。少なくとも、「利用回数の制限を解除」をユーザに購入してもらうビジネスモデルでは成り立ちません。じゃあ、広告を入れるようなモデルでは?と考えても、いまのユーザ数では広告は無理ですね。というか広告モデルにするなら、Webサービスにした方がいい。

結論としては、ユーザ数が増えて、稼働率もそこそこ上がったけど、課金にはまったく結びつかない、ということでした。このまま無料を続けても課金率が上がる見通しはなく、赤字がふくれあがる一方なので、終息させざるをえません。

リリース前にいろいろとシナリオを予想していたましたが、悪い方で決着しました。ただ、挑戦したこと自体は、間違っていたとは思っていません。この結果をもとに、修正をしていきます。

今後は、有料アプリとしての開発となります。従って、方針も変わることになります。バージョン1までは、ユーザ数を増やすためにソーシャル的なつながりを掲げていました。バージョン2からは、そちらは縮小します。ここからは、語句をいかに素早く効率よく検索できるかという、辞書としての検索機能の向上を目指します。辞書の検索は、まだまだ改良の余地があるんです。まずは、近々新語の追加がありますので、そのときにも強化を含めていきます。

結局、有料アプリの販売数が下がっている、という問題は解決していません。でもフリーミアムもその解決策にはならないということは分かりました。少なくとも、辞書では。また新たな策を探しにいきます。

『大辞泉』1.6.2がリリース


daijisen_icon

iOSアプリ『大辞泉』1.6.2がリリースされました。変更点は、以下の通りです。

[機能の改善]

  • 文字表示パフォーマンスの改善

次は大きめのバージョンアップになるべく、準備中。

先日まで短期のバイトが入ってました


先日まで短期のバイトが入ってました。プログラマバイトです。本当に短期で一週間にも満たなかったんで、お金を稼ぐというよりは、体験を目的とした感じです。

バイトだったり新人社員だったりした場合、うちの会社は仕事のやり方ってのがある程度決まっています。まず、新規のプロジェクトをお願いする事はなくて、既存のプロジェクトに参加してもらいます。そして、あるクラスのある機能の実装をお願いします。そのときに、大体この辺のメソッドをいじればいいんだよ、という事は伝えます。作業時間の目安は2時間程度。そのくらいで出来る規模です。出来上がったら、コードレビューして確認します。

このコードレビューが肝ですね。レビューは、いつも2時間くらい。つまり、実装時間と同じくらいかけます。書いてもらったコードを、ああでもないこうでもないと突き回して、ちょっと書き直させてもらうねと言って、痕跡が残らないくらい書き換えてしまいます。プログラマにとっては、自分の書いたコードをリライトされることほどの屈辱はないですよね。レビューという名を借りて公開処刑をやっているんじゃないか、という気持ちにもなります。

いろんな人の書いたコードを見てきましたが、大体みんなロジックは間違えてないんですよ。プログラミング原語は理解している。UI Kitの使い方もオッケー。アルゴリズムも悪くない。

問題は、「それをどこに書くか」ということです。つまり、どのクラスで、どういうメソッドを切るか、というところに問題の大部分が集中します。経験の浅いプログラマの場合、多くの場面でメソッドの切り方が不適切です。不必要に細かすぎたり、同一処理が分散したりしています。レビューでは、そこを指摘して、メソッドの切り直しを行います。ロジックやアルゴリズム自体は変わらないので、コピー/ペーストで済みます。これを行うと、コードが見違えるようになり、デバッグや拡張が容易になります。

じゃあ如何にして適切なメソッドの切り方を身につけるか? いろいろ考えますが、やっぱり経験しかないですかね。個人的な意見では、適切なメソッドさえ切れれば、プログラミングにまつわる多くの問題は解決します。世の中にはユニットテストとかいう類いのものがありますが、あれはメソッドが適切に切られているということを前提としていますよね。そこが不適切だったら、テストなんか無意味です。本当は、メソッドの切り方が適切かどうかテストする手法が欲しいんですが、それはまだないでしょう。

どうにかしてここを定性化できないか、と思って書いたのがオートマ本だったんですけど、うーん、物足りないですね。ソースコードの質を上げるには、レビュアーの質に頼るしかないのか、というのが現時点での結論です。