What I Learned at South Florida Code Camp

South Florida Code Camp 2013 is now over. This was a large event on the campus of Nova Southeastern University in Fort Lauderdale, Florida. The organizers did an excellent job, especially considering that there were about 80 speakers, over 1200 registrants, nearly 90 sessions and a blizzard in the northeast (which prevented a number of speakers from attending). A big thank you to Rainer Habermann, Dave Noderer and everyone else that was involved in making this event happen.

Since I have been attending a fair number of conferences and code camps, I have decided that it might be worthwhile for me to start sharing what I learn at these events. If this goes well, I’ll likely continue.

Here are my notes from the event. Some of these are things that I just learned. Most are things that I knew already, but enjoyed the reminder.

So here we go. What I learned (or re-learned) at South Florida Code Camp.

General

• A presenter is perceived as an expert in the topic they are presenting. As such, they should know the topic at least as well as their audience.
• Alarms on stairwell doors should be turned off, or warning signs should be posted.
• Test the presentation equipment you will be using. Test it ahead of time, and test it in the actual room you will be presenting in.
• Make sure your demo code/apps work.
• As a presenter, don’t waste time justifying your technical decisions (or apologizing for them), unless someone asks.
• If you haven’t given your presentation in a while, review it, update it, practice it.

Caution! Cross-Cutting Concerns Ahead

Cross-cutting concerns and Aspect-oriented programming with PostSharp.

