NFJS Review

I recently had the opportunity to attend a Java Conference, entitled “No Fluff Just Stuff”. This is a conference whose model is to be regional and affordable, which means in theory that more people get the chance to attend. When I mentioned I was interested in attending a Java Conference, my manager suggested NFJS in lieu of some of the more expensive conferences that would have also required air travel. This worked out pretty well, as my employer could afford to send several of us at a time; we could car pool together, and considering Chicago was only a 3 hour drive from Indianapolis the trip was not exhausting. The opportunity to spend some time with a few co-workers outside of work was nice, as it gave me insight and perspective about where they were coming from: their motivations, what excites them, what are they afraid of, what are they frustrated by. You don’t get this information in a hallway discussion at a client site. You surely get a chance to discuss these things trapped in a car for multiple hours, or even over a deep-dish pizza the night before the conference kicks off. (And on that note, if you’re ever in Chicago craving pizza, I highly recommend Giorodono’s Pizza. Great buttery crust, decent sauce, and a cool local atmosphere. But, I digress.)

If you ever get the chance to do a remote conference with co-workers, I’d say go for it. Don’t be afraid about leaving your family or personal life in the lurch. This is for you and your career, and you owe it to yourself to grow professionally. After all, this indirectly benefits your family and/or your personal life. I should mention that I am an expert in rationalization ๐Ÿ™‚ I had to leave my family to go to the conference. I hated to do so, mostly because I was missing my daughter’s first Gymnastics meet, but also because a few of my other young children were sick. Luckily, I’m married to a Super Wife who managed to keep the ship afloat while I was gone. It was tough on everyone. She was exhausted by the end, and she probably wasn’t thrilled with my leaving. She understood, though, ultimately, what it meant to me, and she supported me. Your mileage may vary – everyone has their own lives and challenges at home, each with varying degrees of flexibility – but in the end, you’ll thank yourself for sucking it up and attending. Your career is important, and these chances to grow don’t necessarily come often.

The main benefit to group attendance is the the post-session collaboration you get to experience. You get to bounce ideas off of your coworkers, gleaning the best and most relevant parts of the discussions and applying them to your work problems, and debate them over break-time coffee and snacks. You coincidentally experience the sessions together, and pledge “We are so doing this as soon as we can! Look how cool it is!”. You start fantasizing how you could introduce this tech to your boss and perhaps your clients, and you can imagine the nifty new bullet points you can add in your resume’s tech skills section. Or, most likely your group members will attend separate sessions, and meet up later to relate the high and low points of the speakers and the material covered. This can be invaluable information you can use to choose later sessions – “Don’t go to that guy, he’s not that great” (really only happened once to me at the conference, and it wasn’t necessarily his fault) or “You HAVE to go to the next discussion by this speaker, he really knows his stuff”. You also get to divide and conquer – after all, all of the topics are probably relevant to your career at least tangentially, and the more coverage by your company’s group the better. These discussions with your co-workers can be occur on the spot, or later over a meal, or even hopefully weeks later when you’re co-introducing technology-X to your shared boss.

After attending the conference, I’d say it was a great decision. I left with many ideas swirling around in my head – there were so many new technologies and tools I was exposed to that I never had the chance to see first hand. Sure, I’d heard of languages like Groovy and Scala, and I know people are developing mobile apps using JavaScript, but it was beneficial to see it in action. I am a visual learner, and to see these newish (to me at least) technologies first hand made a larger impact than reading about them online. The people in charge of this particular conference have done it more than a few times by now, and it’s a well-oiled machine. They’ve thought of everything logistically speaking, and their topics were timely and appropriate. The speakers were all very knowledgeable and friendly. NFJS even lends everyone an iPad preloaded with a feature packed conference app. I hope to be able to return in the future. Here are three of my favorite sessions I attended.

Introduction to Android Development, by James Harmon
This was a good intro to the topic. James covered the ecosystem of the mobile space, introduced the IDE and Android SDK, illustrated the creation of a simple app, and touched on deploying apps. I had heard of Android (duh), but never quite realized the challenges of this type of development. Did you know there are over 800 Android devices out there? I knew there were a lot, but that number struck me. Each of those devices have different screen sizes and resolutions. Guess what? Your app, if it’s any good and if it ends up being popularly adopted, will address a large portion of those options. James covered the different ways your app can interact with the mobile device through the Android API. It just made sense that a lot of it – maybe 99% – was actually Java (mostly 1.5 with cherry picked features of 1.6 and 1.7). I could see how easy it would be to take your Java skills in the typical corporate Application space and apply them to a hot, new, SEXY, marketplace. And if you happened to have a decent app idea, hey, you might be able to make a buck or two. You don’t also have to have an Android to develop and test your new mobile App – the tools and IDEs out there help you out with that (Android Studio (beta), or IntellJ Idea w/Android, my personal IDE of choice. James didn’t discuss the latter, but the former is based on the latter.) I was tempted by the thought of picking up a MotoX or perhaps a Galaxy Note, even though I already own a iPhone 5s, if only for testing purposes. Hey, it’s for my career ๐Ÿ™‚

Applying Groovy Closures for Fun and Productivity, by Dr. Venkat Subramaniam
This was a great session led by a very energetic speaker. Dr. Subramaniam spoke very quickly and excitedly, and I had to pay close attention to him and the material or else I might have been left behind. It wasn’t a problem for me for two reasons. One, Venkat (I feel like I know him at this point, so I’ll slip into a more familiar reference) was so HILARIOUS that you couldn’t help but be tickled by his enthusiasm and chuckle at his simple jokes of friends and parties. I was drawn into his fun like a whirlpool of energy, and I was sad to see the session end. Two, the source material was pretty neat, illuminating, and exciting. I’m not quite sure what the practical use of Groovy is yet, but combined with Grails it would seem that you could whip out some applications pretty quickly.

Scala Koans – A New & Fun Way to Learn Scala, by Daniel Hinojosa
Daniel led a fun two-part session that let you learn Scala by doing it yourself. I had been introduced to the language a few years back, but that was via a presentation that was mostly theoretical and not hands on, and I didn’t get much out of it. This session, on the other hand, was very hands on and aptly named, FUN. I got to download a small program on my laptop, fire up a console window, and interactively learn the language. Myself. By doing. Pretty sweet, huh? By saving a simple Scala class file using my favorite IDE (the program also worked fine with Eclipse, but I of course used IntelliJ), the console window would auto detect the change and give instant feedback if my change was correct. The Scala Koans program started small by introducing how a simple boolean unit test case worked. Then I proceeded to progressively harder tests which I had to fix by filling in the blanks in the expression. Each test built ever so slightly on the previous. As I completed each test in a class (one test per method), I was supposed to sit back and reflect on why the test worked. In the early tests, it was obvious. But given that Scala is very concise (or terse as detractors would say), just like any functional language, at times the tests weren’t that clear to me about how or why they were or weren’t working. The meditation portion was important, and reflecting on the tougher methods allowed me to understand them. I really enjoyed the technique, and I look forward to finishing up the Koans program. Daniel mentioned there was several more Koans out there, from Javascript to Ruby to .Net. Here’s a good compiled list of Koans sites, so that you can pick your favorite new language and begin today. Why not?


Posted on November 12, 2013, in Java and tagged , , , , , , . Bookmark the permalink. 1 Comment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: