entropia

Used to be, software development was compared to bridge building.  But no one likes that anymore, and there’s an ongoing search for a better analogy.  Software development is a game.  It’s gardening.  Rock climbing.  Gardening.  Painting.  Gardening.

Enough already.  Software development, like everything else, is like everything else.  What’s this obsession with trying to devise and break down analogies?

Analogies are like clouds.  They may look solid from a distance, but they’re really nothing but vapor.

The truth is, software development is like bridge building, in some ways.  And it is like gardening, in some ways.  You can compare it to anything you want, and you’ll be able to make a case.  But it’ll also be torn about by anyone who thinks about it for a couple minutes.

The problem people have with analogies is that they try to derive conclusions from them.  “If A is like B in respect C, they might also be similar in respect D“.  But analogies don’t work like that.  Analogies cannot be extrapolated.

So the next time someone says software development is like bridge building, they’re right.  As long as they specify the bounds of the comparison.

A while ago I wrote about Notepad++’s awesome customizable syntax highlighting.  Today I learned sometime else to help with my task management:  customizable function definitions.  Using the function list plug-in, I can get a list of all my incomplete tasks.

The plug-in normally finds the functions in a file based on its language settings.  It does this by finding regular expression matches for function declarations (usually just function ) and names ([a-zA-Z][a-zA-Z0-9_]* maybe)  My task files don’t have functions, but I can find my imcomplete tasks using ^\t*\[[ \.]\]. (which matches “[ ] ” and “[.] “, preceded by any number of tabs) for the declaration and .* for the name (which matches the rest of the line), I get exactly what I want.

I missed the ’90s bubble.  I was one of the outsiders looking in at all the dot-com-ers getting rich, then poor.  So I’m probably way off base here.  But I’m not sure the current situation constitutes a bubble.  At least, not like ten years ago.  Here’s a few ways things are different now than they were then.

The leaders

Then, dot-com businesses were run by businessmen.  They would think of something to sell, then hire programmers and marketers to make it happen.

Now, so-called Web2.0 sites are run by designers.  They think of something that may or may not already be available, put it on a pretty website, and give it away.

The content

Then, product were, well, products.  You hear about a website that sells something you want, then go there and buy it.

Now, products are information, packaged in intriguing ways.

The goals

Then, startups would try to sell enough of a product to make money.

New, the goal is to be bought out by Google or Yahoo.

The perception

This is where I think the real difference lies.  In the late ’90s, everyone knew the tech industry was hot.  If someone said they were a programmer, people would assume they’re getting rich on that Internet thing.  The common perception of a computer geek switched from a nerdy antisocial guy who lives in his parents’ basement to a nerdy antisocial rich guy who live in an Aeron chair.

But now, outside of those in the industry no one notices what’s going on.  Other than a few huge successes like Flickr and YouTube, most haven’t heard of the current startups.  Ask your parents what Twitter is.  Or del.ici.ous.  But everyone knew about Amazon and eBay when they were young.  Same goes for the technologies:  Java is no longer a cup of coffee, but Ajax is still a cleaning product.

Then again, a quick glance at Techcrunch makes it hard to ignore that something’s going on here.  Something that can’t last for long.  Maybe that by itself makes this a bubble; some people would agree to that.

I found IE7Prowhile looking for an ad-blocker.  It’s being billed as the “ultimate add-on for Internet Explorer 7″ and I must say, so far that’s pretty accurate.  It’s has ad-blocking, crash recovery, mouse gestures, user scripts like Greasemonkey, and a bunch more features.

I now have only one reason to ever use Firefox:  web development, as there’s no IE alternative to Firebug (in fact, nothing comes close).  But everything else Firefox can do, IE7 can do better.

I’ve been reading a lot of software development and design blogs and articles lately.  Coding Horror.  Joel on Software.  37 Signals.  Paul Graham.  Anything they link to and anything that links to them.  And it’s all good stuff.  Inspiring, if nothing else.

But for the most part, it’s all stuff I already know.  “Don’t repeat yourself”.  “Eat your own dogfood”.  In general:  like what you do and do it well.  Sure, the great writers can help you realize things you never knew you knew, but that only helps so much.

It reminds me of listening to political speeches.  Rallying the public.  Inspiring.  Everyone knows you should “Ask not what your contry can do for you, ask what you can do for your country”, but that doesn’t mean we don’t like hearing it.  Just like we don’t mind reading about how successful we can be if we just follow a few simple business rules and use some common sense.

How Not To Achieve Business Success is a great write-up on the subject.

Hanging on every word of Joel Spolsky (my favorite software industry inspiration) is no better. As he exposes his journey of building a software startup into a success he makes it all sound so sensible and straightforward. Does that help me? No, not a bit. It has been interesting to watch but nothing that he did has worked for me.

Just like everything else in life, you can’t become successful in software just by reading about it.  Joel et al are great as long as you keep thinking for yourself.  Just like with politicians, you can’t rely on someone else to tell you how to live your life.  If you follow the leader too closely, you’ll just end up tripping on their shoes.

Notepad++ has been my text editor of choice for a while.  It has all the standard features:  multiple document interface, regular expression search and replace, a flexible syntax highlighter that lets me work with HTML, javascript, PHP, whatever.  At work I use it to keep track of tasks.

I have a pretty simple system for my tasks.  I use a plain text document, where each line is prefaced by a few characters to denote whether it’s an imcomplete task, a completed task, a comment, a filename, whatever.  It works great for me but the problem I have is that it can be hard to understand at a quick glance.

But today I realized that it lets you define custom highlighting rules for cases just like this.

It’s nothing much for such a small sample, but when you’re scrolling through pages of notes it’s a lot easier to pick out the red incomplete tasks from the green completed ones.  And if I need to make a list of the files I needed for something, I can just look for the blue “-f-”s.

