The definition of idempotence varies based on context. However, stating a function (whether it is a RESTful call, a function call, or a SQL command) is idempotent usually means that function has the following properties:

1. The function should be referentially transparent.
2. The function should be reentrant.
3. The function should not have any side effects.

That’s the basic definition I could find on Wikipedia, but it makes it sound much more complicated than it really needs to be. This may be because the principles of Computer Science are so intertwined with mathematics that we like to discuss these ideas using equations and complex terminology. However, the idea of idempotence is easy enough to grasp for mathematics laymen such as myself.

The function should be referentially transparent

Referential transparency of a function suggests that a function call can be replaced with a hardcoded result value without changing the behavior of the program. For example, let’s say we have a method that calculates the area of a rectangle. Simple enough to build this using ruby.

1
2
3
4
5
6
7
8
9

# Calculate the area of a rectangle
def area( x, y )
  x * y
end

# Call the area method
my_area = area( 10, 20 )

puts my_area # 200

As you can see, a simple call to the area method with x equal to 10 and y equal to 20 will return a result of 200. We can also see that if we call area( 10, 20 ) any amount of times, it will always return that same result. Knowing this, we can easily enough replace all that code with this:

1
2
3
4
5
6
7
8
9
10

# Calculate the area of a rectangle
# def area( x, y )
#   x * y
# end

# Call the area method
# my_area = area( 10, 20 )
my_area = 200

puts my_area # 200

Haskell, a functional programming language, has this type of replacement built in since it’s built on the idea that a function should have referential transparency.

1
2
3
4
5

let area :: Int -> Int -> Int
    area 10 20 = 200
    area x y = x * y

show( area 10 20 ) -- "200"

As we can see here, when we call area 10 20 it runs the first method that returns the hard coded value of 200. Any other values will run the second version of the function.

The function should be reentrant

A function is considered reentrant if it can be safely interrupted while in the middle of running and re-executed before the first pass has completed. This can happen on a multitasking operating system, which is pretty much every O/S in existence today. For example, let’s say we have two threads running the same method on a single core machine. At any time, the operating system can stop the first thread and start running the second. In the case that the two threads are executing the same method, the two threads should not clash. No shared data should be modified that could cause the first thread to be in an unknown state when it continues executing. Let’s look at an example of a non-reentrant function

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

string_value = ""

def add_to_string( line )
  string_value += line

  # Thread interrupted here

  string_value += "\n"
end

thread1 = Thread.new{ add_to_string( 'line1' ) }
thread2 = Thread.new{ add_to_string( 'line2' ) }

thread1.join
thread2.join

puts string_value # "line1line2\n\n"

As you can see, calling add_to_string on two different threads can cause an unknown state if the method is swapped out in the middle of execution. While we’d expect line1 and line2 to be on separate lines, they come out on one. This method is considered non-reentrant because it modifies a global state, in this case string_value.

Now, you may believe that reentrant and thread safe are synonymous, but they are different in a very important way. Let’s say we modified this code to read as the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

mutex = Mutex.new
string_value = ""

def add_to_string( line )
  mutex.synchronize do
    string_value += line
    string_value += "\n"
  end
end

thread1 = Thread.new{ add_to_string( 'line1' ) }
thread2 = Thread.new{ add_to_string( 'line2' ) }

thread1.join
thread2.join

puts string_value # "line1\nline2\n"

This method is clearly thread safe, but it no longer is reentrant. When thread2 decides to jump in and run add_to_string, it can’t since thread1 holds a lock. It must wait until thread1 is complete before running. It cannot reenter the method. Instead, we can just pass in all state, including string_value to overcome this.

1
2
3
4
5
6

def add_to_string( original, line )
  original += line
  original += "\n"

  original
end

This way the method is not only thread safe, but also reentrant. It does not rely on any outside scope to execute. The method can be stopped in the middle of execution and recalled on a different thread without side effects.

The function should not have any side effects

Speaking of side effects, that is probably the most important aspect of idempotence. The method should not have any side effects. What this means is that every piece of data outside of the method should remain pristine when running a method. It cannot change any values outside of its own scope or make any changes in the operating system. Forget when you learned what a function was in computer science and go back to your algebra days. If your algebra teacher showed you the function x = x + 1, you would have told her she was crazy since this doesn’t make any sense.

When it comes down to idempotent methods, this also remains true. A function in algebra is denoted as f(x) = .... It takes in one or more inputs and returns a result from just those inputs. Think about your code in the same way. If I passed in values to your function, I expect calculations to be done only on those values. It shouldn’t change the global variable, num_calls. It shouldn’t create any files. It shouldn’t change the state of any value outside of the function. When I call your function, I expect nothing to change. I only expect a return value.

Now, to play devil’s advocate, there is always some side effect of calling a method. That side effect is the time taken to execute the code. Most of the time, this can be safely ignored. There is always an opportunity cost to running code, so we can’t change that even if we wanted to.

More Information

I’ve talked previously about idempotence. If you want to learn more about the “why” of idempotent functions, please check out the following articles and expect some further discussions in the future.

• Think Functional: Immutable Types and Idempotence
• Think Functional: Lambdas and LINQ

In a previous life, I worked on high speed trading software where our traders worried about millisecond delays. We pushed and received so much data that a standard TCP/UDP system could not come close to keeping up, even on multicore machines with gigabit connections. What this describes is a post-mortem of my learning process.

One of the downsides of the huge popularity in networking is that at a certain point, the hardware and firmware guys took away our control. Most of the network stack is done directly on the network hardware with the help of the device drivers running in kernel space of the operating system. This gives the benefit of “hardware acceleration” at the cost of customizability. While code can be written to operate at lower layers than the transport layer, most of the time these will run slower due to multiple layers of abstraction from the hardware. We will focus instead on working with what is given.

There are large and expensive packages that try to solve these problems from companies such as Tibco and 29West. From my time working with them, they are worth every penny if you can afford it and you work in a problem space that requires that level of throughput. However, for us peons, we have some options that can help improve our throughput speeds.

Now, I spend all my time giving examples and micro benchmarks of all possible optimizations I’m offering, but what I’ve found is that networking is a little bit like black magic. There are so many variables involved that determine final output speed that my benchmarks will not match anything you create, even if we use the same exact algorithms. Things such as network latency, number of hops, solar flares, the number of flaps of a butterfly’s wings while traveling from tree to tree outside your window; all cause random differences. Don’t focus too much on the numbers involved with network programming, but instead focus on the concepts.

UDP for speed

The first thing you learn when trying to do high speed networking is that you should pull out UDP. This is an obvious choice due to the fact that there is no overhead of acknowledge (ACK) packets that come with other reliable transport services. You will find that most real-time games use UDP because it can push out the raw speed with minimal delay.

This is because UDP packets are about as raw as you can get on standard home and commercial hardware. There is no flow control, no delivery confirmations, and no guarantee that the packets even arrive in the same order.

UDP is good for fast, streaming data. When you care more for fast packet delivery than you do for guaranteeing that older packets arrive. You’ll commonly find it being used for streaming video since that data has hard real-time requirements for delivery. Video codecs normally have error correction built into the algorithms because they know they will lose packets.

In the trading world, stale price quotes were normally worthless when newer quotes were available. We streamed price quotes as UDP datagrams because we only cared about up to date pricing. We did lose packets, especially on huge bursts of data, but that was okay in moderation.

TCP for reliability

Not all data is so easily ignored, however. Most data requires guaranteed delivery. Just think, if you were browsing your favorite site and small chunks of data were missing from the page and every once in a while an image was mangled.

TCP gives the client server an agreement on the data. The data will arrive on the receiver’s side, the data will arrive in order, and the data will be correct. This is great for files, especially larger ones that require multiple packets to send it in whole. The receiving software won’t need to worry about those issues and can use the connection to stream data in correct order. If you need reliability, you won’t find any protocol that beats TCP on protocol availability and data validity.

The price of those guarantees is great, though. If you need any type of throughput, you will find yourself lagging. When I was building a prototype phone for Motorola, we were using a PC to take readings from multiple sensors on a phone over an 802.11 wireless connection for real-time and post processing. The data wasn’t all that large or fast, but we constantly got lagged responses because TCP would hold us up. Because we didn’t have time to rebuild it for UDP reliably before a demo, I would SSH into the phone while someone demonstrated it and would reset the socket connection every few minutes while he was holding it to get it back working reliably. “Ignore the man behind the curtain.”

TCP includes a buffer called the “sliding window protocol” buffer. It will hold a certain number of packets in order on the receiving side so it can send them off to the client software properly. This buffer is quite small and can be easily overflowed, especially on an unreliable network connection such as wireless. When that happens, the protocol will start throwing away perfectly good packets it receives until it can catch back up. This was what was happening on our phone prototype. While our network monitor showed great throughput, most of the packets were being thrown away because of one single missing or bad packet. We also lost throughput since the flow controller would start backing off on the speed until the PC could keep up.

Join the two sides

We have these two two popular protocols that seem to be mutually exclusive. Nothing can be further from the truth. Instead, you should join forces and use both protocols, just on separate connections. Have your stream of unreliable data on one UDP connection and the rest of your data on TCP connections.

