はてなブックマーク

git-flowのフル利用は受託案件にはオーバースペック 個人的な感想として、開発で多いのは"成果物や期間の定まった小規模受託案件 > 継続的に運用を必要とする大規模案件"だと思ってます。あくまで個人的な感想です。 git-flowはプロダクトを継続的に開発・運用することを前提にした運用です。なので、「リリース後～次のリリースまでに問題が起きたらhotfixする」のようなワークフローが作られています。 逆に受託開発（特にアプリ開発）は「n月末までに納品物を作る。あとは知らん（契約によるからね！念のため！！）」という流れです。git-flowのワークフローは大仰すぎて、あんまり受託開発向けじゃありません。 じゃあ、なんでgit-flowを使うのか 有名だからというのが一番の理由です。完全な社内ルールとかオレオレルールを適用してしまうと、協力会社だけじゃなく、中途採用の人にも学習コストがのしか

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? @eaglesakura です。 皆さん、進捗どうですか？ お仕事の規模が大きくなれば、参加人数が増えていくでしょう。 参加人数が増えれば、様々な宗教観の人がプロジェクトに参加するでしょう。 お一人様プロジェクトを中心にやっていた人もいれば、大規模案件のソルジャーとしてキャリアを積み上げてきた人もいます。彼らのスキルレベルもまちまちです。 私が参加している（そしてプログラマーに対して強い権限のある立場である）プロジェクトでは、次のようなルールをベースに適用しています。 これはなるべくプログラマーの負担をかけずに管理側（プロジェクトマネー

