July 2008 - Posts

• Net Neutrality

  Net Neutrality advocates tell us that, if ISPs are allowed to pick and choose what kind of bandwidth they throttle the most, they'll, of course, discriminate against their competitors.  Being the giant, evil, corrupt corporations they are (this is Microsoft and Google talking, BTW), they can't be trusted to play fair.  They've already proven this by discriminating against people using P2P services.  The ISPs in question answer that those are evil people who are illegally sharing copyrighted music (every one of them), so who cares? Besides, if they didn't discriminate against those pirates, you'd never get your email.  So they need to set up a special premium service where they can sell you enough bandwidth to actually watch high-quality video over the 'Net.  Video that they'll sell, of course. The problem with this particular smoke-and-mirrors round of this fight is that anyone with some sort of broad-band is already paying for premium service. The problem with their new "super broad-band" level of service is that their infrastructure can't support the bandwidth they've already sold. They've built their infrastructure on a sharing model.  Take 1 pipe, that can handle 1,000 thingies (whatever a "thingie" is) a day, and hook it up to 4 different houses.  Tell each home-owner that I'll let them use 1,000 thingies a day.  It works, because Milton works from home during the day, then turns his computer off, Mildred uses her computer in the evenings after work, Martha always works late and uses it late at night, and Michael wakes up early in the morning and uses it before work. That is, it works until Michael (the evil fiend) starts sharing his home movies on some P2P network. Now he's connected and using bandwidth (that he's already paying for) all day long.  This interferes with Mildred, Martha, and Milton. A big part of the fight is about the "last mile": where the lines snake out from the telephone poles and go to your house.  That seems to be where "the pipes" get clogged up.  Even if you have a ton of other companies push into the picture and add more options there, you'll still have congestion where all of their "pipes" meet to connect with...whoever their ISP is.  Ultimately, everything's running through huge "back-bone" lines, most of which are owned by either AT&T, Verizon, Sprint, or a company named Level 3. We probably don't have to worry too much about them throttling down on your music sharing so the cable companies can sell their customers smoother video.  But do you want to bet that they won't take the money, if the cable companies offer? Here's the flip side of the coin: ISPs can charge (for example) YouTube a premium, to let their videos stream faster and more smoothly.  Their competitors (do they have any?) can't afford to pay that premium.  They go out of business. To a web company, the internet is basically just a public utility. If that company uses more bandwidth, it also pays a premium already.  If a company bases its business model upon a particular technology, and then ISPs start penalizing that technology (because they weren't foresighted enough to realize that, someday, people would be presumptuous enough to actually expect to use the premium bandwidth they were paying for), it can destroy that business. That is the situation, as I understand it.  ISPs want to charge a premium for something we're already paying for. Google and Microsoft want the government to add new, unworkable regulations that will almost certainly be obsolete before the ink finishes drying.   Posted Jul 21 2008, 04:20 PM by JamesAshley with no comments Filed under: theory, Not Dot Net, Completely Off Topic

