1. Internet Explorer 8
2. Browsers that have rendering bugs (aka Internet Explorer)
3. Browsers that have terrible CSS support (aka Internet Explorer)
4. Browsers that have terrible developer tools (aka Internet Explorer)

Coincidentally, that’s also the list of reasons why there is no new blog post today.  In all seriousness, JavaScript and HTML have gotten a bad rap.  If you ignore IE, they’re a great to work with.  As soon as you start worrying about Internet Explorer though, you might as well go find a bus to lay down in front of, because that’s going to hurt less than getting IE to behave.

Tags:

I’ve been pretty down on Microsoft lately (and deservedly so since I’ve been developing JavaScript that has to work in the pile of trash they are passing off as a browser), but not all is doom-and-gloom from Redmond.  Yesterday, Microsoft RTM’d Windows 7, Windows Server 2008 R2, and Expression Studio 3.  I haven’t tried Expression Studio 3, but I can vouch for the high quality of the other two products.  I’m running Windows 7 RC (and beta before that) on a production machine, and I’ve had one, maybe two, hiccups the entire time.  It’s a great OS, and I have already pre-ordered my copies.  My only regret is that I have a new machine to build this weekend, and I won’t be able to put Windows 7 RTM on it.

So, congrats, Microsoft, on some great releases this week.  Now take all that positive energy, and channel it into creating a browser (based on Firefox) that doesn’t make me want to find a new profession.

Tags:

If you have seen the excellent* comparison of browsers, you may actually believe that Microsoft made improvements with Internet Explorer 8.  However, you would be mistaken.  For the past 48 hours, I have been in bug-squashing and clean-up mode on liteGrid.  During that time, I have repeatedly found cleaner, more elegant ways to do handle some of the rich functionality (such as column resizing).  Unfortunately, every single one of these has failed in IE8.  Rendering it in “quirks” mode fixed some of the issues, but created even more of its own problems.  Here’s my favorite example so far.  The resizable columns in liteGrid are handled by draggable divs embedded within the th elements.  As you drag the elements, they resize the columns.  That part works great.  Except when the column shrinks and begins truncating text.  When that happens, the draggable div mysteriously disappears completely.  That is, of course, unless you assign a non-transparent background color to it, then it works perfect!  You can also assign a bogus background image URL to it, and it will work just fine.

Microsoft: stop kidding yourselves, and stop lying to consumers.  Internet Explorer 8 doesn’t deserve to be listed on the same page as either Firefox or Google Chrome. It’s not a browser, it’s an abomination.

</rant>

*full of crap

Tags:

This is kind of a rambling post since I’m writing this on-the-fly at 11:00 PM.

In preparation for the release of ML# (ML-Sharp), I’ve begun moving things over to Google Code.  ML# has a very long Subversion history with over 300 commits in the last year.  I could have just nuked all that history, but I really wanted to preserve it just in-case I ever wanted to go back and look at something one day.  So, just copying the current revision into Google Code was out of the question.  Here’s what I did to migrate the project.

Isolate the projects to be migrated

The original SVN repository contained everything: code, data, the works.  It wasn’t anything sensitive, but it was data that wasn’t really needed anymore, and I didn’t want to copy it.  So, I followed this procedure to filter the repository down to just what I wanted to migrate.  Unfortunately, I did some renames/moves early in the project, and the original files were in paths that were outside the path I wanted to migrate, which means that svndumpfilter won’t work; it fails with the lovely “Invalid copy source path” error.  A bit of digging revealed this python script which claimed to overcome this limitation in svndumpfilter.  It did not work for me, it died every time with a cryptic error.  Lovely.  So instead, I manually excluded the folders and directories I didn’t want to include.  That *seems* to have done the trick.

Next, I created a new, empty repository on my local server, and loaded the dump using svnadmin load.  Next, I re-organized this new repository so that it’s structure matched my desired structure.  At this point, I was ready to begin migrating the repository to Google Code.

The Migration

First, I went to the source control page for my project on Google Code. At the bottom, there was a link that I clicked to reset the repository to revision 0.  This step is necessary if you’re going to use svnsync to migrate an existing repository (which is exactly what I was doing).

