Half Use Websphere and No One By Choice

Banks don’t like being dependent on any one particular thing. They like to have a lot of options. Typically, we’ll roll out WebLogic, but we’ll also have JBoss on the side. Who uses Weblogic? IBM Websphere? Anybody use Websphere by choice? No hands at t’all, (Laughter from the audience) I like that one. So for the benefit of the camera half use Websphere and no one uses it by choice.

— John Davies

Talk on ESBs in the Investment Banks

I sense a wave of disillusionment with IBM Websphere that threatens to end their dominance in commercial application servers. Weblogic has always had a it’s share of detractors and quite a few people get annoyed with the marketing politics of JBoss. Still you can easily find lots of developers who would admit to using either one by choice.

With the application server moving towards more of a commodity item easily dominated by open source competitors like JBoss, Glassfish or even a simple Tomcat server can Websphere sustain charging for enterprise software rates for the Webshpere platform? Not really a sustainable model, though they really make their money in professional services so maybe they’re not that concerned.

And John Davies isn’t some Web 2.0 type. He’s worked for over 20 years in ever so Enterprisey investment banking. He is CTO and co-founder of C24.

2nd Annual Silicon Valley Ruby Conference Thoughts

Two days at the San Jose Tech Museum hearing about Ruby rejuvenated the old cranium. Just in time since I had spent the previous day doing about 14 hours of troubleshooting on some Enterprise software.

The conference had somewhere above 100 attendees (I didn’t count). It was all in one big hall on the first floor of the Tech. The chairs, well they were bad and know tables to drop a laptop. Still for about $250 for two days I can’t complain too much about the chairs.

The talks ranged from Ruby testing techniques and libraries to IDEs and even into a good bit of depth on VMs and compilers since there were talks on Rubinius and JRuby. At least 10 people in the room had open positions and if you’re a Ruby developer now there’s little chance you can’t find lots of work in Silicon Valley. A decent portion of the audience even had at least one patent.

As a manager dealing day to day with the Java world I felt in over my head as far as Ruby expertise, and it was great. When I go to more general software conferences or Java talks I often get less out of them because I have a lot of experience. Here I was in the bottom third of the class and it was nice. Everything is still shiny and new.

Since there was only one track you didn’t have to do any deciding and walk out of a session feeling like you made a mistake. Another nice part was most of the presenters were very focused and often finished ahead of there hour or so. Instead of sort of filling the time up they generally gave up the floor for lightning talks or answered questions. The self-organization was evident.

Coming down from Sacramento the drive was reasonable, and I just crashed at a $80 hotel room Saturday and headed home Sunday afternoon. Given a really long week at work I didn’t have as much energy as I usually do for socializing, but I did manage to spend some time talking to Cary Campbell of Codecraft. He was trying to get up to speed on Ruby on Rails since he’d spent a lot of time at IBM, 37 years, and the last 15 with embedded systems. He had a great story about setting up a lot of tests based on specs. It sounded like the tests were all written first and then the software was added until all the tests pass. Sort of big test design up front. They were going to use Rails so management could see web reports. Right now if you’re not starting with any legacy web baggage Rails is a great option.

Josh Susser on Contributing to Rails

Josh Susser gave a pointed talk on how you can contribute to Rails, or really any other open source project for that matter.

Why Contribute?

Maybe there’s the guilt associated with the freeloader effect that drives you to contribute. Guilt is never the strongest motivation though. Better motivations include getting some measure of control over a piece of software. You can fix your own bugs and contribute patches. Finally, the cool reason–cred. With credibility people start listening to you and eventually you get things like book offers and job offers.

Where to Start

  • Start with the Trac site for rails.
  • Follow the rails core discussion list.
  • Documentation is a great place to start.
  • Tests, more tests are always needed.
  • You can write a test around a bug and submit it. Maybe someone else will write the code to fix it.
  • Then you can always write code.

  • New code is glamourous, but not the best starting point.
  • Better to start with bug fixes.
  • Move on to plugins, generators, tasks, etc.
  • Maybe then an enhancement.

The How

Start with setting up a rails development environment. Then pull down rails from the trunk:

$ svn co "http://svn.rubyonrails.org/rails/trunk" rails

