Wednesday, August 31, 2005

So you wanna be a coder?

Read these books:

"Introduction to c# using .NET" by Robert J. Oberg
"Head First Design Patterns"
"Patterns of Enterprise Application Architechture"
"The Pragmatic Programmer"
"HTML for the World Wide Web with XHTML and CSS: Visual QuickStart Guide"
"JavaScript & DHTML Cookbook"
"Programming Ruby"
"Agile Web Development with Rails"


Anything that has "Cookbook" in the title is generally about showing you reams of well-written, working code covering a wide range of problems. They're a great way to learn by example.

For any given subject you'll probably want 3 books: An Introduction, an Advanced book, and a Reference or Cookbook. The last is actually optional since there's just so much to be found on the web these days and online documentation is better than the books sometimes.

In a few months you'll be programming on a new level (if you aren't already familiar with the subject matter of course).

Saturday, August 27, 2005

Ruby DBI

Google for Ruby DBI, what do you get? A sourceforge homepage is the top result. That's not maintained though. What you actually want is the sixth link down. The current release of DBI is on RubyForge. I only just learned yesterday that the sourceforge version I was using is two minor revisions out of date.

No SQL Server specific fixes as far as I can tell, but a number of small fixes to do mostly with statement parsing and preparation, so probably good to have.

Plus there's fewer file overwriting installation failures, which is certainly convenient not to have to rename/delete existing files in your one-click installation.

Wednesday, August 24, 2005

Home PVR

A couple weeks ago I started building a Home Threater PC, here's a quick blurb on the experience:

KnoppMyth: Wasn't stable with my Plextor M402U (USB2 Divx capture device)

Fedora Core 4: Worked fine with my stand-in Athlon64 box, after about 20 hours of hacking that is, and never did get it working right with my DirecTV D10-100 satellite reciever (wouldn't change to channels under 100, even with the script). When it came time to swap the Athlon64 out for my new media-center box (Intel 945G, Celeron D, etc), FC4 would hard-lock when detecing the Intel HDA soundcard. You'd think Intel on Intel would be a sure bet, but oh well.

While trying to download Knoppix, Unbuntu, and Gentoo, my Fedora Core 4 based laptop crashed. Despite popular opinion it actually seems pretty easy to crash a Linux box if you spend much time in a GUI (KDE & Gnome also seem laggy compared to WinXP).

After all this I made the decision that Linux has a long way to go for the desktop. The shell is great, running a Lighttpd server is great, but as a workstation? Unless you've got hardware that's a couple steps behind the cutting edge, and unless you're willing to put up with some "quirks", you should probably stay away from Linux as your main workstation in my experience. Until you know all the ins and outs anyways.

WinXP: Downloaded SageTV and BeyondTV. Stuck with SageTV after a few minutes since it had much better picture quality by default. Maybe BeyondTV can be tweaked to be the equal of SageTV, I dunno, but I gave up on MythTV precisely because I was tired of tweaking. Shot off an email to SageTV support and by the end of the next day they had me an update that allowed it to change to channels below 100 on my satellite reciever controlled by a serial cable. We're pretty sure we're gonna stick with SageTV. The picture isn't quite what you might expect for a PC plugged up to a ceiling mounted projector over regular DB15 VGA cable, but it's at least the equal of our old ReplayTV, so that's good enough for now I suppose.

If you're thinking about an HTPC, and don't have a lot of Linux experience, I'd probably suggest you go with SageTV unless you're planning on running older (non VIA) hardware, with a Hauppage PVRx50 capture card, and analog cable. If that's the case you could probably be up and running with KnoppMyth in 15 minutes. If it's not, you should probably get a handle on Linux in general before you attempt a MythTV setup.

My overall impression is that there's a lot to love about Linux, and there's a great community out there supporting it, but a lot of it seems to suffer from the "gee-whiz" factor. ie: Developers creating something really cool, but loosing interest when all the fun bits are there, and leaving something that doesn't always work too well. Cream(VIM) is a perfect example. One of the best editors I've ever used, with simple touches that make all the difference like color themes in dark tones you can stare at forever and never a hint of eye-strain. It also looses syntax highlighting for seemingly no reason sometimes though, or crashes, or fails to load without a graceful error, etc...

I realize that's not completely fair, as considering how many packages are involved in your average setup, it's only a small fraction that suffer any instability. Just the same, they spoil the party.

It really seems a shame that it seems the vast majority of Linux and the apps that run on it are written in C++. You'd think Java would be a much bigger player in the Linux world. It'd certainly result in simpler, more stable code I'd imagine.

Oh well, this post isn't a knock on Linux. Linux is great. Just a knock on Linux as an HTPC on new hardware, or hardware outside of the 90% adoption realm.

WinXP + SageTV is where it's at for HTPC in my opinion. Atleast currently.

Ruby Everywhere!

Hey, drop me a line if you know how to do a Word Mail-Merge through OA.

Anyways, another win for Ruby. Excel automation is a piece of cake, and it doesn't have the interop funkyness of c#. Yup, converted another coworker to Ruby today. It's infecteous. :)

