Category Archives: njug

Do you have real life struggles in SW development? Lessons learned in Ops? Come share them @NashvilleJUG

Ever battle a NoSQL data store for six hours straight? Installed an upgrade that destroyed a database? Have you spent two weeks learning a new library, language, or build tool, only to chuck it out the window? We’d love to hear about it at the Nashville Java Users Group.

We meet on the first Tuesday of every month in downtown Nashville. Beer and pizza are provided gratis.

We’re looking for people just like you, willing to share their most tragic or most exciting tale. Can you chat for 20 minutes? That’s all we ask.

Whether it’s a tale about beating your brains out over a Maven plugin or kicking a Redis server into oblivion, we’re excited to hear about it! Whether you scrapped some infernal JavaScript library, or just finished a new book that has changed your development perspective forever, let us know.

And you’ll find a bunch of others nodding along, saying “I know what you mean!” The Java community in Nashville is strong. We founded the group back in 2010, and have been growing every since. But we can’t operate without guests coming in, and pouring out their heart and experiences. We need you!

How to reach us:

When testing really matters

This past Tuesday, we had James Ward, principal developer advocate for Heroku, give a presentation on the Play Framework, scala/java, and Heroku at the Nashville JUG. Suffice it to say, it was a really awesome presentation. This was far from a sales pitch, and more like a lets-get-our-hands on this framework and build a web app as fast as possible.

