Dangerで始めるPull Requestチェック自動化 - コネヒト開発者ブログ
こんにちはー！こねひとちほーのえんじにあのフレンズ@Utmrerだよー！ 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…？ タイトルにIssue Idを含めてもらえますか？ WIPみたいなんですがレビューして大丈夫ですか？ Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F
メルカリ カウルの開発気になる？なら話そう！
メルカリ カウルの開発 気になる？なら話そう！ shibuya.apk #17 https://shibuya-apk.connpass.com/event/62499/
何もコミットしないスプリントで各自好きなことをする
何もコミットしないスプリントで各自好きなことをする インクリメントの完成に高いコミット意識をもって毎スプリント取り組んできている CS 開発チームがいくつか大きなリリースを終えたので、スクラムマスターと相談して今日からの1週間スプリントは「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良いことにしました。 リファクタリング・技術的負債の返済・開発環境の整備や、調査・学習・ドキュメントの整理など、いつものスプリント中にはなかなかできないことを各自でしてよい1週間です。 普段から持続可能なペースを意識してスプリントプランニングしていますが、それでも頑張り続ければストレスも溜まってくるでしょう。適切なタイミングでブレイクを挟むことで、バーンアウトを防ぎ長期的にデリバリーし続けられるチームでいられればと思っています。 ちなみにこの取り組みは去年別のチームが unw
iOSで消費型プロダクトのアプリ内課金を実装する際の注意点 - Blog :: Meatware
TODO:コード例を載せる Consumable なプロダクトの In-App Purchase は、クライアント側でのアプリ内課金と、サーバ側でのアイテムの付与が１対１になっている必要があります。 課金をしていないのにアイテムの付与をする、あるいは課金をしたのにアイテムを付与していない、という状況は許されません。 今回は、正しくアイテムを付与するためにはどうすればいいのかについて書きます。 正しい付与のやり方 iOS の消費型 IAP ってめんどそうだなぁとか思ってたけど、よく考えると、クライアントは正常に成功か失敗が返ってくるまでリトライする、サーバは１個のトランザクションで１回だけアイテムを増加させる、というルールさえ守ってれば何とかなりそうな気がする。 — めるぽん(ヘルニアン) (@melponn) 2013, 12月 5 本当に重要な部分は、これだけです。 iOS でアプリ内課
マイクロチームでの高速な新規開発を支える開発・分析基盤
マイクロチームでの高速な新規開発を支える開発・分析基盤 by @__timakin__ Builderscon2017でのプレゼン内容です。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
