What makes a process good?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/what_makes_a_process_good.htm]

I've seen that there seems to be two different views of what "process" means, I'll refer to them as the "pro" and the "con":

• Pro - Steps to help save time and reduce tedious and error prone tasks. Examples include: continuous integration, automated unit testing, and code generation.

• Con - Red tape, bureaucracy, and damaging politics - something that exists so that ivory-tower-folk can feel important. Examples include: wasting hours to reformat a private word doc so it meets "standards", or manually going through all your (perfectly functional, production) code to switch the naming convention from Pascal to Camel case.

I've seen projects where someone, with good intentions insists that "we need to improve our process", while others, also with good intentions, just cringe. The problem is that even though they're using the same words, they still mean different things. Obviously any good project should avoid the bad and emphasize the good.

 

With this, I offer several criteria that a good process should meet:

• As a complete package, it should make life simpler. It should solve a specific problem that the team agrees needs solving. (run your tests, manage your source control, etc...)

• It must always functionally work, from end-to-end. Process that produces bad output will just cause you bigger problems. It is better to have a slower process that works, then a faster process that randomly fails.

• It should have public results so that everyone can see what happened

• It should be publically documented, such as on a team wiki, so that others can understand it (as opposed to always bugging you for questions)

• It should be easy to maintain (automated [perhaps with MSBuild], machine-independent, abstract out variables like pathNames to a config, etc...)

• It should be easy to setup. Process that is a pain to install (perhaps requiring third party components that you don't have licenses for) will eventually just be ignored.

There's probably more criteria, but a process that fulfills all these is off to a very good start.

A reactive learner is also a reactive problem solver

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/a_reactive_learner_is_also_a_reactive_problem_solver.htm]

It's much easier to be reactive than proactive. A reactive person looks at what already happened and tries to make sense out of it - they're always playing catch-up. A proactive person needs to understand the rules beforehand so well that they can anticipate the possible scenarios that may happen.

 

This is why so many developers are re-active learners. For example, they'll first be given a problem or coding task, then they'll google to figure out the syntax, concepts, and usually code with trial and error until it appears to work (i.e. "coding by coincidence"). It's a very re-active approach, and it suffices for an average programmer.

 

The problem is that a re-active learner will always be a re-active problem solver because before you can solve the problem, you need to first understand it. This means you need to learn the concepts involved. Furthermore, if you haven't learned the concepts yet, you can't know how the system will react, which means it will likely react in ways you didn't intend. For example, a developer who never learned about concurrency or scalability will be in for a big surprise when their procedures start running in production with multiple users. Such an error can sound very cryptic, especially if "it works on my machine", but randomly fails in production. Instead of designing their code proactively to deal with the problem (where such a solution would be much cheaper), they'll have to try to reactively first learn what happened, and then hope that it's still solvable.

 

Therefore, a good long-term approach is to not just reactively google coding questions as you come across them, but to also proactively read the actual books and language specifications themselves. That way, you know before hand what to expect from the technology, without waiting for it to do something intentional - when learning the solution may be too late.

Using Linq to sort and filter entity lists

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/using_linq_to_sort_and_filter_entity_lists.htm]

One of the big new features for .Net if LINQ - Language Integrated Query. There's lots of good tutorials out there - you can see 101 examples, download a free GUI editor from the guys who wrote C# 3.0 in a Nutshell, or even just google it. As I was toying with Linq (via the very good chapters from C# 3.0 in a Nutshell), I especially enjoyed using Linq to query objects. Here's the test snippets I was running.

 

First, I created a trivial entity:

 

    public class Employee
    {
      public Employee(int age, string strFirstname)
      {
        this.Age = age;
        this.FirstName = strFirstname;
      }
      public int Age { get; set; }
      public string FirstName { get; set; }

      public override string ToString()
      {
        return this.FirstName + " (" + this.Age + ")";
      }
    }

 

Then I set up an MSTest project (perfect for stubbing out things like this), and added this initializer to always give me an Employee array:

 

    [TestInitialize]
    public void SetData()
    {
      _employees = new Employee[]
      {
        new Employee(39, "Homer"),
        new Employee(39, "Marge"),
        new Employee(7, "Lisa"),
        new Employee(9, "Bart"),
        new Employee(3, "Maggie")
      };
    }

    Employee[] _employees;

 

Now, I can write some test snippets.

 

