NYC Code Camp Saturday 9/13/2013 – Simplicity Is Genius

Saturday I will be attending my first New York City Code Camp (@codecampnyc ). I’m traveling thousands of miles to help you make you a better you. I’ll be doing the talk “Simplicity Is Genius”. Looking at the list of sessions this is the ONLY real Soft Skills session on the menu so I really encourage the New York faithful to attend. If you don’t come you are doing yourself a disservice. Putting technical content in the brain is great but you need to work on YOU some as well.

In this session we’ll take a break from code and focus on the other skills developers need called Soft Skills. We’re going to go deep on what "Simplicity is Genius" really means from the eyes of Forrest Gump and look at many of the life lessons Forrest was trying to teach us in the movie. After attending this session you will learn the value of providing value, how to better communicate with team members, the importance of being nice, and how to leverage techniques used successfully by salesmen backed by scientific research so you can ultimately… tell IT like Forrest Gump.

MIGANG Wednesday 9/18/2013 – Web Applications Re-Imagined for Today’s Demanding End Users

After CodeCampNYC I’ll be heading to Detroit to work onsite for the week. The timing works out so I can make the MIGANG on Wednesday night. I’m really looking forward to it and stressing at the same time as I’m giving a brand new talk entitled “Web Applications Re-Imagined for Today’s Demanding End Users”. If I can pull everything off I want this should be fun, enlightening, dangerous, scary, exhilarating all at the same time.

In this talk we are going to take an extreme departure from a typical three-tiered web application and look at how we can leverage asynchronous messaging, queues, and events in exciting ways.  We’ll be architecting a web application utilizing SignalR, TopShelf, Asp.Net, RabbitMQ, and ServiceStack to create a scalable, highly available, buzzword filled, real-time web application.  We’re going to look at how we’ll handle long running business processes that cross service boundaries using command queues and events to push notifications back to our end users. We’ll learn that we’ve actually made our application stronger, faster, and simpler to write (even transactional when we need it). In the end we’re going to try to break our application to find out if it is truly Engineered to Amaze.

If you are in the area I hope to see you at either event, don’t forget to say hi!

Prepare the crawdads and gumbo because I’ll be in Baton Rouge, LA this coming Saturday doing some talks at the SQL Saturday #234 event!

I’m planning on doing two talks Saturday as well as recording some http://deepfriedbytes.com episodes if time willing.

Here’s the talks I’ll be giving and more about them.

Channeling Your Inner Forrest Gump – Simplicity is Genius

In this session we’ll take a break from code and focus on the other skills developers need called Soft Skills. We’re going to go deep on what "Simplicity is Genius" really means from the eyes of Forrest Gump and look at many of the life lessons Forrest was trying to teach us in the movie. After attending this session you will learn how to better communicate with team members, provide value not only to your business but also your profession, the importance of being nice, and how to leverage techniques used successfully by salesmen backed by scientific research so you can ultimately… tell IT like Forrest Gump.

That’s right, I’m bringing the GUMP to Baton Rouge. No prerequisite required to attend this talk and you don’t even have to be a developer! I gave this talk at DevLink a few years ago as the keynote and I’ve given in another time or two in smaller settings and each and every time I give it it hits home with many in the audience. You don’t want to miss this one I promise.

Building an English-Based Rules Engine using the Dynamic Language Runtime and IronRuby

In this session we will explore writing an English-based rules engine that allows developers to create domain-specific rules for an application that can be easily understood by anyone. We will use a combination of C# and the DLR (dynamic language runtime) with IronRuby on the .NET platform to create a way to write, manage, and process rules for an application.

If you’ve ever wanted a simple way to store and process business rules whereby you can still read them come to this talk. It is geeky, it is fun and practical. We’ve already created four different interfaces to this at work and are using it in production (with some enhancements of course) so it isn’t just theory.

Hope to see you there and feel free to follow http://twitter.com/sqlsatbr via Twitter.

As promised at CodeMash to those that attended my session I finally am getting around to getting the slides and demo from my talk posted to my web server. You can download everything at this URL location:

http://keithelder.net/Presentations/RulesEngineWithIronRuby/RulesEngineWithIronRuby.zip 

What you will need to run the demo:

• Visual Studio 2010

To run the demo you should be able unzip it, open it up in Visual Studio and hit F5.

Once the demo opens you’ll be presented with this.

In the middle of the screen you’ll see sample rules for the survey already loaded.

To convert these rules to Ruby script click on the “SurveyRuleSet” option listed under “Rule Sets”. This will load all of the available rules for that rule set.

Once you have the rules loaded for the SurveyRuleSet you can then click “Convert To Ruby Script” button and the English text in the middle of the page will be converted into Ruby Script.

Once you have the Ruby script generated click the “Use Script in Survey”.

This will open a form that has questions and answers.

Once the form is open just press “Submit” and the rules will fire. You can close the form, change the rules, re-gen the script and then re-run the form to see new rule values run.

When the “Submit” button on the Survey form is called, this is when the IronRuby engine gets invoked.

You can also load the SouthernRuleSet and then load the pre-typed Southern rules to see a “Southern DSL” of the same rules.

In Visual Studio you can open the SurveyRuleSet.cs file and uncomment the other attributes to enable Spanish instead of English (just as an example).

DISCLAIMER

What you should try to take away from this the most are what it is doing and what is possible. We are running something very similar to this in production so this isn’t smoke and mirrors. There are a lot of things that are missing in the demo, but they are completely doable with some additional work. For example grouping isn’t done in this example, other rules like greater than, lesser than etc could all be added to the base ruleset class. Use your imagination and go wild.

Enjoy.

http://tinyurl.com/deepfried63

In this episode we sit down to discuss Multiparadigmatic C# with Ted Neward.  Yes it is a long word but C# has grown from “just” an object-oriented language into a language that is capable of expressing several different paradigms of software development: object-oriented, functional, and dynamic.

For the past week or so I’ve been working on wrapping the Sonic API to simplify it for developers at my company.  The API itself is pretty much a straight port from Java.  There is nothing C# about the API.  For example no enumerations, no generics, no nothing.  This means when you are using the API you see functions that take a parameter that is just an integer since there are no enumerations for example.  That wouldn’t be so bad if the code was documented in the proper C# way but it isn’t.  So, instead of having 100+ developers at work learn how Sonic works I have been coding up several scenarios that we need to support for the business. 

In my quest to wrap the Sonic API into a more C# centric approach I needed to write some tests obviously to make sure things were working.  Primarily these are integration tests as each test relies upon connecting to a Sonic dev environment. 

If you aren’t familiar with Sonic it is an enterprise messaging platform.  It does pub/sub, supports queues, fault tolerate and so on.  I think the stock market even uses Sonic to route messages so it has a proven track record. 

One of the scenarios I had to cover was I needed to send a message to a queue and then have that message pulled out of the queue on the other side, processed and acknowledged.  In order to do this there is one object that sends a message, and another object that is listening for a message(s).   But how do you write a test that waits on an event to happen?  Well, it turns out we’d done this before in other tests but I couldn’t for the life of me remember how.  So here’s how it works. 

Using an EventWaitHandle we can wait on an event to occur.  First is to create a handle.

   1: EventWaitHandle handle = new ManualResetEvent(false);

Using the handle we can tell it to WaitOne() which blocks the current thread until the WaitHandle receives a signal.

   1: handle.WaitOne();

Then inside our event we simply call handle.Set() (this is the signal). 

Putting all of this together we can write an integration test that sends a message to Sonic and then waits for that message to come through.  Obviously the Sonic piece doesn’t really matter, the important piece here is how to get a test to wait for an event.  Putting it all together it looks like this.

   1: [TestMethod]

   2: public void Can_Send_To_Queue_And_Receive_Message_From_Queue()

   3: {

   4:     EventWaitHandle handle = new ManualResetEvent(false);

   5:     SonicQueueSender sender = new SonicQueueSender(Helpers.SonicQueueArgs);

   6:     string sendMsg = "test";

   7:     sender.SendMessage(sendMsg, SonicDeliveryMode.NonPersistent);

   8:     SonicQueueReceiver consumer = new SonicQueueReceiver(Helpers.SonicQueueArgs);

   9:     string receiveMsg = "";

  10:     consumer.MessageRecieved += (mySender, args) =>

  11:         {

  12:             TextMessage txtMsg = (TextMessage)args.Message;

  13:             receiveMsg = txtMsg.getText();

  14:             handle.Set();

  15:         };

  16:     consumer.StartListener();

  17:     handle.WaitOne();

  18:     Assert.AreEqual(receiveMsg, sendMsg);

  19: }

Hope this helps someone out.