Operating systems and network hardware have built in mechanism, called “Quality of Service,” to actually slow down a single connection so one hoggy connection cannot take over an entire network (although how well this works hugely depends on the quality of their QoS algorithm). Yes, this is an over exaggeration of the truth, but it presents the idea simply. To increase throughput despite QoS systems, you should increase the number of connections. On a side note, including multiple TCP connections also increases the size of your sliding window buffer by a multiple of the number of connections.

Threaded service

This is probably the most important piece, that I question putting it way at the bottom of this article. When you write a socket program, what do you do with a packet the instance you receive it? If you said anything besides buffering it into a queue, you are doing it completely wrong.

The sockets library has an odd system for how you access the receive buffer. Instead of receiving a notice that a packet is available to grab, we are notified that the receive (Rx) buffer is ready to be read, and only if we specifically ask to be notified for the next available stream of bytes. What this means is the data will stay within the network buffer until you go and read it. And while you are reading from the socket, you could be (and will be, at a certain throughput) losing data.

To minimize this data loss, you need to take the data off the network stream, put it directly on your internal packet queue, and enqueue another asynchronous (or threaded synchronous) read. Don’t try to parse the data. Don’t try to analyze what packet you just received. Don’t even create a byte array to host the new packet. Just pull the packet and put it in your queue. Many asynchronous socket libraries (such as ASIO) require a buffer to place the data within, so make sure you have those packet buffers already created. Use a memory pool of byte arrays if needed. Reuse these buffers as much as you can.

The quicker you get to the next read statement, the less likely you will lose packets. Although I would love to see multiple queued up reads available from the socket library (you can do this over USB, for example. I once queued up 10,000 reads simultaneously over USB to max our throughput.), it doesn’t yet seem available.

Even if you use a non-blocking library such as I/O Completion Ports (IOCPs), you need to follow these same rules because the same results will occur. At the trading firm, we would normally lose packets when using IOCPs because we had the same thread reading from the socket along with parsing them out. Non blocking APIs still have to follow the same rules we do, so don’t expect that using one will allow you to ignore these issues.

Oh, and by all means, never use the UI thread to do any networking. You’ll find that just drawing to the display can cause networking problems due to the delays.

TLDR: Too long. Didn’t Read

• Use UDP when you can get away with lost packets, but need the speed.
• Use TCP when you need guaranteed data.
• Use a combination of the two on multiple connections when you need both.
• Use more than one connection to maximize throughput.
• Don’t do anything other than read from the socket on the receiver thread.

This goes against everything I was taught growing up. I was always told that to be the best, you had to force yourself to become that expert. The problem lies in that technology has advanced to such a degree that it’s not possible to become that expert in a short enough time period to even stay relevant. No time in history has there ever been such a growth in a field that one could obsolete him or herself so quickly just by trying to learn everything there is to know about their profession.

Take programming methodologies as an example. If you know assembly, you will know that there is no such thing as a loop. Sure, you have things such as JNZ (Jump if Not Zero) or any of the other conditional jump statements, but those are just gotos with a condition attached to them. This was and is still common when you jump down to most byte code. For and while loops just don’t exist in these contexts. All of a sudden, with an influx of procedural languages, and with an article written by Edsger W. Dijkstra named Go To Statement Considered Harmful, this was bad practice and programmers had to adapt by using loops, method calls, etc.

The same happened with object oriented programming, following procedural. The use of functions alone was deemed bad practice, so most of us moved on to thinking in objects, interfaces, and methods. It’s happening again today with functional languages such as Erlang and Haskell. Again, object oriented programming is considered harmful because it has too many side effects. So, some people are moving on. This is not going to stop any time soon. The explosion in computing power has had the effect of exploding the lines of code required based on what users expect in their software. New methodologies have to be created to mitigate some of these issues as they arise.

This doesn’t even go into the vast number of programming languages in production today. Take in all the legacy code still written in languages such as Cobol and add in languages such as Ruby, C++, Python, etc. Then you add in the managed languages such as those written for the .NET framework and the Java Runtime Environment (JRE). Finally add in some of the newly popular languages such as Erlang and Haskell. What you get is the impossible task for any person to keep up with the technology.

So How Do I Keep Up?

This is an interesting dilemma. On one hand, I spent the first part of this post explaining that you can’t keep up, but now I’m going to explain how you can. I consider myself lucky. I’ve had the opportunity to work in a huge range of industries on a large number of languages. In college, I was a C++ guy. Growing up, I spent years honing my skills in its idiosyncrasies. And then, when I graduated and need a job, I took on C#. My next job went back to C++ but mixed in some Perl and Python, I then went back to a mix of C++ and C#. Finally, I switched completely over to Ruby and Rails. This makes me fairly marketable since I can confidently apply for a job in C++, C#, Ruby, Python, or Perl. Being marketable should be high on anyone’s priorities due to the state of the job market in a whole (recession) and the job market for programmers (booming).

Now I’ll tell you what I’m not. I don’t have any certifications. I’ve never been comfortable enough with a language to contribute to their core library. I don’t know exactly how the garbage collectors work in .NET or Java. There are a lot of things I just don’t know about the languages I work in daily, the small details about a language that are not required to be known to write great code within its confines.

Even though I can’t call myself an expert at any of these languages, I can say that I’m a jack of all trades. I decided early in my career that I would not focus solely on one language because they can go out of popularity multiple times in my lifetime. I’ve shown instead that I can adapt to change in infrastructures.

It’s not a difficult task. On the contrary, it’s quite easy. Instead of continuing to read the same blogs on only Ruby, branch out and start reading about .NET or Java. Get a better understanding of what the alternatives are, and maybe one day you’ll find that the language you know and love just may not be the perfect solution for your next project.

Master of None

When people say “Jack of all trades,” we all know the next line to that statement is “master of none.” This can be worrisome to quite a few people because they believe that will hinder their career growth. If you look at job descriptions for senior level developers, you’ll see things such as “requires 5+ years developing in X,” or “looking for an expert in Y.” If you looked at my resume, that would have made me unqualified at my current job because I never had written a line of production ruby code in my life before it. On the coding test, I had to look up half of the ruby methods because they weren’t ingrained into my brain yet. Of course, I did get the job despite these shortcomings due to my broad knowledge of programming.

Theres another side effect of broadening your knowledge. You will get a different perspective on the problems you encounter in your job. Learning functional programming will teach you how to handle threaded applications simpler in C# or Java. Learning a static language will give you a better understanding of what strict types gives you in Ruby. You will be able to know when it’s best to use TCP to send messages to another process and when it’s better to use a message queue.

While you may not know exactly how to install and instantiate the message queue, you will find it much easier to learn how to do it. You have been practicing learning new tools, so you will be able to pick up basics of setting up RabbitMQ knowing right away that it uses Erlang’s cookie system for security. Once you break free of trying to become an expert will you finally start becoming great.

Startups are everywhere. They are the hot ticket item. Get millions of people to join your website, and you are a rich man. I’m not deeply tied in with the startup community, but I personally know a few people doing startups, and I can see flaws in their business model. Still, the market has shown recently that they will still “violently fund” these startups without any plans for profits. All this sounds too familiar.

Disclaimer:

I apologize in advance since this is veering far from my expertise and diving into the business world. I am by no means qualified to make such broad, sweeping statements about the web industry. Sometimes, I just like to rant. Also, notice the question mark in the title? Consider me Fox News. I’m just asking questions.

Seed Money Business Plan

Software prototyping tools are prevalent. The days past of creating prototypes in C++, creating thousands of lines of code just to throw them away are gone. Web developers can use Rails, Django, CakePHP, or ASP.NET MVC (depending on your language preference) to create simple examples of their idea.

So what do some of these companies start with? Trying to find seed money. In general seed money can be great for a startup. It’s good when you can play with “Other People’s Money (OPM).” But, creating web applications can be done so cheaply that you wonder why these people spend months trying to find money to fund their development when they could have used that time to create the product in the first place.

Businesses always require a solid business plan, so I don’t expect startups to give up on the idea of creating one. However, a solid prototype or production application can sometimes sell itself. If it can’t, the business plan should write itself once you put some code to work. Trying out your product can quickly show you flaws in your business plan and even more or better ways to make money.

Many of the people I’ve talked to about seed money see it as the way to personal profitability and lack any real plans of future profits for the company.

Crowd Sourcing

The idea is solid enough. Build it, and they will come. If you’re trying to make another social networking site, let me stop you here. If you build it, it will sit idle. You have a catch-22 here. People drive content, but you can’t intice those people until you have that content. So, if your business plan requires your content to be created by others, you have to find a different way of bringing in these users.

Now, think about your business plan. Do you have a good way of bringing in these users without Tweeting, FaceBooking, or whatever the verb format of Google Plus is? If you don’t, your idea is probably doomed to failure. Go back, look at a different way of generating content or bringing in those users.

The internet is full of users that could be described as having Attention Deficit Disorder (ADD). And, because of how easy it is to create simple web applications even for non professional programmers, there are tons of social sites available. You have to find a way of not only bringing that user to your site for the first time, but also keep their attention long enough for them to care about coming back.

