Tech Blog

Jay's Technical blog

The Job Hunting is a little like Church Hopping...

31 August 2005
Jay Kimble

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

For those who don't know, church hopping is a practice that some Christians (I don't know about other religions) do to find a new local congregation to attend.  While it is sometimes necessary (for a number of reasons) to do this, sometimes folks do it only because the current church is not as exciting as it once was; there are a number of good reasons that people leave a church and move on (don't agree with Theology/practices of the church is one good one, but there are others). 

The quest is usually to find a church that is to find a place with better music, a more exciting service, etc.  What ends up happening is that these people (these "church hoppers") bounce from place to place to place.  The types of "exciting" churches tend to do more redistributing of parishoners instead of converting.

As someone testing the job market (still) and helping to find good people in my current job, it seems that this same type of practice goes on in the IT industry.  When you are interviewing a candidate, you can't get it out of your head that there is a reason why this person is moving on.  Of course you can ask and you'll get some kind of sanitized response that will hint at the real, but it won't tell you the real reason.  You won't know that until at least a month after you hired the person.

Interviewing a potential employer is even more like this.  You can't escape the fact that if you are applying for a position that someone previously occupied that there was a reason they left.  You're not sure if they were just on the quest for more money/more excitement or if they left for a really good reason and that you shouldn't even think about going there...

Sometimes I wish we could set up a blacklisted company site where people who are leaving their positions could report on why they left in medium detail (for instance, "This company is too *@%^ cheap for me... they wouldn't by me an MSDN Universal Subscription for my personal use" or "my manager Brendan Tompkins is freaking moron and shouldn't be allowed to manage developers." (BTW, apologies to Brendan for misusing his name). If I could look a company up then I could use the info to make a real decision instead of having to try to guess.  Eric's questions help in this regard, but they don't solve everything)


DataSets and Services

24 August 2005
Jay Kimble

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

My co-worker, Rob Teixeira, MVP (he makes me put those three characters --"MVP-- in if I'm going to quote him), sent me a nice little tidbit today in email.  It's a performance assessment (I won't call it a test) of the Enterprise Services vs. TCP Remoting vs. XML Web Services.  The Article is here.  The article does not describe the results of a perfect performance test, but it attempts to try to give developers an assessment of what technology does a better job in the performance category in certain situations.

The article itself is a little confusing, but there is a nice little discussion of DataSets after the "Figure 6. Retrieving the Northwind product catalog as a DataSet" graph.  Rob quoted a line from the article, but (since this is my blog) I like this quote even better: "It's clear from the results of this test that returning DataSets from service to caller decreases performance significantly—by around 75% for the binary transports!" 

I'm a lazy coder which is why I use business object.  I don't want to have to go back and redesign my app that was using DataSets because a new requirement that specifies that I have to retrieve data from a Service instead of directly from the database.  And I'm still lazy in this in that I generate the business objects direct from the Database.


D-Link DSM-320RD MediaLounge/Hauppage PVR-150 Review (or how to build a cheap PVR setup)

18 August 2005
Jay Kimble

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

[Update I fixed the URL for gbpvr.com]
My birthday present from the How To Select Guides (AKA Mike Schinkel and Mike Gunderloy) was a D-Link DSM-320RD AKA D-Link's MediaLounge with DVD capabilities (NOTE: Mike S and Mike G didn't actually purchase this for me, it was a result of my payment for the writing I did for the email components guide which is coming soon).  This appeared to be a nice addition to my Hauppage PVR-150 capture card (which was my birthday present from my wife and kids).
My Goal
I don't ever want to miss 24 again, and I don't want to care whether Fox is airing it for 2 hours or for a single hour.  I want to simply point some kind recording mechanism at the show and say record this always.  I also don't want to mess with tapes of any kind.  Sounds like TiVo which is true, but I really could care less about watching live TV (unimportant); I just want to know that when I sit down to watch TV that there are programs to watch.  AND, I want to watch on my television and not my computer.
The Hauppage PVR-150
Wow!  That's really all I can say.  The Hauppage card has a built-in hardware MPEG encoder, so the unit records TV straight to MPEG.  It comes with a remote which I have yet to need.  My goal was to get a setup so that I can record television to video files without slowing my desktop to a total crawl.  I had an ATI capture card which was adequate, but the software that I was using kept flaking out on my card with each new release.  Speaking of the software
Software
The Hauppage comes with adequate software to basically replace the VCR, but I wanted something more sophisticated.  The ATI card I had been using came with a little better software, but I wasn't thrilled with the fact that everytime it recorded, my desktop was not extremely responsive. 
As a result I have been toying with Media Portal (which is open source).  This is the stuff that a lot of people are talking about.  I recently gave up on it because it seems that each release either breaks some functioanlity or some aspect of the configuration is harder, etc.  Just my opinion, you may find things different. 
I am now using gbpvr (www.gbpvr.com).  This seems to be way easier to use and configure.  I am totally thrilled.  It even has internal hookups to Zap2it (the free tv listing service), so there's really no need to play around with xmlTV (a script that downloads the listings and puts them in XML).  I'm getting ready to play with some of the plugins to see if I can get the auto-commercial remover script and to re-encode to xvid to save some space. 
BTW, both Media Portal and GB-PVR were written in C#.
D-Link DSM-320RD MediaLounge
The role of the DSM-320RD is to wirelessly pick up my video, music, and pictures on my desktop and transmit them to my TV/Stereo setup.  It is a UPnP client that talks to UPnP media servers running on your desktop.  Once again I quickly realized that the bundled app might not be the best.
This is still a bit of an experiment for me.  Like most reviews that you will read, I found that pictures and music work smoothly, but video can be a little choppy.  I've started using Tversity (tversity.com) as my Media Server.  It does the standard music, pictures, and video, but it also adds some links to media on the internet.  I just recently read that there is a way to hack their list and add a few of your own.  It will also re-encode the video on the fly to get a bitrate that the 320RD can handle.  I still get video stutters, but this seems to be only when my main machine is recording.  I will probably move the media server to a different box which should fix the problem... now if I could only build plugins to the media server.  I'm pretty excited about this one (it's really cool). 
The 320RD has one other feature that makes life a little better.  Remember that DVD Player?  Well you can burn video directly to disc and drop the disc in the player.  Video played in this manner has no stutters at all!


One CodeSmith Template Shall Rule Them All...

18 August 2005
Jay Kimble

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

I just finished building the ultimate CodeSmith Template for myself.  Let me give a little back drop to this.

I have a Data Access Layer Template that I simply point the template to all my select, list, and CRUD (Create, Update, and Delete) Stored Procs and it builds the following classes for me:
1) SQL data communications - the only place in my code that communicates with the database server
2) Data Bus Object - a class that represents a single row from the Stored Proc
3) Data Collection - a collection containing the previously generated bus object
4) Controller - a class that is used by the GUI to communicate with the other layers; it exposes all the actions that can take place on the data (Create, Update and Delete)
[I have a couple additional classes I will be adding, but for now this is what I have]
I have come to a place where I need more actions than the standard select, list, create, update, and delete.  Sometimes I have a special update that only updates a single field, or where I need to maybe get all the IDs that are ready for the next step of a workflow (trying to be very generic in my explanation here).  Anyway, what I ran into was that I want more actions than I'm currently accounting for.
To solve this problem, I created a new CodeSmith template to create My Data Access Layer Template; in short a template that code generates other templates. 
Here's how to do it.  First of all start with a working template.  What made things easy for me was I created a constant that represents the start and end script tags (<% and %>) in a string like this:
<script runat="Template">
 Const __b as String = "<%"
 Const __n as String = "%>"
