DDD: ten years too late

This is a good retrospective point. In my trip to Codemotion I got some real details on Domain Driven Design. And I understood that I never got really in to it. Because I thought it was a completely different thing.
I do not know how could it happened. Been superficial could be a reason. I just thought that DDD was the art to use ORM in a good way, design the model and the services / features around them. I was terribly wrong. And, for those who knows me closely, I do not like to be wrong. To amend this I bought

Domain-Driven Design: Tackling Complexity in the Heart of Software and started reading it immediately. It's not and easy book, but it is amazingly interesting. I'm just ate the beginning but I want to quote Ralph Johnson, author of Design Patterns 

Eric Evans has written a fantastic book on how you can make the design of your software match your mental model of the problem domain you are addressing.

 And even before open it ( well.. I'm reading it on my kindle so I do not really open it! ) I have learned something. Never ever underestimate an acronym.

I survived Nodejsconf.it

On Saturday I attended and talked at the 2012 edition of Nodejsconf.it. I was pretty nervous because the talk would have been in English and... because the proposed title was "Why I hate Node.js". As stated ate the beginning of the talk I really do not hate anything. Life is too short and too complicated to hate things like web frameworks of programming languages that last only few years. But I thought also that ti would be wise, having a provocateur presentation in front of a potentially hostile crowd , to wear an helmet! The "hater" talk was inspired from a tradition I saw at the djangocon since the first edition. I do not know if it has deeper roots. I tried to explain my points with ease and humor. And it  worked. I had a very very positive feedback from both attendees and webdebs, the organizer of the conf. In the audience there were prominent personalities of the node.js community and the question time has been taught.Glenn Block, Microsoft Azure expert of Node.js.
I had also some controversial critics on joined.in about being in favor of multi-threaded programming  not showing data and not giving credits for some of the material in my slides.
So starting from the credits, I do really apologize for that. I was too easy on this and I hope this is not too little and too late.
The writer/javascript stuff was taken from the blog post if Hemingway wrote JavaScript. It appeared also in HackerMonlty after I decided to mention it in my talk ( just saying). Growing complexity examples where taken from FENN BAILEY blog post "Node js a gigant step backwards"
Something also from "is nodejs wrong" by Nicolas Cannasse. And part of the questions to make some fun of javascript typing are takent from the famous "WAT" video ( you can find it on the internet :-) ). The quote

You want to use a programming language with the word "script" in it... and "java" in the other side

Is mine.
About not showing data I tried to find some data that were not controversial. The "Hello word" example ha no meaning and the implementation could bias benchmark too much.  I displayed a chart with completely made-up data just to show how I think complexity over feature could work on a large node/javascript codebase.
I had a great time doing this talk and the majority of people seem to liked it. If I had the chance to perform it again I will try to fix it with the previous suggestions.
These are the slides

Why i hate node js from sammyrulez

The Ten Commandments of Egoless Programming

The Ten Commandments of Egoless Programming, as originally established in Jerry Weinberg's book The Psychology of Computer Programming with my updated comments.

1. Understand and accept that you will make mistakes. The hardest part here is to make OTHERS understand that you can make mistakes without been pointed as an incompetent  looser. Maybe it is a "large enterprise" issue or an Italian stereotype but I find this particularly hard.
2. You are not your code. kind of a mantra. Feeling an artisan makes you sens your code as the product of your art.
3. No matter how much “karate” you know, someone else will always know more.  Seek and accept input from others, especially when you think it’s not needed. [TOTAL QUOTE]
4. Don’t rewrite code without consultation. There’s a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer. [TOTAL QUOTE]
5. Treat people who know less than you with respect, deference, and patience. Very hard! I mean with coworkers you always tries to be understanding but there is a point when you sens you are wasting your time. What to do then? Keep going or Giving up? I got no clear answer... I realy on my gut on this. 
6. The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, rather than some serious inconvenience to be fought.[TOTAL QUOTE]
7. The only true authority stems from knowledge, not from position. If you got this about yourself it's a good metric to become a senior. But do not expect this from others. I got too many times the " Because I said so" answer. Many people thinks that position means knowledge.
8. Fight for what you believe, but gracefully accept defeat. UH... too much zen in here if you put it in a long view perspective. How much mud can you swallow before throwing up? 
9. Don’t be “the coder in the corner.” Again do it... but be ready to got someone to tell you "back to your corner, coding monkey!" see points 7 and 8.
10. Critique code instead of people – be kind to the coder, not to the code. Works well with rule number two.

In the end you tailor your way to seniority within contrast and the true art behind it is to learn stuff that matters  learn to understand what is noise and what is important. And not  hanger in the process.