Tech Blog

Jay's Technical blog

Parallel Thoughts...

30 November 2007
Jay Kimble

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

[Warning this post may jump around a bit... ]

I was reading Rick Strahl's assessment of "What's Ailing ASP.NET Web Forms?"  Rick ends with the idea that MVC is probably not the answer although it solves an issue that we have at the moment.  He mentions that maybe MS should invest some time into creating a new Web Framework.  I was right there with him.

From there I moved over to looking into the new PLINQ stuff.  That's Parallel LINQ.  This got me thinking that our code isn't necessarily written for modern day (multi-core) processors.

Our machines simply can do multiple things at once (at least that's how I understand it).  I read an article about a year ago that talked about how we need to start considering that when we write single threaded apps we are not taking full advantage of the processor.

I'm sure things like the Windows Forms Event model takes advantage (somewhat) in parallel processing.

Regardless if it does or not I've been thinking about what an app look like that took advantage of multi-core's ability to process multiple threads at once (if that's possible).

I can envision something MVC like.  Where the main thread kicks off the data process (which might in turn kick off additional threads) where entities are built and then dropped off into some common area (I know my terms are all wrong) where the main thread simply waits to pick up the data and display it. 

Saves would happen in a similar manner in that data would be handed off to the data processing thread and a complete, or error is the result. 

Anyway, I'm talking about stuff that I'm not that well-versed in, but I can dream some interesting app frameworks that would be multi-threaded at their core.  Although I'm not sure how useful something like this would be for web frameworks...

I'll admit I like ASP.NET even though I have encountered my share of warts with it... MVC still seems like a lot more work for minimal bang for my buck... although I can see it's usefulness in complex apps.


Generics are better than Collections...

27 November 2007
Jay Kimble

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

At least that seems to be true for Mono

Basically not to rehash too much of Miguel's post (and Rob might be the only other person who truly cares)...  Miguel did a few tests with Generics and found that for Value Types, Generics have a much smaller memory footprint than things like the ArrayList (I knew there was a reason I liked Generics!)

He actually quotes a comment by Rico Mariani (on an MS Blog).  Rico is an MS Employee (I think).  He mentions that basically the only problems with Generics are that in memory the code for the framework code is duplicated (Jay's translation which may or may not be fully correct).

The idea is this.  When you create an Arraylist there is a lot of code that goes on underneath the covers to deal with the object data type.

When you create a Generic List it (the JIT compiler) creates a memory array of your type plus adds the method calls... that all that the code is.  Doesn't seem like that big of a deal, but knowing what the type is makes for writing the code much easier/simpler.  Again this is just my interpretation.

But what it means to me is that "Generics Rock." (and I already knew that... I don't need to be afraid of using them).


Using LINQ to Query the Command Line args

26 November 2007
Jay Kimble

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

[I just happened upon this one.. this is pretty cool (not sure how it performs, but then again you are probably only talking a few cycles difference)].

I typically parse command line arguments like this:

  1:// Class/Namespace deleted for brevity
  2:staticvoid Main(string[] args)
  3: {
  4:bool AAArgumentExists = false;
  5:foreach(string arg in args)
  6:     {
  7:switch(arg)
  8:         {
  9:case"-aa":
 10:                 AAArgumentExists = false;
 11:break;
 12:// Additional cases follow
 13:         }
 14:     }
 15: }

 

Today, I just started thinking about this code... I really don't like it.  It doesn't really evoke what I want to say.  I want my code to say "does such and such argument exist in the string array."
Using LINQ we get a cleaner (in my opinion) variation of the above and it "says" what I want it to "say."

  1:// Class/Namespace deleted for brevity
  2:staticvoid Main(string[] args)
  3: {
  4:bool AAArgumentExists = (from arg in args
  5:where arg == "-aa"
  6:                                   select arg != "").FirstOrDefault();
  7: }

Of course something else I tend to do is have an argument for passing in a  date value (just something I seem to run into on a regular basis).  Here's the code snippet to do that (I wish it were a little more terse... but I'm still a newbie to LINQ).

  1: DateTime RunDate;
  2: String RunDateString = (from arg in args
  3:where DateTime.TryParse(arg, out RunDate)
  4:                         select arg).FirstOrDefault();
  5:if (RunDateString == null || RunDateString == "")
  6:     RunDate = DateTime.MinValue; /* Or whatever default value you want to use */

BTW, the above technique could be applied to a number of other data types.


Javascript - Public, Private, and Static

26 November 2007
Jay Kimble

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

Ok, I recently wrote a post on js closures which was mostly correct.  The post itself was mostly correct, but I implied rather heavily that JS created objects could not contain private values.  Luckily my readers are smarter than me and correct me on it.

What I want to do in this post is lay out how one achieves various OOP scopes.  So here we go (it's all code):

  1: myFunction = newfunction() {
  2:var privValue; // private field (using var in constructor)
  3:this.pubValue = null; // public field ("this" in  constructor)
  4:
  5:var privFN = function() { // private function (using var in constructor)
  6://Do something here
  7:         }
  8:this.pubStaticFN = function() { // public function ("this" in constructor)
  9://Do something here
 10:         }
 11: }
 12:
 13: myFunction.statFN = function() { // public static function (attached directly to "class")
 14://Do something here
 15:     }

 

I had forgotten how I had gotten statics before so I used Script# to have it generate me a mock class.  Insterestingly enough, it doesn't use the "var" keyword to make things private.  Also,in my experimentation with making something private I discovered something that would have let me call a private (but very indirectly).

I could actually get to the text of the constructor relatively easy (in the above example it's myFunction.toString()).  And the text for the private function was there... it probably would be possible to build a parser to find out what's actually in the constructor, and then you could always add your own function to the class so that you could call the private function. 

Many of us are .NET guys so we understand about reflection and we are more or less OK with it (there's not a ton you can do about it... and for the most part no one wants to call a private function... unless it's something useful in the CLR).


CTE (Common Table Expressions ) behavior

21 November 2007
Jay Kimble

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

Hey, VS 2008 shipped 2 days ago... so in honor of that I'm going to talk about something that shipped with the last version of SQL Server (SQL 2005).

I recently discovered CTEs via Eric.  You may want to read one of the following articles to learn about them: John Papa or Scott Mitchell.

I have begun to use them within Stored Procs, but they seem to be very finicky as to where they go. witin the proc.

This is what I discovered.  They work great but you can use one at a time.  That means that you can use a CTE to define another CTE (you are effectively using the first CTE).

If you try to use a second CTE without using the initially created one you will get an error.

Also try something like this (with a real table and a real field):

 

  1: ;WITH myCTE(AccountID) AS
  2: (
  3:SELECT RealField
  4:FROM RealTable
  5: )
  6:
  7:SELECTTOP 10 *
  8:FROM myCTE
  9:
 10:SELECTTOP 100 *
 11:FROM myCTE

You will get an error on that second statement.  Why?  Well I believe that CTEs are tied to the next SQL statement. You will actually get an error if the next SQL statement doesn't use the CTE.

So to use CTEs with the above statement you have to do something like this.

  1: ;WITH myCTE(AccountID) AS
  2: (
  3:SELECT RealField
  4:FROM RealTable
  5: )
  6:
  7:SELECTTOP 10 *
  8:FROM myCTE
  9:
 10:-- CTE is only used once... so if we want to use it again we have to define it again
 11: ;WITH myCTE(AccountID) AS
 12: (
 13:SELECT RealField
 14:FROM RealTable
 15: )
 16:
 17:SELECTTOP 100 *
 18:FROM myCTE

I would not call the above an ideal scenario.  CTEs definitely make your code more readable, but defining them multiple times doesn't seem like a great solutions.  I would say you would be better served with a View, Table function or something like that.

Scott Mitchell mentions some advice in his article that I would wholeheartedly agree with: "Common Table Expressions offer the same functionality as a view, but are ideal for one-off usages where you don't necessarily need a view defined for the system."