Growth Opportunity

There are a ton of web startups out on the internet. The chance of getting a new user to commit to your site without them jumping from another site is probably pretty slim. This could be good news for you because that would allow that person to use your site that much more. The reason that person would jump from the older site is that it no longer fulfills their needs.

And this is the heart of the problem. Popularity will always be cyclical. You need to grow your business horizontally, not just vertically. What this means is you need to move into other opportunities before your business popularity drops. Web companies seem to be so focused on a niche market that it’s very difficult to expand. Many of these companies wind up dying out instead of moving on.

IPO

So if a company is doomed to die out if they don’t expand horizontally, what is their ultimate goal? From what I can gather, it’s the infamous initial public offering (IPO) or the sell. This is overly prevalent recently with the IPOs of LinkedIn and Groupon.

I’m going to use Groupon as the example here since it’s the epitome of my points. When they had their IPO on November 4th, 2011, they raised $700 million, valuing them at close to $13 billion. And this is for a company that loses $100 million a quarter. The founders and early investors got filthy rich off of this business that has no chance of making money, and the late investors are stuck holding the bill. When things looked dim for the Groupon company, when their capital was running out, they rushed the IPO to make sure they weren’t the ones dealing with the bill.

Another Dot-com Bubble

It seems a lot of these companies are falling down the same path as the original dot-com bubble. These companies have very high P/E ratios, bright red balance sheets, and no real future of profitability. Yet money is still grossly injected into these startups. There are ways of making web companies profitable, and I hope to see more of it.

For those companies that are already over invested? My only question: who will be the ones holding the toxic assets in the end?

When you create a new rails project, there are a few gems that you require to even get started. While rails does have a lot built into itself to help start you off in creating great applications, I find myself in need of a more complete starting point. I’ve compiled a short list of my most commonly used gems in new rails projects.

Devise – Authentication

Every one of my projects in rails has required some sort of authentication system. I have not found a better solution than Devise. It seems like it’s the de-facto standard for authentication in rails. Even if you want to use other external authentication systems, like Facebook or Twitter, there are plugins built for devise that handle these systems also. It’s a super simple installation process and even simpler to use.

RSpec – Testing

This is just a personal preference. Test::Unit or Minitest can be substituted for rspec, but I’ve gotten used to the DSL that rspec includes. Plus I prefer its included mocking framework for those few times that I need to stub out a method call.

factory_girl – Test factories

While rspec does give me a full featured mocking/stubbing framework, I personally prefer to use real objects for tests. However, building objects using standard ruby methodologies can be time consuming and verbose, especially when you have hierarchical models. Factory girl simplifies this with a small DSL that allows me to define model factories one time while still allowing me to change them per test.

The standard still used in rails is to use fixtures, but I feel that fixtures takes away part of the meaning of the test since it is separated in a different file. Plus you have to know what exists in the fixtures before hand to make sure your tests are valid. Instead, I can start with a clean slate for every test and define the model instances as they are needed, and define the exact parameters that are needed for that test instance.

Guard – Automation

While not the first automated testing system, it is my favorite. Using its plugin architecture, I can have it tests for files that have just been updated, start up my spork server, and restart pow as needed.

I also install gems to allow guard to notify me using Growl whenever events occur. This is probably the nicest feature of guard which allows me to keep my eyes on the code without having to flip to the terminal all the time to run my tests. That plus the speed of spork allow me to breeze through the code in no time.

Pry – REPL and Debugger

If you are running ruby 1.8.7 or newer and haven’t tried pry, you are really missing out on a great REPL system and debugger. On top of the standard read, execute, print loop, it allows you to also use ls and cd to browse through objects. I use this to replace IRB in all my new rails projects and I’ve never been happier. Ryan Bates has a great screencast on RailsCasts about how to set this up.

Haml – Template Engine

When it comes to view engines, you have a few to choose from. Rails comes standard with erb, but I prefer to use Haml. While some people may not like the limitations that come with Haml, I find the single line definitions force me to simplify my views significantly. I also like the simple syntax and the conciseness to the template language. After working with HTML and XML for so long, it’s nice to see how little code is required to do the same thing.

Of course, Haml does use indentation rules similar to Python and CoffeeScript. This can be a major turn off to some users. If you keep your views simple and extract partials wherever it seems reasonable, the indentation shouldn’t be more than three or four layers deep.

Capybara

Regression and full stack testing can be difficult without the right tools. Luckily we have Capybara to handle a lot of the backend work to call into our server. What we need to code is CSS or XPath selectors like you would using jquery. Add in a few automated input handling through the Capybara gem and you can easily run through multiple pages in only a handful of lines. This helps a great deal because it takes a lot of headaches of integration tests, making it more likely that I will write them more often.

Summary

As I had written before, one of the greatest assets that the rails community has is its vast collection of ruby gems. I have not seen another community release as many of these projects in such a relatively short amount of time. Take advantage of some of these and you will find that you are much more productive and have fewer errors because you will have to write much less code and use more production tested gems.

If you’ve been reading this site in the past, you may have noticed a face lift. This isn’t just a face lift, but a complete rewrite of the blog software that I use. I used to be hosting this site on wordpress, but I found I was battling the system too often and trying to find work arounds for the quirks. Now this site is just a bunch of static HTML files that were nicely generated using Octopress and Jekyll. This should significantly improve the speed of the site and allow me to write more often (with more code examples). I’m also finally able to host on “the cloud” using Amazon’s S3 service which finally allows me to do automated deployments. As an added bonus, it also increases my geek status.

So what real benefit does this give me? Well for one, I can write everything offline in markdown format without worrying about some converter messing up the formatting. I also have more control over the styling and layouts of the page and it greatly simplifies my setup.

Markdown and SASS goodness

Creating posts using only HTML tags can be time consuming and error prone. The problem is you have to force yourself to a subset of HTML which may be removed by the Wordpress editor anyway. Instead I can now use markdown, which is a simplified markup language that can be converted for me automatically and safely. I can also use SASS to drastically simplify my CSS code.

Markdown, at least with the extensions brought in from Jekyll, has the benefit of allowing me to insert code directly into the content. I’ve struggled getting code to properly format using Wordpress in the past, so this is a huge benefit.

Uses ruby

As a new found ruby developer, I like the fact that Jekyll allows me to run arbitrary ruby code while generating the site. For example, I use this to insert the page links in the index pages. I don’t have to manually handle these housekeeping issues by handing them off to an automated process. The fact that it’s ruby is a bonus since this is what I work with daily.

No back-end

The best part is that the Markdown is converted to static HTML files. That’s right, there’s absolutely no back-end for this site now. You’re downloading HTML files I generated on my computer directly without worry about putting things properly in databases. That means I can’t have downtime due to a database crash, and there’s no way I can lose data due to database corruption. No need to run multiple servers to handle the separation.

It’s also much more difficult to attack the site. The only point of attack is now the web server which will always exist. There’s no need to worry about patching wordpress anymore (which is still an ongoing battle) nor any other software. I just let Amazon worry about the server software and just worry about content.

Automatic deployment

1

$ rake s3deploy

That’s all I have to do to push the new content live. It’s a great feeling.

Offline access

One of the issues I ran into a lot was that my wordpress site could not be accessed without an internet connection. I spend a lot of time on the train to and from work where I don’t have access to the internet. That means I could not see what the site would look like while making changes during that time. I’m sure I could have setup a LAMP server locally to do development, but it was more work than I wanted to put into it.

Instead, I can run the entire site locally by generating the site or running a rake task to run a WEBrick server. And, it will look and at exactly as I see it when I finally do deploy. There are a few external services that won’t work, such as my twitter feed, but that’s a minor issue since I don’t usually maintain that part of my site.

Version control that makes sense

As a software developer, I’m used to great version control systems that give me more than just history. I’m now storing the entire site in a github project. Since markdown files are just files, I can do diffs, branches, merges, even cherry pickings. You can’t even start to think about doing these things in wordpress, especially without some major modifications to the software.

If you’re interested in my setup, you can go to my github repository and download the entire thing onto your computer. In the future, I may talk about how I set the site up and my own customizations.

You’re probably thinking that this is just another post of how great rails is and how you should come over to our side because we have cookies. I’m trying to write this as an objective view of Rails from a .NET developer’s perspective, so hopefully this won’t come off as fanboyism speak.

I have been writing code in C# since v1.1 and the language itself has come into being my personal favorite of the many I’ve used in the past. It has near native speed, fast compilation, and a fairly straight forward syntax. But it also includes a vast framework which now includes ASP.NET MVC. Although ASP.NET MVC isn’t the first MVC framework, even for .NET, it’s tooling support in Visual Studio and simplicity has made it the fastest growing in the .NET world.

Ruby on Rails on the other hand is fairly new to me. I’ve been coding in it for about a year between versions 2.1 and now 3.1. While it’s new to me, I’ve found myself building web applications quicker and cleaner with it.

Works in Notepad

