Johnny Halife’s Blog

Yesterday, Lito & I gave a presentation on the SQL Server Data Platform at Code Camp 2008 in Buenos Aires, Argentina. I’m really happy that the conference got really crowded, with people even sitting on the floor. I have really enjoyed what our presentation, and when it was over I got that felling of happiness because I was really satisfied with what we have done.

Briefly for those who didn’t attend the presentation, we talk about the how our storage needs is getting bigger and bigger, also who does SQL Server Platform help us to handle the data across that we have everywhere. One of the major points of our presentation was the Sync Framework. We have discussed different scenarios for synchronization including hub-based synchronization and peer-to-peer.

 I hope that people have enjoyed it as much as I did, and hopefully see you all again very soon. Besides the technical stuff of the presentation Code Camp was an event where I’ve seen too much friends from the industry that you don’t see every day all together at the same place. It was really cool, we had discussions technical discussions around almost everything.

For those who have attended our presentation here is the material we have shown, including some backup slides that discuss deeper some of the topics we have shown like SQL Server Data Services, and  Microsoft Sync Framework. Feel free to ping me with questions and possible application scenarios.

Additional Material

These are the backup slides included on the presentation that we are posting here for you to download.

NOTE

All the presentation material and its supporting material is written in Spanish which was the native language of the event, please if want the presentation in English don’t hesitate contacting my for a translated copy.

Last week I was discussing with Matías about the implementation of DFO (Design For Operations) for a system we are building at Southworks. Our discussion took us to an Ayende’s post that talks about Logging The AOP  Way for .NET. At that moment we thought that’s what we want.

Later on, reading ScottGu’s blog, we realized that a filtering pipeline has been built for the ASP.NET MVC, so we thought about mixing what ScottGu’s blog says to achieve what Oren’s was posting on Logging the AOP Way.

I have divided this post in two parts, the first is the conceptual part where I’m going to discuss a little bit about the Filtering model of ASP.NET MVC and then I’ll show a little how-to build a custom tracing filter.

What are ASP.NET MVC Filter Interceptors?

As described in ScottGu’s post Action Filter Attributes are declarative way to inject code that can be executed pre and post controller’s action execution. Also the same can be done for pre and post ActionResult conversion into an ASP.NET response. This enables another way to do AOP and achieve for example the logging described by Oren’s at his post.

How do they work?

In order to understand how do they work let’s analyze how does the ASP.NET MVC pipeline goes. Below is a diagram that demonstrates how does an action flows from the HttpRequest until the ActionResult gets executed.

Now, let’s go one by one the items diagrams and I’ll try to explain what’s happening on each part:

1. The user makes a call using the browser.
2. Given the URI of the request the ASP.NET MVC Handlers looks for the appropriated controller using the Routes configured on the Global.asax. Prior instantiating the controller a ControllerContext is created. It wraps ,among other things, the current HttpContext for a given request execution.
3. The ASP.NET MVC engine, instantiates the appropriated controller passing the current context as a parameter.
4. The controller executes the action that correspond to the current Route.
5. As a result of the Action execution an ActionResult is returned to the context, given the ActionResult implementation type (must inherit from ActionResult) it might be turned into a View (ASPX Page) or JSON as an example.

Now that the baseline execution context is a little bit dissected let’s explain where does the ActionFilter attributes hook to this model.

The items squared with black on the diagram above are the hooks that can be used to inject the code. Those are the interaction points where we can create our hooks and perform crosscutting operations like logging, tracing, error handling and even authZ and authN.

• OnActionExecuting. The ActionExecuting contains all the data about the action that is going to be executed prior its execution.
• OnActionExecuted. The ActionExecuted contains all the data gathered after the action execution.
• OnResultExecuting. The ResultExecuting contains all the data about the ActionResult that is going to be executed. Two of the differences that you will find between this and the previous hook are:
  • If the Action execution ends in an exception you  might not reach this point.
  • If the user called for example "View()" which renders the default view for that action, in the previous one you don’t know the view name.
• OnResultExecuted. The ResultExecuted contains all the data gathered while the ActionResult was turning into an ASP.NET Response.

Up to now we understand how does this ActionFilter pipeline works and which data we can get from it. Now, you might be wondering how do you get this in your code. It’s just simple as decorating your Controller and/or Action with the desired Action Filter attribute.

[TraceFilter]
public ActionResult Index()
{
    ViewData["Title"] = "Home Page";
    ViewData["Message"] = "Welcome to ASP.NET MVC!";

    return View();
}

