Howdy, folks!

This is just a quick status report about what's going on with Gun.io.

Still roamin' the prairie..

On the whole, things are going really well! We're starting to find more jobs and freelance gigs for you all, the community is growing, we're adding more features to the site and, best of all, I think more and more people are starting to understand what we're trying to do here: find better programmers for people seeking workers, and to provide better opportunities for developers from the open source software community.

Bugfixing

The codebase here has grown enough that it's time for us to go through a complete audit, do some major refactoring and find and squash any outstanding bugs. Our accounts and notification in particular needs some attention, so hopefully any of the issues some of you may have been having will be resolved over the course of the next week.

Community Guidelines

In an effort to retain our high-quality talent pool and our top-notch customer experience, we have introduced a set of community guidelines which job applicants must abide by when applying to gigs. The rules are quite simple, really: demonstrate open source contributions in relevant areas, speak fluently in the language of the job poster and address the specific needs of the poster rather than submitting a resume to every job that's posted here.

If these guidelines are repeatedly broken, we may have to suspend the accounts of people who are persistently in violation. Fortunately, we haven't had to do that yet, but we wanted to set a high standard now so that hopefully it will never come to that.

More OAuth Providers

I love this logo.

This is something we'd like to have some more feedback from you guys on actually.

Since we added GitHub-based registration, it's become the most popular way to register with Gun.io by quite a large margin. It's quite possible that in the coming few weeks, we may make it so that the only way a person can register, besides posting a job, is by using a code-hosting OAuth provider. That way, hopefully only those with open source code portfolios will be able to join, which keeps our talent pool at the highest quality.

Still, I feel that we owe some similar services to people who choose not to use GitHub as their code host. I've reached out to Gitorious to ask them if they want to become an OAuth provider we can use to sign up. BitBucket are also an OAuth provider, so we may also integrate them into our signup process as well.

Would this be useful for you guys, or is everybody just on GitHub?

Suggestions?

Are there any other features you'd like to see on the site? How can we better serve you? I'd really, really appreciate any feedback you have - we're just trying to build the best possible service for you to use, so if you let us know what you want, we'll try to build it for you!

If you have feedback, you can either leave it in the comments below or shoot us an email - contact@gun.io - we read and respond to all the email we get as soon as possible!

Thanks!

Across the globe, governments have adopted policies of seizing domain names as a way to shut down content they find objectionable. This has become a primary censorship tactic of the United States government (through the Secret Service, Immigrations and Custom Enforcement, DHS, and the Department of Justice, via the FBI and the DEA), and it seems that we have set an example, as the domain seizure tactic has been used by other oppressive countries, such as in the Libyan seizure of vb.ly.

Get used to seeing this.

Even more worryingly, we've recently seen the United States Secret Service seize a domain of a startup company, JotForm, entirely because of user generated content. If this trend continues, it could mean very bad news for young entrepreneurs looking to build the next YouTube, Facebook, or Google. So, where in the world is safe to purchase a domain name from?

Bill!

To find out, I talked to Bill Woodcock, director of Packet Clearing House, a non-profit research institute that supports operations and analysis in the areas of Internet traffic exchange, routing economics, and global network development. Basically, they make the internet go.

This is what we discussed.

Criteria

Before we make our list, we need to define some criteria for what we're after. We aren't just interested in a finding a country to host our domain for our user generated content (which could mean anything from cat pictures to pirated sports streams), gambling website or porn site, but also one which will also stand resistance against political attacks, as well as logistical ones. So, let's get started.

The Real Issue

Yeah, right.

Before we get really nitpicky, here's the one-line take away message: Avoid VeriSign. Almost all of the domain seizures so far have come with the involvement of VeriSign. Verisign is the authoritative registry operator for two of the most important top-level domains, .com and .net. It is also the contracted registry operator for the .name and .gov top-level domains as well as the country code top-level domains .cc (Cocos Islands) and .tv (Tuvalu) (Wikipedia citation).

VeriSign is a Washington DC-based company with a lot of government contracts and government friends, and so they basically do whatever the US government asks them to do, without asking any questions.

So, we can rule out .com, .net, .name, .gov, .cc, and .tv. Which is a shame, because .tv looks great for video websites.

Since Wikileaks also had their .org domain temporarily suspended, we should also rule out domains administered by Afilias, so we can rule out .info, .mobi, .org, .asia, .aero, .ag, .bz, .gi, .hn, .in, .lc, .me, .mn, .sc and .vc.

What We Don't Want, What We Do

So, now that we've ruled those out, what else should we be looking for? Here are some bullet points.

Avoid:

• Small countries.
• Countries with military mutual defense agreements (NATO, etc).
• Countries with high levels of corruption.
• Members of the ECHELON signals interception/monitoring pact (AUS/CAN/NZ/UK/US).
• Countries with large amounts of debt.

Look for:

• Countries without debt.
• Countries of medium size.
• Militarily neutral countries.
• Liberal countries with a high freedom index.
• Countries with high levels law and order.

Basically, look for countries that have low levels outside influence, financially and militarily. Greece and Estonia, for instance, are probably some lousy choices for obvious reasons in this regard. Unfortunately, we're also forced to rule out Iceland's .is, as although they're trying very hard to position themselves as a pro-transparency, pro-press-freedom and generally hacker-friendly nation, their economic collapse has left them extremely vulnerable to outside influence (even with their rejection of the austerity package.)

So what does that leave us with?

The Short List

Illustrating the internet requires boring graphs
or nonsensical pictures like this one. I'll take the latter.

This is by no means meant to be an exhaustive or authoritative list, but here are some candidates which meet all or most of the criteria which we have laid out.

Switzerland: .ch

The most neutral country in the world, Switzerland seems like an obvious choice. .ch is administered by SWITCH Information Technology Services, who mostly deal with university networks and provide services to open source projects, which is a big +1 in my book. They also manage the .li (Liechtenstein), which could serve as a better alternative than .ly for those who want web 2.0 domains that sound like adverbs.

If you want further endorsement, Wikileaks keep their primary mirror on a .ch domain now. Their list of mirrors might give you some ideas for other safe countries as well. Encyclopedia Dramatica have also moved their operation to a Swiss domain.

Norway: .no

Financially independent and socially liberal with a high index of law and order, Norway is a good choice. Unfortunately, technically registration is only open to organisations and companies registered in the Brønnøysund Register Centre, which is another hurdle to jump through.

Beautiful fjords, as well.

Sweden: .se

This is a pretty obvious one as well. They're an independent country with low debt, high stability and they're the birthplace of the political pirate movement.

It's also worth noting that even though the founding members of the Pirate Bay were tried and convicted in Sweden, ThePirateBay.se is still alive and kicking, showing just how resilient a Swedish domain can be.

United Arab Emerates: .ae

