We bring good news, Ubuntu 12.04 64bit is now available for redeploy. Please note that this does not guarantee you can upgrade from your old setups.

If you have any problems please make sure to submit a ticket.

Thanks!

Felipe

Want to see what we’re cooking next? We’ve been working tirelessly behind the scenes in the past few months to bring some great new upgrades to the Webbynode family.

We are revealing for the first time the new and upcoming Webby Manager v2. Here’s a screenshot of the new Webby dashboard.

We’re very close to having it completed, we’re in the final internal testing stage and we’ll be having some lucky few be part of the customer beta testing. We’ll let you know when its time!

We’re always craving your feedback so please let us know what you think.

I’ve never programmed in pair. Two developers sat down in front of a single computer and they code together with one as the pilot and the other, the co-pilot. But in the last weekend I’ve joined in a local event in Brazil organized by my community that mainly studies and practices Agile principles.

During the event, I’ve led a Coding Dojo using Ruby to solve a Fizz Buzz game. That was my first Coding Dojo I’ve ever participated in!

Summarizing… the rules of Fizz Buzz game are like the following:

• If a person’s number is a multiple of 3, he must say “fizz”
• If a person’s number is a multiple of 5, she must say “buzz”
• If a person’s number is a multiple of 3 and 5, he must say “fizz buzz”
• If a person’s number isn’t multiple of 3 or 5, she must say the number.
• If I make a mistake, I drink! This is the best part.

So before the Dojo started, I coded by myself what I thought the final code could be, just for practice.

I got the following specs:

So my own code:

Well. I did it alone, and I thought it was beautiful! Simply beautiful! Why? Because the specs say just the truth. They show us what the code should do. I could read the test and be just fine. Note that the spec descriptions are almost the same as the rules list I showed above.

Then the Dojo began. Half of the participants were new even to Ruby, but were at least a developer in some other language, but none of them was used to TDD.

Anyway, the code began. I started and sat down in the pilot’s chair and I was half coding, half teaching about good practices of programming, especially TDD.

I wrote all the specs, it was enough, but my 5 minutes were gone and I just wrote the first implementation of Game: when the number is multiple of 3, returns “fizz”.

Then a friend of mine took my place and some one in the audience took his co-pilot place. Then after about 1 hour, we’ve got the following production code (the specs weren’t changed).

I was simply amazed: this code was better than mine! If you check this new code, you can read the class just like the bullet list I showed you about the Fizz Buzz’s rules! Fantastic!

Then I was the last to sit in the pilot’s chair, and I improved the code a little bit:

What do you think about this last version of the code?

Yes, we could use “number % 15 == 0″ in the .number_is_multiple_of_3_and_5? method, but we didn’t, we just didn’t think about it at that moment.

But note the main improvements:

I’ve set the methods that use math to private, so the Game class interface just shows what the class should do: run the FizzBuzz game without knowing how it does it.

I have also improved the if/else syntax. Now the Game rules are perfectly readable in the specs and also in the production code! Couldn’t even a non programmer read the production code? Beautiful!

I try to get rid of IF when I code, that’s why my first implementation of the code I did for the Fizz Buzz game had less IFs. But I got rid of the most important: readability, even if it has more IFs.

Thanks to the Coding Dojo dynamics, the code became cleaner and more beautiful, even more so than my first code attempt.

Did the Coding Dojo finish after the event? I’m glad it didn’t!

After showing the code to friends in Webbynode, we refactored the code to the following:

Now we improved the private method names to fit the purpose of our Game! It’s readable just like the last one, but now we can inherit from Game class and create a new game class that uses multiples of 4′s and 7′s if you wish! Have you ever heard about the Open Closed Principle?

In the future, the maintenance would be easier, faster, cheaper and more enjoyable.

This is the power of Pair Programming.

Doing Outside In development is important. You will be able to better design your classes when dealing with use cases or stories.

Imagine you have a notebook, when you turn it on, you also need to turn on its monitor and keyboard.

Let’s write some acceptance tests for this.

Let’s try to implement the acceptance spec starting with Notebook:

Hum, of course it will fail for many reasons. First, we need Monitor and Keyboard classes and they need to respond to #turn_on. We need two already implemented classes just to start writing our Notebook class!

Dependency Injection to the rescue!

Dependency Injection is very discussed in programming development for decoupling code. In Ruby we feel like we get it for free. It improves our code design by decoupling classes and eases our tests.

So, let’s start writing unit tests for Notebook with Dependency injection.

Nice! We didn’t need Monitor and Keyboard classes to write our Notebook code! We can test everything in isolation because we’re able to stub our methods/constructors inputs, so we won’t need the actual objects.

Remember, Ruby is a very powerful dynamic language. It doesn’t care about type, only about their interfaces. If a Monitor and an ExpensiveMonitor behave like the same for the computer needs, it will work.

Our unit tests for Notebook are green now! Yay! Look, we don’t use Monitor or Keyboard objects, we use stubs, so you need to pay attention to some points. Look at the #as_null_object I added in monitor and keyboard stubs. It’s needed because our stubs don’t respond to #turn_on.

Each expectation mocks the #turn_on in a SINGLE object and expects it. But the other doesn’t respond to it, so each test would fail because of the other dependency.

Using #as_null_object, we tell the stub to respond to any method in any test, so it won’t break other tests so each test will have only one expectation.

So our Notebook works as expected, but our acceptance test is still red because we don’t have Monitor and Keyboard.

And our monitor and keyboard:

Now our unit and acceptance tests are green. We did Outside In development and improved our unit tests with Dependency Injection. We didn’t need Monitor and Keyboard at first to test our Notebook.

