18 ms·

Nanobox: Local development done right

201 points by numo16 11y ago

amelius 11y ago
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.
- thecopy 11y ago
  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 how each should be configured This sound quite fragile imo. No specs or configuration, it just guesses what all my deps are, and how to configure redis,mysql, and "other data-specific services" etc. So an enourmous abstraction over everything except my source code with no configuration and a promise to "take care of everything" and forcing me to use their pipeline. Hm...
  - sdegutis 11y ago
    >> Nanobox detects your app type and automatically configures the environment and installs everything your app needs to run Yeah, that's gonna be a bit hard for it to do with our Clojure web app. Well, maybe. If it knows to install openjdk-7 and nginx because it sees a project.clj, then perhaps it really is as smart as it thinks it is.
    - fu86 11y ago
      .. or immutant or jetty or .... Buildinng a simulated production environment on the dev machine is hard because in production, there are (in most cases) special settings, special servers, special configurations, special files on special places, ... It is rarely out of the box configured service stacks.
    - sanderson1 11y ago
      Auto-detections is based on the existing library of engines, which is only in its infancy right now. Engines have what's called a "sniff" script. This is a bash script written by the engine developer that searches the codebase for uniquely identifying files or content within files. Auto-detection won't work for every app, but it should help to get the majority of apps up and running quickly. For very custom apps, anybody can develop and publish their own engine. Information about engines is in the nanobox docs: https://docs.nanobox.io/engines/ https://docs.nanobox.io/engines/
  - tylerflint 11y ago
    You're right, not every scenario can be handled automatically. For that reason, the Boxfile is king: https://docs.nanobox.io/getting-started/boxfile/ https://docs.nanobox.io/getting-started/boxfile/
  - josegonzalez 11y ago
    Note: this is exactly how buildpack detection on heroku - and anything that uses buildstep/herokuish for PaaS solutions - work.
- JustSomeNobody 11y ago
  Who doesn't have scripts to do most of this anyway?
  - hullo 11y ago
    the target audience for the tool?
duiker101 11y ago
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.
- grhmc 11y ago
  Later it says you can specify which JS runtime to use with python: build: runtime: python27 js_runtime: nodejs-0.12 app_module: ''
  - zeckalpha 11y ago
    That one's not unreasonable.
    - grhmc 11y ago
      It seems I can't also specify a ruby runtime, though. What makes one reasonable and another not?
      - sanderson1 11y ago
        The mention of ruby in the description is a typo. There isn't a ruby runtime available in the generic python engine, but you're free to fork the engine and add the ruby runtime. All engines are open-source.
  - sanderson1 11y ago
    The js_runtime is included because of the ubiquity of using tools like bower and gulp to compile assets, which require node.
- stinky613 11y ago
  Yeah, if anyone from nanobox is reading, I found a broken link on the Node.js Engine page: On page https://engines.nanobox.io/languages/nodejs https://engines.nanobox.io/languages/nodejs the link for Create Custom Engine leads to a 404 on https://nanobox.io/engine-dev https://nanobox.io/engine-dev
sz4kerto 11y ago
Can't see the letters, sorry. Not everyone is sitting in a dark room.
- creshal 11y ago
  I am sitting in a dark room, with a high-contrast IPS screen, and still can barely read anything.
  - sdegutis 11y ago
    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.
    - creshal 11y ago
      Seems to be the solarized colour palette (or was inspired by it, at least): http://ethanschoonover.com/solarized 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 https://github.com/nielsmadan/harlequin ).
      - sdegutis 11y ago
        I used to use Solarized but switched to Zenburn since then in my editor. That said, whatever color scheme they're using on that website looks really nice on the website, even if I wouldn't use it in my editor (I might though!)
johanvts 11y ago
I just see a blue wall with a logo at the bottom on Edge or IE 11.
- tylerflint 11y ago
  This is an issue we just became aware of. Working on a fix as we speak.
lucadom 11y ago
What makes it different from https://ottoproject.io https://ottoproject.io ?
- sanderson1 11y ago
  We, like otto, see the need for tools like these in today's development climate. While both tools are very similar and accomplish nearly the same thing, the main difference is under the hood: 1. Nanobox embraces Docker and the philosophy of containers. Every component and process of your app is housed inside of an isolated container. The VM only runs the Docker deamon and the Nanobox deamon. In contrast, otto leverages Docker, but is built more to conform to Hashicorp's existing toolset. 2. Extensibility in Nanobox is accomplished through engines, which are inspired by and very similar to Heroku buildpacks. As noted above, engines run inside of isolated containers inside the VM. Otto's extensibility is accomplished through Go plugins that run on the host machine. 3. Nanobox caters to the dev workflow. We'll automatically suspend and save the VM state when it's not in use. Nanobox doesn't require the VM to always be running.
