Archive for February, 2013



Dear Leanpub first-time author

I've only written a book, enough to know how much work it is. Before writing it, I used to think that writing was going to be the most time-consuming task. However, it turned out that I spent more time fixing mistakes, reading again and again what I wrote and, specially, applying changes based on my dear reviewers' feedback. The first draft I wrote had nothing to do with the final version. The reviewers where friends as the book was self-published. And reviewing was hard to them. Some of them stopped following revisions as the chapters were mutating.

As a reader and also as a reviewer of other books, I like to give feedback to the author once the book is in a very advanced stage. Once the author has read his book so many times that she is tired, and she thinks it is ready to be published. At that point feedback is more precise and changes are easier to apply. Less work and better experience for everyone.

Guess what my advise is?
Do not invite your reviewers to read your book when you consider it is 50% done. Wait until you think it is pretty much done. When you consider you've got all the chapters in and you are happy with the content. At this point is when you really got 50% of the job done, but you believed you were 90% 🙂
Well, if you have been writing for many months and the book is going to be huge, then you need feedback sooner. But for the average 200-300 pages book, I would rather wait.

You can ask your reviewers about the general table of contents, or maybe about some technology your are talking about, but going through the whole book soon is not a good idea in my opinion. As the book evolve, your reviewers will be tired. And worse than that, some of them might have a wrong idea about the final version, just because they left the project too early.

Care about your reviewers' and readers' time as much as you care about your own time 🙂

And remember, never write a book for money. Write it because you feel like sharing with others. If the book is good, the reward will come, but not in the form of direct money from the sales.

 

 

There are two major events in the Agile-Spain Community. One is a conference and the other is an Open space. In June 2013 (21st and 22nd), the Open Space will be held in Tenerife, Canary Islands, a paradise in the middle of the Atlantic Ocean. Perfectly connected with Europe thanks to its two international airports.

I am helping with the organization, am part of the staff in this edition. In previous editions, we haven't had talks by non-Spanish people. It would be great to have guests from all over the world this time. We would love to have talks in English during the event. Everyone will understand English (although not everyone would be able to speak  fluent English) so it is a great opportunity to meet the Spanish agile community. There will be 2 or 3 tracks. At least we will have a technical track and a management track. Between 150 and 200 people from all over the country will attend.

We are planning leisure activities the days before and after the event, for those willing to spend some days off in the island. I'll be organizing a "snorkling" morning for example:


All I say in the video is that you should bring your diving mask 🙂

We'll go hiking, on party, and more. You will also enjoy traditional local dishes (home made!). Perfect for holidays and networking.
These islands are an excellent place for outsourcing development and this is the perfect opportunity to meet the right people 😉

Open Space Date: 21st and 22nd, June 2013
Current Website (will change soon): aos2013.wordpress.com

As this is not a conference, travel expenses won't be refunded, because we don't even know who is going to be a speaker (this is an open space). However, we will probably get nice discounts for accommodation. Lunch and dinner will be covered by the sponsors.

I am also planning an edition of my BDD workshop for JavaScript developers in the same week. The workshop will be in English 🙂 For more information about the workshop date, please subscribe to the upcoming workshops list.

If you need any other information regarding the event, please contact me directly at "carlos AT iexpertos DOT com".

See you in June 🙂

I always encourage developers to write a technical blog. I've already convinced some of them to start blogging... yeah!

Why is it that you explain your problem to other person (or even to a rubber duck) and you find the solution yourself as you describe the problem? The brain works differently when you think without talking loudly, than when you talk or write.

There are different learning levels for techniques:

  1.  You discover there is something new you want to learn.
  2.  You start reading how others use the technique but don't understand what they are doing. It's confusing at first.
  3.  You start reading how others apply the technique and you understand what they do, but you can't do it yourself.
  4.  You are able to start doing it by yourself.
  5.  You explain what you know to others and then new doubts and thoughts pop up, and you get a deeper knowledge.
  6.  You teach people on the technique and that gets you closer to the master level. The more you teach the more you learn.
  7.  You eventually become a master.

Write a blog

Just do it for yourself, write notes that can be helpful for you in the future. Explain what you learn. It might help others and it will definitely help you, just for the sake of learning. Don't worry too much about your writing style, you are not writing a book and it is your blog, don't let the wording stop you from your willingness to share. In my case, every time I write in English, I learn more English also, so it is not only technical stuff that I learn. However, I prefer to write it even feeling that I am making some grammar mistakes, rather than keeping the draft for months, waiting for the perfect moment to polish my writing to come off. I try to deliver frequently and learn from my mistakes. All I know is reading my post when I finish it to fix the mistakes I notice.

Talk to others

Don't miss the opportunity to expose what you learn in your local community. Talk to others and present papers for conferences. But if you decide to talk in a conference,  prepare your pitch upfront. Prepare your slides and your talk very well before doing it. The more you practice your pitch the more you will learn and the better it will be for the audience. Don't be afraid when talking for a big audience, nobody is better or worse than you, you deserve all the respect, and so your audience.

Teach what you know

If you don't want to feel uncomfortable as the questions come in, you better know what you are talking about. This means you have to prepare the classes very well, and that will help you to know the technique really well. Teaching is a great motivation to learn. If you don't have experience as a teacher, my advise is to teach your friends or colleagues in your local community for free, until you reach the point where others confirm you they are taking value from your lessons.

