Brewr.io source code released | Hacker News Reader

Brewr.io source code released

github.com

48 pointsthebillkidy17 comments

You should probably post a license with the project (as really, you always should with any source code you post).

The closest thing you have is:

> I hope that someone else willl pick it up and eventually transform it in a startup. I however do hope that once this happens I will get to see credits towards me for the initial idea.

http://choosealicense.com/ is a good starting point, if you're unsure.

Thanks!

There was bowery.io, they even raised money, they seemingly disappeared [1].

There is also the nix-shell tool from Nix [2] which work great for python, haskell and golang (at least on Linux) but can get very hairy for node and ruby (not only Nix's fault).

I am also working on Pipez [3], which tries to solve a similar problem for frontend development.

[1] http://venturebeat.com/2014/10/21/bowery-io-wants-to-configu...

[2] http://nixos.org/

[3] http://pipez.io/blog/1-tool-hell.html

I'm a FoaF of one of the founders of bowery -- If the word of mouth is true they got bought out by Google and I assume integrated into one of their projects.

This is cool, I'm eager to try out and take some ideas.

As a New Year's resolution I tried to improve my dev environment and in January, I created a big yeoman generator for making most of my time consuming tasks trivial, like :

1. Creating a remote repo ;

2. Configuring CI ;

3. Generating project boilerplate files ;

4. etc ...

Doing this with yeoman has it's limits and seems hardly maintainable.

I didn't know this exsited.

Tools like Vagrant and Docker are great when working on a per-repository basis but I have not found a good solution to install/sync dev environments globally which sounds exactly like what brewr did.

Does anybody know of any simplish solutions to accomplish something like this?

Don't know about simple, but we're using Puppet with Vagrant.

Our Vagrant box uses the exact same setup as production, with minor local tweaks (for example, our internal tool also sets up local DNS resolution so that every app can be invoked from a .dev host name, and we also mount apps from the host machine so you can work on the code and hot-reload it). We use the same tools to deploy apps, inspect status and generally interact with the environment.

Once the developer has downloaded the box, keeping it updated is a manner of running an update command which performs the Puppet magic. The developer doesn't need to know what's going on exactly.

It's not perfect, but it's fairly pain-free, and means we have the exact same software locally as what's on the server.

At my last company we rolled our own little interface in NodeJS. Simple enojgh and worked really well!

Docker will be coming out with a solution for this pretty soon

Do you have any details about this? It sounds interesting.

https://goto.docker.com/try-universal-control-plane.html

This is a cool idea. Who is working on it? Email me at mdl0394 at gmail.com

How does it compare to defining projects in boxen (or puppet)?

This project was meant for upper management, as in a company decides on a project and the developers can instantly get to work. See of it as local development environment. It is also easy to be deleted and removed from the system so that a system stays as clean as possible.

The main vision was that a developer should be set up within minutes and be able to receive updates when an environment changes it's configuration.

I had some more ideas planned, such as work statistics for project management and deployment to production environments.

I can do that with boxen alright: create a project manifest, define where the source is (git repo), what the dependencies are (node version, database server), nginx configuration for the local environment (a foo.dev domain which automatically proxies to the project's web server) etc.

I doubt the upper management can set up these things, they can say that they want to start a new project X, but how exactly the dev environment will look should be, IMO, in the hands of engineers. Lots of technical decisions to be made there.

I do like the UI though.

Many of these decisions would be done through a Beta if I had released it. I did however put a lot of thought into it but after seeing some interesting sign ups from specific companies I decided that a beta would be the way to go.

However, the project was terminated due to the lack of time / financials.

You sure your not just trying to refuge a failed startup and get some good press out of it?

Reply on news.ycombinator.com