Mikhail Arkhipov explains how to get a window office at Microsoft. Interesting - most organizations wouldn't have the guts to value years of service over organizational position.
Actually, valuing and rewarding people by years spent on the job has more sense to it than it sounds at first. But perhaps only if the organization gets quickly rid of nonproductive people?
Black hole projects versus teams with proper discipline - which one does your organization belong to?
IE team recently announced Longhorn's deep support for RSS. Although RSS is already getting rather common - and will be even more so by the time Longhorn hits the markets - Microsoft's move will energize the technology further. I think most of us ("us" meaning the loosely defined group of advanced Internet technology evangelists) agree it's a good move.
The point where the opinions split are Microsoft's additions to the spec, i.e. Simple List Extensions. Willie Wilson's comment on IEBlog about sums it up: "I'm really saddened that Microsoft has decided to defy standards yet again and alter RSS feeds so that they won't work in other news readers. You've done ruined Javascript; why must you go in and infect other products as well? It's like you guys are poison, destroying the veins of the Internet. Your IE-only hacks are getting old."
A more balanced view is provided by Tristan Louis. I believe the big picture is well described there: It may be questionable whether or not Microsoft's desires could've been better achieved by, for example, using Atom instead of RSS. However, so far I've seen no technically competent person blame Microsoft for the extension: it's made rather nicely in the spirit of RSS and XML namespaces. Any software development group could've done the same - now people fear market power, not the technology themselves.
Time will tell whether the SLE additions to RSS will prove useful. At the very least, comparisons to Microsoft's HTML and Javascript extensions should be avoided until we've seen some of the technology in practice. Unlike the web stuff in 90s, this one is a truly modular addition leveraging the best parts of XML technology.
What's more, Microsoft has provided a rather surprising licensing model: The Creative Commons Attribution-ShareAlike license. Read Lawrence Lessig's blog entry on this one. The commentary is particularly delightful. Paranoia rules the day?
I get lots of spam all the time. Most of it tries to sell me medication for issues I don't have. But today, I got a message I didn't even realize to be spam at first. It looked just like another product announcement - .NET components this time - coming from PureComponents. However, the alarming thing is this: I never ever register anywhere with the address the mail was sent to (it's only used in newsgroups). Neither have I ever even heard of PureComponents before. True enough, the message doesn't say "You're getting this because you have subscribed..." blahblah, the usual stuff with legit subscribed product offerings. It simply offers an unsubscription link.
I'm not even going to bother using it. I'll just delete the mail outright. Any company sending mail to addresses collected from newsgroups will not have my (or my employer's or any client's as far as I am concerned) money totally regardless of the quality of their products.
So why is this incident worth a post? It was one of the first spam messages related to programming; one of the first ones that actually could have made me buy something. I hope it won't get more common. It shouldn't; software developers are a critical bunch of nerds. Sending unsolicited mail to them is... well, short-sighted. At best.
I usually don't bother posting links to The Daily WTF, no matter how ridiculous some of the postings are. But this time, I have to. The posting describes an application that passes SQL strings from one ASP page to another - using a cookie. Even by the normal WTF standards, this is... ugly.
Without starting on lengthy rants about all the possible problems with the mentioned approach, I'll make one general point. During the past two weeks I've reviewed quite a lot of code, both from in and outside our organization. I've seen both brilliant examples of truly responsible codership and totally horrifying lumps of code strung together by very fragile APIs. It's been a very demanding experience - with both patience and understanding being stretched to their limits. But it did come with lots of prizes in terms of understanding and knowledge.
This has to be the gem of all my learning: If your organization doesn't have a policy for frequent code reviews by colleagues, establish one. Most of the really horrible solutions simply stem from leaving bad code alone for too long. It doesn't matter if the reviewer isn't the Einstein of the coding world - the most important thing is having another human being evaluate the readability of the code. That, and feedback. DO IT.
Google has announced Google sitemaps, a service that allows webmasters to craft XML sitemaps to notify Google about their site structure. Another interesting move from Google. Life certainly isn't getting boring.
Why is this better than crawling? Well first, it allows the webmasters to suggest indexing intervals and notify Google about new content. That by itself allows huge enhancements in retrieval efficiency. Second, it generates a framework for passing more metadata to the search engines - in this case, Google provides the possibility for using an intra-site priority variable, allowing webmasters to further refine the indexing speed and frequency of their site (note: it doesn't allow you to affect your position on the search results). And third, it makes indexing of dynamically generated pages considerably easier.
An XML sitemap is not really a new idea - for example, Whidbey has internal support for it for the purpose of breadcrumb path and navigation menu generation - but Google's strike was well-timed. The Sitemaps technology is early enough to make people actually think about generating sitemaps for it, thus perhaps creating the de facto standard for sitemapping. Well, luckily Whidbey's sitemap reader is constructed with a provider architecture, so making the new ASP.NET controls talk to Google XML is a snap.
It'll be very interesting to see how the sitemapping stuff picks up. It won't be easy for large sites with loads of dynamic content - the task of constructing the site map is huge, and keeping it up to date may require considerable changes in existing publishing systems. On the other hand, if Google uses the technology as promised (and I believe they'll do - a good track record helps here), it'll certainly be worth serious consideration.
The standard mantra for many programming evangelists is "use design patterns, they combine the wisdom of years for you to use" (in case you don't know what patterns are, read the Wikipedia article). Some of my recent adventures into the patterns world have convinced me that while patterns do contain much wisdom, they are not the solution to the average programmer. Why is this?
Design patterns help you model your real world object model into OO terms and avoid pitfalls such as tight coupling and unmaintainable code. That's great. But the problem? Proper use of the patterns requires so much preknowledge that the average programmer very easily stumbles on them. Certainly you can factor your real world application into some nifty classes, apply some Bridges, create Flyweights and throw in some Proxies for good measure. And then? Perhaps your code now adheres to some patterns - but it's not too likely to be much more maintainable: patterns are just new ways to play with toys you didn't understand properly in the beginning anyway.
Patterns come from the world of building architecture where they were considered extremely useful. Use of patterns in an all-professional environment is quite different from the current programming world. You can easily get a B.Sc level examination without actually knowing how to design an OO system. Now this is the problem we should be addressing!
Despite everything above, I'm by no means saying patterns are evil. Common terminology is good, and they do provide a valuable canonicalization for certain common phenomena in the software engineering field. However, they do remind me of software development processes: Once you're competent enough to really understand them, you realize you've arrived at most of the conclusions yourself.