Posts tagged: tools

A couple weeks ago, I reached out to the guys at Count.ly to express frustration that the SDK didn't persist events and data.

It's a big problem. If the device isn't connected for a period of time, or the server fails to respond, the SDK would drop the data off into oblivion. The SDK should be able to store the analytics offline easily, and then upload them when the connection becomes available. Now, with a little bit of Core Data work the developers at Count.ly have added event persistence to the SDK.

I was surprised that instead of spending time building the platform they were working on front end clients. You'd think the platform developer would focus on the platform.

I'm impressed that they listened, and I'm even more impressed that they responded so quickly. I hope that they are able to keep moving forward swiftly with a strong focus on their platform.

Adding persistence is great, but will this be something they struggle with frequently? Choosing product over platform? 

  • Charging $50 a month for cloud analytics that can be hosted on DigitalOcean for $5?
  • Having a web dashboard for a mobile analytics platform that can't be viewed on a mobile device?
  • Spreading themselves thin on countless platform SDKs rather than knocking a select few out of the park?

I am a big fan of what Count.ly has, but I'm afraid I've been attaching myself to a ride that's veering off the road.

How we use GitHub as a killer bug tracker and code review tool

I like a place to organize my bugs and features. I don’t like to double track in my own to-do list and in a bug tracker. I’m also a huge fan of code review. It was important to me that code review integrated well with my bug tracker.

Enter GitHub and Hub

I’ve started a few team projects, and haphazardly ended up using GitHub for bug tracker and code review. Once I found that Hub converted issues into pull requests, I fell in love. My team has a very simple workflow for code review. (This could work well for individual projects as well by simply skipping the code review step.)

Planning and bug tracking

  • Create milestones in GitHub Issues
  • Create issues for features or bugs for each milestone

Development

  • Create a branch for each issue you start work on

    git branch –track issue8 origin/issue8

  • Push to the branch on GitHub (You can commit/push as much as you want to this GitHub branch)

Code submission and review

  • Convert issue into pull request with Hub

    hub pull-request -i 8

  • The code can be reviewed on GitHub by a co-developer

  • Changes are pushed to the branch and GitHub tracks commits in the pull-request thread
  • Once the code is ready — Merge

Rinse and Repeat

  • Rinse: delete branch
  • Repeat: create another branch for another issue  

Tracking branches

The only step that felt like extra work here was adding branches for each issue. However, once it became habit I can’t imagine it any other way.

We have a master branch that is merged into, and a release branch that gets updated with each milestone. It seems natural that each issue/feature has it’s own branch to update and merge.