I attended the Fall 2011 No Fluff Just Stuff stop in Reston, VA. I really enjoy attending these local conferences. Lots of learning crammed into 3 days and a chance to meet with other enthusiastic developers in the area. The conference also provides the added bonus of giving me at least a couple of new things to learn.
Keynote: The Rise and Fall of Empires: Lessons for Language Designers and Programmers by Venkat Subramaniam
Venkat spoke about what developers can learn by studying history. Empires fall eventually so be prepared by learning and understanding other languages (Java won't be forever: learn Scala, Ruby, Groovy, Objective-C, and/or Clojure). There is a pattern in history where revolutionaries become resistors. For languages this is like people who started in C++ and moved to Java and now resist changing to something else, or Java people who moved to Ruby and act elitist. Be willing to move on and at minimum learn from other languages. He suggested working through Seven Languages in Seven Weeks.
Game Theory for Software Developers
This talk focused on various game theory techniques from economics. You want to be very careful with incentives and metrics so you don't drive the wrong behavior. You want to instill intrinsic motivation rather than extrinsic. Examples offering $50 per resume referred may lead to getting lots of bad candidates or mandating 100% test coverage could get test code with no asserts. There were other interesting stories based on the prisoner's dilemma, Akerlof's "Market for Lemons" as applied to hiring, and the grim trigger as applied to projects with known end dates. Lots of internet searches could come out of this.
http://ambientideas.com/blog/index.php/2011/04/game-theory-and-softwaredev/
NoSQL
Main suggestion from both talks was use the right kind of database for your data model and profile. Possibly use multiple kinds of databases for your project.
CouchDB: Document based datastore that sacrifices immediate consistency for high availability and ability to partition. Good use case looks to be as a store for data used in a massively parallel map reduce type problem.
Neo4J: Graph based datastore has all of the ACID properties of a relational database. Excellent for graph based problems like social networks. Sharding poses a problem as that is an unsolved issue in graph theory. According to the speaker, sharding is not needed unless your graph database has billions of nodes.
Testing with Spock
Spock gives a specification driven bent to automated testing on the JVM. It provides the given, when, then constructs to your tests. It is possible to do the same things in JUnit so my recommendation would be to try out both and pick the one that works best for you. I can see using both in my applications depending on what I'm trying to test/do at the moment. I don't think spock would work as acceptance tests that can also double as requirement documentation for the customer, that's a space for cucumber or easyb.
http://code.google.com/p/spock/
Functional Thinking
Writing code in a language with functional abilities like Scala or Clojure requires a mental paradigm shift. The speaker showed a program to find perfect numbers in well tested object oriented java, and then showed the differences in thinking needed to make it functional. The end result was the same problem solved using functional java, groovy, scala, and clojure. So even if you don't want to try a new language, try to solve a problem without using mutable state.
Scala
The session was hands on coding. Bumped learning Scala higher up on my queue. Scala is statically typed, lets you drop a lot of the cruft that you need in Java, combines functional and object-oriented properties, and looks to be developing a good community.
http://www.scala-lang.org/
Testing Javascript
The summary is you can and should unit test your javascript. We did some live coding using js-test-driver to run tests. In my opinion the best self check of the conference came during this talk: my paraphrasing "If you've ever thought, this code I wrote is too hard to test, it means you have designed/written some poor code."
http://code.google.com/p/js-test-driver/
Continuous Delivery
Read Continuous Delivery. Continuous delivery is about reducing the amount of time between having an idea for a feature or discovering a bug and getting the update into production. This is accomplished by automating as many parts of the delivery pipeline as possible. This pipeline includes continuous integration with automated acceptance tests, the ability to automatically setup infrastructure, and capability to automatically or on demand deploy to a testing or production environment.
I'm putting together a brown bag and blog series on this topic. Updates will go out as pieces are finished.
Enterprise Security API w/ OWASP
Hacking Your Brain for Fun and Profit
This is a list of ideas from the talk:
- studies show that missing a night of sleep makes you 30% less efficient and if you need 8 hours of sleep and regularly only get 6 its like missing 2 nights of sleep
- if you're stuck on a problem play with a cube toy, talk to someone, sleep on it, take a run
- rare things are hard to notice, have beginner's eyes for a problem
- keep an external brain - record ideas on a computer or in a notebook
- exercise releases chemicals that make your brain work more efficiently
- you can't really multitask, distractions break flow
- Dreyfus model for skill acquisition
- Be aware of cognitive biases
- Dunning-Kruger effect: Incompetent people overestimate their abilities, competent people underestimate their abilities
- Free is powerful/losses hurt more than gains: Situation you have the option of a $10 gift card for free or a $20 gift card for $7. Most people take the free card.
Reading List
In no particular order:
- Continuous Delivery by Jez Humble and David Farley
- Seven Languages in Seven Weeks by Bruce Tate
- Programming Scala by Venkat Subramaniam
- Pragmatic Thinking and Learning by Andy Hunt
- Where Good Ideas Come From by Steven Johnson
- The Master Switch by Tim Wu
And remember to do something today to make yourself better than yesterday.