Http Pocket Reference

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

I finished reading the O'Reilly HTTP Pocket Reference. I just wanted a good refresher on HTTP. It was a very good book. I liked that it was only 80+ pages, maybe a 1-2 hour read, and just covered the important stuff. When time is short, there's a definite benefit to just reading a summary as opposed to an exhaustive reference. I notice that many devs don't take enough time to read a full book, so they settle for just skimming blogs. However, that usually gives just a gap-filled understanding because they never get that end-to-end thoroughness. The pocket books offer a good compromise - more thorough than just a blog entry, but still short enough to read when time is tight.

Random producing same values

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

In programming languages, Random numbers aren't truly random, but rather appear random based on a seed value. For example, a trivial "random" number generator may just take the current milliseconds from the timestamp.

The following two snippets illustrate this. Each snippet runs through a loop to generate a list of "random" numbers. However, the first snippet produces all the same values because the Random generator is re-called in the loop each time, therefore the same seed appears to get used. This is bad. The second snippet is the way to do it - put the Random generator outside of the loop, and then re-call it each time to get the next random value.

While this example is obvious, it may be a little harder to see if a developer puts the Random() call in a method, and then calls the method within the loop. In that case, it would act like the first snippet, and always generate the same values.

 

    [TestMethod]
    public void Random_Bad()
    {
      List<int> li= new List<int>();
      for (int i = 0; i < 3; i++)
      {
        Random r = new Random();
        li.Add(r.Next(0, 1000000));
      }

      Assert.AreNotEqual(li[0], li[1]);  //Fail
      Assert.AreNotEqual(li[1], li[2]);  //Fail
    }

    [TestMethod]
    public void Random_Good()
    {
      List<int> li = new List<int>();
      Random r = new Random();
      for (int i = 0; i < 3; i++)
      {
        li.Add(r.Next(0, 1000000));
      }

      Assert.AreNotEqual(li[0], li[1]);
      Assert.AreNotEqual(li[1], li[2]);
    }

 

Making Process Results Public

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

Enterprise applications require a lot of supporting processes - continuous builds, feature tracking, monitoring production, etc... One sign of a mature department is that the non-secure output from those processes is publicly available to the entire team, as opposed to "hidden" in a personal file on some manager's computer. This keeps everyone on the same page, encourages team feedback, and reduces bureaucracy.

 

For example, anyone on your team should be able to tell you the release dates, their current expected feature list, the amount of open issues they have, and if their code patch broke any unit tests on the server. Those should not be "special" things that only a manager has access to view.

 

There are several processes that any development department should have, and these processes should all have publicly accessible results (such as via a web dashboard or shared network drive).

• Issue Tracking System (we use a web-based solution)

• Continuous build with unit test results (we prefer CruiseControl)

• Wiki (we started with FlexWiki to just get started, but now use SharePoint)

• Production performance results (you should be able to go to a web dashboard, not pester your IT department for the raw IIS log files)

• Available project plan (even an Excel sheet on a shared network drive)

There's no doubt more to this list, but it's a good start.

Book: Getting Started in Consulting

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

I just finished a very good book - Getting Started in Consulting. As its title suggests, it explains how to start up your own consulting practice. While I am personally entrenched in industry at Paylocity and not heading towards consulting, the book is still very applicable. (I used to work in consulting at Deloitte and CSC). Essentially, the developers who really stand out do a lot of the same things that successful consultants do - they take initiative to add value in a way that supports the client.

 

As someone now in industry, my "client" is usually my boss, or the customers who purchase our product. My "fees" are usually how I get to spend my time - i.e. I need to justify to my boss that project X is worth the time investment, and they should therefore allot schedule resources for it. The chapters on sales and marketing are good for any developer to know because they remind you that ultimately the project needs to generate revenue. It's easy to think that money grows on trees for these corporate giants, but for many of us, good projects often come down to a series of small "sales". Alan does a great job of showing how to incrementally add value and handle scope creep.

 

He also has very applicable chapters on "Moving to the Next Level" and "What do you do with Success?" For developers, if you've been in the field for 10 years, are you just doing more same old features, or are you still professionally growing and contributing back to the community via mentoring, publications, user groups, or other extra curricular activities?

 

It's an easy read, a well done book, and stimulates your mind to think about how to add value for your current project in industry.

Merry Christmas

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

Merry Christmas for 2007, and a happy new year coming up in 2008!

 

Generic Dictionary in C#

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

I love the generic Dictionary class. It's located in the System.Collections.Generic namespace. This class is like a strongly-typed hash table (which lets you reference objects as key-value pairs). You can specify the type for the key and another type for the value. This code snippet below shows how to create, add, and retrieve data from a Dictionary. It spares the developer from writing a bunch of extra conversion wrapping code.

    [TestMethod]
    public void Dictionary_1()
    {
      Dictionary<string, DateTime> group = new Dictionary<string, DateTime>();

      //Add based on separate variables
      string strKey1 = "abc";
      DateTime dt1 = DateTime.Now;
      group.Add(strKey1, dt1);

      //Add as single line
      group.Add("def", new DateTime(2005, 12, 25));

      //Should now have 2 items
      Assert.AreEqual(2, group.Count);

      //Get value given key
      DateTime dt2 = group["abc"];
      Assert.AreEqual(dt1, dt2);
    }

Generics are great. You can also use them for strongly-typed lists, setting the return type of a method, and many other techniques that simplify code.

Tips to overcome problems with learning

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

Although it's common knowledge that you need to invest time and effort to learn, the question is how to maximize that investment. Certainly you will encounter problems at every step of the way, such as:

• Staying motivated.
• Not feeling overwhelmed.
• Finding time to learn despite being busy.
• Learning the right stuff.
• Retaining what you do learn.
• Getting to use your new hard-earned knowledge.

Here are some random tips to dealing with those problems. Obviously a lot more could be said about each one; this is just a partial brain dump - and isn't that what blogs are for?

Problem	Ideas for Solutions
Staying motivated	Work on what you personally care about Reflect on your accomplishments
Not feeling overwhelmed	Make reasonable goals Focus on smaller chunks
Retaining what you do learn	Summarize your new knowledge Put it in easy-to-find places Practice it hands-on
Learning the right stuff	Continually try at everything, and eventually you’ll hit the jackpot (This will also increase your learning ability such that you’ll be ready when you get the chance). Invest time outside of your required learning to explore the topics you want.
Using your new hard-earned knowledge	Pick topics that assist with your personal goals, so regardless of what happens at work you'll still get to use it. Hang out in communities that value the same knowledge.
Finding time to learn despite being so busy.	Use the dead parts of the day (like driving or waiting in line) to mull over ideas. Use smaller chunks of time instead of waiting for an entire free day. Even in seasons when you’re just trying to survive (and hence are not doing any new studying), you can still learn better character like patience and determination.