path11 crafters

Enrique Comba Riepenhausen: The Impersonator Pattern: Redux - Getting rid of the world at a method level

ecomba — Fri, 05 Apr 2013 09:09:56 +0200

Enrique Comba Riepenhausen: The Impersonator Pattern: Redux - Getting rid of the world at a method level:

Last 4th of April I gave a talk on the Impersonator Pattern during the CukeUp! event at SkillsMatter.

Before my talk I was talking to Andrew who also presented during the conference and we had a nice idea about how to improve my impersonator pattern.

There was always one thing…

Kicking ass - The experiment

ecomba — Fri, 01 Feb 2013 13:10:53 +0100

At the end of last year we wanted to give you an offer you could not refuse to take, we called it Kickass 2013.

Our aim was to help people with ideas not to have any excuse to get it out to the market by offering an insanely attractive price.

The experience has been really nice! We talked to some really nice people and started working on some really nice products.

Soon we will be reporting more about them, so stay tuned!

Now that the kickass deal is over we have revamped our site, check it out!

It's out!

ecomba — Mon, 14 Jan 2013 09:35:45 +0100

It's out!:

ecomba:

What a frantic weekend! Last week I made the bold statement that I wanted to publish my book on Monday. Since then I have been regretting that decision more and more as Monday slowly drew closer. It’s possibly a common thing when you are going to release something that you haven’t done…

Kick some ass in 2013

ecomba — Wed, 19 Dec 2012 20:13:31 +0100

2012 was a great one for patheleven. We got to work with some amazing people.

We delivered great work. We poured ourselves into their mind, their business and their dreams.

We learned a great deal and experimented with some ideas. Actually experimenting with ideas is in the core of what we do. You see, for us patheleven is a vessel. A vessel that allows us to be creative and live the lives we want to live.

Anyhow… Let’s get to what we wanted to share with you with this blog post…

In the spirit of experimentation we came up (actually it was Sebastian, so you know who to blame if this goes wrong) with a really crazy idea; start 2013 with an insanely attractive weekly rate and slowly increase our prices during the year.

This idea was inspired by Jason Sadler who in 2009 sold an entire year of shirt-wearing, promoting a different company every single day. We loved the concept as we didn’t know about anyone doing this kind of business and we thought we could apply the same principles to our business.

The principle is very simple, you will be able to book weeks during the year (we call them iterations) and we will kick some ass for you!

The only issue is that we will only be offering bookings at the super reduced price till the end of February!

You should checkout our website and book some time with us so that we can some kick some ass with you!!!

What are you waiting for?

We are changing our logo for 2013, this is a fake 3d...

ecomba — Tue, 18 Dec 2012 12:44:00 +0100

We are changing our logo for 2013, this is a fake 3d representation of what’s about to come…

Clean cukes: The impersonator pattern

ecomba — Thu, 06 Dec 2012 10:35:23 +0100

On our path of writing cleaner code we often forget that the code that is testing that our application should be clean as well.

At path11 we try to make sure that every piece of the software we write is clean, dry and readable.

Recently we have been looking with more detail at how we write our cucumber features that will drive the acceptance testing of our code.

When you think about the features in depth there is a recurring theme in them: you are testing the application assuming the role of a user interacting with the system

This is oftentimes overlooked and you end up with features and scenarios that look like this (I’m going to use an application I am developing for internal use at path11):

Feature: Logging in
  In order to make sure that the site is secured
  As a path11er
  I want only other path11ers to log into ledger

Scenario: path11er logs in
  Given I am a path11er
  And I am on the landing page
  And I follow "login here"
  Then I should be on the dashboard

 Scenario: anonymous user trying to access
  Given I am an anonymous
  And I am on the landing page
  And I follow "login here"
  Then I should be on the landing page

There are a few problems with the scenario definitions in this feature.

First I am tying the description of the steps in the scenario to the actual pages the user is “visiting”.

Secondly, and more importantly I am NOT concentrating on the real value proposition of this story.

Most of the time we overlook what the real value of a feature is and write the cukes in a way that we as developers understand better.

A way better approach is to only describe the value proposition of the feature and hide the implementation details inside the step definitions (or even better inside an impersonation of the user interacting with the system under test, as we will see later):

Feature: Logging in
  In order to make sure that the site is secured
  As a path11er
  I want only other path11ers to log into ledger

Scenario: path11er logs in
  Given I log into ledger as a path11er
  Then I should be on the dashboard

