Paulo: Zip RogerRoger: Zip MarcoMarco: Zoom Mathias...
Zip Zap Zoom is a great energy boost ice breaker. I made a small addition to it for helping the team memorizing each other names.After the Z__ command (Zip, Zap, or Zoom), the person passing the imaginary relay has to say the target person name.This keeps the energizer fun while helping the team memorize each other names.

On this blog post I share an activity I used on my last Inception.  I found this activity very useful to kick start the User Stories creation.

What are the goals of this project? This question  triggered the conversation about the business goals for the project. 
Who will use this system? What are their roles?These questions disclosed the personas (with their roles) for the project. Goals and personas were written on post-its. Large pink post-it was used for goals, and small colorful post-its were used for personas. This is shown on the photo below.

After having written a few goals and personas, the team started brainstorming for creating User Stories.
As a X, I want Y so that Z. Note that X and Z were already known variables (personas and goals). We were now looking for the Ys.
So, what does X want from the system in order to achieve Z?For example: What does an OPS dude want from the system in order to monitor the browser against system overflow?
User stories were being written...
Soon these stories were combined into features (blue post it). Usually a feature would have from two to eight stories.
This whole process was not linear and definitive. Index cards (for stories) and colorful post-it (goals, personas and features) were written and re-written a few times. Below are a few photos showing index cards and post-its.

Last month I was at the airport browsing random things on my phone and I ran into this text by Jon Evans.
It made me think of how people always try to come up with the perfect set of practices for software development, but there’s always someone reminding them that common sense still prevails over every possible process or practice. But it also reminded me of some thoughts I had many years ago about pair programming, or, actually, trio programming.

I’ve seen many terms for the situation where 3 people are coding together: triple-programming, trio-programming, trairing, etc, choose at will.
The problem I see with these terms is that usually they are used to describe 3 people working on a single feature, and that’s not very effective in my opinion – except on some rare occasions with extremely complex/important features or problems (common sense still prevails).

Going back in time a little, when I was in college I had to work with a group of 3 other guys to write a web application, it was our finals for one of the courses we were taking, and it was a big deal because we had never written something like that with all the integrated bits and layers and shenanigans. One of the guys bailed for some reason I can’t recall – no hard feelings, he had his legitimate reasons – so it fell to the other 2 and I to do the work.
All the 3 of us were raised in Brazil, and as I usually say, every Brazilian is born agile, because we always seem to “do everything at the latest responsible moment”. As expected, 2 days before the deadline to hand in the application we had barely started coding, so we had an overnight development session where we wrote most of the application together.

It worked like this: we were 3 guys, we had 2 machines. There was always one pair and one solo dev, but the pair would rotate constantly. I was pairing with João now, and César was going solo, until he stumbled on an issue/doubt/important-decision-making-point, where he would call for help and either João or I would join him. If João joined him, now I was the one going solo, until one of them joined me again. We had 2 well defined streams of work, but neither of them had a clear driver, because all 3 of us had a medium-to-high level general understanding of what was going on with both.

The most interesting thing is that this process had not been defined previously, in fact we only realized that it had happened once we finished, it was all very natural and organic, and worked very well. We didn’t have any tool to remind us of rotating, in fact, we barely noticed we were rotating. We were just 3 guys working together on a project, all of us helping one another.

Back to the present, whenever I think about that experience, I recall how well it worked, and how interesting it would be to try that again.
I guess I am just trying to put into words a very non-organized way of work, but I think it’s possible.
And here’s why:

A typical pairing session for me usually has 3 clear different actions: the talk, the decision making, the typing. For the typing bits, given both people in the pair are proficient with the technology in hand, usually there’s not much the navigator has to add. Most of the comments around typing are going to be things along the lines of “you forgot a semicolon” or “there’s a typo there”, which are usually things the driver had already noticed and was on his way to fixing, or that he would catch quickly enough anyway. The greatest value of pairing is on the other 2 actions.

(Now, there can be typing involved in the talk and in the decision making, typically when one of the developers in the pair go like “here, what if we did something kinda like this?” and starts to type code away, usually not really code that is going to be used in the final version of the solution but just a means of expressing his/her ideas. So when I say that “typing” is one of the 3 actions in pairing, it does not include these moments where we write code to discuss our solution.)

