道産子エンジニア

毎週好きなこと書きます。

greenDAOをObjectBoxに置き換えたい

この記事は本日 potatotips #37でした以下の発表のafter showみたいな内容。

speakerdeck.com

greenDAOをプロダクトで使っているけど、version2なのでかなりいけてない。

greenDAO v2の良くないところ

  • 自動生成されるクラスが多い&コードを変更でてきてしまい、闇クラスの香りがする
  • とにかく Schema の記述が面倒。リレーションを組むならまず精神統一が必要
  • SQLiteベースでシンタックスも微妙

などなどいろいろ問題はある。スピードは早いのだけど、 設計が開発者フレンドリーじゃないのであまり好きじゃない。(もっと楽したい)ちなみに、この辺はv3になりannotationベースになってから改善されてきている。導入については今回端折るけれど最新のv3.2.1ならまだすぐに別ライブラリに置き換えたい!と思うレベルではないかもしれない。

そして先月末でてきて期待しているのが、同じくgreenrobotが作っている新しいORMライブラリの ObjectBoxだ。

ObjectBoxのいいところ

  • 公式のベンチマークはないが読み込み早いらしい(gfxさんの記事が詳しい)
  • アノテーションベースでいい感じ(日本語最速の記事はこれだった)
  • 自動マイグレーションあり

などなど導入しない手はないな!って気持ちでいっぱいなのでまずはv3に上げるところからサンプルを作ってみた。

github.com

コミットの順番にアップデートして見てるので試してもらうと動きがわかりやすいと思う。 greenDAOにはないのがマイグレーションとDBっぽくないシンタックスなので最終的には全部置き換えたい。

DaoCompatを使えばgreenDAOから移行できる

とはいえ今のプロジェクトの膨大なコードを別ライブラリに一気に置き換えるのはテストが大変なので困る。 俺がこの発表をしたかったきっかけは greenDAO から ObjectBox へ以降しやすいように DaoCompat なるものを用意しているから簡単だよ!というからだった。

featureにもちゃんと

DaoCompat library: Already using greenDAO? This small helper library gives you familiar greenDAO APIs for ObjectBox.

と書いてあったので期待していたが結果は発表した通り、エラーがでまくってて動かなかった。
サンプルを見て問題があったら指摘待っております。
コードもまだgithubにないのでどの辺が悪さをしているのか想像するしかない。importが失敗してるのでその辺はちゃんと見たいが、daoCompatを使うとgreenDAOのコードが生きたままなので結局あんまりいけてない。

最終的には DaoCompat 使わずに ObjectBox でフルスクラッチできたほうが幸せなのでこの際やりきってしまうのもありだと思う。(サンプルコードはそうなった。)ただし、導入においていくつか注意点もある。

  • もちろんまだbeta版なのでAPIの破壊的変更などがありえる。あと下位互換はしないそう
  • 複数スキーマを作っている場合はまだ未対応

個人的にはコードが自動生成されるのは好きだ。中を見れば何をしていて、どこが問題かすぐわかるから。 ただ既存のモデルにアノテーションをつけたらクラス内を変更されるので、メソッド名の競合など何か不具合が起きる可能性は0ではないかもしれない。

今後もアプデされたら追って発表していく。issueを見るかぎりRxやkotlinの対応もされていくっぽい。

加藤昌治「考具」

考具 ―考えるための道具、持っていますか?

考具 ―考えるための道具、持っていますか?

かなり昔に表紙を見た記憶があって、ブックオフで100円だったので購入。 古くなっていたが、2010年の第30版なので相当売れているのだろう。(発行部数が少なければ一概には言えないが)

ブレインストーミングやKJ法みたいなものを普段から使っている人には「何をいまさら」な内容だと最初は思っていた。読んで見るともちろんそういった内容も多いのだけど、いくつか「これはやってみたいな」と思うようなアイデア出しの方法があってよかった。

これは自分も含めてかもしれないが、昔からよく感じるのはエンジニアは「アイデアがあんまり面白くない人が多い」ということ。(それでも自分はアイデア出しには少し自信がある)どうしてなのだろう?と考えてみると、デザインの知識がある人や経営者の人たちはアイデア出しの瞬間、 紙などに雑に書きなぐることが多くないだろうか?その一方でエンジニアは マークダウンなどテキストでリストアップすることが多くないだろうか。 自分の実体験で思い出して見て欲しい。

面白いアイデア出しのポイントはここにあるのではないかとこの本を読んで思った。なぜなら

脳は放射状に働く、知的作業は一直線なのでずれている

だからだ。どういうことかというと、アイデアが生まれてくるときの自分の状態を思い出すとわかる。 アイデアが浮かんできているとき、「そういえばあれも〜だ」とか「関係ないけど…もあるよな」みたいなことがないだろうか?(俺は非常によく体験したことがある。なかったらむしろアイデア出しに脳が活発になってないのかも)

人はアイデアを考えるときと問題を解くときでは明らかに考え方が違う。問題を解くときは順序立てて、論理立てて、なぜを突き詰めていく。それは後からなぜそこに至ったか自分に説明する必要があるからだ。アイデアを考えるときはあるテーマについていろんな方向に発散しながら考える。つまり放射状に考えている。

エンジニアのアイデアが凡庸なのは、エディタの左上から順番に列挙しようとするからつまらない

俺はそう思う。そしてそれを意識して変えていけば誰でも面白いアイデアにぶち当たることができるはずだ。 そう思うことができたので面白い本だった。

マンダラート

いろんな考えるための方法を書いてあるこの本で、自分が聞いたこともやったこともなかったのがこの「マンダラート」(Mandal-Artと書くらしい)詳しくはおググりくださいなんだけど、簡単に言えば9マスの正方形を使ったシンプルなバリエーション出しのことだ。9個ってのとマンダラってのがいい。マンダラって仏教のやつらしいんだが名前もいけてる。ポストイットを使ってブレインストーミングするとなんでかあんまり手が動かない人っていると思う。漠然とポストイットを見つめるだけでは確かに難しい。けれど、マンダラのマスを埋めるのはなんだか楽しい。マルバツゲームをやっているような感覚になるのがいいところ。

これは是非やってみよう。

名前は重要

この本でもタイトルの重要性が説かれていた。いつかのブログでも書いたのだけど、大学でバイクサークルを作ったとき顧問だった学長に「名前をちゃんと決めてね。名前は重要だから」って言われたのをいつも思い出す。加藤さんも自分のアイデアにはタイトルをちゃんとつけるのが大切だという。会社の社長もこの施策にゴロのいいフレーズが欲しいねというし、半期に一度の社員総会では必ずスローガンを掲げる。

少し違うけどエンジニアも変数名とかメソッド名を気にする。ライブラリの名前なんかもそうだ。 人は名前がイケていると使いやすい、覚えやすい、呼びやすい、伝えやすい、思い出しやすい。 タイトルは絶対重要だ。


読書所用時間:約3時間
オススメ度:★★★★☆