sandGorgon 11y ago
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.
- krishicks 11y ago
  You can use Lattice for that: http://lattice.cf/docs/ http://lattice.cf/docs/
  - sandGorgon 11y ago
    thanks for that. lattice seems overly complicated for a developer machine usecase. I might as well do Docker.
- mikewhy 11y ago
  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 https://www.docker.com/docker-compose
  - davexunit 11y ago
    Docker Compose depends on a bundled copy of OpenSSL that has been insecure since June: https://github.com/docker/compose/issues/1601 https://github.com/docker/compose/issues/1601
  - sandGorgon 11y ago
    our production is built using docker-compose. But it is still not as easy for a developer to get started using docker-compose and be as effective as installing the code on his desktop. 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.
- geuis 11y ago
  Yeah, I've been trying to streamline this too. Have yet to find a good way to do local development inside docker. The best approach so far I've found is that I have my db, redis, and other services like that running in docker. My application is checked out locally and configured to hit the docker services.
nextos 11y ago
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)
- davexunit 11y ago
  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.
  - random778 11y ago
    I have read about half of Eelco Dolstra's Ph.D. thesis [1]. I wish all distros worked like this. I had never heard of Guix before and was about to ask how it relates to / differs from Nix, so if anyone else is wondering: Guix: Specializes in providing exclusively free software. Based on Nix [2]. Implementation differences, quoted from section 2.3 in [3]: "Our main contribution with GNU Guix is the use of Scheme for both the composition and description of build processes, and the implementation of build scripts. In other words, Guix builds upon the build and deployment primitives of Nix, but replaces the Nix language by Scheme with embedded domain-specific languages (EDSLs), and promotes Scheme as a replacement for Bash in build scripts. Guix is implemented using GNU Guile 2.0 2 , a rich implementation of Scheme based on a compiler and bytecode interpreter that supports the R5RS and R6RS standards. It reuses the build primitives of Nix by making remote procedure calls (RPCs) to the Nix build daemon. We claim that using an embedded DSL has numerous practical benefits over an independent DSL: tooling (use of Guile’s compiler, debugger, and REPL, Unicode support, etc.), libraries (SRFIs, internationalization support, etc.), and seamless integration in larger programs. To illustrate this last point, consider an application that traverses the list of available packages and processes it—for instance to filter packages whose name matches a pattern, or to render it as HTML. A Scheme program can readily and efficiently do it with Guix, where packages are first-class Scheme objects; conversely, writing such an implementation with an external DSL such as Nix requires either extending the language implementa- tion with the necessary functionality, or interfacing with it via an external representation such as XML, which is often inefficient and lossy. We show that use of Scheme in build scripts is natural, andcan achieve conciseness comparable to that of shell scripts, but with improved expressivity and clearer semantics." From my limited view, Nix has a very strong theoretical base. Do you expect any developments at that level, and do you think these hypothetical developments will be integrated by the developers of Guix, or might it at some point start ignoring improvements in the theory? [1] http://nixos.org/~eelco/pubs/phd-thesis.pdf http://nixos.org/~eelco/pubs/phd-thesis.pdf [2] https://en.wikipedia.org/wiki/Nix_package_manager https://en.wikipedia.org/wiki/Nix_package_manager [3] http://arxiv.org/abs/1305.4584 http://arxiv.org/abs/1305.4584
threatofrain 11y ago
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 with well-defined boundaries.
- rdsubhas 11y ago
  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.
  - tylerflint 11y ago
    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/ https://docs.nanobox.io/getting-started/boxfile/) 2- Write your own engine that will actually setup the environment (https://desktop.nanobox.io/engine-dev/ https://desktop.nanobox.io/engine-dev/).