Probably the best choice for those seeking a domain in the Arab world, the UAE is a rich country with progressive values by middle eastern standards. Their oil power gives them a high degree of autonomy and resilience to external pressure, and I can't imagine they care all too much about Western politics and copyright law. Palestine's .ps domain may also be a decent runner up.

Mauritius: .mu

The island nation of Mauritius off of the coast of Africa is an independent nation with a European history and may be a great choice for those seeking an African domain name. It's also gaining popularity for music startups, so this might make it attractive for music sites with user-generated content.

Singapore: .sg

Singapore is a strange country. They're one of the most advanced and socially progressive Asian countries with financial autonomy, but they also have an extremely harsh penal system. Still, they meet all of our other criteria. However, they do technically require a presence in Singapore.

I have not found an Asian domain name which meets our criteria without requiring a presence inside the country, unfortunately. (If you know of one, please post it in the comments below!)

Nowhere/Everywhere: .onion

None of these options suit your needs so far? For those seeking complete anonymity and autonomy in their domain name of choice, there is the '.onion' domain name, for sites which are only accessible on the Tor anonymity network. These websites are very, very difficult to locate and knock off-line, and anybody can set one up for free, but they're also only available to users who have Tor installed and running. Perhaps not the best choice for your hot new startup (unless, maybe, you want to start a casino), but a good choice if you want to publish information under the veil of anonymity.

Choosing a Registrar

"No Bullshit."

Who you register your domain with also matters. Since VeriSign are in the pockets of the US Government and GoDaddy are a bunch of elephant-murdering, SOPA-supporting bastards, I'd strongly suggest avoiding them.

Instead, use Gandi.net, who have a stated policy of "no bullshit," or the official NIC of the domain you're trying to register under.

Wrapping Up

Hopefully, you've now got a better idea of where is a safe(r) place to register your domain. I'm not making any promises about security here, but hopefully now you can avoid some of the most obvious mistakes and have a good idea about the things which you should be considering.

It's also worth pointing out that I'm only talking about domain names and their political resilience here, not technical domain name security (DNSSEC), or legal implications about where a service is hosted and operated. Those issues vary wildly from country to country, and I'll explore them later if there is interest in this article. Special thanks to Bill Woodcock for allowing me to interview him for this article, buying me tacos and for keeping the internet going.

Are there any other countries which meet the our criteria which I've left out? Am I wrong about some of the countries listed above? Please leave your comments below!

Extremely quick blog post!

Here's how to make a crude template tag which lets you add the HTML5 'placeholder' attribute to your form field inputs and textareas in a Django template.

Drop this in /yourproject/yourapp/templatetags/ as placeholder.py, and then use it like so:

{{yourformfield|placeholder:"This is placeholder text."}}

Tada!

Hey there, green buddy!

So, you've got an idea for a new mobile app, or perhaps you have an iPhone app and you want to hire an Android developer to port your iPhone app to Android.

What should you be looking for? Since Android is based upon Java, which is the language of choice at many computer science schools, there are lots of people who claim to be able to write Android programs. However, Android is it's own beast, and simple knowledge of Java is not enough to claim competency and skill as an Android developer. There are many Android-specific features that your developer needs to know about.

So what should you be looking for? This guide should give you a good idea about how to hire android developers.

Open Source

Get it? It's Open!

What makes Android so appealing to developers, manufacturers and customers alike is it's open source nature.

Make sure your Android developer has a good knowledge of the Android open source ecosystem. There are many good open source libraries that they should be aware of, and hopefully they should have some open source projects of their own.

Even better would be if they have some involvement with the Android Open Source Project itself, either in the form of bugs filed or patches submitted. This shows a deep understanding of the Android platform, which can be extremely useful. It'll also mean they know where to take code from, as the AOSP has some great reusable code in it. Remember, good artists copy, great artists steal!

Java Fundamentals

Lame Visual Pun.

Although Java knowledge alone is not enough to make a great Android developer, mastery of the Java fundamentals are a must.

Does your developer know what data types to use in the right situations? Do they know how to properly use synchronized? How about JNI, do they have experience with the Java Native Interface? All these things show advanced understanding of the underlying Java platform, which serves as the foundation for any good Android application.

Jank

Android is plagued by what we developers colloquially call "jank." When an iPhone app scrolls smoothly and the Android counterpart stutters, that's jank. When an Android app overrides the back button inappropriately, has an ugly title bar, or crashes unexpectedly and unrepeatability, that's jank. Jank sucks.

Bring up this concept with your developer. They'll know what you're talking about, and if they're up to snuff, they'll immediately start getting defensive about their beloved platform and start offering their own anti-jank patterns.

They should know about how to properly use database-backed ScrollViews, reusable ViewHolders, and how to only redraw the parts of the screen that have changed. Ideally, they'll have seen the Google I/O talks talks on how to avoid jank, and their open source projects will reflect this knowledge.

Versioning

What a tasty pie!

Android has a turbulent past. 1.0, 1.1, 1.2, 1.5, 1.6, 2.0, 2.1, 2.2, 2,3, 3.0, 3.1, 3.2, 4.0, and beyond! All these versions have their own unique set of APIs and capabilities. Can your developer handle all of them?

You should decide early on which version of the platform you want to target.

In fact, it gets even more complicated than that. Unlike the iPhone, which has a standard screen size, Android devices have many, many different screen sizes, resolutions and pixel densities. Can your developer handle all of those, too?

Oh, and it actually gets more complicated than that. Different manufactures put different APIs, codecs, applications and skins on their own devices which sometimes significantly alter how an app runs (see the previous section on jank) - is your dev prepared for all of the curveballs they throw? Make sure they have some knowledge of the challenges you're going to face, and that it is factored into the timeline of your project. This bullshit can take a long, arduous time to test if you're not prepared for it.

Publishing and Distribution

This is a pretty crappy icon.

Once the app is ready to push, will your developer be able to help you publish it?

It's actually quite tricky to publish an Android application and gain traction. Although it's easy to actually get the thing online (as there is no review process like on the iPhone App Store), once things are published, it's basically a free for all.

Make sure your developer can guide you through how to publish an application, how to make sure application comes up in the search terms which your looking to target, how to manage customer feedback and keep your rating high.

There are also many alternative app stores, like the Amazon Android App Store. Can your developer help you publish to those as well?

Conclusion

Obligatory cartoon robot.

Hopefully now you've got some good ideas about what to look for when hiring an Android developer.

And where should you look to find one? Why, right here at Gun.io, of course, where there are thousands of great developers from the open source community waiting for you to hire them! Find an Android developer by posting a job and start getting high quality leads right away!

Did this article help? Is there something I'm missing out? Leave a comment below!

PS: We're also looking to write more of these articles about how to hire developers for specific languages and platforms. If you'd like to write a guest post (with a link back credit and a plug), please send us an email!

Mmmm.