Filter an Entity list

 

Given an array of Employees, I can filter them by business rules, such as getting all employees over 10 years old. We used to need to handle this (in C#) by writing a custom loop that checked each item. Now, Linq gives us a Domain-Specific-Language to just handle this, usually with 1 line of code.

 

Note the "n => n.Age < 10)", this is where the syntax may seem new. This is where you can put your appropriate filter expression. Linq then provides a ToArray method to ensure that an array of employees are returned - as opposed to some differently type dynamically-crated object.

 

    [TestMethod]
    public void FilterEntity()
    {
      Employee[] ae = _employees.Where(n => n.Age < 10).ToArray();
      Assert.AreEqual(3, ae.Length);
    }

 

This alone is great. There's no fluff wasted. It's a single line, and every keyword and expression maps to a specific concept: "Given an array of employees, filter them where the age < 10, and then return an array of employees."

 

It gets better - the filter expression can contain your own custom method. In this case, I created a "HasBigName" method to check for custom logic (the length of the string).

 

    [TestMethod]
    public void FilterEntitySpecial()
    {
      Employee[] ae = _employees.Where(n => HasBigName(n.FirstName)).ToArray();
      Assert.AreEqual(3, ae.Length);
    }

    public bool HasBigName(string s)
    {
      if (s == null || s.Length <= 4)
        return false;
      else
        return true;
    }

 

Sort an Entity list

Linq makes it easy to sort entities by their fields. In this case, I can sort the employees by their first name.

 

    [TestMethod]
    public void SortEntity()
    {
      Employee[] ae = _employees.OrderBy(n => n.FirstName).ToArray();
      Assert.AreEqual(5, ae.Length);
      Assert.AreEqual("Bart", ae[0].FirstName);
    }

 

Conclusion

Linq is a great example of something that was possible to do before, but wasn't always practical. Developers don't like writing  extra lines of plumbing code just to do mundane things like sorting and filtering, so it's a huge win to have a means to quickly handle that.

Beyond functionality for enterprise apps

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/beyond_functionality_for_enterprise_apps.htm]

Many developers are so pressured by demanding schedules that their goal is just to "get the job done", by which they mean "it functionally works." While this is a great first step, professional programming requires more, such as:

• Maintainability

• Performance

• Scalability

• Security

• Testability

As you go from a hobbyist toy to an enterprise app, these criteria become self-evident. They're buzzwords that everyone has heard, but surprisingly few seem to put into practice. Interesting questions to ask yourself (or someone you need to interview):

• Maintainability - Have you ever had to write code that will be maintained by other people? How did you code differently to make it more maintainable?

• Performance - Have you ever had to write code that was performance critical? How did you ensure that that code was fast enough?

• Scalability - Have you even had to write code that was used by more than 1 million users? What might you do differently to ensure the code handled that?

• Security - Have you ever had to write code that protected secure data and you knew someone would try hacking it? How did you make it secure?

• Testability - How would you ensure that your code could be tested?

Of course some of these, like performance tuning, may take more time. But that goes with the territory of large-scale apps.

 

In general, I come across two kinds of programmers - those that just worry about functionally "getting it done", and those that look beyond functionality. It seems the first group digresses into boring copy and paste work, whereas the second is constantly on an adventure doing new, fun things. The beauty is that there's nothing that stops someone from jumping into the second group. You can read about all the techniques online, use open-source tools, and often it's even faster. For example, anyone could use NUnit, or MSTest to write unit tests to help their testing, or read about Refactoring or design patterns for more maintainable code.

"I know the concepts, but not the syntax"

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/i_know_the_concepts_but_not_the_syntax.htm]

I hear it a lot from developers - "I know the concepts, but just not the syntax." The thinking seems to be:

1. There's too much out there and I can't know it all

2. The concepts are what really matter

3. The syntax is just trivial stuff that I can look up.