Scenario: anonymous user trying to access
  Given I log into ledger as an anonymous user
  Then I should be on the landing page

As you can see this feature and the step definitions are coincise and to the point. We (or our customers) are not interested in the how this is accomplished, but we want to see that the application implements the features we requested.

Most developers will now implement the step definitions describing how the browser interacts with the application.

The problem we found by doing so is that we are not impersonating a user and we will have to write redundant step definitions that assure that the user that is interacting at that moment is the user we are interested in.

We felt that there was some key point missing there, something that would help us to describe our application better. During our inception workshops we define personas that we later relate to when thinking about how to implement the user stories.

These personas where actually the missing link we needed to change the way we write our cukes.

Introducing the Impersonation pattern

Let’s first look into the step definitions for the improved feature we saw earlier:

Transform /^a path11er$/ do |user|
  path11er
end

Transform /^an anonymous user$/ do |user|
  anonymous
end

Given /^I log into ledger as (a path11er|an anonymous user)$/ do |user|
  user.is_in_the_landing_page
  user.login
end

This is where the impersonation magic is defined.

We first use cucumber’s transformations to initialize the impersonation classes that will be interacting with the system. This classes are implemented as modules and will sit in the support directory of your features and included into the world definition:

class LedgerWorld
  # other includes left out for clarity
  include Ledger::Cucumber::User
end

Let’s look with more detail into this impersonator.

As we saw earlier in the transformations the instantiation of the impersonator will happen in there and is declared like so:

module Ledger
  module Cucumber
    module User
      def anonymous
        @anonymous ||= AnonymousUser.new(self)
      end

      def path11er
        @path11er ||= Path11er.new(self)
      end
      #…

If you look again into the next step definition we have:

Given /^I log into ledger as (a path11er|an anonymous user)$/ do |user|
  user.is_in_the_landing_page
  user.login
end

It becomes obvious what those objects implement:

class AnonymousUser
  def initialize world
    @world = world
  end

  def is_in_the_landing_page
    @world.visit '/'
  end

  def login
    # stubbing of omniauth requests left 
    # out for clarity of the example

    @world.click_link 'login here'
  end
end

The Path11er class has a similar declaration as the AnonymousUser class (although in the real implementation the stubbing of the OmniAuth code is silghtly different in both cases).

The greatest benefits we have found for implementing our cucumber features like this are:

Our scenarios are much clearer and to the point without unnecessary steps.
The step definitions make reveal what the user is doing in a clear way and without the details
The impersonator objects help us think as the user interacting with the system at that moment improving the general user experience of the system.

What are your thoughts on cucumber testing? We would love to hear from you and see if we can improve even further the way we test our applications.

11 things we learned (part 2)

ecomba — Thu, 29 Nov 2012 13:33:46 +0100

This is the second part of our post 11 things we learned, if you haven’t read the first part we urge you to read it first.

Okay, let’s continue with the things we have learned in this past year then.

7. Starting from the UX seems to be the answer.

We have found out that when we work on a user story we have a hard time coding it if we don’t pay attention to the overall user experience.

We tried coding without going through wireframing and thinking how the flow of the story (or application or the screens) should be and the result is more often than not a mess.

Coding, although not easy, is the simplest task you can do when implementing a user story. We figured a common workflow of how we work best which has given us pretty good results.

When we work on a story we usually do the following:

create a low key wireframe of the flow (for this we use Apple’s Keynote)
share that work with the customer (either by sending them a pdf or in most cases share a video over dropbox with our thoughts behind that flow).
once it is validated we write a Cucumber Feature and the accompanying Scenarios to have an acceptance test for that user story.
then we start our TDD/BDD cycle and work on the story and apply a little design to it
once it is finished we share that with the customer on a staging environment for the app and try to get validation from it.
once validated we will do some UI magic, revalidate it with the customer and have the story ready

We are still refining those processes we do as we go. Maybe this is worth another blog post to share with you our process in more depth (let us know if you’d like to hear more about it).

8. Short projects make us happier than long projects.

We are always looking for new techniques and technologies, we love it!

We have figured out that, although the projects we do haven’t been specially long in time (if we compare to those year long projects you can find in more enterprisey environments), we do like projects that are rather shorter than the longer ones better.

When you start something new it is exciting and you are all hyped about it. This fades away over time as it is hard to keep a group motivated for long.

