I have not had much time to post lately about Ruby, Rails or other goings on inside the community, this is due largely to my work on a new side project called Smokehut. The application is centered around being the one application you need when you hit the slopes at your favorite mountain resort. This ranges from tracking down friends to finding someone interested in grabbing a beer afterwards. Well, I don’t want to spoil it all right away so head on over and check it out.

It has been months since posts have been very active on Resourceful Idiot, that is largely due to other sites I have been focusing on. The primary site is my more technical and personal blog, eval(code). It has a much different flavor to it than posts over at Ri, but still has a focus on quality content. Other projects I have been working on can be seen at my splash page. I am hoping to get back into posting here at Ri, but need to build up some additional material.

If you analyze the vast majority of today’s successful software businesses it does not take a rocket science to figure out what worked, simple ideas are successful. The more simplistic the idea, the more simplistic the product, the lower the cost of funding, and the easier the pitch. Take a moment and think of your favorite applications you have used throughout your life, the common thread throughout those apps is simplicity. I am sure that some of you may have said Winamp and many did not say Windows Media Player, but why? Winamp is only a music player that really only supports a few features while WMP supports nearly every codec under the sun including video. Well, Winamp focused on a simple idea, “a great audio music player” while WMP wanted to conquer video, music purchasing and audio. Each added component adds an additional layer of complexity thus adding complexity to every aspect of the business from support costs to marketing. So you want success? Take a simple idea and develop it as close to perfection as possible. Apple has done it for years and look where it has gotten them. They have some of the world’s simplest applications (iPhoto), but also some of the most successful.

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

After a short hiatus from the series, I am proud to say we are back with another new business model. This week we are going to take a look at the data mining business model. Using this model means that revenue is generated as a result of data mining through the usage of a product. Nearly every business can use data mining as a way to increase revenue, but there is a growing trend to use data mining as a principle revenue stream. However, this approach does not come without its pitfalls.

Read More

Why bother spending the time and effort to create a clean, compelling resume? Is it really all worth it? After all, my code and projects speak for themselves. Right. Right? Besides, who else can write an orange peeling script in Bash that directly translates to assembly for deployment to my mechanical “peel a wizard” device.

Read More

It really is not a very difficult thing to master the art of salary negotiations. I spoke about some of the myths of software development salaries that were told to me when I applied for positions. Now, I will take a look at negotiating your salary during the employment process. The biggest mistake any applicant makes is filling in the area labeled “expected salary.” This is a question with no good answer, so it is best just to avoid answering. If you ask for too little the company will pay you that salary, but if you ask for too much they may pass over your resume all together.

Read More