I use notepad as an example here although I use vim. What I’m really saying here is the framework is easy enough that you don’t need an IDE, IntelliSense, or even documentation up if you are familiar with the framework. This is not so true with ASP.NET MVC due to the complexity of the .NET framework and the amount of generated code.

Quick Dev Time

My time is so precious, I didn’t even have enough time to write “development” in the header. Okay, so that’s not true at all, but I’ve noticed Rails to be quicker in development even though I’m an average ruby programmer and pretty fluent in C#. This mostly comes down to the simplicity of the framework and the minimal amount of physical typing that’s required.

ASP.NET MVC has improved greatly to reduce the amount of code that’s required to build an application, but it still has a way to go. Ruby may have the advantage here because it’s a dynamic language and simpler to add duck typing. While .NET supports multiple dynamic languages, it still has to limit itself to the lowest common denominator with static objects with some dynamic thrown in.

Also, while ASP.NET MVC 2 and 3 are pushing hard for the user to run with ADO.NET Entity Framework, it still doesn’t make a default choice for the developer. While this shows the framework is open to choice, it makes initial development one step more difficult.

Gems

If there was one thing that should make anyone look another time at Ruby on Rails, it’s the huge number of ruby gems available. Microsoft has had a good push lately with their NuGet packages and the market has seen a quick explosion of popularity, but it’s still hard to browse for packages unless you know them before hand. Mostly this is because there seems to be less discussions on popular NuGet packages on the Internet. I’m hoping that the tooling in Visual Studio 11 fixes some of that and people talk more about their favorite NuGet packages.

On the other hand, I know that in a new Rails application, I’m going to pull in Devise (authentication), CanCan (authorization), Haml (view renderer), RSpec (testing), and Will Paginate (pagination). With these, I’ve gotten at least a weeks worth of work, if not more, compared to having to build some of those by hand in ASP.NET MVC. It’s a nice feeling to know you won’t have to write yet another pagination partial.

Tools

Okay, this one I know is going to be widely controversial. Visual Studio is by far the best IDE built. Period. End of story. If you use even 10% of the features it has, you will have to agree with me. However, I now work almost exclusively with Macs and Linux machines. This means I cannot use visual studio.

We have a pretty good alternative with MonoDevelop which I use quite often now, but the tooling for MVC within it is mediocre at best and only really supports V1 and some parts of V2 of the MVC framework.

The Rails community follows more along the lines of the Linux and Unix mentality of having tools do one thing and do them well. With the fact that everything runs separately, I can have a script run things automatically for me. This is exactly what I do with Guard which runs my unit tests automatically every time I save. It also alerts me on success or failure using Growl so I don’t have to interrupt what I’m doing.

ASP.NET MVC Not a Bad Choice

If you’re a .NET developer, this is not going to change your mind. ASP.NET MVC is still a solid choice, especially if you have existing .NET code you need to interact with. Microsoft, in a short period of time, has built up a great framework that competes with Ruby on Rails and Django. This hopefully opens your mind a little to the other options that may exist.

Java, what could have been

Java was supposed to be the solution to making your applications work across multiple platforms. While the “write once, run anywhere” slogan is quite accurate, you can easily pick out a java application on every desktop platform. Java currently uses its own UI framework named Swing. The problem is that to make sure that applications run properly on all the platforms, swing does not follow any of the UI standards set by Windows, Mac OS X, GTK, or KDE. It also does its own software based drawing of all its widgets. Because of this, Java has gotten a reputation for being slow and laggy. The language is quite fast, keeping up with .NET and in a close race with C/C++, but the UI has really held it back.

Qt, the C++ solution

The Qt framework, by Nokia (previously Trolltech), is an impressive cross platform C++ framework that tries to solve some of the same things Java set out to do, but using the tried and true C++ language. I’ve used Qt since somewhere around version 2, and I’ve found that for a C++ developer, Qt is quote an impressive framework. Nokia has also put together an IDE specifically for Qt which inclues code completion which has been difficult in the past due to Qt’s precompiler.

Also, Qt is another framework that does its own widget drawing, but has the added benefit of supporting hardware acceleration. This makes Qt’s widget drawing to be as fast or faster than native widgets. If you don’t use the hardware acceleration for whatever reason, the Qt “trolls” have optimized the heck out of their drawing code. They also have different skins for the different operating systems to make the widgets look native, however don’t expect all widgets to be there or look 100% the same. All in all, if you know and like C++, Qt may be a decent solution.

One of the problems with Qt is that it’s built on C++. While I’m a C++ fan, the development time for anything is dramatically increased. C++ is verbose in general because of the header/source files, sometimes making it feel like you are writing twice the amount of code. C++ compilers are also slow due to complicated syntax rules and C++ template generation. This makes development slow compared to some of the snappier compilers for other languages. You also have to take into account compiling a different executable on every platform. Since the executable code is not run within a virtual machine, it needs to take into account the differences between platforms itself.

Mono and .NET

You wouldn’t realize that .NET is a cross platform solution by looking at Microsoft’s website. That’s because to Microsoft, .NET is for the Windows operating system. You have to look to a smaller company, Xamarin, and the Mono community to find that they have developed a fairly complete and production ready .NET implementation over the past seven years. They’ve also created a fairly good IDE for Mono called MonoDevelop.

So why is .NET and Mono the better solution? Well, you get the power of the .NET framework of course. Mono currently supports up to .NET 4.0 with some features of 5.0 already working in the trunk. The .NET compilers are also quite fast during compilation out of the box giving you major speed boosts over C++. You also get WinForms support out of the box. That will give you native rendering in Windows with mimicked results on the other operating systems. Of course, this is only a starting point. Mono supports a multitude of other UI frameworks including Gtk and Cocoa, giving you true native drawing in all platforms. There’s even MonoTouch, Mono for Android, and Windows Phone 7 frameworks to cover the mobile side.

The one issue you have when you jump to multiple frameworks, though, is that you require multiple UI projects for the same solution. This will be the downside of any project that will try to be native on multiple platforms, no matter what the language. You can start developing using WinForms and have a workable solution for all platforms. Later when you want to add true native support, you can add in WPF, MonoMac, and GtkSharp. At that point, it’s up to you which frameworks to support with no limitations.

Software that’s been out for many years: v0.71. Google Chrome that’s been out for a short time: v12.0. What has happened to version numbers that meant something? They have become a way of trying to show market dominance, or a way from hiding from your users. Worse is the software that is so afraid of version 1.0 that they will increment so slowly that we don’t know if it’s worth upgrading. Looking at a version number for a piece of software no longer tells me anything.

Many of you will argue that version numbers never had any true meaning. This may be true for many commercial applications. A large version number shows that you’ve been around for a while, and it’s a great way of deceiving without anyone really noticing. Minor version numbers were just incrementers no matter how large or small of a change.

I was bitten by this recently at my job. We are still stuck on ruby 1.8.6, however we are looking to upgrade to 1.8.7. One of the great benefits of ruby and rails is gems and bundler. A gemfile stores the names and versions of all the required ruby gems in your project. Even better, you can specify a versioning system for each gem to automatically update when asked. This is great, if the gems stay with versioning standards.

However, one gem did not follow any standards and released a maintenance release that no longer supported ruby 1.8.6. Since we only locked down our gem to the second decimal point, this came down the pipeline to our development machines causing all sorts of new errors in our tests.

The response from the developer was “I told you 1.8.6 was deprecated.” Yes, but we expect deprecation warnings to affect us on the next fairly major release. This was a breaking change, however the version number did not denote this. I wish I had the time to read the release notes of every gem, but this is just not possible. I made an assumption based on the version number and was bitten by it. You may say that this is my fault for allowing the update, and you would be right. It’s something that I will not repeat in the foreseeable future. However, based on my own Googling of the error message, I obviously wasn’t the only person that ran into this problem.

Keeping up with the Joneses

Remember Java 1.2? I do, and it wasn’t all that long ago. How about 1.3, 1.4? Do you remember Java 3 or 4, though? No you don’t. That’s because they never existed. Java 1.5 was labelled “Java 5” and Sun (now Oracle) never looked back. This was back when .NET was version 2.0 already making Java seem like old news. The name, “Java 5” sure looks more appealing against .NET 2.0/3.5/4.0. Sun also did this with Solaris jumping from v2.x to v8. Marketing material magically removed any reference to their old versioning scheme.

This is not limited to Sun, however. Winamp jumped from v3 to v5 because, as their marketing states, it was a combination of v2 and v3. Since v2 + v3 = v5, this is what they decided on. AOL seemed to release a new major version every few weeks. Netscape skipped versions 5 and 6 to catch up to Internet Explorer. Many times these major version releases hardly warranted these numbering changes. This is what happens when marketing is allowed to take over version numbers.

It will never be truly finished

This is the exact opposite problem that plagues many open source projects. Open source projects are afraid of the v1.0 stigma; that the program needs to be stable. Instead they will release v0.19.37a (okay, a little facetious). This makes it more difficult to believe that this software is ready for production, but nonetheless, it is.

As a reborn programmer into the Ruby on Rails realm, I have been shocked at the number of gems used in production that are no where near v1.0. It’s not that they aren’t production ready. On the contrary, many of these gems are rock solid. It just feel a bit weary when it looks like the authors don’t believe it’s v1.0 worthy.