@eaglesakura です。 Google I/OでAndroid Studio 3.0が発表されましたね。 Preview1の段階ですが、メジャーアップデートということでいろんな機能が追加されたようです。 2.3系列から3.0へのマイグレーションガイドは(youtubeのセッション動画等で）公開されていますが、毎度のことでそれだけではなんともできないことが多いので私の個人的なアプリプロジェクトでガイド以外にマイグレーションした箇所を書いていきます。 DexCountプラグインを削除する DexCountプラグイン(com.getkeepsafe.dexcount:dexcount-gradle-plugin) ~~slack通知プラグイン(com.github.operando:gradle-slack-plugin)~~は内部で参照しているGuavaのバージョンが他のプラグインと競

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? @eaglesakura です。 春ですね。新入社員の季節ですね。 前置きはこのくらいにして、「この環境を最低限用意してほしい」という一覧を書いておきます。 OS選定 Windows 10 or Mac OS をお勧めします。それ以外のOSを導入できるようなスキルがあるならば、たいていのことは自分でどうにかできるでしょう。 私はWindows10を使用しています。所属しているトップゲート社はほぼ全員Macを使用しているためマイノリティですが、下記のような理由で使っています。 購入時点でMBPより強力なCPUを搭載していた メモリ32GB

@eaglesakura です。 アプリ（Android/iOS）とFirebaseはFirebase Authを使うと簡単に認証を行えます。 ですが、単純にFirebase Authだけを使うと、自社サーバー（Appengine含む）からユーザー権限でAPIを呼び出せず（例えばユーザーのGoogle Driveにアクセスする、等）、サーバーとアプリ両方の認証が必要になるなどユーザーとしては認証が複数回発生して煩雑になります。 自社サーバーとGoogle APIとFirebaseを連携させ、なおかつユーザーフレンドリーさを保つために「一度のログインで全リソースへのアクセスを行なう」ために必要な処理をざっくりとまとめました。 SDKが整備されている環境・言語（node.jsとかJavaとか）であれば苦労なく行えますが、整備されていない場合や一部だけ実装する必要がある場合等は参考になるかと思い

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

@eaglesakura です。 結論から言うと、DIは怖くないぞ。 DI(Dependency Injection, 依存注入)は昨今のプロダクト開発では当たり前のように使われています。 DIそのものに関しての解説は参考URLを読んでください。 参考 http://qiita.com/hshimo/items/1136087e1c6e5c5b0d9f 私自身は今年になって担当案件の開発規模が大きくなり、それに従ってUnitTestや依存関係が増えてきたことで、スマートな依存解決を求めて「どんなもんだろうな」と調べるようになりました。 遅いですか？ 遅いですね。 AndroidのDIライブラリ 一般的なAndroid界隈の開発では Square/Dagger やそれをForkした Google/Dagger2 が有名です。 なぜDagger系ライブラリを使わなかったのか コードの追いづらさ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? @eaglesakura です。 社内でプロジェクトのメインプログラマーとしてコードレビューをする機会が増えてきたので、私の考えるActivity/Fragmentの基本的な設計方針を解説します。 この実装はあくまで私が考える範囲での設計です。この考え方は2016年Q3現在のものです。 事前に読んでおくべき記事 ActivityやFragmentに関してはこの記事も読んでおくと良いです。 参考 https://developer.android.com/training/basics/fragments/communicating.ht

@eaglesakuraです。 この記事で解説するのは、2016年Q3現在、私個人が「気楽に非同期処理を実装できる」と考えた設計です。 私は好きにした。君たちも好きにしろ。 Androidの非同期処理とは 面倒の塊である。 Androidアプリの中心にあるのはActivity/Fragment/Serviceといったオブジェクト（便宜上、システムオブジェクトと呼ぼう）で、こいつらはユーザー操作によって画面のForegroundとBackgroundを縦横無尽に行き来する。 非同期処理中にForegroundからBackgroundに移るだけならまだしも、サクッとDestroyされてしまうこともある。なので、Androidの非同期処理（と、結果の受け取り）は慎重に実装されなければならないし、それがまた面倒だ。 コールバック地獄を回避する 非同期処理を簡単に行う（そして結果をUIスレッドでコー

前提 @eaglesakura が務めているTopgate社は受託案件が多いので、この方針が絶対ではない。受注元によっては好き放題できるし、受注元によっては条件が厳しくなる。 また、弊社のAndroidアプリ開発は1人～数人で行われることが多い。そのため、この方針は更に大規模な開発では通用しない可能性があることも承知している。 その辺りは 以前の記事 でも書いたとおり。 ここに書いた方針はその時々の状況（公式ツールやSupport Library、流行り廃り）によって変化する。が、こういう構成になったのはその時時の理由があるわけなので、明文化することで後々「なぜこういう構成にしなければならなかったのか」ということを思い出せるようにもしておきたい。 環境整備 ソースコード管理 制限が無いのであれば、githubで管理する。githubのissueはRedmineに比べると機能的に不十分である

一身上の都合により、ButterKnifeを捨てることにしました。 かなり個人的な理由ですが、ButterKnifeを捨てる理由を挙げていきます。 Androidアプリ開発でのButterKnifeの便利さ ButterKnifeはいかに便利であるかは、Qiitaで"ButterKnife"と検索すればたくさん出てくると思う。Java標準機能である"Annotation"を駆使して、findViewByIdやsetOnHogeHogeListenerを駆逐してくれる、便利なライブラリだ。 この「findViewByIdやsetListenerの代わりにAnnotationを用いる」という基本的なところは大いに賛同するし、Android Annotationを始めとして幾つかの人気ライブラリはそういった便利さを提供してくれている。 ButterKnifeに足りないもの ButterKnife

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

最初に この記事に書いてあることは23.2.1で修正されました。よって、普通に使って問題ありません。やったね！！ （23.2.1での直し方も、この記事で紹介しているのとほぼ同様でした） Design Support Library 23.2.0がリリースされた BottomSheetDialogというのでBottomSheetがカジュアルに使えるようになりましたが、ユーザーがダイアログを引っ張り上げすぎると勝手にDialogがcancelされてしまうというあんまり好きじゃない挙動があります。 これが公式なのか意図しない挙動なのかはわかりませんが、現時点ではどうにも直す手段が提供されていないように見えるので、ソースコードを引っ張ってきてちょっとイジりました。 問題箇所 onTouch()でキャンセルしている判定で、ACTION_UP時に指がBottomSheetのコンテンツ部分からはみ出して

Android Nから 縦横という概念自体がなくなる ので、デザイナーが対応できるかも考慮が必要。(-land就職子はdeprecated。-sw320などを使う) WebView有無 WebViewをアプリの一部として使う場合、レイアウト崩れを誰が解決するかを確定させておく必要がある。Android 4.3以下、4.4、6.0でそれぞれWebViewの挙動が多少変わったため、必ずOSバージョン選定と一緒に、WebViewの挙動チェックを行う端末も選定しておく。 「既存コンテンツをWebViewで表示する」案件 これは多くの場合炎上する。 なぜなら、そのように「既存コンテンツを再利用」するということは、モバイルコンテンツに対するコスト意識が希薄で、「簡単に考えている」からだ。 大抵のリスク説明は「そんな風には考えていない」「簡単でしょ」とと言われる傾向にある。 例えばレイアウト崩れの問題が

buildscript { repositories { jcenter() } dependencies { // classpathが変わった classpath 'com.android.tools.build:gradle-experimental:0.1.+' } } allprojects { repositories { jcenter() } } さらに、プロジェクトをビルドするためのbuild.gradleが大胆に変更されています。Plugin名も変わっています。 記述方法は、従来は"compileSdkVersion 22"のように記述していた部分が、"compileSdkVersion = 22"のように"="で記述するようになりました。実装的には、メソッドではなくて変数に書き換わったかと思います。 全ての変数がそうなのか？というとそうではなくて、一部は従来のようにメ

仕事でも個人的にもAndroidでBluetooth LEの製品を扱うことが多いです。ですがAndroidはBLE関連機器の扱いがかなりテキトーで、それなりに問題が多いので、情報共有します。 直し方知ってたら教えて下さい。 試しているBLE機器 仕事で扱ってるBeacon類と、Andriders Central Engine(ACE)で対応しているBLEフィットネス機器を対象に書いています。 各種Beacon Wahoo 心拍計 Wahoo ケイデンス・スピードセンサー Wi-Fiと併用すると通信不可能になり復帰できない 規格的に周波数帯が同一だからかもしれませんが、Wi-FiをONにした状態（アクセスポイントに接続する・しないは問わない）でBLE機器との通信が行えなくなります。 この状態になった場合、GATTの切断メッセージ(BluetoothGattCallback.onConnect

結構前にGoogle Play Developer APIが公開され、それなりに便利そうな割にはあんまり使ってる人を見かけないので、何が便利でどういう問題があるのか、実際に触れ合ってみました。 最初に書いときますが、APIだけでは個人的に必要な要望を満たせませんでした。 Google Playの機能拡張待ちです。 Google Play Developer APIとは Google Playのコンソール画面(アプリを公開したりする画面)の操作を行えるAPI 2015.4月現在はv2が提供されている 各種言語から扱えるライブラリやサンプルコードが配布されている JavaだとMaven Centralとかで配布 API自体は非常にカンタンに覚えられる Gradleからアップロードしたい Gradleからアップロードできれば、Jenkinsやら流行りのTravisやらCircleやらのCIでアッ

@eaglesakuraです。 俺、L-Previewやめるってよ Android L PreviewがリリースされてからこのかたずっとLを使い続けていました。日経ソフトウエアで新APIの記事書いてるので、みんな買ってね♡ さて、Lの新機能は非常に良く出来ていますが、ぶっちゃけて言えばDeveloper Previewなのでバグバグです。どのくらいバグバグかといえば、たまに3G/LTE回線にすら繋がらなくなる（電波は3本立っている）くらいバグバグです。 Preview版なので、別に完璧は求めてません。単に、俺個人の感想として「L-Previewは人類には早すぎた」とか思ってるだけです。 ようやくまとまったお金を手に入れることができ、常用端末と開発用端末を切り離すことが出来ました。喉元過ぎて忘れないため、L−Previewで何が問題だったかをメモっておきます。 なお、ここでのバージョンはLP

@eaglesakuraです。2013年にAndroid Studioが発表されて、だいたい1年ちょいが経過しました。最初は不安定でアレな感じだったAndroid StudioとGradleプラグインもそれなりに安定してきて、普通のAndroidアプリを開発する分にはあまり困らなくなりました。 現在は移行期にあたるため、2014年のEclipseを使っている人も多いと思いますので、「Android Studioって正直どうよ？」っていう人たちのためにEclipse+Antにはない利点を列挙していきます。 ビルドがGradleに統合される 最大の利点で、コレが移行するための大きな動機であり障壁です。Gradleはそこそこ新しいビルドシステムで、Groovy言語でビルド内容を記述します。 ビルド用ファイルであるbuild.gradleは、Android Studio(GUI環境)からもコマンド