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-Service-tp4665479p4665786.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
--
http://tulipemoutarde.be
+32 65 709 131
