Jeremy's Blog

It’s certainly been a long time since I’ve felt motivated to post anything here. I generally don’t like talking about what’s going on in my life except in small blips, most of which are suitable for Twitter. Using this blog as an outlet to talk about just me or life in general feels like a waste when there’s much cooler stuff I would rather be talking about. Those of you who are looking for life updates can get them from Facebook or Twitter. Those of you who are looking for information on the cool stuff that I’m working on, stick around.

I’ve finally decided that I’m going to take an active role in getting myself out of this almost year-long development-less funk that I’ve been in. I’ve been pouring over information and ideas, trying to come up with something that I could spend my time on and make a personal project of. I actually came up with a few. They’re all Omega Vortex projects from back when we were trying to bootstrap a software company by consulting. The projects never got enough attention because of the consulting and we started to enter the really nasty area of the recession, so the consulting projects also started drying up, leaving us without enough income to allow us to move forward …

(continue reading…)

This probably isn’t the most elegant or efficient method of doing this, but I needed a way to perform an “ArrayShift” on an array in C#. There’s no built-in method to do this, so I wrote up and dropped this method in my ToolBox:

/// <summary>
/// A C# implementation of "ArrayShift" this is a generic method that
/// will take an Array of T's, shift one off of the beginning of the
/// array and return it.
/// </summary>
/// <typeparam name="T">The type of array.</typeparam>
/// <param name="array">An array of T's, will be modified to remove
/// the first element.</param>
/// <returns>First element of array.</returns>
public static T ArrayShift<T>(ref T[] array)
{
   T first = array[0];
   IList<T> list = array.ToList();
   list.RemoveAt(0);
   array = list.ToArray();

   return first;
}

It’s a quick and dirty way to accomplish what I needed. If anyone has a better method, I’m open to it.

As classes and consulting work at Omega Vortex keep pushing me more and more into .NET development, I thought it would be a good time as any to try to start learning new things and try to keep my mind working on this stuff. I decided to start looking for an Open Source project that I could contribute to.

After noticing someone on Twitter mention a LINQ to WMI project, it seemed like the perfect fit. LINQ (Language-Integrated Query) is something I’m not too familiar with and want to learn. While I’m somewhat familiar with WMI (Windows Management Instrumentation), it’s huge. There’s still plenty left to be learned about it.

I’ve become a developer on the LinqToWMI project at Microsoft’s CodePlex and I’ve already made two major updates for those who are interested. One of which is the ability to generate “Commonly Used” WMI classes instead of just generating the ones you need one at a time. The next is a major speed enhancing change on the ClassGenerator.

It came to my attention while testing the project that it would crash with a NullReferenceException if there were no instances available of the class you wanted to generate. (Example: It would crash when trying to generate a Win32_FloppyDrive class. My laptop has no floppy drive.) In re-working the generator to not use an instance to generate code from, we gained a pretty huge speed boost from not having to search for an instance. Before, it took about 4 or 5 seconds to generate around 15 classes. Now it takes a fraction of a second.

If you’re needing to use the WMI on a project and want an easy way to query it, give this project a shot. If you think it’s good, help us out by contributing patches or bug reports so we can make the project even better.

Even vague ones … and I mean really vague.

Quite a while ago, Omega Vortex adopted a policy that we would refrain from announcing specific release dates. We won’t even narrow it down to a month for you. There’s quite a few reasons that we do this.

We’re a startup that’s bootstrapping from consulting work. At any given time, said consulting work currently takes priority over all other things, because we have to make money in order to pay bills and keep developers paid. That’s all fine and dandy, but while we’re having to focus so much on consulting, software isn’t being written. This is eating us like the plague. We’re presently amazingly profitable, but not in the way that we want to be. No matter how good our scheduling is, it doesn’t make a difference because we’re constantly having to drop everything to invest time in a new consulting project.

On the plus side, we’re about to simultaneously release a new product that hasn’t been announced yet along with updates to two other products that you may already be familiar with. No matter how close we get to that day, we’re not going to tell you when that day will be, in advance. All of our releases are marked by quarters. Any one year is divided up into three month quarters. Q1 is January – March, Q2 is April – June, Q3 is July – September, and Q4 is October – December. That means that when we mark a release as Q3 of 2008, we could potentially release that product at any point within those three months. If we’re expecting to release in September, we’ll actually really say Q4 so that we have three extra months worth of time buffer to use in the even that something goes wrong. If we happen to meet our goal of September, we just managed to release an entire month early.