If you've ever met me (especially if you've met me in the early morning), you'll know that I'm a caffeine addict. I'm very grumpy if I can't get my morning jolt, and I usually drink coffee throughout the day to keep me going. I don't particularly like this about myself, but I try to keep very busy and it's hard to fit in periods of detox with a busy work schedule. As a result, I'll normally drink 3/4 of a pot of coffee during the day and a soda or two at night. All that acidic coffee has started causing me stomach problems, and it's interfering with my efficiency as I have to keep taking bathroom interruptions.

About two weeks ago, I was idling on Hacker News and noticed a comment by somebody who said they had the same problem and switched to caffeine pills instead, with great success. I love self-experimentation, so I decided I'd give it a shot. I've made a little interactive chart to illustrate the effects I've perceived.

Explained

As you can see, I find that if I down a strong cup of coffee or take single 200mg caffeine pill, the coffee comes on faster and reaches a higher peak. The pill still comes on quicker than I expected and takes me up to a normal, human amount of energy in about half an hour. This slowly climbs throughout the next few hours, then slowly tapers off.

With the coffee, however, my energy level keeps rising and falling as the initial cup wears off and I have to drink more to keep going. After a few hours of this, I begin crashing so hard that I'm actually worse off than if I just didn't have anything at all.

Overall, the advantages are quite clear.

The Downsides

There's nothing else in the world that can give me the feeling that coffee gives me, the feeling that there is something in this world that loves me, it is warm and it is black, and I love it like it loves me. There is a reason to keep living, and that reason is love. The ritual of brewing it, the smell, the taste, the burn of the tongue, the flashflood of dopaine as my brain boots up, oh God, I love coffee.

A caffeine pill will not fix a hangover like coffee will. A pill does not make the senses tingle nor does it rev the libido. You can't go on a date to a pharmacy. In fact, the ritual of taking a pill every morning I one that I actually find quite repulsive. I've tried to mask it by having a cup of decaffeinated tea as well, but I can tell. It's not the same.

As Saved By the Bell showed us, the pills can also be quite habit-forming. It's easier to take six pills at once than it is to down 12 cups of coffee. I'll only take one in the morning perhaps one more in the evening if I intend to work late, but I could see how this could be a problem for some people. It's something to keep an eye on, at least.

Conclusion

If you're working long hours and your coffee intake is over 1 or 2 cups a day, I'd seriously recommend switching to a caffeine pill, if only for the sake of your stomach and your bladder. Everybody else, keep drinking coffee. Drink it slowly and appreciate all that it gives you. It is a gift.

This guide will teach you how to properly contribute to open source projects on GitHub. It assumes that you already know about how to use Git for version control and that you already have a GitHub account.

Psstt.. if you already have a GitHub account and you want to earn more money, sign up for Gun.io with your GitHub profile and we'll pair you with people looking for developers based on your portfolio!

Getting Started

GitHub displays these instructions when you start a new project.

GitHub is pretty great about giving advice to users starting new repositories, but it isn't very helpful when it comes to contributing changes back to other projects. Hopefully, this guide will help.

Before you get started, find the page of the project you're looking to improve. Poke around in the code a little bit, familiarize yourself with their development styles, check the commit log to see who is contributing and check out the profile of the core maintainer.

Check the Network

The network graph. Notice that somebody is already working on a 'mobile' branch, so you probably wouldn't want to duplicate their effort.

The first thing to do is check the Network tab on the project to see all the other forks that other people have made. Spend a few minutes digging around in them, as it's quite possible that somebody is already working on the problem that you'd like to see solved. It'll also give you an idea of the activity of the project, and how likely it is that your changes will be merged in.

Opening an Issue

You've got issues, man.

Next, head over to the Issues tab. Have a look around, see how many issues there are and if anybody has opened up the issue that you're interested in working on.

This is an important step that many people forget about, and they just submit major pull requests to maintainers without considering that the maintainers might not have the same intentions with the software as they do. This is especially true if a new feature requires user interface/design changes, as often, that's the aspect of programs that people are the most protective of.

If your issue doesn't exist already, open up a new issue. Standard human interaction rules apply here; be friendly, be polite, say thanks for making the project, describe the bug or feature you'd like to work on and then offer to help.

Hopefully, they'll reply shortly with some input on how to solve the problem.

Making Your Fork

Hardcore Forking Action

Here's the fun part! Hit 'Fork'. Now you've got your own version! Go to the page, get the ssh: url from the box at the top and then

git clone **your ssh/git url**

to your local machine. Hooray! You have the code on your local machine now.

Make Your Fork Track the Original Upstream Repo

It's a fork. Hur hur hur.

This step isn't absolutely necessary, but I find it very useful if you plan on working on this project for anything more than a very quick fix. Use the following commands to add the 'upsteam' (original project location) as a remote branch so that you can get their updates into your branch. Replace the 'upstreamname' and 'projectname' values with that actual user/project name that you're trying to track.

This will add the original project as a remote named 'upstream'. To get the code, type:

git fetch upstream

Then, to merge it into your own project, type:

git merge upstream/master

Tada! Now you'll have an up-to-date version of the upstream code in your current branch.

Setting Up A Development Branch

Guys, remember the old internet? Oh man.

Now you're getting ready to start hacking, you'll want to switch off of the 'master' branch and onto a different branch for your new feature. It's important to do this because you can only have onePull Requestper branch, so if you want to submit more than one fix, you'll need to have multiple branches. Make a new branch like this:

git branch newfeature

Then switch to it like this:

git checkout newfeature

Now you're on your new branch. You can confirm this by simply typing 'git branch'.

Hack!

This part's up to you. Hack along as you normally would until the code is in the state where you're happy with it, it performs the task as described and it passes all the tests you've written for it. Yayyyy!

Squashing Your Commits

Squash. Hur hur hur.

If you're a heavy committer like me, you've probably got lots of poorly messaged commits ('works!', 'broken', 'fuck', 'woo', etc.). This is a bad habit, but I haven't been able to break it yet and I know I'm not the only one!

Before you submit your pull request back upstream, you'll want to squash these commits into a small handful of well-labeled commits. To do this, we're going to use the git rebase command. First, take a look at the commits we've made with git log and figure out the commits that we want to squash. If we wanted to squash the last 3 commits into one, we'd open up an an interactive rebase like this:

git rebase -i HEAD~3

This will bring you into your editor with some text that will look something like this:

  pick df94881 Allow install to SD 
  pick a7323e5 README Junkyism 
  pick 3ead26f rm classpath from git 

To squash those commits into one, change to something like this:

  pick df94881 Allow install to SD 
  squash a7323e5 README Junkyism 
  squash 3ead26f rm classpath from git 

Then, save/quit, and you'll be brought to into another editor session. Describe the changes as well as you can and save/quit again. Hooray! You've squashed your ugly commits into one nice one. Now you're ready to submit a pull request.

Submitting a Pull Request

Once you've commited and squashed your changes, push them to your remote like this:

git push origin newfeature

Then go to that page on GitHub and change branches to the one for your new feature.

Submit a Pull Request!

Then, click on the little button that says 'Pull Request'. This will bring you to a page asking you to describe your change. Describe it thoroughly.

Describe your Pull Request.

Then press 'Submit Pull Request'. Hooray! You did it. Now, you're not quite done yet. If the maintainer finds some problems with your code, they won't want to pull your changes until you fix them. Fortunately, whenever you commit and push more things to that branch of your code, they will be included in that pull request until it is closed.

Accepting And Merging a Pull Request

Bonus! If you're on the receiving end of a pull request, how do you merge the changes? Easy - press the button! GitHub now has an auto-merge button which does everything for you in one click. However, it doesn't always work, in which case you'll have to do the merge on your own machine, like so:

git checkout master
git remote add contributor git://github.com/contributor/project
git fetch contributor
git merge contributor/newfeature
git push origin master

And then their changes will be properly merged into your main master branch.

So, Your Pull Request Was Rejected. Now What?

Some forks are unavoidable.

Sometimes, for technical or organizational reasons, your pull request will be rejected. This can feel really frustrating, and there are a few different ways you can proceed. Just remember to act rationally.

The simplest thing is to simply accept their judgement. It's their project, and a good maintainer knows when to say "no." If their argument is logically sound, you should accept it. If you don't think it's a particularly important feature, hopefully whoever is looking at the project will check the Network and Issues tabs of the upstream project and will notice your changes. However, I think this is a pretty poor solution in cases when the upstream maintainer is wrong or unresponsive.

A better thing to do is write about it. Write about it on your blog, start a discussion on a mailing list, and solicit opinions from the community about what the best way to proceed is. It'll also give some Google-juice to your project/issue, which will help other people who ran into the same problem you faced.

The last option is to sever ties with the upstream and declare yourself the new maintainer of the project. This should only be as a last resort and should only really be done when the upstream project is dead or has gone completely off the rails. That being said, this kind of software deadheading can actually breathe a lot of new life into a project - just look at how LibreOffice has managed to revive the OpenOffice project by severing ties with Oracle.

If you do this, you should rename your project to differentiate it from the upstream, explicitly state your reasons for the schism in your README, and be sure to give proper copyright credit according the the open source license they originally chose. Maintaining an open source project carries quite a lot of responsibility, so make sure you're prepared to care for the project once you create such a schism.

Wrap Up

Hopefully this little guide was useful for getting you started with collaborative software development on GitHub!

If you're a developer looking for more jobs, we at Gun.io would like to help! You can sign up with GitHub and we'll automatically pair you up with freelance and full-time job offers based on your existing code portfolio!

Try the Tech Jobs Map Here!

A New Way to Explore Jobs

Now that we've started to have a steady stream of jobs appearing on our site, we wanted to come up with some innovative and intuitive ways to explore the data we're hosting. So, we came up with a Tech Jobs Map which allows users to visually explore new high tech job opportunities.

Now, whenever any organization posts a tech job, we use HTML5 Geolocation to tag the location and put it on the map! Very futuristic. Currently, the map is only showing a percentage of the total jobs that we're listing, but all jobs posted from now on will have geospatial information as well.

It's interesting to see the current distribution of software jobs, which fall mainly in the north east and in California, as you might expect. Still, you can see quite clearly that there are some opportunities for Midwesterners in Chicago, Michigan and Colorado. Are there no tech jobs in Florida?

Works great on the iPad, too! Excuse the fingerprints.

The Roaming Hacker

In addition to full-time positions, shown in red, the map also shows freelance gigs, shown in blue! There are only a couple right now as most of our freelance gigs are remote positions, but a growing number of jobs were location-specific, so we're showing those on the map as well, and all new freelance job listings can be geotagged.

Hopefully, this can be a handy tool for roaming hackers who like to travel and work, exploring the world while coding!

Future Features

This is only the first iteration of the map. There's still a bit of work to be done, particularly around clustering of jobs, since so many fall in New York and San Francisco. It's also very US-centric at the moment, and hopefully once we're listing more international jobs the tool will be of more use to international hackers.

If you have any ideas, please send us your feedback!

Click on the map to play with JobMappr!

Good news! We've just launched JobMappr, a visual way to explore over 40,000 job opportunities! Check it out! It lists all sorts of jobs, from programming jobs to fashion jobs, retail jobs to government jobs, farming jobs to investment jobs, and so on.

It's a much more interesting way of exploring what's out there around where you'd like to work, as you get to picture yourself in all sorts of different roles and ponder what your life would be like in all those various places. It's also really interesting to see the various regional trends, to see that there are lots of jobs at financial firms in New York, lots of retail and defense contractor jobs in the Midwest, things like that. Dive in and see what you can find!

After building our Tech Jobs Map, it was only natural to generalize the idea. JobMappr uses a variety of different data sources to find as many job opportunities as possible for all sorts of people. Jobs posted on Gun.io will now also appear on JobMappr, as well on the Gun.io Tech Jobs Map, website, in the usual notifications, etc.

Breaking the Niche

JobMappr!

I was recently turned onto Amy Hoy's program, 30x500, which goes against the common notion that startups need to find a niche markets and dives deeper into how to build products with a broad appeal.

Gun.io has a fairly small niche. Relative to the overall population, only a small percentage of people are software developers, and of that percentage, only a small percentage of those are open source developers, and only a small percentage of those are looking for jobs at any one time. It's something I still think is worth doing because the way that people like me find programming work could be greatly improved, but it's still a small niche.

JobMappr has a much broader use case. Right now, the US unemployment rate is 8.2%. Multiply that by the US population, and you've got 25.3 million people who could possibly use this service. Not bad. Of course, the quality of the job opportunities which are scraped for JobMappr are a lot lower quality than the high-quality careers we list on Gun.io, but there are still quite a few good opportunities there as well.

Technology

I love the Memcached banner, too.

The fun part of this project was getting the responses to be as fast as possible. The first version took over 60 seconds to load the page, and the initial query was over 14M of data! Not good. So, instead of rendering the entire database as a template and passing that to the client, the data is now separated from the code on the server, and all of the data is passed asynchronously. Additionally, it makes heavy use of Memcached, which greatly improved the response time. Now, the data points load in under two seconds, even faster than the map tiles. Hooray!

This project is still hosted on my hobby-box, so I'm not sure how well it will scale. If there is a sustained interest in the product and performance issues crop up, I will move it into a larger and faster dedicated server.

Future

Ooooo.. data is fun to play with.

There is still some work to be done. The robots are adding more and more data all the time (a few thousand a day), but more importantly the data is quite noisy and difficult to navigate.

To solve this, I'm actually going to use some of what I learned in school for once, (yay!), to cluster the tags with the k-means algorithm. I'll try to make it as generic as possible and open source it, if I can. More on that as it happens!