Also this has to do with the amount of work we put into the work we do. Unlike other teams that have a slower start into a project we make sure that from the start of the project things move quickly and our customers feel and see that they are getting value for money immediately.

When a project is really long this is harder to maintain as the value of the things most customers request over time is less valuable to their business.

9. Don’t rely on email communication for difficult conversations

We’ve made this mistake. It’s an easy one to make. Sometimes you are just tired or you don’t feel like starting a conversation, and you send an email. That’s wrong.

It’s not like if email is wrong, sometimes, and for some easy talk, it is ok to communicate like that. The problem is when you use an email to start a difficult conversation. It’s always better to call.

10. Our market is global

When we started path11 a compelling reason to set up the company in spain was that the market in this country is very immature in terms of agility and craftsmanship, or should we say, quality work. We thought that we could offer a great service to spanish customers who are really interested in having great products.

We could not have been more wrong

The spanish market is a whole different kind of fish than the markets we are used to. In Spain you don’t look for quality, but for the cheapest solution around. It seems that the whole country is in a race towards zero (I will offer less than you and then you offer less than me and at the end no one wins).

We first thought that it might be that we are just talking to the wrong people, but as time went by we realised that it is a cultural thing, something that is not likely to change in the future.

The good news is that our services are cheaper than the average high quality development work you find out there in the USA and northern European market, which has won us a deal or two.

We might be wrong about Spain and the spanish market, so if you are there and need our help just get in touch with us!

11. Love your customers

One thing you have to realise is that your customers shape your business. The way you interact with them and the way they do with you; what you as a team allow and don’t allow will set a precedence into future interactions with customers.

For that reason you have to truly understand your customer if you want a productive working partnership and be really able to provide the maximum value.

This is why we set up an inception workshop at the start of every project to know what exactly is in our customers mind. This will give us an initial understanding of the project and the team we will be working with, which helps to gauge and see if the relationship can take us to where we want it to be.

An inception workshop is a wonderful tool, but it’s by far not sufficient if you are wondering. When you are in the service business you have to really start your every day you are giving a service to your customers as a new challenge, focusing on trying to understand your customer, where he is coming from, and trying to offer the best solution that suits you both best.

Coffeescript cookbook

ecomba — Tue, 27 Nov 2012 10:00:52 +0100

Coffeescript cookbook:

Do you write coffeescript instead of javascript? Are you learning it right now? You should check out this website that offers some recipes for coffeescript. Very useful when your memory is not the best in the world any longer ;)

Commands, Queries and RSpec

j4cegu — Mon, 26 Nov 2012 11:00:36 +0100

Reading part 4 of Growing Object Oriented Software book has made me think a lot about how I test drive my code. There is a lot of insight in that part of the book about how to write readable and maintainable tests and how to use them to catch design problems.

One of the tools you have to find those issues are mock objects and the use you make of them. Depending on whether the method uses collaborator’s commands or queries the test should change.

For those of you who don’t now what commands and queries are, it’s just a way of categorize the methods of an object. If the method causes side effects then we call it a command. If the method doesn’t change anything we call it a query. Typically commands do not return a useful value while the main purpose of queries is precisely providing information.

For a long time I’ve being making this distinction while testing my code with RSpec:

If the method I am testing needs to call a query on one of the subject-under-test’s dependencies, the test will stub the value returned by that method. And I will use RSpec’s stub and and_return methods to do that.
If the method needs to call a command on one of the subject-under-test’s dependencies the test will assert that call has been made. I will use a mock object for the dependency and the should_receive method for the assertion.

That means that if I ever need to use should_receive and and_return in a method, something is wrong with my design. The method I am mocking/stubing is both a command and a query and that shouldn’t happen.

This vision seems pretty aligned with what Steve and Nat say in the book and the use they make of JMock’s allowances and expectations. There is a feature I have missed from RSpec though, which is actually used often in the book’s examples: the ignoring clause.

When you have a method that sends commands to two different collaborators then you would end up with a test with two message expectations. Let’s see an example:


def success
  @collaborator1.notify_success
  @collaborator2.handle_success
end

That leaves us with two options: either add both message expectations in the same spec or write two separate tests and stub one message and assert on the other. I don’t like tests with more than one expectation because they end up making diagnosis harder. So I usually stub the message. You can see an example in a library that we recently open sourced.

