CVDD – Curriculum Vitae Driven Design

I’m in debt to Giovanni Asproni for this new acronim. But the fact behind the term is very well known here.

Let’s start saying that it’s a matter of fact, although a sad one, that a lot of enterprise projects are poor designed.

But, as strange it may seem, in my career I (almost) never saw a simplicistic design, they are all wrong on the over-complicated side.

So why is this happening? If they were all producted by morons, they ought to be equally distributed on both side of the Gaussian. Also I have anectdotical evidence that not everybody in the contractor world is a moron (honestly!).

So, as you may have guessed, the reason behind it is a little more complicated and it has Darwinistic-like reasons.

As contractors’ life goes, you need to keep your resume always updated to the latest hype and keywords in order to be recruited. And simply you don’t have enought spare time to learn everything, so…
a solution appears misteriously in front of you: Put whatever is the current buzzword in your next design document.

Add some new fancy framework or library to your current project, and learn it, test it, experiment with it at your usual tariff.  It’s brilliant and convenient!

I’m not sure to blame only the contractors, it’s a response to the market absurd rules. If customers were looking for developers who know how write simple and elegant code, they would get exactly that.
Instead they usually hire developers with the most buzzwords complete CV. And at the end, they will obtain CVDD applications. Unnecessary complicated, with tons of once-popular frameworks, often misused, etc. etc.

Disclaimer: in case you’re considering to hire me, I would never do anything of this sort! 🙂

Explicit is better than implicit!

Today at work I gave a little help with Javascript to a collegue of mine, he’s a very bright guy but he is touching Javascript for the first time.

So after a little of pairing, we saw that in a line a class method was used as it was a standalone function.

Given that there’s no ide for javascript and the code was not properly indented, the problem is more trickier than it seems.

Later, he asked me how can you easily tell them apart… not very easy unless you start counting the braces. (if someone know a better way please tell me).

So now I have finally understood how convenient is that Python uses an explicit this for each class method.

Better late than never…

or in Italian “Fino alla bara sempre si impara”

157 + 486 = 157486!!

At least according my first Django site!

(bug fixed in version 2.0 almost 12 seconds later…)

Anyway as little spike I created a (very useful) site that adds two numbers, for example

http://uberto.user.openhosting.com:8000/calc/156/plus/418/

of course you’re free to change the numbers. Not sure how long I’ll keep it running up.

What’s the point? Actually I wanted to deploy something on my virtual host but creating this site took me 5 minutes and 8 lines of code.


from django.http import HttpResponse
import datetime
def plus(request, n1, n2):
n1 = int(n1)
n2 = int(n2)
html = "%s + %s = %s" % ( n1, n2, n1+n2)
return HttpResponse(html)

These are 7, the last one is in the urls.py (one of the 4 files automatically created by django for a new project).


from django.conf.urls.defaults import *
from views import *
urlpatterns = patterns('',
(r'^calc/(\d+)/plus/(\d+)/$', plus),
# Uncomment this for admin:
# (r'^admin/', include('django.contrib.admin.urls')),
)

So, all in all it’s not such a big effort! I know that maybe with Rails I could do the same in half the lines , you could do it in Python too for what it matters.

Anyway I’m still fond of Python values (aka “import this”) and Django is really really elegant.

I haven’t yet configured postgreSQL on the server, so you have to wait a little before seeing something interesting.

To agile or not to agile

I know I’m late, actually I’m always late so there’s nothing new here.

Anyway, some days ago, a post of mine in Milano Jug mailing list, has been quoted by .MOz on his blog.

This is his translation (my actual post was in Italian):
“Blockheads, agile or not, will never produce good code, just as even if you can produce the best software in the world but you don’t understand the domain your project is doomed: technical success is a foolish illusion.”

Maybe “blockheads” and “foolish illusion” are a bit too euphemistic for my tastes, but ok, the meaning is there.

Anyway if you don’t know me, you can think of it as a critique of Agile methods from my part, but it is not. I’m still regarding Agile Methodologies as the fastest and the most cost-effective way to develop software.

It’s only that they’re not a goal per se.

Being fair, probably 99% of Agile practitioners do agree here.

Moreover, methodology is not the Most Important Thing in Software Development, and neither the second one… probably it is the third one MITSD.

It’s like having a race between an old Fiat 500 and a Ferrari Maranello:  if the Ferrari driver doesn’t know which way to turn, or if he doesn’t know how to drive a car… he simply cannot win.

Forums are dead, long life to groups

At first there was NNTP, a dedicated protocol unfairly killed by firewalls and proxies.

Then came the mighty Mailing lists, with their burdens of mails, daily digest, problems with reply, complicated majordomos and the ultimate lame who cannot unsubscribe from them.

In the Php era, Forums ruled unchallenged. Reasonably easy to setup, with lots of implementations to choose from, full of smileys for every users they seemed the ultimate solution.

But how are they doing now, in this era of Web2.0, Social web and Ajax scripts?

Not so well after all. I’ve tried the “groups” feature of Google Groups, Facebook, Flickr and Mixi, and I found  them much more powerful and flexible of forums.

Especially Facebook groups have a lots of very cool features (privacy levels, officials, the wall, files). It’s hard to imagine more than 4 million of people on a single forum or mailing list!

So cool as a matter of fact, that I decided to implement something similar (but simpler) for my Django project.
Stay tuned…

D300 meta-review

Today, after a few days doing practice, I reread some review of D300.