Next, I ran svnsync. When prompted for your Google code credentials, be sure to use your GoogleCode.com username and password, not your regular Gmail credentials.  If you get an error that says “DAV request failed” and “pre-revprop-change hook either failed or is non-existent”, be sure you have a pre-revprop-change hook defined (the hook can be empty).  Also, if you get authentication errors, make sure you are using https and not http to connect to your Google Code repository.  That mistake cost me about 15 minutes.

Once you’ve initialized svnsync, just fire up the actual sync process, sit back, and wait (for a really long time, in my case).  Once svnsync finishes, you should find that all your code has been mirrored on your Google Code repository. 

Tags:

I have had to temporarily disable comments as my site has been overrun by some jerk’s spam bot the last 24 hours.  Comments are moderated, so they’re not gaining anything by spamming my site, but it’s annoying to wake up after 6 hours of sleep and have over 50 comments pending review.  I’ll re-enable comments after I find a CAPTCHA system that works with BlogEngine.NET. 

NOTE TO THE BLOGENGINE.NET DEVS: No, your simple JavaScript-based “captcha-like!” system does NOT work.

UPDATE: Comments re-enabled.  I’ve implemented a hack that *might* stop the spam attacks.  For more information on what’s going on and how everyone with a BlogEngine.NET blog is affected, check out this thread.

Tags:

I’ve been thinking recently about how to define the skills and traits that make for a “great” developer.  I’m certainly not an authority on the subject, but I consider myself to be a pretty solid developer.  I’ve worked with some truly stellar people, too, so I know what a great developer looks like.  But as I’ve tried to come up with a description, I’ve found that defining a great developer is a lot harder than recognizing one.  Here are a few traits that I think great developers usually have. 

Strong problem-solving skills – Software development is mainly about solving problems, particularly new problems (or variations on existing problems).  Let’s face it, if this wasn’t true, there would be no need for developers, since monkeys would be able to take off-the-shelf components, slap them together, and successfully meet all the customer requirements.  In reality though, any solution requires at least some customization and novel thinking; if not, the customer would be much better off using the existing solution.  So being able to solve problems is very important, but what makes a developer “great” is an ability to quickly come up with elegant solutions to problems.  A “great” developer doesn’t reinvent the wheel, either, he recognizes and utilizes existing solutions whenever possible.

A passion to learn – Software development is not a skill that you pick-up in school then coast on for the rest of your career.  “Great” developers recognize this and make both a professional and personal commitment to advance their knowledge.  They constantly explore new things, acquire new skills, and seek knowledge from those that are more knowledgeable than they are.  A “great” developer is not content and always seeks to improve themselves.

An ability to craft elegant solutions – A “great” developer will solve a problem using a solution that is both readable and efficient.  It will contain exactly as much code as is needed and no more.  A “great” developer will not hammer a problem with more and more code until it “works”.  A “great” developer dies a little inside every time he sees that happen.

A willingness to teach - “Great” developers are not greedy with their knowledge.  They’re happy to share it; they want to help their fellow developers learn.  They may not want to hand-hold constantly, but a “great” developer will be more than willing to provide feedback and guidance when asked.

An understanding of the differences between “developer” and “programmer” – While every developer is a programmer, not every programmer is a developer.  A “great” developer not only understands this, but they embrace it.  They know that development doesn’t just mean writing code, it means understanding the business and the users.  It means testing code, not just flinging it at the screen.  It means documenting code so that solutions aren’t write-only.  It means designing solutions, not just hacking at it until it works.  A “great” developer understands that the majority of their time will be spent not writing code. 

That’s certainly not an all-inclusive list, and if I sat here longer, I’d probably think of other things.  What do you think are some key traits that separate a great developer from an average one?

Tags:

The reason I suddenly went dark (again) was due to an unexpected change in the timing of my thesis defense.  Originally my deadline was July 9th, but I found out at the end of May that I actually had to defend by Friday, June 5th, because some of my committee members were going to be taking extended trips during the summer.  Last week, the schedule was again accelerated, as my defense was moved from June 5th to June 2nd (yesterday).  Fortunately, many late nights and lots of Red Bull were all it took to wrap things up, and I am now all clear to graduate in August.  I have the usual edits to make and a few things to clean up, but I’m mostly finished now. 

I probably won’t be posting much this week as I try to finalize my thesis and catch up on all the things that have fallen by the wayside, but I will start blogging again.  I still have lots of things I want to cover: deep-web crawling (and the public release of DeepCrawler.NET), my machine learning library for .NET, Lucene.NET, object databases, and more. 

