Archive for the ‘Programming’ Category

Amen, Joel Spolsky!

December 28, 2008

I couldn’t agree more:

I don’t understand why this “leaving the industry” thought process is so predominant in this little corner of the universe.

This is a TERRIBLE time to leave the industry. I don’t know if you’ve noticed, but there are half a million NEW unemployed people JUST THIS MONTH.

Although the tech industry is not immune, programming jobs are not really being impacted. Yes, there are fewer openings, but there are still openings (see my job board for evidence). I still haven’t met a great programmer who doesn’t have a job. I still can’t fill all the openings at my company.

Our pay is great. There’s no other career except Wall Street that regularly pays kids $75,000 right out of school, and where so many people make six figures salaries for long careers with just a bachelors degree. There’s no other career where you come to work every day and get to invent, design, and engineer the way the future will work.

Despite the occasional idiot bosses and workplaces that forbid you from putting up dilbert cartoons on your cubicle walls, there’s no other industry where workers are treated so well. Jesus you’re spoiled, people. Do you know how many people in America go to jobs where you need permission to go to the bathroom?

Stop the whining, already. Programming is a fantastic career. Most programmers would love to do it even if they didn’t get paid. How many people get to do what they love and get paid for it? 2%? 5%?

Advertisements

SQLcached

November 10, 2008

I have to agree with Dare Obasanjo’s latest blog entry about in-memory caching. After working on high-transaction, heavy database-using Web applications for the last nine years, there is one thing above all else that I have learned and taken to heart: a Web application is only as good as its caching strategy. My career has seen a progression from light to heavy cache usage and each new application has benefitted in scalability from that.

Dare’s entry got me thinking: why couldn’t the RDBMS itself incorporate a distributed, in-memory cache like memcached or Project Velocity? What if a Web application could basically eliminate the need for its own caching layer by relying solely on the database, which would then aggressively and algorithmically use one of the caching services to expand its memory-based caching?

If the problem with query caching in MySQL or SQL Server is the amount of server RAM that can be installed, then distributed caching seems like the perfect solution. It’s what the Web server layer uses: why not bring it down to the data layer. Moreover, given the common replication and clustering scenarios, there are likely idle database servers whose memory is already going unused for the most part. Putting a distributed caching system in place would put them in action while still keeping them ready for failovers.

The main objections I can see is that going to the database might cause an increase in network usage since some cache calls in the Web server layer would never leave the server and that the database would have to work to decide between file-level and cache-level access. But that would be minimal and the simplification it would engender on the Web application level would make the costs even less objectionable.

It’s entirely possible that Project Velocity is being undertaken with exactly this thought in mind. (It’s not clear that there’s any movement afoot in MySQL AB towards this end—at least from my cursory searches.) This idea would have to be implemented at the RDBMS level.

Bravo! Bravo!

October 31, 2008

“All I ask is that you restrict them to ‘layout-only’ check-ins. In other words, if you want to do some source code reformatting and change some code, please split it up into two check-ins, one that does the reformatting and the other that changes the code.” – Raymond Chen, “If you’re going to reformat source code, please don’t do anything else at the same time”

jQuery On the Rise

September 29, 2008

Wow. Microsoft will bundle the jQuery library with all ASP.NET MVC projects, enhance its interaction with Visual Studio through IntelliSense, use it in future ASP.NET Ajax controls, and provide support for the library itself. This is huge because most of the Microsoft universe doesn’t take note of anything not provided by Microsoft in a standard distribution.

A Hard Decision

September 27, 2008

I’ve been a consumer of the Facebook.NET framework for a few months now as I’ve developed several Facebook applications in ASP.NET. I chose that framework instead of the official Microsoft one because it seemed more logical and straightforward.

Honestly, I’m not at all certain why I originally chose one over the other. I read all of the blog commentary about each, I looked over the source, and I checked out the sample applications included. Facebook.NET struck me as elegantly designed, well conceived, and actively developed. Sure, Microsoft had commissioned and paid for the development and maintenance of the Facebook Developer Toolkit, which meant it was more likely to be around in the future. This possible objection was easily dismissed since Facebook.NET was open source and could be extended privately as long as need be.

What I couldn’t have foreseen were sweeping changes by Facebook to the underlying API within six months and a complete abandonment of the open-source project by its sole maintainer. Facebook has made a lot of mistakes in handling the transition but there’s precious little that I, as a third-party application developer, can do about that. So my sole responsibility is to keep up with updates to the framework and alter my code to accommodate the new (or changed) functionality.

Faced with a framework that isn’t getting updates, the responsibility expands considerably. One must either abandon the abandoned framework to search for greener pastures or one must take up the mantle of leadership by forking the project. Neither is a path to be chosen lightly for each entails considerable pain.