In the example above I placed a custom attribute called TraceFilterAttribute that is a custom Filter I have created for demo purposes. Wondering how? Read below!

Do it yourself, your own ActionFilterAttribute in 5 minutes.

In this section we will discuss how to create a custom attribute. This attribute will trace the calls to the controller and log them like:

The log entry above displays the Date Time the entry happend, the warn level [Debug ||  Fatal || Error || Information] and the parameters if they were any.

Step by Step sample

1. Open Visual Studio (ASP.NET MVC works on Web Express versions of VS2008).

2. Create a new ASP.NET MVC Web Application and name it as you want.

3. Using the Solution Explorer, create a folder on web site’s root and name it Filters.

   
   
   (Figure 1. - Filters folder on Solution Explorer)

4. Add a new Class file and name it TraceFilterAttribute.

5. Delete the TraceFilterAttribute class declaration from the file.

6. Inside the namespace declaration, use the attribute code snippet to create the attribute structure.

   

   (Figure 2. Using the Attribute code snippet). 

7. Name your attribute (using the snippet) TraceFilterAttribute and make it inherit from the ActionFilterAttribute.

   [AttributeUsage(AttributeTargets.All, Inherited = false, AllowMultiple = true)]
   public sealed class TraceFilterAttribute : ActionFilterAttribute
   {
   }

8. Copy and paste the code below inside your class declaration

   public override void OnActionExecuting(ActionExecutingContext filterContext)
   {
           StringBuilder builder = new StringBuilder();
           filterContext.ActionParameters.ToList()
                                         .ForEach(a => builder.AppendFormat("{0}:{1}; ",
                                                                            a.Key,
                                                                            a.Value ?? "{empty}"));
           var parameters = builder.ToString();
   
           var message = string.Format(CultureInfo.InvariantCulture,
               "{0} {1}.{2} => {3}",
               filterContext.ActionMethod.ReturnType,
               filterContext.Controller.GetType().Name,
               filterContext.ActionMethod.ToString().Replace(filterContext.ActionMethod.ReturnType.ToString(),
                                                             string.Empty)
                                                    .Trim(),
               string.IsNullOrEmpty(parameters) ? "(void)" : parameters);
   
           this.logger.Debug(message);
   }

9. The Logger used above is using Log4Net, which provides and easy and configurable way to do logging.
   
   
10. In order to configure the logger (once you have added the reference to Log4Net) copy and paste the following to your section declaration in your web.config.

    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" requirePermission="false"/>

     
11. Now include this other chunk of XML before the </configuration> tag.

    <log4net>
      <!– The DebugFileAppender writes all messages to a log file–>
      <appender name="RollingLogFileAppender" type="log4net.Appender.RollingFileAppender">
        <file value="logfile.txt" />
        <appendToFile value="true" />
        <rollingStyle value="Size" />
        <maxSizeRollBackups value="-1" />
        <maximumFileSize value="50GB" />
        <layout type="log4net.Layout.PatternLayout">
          <conversionPattern value="(%date) [%-5level] %message%newline" />
        </layout>
      </appender>
      <root>
        <!– add other appenders here and the log messages will be sent to every listed appender –>
        <appender-ref ref="RollingLogFileAppender" />
      </root>
    </log4net>

     
12. In order to consume the logger using Log4Net copy and paste the following code inside your class declaration

    private ILog logger;
    
    public TraceFilterAttribute()
    {
        XmlConfigurator.Configure();
        this.logger = LogManager.GetLogger(typeof(TraceFilterAttribute));
    }

     
13. Now that we have built the attribute, let’s apply it to the Index() method on the HomeController.cs . Your code should look like this:

    [TraceFilter]
    public ActionResult Index()
    {
        ViewData["Title"] = "Home Page";
        ViewData["Message"] = "Welcome to ASP.NET MVC!";
    
        return View();
    }

14. Press F5 and you will see the default MVC home page.

     
    

15. Now go the web application project directory and look for the logfile.txt.

16. Open the logfile.txt, it should look like this

     

17. That’s it , you’ve built your own Action Filter Attribute.

One more little  trick

You might want to turn this sample into something for real, there’s a trick that will enable you do the tracing just if debug is enabled. All that you have to do is surround the OnActionExecuting method body with the code depicted below.

if (filterContext.HttpContext.IsDebuggingEnabled)
{
    // The method body goes here.
}

Now, your attribute will log data just if the Debug mode is enabled on the web.config of your application.

<compilation debug="true">

Conclusion

We’ve learnt how to develop a custom Action Filter Attribute. This is a very powerful and cool feature of ASP.NET MVC. This enables you to do logging, tracing and exception handling. I love this approach of doing AOP with Interceptors and the most that I like that is built in to the technology. There’s unlimited power on this, but remember a great power also means a great responsibility.

thanks,

~johnny

While attending some CMMi courses that we held at Southworks, and reading some papers about re-work written by Watt Humphrey and the CMU-SEI crew, I started thinking about how to avoid rework and what do I do to avoid re work while coding.

I realized while asking myself a couple of questions and analyzing the code review results for the reviews I conducted that most of the people make the code work, check the code in and then start caring about the quality of that code. For example most of the people check in code that doesn’t meet the code standards and then they do another check in in order to fix those.

I came up with 10 do’s and don’ts while coding that helped me understand how to avoid rework and ensure the health of our deliverables on every check in.

10 Do’s and Dont’s to avoid quality rework

These do’s and don’ts aren’t a silver bullet but they may help you as a strong starting point for avoiding rework on quality related subjects.

Do check-in often

As Alex always says Software Development is a team sport played by talented individuals. While you keep your code in your local machine you’re also putting a barrier between your work and the rest of the world’s work. Doing check in often helps you on integration, avoiding conflicts and even better gives the team visibility on where are you in terms of what you committed to do. In the other hand if you don’t commit often, be prepared to spend half a day fixing the code to avoid conflicts.

Do run StyleCop each time you modify a source code file

Code Standards are something big to be treated on another post by itself but as summary I’ll say that in Southworks we chose the working software over the comprehensive documentation as the Agile Manifesto states.

We have chosen to use Microsoft’s StyleCop to validate our code standards. Most of the code that we write often goes public, and it’s important to demonstrate that we follow a single line of thinking and the code has signature that differentiates it  from others code but also that the code is written in the same way by all the developers on the company.

In order to accomplish this, is as simple as doing right click on the source code file in Visual Studio and then Run Source Analysis. It won’t add an overhead to your regular coding routine but will ensure that the code is written on a consistent fashion the first time.

How to run source analysis

Do run Code Analysis prior every check in

Code Analysis (a.k.a FxCop) is the tool that validates the best practices of the Microsoft.net Framework. It’s based on the book written by Brad Abrams and Krzysztof Cwalina. The best practices described there were ported to an application known as FxCop.

Following Code Analysis guidelines ensures that our code is leveraging the Microsoft.net framework in the best way it can be done. And the same as Style Cop (a.k.a Source Analysis) it can be done by doing right click on an assembly in Visual Studio and then choosing the Run Code Analysis option from the context menu.

Again, doing this the first time is better than reworking the code and re committing to the main line twice in order to do it and then to fix it.

How to run Code Analysis.

Consider branching out code that may introduce risk to your deliverables

This is pretty obvious, sometimes you think a problem can be solved using some kind of approach that might have an impact on others work. The solution there is to branch the code out and don’t introduce the risk while you’re not sure that this will be the final solution or at least that your solution works.

Why is this? Some people might choose to keep it outside the source control but experience tell us that no source control will turn into something painful if something happens.

I’ll write another post about GIT which leverages this by having a local repository for each developer but that’s another story.

Do not forget the commit message

Look at the log above what can you tell about what’s going on on the project? If you don’t include a comment, a note, a reference to a requirement or something that states what are you committing you can get your team in trouble if you have to do any rollback or review of the requirements implementation.

It’s a 1 minute thing to say what are you committing and why are you committing, that also forces you to think what problem, requirement or commitment are you closing with that check in.

Do be polite with the Integration Server

This one is loved by my friend .jpg who is our Build Server & Tooling ranger. People often get confused with the intent of an Integration Server. The Integration Server is used to verify that there’s harmony in your repository, it’s not your tool to validate your code against. You should verify your work against it but don’t use it processor cycles to do your validation work.

Our build process is complex enough that might take at least 2 minutes to build a project, people often think that is the Integration Server responsibility to validate your process. Truth to be told, the intent of the Build Server is just to verify that there’s no integration problems and that all the code follows a standard.

Although the quick feedback is the most important part of the build server, you should have in mind that is a verification of work and it doesn’t do the validation you’re supposed to do.

Do not check in prototype quality code to your main line

I won’t go further on this one, I recommend you to read I.M Wright’s post about Prototyping that he just posted. As an spoiler I can tell you that the title gives a clear message “My experiment worked!”.

Do not check in until all tests pass

This one seems pretty obvious, I wrote a post about TDD last week and most of the people nowadays are adopting this practice. The important thing and a killing feature of TDD is that you are a click away of doing regression testing on all the code and check that nothing got broken with your changes.

