Thursday, May 31, 2007
After checking the laptop and the rebooting the router twice, I decided on a whim to check the FIOS cable that the Verizon install team left exposed and running behind my house to the terminal. Shortly after I got to the grassy strip behind my house, I discovered it. A gash in the line that was more than likely caused by that lawnmower I heard.
Well, if you have FIOS running your internet AND your phone, you're really screwed when you try to contact Verizon to have them come and fix your service in the middle of the night. So I called them on my cell phone and had to schedule to leave work early the next day in order to meet the repair technician. He pointed out that it looked as thought the contractor that was paid to bury the FIOS cable had done the work, but never connected it to the house as there was a coil of fiber cable poking it's way out of the ground beneath the external housing.
So now that I'm back up and running at home and I have a buried fiber line, I think I'll be dropping Comcast and put all of my eggs in the Verizon basket by picking up FIOS TV. It'll even save me a few bucks per month and the best part is that I won't have to deal with their crappy DVR UI again.
Wednesday, May 30, 2007
Here's my initial thoughts on the ones I've tried out:
- MooTools - Looks nice, but severely lacking in beginner samples. I couldn't even reference the fully loaded MooTools.js (v1.1) file without throwing errors. Needless to say, this did not go over well with me. It's a real shame as I like this tool set over Rico.
- Rico - Speaking of which... Rico was the first framework I ever saw and it just blew me away. I've never had a chance to implement it and, to be honest, I had initially shied away from it because I wanted to pick something that had a higher user adoption rate. I've still not tried it as I'm told that it is an extremely bloated framework and there are much lighter frameworks (MooTools for instance) that put Rico to shame. That makes sense as, to my knowledge, Rico is essentially an effects package that sits atop the Prototype framework.
- Prototype - This is, to my knowledge, the (most well known) framework that started it all. It provides all sorts of hooks and utility methods that make common functionality a breeze and it also has the benefit of eliminating the need for knowing the intricacies of cross-browser scripting. Not only that, but it's the first one that I've looked at that actually worked. Granted, the examples I was looking at were still too meaty to be easily digested by a n00b like myself, but I was able to supplement their examples with examples found in the blogosphere. Once again, another reason to make wide user acceptance a criteria for picking your framework.
- Adobe Spry - This is toted by Adobe as being the framework for designers and I can say by the lack of technical documentation that this would appear to be true. While it would be nice to pick a framework that is backed by a heavy-hitter like Adobe, I just can't get into a framework that doesn't have the documentation to make my learning process that much quicker.
- Yahoo! YUI - I haven't looked at it as Prototype just started working for me, but it's on my list of things to check out. Perhaps Andrew has taken a peek at it?
Friday, May 18, 2007
Apparently Doug1 thinks he sent me a link to MooTools. I don't recall that being the case. Either way it is a slammin', lightweight DHTML/AJAX library that I fully intend to spend more time looking at. I think I like its examples more than any other library I've seen and now that it's been blogged, I have a better chance of being able to follow up on that intention.
Thursday, May 17, 2007
I've kept FireBug installed on FireFox since I first learned of it's existence. I didn't use it for much until today when I was appending elements to the DOM. Imagine if you will that you are the Sorceror's Apprentice and you are creating brooms to carry the buckets of water. Appending elements to the DOM is nothing like that...except that you can conjure DOM elements up and splice them in wherever you want.
The problem with appending elements to the DOM is that you have no way of seeing the HTML that makes up the resulting DOM since "view source" only shows you the HTML that was initially sent to the browser. Enter FireBug. It allows you to see the real-time HTML since it is "pinging" the DOM rather than reading from the first set of HTML that came down from the server.
Tomorrow I'll be implementing AJAX and I hear that's another area where FireBug kicks butt as troublshooting asynchronous server calls is yet another layer of hidden abstraction that FireBug monitors for you.
...and so is the home for the Koosh blog. I'm in the process of migrating all of the content from the old blog to wordpress or some other blogging site. However, with a day job with a 40 minute 1-way commute, side work in the evenings and all the like, I'm not terribly motivated to port the content. Never fear though...I have the database backup so all those posts about Ridley and my frustration with pre-order madness will soon be available again. It should be a simple matter of writing the queries and exporting/re-importing as XML. Should be.