18 January, 2007

how to be an expert

kathy sierra has an excellent article on how to become an expert. here's a quote, that captures the essence of her post:


For the superior performer the goal isn't just repeating the same thing again and again but achieving higher levels of control over every aspect of their performance. That's why they don't find practice boring. Each practice session they are working on doing something better than they did the last time.

i've blogged about becoming a pro too; you can find the post here.

08 January, 2007

self correlating ports (and parallel processing)



the image above belongs to an orchestration i wrote to update a table with a list of currencies. the process is rather simple: all we have to do, is get the list of currencies we support (from the database), and then update the exchange rate.

to do this, i chose to use and extremely parallel method, in which every currency spins off its own thread, calls the service that contains current exchange quotes, and updates its value in the db.

what you don't see in the image above is the code that gets the list from the database and then instantiates a new orchestration for each currency. what you do see, is the part where the orchestrations (when they have finished their work) call back to signal that they have finished. after this, we send out an email notifying that we've updated all currencies.

doing this in biztalk is rather simple, since the functionality to asynchronously start orchestrations comes out of the box, and call backs are easily implement with self correlating ports. i like how biztalk makes this parallel process extremely simple.

if you wish to learn more about how to setup self corrlating ports, visit Stephen W. Thomas BizTalk Blog here for detailed instructions.

03 January, 2007

who's on your bus?

i once read an interview with jim collins (author of from good to great and built to last) where he said the most important factor in a succesful company is whther or not "the right people are on the bus". if you have the right people, everything else will fall into place... at least that is the theory. and my gut feeling is that the theory is right; people are not everything, but they are important enough where if you have to just pick one thing, you pick the right people.

i mention this because of an experience i had at work today:
i found a problem trying to begin a transaction in one of our live servers. before calling the dbas, i made sure i had a pretty good idea of what was going on... the problem only surfaced when trying to start a transaction from a client that was on a different domain.

i called in one of the dbas and described what was happening and asked for his help to solve the problem. i was polite when i brought the issue up, but our dba immediately became aggresive and blamed the problem on the client. i was confident that the problem was on the server, so i insisted he should at least take a look at it.

we went back and forth, arguing where the problem was, for at least 10 minutes; i finally had to show our dba i wasn't kidding, and in a somewhat threatening (firm, more than anything) tone told him that (1)what he was saying made no sense and he knew, and (2) what he needed to do to get proof that it was the server that wasn't working.

after going through the steps i asked to go through, he finally admitted it was the server that wasn't working. he also told me he had no idea on how to fix it (i don't blame him on this... from the research i did before i called him, it was apparent to me that the problem wasn't trivial) and would get back to me whenever he had found a solution. i immedately thanked him for his time and for committing to solving the issue.

after i hung up, i started thinking: why did it have to come to this? why is it so hard to work with the dbas? (it's not the first time i've had a experience like this, and i'm not the only one that has problems working with them). i thought: "we need the right people on that job, it's a key job. we nee the right people on the bus".

my manager congratulated me on how i handled the situation (he actually sat there listening the whole time because this was a high priority issue for us). after a few comments i told him i thought the hardest part about being a "techie" is not the technology, but working rather working and communicating effectively with others; i also told him most problems in software arise because of problems in these areas... and thus the importance of getting the right people on the bus.