Sometimes you get green on yours and then just wait to the Integration Server or another developer to complain about your work. This is the case where you should be polite not only with the integration server but also with your co-workers making sure that nothing is broken because of your changes.

NOTE: If you are running a huge solution with thousands of tests you might want to run just those hundreds tests on the impact surface of your code.

Do ad-hoc peer reviews to validate your logical thinking

Two pair eyes of eyes see better than just one. That’s the rationale behind this point. Developers (and I include myself on the subset) love to put their headphones, enter their matrix kindda world and write code as the music moves forward. But as I said on the first point Software Development is a team sport and a team that cooperates is by far more candidate to win.

Do not wait until the formal Code Review comes up to you and you have to explain what you’ve done. Just put pause on iTunes for 5 seconds, ask your nearest team member (doesn’t matter his expertise always there’s something good to learn from our peers) what does he think about your idea and that’s it. You just had a peer review.

Do be consistent and disciplined while applying the nine practices above

Now you know it, but the practice makes the master. Fasten your seatbelt and get ready to improve your personal development process. You and your team will be happy to share a principles in terms of quality so your code is nice, easy to maintain and well written.

And your team as all the famous painters will have a code signature that will distinguish yourselves from the rest of the mere mortals.

And in the end….

One thing that I’ve learnt from people that have years working on Software Quality and people that I met like Eric Brechner (Microsoft Engineering Excellence Director) is that the most important thing when talking about Software Quality is defining done. If you follow these simple steps you will be closer as a team to produce code in a standard and consistent basis while starting to define the meaning of done for code.

thanks,
~johnny

On July 25th Dr. Randy Pausch PhD, lost the fight against the Pancreatic Cancer. The brilliant mind behind "The Last Lecture" was 47 years old. Before leaving Randy left an amazing legacy on the "Last Lecture".

The "Last Lecture" has even more hits than the all time famous "Stay foolish, stay young" talk given by Steve Jobs at Stanford university. The talk is about achieving your childhood dreams, about how to live your life in order to always have fun.

The talk began with "What would you say if you knew you were going to die and had a chance to sum up everything that was most important to you?" and after that all his wisdom got revealed.

I knew his lecture since it was recommended on the Wired magazine that I love, those sitting around saw me almost crying while I was watching it. It’s a lesson learnt by one of the most gifted people I ever seen.

Besides all the fashion and post-mortem merchandising that will appear now that he is gone, I sincerely recommend you to go to YouTube.com and watch the video.  Also the Carnegie Mellon Univesity set up a memorial page for Dr. Pausch and a great article about his legacy.

I’ve shared it couple of months ago on our internal distribution lists, but now I’m doing it publicly so everyone can learn something from one of the greatest minds of the 21st Century.

thanks,
~johnny

Almost form the beginning of my blog,  I started writing about Test-Driven-Development [1] [2] [3] [4] [5] that now was renamed by the Agile Gang  as Behavior Driven Design. That new name is kind of cool and fancy (Oh these agilists always looking for new adepts) but there’s a truth and a strong rationale behind what they call BBD.

I wrote this post after a long time practicing TDD, this Truths and Myths are based on my personal experience and the knowledge acquired with time. You might disagree with some, you will love others, but this post is an exercise for my self trying to dump all what I’ve learnt in these years practicing TDD.

I’ve divided the post in three parts:

• Myths. These are the things I heard while working as consultant, stuff that showed up while discussing with colleges or things that came up while discussing with friends.
• Truths. These are almost the same as above but mostly positive things that demonstrate that there’s value on applying this practice.
• My TDD Zen Garden. This are tips and tools that I used while doing TDD, they’re not mandatory or maybe part of the official practice. There I’m just sharing my personal tips and thoughts.

5 Myths about TDD/BDD

Myth 1: “Tests are for testers”

That’s my favorite one, when people don’t understand TDD or are just too lazy to write the tests they claim for the “Test is for testers”. Although the name has the word test, it doesn’t necessarily means that your testing as a tester would do it.

Myth 2: “Oh buddy, if I wrote them it’ll take me twice”

Ok some people think about writing the tests first as some kind of time consuming, useless, non-sense activity. Those that think like that are often the ones that never thought or read about Re-work  there are some great papers from Watts Humphrey and CMU-SEI Crew about this. If you had the tests to validate and verify your work, you’re one step closer to avoid rework.

Myth 3: “I’m bug free , I had 100% Code Coverage”