arsalanb 11y ago
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.
- sanderson1 11y ago
  Full disclosure: I work for Nanobox. We're prepping Nanobox Cloud for release likely in 2016 https://nanobox.io/cloud/ https://nanobox.io/cloud/. With Nanobox Cloud, you'll be able to take the exact same environment configuration you have locally and deploy it to a cloud provider (starting with Digital Ocean but others will soon follow). The same engine used to run your app locally will be used in the production app. The whole workflow has been designed to provide parity between development and production environments.
  - arsalanb 11y ago
    How can I pay you for this? Note — I know many might disagree, because of very valid points, but for me personally, deployment is a nightmare. I really have no clue how that works. I didn't know SQLite3 (being file-based) needed special permissions on the .db file to be able to avoid an OSError, and the folder containing the file needed other permissions. The whole absolute-path-in-server-but-relative-will-work-locally, blah blah — This is really a irritating business for me. Deployment ideally should be like — $ sometool deploy myAwesomeApp $ Enter <some-sort-of-username-for-server> — myServer $ Enter <some-sort-of-password-or pem key location> — •••••••••• $ Deploying...done! $ Your app is live on YOUR-SERVER-IP Too far off for many. Many might hate it, but trust me I personally know atleast 50 other developers who would benefit from a setup like this. Mostly people learning how to code, who just want to put their simple apps out there.
    - sanderson1 11y ago
      Thanks for the support. Nanobox Cloud is still a work and progress, but we are hoping to open up the private beta soon. You can sign up for a beta invite on https://nanobox.io/cloud/ https://nanobox.io/cloud/ (Just click "Sign up for the Private Beta" and submit your email).
rnernento 11y ago
While 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.
- codebeaker 11y ago
  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.
  - edw 11y ago
    _Ars Technica_ and Heroku, two sites that catered to the tech ninja videogamer-brogrammer demographic, both spent a lot of effort work walking back their light-on-dark visual identities when it was time to join the grown-ups. _Ars_ addressed this issue in the FAQ for their 2004 redesign: http://arstechnica.com/uncategorized/2004/10/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.
odiroot 11y ago
And again dependency on Vagrant and Virtualbox. What can you do. On every modern Ubuntu (even previous/old LTS) Docker works out of the box, without any issue. Why add another virtualization layer on top?
- aeze 11y ago
  To work with other operating systems?
  - odiroot 11y ago
    Then why not have it optional?
deleted 11y ago
[deleted]
jcwilde 11y ago
It's a bit disingenuous to list a bunch of languages (along with custom logo icons) that are _presumably_ supported by nanobox, only to force visitors to drill-down one-by-one to discover that only one out of three have any support at all, and the others are just placeholders saying "please contribute". On the positive side, I guess it is better odds than a state lottery.
- sanderson1 11y ago
  We (I work for Nanobox) listed all the languages we hope to support mainly as an invitation to collaborate. We admittedly do not specialize in all programming languages. Engines are open-source and those who do specialize are invited to create engines for each language. We'll even create the engine for you. We just need to know what the engine should look for and how the environment needs to be configured.
  - thawkins 11y ago
    The php part has almost no content. Im also concerned that the custom builds are not documented, its easy to build a dev env with half a dozen rpm files thrown in, but when it comes to getting all your custom extensions etc added thats a bit harder and we cannot judge that as of right now.
    - sanderson1 11y ago
      There's currently only one php engine, other than the generic php engine, listed on https://engines.nanobox.io/languages/php https://engines.nanobox.io/languages/php. However if you look at the generic php engine docs, there's a lot of content: https://engines.nanobox.io/releases/3b30f069-bb16-4f1a-9c36-10ac20580799 https://engines.nanobox.io/releases/3b30f069-bb16-4f1a-9c36-.... And even more in the Advance config options included in the nanobox-engine-php repo: https://github.com/nanobox-io/nanobox-engine-php/blob/master/doc/advanced-php-config.md https://github.com/nanobox-io/nanobox-engine-php/blob/master...
  - carapace 11y ago
    Hey, I typically browse with javascript turned off. Your site is a blank page for me.
Gedrovits 11y ago
Magic engine detected Rails 4.2.5 app as nodejs...
- sanderson1 11y ago
  There currently isn't a Rails engine so rails won't get auto-detected yet. The nodejs detection is listed in the New column on their trello board: https://trello.com/b/4nVFzmNZ/nanobox-desktop https://trello.com/b/4nVFzmNZ/nanobox-desktop Looks like it never got added as an issue on the nanobox project. I'll do that now.
