There was a recent report about the US “falling behind” other countries in terms of broadband use. This has sparked a lot of interest and made a lot of people state the federal government needs to do more to make broadband more accessible for more Americans. This is yet another case of well-meaning people supporting a very bad idea. Here is a good rebuttal of the idea, but I have my own reasons for being against this.
One of the main ideas behind national broadband is that broadband is similar to public utilities such as electricity and telephone service. This will be the first idea I will debunk. The biggest problem with this idea is that there are exact functional equivalents to broadband – name dial-up service, but there is nothing similar for electricity or telephone service. Certainly another big problem is that it’s hard to compare web surfing and email to having your lights turned on or being able to call 911 in an emergency. It’s just not an accurate comparison, at least not yet.
Another big problem with nationalizing broadband access is that internet access in general is still an emerging technology. Do you know anybody who has had broadband at their home for more than ten years? Other technologies are emerging that could provide better service for less price, such as broadband over power lines and Wi-Fi/WiMax. These new technologies will not have a chance if they have to “compete” against government backed broadband (or government backed broadband providers.) Competition between existing broadband and emerging technologies will certainly lower costs for all and provide a test to see which technology is best. And of course there are probably other technologies that are even better that we haven’t heard of yet. These too would be stifled by a government backed broadband service.
So those are the more practical arguments against national broadband, but for me they aren’t even necessary. The big problem with national broadband is that eliminates choice. As soon as taxpayer money is being used to provide/subsidize broadband, then we’ve all had a choice of whether to use broadband or not taken away from us. Now I know there are countless other things like this already, but that’s no excuse to willingly give up another freedom.
Ultimately national broadband will mean yet another government agency to administer and manage either the actual the service, or the distribution of funds to subsidized providers. This only begs for more corruption and government backed monopolies. That’s always bad, but especially bad when it comes to a fast changing technology. You see, monopolies don’t like change and only have an interest in keeping the status quo.
Tuesday, August 23, 2005
Saturday, August 13, 2005
Beta Stuff from Microsoft
A lot of people like to criticize Microsoft, and I must admit that I enjoy partaking in that, too. However, I use Windows just like everybody else. I've been an XP user since summer 2001, when I installed the beta. I recently installed their two latest beta offerings, Windows Vista (Longhorn) and IE 7.
First off, I installed IE 7 on to my XP box at home. I'm actually composed part of this post on IE 7. First the good... I like the UI. I haven't used IE 6 much for the last three years or so, but I had its UI stripped down very similarly to IE 7. Of course it will draw comparison to Firefox. It is definitely weird where they put the menu bar. The new tab button looks odd, but I think it's actually pretty intuitive, especially if somebody has not used Firefox or Opera before, as will be the case for most IE 7 users. Ok, now for the bad... It is slow and a memory hog. It tried some JavaScript and dhtml benchmark sites, and it is much slower than IE 6 and Firefox. Opera is still the king in terms of speed of course. It is also uses a lot more memory than IE 6 or Firefox, especially when you start opening up multiple tabs or you hit a site with lots of CSS or DHTML. Finally, it is well known that IE 7 does not and will not pass the ACID2 test. That doesn't bother me as much as it might others, since neither Firefox or Opera pass it either. Also it should be noted that Microsoft generally tends to introduce features first, then optimize performance later on their beta type releases. This is the right way to engineer software, but it was still surprising to see the performance of IE 7.
Now on to the bigger fish, Windows Vista a.k.a. Longhorn. I created a small partitition on my XP machine to install Vista and had no problems with the install. The installer is much simplified, though it is still a very long procedure. Since this is an entire operating system to consider, let's break things down:
UI. I had heard a lot about the revolutionary new graphics and UI in Longhorn. I did not see it in Vista though. I've also heard that some UI elements are disabled if your graphics card is not beefy enough, but if that was the case for me then it never indicated this. My graphics card (Nvidia GeForce Ti 4400) is pretty decent, though a couple of years old. I think 128 MB of dedicated video ram and DirectX 9 support should be enough for the operating system, so I'm going to assume that nothing was turned off. Given that, the UI is disappointing. It's relatively clean, but the grey/silver windows are just ugly. I don't mind that there is less chrome, just don't like the look of the new chrome.
Windows Explorer. I give high marks to Windows Explorer, though some of its toolbar items can be confusing. It's easy to accidentally specify some kind of sort on a set of files that could take a long time. This does not cause the whole system to lock up though, it just makes the window you were looking at lock up for a few minutes. I have to say that it really reminded me of Finder...
Security. Windows Vista makes lower-powered users the default, or at least its supposed to. The beta simply logs you in as the administrator, but you can create limited users pretty easily. The new authentication mode allows for you to do everything as this lower powered user and simply have Windows prompt you for administrator password when needed. In other words, Windows has finally added sudo. This is done exactly how Apple does it on OSX, so it's pretty good. I haven't encountered any bugs with this, though I have heard of others that did. Otherwise, security is much the same as in XP-SP2.
Compatibility. As expected, I got to encounter to some hardware issues with Vista. It wasn't too bad though. My wireless PCI card was initially not recognized so I had to install its driver. The driver installed nicely, but the config tool supplied by the vendor (Belkin) did not work and would crash immediately when you would try to launch it. I was able to get Windows to connect to my home network, but it's connection was much more unstable than it is on XP where I use the vendor config tool. Otherwise, things seemed ok. I was able to install and run Java, as well as Tomcat and Eclipse. I was also able to install iTunes and burn CDs, and plugin my digital camera to import pictures.
Performance. Like IE 7, performance stinks on Vista so far. It boots/restarts very fast, but file management is much slower (and that's without anti-virus software...) and application performance is noticeably slower. This was a little noticeable on stuff like code compilation but much worse on something like Photoshop image filtering.
Other Stuff. I wanted to try the integrated search (the current MSN desktop search I believe) but it has been very slow in indexing. Of course I don't leave it running overnight, since I normally stay booted in XP. I did have good experiences with MSN desktop search when I tried it in the past. I was not surprised to see the desktop search built in to the start menu, though I expected there to be options for desktop vs. web searches.
A lot of people like to criticize Microsoft, and I must admit that I enjoy partaking in that, too. However, I use Windows just like everybody else. I've been an XP user since summer 2001, when I installed the beta. I recently installed their two latest beta offerings, Windows Vista (Longhorn) and IE 7.
First off, I installed IE 7 on to my XP box at home. I'm actually composed part of this post on IE 7. First the good... I like the UI. I haven't used IE 6 much for the last three years or so, but I had its UI stripped down very similarly to IE 7. Of course it will draw comparison to Firefox. It is definitely weird where they put the menu bar. The new tab button looks odd, but I think it's actually pretty intuitive, especially if somebody has not used Firefox or Opera before, as will be the case for most IE 7 users. Ok, now for the bad... It is slow and a memory hog. It tried some JavaScript and dhtml benchmark sites, and it is much slower than IE 6 and Firefox. Opera is still the king in terms of speed of course. It is also uses a lot more memory than IE 6 or Firefox, especially when you start opening up multiple tabs or you hit a site with lots of CSS or DHTML. Finally, it is well known that IE 7 does not and will not pass the ACID2 test. That doesn't bother me as much as it might others, since neither Firefox or Opera pass it either. Also it should be noted that Microsoft generally tends to introduce features first, then optimize performance later on their beta type releases. This is the right way to engineer software, but it was still surprising to see the performance of IE 7.
Now on to the bigger fish, Windows Vista a.k.a. Longhorn. I created a small partitition on my XP machine to install Vista and had no problems with the install. The installer is much simplified, though it is still a very long procedure. Since this is an entire operating system to consider, let's break things down:
UI. I had heard a lot about the revolutionary new graphics and UI in Longhorn. I did not see it in Vista though. I've also heard that some UI elements are disabled if your graphics card is not beefy enough, but if that was the case for me then it never indicated this. My graphics card (Nvidia GeForce Ti 4400) is pretty decent, though a couple of years old. I think 128 MB of dedicated video ram and DirectX 9 support should be enough for the operating system, so I'm going to assume that nothing was turned off. Given that, the UI is disappointing. It's relatively clean, but the grey/silver windows are just ugly. I don't mind that there is less chrome, just don't like the look of the new chrome.
Windows Explorer. I give high marks to Windows Explorer, though some of its toolbar items can be confusing. It's easy to accidentally specify some kind of sort on a set of files that could take a long time. This does not cause the whole system to lock up though, it just makes the window you were looking at lock up for a few minutes. I have to say that it really reminded me of Finder...
Security. Windows Vista makes lower-powered users the default, or at least its supposed to. The beta simply logs you in as the administrator, but you can create limited users pretty easily. The new authentication mode allows for you to do everything as this lower powered user and simply have Windows prompt you for administrator password when needed. In other words, Windows has finally added sudo. This is done exactly how Apple does it on OSX, so it's pretty good. I haven't encountered any bugs with this, though I have heard of others that did. Otherwise, security is much the same as in XP-SP2.
Compatibility. As expected, I got to encounter to some hardware issues with Vista. It wasn't too bad though. My wireless PCI card was initially not recognized so I had to install its driver. The driver installed nicely, but the config tool supplied by the vendor (Belkin) did not work and would crash immediately when you would try to launch it. I was able to get Windows to connect to my home network, but it's connection was much more unstable than it is on XP where I use the vendor config tool. Otherwise, things seemed ok. I was able to install and run Java, as well as Tomcat and Eclipse. I was also able to install iTunes and burn CDs, and plugin my digital camera to import pictures.
Performance. Like IE 7, performance stinks on Vista so far. It boots/restarts very fast, but file management is much slower (and that's without anti-virus software...) and application performance is noticeably slower. This was a little noticeable on stuff like code compilation but much worse on something like Photoshop image filtering.
Other Stuff. I wanted to try the integrated search (the current MSN desktop search I believe) but it has been very slow in indexing. Of course I don't leave it running overnight, since I normally stay booted in XP. I did have good experiences with MSN desktop search when I tried it in the past. I was not surprised to see the desktop search built in to the start menu, though I expected there to be options for desktop vs. web searches.
Tuesday, August 02, 2005
Spring
I've been doing a lot of work lately with the Spring Framework. I'm still a little undecided about dependency injection as a way to implement inversion of control. Certainly IoC is good in principle. Dependency injection can make for some pretty clean code. That's all well and good, but if that was all that Spring promised then there wouldn't be such buzz around it. The bigger thing that IoC in general and Spring in particular promise is to allow for more portable and reusable software components. This is The Holy Grail of software (or at least of object oriented programming.) However, simply declaring your dependencies and allowing your container to resolve those dependencies does not guarantee reusable software. Another pre-requisite is that all the dependencies resolve to things that are also reusable. For example, I could have controllers that declare a dependency to some BigBadService class. That class must have all of its dependencies declared, and they need to resolve to interfaces (or to some other class that in turn has its dependencies resolve to interfaces, etc.) So Spring could definitely be used to simply clean up some code, but it takes a lot more than just that to really reap benefits from Spring.
Enough about that, I wanted to talk about some of Spring's features. I really like it's implementation of dependency injection. I am among those people out there who gets annoyed with too many and overly complex XML configuration files. There are definitely frameworks that verge on having "xmlscript" as a secondary language. Spring is a little guilty of this. Their configuration files can get pretty ugly, but that usually indicates a very complex application. They can be pretty simple to start. For pure dependency injection, they are very simple and clean. It's when you start adding others things like transaction management and web flow that things get ugly. I definitely think that transaction management should be done through annotations, a la EJB 3.0. Configuring controllers is always somewhat complex. The legacy of the original servlet spec is going to push a lot of this complexity into ugly xml files, so I don't totally blame Spring for that.
Of course dependency injection is just one of the many features of Spring. I haven't tried them all yet, but I'll describe a couple. First, it's previously mentioned transaction management is pretty solid. I used the DAO+Hibernate modules for this. The one thing I didn't like was that it was a little tricky to declare transactions for a class that I did NOT want to Spring to manage the creation of. I had a class that I wanted created by a factory. Spring managed the creation of the factory. Since I had a factory, I did not need it to manage the creation of the objects created by that factory. However, I wanted those object to be transactional. So I had to have it manage the creation of those objects, though I was able to tell it to use the factory. I felt like I was jumping through a hoop here. Otherwise, the Hibernate integration was very easy and well done.
The other module I used was Spring MVC. When I read the documentation on this, it really seemed like a nice step forward from other MVC incarnations. Of course, I'm not actually a big fan of MVC. I think it encourages a lot of coupling between presentation and data. This is especially bad given that the motivation for MVC is a separation of these things. I worked on a project once where we had a nice architecture that involved session beans that exposed XML only. Our servlets then applied XSLT. The motivation was that we needed to expose the exact some business logic but to many different user interfaces. The big problem with this kind of architecture was that the XSLT became incredibly complex. That's where the biggest advantage of using an MVC framework comes from, at least to me. It handles data-binding (and related things like validation messages) nicely.
Back to Spring MVC... It is very easy to get started with, but also very easy to start having problems with. The reason is its flexibility. There are so many options, and many of them are designed to have you write less code. Whenever you write less code that means the container is doing more for you. The combination of lots of options + lots of "invisible" container services can cause a lot of confusion and unexpected behavior. Fortunately it didn't take me too long to sort through the different options and understand them well. The Javadocs were great for this, much better than any of the tutorials/quick-starts out there. Once you understand how each controller-type works, the associated options are obvious. I like the command objects in the framework. They encourage abstraction and less coupling between business objects and the UI. Of course it would be easy to abuse this and basically make your business objects the same as your command objects.
All in all, I'm very pleased with Spring. There are certainly many more features that I have not explored on it. Its web flow particularly interests me. I think its IoC implementation is nice, and both of its dao/transaction packages and MVC packages really help the developer to write less code while not burdening him with arduous configuration.
I've been doing a lot of work lately with the Spring Framework. I'm still a little undecided about dependency injection as a way to implement inversion of control. Certainly IoC is good in principle. Dependency injection can make for some pretty clean code. That's all well and good, but if that was all that Spring promised then there wouldn't be such buzz around it. The bigger thing that IoC in general and Spring in particular promise is to allow for more portable and reusable software components. This is The Holy Grail of software (or at least of object oriented programming.) However, simply declaring your dependencies and allowing your container to resolve those dependencies does not guarantee reusable software. Another pre-requisite is that all the dependencies resolve to things that are also reusable. For example, I could have controllers that declare a dependency to some BigBadService class. That class must have all of its dependencies declared, and they need to resolve to interfaces (or to some other class that in turn has its dependencies resolve to interfaces, etc.) So Spring could definitely be used to simply clean up some code, but it takes a lot more than just that to really reap benefits from Spring.
Enough about that, I wanted to talk about some of Spring's features. I really like it's implementation of dependency injection. I am among those people out there who gets annoyed with too many and overly complex XML configuration files. There are definitely frameworks that verge on having "xmlscript" as a secondary language. Spring is a little guilty of this. Their configuration files can get pretty ugly, but that usually indicates a very complex application. They can be pretty simple to start. For pure dependency injection, they are very simple and clean. It's when you start adding others things like transaction management and web flow that things get ugly. I definitely think that transaction management should be done through annotations, a la EJB 3.0. Configuring controllers is always somewhat complex. The legacy of the original servlet spec is going to push a lot of this complexity into ugly xml files, so I don't totally blame Spring for that.
Of course dependency injection is just one of the many features of Spring. I haven't tried them all yet, but I'll describe a couple. First, it's previously mentioned transaction management is pretty solid. I used the DAO+Hibernate modules for this. The one thing I didn't like was that it was a little tricky to declare transactions for a class that I did NOT want to Spring to manage the creation of. I had a class that I wanted created by a factory. Spring managed the creation of the factory. Since I had a factory, I did not need it to manage the creation of the objects created by that factory. However, I wanted those object to be transactional. So I had to have it manage the creation of those objects, though I was able to tell it to use the factory. I felt like I was jumping through a hoop here. Otherwise, the Hibernate integration was very easy and well done.
The other module I used was Spring MVC. When I read the documentation on this, it really seemed like a nice step forward from other MVC incarnations. Of course, I'm not actually a big fan of MVC. I think it encourages a lot of coupling between presentation and data. This is especially bad given that the motivation for MVC is a separation of these things. I worked on a project once where we had a nice architecture that involved session beans that exposed XML only. Our servlets then applied XSLT. The motivation was that we needed to expose the exact some business logic but to many different user interfaces. The big problem with this kind of architecture was that the XSLT became incredibly complex. That's where the biggest advantage of using an MVC framework comes from, at least to me. It handles data-binding (and related things like validation messages) nicely.
Back to Spring MVC... It is very easy to get started with, but also very easy to start having problems with. The reason is its flexibility. There are so many options, and many of them are designed to have you write less code. Whenever you write less code that means the container is doing more for you. The combination of lots of options + lots of "invisible" container services can cause a lot of confusion and unexpected behavior. Fortunately it didn't take me too long to sort through the different options and understand them well. The Javadocs were great for this, much better than any of the tutorials/quick-starts out there. Once you understand how each controller-type works, the associated options are obvious. I like the command objects in the framework. They encourage abstraction and less coupling between business objects and the UI. Of course it would be easy to abuse this and basically make your business objects the same as your command objects.
All in all, I'm very pleased with Spring. There are certainly many more features that I have not explored on it. Its web flow particularly interests me. I think its IoC implementation is nice, and both of its dao/transaction packages and MVC packages really help the developer to write less code while not burdening him with arduous configuration.