Pictures from Austin Code Camp 2013

Here's a few pics from the Austin Code Camp 2013.

The Camp was great.  The advanced planning and hard work of all those involved was evident.

It always surprises me that the camp is free, with two free meals thrown in.

Registration was fast and easy.

 My 8:30 class was "Web API Quick Start" by Ryan Vice.
My notes:
* Ryan stressed a resource-centric, guessable URL design like the apogee web site promoted I was not able to find the apogee web site) like Accounts/:id/Withdraw and not AccountWithdraw/:id
* Ryan used Postman for debugging URL, although Fiddler works as well
* HTTP 201 is the freturn code if you create a resource (Accounts/add) and in the headers you return "location: Accounts/12345"
* The MVC framework has HTTP codes so you don't need to put in a magic string, "201".
* They use a web api pipeline poster to discern where to insert their function into the sequence.  Perhaps he was talking about this one.
* To create a Web Api project start with a new "MVC4 Web" app in VS.
* Use the Json.Net framework
* For versioning use something like "uship.com/api/v2/Resource"
* JSON to C# utilities are out there that create a C# object from JSON text
* For documentation, instead of WDSL use HelpPage from NuGet

My next class was Database Optimization with Anil Desai

* Don't look for the longest running query, but the longest time*frequency

* Use the Activity Monitor in mssql by right clicking on the db server in Management Studio

* He showed a bunch of reports I'd never seen by right clicking on the database and selecting "Reports"

* Sometimes autogrowth is set to 1 Meg - too small a value for today.

* When tracing you can add a filter to only catch queries only above a certain threshhold

* It's good to add the name of the app in the connection string.

* He showed a statement with "BETWEEN" which I'd never seen.   BETWEEN 10 and 20

* When running a trace write to a file and then import to database, otherwise it soaks up more resources

John Crowe gave a good overview of Dependency Injection.
* The big problem is the "new" operator, it makes for ridged code that is hard to test.
* Three types of IOC: Factory Pattern, Service Location and Dependency Injection
DI has three types:  Constructor Injection, Setter/Property Injection, and Interface Injection

Anne hosted a "Lightening Talk" round where attendees gave informal 5 minute presentations.
Jeffrey Palermo gave in interesting talk on his new company, Clear Measure, started in January and quickly built the startup company by using Cloud based services.  They use GoogleApps for mail and video calls, GoToMeeting for conferencing, EchoSign for authentication, Ring Central for phones, Quickbooks for accounting, LegalZoom for incorporation and BaseCamp for management.

Latish Sehgal talked about tools for .Net Development, his list is at http://dotnetsurfers.com/tools.
* Use ReSharper to locate unused libraries
* Use Firebug console mode to test jQuery commands; YSlow to get recommendations on speed
* Glimpse (http://getglimpse.com/) does for the server side what Firebug does for the client.
* SMSS Toolpack which is a little like ReSharper for Sql Enterprise Management Studio. It remembers all your handwritten sql queries.
* Gray Wolf was the most interesting. This (hacker) tool allows you to insert code into applications.

Amir Rajan gave an interesting talk on "JavaScript MVC Framework Rundown"
* jQuery - spaghetti code
* Backbone - event driven (most accessible) may use Marionette plugin
* Knockout - MVVM with DuRandal
* Angular.js - redefines HTML
* Ember - all MVC in browser, steep learning curve

https://github.com/tastejs/todomvc has an excellent overview of all the browser-based MVC frameworks.

C# WebClient .DownloadStringAsync Blocking Main Thread

Photo by Max Ronnersjö

While needing to invoke a url in the background from a C# 5.0 program, I was overjoyed to stumble across "WebClient .DownloadStringAsync(url)". I thought I'd found a bird's nest on the ground. 
Here was a single call to solve my problem. 
Great job Microsoft framework group!

Well, not so fast.

My unit tests for bad and malformed URLs were actually blocking.
The problem is that WebClient.DownloadStringAsync() blocks until the connection is made.  If your application happens to call a bad url, the main thread will block until it gets an error code back.  This can be up to 3 seconds for normal malformed urls.  In  one case, our internet proxy had problems with the malformed url and consistently hung for 10 seconds while it was sorting out the problem and eventually returned a timeout error.

If you ever suspect the url you are calling is ever going to have issues (and we know all sites are up all the time!  Right.), don't use DownloadStringAsync, use DownloadString() wrapped in a Thread or Task.  This way if the connection has problems, it's another thread's problem, and your main thread can move forward.

...
new Thread(() => DownloadUrlSynchronously(url)).Start();
...

public void DownloadUrlSynchronously(string url)
{
            using (WebClient client = new WebClient())
            {
                try
                {
                    var x = client.DownloadString(new Uri(url));
                    _logFileWrapper.LogInfo("Url called successful - " + _url);
                }
                catch (Exception e) { ...}
                ...
}