JQuery breakout – the server side java symposium

Jquery – do more with less. The talk is a scenario that helps a developer be more efficient.

Unlike Lasse Koskela, Bear Bibeault doesn’t speak like he writes  A great presentation though.  Bear is dynamic in a different way on a stage than when he’s in writing or even in person outside a formal presentation. Almost like the stage gets him in teaching mode with a large emphasis on keeping people engaged and entertained. And fast moving without being overwhelming.  The content almost gets snuck in without you noticing you are learning, which is awesome!

Covered good practices like unobtrusive JavaScript. Noted similarity to HTML 5 where tags are becoming more document centric.

I really like how all the AJAX code malls to one line of jQuery. And it’s not a contrived example either.  [when i train people on jQuery at work, I show how common idioms we use can be expressed in one line as well]  Noted the JQuery code doesn’t require a global variable to keep track of the request.

Things I learned that I didn’t already know

  • JQuery css 3 style selectors work even if you are using a browser that doesn’t properly support then.
  • You can bind event handlers to elements that don’t exist yet (I’ve used this but never really though about what was going on)
  • How to use Ajax functions beyond the bare minimum, for example specifying the target on the page for the response
  • There is a validation plugin where you can configure your own rules

Other important points that jquery users might not realize

  • Document ready handler executes before window.unload because it doesn’t wait for images to load.   It also lets you run multiple initialization functions in the order defined.

I also liked seeing jquery functions with a dozen lines to see how to do it well and in a readable manner. It requires more thinking in chaining than I’m used to, a good skill to get better at.

I didn’t write about the jQuery syntax parts. For that see the query website (docs.query.com) or read Bear’s book jquery in Action.

Glass fish and JEE 6 keynote at the server side java symposium

Oracle’s first slide is a TEN LINE disclaimer from their legal department.  Which must be standard because nothing was forward looking.

JEE 6

  • Split  sub platforms so less large
  • JEE web profile
  • New: managed beans, bean validation, CDI (dependency injection)
  • ejb 3.1 lite lets you use ejb in a war file
  • Ear files are now for backward compatibility
  • Encouraged use of setting up everything in annotations instead of web.xmk [I think somethings belong eternalized]
  • Putting a web-fragment.xml file inside your meta-inf directory lets jars contribute content to the web.xml
  • Can promote a managed bean to a “real ejb” to take advantage of transactions
  • Showed response builders for web services. Nice concise way if setting status, content type, result, etc.
  • Ejb 3.1 supports singleton and start up beans. Can set scheduled tasks and asynchronous tasks in annotations as well.
  • Going to great lengths to avoid mentioning Spring,  Guice was cited as the comparison/example of dependency injection. Speaking of Spring, this is the first time I’ve seen this much JEE 6 code. It looks a lot like Spring.

Glassfish

  • Web profile ships with REST
  • Glassfish is wonderful because Oracle says so. Not taking further notes on this. Do people really use Glassfish in production?

Test smells breakout at the server side java symposium

While I’ve read about this topic a lot, I wanted to come to do the topic to see how Lasse Koskela presents. [I’ve learned so much from him over the years as a moderator at coderanch ] He speaks in the same voice that he writes – casual and easy to follow. I really liked the format: present an anti-pattern and have the audience brainstorm what is wrong with it/how to improve it.  I also like his speaking style, gets away from the podium, engages with the audience, good pace, etc. And good use of humor to get participation going “I’m from Finland, we’re ok with silence”

“it’s a good thing that tests break,it means they are testing something that changes”. “as long as they don’t break for the wrong reasons”

Assertions

  • Primitive assertions – Custom assertions, assertStringContains
  • Overly broad assertion – like the golden master, but not intentional, dangerous because have to change if any small detail changes, more specific are preferred
  • Irrelevant assertions – assert not null and then assert a property on the non null object – let junit throw the null pointer

Organization

  • Split personality – Tests two things, many ways to see – var reuse, calling method under test twice, a blank line for two blocks of code
  • Split logic – don’t use information from elsewhere, it is a mystery to the reader of the test what is happening
  • Note: sometimes a refactoring makes things worse and you need to go back or explore another solution.  Better to fix the problem with the refactored code because it is likely better than the original.

Transparency – how readable is it

  • Setup sermon – Extract overly long/complex setup methods, revisit design to get file system out of the picture, avoid magic numbers “why four”
  • Use multiple setup methods to make clear what is being setup
  • Big string – building an XML file in java is bad.  Instead of. Putting in external file, could create method that takes parameters and builds the XML file. This helps because can clearly deduce the important info without reading through reams of XML.

Maintainability

  • Absolute file path – Don’t depend on the environment, platform specific makes harder. For files could use a temp directory that you wipe clean. That way there isn’t test residue
  • Also, relying on path messes up paths when checking out from a branch, use relative path instead. Or getResourceAsStream()
  • Pixel perfection – a lot of assertions for each pixel in an image, any small change breaks the test even if not meaningful (like golden master pattern). One approach is to make the burden of maintaining less. Grab good image and compare to new image. Tis makes it obvious that it a golden master and requires visual inspection. Another way is to fix the test to use the proper language in the assertions.  that tests the lines are connected without testing the pixels directly  To implement, write custom matcher to test pixels by relative position.
  • Lasse feels adding assertion messages makes the tests harder to read and doesn’t add clarity.

I like how Lasse showed the benefits of looking at your old code. It shows that you’ve learned a lot since then.

I like that some of the examples were in languages other than java. I also learned a lot!  Sorry Scott: I wanted to be at your session, but this one was awesome!