After lunch we had the ‘expert panel discussion’ where the speakers. One of the great quotes was “If you use Eclipse just because it is free we have a name for that… arranged marriage. You can get some things done, but there is no love.”
I then went to “The Busy Developers Guide to Annotations” with Ted Neward who was on the expert group that defined the annotations facility. After a thought experiment that covered how you would mark a class as Serializable in the old Java 1.1 days we moved to a live code example implementing an annotation on a person object.
The annotation example we developed was a validation annotation. The annotation sits in front of the thing that it modifies, just like the public keyword. An annotation adds no code to the method or class it modifies, just data that is accessible via reflection. Anything that you can put annotations on has the AnnotationElement interface, including classes and methods, in the reflection API. I learned that annotations have annotations including @Retention, which specifies how long the annotation should be available, either RUNTIME, SOURCE, or CLASS, and @Target which specifies where the annotation can be used, either methods, fields, classes, constructors and more.
Annotations should never be used to carry configuration information such as filenames or defaults. They cannot be changed at runtime. Annotations are compiled to an interface by the compiler.
A great observation from Ted is that while it is not acceptable to add a keyword to a twelve year old language, it is acceptable to use a existing keyword in a new and confusing context.
For my last session of the weekend I embraced my inner masochist and attended Venkat Subramaniam’s talk on Functional Programming on the Java Virtual Machine. Functional programming is focused on well-behaved functions. Some of the benefits of a functional programming model is working with multi-core machines. When your functions can be passed to functions and functions do not have side effects, you can split those functions across multiple processors without data integrity issues.
An interesting point from Venkat is to initially ignore the syntax of a language and focus on the idiom. Every programming language hurts when you first learn it, but the compiler will catch the syntax errors.
His first example was from erlang, which is a pure functional language but not on the JVM.
main(_) ->
io:format("~p", [double([1,2,3,4,5])).
double(L) -> lists:map(fun(E) -> E * 2 end, L).
This takes the array 1 to 5 and runs the double function, then passes it to io:format to print to the console. The double function runs lists:map to run every element of the array and executes the anonymous function to double the value of each element.
Scala is a functional programming language that runs in the JVM. You can write Java like code in Scala, but you lose the concurrence protection.
val lst = List(1,2,3,4,5) println(lst.map(_ * 2))
This is the same functionally (no pun intended) as the erlang code above.
Its official, my brain hurts.
Tags: annotations, erlang, functional programming, java, nfjs, scala
After lunch I bought a few books and then headed to the ‘mystery panel’ (a typo on the schedule) about Code Metrics with Neal Ford. After a brief tour of tools we started to talk about the meaning of various metrics. First, KLOC or thousands of lines of code is meaningless or worse.
Cyclomatic complexity measures the complexity of a function. The basis of this is metric is pretty simple. Treating the code as a graph G where statements are nodes and paths are edges the metric is V(G) = e - n + 2 where e is the number of edges and n is the number of nodes.
FLOG is a tool for Ruby that assigns a value to each type of action, such as literals, branching, assignment, etc. Add the values of the actions and you get a sense of the complexity of the function. Neal said that you can run FLOG on the codebase of any Ruby project and the file with the highest score is almost guaranteed to be the one with the most bugs.
Next he covered the Chidamber and Kemerer object-oriented metrics. They covered two types; easy but not useful and very useful. The latter category includes the # of methods executed due to the method call, sum of other classes that this class uses, and the sum of how many classes use this class.
A side note, he was using a tool on the Mac called oXygen that provided a fairly sane way to work with XML documents.
jdepend was the next tool he covered, which reports based on packages instead of classes. It calculates the efferent and afferent couplings, just like the C&K OO Metrics but extrapolates instability, abstractness, and distance from the main sequence. Distance from the main sequence states that packages should either be very abstract and highly stable, or highly unstable but very concrete.
All in all a lot of great content, especially on communicating the metrics as a part of developer motivation, etc.
My last official session of the day was titled "The Busy Java Developer’s Guide to Performance and Scalability". Ted Neward is a self-proclaimed language whore, with books on Java, XML, and .NET under his belt.
He had a simple definition of performance and scalability. Performance is how fast the application responds to an end user. Scalability is the number of users you can support.
His steps were pretty straightforward:
The base assumptions to avoid are pretty obvious, but as developers we seem to ignore:
These are all great points to remember are NOT true. If you look at the difference between google.com and amazon.com home pages are a great example of myth one. Amazon seems to think that bandwidth is infinite, where Google understands that it is not!
One of the tools he demonstrated was jConsole, where you can view the memory, CPU and other metrics about your application. This hits on myth six; do not assume you know where your issues are. Measurement is the only meaningful way to evaluate your code.
Another great day, Birds of a Feather sessions next then I am off home.
Tags: code metrics, java, nfjs, performance, scalability
I got in today at 0830 for some breakfast, talked with some coworkers and tablemates, then moved out to the first session.
My first session was once again with Jeff Brown of G2One. He talked about Test Driven Development with Groovy and Grails. TDD is one of those things that I know I should do but don’t discipline myself to do. Groovy does some nice things that I like from Ruby. Duck-typing is great when you are working with tests. You aren’t writing a bunch of interfaces just to make the compiler happy.
Another interesting test piece is the Expando class in GroovyTest. Expand allows you to create a class that pretends to be anything you need such as a file. Therefore you can test object that, for instance, write to the filesystem without actually writing to the filesystem in your unit test.
Interesting clarification was the differences between mocks and stubs. Mocks have strong expectations and stubs have loose expectations. The stubs in GroovyTest are slick. You call new StubFor(class) and get a stub back that you can overload the functionality of, allowing you to change the functionality of a Groovy or Java class for the purpose of your test.
For my second session I had some hard choices to make. I selected Mark Richards talk on Java Persistence over the Powerful Metaprogramming Techniques with Groovy with Jeff Brown, but it was a tough choice. Mark is a Director and Senior Architect at Collaborative Consulting LLC and the Author of Java Transactional Design Strategies.
Mark was a dynamic speaker and really engaged people. His focus was that there will never be a silver bullet for persistence. Each toolset has it’s strong points and weak points. He started talking about the types of Java persistence frameworks, specifically Object-Relational Mapper, SQL Mapper and Standards Based Frameworks.
One of the big differences between an ORM and a SQL Mapper is that where ORM maps objects to tables, a SQL Mapper maps objects to result sets. This has hefty implications if you need to change from MySQL to Oracle. In a ORM the SQL is generated by the API so you don’t need to do anything but change the dialect used by the ORM.
iBatis is a SQL Mapper that keeps the mapping of statements, result sets and such in XML. Since the SQL is not generated automatically you have the chance to tune your queries.
He tangented off to a couple of things. One was the Triangle of Knowledge. The first area is what you know, the second area is that which you don’t know, and lastly is the things that you don’t know that you don’t know. This is important in learning anything new, you can focus on the things that you NEED to know, as opposed to know that you don’t know and therefore can look up. I like to think of this as Just In Time knowledge.
The big finale was talking about the impedance mismatch between reporting queries and ORMs. An ORM is great when you need CRUD operations, but the moment you need to run a complex reporting type query there is no longer a table to map to and no key to get the data from the cache. iBatis makes things easier in that case, but CRUD is a pain. The end result is to combine ORM and SQL mapping frameworks. One limitation, however is that you cannot combine iBatis and Hibernate in the same transactional unit of work. Therefore it works when you have a project with separate CRUD and reporting areas of function.
My brain is a bit full, so I am glad that lunch is next!
BTW: Acronym of the day: RDD — Resume Driven Development. i.e. when someone makes choices based on what technology they want on their resume instead of the requirements of the project.
It has been an interesting day. I talked my boss into letting me use my annual ‘tuition’ reimbursement to attend the Pacific Northwest Software Symposium put on my No Fluff Just Stuff in Redmond. The conference is different in that they cover hard core topics with no marketing spin. They do not have an expo hall, just breakout room with speakers that know their stuff.
I arrived at the Redmond Town Center Marriott at noon and checked in. Some of my coworkers, developers for whom this was training, were already there and we talked for a bit. The event started at 1300 with a short introduction session and then it was off to my first breakout session.
I spent the majority of the day in one room listening to one guy speak. Jeff Brown is the VP of Professional Services at G2One and a member of the core Groovy and Grails development teams. The first session was an introduction to Groovy, a dynamic language that runs inside the Java Virtual Machine. I learned a few interesting things, but Groovy is similar in a lot of ways to Ruby so it wasn’t too much of a stretch.
The second session with Jeff was about Grails. Grails is a Java web framework built on top of Groovy. While the end result is a WAR file, you do not have all the nasty configuration files to wire together all the parts of your application. Grails includes Hibernate, Spring, log4j and other technologies but takes the heavy lifting away allowing the programmer to get to the core of the data domain and business logic.
Third was a session on advanced Grails where Jeff covered relationships, templates (what Rails calls ‘partials’), custom tag libraries (worth the price of admission right there!), AJAX and more. This session was largely a live coding exercise and we walked through most anything that someone could come up with. While this was going on I created a basic Grails app myself and mucked around a bit.
Jeff was a really good speaker and was focused on getting the most content across that he could. I enjoyed his sessions and learned a far bit.
Then came dinner with great cheese bread and a terrific chocolate cake. I ate more of that than I should have.
After dinner we heard a keynote from one of the presenters, Jared Richardson. Jared, the co-author of a great book called Ship It! A Practical Guide to Successful Software Projects, spoke about what he called "Career 2.0". The focus of this keynote was that you need to treat your knowledge as you would any other investment. No one else is going to invest in you like you will. Diversify your investments so that you are more insulated from the whims of the job market. Acknowledge it will take effort, set goals and plan accordingly.
Also he talked at length about sharing the things that you know. He pushed hard on blogging; blog about every problem you solve, every mistake you make and correct, every thing you research. If you write lots you get better at writing and you make a name for yourself. I liked the concept of getting beyond resumes to name recognition.
Anyway, I really enjoyed today and am looking forward to tomorrow. More to come…
Tags: career planning, confrence, education, grails, groovy, java, nfjs
