brew was a big step forward. But 1 step (download postgres.app) is better than 3 (install devtools, install brew, brew install postgres).
We saw that many developers were using SQLite (or MySQL) on their local machines, but Postgres on Heroku. This led to frustrating and hard to diagnose bugs and behaviors in their apps. Our hypothesis is that easier local install will lead to more widespread usage for the technology.
This will definitely lead to more people using Postgres on their OS X setups, but what I wonder is whether it will lead to an overall better quality of development.
Let me try to articulate my point, but I could probably use some help:
I suspect that the sort of developers who were writing apps and using SQLite locally but deploying with Postgres were the sort of developers whom will still use shaky and poor development and deployment practices regardless of whether or not Postgres is available to them locally.
Orthogonally, I think that the kinds of developers who will actually take the time to follow best development and deployment practices probably wouldn't want to use an app like this - not because it isn't a nice and helpful app, but because they probably want to install the full always-on server bundle via 'brew'.
That's my guess anyway. Does this mean the app was a bad idea? No, definitely not. But I don't personally expect a huge uptick in Heroku deployment quality because of it. At least it definitely won't be for lack of trying!
I routinely use SQLite for development and deploy against PostgreSQL and MySQL (and others) and I don't think my development and deployment practices are either shaky or poor. I write tests, measure coverage, do continuous testing (including load testing and resource consumption goals) and the fancy technologies that allow me to target different databases with the same source code are nothing new: SQL and an ORM. I consider the fact the code isn't very tied to a given database implementation is a sign of high quality, not the other way around.
No doubt this app will appeal to the more casual developers. When the low-end of Dell is a 4-core x86-64 with more memory than most people will ever need, most non-casual developers who need to write code specific to a given database will have it starting up on boot.
Agreed. The pay off seems rather incremental but the playoffs are nuanced. A developer doesn't have to install it manually, and this is big for junior developers who may not have set up a sophisticated environment before. It also cuts down on set up time for new machines and new hires. Any bogus environmental issues go away and could regain 3-4 hours on day 1 getting into a new app.
Postgres performs and behaves differently too. Developers will be more conscious of vacuuming and analyzing their DBS, especially after large deletes, etc.
Overall it removes friction, regardless of how trivial, and helps commoditize the whole development and deployment cycle which is essentially herokus entire value proposition.
this is big for junior developers who may not have set up a sophisticated environment before. It also cuts down on set up time for new machines and new hires
This. I'm just getting started playing with Heroku as a hobby. I've not used Postgres before, so getting things set up correctly on my dev machine was not a "install one app, go" kind of experience. I spent at least an hour reading / trying / understanding. Having something like this would have meant 1 more hour of making, rather than trying to get Postgres setup.
For hobby (or any) projects, 1 extra hour doing what I want to do is a big deal. I'm only able to spend about 5 hours per week on my hobby, getting 20% of my time last week back would have been a big deal to me.
We saw that many developers were using SQLite (or MySQL) on their local machines, but Postgres on Heroku. This led to frustrating and hard to diagnose bugs and behaviors in their apps. Our hypothesis is that easier local install will lead to more widespread usage for the technology.