Swimming the Matrix

Disincentives for Doing Things Right

Ask most programmers, and they’ll tell you the proper way to do things. They want Agile project management with two week sprints, they want automated Continuous Integration testing, they want DevOps workflows with rolling releases. They want things done with a quality and a perfection that will make for a flawless system.

The problem is, we never get that system. And even when we do, things get screwed up. We start with the CI system, but as deadlines close, we start skipping the test writing. We stop commenting our code and stop having meetings in a furious desire to hit the deadline.

And there’s our problem.

Software development, like most industries, is in constant flux with regards to delivering products. Better automation, toolsets, and methodologies make it easier than ever to create software, but also leave us with new challenges, most of which many companies ignore, expecting that using Ruby over Java will magically fix all their problems.

Management holds a lot of the blame for this. I know I’ve told developers on at least one occasion that we couldn’t test everything properly: there just wasn’t time in the budget for it, or the client didn’t pay enough for it. And I was wrong to do that, if I truly wanted a high-quality product, something my company at the time advertised that we did, what made us “different.”

The real problem, however, is that there are plenty of things we do that have no bearing on doing actual development, that set developers up for failure and actually encourage them to get things done poorly.

1. Rushed Deadlines

This one drives me up a wall, since I see it at almost every company. Management, for whatever reason, sets a deadline of X days in the future, then tells the dev team it needs to be done in this time. At no point will they talk to the dev team about the deadline to even see if it’s feasible. The best manager I ever had had this as his only flaw: he would ask me if something could be done in two days only after he had promised it would be done to upper management. I made him look bad a few times when I told him it couldn’t be done, there was no physical way to do a brand new mobile app in two days.

This is a real bad practice because it reinforces two principles in your developers: “You are not a part of the discussions about how best to accomplish a project” and “Deadlines are meaningless.” When you’ve broken the engagement with a move like this, you are treating your professional problem solvers (which is what pretty much any engineer is at the core of it) and tell them this is one problem they are not allowed to help solve. You’re demeaning their expertise in their craft. Keep in mind: No one knows better than they how long it will take them to do any task. It’s always best to ask first.

In any case, when a deadline isn’t agreed upon, and you’ve done your own project estimation, you aren’t getting a commitment from the developer on the work. You can’t say, “well, they were slow to finish it” when they never agreed that it could even be done in the timeline set.

A far better practice is to go to the developers, outline the task, project, etc. and get their feedback. You both mutually agree to a timeline, then you hold them to that timeline. That way, you’ve sought out their expertise, made them feel valued, and gotten a commitment from them for that deadline, so if things are going slow, you can use the point that they told you it could be done in that time to hold their feet to the proverbial fires.

2. Team Code Reviews

Ask most developers their least favorite part of their job, and they’ll most likely say code reviews if their company does them. For those not familiar with it, code reviews are team meetings where you get all the developers together, and look at everyone’s code, pointing out points of improvement for everyone. The goal of the code review is to make sure there aren’t any glaring issues (usually easily spotted by developers not familiar with the code but something that will escape the main developer’s eye). The problem is, in most companies, it turns into a blame game. Developers, being people with the full range of human emotions, can deliver biting remarks, calling out bad code and generally making a developer look incompetent to management, even if what they’re doing isn’t wrong, but a different stylistic choice. It often devolves into an argument about the best way to do something trivial like sort numbers.

While it’s a great idea to review a developers code, code review meetings are probably one of the worst ways to do it. Better ways are to have blind code reviews, where developers are not told whose code they are reviewing. This will cause them to give a more honest answer not tainted by how they feel about the developer (positive or negative). Management can then take that feedback to the developer, and present it in a less hostile way. I did my own code reviews for a company whose dev team I managed, and doing it in this way led to higher code quality, fewer defects, and greater developer productivity, because we didn’t need to waste hours having everyone look at the same block of code, when one person was enough.

3. Keeping Dead Weight

There is nothing worse for a talented team than keeping on dead weight. By dead weight I mean developers who don’t produce quality code, are constantly delivering late, or have a horrible attitude. Top performers of any job don’t want to carry the weight of others, and have to pick up the slack. On top of breeding resentment, the increased stress can cause burnout and even cause your best talent to search for opportunities elsewhere.

It also sends the message to the less motivated of your team that you won’t punish poor performance. This can cause your middle-tier workers to start slacking off, thinking they don’t have to work as hard if it doesn’t matter if they hit deadlines, write quality code, etc. In extreme cases your best performers might feel the desire to “give it their all” wane in the face of the current reality that doing well just gives them more work to do.

Which brings us to…

4. Not rewarding good work

As humans, we tend to focus on the negative. It’s what pervades our news, and it’s there because we remember the bad more than the good, as skewed as that might be. So it’s easy to have the squeaky wheel approach to management, where you ignore those who are doing good work in favor of focusing on those employees who are a problem.

The problem is, like training dogs or children, we need positive reinforcement as much if not more than negative reinforcement. A simple “you’re doing a good job” takes no effort at all, doesn’t require you to jump through hoops with the finance department for approval, but can have a huge impact on morale. Everyone wants to be told they’re good at something (possibly because at some point in the day we feel like we aren’t).

If possible, things like raises or bonuses are great ways to reward continuous good work, but there are plenty of other minor things you can do as a reward, such as buying the team lunch on your own dime if they’ve really been getting things done, or even telling them to take a Friday off if you’re ahead of schedule. Again, those kinds of actions don’t require jumping through bureaucratic hoops to get it approved (usually).

