What I Learned At Nebraska Code Camp 2013

nebraska-code-campA couple of weeks ago I was at Nebraska Code Camp in Lincoln, NE. This was a very good event. All of the sessions I attended were excellent! In the hallway between sessions, and during the after-party, I met with some excellent individuals. The software development community is thriving in Nebraska!

After such a productive code camp, I thought I would post some highlights of the most useful and/or interesting things I have learned/re-learned. Unlike my last “what I learned” post, I am just going to include some of the highlights this time. This means you might have to think a little bit to digest these notes.

Rethinking Enterprise

Ted Neward (@tedneward, http://tedneward.com/)

  • We are trained to think that the solution is never far from the problem.
  • Real world problems are difficult, unpredictable and complicated.
  • Reuse should not be the goal of your programming efforts.
  • “best practice” does not get you the best, it gets you the average.

Sniffing Out Success: Identifying Smells and Anti-Patterns in Your Code

Patrick Delancy (@PatrickDelancy)
This was my presentation for the event. I have received a lot of positive feedback, and some excellent suggestions!

You can get some more information about this presentation on this page.

The Busy Developer’s Guide to Esoteric Languages

Ted Neward (@tedneward, http://tedneward.com/)

  • Esoteric programming languages are rarely useful for real applications
  • INTERCAL: Politeness is mandatory.
  • Chef: For the stack-based cook.
  • UnLambda: Your functional programming language nightmares come true
  • Brainf**k: the name says it all
  • LOLCODE: CAN HAS STDIO? KTHXBYE
  • Shakespeare: Recall your imminent death!
  • Piet: Program code will be in the form of abstract art.
  • Whenever: Has no sense of urgency. Executes all of the program commands… eventually, and not in the order specified by the programmer.

Exploratory Data Analysis with R

Matthew Renze (@MatthewRenze, http://www.matthewrenze.com/)

  • Data is like oil. It needs to be refined before it can be used as information.
  • R (http://www.r-project.org/) is a combination of scripting language and development environment.
  • In data analysis, it is impossible to prevent all bias, but exploratory data analysis is especially susceptible
  • Exploratory analysis is generally conducted in the REPL, writing scripts as necessary for repeated tasks
  • Data cleaning is probably the most time-consuming step.
  • Analysis is closely related to data mining and machine learning.

Unit Testing JavaScript when you’re scared of JavaScript

Matt Steele (@mattdsteele, http://www.matthew-steele.com/)

  • JavaScript should be treated with a healthy amount of fear / respect.
  • Browser-based integration tests are slow, brittle and hard to maintain
  • Single responsibility principle also applies to JS
  • Using mocks in unit tests applies SR principle to the test code
  • Tips to get started
    • Start small
    • Use tests and process as a safety net for refactoring
    • TDD
    • Synchronous first
    • Pair programming

Have an embarrassing coupling problem? Let’s solve that with Dependency Injection.

Cory House (@housecor, http://www.bitnative.com/)

  • instantiating objects in the constructor produces tight coupling to the implementation
  • Dependency injection is one way to simplify inversion of control/dependency inversion principle
  • Composition root is where the app starts. This is where DI should be configured
  • Classes should benefit from DI, but not depend on any specific DI container
  • Injection locations
    • Constructor
    • Property
    • Method
  • Config Styles
    • XML
    • Code
    • Auto-Registration
  • Moving classes to a separate folder or assembly does not remove coupling
  • Using service locator adds dependency on the IoC container

Leave a Reply