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.

 

Twenty excuses to avoid learning

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

I was thinking the other day of all the excuses that I've heard for my software developers avoid trying to learn new things. I'm a huge advocate of developers doing continuing education, so I always find the excuses interesting. Here's a random list of the top twenty:

1. I’m too old / I’m too young.
2. I’m not smart enough.
3. I don’t need anything new / I don’t care.
4. But my memory is too bad…
5. Even if I learn something new, it won’t help me.
6. I don’t have the technical job yet. First I’ll get the job, and then I’ll learn about it.
7. The technology will just be obsolete by the time I learn it.
8. I’ll just wait until some teaches me.
9. Learning is punishment for being bad - i.e. the grade-school mentality when you're teach assigns extra homework to "punish" you.
10. The instructor dislikes me, therefore I won’t try.
11. The techniques/resources aren’t available.
12. My environment is unfair, so why put myself on the line when it’s setup against me.
13. Training is too expensive
14. It’s too overwhelming
15. It’s my boss’s responsibility to train me
16. I don’t even like my job, why would I want to learn more about it? (Rebuttal: then learn about another job, the job you want).
17. I don’t want to waste effort learning something unless I absolutely need it.
18. If I learn some niche tech, then I’ll get stuck maintaining that obsolete system.
19. I worked really hard before, and nothing good came from it.
20. It’s not worth it.

Are there other ones that you've heard? At some point, I'd like to offer explicit rebuttals to each of these.

Resources for learning software development

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

I was thinking the other day how many different resources are out there to help someone learn software development. There's something to appeal to almost every style:

1. Books
2. Reference docs
3. Articles
4. Webcasts
5. Podcasts
6. Virtual labs
7. Newsgroups, discussion forums
8. Live Events
9. Professional Groups
10. Blogs
11. Training (class room setting)
12. Sample code - quickstarts
13. Sample code - real projects
14. Tutorials & Walkthroughs
15. Local class at community college
16. Bachelors or Master’s degree
17. Teaching others (forces you to learn it)
18. Write your own blog
19. Personal pet projects
20. Open source projects
21. Your coworkers. A physically present person, who can look at your machine environment, can be the best way to learn.
22. Private tutor – perhaps for introductory topics where such tutors are much more abundant.
23. Certification

Any others that you've personally found helpful?
 

Architecture: Keeping it non-exponential

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

Systems have a tendency to get more disordered. Architecturally, it's easy to always take shortcuts such that your application code becomes one big mess of tightly coupled objects and duplicated code. It starts innocent enough -you have only a few initial components, and each one has a dependency on the others. So that's still only a few dependencies.

But then, a few emergencies later (and what isn't an emergency?), your code has ballooned, and the dependencies have exponentially exploded into a mess. The project has accrued so much technical debt that the schedule is hopeless, and it's no longer fun. Every object is intertwined with every other object:

A much more sustainable model is to demand cleaner code at each step of the way, and end up with something maintainable, which the number of dependencies increases linearly with the number of new components. This lets you add, remove, and modify the code much more easily:

I see this as one of the basic issues of architecture: keeping the ever-growing code base in a maintainable state. In application development, this often boils down to conscious decisions where everyone "knows" the right way, but instead write sloppy code for ("we don't have time", "we'll fix it later", "this one won't hurt", "it works", "the maintenance team will fix it", etc...). Often, it seems like the team just needs a strong and credible voice to encourage everyone to do the right thing. Especially for long-term, enterprise projects, this seems like the optimal way to go. It sure beats having 12 months of garbled code.

SSN is not a secure password

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

I had a conversation the other day where SSN was considered viable to replace using a password. Yes, it simplifies single sign-in, but it has major consequences (and there are other ways to do single sign-in). Using SSN as a password is a bad idea, the kind of thing that blows up in your face with security and functionality problems.

1. You can't change your SSN (unlike your password)

2. SSN is too limited. It's merely a nine digit number, so it can't even pass strong password tests. Furthermore, the last 4 digits are often available (so down to 5 digits left), and there are rules that an SSN must adhere too (they aren't just any random 9-digit numbers). With less than 50,000 possibilities, it's fair game for a brute force attack.

3. SSN is publicly available in many cases. For example, HR and managers can often see your SSN (but not your password).

4. SSN has direct real life significance too, and is therefore immediately dangerous if lost. For example, if you lose a password, that's bad, but it's only dangerous if the hacker (A) knows the context - i.e. the system  to apply it to, and (B) the password hasn't changed yet. But the context for an SSN is immediately known (like any financial or government institution), and SSNs can't change.

What's your favorite Domain Specific Language?

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

I love domain specific languages (DSL). The idea is that instead of programming at a low level (i.e. tedious and error-prone), you program at a higher level of abstraction. This means coding with a language (or even class library) that closely maps to the problem domain. For example, here are several domain specific languages. While you could try to do without, it just becomes so much easier with them:

 

DSL	Purpose	Example	Manually doing without:
Regular Expressions	Find and replace patterns in text	Find all numeric decimals in a file	You could use core string methods like SubString and IndexOf
SQL	Manage database data	Select all employees that meet a certain criteria	You could do selects by getting the entire dataset and cycling through the object model
XPath	Query xml data	Get the custom order xml nodes where price is less than $100	You could step through the xml with a reader, or loop through an XmlDocument
MSBuild	Microsoft's build engine to automate your processes	Compile your application on a build server, run unit tests, and then produce MSI outputs	You could use System.Diagnostics to manually run a bunch of commands, and keep track of error conditions and logging output yourself.
String Format Expressions	Format a string using var.ToString("myPattern")	Format the number 12.3456 to only two decimal places	You could use core string methods, and pick apart the variable, and re-assemble it.

 

The point is that while someone could get by without knowing the appropriate domain language, it's just not practical to tackle the domain without it. Each of these has tons of tutorials and quickstarts, so there's no reason to avoid them. An application developer should probably be comfortable with most of these.

 

So, what's your favorite domain specific language?