Therefore, the idea is that the developer knows the important stuff (concepts), and shouldn't be blamed for not knowing the unimportant stuff (syntax). Fair enough as long as you know enough syntax to get the job done. However, more often than not, I see developers who continually shrink the first category and enlarge the second. For example, I've seen developers refer to standard concepts for which they're heard the buzzword but don't understand (OOP, exception handling, n-tier architecture, client-server models, design patterns, etc..) as "syntax". Some people think this is a smart way to avoid saying "I don't know." The problem is that these things are not syntax - syntax is language specific details for a single implementation. For example, various languages can each have their own syntax to create comments. The concept is "creating a comment in code", the syntax is what you actually type to do it (such as // or /* ... */ in C#).

 

A general rule is that concepts transcend any one language. For example, C++, Java, and C# all use OOP, so questions like "What is an abstract class" or "What is polymorphism" are conceptual questions - they have nothing to do with syntax. Likewise, all these xml config files (like the ASP.Net web.config, or even MSBuild) have little to do with syntax - the whole point of making them in xml is to bypass any syntax problems. Rather, they're about "do you understand the problem space?" If you know the concepts to tune a web application, ASP.Net's web.config suddenly makes a lot more sense.

 

I realize at the end of the day, implementation requires us to know the syntax. In fact, many developers can copy and paste chunks of code without even knowing that conceptually is going on. To such a developer, everything is effectively syntax. However, there's always the benefit of being able to step back and differentiate between the two.

Converting an object from JSON and back in Silverlight

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/converting_an_object_from_json_and_back_in_silverlight.htm]

JSON (JavaScript Object Notation) provides a convenient way to serialize an object, like "Employee" with first and last name, to a string. This can be very useful in Silverlight apps, such as when you need to pass complex objects to and from a web service.

There are APIs in Silverlight that make it relatively easy to roundtrip an object from a JSON string and back. Here are two wrapper methods.

These use the assemblies System.IO and System.ServiceModel.Web (which contains the necessary namespace System.Runtime.Serialization.Json). It also uses the two static utility methods I blogged about to roundtrip from a MemoryStream and back (GetMemoryStreamFromString and GetStringFromMemoryStream).

    public static T ConvertFromJSON(string strJSON)
    {
      System.Runtime.Serialization.Json.DataContractJsonSerializer d =
          new System.Runtime.Serialization.Json.DataContractJsonSerializer(typeof(T));

      MemoryStream m = GetMemoryStreamFromString(strJSON);
      T obj = (T)d.ReadObject(m);

      return obj;
    }

    public static string ConvertToJSON(T obj)
    {
      System.Runtime.Serialization.Json.DataContractJsonSerializer d =
          new System.Runtime.Serialization.Json.DataContractJsonSerializer(typeof(T));

      MemoryStream m = new MemoryStream();
      d.WriteObject(m, obj);
      string strJSON = GetStringFromMemoryStream(m);

      return strJSON;
    }

I assume that the code is self-explanatory. Perhaps the only note is that it uses Generics to dynamically set the return type. You could also optimize the methods for performance by instantiating the DataContractJsonSerializer once, and making these utility methods, as opposed to static methods that re-create it every time.

Is Silverlight just another buzzword?

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/is_silverlight_just_another_buzzword.htm]

There are always new buzzwords coming out in software development. One of those buzzwords gaining more traction is "Silverlight", a Microsoft technology to enable rich UI web applications.

I think that Silverlight is great, and is far more than a buzzword. I see it offering several big benefits:

1. Graphical API -  Silverlight lets you draw and animate vector graphics. For example, you could easily do a graph. ASP.Net had ways to handle this, but they were slow and cumbersome (for example, use GDI+ to create the image on your server, and then load it up).
2. Programming a compiled language (like C#) on the client - This is just awesome. Whether you've written an entire physics engine that you're running on the client, or just doing complex validation, the ability to code difficult logic in a first class language like C#, as opposed to a brittle scripting language, is invaluable.
3. Rich object and event model - no more postbacks, easy to add controls, etc... - You could modify the DOM using JS, but it's so much easier to do this with Silverlight. For example, try dynamically adding an entire complex UserControl with JavaScript - it's doable, but hard. It's one line in silverlight.
4. Cross-browser compliant - Silverlight just works on the main browsers (IE, Firefox, etc...). No more pulling your hair out because you forgot to check some DOM method nuance.
5. UI rendered through xaml - Silverlight lets you create your "Form" via a markup language, somewhat like Html, but much cleaner. I think this is a cleaner style than creating it via the codeBehind (like WinForms).

How does Silverlight doe this? In one sense, it "cheats" by requiring a small download (kind of like a flash player). So, Silverlight isn't just like Ajax, which plays by the rules of the web but just stretches them by leveraging the XmlHttpRequest object, but rather Silverlight plays a whole new game.