5. Taking credit and deflecting blame

The worst managers make sure that everything good is because of them and everything bad is someone else’s fault. Yes, if your company structure is such that you are the only one meeting/talking with the people above you, it’s easy to steal credit. But that doesn’t make it right ethically, or mean that’s the best way to get ahead in your career, as smart managers above you will notice that trend and hold it against you.

As part of this discussion, throwing your developers under the bus when things go wrong, especially if it’s actually something you did, will cause your team to distrust you and definitely encourage them to do less than their best, especially if they know that any success they have will be going on your CV instead of theirs. Vindictive developers may even sabotage the project to try to make you look bad.

Instead, managers should always talk in a positive manner about their team to upper management, and especially attribute success to the people who brought it about. Remember: managers are there primarily to help keep everyone organized and tasked out, and to relay communications and orders from higher up the chain. You aren’t the one writing code, so the fact that a function works without error is due to the developer, not due to you telling the developer to do it.

Published by meatshield, on July 26th, 2014 at 2:15 pm. Filled under: UncategorizedNo Comments

Politics and Business

Anyone who has started a company with me knows I have two main rules when I start a business:

  • I don’t want to succeed at the cost of my ethics and morals
  • I don’t want us bringing politics and political views into our company

I get a few arguments for both points, but the more interesting one is the second. I understand why some companies want to become involved in politics. They’re heavily regulated, they want to be less so, or have laws more in their favor, and spending a couple million on lobbying can save them billions. And, for the most part, unless you do something crazy like Chick-fil-a or Hobby Lobby, most people don’t care.

My problems with businesses involved in politics are two-fold: you’re throwing away customers and you’re acting like a person. By expressing any political belief, you are going to alienate some people. During the Chick-fil-a scandal in which they were caught supporting anti-homosexual groups, anyone supporting LGBTQ rights wouldn’t have anything to do with them. Hell, I still feel uncomfortable if I have to eat there, even after they stopped that practice. Now you can argue that the people who chose to eat there more often in support of their political beliefs might offset the difference, but the problem is that, on their side, their patronage drops off as well, returning to normal levels as the controversy fades. Scorned consumers, however, are much less likely to be forgiving, especially if it’s something like Hobby Lobby’s recent healthcare snafu.

Which brings me to point number two: businesses are not people. I don’t care what the Supreme Court says, you can’t equate a living, breathing person with the nebulous entity that only exists on paper. In Texas we joke that corporations will be people when we execute one. And that’s the difference: you can commit fraud, knowingly, as a corporation and pay a fine. Do that as an individual and you go to jail.

To that point, again, despite the Hobby Lobby ruling, you can’t tell me that you are your company. I am not Airvirtise. Airvirtise is not me. I am more than it and it is more than me. Airvirtise doesn’t play Pathfinder, and I don’t render OpenGL content on phones and process tons of data (thankfully. I’m terrible at math). If I die, Airvirtise goes on perfectly fine, and the same to me if the company folds. If I wanted a company to be an extension of my beliefs, I’d start a non-profit. Non-profits are made for that kind of thinking. And remember: just because it’s non-profit doesn’t mean no one gets paid.

Published by meatshield, on July 24th, 2014 at 1:23 am. Filled under: UncategorizedNo Comments

My Attempt at 30 Days of Social

I don’t consider myself a social person. I don’t have a lot of friends, I certainly don’t go out to the bars, and I’m not a part of any group online like a forum or a guild in World of Warcraft (though I do read a lot of Reddit). I don’t have a large Twitter following, I don’t post to Tumblr, and I don’t share pictures on Instagram. If I am in a social situation, I’m worn out by it rather than energized.

That being said, there’s something to be said for why I don’t do any of that, and it’s a complex reason. The primary reason, I feel like, is that I don’t have time. Of course, when you’re doing a startup, trying to make sure you still can pay rent at the end of the month, it’s easy to cut down on the Facebook posts. But to be honest, I have time. I take at least an hour a day to just sit and watch a TV show, if for no other reason than to unwind and try to get my energy levels to go down enough so I can go to sleep.

No, the deeper reason why I don’t post all of that stuff is simple: I don’t think what I have to say is especially interesting. I’ve spent my whole life being misunderstood. Whether it’s the family that insists I know how to fix their DVR because I “do computers” or the acquaintances who think what I do is comparable to work done by oversees programmers, people have always had a hard time “getting” me. And that makes it hard to explain, why being an entrepreneur attracts me, why I can’t come to dinner until I fix this bug in my code, or why I’m hopping mad when I’m working in WordPress, because most people don’t understand my lifestyle and my profession.

I’ve realized, this past year, as I’ve changed jobs several times, that I find myself feeling disconnected from society at large. Sure, I have my few friends and my business partners, but I don’t network like I should, I certainly fail at keeping in touch, and I’ve been so insular, it’s no wonder people ask me what I’ve been doing, and are surprised when they see what all I do.

Because I don’t share. I’ve never shared, because I was told my whole life that what I had to say didn’t matter. Funny enough, everyone who told me that was dead wrong.

So I’ve decided, on my 26th birthday, and for the next 30 days, I will do the following every day:

  • Post one article on my blog, either personal or professional
  • Post something (aside from my blog notification) to Facebook
  • Post something (aside from my blog notification) to Twitter
  • Respond to posts on Facebook and Twitter