That’s why I think triple-pairing in 2 work streams works so well: there’s always a pair talking and making decisions, while the typing can be done solo. Hell, if the typing is so important to you, and, let’s say, you don’t want to have to wait for the tests to run to catch a typo, I could even argue that there’s some just-in-time code-reviews happening there as well: whenever the pair enters in typing mode, one of the guys in the pair goes back to the solo guy to check on how he’s doing and can offer advice on the typing bits.

So how can this practice be formalized? Should we try to assign 2 stories to 3 people?
Well, maybe, why not? I still want to try this out and see what happens. If anyone out there has had experiences in these lines, please share!

But I think that there’s more to that than simply having 3 developers for 2 streams. The project I am currently working on has a small team of 5 developers. Which means there’s always one person soloing, but this person is more often than not doing QA work. Anyway, here are 2 situations that I think fit this idea even though they don’t fall into the 3 for 2 category:

- I worked in a story while another dev worked on some other bits of work. We were sitting side by side just as if we were pairing, but our pairing screens were not connected to the same machine. We both knew what each other was doing, and we both talked about both problems constantly and even took each other’s keyboard for a few seconds to type something – but we had clearly one person working on each stream of work;

- 2 pairs working on 2 different stories, but all 4 people involved knew at least some about the 2 stories (they are both stories in the same project after all, so guess what? They are related!). One developer goes to the restroom, his pair has a doubt, one of the developers in the other pair joins them, the refreshed-developer-who’s-just-back-in-the-room hovers a little bit both streams of work and eventually joins one of them. This happened more than once (and not only triggered by restroom visits, otherwise we would be thinking about a general team visit to the nephrologist).

So, here are my conclusions:

- 3 developers for 2 streams of work may be worth trying. I want to try it out again, and will share my experience when I do so. If you have, please share with me.
- When pairing on a story with someone, don’t shut yourselves from the world – I see this happening very often. Go around the team and talk about the problems you’re facing, ask for advice from a third party, go around offering advice. If you’ve done the talk and made a decision with your pair that results in at least a few minutes of pure typing/refactoring/moving stuff around, choose one of you to do the dirty job and get the other to go poke around and check what the others are doing, maybe they could use some talk themselves. Of course, sometimes it may be worth to stay and pair through the typing too, specially if it involves moving a bunch of existing code around or touching the always-present-hairy-parts of the codebase – again, common sense.

this JavaScript:

var o = {
    f1: function() {
        console.log('hi');
    },
    f2: function() {
        this.f1();
    }
};

o.f2.prototype.f1 = function() {
    console.log('bye');
}

var k = {
    f1: function() {
        console.log('pfff');
    }
}

new o.f2();
o.f2.apply(k);
o.f2();
var x = o.f2;
x();

There. That’s why I never use the this keyword in JavaScript.
And that’s why I think you should stop using it too.
Can you figure out what’s the output of this code?

If you run this piece of code on Chrome’s or Firebug’s console you will see something like (extracted form Firebug):

bye
pfff
hi
TypeError: this.f1 is not a function

The this keyword references a different object depending on how the function is called.
This could be a very powerful feature if it was not so misleading. When developers use this they expect it to reference one single object – thanks to many years of practicing using such keyword on languages like Java.

What happens there?

new o.f2();: When we call a function with the new keyword JavaScript will implicitly create an object and assign all this references in that function scope to that object, and return that object in the end. It will also create a reference to all of the properties of that function’s prototype in the newly created object.
When we do new o.f2(); we are doing exactly that, so when f2 gets executed it looks for a function called f1 (line 6) that belongs to that object. Since f2′s prototype gets assigned to the created object, that function would be the one that prints bye (line 10).

o.f2.apply(k);: All functions in JavaScript have a method called apply that will let you explicitly override the reference to this keyword during the execution of such function. That’s exactly what we are doing here. When f2 gets executed, this points to k, there fore pfff is logged, since k has a function called f1 that does that (line 14).

o.f2;: That’s the regular and usually expected behavior.

var x = o.f2; x();: We assign a reference to f2 to a variable called x. When we call x there’s no object associated with the call, so this points to nothing. When we try to access the property f1 in an undefined object, we get an error.

And if that’s not enough for you, here’s another example that shows another problem with this:

var object = {
  name: "simple object out here"
};

var anotherObject = {
  object: { name: "simple object in here" },
  p1: this.object.name,
  f1: function () {
    return this.object.name;
  }
};

console.log(anotherObject.p1);
console.log(anotherObject.f1());

This code outputs:

simple object out here
simple object in here

Maybe it’s just me, but I would logically expected it to output:

