本を書きました!
ひょんな経緯から、クラウドファンディングによるAndroid設計本「Android アプリ設計パターン入門」の執筆に携わりました。 自分が担当した章は「7章 チームとアーキテクチャ」になります。クラウドファンディングの本で手にとっていただくのはなかなか難しい部分もあると思うので、どんなことをこの本に詰め込んだか書きます。
続きを読む
ひょんな経緯から、クラウドファンディングによるAndroid設計本「Android アプリ設計パターン入門」の執筆に携わりました。 自分が担当した章は「7章 チームとアーキテクチャ」になります。クラウドファンディングの本で手にとっていただくのはなかなか難しい部分もあると思うので、どんなことをこの本に詰め込んだか書きます。
続きを読むInstrumentation Testを書く時、実際にAPIリクエストは行わせず、APIレスポンスをmockしたいですよね。方法としては2通りはあるかと思います。
mockの値を変更するのが容易なので、2番目の方法がおすすめです。しかしながらDagger2でmockを依存性注入するのは結構面倒で、実際テストを書き始めるまでにいくつかステップが必要です。この記事ではDagger2とKotlinを使ってEspresso instumentation testをを書く方法を説明します。
続きを読むこちらはReact Nativeアドベントカレンダー 19日目の記事になります。
ここ1、2年でReact Nativeによるアプリ開発はますます盛んになっていますが、一方でNativeと組み合わせたとハイブリッドアプリケーション開発はまだ発展途上です。 React Nativeの公式ドキュメントにもIntegrating with existing appという項目がありますが、あっさりと書かれている上に鮮度がお世辞にも高くありません。
しかしながら、FacebookやAirbnbなど大企業がハイブリッドアプリケーションを積極的に導入していることや、Nativeアプリを部分的にリプレイスできる利便性から、今後も採用が増える分野と考えられます。本記事ではハイブリッドアプリを開発した自分の経験から、プロコンや実装の基本についてまとめました。
続きを読む
先日結婚式を挙げました。式中ご参列いただいた方と簡単に写真を共有したいなと思い、そういうマイクロサービスを作ってみました。ここではどのように実装していったのかを記憶が薄れぬうちに書いていこうと思います。
自分が結婚式に参列する時、写真を撮るものの、主賓に送りそびれることがよくあって、だったらそのままさくさく送れたら楽じゃんねーと思っていました。で送りっぱなしだとグルーブ感がないので、出来たらその場でシェア出来たらよいかもと考えていました。それを踏まえて仕様としては、
ことを目指しました。
全体構成は以下のようになっています。
LINE Message APIを使ってLINEのチャンネルを参列者に登録してもらい、そこから写真を投稿してもらいます。webhookを介して画像データをサーバーに渡し、CDNに保存したのち、WebSocketでスクリーン側(ブラウザの全画面表示)に更新通知を投げて画面を更新しています。
当初、写真を送る部分はReactNativeでiOSとAndroidアプリを作る想定でした。しかしiOSでのアプリ公開のハードルは非常に高いです。テスト用に公開するにしても審査を通らなくてはならず、個人の結婚式用アプリだと到底通らないですし、デプロイゲート等の配信サービスを使う場合でも端末単位でプロファイルIDが必要だったりします。そこでどうしようかと模索していたところ、皆がまず間違いなくインストールしているLINEを利用することを思いつきました。
LINE Message API
サンプルやドキュメントが充実しており、とても簡単に扱えました。チャネルはTrial,Free,Proがありましたが、100人以内のログイン&チャネルからポストしないであればFreeが良いです。
リアルタイムに共有する部分については、スーパーハッカー夫婦の@hatoneさんと@kyoroさんが以前ご自分達の結婚式でやはり写真を共有するサービスを作っていらっしゃったので、実際に相談に行きました。画像のCDNとしてCloudinaryを使う点やWebsocketで更新を通知しビューを更新する点などはめちゃくちゃ参考にさせていただきました。足を向けて寝られません。
Framework
ミニマルな機能でマイクロサービスを作るのにうってつけなサービスであるFlaskを利用しました。ドキュメントは若干散らばっていてわかりにくい部分もありますが、シンプルなサービスを作るのには適していると思います。ORMとしてはSQLArchemyを利用しています。ただ途中から導入したので部分的に生SQLを叩いている所もあります。
Flask Web Development: Developing Web Applications with Python
CDN
Cloudinaryは画像に特化したCDNです。Cloudinaryの優れた点として画像の加工が容易な点が挙げられます。例えば300px,300pxサイズで画像を作り隙間部分は黒色としたい場合、
https://res.cloudinary.com/xxx/image/upload/c_pad,b_black,h_300,w_300/%s.jpg'
というようなリクエストを投げるとよしなに画像を生成してくれます。
またフリープランがとても充実している点もおすすめです。月間20000枚の画像加工と300000枚の画像と動画を扱えるので、結婚式サービスくらいなら十分カバーしてくれます。
Server
リージョンが日本にもあるGAEとも迷ったのですが、Herokuを利用しました。理由としてはHeroku CLIが使い勝手が良かったということがあります。サポートしているDBもPostgreSQLで、FlaskのローカルDBがSqliteなので親和性が高いです。
FrontEnd
jQuery部分は知識がほぼ皆無だったのですが、Kyoroさんから教えていただいたコードを参考になんとか実装しました。ライブラリ群はWebpackでまとめました。Webpack便利ですね。
結婚式約3週間前にサービスを作ることを思い立ち、週末や飛行機内でぽちぽち書きました。
LINE Message APIの不具合なのかサーバー側の問題が切り分けができなかったのですが、受け取った画像の下部が途中で切れてしまうという不具合がありました。結局解決できなかった。
WebSocketがたまにうまく動かず、更新の通知を受け取れない問題がありました。リロードするとうまくつながったりするのですが、この辺の知識が浅いこともあり、いまいち原因がわかりませんでした。
当日実際に式場で動かしてみると、ソケット通信がうまく動かないという事案が発生しました。元々結構不安定だったので、その場で何度かサーバーをやブラウザをリロードして対応しました。
自分の結婚式でLINEbot使った写真共有サービス作ったんだけど、ぎりぎりまで調整してて手元でデバッグとかしてました pic.twitter.com/h9bsZzxLG1
— Tomoaki Imai (@tomoaki_imai) 2017年10月15日
約7割の参列者がLineチャネルを登録し、160枚近くの写真が投稿されました。実はQRコードを一部のテーブルにしかシェアできていなかったので、皆が登録できることを知らなかった可能性があります。事前にQRコードを積極的にシェアしておくのがよいです。
全然関係ない写真なんかもポストされていて微笑ましかったです
ということでちょこちょこメンテしつつ、普通のパーティなんかでも使ってみようと思います。ソースコードは以下で公開しております。もし何かのイベント等でつかいたいという場合はもちろん大丈夫ですが、上記で述べたバグがあるので、うまく動かなくても責任はもてませんことをご承知ください。また、一言連絡いただける(&どんな風に使われたか等をシェアいただける)と大変うれしいです。
ReactNativeプロジェクトで、型がないことによるつらいシーンが多くなり(特に変数の解釈に起因するバグ)、Facebook製の静的型解析ツールであるFlowを数ヶ月前に導入しました。導入時の学びと、しばらく運用して感じていることについて個人的な感想を書きました。
Javascriptで静的な型付けをするといえばTypeScript(正確にはJavascriptのスーパーセット)がありますが、プロジェクト途中からの導入しやすさの観点からFlowにしました。Flowはお作法(行頭に @flow
つける等)さえ押さえれば誰でも使えることから導入障壁はだいぶ低いといえます。導入のメリットについては以下のスライドがとてもわかりやすいです。
flow status
でプロジェクトに対して静的型解析を走らせることもできますが、 コーディング時にワーニングを出す方が便利です。Atomを使っている場合、Nuclideを導入し、Flowの設定をするだけです。
素直にFlowのinstallationドキュメントを参考にすると、node_module配下のflowアノテーションが付いたファイルも解析されてしまい大量のエラーが出ました。実はそもそもReactNativeは標準でFlowに対応しているため、Flowのドキュメントを参考にする必要がありません(むしろうまくいきません)。完全に罠ですね。
ReactNatveでFlowを導入する場合は、以下のようにします。
[ignore] ; We fork some components by platform .*/*[.]android.js ... [version] ^0.38.0
npm i flow-bin@0.38.0 --save-dev
これだけです。
参考:
medium.com
なお、もし無理やりFlowのinstallation手順で行く場合は、 .flowconfig
にいくつかの設定を行いnode_module/
配下を解析対象から外すように出来ます。
[ignore] ; Ignore templates for 'react-native init' .*/local-cli/templates/.* ; Ignore "BUCK" generated dirs <PROJECT_ROOT>/\.buckd/ .*/Libraries/react-native/React.js .*/Libraries/react-native/ReactNative.js ; Ignore react related flow in node module .*/node_modules/react-native.*/.* .*/node_modules/fbjs/.*
上記の場合、Moduleが認識されなくなるのでreact-nativeのModuleについてStubを作る必要もあります。
declare module 'react-native' { declare var exports: any }
参考:
github.com
github.com
例えばフォーマット関数を持つIntlクラスはオブジェクトとして認識されず、エラーが出ます。
const mmyy = new Intl.DateTimeFormat(ENV.LOCALE,...) ^^^^ identifier `Intl`. Could not resolve name
こういったオブジェクトは型を明示的に定義して上げる必要があります。
type IntlType = any; const intl: IntlType = window.Intl; const mmyy = new intl.DateTimeFormat(ENV.LOCALE,...)
参考: github.com
Flowを使い始めてしばらくたった個人的な感想をつらつらと書きます。
コーディング中に型チェックが行われるのでまずい実装をしているとすぐわかります。また↓のように定数の打ち間違いなども適宜指摘してくれます。いくつかの潜在的なバグが洗い出されたのは良かったです。
PhoneVerificationTypeにreset_to_initial_stateというPropertyが定義されてないと教えてくれている
導入も含め、ラーニングコストが低いです。型の作り方も初歩的なものであれば容易に理解できますし、TutorialもReactやReduxで導入する方法など充実してます。なおTypeScriptはDocumentをちょろっと読んだ程度なので、比較はできてないです。
Flowはあくまでもコーディング中にWarningを出すだけなので、強制力はありません。@flow
アノテーションをつけないとWarningもそもそも出ません。なので、チームがメリットをよく理解した上で率先して導入していかないと、導入率は上がらないです。その点で言うと型を強制するTypeScriptの方が良いかもしれません。
当たり前な話なのですが。FlowはJavascriptに型を与えるものなので、正確にはJavascriptとは呼べなくなります。例えば、React ComponentにFlowを適用すると、propTypes等の型定義が必要になります。これにはFlowの特有の記法が求められます。またpropsの型定義を追加すると当然ながら若干コード量が増えます。いざFlowを辞める場合(ないとは思いますが)、このような変化はチーム内で合意を得ておく必要があると思います。
例えばあるクラスにFlowを導入した場合、呼び元のクラスがFlowに対応していない場合は当然警告が出ないです。なので導入が進まないと目に見えた効果が出てこないな~と思いました。途中から導入する場合でもガガっと全てにFlowを適用する方がよいのかもしれません。
三行でFlowについて思う所を述べるとこんな感じです。