Want to know more about JobMappr? Get in touch or leave a comment below! We'd love to hear any ideas you have for features and so-forth.

Enjoy!

Earlier this week we launched our new product, JobMappr.com. Of course, you didn't hear about it because we completely flubbed the launch. Somebody submitted it across social media sites before we wanted them to and it got to the front page of HackerNews, at which point the server completely melted and the post fell off into the abyss. Crap. Oh well.

It went something like this.

Here's what we should have done instead.

Launch Strategy

First of all, it's my opinion that if your business has a critical dependency on a successful, buzz-heavy launch, then you're doing it wrong. You can't just launch a website, cause a buzzstorm and suddenly have millions of users who love your product. Maybe this has worked for a very, very small handful of companies, but it won't work for you, so just put that idea out of your mind. Even at its best, launch buzz is really just a bonus to make you feel good, a small reward for all your hard working building a product. Check your traffic stats 3 days after a successful launch and realize that it didn't have quite the impact that you were expecting.

Get used to seeing this shape.

Goals

The goal of your product launch should not to become a household name overnight. If you're just launching, you're not even ready for that anyway. Your goal should be simply to be noticed by a small group of people who can become users, who will engage with your product and give you the precious feedback that you need to iterate and improve. That's it. Launching is step 0.

Demographics

Figure out who your target audience is and how they consume media. Focus on quality over quantity - 50,000 views from people who have no use for product is less valuable than 500 views from people who can use it.

Timing

I appear have stumbled onto a cache of firework mishap animated gifs. Apologies.

Timing is the most important aspect of a launch, and it's also the hardest to control. This is also tightly tied to your target demographic, as different demographics consume media at different times and in different ways. For instance, if you're launching a product to help people find fun nightlife, launch on a Friday! If your product helps people manage their email, launch midweek. (I've found that mobile apps do better on Friday, too.)

Pay attention to the news cycles in the weeks before your launch and figure out the volume and the signal:noise ratio at different times of day to predict the optimal launch time. Pay attention to your competitors as well.

If you're working with bloggers/tech media to cover your product launch, remember that you can't rely on them to release their news about your product at exactly the time they want you to. They're on a different schedule than you are and their motivations are different. I'd recommend trying to reach potential users in more direct channels rather than relying on the tech media and just viewing any media coverage as an added bonus.

Testing and Scaling

Traffic porn.

Before your launch, make sure you can handle the sudden surge of traffic!

I'd strongly, strongly recommend deploying a caching system, (I'm very partial to Memcached), and make sure that your database server is tuned properly to handle massive amounts of parallel connections.

To test your readiness, I'd recommend the service Blitzio, which uses the Amazon cloud to simulate thousands of simultaneous users to your site. It'll give you some basic reports and some pretty graphs, too. It's pretty cool, and has a free tier. Make sure you test the pages with heavy database load as well (dashboards/activity feeds).

If there are problems, profile your application and figure out how you can improve it, then try again until you're satisfied. When in doubt, buy more RAM.

Tell A Story

A good story, too!

Once you're sure you can handle the traffic, make sure you've got your story straight. Having a landing page up isn't enough - you have to answer the question, Why? Give visitors something compelling to talk about.

The internet will probably immediately summarize your product as **Other Service** for **Demographic** ("AirBnb for Dogs!," "GitHub for Gardeners!," "PadMapper for Jobs!," "oDesk for Open Source," etc). You can either roll with it, try to fight it, or try to change the conversation. I'd recommend the later, and the way to do that is by telling a good story.

The might can go something like this: A person has a problem and the current array of solutions didn't help, and something bad happened as a result. You came along with a new approached, changed the game, saved the day, and as a result, a good thing happened.

Be controversial. Don't troll, but it's good to be bold about the problem you're trying to solve. You're trying to make the world suck less, right? So point out why it sucks and why you're making it better.

Capturing Visitors

The final thing to check is that you have a way to continue communicating with the people who expressed interest once the buzz dies down. Don't require them to sign up to see the site, but give them a convenient way to sign up if they want to (and let them know that they won't be spammed or have their contact information sold.)

If you're just launching, I think it's good to personally engage with all the new users you can. Say hello, do some research about them if you can, and ask them what they think about the service and how you can help them more.

This is what running a business is actually all about. Welcome!

Did I miss something? Leave it in the comments below!

This is what it looks like on the inside. See an example or try it for yourself!

We've just launched a new tool for freelancers that generates nice, itemized proposals for responding to RFPs!

The data is automatically populated from your Gun.io account, and you can edit the form inline simply by clicking on any text you want to edit and it'll be saved using nice Ajaxy calls. The design is responsive, so it looks nice on mobile phones, and you can also export to a PDF. It's pretty damn sexy, if I do say so myself.

You can see an example here or try it out yourself here! You must have a Gun.io account first, but that only takes one click if you already have a GitHub account!

We think this is a great proposal template generator for programmers, designers, writers or any other type of freelancer. I've already used it twice myself and clients seem to really like it, too!

Next Steps

Next steps are to make the PDF generation work on the server-side and, more importantly, tighter integration with the rest of Gun.io. We're currently undergoing a pretty serious redesign and this will certainly be incorporated into the next iteration of the site.

Got any feature requests? We'd love to hear them! (Or just leave a comment below!)

What?

(I've griped about this before, so I'll try to keep this post short.)

GitHub updated their graphs page today. Lovely! Unfortunately, they didn't update the 'Network' graph, which is the most important and most fundamentally broken. See the image above for an example of why it's broken.

The solution isn't easy, as it requires patching the culture to make people give proper branch names ('patch-1' is pretty useless'), and to force maintainers to have a clear vision of what's going on in the rest of the network.

However, there are a few things they could do to make it slightly better at least! First of all, don't make me tilt my head like I'm eating a taco just to read the branch names! Secondly, make the commit messages much more accessible so I pixel hunting for a tool tip to see what's in these branches. That should be a step in the right direction.

/End rant!

I originally intended to write a post to compliment the discussion of Sherry Turkle's new book (which can be boiled down to a single oversimplification: Technology is making us more isolated), but my outline quite quickly ballooned up so much that the post would have been a bit much to swallow. (I may still write it as a series of posts.)

The critical heart of the essay, however, would be something that many writers, critics and academics seem to forget quite often, and that's this: arguments by analogy are fallacies. That's what I'd like to expand upon here.

Going Backwards

This cropped up in a conversion I had the other day about the same subject of the pervasiveness of distracting technology. In these conversations, I typically play the role of technology-detractor, arguing the case that better technology means less of it, rather than simply more technology is good.

I remarked that it was a shame how these days idle people can mostly be found using computers (browsing Facebook on a smartphone, watching videos on a laptop, etc). At this point, the techno-believer said, "but it's not any different than how it was before! It's the same as reading a novel or watching television!"