This breaks the semantics that I usually give to stub as I am using it to ignore a command instead of actually stubbing the return value of a query. I am going to start aliasing the stub method to ignore in my spec helper file so I can write the specs like this:


it 'notifies success' do
  @collaborator1.should_receive(:notify_success)
  @collaborator2.ignore(:handle_success)
  subject.success
end

it 'handles success' do
  @collaborator1.ignore(:notify_success)
  @collaborator2.should_receive(:handle_success)
  subject.success
end

While this is only a semantic problem makes a huge difference while you are reading the test because it removes the ambiguity stub usually has.

rbenv

ecomba — Mon, 26 Nov 2012 09:00:37 +0100

rbenv:

Do you want to be hip again? You know, the cool ruby cats use rbenv now…

I have been using rvm for a while now, but today I switched to rbenv (just for the chops actually) and like it so far.

If you miss rvm’s ruby installer there is a plugin for that: ruby-build.

If you miss rvm’s gemsets there is a plugin for that as well: rbenv-gemset

The Early History Of Smalltalk

ecomba — Mon, 26 Nov 2012 00:46:00 +0100

The Early History Of Smalltalk:

Corey Haines tweeted this link a few days ago and it’s definitely worth reading!

Old article from Kent Beck about design

ecomba — Sat, 24 Nov 2012 14:10:46 +0100

Old article from Kent Beck about design:

A very interesting read about Connected and Modular Design which focuses on writing software systems so that the cost of features stays the same over the lifetime of a project/product development.

If you have read about Adapters and patterns or Hexagonal Architectures you should definitely read this article!

The Little Redis Book

ecomba — Thu, 22 Nov 2012 07:57:29 +0100

The Little Redis Book:

We stared recently toying around redis when we need some low key store that we can use without much ceremony. I found this little book while searching for some more information about redis and found it very instructive and simple to read.

The rake file task

plagelao — Wed, 21 Nov 2012 11:00:50 +0100

I have been using rake for at least 2 years now, but it looks like I don’t know how to get the best of it yet. I watched Jim Weirich’s talk at Goruco 2012 (Power Rake) and I realized (again) how important it is to know the tools your using.

Slow tasks

In one of our projects, we use rake to compile our coffeescript files to one javascript file, and to minimize that javascript file. We do this to speed up the application, but that’s a different story.

This approach works fine, but it is somehow slow when your in your development environment and you want to run the app. At that point, we are generating the minified javascript first and then we are launching the app.

Compiling the javascript takes around 10-20 seconds (depending on how good your computer is. Mine is not the best one), so the server start up is not as fast as we would like it to be.

This is more or less what how we do it:

task :some_js do
  files = [
    'views/coffee/models/a_model.coffee',
    'views/coffee/models/another_model.coffee',
    'views/coffee/models/one_more_model.coffee',
    'views/coffee/collections/a_collection.coffee',
    'views/coffee/collections/another_collection.coffee',
    'views/coffee/views/a_view.coffee',
    'views/coffee/views/another_view.coffee',
    'views/coffee/views/one_more_view.coffee',
    'views/coffee/views/still_one_more_view.coffee'
    ]
  compile :some_js, files
end

The compile method generates the public/js/some_js.js file.

We have more than one task, since not every part of the application uses the same set of coffeescript files. In total, we have 5 rake tasks like the previous one, and our rake task to compile the coffeescritp and to start the aplication is like this:

task :rackup => ['coffee:some_js', 'coffee:different_js', 'coffee:more_js', 'coffee:a_bit_more_js', 'coffee:some_more_js'] do
  system 'foreman start -p 5000'
end

This is too slow because it compiles and minifies all the javascript everytime we launch the application, even if we haven’t changed any of it!

File task

We’re not the first ones with this problem, and there is already a solution to it in rake (Thanks Jim Weirich!).

We need to use the file task!

As it says in the documentation, “If a target file is newer than all its dependencies, then the task actions do not need to execute”. This is exactly what we want! If nothing changes, don’t execute the task :)

We can change our rake tasks to looks like this:

LOT_OF_FILES = FileList[
  'views/coffee/models/a_model.coffee',
  'views/coffee/models/another_model.coffee',
  'views/coffee/models/one_more_model.coffee',
  'views/coffee/collections/a_collection.coffee',
  'views/coffee/collections/another_collection.coffee',
  'views/coffee/views/a_view.coffee',
  'views/coffee/views/another_view.coffee',
  'views/coffee/views/one_more_view.coffee',
  'views/coffee/views/still_one_more_view.coffee'
]