Joseph Kunk (@JoeKunk, http://jbknet.blogspot.com/)

Joe Kunk wrote an article for VisualStudio Magazine a few months ago. His presentation followed a similar structure to this article.

• C# was internally referred to as “java better than Java” as Microsoft
• VB.NET was developed to out of the fear that VB6 developers would make the leap to Java instead of C#.
• “At its core, AOP is the practice of encapsulating functionality common among multiple code elements yet independent of the business logic, and applying that common functionality to the target source code elements declaratively.”
• Benefits include
  • reduction in repetition of “plumbing” code
  • centralization of this code
  • particularly for code that is difficult to refactor into libraries
  • reduce clutter in business logic, which can result in more readable code and shortened development time
• The concept of AOP can be traced back to Xerox Palo Alto Research Center in 1996, which was a predecessor to the current AspectJ project.
• AOP has been implemented in different ways, but must be able to be applied declaratively, and it must not require the application’s architecture to change in order to accommodate it.
  1. Dynamic Proxy: limited to modifying communication, but cannot affect the logic of the service itself.
  2. Code Generation: more powerful than dynamic proxy, but requires regenerating the application from source whenever an aspect changes
  3. Meta-driven programming using dynamic languages
  4. MSIL / IL Modification: very flexible, but only against the final assembly, and it modifies the compiled assembly.
• PostSharp uses IL modification, which is supported (and used) by Microsoft. It is also described in ECMA-335, which defines the standard for a CLI.
• Visual Studio 2012 “portable library” option will hide namespaces that are not supported on all selected platforms.
• PostSharp aspects must be serializable. They are added as application resources and are dynamically loaded on demand.

Building Cross Platform Applications: WP, iOS, Android

Cross-platform development using c-sharp and mono (xamarin).

Jonas Stawski (@JStawski, http://www.jstawski.com/)

• Xamarin
  • iOS – “ahead-of-time” compilation to fully-native application
  • Android – integrated application and mono runtime
  • Windows Phone – native .NET, built-in .NET framework
• Write once/run anywhere requires supporting only the lowest common denominator. When doing this, generally the UI and the end users will be the ones that suffer the most.
• The Xamarin architectural decision was a balance that will let each platform benefit from its own strengths, but effectively use a significant amount of shared code.
• Use of some patterns will improve your experience with Xamarin and mono:
  • MVC (Model-View-Controller)
  • Business Facade / Manager Pattern
  • Singleton and Factory
  • Provider Pattern like Dependency Injection
  • Asynchronous logic to prevent blocking the UI thread

Magic Bus – The Pub/Sub Pattern on Steroids

Introduction to service bus architecture and providers.

Page Horton (http://www.pagehorton.com/)

• Eventing framework enables decoupling of layers and services
• Helps to reduce your code graph (complexity / number of paths through the application logic)
• Usually allows side-by-side versioning of messages and services, which helps with independent deployability.
• Increases extensibility of the application
• topic-based vs. content-based publishing
  • by message contract (class/interface) vs. by the content of the message
  • heavy use of interfaces and classes vs. heavy use of pattern-matching
  • topic-based enhances develop-by-contract
• Service bus vs. Enterprise service bus
  • pub-sub is application-based vs. enterprise-based
  • typically simple patterns vs more complex message patterns and more management structure
• A service is usually indicated by implementation of some kind of “BusService” interface.
• A service is combined with subscription declaration
• A service should be fully decoupled using dependency injection or something similar
• A saga is a long-running service that is serialized/deserialized as needed
• Filtering is topic-based subscriptions with some condition on the content of the message
• Active vs. Passive service discovery
  • A service must be started and send notification of its existence vs. the service bus loads and searches for subscribers.
• Itinerary-based vs. Dynamic graph
  • Pre-defined plan with known subscribers vs. publishing to whatever subscribers may be listening at the time

Getting Started with SignalR

Jonas Stawski (yes, the same one listed above)

• The web has evolved to require more real-time delivery of data asynchronously, even server-initiated.
• A problem is that HTTP is stateless. 1 request yields 1 response.
• Some attempts to work around this limitation of the protocol include short polling, long polling, forever frame
• HTML5 introduced some better approaches like server-sent events and web sockets, but these are not supported consistently
• SignalR provides a persistent connection, but it abstracts the transport layer and uses a signal-based programming model
• Questions can be directed to the jabbR chat room for SignalR. David Fowler or Damien Edwards are frequently available there to help.
• Client subscriber to server publisher.
• Hub can be used for server, which enables client code to appear more like a direct call.
• Client can be any platform (web, windows forms, etc.

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

This was my presentation at the code camp. There was an excellent audience, and we ran out of seats!

Look under presentations above for this talk’s outline and some other background information. Please let me know what you think!

Are your indexes helping or hurting your application?

Some technical information about database indices and how to control their behavior for better performance.

Sam Mesel (LinkedIn)

• A SQL server database file contains extents, which are composed of pages, which are each 8k in size
• A Page contains the page header, body and a row offset table
• “Heap” refers to a table that does not have any clustered indices. This will force a table scan for most operations.
• A cluster is a table with a clustered index.
• A query will start at the root node and traverse the index tree to find the data row references.
• Filtering by only part of a composite index will cause an index seek, as long as the filtering is applied to the left-most index field(s)
• assume a non-clustered index on fields (ID,Name)
  • SELECT WHERE Name index scan
  • SELECT WHERE ID,Name index seek
  • SELECT WHERE ID index seek
• SQL Server index is an inverted balanced tree (b-tree)
• In a clustered index, the leaf level is the record data
• In a non-clustered index, the leaf level is the row id (database file id, page number, etc.) and included fields
• In a non-clustered index on a table with a clustered index, the leaf level contains the cluster index reference, not the row id
• In this situation, Microsoft has enforced consistent time to return each row for a given query — it is the same distance through the index tree to any given record data
• Build an index with INCLUDE in order to add frequently accessed row data to the index leaf node, but don’t include those fields in the index itself.
• SARGable (Search-ARGument-able) items are any item in the search predicate that can use an index
• Causes of non-sargable items include funcitons, complex expressions, inequality comparisons, implicit conversions and LIKE statements that start with ‘%’
• Some helpful commands, tables and stored-procs:
  • SET SHOWPLAN_ALL ON
  • EXEC sp_help
  • EXEC sp_helpindex
  • SELECT FROM sys.dm_index_physical_stats
  • DBCC IND, DBCC PAGE, DBCC TRACEON, DBCC SHOW_STATISTICS, etc.
  • SELECT FROM sys.stats
  • SELECT FROM sys.indexes
  • SELECT FROM sys.partitions
  • SELECT FROM sys.dm_db_index_usage_stats