One response to this is that the developers feel that it’s never truly finished. MAME is one to use this excuse going as far as going from v0.99 to v0.100. What these projects fail to realize is that there is life after v1.0. There’s actually v2.0, v3.0, and so on. Heck there is an infinite amount of version numbers just waiting to be taken. If anyone needs some, I have some extra version numbers lying around that I’m willing to give out for free.

What I believe in

I’m sure it’s difficult to listen to someone standing on his soap box decreeing what people should or should not do with their version number, especially when there does not seem to a hard and fast rule for version numbers. Instead, what you should do is read more on version numbers and what prior, successful projects have done. I just give one way of doing this that makes sense to me.

I believe in the [major].[minor].[maintenance] versioning system.

Major is for major changes in the software. This can even include enough changes to warrant a paid upgrade. When I see a major version change, I expect and understand breaking changes. I also expect new features, not just bug fixes.

Minor is for minor updates. These may be small feature additions, major bug fixes, etc. This can include some breaking changes, but fairly minor. I should be able to look at the release and fix whatever breaks within a few hours.

Maintenance is for just that, maintenance builds. This should absolutely not include any breaking changes. It also should not have any new features. This is just bug fixes. Leave it at that.

Another example of a good versioning scheme is Ubuntu’s month.year.point versioning. I know right off the bat that 11.04 is the latest major version and that significant changes have occurred since 10.10. Although this does contradict my version inflation talk above, it is a well known versioning method for Ubuntu users and very consisten. It’s not just marketing telling developers that we need to skip a few versions to catch up to our competitors.

Following a standard will always make things easier for your users. It doesn’t have to be the major, minor, maintenance style that I show above, but stick to a versioning scheme that fits for your project and users.

What happened is GitHub changed the string format of dates within their API. This is obviously what we call a “breaking change,” and their API probably should have been versioned to avoid these types of problems. However, that’s not the real issue that I’m trying to address. The problem is the application didn’t safe guard how they access the API. The assumption was that GitHub wouldn’t change their API in any way that would break compatibility. I question why you would assume anything when it comes to programs.

Why aren’t you handling errors?

This is the most obvious issue. I remember back a few years back when writing C/C++ applications for embedded hardware that if we didn’t handle an error, you would get random behavior. We didn’t have stack traces, core dumps, or even printfs (We had a pretty primitive hardware setup since we were R&D). What we did instead was check every return value and used interrupt handlers to handle the exceptional cases. In other words, we used all the tools available to us to make sure we didn’t fail. In embedded systems, we truly had exceptional cases such as blown parts, power surges, and even dropped prototypes. String parsing errors are nothing compared to random hardware failures.

One thing that was drilled into my skull over and over again was that you need to handle every error state. If a method returned a value and you ignored it, you would be reprimanded. If a function returned a value, the function’s author obviously believed it was important enough information to include. You need to check it. With C, there were no exceptions, so an ignored error caused undefined behavior.

Why are you ignoring your exceptions?

This is even more important, and arguably easier to handle, with languages that support exceptions. Instead of checking the return value of every function call or checking the global error value, you can check for errors on an entire block. The call stack is unwound to whichever position you want that can successfully handle the exception.

Heck, even having a catch all handler at the root of your application that just shows an error message then quit would be better than letting an exception unwind the entire stack of your application to be handled by the operating system. Then I would know that an exceptional situation occurred instead of thinking the program was just poorly coded.

Why are you still using a non managed language?

Okay, this one may seem odd and controversial , especially since all my examples so far are about embedded C and an iPhone application. This obviously doesn’t relate to certain types of programs that require high performance (games, trading applications, etc.) or that have the requirement of a certain language (embedded software). For the rest of the situations, a language should be used that can help write better, safer code. There really is no reason to still use C/C++ or Objective C now that there are multiple options.

Yes, Objective C is questionable since Apple puts this requirement on all Cocoa applications, but MonoMac and MonoTouch are great solutions which use a .NET runtime or compiler. MonoTouch does cost money on top of the money you have to shell out to Apple for the opportunity to write iOS applications, so your mileage may vary. I also know Adobe has a similar solution and I wouldn’t be surprised if Java had something also.

The real benefit is garbage collection. Why manage your own memory if you don’t have to? Memory management is difficult to handle perfectly, especially with exceptions. Patterns such as RAII in C++ and smart pointers mitigate these worries, but the language still allows you to shoot yourself in the foot if you aren’t careful with using these. I hear iOS 5 is going to get reference counting for Objective C, so this may be a moot point in a few months.

Patches are not a solution

Sure, patches for the problem are good. We need fixes so we can run your software, but that is not the end solution. It is only a bandage on an incomplete design. What you need to add with the fix is error checking to make sure this never happens again. Don’t just fix whatever error you’re getting. Make sure that all possible future errors are handled.

We are all human

Now this may come off as a rant, but I know we’re all human. I’ve definitely had crashes in programs that I’ve written. Errors happen that sometimes we really can’t predict. However, the options listed above should help mitigate some of the most likely situations. Just remember that while we are all human, we can still avoid the crash situation. Error messages, no matter how cryptic, are infinitely better than core dumps alone.

The data link layer is the first step in managing the connection between two network adapters on the same LAN. It really has two main jobs, and in IEEE 802 networks is defined as two separate sublayers. The first, or lowest of the two, is the Media Access Control (MAC) sublayer. You may recognize the acronym MAC from the MAC addresses printed on your network cards. This is the first address used in socket communications. The MAC address is a globally unique address flashed onto the network adapter’s ROM space. This address is what is added to each frame that is sent out, and it’s what is monitored to see if a frame needs to be read.

Of course, that’s not the only thing it has to worry about. If we have a group of computers on the same LAN, we would have interference. Imagine that instead of computers, we have a group of people sitting at a small table. One person can’t just start talking without listening for silence first. If every person started talking without listening for silence first, all we would hear is noise. While some protocols can pick out streams from noise, like picking up a conversation by the sound of one person’s voice, but most of the time you’re stuck with one speaker at a time.

Some of you may have noticed a problem. If two people are listening and hear silence, they may on occasion start talking at the same time. In the case of two people, they will usually hear this and go back and forth saying “No, you go first.” In the case of the MAC sublayer, a simpler process of random delays after a collision occurs. Each network adapter chooses a random wait delay and then tries again. In the case of another collision, a new larger random number is chosen. This is called carrier sense multiple access with collision detection or CSMA/CD.

The MAC sublayer also handles frame synchronization. It determines at which bit a frame starts and ends. This is done through different methods and varies based on standards. The usual method is to stuff a special sequence of bits or bytes at the beginning and end of a frame. These are known as start of text (STX) and end of text (ETX) sequences. So if a receiver notices an ETX sequence at an unusual point, it knows that the frame has been corrupted.

The other sublayer is the Logical Link Control (LLC) sublayer. While the MAC sublayer can detect frame errors of size changes or missing bits, it alone cannot detect bit errors. For example, if say the frame is 1500 bytes long, and only one bit has been incorrectly inverted, the MAC sublayer would never know. In this case, the LLC sublayer adds the CRC value of the frame to the end. This will detect nearly all the bit errors.

The LLC also handles flow control. When a sender sends out a frame, it expects the receiver to acknowledge its arrival. In simple cases, the sender would wait for the acknowledge packet before sending the next. This way, the receiver determines the rate at which packets are sent; how fast the receiver can receive. Of course, there’s a delay using this method known as a round trip delay time (RTT). To get around this, most processes support a sliding window protocol. In simple terms, a sliding window allows for a range of packets to be on the line waiting for ACK packets. Ideally the window size would allow enough packets to be sent to cover the RTT. This would ideally make the transmission continuous.

Next time we’ll be discussing the next layer up, the network layer. This is where the fun job of routing occurs and where software decisions can start to be made.

Yes, if you look again at the URL for this site, it will still say codefixes.com. Of course, you can’t master the art of software without knowing how what your write turns into physical changes. In this case, how does the information from one computer electronically get sent over to another. This is not black magic (as much as the electrical engineers want us to believe).

Let’s first talk about the physical layer you may be most familiar with, ethernet. You may see it as 10BASE-T, 100BASE-TX, or 1000BASE-T. These are the standards for communicating over copper wire, which is what hides inside the ethernet cable. The wires are paired and twisted together inside the shielding. They are twisted and shielded to avoid electromagnetic interference. The trick here is the twisted pairs carry opposite signals, known as differential signaling. This means that if one wire gets interference, the other will too because the twisted wires coupled together.

The other standard you probably know and use is 802.11, or really IEEE 802.11. This is the standard for consumer grade wireless networks and is pretty standardized in the corporate world. It transmits wireless signals from one wireless adapter to another using strange modulation acronyms such as DSSS, FHSS, and OFDM. Basically, all of these describe how to use the wireless frequencies assigned to each standard. The basic idea is that wireless has to deal with more interference than a physical wire. Think of your radio in your last car (because maybe you have one of those fancy HD radios now). When you were far from a radio station, sometimes you heard two stations switching back and forth within the static. This is what radio frequency, or RF, interference “sounds” like.

