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.
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.
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.
For a long time, Ruby on Rails developers have put a good amount of effort into testing their apps. The Ruby on Rails community was the first to show me the beauty of automated tests.
The reason I write “Ruby on Rails community” is because I got to know Ruby through Rails, like thousands of other developers and a sickness we share is loading the whole Rails environment to application bits.
I’m not talking about the importance of developing applications entirely in Ruby and using Rails only as the gateway between the web portion and the business logic of your application, which is indeed a good idea. This kind of architecture approach was introduced to me by Uncle Bob and his really awesome screencast series from cleancoders.com.
What I am really talking about is testing our applications using plain Ruby, avoiding loading Rails environment entirely. My eyes shined when I watched the Corey Haines lecture about Fast Rails Tests. This lecture is what motivated me to write this post.
So let’s get our hands dirty.
Every Rails application has 4 important parts: Models, Controllers, Views and Routing.
Forgetting about the SOLID principles (this is not the focus of the article), let’s assume that we follow the Rails convention Fat Models and Skinny Controllers: our Models will have all the logic and we want to add a new feature.
Let’s say we have a Person model, it has a first name and last name methods and we want to concatenate them into a full name method. Pretty simple.
So, sure enough, we would start by adding specs for a method that shows the person’s full name:
Making this test pass is pretty trivial:
As a Rails developer, we know this test will take AT LEAST 8 seconds to pass and if you add more Gems, more Models etc, it will become slower and slower, and slower.
The reason this happens is that our test loads the whole Rails environment with all its gory complexity. It evens require a database to be present by loading ActiveRecord::Base. That means this is not a unit test at all, but rather an integration test.
To make matters worse, if in the future you want to change this method and include a middle name you’ll have to wait 15 seconds just for this one test to complete. It stinks. It stinks a lot.
The slowness will eventually get to you and you will want to start neglecting running the whole test suite because it takes minutes, not seconds anymore. So, when you break some unrelated specs by changing one feature in an unrelated test, you won’t notice until it’s too late. That bug went into your version control, other developers pulled and they want your head (and the one dollar fee) for breaking the build and not noticing it.
So it’s clear that we want faster tests, not only faster, but orders of magnitude faster than what we have.
Here at Webbynode we do this by isolating common behavior of classes into modules.
Let’s rewrite our example spec in a new /spec_no_rails folder using this technique:
There’s a lot of stuff going on here so let’s break it down into parts.
First, we require the naming module file, then we include it in a class created only to serve as the test subject.
Notice this class is in a plain old Ruby object and doesn’t inherit from anything, it exists with the sole purpose of including the concerns of our isolated module Naming.
Now, when describing Person::Naming, we want to use the class we just defined as our subject.
The rest of the spec is trivial and doesn’t change too much. We stub both #name and #last_name to completely isolate the behavior we want to test: that both name and last_name get concatenated.
It may seem that this is harder to test, but the benefits just scream. This test runs in around 10 milliseconds! You can run about 100 specs per second. I don’t know about you, but I find it amazing!
Making the spec pass is also very trivial. We just need to code app/models/person/naming.rb:
Finally, we write one (slow) new test for the Person class to make sure it includes our method:
That drives us to include the Naming:
And voilá, this is the fastest running unit test you will write in Rails… ever.
When you have slow tests, you start to drift away from TDD’s purpose… You may be concerned about how fragile the tests become with this approach.
Well, there’s always a trade off. You’d have to cover yourself with better integration tests, but we find this trade off does more good than harm.
We hope this simple example will engage you to try and make your Rails tests faster… For us, there was no looking back: we simply love it.
For more on the subject, be sure to check out Corey Haines’s lecture, where we first heard about this technique.
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.
Ever since we started working on Webbynode in 2008, all our work has been long-distance. We’re a distributed team across 3 continents. Working remotely has its advantages and disadvantages, but as any self funded startup we’ve had to do our best with what we got.
- Carlos – Miami
- Felipe – Brasil
- Chris – Austria
- Travis – Knoxville
- Paul – Sacramento
- John – SF
- Ben – NY
About 3 months ago we decided to make a change. Felipe would move to Miami so that we could work closer together, and really push hard to get things done more efficiently. This was a dream come true.
Lets get cranking
Fast forward a few months later, we were very motivated to get started. The first few days we were so happy about working together, we talked and decompressed more than anything. We were not able to get much done. A few days went on like this; not really productive at all -when it finally hit me. We weren’t used to it! We’d grown accustomed to having our private spaces where we could ‘zone-in’ and focus on what we had to do.
For this reason, we decided to try to work from our independent home offices once again. Felipe got himself a nice little office setup, and immediately, we could tell we were being a lot more productive by having a full 5-6 hours of uninterrupted time to get through our daily tasks, plus tasks from the projects we’re working on. However, there was something missing. After moving from Brasil all the way to the US, and still work remotely? Seriously? I mean, we live in the same city now, this is what we had always wished for, wth!?
So one day we were discussing that we should have certain sessions, in order to get through certain parts of projects that needed both of us involved. So, we played to our strengths.
Nightly 2-3 hour sessions
I personally like to work at night. There’s even times, I grab a project and I can easily stay until 6-7AM at it. I simply like it. There’s no girlfriend txting or calling, there’s no phone ringing, and hopefully no tickets are coming in. So, with this in mind, we decided to take daily 3 hour sessions, from about 7pm to 10pm max where interruptions would be minimal – and wow. We really felt this boosted our gsd tremendously. But we had to find a way to channel all our focus into these short sessions.
Since we’ve gotten accustomed to working with such tools as Basecamp, where you can setup a to-do list and add single tasks to each list, I decided to make our sessions to try to go through a whole todo-list, now dubbed a ‘mini-project’. A mini project, doesn’t mean the whole project will get done in one night, a mini project is simply a large project divided into very little mini ones, this way we can get a sense of gsd every single night.
For example, one of the projects we’re working on, is streamlining the Webbynode Manager user experience. In general, we want to have even less steps for a web app to be deployed onto Webbynode. Firstly, we decided which components need to be streamlined, but that’s still too general. So we decided to go for the initial signup process. We then divided the initial signup process into different mini-projects, such as work to be done in the front-end, changes to the backend is another one, automation is another mini-project, etc – you get the deal.
This allows us to work on each single mini-project per night or even making it a whole week project. But the feeling of gsd, is there every single night. It simply feels like this is the only way to work.
In the end, Felipe’s move to Miami has been greatly beneficial for us. It has allowed us to work in much more sync than we used to, but it also allows us to have enough uninterrupted time where we can tackle the majority of the daily-work. But even though we are not working 100% together, it has actually made the time that we work together much more valuable, therefore making it exponentially more productive.
How do you do it?
How do you do it? Whether its your startup, your consulting firm. How do you GSD? Leave your comments.