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 <camsanders@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 <stephan@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