These radio stations are given dedicated bands of space by the FCC (in the U.S.). That means they are guaranteed that band by the government. WiFi does not have that luxury. Everyone needs to play nice and share the same bands. Worse yet, the transmission performance is so poor on these bands, that the FCC didn’t want it and has opened it up to anything. That’s why we see 2.4GHz cell phones, 2.4GHz wireless keyboards/mice, and 2.4GHz bluetooth. Everything is on this band and we want to get over 100Mbps to our PCs.

That’s where the complicated spread spectrum type modulations come into play. At its most basic level, a signal is transmitted on a coded set of frequencies that is agreed upon by the sender and receiver. This is called code division multiple access. Since the frequencies are coded, another sender can send on a different code simultaneously. The receiver then takes the full spectrum, and using advanced math that is above my level, extracts or de-spreads the original transmission.

There are further ways of handling interference such as 802.11n’s use of orthogonal frequency-division multiplexing. It uses multiple signals, subcarries, and higher level math than the previous versions. If you’re really interested, or just a glutton for punishment, you can read more about it on Wikipedia.

So what does this all mean for us coders? Well for one, you can now impress your engineer friends by using acronyms such as CDMA and complex vocabulary such as “orthogonal subcarries”. But in reality, we need to know one thing out of all of this. Interference is our main source of slowdowns in layer 1 of the OSI model. So, we have a few options to think about. If you need the dedicated bandwidth, go with a wired connection. This will give you some level of guaranteed bandwidth, although there are some things to worry about higher up the OSI model.

If you have to use wireless, know that you may lose large chunks of your data. If you’re using TCP, this equates to large lags and drops. You can avoid some interference by switching channels on your routers and making sure two routers near each other are on orthogonal frequencies. This will avoid interference between the routers and minimize the crosstalk between computers on different routers.

You can also switch bands all together to the 5GHz band. There will be generally less interference on this band right now since most consumer grade electronics don’t use it. Plus the added benefit of 802.11n’s four simultaneous open channels using multiple input, multiple output and its multiple antenna array for allowing directional transmission will give you much higher performance with much less broadcast noise.

Also, since 802.11n is an open ended standard in some regards, you will find that the expensive hardware will actually out perform the cheap stuff. So, if you need the bandwidth, get ready to pony out a lot more money for a router that has higher coding rates and more simultaneous streams. These babies can get up to 600 Mbps (theoretical), if you have the right hardware.

So now that you know the basics of the first layer of the OSI Model, we can continue building upon that knowledge to understand the next article in this series about layer 2, the data link layer.

As with many of my other posts, we’re really here to talk about maximizing performance. The world has changed with the advancement of multicore processors and cloud computing. As we move into distributing our work among multiple processors and machines, these separate processes will need to communicate. The IP protocol is now ubiquitous due to the internet’s popularity. It continues growing as processes are moved to the cloud and APIs are moved to RESTful sites.

So the Open Systems Interconnection model or OSI model defines the basis of most networking systems. This includes the full stack that runs the internet from HTTP down to the 802.3 standard (ethernet cable). I’ll briefly define each of the seven layers and how they map to the web. Each layer of the stack adds its own unique wrapper upon the packet it receives from above. In other words, the layers don’t care about each other. They just know they need to add some data to the packet as it goes down the layers, and reads from the packet as it goes back up on the other side.

Layer 1 – Physical Layer

This is the one that’s probably the easiest to understand. This is the standard of actually sending bits down the wire. This includes your standard ethernet and wireless standards. This defines not only the signals and voltages, but also the physical connectors and wires. There’s not much for efficiency that we can do on this layer since it’s physical hardware and doesn’t allow for software modifications.

Layer 2 – Data Link Layer

The data link layer defines the protocol of talking between two machines that are physically connected. 802.3 extends into this layer describing what each byte means. This is also where your MAC address comes into play… you know, that long hex string written on your network card. Again, this is usually physical hardware, so not much we can do. If you have an “ethernet” card, it will probably only speak ethernet. Flow control and error checking are done here too.

Layer 3 – Network layer

Okay, this is where code starts getting thrown in, although mostly in firmware. You may know this layer as the IP layer in protocols such as TCP/IP and UDP/IP. The network layer defines how packets are routed from computer to computer. This is mainly how far up routers and hubs go when it comes to analyzing packets. They read up to layer 3, then decide the optimal path this packet should travel.

Layer 4 – Transport Layer

This is the basis of how one computer “sees” the other, even though they are not directly connected. This is where TCP and UDP live. Decisions on how you use this layer can affect your throughput and data quality. This is probably the most important layer to grok to improve your throughput. TCP is your connection oriented protocol, where the two PCs communicate as if they were next to each other. UDP is the same, except the connection state is not shared and the data may come randomly.

Layer 5 – Session Layer

Layer 5 isn’t all that important in the TCP/IP world. It defines things such as VPNs and broadcasting methods. This is only useful if you are building something custom. Otherwise, you would normally just use an off the shelf component for this. Ignore it for now.

Layer 6 – Presentation Layer

This is where things become a little grey. The presentation layer defines how the packets work together as a whole. That means if you’re sending a file over TCP/IP, while it may break up into packets, this layer will use them all as a whole. This is straight code. It is normally the code that handles the raw packets and converts them to useful information in your software. Security is also added at this layer, so things like SSL live here.

Layer 7 – Application Layer

This is the bread and butter. This is what the user actually uses and sees on the screen. After the packets are pieced together in layer 6, your application must use that information. This part of the application is usually run on the UI thread, and normally does not interact with sockets directly.

In future posts, I will go into more detail about each one of the configurable layers and describe steps that you can do to increase throughput.

If you’re looking for a long post on how much rails API sucks, you’re going to be sorely disappointed. Remember, I do like rails. It’s an easy framework for anyone to get into. If you’re looking to build simple CRUD applications, rails is hugely productive. Just a simple set of terminal commands and you have a full working application. Hell, no code required. The problem is that all the work is hidden by code generation. Once you have to do anything out of the ordinary, your stuck looking up the documentation.

Why is this so difficult? Because the API isn’t all that great. There are multiple ways to do everything. Without consistency, it’s a matter of memorization, and who has time to memorize when work needs to be done. The problem is compounded when you add in the multitude of gems into your project. All of these work, as black boxes. You just run random commands and something happens. These commands are all different and you hope you don’t get them confused.

Just for a test, I looked up the new “respond_with” command on Google. The first link to actual documentation is the seventh one, and that is with me looking up the exact command. The documentation is just bad. I still have to look up things every time I have my editor open. There are ways to avoid this, though. We could use an editor with code completion, but doesn’t that just hide the underlying problem? What we really need is a better API.

Now, I’m picking on Rails a little bit, and that framework doesn’t deserve all the negativity alone. .NET has the same problems, but it’s hidden behind the “Visual Studio” facade. With intellisense (code completion), I can see the list of methods on a class and descriptions of them at a simple control and space. I admit that I do this quite a bit with new libraries.

If you designed your APIs with consistency in mind, your users wouldn’t need to constantly reference the documentation. Focus on the language (as in spoken) of your API. Speak it out loud and just listen for the sentences that come out. Are you hearing coherent thoughts? Do each of the sentences from your classes and methods sound like they come from the same paper? Your methods define your sentences, your classes define your paragraphs, and your namespaces define your pages.

You’ll find out that when your API makes sense to you, it will start to make sense to your users. Too many APIs try to focus too much on functionality and ignore verbal cohesion. Others go the opposite route and become overly verbose. (I’m looking at you testing frameworks). There is a happy medium to be found.

Just remember, when your users are complaining about your documentation, they are really complaining about your API.

There are various reasons why, and I won’t go into detail on all of them. One of the reasons is that corporations are slow to move to new technology. They want it to be bullet proof; they want it backed by a company so they can get support now. Enterprise software has to meet these criteria. Of course the cloud has large backers also, like Amazon and Microsoft, but they don’t work well with each other.

Let’s not forget social media. You have your facebook account, twitter account, and google account. You update people about where you are on foursquare. You post videos of yourself on youtube, you checkout your friends on flickr, and most of all, you have to know what your friends are doing right now. Communication used to be simple when there was email and telephones, but now there are dozens of ways to communicate.

Now if you’re a corporate man like myself, you understand a different version of “social media.” You know it as voicemail and email. You search the web on your BlackBerry more than you do on your computer. You’re a proud corporate man. You segregate yourself from the rest of the social world. You know enterprise as the Microsoft Office suite.

So what’s different between corporate enterprise software and cloud services? One word, integration. You know if you buy Exchange Server, it will run perfectly with your Windows XP clients, and run beautifully on Windows Server 2008. Your email syncs to your phone and people can schedule meetings while knowing if you are available. Cloud services are run by multiple companies with little to no integration. It’s in their best interest to not cooperate with their competitors. You can see this just by the fight between Google and FaceBook. We have been using Microsoft for so long that it’s in our blood. It will be hard to dilute it.

