Monday, January 28, 2008

JavaScript : Always the bride's maid, and never the bride

I've been working with JavaScript since 1998, when I first started 'developing' for the web (if you can call hand coding HTML pages developing...).

Back when the DOM was non-standard, and most of what we now call Ajax and Web 2.0 was known by a far less sexy moniker, namely DHTML (huh?)

CIO Magazine looked at JavaScript recently, and it got me to thinking about the little language that clearly WASN'T.

JS is great, JS breaks, JS is hard to debug. And yet when addressing the browser its the best thing we've got. I once had a boss of VERY german origin, getting VERY upset with me because I had the audacity to use VBScript to write some client side code back in 2003.

This despite the fact that all the people using the application had IE, but that is a more philosophical question; the fact is that JS is your best bet to have your code run on the MAX of browsers; however judging by the number of browser-checking code branches in the average JS application, its certainly not a good thing.

I like the basis of JS, namely EcmaScript, and have achieved great things in Flash and other applications which implement this syntax to drive their scripting. It plays nice, makes a lot of sense (once you understand prototyping) and is easy for developers to have a common ground, whether they are C++, C# or Java programmers.

The only people all at see in JS are Visual Basic programmers, and quite frankly... they should know better than to try and get their hands dirty in the land of curly brackets. (HA!) : seriously though, I think VB is an unfairly killed language, and I'll be going into that soon enough. (Try teach someone programming with a Basic language, such as VBScript, and you realise where the appeal once lay with this family of languages : its a BREEZE)

JavaScript's greatest weakness isn't a weakness of the language itself, but rather the complete lack of tools and debuggers for the scripting language. For such an established languaged, how can it possibly be so hard to debug?

There are several offerings online, from Eclipse plug-ins to stand alone IDEs, but more often than not, most developers will admit that their JS development tends to involve a text-editor (maybe DW), a bag of alert()'s and a prayer.

This isn't an acceptable situation, and strides made in VS 2008 go a long way to fix such things; but I can't help but feeling that JS will only really take flight when it is completely divorced from the user. ASP.NET Ajax goes a long way in this direction, allowing me to code my app (client side and all...) in C# and see nice efficient JS be pumped out of my server, and I never have to interact with it. That for me is what an programming language should be.

Maybe JS's day will come. But not yet.

Labels:

Thursday, January 24, 2008

Last.FM : Finally social music for the masses

When I'm in the UK, I've used the amazing Pandora internet radio service. This service was suspended in all locations outside the U.S. a while ago, but the UK had been a bit of a grey area. Since the 15th of Jan, it has stopped in the UK.

Now, staying in South Africa has been even worse, with virtually none of the great things about Pandora available on any service.

BUT NO LONGER! Last.fm has finally gone global, having signed licensing agreements with all the major record labels, just go to:

http://www.last.fm

Last.fm works on the same principle as Pandora: type the name of a genre or artist you enjoy, and let the software jukebox play you a selection; Last.fm also listens in to your iTunes and/or WinAmp etc playlists as they are playing, to see what else you might like; they call it scobbling, but it sounds like spyware to me. I've installed it, I'll write soon, how that goes...

Last.fm is accessible via the browser or their desktop app.

I recommend to anyone (everyone) who loves music. Awesome... absolutely fantastic. and its legal. Good bye thousands of MP3's on your PC.

Tuesday, January 22, 2008

Tactile Music Sequencer

I was loitering around Engadget today, and found a truly awesome music sequencer, and proof that an appliance with a really clever tactile interface can still make an impact on the industry.




I doubt anyone is going to be making any major albumns on this thing, but seems like a pretty cool desk toy for the raver close to your heart.

To recode or not to recode

When an application is in daily use, especially a web application, for many years (7+), its in all likelihood:
  • Written in a scripting language (ASP, PHP, CF, et al)
  • Been worked on by MANY different developers
  • Has fallen pray of many server and client side "fixes"

The question then eventually becomes when and/or if you should recode the application or parts of it. Some might jump straight to "recode the whole thing in .net/flex/j2ee/ruby" decision, while others might be a little more circumspect, and decide instead to focus on simply recoding with better practices the pages in the language they were written in the first place.

It's a very difficult decision, and I don't know if I have a strong opinion either way, I have a tendency to look at the code base and decide on a case by case basis, especially if the code appears to be stable and operating normally.

The problem is maintainability in the long term, but I don't know if the potential new bugs included in a recode (or worse: a rewrite) make it worthwhile.

It depends on the system. If you have a bad email post form, recode it for sure. If you have a vast client management platform hit by 100 000 users a day... maybe reconsider bringing out your Dreamweaver and going 'bos' on the code base.

