June 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Object >> #is:

by StÃ©phane Ducasse

the isBlah is not optimal now it is just there and we cannot rewrite everything. I still think that is: is a nice way to kill some of the isPlague in Object. Stef >> But I hate more isPlague in Object. > > I think that plage mostly arises when people do not like to use Visitors / DoubleDispatch. > > Conceptually the #is: message IS exactly the same, instead of doing a dynamic dispatch > you write procedural code with if checks, no?

June 24, 2013

Re: [Pharo-dev] Object >> #is:

by Camillo Bruni

On 2013-06-24, at 18:41, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > But I hate more isPlague in Object. I think that plage mostly arises when people do not like to use Visitors / DoubleDispatch. Conceptually the #is: message IS exactly the same, instead of doing a dynamic dispatch you write procedural code with if checks, no?

June 24, 2013

Re: [Pharo-dev] Object >> #is:

by StÃ©phane Ducasse

But I hate more isPlague in Object. Stef On Jun 24, 2013, at 12:55 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > I never liked it, so I vote for removal :) > > On Jun 24, 2013, at 11:27 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On Jun 23, 2013, at 10:08 PM, Tudor Girba wrote: >> >>> Just remove it :) >>> >>> Doru >> >> Alternatively, start using it, and remove the rest of the is* methods on Object, which was the initial intent :P >> >> Of course, there's a tradeoff between locality of implementation and discoverability with (default) tools here, in that you get less implementors, and Object is cleaner, but at the cost that finding the actual meaning of is: in use in a specific piece of code outside of a debugger *can* be a painâ¦ >> >> In my mind, what's currently in use is the better tradeoff for day-to-day programming and maintenance . >> >> Extensions that don't require contrived protocol names for tool support would be a neat thing :) >> >> Cheers, >> Henry > >

June 24, 2013

Re: [Pharo-dev] Cloud Hosting why/when?

by James Foster

Do Amazon's data centers outside the US qualify for EU usage? On Jun 24, 2013, at 7:36 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Another issue is, at least in the EU, the Data Protection Directive. > AFAIK no cloud provider from the US or with US ownership can > currently comply with that. > > Stephan > >

June 24, 2013

Re: [Pharo-dev] Cloud Hosting why/when?

by Sven Van Caekenberghe

Hi Steven, Thanks for the insights, very interesting. It is good to know that people with your profile are on this mailing list. What is your take on persistency and virtual hardware ? The performance difference between say Postgresql running on real hardware vs on ec2+ebs is challenging to say the least. Sven On 24 Jun 2013, at 16:56, Steven Baker <steven(a)stevenrbaker.com> wrote: > I've had quite a lot of experience helping teams who use both cloud-based and physical-server hosting. > > The promise of the cloud is that you can start/stop servers to meet dynamic demand. In the simple case, run ten servers during the day in your timezone, and only one at night to keep the lights on. In a slightly more complicated case, have some software tools (that you probably have to write yourself) that spin up and add new servers to the pool when server load reaches a certain threshold. In the usual case, spin up new servers to do computationally intensive background workers. > > Since you typically pay for cloud services by the running hour, very careful management of this can lead to lower costs. In theory. > > In practice, people don't really do this. They spin up some servers, deploy their stuff. When they need more, they spin up some more, and never really manage growth or two to manage expenses. In fact, because it's *so* easy to spin up a new server, folks will often end up with far more than they need very quickly. > > My experience has been that the average non-profitable startup will spend between $10,000 and $30,000 per month on their cloud hosting. For hosting that can be adequately served by two $2500 servers for $250/mo in co-location fees. I have literally gone to clients, moved them off of cloud provider to real hardware for significant and nearly immediate gains. One month of their hosting fees can typically pay for my time (and I'm not cheap), the new hardware, and a year of co-location fees. > > There are rare cases when this is reasonable. Also, since I'm in Canada, companies typically can't store their data in the US because of the Patriot Act, and that makes Rackspace Cloud one of the few options we have. Finally, you can install VMware's vCloud Director (or similar; they have many products) on your own hardware and have "the cloud" on your own hardware. It's amazing. > > That said, there are some good reasons to us cloud-based services: hardware management, backups, security. > > - Hardware management is the most obvious. When you use a product like Rackspace Cloud, you don't ever have to think about disks, servers, locations, network configurations, etc. When you want more power, you click a button. Someone else manages all of that. When there's a bad disk, you don't notice, because it's someone else's job to swap out the bad one and make sure that everything was redundant. > > - Backup and reliability are a really important feature that cloud providers offer. All will offer redundant disks and the like, but most go further than that. Most cloud providers have multiple datacentres and can spread out your servers, or move your data between them quickly. In Canada, we have one cloud provider who will transparently fail over your stuff from Vancouver to Toronto and vice versa. > > - Security is probably the most often overlooked point. Most cloud providers will manage firewalls, and do the "infrastructure bits" of PCI compliance and related things which significantly reduces the work you have to do yourself. > > In the end, it depends on the business. My experience is that it's foolish to use cloud providers for anything more than small VPSes without taking a hard look at the costs. Most businesses will have someone on staff who can manage the building and deployment of these servers, and well managed servers don't need babysitters anyhow. Plus, as software developers, we'll automate everything (they call that Devops now) and make it even easier. > > I have recommended two past clients switch to the cloud. They had a rack full of aging servers, and were paying a staff of four system administrators ~ USD$80k/yr to manage those. Moving to the cloud was cheaper for them in both the short and long term. But it's rare. > > Finally, when your stack is "simple Rails app running on MySQL", which is a completely boneheaded stack in the first place, it's *easy* to scale and can be done nearly transparently. Plus, do you really want the Rails kids touching infrastructure bits? Some things are best left to the experts, and using a cloud provider makes that easy even if it is more expensive. > > Cheers! > > -Steven > > > > > On 2013-06-21, at 8:29 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> When I see the enthousiast reactions to the cloud hosting tip, >> I often wonder why? What do you see as the advantages, >> and where does it provide a good fit? I can understand the >> 5 euro/month vps for a single instance case. >> >> As soon as I need redundancy, monitoring and scaling, >> I still need to understand so much of the underlying infrastructure >> that the step to DevOps seems awfully small. Neiher Heroku, >> nor AWS make scaling transparent, AFAIK. That is to say, they'll >> start up new instances just fine. That only helps when processing >> is the problem, not internal bandwidth. And solving the wrong >> problem only leads to high costs. >> >> The cost figures I've seen published on the web suggest that most >> larger scale usage would be better of with at least their regular demand >> covered by dedicated servers. I know hosting in the US is much more >> expensive than in Europe. Digitalocean at least seems to give more >> reasonable price/performance. AWS vs Hetzner seems uncomparable >> >> Your thoughts? >> >> Stephan >> >> >> > >

