because it is not transferable genetically
on
Let the Games Be Doped
·
· Score: 5, Interesting
Children of doping athletes have a higher incidence of deformity:
http://www.smh.com.au/news/world/children-of-doping-athletes-deformed/2007/10/31/1193618974100.html
The point of the olympics includes an ideal of finding out our limits, and improving them.
The problem with doping is the same one with modern news: it favors the individual instance instead of favoring the system. It is not sustainable, nor durable over the long haul... and by long haul I mean multi-generational.
We started in plone, spent about $30,000 dollars on initial prototyping but found some problems and then rewrote in ruby on rails; redoing the same work for about $10,000 and being more complete. Granted our needs were not for the full plone capabilities, and granted some of the initial research we did in plone did rollover to the RoR version but the fact is nobody uses the full capabilities of plone and most of the features that one really needs can be easily written as small modules in say drupal or ruby on rails.
I did have several specific criticisms of plone:
Most seriously the database is too closely coupled to plone and doesn't support the kinds of independent access, orthogonality, scaleability, standard query language and many of the kinds of characteristics that we were used to with ordinary rdbms such as postgresql. It was exceedingly unclear as to how we would do replication and scaling with plones database model and this created fear for us. Granted there is apparently an ordinary sql database binding for plone but we want to have simple table structures; not some bizarre plone ODBMS mapping to an RDBMS.
Secondly the templating grammer was hermetic, poorly documented and required a priesthood of plone experts to maintain - we wanted to also help participate in defining templates and the like and not always have to have the plone experts mediate our changes.
Beyond this the python notation is terrible; verbose, clumsy, the white-space requirements are completely ridiculous and impositional. Basically it is an obsolete language.
The state of tools and libraries for Python is also unclear; is twisted-python the state of the art? What are the right choices for socket handling and the like? At least with newer grammars the field has not been polluted by many half-baked solutions.
The larger problem with plone is that it reinvents everything into python rather than being centered around a small pieces loosely joined philosophy. This is not dissimilar from Java and is a trademark of smart isolated people. This makes the learning curve too steep, makes the technology too fragile, and makes us all too dependent on experts who hold the secret lore.
We were much happier rolling our own even with having to do work that is normally already provided (such as user account handling); not because we got the work done any faster per se but because we could open up the work to more participants and could separate roles between participants more easily. The ruby and php and like model of just being lightweight scripting languages, acting as a glue binding the database to the layout is much easier to deal with conceptually.
I see plone as a pathologically bad choice; like RDF it is grasped at when somebody has unclear goals, and wants to avoid nailing down their specification. In reality most projects consist of only a few specific modules of functionality and those modules can be written by hand or scraped together from other existing modules or source code on the net. This is not to say that Ruby on Rails doesn't have serious problems as well, or that the infinity of php based frameworks and cms'es don't have serious problems, but Plone was particularily hermetic, clumsy and obsolete. I raise it as a red flag in my advisory roles when I see teams suggest it now.
historically games were often developed in environments of intense pressure
if a game development effort is not at gold master by say september 15 then it would not make christmas and if it failed to make christmas then it would lose 70% percent of its revenue
many smaller development houses were created or broken by a single game that simply shipped or failed to ship on time. discovery wrote arkanoid and built their subsequent business around the revenue from that one title.
the way i recall developers working therefore was many small short sprints with multiple people often huddling around one screen, visually auditing the code as one person typed it and acting as feedback and expertise. managers and executive watching everything intensely closely and demanding frequent milestones. these were extremely high stakes development efforts and everybody knew it.
unit testing and regression testing and the like was not done, but there were monkeys in the back that tested the builds all day long and provided a constant stream of test report data; and of course the app developer was often a subscriber to the experience as well and often there would be late night play sessions against the latest build - simply for fun.
Slashdot Mirror
Children of doping athletes have a higher incidence of deformity: http://www.smh.com.au/news/world/children-of-doping-athletes-deformed/2007/10/31/1193618974100.html The point of the olympics includes an ideal of finding out our limits, and improving them. The problem with doping is the same one with modern news: it favors the individual instance instead of favoring the system. It is not sustainable, nor durable over the long haul... and by long haul I mean multi-generational.
We started in plone, spent about $30,000 dollars on initial prototyping but found some problems and then rewrote in ruby on rails; redoing the same work for about $10,000 and being more complete. Granted our needs were not for the full plone capabilities, and granted some of the initial research we did in plone did rollover to the RoR version but the fact is nobody uses the full capabilities of plone and most of the features that one really needs can be easily written as small modules in say drupal or ruby on rails. I did have several specific criticisms of plone: Most seriously the database is too closely coupled to plone and doesn't support the kinds of independent access, orthogonality, scaleability, standard query language and many of the kinds of characteristics that we were used to with ordinary rdbms such as postgresql. It was exceedingly unclear as to how we would do replication and scaling with plones database model and this created fear for us. Granted there is apparently an ordinary sql database binding for plone but we want to have simple table structures; not some bizarre plone ODBMS mapping to an RDBMS. Secondly the templating grammer was hermetic, poorly documented and required a priesthood of plone experts to maintain - we wanted to also help participate in defining templates and the like and not always have to have the plone experts mediate our changes. Beyond this the python notation is terrible; verbose, clumsy, the white-space requirements are completely ridiculous and impositional. Basically it is an obsolete language. The state of tools and libraries for Python is also unclear; is twisted-python the state of the art? What are the right choices for socket handling and the like? At least with newer grammars the field has not been polluted by many half-baked solutions. The larger problem with plone is that it reinvents everything into python rather than being centered around a small pieces loosely joined philosophy. This is not dissimilar from Java and is a trademark of smart isolated people. This makes the learning curve too steep, makes the technology too fragile, and makes us all too dependent on experts who hold the secret lore. We were much happier rolling our own even with having to do work that is normally already provided (such as user account handling); not because we got the work done any faster per se but because we could open up the work to more participants and could separate roles between participants more easily. The ruby and php and like model of just being lightweight scripting languages, acting as a glue binding the database to the layout is much easier to deal with conceptually. I see plone as a pathologically bad choice; like RDF it is grasped at when somebody has unclear goals, and wants to avoid nailing down their specification. In reality most projects consist of only a few specific modules of functionality and those modules can be written by hand or scraped together from other existing modules or source code on the net. This is not to say that Ruby on Rails doesn't have serious problems as well, or that the infinity of php based frameworks and cms'es don't have serious problems, but Plone was particularily hermetic, clumsy and obsolete. I raise it as a red flag in my advisory roles when I see teams suggest it now.
historically games were often developed in environments of intense pressure
if a game development effort is not at gold master by say september 15 then it would not make christmas and if it failed to make christmas then it would lose 70% percent of its revenue
many smaller development houses were created or broken by a single game that simply shipped or failed to ship on time. discovery wrote arkanoid and built their subsequent business around the revenue from that one title.
the way i recall developers working therefore was many small short sprints with multiple people often huddling around one screen, visually auditing the code as one person typed it and acting as feedback and expertise. managers and executive watching everything intensely closely and demanding frequent milestones. these were extremely high stakes development efforts and everybody knew it.
unit testing and regression testing and the like was not done, but there were monkeys in the back that tested the builds all day long and provided a constant stream of test report data; and of course the app developer was often a subscriber to the experience as well and often there would be late night play sessions against the latest build - simply for fun.
- a
There were some rough spots in initial releases. The process is far more automated at this point. - a