Oh, btw, if you're using Ruby and DBI's dbd_ado driver, MAKE SURE TO USE SQLOLEDB database connection strings! That's the one that looks like Provider;DataSource;InitialCatalog instead of Driver;Server;Database. Update and Insert statements will magically fail to work with no warning if you don't. It can be very frustrating.

A buddy at work finished parsing a 1.3GB file in Ruby today. Parsed and written out to Yaml for archiving takes around 20 minutes. Having done a fair amount of c# processing I'm fairly impressed at Ruby's performance, and this is without StringBuilders or custom Buffers or Arrays or anything. He tried 'em of course, but the performance benefit was so slight as to not be worth the extra lines. I had some serious gut-feeling doubts that Ruby would be up to the task, but I'm pleased to say I couldn't have been more wrong... EXCEPT: Ruby really needs OS threading. It's not such a huge impact on this file, but there's definitely times where the resources could be better utilized, and it takes more thought to build a smooth process than should really be necessary. (Though still, not much code)

I'm convinced that Kernel::eval() could play a role in creating a "Smart Parser" if I got a chance to sit down and have at it for a few days. Something that could use a data-dictionary to derive what it could, and actively ask questions to fill in it's knowledge gap when it came across areas of files it couldn't. Might sound a little Sci-Fi, but I'm convinced it's feasible with the right coders behind it (and hey, that might not be me ;) ).

Ruby's certainly spreading like wild-fire at work it seems. Most of my and a collegue's (sp?) current work is now in Ruby.

Now I just have to figure out how to automate a mail-merge... ugh.

Thursday, August 18, 2005

454 Lines

454 Lines of code in the new final final version of the Javascript Calendar.

That's a lot.

But it's cross-browser, bug free, fast, sweet.

I have a new appreciation for how truly crappy IE is btw. The latest is that under certain times of year and cycles of the moon, you can't use .innerHTML, even on DIVs. So I had to create my year, month, and day containers with the DOM, and then, BEFORE I appended them to the document, I could fill in their content with .innerHTML. If I appended them first I'd get a runtime error. If I tried the += operator on an existing element, I'd get a runtime error.

Another special specialness that IE has brought us: You can't assign strings to events when creating DOM elements. In other words:

myelement.onmouseover = "alert('boo!');";

Doesn't work. No, you have to define functions:

myelement.onmouseover = function() { alert("boo!"); };

This isn't always bad of course. It can make longer strings a bit more readable. Say you wanted to pass in a value though, aka:

myelement.onmouseover = "MyArray[TWENTY_EIGHT].doSomething();";

Now what? TWENTY_EIGHT is out of scope when the function is fired, so you can't just blindly replace that with a function like the following:

myelement.onmouseover = function() { MyArray[TWENTY_EIGHT].doSomething(); };

So what do you do? Well... I got around it with attributes:

myelement.setAttribute("myIndex", 28);
myelement.onmouseover = function() {

Yes, it's true. IE sucks.

Wednesday, August 17, 2005

JAAJAX and the state of Ajax on .Net

To flame or be civil? That is the question. :)

Ok, I'm going to try to be nice here. Jay Kimble (CodeBetter member) has posted an Ajax library. He calls it "JAAJAX" aka: Just Another AJAX.

His intentions are good enough: He hopes to start setting some best practices for Ajax usage.

Or are they?

My position is we don't need 'em ("best practices" that is). The rules of good use of Ajax are no different than anything else. He mentions Ajax Security concerns later... but the overall message is, don't deviate from what you should be doing now with regular pages. Is this really something that needs repeating? Good coders will seek out ways to improve. Bad coders can't be force-fed. Nothing new here.