This is a silly example but in the real world our classes have many dependencies and if we begin writing things the Inside Out way, we will write more code than we need.

In 2009, Joseph Wilk had a very nice talk about Outside In development With Rspec and Cucumber on Scotland on Rails 2009.

You can start Outside In development from acceptance UI tests until the core of your application’s unit tests so you won’t loose yourself writing code you don’t need, and Dependency Injection will help you develop your project step by step, making you happier and your life easier.

Here we go again. That feeling of creativity rushing through, new ideas, new concepts, brain pushing keywords non stop – it is the birth of a new project.

Part of my growth in years past, has been to methodically look at a problem and understand what actions I need to take in order to reach the solution. In the case of a new project, when ideas are flowing and your mind is high with the countless thoughts racing through, it is very easy to quickly become overwhelmed.

Not knowing were to start, One must slow down and analyze and understand the task at hand. We must always plan our approach – some may be against such planning, however I find it imperative in order to avoid the mental treadmill and never see the project come to life.

I will be posting every week about ways to solve this hurdle, and actually get somewhere. There are many obstacles that block our way and deter us from achieving our goals. Let’s find solutions and ways to overcome those.

The Nature of a Startup

Let’s start with Eric Rie’s brilliant definition of a startup “A startup is a human institution designed to deliver a new product or service under conditions of extreme uncertainty“. On top of that, being part of a startup is almost like being a professional juggler. Startup founders have to play multiple roles, from being good at leading the team, providing customer support, answering the phones, etc. In short, doing whatever it takes for the company to be a success.

In this juggling process, there are a lot of risks. It’s very easy to get overloaded, to only focus on the parts that you like, to procrastinate, and the worst one in my opinion, paralysis of analysis – which is a direct effect of not having a plan.

The 3 week cycle

In this post I won’t get into daily activities, but rather on creating a plan for your activities. We need to make it short term, not more than 3 weeks.

Your plan should contain the following tasks:

• This initial task is an important part of the process. Create firm goals, purpose and deliverables.
• Risk analysis. Possible red flags for tasks that may delay your project.
• Budget analysis. Even if your team (or if it’s only you) are running on salary, or if it’s a freelance project, make sure you quantify your hours per week per person and create your expense budget for the project. This is important in order to have clear visibility of how much it is costing you to deliver these goals.

Week 1 is the immediate activities which will lead you to understand what must happen in order to see this project come to life. Week 1 is the beginning and also the re-start of the 3 week cycle. Take this time to perform any research needed, analysis of your numbers, metrics, and of course, finalize your daily tasks and goals for the upcoming 2 weeks.

Weeks 2 and 3 are where the magic happens, this is where you execute all the ideas gathered and planning put forth during the first week.

In the end, ideas are nothing without proper project planning and execution.

This text is based on a comment I read in HackerNews but I adapted to my own version which expresses my feelings about Steve’s death.

Considering how apparent it was that Steve’s health was gravely bad and rapidly deteriorating, we all in the back of our minds knew the time we had him in this world was limited and precious. So it comes as a complete shock to me how upset I actually am by Steve’s passing.

Even though most of us never knew him, we all feel as if we did know him very well; his inventions, complete labours of love, have become so central to how we live our lives. The profound impact his creations have had on us cannot make us feel any other way.

I remember when I bought my first Mac. It was completely worth it because purchasing that machine literally changed my life.

Without a computer that was an absolute joy to use, I would have never spent so many hours having pleasure while coding and consequently now have the career opportunities that I do.

I feel eternally indebted to Steve, despite having never met the man myself. By creating the wonderful tools he did for us to work with, I feel he is significantly responsible for the career I have today.

To one of the few that can say ‘I changed the world’, thank you.

Rest in peace Steve!

Interesting talk on UX from Google I/O 2010

For the curious: Yes, Slicehost is one of our strongest competitors for sure. But, more than simply competitors they’re also our colleagues, friends and even more imporantly, we value how they helped shape the market we see today. This is a tribute to them for their contribution and great work.

When Slicehost started selling their VPS product back in 2006 I was starting my first company where we did a ton of hosting for enterprise customers, which is no doubt is a very different world from the world that Webbynode exists today. This world was started to get defined by companies such as Slicehost.

Slicehost was one of the first to actually come out and challenge the rules of the “all you can eat” hosting providers by offering a concise and very well focused product, for developers. In reality, they did great a great job, Matt and Jason were smart enough to work together in order to make Slicehost a very ‘personal’ company that you could work with and get all your answers not from some boring guy in a tie, but you’d get an answer from a person just like you, a developer.

Some great stuff from Matt & Jason:

• Hacking Cashflow
• What’s up with the wait list?
• 3 way handshake Ep1
• Slicehost Podcast
• 10k slices and more

Earlier this year I met Matt, and since then he’s become basically an advisor to us. He and I see very eye to eye about what a hosting company for developers should be. In general, we understand the same principles of offering more than simply a barebones product, and offering a service along with it and in general doing the extra steps to get stuff done for customers. This all falls into the same concept of how the small Italian Restaurant is gonna care more than the big ‘brand-chain’ restaurant and usually give you a better quality product.

What’s Matt and Jason up to?

I never personally met Jason, but from what I know he moved to Texas to work with Rackspace after their acquisition. Matt is doing some rad work doing his own investments and also some very cool projects such as DevStructure, its a tool that lets you reverse engineer the setup in a server and generate configurations for Chef and Puppet.

We want to offer our best wishes to the Slicehost founders, and all the guy who worked there to make it to the great successes they had.