But no, it isn't! They are fundamentally different things entirely. Ubiquitous, general purpose, networked-connected computation and communication is radically different than any previous technology in the history of mankind. It enables users to consume much, much more information (typically low quality, anti-rational information) by many, many orders of magnitude, from near-infinite different sources, and at the user's will. To say that it is like reading a book or watching television is an argument by analogy, and it is a fallacy. If it were the same, would we even be having the conversation at all?

Just because an analogy can be made, in this case because both things require eyeballs and attention, it doesn't mean that they're actually the same, or even similar. To be reasonable, an analogy requires an independent explanation for what is analogous to what and why, and the analogy that books and television are like ubiquitous general computation very quickly breaks down at this point. (Ubiquitous computation is creating a vastly different culture, in terms of identity, privacy, honesty, communication and capability than anything we have ever seen before, and it is worth seriously considering and criticizing the social and individual implications of these changes so that we may attempt to steer future iterations of technology in socially-positive ways. We aren't just distracted; we are different.)

Take it Home

Good analogies are helpful for illustrating concepts. However, they are useless as the basis for arguments. Next time you're making a persuasive argument, do a quick check to make sure that you're not making an argument by analogy.

tl;dr: While seeking open source audio software, I found a project which asks for a small donation before you can download the application binaries. I interviewed the leader of the project and found that he is able to support a family of five through this donation system. Awesome!

Ardour!

Lately, I've been recording music in my spare time. Since I try to use as much Free and Open Source software as possible, I found the free digital audio workstation Ardour. When I went to download the software, I was asked for a donation before I could download it. Intriguing!

The appeal was a familiar one to anybody who uses Wikipedia - a picture of the project leader and a short message explaining the costs of the project and how your support matters. The difference is that Ardour has a monthly goal, and unless that goal looks likely to be reached, the project doesn't provide free binary downloads of their software. You can still download the source code and compile it yourself, but I imagine this is too complicated for the average end user.

I interviewed the project leader, Paul Davis, about this business model. You can find out more about Paul on the Ardour credits page, and you can download and support Ardour here.

Interview

This is the appeal message.

When did you start this donation model for Ardour and why?

When I originally started working on Ardour, I was relatively financially independent. This changed as my personal circumstances changed, and by 2008 I was reliant on the support I was receiving from a few companies in the audio technology world. In early 2009 this support had all come to an end, and I could either give up working on Ardour and find a "regular" job, or figure out some way to make a living from Ardour itself. I had been accepting donations for several years, and had added subscriptions a year or so earlier.

The big change was the so-called pay tunnel which was inspired partly by Radiohead's handling of their album In Rainbows in 2007. I didn't want to try to force people to pay for Ardour, but I wanted to "encourage" them as much as I could.

Radiohead's Pay What You Want Album, In Rainbows.

How much revenue does it generate? Is this enough for you to work on Ardour full time?

The target is $4500 per month. Occasionally it makes or slightly exceeds that target. Often it falls short. I work on Ardour full time based on this income, though the last couple of years have seen me do some relatively short term consulting that has supplemented my income by about 10%. My real goal is to grow the income enough to pay some of the other developers who work on Ardour with incredible dedication, and no payment at all. My family lives without health insurance or any clear retirement plans, but we can also live cheaply thanks to my participation in helping start Amazon. Having complete control over my work schedule and life is worth something - I'm not sure how much. If someone offered me $200k/year to work on something that I really wanted to do, I would undoubtedly say yes and give up that freedom. If they offered me a generic programming job paying as much as I earn at present, I'd say no. For the more realistic scenarios somewhere between these two its a difficult judgement call.

On the one hand, I am extraordinarily lucky and fortunate to work as I do on a project that love. On the other, living the US with 3 children who still need our support and doing so on a bit more than the median household income is not always a comfortable experience. In general, I prefer freedom and loving my work over comfort though, and try to be optimistic that eventually revenue from Ardour will improve or a couple of other projects that I have some involvement in may do well.

Ardour has a pretty sweet logo.

What feedback have you received about the program?

Most of the complaints are of one of two varieties. The first are people who don't realize that source code for Ardour is always available and that anyone can get Ardour at any time without paying anything for it if they are willing to deal with svn and building the software. The second are people who for one reason or another cannot use PayPal or a credit card.

As usual, one doesn't hear much positive feedback about a system like this. There are several people who try to provide ideas about improving revenue flow - unfortunately most of them do so without any awareness of the actual numbers or what has been tried in the past.

As an open source project, do you worry about the missed opportunities from being redistributed elsewhere, such as in distros and on other websites?

The fact that most Linux users of Ardour get the program from their distributions without a doubt takes away some potential revenue and tends to disconnect people from the fact that Ardour is an ongoing, live software project with its own forums, support channels and developers. It also means that we have to deal with packaging mistakes and distro-dependent problems when those users eventually do find ardour.org. These are problems, but for now they are manageable.

Our biggest issue really is that the majority of Linux users are using Ubuntu and for an apparently large number of them, this distribution (like many others) is badly setup for the kind of requirements that Ardour users have. The fact that JACK and Ardour don't work "out of the box" on a given distro is a huge stumbling block for many actual and potential Ardour users.

Ardour comes packaged with Ubuntu Studio.

How do you plan to improve the donation model and Ardour in the next year?

No real plans at this point. I'd prefer to focus at some point on a subscription drive to get more people to commit to 12 months of helping support the project financially. A steady stream of releases sounds like marketing BS, but my experience is that it too drives revenue. I'm not happy about that, but it seems to be a fact of life.

Do you have any advice for other open source projects looking to adopt this model?

A "conversion rate" (i.e. the fraction of people who download the program and pay for it, versus those who choose not to pay) of more than 3% should be considered successful. Attempts to find out why people don't pay result in statistics like this:

Reasons for paying nothing:

• Third world: 1419
• AAAA Poor: 5434
• Want a free demo: 22789
• Ardour wants to be free: 5075
• No PayPal/CC: 10938
• Too lazy to even say: 21721
• Other: 8788

Note that "Too lazy to even say" is the default setting on the page that asks this. Most of the "Other" category are actually one of the previous 6 reasons, but people feel the need to say things like "I can't afford to pay" or "Fuck you Paul".

Finally, I will note that open source projects seem to me to divide into 3 broad categories. One I would term "infrastructure" and includes things like the Linux kernel, Firefox, Apache, OpenOffice and so forth. These projects produce tools are used by millions of users, among them people with a financial interest in seeing them supported, developed and so forth, and so they manage to have significant developer presence and momentum.

A second category are what I would term "small app" projects - soundjuicer is one of my favorite examples. These are projects that can be meaningfully completed by one person, have defined goals that can actually be reached, and low maintainance requirements. Such projects don't need financial support in order to happen (though I'm sure their authors wouldn't mind), and there are typically many different attempts to provide given functionality.

The final category is the one I would place Ardour in - large, complex niche projects that cannot possibly be developed by single individuals, but have a limited user base without clear financial reasons to support the project. Programs like the GIMP, various video editors, and other media tools all fit in this category. Finding ways to ensure that these programs move forward at a rate that makes them viable for potential users is always going to be a challenge.

Conclusion

Thanks again to Paul Davis, leader of the Ardour project for talking to me about this!

What do you think? Do you think other Open Source projects should adopt this model of business? Leave your comments below!

A Thirty-Minute Blog Post!

A few weeks ago we got an email from somebody who wanted to post a job on Gun.io, but it wasn't working and they couldn't see why. There was no record in our database, so we didn't know what was going wrong.

I whipped up a function to notify us of all the (non-sensitive) information in a form whenever where there was a problem.

At this point, error emails began trickling quite regularly and the problem became apparent quickly.

Diagnosis

Damn you!

A single form field! That was what was causing all those problems. Over 2 out of 3 attempts to use the form caused this problem. Woah.

The field required a integer value (things like "5000", "200", etc.) but people were people were entering values like "Around 4000," "$50/hr," etc., which broke the form. The field would let them know that this was causing a problem after they submitted it, but it wouldn't tell them how to fix it, and most people didn't even notice the error message anyway. Bummer.

The stop-gap solution has been to simply remove all text from the field, and that's worked pretty well for now. We're currently giving the site a major overhaul, so the next version will be able to accept text and intelligently pick out the actual estimate.

Lesson

The real lesson here is have your applications tell you how they're breaking, because you can't rely on your users to! They'll probably just see it break, lose all confidence in you and move on.

It's a no-brainer, really, but I guess we had to learn it the hard way. And don't just log the error and file it away, either, make sure it pops out at you and forces you to address it!

Have you ever caught any dumb errors in your forms like this? Leave your horror stories below!

"Weird dancing in all-night computer-banking lobbies. Unauthorized pyrotechnic displays. Land-art, earth-works as bizarre alien artifacts strewn in State Parks. Burglarize houses but instead of stealing, leave Poetic-Terrorist objects. Kidnap someone & make them happy. Pick someone at random & convince them they're the heir to an enormous, useless & amazing fortune - say 5000 square miles of Antarctica, or an aging circus elephant, or an orphanage in Bombay, or a collection of alchemical manuscripts. Later they will come to realize that for a few moments they believed in something extraordinary, & will perhaps be driven as a result to seek out some more intense mode of existence." - Hakim Bey, Poetic Terrorism.

Note: I've been challenged to write a blog post about Temporary Autonomous Zones, which is one of my favorite books. I have quite a lot to say about the book, but I'll try to keep this post short. You should read the book. You'll like it. Also, I studied this AI stuff while I was in college but I haven't used it in a while now. It's possible I'm going to be completely off the mark about somethings, please forgive me.

T.A.Z.

Chaos is good. It is useful in artificial intelligence for solving optimization problems, and it is similarly useful in society for improving overall quality of life and general well-being. We should try to embrace intelligent chaos in our lives as much as possible, even if it means short-term discomfort, as it is the only path to the greener pastures on the other side of the mountain.

Climbing the Hill

Many hard computer-science problems are global optimization problems. These problems appear in all sorts of disciplines, from physics to chemistry to biology to engineering, and so on and so on. It's a very deep field - there are whole journals which deal with these kinds of problems.

We're at 5. We want to be at 24. Getting there might suck.

In these types of problems, there is a huge space of possible solutions, but only one is the best. There are many, many ways to solve these kinds of problems, but the best ones (in situations where simply trying all possible solutions is infeasible) are the ones which use an element of randomness to break out of local minima when traversing the problem space.

The same approach must be taken in the way we develop our society.

Change is (Probably) Good

When modeled mathematically, society is no different than other other global optimization problem. There are many metrics by which we can measure and model our society mathematically; Gross domestic product, median income, rate of incarceration, etc, and the purpose of our society, at least in theory, is to optimize those metrics.

To do this properly, we need disorder. An ordered, stagnant society will never properly optimize for any metric we can lay out (except in the extremely unlikely situation that we are already optimized, which I don't believe we are, or that if we were that we could remain in it for long, as there will always be new variables as time goes on).

This makes people uncomfortable, as the period of disorder will likely be one in which conditions are worse in the meantime. However, it is necessary on the path towards something better.

The Slam

Let's consider the rate of incarceration. The United States currently has a disturbingly high incarceration rate. Let's imagine that as a way of solving this, a random variable is introduced in trials and that up to 50% of new non-violent convicts are contingently pardoned before their incarceration and randomly remixed into society. The immediate effect may be seem to be negative, as there would be 50% more criminals on the street. However, the long-term effect may be that these pardoned convicts are able to sucessfully reintegrate into society, get jobs, raise families, pay taxes, etcetera.

This is a cartoonish example, of course, but it's not too far off from how society actually does progress. New legislation, activist judges, and shifting social norms and expectations are all somewhat analogous to the explicit randomness in our thought experiment.

I simply suggest that we embrace disorder as a necessary rite of passage for our society, and that we should all try to intelligently introduce chaos into society for the explicit purpose of making things better in the long term. Hakim Bey proposes Art-as-Crime/Crime-as-Art as a method for doing this in the minds of the victims/art-consumers, and the mischievous little boy in me absolutely loves this, but I believe that there is just as much opportunity for chaos in law, politics, business and technology as there is in Poetic Terrorism. The trick is to be dynamic, to fail quickly and cleanly, to embrace and learn from mistakes, and to stick through the hard times when it's reasonable to think that things will be better on the other side.

I think that we should be encouraging intelligent chaos not only because it is the only way to optimize our society, but because the alternative is ghastly.

Stagnation is Horrible

"The Triumph of Christianity"

It's my belief that human behavior tends towards chaos. We make mistakes, we break things, we make art, we misunderstand each other, we rely on faulty sensors, we take drugs, and so on. All of these things inadvertently contribute to a dynamic society which moves towards better minima (although not necessarily the global minima).

The converse of this is a static society, a society in which those things don't lead to change. This is more nefarious that it sounds as it requires active suppression of novelty and randomness.

The best example of this is the Dark Ages, the period of human history between the fall of the Roman Empire, a massive force of global chaos, and the Italian Renaissance, a fountain of intellectual chaos which gave rise to modern society as we now know it.

During the Middle Ages, pretty much nothing happened. Most people lived short, miserable ideas under monarchs and church leaders. These rulers did so brutally, and anybody who questioned the social or religious structure was tortured and executed. The prevailing ideas are anti-rational ones, ideas which exist by suppressing other ideas, for instance belief in witchcraft.

A modern static society wouldn't be too dissimilar, and this is exactly how many iconic dystopian novels like Brave New World and 1984 have depicted it. If we are not mindful, we may end up in a trough we really don't want to be in.

Static Information Technology

One of the reasons I like TAZ so much is because of it's criticisms of technology, cyberutopianism in particular. Internet usage in the West seems to be trending towards a static system rather than a dynamic one, and that makes me very worried. Perhaps I'm being pessimistic, but it seems to me like the most popular and pervasive web technologies, recommendation engines, social aggregation, "personal search", etc., are the ones which suppress chaos in favor of convenience and the satisfaction of confirmation bias.

I would like to encourage to technologists to be mindful of intelligent chaos when creating new technologies and services. Short term convenience at the cost of disorder, novelty and experimentation may only end up being net-harmful to society

Real technologies are the ones which climb hills.

This isn't the best illustration. There'll be a proper logo soon.

UPDATE: WebP2P has a new home! Check it out at WebP2P.org!

There is a new mailing list for peer to peer hackers who are interested in building the next generation of P2P technology!

To join it, send an email to:

and you'll be subscribed! Please introduce yourself to the list when you sign up! You can read the archives here.

Fun Stuff

We'll be discussing, and more importantly building, new open source peer to peer technologies on the web using WebRTC, ROAP (RTCWeb Offer/Answer Protocol), JSEP (JavaScript Session Initiation Protocol), and WebDHTs to create resilient and distributed web-based peer to peer services. This stuff is really cutting edge so it's very exciting to work on. Totally experimental.

Discussion topics will include, but not be limited to, censorship-resistance, public and private P2P filesharing, E2E encrypted P2P communication, mobile peer to peer networks, friend-to-friend networks, Unhosted applications and much more!

There are already a ton of great hackers on the list, but newcomers are more than welcome!

There's a small wiki, and I'll be making a real website to house all the docs, communication, projects and code soon.

See you there!

I like to consider myself a very productive person. I do a lot of writing, I make a good living running my own business and I maintain many open source projects. And yet, by outward appearances, I don't seem to work particularly hard, but I still manage to get a lot done, and I go to bed feeling satisfied every night and every morning, I wake up eager to attack the day. I'd like to share with you how I do it.

So what's the secret? Every day, to I simply force myself to do 3 things:

• 1) Get paid.
• 2) Get fit.
• 3) Make something cool.

