talkingquickly

That's basically what we do with https://www.makeitwithcode.com, we take people through building things and teach them theory as they go along. Then we go through deploying something to Heroku etc as part of subsequent lessons, so by the end they've got a mixture of the theoretical stuff as well as the more practical "how do I make this be on the internet".

I think there's a few others which also follow the approach of each lesson essentially culminating in a new portfolio piece.

Thanks for sharing that, solves a problem which bugs me on a daily basis!

I see your point but I think it's still fair comment when the parent isn't suggesting a better approach, they're just saying "don't use this one".

This has been driving me crazy for months, I had one version of the old buggy Adobe Air app running and one of the new Native app. Somehow just creating a copy of the new native app just never occurred to me. You just made my day substantially better.

I used to work in business modelling and a part of that was creating and auditing spreadsheets so complex they fell into the "this should never be a spreadsheet" category. There are several proprietary excel addons which are designed to do exactly this. Unhelpfully I can't remember the name of the ones I used but if you Google "Excel Auditing Tools" you get quite a few.

Have been consistently impressed with the way these guys have iterated on the developer experience as well. The first version of the SDK was completely usable although admittedly limited in what you could do with it.

We worked with them for a while before the official release of the V2 SDK to put together the first automatic swimming lap tracker for Pebble [1] and they were incredibly responsive and helpful when we ran into issues with it. They'd clearly put a lot of thought based on the V1 feedback into how to make it a better platform for developers to work with.

I think it's underestimated just how much work from such a small team must have gone into getting a the developer experience as good as it is, only a year after launch.

[1]http://www.helloswimio.com/

I've got a fair bit running on both DO and Linode. Fairly happy with both but still for anything CPU bound (to me the speed part of that), Linode is substantially outperforming DO still and both leave Rackspace Cloud in the dust.

So for me, on average a $20 Linode has less RAM but performs better for CPU bound tasks than a $20 DO Droplet.

I think the use case for this is the reading we do because we need to consume the information as quickly as possible rather than the reading we're doing for pleasure. Not that the two are mutually exclusive by any means.

I love reading but, particularly online, I'll often need to read something which contains a lot of information I need but isn't written in a style I particularly enjoy reading. For these, I can see the benefit of tools like this.

And in a way which so many people relate to. As soon as I saw "xkcd" I knew which one was going to be linked to...

Very cool. The thing I really like about the early ones was that as an experimental class, you could get boats that were incredibly different to one another but still technically "moths". Much like early formula racing, there really was the latitude to tune the boat as well as your technique.

Not that I ever did with this one, it was about thirty years old and took all of my effort just to learn how to keep it upright. You also couldn't moor it anywhere because it would fall over if not moving which meant leaving it on its side at the jetti...

I had a very early moth (before they put foils on them) which was still statically unstable. Inland waters with unpredictable winds meant you could go from strong wind to nothing almost instantly and with very little indication it was going to happen.

I remember spending a lot of time in the water...

Didn't know it was displayed in settings, really useful, thanks. My suggestion would be that there should be some sort of notice on the Droplet list page if you're at your limit.

I suggest this because I've been using Digital Ocean for quite a while (several different accounts for different projects/ clients) and have never needed to look at that page.

The need for limits and additional verification makes complete sense, but it would be useful for it to be highlighted in advance (e.g. in an intro email or banner) so you can deal with it in advance of it becoming a problem.

I also use them and in general like them but would add to this list;

* Can't add backups to an already provisioned node

* Undocumented "droplet limits" e.g. one day you'll click "Add Droplet" and it will say "You've reached your droplet limit, please contact support". They'll generally raise it after some basic security verification but it's a nasty shock since you don't find out about it until you need to provision a new Droplet, especially if you're in a hurry.

that's an awesome story. Currently compiling a blog post series of interviews with people who have interesting stories about how they learned to code, would be great to interview you! If you're interested my emails ben at talkingquickly co uk

My impression was they were claiming to have passport scans and a 20GB DB dump, e.g. that they were separate?

