CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Karl Seguin

.NET From Ottawa, Ontario - http://twitter.com/karlseguin/

July 2008 - Posts

  • Looking for .NET projects to contribute to

    I've been getting a fair bit of mesages from developers, who are enthusiastic about DDD and the common ALT.NET toolset, looking for a good project to contribute to - as a means of doing some hands on learning and helping out the community at the same time. I know one place to start might be Jeff Atwood's open source list, but I was hoping someone might have more specific ideas.

    I think one of the challenges is that many open source projects tend to be tools for developers, and as such they are either pretty complicated, or don't relate well to typical enterprise development. The other problem is that many open source projects are well established and have a large codebase, which makes them significantly harder to get involved with.

    Anyways, if anyone knows of a good open source project where a junior developer would be able to understand and contribue, please let us know. (Self-promotions welcomed)

     

  • Password : You're doing it wrong

    I'd like to think that I deal with passwords the way most developers do. When dealing with registration or something else that requires the user to provide a password, I follow some general guidelines:

    1. The password must be a minimum length, normally no less than 6 characters
    2. The password's maximum length is very high (200 characters)
    3. I'll typically check for at least a mix of letters and numbers. For applications with considerably more sensitive data, I'll have more requirements – such as mixed casing or special characters.
    4. Hash the password with a salt (the salt can be a fixed string, or something more unique to the user - again based on sensitivity). Salting means that if someone gets access to a dump of your Users table, they'll still have a hard time logging into the system with a dictionary attack.
    5. Since hashes can't easily be reversed, send out a new password to users when they forgot password and have them change the temporary password as soon as they log in.

    All this is pretty vanilla and you can change an SHA1 hash implementation for some encryption or whatever else tickles your fancy. What I've noticed though isn't that developers are hitting some type of technical hurdle when dealing with password, but rather, a usability one. The point behind bullets 1, 2 and 3 is that users ought to be able to enter anything they want as a password, provided it meets a minimum set of guidelines. As developers, we should try very hard never to impose restrictions which limit the effectiveness of a password. Lately though, I've been astonished at some of the limits sites impose on passwords – forcing me to come up with a less secure password than what I would have liked.

    Here are some popular sites which have such restrictions:

    • digg only accepts letters and numbers
    • SourceForge only accepts letters and numbers (when you change your password, SourceForge even goes through the trouble of showing you a little dynamic update as you type (weak > normal > strong and then "invalid character" when you enter an exclamation mark)
    • Passport limits password to 16 characters (isn't Microsoft a champion of passphrases?)
    • MySpace only accepts passwords up to 10 characters long, but at least require 1 number or punctuation character
    • Wikipedia let me register with a password of ‘a', but at least has very informative help on choosing a strong password. (Additionally, given what an anonymous user can do on Wikipedia, I'm not too disappointed in this policy)

    And for sites with better policies:

    • Ebay, PayPal and Google have useful help and accept special characters (PayPal and Google even require at least 8 characters),
    • Twitter and Facebook don't have any “choosing a strong password" help, but still seem to accept everything

    The most shameful site I've ever come across though is completely unacceptable – not only because of the ridiculous limitations it puts on passwords, but also the type of data it's responsible for. The Bank of Montreal's Mosaik Credit Card (BMO is major Canadian bank), has a password limit of 8 characters and only accepts letters and numbers (there's actually a maxlength="8" attribute on the form).

    Here's a simple rule to follow. If Windows Calculator displays the total number of possible combinations in non-exponential form, you password guidelines suck.

  • My Thoughts on ASP.NET's MVC

    Like me, you might have been surprised that the foundation series didn't have a chapter on the MVC pattern. I'm no fan of the existing page model (I actually think it's horrible), and I've successfully used MonoRail on a few projects, so it would have made for a good topic. My reasons for not including something on MVC were simple: we were and continue to be flooded with MVC information (as though it's a brand new invention), and I didn't think I could explain MVC using MonoRail effectively (I find it has a steep learning curve). I considered using RoR, but figured that would confuse people even more.

    Hopefully though, if you're a fan of the foundation series, you've already downloaded the learning application which puts the theory to practice using ASP.NET's MVC framework. So, what do I think about ASP.NET MVC? Overall I've been very impressed. I can't think of a good reason for starting a new project using the WebForms model - or MonoRail for that matter (sorry). If you're an ASP.NET developer, it's really a no brainer.

    I do have two major issues with it though. First, if you come from almost any other MVC framework (MonoRail, Django, RoR, Akelos, etc...) you might be expecting an actually Model framework - instead you get an empty Model folder. In other words, the MVC framework doesn't add anything to the .NET O/R Mapping / DAL story. From Microsoft's point of view this makes sense, since they feel that they are already offering solid solutions - DataSets, SqlDataSources, LINQ to SQL, Entity Framework. Truth be told, this is fine with me, as it lets me use NHibernate. I just think, given what the other MVC frameworks offer, it's a little dishonest - you'll end up disappointed if you're expecting to be able to do this out of the box:

    public class Car : ActiveRecord
    {
    }
    ....
    Car.FindById(1);

    My real problem though is simply that neither C# nor VB.NET lend themselves all that well to view logic. Jeff Atwood actually just blogged the same criticism. Jeff uses RoR to highlight the problem. I don't fully agree. I won't say that RHTML is great, but I will say that it's far better than C# or VB.NET. I think views need a specialize language - I'm sure that anyone who's done some significant work in either RoR or Django would agree. There are solutions available now - NVelocity and Boo (I assume you could use it with the MVC framework?), but I'm just going to trudge along with C# until IronRuby is a viable solution.

    Aside from that, everything is pretty solid - routes work great, helper methods are adequate (they're starting to add more and more), and testing is actually doable - I haven't run into any problems, but from what I've read things aren't 100% perfect yet (either way, it's a huge step up from WebForms).

    So, to recap. MVC good. WebForms Bad. C# in views less than ideal. Empty Model folder = M. Oh, and download the learning application!.

    Posted Jul 22 2008, 09:49 PM by karl with 8 comment(s)
    Filed under:
  • Foundations of Programming - Learning Application

    If you're anything like me, you probably learn a lot better by going through code rather than reading books. I'm happy to release the Foundations of Programming Learning Application - it's a complete solution meant to show what was covered in the Foundations series. It's a Visual Studio 2008 solution.

    You can download it here. It should require no configuration (my fingers are crossed on that one) and ought to just run out of the box. There are comments sprinkled all over to help explain things or provide some insight. No doubt there'll be typos, since I'm nothing without word.

    (you can grab the free ebook from: http://codebetter.com/blogs/karlseguin/archive/2008/06/24/foundations-of-programming-ebook.aspx)

    What is it?
    It's a sample awards website - with categories and nominees. The root container is called a Round - a sample Round would be called 'The 2008 CodeBetter Awards'. A Round has a state (planning, annoucements, voting, winners) and a number of Categories (Best Blogger, Best Blog Post, Best Open Source Project, ...) with each categories having a Nominee (Title, Summary, Link, Author...). The website is using the ASP.NET MVC Preview 4 - I don't think you'll need to install anything extra as all the DLLs are included with the project. I'm using an SQL Lite database with a relative path to the file, so all should work as-is. Dummy data is already loaded.

    The web application mostly shows a read-only view of the data. There's also a sample console application that does more administrative stuff (it isn't interactive, it just runs through 4 steps or so). You can run the administrative portion over and over again - the first step is to clean itself up. The admin part basically adds a new round, with categories and nominees.

    Of course, there's a project full of unit tests as well.

    I tried to keep everything simple and straightforward (which is largely why I didn't want to build a whole web-based admin module and user registration and all that). Like most, I'm pretty new to ASP.NET MVC. Some might think my views have too much code, I think they have the perfect amount Stick out tongue. There's extensive use of Lambdas, so if you have a hard time reading them, I hope my excessive examples will help illuminate them.

    Posted Jul 18 2008, 09:34 AM by karl with 21 comment(s)
    Filed under:
  • Announcing the .NET Extension Library

    285 days ago I blogged about my dislike for extension methods. Extension methods aren't very discoverable, and they can lead to poor communication (between members of a team, from project to project, and between a developer and the code he or she is trying to read).

    I still think extension methods have serious shortcoming, but I've soften my view on them quite a bit. I don't know what changed, maybe it was my extended foray into Ruby or spending the last few weeks neck-deep in the ASP.NET MVC framework, but I decided to attempt to put out a standard extension library for .NET developers. One of my gripes with extension methods is that they can make projects rather inconsistent, a new developer might be surprised that string.Left suddenly doesn't work on a new project. Ideally, having a well-known extension library might help solve that problem.

    The .NET Extension Library isn't just about extension methods though. It's about providing core functionality to projects. For example, I've blogged a few times about how hard it is to unit test code that caches - largely because there isn't an cache interface. This is a problem no more. The .NET Extension Library has an ICache interface, a CacheFactory (which really just returns HttpRuntime.Cache - for now), as well as enhancements to the cache API. Here's one of my favourite examples of what you can do:

    User user = CacheFactory.GetInstance.Fetch(
         "user.{0}".Sub(userId), 
         () => _dataStore.GetUser(userId),   
         3.DaysFromNow());
    

    Fetch is a mix between Get and Insert. My second favourite addition are the extensions to IEnumerable, which bring all collections/arrays inline with the List when it comes to methods like Each, TrueForAll, Find, FindAll and more. You no longer need to use the static Array methods.

    Input is always welcomed, as are suggestions and/or additions. As much as I'm up for adding useful extension methods, I rather focus on classes that show up in every project kinda thing, such as an abstraction for logging and such.

    Anyways, check it out at codeplex: http://www.codeplex.com/nxl

  • Scale Cheaply - Memcached

    I generally subscribe to the attitude that premature optimizations are evil, but I strongly believe that a robust caching strategy should evolve alongside the rest of the system. Waiting too long makes it hard to cleanly and thoughtfully add caching. Besides, in my experience, a considered caching strategy generally means I worry less about performance in other areas - especially data access and data modelling. In other words, I can build those complex parts for maintainability, as opposed to having to worry about the cost of each individual query.

    .NET developers are pretty cache-savvy - thanks largely in part to the powerful System.Web.Caching namespace and ASP.NET's simple to use OutputCaching capabilities. For that reason, and the fact that it tends to be very application specific, I don't want to go over how to decide what to cache, how to deal with synch issues, updates and so on. Instead, I specifically want to talk about Memcached.

    You're probably already familiar with Memcached - it's a highly efficient distributed caching system. It's used generously by all the big web 2.0 players (In may 2007 it was revealed that Facebook relies on 200 16GB quad-core dedicated Memcached servers). Interest in Memcached from the .NET community has been relatively low (although over the last year more and more people are talking about it). Frankly, if you're doing anything that requires horizontal scaling you're seriously shooting yourself in the foot by overlooking it. It runs on windows - although we run it on Linux and there's really no reason for you not to learn that too!

    Fundamentally, there are two problems with the built-in cache. First, it's limited to the memory of a single system which happens to be shared with the rest of your application domain. Secondly, if you have two servers, each with their own in-memory cache, users are likely to see very weird synching issues. Memcached isn't as fast as in-memory caching, but will scale to virtually unlimited amount of memory. There isn't any redundancy of failover, simply memory spread across multiple servers.

    The best part is that it literally takes seconds to get it up and running. First, download a windows build onto your development machine here. (look for the win32 binary of memcached). Unzip the package somewhere, I put mine in c:\program files\memcached\. Next, from the command line, run memcached -d install. This will install memcached as a service. You can run memcached -h for more command lines options. You'll need to start the service (I also changed my startup type to manual, but that's completely up to you).

    The next step is to install the client library. I use suggest Enyim Memcached from CodePlex. The project comes with a sample configuration file, which you should be able to easily incorporate into your web.config or app.config. While developing, only put one server 127.0.0.1 on port 11211 (which is the default). You also need to add a reference to the two dlls.

    Aside from that, you basically program against a simple API. You create an instance of MemcachedClient (it's thread-safe so you can use a singleton, or re-create it since it's inexpensive to create), and call Store, Get or Remove (or a few other useful methods) like you would the normal cache object. As I've blogged about before (here and here), I'm a fan of hiding all of this behind an interface to ease mocking and swapping.

    Here's an example:

    MemcachedClient client = new MemcachedClient();
    client.Store(StoreMode.Set, "Startup", DateTime.Now, DateTime.Now.AddMinutes(20));
    DateTime startup = client.Get<DateTime>("Startup");
    client.Remove("Startup");
  • Get Your Func On

    I've noticed that I have a 2 step pattern for learning new framework or language features. I'm guessing this is pretty typical for most people. First, I'll use the feature within framework classes or 3rd party ddls. Then I'll leverage it more directly within my own code. What's surprising to me is the length of time which occurs between step 1 and step 2.

    Take generics for example. Back in the 1.x days, I wrote a ton of repetitive classes that inherited from CollectionBase. So when 2.0 came out, I immediately and aggressively started to use generic collections. However, it was quite some time later (a year?) until I wrote my own class that leveraged them directly. Today, I don't write a new generic class every day, but I do consider them an important part of my toolbox and kinda wonder what took me so long to take them up.

    I have a feeling that many developers are in the same boat - it's easy to consume code that implements new features, but not so easy to grasp how to implement those same features ourselves.

    As it turns out, the other day, I had another such ah-hah moment with the System.Func generic delegate. Like me, you've probably consumed it often, or at least one of its cousins: System.Action and System.Predicate. I thought I'd show how I used it, in hopes that it might open up some possibilities for you.

    Ovewview

    First though, a brief overview. The three delegates above are essentially shortcuts that save you from having to write your own common delegate. The most common one is probably Predicate<T>, which returns a boolean. Predicte<T> is used extensively by the List<T> and Array classes. The most obvious is the Exist method:

    List<string> roles = user.Roles;
    if (roles.Exists(delegate(string r) { return r == "admin";}))
    {
       //do something
    }
    

    or the lambda version (which I much prefer)

    if (role.Exists(r => r == "admin))
    {
    }

    Func<T> is a lot like Predicate, but instead of returning a boolean it returns T. Also, Func<T> has multiple overloads that let you pass 0 to 4 input parameters into the delegate. Action<T> is like Func<T> except it doesn't return anything - it does an action.

    Code Decoupling

    So, how can you make use of these within your own code? Well, here's what I did. First, I'm a big proponent of caching, as well as a big fan of unit testing. However, the two don't easily go hand-in-hand because Microsoft doesn't provide an interface to their built-in cache, which leads to tight coupling (which of course makes it difficult to change caching implementation down the road, and impossible to unit test). The first thing to do is create your own interface, a simple start might look like:

    public interface ICacheManager
    {
       T Get<T>(string key);
       void Insert(string key, object value);
    }

    Next comes our first implementation:

    public class InMemoryCacheManager : ICacheManager
    {
        public T Get<T>(string key)
        {
            return (T) HttpRuntime.Cache.Get(key);
        }
        public void Insert(string key, object value)
        {
             HttpRuntime.Cache.Insert(key, value);
        }
    }

    Func Fights Repitition

    So, what does all this have to do with System.Func? Well, the above code is used in a very repetitive manner: get the value from the cache, if it's null, load it from somewhere and put it back in the cache. For example:

    public User GetUserFromId(int userId)
    {
        ICacheManager cache = CacheFactory.GetInstance;
        string cacheKey = string.Format("User.by_id.{0}", userId);
        User user = cache.Get(cacheKey);
        if (user == null)
        {
           user = _dataStore.GetUserFromId(userId);
           cache.Insert(cacheKey, user);
        }
       return user;
    }

    After a year or so of writing code like this, I figured there must be a better way, which of course is where Func comes in. Ideally, we'd like to get the value, and provide our callback code all at once. So, let's change our interface:

    public interface ICacheManager
    {
       T Get<T>(string key, Func<T> callback);
       void Insert(string key, object value);
    }

    The second parameter is the delegate we'll want to execute if Get returns null. Of course our delegate will return the same type (T) as Get would - just like in the above case where we expect a User from both Get and our data store. Here's the actual implementation:

    public T Get<T> (string key, Func<T> callback)
    {
       T item = (T) HttpRuntime.Cache.Get(key);
       if (item == null)
       {
           item = callback();
           Insert(key, item);
       }
       return item;
    }

    How do we use the above code?

    public User GetUserFromId(int userId)
    {
       return CacheFactory.GetInstance.Get(string.Format("User.by_id.{0}", userId), 
                                                                    () => _dataStore.GetUserFromId(userId));
    }

    I know the () => syntax might be intimidating (especially if you aren't familiar with lambdas), but all it is is a parameterless delegate.

    Of course, this system can easily be expanded to add additional caching instructions (absolute/sliding expiries, dependencies and so on) via overloaded Get<T> and Insert members.

    (I just noticed this example also highlights how to use generics within your own code too!)

More Posts

Our Sponsors