On Thu, Apr 5, 2012 at 5:25 PM, Ryan Lane <rlane32(a)gmail.com> wrote:
How many languages can we reasonably support?
We're currently using
PHP, Python, Java, OCaml and Javascript (and probably more). Should we
also throw Ruby in here as well? What level of support are the
Selenium tests really going to get if they require developers to use
Ruby?
It might be good to see examples of what MW developers would actually have
to do to implement new Selenium tests once the framework is complete.
There's a login example in the github prototype that's straight forward but
I assume it will get simpler as more is written which can be reused. I
doubt it will require much in terms of actual ruby finesse.
We've already gone down the Ruby road once. I think a lot of the
people involved with that would say it was a bad call,
especially ops.
Ruby at scale can certainly be a lulz engine, especially for those on the
sidelines. This project doesn't seem to place any software demands on the
production cluster, or even necessarily require anything from ops though.
I assume the road you refer to was the mobile gateway; I consider that to
have been a train wreck primarily from a project standpoint as opposed to a
technical one. When I stumbled upon it, there wasn't an employee with the
combination of access and knowledge required to commit code changes to its
read-only-to-us repo, and to deploy those changes. We were essentially
passing bits of duct tape back and forth by transatlantic carrier pigeon.
For a slew of reasons, it makes much more sense to do what we're doing now
with MobileFrontend, but we've yet to reach the point where it does
anything the ruby gateway couldn't have done with a bit of iteration. In
its last incarnation, it was typically faster than the current
MobileFrontend for a request not served by the frontend caching layer. The
point being, I don't think language was the main issue there.
Chris makes a compelling argument that his preferred route is closer to
being off the shelf and widely supported by industry and community. I have
no comment on what QA engineers prefer to hack on, but I think the ease of
hiring new ones who are good at what they do and excited about the tools
they get to use should be part of the decision.
-A