June 24, 2013

Re: [Pharo-dev] Cloud Hosting why/when?

by Sabine KnÃ¶fel

Amazon has a datacenter in ireland. Sabine Am 24.06.2013 16:36 schrieb "Stephan Eggermont" <stephan(a)stack.nl>: > Another issue is, at least in the EU, the Data Protection Directive. > AFAIK no cloud provider from the US or with US ownership can > currently comply with that. > > Stephan > >

June 24, 2013

Re: [Pharo-dev] Cloud Hosting why/when?

by Steven Baker

I've had quite a lot of experience helping teams who use both cloud-based and physical-server hosting. The promise of the cloud is that you can start/stop servers to meet dynamic demand. In the simple case, run ten servers during the day in your timezone, and only one at night to keep the lights on. In a slightly more complicated case, have some software tools (that you probably have to write yourself) that spin up and add new servers to the pool when server load reaches a certain threshold. In the usual case, spin up new servers to do computationally intensive background workers. Since you typically pay for cloud services by the running hour, very careful management of this can lead to lower costs. In theory. In practice, people don't really do this. They spin up some servers, deploy their stuff. When they need more, they spin up some more, and never really manage growth or two to manage expenses. In fact, because it's *so* easy to spin up a new server, folks will often end up with far more than they need very quickly. My experience has been that the average non-profitable startup will spend between $10,000 and $30,000 per month on their cloud hosting. For hosting that can be adequately served by two $2500 servers for $250/mo in co-location fees. I have literally gone to clients, moved them off of cloud provider to real hardware for significant and nearly immediate gains. One month of their hosting fees can typically pay for my time (and I'm not cheap), the new hardware, and a year of co-location fees. There are rare cases when this is reasonable. Also, since I'm in Canada, companies typically can't store their data in the US because of the Patriot Act, and that makes Rackspace Cloud one of the few options we have. Finally, you can install VMware's vCloud Director (or similar; they have many products) on your own hardware and have "the cloud" on your own hardware. It's amazing. That said, there are some good reasons to us cloud-based services: hardware management, backups, security. - Hardware management is the most obvious. When you use a product like Rackspace Cloud, you don't ever have to think about disks, servers, locations, network configurations, etc. When you want more power, you click a button. Someone else manages all of that. When there's a bad disk, you don't notice, because it's someone else's job to swap out the bad one and make sure that everything was redundant. - Backup and reliability are a really important feature that cloud providers offer. All will offer redundant disks and the like, but most go further than that. Most cloud providers have multiple datacentres and can spread out your servers, or move your data between them quickly. In Canada, we have one cloud provider who will transparently fail over your stuff from Vancouver to Toronto and vice versa. - Security is probably the most often overlooked point. Most cloud providers will manage firewalls, and do the "infrastructure bits" of PCI compliance and related things which significantly reduces the work you have to do yourself. In the end, it depends on the business. My experience is that it's foolish to use cloud providers for anything more than small VPSes without taking a hard look at the costs. Most businesses will have someone on staff who can manage the building and deployment of these servers, and well managed servers don't need babysitters anyhow. Plus, as software developers, we'll automate everything (they call that Devops now) and make it even easier. I have recommended two past clients switch to the cloud. They had a rack full of aging servers, and were paying a staff of four system administrators ~ USD$80k/yr to manage those. Moving to the cloud was cheaper for them in both the short and long term. But it's rare. Finally, when your stack is "simple Rails app running on MySQL", which is a completely boneheaded stack in the first place, it's *easy* to scale and can be done nearly transparently. Plus, do you really want the Rails kids touching infrastructure bits? Some things are best left to the experts, and using a cloud provider makes that easy even if it is more expensive. Cheers! -Steven On 2013-06-21, at 8:29 AM, Stephan Eggermont <stephan(a)stack.nl> wrote: > When I see the enthousiast reactions to the cloud hosting tip, > I often wonder why? What do you see as the advantages, > and where does it provide a good fit? I can understand the > 5 euro/month vps for a single instance case. > > As soon as I need redundancy, monitoring and scaling, > I still need to understand so much of the underlying infrastructure > that the step to DevOps seems awfully small. Neiher Heroku, > nor AWS make scaling transparent, AFAIK. That is to say, they'll > start up new instances just fine. That only helps when processing > is the problem, not internal bandwidth. And solving the wrong > problem only leads to high costs. > > The cost figures I've seen published on the web suggest that most > larger scale usage would be better of with at least their regular demand > covered by dedicated servers. I know hosting in the US is much more > expensive than in Europe. Digitalocean at least seems to give more > reasonable price/performance. AWS vs Hetzner seems uncomparable > > Your thoughts? > > Stephan > > >