file 'public/js/some_js.js => LOT_OF_FILES do |t|
  compile t.name, LOT_OF_FILES
end

task :rackup => ['public/js/some_js.js', 'public/js/different_js.js', 'public/js/more_js.js', 'public/js/a_bit_more_js.js', 'public/js/some_more_js.js'] do
  system 'foreman start -p 5000'
end

Now, everytime we run our rackup task, it will only compile and minified the coffeescript if we made some changes to it. By default, the app will start without any delay and, even if we change some of the coffeescript, it won’t compile all of it, only the tasks that need to be updated because of that change, so it will be faster than before.

I think this is pretty awesome.

Docco

ecomba — Wed, 21 Nov 2012 09:10:00 +0100

Docco:

I found this by pure chance while I was reading some documentation of some open source project. The way some projects are documented (using docco as it happens) always caught my attention and I always wanted us at path11 do something like this for our open source projects. Maybe now we don’t have an excuse ;)

11 things we learned (part 1)

path11 — Tue, 20 Nov 2012 12:18:00 +0100

We are one year old! Oh, well, this was supposed to go out on our birthday, but it didn’t…

In this post we want to share what we have learned the past year. Some of them are failures and other ones small victories that define what path11 is today.

As the post was very long we split it into 2 parts. Let’s start with part 1 then, shall we?

1. We like sharing things with the outside world; but we didn’t do a good job at it.

We really love reading blog posts, articles and books other people write. In fact we have a part of our daily standup meeting where we share new and interesting things we have discovered. We also love the idea of sharing our experiences, but let’s be honest, we are really bad at it.

We get bogged down in our own world (customer projects and other ideas) that we totally forget that sometimes it would be interesting to you, our readers, to know about what we are up to or what we have discovered.

The path11 Zeitgeist so to say.

This is something that we are actively working on improving, and we have decided finally to take action about it and post more often.

In the days to come we hope that you will find more interesting posts here as well as links to the things that catch our attention while learning; what we call interesting things.

2. It’s very hard to let co-founders go.

You might, or might not know that we let two of our co-founders go during this last year. It was a really hard decision, possibly the hardest one we took.

When you build a company you build it with the shared dreams and vision from all the founders. During the process you align those and find common denominators that will help the company to shape the way you want it to be shaped.

If things go well everything seems to flow into the right direction not needing to struggle to much about it (apart from the common problems of running your own company that is).

The alignment of path11 was broken for some time and we were battling internally very hard to get it moving in the right direction. This led to the inevitable and yet so painful situation of letting go.

Letting go is hard, it can kill friendships and cause a lot of damage. We really crossed some dark times going through the separation, but at the end we came out of it stronger than before.

3. It’s hard to find a sustainable rhythm of work.

Everything seems to be urgent when you have a company, but you can not achieve everything even if you work 12 hours a day (we’ve tried that!).

Finding our pace is one of the most difficult things we’ve found this year. We are still trying to find it.

You need time to live your life appart from the company, but yet your company seems your only life sometimes.

The main problem is that the work you love doing is now shared with the work it takes to run a company. Somehow you don’t want to give up on coding, or designing a great new user experience for an application, so you set the business time to after work; result 12+ hours of work.

This is sometimes not even true, we have another problem.

Our passion for developing software makes us stay late at night trying new things or working on internal and even projects for our customers. It’s something that we cannot leave doing.

We are still learning to let go and find time to do other things, but it is a hard thing to do. One of the solutions we found to that problem is to have one day a week were one of us has to take off and do something else not path11 related; a one day vacation so to speak.

4. Short term can kill you.

Day to day work never ends and it’s difficult to focus on middle and long term work. This is possibly a reality for any service company that is still in it’s infancy as we are.

Now and then we setup a day when we talk about our medium and long term plans and guess what? We fail.

We have an amazing product that we prototyped to see if it worked and then we wanted to build it for real (we even mentioned it in twitter). But other priorities seem to pop out of nowhere and the medium term (build this product so that you can use it) get’s pushed away.

Possibly it is a matter of making more realistic medium term plans (and make the medium term shorter than it is now), but we are still learning and trying to adapt it to how we work.

5. It takes time to mature a vision.

It’s hard to keep a vision together for a long time. And harder to let that vision all together.

