Microservice architecture: breaking one large, monolithic app with lots of functionality into a network of small apps that all communicate with each other.
This architectural style addresses two frustrations associated with building monolithic apps:
Continue reading “When Not to Use Microservices”
I’ll call this post “When and How I Use Robolectric” instead of “When and How to Use Robolectric” because a) I don’t like telling people when and how to do things, and b) I use Robolectric less liberally than most developers who use it.
Robolectric is a fantastic tool for ensuring that stuff in your Android app works properly. The problem, as you may have heard me say before, is that it runs slowly. In particular, FragmentTestUtil’s operations are especially time-expensive. Compounding the issue, Robolectric 3.0 currently has a memory leak that causes the heap to get bigger than it should. You won’t notice it on a smaller app, but when the app grows enough for the test suite to hit 600 or 700 Robolectric-assisted tests, the suite will hang or stop running because it runs out of memory before it completes.
So you only have 600-ish Robolectric bucks in the bank, and you spend one every time you write a test with Robolectric. My team at work, and I at home, have experimented with ways to save our Robolectric bucks. The first (main) trick has been to separate as much logic from the Android framework as possible and test that logic with JUnit. We save our precious Robolectric bucks this way, spending them on just a test or two for the places where the logic gets wired into the Android app.
Continue reading “Test-Driven Android: When and How I Use Robolectric”
This synopsis is a guest post by Matt Hucke (@matthucke), a developer at AutoAccessoriesGarage.com and one of the first people I met this year at Windy City Rails! It covers Justin Love’s talk on SQRL.
Shared secret password security is “rotten at its core”.
With a memorable image involving monkeys sharing far too much, Justin Love (@wondible) exposed the fundamental problems of typical web site password setups. What we want in an effective authentication system, he says, is unique identities, not reused from site to site, to protect us from the inevitable breaches that are far too frequent these days. A hack of Target or iCloud should not result in our email accounts also being compromised – for users will reuse passwords across sites, no matter how often we tell them not to.
Continue reading “Justin Love on SQRL (and the post-password authentication movement in general)”
This morning at Windy City Rails, Dinshaw Gobhai’s talk “Meet the SLAs: Rails at Constant Contact” started with an intimidating consideration: their application, which they intended to build on Rails, would have to serve multiples more requests than most Rails apps. With the “Rails doesn’t scale” idea making the rounds, how were they going to make sure that it did?
Well, at first, by writing two Rails apps: one for the UI and one for the logic. This required separate integration stubs, a node.js gateway, and a bunch of other workarounds that made the next 6 months very frustrating.
So instead, they switched back to one rails app, and learned an important lesson:
Continue reading “Dinshaw Gobhai on Speeding up Rails at Constant Contact”
I’m back at Windy City Rails! Dr. Nic started things off with his talk, “The New Era of Orchestration: From Docker to BOSH to Cloud Foundry.”
What’s Orchestration? Here’s a brief technical rundown, and here’s a more comprehensive one (thanks, Wikipedia).
First off, though, Dr. Nic mentioned a book called The Phoenix Project, and I’m a sucker for book recommendations so that’s getting a shoutout. If enough of you tweet Gene Kim, maybe we’ll get a discount code. They gave ChefConf 2013 50% off, and don’t see why we’re not just as good as whoever was at that conference.
Dr. Nic also mentioned this 12factor set of SaaS development orchestration guidelines.
Continue reading “Dr. Nic Williams on Orchestration”
For Thursday’s last talk at Windy City Rails, Sean Griffin (the guy to talk to about the problem you ran into with Rails 4.2 beta, by the way) discussed “The Functional Web: How Functional Programming Concepts Could Improve Rails.” The talk centered mainly on the lack of concurrency in Rails. It’s a problem that I’m sure has produced or would produce an interesting discussion over drinks with Brian Shirai, our ambassador at the conference for Rubinius X, which, ICYMI, is trying to fix that (though in a decidedly object-oriented way).
Maybe we didn’t get all the jokes in the talk (sorry Sean), but it still left my interest piqued: Sean introduced to me a discussion in Ruby to which I had had little exposure before. TO write effectively about it, I had to look some stuff up. So, I figured I’d pass those resources on to you.
Continue reading “Sean Griffin’s Functional Web Talk, Plus Further Reading”
This afternoon at Windy City Rails, Yan Pritzker‘s talk, “Domain Driven Rails—Use Case Driven Simplicity,” went over how the Reverb application avoids this:
cartoon courtesy of bonkersworld.net
That is, how we go about avoiding finishing our app…and then having to refactor everything.
Continue reading “Windy City Rails: Yan Pritzker on Domain Driven Rails”
I had a limiting belief that went something like this:
A multi-functional app takes days to build, if not weeks, months, or years.
For many multi-functional apps, this is true. That said, it’s always useful to challenge one’s limiting beliefs about their craft. What better way to do that than to code a multi-functional app in 24 hours or less?
The app creates links businesses might use to analyze where clicks to their website come from: it has visit tracking for each link, geographic tracking for each visit, and a graph how many visits are coming from each link.
And yes, it’s real: you can make an account and use it, if you want to :). Check it out on Heroku, or see the code on Github.
Pictures below, plus an hour-by-hour breakdown:
Continue reading “Zero to Bit.ly (with analytics!) in 8 Hours”