vinceguidry 11y ago
I develop in OSX, Vagrant is entirely too much overhead and hurts more than it helps. It's less work to make the app work cross-platform than to have to deal with the slowdown and the added tool complexity.
- sfilipov 11y ago
  The only overhead I notice is the fact that VirtualBox Shared Folders are really slow. If that's the case, using the paid VMWare plugin can help.
  - boundlessdreamz 11y ago
    Or use NFS. Way better performance.
    - tylerflint 11y ago
      NFS will be the default adapter for nanobox, but can be disabled.
jonathankau 11y ago
The aggregate HN community seems to be reacting pretty negatively, but I see a lot of value in high-level "magic" tools (like this and Otto) that abstract away configuration for developers. While everyone else commenting is likely more experienced and thus feels more comfortable setting up the required config files, I am still a relatively novice web developer. Tools such as Nanobox and Otto provide a way for people like me to start using the right dev environment management processes without being overwhelmed.
- sdomino 11y ago
  You hit it right on the head. We realize that this tool isn't going to be for everyone, but it will definitely help others. We're trying to make it so that developers don't have to worry about configuring an environment and just focus on coding. Even an experienced developer could benefit from this if they don't want to take the time to configure environments.
  - Glide 11y ago
    I think it's great what you're doing to reduce friction for developers. I don't think people want to take time to configure environments. It's just that we've all been bitten by environment configuration and sometimes configuring it in a specific way matters.
  - mpeg 11y ago
    I don't think the tool is for me, as it feels like too much of an opinionated framework. However, I really appreciate you open sourcing it under a permissive license, as I can see myself using some of your shell and go scripts in the future. Thanks.
- armandososa 11y ago
  I've learn how to setup everything to develop NodeJS apps and I still hate it. I wish I had nanobox a month ago when I was setting up a new machine against a tight deadline.
  - 11y ago
