Tech Blog

Jay's Technical blog

DLRScript Project - Revealed...

26 February 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

[You know I hate making announcements... It seems like my expectations are always higher than what actually happens.  I've announced stuff before that I thought was somewhat impressive -- maybe not though-- with like zero interest]

This weekend I created a new project over at CodePlex called "DLRScript."  I put this ominous description - "DLRScript is a SilverLight 2.0 sample using the DLR. It is based on the DLRConsole found in the sample in the SilverLight 2.0 SDK, but with a new advanced twist (check back here for more info later... I want to be the first to do this which is why I'm mum on the subject) "

Background

So let me tell you the background.  I recently was pondering the new upcoming beta of SilverLight 2.0 (something I have been waiting impatiently for a year).  I started thinking about some of my past demos and playing around with it.  You see I have been using it to get rid of JavaScript altogether and replace JS with C#.  I contemplated creating a project for that functionality a few months back, but with SilverLight 2.0 so far away it didn't seem like a great idea at the time.  I also have begun recently playing with some of the DLR languages.  I have to say that I really like Python (I wish I was better with it), and Ruby is very intriguing to me as well.

I started thinking about how with SilverLight 2.0 we could actually add new languages that could be put into a script tag.  So I built it..

A picture is worth 1,000 words

Here's whit it looks like-

  1:<scripttype="DLRPython">
  1: 

											
  2: def clickHandler():

											
  3:         DomHelper.alert("Hello from Python")       

											
  4: eh = DomHelper.createEventHandler("clickHandler")

											
  5: document.GetElementByID("clickMe").AttachEvent("onclick", eh)
</script>

If you look closely I have a custom object called DomHelper.  The reason that exists is that I am currently having problems adding namespaces (but I can easily add variables to the script environment).  DomHelper knows how to do a couple things. Send Alerts, and Create An Event Handler from a method name (there are others, but I need to work on them). 

That "document" variable is not the standard DOM document, but a reference to the SilverLight environment's HtmlPage.Document.  Right now I am having problems with setting the property values of DOM Element (I will be fixing that soon).

Why did you do this (JavaScript is fine)?

I'll blame George Tsiokos again (he was the one who told me he didn't want to have to extensively know JavaScript).  I personally don't like that we web developers need to be fluent in a bunch of things : HTML, Language on the Server (be it C#, PHP, python, or Ruby), CSS, and JavaScript.  I know that the markup stuff is fairly simple for most of us... it's having to be fluent in 2 languages is what stinks.  So my goal is for a Ruby on the Rails developer to be able to use Ruby both client-side and server-side.

Some caveats (it's an alpha what do you want?)

  • You need to have the SilverLight 1.1 Alpha Refresh (from September) installed.
  • The project is a VS2008 project so you'll need that and the VS2008 Tools for Silverlight alpha (I think this came out in December)
  • I have exactly 1 DLR language working: Python. 
  • I will try to get Ruby working shortly. 
  • I have code in place for DLRJScript, but it doesn't work (I'm getting an initialization error). 
  • I don't have the files to try VBx.
  • Everything will change after Mix and the release of the beta (unless someone from MS wants to give me a pre-release <wink />)
  • The code is a mess right now, so consideer it a rough prototype (that works)