Tags:

This isn’t directly development-related, but it is noteworthy.  On May 8th, Square Enix, makers of Final Fantasy, Chrono Trigger, etc, hit Chrono Compendium with a cease-and-desist related to ROM hacking and modifications, particularly as it relates to the Crimson Echoes fan project.  Square Enix has sent C&D projects in the Chrono community before, but they were always to people that were recreating Chrono in a new engine/platform/whatever, not to groups that were creating ROM hacks.  ROM hacks are essentially nothing more than mods, which are standard fare these days.  Instead of being appreciative of a community that has thrived despite being largely abandoned for the better part of a decade, Square Enix decided to be LAME and resort to legal threats. 

I was actually look forward to playing Crimson Echoes, and I’m very sad to see it go.  This is a great example of how screwed up intellectual properties are… anyway, if you have a blog and were/are a fan of the Chrono series, spread the word.  I highly recommend *NOT* buying things with the Square Enix label since they are unoriginal dicks who are surviving mostly on name and rehashes of old IP.  Good job, Square!  Digg the story here.

Tags:

The use of metadata classes:

   1: [MetadataClass(typeof(MyMetadataClass))]

   2: public partial class MyClass

   3: {

   4:     public int MyProperty { get; set; }

   5: }

   6:  

   7: public class MyMetadataClass

   8: {

   9:     [Range(1,100)]

  10:     public int MyProperty{ get; set; }

  11: }

[Credit goes to Mike’s post for inspiring this bit of hatred; I’m not blaming Mike for the hate, of course, just for reminding me that I hate it. :) ]

I don’t understand why MS is using this approach.  Why not a fluent approach like, maybe something like this:

   1: Constraint<MyClass>.Add(x => x.MyProperty).Between(1,1000);

The advantages of the fluent approach should be obvious: I’m not violating DRY, I have compile-time checking that my constraints are valid (somewhat), and I don’t have to create a new public class just to house a single constraint. 

Noisy Tweets:

I like Twitter, and I’ve actually gotten some real value out of it, but the signal-to-noise ratio is terrible, even for guys I really respect and that have a lot of valuable things to say.  I’m not going to name names, but I’m appalled at how much time some people are apparently spending doing useless activities on Twitter, such as retweeting retweets and telling me about their breakfast.  I DO NOT CARE.  I follow you on Twitter to get useful information.  Maybe Twitter should allow people to categorize their tweets or something.  That would let me turn off the “walking the dog” category.  Of course, I seem to be in the minority here.  Maybe I should start tweeting every time I walk to the fridge to grab a water?

People hating on ‘#regions’:

I am very sick of posts like this.  I 100% disagree with this post.  I do indeed use regions to group my code in the standard way (fields, properties, constructors, methods, sometimes breaking things up further if I think it makes the code easier to navigate).  I do not want to use the file structure window; I don’t want to ever look away from the code window at all (and yes, I use Resharper).  Regions make things look saner, even for small classes, and really make large classes easier to navigate.  In the end, the use of regions is a matter of opinion, and I’m sick of people ranting about it.  If you don’t like #region, fine, don’t use it, but stop talking about it.  It isn’t even original at this point.

Tags:

My lack of posting and failure to follow through on promised posts has been noted by Sol over on Federated Search Blog.  I wish I had a good excuse, but I really don’t (aside from my usual excuses: school, work, baby).  So… sorry about that. :|

Things are going to be hectic for the next couple of weeks as the semester winds down, but after that, my schedule should improve tremendously.  One of the things I’ll be reviving is my posts on Deep-Web crawling.  Despite being quiet about it, I’ve actually been very active in this area lately.  I just gave a 45 minute talk on the topic yesterday (if anyone wants to see the slides, let me know and I’ll post them), and I feel about 200% more knowledgeable on the topic than I did when I wrote the prototype version of DeepCrawler.NET.  I’m still not sure when I’ll have to pick that project back up and do it justice, but I will pick it up long enough to properly document its usage and post it on the blog for the world to make fun of.  I am still very interested in the topic, too, so if anyone has anything they’d like to share, please let me know.

Aside from that, I am also planning on showing off a fully-functional, front-to-back information retrieval system that I’ve created this semester for another class.  It uses Lucene for the actual index, but it has a complete pipeline built around it to enable distributed indexing including a document partitioner, indexers, and a simple search interface. 

Tags: