51–60 of 185 posts
Earlier quoted context omitted.
Why? If someone else is doing it that probably means there is a market for it.
Sure, but could I compete with free?
I want to build apps, not worry about hosting and servers.
Earlier quoted context omitted.
Mitchell Hashimoto has been supporting Vagrant users for several years now. I wouldn't be surprised if that experience has led him to such a conclusion in regards to the use of Vagrant, e.g. all uses have dependency on a version of Ruby/PHP and some versions of some number of libraries and so on. The same abstractions allow control despite differences at a finer grain.
The number of variations on PHP applications are infinite: 1. Apache or Nginx+PHP-FPM 2. INI Configuration 3. PHP Extensions and their INI configuration 4. Vhost Configuration, especially rewriting rules 5. Docroot in app root, or dedicated directory This cant possible be defined in a common/generic way and supporting more than 50% of the use-cases. There is a reason why complex click to configure interfaces exist fo…
there is already go project named otto: https://github.com/robertkrimen/otto
Earlier quoted context omitted.
Why? This is what I love about Heroku. I get to build the app I want without worrying about all the other aspects of hosting that make me want to never launch an app ever again. I love the idea of focusing on the development part and letting something / someone else worry about hosting.
Have you ever dealt with a large app deployment on Heroku? Unless you're willing to throw money at the problem it sucks.
"Notice that the Appfile makes no mention of OS, memory, disk space, etc. Otto has built-in knowledge of best practices and picks smart defaults for you." Sounds like a big bag of "nope."
I think that's why they're defaults? Not hardcoded unchangeable values?
In such cases, explicit and declarative is much better than implicit and hidden.
Hello everyone! I just wanted to note that I'm running around at HashiConf and likely won't be around to answer as many questions or comments as I'd like. But thank you for all the activity around this and we're excited to show this to you today. I want to just give a few key notes, though many other folks around here are right. * For Otto 0.1, we focused on developer experience. We don't recommend deploying for anyt…
Hello everyone! I just wanted to note that I'm running around at HashiConf and likely won't be around to answer as many questions or comments as I'd like. But thank you for all the activity around this and we're excited to show this to you today. I want to just give a few key notes, though many other folks around here are right. * For Otto 0.1, we focused on developer experience. We don't recommend deploying for anyt…
Why isn't Otto named Vagrant 2.0 or something? Its confusing to be "abandoning" Vagrant for a new system "Otto" when really all that is happening is that Otto is fixing issues that have come up over time with Vagrant. Why not a migration strategy, some backwards compatibility during the translation, and then move into the future?
Earlier quoted context omitted.
Why isn't Otto named Vagrant 2.0 or something? Its confusing to be "abandoning" Vagrant for a new system "Otto" when really all that is happening is that Otto is fixing issues that have come up over time with Vagrant. Why not a migration strategy, some backwards compatibility during the translation, and then move into the future?
Otto uses Vagrant under the hood.
Earlier quoted context omitted.
I think that's why they're defaults? Not hardcoded unchangeable values?
Everything having a default is sometimes not sensible. In such cases, explicit and declarative is much better than implicit and hidden.
Why not choose a name that is not already used by other project? There is already a pretty popular library for android named Otto http://square.github.io/otto/