Interesting, but this is too much of a framework for my taste. I prefer to work with independent tools with a well-defined boundary, so that I can change them at will.
Who doesn't have scripts to do most of this anyway?
Nanobox: Local development done right
81–84 of 84 posts
Re: Nanobox: Local development done right
#82I have a Dockerfile that I use to run my production. This is already built. Is there anything I can use to build a local dev environment quickly using the Dockerfile . Obviously I can use docker, but quite often new developers have trouble with docker.
Why not docker-compose[1]? One thing it does well is abstract docker commands to `docker-compose build && docker-compose up`. [1]: https://www.docker.com/docker-compose
I know I'm nitpicking here, but it would be great to have an abstraction on top of Dockerfiles that make it possible to develop in a near-production environment.
Re: Nanobox: Local development done right
#83While I don't think your tool is for everyone your site design is. Love the colors and clean design, goes a long way towards making me want to understand Nanobox.
Also a big dan of the design but I do find it to be much too dark, I'm in a well lit office, with a calibrated Dell UltraSharp display and the site's color scheme is really quite hard on the eyes, even if the design itself is beautiful.
_Ars_ addressed this issue in the FAQ for their 2004 redesign:
http://arstechnica.com/uncategorized/2004/10/redesign/
> Q. Why the white? Oh my eyes!
> A. Believe it or not, many people cannot read the "black" version of the site. This has been the #1 complaint Ars has received since day one. We thought it unwise to continue to use a default color scheme that was driving so many users away. Once it was clear that we could support both, we did, but white will be the default. The black design was also unfavorable to readers in corporate environments, and other places where the scheme sent the wrong signals to bosses and cubicle neighbors.
Re: Nanobox: Local development done right
#84Interesting, but this is too much of a framework for my taste. I prefer to work with independent tools with a well-defined boundary, so that I can change them at will.
Agreed. This sentence especially makes me think this is too much magic: >Nanobox detects your app type and automatically configures the environment and installs everything your app needs to run and >Each Engine sniffs the code looking for a positive match to determine which language / framework your app is written in and lastly: >The matched Engine generates a Boxfile defining the services your app needs to run and h…