Along comes this college student pitching his simple idea to a large crowd last Friday night at Startup Weekend. Why not take one step forward? Why not create a simple interface to all of the services you use? In comes ubercmd. Finally you wouldn’t have to worry about syncing all your contacts to five different locations. The interface is a simple, intuitive, fast command line type page. For a terminal junkie like myself, this is great. Just type email mark@codef... oh wait, it’s already there. And it’s showing my twitter and facebook accounts. Now three ways of contacting me instead of just the one you were about to do. It’s so simple, yet so brilliant.

So how does this tie into enterprise software? It is one step forward to interoperability between all the software you use in the cloud. That means we can stop paying the Microsoft tax and move towards simpler SaaS. Small companies can finally compete without having to pay outrageous pricing. It would be great if their 37 signals accounts would connect with their Google apps accounts. Finally the level of connectivity that Microsoft and IBM junkies have had forever.

Of course, this is a pipe dream, for now. All they have is a demo. This is where you can help. This group is in the running to win a trip to meet VCs in California. You can vote for them to win so this dream can finally come true. There are just so many possibilities on how this idea can grow and I’ll be the first to sign up when a public API goes live. Go check out startup weekend’s winning ideas and vote for the one you want to see win.

Now tell me, does it match the following?

1
2
3
4

public void OnClick( EventHandlerArgs args )
{
    ThreadPool.QueueUserWorkItem( _ => DoTheWork( ) );
}

If it doesn’t, you may be irritating your users.

So what can we do? Well your processing power is a limited resource, especially when we talk about the user interface. You need to treat it like the rare commodity that it is. If the cost of processing power on the user interface thread actually did cost you money, you would do anything you could to avoid using it. Well that’s how your user feels. Every millisecond on the the UI thread is another millisecond your user has to wait. It might not seem like much, but an unresponsive UI is a problem. It’s hard to see and even harder to test. You just know if something is unresponsive.

To fix this we need to move everything off the UI thread… I mean everything. Well, as you know, not everything can be on the background threads. You need still need to handle events and physically update the screen. These things are inherent to operating systems and GUI frameworks. Even if you could, the display updates all at once. So we work around these things by doing the bare minimum. The instant we are on the UI thread, we queue up work on the thread pool.

I told you before that multi-threading is difficult. Well, that is true, but it’s an issue you will have to deal with eventually. I will go into more detail in the future, but for now, just lock everything that you need. Don’t worry about efficiency on the background threads. It’s already in the background, so it shouldn’t bother the user to wait an extra hundred milliseconds. If you find that something is taking too long because it’s waiting on a lock, then you can go and optimize it using functional style programming or non blocking operations.

Now the GUI is responsive. Button presses are handled instantaneously and switching tabs happen right when the user clicks. Everything is great, except for the fact that there is no response to a user clicking the button. All it does is press in and out. No user feedback besides that. What happens if the background process requires multiple seconds to run? Well, you need to notify the UI thread.

This is where the BackgroundWorker comes into play. The ThreadPool.QueueUserWorkItem is fine for those quick processes you need to fire off, but we need something for the long running tasks. BackgroundWorker can access the UI thread whenever it’s needed. That means you can update the status of the process and notify of completion whenever you need and not worry about whether or not you’re on the correct thread.

Let’s look at how we use it.

1
2
3
4

// Create the worker 
var worker = new BackgroundWorker {
    WorkerReportsProgress = true,
};

We’re reporting progress in our example, so we need to tell .NET about that.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// Does the actual work 
worker.DoWork += ( s, a ) => {
    var w = ( BackgroundWorker )s;
    for ( int i = 0; i < 10; ++i )
    {
        // Slow process... zzzz
        Thread.Sleep( 1000 );

        // Report the progress
        w.ReportProgress( i * 10 );
    }

    // We're done 
    a.Result = "Success";
};

Here we’re running a slow process to show that the user interface is still usable. If you did this on the UI thread, the application would lock up for a full ten seconds and would never update the display. In this example, it’s harmlessly locking up a background thread.

1
2
3
4
5
6
7
8
9

// Will run on the UI thread
worker.ProgressChanged += ( s, a ) => {
    // Progress has changed
    progressBar.Value = a.ProgressPercentage;
};

// Also run on the UI thread 
worker.RunWorkerCompleted +=
    ( s, a ) => MessageBox.Show( ( string )a.Result );

Now we can update the user interface. The progress bar will update every second, and we didn’t have to check which thread we’re on.

1
2

// Run the worker on the threadpool 
worker.RunWorkerAsync( );

That’s all that’s required to run something in the background. Why would you even think of trying to do it in the foreground?

As we recall, we were creating idempotent (pure) methods and forcing the rules by using immutable objects. We can easily use these ideas to create queries and projections directly in code, where the original data is not modified. The benefit here, again, is that this will scale. Also, as will see soon, the application will run faster by the magic of lazy evaluation.

For example, let us say we have a list of ten thousand orders.

1

// Load all the orders IEnumerable<Order> orders = OrderRepository.GetAllOrders( );

Notice that the result returned is a generic IEnumerable. What happens here is that GetAllOrders doesn’t necessarily need to return the full list of orders, it can skip this step and return the intent of getting the full list of orders. The IEnumerable is actually hiding what the GetAllOrders method is really returning, an IQueryable.

1
2
3
4
5
6
7

public static class OrderRepository
{
    public static IQueryable<Order> GetAllOrders( )
    {
        return orders.AsQueryable( );
    }
}

The IQueryable interface provides a decoupling of the query source from the logic to be run upon it. In other words, the IQueryable interface stores the methods (lambdas) to be called upon its source in a tree structure. Later, when you want to iterate over the list, it will run the commands live on the data. This can significantly reduce the amount of data returned and won’t force you to create multiple lists of the same data in the various steps of the query. Haskell takes this one step further and actually allows infinite lists. This may seem odd to you, but since everything is lazily loaded, the list doesn’t need to actually exist in memory.

1
2

take 5 [1..]
[1,2,3,4,5]

Also, the IQueryable defines an immutable type, so it may be able to run on multiple cores. This is not always the case, though. For example, an IQueryable can be attached to a database, and therefore only run one SQL command. For now, let’s assume the list is stored in a randomly accessible location such as in memory.

What we can do with these queryable objects is throw expressions or lambdas at them. The IQueryable interface defines a long list of methods that can be executed, such as Where, Select, FirstOrDefault, etc. Each of these methods take in a lambda and will run that anonymous method against the function. For example, if we wanted to reduce our list of orders down to only the ones that were over $1000, we could do the following.

Lambdas in C# use a new operator that looks like an arrow (=>). This may be confusing at first, but generally becomes easier to comprehend as time goes on. I find it easier to talk the expression out loud and replace “=>” with “such that.” In the following example, I would say “Expensive orders = orders where ‘o’ such that ‘o’ dot total price is greater than one thousand.” If you can speak it out loud, it will be easier to understand. Of course, lambdas go deeper than this example, but you can find many other examples of the syntax by searching the web.

1
2

var orders = OrderRepository.GetAllOrders( );
var expensiveOrders = orders.Where( o =\> o.TotalPrice \> 1000.0M );

As I said before, the IQueryable is considered an immutable type. It will return a new query object every time you add more expressions to it. In this case, we now have a new query stored in expensiveOrders. The query stores a series of expressions for later use, allowing it to be lazily invoked. This can save us a tremendous amount of CPU work. If we did the above using a simple foreach loop, it may take a long time to run through all of them.

1
2
3
4
5
6
7

var expensiveOrders = new List<Order>( );

foreach( var order in orders)
{
    if( order.TotalPrice > 1000.0M )
        expensiveOrders.Add( order );
}

In this case, the program would be forced to loop through every order, even though they may not be all used. In a user interface, you can’t possibly show all the results of this query on the screen simultaneously. It could require many greater magnitudes of view space than the screen offers. We would need to display the list in pages. Of course, in the previous example, even though we may only show ten results, all ten thousand original orders would need to be checked.

However, if we stuck with LINQ, the query won’t be run until it is finally forced.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

int pageSize = 10;
int page = 0;

// Query first created
var orders = OrderRepository.GetAllOrders( );

// Not run yet
var expensiveOrders = orders.Where( o => o.TotalPrice > 1000.0M );

// Still not run
var displayedOrders = expensiveOrders
    .Skip( page * pageSize )
    .Take( pageSize );

// Now the query is finally run
foreach( var order in displayedOrders )
    DisplayOrder( order );

Although it’s not quickly apparent, the query is finally run before being passed to DisplayOrders. In this case, only ten results are needed. Because of the use of LINQ, the query will be stopped short once ten items are taken from the results.

Now that we know about pure methods and lazy invocation, let’s use that knowledge to actually build faster code. Next time, we’ll take a look at PLINQ and the Parallel Extensions library.

Functional programming doesn’t require esoteric languages. It’s more of a mind set than anything. Sure you could go right now and download Erlang or Haskell, but I can tell you that you’re about to go down a long, difficult road. The problem is you not only have to learn a new language, but you still need to learn functional programming. Instead, I’ll be writing a series of articles on how to implement functional ideas in your current language.

