The meeting will be held at 6 pm on Wednesday, May 15, at SRT Solutions, 206 S. Fifth Ave., Suite 200, Ann Arbor, MI 48104.

RSVP at http://www.meetup.com/Ann-Arbor-Scala-Enthusiasts-User-Group-Meeting/events/114864142/

Enjoy!

No one, at any level, should ignore this responsibility. You owe it to yourself and to your organization. If your current position isn’t working for you, either adapt it to work, or find something that does. In Open Spaces conferences, we call this the Law of Two Feet, and it’s quite liberating to apply this thinking broadly.

SRT Solutions recognizes that employees are most effective when fully engaged. This translates to better software, better communication with customers, and to being a better co-worker. And, to being a better boss. Even business owners are not exempt from needing to follow their passions.

So what’s my passion? I like bringing people together and building great software to match what they need. I’ve had a lot of opportunity to do that in my 13 years at SRT, but I’ve decided that I need a new adventure. I could have stayed at the company that Bill Wagner and I built until retirement, but I decided to use the Law of Two Feet to find my next adventure.

I’m excited to say that I will be joining Netflix in Los Gatos, CA, next week as Director of Engineering for Cloud Tools. I will be working with an amazing team as they build software to support cloud deployment and management, used both internally and often released as open source tools to the broad community. I’ll be working with the other teams to ensure that they know what our team builds, and to help ensure that what we build is useful for them. This is an amazing opportunity for me, but not one that I made lightly. It required not only asking Bill to take on full managerial responsibility for SRT but also moving my family across the country. I remain committed to SRT’s success, and to watching the personal and professional growth of the SRT staff.

My nine year old daughter is wise. She said, “Sometimes change is good”. Indeed, indeed it is.

Productivity Highs with RIA Frameworks

After traveling out and back, I see everything from a different perspective. Web applications, today, are incredibly different from the way they were in the 90s. The biggest difference, from my perspective, is the way we develop them. Coming from the RIA perspective, using Silverlight and Flex, I am accustomed to a certain productivity that I pine for now that I am developing for the web again.

If you know me, you know that I was a big fan of Silverlight and Flex. They were frameworks which let me develop amazing desktop experiences in the browser. I was doing things in 2007 that to this day is still impossible to do with HTML5 today. Those frameworks had one flaw, however. They required plug-ins to run.

Death to the Plug-In

I’ve never been much of an apologist for plug-ins. I saw them as a necessary evil. An evil that became unsustainable in this brave new world of mobile computing. When Apple, Microsoft and Adobe killed Silverlight and Flex, I wasn’t sad because I loved those platforms. I was sad because I knew I couldn’t be as productive writing the same kinds of applications in HTML/JavaScript/CSS.

First Generation SPA Frameworks

This is where the Single-Paged Application (SPA) frameworks came to my aid. There are too many to count, but from my vantage point, it has felt like Backbone.js and Knockout.js have been the primary options in the SPA market. I landed on Backbone.js as my go-to choice because it was a more complete solution than Knockout.js with its client-side route handling and model synchronization. I found myself at home with building SPAs because they were so similar to RIAs.

Unfortunately, my productivity never came close to that of the plug-in frameworks. Backbone.js and Knockout.js simply aren’t high enough of an abstraction for them to provide the same abilities to me. They are the first generation of SPA tools and with that brings the pains of a first-generation technology.

Filling in the Gaps

We’re starting to see some pretty nice add-ons to our first-generation tools. These add-ons fill the gaps that the frameworks leave by attempting to make you more productive. Specifically, Backbone.js has a poor view abstraction, making things like collection views and deeply nested views difficult. Marionette.js builds upon Backbone.js to provide more structure, guidance and capabilities. Using Marionette.js boosted my productivity significantly by taking care of much of the boiler-plate code that I found myself writing with Backbone.js alone. It is still not ideal, mostly because the abstractions are not extremely strong. They are strongER, but nothing compared to the capabilities I pine for. Knockout.js has a similar packaging called Hot Towel. Hot Towel fills in the holes that Knockout.js left by providing model synchronization, route handling and child view handling.

Unfortunately, these approaches only take us as far as the base technologies allow us to. Without a strong abstraction to begin with, these add-ons can only ever takes us to generation 1.5.

Second Generation SPA Frameworks

At the same time, the second generation of the SPA frameworks are coming forward. They come from a higher level of abstraction and the code you write demonstrates it by being significantly less (half or less). These frameworks (Angular.js and Ember.js) provide everything we wanted from our first generation tools but they also bring more capabilities like convention-based development paradigms and dependency injection. What’s more, we are starting to see tooling (such as Batarang) built around these abstractions which let our development lifecycle be that much smoother.

