PREFACE

Ruby-speedrun was a ‘fun’ project. I’d heard mythically good things about ru on rai in the past,

(although I can never quite remember the sources?)
(maybe I’m conflating multiple 00s/10s bloggers with Patrick McKenzie’s posts on rapid web development in RuORai?)

at the very least that it was fast, simple, and straightforward to directly add fleshed out features to a dynamic web app.

(everything on a computer is just an app these days 😔)

Since the purpose of a web(site/app) is to serve a document, blob of code, or pile of visual experiences to the needs of a user, rapid iteration and acting on feedback from users is important! Very important! It’s best for your code to already be complete and shipped, but if that isn’t on the docket, “shipped as fast as possible” is almost acceptable. Working so slowly that you understand your code might work for waterfall-at-broderbund-in-1983, but it just isn’t a fast enough OODA loop for the far-flung future of 2007+N.

The real specifications and requirements for your project will ultimately emerge at the interface between the compiled/running/displayed piece and its audience.
For various reasons not in the scope of this blog post, it just isn’t possible for you to imagine your user’s mind with such detail & precision that you can guess exactly what they need.
Since you can’t guess what your users need, your guessed specifications/requirements will always diverge from the user’s!
It follows that (even/especially) the best-laid plans inevitably require refactors, rewrites, revisions.

GOALS

With that out of the way, RuORai is Mythically Fast.

(Sure, configuring a development environment takes time, but in post-virtualization land you can just fetch a clean dev environment that’s already set up!)

I wanted to find out what the big deal was with ‘writing’ entire ‘web-apps’ with one-liners,
try out ‘cloud-IDEs’ and pre-configured environments,
and see if I could “learn” a new framework fast enough to push a working (if boring) web app in under 24 hours.
Using Heroku as a deploy target was unabashed scope creep and somewhat irresponsible for a timed project!

CHALLENGES

Heroku. Everything that “just worked” locally in the dev environment did not “just work” on the deploy target.
Sure, pushes always made it to the deploy target, but…
Databases failed to initialize, requiring manual prodding to the remote server.
Versions of our frameworks were rejected by the remote server and had to be massaged into correctness.
Without introducing dependency conflicts. On a hello world toy project.

These are minor tasks/fixes, sure, but each minor debugging task occupied around 4x to 8x the time of any task step which just worked. Under a serious time limit, like ‘get the project done by the end of the day / week / month’, it’s easy to see how they could balloon to fill all of the available time in a project.

SUCCESSES

Forcing out a dynamic web app that correctly reads from, writes to, and deletes from a database in around 4 hours of work, 4 hours of debugging, and ~12 hours of sleeping / procrastinating felt pretty good! I want to revisit the pedagogical resources I was using and flesh out a ‘complete’ toy social-media-service.

Working on this project updated my expectations of the time-cost and complexity of plugging databases and rendering rule together from around
‘1 week per feature, around a month to a complete project’
to around
‘1 day per feature, around 1 week to a complete project’.

I’m sure that at MEGAFANG-TRUNK-OF-THE-INTERNET scale there are probably some issues with using RuORai.
Of course, the problems that come from having millions of users and hundreds of millions of hits per month are good to have.
There’s no use in theorycrafting how to scale from 100,000 users to 10,000,000 when you don’t even have 10 active users yet.