Dangeranger 11y ago
Does anyone know what the endgame for this software is? Does Nanobox plan to offer a more premium service in addition to the basic functionalities? Hashicorp makes some revenue from premium services and I cannot imagine a tool this polished being sustainable without some sort of revenue source. Just asking, not a criticism.
- sdomino 11y ago
  We hope to keep the nanobox desktop tool free and open source. We plan on offering a "cloud" version of the tool (https://nanobox.io/cloud/ https://nanobox.io/cloud/) that will use nanobox desktop to help streamline deploying production code to a provider of your choice.
  - Dangeranger 11y ago
    Thanks Steve. After looking into your company a bit it's clear that you all have been building your infrastructure to support PagodaBox for some time. Thanks for open sourcing so many tools https://nanobox.io/open-source/ https://nanobox.io/open-source/ . I had never heard of anything you all made until today.
  - mwcampbell 11y ago
    DigitalOcean and Linode? Want!
gotrek 11y ago
Love the page. On my mac it looks amazing. I think that we are being flooded with new kind of software. I would appreciate a maximum 1 page long example of what can be done with the nanobox and a short comparison to existing tools (this is absolute must). I cannot justify using it and relying on it compared to the Docker or Hashicorp's software.
gmisra 11y ago
To save everybody some time, here is a list of the runtimes and frameworks actually supported by nanobox: - ruby 1.9, 2.0, 2.1, 2.2 / jruby 1.6, 1.7, 9.0 - node 0.8, 0.10, 0.12 / iojs 2.3 - python 2.7, 3.4 - php 5.3, 5.4, 5.5, 5.6 - wordpress (version unknown) - java openjdk 7, 8 / sunjdk 6, 7, 8 (no minor version information available) The actual content on the "Engines" page is aspirational, to say the least. One of the first question I ask of a tech product is "is it usable today for any current projects?" - why make this question challenging for site visitors? If they're targeting novice web developers who should follow best practices, no rails support and out-of-date node support seems like a bad place to start.
- sanderson1 11y ago
  Posted this answer to a similar question/comment: --- We (I work for Nanobox) listed all the languages we hope to support mainly as an invitation to collaborate. We admittedly do not specialize in all programming languages. Engines are open-source and those who do specialize are invited to create engines for each language. We'll even create the engine for you. We just need to know what the engine should look for and how the environment needs to be configured. --- The library of engines is in its infancy and we're working to expand it. You're absolutely right in saying that the list of engines is "aspirational". Anybody can build and publish new engines. Any help you can provide would be greatly appreciated.
  - gmisra 11y ago
    Aspirational is great, but I would suggest you update that page to clearly identify what is currently supported versus what is aspirational. There is probably limited overlap between your target user audience and your target collaborator audience.
    - tylerflint 11y ago
      I think you're right. Thanks for the advice!
marknutter 11y ago
Beautiful website. Really. The colors are exquisite.

201 points by numo16 11y ago

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.

thecopy 11y ago
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 how each should be configured This sound quite fragile imo. No specs or configuration, it just guesses what all my deps are, and how to configure redis,mysql, and "other data-specific services" etc. So an enourmous abstraction over everything except my source code with no configuration and a promise to "take care of everything" and forcing me to use their pipeline. Hm...
- sdegutis 11y ago
  >> Nanobox detects your app type and automatically configures the environment and installs everything your app needs to run Yeah, that's gonna be a bit hard for it to do with our Clojure web app. Well, maybe. If it knows to install openjdk-7 and nginx because it sees a project.clj, then perhaps it really is as smart as it thinks it is.
  - fu86 11y ago
    .. or immutant or jetty or .... Buildinng a simulated production environment on the dev machine is hard because in production, there are (in most cases) special settings, special servers, special configurations, special files on special places, ... It is rarely out of the box configured service stacks.
  - sanderson1 11y ago
    Auto-detections is based on the existing library of engines, which is only in its infancy right now. Engines have what's called a "sniff" script. This is a bash script written by the engine developer that searches the codebase for uniquely identifying files or content within files. Auto-detection won't work for every app, but it should help to get the majority of apps up and running quickly. For very custom apps, anybody can develop and publish their own engine. Information about engines is in the nanobox docs: https://docs.nanobox.io/engines/ https://docs.nanobox.io/engines/
- tylerflint 11y ago
  You're right, not every scenario can be handled automatically. For that reason, the Boxfile is king: https://docs.nanobox.io/getting-started/boxfile/ https://docs.nanobox.io/getting-started/boxfile/
- josegonzalez 11y ago
  Note: this is exactly how buildpack detection on heroku - and anything that uses buildstep/herokuish for PaaS solutions - work.
JustSomeNobody 11y ago
Who doesn't have scripts to do most of this anyway?
- hullo 11y ago
  the target audience for the tool?

duiker101 11y ago

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.

grhmc 11y ago
Later it says you can specify which JS runtime to use with python: build: runtime: python27 js_runtime: nodejs-0.12 app_module: ''
- zeckalpha 11y ago
  That one's not unreasonable.
  - grhmc 11y ago
    It seems I can't also specify a ruby runtime, though. What makes one reasonable and another not?
    - sanderson1 11y ago
      The mention of ruby in the description is a typo. There isn't a ruby runtime available in the generic python engine, but you're free to fork the engine and add the ruby runtime. All engines are open-source.
- sanderson1 11y ago
  The js_runtime is included because of the ubiquity of using tools like bower and gulp to compile assets, which require node.
stinky613 11y ago
Yeah, if anyone from nanobox is reading, I found a broken link on the Node.js Engine page: On page https://engines.nanobox.io/languages/nodejs https://engines.nanobox.io/languages/nodejs the link for Create Custom Engine leads to a 404 on https://nanobox.io/engine-dev https://nanobox.io/engine-dev

sz4kerto 11y ago

Can't see the letters, sorry. Not everyone is sitting in a dark room.

creshal 11y ago
I am sitting in a dark room, with a high-contrast IPS screen, and still can barely read anything.
- sdegutis 11y ago
  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.
  - creshal 11y ago
    Seems to be the solarized colour palette (or was inspired by it, at least): http://ethanschoonover.com/solarized 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 https://github.com/nielsmadan/harlequin ).
    - sdegutis 11y ago
      I used to use Solarized but switched to Zenburn since then in my editor. That said, whatever color scheme they're using on that website looks really nice on the website, even if I wouldn't use it in my editor (I might though!)

johanvts 11y ago

I just see a blue wall with a logo at the bottom on Edge or IE 11.

tylerflint 11y ago
This is an issue we just became aware of. Working on a fix as we speak.

lucadom 11y ago

What makes it different from https://ottoproject.io https://ottoproject.io ?

sanderson1 11y ago
We, like otto, see the need for tools like these in today's development climate. While both tools are very similar and accomplish nearly the same thing, the main difference is under the hood: 1. Nanobox embraces Docker and the philosophy of containers. Every component and process of your app is housed inside of an isolated container. The VM only runs the Docker deamon and the Nanobox deamon. In contrast, otto leverages Docker, but is built more to conform to Hashicorp's existing toolset. 2. Extensibility in Nanobox is accomplished through engines, which are inspired by and very similar to Heroku buildpacks. As noted above, engines run inside of isolated containers inside the VM. Otto's extensibility is accomplished through Go plugins that run on the host machine. 3. Nanobox caters to the dev workflow. We'll automatically suspend and save the VM state when it's not in use. Nanobox doesn't require the VM to always be running.

sandGorgon 11y ago

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.

krishicks 11y ago
You can use Lattice for that: http://lattice.cf/docs/ http://lattice.cf/docs/
- sandGorgon 11y ago
  thanks for that. lattice seems overly complicated for a developer machine usecase. I might as well do Docker.
mikewhy 11y ago
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 https://www.docker.com/docker-compose
- davexunit 11y ago
  Docker Compose depends on a bundled copy of OpenSSL that has been insecure since June: https://github.com/docker/compose/issues/1601 https://github.com/docker/compose/issues/1601
- sandGorgon 11y ago
  our production is built using docker-compose. But it is still not as easy for a developer to get started using docker-compose and be as effective as installing the code on his desktop. 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.
geuis 11y ago
Yeah, I've been trying to streamline this too. Have yet to find a good way to do local development inside docker. The best approach so far I've found is that I have my db, redis, and other services like that running in docker. My application is checked out locally and configured to hit the docker services.

nextos 11y ago

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)