June 24, 2013

Re: [Pharo-dev] Cloud Hosting why/when?

by Stephan Eggermont

Another issue is, at least in the EU, the Data Protection Directive. AFAIK no cloud provider from the US or with US ownership can currently comply with that. Stephan

June 24, 2013

Re: [Pharo-dev] Request to update Seaside build

by Sven Van Caekenberghe

On 24 Jun 2013, at 16:01, Camillo Bruni <camillobruni(a)gmail.com> wrote: > --groups=Core,Tests,Seaside will do AFAIK :) I don't think so. There is a double dispatch at MetacelloMCVersion>>#load: that works on Collection or String. But in the String case, the string is just wrapped in an Array, with no splitting going on...

June 24, 2013

Re: [Pharo-dev] Request to update Seaside build

by Camillo Bruni

>>> Could you please also do a Zn update and an install of the adaptor ? >>> >>> ./pharo Seaside.image config http://mc.stfx.eu/ZincHTTPComponents/ ConfigurationOfZincHTTPComponents --install=stable >>> >>> ./pharo Seaside.image config http://mc.stfx.eu/ZincHTTPComponents/ ConfigurationOfZincHTTPComponents --install=stable --group=Seaside >> >> both entries? stable and group Seaside separately? > > Yes, because the Seaside group is special: it is a hack as it does not depend on either Zinc or Seaside, both for technical MC reasons, while it actually should; in a way it just loads one package. > > If the config handler could load multiple groups, then the equivalent of > > ConfigurationOfZincHTTPComponents project latestVersion load: #('Core' 'Tests' 'Seaside') --groups=Core,Tests,Seaside will do AFAIK :) > would be fine (tests not really being needed). > > BTW, stable is not needed right, as it is the default ? actually true > Maybe, in the future, we could change ConfigurationCommandLineHandler > > installVersion: aVersionName > | metacelloVersion | > self inform: 'Installing ', self configurationName, ' ', aVersionName. > > metacelloVersion := (self metacelloVersion: aVersionName). > > (self hasOption: 'group') > ifTrue: [ metacelloVersion load: (self optionAt: 'group') ] > ifFalse: [ metacelloVersion load ]. > > Smalltalk snapshot: true andQuit: true. > > with > > installVersion: aVersionName > | metacelloVersion | > self inform: 'Installing ', self configurationName, ' ', aVersionName. > > metacelloVersion := (self metacelloVersion: aVersionName). > > (self hasOption: 'group') > ifTrue: [ metacelloVersion load: ($, split: (self optionAt: 'group')) ] > ifFalse: [ metacelloVersion load ]. > > Smalltalk snapshot: true andQuit: true. > > It is just so hard to testâ¦ Erwan has set up a Metacello test configuration, we will write some functional tests with it an see how it behaves. After that we can write decent tests for the Configuration command line handler...

June 24, 2013