I am focusing my efforts on these second-generation tool sets for now. I am not abandoning my Backbone.js/Marionette.js tools completely, but I am not planning to invest much more time in them. Instead of patching the holes that the first generation tools created, I am choosing to spend my time using (and recommending) the next generation of tools. Specifically, I am focusing my efforts on Angular.js. It fits my development style better and I feel like the abstractions make more sense to me. I’m not knocking on Ember.js in any way. It is a fine choice, in my opinion.

The Future of SPA Development

But this isn’t where we are settling. I think it will require a third generation of tools before the SPA space really takes off. I have no idea what these frameworks will be, but I expect they will approach the productivity that I grew accustomed to with Silverlight and Flex. The levels of abstractions will be higher and the tooling will be richer. I expect that we will start to approach similar developer/designer workflows that were so amazing in the SPA days. I expect we will see multiple language integration, including debugging and profiling tools built around these frameworks. They will feel much less like a web framework and more like a desktop development framework. The user experiences we create will be comparable to the experiences we created with Flex and Silverlight.

Paying Back the Debt

The funny thing is that we will have taken 5 years to get there. It will be 5 years of stepping out of the plug-ins and into the browser so that we can achieve the same quality of application that we were already producing. In some ways, it feels like a regression, but we have to realize that the plug-ins were really just a disguised form of technical debt. They provided a one-off environment so that we were able to do things that weren’t possible in the browser, but they did so by not investing in the browser. Ultimately, the browser is the platform we were headed towards so we incurred debt. We just have to pay it off before we can really innovate again.

Conclusion

I’m excited to see where the future of front-end development goes. I’m excited to see that great strides are being made and I am happy to be at the front of the wave. The community is starting to get excited too. Here in Ann Arbor, we will be kicking off a JavaScript user group very soon which will give us a place to discuss these technologies and approaches. I look forward to chatting it up!

On a personal note

This is my last blog post written for SRT Solutions. I am moving on to something new. More on that soon.

On the 10th, we built on the foundation we created on Tuesday. We spent the entire evening coding. The event was supposed to end at 10:00. Everyone asked for “15 more minutes to finish a couple cards”. Two hours later, at 12:30 am, we finally left. The best part was that we had finished the key features we came to build. Tony Surma, Microsoft’s CTO for disaster relief response said, “if a disaster hit tomorrow and I deployed this, it would get used already. It’s better than what’s in the field today.” A lot of credit goes to some very dedicated people.

First and foremost, credit goes to the conference attendees that were part of the hack a thon both nights. We didn’t know what to expect, and as a result, we’ll plan better in future. The folks were patient, and helped us drive the forward. We got great ideas, lots of energy, and most of all: Working Software.

Also, a quick tip of the hat to Aaron Skonnard and Pluralsight. Everyone that participated by making at least one checkin got a free month subscription to the entire Pluralsight library. Selfishly, I hope they learn more, and help us build more software for Humanitarian Toolbox. (Disclosure: I’m working on my first Pluralsight course.)

Brian Randell did a lot of behind the scenes work to setup web hosted TFS for us. He also helped us test and work with the Git TF bridge so attendees could use whatever they felt most comfortable with. (And, he helped me get more familiar with TFS and it’s features.  He was a great help.)

Three people deserve extra thanks: Ward Bell, Julie Lerman, and John Papa. The team wanted to apply what they were learning at the conference, and selected breeze, HotTowel, and Entity Framework Code First for this project. John, Ward, and Julie all gave up quite a bit of time to help. They paired with attendees, explaining as they coded, or guiding their pair (sometimes me) around the code and libraries involved. Pure bliss: Learning and building super useful software at the same time.

For examples of what they did, John told me he and Ward would “try to stop by for about 10 or 15 minutes” to help a bit. They were both helping for at least two hours. Julie stayed until she was in jeopardy of missing her flight. (She did make it).

We had quite the cast of characters show up and ask how they can get involved as this continues over time. At future events, you may see Phil Haack, Scott Hanselman, Damien Edwards and other familiar names helping out. All of those said they would have helped this time, had they known more about it earlier in the process.

I can’t close this “thank you” section without mentioning three other very important people. Mari Sessions took on every task that doesn’t involve code (she’s got a business background, not a developer background). I have no idea where she gets that much energy. She organized the room, promoted the event, walked up and down the halls asking random conference attendees if they wanted to participate. Arranged refreshments, made everyone feel welcome, and made the event happen.

Tony Surma, Microsoft’s CTO for Disaster Relief, kept us focused on the problem at hand. He’s gone to disaster sites and written code while in the field. His experience and knowledge of disaster zones and the problems relief workers encounter in the field was invaluable. I’d be remiss if I didn’t mention that he’s also a super smart tech guy, and can just pitch in and make things work.