davexunit 11y ago
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.
- random778 11y ago
  I have read about half of Eelco Dolstra's Ph.D. thesis [1]. I wish all distros worked like this. I had never heard of Guix before and was about to ask how it relates to / differs from Nix, so if anyone else is wondering: Guix: Specializes in providing exclusively free software. Based on Nix [2]. Implementation differences, quoted from section 2.3 in [3]: "Our main contribution with GNU Guix is the use of Scheme for both the composition and description of build processes, and the implementation of build scripts. In other words, Guix builds upon the build and deployment primitives of Nix, but replaces the Nix language by Scheme with embedded domain-specific languages (EDSLs), and promotes Scheme as a replacement for Bash in build scripts. Guix is implemented using GNU Guile 2.0 2 , a rich implementation of Scheme based on a compiler and bytecode interpreter that supports the R5RS and R6RS standards. It reuses the build primitives of Nix by making remote procedure calls (RPCs) to the Nix build daemon. We claim that using an embedded DSL has numerous practical benefits over an independent DSL: tooling (use of Guile’s compiler, debugger, and REPL, Unicode support, etc.), libraries (SRFIs, internationalization support, etc.), and seamless integration in larger programs. To illustrate this last point, consider an application that traverses the list of available packages and processes it—for instance to filter packages whose name matches a pattern, or to render it as HTML. A Scheme program can readily and efficiently do it with Guix, where packages are first-class Scheme objects; conversely, writing such an implementation with an external DSL such as Nix requires either extending the language implementa- tion with the necessary functionality, or interfacing with it via an external representation such as XML, which is often inefficient and lossy. We show that use of Scheme in build scripts is natural, andcan achieve conciseness comparable to that of shell scripts, but with improved expressivity and clearer semantics." From my limited view, Nix has a very strong theoretical base. Do you expect any developments at that level, and do you think these hypothetical developments will be integrated by the developers of Guix, or might it at some point start ignoring improvements in the theory? [1] http://nixos.org/~eelco/pubs/phd-thesis.pdf http://nixos.org/~eelco/pubs/phd-thesis.pdf [2] https://en.wikipedia.org/wiki/Nix_package_manager https://en.wikipedia.org/wiki/Nix_package_manager [3] http://arxiv.org/abs/1305.4584 http://arxiv.org/abs/1305.4584

threatofrain 11y ago

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 with well-defined boundaries.

rdsubhas 11y ago
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.
- tylerflint 11y ago
  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/ https://docs.nanobox.io/getting-started/boxfile/) 2- Write your own engine that will actually setup the environment (https://desktop.nanobox.io/engine-dev/ https://desktop.nanobox.io/engine-dev/).

arsalanb 11y ago

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.

