Friday, September 09, 2005

This site has moved...

I have officially setup a Typo Blog at RedCloth/Textile is enabled, Comments are open to the public, and... well, pretty basic install for now.

Wednesday, September 07, 2005

I've finally done it...

I broke down and ordered a domain through (read about 'em through the awesome blog), and a TextDrive account.

Since the money's spent, hopefully that'll motivate me to setup my own blog there. I'll probably discontinue posting here for now hopefully.

My new domain names are and ( was taken by a squatter). As in: "I'm poor. When am I gonna get mo' substantiality at work?" :D

Javascript is cooler than you thought

We'll write a helper to prove it.

String.prototype.format = function() {
content = this;

if(arguments) {
args = arguments[0] instanceof Array ? arguments[0] : arguments;

for(i = 0; i < args.length; i++) {
regex = new RegExp('\{' + i.toString() + '\}', 'ig');

content = content.replace(regex, args[i].toString());

return content;

alert('{0} is {1}. Yes, I said {0}.'.format('Javascript', 'cool'));

I whipped this up in a couple minutes. It's had no real testing. I wrote something similiar at work, so I don't expect you'll have any problems with this, but no promises. ;)

Also, this should be at least IE6 and Firefox compatible. Been meaning to try it on Safari... The only real concern is that the browser supports the instanceof keyword. If not, there are workarounds online that should do the trick.

Why does the code also accept an Array? So you can write other things like an Array.append(content) method that optionally accepts arguments after the content parameter, sticks them in a new Array like so: for(i = 0; args[i] = arguments[i + 1]; i++);, and then pass the new array to content.format(args).

Tada! Now you not only have a useful Array.append method (this[this.length] to get the next new element), but you also have the equivilent of an Array.append_format in the same method. Now is that slick or what?

Told ya Javascript is cooler than you thought. ;)

Hand me down tools?

Jeremy D. Miller has a great post at CodeBetter.

Here's my mini-response:

I think it's important to keep the "competition" in mind. Ruby and Java both bring something very important to the table .NET only has a poor approximation of (despite many talented developers working on the problem): AOP

This is what makes a truly robust O/R Mapper like Hibernate possible. It's what makes an entire framework like Ruby on Rails take less time to develop than tools like NVelocity, NHibernate, WilsonORMapper, etc.

Not that they don't all have very talented people behind them doing great jobs, but c# is frankly crippling compared to the flexibility of Ruby's mixins, or Java's default virtual methods.

And yet Microsoft spins their wheels coming up with solutions to problems that are already solved with things like Comega. Does anyone with experience with both honestly think ASP.NET + Comega will be able to hold a candle to Ruby On Rails? Will any of it result in less or cleaner code? Will I be able to extend it through metaprogramming?

So what's the point?

It seems a shame that Microsoft made such a really beautiful versioning system, and then crippled their flagship language for versioning concerns. When I can run multiple versions of the .NET runtime side-by-side transparently, why should versioning have been such a problem? Target the assemblies to a version, and be done with it.

But instead of fixing the problem, they put out flashy PR like Comega that really brings little new to the table and misses the boat completely. We need flexibility. Until we get it, c# will always play second fiddle to Java IMO.

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

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