May 3rd, 2009
Yesterday I upgraded my main system (a Dell Studio XPS Desktop 435MT with an Intel Core i7, 6Gb of memory and an ATI HD 4850 running Vista64) to the Release Candidate of Windows 7 Ultimate. And I must say that it was a smooth ride, a bit long but smooth.
Including making a backup and uninstalling some programs that the installer did not like (Daemon Tools, VMWare, Virtual PC and the ATI display driver) the entire process took about three hours. Two of those were for the actual upgrade.
So after that long wait I wanted to see what I got so I rand the Windows Experience Index. With Vista I got a total of 5.9 with all the components being 5.9 and in Vista this was the absolute maximum. With Windows 7 the bar was raised to 7.9 so I was kind of curious what the bottleneck would be. Looks like the hard disk is the weakest link but I can live with that.
So far I’m pretty pleased with Windows 7. The user experience is pretty smooth and polished. Every program I’ve tried just works as it should. Currently I have only one real problem with Windows 7 and that is the way that Libraries work.
Libraries are meant to abstract away from the fact that files can be in several locations. You can add more locations with the library to expose all music for instance in one place.
The only problem with that is that the location has to be indexed.
This is a problem for me (and a host of other people) because all my media are on a NAS and cannot be indexed. Luckily I did find a way around that but that is kind of a hack. In my personal opinion Microsoft did not think this one all the way through and I’m hoping we’ll see some kind of patch for this in the future.
But like I said, this is my only problem with Win7 thus far. It is fast, smooth, polished and (mostly) a joy to work with.
Hasta la vista: Vista!
April 19th, 2009
In the past week Microsoft released a resource kit for developing Web 2.0 applications called Kobe. I found out about it because Oren Eini and Karl Seguin were writing about it. This is what the official site says about Kobe:
Project Kobe is a getting started resource kit for planning, architecting, and implementing Web 2.0 applications and services using the Microsoft Platform. This resource kit is targeted toward technology decision makers, hands-on solution architects, development managers, and developers in the aspiring web startups community and in enterprises and businesses looking to invest in new Web 2.0 application/service development projects.
I don’t know about you but to me this spells guidance and reference application. I therefore expect to find a high quality sample which will teach me the best way to architect, design and build a Web 2.0 application. It appears that is not the case since there is a lot of writing going on about the quality of Kobe.
This spiked my interest but when i tried to download it myself I found out that it got pulled because of ‘community feedback’.
Searching the MSDN site for Kobe also turned up a response from the team:
The sample app is not a "reference application" in the context of code completeness. A "sample app" and a "reference app" are quite different in the context of code completeness, and we do not claim Kobe to be a reference app in this context.
If you are as big as Microsoft is then everything you do is under close scrutiny. Also everything that gets released is looked at for guidance since you’re supposed to lead the field. This means the quality of everything that gets released has to be up to par or even exceptional.
Next time ask the community for feedback before it is released and not just throw it out there because whatever is wrong with it, the community will find it and write about it. The former is smart, cool and very Web 2.0 while the latter is just plain silly.
April 8th, 2009
This past week I went to an internal seminar about code quality. The senior consultant that was presenting made an interesting statement:
The software architect is responsible for the quality of a project.
That got me thinking… Am I? Well maybe I am. A lot of the things I talk and worry about on a project are actually quality indicators according to ISO 9126. Does this also mean I get to decide what the quality level should be? Not really. Let me try to clarify that with an analogy.
Compare the ordering of a custom piece of software to buying a car. What brand of car does the client buy? Since cars have implicit quality levels the selection of a brand tells you something about the quality the client is looking for. Does he buy a Fiat or a Ferrari? The answer of course is: It depends.
If the client only needs to get from A to B then any brand will do so he might just as well buy the cheapest. If he needs to do a endurance race like the 24 hours of Le Mans then it is more important what brand he selects because of those implicit quality levels.
So we need to find out about the needs of the client. Does the software only serve some short lived purpose or will it live for decades? Will it be used by a lot of users or just a few? Will it be used every day or sporadically? Is it ok if the software makes mistakes or should these be prevented at all costs? The answers to those questions give an indication to the kind of quality the client is looking for.
If that was it the world would still be simple and possibly quite unsafe. There are also rules for the minimum quality level a car is allowed to have. Those are mostly baked into law by countries. Renault can only sell cars in the Netherlands if these have at least a minimum level of security features and the government wants that certified by a trusted auditing body (NCAP does that for most Europe countries).
In our companies there are also laws to follow. Our DBAs want stored procedures, no triggers and we must not use the systems stored procedures (the stored procedures starting with sp_ in Microsoft SQL server). Our internal hosting provider tells us that our folder structure should look like this, we have log to the servers event log and must not use more than ye megabytes of memory or we will be shut down. To top it all off there are also other projects and existing systems to take into consideration. Somewhere between all those constraints is where we as software architects make the choices that satisfy all parties.
In order to be effective as a software architect you have to know what all the laws in your company are. You have to know what the client wants. You have to know what all the other projects need. And finally you have to tell everybody participating in the project which choices were made and remind them occasionally so they can keep those choices in mind while building.
Does this make the software architect responsible for the quality in a project? We may not always be responsible for all the constraints in place but we sure are responsible for creating a solution that satisfies all of them.
April 5th, 2009
Recently I have been reading in 97 Things Every Software Architect Should Know. It is filled with 97 little nuggets of wisdom that you as a software architect should know. Each piece is described in a pleasant two-page format which helps to keep the information concise and easily congestible.
Take for example There Is No One-Size-Fits-All Solution. In it Randy Stafford describes that you as a Software Architects should strive to know the contextual sense in which you work. When you do this, the solutions you pick will be better.
Maybe less obvious are You’re Negotiating More Often Than You Think by Michal Nygard or Chances Are, You Biggest Problem Isn’t Technical by Mark Ramm which both really drive the point home that our industry is as much about people as it is about computers. While the point Udi Dahan makes in Stand Up! just makes you think about your non verbal communication.
This book is a pleasant read with a lot of useful little tidbits. Consider picking it up the next time you’re in the bookstore.
April 3rd, 2009
It took me more time then I would have liked but my domain is finally available. I had to wrestle blogger for the right to use https://www.theaspiringarchitect.net/.
After buying the domain via blogger itself instead of going to my normal provider I was expecting all things to go smoothly but I was wrong. It turns out that there are a lot of things that can go very wrong this way. Researching my way through the detailed and very complete site of The Real Blogger Status I finally found my culprit and now my domain is working.
Thank you guys, you made my day.
March 27th, 2009
Today I decided to install Windows 7 build 7057 on my Asus EEE PC 901. I downloaded the ISO (which I will not get into, you can do that yourself) and remembered that the EEE PC does not have an optical drive so I need some kind of USB device to get this going.
My trusted 4Gb thumb drive can do the job but it needs to be bootable which is a breeze if you follow the instructions. Then I unpacked the ISO and copied all the files onto the drive and stuck it into the EEE PC. Booted from the thumb and started the setup.
It takes about 45 to 60 minutes to install while I watch Scott Hanselman do his MIX09 talk on ASP.NET MVC and NerdDinner.com (really worth watching). After this it tries to load for the first time and gives me a black screen. I have read about this before so I know that this is some kind of glitch. I have to press the power button to put the system to sleep and then press it again to wake it back up. Now I can create my account, enter the product key and select my wireless network. At this point the system starts finalizing and logs me in for the first time.
After a couple of minutes I am greeting by the logon sound and see my Windows 7 desktop for the first time. I’m actually pretty amazed to that its running Aero without installing any additional drivers!
After playing with it for a couple of hours I’m pretty pleased with the result. The performance is pretty good considering all the bells and whistles are on. I still need to get the Bluetooth connection with my N95 going but I’ll try that some other time.
How are your experiences with Windows 7?
March 21st, 2009
This is my very first blog post and I’m a bit apprehensive. Is this a good idea? Can I do this? It is kind of similar to the road I’m taking to becoming an Architect. What kind of architect? Well that’s a good question. In January 2008 I left the lead developer role behind and currently I’m working towards becoming a good solution architect. I find the journey interesting and rewarding although at times challenging. On this blog I will try to share with you my insights as well as my moments of success or failure.
I hope we will both learn from it.