At Gluon, we are experts in Java SE, Java EE, and JavaFX. This expertise has not only led to the development of the Gluon family of products, but we can also assist you with your project. Today we interview Neil Matatall from Brakeman Pro, who asked us to review his JavaFX application and provide feedback while they were in the early stages of development.
Hi Neil, thank you for chatting to us today. I was hoping you could introduce yourself to the readers?
My name is Neil Matatall and I’m a cofounder of Brakeman Pro. I’ve been doing web application security for almost 10 years now, but writing code is one of my favorite things in life so I like to think of myself more of a developer that knows security than a security person that can code. I’m based in sunny Kailua Kona, Hawaii and work remotely for GitHub as my day job. In the past, I have been heavily involved in the Open Web Application Security Project (OWASP) organization having run a chapter and 4 conferences. Most recently, @appseccali.
You work on a JavaFXbased product called Brakeman Pro. Would you mind explaining to the readers what this product is?
Brakeman Pro is a static analysis security tool for Ruby on Rails applications. It searches for potential security vulnerabilities by scanning the source code of Rails applications. Brakeman Pro provides an interface for reviewing, managing, and reporting on warnings across multiple scans and applications.
The Brakeman Pro product is primarily a desktop application which runs on OS X, Windows, and Linux. A commandline version of the engine is available for integration with continuous integration servers and for licensing by SaaS and other cloud providers. As a desktop application, Brakeman Pro requires no configuration. Just install and run.
Brakeman Pro builds on the success of the open source brakeman project which is authored by another Brakeman Pro cofounder: Justin Collins (@presidentbeef). Everyone at Brakeman Pro is a strong believer in open source and we are committed to ensuring that the open source project does not suffer, but rather benefits from the Brakeman Pro work.
We just saw you announced the release of Brakeman Pro 1.0. Congratulations! You must be very excited! Was it a long development cycle?
Very long. We have been working on this for a little over a year. We all have day jobs that are important to us, so all development time was done during our free time. Being such a small team and having so little spare time, there have been weeks without activity. There were also two weddings and two significant relocations in the process so life really got in the way.
When you were starting out on Brakeman Pro you consulted with Gluon did you find this relationship was beneficial?
Definitely. Our engagement was fairly short, but the results had a meaningful impact. Namely, there were a couple of antipatterns in heavy use at the time of review. Understanding these antipatterns actually opened up a new level of my understanding of the platform. It was also nice to be able to ask questions and work with the team to form that understanding. Another issue that was identified was the overuse of components / using the wrong components for a job. Again, after gaining the understanding of the right way to do things, we noticeably reduced the complexity of our UI which lead to responsiveness gains.
When you came to Gluon for support, one of the interesting aspects of your project that sticks out in our mind was that you were coding your JavaFX using JRuby. As your work progressed how did you find coding JavaFX in JRuby? Would you recommend this approach to others?
Selfishly, I hope this catches on! I’ve been writing mostly ruby for the past 6 years and I’m quite fond of it (on most days). JRuby allows me to write ruby code that executes and interfaces with anything else on the JVM. We are using multiple java libraries in the project, obviously JavaFX is one of them.
I really like being able to tap the JavaFX community for knowledge even though I’m writing code in ruby. More often than not, I can take a look at StackOverflow and apply the information directly into my code. And I do feel that the community/documentation around java projects is much better than the ruby community (don’t hate me!).
Using JRuby with JavaFX is basically made possible by the JRubyFX project. I am incredibly thankful this project exists because I wasn’t really interested in writing Java again. The DSL provided by JRubyFX is great. I don’t know how to describe it, but writing JavaFX code in ruby feels natural and eliminates a large amount of boilerplate code. I just wish there were more JRubyFX resources, maybe I can make a difference here.
The downside of course is that we have introduced multiple layers of complexity into the stack. Is it my bug? A JRubyFX bug? JRuby bug? JavaFX bug? Java bug??? All of these things are possible and investigations can become tiresome and frustrating. Also, we’re having trouble
upgrading to the latest JRuby 9K which means we aren’t able to get the best possible performance out of our app.
Stepping back from JRuby did you find JavaFX to be satisfactory for your work? Were there particular aspects of the library that you enjoyed using, or that you particularly did not enjoy using?
Yes. I’m very happy with the approach we have taken and we’re seeing more and more java make its way into Brakeman Pro. I’ve already said many times that I wouldn’t be surprised if Brakeman Pro became a pure java application.
In the beginning, I had trouble using cell factories and understanding how to bridge the java <> ruby gap with the filter of the JRubyFX wrapper library. As I became more experienced, things felt more natural. With the introduction of lambdas into Java, JavaFX looks more and more like natural ruby! We’ve only run into one issue where the API and implementation provided could not meet our needs. We’ve run into a small handful of performance problems which required some unfortunate optimizations, but we have not definitively determined if this is a JRuby, JRubyFX, JavaFX, or Brakeman Pro problem (see!).
Did you and your team use the Scene Builder tool for designing your user interface, or are you from the ‘code your UI directly’ school of thought?
Yes! Everyone on the team had used Scene Builder at some point, even if they didn’t write corresponding ruby code. I still use it to modify some fairly complex controls. We only have a very small amount of code that builds elements programmatically, so Scene Builder is our primary tool for building the UI. I find myself modifying the XML for trivial changes or complete reorganizations of the UI. Scene Builder fills the gap of everything in between.
Your user interface is heavily styled did you find that JavaFX CSS was able to let you get the visual results you wanted?
Some aspects of working with the CSS were pretty straightforward though, and it was as simple as adding the fx prefix to properties to make something like I expected. It was a little rough, and I wasn’t able to get to exactly what I was going for. The main thing that seems challenging is
that layout, sizes, margins, etc. are handled in FXML in a way that doesn’t easily translate from a knowledge of working with HTML+CSS.
You posted a few blog posts about unit testing JavaFX applications. How did you find this were you able to get satisfactory results? Do you have any advice for the community on JavaFX unit testing best practices?
I come from a web background so I approached the UI testing the same way I would approach browser testing. In browser land we have selenium et al. In JavaFX land we have a few choices (Automaton, Jemmy, TestFX, etc).
We’ve actually had more problems with our CI provider than our automated tests! At first, things were very unstable. Slowly, I had built up a mini framework around Automaton and Tempus Fugit to have a system of waiting for conditions to be true, element scoping, helper methods for common domain problems, retries, and other handy functions. For anyone keeping score, Automaton is written in Groovy so it adds yet another layer of complexity to the problem!
The tests are structured like acceptance tests where each test performs an action that a user would want to do. This gives us fairly good test coverage with a small number of tests. We do use unit tests for specific functionality, but not at the UI element level. In summary, we test our data model, we test how the UI *would* interact with the data model, and then we test the UI actually going through the motions. I think this works out very well. However, I would love to be able to test individual Scenes or elements without the coupling of the rest of the UI but we are not there yet.
Neil, thanks so much for your time. Your points have been very insightful and we are sure the community will appreciate you sharing your pearls of wisdom. Did you have any last words you wanted to pass on to the community?
How cool is it that I’m running a Groovy UI test framework that tests a JRuby application making heavy use of a Java GUI framework that runs inside a docker container and builds/tests in parallel? I love computers.
Thanks Neil, and from all of us at Gluon we wish you all the best for Brakeman Pro 1.0 and many versions to come!