I used to have 5 or 6, some related to different companies, some for junk, etc., but now I find it much easier to just use a single address for everything.
He's right in that we won't remember either solely for the money the made. But Steve Jobs will be remembered along the lines of people like Thomas Edison. And he'll probably be studied in business classes for a very long time, both for the smart and not so smart moves.
Product menu > Build will build your app. You can tell Xcode where to put the app in the Locations preference pane, but if you want to distribute an iOS app you'll have to use the app store.
Is there an advantage to having it run in a browser? Desktop-style web apps always feel out of place compared to native apps. I prefer apps that fade into the background when I'm using them so I can focus on what I'm doing, and if an app feels non-native it tends to be more distracting than useful. It's like adding one more layer of complexity.
None of that would be particularly difficult. And nothing here is stopping that from happening, or replacing it. It's just another, fairly simple way, to organize and share code.
They're easier for non-programmers (I work with a lot of designers) to create and use. In fact, most of the plugins use gems and then add their own config and assets.
Aside from the plugins, the structure of Vesper is just Sinatra, Rack and Rake (/public, /views, config.ru, Gemfile, Rakefile, etc.) plus application and config directories. When the app is run, it does all the normal rackup stuff, and loads everything in /config and /application. There wasn't a need to do anything more.
That's where this whole thing started. I got tired of the routes file in Rails (my biggest Rails complaint), so I switched to Sinatra, and this is how I ended up writing a lot of apps.
Sidenote: /data and /tests are both generated by default plugins.
By unstructured, I just meant the MVC thing. Most frameworks I've used start off with the assumption that I want to use MVC directories. Sometimes I do, sometimes I don't. Most of the time I want to use the concept of models and controllers, but instead of separating them into different directories and files, I want to group related models and controllers together - i.e. a users.rb file with the User class and the associated routes for sign in, profile editing, etc.
The plugins were extracted from code I use in a lot of apps, but not all. That's why a plugin is so similar to a full project, with a few extras thrown in, like hooks (they just run code are certain times during loading). I'm mixed as to polluting the main project with assets, so I just did both. A plugin's /application, gemfile and /tasks don't get moved into the main project. But sometimes it makes sense, such as DataMapper and a /data folder, and MiniTest and a /tests folder. It's really optional.
Now for gems: There's nothing stopping anyone from adding gems to a project. They should work just fine, and I do it all the time. But at the same time, I work with a lot of designers and just-getting-started programmers who have no idea how to write a gem, but still have code they reuse a lot. The 'plugins-as-a-repo-in-a-live-folder' allow for that, while not stopping them from using gems if they fit the bill. A few of the plugins are nothing more than wrappers for gems with a little config pre-written.
I don't think there's anything wrong with Padrino.
I just wanted to use something a little more lightweight and unstructured. Without the plugins, Vesper is basically just a Sinatra app. You can organize it as MVC, or not. There's not much abstraction from adding code to a Sinatra app, and everything glues together nicely. Also, I really like developing plugins this way (put the code from an app into a git repo, and you're done).
I just wanted to use something a little more lightweight and unstructured. Without the plugins, Vesper is basically just a Sinatra app. You can organize it as MVC, or not. There's not much abstraction from adding code to a Sinatra app, and everything glues together nicely. Also, I really like developing plugins this way (put the code from an app into a git repo, and you're done).
After building a lot of apps with Sinatra, I decided to pull out the code I always end up using (the framework) and package up the code I almost as often use (the plugins), then write generators for everything and wrap it up in a gem.
There are still a few plugins I'm writing now (DataMapper REST services, Stripe boilerplate, user accounts, URL based commenting, Linode stack script, etc.), but since the whole project is moving along nicely, even getting a decent amount of downloads, I thought I'd share.
Most of our cities (maybe all?) haven't been planned that way though. They usually start out as a small town, then they get a large influx of people and businesses who all want different things, and the city ends up growing by leaps and bounds with very little planning. Then it happens again and again, in waves of growth. Even if the expansion was somehow planned well, the existing part of the city won't be prepared.
Also, there are plenty of reasons to travel around town that don't involve what you need in your daily life. What about when your friends want to meet at a bar on the other side of town? If that's 5 blocks, no big deal. If that's 15 miles it becomes a problem.
High population density doesn't make public transportation efficient, good planning does. If the public transportation system is designed for a city of 2 million, and the city grows to 7 million, the public transportation system won't be effifcient, or pleasant to use, at all. The unpleasantness and eneffieciency is one of the reasons so many people have cars to begin with. Private transportation takes you where you want to go, when you want to go there, in an environment of your choosing. As is mentioned in other comments here, walking when the weather is bad (cold north, too humid south) is very unpleasant no matter what.