</script>
Or in C#
<script runat="Template">
 const string __b = "<%";
 const string __n = "%>";
</script>
Next, I changed all the occurrences of the "%>" to "%%>"; now you can do a search and replace on "<%" and change it to "<%=__b%>", and finally you can do a global search and replace on "%%>" changing it to "<%=__n%>."  Now you have a template that will generate another template.

Simply edit like you would any other template.  You'll have to remember that the stuff between the "<%=__b%>" and "<%=__n%>" tags will be script in the new template and that the editor won't highlight this.

Pretty nifty if I must say so myself.


Security and AJAX (an AJAX musing)

16 August 2005
Jay Kimble

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

Michael Howard (one of the Author's of Writing Secure Code) says that there are 2 types of security problems: those involving untrusted input and everything else.  It's true.  Most of the security issues that we face and have to deal with in our code can be dealt with by validation checks.  One of the things that AJAX lets us do is blur the lines between client and server.  This is really cool, but don't forget to validate your data on the server. 

Now some of you may be saying, but are you saying that I should never do validation on the client?  The answer is no; client validation is a usability feature; it makes your app friendlier to the user.  But, don't trust data coming from the client that is only validated by client side scripts.

I know this can be a pain, but remember that hackers can easily take control of your app with an attack proxy; this means that by simply examining the traffic flying back and forth a hacker could determine the right values to change to manipulate your app; a hacker could also make changes to data returning from the server to cause your app to behave in an unexpected manner (be careful).

Therefore you should avoid sending user names, passwords and other security related data over the wire between the browser app and the server (I know you knew that).  You should also make sure that the client is not making security decisions.  I have seen where people have sometimes filtered data on the client app based on credentials passed to the browser from the server; all of which was done with Javascript... be very careful!  Don't offload security logic to the client, ever.