Next setup the test database for ActiveRecord and possibly others and read RUNNING_UNIT_TESTS. Run tests before any changes. Then run tests after every change. Start writing tests first. The tests in rails could do with a lot of refactoring, and Josh mentioned there was a good opportunity for contribution there. Remember to follow the Rails style guidelines. Then document what you do with RDoc and inline comments. Again, tests must pass and docs must build.

The Patch

  • Generate the patch file
$ svn diff > well_named_patch.diff
  • Look at the diff file in TextMate or some IDE. There should probably be a lot more test code and documentation then actual application code in the diff file.
  • Open a ticket on the trac site.
  • Start the summary with [PATCH].
  • Upload the diff file, don’t paste it.
  • Describe problem and solution, show usage.
  • Use Keywords: doc, test, tiny

  • doc – patches that are just documentation
  • test – patches that are just test
  • tiny – small changes, probably only one file

  • Then practice being patient.
  • Lots of patches are sitting in Rails Trac for a long time.
  • Smaller changes are easier to get accepted.
  • Use tiny keyword.
  • If you have a big patch, discuss on rails-core list first. Try out patch as plug-n it makes it easy to check the stability.

Other Things You Can Do

  • Room for lots of different types of contributions. Can do some grooming on the wiki.
  • Respond to updates to your ticket.
  • Check the rails irc channel at #rubyonrails at irc.freenode.net
  • Keep a blog. Everyone who contributes has a blog of some sort.
  • Look at open bugs if you don’t have anything you want to change in rails right now.

The talk finished up with some questions. One attendee mentioned that in their shop they have new developers just cruise through rails and contribute patches for the first month or two before they really put them on projects, so they can get really familiar with rails and help out at the same time. And Josh explained that PDI (Please Do Investigate) is not a brush off from the core team. Instead it’s a small compliment that someone thinks it’s interesting, and please go make it happen.

Twitter is UDP

Someone asked me if Twitter was TCP or UDP. UDP, it’s definately UDP. I can’t talk about the numbers, but UDP.

– Blaine Cook

Scaling Twitter talk at 2nd Annual Silicon Valley Ruby Conference

Blaine talked about dealing with traffic on the busiest Rails based site. His comment was related to their use of DRB and Rinda, a distributed object system for ruby, basically RMI. Apparently Twitter has been getting so much traffic at times that there’s no way it’s going to catch up, so the solution was to just drop the queue when it got too big since it wasn’t going to catch up anyway. A purely pragmatic approach for a very popular site experiencing growing pains.

(The conference was pretty great and I’ll probably be culling posts from my notes for the next week or so. The slides from Blaine Cook’s talk can be found on Slideshare.)

Full Stack Web App Testing with Selenium and Rails

Alex Chafee and Brian Takita of Pivotal Labs mix regular rails tests including fixtures with Selenium tests for a full stack test in one. They kicked off the 2nd Annual Silicon Valley Ruby Conference in style with a focus on testing. Few thought it odd to be talking about testing early in the morning. Rails of course bakes testing in and you almost have to work to avoid it. Selenium isn’t drop dead obvious though especially since you can so easily test a lot of the web tier through functional and integration tests in rails controllers. When Alex Chafee asked for a show of hands a good number of the 100 or so attendees had used it, but very few were using it at work.

The approach is pretty simple:

  • You need to test your view layer partially because of all the AJAX going on their and partially because it doesn’t really work unless it works in an end users version of IE.
  • Since you have access to rails and you can write the Selenium tests in Ruby, just go ahead and mix the two.
  • You can use fixtures for Selenium tests.
  • You can almost produce a DSL with the Selium tests for the customer.
  • Since many of the tests will take a while you should hook them up to your continuous build boxes. (They run Mac minis with Parallels and Windows and Linux installed so they can test three platforms at once.)

They had some lessons learned to pass on:

  • It helps to check the page title on every page to ensure you’re actually navigating somewhere.
  • To handle AJAX you probably need to resort to polling. They use a default timeout of 20 seconds.
  • Remember to refactor out common code to create sort of a DSL.
  • Tests are more legible if you use literal strings for many of the parameters.
  • Long test methods are good in Selenium because you want to touch large swaths of the code.
  • Rarely use Selenium IDE for doing any recording.
  • You probably need to disable transactional fixtures for Selenium tests.

And finally they should have some rake integration code around this available soon as open source.