Also, an extra hat tip to Microsoft.  They are providing free TFS hosting, Azure hosting, and other help supporting the effort. Furthermore, they are not mandating any technology decisions that we make. They are being a great partner to help us build software to solve real problems.

And finally, without Richard Campbell, this doesn’t get off the ground. I’m thrilled to be working with Richard on this. The reason is simple: when Richard gets behind an idea, things happen. Ideas turn into action. Tony started using the phrase “turn innovation into impact.” That sums up Richard’s contributions well. What we started only has meaning when it gets in the hands of real relief organizations during a (sadly) real disaster. When that happens, real lives are saved because those relief workers can do more. Richard brings energy, drive, and makes it happen. I’m glad he invited me to join.

Finally, this last week can’t be a one time event. It’s got to be the start of long term commitments to create software that helps relief organizations respond to disaster events. Richard, Tony, Mari and I will be meeting in the coming weeks to go over what we learned. We’re going to push code into release cycles. We’re going to plan more events. We’re going to create a plan to involve more people.

Join us:

When disaster strikes, code saves lives. If you’re interested, signup at humanitariantoolbox.net and well keep you informed.

We didn’t really know what to expect.  Would conference attendees give up a free night after a day of learning new technologies to build more software?  Thankfully, the answer was yes.  We had a great team of developers helping us start building a crisis checkin system for disaster relief workers.  I’m confident that if we get some of the right people to attend tonight, we have a chance to make significant progress on the user stories for our first sprint. It was great to see developers that hadn’t even met each other sit down, discuss designs, create code, and help us build software to make disaster response more effective.

There were three key events that make me very excited about where this can go:

1. We were starting from nothing, and this morning we have working software.
2. The folks that came wanted to apply what they’ve learned at DevIntersections to this project (more below).
3. We continued to get commits after we all left at 10:00 pm.

One of the main sessions yesterday was JavaScript Jumpstart, where he explained his HotTowel template to attendees.  Our first app is using the HotTowel template. Thanks to John Papa for creating a great framework, and inspiring the team.

The big goal is that this is the start of something.  It’s not a one time event.  We need to continue building software, creating real applications that real relief workers have asked for.  We’re using innovation to create real impact in real disaster situations.

We’ve got another session tonight at DevIntersections, where we plan to finish the user stories that are in progress. If you’re at DevIntersections, please come by and help.  If not, don’t worry.  After this hack-a-thon, we’re going to open the source control system and the task board to everyone. We’ve got a few tasks to get done to make that happen, but we’ll get it done.

Overall, I’m really impressed with the beginning we made.  I’m constantly impressed by the commitment, dedication, and contribution the software development community will make.  We are asking developers to give up their free time to build software that aids relief workers. We are getting great response.  I’m excited to see what we’ll build next.

I’m excited to be part of a new opportunity for developers to help others: The Humanitarian Toolbox.

The Humanitarian Toolbox  is the brain child of Richard Campbell, of .NET Rocks fame. The concept is to have developers create Open Source software projects that solve real problems for disaster relief organizations. A group of people, including Richard and I, have been working with global relief organizations to determine what they need most. We’ve already got a list of more than a dozen application ideas.

It’s time to start building. We’ve picked the first project: a relief worker check-in system. This system would enable relief workers and volunteers to check-in and check-out at a disaster site. The field coordinators would have better information about the skills and the availability of relief workers, enabling them to better deploy the people that have volunteered their time to help. Relief workers and volunteers would get assignments and locations directly on their smartphone. The end result will be that relief workers are more efficient while on site, and more lives are saved.

We need developers that want to build this app.

Humanitarian Toolbox is hosting a hack-a-thon at DevIntersections. I’m working to organize the event, and help organize developers (like you) interested in participating. We plan to create a small proof of concept for the relief worker check-in system during the hack-a-thon. After the initial hack-a-thon, we want to enlist the broader community to continue building the app.

What’s our deadline? We’d like it in place before the next natural disaster happens. We don’t know when that will be, so we’d like to keep building and have it ready as soon as we can.

If you’re going to be a DevIntersections, join us. Contribute your talent and help relief workers save lives. If you’re not going to DevIntersections, there’s still plenty to do to help. Follow us on twitter: @htbox or the hash tag for the event: #HtBox. We’ll have plenty more software to build after the hack-a-thon. For us to be successful, we’ll need to keep building and enhancing software for relief workers to battle the next crisis.

Write some code, help the world. Contribute to Humanitarian Toolbox.

In other words, we hope to lure you in!

The meeting will be held at SRT Solutions, 206 S. Fifth Ave., Suite 200, Ann Arbor, MI. It’s free and open to the public, but please RSVP on the meetup site so we will know how many folks are coming. You never know. I might bake cookies. Or not.

The speaker:

