Tee-Ball
blog.cjeller.site
blog.cjeller.site
This is why we get paid enough that we can retire in a mere decade.
> Do you ship a single binary or do you copy a boat load of language files over?
Rust or Go? Single binary. But you should ship containers regardless of language and just not care.
> Do you use your languages special packaging tool or do you use something like rpm?
DO NOT USE THE HOST PACKAGE MANAGER. Version and lock your dependencies. Vendor them. Don't get tangled up in the OS. That'll double the trouble. Then build and ship containers. Don't ever run bare metal unless you want to be tied to it as a design contract.
> How do you handle dependency conflicts?
A monorepo helps tremendously. You seldom deal with dependency issues, and every bump is handled by one person once in most cases. But people tend to hate these for some reason. I happen to think they work even for small orgs.
> Where on the box do you store your files?
Firstly, use containers. But as for where to place them, the homedir or /data is perfect. But it doesn't really matter that much if you make a single choice and stick with it across your apps.
> What should the default config look like?
Like development.
> How do I populate my prod config?
prod = development, but overrides for the prod topology. Perhaps this varies wildly for apps that use many sharded databases. This is the nature of our work.
> What about app install scripts?
Docker / K8S. Don't bake them into the runtime lifecycle if possible.
> Do I use puppet or ansible to manage packages and configs?
Version control your config. You won't have secrets in them.
> How do I know if my application stops running?
Metrics + PagerDuty
> What if it hangs?
Metrics + PagerDuty
> Should I put my app behind nginx or apache?
Rust or Go won't need this. Swift might work too. Ruby and Python, maybe. Sounds like a lot of work. You can launch it as a sidecar or DaemonSet, perhaps. I shy away from scripting languages that need to be load balanced. You're stretching a solution beyond its limits, and there are modern languages and platforms that won't need this.
> How do I configure my firewall?
Envoy, Calico. Default policies to DENY all except what you carve out.
> What about backups?
For your databases, file uploads, and last few weeks of production builds.
> Is your SSL cert up to date?
Monitoring and paging helps here too.
They aren't the trendy new thing, but they're more than adequate for most beginner projects. They work quite well even up to pretty reasonable scale for SPA frontend-focused apps, and "deployment" consists of `scp` or a friendly gui client.
The unifying concept was they were simple machines, with a basic feature set. Came well documented and when you turned them on they dumped you into a BASIC shell.
Everyone typed in something to the effect:
10 print "Hello"
20 goto 10
Run
No compilers, editors, linkers, deployment, security rights. Nothing. Just turn it on and type simple stuff. Screw up the machine -- just power on, power off. Bam - you get to the default stable state to try again. Get into the complexity when you are ready and willing to deal with it. Brilliant.
Kids today don't have that.
Maybe no kids leagues use it, but there are sticky balls and gloves using velcro that are used in informal play, usually in indoor gyms and/or just for little kids playing in the backyard.
MS Access (1992) and Visual Basic (1991) could be pitched as a Tee-stand for software. Why didn't they take over? What happened in the 90s? The world wide web. Microsoft was over here playing desktop tee-ball while web technologies ate their lunch.
It takes time to smooth out a software stack, but it keeps getting disrupted every ten years.
However in their niches MS Access and Excel (VB not anymore but that was because Microsoft forcefully killed it, not because the developers that used it decided by themselves to move away from it) are still dominant (in fact so dominant that they overflow from these "niches" - see how many stories of Excel VBA doing things that weren't "supposed" to be done in Excel).
It lets you do a lot of simple things easily and quickly, and provides enough hand-holding for a beginner.
No such thing around the frontend, though. No form designer. There are several things that generate crude but working HTML from simple descriptions, though.
Very much like a VB program, such an app is hard to make look polished, but it's not the point.
The other related sports (including baseball's origin sport 'rounders') all require barehanded fielding (AFAIK), with the occasional exception on a specialist backstop (e.g. the wicket keeper in cricket)
Pitching and hitting was the first time I ever opened an IDE. Now I know my way around, but the learning curve on firing up VS or Eclipse the first time (can't remember which it was): holy crap.