sanderson1 11y ago
Full disclosure: I work for Nanobox. We're prepping Nanobox Cloud for release likely in 2016 https://nanobox.io/cloud/ https://nanobox.io/cloud/. With Nanobox Cloud, you'll be able to take the exact same environment configuration you have locally and deploy it to a cloud provider (starting with Digital Ocean but others will soon follow). The same engine used to run your app locally will be used in the production app. The whole workflow has been designed to provide parity between development and production environments.
- arsalanb 11y ago
  How can I pay you for this? Note — I know many might disagree, because of very valid points, but for me personally, deployment is a nightmare. I really have no clue how that works. I didn't know SQLite3 (being file-based) needed special permissions on the .db file to be able to avoid an OSError, and the folder containing the file needed other permissions. The whole absolute-path-in-server-but-relative-will-work-locally, blah blah — This is really a irritating business for me. Deployment ideally should be like — $ sometool deploy myAwesomeApp $ Enter <some-sort-of-username-for-server> — myServer $ Enter <some-sort-of-password-or pem key location> — •••••••••• $ Deploying...done! $ Your app is live on YOUR-SERVER-IP Too far off for many. Many might hate it, but trust me I personally know atleast 50 other developers who would benefit from a setup like this. Mostly people learning how to code, who just want to put their simple apps out there.
  - sanderson1 11y ago
    Thanks for the support. Nanobox Cloud is still a work and progress, but we are hoping to open up the private beta soon. You can sign up for a beta invite on https://nanobox.io/cloud/ https://nanobox.io/cloud/ (Just click "Sign up for the Private Beta" and submit your email).

rnernento 11y ago

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

codebeaker 11y ago
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.
- edw 11y ago
  _Ars Technica_ and Heroku, two sites that catered to the tech ninja videogamer-brogrammer demographic, both spent a lot of effort work walking back their light-on-dark visual identities when it was time to join the grown-ups. _Ars_ addressed this issue in the FAQ for their 2004 redesign: http://arstechnica.com/uncategorized/2004/10/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.

odiroot 11y ago

And again dependency on Vagrant and Virtualbox. What can you do. On every modern Ubuntu (even previous/old LTS) Docker works out of the box, without any issue. Why add another virtualization layer on top?

aeze 11y ago
To work with other operating systems?
- odiroot 11y ago
  Then why not have it optional?

deleted 11y ago

[deleted]

jcwilde 11y ago

It's a bit disingenuous to list a bunch of languages (along with custom logo icons) that are _presumably_ supported by nanobox, only to force visitors to drill-down one-by-one to discover that only one out of three have any support at all, and the others are just placeholders saying "please contribute". On the positive side, I guess it is better odds than a state lottery.

sanderson1 11y ago
We (I work for Nanobox) listed all the languages we hope to support mainly as an invitation to collaborate. We admittedly do not specialize in all programming languages. Engines are open-source and those who do specialize are invited to create engines for each language. We'll even create the engine for you. We just need to know what the engine should look for and how the environment needs to be configured.
- thawkins 11y ago
  The php part has almost no content. Im also concerned that the custom builds are not documented, its easy to build a dev env with half a dozen rpm files thrown in, but when it comes to getting all your custom extensions etc added thats a bit harder and we cannot judge that as of right now.
  - sanderson1 11y ago
    There's currently only one php engine, other than the generic php engine, listed on https://engines.nanobox.io/languages/php https://engines.nanobox.io/languages/php. However if you look at the generic php engine docs, there's a lot of content: https://engines.nanobox.io/releases/3b30f069-bb16-4f1a-9c36-10ac20580799 https://engines.nanobox.io/releases/3b30f069-bb16-4f1a-9c36-.... And even more in the Advance config options included in the nanobox-engine-php repo: https://github.com/nanobox-io/nanobox-engine-php/blob/master/doc/advanced-php-config.md https://github.com/nanobox-io/nanobox-engine-php/blob/master...
- carapace 11y ago
  Hey, I typically browse with javascript turned off. Your site is a blank page for me.

Gedrovits 11y ago

Magic engine detected Rails 4.2.5 app as nodejs...

sanderson1 11y ago
There currently isn't a Rails engine so rails won't get auto-detected yet. The nodejs detection is listed in the New column on their trello board: https://trello.com/b/4nVFzmNZ/nanobox-desktop https://trello.com/b/4nVFzmNZ/nanobox-desktop Looks like it never got added as an issue on the nanobox project. I'll do that now.

vinceguidry 11y ago

I develop in OSX, Vagrant is entirely too much overhead and hurts more than it helps. It's less work to make the app work cross-platform than to have to deal with the slowdown and the added tool complexity.

