Monthly Archives: December 2011


Spark::red 2011 Review and 2012 Preview

2011 has been an amazing year for Spark::red ATG Oracle Commerce Hosting.

  • We’ve added several new clients (including a well known member of the Fortune 1000!)
  • We’ve added 101 new dedicated servers and over 20 cloud computing instances
  • We’ve opened an office in Boston
  • We’ve earned our PCI Level 1 MSP Certification
  • We’ve hired several […]
By | December 26th, 2011|ATG|2 Comments

Siri Reminders flow into OmniFocus

I just discovered that you can setup OmniFocus to pull from your iCloud synced Reminders. That means if you use OmniFocus, as I do, that you can create new ToDo items via Siri:

Siri, remind me to call Bob […]

By | December 12th, 2011|Apple|2 Comments

The Twelve Factor App Review – part 2

Now I’ll tackle the last 6 factors:

7) Port binding

They say that every application should internally provide it’s own network protocol servers and not rely on containers like Apache or Tomcat/JBoss.  I think this is kinda nutty, not just because I write apps that use containers, but because network protocol servers are extremely hard to do well.  Security, performance, scalability, standard protocol implementations, etc… are all very hard to do.  So presumably you’d want to roll in some sort of third party library for that, at which point using a container is the same or better.

8) Concurrency

Again, throwing Java and PHP under the bus, they tie back to “factor” number six where everything is stateless.  They also ban PID files, daemon processes, etc…  What they’re proposing is so far outside anything I’ve done or seen anyone do in a real world app I don’t even know how to respond.

I’m not sure how spinning up large numbers of processes on the same hardware works with the idea of having to vend all your own network servers.  How do you handle port binding, port conflict, and port discovery across a cluster?

9) Disposability

This ties back to “factor”s six and eight, stateless standalone processes which can spawn and die quickly without any impact to the overall system.  This forces you to avoid caching, anything complex, and so on.  I’d much rather have big powerful instances with caches, stateful data, a mature container, solid network systems, and all that.

Building a system around stateless job queues and assuming that instances can and will die often enough to warrant building a system around that seems like an odd place to spend your effort.  Big JBoss instances are VERY stable.  They run and they run and they run for months at a time without issue.  There’s no need to build complex queues and job management system, relying heavily on your external systems (like your database, message queues, redis, etc…) to handle all your state because you’re scared to do it yourself.  I’m not sure why relying on MySQL or RabbitMQ for long running state management is any better than just having your app do it.  Let parsing, network overhead, and re-work.


By | December 2nd, 2011|General|2 Comments

The Twelve Factor App Review – part 1

I don't agree with the Twelve Factor App guidelines, and here's why.

By | December 1st, 2011|General|11 Comments

How to Make an Impact During the First Month of Your Startup Job

How to Make an Impact During the First Month of Your Startup Job

By | December 1st, 2011|General|0 Comments