This might be controversial,  but after doing some deep thinking on this and listening to Scott Hanselman podcasts, I realized that 100% Code Coverage isn’t the best. Code Coverage is a negative metric, it’s about where we should focus are testing intentions based on what we’ve left uncover. As far as I researched, there’s no tool to measure code coverage by paths (this can be fairly accomplished by hand). So 100% isn’t bug free.

Myth 4: “If I apply incremental design techniques based on TDD, I end up just with a huge test method”

That’s more than a Myth, that’s a mistake, when doing TDD it’s always a matter of starting to cross tests from the lists. People often think that as the method to be tested evolves the original test evolves with it. Well, for me it’s that as you move forward you add new tests. So your fixture becomes a living, and breathing component documentation.

Myth 5: “Doing TDD covers our team from doing functional testing”

That’s something that I heard too much, in this case the Myth or assumption is not about people using it wrong, this is about misunderstanding its power. TDD as I titled this post is about letting the design to emerge by expression on a bunch of lines of code our intention for that component. Also the testability for components (the new buzz word) will help us to understand coupling (WARNING! this also might led you to over engineering).

5 Truths about TDD/BDD

Truth 1: “The TDD motivation is about writing clean code that works”

By writing the code needed just to make the test passes you are ensuring that your code fulfils just the test requirements and also that there isn’t dead code, unwanted code or other sort of code horrors.

Truth 2: “TDD outcome is a living breathing documentation for the component”

That’s one of my favorites things about Test Driven Development while you’re writing the tests your expressing the rationale behind those lines and more than that the intended use. When a new developer arrives to a project, if you can hand out a couple of fixtures for him to look at, you’ll probably get him up on speed faster than it would take if he just have to read the code.

Truth 3: “By applying TDD you end up with well factored code”

Some people think about all the decoupling stuff associated to TDD as some kind of black art or magic. Truth to be told, this principle applies painless and it’s harder to realize that you’re doing it than doing it. While you are expressing the intention and how the object should be have you’re defining almost ad-hoc what it shouldn’t do. Writing tests is determining responsibilities for components and when you define those, you’re already decoupling your objects.

Truth 4: “Doing TDD increases the motivation”

While setting micro-goals to yourself and accomplishing them you start to fell better, think of it as 3 years projects, with thousands of man hours to be invested. How do you get the fell of moving forward and don’t fall on the depression of writing code that is going nowhere. Well by simply setting a test for your code, you start to fell confident about what you’re doing and that gets you the feeling of progress as the green lights for your test cases are on.

Truth 5: “There’s no silver bullet”

This might be the most discouraging truth I’d ever written but the true doesn’t hurt. You may get all the benefits of doing TDD but you still need peer reviews, code reviews, analyze your code against formal computer science metrics of complexity and coupling, and all that stuff. I felt like you maybe be feeling when I read the same title on the Mythical Man Month, I thought about that book about the great software engineering problem solver but Mr. Brooks Jr. was pretty clear and I’m agree, there’s no silver bullet and TDD is just another great practice to use in the fight against the bug count and defect ratio.

My TDD Zen Garden

These ten tips are what I call my TDD Zen Garden, they consist in 10 things that use, think about or realized while practicing TDD for about +4 years. As I said on my last Truth (”there’s no silver bullet”) these are just practices, and I encourage you to challenge them, try to defeat and destroy them, because at that point you’ll have something to teach the rest of the world or just me, and that idea fight is really enriching.

Tip 1: “Write tiny and focused test methods that check only one aspect of your code”

If you method can’t be tested with 2 or 3 assertions, that’s code smells. The rationale behind this is to write method with less responsibilities and generate a well factored code.  A single method might take 2 or 3 test cases to test the alternative paths but a well written method will just need one to test it’s core functionality.

Tip 2: “Avoid fragile assertions on human readable text such as error or flash messages”

Try to write your tests (and your code) in order that it can be checked without doing strange things, like converting case or stuff like that. Tests are used to verify and validate that the code does what it needs to do. Think of it as an equation, don’t try to test things that might become messy.

Tip 3: “Use Code Coverage Tools”

Although all the things I said about Code Coverage percentage being a negative metric, it’s useful to know what aren’t you testing. Some people might think that when you find a line that isn’t tested what you should do is to write a test that passes over that line. My approach is a little bit different, if I find something that isn’t covered I just go and delete it. If that was something that I really need it will appear again when the time is right.

Tip 4: “Keep the test logic inside the test method”

