digitalBush

Earlier in the year, I pledged to lose 50 lbs as a new year's resolution.  Three quarters of the way through the year and I've not quite made the progress to meet this goal.  Let me explain what came to be with this goal.

I started off the year strong with a heavy diet and then mixing in a running program.  All was well and good until I jacked my foot running.  I learned a very valuable lesson about letting your running shoes wear out.  At the point when this happened, I had lost 20 pounds.  I was forced to quit the running regime and I basically lost motivation to stick to my diet.  I gained back 11 lbs over about 6 months. 

Three weeks ago I got back on the horse with the help of Ashley and a generous workout to the max machine donation from Brandon.  I've lost 6 pounds since then and am still making progress while keeping my morale up.  I'm still being gentle on my foot so I don't mess it up again. 

So, here I am with 3 months to go and 35 pounds to lose to meet my resolution.  I don't think that's possible, but I'll keep chuggin' along to see where I end up.  At this point, I will be happy with losing 35 pounds for the year which leaves me with 20 pounds to go.  I'll keep reporting progress.

I keep seeing mention of this obscure .NET language called BOO and I had to check it out.  I haven't delved into it very deep yet, but I like what I'm seeing.  Of course, I'll actually need to write some code with it in order to really get a feel for it.  Regardless, I wanted to touch on a few things that spoke to me with the syntax.

• It has a python feel to it.  Years ago in college we did some code in Python.  I really like how python gets rid of the braces and instead uses indention as it's scope identification.  That style of coding forces a certain aesthetic which I like.
• Built-in literals.  Seriously, if I have to type "Regex something=new Regex(@"^\d{10}");" one more damn time, I'm going to scream.  Why can't the c# spec support "/^\d{10}/" just like other languages.  Oh yes, the shorter syntax for arrays, lists, and hashes are nice too.
• String Formatting.  It's like a mini template system.  "Hello, my name is ${MyName}" looks so much nicer than String.Format("Hello, my name is {0}",MyName).
• Syntactic Macros and Attributes.  I'm not sure what to make of this, but it looks insanely powerful.  Anything that means I can write less code sounds great to me! 

Once I have an opportunity to write some code with this, I'll report back my findings.  I like code brevity, and I am encouraged by this find.

It's a rare thing for me to find something that I like so much that I'm willing to blog about it.  Hell, it's a miracle that I'm even blogging.  With that said, Ashley and I stumbled across a program online that has helped make out lives a little easier. I'll give you the gist of it and give you a link at the bottom of this post.

e-Mealz is a weekly food plan that has done 3 things for us.  It's helped us watch what we eat more closely.  It's lowered our shopping time at the store.  It's also saving us money by us not eating out so much.  It costs $15 for 3 months and you get a new meal plan every week.  The meal plan consists of a menu and a shopping list of items you'll need to prepare that menu.  The shopping list is broken down by section like frozen foods or produce.  We're currently doing the points system for 2 at any store.  We've been doing it for a week and it's really impressed us.

If you are interested, then you can click here to go to the e-mealz.com website.  Please note that this is a link that will give me some credit if you decide to sign up.  If you don't feel like giving me credit, then you are more than welcome to just type in the URL directly.  At any rate, I encourage you to look into it or a similar program.  We've been preparing our meals the night before and then it takes us 20 minutes max when we get home to produce something edible on the dinner table.

As an aside, I have become re-acquainted with my commitment to lose weight.  This week was good for me due to actually getting off my bum and exercising.  I'll be posting more about it as I go along.  Right now I need to get some shut eye.

All you need to do is show up at my house, and you are basically guaranteed to not sell me something.  I don't like loathe door to door salespeople.  This is especially true if said salesperson talks slang and refers to me as "daddy".  Thanks, but no thanks.  Please go find some other sucker to buy your universal cleaning product.  If I believed that shit, then I'd buy the junk that Billy Mays sells on TV.

The exception to this rule is, of course, the girls scouts. Mmmmm, I love me some Samoas.

I've been out of academia for 3 years now and out in the real world.  Since then I've had the opportunity to get to know several developers from all over.  In some of my discussions I've had the opportunity to compare backgrounds and experiences.

As far as I can tell, there are 3 different paths that lead someone to a development position:

• Computer Science Graduate - Emphasis is on lower level concerns.  Coursework involves more study of principals and algorithms than following the latest tech.  The software projects reproduce things that exist already.
• Business Applications Graduate - Different universities call this different things like Management Information Systems and Computer Information Systems.  Regardless of what you call it, the coursework is geared towards tackling problems associated with the business concerns and generally nothing lower.
• Old School Tech Junkie - These people have differing backgrounds, some with formal education and some not.  Most I've encountered do not have the formal education, they've just seen it evolve and happened to be there when this whole birth of tech came about.

Where do I come from?  I'm the CS graduate who learned the nitty gritty mind numbing details about computer systems and software.  I had to code the standard structures like linked lists, stacks, and trees.  I had to code basic libraries like those for string handling.  I had to even write my own TCP stack and a basic OS.  Why?  Well, I know now that it's because I needed to learn the limits of the hardware and the environment.

Am I writing kernel code?  Nope.  Am I writing device drivers?  Nope.  I write business applications.  I feel that my education makes it easier for me to do what I do.  What I've found is that a majority of people produce inefficient code because of a lack of understanding for what's happening deep down.  Managed code hides all of that gory stuff from you and if you've never seen it, then you just don't know it's there.  This is where all that "junk" I learned really starts to help out.

Hmm, let's see... I'll loop over this file right here and build a query for each line.  I'll start with a string and concatenate everything I need to it to generate my query.  Then at the bottom of this loop I'll execute that query and store the results into this list over here.  Then when I'm done I'll loop over my list and write it to a file.

That code will get the job done just fine for small sets of data, but it can break down when it needs to scale.  When that 10,000 line file becomes a 1,000,000 line file, that 0.5 second loop times will stretch an hour job to a week long job.  And that list where you were storing the results?  Oh yeah, it got too big to fit in memory, so now the OS is wasting more time thrashing the page file to and from disk.  Don't forget that the database is struggling with those non-parameterized queries trying to figure out an execution path for each one. 

I'm not the smartest person in the world.  I know there are people from all backgrounds who can code circles around me.  That's not what I'm trying to convey here.  What I am trying to say is how important it is to understand what is actually happening behind the curtain for that line of code you just wrote.  Do you understand the implications of what you are doing there?  If you don't, then you better learn it before your boss finds someone else who does.  If you do know it, well learn it some more because we all make stupid decisions in code.  Later.