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. (more…)

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.

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.

(more…)

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.

I’m really starting to get disappointed in PHP IDEs. Because, I find one that works really well that I love (Zend Studio) but it falls short in respect of two things. The first being the lack of the ability to add support for other source control systems besides CVS and SVN. Second being the lack of built-in support for Unit Testing.

PDT (the Eclipse plugin) is very project-based. It offers up a lot of features that Zend Studio offers, with the added bonus of being built into Eclipse. And Eclipse has a plugin to support the Source Control System we use at work. Eclipse also has a plethora of other very useful plugins, like Aptana. PDT, unfortunately, offers no code inspection support for files outside of projects. That’s a bummer, because I have to jump in and out of various files in various locations that may or may not be apart of any project. So, PDT is missing ZDE staples, but has the benefit of being an Eclipse plugin, meaning I can have my source control integration.

Enter PHPEdit, which I’ve never used, but just learned that it’s going to solve the other problem, in an upcoming version. But not the first. I probably won’t use PHPEdit, except maybe to play around with, but the Unit Testing support is intriguing. If Zend Studio or PDT could get this in, that would be great. If Zend Studio could get this and alternate methods of adding source control support, that would be even better. I’m still waiting to see if PDT will be able to replace Zend Studio or not. Lately, I’ve been using them rather interchangeably, but I’m really wanting to move back to Zend Studio… Time will tell, but I wish these IDE developers would get it together.

I’ve been wanting to start using PHP6 snapshots as part of my development process to ensure that my work (especially the Engine) is forward-compatible with the changes being made across the PHP Core. So, I set out on a little endeavor to make the PHP6 snapshots work in WAMP.

First, you’re going to need the latest version of WAMP. So, go to the site using the link above and grab the download. Now, my change is based on the PHP 4.4.4 Add-On (also, don’t install this Add-On if you want the switch to work properly), so it’s pretty simple to do.

Go grab the latest Win32 6.0-dev Snapshot from snaps.php.net. You’re going to need to extract this into your wamp directory as “php6″ so that you’ve got <path_to_wamp>\php6\php6apache2.dll … Now, copy the php.ini-dist file into <path_to_wamp>\Apache2\bin\ and rename it to php6.ini. You’re also going to want to open this file and change your extension_dir to <path_to_wamp>/php6/ext/ …

Now, save this file into your <path_to_wamp>\scripts\ directory as switch.php … You may have to modify this file to change the line:

$mphp6 = “php5_module”;

to

$mphp6 = “php6_module”;

This tripped me up last night, because php6apache2.dll was still registering as php5_module as of last night’s snapshot. I poked the internals mailing list and found this out from Antony Dovgal, who also said that this should be fixed in the next snapshot. I haven’t tested this to see if it has been fixed yet, though.

Anyway, after you’re done with all of the above, fire up WAMP and then open the command line. cd to <path_to_wamp>\scripts\ and then php switch.php (assuming you’ve got a path to a PHP binary in your system path — if not, you’ll need to use <path_to_wamp>\php\php.exe switch.php). This should shutdown Apache and swap out the PHP5 data for your PHP6 data. After it’s complete, and Apache restarts, check your phpinfo() and you should see PHP 6.0.0-dev.

And that’s all there is to it.

I was just going through my RSS Feeds and I stumbled upon 81.4 is evil through Planet PHP. I invite all of you developers to try this for yourself.

The original code:

<?php
$total = 100 - 81.4;
//$total should be 18.6
echo “18.6 == {$total}? ” .
($total == 18.6 ? ‘yes’ : ‘no’) .
“\n”;
var_dump(18.6 - $total);
?>

You’ll get a “no” and var_dump will give you float(-7.1054273576E-015) … Talk about the precision being a little awkward.

Now if you thought that was weird, check this out.

Look at what happens when you type-cast $total to a string before doing the arithmetic:

<?php

header(”Content-Type: text/plain”);

$total = 100 - 81.4;
echo “18.6 == {$total} ? ” . ((string) $total == 18.6 ? ‘yes’ : ‘no’) . “\n”;
echo (string) $total - 18.6;

?>

For me:

18.6 == 18.6 ? yes
0

Does type-casting float variables to strings before performing the math actually increase floating point precision, in PHP? I found this kind of odd …