Congratulating a company for getting funding is a lot like congratulating a couple for getting engaged.

Because of our involvement in the Atlanta startup scene, we talk with many startups in various stages of development. Among those that have either yet to build or have simply built a test product, the topic of technology stack comes up often. Specifically, what type of a framework to use.

What framework-based technology stacks are out there? Here’s a partial list:

• Ruby on Rails
• Python on Django
• Groovy on Grails
• PHP on CakePHP or Zend
• Scala + Lift
• There are way more and as always, Wikipedia knows what they are

If you aren’t a supernerd, making a decision about which to use can be overwhelming. Our view is that in most situations, the reasons for picking one technology stack over another are for business reasons, not technology reasons. Most frameworks are equal, but different, and each have their own strengths and weaknesses.

As a startup, here are what your goals for making a choice should be:

• There are talented and hirable developers that know the framework (or have the desire to learn it)
• The framework has been around long enough to be in a stable state
• There is a decent sized (or growing) community of developers that have written open source code that you can leverage

If you can reasonably meet these goals with your technology stack, then there’s really no wrong decision for a startup.

Dreaming big is wonderful and everyone would love to have 1,000,000 users by day 10. The fact is it’s usually not going to happen and if it does you shouldn’t have a problem finding the funding to fix any technology problems that come up.

The last thing I’ll mention is .NET. Our opinion is that it should be avoided in a startup situation. Here’s why:

• It’s more expensive than Linux based solutions
• It’s not cool (possibly unfair, but true), and talented developers want to work with cool stuff
• .NET (and Java) are typically used in enterprise environments and it takes a different kind of person to succeed in a startup environment

If you want to read a very heated exchange on the topic of bullet #3, you can do so here.

The US Congress is considering America’s first system for censoring the Internet. Despite public outcry, the Internet Censorship bill could pass at any time. If it does, the Internet and free speech will never be the same.

Click the link in the top left corner of this site or go to the link below for more information.

http://americancensorship.org

On my personal blog, I had a running series called Design Whine, where I posted about things I found with poor design (in my opinion). I made one post. I’m hoping to continue that blog here but supplement it with something on the positive side. So, without further adieu…

A friend of a friend posted this on facebook and I wanted to share it because it matches our design philosphy. Simple. Clean. Minimal. Modern. If you wear contacts, help Beverly meet her goal!

Tom (@tom_odea)

…okay…I’m impatient when it comes to everything. Yesterday, I told my wife she needed to get home at 5:00 to make our dinner reservation. She showed up at 5:30. Obviously, I was not too happy. However, being the compassionate, understanding and forgiving husband that I am, I was able to get over it quickly. When it comes to me and my development environment, I possess none of these redeeming personality traits. I can’t stand waiting for anything.

Rails is so fast when I create a new project.  However, as time passes (or you inherit an already massive project), then the project slows down to the point where I notice some lag. Now, these lags may be 100% my fault (code bloat, poorly structured DB queries, etc.), but when I see the same transaction take 10x less time to complete on my production server, my eyebrows start inching up my forehead.

Eventually, I focused my frustrations to a google search and I stumbled upon this little gem: https://github.com/thedarkone/rails-dev-boost (if you’re a nerd like me, you’re really enjoying that double entrendre right about now). It sped me up by a factor of about 5x (according to my Rails log). Sweet!

I have had problems where I change my models and weird things start happening, so I have to restart my server. However, the documentation for the gem seems to cover some situations that fit that description, so it looks like it’s me and it’s fixable (whenever I get to it).

Sam (@samwduvall)

“Being a professional is doing what you’re supposed to do even when you don’t want to.” - Unknown

In my previous embedded programming life, I thought databases and SQL were synonymous.  I also thought MySQL and SQLite were the only games in town. My ignorance knew no bounds. Enter my long time, webniscient (web-omniscient) friend @deanlandolt. He turned me on to NoSQL and eventually my journey towards enlightenment led me to Mongodb. I decided to compile some reasons why I now love Mongodb. Enjoy.

JSON

It was only two years ago, when I byte encoded EVERYTHING…the agony. It was only one year ago, when I learned to encode/decode XML…the waste. Ilove JSON. Everything I do is either a hash or an array…the beauty. I love how Mongodb stores documents as JSON (well, technically BSON). It just blends naturally to how I code.

Embedded Documents

Here’s a typical example scenario: 1 Question has 4 possible Answers. In an SQL database, that is 5 entries spread across 2 tables…the waste. With Mongodb’s embedded documents, those 4 Answers are embedded into the Question - beautiful! Once I find the Question I’m looking for ALL of the data associated with it is there. Done. Next.

No Migrations in Rails

Rails migrations are the Erie Canal to the Erie Railroad… totally useless. I don’t want to do a bunch of crap to add my new field when it doesn’t affect anything else in the database.

There is so much more

I’m just scraping the surface of Mongodb’s capabilities. I hope this entices more people to try Mongodb, so the community gets bigger and there are more people to answer my questions and fix the problems I haven’t found yet.

As always, I know a lot, but I know there is a lot I don’t know, so if you know something I don’t know, then let me know.

Sam (@samwduvall)

For a few minutes (or conveniently timed seconds) today, this blog was offline due to overcapacity on tumblr’s servers, which is what we use as a blogging engine. Users of our site would have received this message:

It’s not as good as the TumblBeasts, but we understand why it might not be a good idea to serve a 100k image to millions of people that are already overloading your servers. I digress.