My more social contacts have told me it won’t change anything, that you have to be social for months to build up a following. I think they misinterpreted my desire to be social. I’m not looking for Internet fame. I guess I just want to get over my fear of sharing. And as I overcame my anxiety disorder, my ignorance of everything not done on a computer, and my depression, I will overcome this as well.

Published by meatshield, on July 14th, 2014 at 2:11 pm. Filled under: UncategorizedNo Comments

Getting Started Programming Lesson 3: The Basics of Hello World, Debugging and Variables

For Lesson 2, click here

I had started out this next session typing out instructions and expected output, when I realized how hard this would be to truly explain in a way that would make good sense to all types of learners. It’s hard as an auditory learner to pick up something just from text alone, and being a visual/kinesthetic learner myself (I learn by seeing and doing) I admittedly sometimes forget that other people learn in a different style.

So I fixed my mistake by instead making a YouTube video. It’s long, but I think it actually has a lot more depth than I could get just with text alone. It’s also much easier for me to produce as well since I do these kinds of lectures frequently enough that it’s pretty comfortable to me.

Let me know what you think and if this us an effective method of conveying this information. I appreciate all feedback!


Published by meatshield, on June 7th, 2013 at 12:14 am. Filled under: UncategorizedNo Comments

Getting Started Programming Lesson 2: Getting Ready to Rock

For Part 1 of this series, click here.

Now that we have a rough idea what it is we’re actually doing, we need to set up your computer so that you can actually run Ruby, the language we are going to be writing our code in.

Read more…?

Published by meatshield, on June 5th, 2013 at 9:01 am. Filled under: Uncategorized1 Comment

Twitter, you’re doing it right!

So I’ve spent the last few weeks getting into web crawling. Not for any really good reason, other than I can.

I started out using Cobweb, a ruby web crawler that had good ratings, just to see what it could do. And I started with my favorite site on the Internet, Reddit. After crawling about 20K pages, I stopped getting responses from Reddit. Going to their site gave me a wonderful warning about how I had been banned for hitting the site too much. I looked and I’d been hitting them 20 times a second! Whoops!

For those not in the know all sites need to worry about denial of service attacks, where an attacker tries to take down a web site by repeatedly hitting the site, much like I was doing. The only solution to this is to block their IP address. Which is what Reddit did to me.

After that I started writing my own crawling system that would be able to not only scale out, but not be banned from every site in existence. A slow crawler if you will.

While working on that, I started playing around with sentiment analysis, or the analysis of what people say to determine if they are positive or negative regarding something. It’s a pretty hard problem, so I started with a very naive method of matching words to words I knew, using a dictionary I found online. Just for something to play with.

This needed data to use, and I hit upon it. Twitter has had this mythical “firehose” for a while that streams all tweets to someone. If you want, you can get the entirety of Twitter and analyze it as fast as you can process it. Pretty much what I need! Test data!

So I found a gem called TweetStream that let me hook into the firehose (who knew it was a public thing anyone could use?!), and set it up to pull in tweets. Here’s the code for your amusement:


require 'tweetstream'
require 'json'
require 'unicode'
require 'awesome_print'
require 'mongoid'

Mongoid.load!("config/mongoid.yml", :development)

class Result
  include Mongoid::Document

TweetStream.configure do |config|
  config.consumer_key       = 'GetFromTwitter'
  config.consumer_secret    = 'GetFromTwitter'
  config.oauth_token        = 'GetFromTwitter'
  config.oauth_token_secret = 'GetFromTwitter'
  config.auth_method        = :oauth

@client = TweetStream::Client.new

@client.on_error do |message|
  puts "ERROR: " + message
  puts "sleeping for 1 minute"

@client.on_delete do |status_id, user_id|
  puts "deleting " + status_id.to_s

@client.on_limit do |skip_count|
  puts "told to limit " + skip_count
  sleep(skip_count * 5)

@client.on_enhance_your_calm do
  puts "told to calm down. Sleeping 1 minute"