The choice was made easier for me by the fact that the Facebook Developer Toolkit was just as inactive at the time. I tried corresponding with the Facebook.NET maintainer and even succeeded a couple times: I would much rather have been a developer on a project than the man responsible. In the end, it became clear that the maintainer had moved on to other projects and that I was going to have to fork.

The result is fb.net. I largely brought it up to parity with the API changes in a span of two days but then I got distracted by work, family, and other projects myself. As it stands, there’s just a little more to go and then I can make a release candidate.

My only hope is that I can get this framework ready for a full release and then start looking to build a community that can assist in its maintenance. The Facebook.NET maintainer got it off to a good start; now it’s my turn to finish the job.

That’s Another Way to Go About It

September 12, 2008

I generally don’t like to showcase other’s inelegant code, but this couldn’t be more timely given yesterday’s Twitter created_at parsing tip. There’s always more than one way to do something, I guess.


       private static DateTime ParseDateString(string DateString)
{
Regex re = new Regex(@"(?<DayName>[^ ]+) (?<MonthName>[^ ]+) (?<Day>[^ ]{1,2}) ↵
(?<Hour>[0-9]{1,2}): (?<Minute>[0-9]{1,2}): (?<Second>[0-9]{1,2}) ↵
(?<TimeZone>[+-][0-9]{4}) (?<Year>[0-9]{4})");
Match CreatedAt = re.Match(DateString);
DateTime parsedDate = DateTime.Parse(
string.Format(
"{0} {1} {2} {3}:{4}:{5}",
CreatedAt.Groups["MonthName"].Value,
CreatedAt.Groups["Day"].Value,
CreatedAt.Groups["Year"].Value,
CreatedAt.Groups["Hour"].Value,
CreatedAt.Groups["Minute"].Value,
CreatedAt.Groups["Second"].Value));

return parsedDate;
}

For me, the lesson here is to know your libraries and always assume that someone else has done it better than you already. It then becomes a quest to find that better solution to the problem.

How to Parse DateTimes from the Twitter API

September 11, 2008

If you were wanting to interact with the Twitter API under .NET, you might find yourself trying to convert a date value from the XML results over to a DateTime in your code. Twitter uses a weird format for their dates—Thu Sep 04 11:09:28 +0000 2008—that doesn’t get converted properly with just a good ol’ DateTime.Parse. You could spend a lot of time iteratively trying to figure out the correct format to use. Or, you could just use the following (my free gift to you, dear Twitter-API-consuming reader):


DateTime.ParseExact((directMessage.SelectSingleNode("//created_at").InnerText), "ddd MMM dd HH:mm:ss zzzz yyyy", CultureInfo.InvariantCulture, DateTimeStyles.AdjustToUniversal);

directMessage here is an XmlNode representing a single direct message extracted from a list of direct messages. I found this out after many iterations since all of the .NET libraries for Twitter just punt on this conversion.

ReSharper *IS* All That

April 4, 2008

Longtime readers may already know that I am a big fan of JetBrains’ ReSharper add-in for Visual Studio. I recommend it highly to any .NET developer, but especially to any of those who are interested in being more productive. You’d think that that’d be everyone, but I’ve found it not to be the case. Many developers I recommend the tool do don’t want to learn a new tool, aren’t particularly keyboard-enthusiastic, or mistakenly believe that ReSharper is superfluous. On that last point, I’ve stumbled upon a nice comparison chart showing that that is not the case.

There’s overlap, to be sure, but in nearly every instance I’ve encountered ReSharper’s implementation is more thorough and more thoughtful. It’s worth every penny.

Contributing to the Growth of the English Language

February 27, 2008

I think I just coined a new word today—encomp (verb): the act of getting an application to match the comprehensive design provided by the designers. Usage: “Oh, I just got the slices from Andy so now it’s time to start encomping.”

I can’t find any usages of it on Google, just confusion with encompassing. I claim this neologism then.

Javascript Splice Ain’t Remove

December 27, 2007

I wanted to remove an item from a Javascript array and looked in vain for a remove function. I did find an implementation of remove using the Array.prototype but I just needed a function to get rid of items that matched a specific criterion.

That’s when the trouble started. The splice function—calling its array.splice(index, count) variant—will indeed remove an item or items from the array (and return an array of the items removed for some reason) but it also closes the void left by the removed item and resizes the array all in one fell swoop. So code like this doesn’t work as you’d think:

for (var i = 0; i < array.length; i++)
{
   if (array[i].someParameter == "someValue")
   {
      array.splice(i, 1);
   }
}

Since array.length changes with each removal, this code will end up missing some items because it will end too quickly. In the interest of saving future Googling, frustrated Javascripters, here’s how I solved the issue:

for (var i = array.length - 1; i >= 0; i--)
{
   if (array[i].someParameter == "someValue")
   {
      array.splice(i, 1);
   }
}

By starting the loop from the top of the array and working backwards, item removals and the dynamic resizing have no effect. If anyone has a better way, I’m all ears. Well, eyes.