Let's get down to the real problem though: His library leaves a lot to be desired. I know, harsh. I don't mean for it to reflect on anyone as a coder. In fact, JAAJAX is rather similar to Ajax.Net, which I myself thought was decent enough. So similar in fact, that you end up wondering what the point is. Beyond that though, Ajax.Net itself is a poor example of how to implement Ajax.

Why should you listen to me? Well, for one, the style of JAAJAX and Ajax.Net breaks Seperation Of Concerns. ASP.NET's half-assed idea of a "Controller" now has to discern between Ajax, and regular requests. Why should it? Plus you just end up having to write a lot more code than should really be necessary for the task.

So what's a decent Ajax Library?

*THE* Ajax Library is Prototype. SoC is maintained (well ok, you might need to add shell Actions to deliver full page layouts for non-Ajax requests, but that's a minor compromise compared to the alternatives), and the only code to write is a Javascript one-liner in your View. It makes all other libraries I've seen (especially on .Net), look like bloated, needlessly complex crap.

Plus it also provides handy Javascript classes to toy with, and it's as cross-browser friendly as they come.

When Ajax is as simple as a one-liner, what's the prob? That people have the power to write crap code? Crap code is crap code... wether it's Javascript, VBScript, c#, etc.

So what's the conclusion? If you're stuck in .Net land, what should you be using if you want to get your hands dirty with Ajax? The answer is easy: MonoRail, whose Ajax support is based on Prototype. Once you write an application in MonoRail you'll never want to go back to regular ASP.NET. Just don't look at Ruby On Rails. As I read on another blog: If you haven't by this point, then don't. It may lead to depression, despair, etc when you realize you've been writing two or three times as much code as you needed to get the job done, and Rails makes anything else look like spaghetti code no matter how clean it is. :D

Sunday, August 07, 2005

Know thy Javascript.

Ok, Javascript & Ajax seem to be taking a beating lately. Lets kick out a couple pointers so people feel more comfortable with it:

element.setAttribute("attr_name", attr_value);

The above works in Safari, Firefox, Konquerer, IE, you name it. Don't be tempted by element indexers, named attributes, etc. setAttribute() & getAttribute() are the only ones you should use.

timeout = window.setTimeout(function() { alert("Test!"); }, 5000, "javascript");
window.setTimeout(function() { window.clearTimeout(timeout); }, 2500, "javascript");

This is how you cancel something. If you're going to popup a window with a timer for example on an element mouseover, make sure you cancel it appropriately. Don't let events just chain so your popup's contents flash through 5 different elements before getting to the current one. Cancel the previous timer when mousing over a different element.

Saturday, August 06, 2005


So I've got this site written in Rails, and my manager seems pretty excited about setting an Apache server up under Linux (Fedora Core 4). Unfortunately I've never really used Linux. Just a few failed attempts at installation. :)

So Friday I fought all day trying to get the site setup on a machine at work. They had already installed Linux on it, including Apache, but the docs on the Rails site assumed I would be installing Apache myself. By the end of the day I hated Linux.

Or rather I hated that it made me feel stupid. So today I give it another go. Last night I downloaded the FC4 DVD. Today I installed it, including the option to include Apache so I would hopefully duplicate near enough the configuration at work. Since I've installed it on my Compaq Presario X1000 laptop, it took me awhile to figure out how to get the wireless working. (I have a Broadcom 4306 based WirelessG MiniPCI card I upgraded to from the stock Intel 2100 or whatever) Eventually I bit the bullet and surfed over to Linuxant (which I was avoiding since I'd read it's not free). The setup couldn't have been smoother though, so I think they earned the $20 they're asking for. Well, actually, there was a hiccup when I couldn't figure out what to do with the R74092us.EXE file I downloaded from their Windows drivers page, but some googling quickly turned up that I could just execute "unzip R74092us.EXE" at the Terminal to open it up.

So now I'm up & running, and posting this with my wireless connection in Linux. Spiffy.

It's like Longhorn aka WindowsVista or something, but today. :)

Anyways, I think I'll hold off on banging my head into the FastCGI/Apache setup again until tommarow.

This page is powered by Blogger. Isn't yours?