sfilipov 11y ago
The only overhead I notice is the fact that VirtualBox Shared Folders are really slow. If that's the case, using the paid VMWare plugin can help.
- boundlessdreamz 11y ago
  Or use NFS. Way better performance.
  - tylerflint 11y ago
    NFS will be the default adapter for nanobox, but can be disabled.

jonathankau 11y ago

The aggregate HN community seems to be reacting pretty negatively, but I see a lot of value in high-level "magic" tools (like this and Otto) that abstract away configuration for developers. While everyone else commenting is likely more experienced and thus feels more comfortable setting up the required config files, I am still a relatively novice web developer. Tools such as Nanobox and Otto provide a way for people like me to start using the right dev environment management processes without being overwhelmed.

sdomino 11y ago
You hit it right on the head. We realize that this tool isn't going to be for everyone, but it will definitely help others. We're trying to make it so that developers don't have to worry about configuring an environment and just focus on coding. Even an experienced developer could benefit from this if they don't want to take the time to configure environments.
- Glide 11y ago
  I think it's great what you're doing to reduce friction for developers. I don't think people want to take time to configure environments. It's just that we've all been bitten by environment configuration and sometimes configuring it in a specific way matters.
- mpeg 11y ago
  I don't think the tool is for me, as it feels like too much of an opinionated framework. However, I really appreciate you open sourcing it under a permissive license, as I can see myself using some of your shell and go scripts in the future. Thanks.
armandososa 11y ago
I've learn how to setup everything to develop NodeJS apps and I still hate it. I wish I had nanobox a month ago when I was setting up a new machine against a tight deadline.
- 11y ago

Dangeranger 11y ago

Does anyone know what the endgame for this software is? Does Nanobox plan to offer a more premium service in addition to the basic functionalities? Hashicorp makes some revenue from premium services and I cannot imagine a tool this polished being sustainable without some sort of revenue source. Just asking, not a criticism.

sdomino 11y ago
We hope to keep the nanobox desktop tool free and open source. We plan on offering a "cloud" version of the tool (https://nanobox.io/cloud/ https://nanobox.io/cloud/) that will use nanobox desktop to help streamline deploying production code to a provider of your choice.
- Dangeranger 11y ago
  Thanks Steve. After looking into your company a bit it's clear that you all have been building your infrastructure to support PagodaBox for some time. Thanks for open sourcing so many tools https://nanobox.io/open-source/ https://nanobox.io/open-source/ . I had never heard of anything you all made until today.
- mwcampbell 11y ago
  DigitalOcean and Linode? Want!

gotrek 11y ago

Love the page. On my mac it looks amazing. I think that we are being flooded with new kind of software. I would appreciate a maximum 1 page long example of what can be done with the nanobox and a short comparison to existing tools (this is absolute must). I cannot justify using it and relying on it compared to the Docker or Hashicorp's software.

gmisra 11y ago

To save everybody some time, here is a list of the runtimes and frameworks actually supported by nanobox: - ruby 1.9, 2.0, 2.1, 2.2 / jruby 1.6, 1.7, 9.0 - node 0.8, 0.10, 0.12 / iojs 2.3 - python 2.7, 3.4 - php 5.3, 5.4, 5.5, 5.6 - wordpress (version unknown) - java openjdk 7, 8 / sunjdk 6, 7, 8 (no minor version information available) The actual content on the "Engines" page is aspirational, to say the least. One of the first question I ask of a tech product is "is it usable today for any current projects?" - why make this question challenging for site visitors? If they're targeting novice web developers who should follow best practices, no rails support and out-of-date node support seems like a bad place to start.

sanderson1 11y ago
Posted this answer to a similar question/comment: --- We (I work for Nanobox) listed all the languages we hope to support mainly as an invitation to collaborate. We admittedly do not specialize in all programming languages. Engines are open-source and those who do specialize are invited to create engines for each language. We'll even create the engine for you. We just need to know what the engine should look for and how the environment needs to be configured. --- The library of engines is in its infancy and we're working to expand it. You're absolutely right in saying that the list of engines is "aspirational". Anybody can build and publish new engines. Any help you can provide would be greatly appreciated.
- gmisra 11y ago
  Aspirational is great, but I would suggest you update that page to clearly identify what is currently supported versus what is aspirational. There is probably limited overlap between your target user audience and your target collaborator audience.
  - tylerflint 11y ago
    I think you're right. Thanks for the advice!

marknutter 11y ago

Beautiful website. Really. The colors are exquisite.