puts "starting Twitter firehose"
i = 1.0
@client.track("Facebook","facebook") do |status|
  #remove all non-english characters
  text = Unicode.decompose(status.text).delete('^0-9A-Za-z ,.<>/?!;:'"+()*&^%$#@')
  mongo = Result.new
  mongo["url"] = "http://twitter.com"
  mongo["word"] = "Facebook"
  mongo["elements"] = Array.new
  puts i.to_s + ": "+ text
  i += 1

I’ve pulled in around 30 million tweets in the last two months or so, purging out those that didn’t have any sentiment in them to get to about a 10 million tweet data set. Next up, the analysis, playing around with Hadoop!

Published by meatshield, on April 17th, 2013 at 3:51 am. Filled under: UncategorizedNo Comments

Getting Started Programming Lesson 1 – WTF Am I Doing?

As 2012 begins to wind down, I think I can say that, if not this year, next year will be the year of the programmer. This year, I’ve had numerous friends who are not programmers express an interest in programming, whether it’s wanting to know how to make a web site or wishing they knew more about computers to find out why their games seem to always run slowly.

I’ve been wanting to start a course like this for around a year now. I had originally intended to do it in PHP, but recently I’ve been working almost entirely in Ruby, and I find that, once you strip out Rails, it does a fantastic job of being an entry level language, since it takes care of a lot of the grunt work you don’t want to overwhelm a beginner with.

This course is going to proceed more or less like I learned programming: from the ground up. Hence why Lesson 1 is entitle “WTF Am I Doing?” I think the most important thing most basic classes seem to miss is explaining exactly what it is you’re doing when you program, and why things have to be done a certain way.

So before we get into installing Ruby and getting you set up to code anything, I want to talk a little bit about history and where we’ve been and why we do things the way we do.

In the beginning of computing, computers were really just circuits. They still are, if we are perfectly honest. These circuits have grown exponentially more complex and more powerful as time has gone on. Your phone has more power than the Apollo program had when they landed on the moon.

Initial computers, the ones you might have seen that were the size of rooms, took binary data. At the end of the day, everything we do is converted into electrical signals of either 1 or 0, on or off, power or no power. Computer engineers, the fellows who make these circuits and processors that we call computers, have designed them to react in certain ways when they see certain patterns of 1’s and 0’s. We call these “commands”, and by combining them, we can do pretty much anything.

The first computers had a sole function: compute numbers. You might be floored to know that’s all they still do! What some smart people did before I was even born was come up with a way to represent more than just numbers in a computer. So the text you are reading is made up of a series of numbers. The browser you are using is a collection of millions if not billions of numbers. And all of these are just collections of 1’s and 0’s. Pretty insane stuff if you stop to think about it!

In the old days, computers had a finite set of numbers they could crunch, and no way to store the answer. So what you did was you put in the equations you needed solved on punch cards, then fed them into the machine in order. Out of the other side would pop the answer, and if you made a mistake, you had to start all over and feed the punch cards back into it.

As you can imagine, that got old really fast, so again the smart guys and gals who came before invented what we refer to as computer memory. These come, still today, in two flavors. The first flavor is your hard drive, or semi-permanent memory. This memory is meant to last for a long time, but can be overwritten if you need it to be. The other type is called RAM, random access memory. This is what a computer uses to hold all the crazy long numbers it deals with. So as you’re reading this, think about the fact that the browser you are using exists as an “application” on your hard drive where you installed it. What happens when you “open” it is that you tell your operating system, itself just a very, very complex program, to load that program into your RAM, where it can then be used.

Now, if you’ve been keeping up, you might notice a small issue here. “Why do you have to put it in RAM at all? Why not read it off the hard drive?” For that, we have to talk about how computers crunch these massive programs like Photoshop or even Notepad. Computer processors have a finite amount of memory. It’s so small you couldn’t do anything useful with just that nowadays. We need a way to feed it more data when we can. What happens though is that your processor can crunch numbers far faster than your hard drive can serve it up, even with the new solid state hard drives. RAM serves as a faster holding place for data that needs to be used. Even moving your mouse takes processor power!

So since we can’t wait forever for the data to come off the hard drive (or, even worse, an old DVD!), we’re going to put most or all of the program in RAM. In video games you might be aware of the dreaded “loading screen.” That’s what you get when the game has to make room for another level or something else that isn’t loaded in RAM. Games that are smart with their RAM usage never show you loading screens!

So to review: we’re writing code that lives on the hard drive and is executed in RAM. Great, now how do we do that? Depending on when you ask that, you’d get different answers. In the early days of Windows, you might have written Assembly code, which is one step up from entering those 1’s a 0’s I was talking about earlier. A little later on a language called C was invented, which has proved to be very popular and is still in use today! There have been more and more languages that have come around that have made it easier and easier to program. We call this “levels of abstraction.” I also call this, personally, “inherent complexity,” which to me is how many lines of code it takes to get something done, which also tells you how much you have to know to do something. The higher level languages usually have simpler complexity, so something that might be 100 lines or more in Assembly is just ten lines in C# or Java and maybe a single line in Ruby.

So the question now comes up as to how we get from some high level code like Java down to the 1’s and 0’s I keep going on about? The answer comes in two forms: compilers and interpreters. In programming, there are two methods for getting lower code. You can “compile” it, and translate from something easy to read, like “print ‘Hello World!'”, to something lower, like 110100101010010010101010100010010100101 (note: that’s not what it translates to, I just typed 1’s and 0’s because I’m cool like that). Compiling is done before you can actually run your code, so it takes it from what we call “code” to an “executable” or a program. These can also be called “binaries” since they are, usually, very quickly turned into binary data. Examples of compiled languages are Java and C#.

The other way is called interpreted code. Interpreted code, rather than compiled, is fed through a system constantly that looks at your code, figures out what commands to run at a lower level, and does that. Examples of interpreted languages are PHP, Ruby, and Python.

We’ll get into the pro’s and con’s of each approach in a later lesson, because there are good reasons for choosing each approach. For now, just know that they exist, and that for our lessons we will use Ruby, which has its own interpreter that our code runs on.

So, to recap: We write “code”, human readable text which we then run through a system someone smart developed which translates it down (eventually) to 1’s and 0’s that are fed to the processor, that makes magic happen. Give it a few lessons though, and it won’t be magic anymore!

Coming up in the next lesson: installing Ruby and your first program!

Published by meatshield, on November 5th, 2012 at 5:08 am. Filled under: Uncategorized1 Comment

Creating a New Product? Look Here For How I Do It

As an active member in Dallas’ startup community, I have the opportunity to talk to a lot of very creative individuals, all with terrific ideas for great software services. One of the first questions they ask me, though, since the overwhelming majority of Dallas entrepreneurs are non-technical, is how in the world to actually build their application, host it, and scale it.
I’ve had so many of these conversations, and seen so many similarities in their needs, I’ve developed what I’ve started calling my Golden Template. This architecture lets me, and anyone else really, quickly and cheaply build a very complex infrastructure from scratch, develop their product rapidly, and host as cheaply as possible, as well as develop for web or mobile or both. There are some options, and I’ll discuss what makes me pick one over the other, but for now let’s get into our language choice.

Language – Ruby on Sinatra

Ruby wins for one reason alone: it’s the fastest language on the market for building things. Because the community is very open-source-friendly, there is tons of code to do everything from talk to any kind of database to tie in to useful services, to sending emails and authenticating your users.
Many Ruby enthusiasts only think about one framework when they are working in Ruby: Rails. Hell, half of non-technical people thing Ruby on Rails is the language. And it makes sense since Ruby on Rails gives you lots of boilerplate code, enforces nice architecture and code organization, and has tons of useful gems for it. I find issue with the fact that it is a very hefty framework. And when you’re working towards a minimum viable product, that can become a hinderance as doing small upgrades starts requiring modifying several files to get things tied togeter. Scaling can also be an issue as you will need to scale sooner than with my way of doing things with Sinatra.
Sinatra accomplishes what we want our hosted servers to be: an API. With a JSON-feeding API, we can build either a mobile app or a web app (and I mean web app as in no page loading on each request). It’s very light weight, and the syntax can be picked up in an hour and have you writing your app. It’s a little more risky if you’re a terrible architect of your code and you start putting everything in one file, but if you break it up into multiple files I find it very easy to work with defining my REST API.

Hosting – Heroku or Appfog

Hosting Ruby code should be like the rest of Ruby: minimal effort. I want to deploy as easy as I start up my testing server locally. I want to scale with a command and I want that scaling done without me needing to add servers to load balancers or make sure my build scripts worked correctly.
Heroku is the hosting platform for Ruby projects currently. They were the first PaaS for Ruby on Rails, and they now host any kind of Ruby web app you could think up. Their first dyno is free, which lets you host your app for nothing while you finish it and get your first few hundred users (protip: use Unicorn for multiple threads in the same dyno!).
Heroku, however, is very expensive when you scale it up. Appfog is trying to disrupt that market by giving you control over not only your dynos(CPU) but also your memory for each dyno. You get 2GB RAM free (which I might add is insane!), and you can distribute that to as many dynos as you want, with a minimum of 128MB per dyno. They also allow unlimited applications with this setup, so you can also segregate and separately scale different parts of your app if you need to do that. This is useful because if you look at a Heroku dyno, it’s one thread and 512MB RAM and one app. Most apps I’ve written top out at 100MB per thread depending on what they are doing, so there’s no point in throwing that much RAM that it will never use. Appfog lets you have a little more control in how that works.
Appfog also has the advantage of multi-cloud tenancy. Heroku is currently only hosted on Amazon Web Services, so when Amazon goes down, so does Heroku (they are currently adding Rackspace to their hosting platform, but if I remember correctly that’s still a beta product). Appfog supports AWS in multiple regions (US, EU, and Asia), as well as Rackspace, Azure, and HP’s new Openstack cloud in Las Vegas with one click replication to another cloud(NOTE: for Ruby on Sinatra you can only use AWS and Rackspace. PHP is supported on all cloud hosts).
The downside to Appfog is that it is still in a beta stage right now. Their PHP hosting was very disappointing, but Ruby has worked out fine for me. Their site seems to be going through some growing pains, and for good reason as from what I hear people are very excited about the 2GB free RAM (another note: the next stage up is 4GB for $100 a month.)

Database – MongoDB on MongoLab

I’ve been a huge MongoDB fan for a while. Yes, I know it has some scaling problems, but they are working on them, and recent versions have gotten much better, with fixes for the global write lock and some other issues already fixed in the current stable version. MongoDB is by far the easiest database to work with, since it lets you organize your data in documents of JSON data, then query that data. This is extremely easy with the Mongoid gem, which I highly recommend as your MongoDB ORM of choice on Ruby. It takes some getting used to, but it’s very easy once you are familiar with it.
Since Heroku only offers PostgreSQL on their platform and Appfog is fairly ambiguous on what exactly their database offering is, MongoLab is my choice for MongoDB provider because they have add-on ties for Appfog and Heroku, so you can get unified billing, and they also give a larger, 240MB free database (and you can fit a LOT of data in 240MB, trust me). I haven’t had any issues with them at all, and have been a happy customer with all of my projects. They also have a very nice admin interface that makes it easy to do things like verify your data is being stored correctly.

Frontend (Web) – jQuery + (KnockoutJS or Backbone) + Twitter Bootstrap

You will most likely need jQuery. If you don’t, don’t use it. I use it a lot, if only for their network functions, so I usually always include it in any project.
Most frontend developers prefer Backbone since it takes care of model syncing for you if you implement the correct REST API. I like Knockout since it has a slightly looser set of requirements and doesn’t require you to reimplement some of their code if you need say offline storage in your application.
DO NOT USE JQUERY MOBILE. I will say it again. DON’T DO IT. Any time someone looks at doing a mobile version of a site jQuery Mobile comes up. jQuery Mobile seems nice since it’s very accessible, but it is a massive, slow piece of junk that still can’t even do animations well on any mobile platform. I’ve used it extensively and I’m done with it. The tradeoff of a rapid development time using their UI isn’t worth it in my book.
Twitter Bootstrap is the current favorite for weekend projects. It comes with a nice UI out of the box that is pure CSS (some add-ons use JS), so it’s far faster than jQuery Mobile. Plus because it’s a responsive design, you get a full desktop, tablet, and mobile app all in one UI. There are also a TON of themes for it that can get you halfway to your app if you don’t have a designer on your team (a massive problem in Dallas along with lacking tech talent).

Frontend (Mobile) – Native, Appcelerator, or Rhodes

As a member of Sogeti’s Mobile practice, we look at a ton of tools to try to make building cross-platform apps as easy as possible. We’re tool-agnostic, so we use whatever fits the bill. We do a lot of HTML5 apps wrapped up in PhoneGap, since that leverages existing skills in HTML5 and is very, very fast to do, which makes it perfect for proof of concepts or pilot programs.
However, the apps tend to be slow unless you spend a lot of time optimizing them, and even them they will never perform as well as a native app because the Webview just doesn’t do things as fast as native. Just ask Facebook and Linkedin, both of who tried it, and Facebook is trying to go full-native after they couldn’t get it to work well.
Native of course gives you the best performance, but it’s hella slow to develop in and you will need to write your app multiple times in multiple languages. Not something you want to do unless you have to, but if you care about performance, this is your likely option.
Appcelerator takes javascript-y code and cross-compiles it down to native code for iOS and Android, then runs it with native UI widgets. It’s a very nice offering that has been getting some serious attention from a lot of big names for their applications. It uses its own syntax and doing UIs is a little like Java Swing or Sencha in that you delcare everything and attach it all together in code. There is no way to do a layout similar to native code for iOS or Android where you have a GUI to design in(at least not that I know of). As such you may have some trial and error to get everything set, but it performs surprisingly well.
Rhodes is a fairly new find on my part, althrough it’s been under the rader for a few years. Rhodes is an open source part of Motorola’s Rhomobile offering. They allow you to write a Ruby on Rails-esque code that creates a Webview based UI similar to PhoneGap. The advantage is that, with PhoneGap, if you need some native component that isn’t in a plugin or part of their standard library, you need to go back to writing native code to get that functionality. Rhodes has most of the native functionality already built in, and a lot of functionality can be added in Ruby code, that compiles down to be run on an interpreter that is C-based (even on Android, it uses their NDK). It supports every platform under the sun, including legacy platforms like Symbian and Windows Mobile. It’s not for everyone (for one thing, if you hate writing C code, that’s what you write native plugins in), but if you need the broadest support across platforms with the least work, and you are already using Ruby, give it a shot and see what you think.

Backend Processing – IronWorker

One of the ways I keep down costs of operations is utilizing deffered processing as much as possible. For those who don’t know, many tasks, such as sending emails and running analytics can be done after a request is submitted, i.e. they are not time-sensitive. If it takes another few seconds to send an email that’s not a problem. For that, we have IronWorker. IronWorker bills you by the second (as opposed to dynos or instances which are per hour) for operation, so in most cases of say email sending each email costs you a second of billing time. And because IronWorker gives our 5 hours a month free, you can do the math on how many emails you can send without paying a cent. They are also very easy to work with, and you can be up and using them in about an hour. You can also run the things you upload locally to test them up before running them in production (note: I highly recommend doing this because if an operation takes an infinite amount of time to run it’ll take them a while to turn it off and you’ll be billed for the time).
Note that Heroku’s worker dynos work and are billed in the same way, but I find IronWorker to be a little easier to manipulate, and I also don’t like keeping the entire infrastructure on one platform.

Queues – IronMQ

This is by the same people who make IronWorker, and they give very cheap queue hosting with a dead-simple API for messaging passing. This makes great sense if say you need a randomized list of entries and only want to generate that list once then pop off of the list as a page is loaded. It’s unneccessary if you need to pass info to an IronWorker, as they have a method for parameter passing, but for other uses it’s very easy.

Payment Processing – Paypal or Stripe

Let’s be honest here: you do NOT want to do your own payment processing. Don’t even think about trying it. You’ll go crazy trying to be PCI compliant alone. Offset that to someone else. Just do it.
With that out of the way, for generic single transactions and subscriptions, Stripe is dead simple to integrate with. I had it up and running in less than an hour. Very nice offering if you want something dead simple to use.
Paypal is a little more complicated, since you have to set up a bank account and get that all working, but past that it gives you a lot more flexibility in how you do payments. For instance, if you need to make payments, Paypal can do that very easily, while Stripe will leave you high and dry since it only takes in money, and cannot distribute it.
Plus, many people feel more comfortable using Paypal than an unknown third party, because Stripe hides themselves so you’ll never know if you’re using them or not.
Lots of people will mention BrainTree for their cheap transaction fees, but I’ve found them to be a total nightmare to work with in PHP. Ruby may be different but I haven’t used them in Ruby yet. Not really MVP material in my book, but probably something to switch to down the line when you are losing hundreds of dollars a day to transaction fees.

Image Management – Cloudinary

I love Cloudinary. Probably because when I found them, I was building a similar offering because I had a few people asking me about image management solutions and best approaches. Cloudinary works by giving you 5GB of image hosting for free. By itself, it isn’t remarkable. What is is that they also will manipulate those pictures on demand, which includes not only scaling them to any size you want, but applying features, doing rotations, and even creating nicely rounded images, then exporting into any format you could think of to be hosted on a CDN, guaranteeing a fast load of the heaviest part of any data transfer. A very cool offering and one I recommend if you are going to deal with pictures.

File storage – Amazon S3

I’ve searched high and low, but there is nothing around that can compare to Amazon on price and speed for storage. It can be a little more complicated to use than say Cloudinary for images, but for files it’s the easiest thing to use. They also have a gem that obfuscates most of the complexity for you. Plus it’s dirt cheap and infinitely scalable!

Performance Testing – Blitz

Blitz is a fairly new addition to my toolbox. It lets you do load and stress testing on your site with thousands of simulated users if you need to. This is useful for cost forcasting as you are getting your financials in order to go to investors. They let you do 250 users for free, which in my experience was not enough to adequately test on Heroku or Appfog, so go ahead and pay (it’s pay per test, so it’s actually nothing to run a test).
There are a few other services I’ve used, most of which can be found on Heroku’s add-ons page, but there are the ones I’ve used and know work well when I’m laying out an infrastructure for someone. Using this, a competent programmer familiar with most of this stuff can be expected to write their backend in a week or two (40-80 hours), then however long the frontend will take (it depends a lot on your app). The important thing is that all of these have very generous free tiers so your infrastructure can be set up and run for free. No users? No problems with infrastructure spend.

Published by meatshield, on August 20th, 2012 at 3:28 am. Filled under: Uncategorized1 Comment

The Mobile Web and UI/UX

While some companies are already taking the plunge and creating mobile applications for the various platforms, still others are hesitant to enter that space. Whether they see it as a fad or something that’s not worth the effort, one of the best ways to take a step towards mobility is to create a mobile site to complement your desktop experience.

When mobile first became popular, this was hard to do, needing lots of custom CSS and thus having a high development cost, today mobile sites are very easy to make with the help of libraries such as jQuery Mobile. jQuery Mobile contains everything you would need to create a mobile site, and can be created with plain html (and maybe some CSS tweaking for theming). This solves the technical hurdle, but the real issue is that you need to recreate the entire user experience for mobility. The desktop experience and the mobile experience do share some commonalities, but there are special considerations, especially with regards to mobile websites.

Real Estate is Limited

This is the hardest part about mobility: there isn’t enough space for everything on your desktop site! The first priority might be to look at all your information, and see if you can either move it to other pages, or remove it all together. Designing a mobile site is not a matter of just taking everything you have and making it so that it fits on the screen and doesn’t scroll horizontally. Users do not want to scroll through tons of content to find what they need. In an ideal world, there is no scrolling at all, unless it is textual information.

Even on a form factor like a tablet, you shouldn’t have to scroll all around the page to find the information you need. It should be right there, or on another page. Jump lists are a great way to take a handful of links, and compress it down into one on-screen button. This saves you screen real estate, as well as giving users a uniform place to look for links to other pages (so make sure it stays in once place throughout the site!)

Links Are Buttons

Textual links are a great thing when you have an exact pointer like a mouse. Mice are precise and accurate. Fingers, on the other hand, are not.

We still need links though, and that is where buttons come into play. Buttons solve two issues: size and visibility. It’s easy for links to get lost in a wall of text if you’ve changed the default link color to something other than the bright blue of the default link color. They are also hard to click, especially if they are close together, and force your users to either zoom in to the site, or try multiple times to click the link that they want.

Buttons are large enough to be clicked easily, and should provide enough spacing between links for accuracy. And we don’t need to have large buttons. Looking at pictures of mobile applications should give you an idea or the size you need. You can also tell if the buttons are too small by trying the site out on your mobile device, and seeing if it is hard to click the correct button.

Fixed Anything Won’t Work for Mobile

Long time designers are familiar with the 960 pattern. It is a design pattern that breaks the web site into twelve or sixteen columns, for a total of 960 pixels in width. This is great for fixed-width sites, because even at a resolution of 1024×768 (the smallest resolution a full-screen website on a small monitor will typically support), you can still see all the content without horizonal scrolling.

The problem with mobility is that there are no fixed dimensions for the screen. There is no minimum you can assume to support, because the reduced screen real estate means you need to use every pixel. As such, designs must be reactive, and use all the available space. Some groups have already adapted the 960 grid system to support mobility, such that elements will compress or expand as the device is rotated or different devices are used. For instance, your desktop site will show in standard 960 pixel format. On a mobile phone, elements will compress down to a few columns so that everything will still be visible without scrolling, and you can hide or show certain elements depending on the resolution. These systems should become the new norm for website design, as mobility is fast becoming the preferred way for users to access information and interact with web sites.

If you are looking to evaluate these multi-form templates, you might try Boostrap by Twitter, which just launched support for multi-device scaling sites.

Flash? Silverlight?

Let’s be clear: if Adobe isn’t even supporting Flash on mobile devices, it’s time to admit that Flash is a dying technology. While many sites still utilize Flash, on a mobile site you are likely to either get poor Flash performance, or nothing at all, meaning users visiting your site will see nothing at all. That’s a quick way to lose a sale or a customer.

And Silverlight? Not supporting on anything but Windows Phone 7. If you are taking advantage of Silverlight, you’re in the same boat as Flash when it comes to mobile web sites.

If you still want some of the animations and other features of Flash and Silverlight, take at a look at HTML5, the new standard for HTML for both mobility and newer browsers. It adds a lot of missing features into HTML, including animations using the Canvas element. Companies such as Zynga are already writing full blown games in HTML5, so it should be more than capable of handling your site with great support on mobility as well as most newer desktop browsers (except Internet Explorer, which is lagging behind the pack in HTML5 adoption). This transition will help future-proof not only your mobile site but your desktop site as well.

Bonus: Take Advantage of Gestures

One thing you can’t do on a desktop is gestures. Swiping, pinching, and other multitouch gestures are not found on desktop browsers. You can utilize gestures to make your site feel more like a native application. If you have a picture carousel, for instance, you might turn that into a touch-friendly version on your mobile site, and allow your users to swipe to change pictures. This increases interaction with your site as well as bringing a sense of familiarity that a non-gesture-supporting site won’t be able to match.

Published by meatshield, on February 25th, 2012 at 8:43 pm. Filled under: Uncategorized Tags: , , , , , No Comments

How I Choose a Language for a Project

I’m apparantly a freak. Well, say those who know me, duh! But in this sense I’m talking specifically about programming. Most people program in one, maybe two languages. I program in a half dozen fluently, and a full dozen if you count languages I would need a refresher on.

So this is fairly unusual from what I’ve seen, but it has some distinct advantages. For one, getting a paying job is pretty easy when you know most major programming languages. Second, and most important as it relates to this post, you have the flexibility to choose the right language for the job.

Programming languages all have pro’s and con’s, and specific cases where they may be better than another. Part of knowing how to program in a language should be the best times to use it. Because while C++ gives you great speed with your code, you’re going to have a really hard time programming a web site in that.

So here’s a quick breakdown of the pro’s and con’s of the languages I use regularly, in the order I most use them (outside of work, or it’d be C# at the top even when it’s not my language of choice)


PHP is my go-to language of choice. It’s quick, flexible, well-documented, and the syntax is easy to understand if you’ve done basic programming. PHP is a language that gets out of your way and lets you get down to coding without worry about imports and DLLs. Many a programmer has been converted to PHP when forced to use it because the code is easy to read and easy to run functions. None of this System.out.println stuff, you just say echo; It also has a massive community of developers, who more than likely have already solved the problem you are tackling, so googling becomes very useful.

On the negative side, PHP is no good at going long-running tasks (the default max time for a PHP call is 300 seconds, though you can extend this) and it’s really bad at desktop programming (since it doesn’t support desktop GUIs, though I have used it for some Cron tasks). It really only works well on the web, as a backend language sitting behind HTML, Javascript, and CSS, so to do a really nice site you will be expected to know 4 languages to get it done. not that the CHJ stack isn’t used in all web languages, it’s just that some languages abstract some of it away. PHP is fairly low level when it comes to the web.


Ruby has jumped a few spots in the last few months as I’ve revisted Rails, by far Ruby’s killer application. Rails is a MVC framework for Ruby that adds a lot of structure to Ruby, and makes it very powerful as a web language. Rails created “scaffolding” or being able to type in a console command to create your components as their most basic levels. It’s extremely powerful and useful for things like Models. Ruby also has the ability to be added on to with “gems” or pre-built community code that you can install with a command. They are extremely powerful. I built a full registration and login system in a half hour using a gem and a tutorial. And unlike PHP Ruby does not have an execution timeout set.

On the downside, Ruby’s syntax makes me want to cry. It’s painful, mainly because it takes a little of this and a little of that approach to syntax. It’s got some C style in it (Java, C#, PHP all follow C style) but when it comes to brackets, they are gone for words. There are around 4 ways to do anything in Ruby, so unless you comment your code someone will have no idea what you did (and I’ve worked with enough programmers to know we never comment as much as we should!). But overall it’s a solid language, albeit with a bit of a steep learning curve.


Despite being primarily Windows-only, C# is the only way to do a Windows application. And since Windows is still the OS with the largest market share, it makes sense to develop a nice GUI for it. C# is a nice language, there’s no way around it. It built upon what was nice about C++ without going the Java route and making everything so complex you’ll never be able to figure it all out. And it has so many features that are just inspired, primarily LINQ, which lets you search arrays just like you search a database (oh, and you can search those with the same syntax!). And everyone can agree Visual Studio is the best IDE around, with just about every bell and whistle a developer could ask for in it.

C#’s biggest problem is primarily the documetation. As in it’s buried in so many places and so imcomplete it’s very difficult to find what you are looking for unless you know where to look for it. Which brings us to point number two: It’s extremely complex. C# has so many “add-ons” that you need to know to really “know” the language that I doubt anyone really knows it all. There is WCF, WPF, .NET, Sharepoint, and let’s not even mention legacy things it has to support like older ways to do GUIs. So it has a bit of what I call “inherent complexity” in that to do something simple, it takes a lot of either typing or work.


Like it or leave it, Java is a huge force in the world. From desktop to Android, it runs just about everywhere (except your non-Android phones mostly). Unlike C#, this includes OSX and Linux as well as Windows. So it’s ideal if you need to do a cross-platform desktop application, and it’s alone in that regard.

But past that, Java is pretty horrible, and I don’t know anyone who will admit to actually liking it. It’s horribly slow (and the cause for why Android is so slow), very complex to use, has spotty documentation, and tends to give some of the most cryptic errors I have ever seen in a programming language. If you can avoid it, never use Java. The fact that they still teach introductory programming classes in it is probably the reason most kids transfer out of computer science. It scares them away!

So we’ve got the pros and cons out of the way, and I mentioned a little about what each language is good for, but how do you go about picking when some of them overlap? I’ve propared a flow chart to aid in your quest. The main idea is to limit language fragmentation where you code different parts of your software in different languages, hence some of the odd answers. Also I don’t take into account languages I don’t know or use often, so there may be something better out there. Also this is very simplified, choosing a language is actually a pretty big part of starting a new project since you’ll be stuck with it for as long as the product exists!

Published by meatshield, on January 9th, 2012 at 9:07 pm. Filled under: Uncategorized Tags: , , , , , , No Comments