Would be really interested to chat to you about Codebox + Docker, email is ben at talkingquickly co uk or talkingquickly on twitter

To put "often" in context, I raised a Github issue on it today which was resolved within a few hours, it's improving incredibly quickly (and it's already awesome).

Exactly, how many developers can honestly say they've never copy pasted commands into the terminal without being 100% sure what they were doing?

I think it's less that you can't and more that most people won't. The reason I know I can provision a new server for app x without hassle is because the chef setup to do it gets used regularly, it's part of the workflow of developing the app. If it breaks I know it's broken because next time me or someone in the team spins up a staging enviro, it won't work.

If you're using Heroku sure you could write that cookbook but in 90% of cases it's going to end up being unmaintained because it's there as a contingency that no-one uses in their everyday workflow. What's more for it to have real value it needs to be tested regularly to make sure it actually functions as expected.

So it's definitely possible to avoid the dependency as long as you don't mind adding a big chunk of devops work. At that point you've got to ask why are you paying the premium for Heroku if you're maintaining the devops expertise and codebase to deploy to a VPS alongside?

They don't actively lock you in which is great but you will almost certainly end up with bits of your workflow which are extremely dependant on Heroku. IMO pure AWS has exactly the same problem if not more.

If you compare this to deploying to "choose a generic VPS" the lock in is substantial. If any of my apps fail, I'm comfortable I can provision an Ubuntu VPS from any provider with a one line chef command and then deploy to it with one more.

So although Heroku isn't locking you in through any bad practices on their part, by using them you're choosing to make your workflow very specific to them. To me and quite a few of my clients, while Heroku is awesome for getting started, there isn't enough benefit for the increased single provider dependency and costs.

Not hating on them at all, I use them quite regularly, but I can understand where people are coming from when they talk about Vendor lock in. Perhaps a more accurate description would be single vendor dependency.

For smaller apps is worth looking at Monit, really simple to setup and covers most of what needs testing if configured correctly.

Myself and some guys with a telecoms background spoke to various telcos about that ~2 years ago. Feedback was that they were already so over stretched with data usage they weren't going to embark on any projects likely to increase it until there had been a lot of network upgrades. May have changed since then though.

Was not expecting a comments from someone at GoDaddy here, appreciate the response.

Exactly, I mentioned further down that their ruby customers are probably made up of people with very little experience. So these customers are probably characterised by quite low spend and very high support costs since they're still quite new to it.

This is making the assumption that only someone who was quite new to Ruby (and development in general) would use GoDaddy for hosting.

My guess would be it's more that no experienced Ruby developer would use GoDaddy for hosting. So most people they've got using it are probably inexperienced people (on that basis if you had experience, you'd use something like Heroku) who would probably be characterised by low spend and high support costs.

OK I'll rephrase; for most people the internet isn't a thing where you view static html documents anymore. Therefore people want to use "something" to access these things (for example new software) and currently this thing is a browser.

Therefore in terms of the expectation of a majority of its users, it's not accurate to define a browser as something for looking at static html documents.

Not to say there couldn't be a different something for this - java applets, flash etc have all tried and failed to remove this from the browsers functionality to a delegated function - but at the moment there doesn't seem to be a viable alternative.

> Browsers are fine as long as you use them for what they are meant to be used

A lot of people now want to use their browser for far more than that and browser technologies are evolving accordingly. I'd suggest it's been quite a while since browsers were meant to be used for nothing more than browsing html files.

Also fascinating that despite all the talk of Bitcoin only being used by speculators, there's demand for tools which allow it to be used purely as an exchange mechanism.

Definitely interested in contributing, going to get this up on a VM tonight and try and get to grips with how it works. What's the best way to get in touch with you?

Exactly what I was looking for yesterday researching an interactive programming tutorial I was thinking of putting together. Great timing!

Not sure if it's intentional but the license (apache2) link on GitHub goes to the docs folder rather than the license text/ definition.