As we discussed previously on this post, test are living and breathing documentation for the component. Do not try to refractor it in order to reuse, test methods aren’t intended to be productive code, they’re documentation and development support. Do no save space or try to reduce its numbers of lines, keep it tight, make it atomic and reduce its dependencies. That will make it more readable for people.

Tip 5: “Use mocking frameworks”

This is because mocks (pieces of code used to simulate another component) are just for testing proposes. People often fall in writing huge mocks, that often do too much and even worse they end up testing them.

Mock Frameworks, are useful because all the interaction logic stills inside the test method and as I said before the more information you give inside the test case the better. I clearly don’t have any favorite one, but MoQ and Rhino Mocks are two that I often use and mostly recommend.

Tip 6: “Don’t rely on context data for your tests results”

I often heard that some test are failing because of data that needs to be on the database isn’t there. I prefer to do the insertion and deletion and everything that needs to be done on the test method I don’t rely on existing data because that will you to a fragile assertion (See tip #2 for more info).

Tip 7: “Use Transactions instead of Tests Databases”

People often create bunches of databases to test against, I personally prefer to wrap my whole test inside a transaction. That let’s me play around without screwing up the database and even better I don’t fall on relying on Context Data for my tests. (See tip#6 for more info).

[TestMethod]
public void MyTestMethod()
{
    using(TransactionScope ts = new TransactionScope())
    {
        //write all the test logic here.
    }
}

When the using scope finishes, it will automatically rollback the transaction.

Tip 8: “Make your test cases atomic”

Do not rely on other tests to be running in order to write your test, do not make any tests dependant to other. Write you tests as if they were intended to run on isolation. This will help you troubleshoot a problem when some test fails.

Tip 9: “Do not hesitate on long tests names”

I’ll continue insisting that test are living and breathing documentation of the project, so avoid naming your tests as ShouldThrowException or something that doesn’t provide an insight of what’s going on to the reader.

[TestMethod]
public void ShouldThrowExceptionWhenInvalidCustomerNameIsPassed()
{
}

The name depicted above is an example on how I like tests method to be named.

Tip 10: “Be consistent, methodical, and patient”

It happens event to the best developers and TDD practitioners that at some point of time they go nuts and think about throwing all the fixtures and crack code as fast as they can in order to see their new creation moving. Be patient, consistent and methodical, follow always the process. Software isn’t just built and thrown away, people will have to maintain your baby so please be considered and be thoughtful and polite when your self because at some point (even the best developer) you will have to troubleshoot your code.

thanks,

~johnny

During Tech Ed 08’ I’ve chance to attend the Dynamic Languages - Births of the Feather session, I’m a big C# and I thought at that point that nothing can make me change C#, because it’s elegant, has language features that I love (interfaces and attributes) but I figured out that is something else under the sun.

Compiled languages has been working for a while, but as every compiled piece it’s targeted to run on a specific platform, there were some intents to get the applications to be built to an intermediate language to allow portability at some point in time. People may often think that this came for free, nobody could be faster than our beloved C/C++, but in terms of tradeoffs if you guarantee me portability I’ll definitely buy in.  Doing a quick recap over these ideas, is there anything wrong with this? Why I’m looking at DLR or dynamic stuff that was out there for a while? Let’s consider PHP which is the most leveraged language in terms of web applications. Why now?

I see static compiled languages as an assumption that your world is static, your business problems can be classified and everything is already defined. Software + Services, DSL and other new trends are claiming for flexibility, customization and extension. This means that static world was nice for a while and might be useful in tons of cases but now it’s time to talk about our new old friends the dynamic languages.

What’s a dynamic language?

Dynamic language is a term used to describe a class of high level programming languages that execute at runtime many common behaviors that other languages might perform during compilation, if at all. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them.

Why dynamic languages?

That’s a complicated political question, as I introduced this post, my personal opinion is that world is moving fast, people need software, developers need to be productive and software needs to be prepared for runtime changing, and mutation. Some computer science orthodox, friend of C++ or C# fan might be thinking about it as “you young padwan just want to crack code and get ready to enjoy your star trek episode”. That’s is fairly true,  but there’s true in something like “I want to write code that runs on my mac, can be developed on Windows using my Visual Studio and hosted on openSuse” , seems as an ambitious desire, but it’s how the world is behaving right now.

Will this be the end of C# and our beloved friend C++?, absolutely not I think that this is a top level mind change, we need C# as much as we need C++ and static languages for some aspects of our product that won’t mutate over time. We want dynamic languages to be the top of the stack, write the business logic, UI and process that might change, where its involved pieces might mutate.

We (developers) want to ship software fast, we want to be ready for changes, but we won’t forsake our lessons learnt as TDD. So the answer might be let’s getting started with something that evolves as your product evolves, and have a coding fun.

What’s the DLR and why I love it?

From the beginning, Microsoft’s .NET framework was designed to support a broad range of different programming languages on a Common Language Runtime (CLR).  The CLR provides shared services to these languages ranging from a world-class Garbage Collector and JIT to a sandboxed security model to tools integration for debugging and profiling.  Sharing these features has two huge benefits for languages on the CLR.  First, it’s easier to implement a language because lots of difficult engineering work is already done for you.  Second, and more importantly, these languages can seamlessly work together and share libraries and frameworks so that each language can build on the work of the others.

DLR (Dynamic Language Runtime) is layer over the CLR that let dynamic languages share the robust platform under hood for .Net Languages from dynamic lanaguages (like Iron Python, Iron Ruby,  Managed Javascript) that will let the developers to have a world class execution environment without leaving the CLR.

Is this it? Not really, DLR also is for dynamic languages what CLR is for static compiled ones, it’s a platform that can be leveraged to write your own language.

Why I love the DLR? It’s an easy question; DLR let me use dynamic languages with runtime language services of the world-class static language. In this way I can get my code fast and productively written on a dynamic language but running with the shields and lessons learnt used for static languages.

Why  IronRuby?

• IronRuby is ruby for .net. I love ruby
• Ruby syntax is one of the most productive, human readable syntax I’ve ever seen.
• Has an almost 100% compatibility with C-Pure Ruby implementation (used in Mac, Linux and windows too).
• Tool set, allows me to do all the stuff I learnt like TDD.

Conclusions

Dynamic Languages are back or never left, but my point is that we like them and since we have capabilities like the one provided by the CLR, we are now ready to start writing some dynamic language based application. I love it, but it’s not always one size fits all, I think we still need to think if our app is the case for a dynamic language.

Stay tuned, I’ll be posting more on this, like: TDD and IronRuby, using rake, consuming .net assemblies from it and much more.

thanks,
~johnny

Fellows, I’m more than pleased to announce that our first open source project has been published on Google Code: http://code.google.com/p/sdctasks/. This project is a set of comprehensive MSBuild tasks that we built along with the maturity of our build process.

These are that tasks the conforms our internal build process. The SDC tasks are a collection of MSBuild tasks that we designed to make our development team life easy. You can use these tasks in your own MSBuild projects, use them standalone or use them as further reference to write your own tasks.

There are 8 tasks included in this library and the number continuously grow , in the v1 there are tasks for: Add copyright headers to your files, run MSTests, generate code coverage reports from your MSTests , run Source Analysis, update your assemblies information, remove duplicated files from a file collection, generate SFX packages, and enable web application code coverage for MSTests.

The deliverable is released on Source Code form, we’re looking forward to provide an installer soon!

thanks,
~johnny

Folks, I know I promised to start posting about other things after my last post of Tech Ed but something showed up on my inbox yesterday’s morning and I didn’t want to miss the chance of sharing this with you.

After the whole keynote revolution, we had time to take one-and-only-one picture with the big boss. The guy that was announcing his retirement that day, William Henry Gates III a.k.a Bill Gates.

This was one of those childhood dreams that become true at some point of my life and I’m still amazed of thinking that he was there and even better I was there.

No more comments, ladies and gentlemen… the picture

thanks,
~johnny

Today Lito came from Tech Ed 08′ that was held on Orange County Convention Center in Orlando, FL. The stuff shown there was amazing and I had the chance to attend many chat talks and conversations about technology that is something that I personally love.

I haven’t been posting since Wednesday because things went busy on Tech Ed, here is a brief summary of what happened since then till I got home.

Thursday, preparing the demo. I got up early in the morning and head out to OCCC to help Liam and Moe to setup the demo for their breakout session. They showed the Microsoft Sync Toy vNext that we help to build at Southworks. Then after relaxing a little bit and meet some folks around I had a Ask the experts session with Moe where we discussed things like Sync with Services and Devices (including non-windows based). The talk was great and after that we went to have a nap since Thursday night was the Attendee Party at Universal Studios.

Sync Toy in action live from Liam’s and Moe’s  (MSFT Sync Framework) presentation.

Friday, the day to say good bye. We went to OCCC in the morning, where people were saying good bye to Tech Ed. I caught up with everybody I saw at Tech Ed to say good bye. After that everything was about shopping, taking Tim and Anthony to the airport and prepare our stuff.

Last picture at the boot. Lito, Tim and me.

Saturday, it never ends until it ends. We were ready to leave to the airport but since we where in Orlando, FL. where the dreams come true,  Lito and I went to have a quick trip around the Disney Hollywood Studios theme park and then yes we went to the airport to come back home.

That’s how a shopping session ends, more if Lito is on his spree

Summary

Tech Ed 08′ - North America was a great experience from my personal perspective and I guess with Southworks as a whole we had chance to put out some demos we help to built (syncToy, SQL Data Platform Keynote, and so on). As you can see Lito, Tim and I were the visible faces of a whole team working towards a single objective become better every time and be ready to take the opportunities as they show up.

I’d like to thank too much people, the list is endless but here are the one that I can recall of:

• Ale Jack and Matias, for trusting me and let me be part of this experience and Southworks.
• Eze B and Seba D, whose extremely hard efforts made the Sync Toy an amazing and attractive piece of software to be displayed, I sure we wouldn’t make it for Tech Ed without you help and involvement. You really hit a homer
• Juan Pablo Garcia and Ezequiel Morito (Engineering Excellence), for demonstrating that excellence is easy, and that you can keep it up no matter what. I’m really prod of the work done while I was out and for the most because beside my team you’re my friends :).
• Maxi Déboli, Edgard, Paulo and Leandro, for keeping the quality, for doing the great Keynote demo and staying up late, working hard in behalf of everybody who make Southworks.
• Tim, the one that makes all these things to happens.
• BillG Keynote Demo Team, the list of names would be endless, so to simplify everybody who makes SQL because of the trust and the great moments we had together down in Florida.

And one big special thanks to my travel mate, my friend Lito.

Lito and me at Downtown Disney.

That’s it, I’ll be posting more and more from now on about what are we doing as Southworks Engineering Excellence and my technology affairs.

thanks,
~johnny

Fellows, we’re here live from Tech Ed North America - 2008, things have been busy and seems that they will still this way. Let’s do a quick pass over what happened during these two days.

Tuesday.We left our Holiday Inn Room at 5:00 am., since we helped on development of Data Platform Demo (SQL) for BillG’s last keynote we had to be there early. After a bunch of sanity checks of the application we were ready to go.

Demo back-stage Crew. Lito, Zack and me ensuring that everything is in place for the keynote.

Personally, I missed the keynote since Lito and I were behind the scene with Zack controlling the demo and doing all the checks that needed to be done. The demo actually went great, even Bill’s feedback was the demo was he was thankful for doing a demo the highest quality.

 
BillG Keynote SQL Demo Team. Right after the keynote ended.Top: Anthony Carrabino, Dave Campbell (SQL - Tech Fellow), Moe Khosravy and Tim. Bottom: me , Lito and  Zack Owens.

Once the demo was completed and the keynote closed we went to hang around Tech Ed, I had chance to take a couple of pictures with the products mascots.

Johnny & the Microsoft Mascots.

After lunch, I took my booth duties [Did I mentioned that I'm at the Sync Framework booth on the Green DAT area?] I had time to answer some questions and setup the demos on the booth. Finally after the booth duties we went to have a nap and then hang out around Orlando.

During booth duties. It’s me giving a presentation about Microsoft Sync Framework over the SQL Server & Sync Framework booth.

After keynote dinner. Moe, Lito and me after the keynote dinner.

If you missed the keynote, you can see it online from http://www.microsoft.com/techedonline/. BTW, Zack has a great post explaining the architectural side from the Trey Research Demo we did for the keynote.

Wednesday. Today was all about the booth during the work hours, I was around Tech Ed a little bit too, but mostly all my time was at booth duties demonstrating the Microsoft Sync Framework - Sync Toy, that was actually fun. After duties I went to BOF (Birds of the Feather) sessions were I attend to DLR and Dynamic Languages and later an interesting discussion about Code Quality and Standards. It was really fun, and some interesting conversations show up during the BOF Talks (Also there were some beers to make a relaxed discussion).

Booth duties day 2. Lito and me during showing the Sync Toy.

Tomorrow (Thursday). Tomorrow I’ll be around Tech Ed, during the morning and at 5:00 pm. I’ll be helping Moe Khosravy on the Ask The Expert session for Microsoft Sync Framework. I hope, you can make it, come and clarify all your doubts. Also Liam will be holding a session at 1:00 pm introducing Microsoft Sync Framework.

My profile. This is what shows up on the DAT Area introducing the Microsoft SQL Server speakers. I was really shocked when I first saw it.

That’s all the news live from Tech Ed North America - 2008 , Orlando, Florida.

thanks,
~johnny