So, where do we begin? Probably the first idea to learn is about immutable objects. The general idea is that once an object is created, it can never be changed. Let that sink in for a second. If you have never created immutable types before, this may seem strange. In C#, for example, you can see a few areas where immutable types are present. Take the C# string type. Once you create a string, it can never be changed. All the methods return a new string with whatever changes you made.

1
2
3

string hello = "hello";
string world = "world";
string helloWorld = string.Join( " ", new[ ] { hello, world } );

In the prior example, both strings “hello” and “world” are unchanged by any methods. You can set a reference to a new reference with different data, but the original data will remain unchanged until its garbage collected. The benefit here is that we now have a strict rule we can leverage when it comes to threading. Because the object can never change, there won’t be any issues with thread safety. If two threads try to access that same reference, no big deal. There will be no concern of one thread changing the data from under the nose of the other.

So, how do we define an immutable type? This is where things get a little hazy. There are no strict rules that governs immutability in many object oriented languages. In C#, we can create class members that are readonly. This allows the data to be set within the constructors only, and then be set in stone.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class ImmutableClass
{
  private readonly int val;

  public int Val
  {
      get { return val; }
  }
  
  public ImmutableClass( int value )
  {
      this.val = value;
  }
}

In C++, we don’t have that option because there’s no such thing as the readonly type. In that case, we need to create class methods that are idempotent. Idempotent means that the method has no side effects, however, what does that really mean? My understanding of this is that the code will not make any changes to any existing data or interface. It won’t change any pre-existing data. It also won’t make any calls outside that may make a change, such as doing any input or output. Basically, if you call a method, the output will be exactly the same if you call it again with the same parameters. In other words, the code has “no side effects.” If all your methods are like this, you all of a sudden have an immutable type.

In C++, this is done by adding the const keyword to the end of methods.

1
2
3
4

int ExampleClass::Multiply() const
{
  return this->value1 * this->value2;
}

This isn’t a C++ only idea, however, other languages may not have the same keyword. The idea to take from this is to create classes that follow these rules. You don’t specifically need the compiler to force these rules for you, although it does help. That’s where functional languages come into play. They will force these rules on your code for you.

Now you have an understanding of the basic rules behind functional programming. Next time we’ll go into more of the ideas on using idempotent methods in real world ways. We’ll also discuss how you can actually connect these “functional” methods to standard methods.

Back when I was young, I made a program that converted a text file into an exe. This allowed shareware vendors to create self running catalogs. It was a pretty neat program, and had search, colors, mouse support, etc. I called it CatGen, and I even sold a copy or two. Not technically open source, but it built you a .BAS file (QBasic/QuickBasic) that included the text file. You can find it here (warning, not coming from a controlled source): CatGen 3.0.

I went on and started looking into 3D graphics, and at one point I wanted to become a game programmer. I studied all the latest books on OpenGL, DirectX, SDL, etc. It was fun, and I created my own game engine from it. I submitted it as my senior design project in undergrad. It was a full blown Quake 2 engine including rendering, physics, animations, sound, and music. I have to go find that code.

I went on to work for Motorola after college. I was working in a research and design group in the cell phone division. I was actually working with the people who designed the original RAZR, and my pride and joy was the “morphing” phone called the MOTOROKR E8.

I wrote all the software for the original prototype, and helped in analyzing and fine tuning the morphing, capacitive sensor, and the haptics. By the way, the haptics on this phone were amazing. Pushing down on the buttons felt exactly like a button, even though the keyboard didn’t move.

I decided to move on from there when the company was doing poorly, but I did take something with me. I took the idea I was using for the user interface and made it my own open source project (with the okay from my boss at the time). I called it MiniUI. This was a hardware accelerated, scriptable user interface. It allowed all the effects we take for granted on our smartphones now to be created simply and easily through XML and simple scripts. I wrote two papers on the project which can be found through the following:

• http://sourceforge.net/projects/miniui/files/Documentation/1.0/MiniUI.pdf/download
• http://sourceforge.net/projects/miniui/files/Documentation/1.0/ctirs08_submission_4.pdf/download

I also have a demonstration video, but it is pretty low quality and the recording was very laggy (hence the tearing on the screen).

To this day, that project still gets downloads, but I’m not sure why. It’s now 2-3 years dated. It also started getting more hits since I started this blog, but that is probably just be coincidence. Otherwise, I’d start believing you guys are stalking me.

Lastly, we come to my latest project. At my company, I created a data access layer for an application framework we use from Aptify. It’s an adapter of NHibernate and NHibernate.Linq to their proprietary system. It’s actually fairly complex, and after doing it I wonder why I finished it. Now that it’s done, though, we’re loving it. I submitted it to Aptify for their Aptify Innovations Award contest. I was one of the top finalists and spoke at their user conference in Las Vegas. After presenting my work to their community, the community voted me as the winner.

So I guess that makes me an award winning developer, although it’s a fairly niche area. You can find my project up on bitbucket at: http://bitbucket.org/markglenn/apics.core/src.

So what now? Well I’m currently working on a commercial client product in the message queuing market. Hopefully I can get that to the market in the next couple of months. In the future I’ll discuss more about the product as I build it. For one, I have a lot of interesting things to talk about in regards to some of the tools and middleware I’m using to create it.

Also, again, I’m going to Startup Weekend next weekend in Chicago. Actually if you go to that link, the top story (as of this writing) may look familiar. Yes, it’s my article! Chris, one of the people running Chicago Startup Weekend, asked to republish my article on the site. So I’m a proud guest writer. Not bad for a guy who got B’s and C’s in english and writing classes. Anyway, I hope to see you there. Also make sure you have your tickets for the event.

The problem isn’t that technology is changing, it’s that your language isn’t changing quick enough. Threads are the answer, or they were. Threads were the answer a few years back when we had two cores, maybe four. Now we have eight with sixteen just around the corner. And worse yet, cores may become less powerful to reduce heat and power. ARM processors have moved on to the personal computer and don’t seem to be slowing down. ARMs are a form of RISC processor or “Reduced Instruction Set Computer.” This means that it has a smaller instruction set than the laptop you have now. An instruction that takes one tick may take two in the future.

Okay, what gives? Why go backwards? Because it’s smaller, more efficient, less power hungry, etc… Smack a few dozen of those cores together and you have one fast machine. Now, I can’t predict the future obviously, nor am I marking the future death of the x86 instruction set. I’m just pointing out one possibility to show my point.

Okay, what is my point? You’re coding style will have to change if you want to stay “future proof.” Threading is difficult. It’s error prone, hard to predict, even harder to optimize. And what do you get out of this headache? Code that still takes only 1/8th of the CPU power available to it. The problem is, most of the time your code is waiting for input, an event to fire, or some I/O process to complete. You have to manage separate threads just to do the same job that was done on DOS years ago. Users expect responsive applications. If you want the truth, try using iTunes on a Windows PC.

So some languages have added features to help with calming your worried mind. For example, .NET added Parallel Extensions and the Reactive Extensions (Rx). And C++ finally added lambda expressions to the mix (although it was available in boost for a while). These help reduce the noise of making your code threaded, but still miss out when it comes to thread safety, deadlocks, or starvation.

You probably know the answer already. People have been blogging about it for a while now. It’s the new kid on the block… er, well, old kid. It’s functional programming, based off of lambda calculus from the 1930s. You may hear it by other names, such as F#, Haskell, Scheme, Erlang, OCaml, or LINQ.

Wait, LINQ? Yeah, you’ve been using functional programming all this time. All those lambdas you’ve been throwing at LINQ are examples of functional programming. And if you’ve done it correctly, they are possibly examples of purely functional programming. Those lambdas don’t have any side effects, so a search can be run on that list of 10,000 items on all of your cores, and without any work on your part. Parallel Extensions in .NET 4.0 does all the heavy lifting for you. This is great news, you say…

But alas, it’s not the final chapter in this story. Parallel Extensions are great if you constantly have to search for something in a list of 10,000 items, but your code answers to clicks and I/O events. You have more important things to do than playing around with something that’s of little to no use to the general coding population, building client applications. What we need is a true functional language.

And this is where the story ends, for now. Functional programming is the next logical step. Just imagine a language where you can write all methods, and they would magically run on other threads when branching, and that they would join up again when the branches merge. The code could trigger a UI update from one thread and not care if it’s on the UI thread or not. No longer are these your problems. You now write functions with no side effects; functions that are idempotent. Let the compiler worry about where the code should run, you have more important things to do.

It has started. Take a look at node.js. They use event driven functions. Most of the time, these functions call out to node.js, requesting or sending data, and send a callback to be called when it completes. No waiting. The server happily handles the I/O in the background and can process other requests while that Ruby on Rails site just sits there. It’s pretty neat stuff.

You can have this too for your desktop applications. F# brings .NET to the functional world. Qt has qtHaskell. wxWidgets has wx and Erlang. That means you can write WPF/Qt/wxWidgets applications that handle everything with event driven code and purely functional calls. It’s available now.

Problem is, functional programming is also hard, but in a different way. Of course, that’s for another place and time. For now, pick up a copy of Real World Haskell or Real World Functional Programming: With Examples in F# and C# and start coding.