A 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