That's it!

With this strategy, you'll feel as smug as Richard Branson in a spacesuit.

This is a lifestyle I've been trying to live for a few years now, but I hadn't formalized it until after a conversation I had with my friend, the wonderful hacker extraordinaire Ben Gletizman, a super-productive person who operates under the same system. I ask all the best workers I know how they manage to do it, and his technique resonated particularly well with me.

Let me expand upon each of the points.

1: Get paid.

This one is fairly self-explanatory. Every week day, I make myself do something that pays my rent. This means talking to clients, writing code, managing contractors, etc. For you, this may mean something similar, or just going to work.

However, money is not the primary drive in my life. It's simply something that I require to do the other things that I like, like having a roof over my head and eating food. I try to optimize for time, which I consider to be vastly more valuable than money. I simply aim to earn enough to pay my bills and to have enough to save for when I want to go on travel adventures. (My current plan is to see the whole 'Axis of Evil.' Been to North Korea - eying Iran next.)

Money is nice - it can be exchanged for goods and services. I don't really need to tell you any more about this. Let's move on.

There is a professional bodybuilder who has the exact same name as me.

2: Get Fit

For those of us who live in front of computers, it's very easy to let our bodies decay. We sit for many hours in the same position, eating greasy food and pounding sugary drinks. Not good! Programmers are typically not fit people, and this is a stereotype I think we should really be fighting against. Not only just so we look better, or because it's healthier, but because a fit hacker is a good hacker!

