Monday, April 19, 2010

Unit testing random methods

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

You can unit test random methods by running the method in a loop and checking for statistical results.

For example, say you have a method to return a random integer between 1 and 10 (this could just as easily be to return any type between any range). You could run the test 100,000 times and confirm that the statistical distribution makes sense. With a sufficient sample size, there should be at least one of each value. The mathematically advanced could apply better statistics, like checking the proper distribution.

Here's a simple sample. It runs the random method in a loop, and checks just that each value was returned at least once.

public class MathHelper
{
    private static Random _r = new Random();

    public static int GetRandomInt()
    {
        //return Random int between 1 and 10
        //recall that upper bound is exclusive, so we use 11
        return _r.Next(1, 11);
    }
}

[TestMethod]
public void Random_1()
{
    int iMinRandomValue = 1;
    int iMaxRandomValue = 10;

    //Initialize results array
    //ignore 0 value
    int[] aint = new int[11];
    for (int i = iMinRandomValue; i <= iMaxRandomValue; i++)
    {
        aint[i] = 0;
    }

    //Run method many times, record result
    //Every time a number is returned, increment its counter
    const int iMaxLoops = 1000;
    for (int i = 0; i < iMaxLoops; i++)
    {
        int n = MathHelper.GetRandomInt();
        aint[n] = aint[n] + 1;
    }

    //assert that each value, 1-10, was returned
    for (int i = iMinRandomValue; i <= iMaxRandomValue; i++)
    {
        Assert.IsTrue(aint[i] > 0,
            string.Format("Value {0} never returned.", i));
    }

}

Of course, this assumes you're explicitly trying to test the random method - you could mock it out if the method is just a dependency and you're trying to test something else.

Thursday, March 25, 2010

LCNUG - Visual Programming Language with Robotics Studio

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

Last night, Lance Larson, president of the Madison .NET User Group, presented at LCNUG on Visual Programming Language (VPL) with Robotics Studio. It was an active presentation - he even had robots moving around the room!

Two things that really got my attention:

  • VPL applies to more than just robots. Many businesses continually hit the problem "how can I have a non-technical person still get technical things done?" For example, they'd like a business analyst program a workflow or rules engine without needing to actually code. Many workflow-related products provide some kind of drag & drop interface (like making a flowchart in Visio) to effectively write a program, but such an interface is difficult to build. It gets especially complicated when you have variables, conditions, looping, etc... Microsoft's VPL is powerful, and I wonder if it will be reused for their workflow products too.
  • Being surrounded by software, it's refreshing to see the hardware part of engineering - like physical robots that follow programming instructions.

Thanks Lance!

Thursday, March 18, 2010

BOOK: Managing Humans

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

About two Christmases ago, I was shopping for a gift for a tech buddy. Browsing through the local Barnes & Noble, I saw this yellow book "Managing Humans". I thought to myself "what technical geek doesn't need to know better people and management skills?" Relieved to have found the perfect gift, I never thought much about that book since. Then a coworker suggested Michael Lopp's Rands in Repose blog. I was impressed with Michael's take on how "software engineers" meet "people skills", saw that it was the same guy who wrote "Managing Humans", and figured that two (indirect) endorsements for the same book, combined with my quest to improve my people skills, meant I should buy it. $16.49 and 8 days later, I had the book in my hands, and could barely put it down. With each chapter, I thought to myself "this guy really gets it".

The book is divided into 34 small chapters, each based on insightful stories based on in-the-trenches experiences. Lots of people-books offer fluff: "be nice to all your coworkers", "work hard", "always brush your teeth so your bad breath doesn't alienate your coworkers", etc... Michael bypasses the obvious and gets to the good stuff. Some of the big points I took away:

