小規模開発のgit-flowの導入を楽にするブランチルールと拡張スクリプト配布 - Qiita
git-flowのフル利用は受託案件にはオーバースペック 個人的な感想として、開発で多いのは"成果物や期間の定まった小規模受託案件 > 継続的に運用を必要とする大規模案件"だと思ってます。あくまで個人的な感想です。 git-flowはプロダクトを継続的に開発・運用することを前提にした運用です。なので、「リリース後～次のリリースまでに問題が起きたらhotfixする」のようなワークフローが作られています。 逆に受託開発（特にアプリ開発）は「n月末までに納品物を作る。あとは知らん（契約によるからね！念のため！！）」という流れです。git-flowのワークフローは大仰すぎて、あんまり受託開発向けじゃありません。 じゃあ、なんでgit-flowを使うのか 有名だからというのが一番の理由です。完全な社内ルールとかオレオレルールを適用してしまうと、協力会社だけじゃなく、中途採用の人にも学習コストがのしか
マネージャーと開発者が安心してアプリ開発を続けるための開発ルール - Qiita
@eaglesakura です。 皆さん、進捗どうですか？ お仕事の規模が大きくなれば、参加人数が増えていくでしょう。 参加人数が増えれば、様々な宗教観の人がプロジェクトに参加するでしょう。 お一人様プロジェクトを中心にやっていた人もいれば、大規模案件のソルジャーとしてキャリアを積み上げてきた人もいます。彼らのスキルレベルもまちまちです。 私が参加している（そしてプログラマーに対して強い権限のある立場である）プロジェクトでは、次のようなルールをベースに適用しています。 これはなるべくプログラマーの負担をかけずに管理側（プロジェクトマネージャー＝PM）が開発管理を行える（進捗がブラックボックス化しない）ことを目的とした開発ルールです。 前提ルール ソースコード管理はgit/githubを利用する 1コミット（1ブランチ）に対して、複数Issueを処理しない githubはリポジトリ管理（作成
Android Studio 2.3から3.0へのマイグレーションポイント - Qiita
@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のバージョンが他のプラグインと競合するた
新人Androiderに導入してほしい環境 - Qiita
@eaglesakura です。 春ですね。新入社員の季節ですね。 前置きはこのくらいにして、「この環境を最低限用意してほしい」という一覧を書いておきます。 OS選定 Windows 10 or Mac OS をお勧めします。それ以外のOSを導入できるようなスキルがあるならば、たいていのことは自分でどうにかできるでしょう。 私はWindows10を使用しています。所属しているトップゲート社はほぼ全員Macを使用しているためマイノリティですが、下記のような理由で使っています。 購入時点でMBPより強力なCPUを搭載していた メモリ32GBを搭載可能 Visual Studioが使用できる GPUに選択肢がある 特にAndroidアプリ開発においてCPUとメモリは大正義です。メモリ8GBは人権がありません。低消費電力モデルのCPUもあまりオススメしません。 「デスクトップPCを買えよ」みたいに
１回のGoogleログインで、モバイルアプリ・自社サーバー・Googleサービス・Firebaseを連携させるフロー - Qiita
１回のGoogleログインで、モバイルアプリ・自社サーバー・Googleサービス・Firebaseを連携させるフローAndroidGoogleAppEngineFirebasegooglecloud @eaglesakura です。 アプリ（Android/iOS）とFirebaseはFirebase Authを使うと簡単に認証を行えます。 ですが、単純にFirebase Authだけを使うと、自社サーバー（Appengine含む）からユーザー権限でAPIを呼び出せず（例えばユーザーのGoogle Driveにアクセスする、等）、サーバーとアプリ両方の認証が必要になるなどユーザーとしては認証が複数回発生して煩雑になります。 自社サーバーとGoogle APIとFirebaseを連携させ、なおかつユーザーフレンドリーさを保つために「一度のログインで全リソースへのアクセスを行なう」ために必要な
Daggerは嫌だが、DIは試してみたかった / Androidアプリを開発する際の俺的設計 - Qiita
@eaglesakura です。 結論から言うと、DIは怖くないぞ。 DI(Dependency Injection, 依存注入)は昨今のプロダクト開発では当たり前のように使われています。 DIそのものに関しての解説は参考URLを読んでください。 参考 http://qiita.com/hshimo/items/1136087e1c6e5c5b0d9f 私自身は今年になって担当案件の開発規模が大きくなり、それに従ってUnitTestや依存関係が増えてきたことで、スマートな依存解決を求めて「どんなもんだろうな」と調べるようになりました。 遅いですか？ 遅いですね。 AndroidのDIライブラリ 一般的なAndroid界隈の開発では Square/Dagger やそれをForkした Google/Dagger2 が有名です。 なぜDagger系ライブラリを使わなかったのか コードの追いづらさ
Activity,Fragmentの分割と協調動作の具体例 / Androidアプリを開発する際の俺的設計 - Qiita
Activity,Fragmentの分割と協調動作の具体例 / Androidアプリを開発する際の俺的設計Android @eaglesakura です。 社内でプロジェクトのメインプログラマーとしてコードレビューをする機会が増えてきたので、私の考えるActivity/Fragmentの基本的な設計方針を解説します。 この実装はあくまで私が考える範囲での設計です。この考え方は2016年Q3現在のものです。 事前に読んでおくべき記事 ActivityやFragmentに関してはこの記事も読んでおくと良いです。 参考 https://developer.android.com/training/basics/fragments/communicating.html 参考 http://qiita.com/HideMatsu/items/ddf640899cbe1b2027ed 参考 http:
Cygwin環境でjavacコマンドの出力が文字化けするのを改善する - Qiita
Windows 10 + Cygwin + ConEmu Cygwin環境+Tabを実現するため、ConEmuを使用している。 問題点 javac(Gradle経由を含む)を実行すると、エンコーディングの問題で出力が文字化けしてしまう。 IDEでは正しく表示されるので実害はあまりないし、年単位で放置し続けていたが、気持ち悪いので直すことにした。 豕ｨ諢・荳�驛ｨ縺ｮ蜈･蜉帙ヵ繧｡繧､繝ｫ縺ｯ髱樊耳螂ｨ縺ｮAPI繧剃ｽｿ逕ｨ縺ｾ縺溘・繧ｪ繝ｼ繝舌・繝ｩ繧､繝峨＠縺ｦ縺・∪縺吶�・ 豕ｨ諢・隧ｳ邏ｰ縺ｯ縲・Xlint:deprecation繧ｪ繝励す繝ｧ繝ｳ繧呈欠螳壹＠縺ｦ蜀阪さ繝ｳ繝代う繝ｫ縺励※縺上□縺輔＞縲・ 豕ｨ諢・蜈･蜉帙ヵ繧｡繧､繝ｫ縺ｮ謫堺ｽ懊・縺・■縲∵悴繝√ぉ繝・け縺ｾ縺溘・螳牙・縺ｧ縺ｯ縺ｪ縺・ｂ縺ｮ縺後≠繧翫∪縺吶�・ 豕ｨ諢・隧ｳ邏ｰ縺ｯ縲・Xlint:unchecke
俺的Androidアプリ開発の基本方針 ver 2016.Q3 - Qiita
前提 @eaglesakura が務めているTopgate社は受託案件が多いので、この方針が絶対ではない。受注元によっては好き放題できるし、受注元によっては条件が厳しくなる。 また、弊社のAndroidアプリ開発は1人～数人で行われることが多い。そのため、この方針は更に大規模な開発では通用しない可能性があることも承知している。 その辺りは 以前の記事 でも書いたとおり。 ここに書いた方針はその時々の状況（公式ツールやSupport Library、流行り廃り）によって変化する。が、こういう構成になったのはその時時の理由があるわけなので、明文化することで後々「なぜこういう構成にしなければならなかったのか」ということを思い出せるようにもしておきたい。 環境整備 ソースコード管理 制限が無いのであれば、githubで管理する。githubのissueはRedmineに比べると機能的に不十分である
さよならButterKnife. 僕はAPTの無いキミが好きだったよ - Qiita
一身上の都合により、ButterKnifeを捨てることにしました。 かなり個人的な理由ですが、ButterKnifeを捨てる理由を挙げていきます。 Androidアプリ開発でのButterKnifeの便利さ ButterKnifeはいかに便利であるかは、Qiitaで"ButterKnife"と検索すればたくさん出てくると思う。Java標準機能である"Annotation"を駆使して、findViewByIdやsetOnHogeHogeListenerを駆逐してくれる、便利なライブラリだ。 この「findViewByIdやsetListenerの代わりにAnnotationを用いる」という基本的なところは大いに賛同するし、Android Annotationを始めとして幾つかの人気ライブラリはそういった便利さを提供してくれている。 ButterKnifeに足りないもの ButterKnife
Android Nで気づいたことメモ - Qiita
Android NをNexus9に導入したので、個人的に気になったことをツラツラとメモしていく記事 Tegra Graphics Debuggerに接続できない Rootedできるようになるのを待つしか無い 多分Rootが取れれば追加のデバッガをインストールできるはず OkHttpの仕様変更でHttp Headerの内容に制限が入った 言語を日本語にしている状態でKindleの書籍DLができない Logcatを見ると、ヘッダに日本語（時刻のtoStringっぽい）を含めようとしている URLConnectionの脆弱性対策が入った模様で、英数などの特定範囲の文字しか受け付けなくなったらしい https://twitter.com/hydrakecat/status/709788601274507264 https://twitter.com/hydrakecat/status/709788
Retrolambda+RobolectricでUnitTestするときのメモ - Qiita
Androidアプリ開発でラムダ式使いたいよね インデント量が減らせるし、慣れれば可読性が保てるので導入したいよね。 Retrolambdaを導入してみた JDK1.8入れて、Pluginを導入するだけなので簡単に導入できる。 // build.gradle buildscript { dependencies { classpath 'me.tatarka:gradle-retrolambda:3.2.5' // support Lambda } } apply plugin: 'me.tatarka.retrolambda' /* Android Lambda Support */ Picked up _JAVA_OPTIONS: -Dfile.encoding=UTF-8 :app:compileGoogleplayDebugUnitTestJavaWithJavac javacTa
公式BottomSheetDialog(23.2.0)がリリースされたけど挙動が気になったのでちょっといじった【そして23.2.1で直った】 - Qiita
公式BottomSheetDialog(23.2.0)がリリースされたけど挙動が気になったのでちょっといじった【そして23.2.1で直った】Android 最初に この記事に書いてあることは23.2.1で修正されました。よって、普通に使って問題ありません。やったね！！ （23.2.1での直し方も、この記事で紹介しているのとほぼ同様でした） Design Support Library 23.2.0がリリースされた BottomSheetDialogというのでBottomSheetがカジュアルに使えるようになりましたが、ユーザーがダイアログを引っ張り上げすぎると勝手にDialogがcancelされてしまうというあんまり好きじゃない挙動があります。 これが公式なのか意図しない挙動なのかはわかりませんが、現時点ではどうにも直す手段が提供されていないように見えるので、ソースコードを引っ張ってきてち
Android案件を見積もる場合に考えておくことリスト - Qiita
アプリ自体のコーディング見積もりのみに注力してしまうと忘れがちで、たまにつらい目に遭うので、必要に応じて追加していく予定。 アプリ仕様 仕様はそもそも決まっているか 「仕様は決まっている。動かない」「移植なのでこれ以上はありません」と言ったな。 それは嘘だ。 既に仕様がガッチリ確定していることはありえない。要求仕様（必要機能リスト）がある程度固まっているならばまだ良い方で、「今から仕様を一緒に考えていきましょう」「アイディアレベルです」まで様々。 その他にも、GCM/FCM等のアプリ外サービスと連携する場合、遅延コスト等どの程度許容できるかも事前に確定させる。特にプッシュ系サービスでは、ありえないレベル（全端末遅延1秒以内必須、とか）を既定路線に含めないように留意する。 改修か、新規開発か これは見積もりの前提として大きな影響力をもつ。 テクノロジーや設計の自由度・柔軟性をある程度コントロ
Android StudioのNDK開発機能を使おう！ - Qiita
@eaglesakura です。 5月のGoogle IOでAndroid StudioのNDK対応が発表されてからずっとNDK対応するする詐欺を１ヶ月半されてきましたが、7/10のアップデート(Android Studio 1.3 RC1)でようやく待望のNDK対応アップデートが行われました。 使った感じはかなり良いのですが、前提条件やハマりどころが多いので、自分用のメモを兼ねて投稿します。 準備 準備を行わずにASのアップデートのみを行っても、NDK機能は全く動作してくれません。また、ビルドも行ってくれません。 そのあたりのツイート http://twitter.com/eaglesakura/status/619305979318939648 http://twitter.com/eaglesakura/status/619306946579992576 http://twitter
Eclipse+Ant勢にオススメする、Android Studio+Gradleに移行すると手に入る便利機能 - Qiita
Eclipse+Ant勢にオススメする、Android Studio+Gradleに移行すると手に入る便利機能AndroidAndroidStudioandroid開発 @eaglesakuraです。2013年にAndroid Studioが発表されて、だいたい1年ちょいが経過しました。最初は不安定でアレな感じだったAndroid StudioとGradleプラグインもそれなりに安定してきて、普通のAndroidアプリを開発する分にはあまり困らなくなりました。 現在は移行期にあたるため、2014年のEclipseを使っている人も多いと思いますので、「Android Studioって正直どうよ？」っていう人たちのためにEclipse+Antにはない利点を列挙していきます。 ビルドがGradleに統合される 最大の利点で、コレが移行するための大きな動機であり障壁です。Gradleはそこそこ新し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
