I wanted to alert everyone to a service that fits well with Codea. Webscript.io is a website that hosts LUA scripts that you can invoke from the web. There is a free version that lets you try things out for seven days.
They allow you to store data, send email, invoke web hooks (like the ones that can be exposed from Github). You can even setup scripts to run as cron jobs.
This seems like a much simpler way to save data, offload processing to a server, and generally connect Codea apps to the wider world of the internet. To get the most use out of the site, you will need a json parser because the site can send/return Lua tables as json. But even if you just use simple strings, you can still do a lot.
I have no affiliation with webscript.io, I just think it is a great fit for any Codea scenario that involves http.request. You can check it out at http://www.webscript.io.
Is the perfect match for a simple “highscore” leaderboard from another thread. Good find - I wish they had more info about the software they’re using to implement it.
The main guy at webscript.io is Steve Marx. He is a very open guy. I met him at a conference where he spoke and he loves talking about the technologies he uses. He encourages people to email him at smarx@smarx.com. Just send him an email with any questions you have.
Hello, one of Webscript’s founders here. Happy to answer any questions. As to the technology stack, it’s mostly Python embedding Lua (nginx, gunicorn, Flask, Lua 5.1). We use Redis for persistence.
Hey @smarx, thanks for the info! I found the notes on the y-combinator news blog. I really like the site - lots of places it could be damn handy. It was pretty clear from the lua code you were using a rack-ish interface of some sort, was curious which one and how you had integrated it, as I had briefly attempted the same a few months back, in an attempt to do lua cgi for something I was working on (and, in the end, defaulting back to perl because I know it so much better).
Don’t give too much thought to the “not really unlimited” idiots. I used to run an ISP - there’s no really good way to say “No predefined limits, but if you start causing operational issues, you’re history” - and that’s really what the case is. No provider has ever or will ever say “Gosh, this guy is taking my servers down, but I said ‘unlimited’ - I guess he can just ruin things for everyone”.
I’ve been thinking about this (no, really!) for the last couple of days; I think I have a small issue with the usage model of webscript.io, but of course no real solution.
The whole “it dies in 7 days” thing makes is unusable for most of my admittedly really casual uses. For example - we were talking about a high score server, which you’ve basically implemented in your examples. It’s cool - except my choices are $5 a month (which is low enough to not be a cost barrier, but high enough [not being zero] to be a pain and impediment to implementing), or have it die in 7 days, and neither is great for something I expect to be hit maybe a hundred times in a 24 hour period. Am I willing to spend $60 to keep it up for a year? Nope. Am I willing to spend $2000 of my own free time to set it up somewhere hosted for free (google apps-scripts, for example), despite it being literally orders of magnitude harder to do? Yup. Weird, huh? (not that weird - I’m salaried, so I can’t easily convert free time to more cash).
Alternatives I can think of (and they may simply not work, just throwing things out there) might be usage-based - the first, say, 5000 impressions are free, and after that it’s a buck for 10k or something. So - a truly low traffic thing might run for months or years, and if someone suddenly gets popular they can pay for it, with enough money so that the existing usage limits you have for “unlimited” are not an issue. I’ll be the first to admit - metered usage comes with it’s own shortcomings - but they may be less of a barrier to adoption than the current plan (which encourages experimenting, but to be blunt part of my reasoning behind wondering how the stack was implemented was me thinking “if I came to depend on this - what would I need to do to set up my own local version?”)
Please don’t take this as anything but (hopefully) constructive criticism - payment model aside, I find the webscript.io model delightful, and I’d love to use the hell out of it. I just need to figure out how.
It sounds like the pricing is doing exactly what we want, which is to charge people $5/month. The 7-day expiration is there so people can play around with this as much as they want, but yes, the goal is that if people need to use it on a consistent basis, they’ll have to pay.
I don’t disagree with you about how a different freemium model could encourage more use, but I doubt it would result in more paid use, and we do have to make sure this is a sustainable business for us.
I’ll keep my fingers crossed that that model works for you - I’d like to see this sort of thing succeed. I’d love to see a blog post or such in a few months with how you’re doing.
@smarx, I agree with @Bortels. I too do respect what you are trying to build and hope it succeeeds.
that said, while I understand that your pricing model is to charge after a few days, in my case, I set up an account in preparation of a test, determined that I didn’t have the time to do it, and had the account expire before I was even ready to play with it.
While I DO have $60.00 a year to spend, I won’t on something that I can’t really play with for more than a few hours once a week. I think that your 7-day sandbox is too short. Maybe 30 days?
Personally, I believe that your business model is too aggressive to attract the right people you want - people with extra cash or small businesses that can’t afford developers.
Get a few good services out there, or set up a model where people can donate their service code in exchange for extensions of the timeout, and go after businesses that can easily afford more than $5/mo.
The 7-day expiration is there so people can play around with this as much as they want, but yes, the goal is that if people need to use it on a consistent basis, they’ll have to pay.