Blunt Truths

  1. "Your manager is not a manager until they've participated in a layoff." (pg. 15)
  2. "If you're sitting in a meeting where you're unable to identify any players, get the hell out." (pg. 23)
  3. "Remember that for every person on the team who has a strong opinion regarding the decision, there are probably four other coworkers who just want someone to make a decision so that they can get back to work." (pg. 28)
  4. "you aren't a company until 1.0 is done." (pg. 77)
  5. About reacting vs. thinking, and being too busy: "when you're busy, you're not thinking, you're reacting." (pg. 83)
  6. About "Malcolm Events" - "Seemingly insignificant events that are intent on screwing you in an unlikely way." (pg. 93) "The only way you're going to learn to identify potential Malcolm events is by going through some horrible, horrible experiences." (pg. 96) Part of avoiding these events is clear and tough communication that most people want to shy away from, such as team status reports that say "We're not doing Phil's favorite feature."
  7. "nothing gets everyone's attention like a deadline." (pg. 107)
  8. About finding the anchor in a meeting - "Just wait for someone to say something controversial and see who everyone looks at." (pg. 148)
  9. "Like it or not, your boss has as much effect on your career as you do" (pg. 163)
  10. "A reorg isn't over until someone important has printed out a new organizational chart and presented it in front of the entire company." (pg. 174)
  11. About outsourcing your job - "You could be outsourced because your job is so richly defined that it can be documented and explained to any reasonable professional on the planet..." (pg. 179) "Jobs that can be 'well specified' are being shipped offshore." (pg. 183)
  12. "A micromanager does not trust." (pg. 189)
  13. "Guy who knows the people are the business." (pg. 190)

Other misc quotes

  1. "you are not talking to a person when you talk with your manager; you are talking to the organization." (pg. 11)
  2. "understanding your manager's place in the political food chain is the trickiest because you're often not in the meetings where he is interacting with his superiors." (pg. 14)
  3. "In any freakout, there is normally a very noisy preamble which is designed to get your attention." (pg. 18)
  4. "your job is not just management of people, it's management of information." (pg. 105)

Tuesday, March 9, 2010

10 tips to write shorter emails

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

There are some who think that the volume of email you send out directly reflects how much work you've done. So if you cc twice as many people, you've done twice as much work. For the rest of us, reading long emails is a time-consuming nuisance. To avoid being that person who irritates everyone with a daily novel-worth of emails, here's some tips to write shorter emails:
  1. The shortest email is the one you never even had to write- perhaps the issue can be resolved with a quick IM or water-cooler conversation.
  2. Refer to external resources with the URL instead of pasting large chunks into your email (like "see the wiki page at...". Although sometimes it may be more convenient for the recipients to just see the content of the URL that you're referring to (such as if they don't have access to the target URL).
  3. Make good use of "To" vs. "CC". Some people even filter their emails to redirect CC.
  4. If replying to a long email thread, consider deleting the older history that no longer matters.
  5. If your email is longer, consider splitting it into a clearly-marked "Summary" (2 lines), and "Details". Make it easy for a busy person to get the main point of the email in less than 30 seconds.
  6. "A picture is worth a thousand words", therefore a picture (like a diagram or graph) can often convey a concept much quicker than verbose text paragraphs. Consider also using outlines and tables for the same reason.
  7. Differentiate between informal and formal emails. Informal emails are usually quick questions or responses to friendly co-workers about a current issue for which there isn't a big consequence (example: "Should the confirmation page have a link back to the home page?"). You can make them shorter because you don't need to re-explain the whole problem or define every term. Formal emails usually have big consequences, are usually followed up with a live meeting or phone call to confirm, and have the details in an attachment. (Example: "Is a rate of $120 per contractor hour acceptable?") This usually requires them to be longer such that you catch all the influential and controversial ideas to ensure that everyone is on the same page.
  8. Consider tailoring your email to your target reader and their history of the topic at hand. For example, phrases like "Per our discussion yesterday..." can save you from re-describing a problem. Don't assume that because email can be forwarded to everyone, you need to write it to the "lowest common denominator".
  9. Consider batching multiple questions into one email. Yes, that individual email may be longer, but as a group, the emails will be shorter. It also saves you from having to re-explain the context in each email.
  10. Use good writing skills to condense your writing.

Sunday, March 7, 2010

Process as Infrastructure Enhancements

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

Most devs I meet hate process, almost like it's a stupidity-tax from some ivory-tower folk (who themselves don't actually need to use the process that they're imposing on others). These devs just want to get the app done, and they think that the process gets in their way with tedious constraints that add no value. I recall projects with "process" like forcing devs to go and update all the internal variable names to be compliant with some new coding standard, or not allowing devs to have admin rights to their own machines until three levels of paperwork is approved (good luck being a dev using a Windows OS if you're not an admin), or requiring that developers test the app by taking success screen shots of every single step - and then printing out that 600 page doc and getting it signed by QA.

That sort of stuff bothers me too, but I'm still a big fan of good process. What I realize is that I essentially view "process" as "developer infrastructure enhancements". I think of process as helpful things like automation, unit tests, code generation, proper tools, CI builds, checkout and install scripts, etc...  Devs just want to get the job done, and good process assists them in doing that, it doesn't burden them with ivory-tower taxes. If your process code-generates the data access layer, then the dev need not do all that manual ADO.Net plumbing code, and hence the dev gets the job done faster.