simple object in here
simple object in here

The thing is: using this in an object scope is not the same as using this in an object’s function scope.

So, please, don’t use this.
Or, use it as little as you can! When working with jQuery you will have to use this inevitably.
And that’s ok! But when writing your own, non-library-interacting code, minimizing the usage of this can make your code way simpler to understand and much less likely to have weird bugs – unless you really understand what all the different contexts this can refer to are. I know I get confused with the this keyword every now and then.

Happy JS-ing!

All the code shown in this post can be found here: https://github.com/luizfar/nothisjs

Em um determinado post, o Nicolas Iensen, fala assim:

O maior equívoco da história da gestão foi acharem que não existe gerencia sem gerentes.

Eu comentei em um evento do Grupo de Métodos Ágeis do RS que na minha equipe não existem gerentes. Mas estava sendo injusto. Muito injusto.

O ponto é que eu acredito em algumas coisas como:

• Quanto mais tempo de empresa as pessoas possuem, mais liberdade elas terão.
• A responsabilidade de uma pessoa aumenta de forma diretamente proporcional a sua liberdade.
• Não acredito em gestão centralizada – acredito em pessoas diferentes liderando assuntos que fazem sentido para elas. Lidere suas causas! Assim seu trabalho vira diversão.
• Todos do time são responsáveis por todos do time. Ou não é trabalho em equipe?
• Auto organização – quem sabe a melhor forma de funcionar, de acertar uma tática, é o próprio time.
• Auto gerenciamento – quem sabe onde está doendo e definir ações, retomadas, ações em crise, também é a equipe.
• Não acredito em gerentes, mas sim em pessoas capazes de gerenciar. E através de vivência prática, trabalhando e vivendo problemas reais.
• As pessoas devem ser capazes de gerenciar seu próprio tempo. Assim podem gerenciar melhor o tempo do seu time e por consequência da empresa.
• … dá para fazer um livro disto, mas enfim, estes já mostram meu ponto.

O grande “problema” disto pode ser quando a equipe fica muito grande. Já passamos por situações assim e em breve vamos passar novamente. Grande para mim é uma equipe com mesmo foco, com mais de 20 pessoas ok?

Mas… medo não tenho. Porque eu tenho uma equipe que ao encontrar um desafio de comunicação, vai enfrentar este desafio. E aí vai para outro ponto que para mim é muito importante. Atitude! Que atitude você quer presente na sua equipe?

Joel Spolsky fala em se “falar menos“, e os problemas de comunicação quando temos “muitas pontas”.  Os problemas que acabamos tendo em grandes grupos. Acredito nisto, mas o bom senso aparece nestes casos. Vamos trabalhar em duplas ou trios para um determinado assunto. Não com a equipe toda. E vamos ter eventos onde todos serão envolvidos. E saber dosar isto. E saber dos prós e contras de ter um excesso de comunicação ocorrendo.

Se não controlarmos estes pontos, não será possível trabalhar no trabalho, porque vamos ficar apenas em reuniões e discutindo assuntos que podem ser discutidos em um grupo menor de pessoas. Por isto que devemos ter foco. E confiar no trabalho da equipe.

So, you as I are tired of Evolution's problems in Ubuntu 11.10?
Move on to Thunderbird...
To have it working with Microsoft OWA following the these steps:

Install DavMail

Download and install DavMail. It will act as a proxy between Thunderbird and your Microsoft webmail.

Configure DavMail

Some tips: 

• Exchange 2003: https://mail.company.com/exchange/
• Exchange 2007 Webdav mode: https://mail.company.com/owa/
• Exchange 2007 EWS mode: https://mail.company.com/owa/
• Exchange 2010 EWS mode: https://mail.company.com/owa/
• Exchange 2010 EWS mode with unsupported authentication form e.g. Windows Live login:https://mail.company.com/ews/exchange.asmx

In my case as I'm behind a proxy I had to mark the option "Use system proxy settings" in the Proxy tab:

Click save then you should see a message in your system tray, saying that DavMail is correctly configured.

Configuring Thunderbird

In Thunderbird main window click menu File > New> Existing Mail Account.
Fill the next windows with your credentials:
Click "Continue", 


then manual config and change the properties to:

• Incoming:
• Server hostname: localhost
• Port: 1143 (if you didn't change this value in DavMail)
• SSL: None
• Authentication: Normal Password
• Outgoing:
• Server hostname: localhost
• Port: 1025 (if you didn't change this value in DavMail)
• SSL: None
• Authentication: Normal Password

Re-test and Create Account and be happy.

Em uma reunião, se pergunta como avisar o usuário do resultado de uma chamada de um serviço, em se usando uma abordagem baseada em REST.

Minha resposta foi algo simples tipo, ah, 200 vai indicar que funcionou show de bola, 201 quando um objeto foi inserido, 400 quando a requisição for mal feita, 501 quando o usuário chamar um recurso que não temos. Note o uso correto da palavra recurso.

Fiquei falando um minuto mais ou menos, sobre alguns códigos de retorno HTTP. Eis que hoje olhando o Twitter do Daniel Barden encontro este tweet da @DanaDanger, que resume tudo isto:

HTTP response codes for dummies. 50x: we fucked up. 40x: you fucked up. 30x: ask that dude over there. 20x: cool.

— Dana Contreras (@DanaDanger) March 23, 2012

Tagged: rest

There is one element in Scrum which I really appreciate. It is the separation of power in Scrum. 
What exactly do I mean with this? Democracies are based on the separation of powers they require.

• Legislative
• Executive
• Judicative

Each one has their rights and responsibilities. The other two watch out and make sure, that third doesn’t abuse it’s power.In totalitarian governments this is not given. One entity reigns over all three. The usual result is that a few benefit and many suffer - from individuals to whole economies.
What does this have to do with Scrum. Well, nothing - at least at a first glance. But if we apply this concept to classical management, the project manager has the possibility to act as a dictator. 

He or she can decide about all three elements: scope, schedule, people.
The image is the incomplete ‘iron triangle of quality’. It tells us, you can choose two out of the three, the third has to give. For example, if we have a certain amount of scope to implement by a given date, we need to adjust the number of people working on it.If all three are set then the quality of the product under development will be sacrified when things get tough. Often the manager tries to convince us about the attainability of the goal with sentences like ‘I know it is aggressive but …. ‘, ‘You are not a team player ….’ and more. 

Quality dies first on each software project. It is not transparent per se, it won’t show until very late in the project or even until the product has been released. This manifests in very high TCO (total cost ownership). Eventually the developers require to rewrite the piece of sh.. garbage software.
How is this handled with Scrum? In Scrum the Definition of Done (DoD) states certain attributes or activities which have to be present in order to guarantee a high quality, potentially releasable product. The compliance of the DoD is paramount to a high quality product with happy customers and low TOC. Now Scrum is not immune to crunch times, times when the Product Owner (PO) is tempted to push the Development Team a little further. In those situations it would be just to easy to abandon the DoD and reduce quality to keep the date and make the Product Owner happy.This is when the Scrum Master comes in. She will make sure that the DoD stays enforced and keeps the PO at bay. Essentially she protects the people (Development Team) so that they can work in the agreed way and thereby create a high quality product. 
In Scrum the Product Owner has the right to decide which feature gets developed in which order. His tool for that is the Product Backlog.

and the Scrum Master ensures that the Delelopment Team has the right to estimate the work according to the Definition of Done and to implement it according to the Definition of Done.


The separation of power protects the Development Team and allows it to deliver high quality product increments throughout the project. This sustainable approach guarantees high quality software with high ROI, low TCO -- easy to maintain, easy to support, easy to enhance -- for a long time. Best, you should see happy, engaged developers.
In the end everybody wins!

 

Reasoning is the core activity for a retrospective. But it is important for a group to have a common ground on what they are reasoning about. The group has to first look at facts and perceptions.

All argument and reasoning must be based upon certain perceptions. Without these, there cannot be any argument. Reasoning is the method of comparison between certain facts which the group has already perceived. If these perceived facts are not there already, there cannot be any reasoning.

When planning a retrospective, choose an activity to help the team uncover facts. Facts help the group understand perceptions, and upon that the group will be ready to engage into reasoning.

Motives

Today even the simplest application will demand from developers to know a handful of technologies and languages. Rapid prototyping libraries were created to bridge this, taking care of much of the boiler plate code necessary to put a application online, like Rails. Moreover template engines are based on the assumption that it will exists a Designer to take care of the pages, also the business logic has to be isolated from the rest of the code like persistence. Patterns like MVC, MVP and MVVM are thought to achieve this, but the sad truth is, often times applications end up with logic everywhere in these layers making growing the application harder and harder.

Vitosto JS – a new way to think about web development

With these in mind, I joined a group of friends and we started to work in a new library, Vitosto JS. View To Storage in JavaScript. The idea is lower down the amount of different layers between the user interface and the storage where the data actually is. Developers can grow their application just controlling one layer of code and having some knowledge about databases, as for now, vitosto.js can only work with MySQL databases, support for Oracle is in progress. Enough talking, more code:

Hello World:

<html>
  <head>
    <title>Vitosto JS</title>
    <script src="vitosto.js"></script>
    <script src="vitosto_config.js"></script>
  </head>
  <body>
    <h1>
      <script>$db.select("text").from("my_table");</script>
    </h1>
  </body>
</html>

vitosto.js is the library it carries all code to actually connect to the database plus a fluent API to issue queries. vitosto_config.js holds the connection information, for security it is encrypted with ROT13 algorithm for security purposes.

All the power of JavaScript is at your hands and a simple WebServer like apache will be necessary to hold your application. Here’s an example of a form submission.

<html>
  <head>
    <title>Vitosto JS Form</title>
    <script src="jquery.js"></script>
    <script src="vitosto.js"></script>
    <script src="vitosto_config.js"></script>
    <script>
      processForm() {
        var name = doSomeSanityCheck($("#name").text);
        $db.insert(name).into("table");
        rewriteDomForThankYou(name);
      }
  </head>
  <body>
    <form>
      <input id="name" type="text" maxlength="50"><input type="submit"
onClick="processForm()">
    </form>
  </body>
</html>

As will can see we can mix JQuery and other libraries with Vitosto.js.

Next Steps

• Oracle connection driver
• Support for Oracle functions and procedures

Code and API information

Download the Beta Release at: Vitosto at GitHub.

Below is a deck for a timeline activity I used on my last retrospective.

Timeline activity View more presentations from paulocaroli.

Previously I have used this approach for a collocated retrospective. I would draw a timeline on a white board, create 4 areas on the board (people, process, tools/technology, and other), and use two colors of notes (well – green /not so well - gray) to start with, followed by a third color for action items (yellow).

Here is the snapshot of the retrospective activity (this picture was generated by Google Drawing):

Back in 2008 I would dream about bringing Thoughtworks to Brazil. Dreams come true!

Today I am glad to watch 5 remarkable techie colleagues (all from Thoughtworks Brazil) shaping, spreading the word and fostering conversations about languages, technologies, tools and platforms.

The Thoughtworks Tech Radar road show (now in Brazil!) starring Ronaldo Ferraz, Rodrigo Kochenburger, Marco Valtas, Carlos Villela and Adriano Bonat.

Porto Alegre
Wednesday, March 28 2012

Rio de Janeiro
Thursday, March 29 2012

Sao Paulo
Thursday, April 12 2012

Belo Horizonte
Friday, April 20 2012

Register here.

Out of the blue my Evolution stopped working today.
After browsing some forums with no success... I finally found a light:

 sudo apt-get remove evolution
 mv .local/share/evolution .local/share/evolution_bkp
 sudo apt-get install evolution

and... Voila!

I don't know yet all the implications of this, but for now I'm so happy that I can see my messages again, and I don't have to use windows that I decided to post it here. If I find anything new I will update this post.

Cheers...

PS: Ubuntu 11.10

If you have ever been in an Agile project, or something that looks like it, you should have heard about the concept of spikes.

For those who haven’t, spikes are the agile response to reducing technical risk in a project. In case you are not sure how to build something or fear that some piece of functionality might take much more than expected, and you have to gain more confidence about it, it’s time to run a spike. Usually timeboxed, spikes are technical investigations with the objective of clarifying a certain aspect of the project.

In my current team, we are developing a few tools that are quite specific to our context and were not sure on how to solve a few issues, so we have been quite frequently playing spike cards.

This is all not new and I’m sure most of you have done that before. If you did the way I used to do, you would write a spike card, something as “investigate technology X for problem Y“, would spend 2 days doing it and would have a response for it in your head once you were finished.

In our current context, team members were rotating quite quickly, so we were worried that any knowledge we would get from spikes could have been lost if it was just…let’s say.. in our heads.

Not wanting jut to write the findings up, as we first thought about doing, we decided to tackle the problem with the golden hammer of agile development: tests!

So, instead of writing tests to decide how we should write our code, we started writing tests to state the assumptions we had about the things we were investigating, being able to verify them (or not) and have an executable documentation to show to other people.

For example, here is some code we wrote to investigate how ActiveRecord would work in different situations:

it 'should execute specific migration' do
  CreateProducts.migrate(:up)
  table_exists?("products", @db_name).should be_true
  table_exists?("items", @db_name).should be_false
 end

it 'should execute migrations to a specific version' do
  ActiveRecord::Migrator.migrate(ActiveRecord::Migrator.migrations_paths, 02) { |migration| true }
  table_exists?("products", @db_name).should be_true
  table_exists?("items", @db_name).should be_true
  table_exists?("customers", @db_name).should be_false
 end

it 'should not execute following migrations if one of them fails' do
  begin
    ActiveRecord::Migrator.migrate(ActiveRecord::Migrator.migrations_paths, nil) { |migration| true }
  rescue StandardError => e
      puts "Error: #{e.inspect}"
  end

  table_exists?("invalid", @db_name).should be_true
  m = ActiveRecord::Migrator.new(:up, ActiveRecord::Migrator.migrations_paths, nil)
  m.current_version.should == 3

  table_exists?("products", @db_name).should be_true
  table_exists?("items", @db_name).should be_true
  table_exists?("customers", @db_name).should be_true

  table_exists?("another_table", @db_name).should be_false

 end

We have used this technique just a few times and I won’t guarantee it will always be the best option, but so far the result for us is having code that can be executed, demonstrated and easily extended by others, making it easier to transfer knowledge between our team.

In May of last year I was able to run my first Pay It Forward Scrum Training at the University of Bern in Switzerland. I had blogged about this event there:  The 1000 Students Challenge

Last week-end I had the chance to do the second run at the University of Applied Sciences (FHNW) in Brugg Switzerland. 20 students volunteered their week-ends to learn about Scrum by attending the Scrum.org Professional Scrum Master Training or short PSM. It was great fun for them and myself and it is good to know that 20 future IT specialists will join the workforce pre-equipped with Agile and Scrum.

967 more to go ...

PS If you are interested in hosting such an event at your institution please contact me at www.effectiveagile.com

For the last couple of years I have been particularly passionate and vocal on my projects and in the community about the importance of writing tests as close as possible to where the code is written. As a result I have been achieving easier and cheaper to maintain testing pyramids as opposed to expensive and brittle ice-cream cones. My passion stems from all the times that I saw, and wrote myself, test suites which attempted to achieve most of the high level scenario coverage through the user interface. I was one of the passionate advocates of this technique during a ThoughtWorks Technology Radar session where we collected new ideas. Now I am quite satisfied to see that the technique has recently been added to the adopt section of the latest radar.

 

Testing at the appropriate level

“The advent of BDD, testing frameworks like Cucumber, combined with browser automation tools like Selenium, has encouraged widespread use of acceptance testing at the browser level. This unfortunately encouraged doing the bulk of testing where the cost to run the tests is the greatest. Instead, we should test at the appropriate level, as close to the code as possible, so that tests can be run with maximum efficiency. Browser-level tests should be the icing on the cake, supported by acceptance and unit tests executed at appropriate layers”

thoughtworks.com/radar

Shallow Depth of Test

I believe that neologistic metaphors, like Ward Cunningham’s Technical Debt, are extremely effective to explain concepts like this. I will explain a real world example and eventually I’ll get to my neologism: Shallow Depth of Tests.

Let’s say, hypothetically, as if I had never worked on one of these, that we have to implement a quote web application that has several business rule validations and if the details provided are valid, it gives the user a price. From the user’s perspective, the app is pretty much like this:

 

Let’s keep in mind that we want to avoid testing this system as a black box, so let’s break it down and understand what’s inside. The system’s architecture is explained in more detailed in the image below:

• Javascript layer communicating to server side using JSON services
• Controller and mandatory validator
• Domain model, business rules and pricing calculator
• Data storage

The pricing calculator is a crucial component of this system. It has to be thoroughly tested in order to make sure that it provides the right price for several scenarios.If we decide to test pricing through the user interface, using a tool like WebDriver/Selenium, or any other tool that drives a browser the image below shows all the components that will be visited by these tests, I call these components on focus.

For pricing, there are several scenarios, maybe tens, sometimes hundreds of different combinations of factors that might affect the amount to be paid. This means that we will be visiting those components many times when all we are testing is the pricing calculator. In other words, everything will be on focus, when all we want to be focused is the pricing calculator component.

Here is when I start my neologistic metaphor… In optics, particularly in film and photography, there is the concept of depth of field:

“Depth of Field (DOF) is the distance between the nearest and farthest objects in a scene that appear acceptably sharp in an image.”

wikipedia

Therefore, adapting this definition to software testing:

“Depth of Test (DOT) is the distance between the nearest and farthest software components that get visited during the execution of a test.”

It is important to point out that the definition mentions a “software component“, which is not necessarily one “class” (OOP), or one “function” (FP). Components are logical entities that performs a small feature of the system. It could be an entire pricing calculator, a business rule validator or a simple string concatenation function. Each system will have its own components with various sizes.

Having defined that, if we want to test the pricing calculator mentioned above, we should keep it on focus and test it at a different level, not through the user interface, in this case a browser. If we do that, we will end up having a Shallow Depth of Test.

What I have learned and observed is that the more shallow the depth of tests, the cheaper is it to maintain and also the faster it is to execute them.

This Monday I participated on the Scrum Bolivia Day 2012.

The event brought together many professionals from different companies interested in learning, and expanding Scrum in its various aspects.

Below are the Scrum Bolivia Day 2012 speakers with their respective presentations

• Emilio Gutter - Introducción a Test Driven Development
• Israel Antezana – Scrum no es suficiente...
• Luiz Parzianello – Agile & Business Analysis: A Successful Combination
  
• Heitor Roriz - Scrum Values
• Martin Alaimo – Adoptando Scrum y no morir en el intento
• Paulo Caroli & Johanns Arispe – Scrum with Kanban, Small Adjustments Big Improvements
• Samuel Crescencio – The Lean Pyramid

Congratulations for Juan Banda and his team for organizing such a great event!

Recently I’ve started working often with Puppet, using it to provision environments for the project I’m working on. One of the things I’ve quickly realised when using it was how long the feedback loop between committing code and actually verifying that the manifest was working appropriately. In my situation, it would be something like this:

1. Work on puppet manifests, making a few changes
2. Commit code to repository
3. Wait for build to finish, which just verified for correct syntax
4. Wait for latest version to be published on the puppet master
5. Wait for next sync between master and client
6. Check that configuration was applied correctly on the client

As you can see, not very simple. If you also consider that I am not very experienced with puppet, you can imagine how I ended up having to retry things in this very long loop, which can end up with anyone’s patience.

Testing Infrastructure Code

Coming from a development background and being used to having very fast feedback about code that I write made me go into a search for testing tools that could ease my pain.

Unfortunately most of the tools I’ve found where not ideal since they focused on unit testing code, as rspec-puppet. Not sure what others think of it, but in the case of puppet manifests and chef recipes, unit testing doesn’t make much sense to me, since there is no code to be executed, and tests end up looking like some version of reverse programming, where you just assert what you wanted to write, but it doesn’t guarantee that the code actually works.

Introducing Toft

Luckily, one of the options I’ve found was Toft, which is a library aimed writing integration tests for infrastructure code using Linux containers. The main idea is that you write cucumber features verifying what you expect the target machine to have (packages, files, folders, etc..) and Toft starts a linux container, applies your configuration and runs your tests against it.

It also can be run from a vagrant box, so you can have your tests running on your mac, which is quite handy.

Features can be created using normal Cucumber steps, and mostly rely on ssh’ing into the target machine and verifying what’s going on in it, so are quite easy to extend and adapt to your needs. Here is an example of a feature verifying if a specific package has been installed.

Scenario: Check that package was installed on centos box
Given I have a clean running node n1
When I run puppet manifest “manifests/test_install.pp” on node “n1″
Then Node “n1″ should have package “zip” installed in the centos box

We’ve started using it in our team when writing new manifests and have also setup a ci build with it, which is quite useful to guarantee our manifests still work over time.

Toft is still in its beginning but I believe it has quite a lot of potential. If you are using chef or puppet you should definitely check it out at:

http://github.com/exceedhl/toft

Eu sempre tive uma necessidade de ter mensagens e apoiar quem está assistindo uma apresentação através de texto, muito texto. De vez em quando algumas imagens.

Em 1999 fiquei vermelho, e bem nervoso, quando fiz a apresentação do meu trabalho de conclusão. Depois outras lembranças que tenho são a partir de 2002, quando comecei a palestrar de forma mais constante. E não parei desde então. E a cada nova apresentação, uma nova lição, uma nova piada para fazer a platéia rir, e por aí vai.

Sempre me preocupei em passar a mensagem da forma mais objetiva possível, e prática. Isto vem me ajudando ao longo do tempo a fazer palestras menores. Normalmente minhas palestras funcionam no estilo “TED Talk“, focadas em no máximo 20 minutos e gerando alguma mudança. Nada de indiferença! Também gosto muito das palestras menores ainda, as Lightning Talks, com 5 minutos de duração. E eu ajudo a organizar um evento muito legal sobre elas, a #Desconf.

Mas voltando ao assunto de como melhorar suas apresentações… um dos pontos para eu melhorar era ter alguns modelos. Durante muito tempo eu trabalhei como instrutor oficial da Borland/CodeGear e hoje Embarcadeiro. E desde 1998 eu participava de eventos sobre Delphi, com apresentação de funcionalidades, sendo um “mero ouvinte”, e ali tive contato com um cara que sempre foi uma referência na arte de apresentar: Renato Quedas. Ele é um cara que eu respeito muito, e tive a oportunidade de conviver com ele alguns anos, ele na qualidade de Master Trainer, ajudando nós instrutores e consultores e se posicionar melhor em sala de aula, nas apresentações e por aí vai.

Depois estamos falando em 2006/2007, e uma das ações que me ajudaram a ver e buscar algo diferente foi quando tive contato com o material do Garr Reynolds e um livro muito legal chamado Presentation Zen. São dicas legais, mais focadas no design e formas de apresentar as informações para gerar um impacto mais positivo no público.

Outra ação foi o ToastMasters. Já ouviram falar deste programa? Em uma das empresas que trabalhei, existia um programa interno, e eu participava, conseguindo a cada semana ver pessoas apresentando e podendo colher técnicas diferentes. E aprender com o erro dos outros. Isto me fez buscar na internet também diferentes técnicas. Aí comecei a conhecer caras como Guy Kawasaki e Larry Lessig e o Lessig Method. Eles seguem sendo grandes referências para mim.

Claro… Steve Jobs por exemplo e seus keynotes milimétricos também são legais, sem dúvida! Mas o ponto é… que eu sempre gostei do improviso.

Muito.

Em uma situação, fui convidado para palestrar em uma semana acadêmica, e nesta oportunidade tinha decidido que iria falar sem ajuda do Keynote. Cheguei no evento faltando menos de 1h para minha palestra. Aí comecei a ter umas ideias e pronto, em menos de 30min selecionei algumas imagens e montei uma apresentação para me apoiar no evento. E foi show! Pode acontecer de dar errado? Claro. Mas aí é o estilo de cada um… alguns gostam de desarmar bombas. Eu gosto de palestrar improvisando.

O que eu procuro quando estou montando uma linha de palestra? Momentos para fazer rir/chorar/emocionar, momentos para fixar conhecimento (aprendizado), momentos para impactar (mudança). E isto vai em um ciclo dentro do tempo da palestra. Seja uma palestra de 5 minutos ou um curso de 80 horas.

Deixo o vídeo que apresentei no TTLabs Summit realizado em abril de 2011, falando sobre estas questões. Foi um vídeo de 5 minutos:

E a apresentação que está disponível no slideshare:

Dicas para desenvolver apresentações

View more presentations from Daniel Wildt
Tagged: career, education, fun, motivation, softskills, talks

Wow, great new feature from Google! You can now enable desktop notifications even using the web browser! That will help you 100 times more to be… interrupted! That’s a bad thing!

If you use GTalk embedded in a browser window as I like to use, here’s a tip to avoid enabling these desktop notifications.

I keep one of my browser windows on top of all others, so I can see it’s title bar, no matter what application I’m using besides the browser. When someone starts to chat with me, the title changes, and it kind of interrupt me, but gives me some seconds to finish up what I’m doing and then I can give the right attention to the chat window. Or defer the talk to the end of my working cycle.

Notifications for emails… no, you don’t want that. You drive your life, not emails. Build a way to make sure you are not every 5mins checking for new messages and cleaning up your inbox.

So, if I can give some tips, here they are:

• Avoid desktop notifications. Check every desktop notification you have and verify if that one is really important. If not, disable it! But hey, if you work on some mission critical support team… leave that notification active ok?!
• Make sure you have a routine to avoid checking emails every 5mins. If something is really important, teach people to call you. Or to ping you by instant messaging, SMS, os some other option that is really going to interrupt you, but for a good reason. If people call you and it’s not that urgent, also tell them they can use emails, and then you can answer back with more time. Actually, in your time.

Tagged: personal productivity