No Fluff Just Stuff Twin Cities Spring 2009 Review

The Spring 2009 Twin Cities No Fluff conference was last weekend. I enjoyed the weekend seeing old friends and learning new things.

I have to give out some gratitude to Jay Zimmerman for putting the conference together and running the show. Every conference I've gone to has appeared to run flawlessly.

My experience in the sessions was excellent. I spent the first day listening to Ted Neward's talks about Java Platform Security and what we might see in Java 7.

For Java 7 it looks like there will definitely be significant performance improvements. Chiefly, the introduction of the G1 garbage collector seams to be generating the most buzz.

Java Platform Security is something that have been largely unaware of. Neward did a good job explaining some of the Java security APIs and how we can implement them in our applications today to make our applications less vulnerable to malicious attacks. One thing that stuck out as a good practice is to run a comprehensive set of tests on a Java application and see what permissions are needed and then modify the security policy to accommodate only those necessary actions.

I commented that the security session was a little bit dry. One of my friends commented that if I said it was dry it must have been...well what do people think of me?

Neil Ford gave his keynote "On the lam from the furniture police." It's a great talk. That was actually the second time I've heard it and it was just as much fun the second time as the first.

Day 2: Stuart Halloway's Programming Clojure talk left me very hungry to give Clojure a spin. I like what I see in Clojure over Scala. Both languages have me interested though. The things I really like about functional languages is the simplicity in which they express functions. Functional programs take very little space to express function. The example Halloway gave reduced a 10+ line method from Apache Commons into a single line of Clojure.

One question that came up in the functional language discussions is: when are the functional languages going to become the killer app? The need for functional programming seems to revolve around concurrent programming and multi-core CPUs. My thoughts are this: right now 2-4 core systems are common. By using only a single core we're realizing roughly half to a quarter of our systems' potential. I think that when 16, 32, and 64 core systems are more common, then we're only going to realize 1/16, 1/32, or 1/64 of our system's potential. Something amazing is going to realize that potential and at that point I think the bandwagon will begin to fill.

The next session that I found to be very informative was Ken Sipe's Java Memory, Performance and the Garbage Collector. Great content and great delivery. Ken Sipe is becoming one of my favorite speakers on the tour. Java memory management is something that I admittedly have treated with the cargo cult mentality of setting the -Xmx to 1Gb and hoping that the Out of Memory errors go away. I had never heard of tools like visualgc, but I think it will be in my tool box of Java memory tools. It's a very cool JVM memory monitoring tool. I think that a lot of the mystery behind the garbage collector will not be so mysterious anymore.

I attended Ken Sipe's Hacking-The Dark Arts. Hacking/security is an interest of mine so some of his content was not new to me. It was a good refresher on some of the more common security vulnerabilities--SQL injection and cross site scripting.

On day 3 I enjoyed Mathhew McCullough's Git talk. I've heard great things about Git and I'm even using it as a source repository at home. I'm really not using it effectively though. I think that I will be much more effective with it now.

Neil Ford's Domain Specific Languages and Regular Expression talks were very informative to me. I think that both of them gave valuable content.

I concluded the conference with David Hussman's talk on Lean agile development. If there's a speaker who knows how to end a conference on a nice tranquil note it's David Hussman. I always leave his talks feeling far more relaxed than anybody else.

The takeaway that I'm getting is what I've suspected in the agile space. It's getting crowded with people who don't understand what they are doing. I don't know how I feel about it. On one hand, people are improving the way they work and realizing tremendous value from adopting some of the agile practices. On the other hand, people are doing 'agile' things that don't make any sense to them and poisoning agility within their organizations.

Another thing that occurred to me is none of the new agile practices are all that new. They're only new to the space of software development.

I've been mulling over what will be the next thing in software development practices. I'm trying to think beyond agility. I don't know what it is, but I think something new is needed. I think it will need to involve more of an organization than just the business users and development.

I'm still digesting the conference experience as a whole. I enjoy NFJS, but I'm beginning to wonder which conference will be the first one that I take a pass on. I didn't decide to go to this one until I saw the schedule and decided that I could find a valuable session for each time slot. I don't know if that will be the case this fall. It will be hard to determine whether there is enough new content to justify going.

One thing I'd like to see are more sessions with deeper content. I'd like to see more 2 part or even all day sessions that really have a deep explanation of topics. The 90 minute expository sessions are good for some things, but I feel like I'm at a point where I want to come out of the conference really understanding the content. There were too many sessions where the content was abbreviated for time.

I found the conference to be valuable. I thought that all of the sessions that I attended were worth attending.

No Fluff This Weekend

It's hard to believe that it's time for the Spring Twin Cities No Fluff Just Stuff Conference this weekend.

I've been looking at the schedule trying to decide what sessions I plan to attend. I think I'll follow Ted Neward's sessions on Friday. On Saturday I think I will attend Neil Ford and Ken Sipe's sessions. I know better than to even think about what I want to attend on Sunday--I will probably get interested in something else and attend that instead. But as of now I think I'll probably attend one of Nate Schutta's sessions and one of David Hussman's.