I hope to inspire more developers to, at least, start a weblog 🙂

 

 

 

Event oriented programming promotes low coupling but not necessarily high cohesion. Always consider the Single Responsibility Principle while designing collaboration through events. I see three primary ways of collaboration:

One to One

A single object communicates with other (a collaborator). This can be done with dependency injection the same way we do it in Java or any other language (and you don't need Spring for that!). JavaScript provides another mechanism for one2one communication, the DOM Level 0 traditional way of event handling. A very useful and powerful way of adding hooks/ports to plug new behavior in, still promoting low coupling. If you need to change the collaboration in the future, from one2one towards one2many, it can be done easily. In some cases I see this as a more decoupled way of dependency injection.

  1.  
  2. function Car(){
  3. this.go = function(){
  4. /* some calculation over here */
  5. this.onLowFuel();
  6. };
  7. this.onLowFuel = function(){/* event */}
  8. }
  9. function RacingTeam(){
  10. function getReadyToFuel = function(){/* whatever */};
  11.  
  12. this.addCarToRace = function(car){
  13. car.onLowFuel = function(){
  14. console.log('low fuel!', this);
  15. getReadyToFuel();
  16. }
  17. };
  18. }
  19. var car = new Car();
  20. var team = new RacingTeam();
  21. team.addCarToRace(car);
  22.  

As you might realize I know nothing about car races 🙂 but I hope you understand the code. When implementing traditional dependency injection, the car knows it depends on a team, but it doesn't know the particular implementation of the team. With the DOM level-0 traditional way, the car doesn't even know it will be used in a team. All it knows is that it has to inform someone else about its fuel level when it gets low. However, the team's got to know about the car. Still the team should not know about the particular implementation of the car.
To test-drive this behavior, you probably need two steps. First one, make sure the car triggers the event and second, make sure the team handles the event. I wrote the two tests in a previous post. DOM level-0 traditional is the main mechanism I use for one to one collaboration, it's got however some pitfalls worth considering.

Pitfalls
  • You might not know some object is already handling the event: the handling mechanism is simple, we are just replacing the original function in the object triggering the event. If we try handle the same event twice, there will be only one handler, the last one. I always use the "on" prefix for those methods that trigger events as a convention to know it is an event with a single handler.
  • You might make mistakes with the "this" keyword: in the code above, what do you think "this" is when we invoke console.log? It's the car object, not the team. It's a problem with a very easy solution though. I usually have a reference to the handler doing "var self = this;". Some people prefer the "bind" method to do the same.

One to Many

For one to many collaboration there is the Observer pattern. jQuery implements the observer pattern to expose events such as "click":

  1.  
  2. $('#closeButton').click(function(){
  3. /* the event handler 1 */
  4. console.log('handler1');
  5. });
  6. $('#closeButton').click(function(){
  7. /* the event handler 2 */
  8. console.log('handler2);
  9. });
  10.  

When the button is clicked, both handlers are executed. When I implement the observer pattern in my objects, I prefer to make it explictly:

  1.  
  2. objectTriggeringTheEvents.addSubscriber('eventName', handler1);
  3. objectTriggeringTheEvents.addSubscriber('eventName', handler2);
  4.  

The "addSubscriber" makes clear to me, that I can have several subscribers. This is specially important to distinguish from one2one collaboration.
As an exercise I leave out to you the implementation of the observer pattern with TDD.
I use one2many collaboration when I really need the object to be observed by several objects, which happens to me, less often than one2one collaboration.

Many to Many

Different objects might trigger the same event and there might be a bunch of other objects subscribing that event. This is the case of a many2many collaboration. Or, I might not be interested in the source of the event, I might just want to handle it. This usually happens at the infrastructure level. For example I use it to know when the window is being closed. I don't care who is responsible for realizing the window is being closed but I do want to know it in several parts of my application to shutdown properly. So I create an object which subscribes to "window.onbeforeunload" to be aware of window closing and in turn, emits the event through a "bus" where subscribers are listening.
This is the less coupled way of interaction between objects, but it comes with counterparts: code gets harder to follow. This is the publish/subscribe pattern. My advise is to use this pattern only when strictly necessary and not as a the default mechanism for event oriented programming.
There are several open source libraries implementing this pattern. As an exercise, try to develop it from scratch, test-first. This is the code I ended up with while implementing my own pub/sub:

  1.  
  2. EventBus = function(){
  3. var subscribersInfo = [];
  4.  
  5. this.addSubscriber = function(callback){
  6. var eventNames = [].slice.call(arguments).slice(1);
  7. subscribersInfo.push({
  8. subscriber: callback, eventNames: eventNames});
  9. };
  10.  
  11. this.emit = function(eventName, eventArgs){
  12. for(var i = 0, len = subscribersInfo.length; i < len; i++){
  13. var info = subscribersInfo[i];
  14. for (var j = 0, lenj = info.eventNames.length; j < lenj; j++){
  15. if (info.eventNames[j] == eventName)
  16. info.subscriber(eventName, eventArgs);
  17. }
  18. };
  19. }
  20. };
  21.  

Last month I was in Madrid talking about best practices for JavaScript RIAs, in the monthly meetup organized by MadridJS. Here you have the slides:


The talk was in Spanish. I expect to give this talk in upcoming conferencies, in English 🙂