Three months of buffer is a pretty decent amount of time. Sadly, because of time constraints with our consulting work, we’re still having trouble meeting those release dates. OmegaVerge has suffered considerably because of this and it has allowed competitors to get a jump on us. (Speaking of OmegaVerge, I’d like to give a shoutout to Ben Babcock who actually managed to help me with a SimpleXML issue by letting me help him with a SimpleXML issue. We now have type-safety/inference of IP.Converge methods in OmegaVerge since we solved that issue, instead of having to pass around SimpleXMLElement objects. Thanks, Ben.)

If you’re a software development shop and, like us, you can’t dedicate 100% of your time to software development, don’t announce release dates. Even vague ones. Surprise people. People get incredibly antsy / angry when you don’t meet release dates.

Oh, and if you have a historic trend of lack of ability to execute, don’t try to say things like “this summer” or “next month” … I’m guilty of this too, but this is a practice that really needs to stop. I’ve seen so many projects say “next month” and it take so much longer than that. Two in particular have me facepalming, right now …

Most of your [code] comments are unnecessary.

Don't ever tell a developer that. Especially, one that is learning. Code commenting is one of biggest components of code maintainability and there are simply not enough developers that do it enough. The thought that someone really would instill the thought that comments are unnecessary really peeves me. I've had so many problems over the years that could've been solved if the programmer before me had just commented his stuff properly.

Don't be this idiot.

This is an interesting position for me. Before recently, Omega Vortex has just been a small group of close individuals who all knew each other and have worked together before. Now that we’re expanding and I’m having to actually interview and hire people, I’ve been able to experience what it’s like to be on the opposite side of the process. I’m used to being the interviewee or the person applying and sending in a resume, not the guy interviewing or receiving the resume. I don’t claim to be an expert on interviewing people or sifting resumes, but here’s my list of things that’ll immediately get your resume tossed out of the pile. (continue reading…)

I was reading today and came across something that seemed contradictory to what I’ve learned over the years. At the same time, it just made a lot of sense.

Programmers don’t throw away code enough. When faced with a hunk of code someone else wrote, which doesn’t appear to be quite right, or is misbehaving, the proper action is to figure out what it’s supposed to do, and its interface, and then scrap it and start from scratch. (I’m not talking about rewriting whole programs here, just sections.) Instead, people try to handle the corner cases, or hunt down where the leak is. Just stop, think for a little while, get the structure well posed, then write that.

We were bit by this problem at OV recently. Instead of trashing pieces that were there in order to make them work, and writing them based on the original specification, we attempted to bend them into place in order to “save time”. Needless to say, that didn’t work out so well. Not only did we not save time, we used up too much.

Next time, I think it would be more appropriate to go with my gut feeling. Instead of trying to bend the immalleable, we should strive to replace the pieces. Sometimes code is just so bad that it’s not smart, safe, or sane to leave it in place.

I’m certainly losing my sanity, about now.

Any code that relies strictly on assumptions is not logic. In order for code to work properly, you need documented truths. In the event that you don’t have documented truths, you create them.

A recent client of Omega Vortex has been hit by the pains of outsourcing. Now, I’m sure there are a ton of really good developers out in India … somewhere. Sadly, a lot of the people I have talked to have had nothing but negative things to say about consulting companies based out in India. It’s certainly a lot cheaper than development shops here in the states, but it’s also a lot riskier. So, here’s my five rules of outsourcing to make sure that you don’t get burned the next time you’re looking for someone to help you complete a project.

(continue reading…)

I found this to be an interesting read. Apparently, JavaScript frameworks that are using JSON to handle their XHR / AJAX are presently vulnerable to “JavaScript Hijacking” – Vulnerable frameworks include Microsoft ASP.NET AJAX (aka. Atlas), XAJAX and Google Web Toolkit, Prototype, Script.aculo.us, Dojo, Moo.fx, jQuery, Yahoo! UI, Rico, and MochiKit.

Take a look.