This will be an interesting conference. I would be surprised if it sold out in this economy though. There are rumors that many of the area employers are cutting/eliminating their training budgets. I can respect the decision, but I still think that people are paying a tremendous opportunity cost by not attending.

This will be my fourth No Fluff conference. Each conference I've attended has significantly helped me become much better at what I do. I'm willing to invest a full weekend of my life to attend the conference because I believe the value is outstanding.

My favorite cooking show

At No Fluff Just Stuff Ted Neward opined that he hates cooking shows. Ted hates cooking shows because the format of just about ever American cooking show is to show the host throwing ingredients into a pot, mixing them around and then they go to put them into the oven and then BA...might get myself in trouble using that word, KABOO...nope that one's for toilets, ALACAZAM!!! magically a delicious finished meal emerges from the magic oven.

Through the magic of BBC programming on American Public Television I grew up watching Keith Floyd on his show, Floyd on Food. Floyd's format is different. His show follows him as he prepares  and enjoys the dishes. Floyd also cooks with wine, some for the food and some for himself. You just don't see television chefs putting themselves three sheets to the wind during the show anymore. I think that's a bit of a shame.

Floyd on Food, as I watched it was all about delicious food and enjoying a meal and a bottle of wine. His guests were some of the most untelegenic people I'd seen, but they were knowledgeable and genuine. They also had a lot of fun presenting the show.

I went ahead and embedded all of the online clips of Keith Floyd cooking that I could find. I really wish that more resources ware available.  The first and last clips are the only clips from the Floyd on Food that I grew up watching.

The more recent episodes have more polish and better production values, but they also ditch the magic oven format that annoys Neward, Perhaps watching Keith Floyd will change his opinion of food porn. I think we, as a people should really do more to make the world more enjoyable for people like Ted Neward. Just kidding, I'm glad there are people like him who have opinions and are not afraid to share them.

As you may have noticed in the earlier episodes, the people aren't exactly the types of people that you'd see on television today. They're, kind of ugly and plain looking. It's almost as if they chose their guests based on the content of what they have to offer and not because they look good for the camera. I miss that, aside from the Sunday morning political news shows, you really don't see that on TV. 

Even though the people don't look all that good that food looks great, even on a horrible picture.

Security and Usability are at odds with each other?

At No Fluff Just Stuff in the Security Birds of a Feather session, Ken Sipe and Ted Neward both made interesting statements. 

Ken said that a secured logging system is the most important element to a security system. His reason for saying that is, even if damage is done, you'll want to know what happened. 

Ted made a good point that the vulnerabilities are likely to be through social engineering rather than trying to crack any difficult systems. That only makes sense that someone who is interested in defeating a systems is going to attack its weakest points. People have lots of weaknesses.

Ken mentioned an anecdote of a group of penetration testers who left a few USB flash memory sticks that were loaded with root kits and other goodies in the parking lot of their customer. Employees of the customer found the flash memory and couldn't resist the urge to stick them in the computers. It was game over after that.

Probably the most interesting, to me, statement made was one to the effect that for a system to be usable some degree of security must be compromised and vice versa.

The statement was in response to the single sign on trend.

That is to say that at the extremes a very usable system is insecure and a very secure system is unusable.

I agree that some measures that are performed in the name of security completely shred usability and that some things that are performed in the name of usability hurt security.

I don't see a single axis security/usability continuum. I truly believe that secure systems can be built that are secure. I also feel that I am not qualified to design these systems, but these are the recommendations that my unqualified self would suggest:

Stop relying on passwords so much. Passwords provide a single point of failure should one password become compromised. In one environment I worked, that was supposedly very secure, the security people required everyone to change each of their numerous passwords every sixty days. Say if one were to have ten accounts, each with its own password, keeping track of those passwords is a bit of a chore. Memory fails people and they will rely on other means. Some will use something like password safe. But there are some who will rely on the old paper backup. Good thing that nobody thinks to look under the keyboard.

Ted Neward touched on one good solution for usability challenges with authentication and that's multi factor authentication. I like multi factor, because it dramatically increases the difficulty of breaking a system without necessarily sacrificing usability, instead of one challenge, there are multiple. The factors usually fall into three categories, what you know(passwords, questions), who you are(biometrics), and what you have(objects).

This is how an ATM works, you have a card and you rely on a fairly weak password There are 10,000 available combinations for a 4 digit PIN. We don't worry about the relatively weak PIN because we're pretty good at keeping track of our ATM cards. Falling prey to social engineering schemes with our cards are far more likely than someone taking an ATM card and guessing the PIN.

I'd really like to see more multi factor security systems in place. If one of the factors in the system is an object, like an RSA token, then adding a relatively easily guessable second factor, for example why not provide a factor of selecting a picture of familiar objects out of a lineup of ten, twenty, one hundred other pictures? Pictures are easy for people to remember. The pass picture lineup may only provide a namespace of 100, but it only adds(multiplies) to the strength of the other factors.

