fooandbarify

For fear of beating a dead horse, let me put it this way: (should I be made King) I would do away with patents altogether if that didn't mean removing all incentive for innovation. For physical inventions, patents foster innovation by ensuring that the inventor will have time to bring their invention to market before a competitor. (I mean no snark at all, but I believe the previous sentence to be generally true whether you buy it or not.) For software, the market does a great job of fostering innovation and so I don't see the advantage of software patents (and that is obviously where our views differ). If a person or a corporation believe that a certain software method offers them a particular advantage, they will retain it as a trade secret regardless.

Note that software is still protected by copyright regardless of its patent status.

  app.get '/', (req,res) ->
    res.send 'Hello World'

?

I want to love MediaTemple, and I agree that their support is excellent, and I accept that terrible accidents happen, but I can never bring myself to use them in a production environment ever again. (The project I was hosting with them was in a sort of private beta, and although I had second backups of the code I had very very foolishly trusted the Snapshot backups with all my user data. Lesson learned.)

Anyway, I'm just one dissenting data point in a giant sea of happy customers. I don't mean to dissuade anyone from using MT--just please don't be any less paranoid about their service than the rest.

I do generally prefer very precise specs for engineering projects, of course.

The way I did it (I was taught this by a friend who does it more regularly) takes a bit of extra micromanagement for the first job, but it will pay off for subsequent jobs because you should be able to re-hire the same people. Post a job, wait until you have about 15 offers and then pick the top 5 (filter them on their English and whether or not they specifically respond to your post). To those 5, assign different pieces of your total job as a test job (less than 3 hours of work each, and limited by the hours/week setting). The most important part of Odesk hiring is communication - use middle school English and make it clear that they are to ask questions immediately if anything is unclear. Be friendly and be sure they know that you are happy to help.

Of the five people you hire for a test job, at least one of them will probably not even start it. Another couple might start but not finish. You will almost certainly have a few that do decent work, though, and even if they represent different skill levels you can leverage them across different projects. (I have a contractor from India who inserts content really nicely, but she can't edit themes very well. I hire her regularly for page content, but I pay her less than my contractor in Kenya who takes care of editing themes for me.)

Of course, this functionality is absolutely trivial for any web startup to set up, but I imagine traditional small businesses would find this page super useful. In fact, I'm going to recommend it to a few that I know, because I'm curious what their reaction will be. (I suspect that I will have to explain what a QR code is first, though.)

EDIT: Did not realize that this site was built by the submitter. arroyo, really slick design. Nice simple idea. Like I said, maybe too simple for tech folks but I suspect you will find a lot of non-tech interest here if you're able to clearly convey how a QR code helps them. The business owners I have in mind would need more convincing than what you have on your site, and you'd be fighting the back button the whole time.

I think the meat of an interesting idea comes from exposure to the widest possible variety of environments, and the intersection between them. An obvious pattern for programmers which fits this criteria is an app idea arising from the intersection of knowledge about software and knowledge about something entirely unrelated, eg. patio11's Bingo Card Creator. (Yes I know, "interesting" is subjective.)

The ideal "idea generating formula" for me has therefore become seeking exposure to interesting (no, actually just different) objects/places/people/ideas/pastimes/jobs/[insert noun here] and then waiting for my brain to make connections out of it while it should be focused on a lecture or sleeping.

EDIT: Given the slices, is it possible to order them properly entirely in the frequency domain?

I recently made a really simple Backbone.js extension (https://github.com/napoleond/localModel) that reduces load times and the number of HTTP requests an app needs to make by caching data in localStorage. It was built as part of a closed-source project, so I can't use that as an example and I haven't had time to port the standard Backbone example (http://documentcloud.github.com/backbone/examples/todos/inde...) to a version which makes use of my project. What we need is the server half of the example app. It will only take a few hours to build, but I am unlikely to get to it for at least a week so if you do it first I will accept your pull request and thank you at the top of the README. (The client side of the example app is exactly the same as the standard example, but with the modified Backbone.sync pulled out.)

It won't make you famous, but it would be a very easy and useful contribution to an open source project that you could use on a resume or something.

With regard to the rest of your comment (7 unrelated technologies, deep layers of markup, huge numbers of LOC, etc) I agree, but as you said - how could it be fixed? The reality is that the web performs a complicated function. It would be nice to abstract the nuts and bolts behind it away cleanly, and I don't think it's unreasonable to believe that could happen in our lifetime, but it's also not unreasonable to expect that developing for a complicated platform will be complicated.

I don't mind App Engine that much though, to be honest. The price changes don't really affect me and I've always been happy with their infrastructure. The only thing that bugs me about using it is vendor lock-in.

And not every back-end dev is lucky enough to be working in their framework of choice ;) (I would actually call myself more of a front-end guy, but I do plenty of back-end work and the only time I get to use frameworks I enjoy - Django, Flask, etc - is for my side projects.)

I have tried it, and I love it (same goes for Backbone and Underscore, by the way - you are the developer who's work has impacted me the most positively in the past year) but I haven't used it for anything serious yet, and here's why: the workflow is more complicated than "make change, refresh". Until very recently, my programming time was split about equally between the three major operating systems (I have since managed to phase out Windows almost entirely) and it's way more trouble than it's worth to set each of them to autocompile changes to .coffees. I know that I could import the compiler and use script type="text/coffeescript", I know about LiveReload for Mac (even though I couldn't get it working in the few minutes I tried it) but the bottom line is that I already know how to write Javascript, and it works great. Learning a new language is the sort of thing I like doing, but wasting time futzing around with build systems is not.

Anyway, I didn't mean to rant. I could easily love CoffeeScript - I don't feel threatened by it a bit. But there are some serious barriers to adoption, and Javascript isn't nearly painful enough for me to deal with them.

EDIT: What aeden said.