Tuesday, December 30, 2008

Retesting software modules

How do you test a piece of software or module that came for retesting, meaning you found some bugs, submitted them to developers that fixed them and sent the module back for retesting?

I think that, whether roles such as QA experts are more or less defined in the team, the person who found the bugs should accurately check the software, as she's the one with more experience on the history of the bugs. It would also be useful to hand the software to another tester, which could look at it with a different perspective and identify more and/or better tests.

The important thing is that tests should be repeatable, better yet automated where possible, otherwise it would be very difficult to positively assert that the bug has been fixed.

Wednesday, December 17, 2008

A parallel between software and people

Recently I witnessed the umpteenth dysfunctional behaviour between developers and systems engineer (nothing new below the sun). The subject of the debate was the backup of several customers' databases used by a software application built by developers, and each group was repeatedly passing the buck to the other one; systems engineers said "you built the application, you perform and collect backups", developers said "you are in charge for all backups, these should not be treated differently". Obviously the hidden agenda was trying to avoid a task nobody likes. It was all worsened by the fact that Xmas holidays and consequent vacancies are approaching, and several people will be home playing the couch potato.

And who was wrong? And who was right? It didn't matter in the thick of the fight...

I think that the right approach is "hey we're in all this together, let's talk and get a solution out of it", but sometimes a long history of untrust and urban guerrilla warfare can be hard to overcome.

Anyway, as a game, let's see if some software development principles and patterns can also apply to people :-)
  • Rigor and formality: formality is a plus (sometimes it can be a burden), but rigor must always be present.
  • Separation of concerns: complex systems are difficult to analyze, and it is very difficult to manage the process that leads to deliver. To overcome this point we try to separately manage unrelated issues. This is why we have developers AND systems engineers...
  • Modularity: it is a specialization of the former
  • Abstraction: complexity worsen the capability to build models that are effective for resolving the problem, thus we abstract from details that are not relevant to the goal. Is it important to know where databases to be backupped come from?
  • Anticipation of change: YAGNI :-)
  • Generality and Incrementality: following the Abstraction principle, we abstract and do not consider them now
Do you have an opinion you'd like to share?

Tuesday, December 16, 2008

Every build you break...


Roy Osherove singing in Barcelona, TechEd 07. Pity for the slightly too long introduction.

Monday, December 15, 2008

Words of wisdom from Master Oogway

One often meets his destiny on the road he takes to avoid it.

A very quick demo on Hudson

Uncle Bob has published a very quick demo in which he uses Hudson right out of the box as a stand alone process (no servlet container required).

Thursday, December 11, 2008

Agile and procedural

Today I partecipated in a discussion started by Dennis Morton who asked if anyone had succesfully adopted Scrum, XP or RUP on non-OO procedural based applications. A little rephrased, these are my thoughts.

Scrum is relatively easy. Implementing Scrum could not be that easy because you have to face several impediments: one of the biggest ones is that it clashes with the existing culture, but that does not depend on the particular language you use.

As Keith and Charlie pointed out, life is easier for OO programmers, as there's plenty of relatively inexpensive tools and technologies (if not inexpensive at all) that can help them: Junit, Cobertura, JMock, EasyMock, Hudson, CruiseControl, Eclipse, NetBeans, and so on and so forth in a sparse order, just to talk about Java.

I don't know of similar tools to be used in RPGLE ("inexpensive" and "IBM" cannot share the same sentence) but that might just be my ignorance, so it is up to the team to find a suitable solution (that could also be an expensive but affordable tool).

Anyway, I have to point out that Scrum is just (?) a very good set of techniques for project management, but it is not enough, as you must have in place the proper engineering practices to benefit from the advantages that Scrum offers.

It is useless to give a product owner the possibility to steer the project at every sprint planning meeting if a simple change requires tons of programming hours, as she always has to weight benefits against cost. You can be agile because you have test harnesses supporting your changes. You can be agile because you continuously refactor. You can be agile because all the team members own all the code. You can NOT be agile just because you use Scrum, as you're just exposing problems - problems that most of the times existed well before Scrum was implemented, so don't shoot the messenger. You also have to master the tools to resolve problems. And the first and most important tool is people, so I'm completely with Keith and Charlie who put them in the heart of the process.

We have to undergo a similar challenge as we'll embark on a very big project next year, almost completely based on IBM technologies. As we're starting from about 650 pages of detailed requirements, aged about one year, a remote customer, a distributed team with several new members (not to mention the rest), we'll surely have to cope with changing requirements (no, not the band in which Craig Larman plays in his free time) and lots of other variables and issues.

It is likely we'll have some answers within the next few months; up to now, as it is well understood that we'll have an application layer exposing services, the only thing that I could think of is the use JMeter as an acceptance testing tool. As always, inspect and adapt, rinse and repeat :-)

We're open to suggestions!

Wednesday, December 10, 2008

Dexter Jackson Mister O

I know it happened a couple of months ago, but I only saw the competition the other day... Dexter Jackson is the new Mister Olympia!


By the way... the commentators reported rumors about the great Ronnie Coleman joining back in the 2009 competition... I still haven't swallowed his 2006 defeat to Jay Cutler, and last year he suffered from too many injuries... shall we have him back on the top of the Olympus?

Snow, rain and commuting

I really don't know why slanderer have to say that some snow and rain can cause big traffic jams in Milano... today's commuting (less than 30 km) only took me 4 hours and 20 minutes...

Measure with JMeter

Apache JMeter is a subproject of the Apache Jakarta Project that can be used to measure performance on static and dynamic resources such as files, Servlets, Web Services and many more. Moreover, you can also use it as an automated testing environment, as you can easily compare actual results with expected ones using assertions.

Using JMeter is really straightforward and the manual is quite good; just remember to copy mail.jar and activation.jar in the lib dir (as an alternative you can always set the user.classpath property in jmeter.properties) if you want to test Web Services.


The picture shows a graphical example, but it is also possible to view the results in summarized reports, aggregated reports and so on.

We used it to simulate a heavy load on an i5 exposing a Web Service realized as a proof of concept, and drew a comparison with a similar service realized some years ago. We were quite satisfied with the results, as the average response time under stressing conditions has dropped by about 40%.

Wednesday, December 3, 2008

Enough with mobiles!

I am not against technology. I think technology has really improved our life. Internet has opened a whole new universe to a lot of people. Mobile phones and PDAs let you connect with everyone you need almost wherever you are, should you need it. But... do you really need it?

Technology should be an aid, and it should not generate addiction. It looks like people can't help talking on their mobiles, no matter where they are. Even when I got married one of our guests forgot to turn his mobile off. Some years ago, when wireless earphones came out, you could easily spot many (supposed to be) crazy guys passionately talking to themselves, waving and bustling about.

