Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nanobox: Local development done right

desktop.nanobox.io

Post reply on HN
Print view View original

21–30 of 84 posts

Re: Nanobox: Local development done right

#21

Post by creshal »

sdegutis wrote: post #8
creshal wrote: post #6

Earlier quoted context omitted.

I am sitting in a dark room, with a high-contrast IPS screen, and still can barely read anything.

That said, the colors really are beautiful. At least, what I can see of them. Excellent color palette! I'm a sucker for softened tones like these.

Seems to be the solarized colour palette (or was inspired by it, at least): http://ethanschoonover.com/solarized

Looks fancy, but boy is it bad on the eyes. I've since switched away from it to harlequin ( https://github.com/nielsmadan/harlequin ).

Re: Nanobox: Local development done right

#22

Post by arsalanb »

Assuming this works perfectly well, all the time — this is awesome. A possible pain-point this is addressing is that apps behave differently locally and then when you move them to the cloud (aka deploy them) they behave differently.

Re: Nanobox: Local development done right

#23

Post by sandGorgon »

krishicks wrote: post #19
sandGorgon wrote: post #16

I 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.

You can use Lattice for that: http://lattice.cf/docs/

thanks for that. lattice seems overly complicated for a developer machine usecase. I might as well do Docker.

Re: Nanobox: Local development done right

#24

Post by rdsubhas »

threatofrain wrote: post #20

I am skeptical about this tool because I feel like the learning surface underneath will actually be massive, but massive in the wrong direction toward someone's idiosyncratic product. In order to give me confidence that I won't have to look underneath the surface too much, I'd want to know that the abstraction is very airtight, but all appearances say otherwise. Like another commentator said, I'd rather have an app w…

Yep, I don't get this whole trend. Want to start a virtual machine? Use docker-machine. Want to start a bunch of services? Use docker-compose. Want to define the service stack? Use a Dockerfile with the predefined language stacks.

Previously we used to write hundreds of lines of puppet/chef/whatever scripts just to set things up. Its all already boiled down to just a few lines of configuration files. With tools like this or otto, its getting further hidden into nothing, seeming to look almost like magic. I'd rather stick with the few lines that I can control.

Re: Nanobox: Local development done right

#26

Post by tylerflint »

thecopy wrote: post #4
amelius wrote: post #2

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.

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…

You're right, not every scenario can be handled automatically. For that reason, the Boxfile is king: https://docs.nanobox.io/getting-started/boxfile/

Re: Nanobox: Local development done right

#27

Post by tylerflint »

rdsubhas wrote: post #24
threatofrain wrote: post #20

I am skeptical about this tool because I feel like the learning surface underneath will actually be massive, but massive in the wrong direction toward someone's idiosyncratic product. In order to give me confidence that I won't have to look underneath the surface too much, I'd want to know that the abstraction is very airtight, but all appearances say otherwise. Like another commentator said, I'd rather have an app w…

Yep, I don't get this whole trend. Want to start a virtual machine? Use docker-machine. Want to start a bunch of services? Use docker-compose. Want to define the service stack? Use a Dockerfile with the predefined language stacks. Previously we used to write hundreds of lines of puppet/chef/whatever scripts just to set things up. Its all already boiled down to just a few lines of configuration files. With tools like…

Yes, nanobox will try to auto-configure your environment for you. If you would rather define your environment or if nanobox can't auto-configure your environment, you can either:

1- Explicitly define your app's environment with the Boxfile (https://docs.nanobox.io/getting-started/boxfile/)

2- Write your own engine that will actually setup the environment (https://desktop.nanobox.io/engine-dev/).

Re: Nanobox: Local development done right

#28

Post by davexunit »

nextos wrote: post #18

What's your take on Nix/Guix vs containers/virtual machines for setting up development environments? (note that the former also support containers, but they provide a very systematic way to manage dependencies)

It's an odd comparision, because Nix and Guix both include tools for making virtual machines and containers. I think the better comparison would be virtualizing/containerizing traditional distributions like Debian vs. using Nix/Guix.

With a traditional distro, you need to use a handful of additional tools like Vagrant, Docker, Ansible, etc. as well as several additional package managers to get everything setup. With Nix and Guix, you use a single package manager and single suite of tools to provision local environments, with or without virtualization. Those environments are declarative, reproducible, can be rolled back, etc. It's a much cleaner way to work.

Re: Nanobox: Local development done right

#30

Post by tylerflint »

duiker101 wrote: post #3

seems interesting but I started clicking around, specifically in the Python section and this website seems to have been released too early, the text I am not sure is right(it says I need to use a ruby engine settings for python?) and some links don't work or give 404.

Thanks for the heads up! Please keep in mind this is an open-source project in the pre-beta phase. Any contributions are welcomed!
Post reply on HN