On Thu, Apr 5, 2012 at 5:25 PM, Ryan Lane rlane32@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