September 2004 - Posts
While on the very short term, this makes me laugh,after thinking about it for 2 seconds for the long term,it makes me cry.
But this cartoon, only summarizes brilliantly, what this one tries to hide, under the guise of agility, smartness, flexibility,efficiency and something that is completely painless.
At first glance, it seems like a nice idea,and they even have the right arguments, like employees retention, challenges and high value positions.
Since when treating people as commodities worked ? (apart from the fantastic numbers on CFO spreadsheets and Wall Street amazing quarter figure cheering?)
The only thing, missing from this article is the vindication of multitasking as the alchemist for efficiency.
They have this nice quote:
"In the end, Poppell says, truly elastic IT organizations are easy to distinguish from those that are merely plugging holes. "The companies that are doing better understand the business drivers behind IT," he says. They have a formal IT plan supported by an infrastructure plan that looks ahead three years. This, he says, allows businesses to create a "formal IT workforce plan that asks, 'Do we have the capability to complete our various projects?' "
Which is perfect in theory, but seems something i've empirically found to be the reverse. Most business that i've seen classfying themselves as elastic, are the ones that keep their time plugging their holes. <sarcastic>Ironic, maybe them have been right all alone</sarcastic>.
But then again, i'm from the country of the secular Desenrascanço, like the frog and the scorpion, it's on our nature.
Funny times ahead, indeed. :-(
In order to travel abroad to attend this, i need a national identity card, oopps it seems mine has expired last february, so today i headed to one of the citizen's "shop" (a kind of government, public offices and utilities companies super mall :-)) in order to renew mine. Although things have improved (when i requested my first identity card to attend primary school (when you reach 6 years) the process took only two days, just to request it)
I know i was facing some waiting time, so i printed the newly released whitepaper An Introduction to the Web Services Architecture and Its Specifications and headed to the shop. I only waited an hour, so hadn't time to finish it, but i really liked what i've read so far. Highly recommended.
Jorgen Thelin's announces two new WS-* specifications (Ws-Enumeration and Ws-Transfer), is this really necessary or just more wood to the RESTfarians pundits?
What happened to Don Box's fewer specs more apps :-)
WS-specs coalition gang is on a roll, they already announced that although it's the journey that matters not the destination, they will most likely stop when WS-BoilTheOcean is finished. For now all efforts are being put on the definition of Ws-KitchenSink
Disclaimer: I haven't read the specs, i just like to shoot first and ask questions later (who doesn't? :-)).
Speaking of Don Box, he has a similar post and called it WS-Hammer, and says something about the 4 stages people go through when they have an third degree encounter with WS-transfer. Hummm don't get it yet, guess i'm still on stage one. (stage 1,2 and 3 seems pro-REST and stage 4 anti-REST). Maybe i can understand after i rest a while (no pun intended, have a nice weekend).
[Update: Seems it didn't took that long, Mark Baker a well know RESTfarian, seems to like WS-Transfer]
[Update: Harry Pierson, seems to be stuck <gr&d> in phase I, but at first sight seems to identify WS-Transfer as a WS-CRUD]
[Update Here is an opinion on WS-Transfer from Jeff Schneider]
[Update: Two not very nice opinions about how WS stack is evolving, one from Sean McGrath and another from Tim Bray]
Nikhilk relaunched an old debate last week. Data-binding to public fields... yes or no?, in principle i agree with the decision of not binding to public fields, but as Otto von Bismarck once said:
"When a man says he approves of something in principle, it means he hasn't the slightest intention of putting it into practice."
I wouldn't go so far, but a nice quote allways looks good. :-)
When all you want is to show one of two fields, it's easy to agree with Scott, it seems an awfull trouble to go, just to show some fields (i already felt that pain, and it was not one or two fields, but more on that later).
But properties are the way go, more clean and more OO.
My gripe is with WS proxy generator, i want to bind to public fields, because the proxy generator only generates public fields, which is a royal pain in the a**.
Picture an application that is written with SOA principles, dozens and dozens of exposed services. Best practices applied, no internal data is exposed. All data that is exposed, through Data Transfer Objects (DTO) generated with Assemblers.
Now imagine that you have another application, that has very little logic on it's own, and all it has to do is to drive the UI to the previously refered application through service calls. Writing the assemblers and the DTO's is already a large task by itself, by not allowing us to bind to the proxies, i would estimate that with the added effort to "manually bind", the overall effort is largely inflated.. (This has been my pain for the last months).
By not generating properties for the proxy, we have some choices:
- Write some helpers with similar syntax and semantics of DataBind.Eval, but that works with reflection in order to work with public fields.
- Write service agents, that transform the proxies into classes (DTO's or Domain Objects) that are are first class .NET citizens to be databinded. This seems not only silly, but would be compared to killing flies with a cannon.
- Extend the proxy generator, so that properties are generated. (not possible until whidbey is released).
- Write your own proxy generator (i actually considered this), but this was an effort that hardly could be justified.
- Write a proxy for the proxy,that during runtime would fake properties for the proxy. (perhaps using this, this would robably fall in the categories of nice hacks and probably in the category of alien artifacts, but it certainly would be a stupid thing (TM),and a big waste of efforts)
Looking in retrospective, i can only cry with all the hours i've wasted by the fact that public fields are not bindable, only because ws proxy generator doesn't generate proxies with propertyes. Anyway 2 wrongs don't make a right. What i really want, is proxies with properties. Fortunately whidbey proxy generator will generate properties, and in the meanwhile we seem to have 2 choices:
While this wouldn't be a problem for me, it has some logistical headaches on it's own. This would cause a non standard dev environment, which is something i can't afford for this probject. Oh well, "manual binding" will continue, as well as swearing and cursing the guy who made the decision not to generate properties. :-)
Sorry for not writing anything for so long,but i've beeb in crunch mode for quite some time (i hope to be done be the end of the month). I already have planned a post, hope to have a little time to write it soon. Stay tuned.
The posting title is a literal translation from Portuguese, i don't know when translated to english it doesn't lose it's semantic. (the bottom line, is there are people who work in the real sense of the word, versus people who merely appear at the job site and stay there until it's time to go home). Anyway i'm not going to write a postulate on the subject, i merely want to give you a pointer to this great post from Rockford Lhotka. I'm just pointing it, not only because it's a great post, but as a future reference for myself (as a motivator, as a reminder, as a justification and for helping in future decisions)
I have 3 gmail invitations to give (i wonder if there are actually 3 people who read me :-)). Contact me, and it's yours.
More Posts