HN user
Automation. I'm building a dev environment that does various bits and pieces transparently - DNS, databases, reverse proxying, backups/restores, secrets, stacking/merging/relating containers etc.
I kinda just stumbled into it as the logical way to move forward once the shell scripts I started out with became too complex, but I've fallen in love with it. I'm sure it will be my go-to language for a lot of coding tasks in the future.
Demo video (no audio): https://www.youtube.com/watch?v=B6yD3Zo3LlY
I'm forever jumping around between different stacks and I found myself really hurting for something that would streamline the process, so I made it. It's not for running production services and it's not polished, but it's very powerful.
It comes with a combined bootstrap and control script which has been tested with Ubuntu 16.0.4 and mac os. Windows and other distros will follow, but it should work on anything x86 which runs Vagrant and Virtualbox if you do some manual setup - the readme in the repo gives a kind-of-detailed/kind-of-hand-wavy explanation of how to set it up manually.
I should highlight up front that this was made as both a learning exercise and to solve problems I experienced specifically when working on isolated container ecosystems. It was built out organically so there's a lot of tidying up to be done, and I've cut corners here and there to get it out the door. There's no scaling or clustering, and you shouldn't attempt to run production services on it. You can enable an external interface in the vagrantfile to present the containers on your LAN, but you'd be wise not to expose it to the internet in its current state. I aim to move it towards something tidy and secure which exports production ready containers and stacks in the future, but for now, it is what it is.
I also haven't included a license. I wanted to ask you guys for opinions on which license I should run with. I've read loads about the various different licenses, I'd like to see some discussion on the pros and cons from people with experience before making a decision.
Anyway, with that all out of the way...
Nedoka lets you control containers, stacks, segments and groups of stacks with painfully straightforward syntax. Your container landscape is defined in yml files anywhere within a config directory tree, and specs can be wired up however you want, regardless of where they live. Any spec can be a container, a stack, both or neither, and can have children which inherit and extend its settings. Stacks/containers/partials can contain dependencies which come up when required, and can include other containers and stacks, and merge containers, stacks and partials together to create new things.
It sounds a bit wild, but it's all very straightforward in practice, the end result being that you can wire any number of arbitrarily complex builds and environments together however you want, and control any portion, portions or the entirety of it as easily as you can a single container.
Aside from letting you mash configs together to create all manner of ridiculous superstructures, there's a lot more going on. Tags anywhere in your specs will generate and/or retrieve vault/consul based secrets, create and switch users portably, trigger actions on the host or other containers, split layers, inject cache busters, pull environment variables and so forth. Specs can have onbuild, onrun, post-start, pre-backup, post-restore, host post-run, host post-destroy, and arbitrary (and extremely handy) helper scripts defined inline, and can be accompanied by file structures and/or database dumps which are injected into the resulting builds automatically at baseline.
When containers come up, .test DNS records are created on split views for traffic kicking around within the VM and over a hostonly interface. If you uncomment the external interface in the vagrantfile, containers with endpoints will be presented over a shared IP with reverse proxying where relevant. If you enable ipvlan i the settings and provide some basic network config, containers with defined service endpoints will automatically join an ipvlan bridge where they'll act as distinct endpoints on the LAN.
Specs can specify service endpoints and port forwarding. HTTP endpoints are automatically reverse proxied. HTTPS endpoints will be reverse proxied and a certificate will be created and signed by a local CA.
A basic database abstraction layer handles the creation, backup and destruction of postgres, mysql and mariadb databases and users - add a db to a spec and it will be created automatically and backed up/restored alongside the container. Databases are treated as persistent, but can be destroyed or restored on demand. Environment variables for accessing databases are injected into the containers they're defined in automatically.
Backups of containers or stacks can be taken manually and will happen automatically on the destruction of a container, restores happen similarly transparently on run, but you can baseline or restore to previous restore points whenever you want.
It covers a lot of ground, and I'm sure for some people it will break in weird and wonderful ways (you can generally just restart supervisor or the VM, but I'm sure there are plenty of bugs I haven't come across) there are also some obvious pain points such as manual renaming and repacking of backups being needed if you want to change a container's name, there is no API or web frontend yet, and it needs a lot of polish, "but other than that it's fine" :)
I'm very fond of Nedoka, not just as the creator but as an end user too. I can't wait to see what people make with it.
Written text is non-persistent too. If you're dreaming and look away and back at a sign, newspaper, whatever, the words all change.
I've used the light switch thing to trigger a number of lucid dreams too, I always assumed that your brain just doesn't bother wiring things like that up, rather than the complexity of shading being an issue.
For developers yes, I'm working on a similar platform just now - you wouldn't be developing a 3D game on these kinds of things, but containerised development environments are definitely The Sane Way To Do It, for various shades of 'it.'
That doesn't leave a lot worth upgrading... maybe just the radio module.
Camera upgrades would sell like hot cakes.
There was one death in Monkey Island. When Guybrush first talks to the pirates in the Scumm bar they ask if he has any special skills and he proudly tells them he can hold his breath for ten minutes. Much later in the game he finds himself underwater, if you let him idle he proves it.
I never found any other ways to kill him, but I certainly tried.
That's because Vin Diesel is a gamer and didn't want games starting him to be run-of-the-mill movie tie/cash-ins, so he founded Tigon and tasked them with making good ones.
Fabulously geeky dude, I like his style.
I wanted to learn some things a while back (can't remember what, I think it was laravel and angular) and set about creating a dev environment for it. Whatever I started out to learn fell by the wayside and building a shit-hot, easy to use, modular, containerised dev environment became my soul focus. I'm getting ready to open it up to the world any day now[1].
I'll post about it once I've ironed out a few more quirks. It makes life so much less unpleasant in so many ways.
[1] yeah we'll see how that goes
I would pay for an app that let me take a picture of the ground and circled anything that looked like a 4-leafed clover.
I didn't know juju existed until now, but I've been working on something kind of similar which is a lot less hassle to get up and running (vagrant up, done) although I'm just one guy who doesn't have a hell of a lot of free time so it will be intended purely for creating local dev environments at least initially (and will come with a "do not run production services on this or you will die" style warning)
It takes some steps towards resolving some of the issues in the article as well as a number of other headaches I've encountered when trying to bend docker to my will and build a development environment I can use every day for everything without having to mess around with basic plumbing.
I can post a show HN about it in the days ahead if there's any interest - it's not anywhere near where I want it to be (least of all in terms of code quality) but the amount of time I can devote to coding is about to drop from "near zero" to "really REALLY near zero" for a while, and it's very usable and handy so it might be worth just tossing it out there as-is and coming back to it at a later date.
There's the same amount of risk as with any other cash transaction, except a receipt exists which can never be lost or altered.
If you're not dealing with dodgy people, the big pain points are getting it, and keeping it safe once you have it.
PayPal, credit cards etc. all have their place, but for non-physical purchases from reputable parties I'm not sure how much you can improve on "pay money, receive thing."
It would have to be a very compelling argument to persuade me that transacting through a middle-man (who then holds all my personal information and card details and also takes a cut) is better than just handing over cash and getting what I want.
There's at least one other type you're missing: people who appreciate the utility of an electronic equivalent to cash.
I pay for things with cryptocurrencies fairly frequently. I don't want every company I buy things from having my name, address, date of birth and credit card info if they don't need it. If I'm buying goods or services that don't require physical shipping, all they need to know is what I want and that the money has changed hands. Crypto facilitates those kinds of transactions.