Future Plans

  • Get ALL existing DLR Languages working (the one I haven't mentioned yet is IronScheme... are there others?)
  • Improve the support for all the basic JavaScript environment functions (prompt, setTimeout, clearTimeout and eval would be nice to actually have working)
  • Be able to fully traverse the DOM (this may be working... I just may need to figure out how to get it working... a gold star to anyone who figures it out before me)
  • Be able to load modules from the file system (setting a the source attribute for a DLR Language)
  • Come up with a sane way to compress a python (or other language) script (maybe there already is a way that I don't know about).  Python appears to be a little more chatty (and being able to minimize the download)

The project will be available to download shortly...


Clarification on POUT... POUT != Test Last...

21 February 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

[Editted this... sometimes I need to turn off the "smack down" and resist the urge to do what appears to be flaming... I didn't really mean to] 

Ok, I'm throwing this out there for Jacob.  I just read where someone created (an excellent article on) yet another Testing acronym.  The post, BTW, is well thought except that I THINK he misses the point of what POUT is (and he has comments turned off so I can't slap him for missing Jacob's point).  He lumps POUT in with the test-last crowd (which I know I am sometimes a part of).  He claims that POUT is a subset of his new acronym which takes into account both testing first and testing last.  POUT according to Jacob's excellent post on it is Automated Unit Testing at anytime (so it could be TDD, or TAD).  The actual quote here is this

"I think some of the confusion with TDD discussions is that TDD is an intensified version of POUT." 

So TDD is a form of POUT [again, this is my interpretation... Troy feels that Jacob leaves some doubt... and Jacob seems to back that up, so again... I need to throw away the flame thrower sometimes... forgive me]. Jacob wanted to bring to light the fact that Unit testing is good in whatever form you do it, and the study that he tore into really proves that. 

That said Troy's article is pretty good... he [debatably] just misses the point that POUT and TSD (his new acronym) really mean the same thing...

Unit testing is good for your dev. work.  So now everyone go back to your coding (and hopefully POUTing).


On Hiring a Brainy Developer...

20 February 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

I recently have been reading some interesting posts on hiring.  I've seen people talk about hiring specifically for your project (so tailor the minutiae questions reflect your needs...)  Seriouly some of the stuff I have seen suggested seems dumb to me.

All this has gotten me thinking about a time when Erik (the architect at one of my last jobs) and I (Dave Balzer may have been in on it too... I forget) were interviewing this guy, and we were desperate we had projects coming out our ears and not enough people to work.  This guy comes in and he's brilliant... I mean that.  He answers every question and he obviously know some things that none of us know... I'm falling all over myself... we need this guy. 

Everyone agrees except Erik.  You see Erik sees something that I didn't and Erik hired a little differently than I did as well.  Erik looks at the person and says to himself "will this guy be a good fit for our team." Not is he brilliant enough to work here... not how good is he.  Erik asks is he a good fit for the team... so in other words does the guy's personality work for our group.

Erik said no, and we outvoted him.

So you know who got to work with this guy... me.  One of the things I missed is that the guys personality was a little grating.  and he seriously clashed with... me.  To say that we got along great would be an absolute and horrible lie.  When the guy's name comes up today... I cringe.  Because he was a bad guy?  Nope, because (unfortunately) the Dev Theologian is human and sometimes there are some people that you will just have a hard time getting along with.

The guy seemed to have a know-it-all attitude which created some additional struggles.  The guy was/is brilliant.  Make no mistake.  Would I hire him tomorrow?  Depends on what I needed him for.

The bottom line is that I hire for what I need.  You need a senior guy/gal to come mentor your junior guys/gals then make sure the guy will get along with your group (and then make sure s/he is technical).  Need someone to work on a project?  I'll always take the less technically adept person who fits in... Need someone to do rocket science?  Hire someone who can do that, but try to find someone who can work with your team... it's all about your team.

Need an partially off-site consultant to come in and help you? Hire me!  [sorry I got carried away there... just kidding... but I am available for work right now though].


JScript and HashTables...

06 February 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

About a year ago I released HashTable within my little library of MS Ajax Clientside goodies (AKA the DTAjax project over on CodePlex).  It's been awhile since I've visited with that code (and honestly I didn't look at it today).  When I released it I mentioned that I had a HashTable.  Someone almost immediately responded to me asking if that was really necessary since JavaScript already could do that.

I never really answered the question because... uhh... well... I didn't really have an answer.  You see there's a feature of JavaScript that I had either forgotten about or learned in the last year (not sure which... surely I knew this back then).

All this came back to mind the other day when my friend Tim (he has no Tech blog) asked me a JavaScript question.  The essence of his question was this:

I have 4 arrays that I want to provide dynamic elements for via script.  I want to easily switch between them and access element of whichever array I currently need.  The switch between arrays will be triggered via a value in a drop down, so all this has to take place as the result of an onchange event.

After thinking about this (and answering incorrectly, because my ADD kicked in and I answered the wrong question), I came up with code similar to this:

  1:// Tim's Code (sort of)
  2: arr1 = [1,2,3,4,5,6,7,8]; // I believe Tim was setting each array element
  3: arr2 = [0,2,1,4,2,6,3,8]; // individually, but you get the idea
  4: arr3 = [1,0,3,2,5,4,7,6];
  5: arr4 = [9,7,6,5,4,3,2,1];
  6:
  7:// Jay's code
  8: MasterArray["arr1"] = arr1;
  9: MasterArray["arr2"] = arr2;
 10: MasterArray["arr3"] = arr3;
 11: MasterArray["arr4"] = arr4;

That MasterArray I created is a dictionary, but i believe if you check it's type it will say that it is an array.  Pretty cool, hunh?  This makes it a little easier to organize your data in JavaScript. (I didn't say it made everything simple).

So back to the initial question do you need a HashTable in JavaScript?  Sometimes you do.  To my knowledge you can't pull the key array from the MasterArray that I created, and sometimes you want that.  Having some kind of object that associates an array of keys with an array of values can be helpful.

[BTW, thanks for the question Tim]


ORMs... Their Real Benefit

04 February 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

This is kind of a strange post from me, but I've started thinking about some things in regards to ORM products due to my fun with LINQ To SQL.  First of all, I'm not sure LINQ to SQL has this benefit (I could definitely be wrong about this), but I'm pretty sure that LINQ To SQL Entities does have (again, I don't speak as one who knows).

The difference is caching.  I know that NHibernate has some strategies for caching your data, as does something like LLBLGen (I checked... I don't want Frans coming down on me).  I'm pretty sure SubSonic has it (although I've let some of my skills in that area lapse a little).

I would argue that this is the one thing that ORMs do better than custom made DALs.  Don't believe me!  Ok, let's think about it...

Both ORMs and traditional DAL layers offer the ability to abstract the database away from us.  I can simply make a call and get back an entity from the database.  What if I'm in a web app where I'm doing multiple things... I need to load up the data to present it, and I need to look up the data to repopulate an object and then make changes based on the data that has come in... or maybe I need to load some related object...  You get the idea.

Here's the part where ORMs excel IMO.  An ORM that supports caching will make a single SQL call and will cache that data for the duration of the web call.  That part is easy and a programmer carefully crafting their DAL will be able to manage the same effect (provided they are looking to optimize the code). 

Some ORMs (and probably not all) have the ability to cache within the entire web application which means that a single update to an object will be reflected across the entire application.  Again, this is possible for a conscientious developer to do... but it's starts to get a little more complex. 

What happens if you have a team of developers working with you?  Can you guarantee that the next time someone has to work in your file that the caching of entities will be appropriately handled... I doubt it (unless you wrote your own ORM).