Live data from Hacker News

Nanobox: Local development done right

desktop.nanobox.io

71–80 of 84 posts

Re: Nanobox: Local development done right

#71
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.

Re: Nanobox: Local development done right

#72
post #71

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 o…

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.

Re: Nanobox: Local development done right

#73
post #37

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.

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.

Hey, I typically browse with javascript turned off. Your site is a blank page for me.

Re: Nanobox: Local development done right

#74
post #71

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 o…

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…

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.

Re: Nanobox: Local development done right

#75
post #74

Earlier quoted context omitted.

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…

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.

I think you're right. Thanks for the advice!

Re: Nanobox: Local development done right

#76
post #55

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…

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.

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.

Re: Nanobox: Local development done right

#77
post #63

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.

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/ ) that will use nanobox desktop to help streamline deploying production code to a provider of your choice.

DigitalOcean and Linode? Want!

Re: Nanobox: Local development done right

#79

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.

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.

Re: Nanobox: Local development done right

#80

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…

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.

Then learn Chef/Puppet or something like that and write/reuse recipes to install and configure whatever you need to configure.

I haven't set up an environment manually in a few years: I simply have my own recipes for the types of apps I'm developing in Chef (most of them just minor tweaks or config changes over existing recipes), my own vagrant boxes (I like different flavors of linux for different types of apps) and so on.

Starting a new project implies choosing the necessary recipes, adding them to a vagrant file, 'vagrant up' and wait a few minutes until everything is set up. Done.

Post reply on HN