People have mixed opinions about biometrics. I'd hate to think that by amputating a part of my body, someone could defeat a security system. Some of these systems can be defeated in some clever ways.

Multi factor is more about the combined strength of systems instead of requiring a single system and cranking its strength up to 11 and cranking the usability down to zilch.

I think we really do need to question why security systems are typically so unuseable and whether they really need to sacrifice usability for security.

No Java Unit Test Tool For Thread Safety Testing--I'm taking notes from Ted Neward's Concurrency NFJS online

Ted Neward mentioned that he is not aware of a unit testing tool for thread safety. I think that there should be one.

Ted recommends reading Release It by Michael Nygard.

Ted says never ever ever catch throwable. It can really hose up a threaded app.

JVM guarantees 32 bit atomicity. Longs and doubles are 64 bit, they need to be synchronized.

Threads don't switch on code lines. Threads switch on operation lines.

Threads are permitted to keep a local copy of field values if field not declared volatile.

Ted recommends Java Concurrency In Practice by Brian Goetz.

Field visibility is irrelevant to thread safety.

Two myths of the Java language: it is expensive to create objects and it is expensive to synchronize code.

05/20/2008 Ted Neward's presentation: The Busy Developer's Guide to Scala

Ted Neward gave a great presentation on Scala last night at the Object Technology User Group. If you have the chance to hear him speak I recommend it. He's a cool guy.
I wish I had prepared better that evening so I could join the group for pizza after the presentation, but that is my only regret.
The following is what I learned from the presentation and beyond that are a few of my own thoughts on the value and future of Scala.
Scala is a functional language built on the Java Virtual Machine. Like Groovy, Scala can use existing Java objects easily, and Java can use Scala functions with a little bit of work.
What's so cool about functional languages and Scala? That's really the big question. The strength of functional programming is that every operation in a functional program can be thought of as a mathematical function. You can think of it as an implementation of Lambda Calculus, at least that's how I'm going to think about it until I find it doesn't work.

For example: The operation 1+2+3+5 be thought of as
theValueOne plusTwo plusThree plusFive
which gets evaluated to
theValueThree plusThree plusFive
which gets evaluated to
theValueSix plusFive
which gets evaluated to
theValueEleven

In functional programming functions enjoy the same status as objects. Or another way to think about functional programming is, everything is a function, values can really be thought of as functions that returns a value.
What's the advantage of functional programming and what are the advantages of using Scala? One simple advantage of Scala is it's a new language that was conceived within the context of how programming languages are used today. What do I mean by that? Marten Odersky, the principal designer of Scala took careful index and consideration of the idiosyncrasies of the Java language and improved upon them. There are many restrictions and constraints in the Java language that we just accept because we've grown accustomed to them.
Java's a maturing language. Like people, maturity isn't all win. Like with people, programming languages pick up some undesirable traits over time. Older, wiser, and more capable, yes--but Java's starting to develop a gut, it's butt is sagging, and some of the new features are like the type of outpatient cosmetic operations that seem to be so popular with the over forty crowd.
Languages created on the Java platform are more like genetic engineering than cosmetic surgery. Designers can take the pieces of Java DNA and work them into their new language, they also have the opportunity to leave out the strands of Java DNA that they don't want. Only time will tell whether a bunch of Frankensteinien monsters come from this experiment. I'm inclined to believe that the LDL reducing ribeye steak is around the corner.
With new languages we have a great set of opportunities. First, we can see how languages are being used and develop features to accommodate those usages, e.g., XML is a first class citizen in the land of Scala.
We also can see areas where a programming language can be improved. For example, Scala has implicit typing. Consider String s = "I'm a String" verses s = "I'm a String". Is there any doubt as to what the type of s is? The Java language seems to think so, that's why we need to explicitly declare the type of all objects.
There is enough Syntactic Sugar in Scala to rot your teeth out.
That's all well and good, Groovy does the same thing. Correct. What does a functional language provide that other languages don't? Scalability. Consider this: a functional language composes functions by passing functions as arguments.
This is like a certain hot topic debate where a group of people rhetorically denounce a theory because it is not a fact. Ken Miller has an eloquent explanation for why a theory is more useful than a fact. To cut that 2 hour lecture to the chase I'll paraphrase: "A theory is more powerful than a fact because a theory can be utilized to derive facts."
A function in a functional language is like a theory. We pass theories around and then apply them to values to derive facts. For example: we may employ the theory of gravity to derive the time that it would take an object to drop 100 feet or 10 feet. If you think about it, most theories are compositions of other theories. Data points are applied to those theories to derive results.
Functional programming is no different. We define functions that are composed with other functions in a process called function currying.
The application of a value to the curried function is independent to currying the function. That is to say, we can curry functions without transforming any data.
As such, thread safety and concurrency are not issues in the functional programming world. That is where I see Scala making the biggest impact. When the Java platform can be used to perform distributed and concurrent computations then we will see a fusion of Java's ubiquity and the power of parallel computing on a scale that the Java community has never seen.