It’s been almost a month since the CodeMash event…let’s see if I can still remember what happened on that second day.
Session: Oh, Crap! I forgot (or never learned) C!
In my case, it’s kind of both: I took a single C/C++ class many, many years ago in college.
Chris Adamson led this session. Chris is an active iPhone developer and said his primary motivation for proposing this session to CodeMash was the fact that Apple decided to create Objective C as the development language for the iPhone. Paraphrasing Chris, “the big-wigs at Apple must’ve gathered in a room and asked the question, ‘on what programming language can we base our development language for the iPhone? I know! Let’s base it on C. Everybody knows C!’” Unfortunately, nowadays, many people don’t know C—hence, the need for this session.
C was developed in 1972, primarily for the Unix platform. The definitive book on the language is The C Programming Language by Kernighan and Ritchie.
LangPop.com still lists C and C++ (not to mention Java, a language inspired by C) as the most popular of development languages. The Linux kernel and tools like SQLite and OpenGL have been written in C (according to the Free Software Directory). Most interpreters are written in C. Much of the iPhone is written in C. Therefore, we should learn C!
What makes C great? It’s portable: most OSes include a C compiler. It’s performant and it’s minimal.
There’s no garbage collection in C, so you should be familiar with commands like malloc() and free(). The language is compiled, not interpreted, code.
C has the concept of a header file (.h extension) and the source file (.c or .cpp extension). The header file contains functions and variable you want others to see—sounds like a contract to me. The source file contains the actual implementation. You use the #include syntax to include the header file in your source file.
Types in C include:
- short, int, long, long long
- float, double
- char, bool
- void
The dreaded beast of C is the pointer, but Chris addressed this pretty well in his presentation. Overall, this was a nice refresher of concepts I learned years ago.
Session: Looting Design Ideas from the World of Warcraft
Here was another instance when I was torn between two sessions: this one and one entitled RESTful Interfaces to Third-Party Websites with Python (by Kevin Dahlhausen). There are many sites I’d like to scrape for data and the RESTful session might have been the ticket for that. Nevertheless, I thought the Warcraft session my be informative since I have a project in mind that will probably need some good GUI design. So, off to the Warcraft session.
I know vaguely what the WoW game is but have never played it. Jason Follas went through several UI shots and the WoW architecture and pulled out some thoughts as to why the game is so successful—12 million subscribers at present.
The WoW interface is pretty busy with tools, meters, and other widgets; however, it appears quite customizable. Here the key concepts Jason outlined to craft a successful interface:
- Tool tips on the controls
- Keyboard shortcuts
- Customizable keyboard shortcuts
- Add/remove widgets
- The ability of the user to customize the UI is more important than developing the perfect layout
- As a developer, you should deliver a simple, clean interface out-of-the-box, permit customization, and provide keybinding/shortcuts that can be customized
WoW is also extensible, with third parties offering ways to extend and alter the behavior of the game (like this one). Extensible apps like WoW should allow the behavior of the app to be modified without requiring a recompile. Allowing an app to be extensible give the community some “skin in the game” and can be a source of free research & development from the community. Extensions in WoW can occur in many ways:
- Macros – chaining multiple commands together under a single command
- Public API – events (using the Observer pattern), methods, and UI widgets
- Add-ons – a.k.a. “mods”
- Scripts – via Lua, a C-based language with a small runtime
In .NET, extensibility can be achieved through the DLR (by using the ScriptRuntime class, for instance) or my using MEF.
From a data perspective, Jason talked about the importance of caching, logging (log everything), and making web services available. Apparently, it is a popular practice for WoW players to grab the log file pertaining to a particular battle and run it through an analytics engine so that they can see which aspects of the fight they were weak in and learn to improve their play.
On the social side, Jason discussed chatting, guilds, game masters, and presence awareness. The makers of WoW actually pay people to play the game as game masters. As a player, you may occasionally encounter a game master who will come up to you and ask you if you need any help.
Finally, Jason talked a little about money aspects of the game. WoW is successful, in part, because it focuses on a subscription model. The software itself is largely free—you just have to maintain a monthly account to play the game. Making recurring payments easy is a way to retain subscribers.
Lunchtime Keynote: The Mother of All Bugs
Popular author Andy Hunt gave the last keynote of the conference. And what is the mother of all bugs? Why our brain, of course! We’re neither logical nor rational. We make processing errors, we can’t predict a most outcomes (see The Black Swan), and we tend to allow contextual influences to slant our decisions.
Andy enumerated many cognitive biases that plague humanity. These include:
- Anchoring/arbitrary coherence
- Fundamental attribution error
- Need for closure
- Confirmation bias
- Exposure effect
- Hawthorne effect – on average, it takes 3 weeks before a practice becomes habitual
- Relativity
- Free isn’t cheap
Extending upon contextual influences, Andy noted that different and competing personality traits play a factor (Myers/Briggs work has identified 32 different personalities among the masses). Deeply held values—what you value and why—is also a strong factor.
Andy also looked at our buggy brain problems at a generational level. He described four generational archetypes:
- Prophet – a generation emphasizing vision and values
- Nomad – a generation valuing liberty and survivalism
- Hero – a generation associated with community
- Artist – a generation focused on pluralism
Andy then overlaid these archetypes with historical generations:
I always find it interesting to see how researchers attempt to identify generational groups. Much of the time, though, I think it’s pretty silly: everyone throughout time is unique and individualistic—shaped by the events and time in which he was born, sure, but also shaped by his geography, community, and biochemical makeup. Or maybe that’s just the Nomad in me talking.
The final thought Andy left us with to help mitigate the bugs we create is: Trust, but verify.
Session: Introducing the MVVM Pattern
Again, I found myself choosing between two interesting sessions: this one and one entitled IronPython with ASP.NET (Chris Sutton). Then I considered the fact that Microsoft appears luke-warm in their support of IronPython and thought my time would be better spent learning more about MVVM.
Brian Genisio ran this session. So, MVVM (Model-View-ViewModel) is this variant of MVC where you have a ViewModel class sitting in between your View and your Model. A binding relationship typically exists between the View and the ViewModel. The View can also push actions to the ViewModel. Data and events can be shared between the ViewModel and the Model. You can actually have your XAML reference your ViewModel as such:
<Window.Resources>
<ViewModels:blah x:Key=”ViewModel”>
For more details, Brian listed some of the popular opinion leaders on patterns and especially MVVM:
He also enumerated some “mini-patterns” that are relevant in this space:
- NotifyPropertyChanged via the INotifyPropertyChanged interface
- Command Pattern (Delegate Command)
- Event Aggregator (Publish/Subscribe similar to the Mediator pattern) [Brian noted that there are problems with the Observer pattern.]
- Attached Behaviors (eg. command binding)
Brian laid out several guidelines for implementing MVVM, including:
- Get your code out of the code-behind
- Bind UI inputs/outputs to the ViewModel
- Implement INotifyPropertyChanged
- House “behavior” in the ViewModel
- Refrain from maintaining ViewState in the Model
Some frameworks to help you get started using MVVM include:
Testing frameworks to help you better test your MVVM components include:
Session: Analyze and Optimize your .NET Web Application
At last, we reach the final session of the conference: James Avery leading us down the jagged path toward ASP.NET optimization. James geared his presentation largely around his own personal experiences optimizing web applications. He’s found that you shouldn’t code with performance optimization on your mind but rather just code then measure afterwards: build & measure. When you measure performance, you measure, then modify, then measure again.
In his estimation, there are three tactics for optimization:
- Optimize the code – this is usually not the problem
- Optimize the database and/or network
- Cheat (by caching data)
His presentation, which was basically all coding/optimization, followed these steps:
- Measure the application (using Pylot)
- Profile the application (using ANTS Profiler)
- Profile the database (using SQL Profiler)
- Run Pylot again and look for any improvements
At one point, James dove deep into LINQ and lazy loading versus eager loading. There are advantages to either approach, particularly concerning optimization, but I don’t remember exactly what they were. I believe, in the demo’s case, that he wanted LINQ to do eager loading and he had to dive into the guts of it to make it work. He also mentioned something about Plinqo.com, but don’t remember exactly what he said about that, either.
Regarding caching, James said that you basically have two options:
- Output caching, where you deal with caching the page
- Fragment caching, where you deal with caching data
For optimization purposes, fragment caching is usually the ticket. Typically, you use HttpContext.Cache to do this.
That’s It
Whew. That’s the end of my notes. Man that was painful, but chances are, some of this might help me down the line. As I’ve said before, CodeMash is cheap and relatively close…so it’s certainly not a bad deal, although it does place some added stress on my already tight domestic schedule. Will I do it again next year? Don’t really know: I’m changing roles at work which will take me almost entirely out of software development, so the conference may no longer be relevant to me this time next year. I’ll just have to wait and see.