Dianne Marsh (yes, that’s me) will be speaking on Wednesday night. I  will be actively recruiting additional speakers for upcoming meetings, so please volunteer!  We already have a speaker for our April 17 meeting, but will be recruiting for meetings after that!

The Ann Arbor Scala Enthusiasts will meet at 6 pm on March 20, 2013, at SRT Solutions, 206 S. Fifth Ave., Suite 200, Ann Arbor, MI 48104. The meeting is free and open to the public. Please join the meetup group and RSVP if you are planning to attend so that we can gauge interest and tailor content.

At my CodeMash precompiler, I mentioned how the C# compiler ensures that methods marked with the ‘async’ keyword that contain ‘await’ expressions never throw synchronous exceptions. Instead, those methods will return a Task (or Task<T>) that will be placed in the faulted state if the method throws an exception. The compiler does the work to add the appropriate try/catch clauses to your methods, and translates any exceptions thrown during your method’s execution into returned faulted task.

Jon Skeet was concerned by this strategy. He felt that API designers would prefer throwing synchronous exceptions for obvious programmer errors (things like ArgumentNullException and so on). I mentioned that the language specification defines that async methods will returned faulted tasks; they will not throw synchronous exceptions.

Of course, there is a way around this. You have to separate your public async APIs into two pieces: A public synchronous API that does parameter validation and state validation. This synchronous method then calls an internal async method that does the asynchronous work.

As an example, consider this (rather contrived) async method:

public async Task<string> FizzBuzzAsync(int val)
{
    if (val <= 0)
        throw new ArgumentException("We can't fizzbuzz negative numbers, or 0");

    await Task.Delay(250);
    var rVal = string.Empty;
    if (val % 3 == 0)
        rVal += "Fizz";
    if (val % 5 == 0)
        rVal += "Buzz";
    if (string.IsNullOrWhiteSpace(rVal))
        rVal = val.ToString();
    return rVal;
}

Calling this method with a negative number is a programming error. We’d like to have that condition throw a synchronous exception. We can achieve this by separating the method into two parts. The first part is a synchronous method that performs the parameter validation and state validation. The second part is an internal method that performs the asynchronous work.  The first method will throw exceptions synchronously. The second will report errors using a faulted task.

public Task<string> FizzBuzzAsync(int val)
{
    if (val <= 0)
        throw new ArgumentException("We can't fizzbuzz negative numbers, or 0");
 
    return FizzBuzzAsyncImpl(val);
}
 
private static async Task<string> FizzBuzzAsyncImpl(int val)
{
    await Task.Delay(250);
    var rVal = string.Empty;
    if (val % 3 == 0)
        rVal += "Fizz";
    if (val % 5 == 0)
        rVal += "Buzz";
    if (string.IsNullOrWhiteSpace(rVal))
        rVal = val.ToString();
    return rVal;
}

That ensures that your public async methods conform to both important rules.

First, TAP (Task Asynchronous Pattern) methods do not allow synchronous runtime exceptions. They must return errors by returning a faulted task.

Second, to make it easier for callers to detect and correct programming errors, simple programming errors will throw synchronous exceptions.

I’ll report throughout the week, but for those who might be curious what we do here, I’m posting the “Master Schedule” below.

Sunday

6pm: Welcome Barbeque.

Monday

Hackathon Day workshops 

9:30 pm at the Majestic Theatre: “Possibilities”: A selection of TED Talks Designed to Inspire New Thinking, presented by the Java Posse Roundup. Free admission, all are welcome.

Tuesday

8:30am:
Conference Overview
Introduction to Open Spaces
Initial talk topics and organization
Session 1
10:30am-12:00pm: Session 2
Afternoon: lunch/hackathons/free time
Evening: Groups go to dinner or informal barbeque & discussion
Lightning Talks 8pm – 9:30 pm
End the evening with private gathering at Princess Wine Bar.

Wednesday

8:30-9:30 am: Session 3
10:00-11:00am: Session 4
11:30-12:30pm: Session 5
Afternoon: lunch/hackathons/free time
Evening: Groups go to dinner or informal barbeque & discussion
Lightning Talks 8pm – 9:30 pm
End the evening at the Dogwood Cocktail Cabin.

Thursday

8:30-9:30 am: Session 6
10:00-11:00am: Session 7
11:30-12:30pm: Session 8
Afternoon: lunch/hackathons/free time
Progressive Dinner (5 pm?).

End the evening at the Lobar with Karaoke.

Friday

8:30-9:30 am: Session 9
10:00-11:00am: Session 10
11:30-12:30pm: Session 11
Afternoon: lunch/hackathons/free time
Dinner at either Django’s or the Yurt (x-c ski or snowshoe to get to the Yurt, rentals at Nordic Center)