Startups for our Parents

(With apologies to mom and dad)

Us young geeks don't understand a life without technology.  Thing is, virtually all of our life online has a non-web counterpart.  Email?  Actual mail.  Ebay?  Auction halls.  Social media?  Phones, dance halls, and intricate musical numbers (at least that's what West Side Story tells me).  The millennials grew up with the virtual side of things.  It's the natural way we live and communicate.  It's also fairly difficult for the average millennial to conceptualize a life without the internet.  Not so for other generations.

Can I fantasize for a moment?  How many people do you know would agree with the following:
"We have to find someone from a different generation to show us how to use [technology]"

Learning technology requires a time investment.  Have you ever tried to learn a new language or framework through a bad tutorial?  How many things have you never done because learning them took too long?

With that in mind, I propose a new website: oldpeopletutorials.com

Ok, so that's not the most flattering title.  Perhaps we should go with BabyBoomerTutorials.com or something like that.  We could direct our parents toward it anytime they need to ask about technology.  It'd have pleasant videos narrated by Paul McCartney detailing the basics of Facebook, Google, and Twitter.  They'd also have an ease-in forum where they could adjust to textual communication, with how-to's on emoticons and proper use of abbreviations.  We youngsters could also develop API's that would parse email from our parents and reply with a link to the correct tutorial.

Aside from this pipe dream, how could we make online life easier for older generations?

My parents are of the Baby Boomer generation.  They've grown up and lived with a disconnected world, are used to offline interaction and have become very good at it.  In short, they're digital immigrants.  Rather than looking at the fascinating new uses of technology, they see what they already have and say "so?"  New technology needs to convince them that it's better (read: simpler) than what they use now.

If we want to reach people who fit the description above, we need a new way of marketing.  Instead of "this is cool," say "this is the new way of doing [offline activity X] (and here's why it's better)."  We laugh at startup ideas that say "It's Facebook for pets!"  In reality, this may be the way to market startups to immigrants: "It's like mail but electronic!".

Focus on introduction.  There's a huge wall we need to scale in convincing non-natives to use our product.  Make it as easy as possible to actually use the part of your product that replaces what's currently being used.  Focus on the specifics of why it's better.  Remember, "better" doesn't mean "more features" in this case.  Make sure to run usability tests with your target audience.

Reaching technology immigrants may feel like it's pulling oil from tar sands instead of the usual wells.  There's a whole untapped market out there.  Good luck!

The Universal Language

What if you could use the same language anywhere you go?  Server/clientside, desktop, mobile, game dev, physics simulators, EBook readers, etc.  This sounds like a pipe dream, and it is in a way.  If it was possible, what would we want the language to look like?  It would have to be:

• Fast
• Open and Extensible
• Simple, yet powerful
• Easy to debug  (If it's appropriate to yell "HEEEEY MACARENA" at the end of your message, it might be too complicated).
• Language nesting (You can write the language in the language)
• Well-documented

(An argument could be made for rapid prototyping, but this usually relies more on libraries than the language).

Slightly off-topic, my roommates had a brilliant idea: "Why don't we make a video game?"  After an excited afternoon of guffaws they had several pages of scribbles.  Then, to my surprise, they actually started work using the Unity game engine.  One of the language options for writing code is UnityScript.  While it's not pure JavaScript, it's pretty close.  Most JavaScript developers should feel comfortable in the UnityScript environment.

It's about this time that I first started experimenting with Node.  Node is a powerful server-side platform using (you guessed it) JavaScript.  It's ridiculously fast, posting times comparable to compiled languages (this is all thanks to Google's open V8 engine).

Astute readers will see where I'm going with this.  Can JavaScript become the universal language?  It's certainly fast (or certain implementations are).  The ECMA standard is open.  JavaScript's flexible enough to be used in all of the above examples.  It's also easy to create powerful libraries for JavaScript to use.  The documentation and errors could use some help.  Overall, JavaScript seems like our universal language.

However, this ignores all of the other languages out there.  C/C++ is fast.  Java's "cross-platform."  Python is extensible.  Why is JavaScript so special?

Javascript is unique in that it is the de facto language for client-side scripting.  Thus, anyone with a web browser (i.e. everyone reading this right now) has access to a JavaScript environment.  Secondly, it means that anyone involved in web development (a large segment of developers) should have a working knowledge of JavaScript.  This means it's much easier for a PHP guy to move to Node.js than Ruby.

JavaScript isn't perfect (seriously, who thought it was a good idea to have "with"?).  I'm also not suggesting that we should use one language for everything.  However, if there's a universal language, it's JavaScript.  Learning and improving your JavaScript skills will be a net gain for your career.

Are books worth saving?

I love books.  My family didn't have television where I grew up.  Instead, I had shelves and shelves of books.  Yes, I was (still am) quite the nerd.

Having been a book aficionado for many years, I was sad to come across a recent Hacker News post about a bookstore in decline.  Are print books so far gone that even the hackers, the constant innovators, can't save them?

It seems that blogs are taking over as the authors go-to method for disseminating information.  Jeff Atwood doesn't even want you to buy his book.  There are quite a few reasons for blogging:
-Blogs are easy to set up.  It took me all of 15 minutes to set up Recoding (and most of that was picking a name).
-Blogs are free
-You don't have to convince anyone that you're writing's "good enough" to blog
-If some technology changes, you only need to edit your blog to be up-to-date

So blogs are way cooler than books.  Heck, Jeff Atwood wrote a whole book and then told everyone not to buy it.  Problem is, this incredibly low barrier to entry has resulted in an incredibly low signal-to-noise ratio.  The lack of quality control has had many detrimental effects, including the viral spreading of poor coding techniques.  Recently, a post recommending the use of jQuery made the front page of Hacker News*.

Alright, blogs aren't the savior of independent journalism that we want them to be.  Despite these flaws, blogs are still fairly popular and some of them are quite a pleasure to read.  Is there anything about books that is actually worth saving?

Print books have several large advantages over digital media:
-Books contain a large amount of information centrally.  Blogs typically contain information in "nugget" form.
-The bar is much higher.  While bad information can be published in book form (just look at any political book this season), the signal-to-noise ratio is much better than the internet.
-There are other miscellaneous reasons:Books don't need a battery, you can use bookmarks, they can help you feel disconnected, they're DRM-free, some like the smell of books.

I'm usually in favor of new technology when it replaces the old.  Some may pine for the romantic days where everyone went around with a horse and buggy but I enjoy traveling in my climate-controlled box at 65 mph.  However, the nuggets of data presented to us by the internet simply can't replace classic tomes like Code Complete 2.

So books are worth saving.  How?
Ebooks are one promising arena.  While they run on batteries, the basic Kindle's life is absurdly long.  Unfortunately, ebooks are still restricted in most areas by draconian DRM.  Why can't I share my ebook like my paper one?
Speaking of Amazon, they're still doing well.  Brick-and-mortar bookstores might have problems, but books are still being distributed online.
Both of these are nice but aren't the real issue.  Book distribution needs to be easier.  Create a simple, centralized system for book distribution, with some sort of basic quality control (avoiding stuff like bad code or Twilight).

Any other ideas for saving the humble book?  Think I'm off my rocker for wanting to save them at all?  Leave a comment!


*Yes, jQuery has it's uses.  There's a lot more questionable recommendations in the post I linked to (such as the use of CoffeeScript).

Source Saturday: I'm an idiot

One of the best things about Node.js is that it's single threaded, using a callback model to manage asynchronous processing.  One of the most annoying things about Node is that it uses a callback model...you get the picture.  Callbacks can be immensely powerful but are trickier to write and understand than the traditional blocking methods.  Case in point: I managed to screw up callbacks while simultaneously forgetting one of the nicer features of databases.

I had an array of ids and wanted to get the various items from the database that were associated with those ids.  (Yes, yes, I know about the $in command.  I don't know what I was thinking either.)

for(var id in ids) {
    //Convert text id to BSON id
    var BSON = mongo.BSONPure;
    var b_id = BSON.ObjectID(ids[id]);
    collection.findOne({_id: b_id}, function(err, document) {
        if(err) { console.error(err); db.close(); return;}
        returnObject[id] = document;
        if(id == ids.length - 1) {
           res.render('checkout', {classes: returnObject});
           db.close();
        }
    });
}

This code set the land speed record for fastest turnaround from written code to "What on earth were you thinking, past Randall?"  (2 days).  While most of you probably have figured out what's wrong, let's look into the details.  In a purely synchronous language, this makes sense.  Loop through the array, find the entry associated with the id at that point in the array and add it to a return object.  When we've reached the last point in the array, render our page with the generated object and close our database connection.

Here's what really happens:
for loop executes, adding collection.findOne callbacks to the node callback "todo" pile.  After the loop finishes, `id` is the last `id` in the array.
Sometime after the for loop finishes, the callbacks are executed, all with the last id.  Since the last id will trigger the render and database close, only one callback is run.  The rest encounter a closed database.

Fortunately, this had an incredibly simple answer: Use mongodb's $in function.  I still had to loop through and convert to BSON ObjectIDs.  This resulted in much simpler code that used callbacks the right way.

for(var i=0;i<ids.length;i++) {
    var b_id = BSON.ObjectID(ids[i]);
    b_ids.push(b_id);
}
collection.find({_id: {$in: b_ids}}).toArray(function(err, results) {
    if(err) { console.error(err); db.close(); return;}
    res.render('checkout', {classes: results});
    db.close();
});

Now, there's only one callback, and it'll contain exactly the data we want it to.  Any number of ids can and will be handled correctly.

A whole blog post, because I forgot one ruttin' command...

Preventing the Demo of Doom

I learned quite a few lessons from my disastrous demo on Monday.  Reflecting, I'm glad that it was so bad.  In the grand scheme of things, there was very little at stake and my teacher was very forgiving (unlike a VC). I'd much rather have a colossal failure at this level than in the future.  Problem is, not everyone can demo at this class level.  I mentioned testing your demo like you would your app.  While we can't write unit tests for reality (man, wouldn't that be nice?), we can run through the demo under certain situations to find faults.

Test 0: Create a failsafe presentation
One of the comments from yesterday brought up a great idea that would have helped enormously:

Lesson 7: If you operate a computer in front of an audience on a screen, you instantly become an idiot.

Steven goes on to suggest that a video of the demo running makes for a much better presentation than actually running through the demo.  This allows you to focus on the sales pitch without worrying about technical glitches (at least with your software)>

Test 1: Practice ideal conditions
I practiced my sales pitch a lot, to many different people, so I had it down.  I understood what questions and objections may be raised and how to respond.  What I didn't do was practice the pitch in front of my product demo.  I threw myself for a loop several times because I hadn't practiced moving from the theoretical to the practical and back.

Test 2: What could fail (generally)?
Many things went wrong during my demo.  I could have made it go a lot smoother had I looked at what could fail and how to insure against that eventuality.  While I would have preferred to have my PC there for speed, I should have had at least one other option to access my product.  It could have been on my laptop (Fairly easy to set up with Dropbox) or in the cloud (I had wireless internet but no wired for my PC, so I could have loaded a cloud version on my laptop).

Some general failure states you should look out for (roughly from most to least likely): Slow/no internet (have a local copy), projector failure (don't depend totally on slides),  code failure (have an alternative way to sell/demo), machine failure.  Practice your demo under each of these conditions until you're confident.  It doesn't have to be as good as the original.  All you need is effective communication of your message.  People are surprisingly forgiving if you show you're prepared for failure.

Test 3: Product/presentation flaws
Your product is world-changing, sure, but it has flaws.  What are they?  Unit testing can help reveal some of them.  Others can only be found by putting someone who didn't work on it in control of the demo.  What assumptions have you made about your product and the audience?  For instance, I assumed that people would understand how to use a simple search box.  Most people stared blankly at it until I prompted them even after the elevator pitch describing it as a search product.

Usability testing can also reveal fundamental assumptions about your code, as well.  Running a friend of mine through the demo uncovered a major mistake I'd made with callbacks.  10 minutes of panicked programming later, the bug was fixed and I'd learned an important lesson.

How I hit the front page of Hacker News (and so can you)

This morning, I submitted my latest article to Hacker News, as usual.  Usually, I get 50-100 hits from HN if it's a good post.  Instead of slowly dying in "new" like the rest, this one immediately received enough upvotes to put it at #14 on the front page.  When I came back, I found that the total hits to my blog had doubled in an hour.

Yikes.  When I first started this blog, I had a goal of getting 13+ hits a day.  I never thought that I'd get hundreds  much less thousands of hits after only two months.  I'm just some dumb college student (how dumb?  Find out Saturday!).

Here's the trick: I just did it.  I didn't spend lots of time planning.  I didn't waste time reading books about how to blog.  I set a schedule and kept myself to it.  Admittedly, that resulted in some pretty poor articles.  You can insert your favorite motivational quote here.

So here's my profound tip to everyone who wants to make an impact (and if you don't, why not?): Keep pushing yourself.  Keep working hard at improving yourself, and eventually you'll find you've arrived.

There's a few blogs that have helped me reach this far, and I'd like to give them some love:
Permission to Suck: It's ok to be bad at something, so long as you don't let it stop you.
Always be shipping: Keep producing "stuff."  It's the best way to learn and improve.
Overnight Success: It Takes Years: Success takes hard work.  Don't expect to be an instant success unless you've put in the effort.

I'm incredibly happy with how well this blog is done.  My goal is still the same: 13+ hits a day.  I have some new ones (encourage commenting, get more followers on Twitter).  The central point is still the same: Learn by doing.

How Not to Demo

I had my first demo Monday night at our school's Inventor's Symposium.  While it wasn't a big pitch to VC's, it was fairly significant demo in that:

• It was my first ever
• Most of the people there were my target market
• It was a large portion of my final grade

Everything went wrong.  My computer broke, the server wouldn't work, and I didn't have an internet connection.  While some of these were avoidable, others were my own dumb fault.  Before I go listing off all the terrible, horrible things I did wrong, let me brag about the one thing I did right.

I had a stack of papers that contained details about my product.  That's it.  While I didn't have a live demo, I was still able to go over my product and explain it's purpose, etc.  While I wasn't able to make any "sales" per se, it still was a confidence boost and prevented the evening from being a complete flop.

Lesson 0: Have an Apocalypse plan.  If everything goes boink, how will you demonstrate/sell?  Can you convince someone of the usefulness of your product without your product?

Astute readers will recall that I was looking for a cloud-based solution to host my project.  That never ended up happening (I was lazy, and didn't want to bother migrating databases).  Instead, I decided to cart my PC down to the hall where I'd be demoing.  When I got everything set up, it hung halfway through boot.  After some trial and a lot of error, I got a new error in BIOS.  Then it wouldn't start at all.

Lesson 1: Remain calm as everything explodes.  Worry about broken things later and focus on selling what's working right now (even if it's just a piece of paper).

I also tried to fix the problem during the symposium.  I found out quickly that people wouldn't come over to my table if I was elbow-deep into a computer's guts.

Lesson 2: Have two people to demo.  When something like this goes wrong, one person can perform emergency surgery while the other mans the booth.

When I finally got my computer running by some miracle, I realized that I didn't have an internet connection (duh).  This wouldn't have been a problem, except for the fact that I was loading one of my JS libraries from the internet, instead of local.

Lesson 3: Test your demo like you would an application.  Make sure it's as local as possible (even if there is internet, it'll be faster if the code's local).

When I finally got everything in a remotely workable state, there was only 10 minutes of show time left.  I quickly learned another important lesson as I watched people stare blankly at the app in front of them.

Lesson 4/5: Walk your users through the application.  Additionally, make sure the best part of your demo is the one they see first.  They probably won't have the attention span to see more.

I had brought my PC and two laptops to scale demoing and make it so everyone got the "hands on" feel.  Two people showed any interest in doing everything.  I ended up running through the demo (when it worked) almost every time.

Lesson 6: While an array of computers running your product may seem like a cool idea, one big screen is probably a better idea.

Despite the incredible amount of things that went wrong, I still got a very positive response.  I'll be taking this class project and (hopefully) turning it into a real project.  Stay tuned!

Easy to use gets the views

I know it's been repeated again and again: make your product easy to use.  This is rather easy in theory but practice proves time and time again that making an "easy" product is anything but.  For example, take my recent experience with Heroku and Nodejitsu.  I've got a small node.js app I've made for a class that I wanted to demo online (rather than drag my PC-as-a-server around).  I looked into both Heroku and Nodejitsu but ultimately decided to go with Heroku because I had an account there from three years ago (logging into that was a bit surreal).  If you're wondering what "Google strikes" are, check here.

After logging in, I was redirected to the "my apps" section of the control panel.  I could see the one app I'd created ages ago.  I then spent an embarrassingly long amount of time looking for the "new app" button.  I ended up needing Google to find the "new app" walkthrough.  Strike one.

The first half of the walkthrough was fairly simple.  Turns out I could only create a new app through my Terminal.  I installed Heroku, set everything up with git, and created my new app.  All went well.  Until, of course, I tried to do anything with my new app, namely update code.  The tutorial had Heroku adding itself as a git remote.  Turns out it didn't.  After hashing through a few options (and Google strikes two and three), I finally gave up on the automated method and added it myself.

Thanks to this brilliant problem-solving, I got an entirely new error.  Google strike four.  I discovered that Heroku expected me to add an RSA key manually.  Oops.  My app FINALLY was pushed to Heroku....and died.  Heroku helpfully told me to check my logs.  My fifth and final Google strike was committed trying to find my logs.

Heroku was supposed to be the darling of YCombinator.  I'm a huge fan of YC and was willing to give it the benefit of a doubt.  Sadly, my experience was not very good.  Looking for another option, I found Nodjitsu.  The experience was incredible.

Like most users, I don't like creating an account to try out something.  Nodejitsu created a system that didn't feel like I was creating an account.  I had the jitsu CLI tool installed before it even asked me for a password.  The instructions provided were concise and clear.  There were two issues during setup, both of them mine.  Both times, jitsu pointed out the source of my error and told me what might have been causing it.  When I finally fixed my problems, the app uploaded cleanly (and Nodejitsu automatically incremented my version, something I always forget to do).

There were still issues (I needed to set up a database) but overall, Nodejitsu was clean and helpful.  Jitsu helped me through my own dumb mistakes and kept quiet otherwise.

Have a story about a great experience?  I'd love to hear about it in the comments?  Want more of this in 140 characters or less?  Write a script to parse my site into blocks!  (Alternatively, you could follow me on Twitter).

Source Saturday: No Actual Code

Sadly, most of the code I've written this week has been boring code for a very unboring project.  So instead of going on and on about .getElementById and textContent, I decided to devote the non-Sherlock-watching time of my Friday night understanding whatever HTML5 is.

Honestly, I haven't paid much attention to the various *tmls.  XHTML, HTML[num], etc, didn't matter to me.  I had real coding to do.  The vague things I heard about HTML5 made it seem like yet another buzzword for "hip" business to claim they used.  (I guess I technically used it in one of my Chrome Extensions that never got anywhere).

After reading through large portions of Dive in to HTML5, (and quite a few really lousy tutorials) I realized just how wrong I was.  Let me try and summarize a few important bits:

There's no such thing as "HTML5 compliant."  HTML5's goodness is made up of lots of component parts, including <canvas>, <video>, and non-tag items like localStorage.  Support for these components depends on browsers.  (You can check your browser here or the whole browser ecosystem here).

I'm glad we've finally got a competent <video> element which embeds a video on the page (surprise!).  <img> has been around since the early 90's.  Gifs have been sort of a stop-gap measure between the two, but they're slooooow.  One of the brilliant things about <video> is how it approaches the multi-format nature of video.  Web designers can point to multiple video files, and the browser can select one of the format it supports.

Local storage is another nice thing in the bat-toolbelt of HTML5.  While it's not exactly a tag, it allows websites to store data local to your machine.  Privacy "advocates" will probably yell and scream at this one, but the data can only be accessed by the website that put it there.  Local storage should not be used to store sensitive data, as it can be retrieved/modified by anyone with physical access to your machine.  I technically used this feature in my BlogMe extension.

Another thing that privacy advocates won't be happy about is Geolocation, which speaks for itself.  Fortunately, most browsers will ask for permission before giving away location-specific data.  This isn't technically HTML5, but is part of the feature set that the "new web" is bringing.  (What are we up to now, Web 8.0?)

There are many, many other cool features of HTML5 that will save lots of time and make life easier for everyone.  If you're interested in finding out more, read the full tutorial I linked to at the beginning.  It's wordy but worth it.

Password problems

A recent Wired article makes the claim that passwords are obsolete.  Normally, I'd just pass it off as yet another blogger trying to get hits by claiming that "$technology is $bad for $reason" but this is Mat Honan, who had his digital life destroyed earlier this year.

Honan has done some incredible research into the (lack of) security in our lives online.  He claims that it would only take him minutes to acquire your passwords to a plethora of online services, including banks, PayPal, and email (which is central to your online identity).  In fact, he can do all of these things even if you've got an incredibly difficult password (like Tr0ub4dor&3).

The biggest problem with passwords isn't the passwords themselves.  It's us.  Human weaknesses result in websites providing the option to reset our password.  So long as that option exists (and breaking it is easier than breaking a password), we'll be insecure.

Alternatives to "just a password" exist.  One of the best (in simplicity and effectiveness) is two-factor authentication.  GMail has it, and if you have a Google account, enable it now.  This isn't totally effective, as it's easy to convince the phone company to redirect your call.

More secure solutions will be found but they will invariably result in a loss of convenience.  I convinced my dad to use two-factor but he turned it off because my mother got tired of chasing down dad's phone.  The convenience factor is what's stopping fingerprint and eye scanners from ever reaching the mainstream.

Passwords need to be done away with - but they're here to stay.

(If anyone's looking for startup ideas, Atwood's pipe dream might be a good place to start)

Projects to pursue your passion by

I've always been an advocate of the project learning style.  Simply put, learn the basics of the language (syntax, simple code structure) and then find a project.  The project shouldn't be overly ambitious (you'll be overwhelmed)  or easy (you'll be bored).  The trick is to find a non-trivial example that only involves one or two things you don't know yet.  You'll be forced to learn new concepts while exercising the ones you've learned already.

Finding a good project is harder than one may think.  It's easy to imagine massive projects (we'll be the next Facebook!).  Here are some tools to help you find your next project.

The first thing that came to mind (and half the reason for this post) was an article I saw on Hacker News: Learn a Programming Language Faster by Copying Unix.  This is a nice way to learn language basics like file I/O, interfacing with the user, hashes, and HTTP.  The problem is that most of these examples are incredibly basic.  You could find bigger projects as you learn (apt clone anyone?) but there are better options.

My CS professor always recommended games and puzzles as a learning mechanism (and he's right!).  There are two nice things about choosing a game as your project: They're scalable and impressive.  When I say scalable, I don't mean in server size or users but as a project.  Once you've created the business logic, you can implement a GUI, add more rules, or save sessions in a database.  There's a lot of new things you can learn incrementally through the project.  Additionally, games are impressive.  Not so much on a resume.  It's something nice to show off to your friends.  Let's be honest.  At this level, you won't be winning any coding awards.  Your friends, on the other hand, will be more than glad to help you with ideas for expanding and improving your game.  (One important thing is to keep the game simple.  Clone Blackjack but don't try to make the next CoD or Halo.)

Finally, if you're going to learn a web technology, it might be a good idea to build a blog framework.  Blogs start out simple.  All you really need are two pages: one to post the blogs, and one to display them as well as something to store them in the interim   After that, there's a lot of places you can go.  I strongly suggest that you write them from scratch instead of using a plugin/library/what-have-you.
Here's some ideas to get you started

• Add a template system.  Because what use is a blog if it isn't pretty?
• Create a comment system.  These can get tricky, especially if you add things like voting and authentication.
• Pagination.
• Search.  Bonus points if you do something more than a simple database "LIKE '%$searchterm%'"
• Unit testing.  Not exactly blog-relevant but a good thing to know nonetheless.

You can follow my own journey in blog creation in node.js form at my GitHub.  If you're not interested in node but still enjoy the blog, follow me on Twitter to get notified when I post (I promise, I'll get a real picture soon)

The trouble with StackExchange

I love the idea behind the StackExchange family of websites.  They've taken something that usually was a horrible experience (Q&A on the web) and created an entirely new way to solve almost any kind of problem.  I also like how they're unafraid to branch out to other topics, even beyond technology.  (For the curious, Biblical Hermeneutics and Parenting are some of the ones you wouldn't expect to find).

The problem is that us geeks tend to be very territorial.  We want our sites to be just as we want them, without all the riffraff.  And there's a LOT of riffraff.  Far too many "professional" programmers see StackOverflow as a crowdsourced application to write their code.  Spend a few days in the PHP tag and you'll see what I mean.

The deluge of bad questions creates a calloused attitude among members who have been around for a while.  One example of this is my recent question at Ask Ubuntu.  While Linux Mint is off-topic there, the Ubuntu Keyserver isn't.  My question involved both.  While it was determined that the question was on topic, it still was closed.

This is an edge case that left me with a bitter experience (and no answer to my problem!).  StackExchange has some great tools for dealing with bad answers but very few for dealing with false positives.  The canonical (pun intended) answer would be to flag my question for moderator attention.  This puts the decision in the hands of a single person which isn't very useful.

It would be easy to dismiss this as a one-time edge case.  It may be.  In any case, it should not be taken lightly.  Tales like this can ruin the user's experience.  If you're building a social website, make sure you have an effective system to avoid these false positives.  StackExchange recently added a reopen queue. We'll see if it stands the test of time.

Thanks for sticking with me in this rant.  If you liked it (or have an idea to solve these sorts of problems) add a comment below!

Source Saturday: In which I learn node

Earlier this week I saw a job posting for my dream position with one caveat: They wanted a node.js guy.  Rather than ignore the fact that this once-in-a-lifetime opportunity had opened up, I decided to use this as an opening to demonstrate how proactive I am.  (This also explains why I've got so many job application posts lately.)  After going through

One of the nice things (or so I've heard) about node is that there's a LOT of features I have access to through npm.  I prefer to learn by doing so simply slapping together all the parts of a blog makes me no better than someone who codes exclusively in jQuery without understanding the JavaScript underneath.  In fact, I could pull an entire blog platform if I so wished.

Building the basics in node.js was actually a pleasure.  I really enjoyed the callback model and found it easy to wrap my head around what was going on stack-wise.  The project also introduced me to the noSQL movement (specifically mongodb).  

There's a lot of things I like about mongodb but I found one irritating issue.  Simply put, my code looked something like this:

function handlePageOne(req, res) {
    //Open database connection
    //Put something in the database
}
function handlePageTwo(req, res) {
    //Open database connection
    //Pull something from the database and add it to response
}

Simple?  Yes.  Correct?  Not a chance.  As it turns out, one actually needs to close the database connection as well (this is very important in a single thread environment like node.js).  What I ended up doing was adding a db.close() statement at the end of every database block.  You can view an example on GitHub.

This was only a toy application intended to help me learn the basics, so I stopped there.  On second thought, there are much better ways we could manage this.

We could (like Poet) not use a database at all for managing posts but rather store them as separate files.  This would eliminate any database issues and open new ones, mostly configuration.  Another option would to be to abstract the database calls into a separate function, ensuring to keep callbacks managed correctly.
EDIT: Another alternative would be to use an object modeling system like mongoose instead of rolling your own.

What does "I Know" mean?

Recently, I submitted an application as part of the work I'm doing for my next job.  As a programmer, I needed to communicate what languages I knew.

I'd like to avoid giving the impression I'm better than I am.  That might get me the job but I won't keep it.  If they're willing to take on an energetic learner, then I want them to know what they're getting so there's no issues or communication that could result in firing or bad feelings.

How can a job-hunting programmer clearly communicate their skill in a language?  I've already asked a related question on Programmers.SE.  There were a lot of excellent answers but let's focus on our topic: a resume.

One solution is to simply group them all together, perhaps ordered by experience.  The problem here is that there is still a lot of ambiguity.  If I've listed "C++, C#, Python," does that mean I have 6 months or 6 years of experience in C++?

Another easy answer is to simply list the years you've worked with a language alongside the language.  This also leads to definition problems, as I've "worked" with Python for three years now but my skill in Python is nowhere near someone who's been using it professionally for three years.  This tactic may impress HR but I hope that any competent programming manager understands that experience doesn't make you a better programmer (for more on this, check out Peopleware).  Feel free to try this tactic if you want to impress a non-programmer.  I wouldn't use this.  If a non-programmer is the one hiring programmers, do you really want to work there?

So the simple approaches didn't work.  One could include all of the major projects one has completed.  This takes up a lot of time and space and you could run into NDA issues.

So what did I do?

I've divided up my programming experience into three categories:
Professional: Languages I've been paid to write in (for a significant period of time.)
Project: Languages that I have completed a decent-sized project in.  Something bigger than Hello World.
Familiar with: Anything that I've written in that doesn't fall into the above categories.  Something more than Hello World but less than a full project.  I also put languages here that I have built something in a while ago.  For instance, I once built a virtual stock market in C++ two years ago.  Naturally, my knowledge has lapsed somewhat.

I chose this system because it was easy for me to categorize my knowledge as well as explain the system to others.  In addition, I included a link to my GitHub account to (attempt to) provide proof that I could code.

Apply with Wishlist

I love Amazon's wishlist.  It's a great place to store books that I'm interested in but don't have time (or money) to read just yet.

While I was applying for a job yesterday, a peculiar thought hit me.  Should I include my Wishlist with the application?  This might seem awfully cocky of me.  On the other hand, there are some good arguments for it.  You can learn a lot about who someone is by the books they want to read.

1. Am I interested in general programming, or just one problem domain?  
2. Do I seem like the sort of person you'd want to discuss things with over coffee?
3. Am I ambitious?

I should hope that my list provides a good answer to all three.

(You can find my list here if you're interested in supporting Recoding!)

Scream Moments

Lightning flashes, revealing a drenched man standing in the pouring rain.  He's just lost everything: family, job, faith.  Losing all sense of humanity, he arches his back and howls a primitive scream.  Raw emotion pierces through the night, leaving stunned silence in its wake.

Ok, so this probably doesn't sound like your typical day at the office.  (or at least I hope it doesn't).  You've probably wanted to scream the same way.  Scream Moments can come from many directions.  Perhaps your boss just dropped a reverse eagle in your lap.  Maybe the API you're forced to work with slowly drives you insane.  It could be that one bug that Just. Won't.  DIE.

How often do you find yourself in such a situation?  Why?  For this example, let's look at moments that come from external sources.  The four hours you spent fixing your own stupid bug may frustrate you, but it's not a full-on Scream Moment.  True Moments come from external sources. There are two types of sources for these moments: technical and personal.

Technical Moments

Code is evil.  Lousy programmers are evil.  Dealing with this evil doesn't make us a paladin (drat!).  It just annoys us.  Have you ever worked with an API that was so mind-boggling messed up that you wanted to beat those responsible senseless?  How about ridiculously illogical language issues?

Technical limitations will always be a problem and yet they tend to crop up more on some projects.  It's important to note why.  Is it an external limitation?  Has management been sold on a product that's slowing you down?  These moments are fixable.  After the initial wave is gone, analyze  what happened.  Find the source of the problem and fix it.  That's what a programmer does, right?

Sometimes, you can't fix it.  If you find yourself encountering a lot of problems that you either can't solve or aren't permitted to solve, perhaps it's time to start working your next job.

Personal Moments

Most technical moments are fortunately easy to fix.  A slow computer can be upgraded, language features can be restricted (through the language itself or office policy), and debuggers are a godsend.  People, on the other hand, are a lot harder to change (Sadly, DNA isn't hosted on GitHub).

Personal Scream Moments are much harder to deal with.  They're usually much more than a simple office spat about coffee location.  They're usually caused by the fourth coffee-related spat in as many days.

Solving these moments (from either a management or worker perspective) require a lot of effort and creativity.  There are many books/blogs/seminars about this sort of thing but two that have stood the test of time are Dale Carnagie's How To Win Friends and Influence People and Stephen Covey's The 7 Habits of Highly Effective People.

7 habits teaches us one big lesson in resolving and avoiding these moments.  We should strive to only work within our circle of influence.  Don't focus on things that you can't change.  Centralize your efforts around the issues and problems that you can influence.

One of two jobs

It's no secret in the CS industry that we switch jobs a lot.  That's not an issue.

At any point in time, we're working one of two jobs:

• The job we have now
• The job we'll have after this one

Working your current job is, well, working your current job.  Working your next job is when you're still technically employed by your current employer but your mind and heart are already trying to land your next job.

Currently, I'm working my next job.  Why?
Poor management: To me, it seems that management cares about product instead of people.  They'd rather have a crummy product now (and never fix it) instead of creating a process and framework to create a much better product down the line.
Sales issues: We have an incredible sales team.  They can sell products that haven't even been invented yet.  The problem is, it's now Programming's responsibility to build said product, no matter how difficult or ridiculous it is.
Wrong career direction: What I'm learning in my current job is not where I want to go.  I want to learn how to build great products in PHP, instead of how to hack together a project as fast as possible.

How about you?  Are you working the wrong job?

There are three main questions to ask yourself.

Is money important to you?  If so, can you make more at another job?

In one of it's brief moments of clarity between long stretches of hilarious insanity, the DailyWTF discusses salary.  The main point to be taken is not that we should strive to make as much money as possible, but rather are entitled to a fair salary and should demand it.  If you can't get a fair or living wage, switch jobs.

Is your current job holding your career back?

Java programmers have higher salaries.  The reason for this is that Java doesn't teach you anything new.  In order to entice programmers, Java shops need to pay more.

In order to make sure your career keeps pace in a fast-moving industry, you'll need to make sure you can learn on the job.  Programmers.SE has an excellent article on this.

Could your work environment use some improvement?

Are meetings held only when needed or when the boss wants to feel important?  Is project scheduling done with proper foresight or with deadlines set to the next big conference?  Work environment can be more important than either salary or learning.

Obviously these three things aren't everything but they represent a lot of what you should be looking for in a job.

EDIT: some tips on online job hunting

Source Saturday: While vs Recursion

In a previous post, I mentioned that I had created a Haiku generator.  One response was fairly concise:

Make this recursive

Most likely, it was intended as a joke (albeit a poor one).  However, will recursion really improve getLine()?

In general, recursion leads to code that is more difficult to understand.  Given the stack-based nature of recursion, it's harder to conceptualize vs. regular iterative code.  In some situations, it's worth the extra effort to find a recursive method because an iterative solution is difficult or impossible.  One example of this is reversing a string because recursion naturally creates a stack that the coder would have to implement in an iterative function.

That said, I can't see any feasible reason why we'd need a stack for getLine() but let's be Mythbusters and try it anyway.  I used Python's timeit library to run tests on the two variations of getLine().

testRecursion.py returns the following results:

Iterative: 11.3675792217
Recursive: 11.7112400532

So a recursive solution is slower (no surprise, as generating each function call in the stack takes up valuable number-crunching time) but not by a whole lot.  Sorry Zirak but I'll keep this solution iterative.

Finally, a Haiku about this process (not generated by Python):

Zirak says: recurse!
Never used timeit before
Turns out I am right

Should you reinvent the wheel?

One important concept we've all heard a billion times is Don't Repeat Yourself.  Simply put, this means that we shouldn't copy/paste code all over our code.  That's what functions were created for in the first place.  There's another side to this.  Obviously, re-using the same code again and again is a recipe for disaster (you need to change something in 40 places?  Too bad).

There's another angle we can look at this.  If there's already an email framework or database abstraction out there, why write your own?  My absolute favorite part of the open source movement is that we now have access to thousands of libraries, frameworks and plugins not only for free but we can view the source code as well.

The reason viewing the source code is so important is that we can learn from a product instead of just using it.  Anytime I want, I can load up GitHub and learn how to find Waldo, learn (and help develop!) an entirely new language, or crank out some poetry.

Full disclosure: The Haiku one's mine.  And I made it despite the fact that many other generators exist.  Am I "reinventing the wheel"?  Absolutely.  Did I learn a lot about Python and the English language while I did?  Also absolutely.

Reinventing the wheel isn't a bad thing.  It may be tedious in some scenarios, but it's a valuable tool in your utility belt.  It's a key step along the way to increasing your knowledge.

Richard Feynman said it best: "What I cannot create, I do not understand."