The problem I have with that message (and the TumblBeasts’ message) is that tumblr doesn’t put their name on it and thus, doesn’t take responsibility for the downtime. Most of our users wouldn’t even know that they’re on a tumblr page (our blog address is blog.rocketwhale.com), so they would assume that it’s OUR servers that are down, not some 3rd party’s. This looks bad for us, a web design and development company.

This sounds like sour grapes (after all, we agree to their Terms which state that they aren’t liable for any downtime), but I’m not upset whatsoever that their server went down. That happens to everyone, and we understand that as much as anyone can. The upsetting thing (I’ll admit, it’s pretty minor) is that they’re passing the buck onto us by not putting their name on their error page.

I’m sure it isn’t intentional. We love using tumblr and have no indication that they aren’t a company full of terrific people. But when a customer of yours can question your integrity, it isn’t good. We all make mistakes. Learn from them and just as importantly, own up to them. Doing so will give you more productive relationships.

Tom (@tom_odea)

I saw a tweet the other day from a respected Atlanta entrepreneur and developer bemoaning Facebook’s recent release of an iPad app. His thought (hope? wish?) was that we were past the days of platform specific development and, with the rise of the non-IE browser, had entered an era of platform independence.

Develop for the Web, Optimize for Mobile/Tablet?

It’s a wish that many entrepreneurs and developers have. Even though developing for one platform - the web - is going to get worse, it’s still better than doing web + Mobile (iOS/Android/Windows?) + Tablet (iOS/Android). Unfortunately, the world isn’t ready. Here’s why…

Browser Technology

Desktop browsers have come along way since Internet Explorer 6 (or, you could argue, IE9). But this article isn’t about web apps vs. desktop apps. It’s about mobile or tablet optimized web apps vs. native iOS/Android apps. One of the great things about mobile browsers is that the big 3 operating systems all have native webkit-based browsers, and thus support up-to-date HTML/CSS standards (and then some). They can even provide off-line access to content. But they still can’t do everything a native app can do, like access the camera, address book, geolocation data or accelerometer. If an app needs any of this functionality, it simply needs to be native.

Performance

There are 2 performance issues that must be solved.

First, mobile devices need more power. Browser-based apps have an extra layer (the browser) between them and raw processing power. That layer slows things down and, because phones just don’t have the power, is much more noticeable on a phone than on a PC. Energy efficient, dual-core phones are just this year entering the market and it will take a couple of development cycles before they’re pervasive.

Second, mobile networks in the US are slow. Until these networks achieve true broadband functionality, a web app cannot perform like a native app. This is going to take a few years (or longer).

Marketing

It’s simple - people shop for apps in app stores. Blame Apple if you want, but this behavior has become the norm and is how people explore and find new apps for their phones. If you’re building an app that you want people to discover without first finding and using your web app, it needs to be native and available in an app store.

What It All Means

I think we’re watching the desktop story play out once again. Native apps will reign supreme until mobile and tablet browsers can deliver the same or similar experience that a native app can. Eventually, we’ll reach a tipping point where users will feel comfortable venturing outside of an app store to find and use a mobile-optimized web app. The main driver will be performance and it’s going to take a while for mobile browsers to match a native OS in performance and capabilities.

Will it ever happen? Sure. But unless your app doesn’t need native hardware and you don’t care if people find it outside of your web app funnel, you should plan on creating platform-dependent software for the next few years.

That’s a big win for companies like PhoneGap and Appcelerator.

Tom (@tom_odea)

Now that I’ve got my Push Server up and running with faye (see Part 1), it’s time to harness it to make something useful.  On https://howtracker.com, users can collaborate on checklists and perform various actions including marking checklist items as complete. Many of our users leave HowTracker open all day, so they can’t see what others are doing unless they refresh the page.  Push notifications to the rescue!

Security

Before we can design anything, we need to address security issues.  Push Notifications are very powerful, but they need to be used responsibly.  HowTracker has SSL, User Authentication and Access Restriction. Thus, we cannot broadcast everything to the entire world over an unencrypted socket or someone could reconstruct our database eventually.

SSL

SSL was a snap.  We already had our SSL certificate, so it was just a matter of configuring the faye server. Read the faye documentation here for help.

User Authentication and Access Restriction

These two are very similar.  Users need a private channel that only they subscribe to. Objects with Access Restriction (i.e. a Checklist) need a private channel that only users that have access to that object can subscribe to.  Ryan Bates, of Railscasts fame, created a nice little gem private_pub to facilitate this process.  In short, private_pub distributes the key to subscribe to a push channel, which makes that push channel private.  Perfect, but we’ll need to extend it a bit to suit our specific needs…

Client/Server

The HowTracker server is pretty much solely an API.  It does not generate much HTML, but it does generate a bunch of JSON. Thus, the HowTracker client does everything through AJAX calls. We leverage backbone.js heavily to do the real work of rendering the page.

Rails Routes and Push Channels

Rails Routes and Push Channels are mirror images of each other. Using a basic Rails routing example an object routes on the server to /objects/:object_id and a push channel is created /objects/:object_id. When you request an object (should you have the proper permissions), the server responds with the object AND the push channel subscription key. Thus, the client receives the object in its current state and can subscribe to changes via push. Beautiful.

Backbone.js Views

There was a bit of refactoring involved with our existing Backbone.js views. Anytime an event was triggered the same function would update the view and update the model (and update the model on the server via AJAX). This is no good as incoming push events should only update the view.  We had to break up the view functions from the model functions and have the view functions bind to model events.

Feel free to go see it in action at https://howtracker.com. You’ll need two accounts to see push notifications in action, so go sign up a friend!

Sam (@SamWDuvall)