Hi,
sorry for the very delayed answer :)
Some years ago I made a massive ecommerce, it was developed on pharo and
deployed on gemstone.
that works pretty well and you have infinite scaling.
now, you could do the same with pharo + some db backend (I'd recommend mongo) +
a load balancing strategy.
this gives you some advantages (like not needing to deploy in a different
platform) and some disadvantages (like have to doing the balancing stuff by
your self).
but... certainly, nowadays there is nothing that could stop you to use pharo
for your site.
cheers,
Esteban
On Aug 7, 2013, at 1:01 AM, Cameron Sanders <camsand...@aol.com> wrote:
> Are you definitely going the smalltalk path and your question is Which One
> platform? Or are you not yet committed to smalltalk?
>
> If you go with Pharo, you may be able to migrate to something like Gemstone
> should the need arise. Or to one of the other flavors.
> -
>
> I recently interviewed a kid with CompSci degree from a small school here in
> the States. He showed me his Senior Project. And I was nearly floored in
> shock. It was a whole mess of PHP... that did nothing more than present
> three DB tables to the user, which they could edit. In Pharo, using Seaside,
> and working through the tutorial to construct your login system (which was
> one of the tables of this project), and ... and using SQL calls directly (not
> learning Glorp), it would probably just take a few days to do as-you-learn.
> The amount of functional code/behavior seemed really small for a senior
> project... at least when compared to the productivity of Pharo+Seaside.
>
> The moral of this story: if you are considering PHP as your alternative...
> DON'T! Instead work with classes/objects, in an environment that supports OO
> programming. Smalltalk scales really well in terms of programming time -- one
> of the most productive environments you will find.
>
> That said... there are more java programmers than smalltalkers. ... of
> course... you need more java programmers for the same functionality! ;)
> -
>
> How many different dialogs/widgets presented to the User? How many unique
> attributes/fields for user to select? Navigation is standardized? Etc.
> Obviously, sizing a project takes time.
>
> ... In smalltalk, one can often lay out crude class definitions as fast as
> you can type them into a project management system. It was made for rapid
> prototyping, and the ('type') evolution that comes with such development.
> -
>
> I have a project that I would like to scale beyond your specs. But we can
> grow more slowly, giving us time to grapple with questions about DB
> mirroring, and how many Virtual images do we need, and how many Pharo images
> running on each... load balancing, etc. There are several people on this
> board who know more about this than I do. (Several offering consulting
> services too.)
>
> Good luck!
>
> -Cam
>
>
> On Sun, Aug 4, 2013 at 7:25 AM, Stephan Eggermont <step...@stack.nl> wrote:
> Sanjay wrote:
> >Possibly the above details are sketchy but the immediate questions for him
> >to firm up investment plans are:
> >- Will a Pharo based platform be appropriate
> > -- Technology ?
> > -- Robustness & support ?
>
> Nothing you indicated in your estimates would be a bad fit for Pharo.
> Strong points for Pharo in a startup context are flexibility and very
> fast development.
> Not being 64-bit is a weak point, but you might be able to come up
> with a shared nothing architecture and lots of images running part
> of the problem.
>
> Do a spike integrating and deploying the technologies you need,
> and make sure you can do that again after each commit.
>
> >- what will be the team man year effort (ballpark estimate) for development,
> >testing, administration upto initial go-live ?
>
> 1, 10 or 10000. Portal is a semantics-free marketing term.
> Estimation at this level of fuzziness is a meaningless activity.
> What do you plan to have online at the end of the first week, the
> first month and the first quarter (at less and less detailed level)?
> Do you already have these users, or do you need to grow the number
> from zero?
>
> Create a story map and slice it.
> http://www.agileproductdesign.com/blog/the_new_backlog.html
>
> Stephan
>
>