Sure, it's semantics - "process" vs. "infrastructure enhancements", but semantics are important because it affects how a thought is communicated to other people, and people are important.

Tuesday, March 2, 2010

Visual Studio 2008 hanging

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

There's a lot of reasons that Visual Studio hangs. It was hanging for me the other day when I tried to open, and I had a clean checkout. One solution that solved my current problem (thanks to a co-worker):

  • Close VS, delete the *.suo file, and try to re-open. I'm sure there's a reason why,

2 seconds later, VS was up and running.

Tuesday, February 23, 2010

Advice to a college graduate seeking an IT job

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

A lot of eager students will be graduating with CS degrees soon. Realistically, with almost 10% unemployment, out-sourcing, and a rough economy, it can be hard for a college-grad to find a tech job.

Here's a brain-dump:

  1. Condition your mind
    1. Until you are employed, your job is to find a job. Prepare to spend at least 4 (maybe 8!) hours a day actively pursuing job opportunities.
    2. Furthermore, you're not seeking to "get a job", you're looking to "add value" to a company by solving problems in a technical field that you're passionate about.
  2. Prepare
    1. Set up a linked-in account. This is an effective and professional way to keep track of people you meet.
    2. Make the equivalent of a business card that you can hand out as you meet people. Even a card saying something like "Joey Finklestein, my-email, 'Technology Specialist'" is good. The goal is to have your contact info easily available.
    3. Get your resume ready. make sure it downgrades to plain text in case you need to dump it into some online text area. I personally don't think resumes are the biggest deal. Yes, everything counts. But if you're blindly submitting your resume online, you're one among thousands, and it probably won't matter (sorry). If you meet someone in person, the impression you make will probably dwarf any wordsmith-ing on your resume. If you've actually got even a phone screen, the resume has already been sufficient.
  3. Network. Meet people.
    1. Especially if you live in a larger city (like Chicago), prepare to go to a user group meeting at least once a week. For example, Chicago has dozens of user groups (LCNUG, ALT.Net, CNUG, SQL groups, IT, SharePoint, TFS, Design, etc...) Just google it, there's probably a group. Even if the group isn't exactly on target, go to the closet-related thing. Try to meet at least 3 people. Talk to them, ask them what they do, get their business card, give them your business card. Often user groups have recruiters who are trying to fill positions - talk to these people. Even if their position isn't an exact match, they may know of another position, they may have a position that frees up later, or they may just offer you good advice. Plant seeds.
    2. Keep in touch with your graduating class. Maybe they have leads.
    3. Go to job fairs - most community colleges offer these on a regular basis.
  4. Start a corporate and professional online presence.
    1. Contribute to online discussion boards (like http://stackoverflow.com/)
    2. Contribute to an open-source project (check out CodePlex.com)
    3. Consider writing some articles (either start your own blog, or contribute on a free site like CodeProject. Even if you're just writing simple articles like "Joey's C# 101 tutorials", it's still beneficial. It tells employers that (1) you're motivated, (2) you can write (non-tech skills are a great asset), (3) you're pro-active enough to write. It will also make you more confident after you've explained things in an article. Try to write at least two short blogs, or one longer article, every week. Even if you're "not the writing type", employers want people who can write, and having a repository of your articles shows them, as opposed to summary statements at the top of a resume that say "has good communication skills". You can then also list your blog on your resume.
  5. Continual Education - industry is a different beast than academia. The CS degree is great, but that's the beginning, not the end.
    1. Prepare to spend at least an 1 hour a day reading blogs that are relevant to the job you seek. Find who the top bloggers are in your field of interest, and read them. Probably get an RssReader.
    2. Read the job postings on online sites like Monster, Dice, HotJobs, etc.... You want to make sure you know all the buzzwords, and see what employers are asking for.
    3. Do charity projects. Many charity groups could really use the free help. Offer to do a tech-related project (assist with their website, do a data migration, write a tool to help them do some task). It doesn't pay cash, but it does pay in experience and relationships.
  6. About applying...
    1. Ideally you want to meet someone in person (like at a user group). Next best thing is to meet someone in the company who can provide a referral.
    2. If you do apply online (with no personal reference), don't put all your eggs in one basket - apply to several companies. But don't spam Monster. Perhaps submit to a few companies each day, but not more than 10 companies at once. If you don't hear back from a company within 5 days, move on. Many companies send out an automated "we received your resume note", and then only personally follow-up if they're interested.