When we started path11 we had an idea of what we wanted path11 to be in the future, well, we had many ideas. Some of them where utopias some of them just noise (we had even ideas about being software service company that gives cooking lessons as a service… go figure).

The first thing you have to learn is that ideas are just that, ideas. And visions are sometimes just that ideas and brain-farts (trust us there, we have so many it’s unreal!).

The core of what path11 means is still there, unchanged, but what we do and what our longterm vision is has changed a little bit.

We don’t set hard monetary targets anymore, but concentrate on the one thing that matters most; our happiness.

6. Working remotely works, but it can be hard.

A lot has been written in the agile world about working remotely and how it doesn’t work. In our experience this is untrue.

Working remotely works. It just requires a different set of things and skills than normal collocated work.

We spend the whole day in campfire, it has become our main hub of communication. Our standups are done in skype (we started using Google+, but we had some bandwidth related issues and stopped using it), but the rest of the time we spend in campfire.

Because of that we keep an eye on how to augment the experience in campfire. We have our own instance of hubot running (we call him p11) and we constantly add more functionality to it to help us in our day by day tasks.

p11 will report when someone commits new code, when someone posts a comment on uservoice for one of our customers sites etc. We are currently even building an interface to the project management tool we use at the moment so that we can control it from within campfire.

All this is not enough though. Even when you trust your team and you work remotely pretty well you still need the contact. For that reason we decided to do periodically path11 retreats where we will meet somewhere for a couple of days and spend time together working and doing other fun stuff together. The last one we did was at the beach and we had a blast.

The next few things we will leave for part two. In the meantime we hope you will enjoy reading this and the rest of the posts which will come more periodically.

_~ your path11 team

RSpec matchers are an underused feature

j4cegu — Mon, 19 Nov 2012 10:35:34 +0100

In our last two GOOS book club meetings we have being discussing how to make test driven development sustainable. That’s one of the most important parts of the book. There is a lot of good advice on those pages.

I have been struck for the emphasis they put on writing readable assertions. A lot of helper methods are written in the book in order to express really well the intent of the test and what’s being tested. This helper methods have made me think about RSpec matchers which are seldom used.

Using this RSpec feature we can make our tests very readable and focused. They allow us to use the correct language for our assertions. Let’s review their advantages using an example from a kata:

describe 'Roman Numerals' do
  it 'transforms 1 to I' do
    RomanNumeral.from_arabic(1).to_s.should eq 'I'
  end
end

There is a lot of information in that single line:

The class that represents the roman numbers.
The factory method that allows us to transform an arabic number to a roman one.
What the string representation of a roman number should be.

Each one of them is a way that spec can end up failing. In other words, each one of them is a form of coupling. There will also be a lot of duplication once we start adding more specs.

Once we have several tests and refactor the spec we will probably have a method like this:

def roman_for(arabic)
  RomanNumeral.from_arabic(arabic).to_s
end

So we can end up with expectations like this:

it 'transforms 1 to I' do
  roman_for(1).should eq 'I'
end

This reads better and also removes the duplication, but the expectation doesn’t use the domain language. Let’s use a Matcher to see how the code is shaped:

RSpec::Matchers.define :be_roman_numeral do |expected|
  match do |arabic|
    RomanNumeral.from_arabic(arabic) == expected
  end
end

As you can see creating matcher is really easy: you just need the name and a match block that returns a boolean value that represents whether the expectation has been met.

Using the matcher we just built the spec would read like this:

it 'transforms 1 to I' do
  1.should be_roman_numeral 'I'
end

This version is better. It has all the advantages the helper method had but also allows us to express our expectations using the domain language.

Definitely RSpec Matchers are a really nice feature. We should use them more often.

GOOS Book Club Update

j4cegu — Thu, 18 Oct 2012 09:44:41 +0200

First things first: we must apologize. Last week we totally forgot to share which chapters we were going to read for yesterday’s meeting. We are ashamed and we have punished ourselves by using emacs for three days.

On yesterday’s episode of GOOS book club we finished reading and discussing part 3 of the book.

That means we have already covered the example. It has been really awesome to share our experience with you guys. We have discussed a broad set of topics that go from design to UX, and how it affects the development process.

But there is more. Now we dive into deep waters. We start the fourth part of the book which talks about being able to test-drive your applications sustainably. This part of the book is really dense and explains the ideas that have been applied during the development of the example. That’s why we are going to slow down. We know these chapters will trigger very interesting conversations and we don’t want to miss them because of having only an hour per week.

