You may have heard about test-driven development, or TDD. The idea is that you write all your tests, run them, watch them fail, and then write code that makes all the tests pass. There are many advantages to this approach. I have done projects with and without TDD, and the projects that used TDD came together more quickly and were more reliable. Yet myself and my teams still did not use TDD consitently. Why? Because it is a drag. Everyone knows that it is a better way to build a system, yet as you slog through the test writing, it is hard to convince yourself of that.

Along comes behavior-driven development, or BDD. Now instead of writing tests that fail (which is really pretty negative and depressing) you describe the desired behavior of your objects, and mark the implementation as pending. Since you probably have to document your objects anyway , it does not feel like a waste of time. And writing BDD tests is just more fun than traditional unit tests.

Some of the critics of BDD say it is just TDD with different terminologies and syntaxes. That’s more or less true. But anything that “tricks” developers into doing the right thing is worth paying attention to. Furthemore, you are likely to get better tests with more coverage, because the BDD frameworks make you want to write tests for everything.

Want to try out BDD? There are implementations for every major language. If you are using Ruby, check out the awesome RSpec framework. For other languages, see this page.

If you have tried TDD before and given up on it, give BDD a try. You will stick with it this time!

I used to think HTML and CSS were fine languages. Then I met Haml and Sass, and now I see the light. But first, a little perspective is in order.

Here is the assembly code and then the C code for a simple assignment and calculation:

MOVF id3, R2
MULF #60.0, R2
MOVF id2, R1
ADDF R2, R1
MOVF R1, id1

position = initial + rate ∗ 60

Compared to assembly language, C is operating at a much higher level, with benefits too obvious to enumerate here. But don’t forget that assembly language was a huge step up from hand-rolling machine code. And also recall that C++ took C to a new level of abstraction of by adding classes and templates. A language is “high-level” only in comparison to its brethren. Read More

The modern, SQL-driven relational databases arrived in the 80’s, before the Web had taken off. When developers started to build web-based applications, these databases were a natural choice for storing persistent data. Object-oriented databases (OODBs) were available, but they were not widely accepted due to performance and scalability issues. Here is the crucial point: relational databases were not chosen because they were a great fit for Web apps, they were chosen because that was the only realistic option available at the time.

With the arrival of Java and other object-oriented languages, the shortcomings of relational databases became more obvious. Developers now had to map their classes to tables in the database. Object-relational mappers like Hibernate made this process less painful, but it remained an awkward solution compared to using a real OODB. Read More

This was not an easy lesson to learn. Our site is less than a few weeks old and I had figured that it would not receive any large traffic for a few months. I was wrong. As some of you noticed our site hit the viral level with our article about web terms. The amount of traffic that was sent our way crippled our server and taught me the importance of caching mechanisms.

Read More

It seems that everyone has their own idea of what Web 2.0 means.That is one of the pitfalls to using a single buzzword to define everything you see on the internet. I have heard people describing nearly every new website as being Web 2.0 as if it was describing the launch date of a site. The term ironically is the most popular category on Resourceful Idiot. In leu of this, I am going to finally give you the definition of Web 2.0 and the principles that define it. In order to do that however, I need to start from the beginning with Web 1.0.

Read More

Stumbling around the internet today I noticed that there is a resounding movement toward the usage of UML diagraming applications. I agree that these programs like Microsoft Visio are cool and a required tool of most business development cycles, but they are a waste of time. There hasn’t been anything that can replace the tried and true methodology of diagramming on paper. Visio can never add enough features to match a developers artistic skills. So here I am to teach you in the next two paragraphs how to take an idea and turn it into code the easiest way possible.

Read More

In the first part of this two part article, I discussed a high level overview of the entire interview process. Now, as promised, I will discuss the types of technical questions that are commonly asked during the interviews.

When interviewing for any software development position, the most important quality for the interviewer to find out is your development skills. They will first look at your resume and begin to work off of that. Prep work begins by reviewing your own resume and making sure that anything listed on there is correct. If you listed something like C++, but have not programmed anything in C++ for the last few years, it is best to give yourself a high level review on a wikipedia article.
Read More

A couple days ago I promised an article analyzing the SOAP approach to building a web service. Well here I am keeping those promises for you all. SOAP can be looked at as the tried and true method for developing a web service. It has been around much longer than REST and currently has a much larger user base. SOAP is another technical acronym meaning ‘Simple Object Access Protocol’. It was originally developed as a replacement for the popular XML-RPC which even I do not know much about (its that dated). Since I am much more versed in REST than SOAP I will give you a quick breakdown on how it differs from REST. If you want more information, post a comment and I will find the answer for you.

Read More

Keeping with the trend of web services, I figured I would take the time to give a brief overview of the two major service types. The one I will obviously cover first is the called REST. This is an acronym for Representational State Transfer, but that does not really tell you much about it. REST is the newcomer when compared to its popular counterpart, SOAP. The idea behind REST is quite simple, its base principle is that everything is a resource. This is similar in principle to object-oriented principles which treats everything as an independent object. Since every resource is independent from each other, the programmer must set up relations between these resources in order to provide access links to related data.

Once the structure is setup with the required resources we need a way to modify these resources. REST provides a very simple interface for manipulation, it uses the existing HTTP protocol that has been around for over a decade. Now if you are familiar with HTTP protocol you are thinking, “So all you do is use GET and POST commands?” Well, yes you do use these but other requests are required. GET and POST are the most common of the two because these are the only ones primarily used by web browsers. However there are actually nine different request types in the HTTP protocol. A few of these are GET, PUT, POST, and DELETE. 

Read More

One thing I seem to come across when talking about new startup ideas for companies is the implementation of some sort of web service. I have personal experience building these type of services so I figured I would take a brief moment and talk about the technology behind them.

The first thing that you must understand is that a web service on the surface looks like nothing more than your average web site. I am sure most the sites you visit have a web service hidden in the background and you have no indication that it is even there. This is the beauty of the system, the service is only visible to those who really look for it. Transparency of this type of system is a thing of beauty, but this does not mean security is not important.

Read More