• Some Open Source Ajax Frameworks

  Introduction I've finally had a chance to look at AJAX again.  Step one (for me) was to do some research into the different frameworks.  The project this is for has nothing to do with .NET, so I still haven't had a chance to look at ASP.NET AJAX.  (Well, nothing worth talking about.  I helped a coworker do some debugging once, when it was in beta). I have even less experience with most of these other frameworks. Still, maybe the research I've done so far will help someone else skip over the first steps that I took. The first thing I found is that the vast majority of articles along these lines are ancient history, but you have to actually dig through the article to find any dates or  version numbers.  I did this research on Prototype/Scriptaculous 1.6, jQuery 1.2.6, Dojo 1.1.1, and MooTools 1.2. Market Share According to jQuery's author/owner, this breaks down as follows (not sure when he gave the presentation these numbers came from): Prototype: 35% jQuery: 25% Dojo: 20% MooTools: not mentioned (don't blame the messenger) The Basics Prototype Prototype's been around quite a while.  A lot of people have been hammering on it a long time.  It's solid and reliable. Apparently they've put a lot of effort into bringing JavaScript's object-oriented abilities more in line with what Java/C# people think of as "object-oriented." It's also fairly minimalistic. I used Prototype a little on a Ruby on Rails project.  Its seamless integration there makes it pretty much a no-brainer in that environment. jQuery Even if it's not as popular as Prototype, it has a huge fan-base.  I see more books and articles about jQuery than probably every other javascript library combined. As far as I can tell, its feature set is very similar to Prototype's. Its basic design approach seems to be the exact opposite: base everything around this magic global $ function. I have friends who are big fans, mainly because it's just dead-simple easy, but the $ reminds me of Perl. (Not to say anything bad about Perl...I know it's a wonderfully good and powerful language, and a lot of people have done a lot of amazing things with it). Looking at all the samples of what people have done with it, it's obvious that you can do some really impressive things with it. Dojo This bills itself as a full-stack framework.  They organize things into several different namespaces, and the basic API is dead simple. It comes out of the box with most of the bells and whistles anyone will ever need. I've read complaints about the friendliness of the user community.  A commenter in one blog post said that "Dojo's just insane," but he didn't elaborate.  (Sorry, I've lost the link back to that article). One of its more attractive features (that I've seen so far) is a "toolkit builder." Basically, you pre-process a few files, and they spit out one single file that contains only the pieces that your app actually needs. Or you can point to a file that contains everything, served up by AOL.  This is extremely important when you're on a platform like Google App Engine, where you're limited to 1000 files and blob entries in the database. (This limitation will go away when they let people start paying). MooTools MooTools is a minimalist, heavily object-oriented library.  It has very dedicated fans. That's really all I know about it. By the time I discovered it, I'd learned that it wasn't what I'm looking for right now.  When I'm working on a project where I'm going to be doing a lot of pieces that are radically different than what everyone else is using, I'll take a much longer, deeper look. I mainly mentioned it because I didn't want the fans to flame me in the comments because I left it out.  ;-) My Thoughts This is where things pretty much get totally subjective and based on current project needs. Prototype It's hard to turn your back on market share this big. You know it's solid, and it will be here tomorrow. It just never seemed like the right fit for this project.  Making engineering decisions based on gut reactions isn't exactly an industry best-practice. But, when you have to make a decision now and get busy writing code, you have to rely on experience and instinct. jQuery jQuery has what could be a vital feature that none of the others seems to: it makes it incredibly to modify the DOM.  The others let you modify a node's attributes or swap out its contents, but jQuery seems to let you make that sucker tango.  Adding items to a  list was one of the examples I ran across. If it's hard to say "No" to the market leader, it's even harder to turn down the #2 guy. Dojo But Dojo comes with pretty much every visual effect I'm likely to need.  Check out the Dojo Feature Explorer. Not all the demos work in all browsers...that's why they've broken those pieces into a package that they've explicitly marked as "experimental." MooTools Any library whose fans love it this much is worth paying attention to. Wrapping Up (I know...finally!) All these toolkits are great.  They make the basic AJAX thing simple and easy. I spent a lot of time torn between jQuery and Dojo. I've been digging through Dojo's manual, trying to learn enough about it to make an educated decision. I've also been trying to dig through jQuery's documentation. Every time I start, I get a "Man, this is ugly," reaction, and I find something else to do instead. And that's my answer.  If I hate the way code looks, I'm not going to enjoy working with it.  It may be the greatest tool since the bread slicer, but if there's something inside me that doesn't enjoy using it, then I won't use it as effectively as something less powerful that I enjoy. Besides, Dojo comes with pretty much everything I need built in. All frameworks have warts.  All abstractions leak. When you're learning a new programming language because it's a way to expand your horizons and view of the world, pick the one that strikes you as the most worthwhile (or that someone you respect/admire recommends). When you get through, there will be parts of it that you hate. When you're picking out a new framework to learn, because you need it for a tight deadline, sometimes you have to go with your gut. At least, that's what my gut's telling me right now.  We'll find out later whether it was right. I fully expect that there will be a few places where I'll need jQuery's DOM-manipulation abilities. And I'll use it then. Other than that, I'm predicting MooTools and Dojo in my future. Posted Jul 19 2008, 05:17 PM by JamesAshley with no comments Filed under: Not Dot Net, AJAX