If you have been falling behind with your reading now you have the time to catch up. It’s only a chapter, the first one of a new part of the book. It’s only 25 pages long. You have no excuses!

Make sure you have paper by your side. We want you to make questions! We want you to play a bigger role in the book club and help us facilitating it. It’s a hard duty and we are outsourcing it. :P

Next wednesday at 18:00 GMT (20:00 spanish time) we will discuss chapter 20. Ping us on twitter if you want to take part.

Sorry, no book club today

sebastianlab — Wed, 26 Sep 2012 10:17:25 +0200

We are currently spending a few days with limited bandwidth somewhere in the South of Spain, celebrating the end of the Summer and start of the Autumn.

We checked if we could gather somewhere around a coffee shop, but there is nothing in miles around. So we won’t be having the book club today. Sorry for the late notice.

Our first bath at 7:15am this morning

We see you all next week! We will be looking at Chapter 12, 13 and 14.

Cheers, Sebastian

Switching to Vim

sebastianlab — Fri, 21 Sep 2012 09:47:22 +0200

I decided to use to Vim as my main editor in 2012.

I had it on my list next to other New Year Eve’s resolutions: getting in shape, and spend more time with the family, so you’ll think that I would have given up by now.

But I didn’t.

Before that I used to spend my time in Emacs and Eclipse. Eclipse for Java and Emacs for the rest. I was happy with my setup. I even wrote a couple of plugins for Eclipse, and Emacs was a fun environment to work with.

I considered giving Vim a try because the majority of us at path11 are Vim users, so pairing left one of us at disadvantage, either me in Vim, or them in Emacs.

But what really got me motivated was asking myself: Am I missing out on something great?

After 9 months of use, I am really liking the switch. I use Vim for almost everything, everyday.

Using Vim

Picture this: You are surgeon performing emergency surgery. Laying on the bed is the patient, your code. With very precise moves and using the right tools you quickly slice, extract, and inject new code.

That’s how I feel when I am using Vim

But the first contact with Vim is rather strange. You have to type i to insert text. And then type ESC when you are done. You move around the text with j and k. I understand that this stops a lot of people from trying it.

But I think this is where I find the power in Vim. As a programmer, I spend my time either typing or searching for the right place to insert/fix my code. And Vim optimizes for both scenarios with a insert mode and command mode.

I made my switch in small steps, learning new commands and tricks everyday. Today, I use vim in my terminal, but I started with MacVim which lets you copy/paste/open/save like any other OSX text editors. It’s less intimidating.

Speaking Vim

I find that the majority of the commands are easy to remember. At first, it helped me to spell them out aloud as I was typing them.

typing: dw, saying: delete word.
typing: dtx, whispering: delete till an x is found on this line.
typing ctx, murmuring: change till an x is found.
typing ci”, whispering: change code inside the quotes. One of my favorites.
typing f0r1, shouting: find the 0, replace it with a 1.

Extending Vim

The ecosystem of plugins is as big as the universe. With package installers like Vundle or Pathogen, it’s super easy to extend vim in any way you want.

I personally use Vundle, but I have heard great things about Pathogen.

Here is my top 3 list of plugins I use everyday

crtlp is how I search for files in my projects.
syntastic helps me commit less mistakes by checking my syntax every time I save a file. It compiles the majority of files that I use everyday: ruby, coffeescript, javascript, sass, python, you name it.
dwm is how I organize my buffers.

Special mention to surround. I am learning it this week. It’s a super fast way to insert/change tags and quotes that surround your text.

Looking for more? I keep my list here starting on line ~30.

What am I Missing

I run into problems when working with clojure on Vim. I can’t get it to work, so I go back to Emacs for that.

I now have Emacs running Evil which allows me to reuse my insert/command modes fu.

Switching to Vim

Want to give Vim a chance? Here is a starting list of things to consider:

Understand how to customize and grow your environment. Don’t copy blindly the configuration from your Vim uber hacker friend. With package managers like Vundle or Pathogen, it’s easy to get started.
Start with a graphical interface to make it less painful. On OSX, I recommend MacVim.
Don’t use the arrow keys to move around. Yes, it’s weird the first half hour. Moving is a command, so you can combine commands: “1jf1r0” Jump 1 line down, find the 1 and replace it with 0.
Memorize a couple of new commands everyday.
Give it a honest try for a month.

Happy Vimin’