Of course kudos to whoever, not being paid, reviews such a complex camera on internet. I’m just reviewing their reviews.

I’ve read a lot of magazine review also, but without doubts the ones on internet are better.

Anyway, here are my thoughts.

Ken Rockewell

Very good review, simple and effective, with clear pictures to show the difference. A problem is that it compares only jpeg shoots and not raw ones. I think that whoever is willing to spend such a sum over a camera will easily know how to use raw to get the best out of it. Anyway jpeg setting of D300 are almost magical.

About his “blunders”:

1) I don’t use AutoISO, unless untill will produce an AutoISO sensible to the actual zoom used and not only to the shutter speed.

2) I agree with Nikon here. No point in having Continuous mode with build in flash

3-4-5-6-7) ok, but very very minor. I do have slightly bigger complaints about D300. Probably I’ll post them soon.

DPReview

As usual for DPReview is incredibly informative. If you are looking for a specific detail, you can find there. A lot of comparation pictures and all the usual stuff we’re used t find there. Not sure if it can really help you to decide… too much information and details. Maybe it lacks a more “human friendly” section on impression of use.

About the conclusions, I fully agree with either pros and cons. Expecially on articificial light the performance are not better than those of mine 4 years old D70. My solution? Always use Raw in difficult light and fix the WhiteBalance later.

Thom Hogan

Very good review with also an inusual point of view, with the current prices what’s better, D300 or D2x? They can be “differently targeted” camera, but if the price is more or less the same… who cares?

All in all gives it has seemed to me the most “sincere” review on D300. The final drawbacks are a bit disappointing though, they’re more limits of current techonology than D300 specific problems.

About this blog name…

As a matter of fact I like refactoring, I like it very much. I mean the real one, done in little steps without changing the behavior.

That is, refactor/little behavior change/refactor/another little behavior change etc. in this way you can introduce a big behavior change without much pain. Or at least making your suffering as less as possible. If you don’t know what I’m talking about, you can find it explained here.

So, why choosing “if it ain’t broken don’t fix it” as title?

Because I hate when things that work just fine are broken by people with “Big Vision”TM.

Today I found a blog (from a Kde developer) with a still better suggestion:

don’t code today what you can’t debug tomorrow

Btw the phrase came from Terry Pratchett’s Discworld books, here is another one:

Give a man a fire and he’s warm for the day. But set fire to him and he’s warm for the rest of his life.

D300 raw file format

Ok, so here we are, the first photo related post.

I recently bought a Nikon D300. Briefly, coming from a D70 the difference is huge. In price too! 😉

The D300 is much more a “professional” camera, no fancy automatic modes for beginners, everything is more complex and you’re supposed to know what you’re doing.

So if you cannot tell the difference between a good Bokeh and a bad one, probably this is not the right camera for you. By the way, I just recently discover that it come from the very informal Japanese word ボケ that means “fuzzy”.

I’m saying that because, strange as it may sound, there’re a lot of people around with deep pocket and no clue whatsoever about photography that simply buy the most expensive hardware they can afford.

Given that I have the manuals in German (of which I don’t understand a word) I did some research on internet and I did some interesting discoveries. Because I’m a pretty decent guy I’ll share that with you and I save you to read all the explanations. But if you don’t trust me, on the bottom you can find the links.

Anyway these are my first discoveries:

• Raw vs jpeg:
  D300 jpegs seem very good. Very very good. I mean, almost too good to be true. I’m wondering if is it still worth shutting in Raw for “standard” pictures. Of course you will continue to need RAW for difficult ones, as instance in case of different artificial lights (so you can change the WB afterward).
• 12bits vs 14bits Raw:
  I haven’t tried (yet) but everybody who tried agree that you cannot tell the difference unless you greatly overexposure the picture (and in that case your picture is ruined anyway). The sensor date are the same. So it simply means that this generation of sensor has not enough information “to properly fill” 14 bits for channel.
• lossy vs lossless Raw compression:
  According the Nikon engineers the “lossy” compression loses details where you’re eyes cannot see them (in the Highlights). So unless you’re going to do HDR snaps you can safely use lossy Raws and still don’t lose anything in your postprocessing.

Links about Nikon Raw formats:

http://terrychay.com/blog/article/lossy-raw-compression.shtml

http://regex.info/blog/photo-tech/nef-compression/

http://www.earthboundlight.com/phototips/14-bit-raw-12-bit-part-two.html

http://www.nikonians.org/forums/dcboard.php?az=show_topic&forum=149&topic_id=103960

http://www.majid.info/mylos/weblog/2004/05/02-1.html

And Ken compares D300 to D200 when taking jpeg pictures.

Step2: decide the scope

It has taken some time, but finally I decided which kind of site I want to create.

It’ll be an experiment, half on technology side and half on social-web side.

So for the technology I already made the main choices:

Django -> the more I’m using it the more I like it.

PostgreSQL -> Although I knew it, I was surprised at Fosdem to see which level of speed and reliability it has archived lately. I don’t need to use sqllite anymore for tests. At least for the moment.

Rest architecture -> I bought this book at Fosdem because I was intrigued by a (not so good) lecture on Rest. I’m still not sure if there is some value in being 100% RESTful, but definitely most of the suggestions are very good indeed.

Hijax -> Another book that changed the way in which I’ve been looking at Javascript.

As for the content side, I have almost chosen a name, following the immortal guidelines of “must be cheap, can be lame”.