Over the coming months I'm going to be doing a partial piece meal code review and instance recode of a large ASP application, so expect some stories of pitfalls around this.

I'll be kicking this off tomorrow by looking at ASP/VBScript's Date() and Now() functions, and why they are ABSOLUTELY not what they seem, and should NEVER be used for anyone expecting any certainty around the date or the time.

Labels: , , , , , , , ,

Monday, January 21, 2008

TFS to VSS port hell

Source control is a neccesary evil. Whether it be SVN, Tortoise, TFS or VSS (which isn't as bad as you think : I hear the audience wail!)

Our company was using TFS, which is an awesome platform, but fairly pricey considering; we still keep our gold press code in the TFS, but for quick and dirty projects the VSS is a perfect tool.

When source code goes awry its never good; and on a personal project, I had some source in my personal TFS at home (one single SQL backup a night for all my personal source), of which I was using the Trial Edition, which I then ported to my VSS on my home server.

But I missed a file. Not nice...

The TFS trial expired. And I "lost" the file...
This is where it got interesting.

I tried queries like this on db (TFSVersionControl):

select * from tbl_identity
select * from tbl_workspace
select * from tbl_PendingChange
select * from tbl_File


select tbl.name from syscolumns c, sysobjects tbl
where c.name = 'FileID' and tbl.id = c.id

select * from tbl_NameSpace
select * from tbl_File
select * from tbl_Content


To no avail...
In the end, I gave my old TFS another 30 days of life, by using bharry's TFS trial extender and retrieving all my files.

Don't even try and brute the MD5 encryption on the hash you need to unlock the content of the file; its NEVER going to happen. Some people suggest restoring your old TFSVersionControl over a new install, but I'm sure that would mean harshing the OS to clear it of the Trial checking crap, or an install on a new machine, neither a good option; so bharry's stuff worked a charm.

But there is an important lesson here...
when migrating from one source control to another, make ABSOLUTELY sure to keep a gold copy and hard copy of your source code seperate from your source control; you never know if your source control might get locked up and become inaccessible.

And that's not a happy day, anyway you look at it.

Sunday, January 20, 2008

Cast your .Net wide : The opening up the framework source

I work with the .NET framework to some degree every day of my life (and if you surf the web every day, then in all likelyhood so do you!)

Scott Guthrie and the rest of the Microsofties have decided to 'open' up the source of the .NET framework so developers can debug based on the source.

I don't think RMS or any of the open source Nazis are going to be building statues to Guthrie and his team outside the Free Software foundation headquarters over this, but it makes an interesting counter point to the whole OSS view point of the world.

The .NET framework is an amazing platform any way you cut it; love it or hate it, if you need to pick a random developer off the street and have him or her deliver your organisation cogent and readable code in large scale corporate product, .NET is where its at.

By opening up the Framework, everyone can get a better understanding of how the Framework really drives, and also enabled developers to better the leverage their applications against the Framework. For those who just want to drag and drop controls and tie them up on the backend this release will mean little, but for those of us trying to squeeze every drop out of our applications this is a VERY welcome submission to the community of .NET houses out there.

Is this the beginning of a broad opening up of Microsoft technologies? I doubt it, and this is a good thing. When ever I look at Microsoft I see a bewilderingly broad range of product and service areas; do I really want to bombarded with the Zune firmware? No, I don't. Sure some people might like to see it, but this is a good example of something niche which would waste Microsoft's resources in supporting.

The framework is central to the development of software on Microsoft's platform, and therefore a greater understanding of it should allow for us all to write better code, and therefore deliver better applications.

I'm also interested to see the coding and commenting practices present in the .NET framework. In the same way Hungarian notation influenced coders in the late 80s and early 90s, I hope to see a broad sweeping adoption of GOOD practices where present in the .NET code base.

I've already found a good example, namely the /* */ commenting of hard booleans into the actual function calls from within a class; I've never thought of this, and it really makes sense.

For example:

callFunction(/* Is the Connection open?*/ false, /*return a bool?*/ true);

which makes more sense than:

callFunction(false,true);

Overall, I am excited to take a look at the source, and get a better understanding of ADO.NET and ASP.NET;

Saturday, January 19, 2008

Enter the inner nerd

I work in IT.
So deep down inside... I must be a nerd and a bit of a tech head.

To keep myself from talking about Tech on my main blog I've created this site to deal with tech issues.

I work full time as CTO for a financial services company, and supervise a team of top notch developers and support personel, so on this blog I'm going to be dealing with some general technical issues, along with some more hairy tech issues which we end up dealing with on a day to day basis.

Let the fan-boy-dom begin... not really... but you get the picture.