It’s features like this that separate good software from great software.  Most people will never even notice it, but it makes my life a little easier.

Here is a demo of dynamic CSS in javascript.  It contains a file, dcss.js, you can use to manipulate CSS by adding rules, changing rules, adding entirely new stylesheets, whatever.

As a computer science degree holder who is not nearly as successful as planned, I feel I’m in the perfect situation to give advice to current students.  I can attest first-hand that not following these 10 rules can result in a less-than-desirable career.

Some of these are shamelessly stolen from Jeff Atwood and Joel Spolsky, but that’s because their advice is just so good.  In fact, if you have read both of their archives in their entireties, go do it now.  And when you get done, consider my thoughts:

• Get a job as an intern.  There is no substitute for real-world experience.  A real job is nothing like hobby-coding, homework assignments, or research work.  If you spend a summer as an intern you will have three months more experience when you graduate.  Plus it looks great on a resume.
• Go to class.  You now have the freedom to skip class whenever you feel like it.  Lectures are boring.  Half the stuff you know already, and the rest is in the textbook, right?  Wrong.  Well, it’s probably right, but there’s more to class than that.  A lot of what you learn in class comes from the way it’s explained and the asides the professor goes on.  You might be able to learn everything on your own, but you’ll learn it a lot better with help.  Plus, the professor will notice if you’re not in class, and he probably won’t like it.  Which brings me to…
• Get to know your professor.  Go to office hours once in a while.  Ask questions after class.  Even if you feel like you understand everything, talk about related topics or alternatives to what was presented.  Show him you care.  If the professor knows who you are, other than the name at the top of your homework, there’s a good chance he can help set you up with an internship or even a full-time job.
• Contribute to an open-source project.  It’s not as good as real work, but it’s better than coding alone.  Working on an established project will give you experience reading and understanding other people’s code and working in a team.  Plus you could make some new friends.  And it looks good on a resume.
• Keep an open mind.  I’m not talking about all the crazy political, religious, and social ravings you’ll undoubtably hear on campus.  I’m talking about opinions on languages, coding conventions, and development methods.  Even though you know C# is the greatest thing ever and there’s no reason to learn anything else, some people prefer Java and you will have to expose yourself to it sometime.
• Care about your GPA.  GPA isn’t everything.  After a few years of real experience, it means nothing.  But it will be a factor when looking for your first job or two.  Having a 3.5 instead of 3.6 probably won’t cost you anything, but if it’s too low, recruiters will think you either don’t understand programming, or you just don’t care.
• Create a portfolio.  Saying “I worked on massively multiplayer games with revolutionary graphics” sounds nice, but recruiters won’t care much unless you can show them something.
• Read.  Read blogs.  Read books.  Read blogs about books.  You’ll learn what people mean when they say things like “factory pattern”, “DRY”, or “fix broken windows”.  Reading isn’t a substitute for coding, but unless you learn about alternatives and better solutions, you’ll just repeat the same mistakes again and again.
• Get a job as an intern.  Important enough to be listed twice.
• Have fun.  If you don’t have fun developing software, maybe you shouldn’t be a software developer.

If I could give a single, cliched suggestion it would be, “Just do it”.  Whatever “it” is:  code, read, learn, listen.  You don’t have to spent your entire life obsessing over every detail and every new concept, but you probably need to spend more time on it than people going into other industries.  Successful software developers don’t just put in their 8-5 and forget about programming all night and weekend.

Breaking news from the interwebs:  Ajax isn’t 100% secure.  Your app isn’t safe.  Your data isn’t protected.  Your privacy is gone.  All your base are belong to the hackers.

Appearantly it’s time to go back to tin cans and strings.  This newfangled Web2.0 thingy has caused nothing but trouble.  Now you can’t even trust the data you receive from the server to be genuine.  What’s next?  Will Web3.0 come into your house while you sleep and download pornography and illegal MP3s?

In case you don’t have your sarcasm font installed, let me make something clear:  the internet is insecure.  Always has been; always will be.  Every developer should always assume that every byte uploaded or downloaded is corrupt, compromised, and counterfeit.  This is Internet Programming 101:  verify data before using it.

But for some reason, every tech site and blog is obsessing over some paper from Fortify Software about “javascript hijacking”.  Here’s a rundown:  they took a known (and solved) security issue (cross-site scripting), renamed it to “javasript hijacking”, and created hysteria.

It must be a slow news week.  Or maybe everyone’s just recovering from April Fools.  We spend one day shrugging off every story, post, and news item, then spend the next week overreacting to the first bit of truth we find.

A while ago a made a little javascript raycaster.  Recently, when I was browsing through my old stuff, I came across it and noticed that it didn’t work in IE7, so I decided to fix it.  But since this was the closest I’ve come to graphics programming in a few years, I ended up doing a lot more to speed it up and make it better.  Here is a page chronicling the development of the fastest canvas-free javascript raycaster I’ve seen.

The rendering portion of a raycaster can be thought of as a simplified subset of 3D rendering.  3D rendering in javascript is covered here.  Essentially, it consisted of breaking down triangles into a number of right-triangles, each of which is represented by a bordered div.  In raycasting, you don’t need to worry about triangles, just trapezoids.  And trapezoids can be rendered in javascript without subdivision.

The crux of making it fast lies in how those trapezoids are calculated from the walls.  I ended up using binary subdivision to find the boundaries between walls, so each wall can be treated as a single trapezoid.  (This is opposed to using fixed-width trapezoids that are subdivided when need be.)

There are a few things I want to add.  Mostly texturing, which I’ve never seen in a javascript raycaster.  I have an idea involving pre-skewing the images which almost works.  Hopefully I’ll be able to work out the final kinks (the most prominent of which is speed) soon.