Sadly, I had to leave early, but I was hooked on poking my nose into Play. I have been fiddling with a small toy app using Scalatra. It is really nice where you focus on building the routes and then stir in some templates, with a little scala in there to make things nice and succinct. But I had been running into issues repeatedly with the testing. I decided from the get-go, that I would make it a test-driven project, and had built up automated testing quite nicely. I built all the REST points and had everything working with a nice stubbed out data source with future plans to replace it with a NoSQL database.
Scalatra has some nice test structures. You can either use specs or ScalaTest to check everything out. But something that nagged me for some time was how my tests would periodically fail every 3rd or 4th time. Sometimes more often than that. But since they would occasionally pass, I knew that everything worked right. It was probably just some race condition that had to do with the jetty container it used to run the tests.
When I tried to swap out my in-memory maps with MongoDB, I couldn’t get the tests to pass ever. Comment out MongoDB code; tests pass. Bring back ’em on line; fail again. It drove me nuts. I tried lots of things. This was when I saw the Play demo. Seeing that it was heavily route-based, I thought it probably wouldn’t be hard to transfer my existing test suite to a Play app, modify any API calls, and use this set of tests to rebuild the REST points in Play. Well, I was able to do it in just a few hours. And guess what? Now there are no failures…EVER!
Why did Play succeed where Scalatra failed me? I think it’s because Play has different levels of testing. They build in helpers that let you test from any angle, meaning you don’t have to test the runnable container. Instead, they offer a lot of useful angles to isolate and test things out:
  • test individual units
  • test templates
  • test controllers
  • test routes (see
  • test the whole thing with an HTTP server
  • test from a browser with Selenium
All these things give you the option to easily grab your existing test suite no matter how it was structured, carry it over to Play, and rebuild you app back up, one test at a time, until everything passes. Then, with your test harness in place, go back and start refactoring as you see fit!
Right now, the web pages look pretty ugly. They are the basics with no styling at all. There aren’t even links to connect the pages together. That is because I am building this app so that each REST point does what it is supposed to. Then I can start putting a nice look-and-feel on it. I’m already excited because it appears that Play has some helpers to plugin Twitter’s bootstrap HTML/CSS/JavaScript library, something I was planning on when I would get around to the UI.
Given all this, Play has really made it easy to put together a REST-ful web app using Scala, my primary goal. I hope you have similar experiences.

@NashvilleJUG reaches 100 members. Woot!

Back in April, I posted that the Nashville Java Users Group had reached 50 members. Today, we have no reached 100 members signing up on This is incredible!

We are approaching our 2-year anniversary this October (despite what is listed on our meetup site), and it appears one of our founders, Csaba, will have departed Nashville by then. He has received an excellent opportunity in California and we wish him the best. We have had many others step up to assist in leading this group over the past year. We also have speakers booked through November.

These are all signs of a fantastic group. Members may come and go, but we are constantly growing. We average 30+ visitors at each meeting. It doesn’t cost anything to join this group and attend the meetings (something I have insisted on since the beginning). We have strong, technically oriented meetings so our members know that they are aren’t attending a sales pitch. We also see people working with enterprise Java, Android, Windows, Mac, & Linux, and alternative JVM languages like Groovy and Scala. All these things help let people know that the Java community in Nashville is strong and diverse.

When I first moved here in 2010, I wasn’t sure where the Java opportunities were. But now I am highly confident that there are many chances for people to work for good companies and develop with some very talented people. I hope that the others that show up for their monthly Java “fix” have the same sense of excitement as I do. Last week, I was chatting with a co-worker of mine who lives in Atlanta, plotting when he would be able to come up and speak at our JUG. This is truly what community is all about.

Having read some of ‘The Art of Community,” and understanding how valuable a community group is, I am proud to a member of such a valuable group. Here is to two wonderful years of Nashville JUG and eagerly looking forward to the next two. Hear hear!

What is the best testing tool?

Someone posted to me a question through meetupcom, “Greg, what is the best testing tool?” I didn’t have room to reply. I posted my response inside the Nashville JUG Google Group we host, but I thought today, it would be better to capture it here.

Asking “what is the best tool” with no other context sounds like you are looking at the situation from the wrong point of view. Let me explain.

A few years ago, I inherited a java app with hardly any automated tests, had been worked on by 6 engineers before me for a couple of years, had been demoed in front of program management, and was non operational. It did stuff, but not much and was loaded with errors. I adopted an approach where I wouldn’t work on any bug/issue until I could write an automated test to reproduce the issue. This was painful; more than you can realize. The software was tightly coupled, lots of static singletons, i.e. global variables, and hard to isolate. Basically, my first test involved using JUnit to empty some database tables, programmatically ingesting a spreadsheet, and then inspecting the database for results. This test took 5 minutes to run. It probably ran through a big chunk of code.

The problem was the system, and no magic test tool was the answer. Changes in the beginning were slow, but as I gained momentum, I eventually reached over 60% test coverage. This may sound low, but within 3 months, I made a flawless demo before program management. They were impressed that it worked, let alone with no problems. The tool was starting to get used by the intended audience. A year later, reported bugs were fixed in one day, and never regressed. I reached a point where I worked for a whole day, and when the half the unit tests failed, I threw away all changes and went home for the day, depressed. I started fresh the next day and actually fixed the problem. Two days to fix it! With no automated test suite, that would probably have been released, and incurred a gob of new bugs to deal with.

I met weekly with the users and captured new feature requests, problems, and generally made this tool work really well. The customers were very happy. I was also empowered to rewrite whole sections that were slapped together hastily in the past, because I had the security of my automated test suite. I threw away code that wasn’t used and didn’t work. My boss showed me a chart where the total lines of code became less than when I first inherited, yet it did more than those other 6 people could squeeze out of it. That was a happy day!

What I’m saying is that I could have used JUnit, TestNG, ScalaTest (works on java too), or any other suite of tools like acceptance testing frameworks, load testing, etc. But what test tool was used wasn’t important. Adopting a strategy of making the whole thing subject to testing, staying test focused no matter how painful it is, paid off. At some times, the test suite took 1.5 hours to run. I spent three days speeding up the most expensive parts of the system, and cutting out certain tests, getting the same number of tests to run in 30 minutes. I came up with a comprehensive test suite and a smaller, smoke test that ran much faster. I also created a spreadsheet to track number of tests and total test time, along with a graph. As the test time grew, I would periodically halt development and polish up certain parts that made it too hard to run tests. I would run the test suite at least once a day to make sure things worked right.

This whole development period was some of the best coding I had done in a long time. Cranking out top quality code with a warm fuzzy green bar made me grin ear-to-ear. When I left that company, I cried a bit because I wouldn’t be working on that tool anymore.

In the 9th chapter of my book, Python Testing Cookbook, the first recipe captures a lot of what I wrote up above, with some more detail. To quote the recipe “Something is better than nothing,”

“Just don’t let anyone tell you that you are wasting your time building a long-running test case. An automated test suite that takes an hour to run and is exercised at least once a day probably instills more confidence than clicking through the screens manually. Something is better than nothing.” —Python Testing Cookbook, page 326

When I wrote chapter 9, I wanted to move beyond simple coded recipes, but instead general lessons I had learned in the realm of testing. These principles work, whether you are writing Python, Java, Scala, or anything else.

@NashvilleJUG reaches 50 members!

This is great news. I just saw an email today sent to me from Maybe that number doesn’t seem huge to you, but after just a year-and-a-half, I think we are reaching more and more people in the Java community in our area.

Earlier today, I was on the phone with a recruiter that helped secure me an interview over two years ago with a local company before I even moved to Nashville. She was calling to share a potential opening, but it wasn’t for me. With that aside, she asked how was NJUG going. I was happy to tell her it was growing fast and pointed her to our website. I explained we average 20-30 people every month. She was impressed.

I remember the first meeting back in October 2010. I gave a talk about “7 Reasons to use Spring” and Csaba was my audience. To tell you the truth, this was the way things were for several months. I don’t know whether Csaba had confidence or not (you’ll have to convince him to write a blog!), but I did. I felt like we had to be active and consistent, and that eventually we would draw out participants. How many did I expect? Having been a part of the Melbourne Linux User’s Group, I was used to average attendance numbering in single digits. I figured this group would reach a similar state, and I would have been quite content to see a handful of passionate Java developers once a month. When it’s not 100+, then it’s easy to have 1-on-1 conversations with everyone. I never expected things to grow so quickly as NJUG has. When 35 people show up to see the lead architect from The Lampo Group, it is an incredible feeling. This was even more intense when I had been away for several months due to family issues. Coming back to a group with a packed room was awesome!

As I continued this phone call with my recruiting friend, I mentioned that while we keep the meetings technical, she was free to attend and network as well as post openings on our Google Group. After receiving yet another email from new recruiter through LinkedIn today, I realized that this felt like more than just technical material being shared at monthly meetings. The opportunity to interact and meet other developers as well as recruiters encourages me. I realized that should I need help finding a new position in the future, I have lots of contacts in this area that will help me out. Knowing that my cohorts of NJUG have the same opportunities is also good to know.

It feels like we are building the key component to any technology: the community. In this case, we are building up Nashville’s piece of the Java community, and that makes me very happy as I watch the membership numbers grow thanks to warm, fuzzy emails from meetup. With a slate full of speakers for the next few months, I can’t wait to see ya’ at the next meeting!

Putting your money where your mouth is

I like maven. There, I said it. Now where is my flame suit?

Last night at the Nashville Java User Group meeting, Kerry gave a good introductory presentation on maven. He talked about the pros and cons, and showed some things like phases, profiles, and parent/child projects. For those who had little to no experience with maven, it was a good introduction. Hopefully they will read more.

I jested afterwards that he should write a blog entry to generate traffic for his web site, because a discussion about maven is never luke warm. People come out either strongly for it or against it. I expressed this at last night’s meeting. Well, sitting here this morning and checking twitter, etc., I realized that I would be a bit of hypocrite if I wasn’t willing to put my money where my mouth was and write my own blog entry.

So here we go. I like maven for a handful of reasons:

  • consistent format of project layout
  • transitive dependency management
  • more plugins than I can imagine
  • declarative definition that supports convention over configuration
  • maven’s one-artifact-per-project promotes a better breakout of modules
Does maven have issues? Yes. What build system doesn’t?
Is it state-of-the-art? No. The XML can be wearying.
These seem to be the two key things that cause people to discard it and seek something else. I have seen this first hand. Instead of using maven, someone typically tries to replicate maven’s intentions using other technologies. If you are on a team where someone has built their own build system there is another dependency that can start to get in your way and come incredibly annoying: that person. Any issues with that build system require support of that person because there is not likely to be any documentation. I didn’t like this aspect, and when that person worked in a different time zone than me or was on vacation, it became detrimental to productivity on occasion.
So what about things like gradle? To tell you the truth, I am kind of excited about new technologies like gradle and sbt. They look very appealing, and I really like the idea of using groovy or scala instead of XML. XML is a strain to read, though for some reason, I find myself reading pom.xml files instead of using my IDE’s editor.
I guess being a command line junky, I prefer to work with the real file rather than a massaged presentation. Probably makes me sound like a dedicated emacs user. While I use vi a lot, I also edit a lot of code inside my IDE. Nothing beats the ability to highlight 200 lines inside my IDE and hit the comment key combo. I use both on equal footing, and it makes me feel like I’m versatile. But…I digress.
Back to the topic at hand: what about new build technologies like gradle? I think a critical feature of tools like gradle would be integration with maven. I understand this is in the core of it, so hopefully gradle will expand and become more mainstream. But right now, I haven’t adopted it.
Go and figure out what meets your needs. But take into consideration what happens when you hire more people. Will you be able to point them at standard documentation, or will you have to be on call to answer questions about your build system? It’s up to you. Just be aware that something like 85% of all java projects use maven. (Okay, I don’t remember the actual number, but according to a survey conducted by the Eclipse foundation, it is a HUGE majority like that). It’s one less impedance mismatch to deal with. Be sure to factor that into your TCO (total cost of ownership).
Whatever you choose, happy building!