Yep, same here. I still use Rails for almost all my client work. Not because of the language/framework but because of a common full stack and easy deployment options (handling attachment is a breeze, deploying is ridiculous). I'm not sure those benefits still stand for big apps you develop in house but for small-medium client work they are crucial. Saying that, most the tools should be portable to Pharo/Seaside quite easily. For example: Error handling: https://github.com/errbit/errbit http://airbrakeapp.com/pages/home Stats and log aggregator: https://github.com/etsy/statsd http://graphite.wikidot.com/screen-shots It's hard to evaluate the market size for a Pharo/Seaside PaaS. Who would pay for it? How much? Do you mind paying 10~20â¬/month per app for a small instance? On 28/01/13 10:32, Nick Smith wrote:
This is very timely. For last three years I have been trying to get my Rails developer friend (they build fairly large scale educational products) to take a look at Pharo/Seaside/Gemstone... and, funnily enough, the last time we discussed this was 3 days ago over lunch at our local Cafe.
But this time he didn't say anything. He just passed me his iPad and showed me the Heroku app managing live performance and services of their applications, with real time monitoring for any latency or bottlenecks issues. He told me they could not seriously consider moving to another language/framework without the same peace of mind of knowing the back-end was well taken care of, so they could focus on development... and know that scaling their applications was no longer an issue.
It seems that for most enterprises, hosted 'back-end management' is now the single most important factor in the decision making process of what language/framework to go with.
-- View this message in context: http://forum.world.st/Phaas-anyone-interested-in-setting-up-Pharo-as-a-Servi... Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- http://tulipemoutarde.be +32 65 709 131