When you exercise routinely, your mind benefits from it as well! I think it boils down to a matter of confidence. When you're confident with your body, that confidence spills over onto your problem-solving ability. You're more likely to think "Hell yeah, I can do that." And, bonus, you'll have the energy to actually do it.

A gym membership is a must, as simply paying for one is actually a good motivation to go and use it. I try lift weights 3 times a week and do something aerobic (skateboarding or jogging) on the days in between. Whatever you do is up to you, but I'd strongly suggest strength-training, either with weights or your own body-weight as part of a cross-fit program. Take it with a grain of salt, but I particularly enjoyed The Four Hour Body by Tim Ferris (full disclosure, I'm a total Tim Ferris fanboy). The main take-away is simple this: combine regular strength training with a high-protein, low-carb diet and you'll be firing on all cylinders in less than two weeks.

This is what programming something awesome feels like.

3: Make something cool.

This is the fun bit! Every day, work on something that you want to see exist. This might mean a song, an experiment, an open-source project, a side-business, a game, a novel, an invention, or anything else that you think is worth your precious time. This should be something which is socially positive, something that will make the world just a little bit better by existing. You don't have save all the starving children or cure cancer, even if you can make one person smile or solve a small problem for yourself or somebody else, you're doing the right thing.

Just don't waste your time making useless shovelware! You're a hacker, and real hackers are artists. Act like one. Put some thought into what you do and build something that you can be proud of.

Don't be a one of those guys who says "I want to.. ." The world has enough of those already. Be a guy who says "I made.. ." The world needs far more of those.

Feelin' Good, Feelin' Great, How Are You?

That's really all there is to it! I can't guarantee it'll work for you, but I know damn well that it works for me.

Just try it! Tackle these three things every day (and I mean every day, I try to do this on weekends, too), for two weeks, and you'll be richer, fitter, prouder and happier. Seriously!

Try it out and let me know how it goes! I'd love love love to hear anybody who has success with this system.

What's your secret to success? Leave them in the comments below!

Facebook and Zynga Stock Prices, Side by Side. From Google Finance.

This is the stock prices of Facebook and Zynga, side by side. Clearly, there is a strong relationship here, and I don't think Zynga is the one holding the reigns.

Think of it as a reminder about what can happen if you tie your business too closely to somebody else's platform or API.

I'd like to see how these two compared before the Facebook IPO - was Zynga still tied to them on SecondMarket, or were they more decoupled than they are now? If anybody has access to that kind of data, please get in touch!

Rodney Mullen is the greatest skateboarder of all time. He invented damn near every trick in the book, and all skateboarders owe him something. He's even responsible for the design and shapes of modern decks and trucks. His contributions to the sport have enabled numerous generations of growth and innovation, and in this talk he likens the culture of skateboarding to the culture of Free and Open Source software.

I don't have much more to add other, I just wanted to highlight this video here because I think that it's completely awesome. (If you hadn't figured out yet, I myself fancy myself a bit of a skateboarder, so I really, really liked this talk.)

Check it out!

Tiny blog post!

Do you want to find the most recently logged in users in your Django application? Cool, no problem. You'll be filtering and sorting your most active users in no time.

Here's how you do it:

Then, to display the result,

And that's it! Handy little trick if you're trying to engage your active users with each other.

Enjoy!