There was only a place where people dared to bear the burden of silence, possibily reading a book, and that was the subway (and only because mobiles didn't work down there). Now this last rampart has fallen.

I think that there's a reason if in some African regions "progress" is translated as "dream of the white man".

Tuesday, December 2, 2008

Collective Code Ownership Part 2

When I write "everyone is responsible for all the code" I also mean that everyone is responsible for all the tests, so if you only have unit tests and you need an integration test... write it! It does not matter if you didn't write the original code or the original unit tests, it does not matter even if you didn't talk to the original developer. It is your responsibility to write it: navigating through an application just to click a link is (almost) completely pointless, and it sure is a waste of time. That does not mean that end user testing must not take place (how could you assert that "a normal user should be able to foobar the barfoo without previous training" otherwise?), but we should strive to automate as much as possible.

This is even harder to assimilate, because not only you have to touch code written by others, but (heresy!) write tests for code you didn't write. It's already hard to persuade people of how much TDD pays off the initial investment and the mental shift, but it's even harder to push them to use tests as a primary way to discover how a particular piece of code works (I often write tests for third part libraries or also for checking the behaviour of java.lang or java.util classes I'm not sure about). I can understand that people fear changes, and that one could be unwilling to change the way he's always worked, but here we're talking about being afraid of one's own shadow. Try it, and try it seriously, and after you did if you still think it won't work (and you won't) you'll still be able to give it up. And... no, "I have no time" is not a valid answer, because not having tests only leads to wasting more time.

Alas, too often I perfectly agree with Gabriele...

Monday, December 1, 2008

Collective Code Ownership

To quote from Wikipedia:

Collective code ownership means that everyone is responsible for all the code; this, in turn, means that everybody is allowed to change any part of the code.

That also means that everyone has to change any part of the code when it is required. Developers cannot shield themselvs behind a "he did it". Even if you didn't partecipate in the writing, the code should be clear enough to allow you to understand it and change it confidently.

By giving every programmer the right to change the code, there is risk of errors being introduced by programmers who think they know what they are doing, but do not foresee certain dependencies. Sufficiently well defined unit tests address this problem: if unforeseen dependencies create errors, then when unit tests are run, they will show failures.

That's true, but... who controls the controller? Just today, after other colleagues were trying to integrate two systems without writing tests (boo!) we wrote a (supposed to be) failing unit test and... it didn't break as it should, as we were testing for equality objects that we clearly knew were different. That was because we forgot to change the equals and hash code methods after adding an attribute to the result class of which our tested method returned an instance, and we didn't have a test on equality on the result class because all the code was generated by the IDE. Nevertheless having a bunch of tests sped the process of finding and fixing the error: if we didn't write a failing test before proceeding we would have spent a lot of time before we managed to find our (not too subtle) bug - time our colleagues actually did spend.

So... always write your tests! That's another supporting example for the "we tried baseball and it didn't work" post: Collective Code Ownership also works because of other practices, such as coding standards, pair programming and unit testing. I'm still convinced of what I wrote, but I certainly agree on the fact that you cannot simply pick random XP practices and hope everything will go well.

Saturday, November 22, 2008

Italian Agile Day 2008 First Impressions

First of all... wow 400 people, definitely a success and a huge growth from the former editions. It was very interesting and an occasion to meet so many passionate professionals (among them, after some long-distance debates I finally met Gabriele and Matteo in the flesh).

Pity that workouts were sold out virtually two seconds after the registration process started... I hope we'll manage to contact the speakers and get some materials.

The meeting was very dense, I barely had the time to breath between sessions. Maybe a little more relaxed schedule could leave you some time to interact with speakers and panelists on a face-to-face basis for better to clarify some doubts or to go into topics thoroughly (after all, culture is acquired in cloisters and not in lecturehalls, as I was brilliantly told in my youth in Politecnico that is forgotten).

That said it surely was a positive experience. The introductory panel dealt with the apparent dichotomy between pragmatism and agile; after an interesting debate Simone Genini pointed out the Agile Manifesto as a very good answer to the "where's the path?" question. Very interesting insights by the other panelists (Stefano Fornari and Paolo Polce) as well.

Not having the gift of ubiquity (I actually do have it, but if you discovered it you'd be envious so I always try to hide it) I could not follow everything I'd have liked, so I'll just talk about the six sessions or experience reports I attended to.
  • Agile come strumento efficace per la gestione dei progetti: interesting (and necessarily very light) introduction to risk management and some ways in which agile helps to deal with it. I was very happy to see that Simone gave many bibliographical references (pity I just bought three books on project management so I'll have to defer them a little).
  • Funambol: introducing SCRUM in software product development. Edoardo presented a synopsis of their transition to a waterfallish method to a "scrummy" one (transition in progress, we're working for you). Very interesting because I could really appreciate the power of the tools that Scrum gives us, as reading their burndown charts I just exactly knew what was happening even if I had no clue of Funambol and their teams before today (one for all, they choose stories that were too big).
  • First coffee break: a queue worse than the one I normally experience when commuting. Actually I didn't attend to it :-(
  • SCRUM-W: quando si maschera waterfall con Scrum. You instantly know when someone is used to presentations, and Luca surely is: no bullets slides, creation of expectations, clearness of exposition and knowledge on the topic.
  • Non si impara solo dai libri: la nostra esperienza di Mentoring. Matteo (see link above) reported two mentoring experiences in two very different realities: the first one in a loose environment and the second one in a highly structured one, and he explained the different approaches used.
  • Second coffee break: this time we really did it! probably many were discouraged by the morning experience...
  • Processo al database server relazionale: very funny drama (after all it was an experience report based on a true story) with very good actors performing a trial. Database was convicted in the end, even if I'm sure, as someone said, that tools are innocent and people are guilty
  • Il nostro metodo per piccoli team con molti progetti da gestire contemporaneamente. I arrived eager for answers, as that's just what we face each and every day, and I was quite disappointed when Claudio said, just a few seconds after starting, that he didn't have any. Luckily what he really meant was (at least that's what I understood) that he hasn't developed a great theoretical meta-ultra-mega-iper-method but he has found a series of practices that help him, his team and his customers. I wish our customers were like his... but complaining is useless, it is our job and responsibility to teach them.
More and more will follow on the Italian Agile Movement freshly refactored site.

What now? to quote Mr. Shin, passion!

Thursday, November 20, 2008

Italian Agile Day 2008 Last Reminder

Looking forward to meeting you all there tomorrow.

Wednesday, November 19, 2008

NetBeans 6.5 is available for download

Version 6.5 of the popular IDE is now available for download here. This version also includes an anonymnous usage statistics collector about high level features for better to help developers to steer the project on the basis of the real usage.

Monday, November 17, 2008

Logs are there to be read

If your application produces a new folder whenever it generates files AND writes an application log, it is NOT enough to check if the newly created folder exists to infer that all went well.

Example given, last time that we were following an issue (apparently) concerning missing data we discovered that the operator - who fired the missing data issue - had started the elaboration but did not check the logs. If he did he would have easily discover that the log was truncated not only in the middle of the elaboration, but also in the middle of a row. If he also checked the system log he would have just as easily spotted a system crash with subsequent reboot. And he would start the elaboration again. <irony>And he would not have dared to disturb us</irony>, but most of all he would not have alarmed the customer, leaving him with some doubts on the integrity of the system.

Unluckily, logs are just another thing like manuals: nobody reads them. I wonder whether there's an equivalent for RTFM... RTFL? No, that's not ROTFL, just the opposite...

Thanks to Antonio for letting me shoot his logs.

Single Choppable Neck

That's a good definition of the Product Owner... and as an add-on to last post, he's the one that gets the blame when he takes bad decisions. This time the product owner choose to prioritize a quick deliver instead of focusing on requirements, and this was not a happy choice. Luckily, his head has not been chopped and it is not going to be, but surely this taught him something.

Unluckily, the Product Owner is also the one who gets the blame when decisions were good but the outcome wasn't. Moreover, we have to remember that a bad decision is better than no decisions at all, as bad decisions can (almost) always be reversed, and that we firmly believe that everyone is always doing (trying to do) his best.

So what's the point in being a Product Owner? well, it is true that you have to carry the burden of insuccess, but you also are the shining star in case of success. Nevertheless, it is quite difficult to find someone who is willing to play this role when you're transitioning to Scrum, because of that axe always lurking above. Even more difficult when the Product Owner is an external customer.

The only way we have to persuade people is to educate them, showing that we are not looking for a single neck to chop, but we're looking for someone that could help us to reach a truly win-win situation.

Friday, November 14, 2008

Stakeholders and Requirements

Use cases are a widespread adopted technique for recording requirements. One of the sections (in the Cockburn format) is named "Stakeholders and Interests", and it reports... stakeholders AND interests. ALWAYS use it. Forget a stakeholder and you'll miss his interests, and as you can guess this is NOT good.

Cockburn uses a candy machine as an example: you interact with a candy machine to get a candy, so you're the user. If the manufacturer did not hold into account the interests of the seller (make money out of selling you candies) the candy machine would not ask you any money, but would give you free candies. That would make you happy, but it would make the seller unhappy. It would be very expensive to recollect all the candy machines on the market, go back to design, build new machines and redistribute them, let alone all the free candies gone with the wind.

The same happens with software, and it is a worse phenomenon as it is much easier to forget a stakeholder.

I recently witnessed a situation in which the headquarter superimposed a software to other offices without taking into account the real needs of the final users (yes, it holds for both extremes) but oversimplifying the business model. That was not an act of power nor stupidity, it simply was what they thought was best - and they had their reasons. Unluckily now they're back to formula, and a meeting has been scheduled to gather more requirements that can satisfy these stakeholders. Everyone would have saved a lot of time, and a lot of money as well (as one of the latest activities was an almost pointless meeting with more than twenty managers).

The problem was magnified by the fact that the software was a tool to use in a change management process, namely the first step to computerization and standardization of workgroup activities, which is already noteworthy per se. And, as change management involves people, it is never easy nor simple, as people normally resist changes. This time the persons involved (that were stakeholders AND users) did not understand the message (one of the reasons for resistance) because it was not conveyed in their language, and that brings us to another consideration.

Eric Evans asserts that everyone involved in a project should speak the very same language (he calls it "Ubiquitous Language"), and that a great investment has to be done in discovering and defining it: it will definitely pay off. Do it. It is the language that drives development, understand the language and you'll understand the requirements, thus you'll deploy more suitable software.

So to summarize: do not forget any stakeholder AND find a common language.

WordPress cats and tags

Wow, you can automagically turn selected categories into tags... Last time I made a blue, now I see where categories fit in... Looks like the inverse is not possible, but maybe I've not explored enough... I will :-)

Thursday, November 13, 2008

DownThemAll!

DownThemAll! is a very useful Firefox extension that lets you download all the links or images contained in a web page, with powerful filters and stuff.

After some months of use I almost accidentally found that you can also specify patterns for downloads using batch descriptors, e.g. if you want to download all pictures from #10 to #25 from your gallery you would use the following URL:

http://your.domain/path/to/gallery/picture[10:25].jpg

Detailed requirements: a never ending story

In an article about selling your IT Projects to Executives the author quotes a former managing director and global CIO:

User requirements, no matter what the development style, must be rigorously developed, detailed and documented.


While I think that it is perfectly true for big companies like Credit Suisse First Boston, where he worked for 18 years, I still am persuaded that it doesn't apply to every situation, though I hope my bank gives very detailed requirements to developers and that they have a very deep QA process in act (I also read from Symantec that banks spend about 10% of their IT budget in security).

But... where's the point of having 600 sheets of paper and 0 lines of code? Surely the requirements eliciting process can provide customers with real breakthroughs and give them a much clearer view of their processes and needs, but it all seems to end with that...

Iceberg approaching?

According to this article Sun is going to face the same adventure Titanic did a long time ago. The worst thing is that everything seems unavoidable, despite what Sun says. To quote from the article:

Do [they] know something we don't? Or do we know something they don't?

I heartly hope for the former...

Just Another WordPress Weblog

I finally gave up... surrounded by tons of WordPress addicted, I decided to give it a try myself, so I downloaded, installed and configured Apache, php and mySQL (with some pain in the b...ack trying to persuade Windows that extensions really are in the c:/php/ext dir).

Finally I got my installation working, as the picture clearly shows. Now what? well a tour in the administrative pages is due, so... hey there's an import feature! Will I manage to get a local copy of my blog on Blogger? The system says it's supported, so I won't spend time with anything, just gotta try this one. Everything seems fine, wp tells me that I must tell Blogger to authorize my local installation, I do it and... well...

Unable to find the socket transport "ssl"- did you forget to enable it when you configured PHP? (0)

I think you can say you forgot to something when you knew you had to, but no time for details... let's go to php.ini... decomment extension=php_openssl.dll... argh it does not work... stop service, start service... yuck! 0 post out of 146, 0 comments out of 10... Import? Import! Importing... importing... importing... (I got a 44k dial-up, no ADSL on the whole territory)... 14 out of 146... I also get the feeling that the download stops every 5-10 posts or so, but maybe it's my wonderful (...) Internet connection. No need to wait till the end, let's go check the first posts.

Everything seems ok, pictures are imported as well. For some strange reasons Blogger tags are called Categories in WordPress, while WordPress tags seem to have no correspondence in Blogger, but more or less my local backup is growing into shape.

Obviously I won't get Blogger Widgets, but as most of them are javascript supplied by other parties (e.g. the Italian Agile Day Banner) it shouldn't be very difficult to fit them into WordPress.

More on this will follow.

Thursday, November 6, 2008

Star Wars revisited

Hey this guy is a genius...



Well, as matter of fact all musical credits go to moosebutter, but the video version really adds that extra bit.

And, after the elections in the USA, some spots for the elections in the galaxy:

See more funny videos at Funny or Die

Wednesday, November 5, 2008

Is software quality expendable?

This is one of tose questions that has been around for a very long time. A recent study from Original Software shows that it will probably stick around in the next years, as the world of CIOs appears splitted in two: 46% of CIOs think that quality has a very important role, while 41% sees it as a "nice to have quality" or even as a necessary cost.


I'm not a CIO (yet) but I have a very clear opinion on the matter.

Many CIOs have a special bend for asking "low cost working software, ready for yesterday". The problem is that the real cost associated with software is not writing it, but - even after a considerable amount of time - reading it for further modifications, bug fixing, evolutions, refactorings, etc. Leave that mess now and it'll cost you much more tomorrow. Software becomes kippleized (read this book for more infos on the term), someone says this happens even if you're not touching it and, mostly, when you're not watching. Bad quality software makes your technical debt increase, thus increasing the cost of software. Add the fact that most of the time you're modifying existing software rather than creating fresh new applications and you'll have an idea about the huge impact this debt can have.

And... is that low cost software really working? The forces involved in software development are intertwined, so you can't modify one without affecting the others. Literature normally refers to time, scope, cost and quality. Cut time and cost and guess what happens.

Another very important aspect, albeit disregarded by CIOs, is that developers love their job (well most of them do). We try to do our best, and we are proud of it. We are not satisfied when time is cut and cost and scope are kept fixed, as quality necessarily drops. Nobody wants to produce sloppy code. Nobody wants to be forced to produce sloppy code. Somebody might even think to move to another company, which, again, means a non neglectable cost. That could even start a trend, and you can see a company slowly transforming into a sinking boat. I'm probably going too far, but it is just for the sake of clarity.

The whole study can be downloaded here (some informations required).

Scrum Mind Maps

These are the mind maps we produced during our Scrum Master Certification Course (thanks to Pietro for posting the original photos).






They have been drawn iteratively, i.e. after our initial draft we started circulating between tables and inspecting the work of other groups. They are a very clean example of how a small set of simple techniques like Scrum can be perceived and represented in very different ways.

Friday, October 31, 2008

Sun Certified Specialist Netbeans IDE

Sun is testing the beta test (...) for the Sun Certified Specialist Netbeans IDE. There's a study group here and obviously you can find a lot of resources on the Docs & Support section of the official NetBeans site.

Download NetBeans!What do you mean "I don't know NetBeans"? what are you waiting for? Go get it!

First draft requirements: lessons learned

I recently talked to a friend of mine that had just terminated a preliminary collection of requirements for a couple of new customers; I found his insights very interesting for a bunch of reasons, and I'd like to report some lessons he learned and was so kind to share. Having seen the result of his efforts I'd like to add a couple of thoughts of my own.
  • Having just a person conducting the interviews and another one working on the resulting minutes is not a good idea (we're not talking about polishing them up), as it is very time consuming. Better to spread the work among two persons and interact frequently between sessions: even if it might seem more expensive, as it doubles the resources involved, it greatly reduces further analysis and review time and leads to better results (likewise pair programming). This practice also reduces bottlenecks.
  • A versioning system is very useful. Use it.
  • Time spent on "aesthetics", like formatting, logos and such, would be better spent at the pub. Ops, I mean concentrating on the core stuff. A good look should not be important to you. If you really need it (you normally do when you approach a new prospective customer) leave it for someone else when the process is (almost) terminated. Better yet, separate presentation from content.
  • Don't forget nonfunctional requirements. I am always astonished when I see that nobody cares (or remembers) about security, scalability, reliability, configurability, performance, and so on. I can understand a customer might not think of maintenability at first, but how is it possibile that nobody ever says things like "the system should support no less than 2000 concurrent users" or "the system should adapt to many different situations"?
  • Inspect and adapt. Rinse and repeat.
Note that the purpose of these interviews was the production of a first draft for a possible collaboration, not working software; nevertheless the same rules hold true also in production time.

Wednesday, October 29, 2008

Putting people first

Stuck in a traffic jam (two hours to commute instead of the usual 40 minutes, thank you very much) I read for the umpteenth time The New Methodology by Martin Fowler. This time the section that struck a chord is Putting People First, as it is closely related to something I've just witnessed (a friend of mine was involved).

The company he works for has repeatedly told him that they can easily live without him, despite the good job he's doing for them (yes, they acknowledged it); though this might be true (well, it surely is) there are some words of caution.

The first and most important is that this attitude can only lower morale and productivity, not only for the person involved but for the whole group, as it can lead to questions like "If that's the way they treat him, why should I be in a different situation?". Someone might think he's different, but the biggest problem when you have a problem is to admit you have a problem (sorry for the pun). And when do you want to know you have a problem? well, now, or at least as soon as possible. That's why good people realize it. To quote from the article,

The good people look for a better place to be, and you end up with what you desire: plug compatible programming units.

Unluckily, unlike plug compatible hardware units, plug compatible programming units are not a great tool.

Moreover, it won't be that easy in the beginning, and it has a cost: studies show how substituting someone can lead to burn up a lot of money, and to get the same productivity level can take up to one year and a half. You even start with a negative productivity, as in the beginning the new resource not only is a sheer cost, but also takes his peers time thus lowering their productivity as well (I will not do multitasking! I will not do multitasking! I will not do multitasking!).

The best way to work it out is an honest and open conversation (I know, I always say so... it's because I firmly believe it). A collaboration must be to everybody's advantage, and everyone involved should make sure that this is so; when it's not possible (anymore) it probably makes no sense carrying it on.

Tuesday, October 28, 2008

Italian Agile Day 2008

Italian Agile Day
I'd like to quote the official communication for the 5th Italian Agile Day:

Venerdi' 21 Novembre 2008 si terrร  a Bologna il quinto Italian Agile Day. Si tratta di una conferenza gratuita di un giorno dedicata alle metodologie Agili per lo sviluppo e la gestione dei progetti software rivolta agli sviluppatori, project leaders, IT managers, tester, architetti e coach che hanno esperienze da condividere o che iniziano solo ora ad interessarsi a queste tematiche.

La giornata ha come obiettivo la conoscenza pratica, le esperienze sul campo e un attivo coinvolgimento di tutti i partecipanti. L'accesso รจ libero previa registrazione, i posti sono limitati.

L'evento, per la terza volta consecutiva, si auto-finanzierร .

Looking forward to meeting you there.

Scrum vs Lean?

Following this discussion I posted my thoughts on the subject. Even if I have just become a CSM, I have to agree about the importance of the certification itself; as our instructor Joseph Pelrine said, "I can only certify that we breathed the same air for a couple of days". This feeling seems to be shared by most hirers in the market. Nevertheless, I learned a lot in those two days, and I also had the opportunity to meet many skilled guys who share my very same interests.

That said, Scrum is about addressing the chaos you tipically get in a complex and fast changing environment, not about developing software: e.g. I always use it with my wife whenever we have to “refactor” our garden (ok, that’s not too complex an environment, but I’m sure you get the point). If you’re looking for practices to improve the quality of software, you’re looking in the wrong place. One word of caution: Scrum really fosters software quality improvement, but it does not provoke it. People improve software quality.

Scrum is not bad because you see many bad Scrum implementations; I’m sure you can find bad implementations of almost everything (OO is not bad because many programmers disguise their procedural code - which is not bad per se, but the mix of the two is often weird). I want to stress that a Scrum Master does not tell the team what to do, as he is not the leader; he is a servant to the team: sort of an istance of the “sacrifice one person” strategy by Cockburn, except maybe for the fact that in the latter you normally assign the sacrificed person a particular task.

I also agree with the fact that a team needs good leadership thus a good leader, even If I'm aware that many will not agree with that. I also think that the leader should emerge naturally in the team, and should not be superimposed. A team without a good leadership (I'm talking about an "internal" one) could easily end up out of action, especially an inexperienced one.

Monday, October 27, 2008

A new use for sudo

Gotta try it... will it only work with sandwiches?


The original comic can be found here.

Deep linking in YouTube videos

YouTube now allows deep linking in videos; all you have to do is to append the suffix #t=xmys to the URL of the video you're referring to, e.g. if you want to start after 2 minutes and 30 seconds you have to append the string #t=2m30s.

A job you love

Find a job you love and you will never work a day in your life.

Confucius

Not all that glitters is gold

Many people keep asking for more responsibilities. Some of them know what that means, others just see the golden side of the coin. Un(?)luckily they will soon find "di che lacrime grondi e di che sangue", which means that "with great power comes great responsibility", and you'll have to expose yourself more than ever, to take hard decisions and to to pay through the nose for them.

Is that so bad? Not at all, but it has a cost you must be willing to pay, e.g. if a member of your team is not behaving as expected and is only a burden and you have the power to throw him off, well, you should do it.

Now... Are you prepared to fire someone whith which you've had lunch each and every day for the last years? I't true that after all they could find a job that better suits their need, and they almost always do, but it's not that easy to step past the line.

Friday, October 24, 2008

Scrum and XP from the Trenches

My friend Manuela suggested me "Scrum and XP from the Trenches", an introductory war story on Scrum written by Henrik Kniberg which I found very interesting.

I particularly liked the idea of a separate place for unplanned items on the whiteboard, as we normally pin them with the others, depending on the feature they address: even if the team knows why it's taking so long to get things done, the management always seems to not to. A huge cluster of unplanned items is a clear signal nobody can ignore :-)

This is another (working) example of the old bit "the simplest thing that could possibily work"... way to go whiteboard warriors!

Henrik and InfoQ provide a courtesy copy of the white paper here (you have to login first).

Monday, October 20, 2008

Scrum by the book

Talking about Scrum I got an objection which sounded more or less "you speak just like a Scrum book, don't you have more practical insights?".

That gave me something to think about. Scrum is really simple: the customer provides a "single choppable neck", called the product owner, who is responsible for the project and decides what he wants (on behalf of the company, of course), the team produces it, the scrum master makes sure everything goes smoothly. They periodically meet and review what has been done and plan for the next iteration. (If you aren't satisfied with this, and if you don't know Scrum you should, go get this book).

So... what's wrong when I say the customer should be involved? Or that communication should be the basis of every project? or that you have to let the team do their estimates? or that management has to trust the team without telling them exactly what to do (or better, without telling them how to fulfil the customer's needs)? I really don't get it.

Sometimes you sound like a book because if you talk your talk AND walk your walk AND hit your target... well you have no reasons to not to. You studied it, you tried it yourself, you got a piece of the action. That's it. You have to know and follow the rules before you can break them, or else you would miss the consequences. I normally pick XP as an example, where people think they can easily remove some practices: you can be quicker avoiding documentation, but this is compensated by having a customer on site (this is now called whole team). Forget that and you're doomed.

Maybe it's just hard to accept that someone else succeeded in something in which you failed (and if someone asks about the problems you'd get combining Scrum and XP this could be true). Or maybe it's just a provocation. As (our) actions speak louder than words I simply took it as a compliment - even if I'm sure it wasn't.

Performance problems?

Last week I was talking about the Spring framework with a team leader, and he was quite astonished when I told him we were not worried by performance problems using it. That sounds strange to me, as I was always told - and firmly believe - that you have a performance problem only when you experience it. Worrying about performance when you don't have problems could lead to overengineering, thus is not very good. Obviously you should try to load the system as soon as possibile, because you don't want to find out your architecture is completely wrong two days before you go into production, but that's a different story (and no, we did it and we don't have performance problems either).

As an aside, what kind of question is "tell me a method you'd use in Spring"? I normally care about my pojos, keeping third party's javadocs close at hand should I need them. I don't think I'm supposed to remember boilerplate syntax, and actually I don't - even because I'm not a one man band, but I work in a team where skilled people can do their job (guys you owe me one) leaving me free to do mine.

Thursday, October 16, 2008

JDK6 Update 10

The new JDK6 Update 10 is available here. More infos on the FAQ page (thanks to Fabrizio for the news).

Wednesday, October 15, 2008

Transition from Waterfall to Agile

Jatin Leuva asked what is required when an organization is transiting from waterfall to agile: this is an interesting, and very common, question.

First of all you should have good reasons for the transition: if waterfall works for you, you have no reasons to change it. Unluckily this is almost never the case.

So your process does not work, and you have to change it. I'd start with retrospectives: what went well, what you'd do differently, what did you learn, what still bothers you. This can give you a start.

Meanwhile, you have to work at higher levels, as agile methods require a shift of paradigm with respect to standard management techniques: managers have to trust people and must resist the impulse to tell them what to do, and this generates fear: fear of losing power, fear of being useless, fear of loss of visibility, and so on and so forth. Unless you dispel this fear, your organization will never get agile, as managers won't allow it.

That said, a very good way to start is to hire an agile expert to help your team (and your managers) get confident with the new process - I should say with the new attitude: your team must face a shift of paradigm too, as team members will not be told what to do anymore, but they shall commit to deliver useful software. They'll have to earn the trust that managers should have in them, as it won't come for free. It's not about skill, it's about committment.

Monday, October 13, 2008

...a very good service?

As a follow up, I just received an SMS that reminds me that on October the 3rd, 2008 I have a time slot reserved for fixing my glass. That would be nice if it weren't October the 13th...

Another case of machines vs humans: luckily I dealt with humans, who did a very good job despite of the systems (un)supporting them ;-)

Face-to-face communication vs Documentation

Recently I partecipated in a discussion on the topic above; here are my thoughts.

Documentation has a big flaw: it gets out of date. And it has a cost. And is subject to interpretation, anyway. Face to face communication is a very good option, provided that you have access to the right people when you need them, as what is unclear can always be further discussed. There are many techniques that help, as active listening and many others.

But the real trick that avoids information loss (at least it minimizes the risks) is the continuous feedback that the team gets by the customer, typical in agile methods. In Scrum, e.g., at the end of each sprint (normally 30 days) the team holds a demo in which a working product is shown to the product owner (a "power proxy" for the customer), and that's where eventual misunderstandings pop up.

Another technique is having the customer write his own acceptance tests, using frameworks like FitNesse. That's also a very good documentation at system level, because tests describe exactly how the customer expects the system to behave. At code level, i.e. for developers, automated tests are the best documentation you can get, as they exactly describe how different pieces of software behave.

What level of documentation can be expected? it depends, and it's not only about how agile your process is. If defects in software could cause loss of lives you'll probably have a higher process ceremony, which means more and more detailed documentation, if software defects could only cause loss of comfort or discretionary money it's a whole different story.

Wednesday, October 8, 2008

A new Certified Scrum Master

After a very intensive and interesting course held by Joseph Pelrine, whom I recommend to everybody interested in Scrum, I am now, lo and behold, a Certified Scrum Master (trumpets playing, cheering and applause). That's not so strange, as I have been very involved in scrum(s) for almost 15 years, as a forward player and as a scrum half... even if that might not count!

By the way, I was shocked by a revelation: the scrum half is not the scrum master, as the name might imply... he is the product owner!

Friday, October 3, 2008

A very good service

I have to pay my compliments to all the CarGlass staff for the very good service provided, from the first call to the contact center to the return of the fixed car.

Thursday, October 2, 2008

Why people resist change

One of our customers has started an ambitious project that I think will bring them great advantages; the only problem is that it will require a paradigm shift and will radically change the way many persons are used to work. Brooding over this project I found this interesting slideshow that reports the most common reasons for which people resist changes.



Good news? They have already identified a good strategy to manage the risk.

Wednesday, October 1, 2008

Things that should never happen

Being a father myself, my heart sinks whenever I read stories like this one. I hope that people involved have been read their riot act.

Tuesday, September 30, 2008

A slideshow for educational blogs

I read and gladly report a slideshow with many links to very interesting educational blogs:

Friday, September 26, 2008

Should IT projects be insured?

I recently posted a comment on a discussion whose topic was similar to the above; the the initial question was related to the very high failure rate of IT projects.

Most of my experience refers to IT product development, so I'm not talking about other things such as insuring an IT project against political instability. As other contributors have pointed out, insurance companies will consider all the risks involved, which means that with such a low success rate software projects are not so likely to be insured, at least as a rule of thumb.

Most of the times the problem lies in the process used to manage the projects, so a better process - which can result in a more motivated team - is often the best insurance you can get.

More on this on this great book by Craig Larman.

Friday, September 19, 2008

A flexibility contest

The introduction in the Hibernate documentation reports that

A relational database is more flexible than a network programming language, so it doesn't need anything like a navigation direction - data can be viewed and retrieved in any possibile way.

As this is quite a statement, I stopped to consider it a while.

In a programming language you have to consider navigability, so if you have - as in the example - a Person class and an Event class and you want to get all events associated to a person you'll have to ask the person with something like person.getEvents(), but if you also want to get all persons associated to an event you'll have to ask the event with event.getPersons(), i.e. you have to provide accessors to both classes. And both classes hold a reference to a collection of their companion class. Moreover, when you add a person to an event you have to make sure that also the event gets modified, and vice versa.

In an RDBMS you can compose all the queries you like, starting from persons or events; the only thing you'll need is a well defined relation between the tables, which tipically translates into a bridge table. You don't even need to enforce referential integrity, though this is the path to the dark side (or is it?), as long as everybody knows how the tables should be connected. So when you add a person to an event you only have to insert a row in the bridge table.

In this sense databases are more flexible than programming languages. You can write
select *
from person p
left outer join person_event pe
on p.id = pe.person_id
left outer join events e
on pe.event_id = e.id
as well as
select *
from event e
left outer join person_event pe
on e.id = pe.event_id
left outer join person p
on pe.person_id = p.id
but this comes at a cost. You need keys. And you need indexes to manage them (even if this relates to the phisical aspect rather than to the logical one). And a bridge table to manage the many-to-many relationship, which doesn't belong in the domain at all but is a pure fabrication used to represent the model. This clutters things a bit, even if we're so used to it that we don't even notice.

The Java language gives a much clearer representation of the domain (at least, the signatures of the method do):
public class Person {
// stuff
public List getEvents() {...}
public void addEvent(Event event) {...}
}

public class Event {
//stuff
public List getPersons() {...}
public void addPerson(Person person) {...}
}
The language shields you from how the model is represented (that's where the rigidity is hidden), and it is more natural to use.

Databases can use views to simplify data retrieval, but they don't work for inserts and updates. That's where stored procedures come in handy, but... aren't they written in a programming language? Should the latter be considered part if the database or as an external means to get a higher abstraction over SQL (which in turn is a language of its own)? How far should we push this?

My conclusion? Everyone should get their act together to make sure that the quality of what they build is the highest that they can get, either when designing a good database schema or when implementing a bidirectional association. The problem is that "the highest they can get" can sometimes be a low standard, so everyone should always try to improve, no matter how high the standard. I think this rule applies not only to programmers in their own field of competence, but to men in the broader sense.

Wednesday, September 17, 2008

Moving your quick wiki

Little by little our VQWiki test installation become our VQWiki production environment; it is not enough for some project management activities, but it's great as a collaborative repository.

Should you decide to move the directory in which you store the files (we did), it is enough to modify the filesystem directory in the admin page; this creates a new folder in the specified position, in which you can copy your existing files. As an alternative, you can modify the homeDir parameter in the vqwiki.properties file located in the WEB-INF/classes folder.

In the same folder you can find the ApplicationResources.properties file, in which you can give your virtual wikis a friendly name.

Thursday, September 11, 2008

Here we are again

And this does not surprise me... all this hullabaloo about switching the LHC on, when no actual collisions had been planned, as only one path was active in a given moment... Was it just a rush to catastrophical news? Thanks to that, a teenager has committed suicide. I hope somebody will clean up their act and think before they talk or write.

Wednesday, September 10, 2008

See you tomorrow... LHC permitting?

This morning the LHC (Large Hadron Collider) at CERN, the most powerful particle accelerator in the world, was finally switched on, and a beam of protons was successfully fired around the 27 km tunnel. This is a great milestone in research, because it could lead to several breakthroughs about the "internal working" of the Universe.


The LHC is composed by thousands of elements that have to work together with great precision and very small (I mean it) tolerances. Today the system was released in a production environment, well after its components had been tested in isolation and several integration testings have taken place. I think I'll analyse thoroughly the testing process adopted in the building of the the accelerator to compare it with the software testing process, and I'm sure this will lead to interesting results. More on this to come.

As always, when dealing with things such as this, many opponents arised, concerned about the high risk involved with the experiments that could lead - they say - to the complete destruction of life on Earth (well, to say it all, of Earth itself).

A commission has been instituted by CERN to study all the possibile risks related to the use of LHC, but the results of their work still did not seem enough to alarmists.

Up to now, alarmists were wrong.

Thursday, September 4, 2008

Where's my CTRL+F?

I can't believe it... when I post a blog entry in Chrome the internal search (CTRL+F) brutally ignores all the content I'm writing...

Faster than light

Probably Superman was carrying it...

Teach Yourself Programming in Ten Years part II

Ok, back to the comments on the recipe for programming success.

Know how long it takes your computer to execute an instruction, fetch a word from memory (with and without a cache miss), read consecutive words from disk, and seek to a new location on disk.

Unlunckily the great amount of resources brought us to forget the art of good programming. I know I might sound old fashioned, but I can remember more than a hell of a program running on a C64, on which only 38k were actually available, the remaining 26 being occupied by the operating system itself. Nowadays too many resources are wasted, nothing is optimized and a lot of programs are lousy. A word of caution: optimization should not be the first thing you look at, as you should first try to have an understandable and maintenable codebase, and you should really measure and optimize only when it's needed, but there's a limit for everything... Anyway, back to the subject of university, one of the exams I've seated (computer and network architecture) represents a good example of something I've really never used in a direct way but dramatically changed the way I look at software, as now I know how the underlying hardware works, and I know many programmers for which this statement doesn't hold true: e.g. you can see it from the way they write inner loops: if you know how words are stored in memory and in cache you'll chose the order which best fits the underlying physical system.

Get involved in a language standardization effort

mrghmr....

Have the good sense to get off the language standardization effort as quickly as possible.

Now this is more like it!

With all that in mind, its questionable how far you can get just by book learning.

Book learning is not enough. You must try, and try, and try. Well, better yet... Try not. Do, or do not, there is no try. And this comes from the wisdom of Master Yoda, so it should not be questioned :-) Nevertheless, IMHO books play a very important part, because they can start you up and serve as a reference, but there must be a "deliberate effort to improve", so you must bang your head on that wall: that's where my look comes from, it has nothing to do with my 15 years of rugby. And it is fundamental to share your experience with others: you have something to learn from them, they have something to learn from you.

About the three-part plan proposed by Fred Brooks: see the "Work on projects with other programmeres" part. When you work in a small firm with a small IT department it is very unlikely that there exist the conditions to follow the plan, at least inside the firm itself.

Wednesday, September 3, 2008

Teach Yourself Programming in Ten Years

Peter Norvig, Director of Research at Google, has published a very interesting article about the huge amount of IT-related books titled something like "Teach yourself XXX in Y days". Having read my share when I was younger, so much younger than today, I really agree with him, today more than ever.

"Day" is not the correct unit of measure when you talk about mastering something - as the article quotes, researches talk about ten years of effort: that's why you must (should) have fun with programming, because it will take you a huge amount of time. To get along with Mr. Sang Shin, you need passion.

Peter proposes a recipe for programming success, and I'd like to comment about it (I'll skip the parts on which I completely agree and I don't have anything else to add).

Program. The best kind of learning is learning by doing.

I'd like to stress the "deliberate efforts to improve" part: spending ten years programming does not necessarily mean you have ten years of experience, because you could as well count each day as the first one. I know many so-called experienced professionals who are in this situation, some of them because I caught them in the act. 

About the education: it is true that with a lot of work you could skip it, but university exposes you to a wide series of subjects, many of which might not look appealing at first glance (some of them not even after many glances), but it really pays off, as many things will come out useful later or help you to lay the foudations of your future professional growth. Moreover, you get exposed to the judgment of many experts on the field, talented people who can counsel and guide you. It's not that easy when you get to your workplace, where many people only look after their own interests (hey it just so happens that not everybody works at Google!). Unluckily (or luckily, it depends...), there's no direct relation between academic achievements and salary (sigh!). 

Work on projects with other programmers.

That sounds easy. Unluckily, sometimes you just have to rely on yourself, or on a very few other people: many customers of ours have just one to three developers, one of which is tipically a "legacy programmer". But it is a great advice, and this is where external groups (e.g. JUGs or XPUGs) come in use.

Work on projects after other programmers.

Far too easy not to follow this one. Browncode represents a huge percentage of a programmer's job, so everybody should know what we're talking about. But crap is not always the best source for knowledge, so it is also important to study and try good code - there's plenty of good open source projects out there, and if you have the time getting involved in one of them you get a very good opportunity to learn a lot.

Learn at least a half dozen programming languages.

IMHO that's hardly feasible or doesn't have the right ROI, particularly in small realities such as ours. My idea is based on the fact that a language that does not need a shift of paradigm is not worth studying (as quoted in the article) and on the necessity to optimize costs and resources. How much does it take to really understand and correctly use a functional language? is it worth the effort? In my particular case it is not, at least for the time being. Should there arise a different need, things would obviously be different. So, I would translate into "have a look at not less than half a dozen programming languages, so that you can select the one that best fits your needs on a case by case basis".

Sorry really have to go... to be continued!

Google Chrome

Google has just released the beta version of the Chrome Browser, which I've obviously downloaded and installed; pity there only exists the version for Windows Vista and XP... at least it's open source, so that everyone can get in on the act.

The Google team has prepared a comic book, which you can find here, in which they present the technical choices and the design of the browser.

The first and overall impression is quite good, it seems faster than Firefox but still occupies a lot of memory, even if (and this is good news) each tab has its own process.

The idea of the first page with the nine most visited pages is very interesting, as the shortcuts to the applications; I have got used to Firefox categories and I'm missing them, even if Chrome provides the so-called "omnibox" with increased functionalities. I will explore the different features and maybe decide to change my default... we shall see!

BTW I'm using Chrome to post this entry...

Monday, September 1, 2008

Always watch your steps

Back to work! A long time ago, in a galaxy not far away, one of my peers dropped a couple of the most important production tables in the most important application of our most important customer. I thought it would be a tough act to follow... till today, even if I was only working on small and relatively unimportant tables. So, when you are testing a system, ALWAYS double check which one you are working on.

Luckily, we believe in the three divinities of software: backup, backup and backup, so everything went back to normal unnoticed.

Wednesday, August 13, 2008

Wordle

Johnatan Feinberg, a Senior Software Engineer at IBM, has developed what he calls "a toy for generating word clouds", choosing from different layout schemas, fonts and colors. The name of the toy is Wordle; also check out the blog if you want to stay tuned.

These are two examples obtained parsing a slightly modified version of my cv. As the software is an applet and there's not a "save as image" option and the printscreen leads to low quality images, I printed the clouds using PDFCreator, then enlarged it and selected the content with the snapshot tool. The final step involved some cropping and resizing in Photoshop.


My next step will probabily be a Photoshop session to blend the clouds with one of my pictures to get a sort of visual cv, maybe this could contribute to the "wow this guy's a class act!" attitude during interviews :-)

Web 2.0

In this very popular video Michael Wesch, Assistant Professor of Cultural Anthropology at Kansas State University, explains his vision of Internet today.



And here's another nice video by the Commoncraft guys that explains RSS "in plain English"

Monday, August 11, 2008

Growing Object-Oriented Software

Steve Freeman and Nat Pryce are posting online parts of a book they're working on, called Growing Object-Oriented Software, Guided by Tests. Should anyone be interested in giving feedback, they provide a Yahoo discussion group.

Rise of the phoenix

The Spandau Ballet are today's background music of mine. Match them with a photography site and you never know what can come out...


I only pray that before I die
Just like a phoenix I will rise and fly
Tell me who's to blame
Oh, I'm a man, now I'm a man in chains

The quote comes from "Man in chains", in the "Through the Barricades" album. The picture actually is ordinary incense smoke colored on the computer; Graham Jeffery describes all the details here. If you are wondering why it makes me think of a rising phoenix I guess you'll have to consult a Rorschach inkblot test expert.

It's all about tact... more or less

How do you tell someone she's not helping? Well Ken Schwaber has a pretty straightforward way of doing it:


Thanks to Michael J. Vizdos for the cartoon (and all the interesting stuff you'll find on his site).

Friday, August 8, 2008

Why I hate Javascript

Basically because I don't know it... and I don't want to get aquainted with it!!! Maybe it is because I'm so accustomed to the Java language, maybe because I'm dumb, maybe for a combination of these and several other factors. Anyway, I'll post some tips and some scripts that, albeit very easy, drove me crazy simply because I couldn't find their right syntax.

If you need to create an object in Java you must have a particular class and call its constructor using the "new" keyword (Yes, we can also use a factory method, a creation method, the newInstance method of the class, or other stuff, let's not be pedantic):
public class MyObject {
private String attr1;
private int attr2;
public MyObject(String attr1, int attr2) {
this.attr1 = attr1;
this.attr2 = attr2;
}
public String toString() {
return attr1 + " " + attr2;
}
}

...
MyObject obj = new MyObject(myString, myInt);
System.out.println(obj.toString());
...
In Javascript you simply create an object and add properties and methods to it:
personObj = new Object();
personObj.firstname = "John";
personObj.lastname = "Doe";
personObj.age = 50;
personObj.eyecolor = "blue";
But the interesting thing comes with methods. If you want to invoke a method in Java it must exist as public (yes, also default, or protected for subclasses, you could use reflection, I'm simplyfing for simplicity's sake!) in a class assignable to the object. In Javascript you simply add it:
addressObj.myOwnMethod = myOwnMethod;
If you want to call that method you use the syntax
addressObj.myOwnMethod();
BTW, all semicolons at the end of the lines are optional, just to make things weirder. And what happens when you call a method? you are really calling a function defined elsewhere, something like
function myOwnMethod() {
...
}
If your function has parameters, its declaration would be something like
function myOwnMethod(par1, par2) {
...
}
and if you want to call it you use the syntax
myObject.myOwnMethod(par1, par2)
What if you want to hide the parameters of the function you call, e.g. you ask a shipment for its cost, which is calculated on the basis of some attributes of the shipment itself? In Java you simply ask it to the shipment instance:
double shipmentCost = myShipment.getCost()
In Javascript you do the same, but it works in a slightly different way (maybe that's not the only one, but it is the only one I managed to get working). You have a method in the object without parameters, as one would expect, you have a function without parameters, as one would NOT expect, that gets called from the object when you invoke its method and it uses the "this" keyword... The "this" in a function!!! and it does not refer to the function but to the object that invoked it! how counterintuitive!
...
// inside the definition of an object (if using a template=
// or simply after the instantiation of an object
myShipment.getShippingCost = getShippingCost
...

// outside the definition of the object
function getShippingCost() {
var cost = 0;
if (this.DestinationAddress == "Boston") {
cost = (this.ShippingType == "STD") ? 100 : 200;
} else if (this.DestinationAddress == "Seoul") {
cost = (this.ShippingType == "STD") ? 500 : 1000;
}
return cost;
}

...
// somewhere else...
myShipment.getShippingCost();
It just gives me a headache... it's such a juggling act trying to learn Ajax technologies while keeping your mental health...

A simple RegExp to validate e-mail

Paul Warren presents a very simple regular expression that can be used to validate any e-mail address; as everybody can easily see, it satisfies all the grammar described in RFC822.
(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\] \000-\031]
+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?
:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(
?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(
?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[
^\"\r\\]|\\.|(?:(?:\r\n)?[\t]))*"(?:(?:\r\n)?[ \t])*))*@(
?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:
(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\
r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(
?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\
r\n)?[ \t])*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?
:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\
]|\\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\
r\n)?[ \t])*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?
:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\
\]|\\.)*\](?:(?:\r\n)?[\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?
=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n
)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\]
\000-\031]+(?:(?:(?:\r\n)?[\t])+|\Z|(?=[\["()<>@,;:\\".\
[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:
(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?
:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\
\]|\\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(
?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)
?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:
[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(
?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()
<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\
["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[
\t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000
-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]
))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r
\n)?[ \t])*)|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r
\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\
\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)
?[ \t])*(?:(?:(?:[^()<>@,;:\\".\[\]\000-\031]+(?:(?:(?:\r
\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\
\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r
\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n
)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.
|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?
[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[
\t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;
:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<
>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])
*))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?
:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])
*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\
\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@
,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)
)*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[
([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?
[ \t])*(?:[^()<>@,;:\\".\[\]\000-\031]+(?:(?:(?:\r\n)?[ \
t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]
(?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()
<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"
(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:
\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?
:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".
\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:
\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:
\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:
(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[
\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])
*)(?:,\s*(?:(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\
n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\
n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|
(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[
\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \
t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]
(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:
\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*
))*|(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:
\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n) ?[ \t])
*(?:@(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\
\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@
,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)
)*(?:,@(?:(?:\r\n)?[\t])*(?:[^()<>@,;:\\".\[\] \000-\031]
+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[(
[^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[
\t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \
t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\]
(?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,
;:\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()
<>@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"
(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:
\\".\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\\".\[\]]))|"(?:[^\"\r\\]|\\.|(?:(?:\r\n)?[ \t]))*"(?
:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".
\[\] \000-\031]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:
\\".\[\]]))|\[([^\[\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*)(?:
\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\\".\[\] \000-\031]+(?:
(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\\".\[\]]))|\[([^\[
\]\r\\]|\\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])
*))*)?;\s*)