# Monday, February 13, 2012

I am currently in the process of getting my Microsoft Certification mainly because I was told I should.  I have started the process 3 times previously in my career but quickly “fell of the wagon” due to priorities I deemed more important such as bringing you this awesome blog content Smile.  I guess I have never really placed a lot of importance in certifications and figured that my past work/reputation are enough.  Anyone can pass a test with enough memorization of content, but not everyone can deliver quality software applications.

My thoughts on certification

  • I have never lost an opportunity as a consultant because I was not certified.
  • Certification is beneficial to new grads/ new entries in the software development work force.
  • Experience and proven track record should far out way a certification.
  • The content, at least in Microsoft exams, does not reflect the world.
  • You should be reimbursed for your time and fees should be covered by your employer and /or a comparable bonus should be awarded.

So, the point of this post, other than to get something out quick so I can get back to studying for said certification exam 1, is to ask a few questions to you my loyal audience.

  1. Are you certified in any technology/methodology/software practice?
  2. If you are certified:
    1. What are you certified in?
    2. Why did you get certified? 
    3. Did the content you study reflect the real world?
    4. Did you ever lose an opportunity prior to certification because you where not certified?
    5. Since becoming certified have you gotten an opportunity because you are certified?
    6. Did your employer provide compensation/bonus for becoming certified?
    7. What have you gained by becoming certified?
    8. Was it worth it?
  3. If you are not certified:
    1. Why aren’t you?


I would love to hear what everyone has to say on this.  Thanks for your time.

posted on Monday, February 13, 2012 4:27:00 PM (Central Standard Time, UTC-06:00)  #    Comments [2]
# Monday, January 30, 2012

The var keyword was introduced with C# 3.0 and the .NET Framework 3.5 to allow the declaration of implicitly typed variables.  The driving force behind the need for implicitly typed variables was the introduction of Anonymous Types

If you are using var outside of truly anonymous types you are doing so out of laziness.  I know this is a bold statement that a lot of developers are going to disagree with, so let me explain.

First off I totally agree that using var can speed up your lines per minute coded and I do use var in this manner.  But, I always replace var with the actual type after the fact.  You can do this with out requiring a large amount of time after the fact using a tool such as ReSharper and setting up you Clean Up Code” functionality to replace all usages of var with the actual type when possible.

Now for my supporting arguments:  *All of which only pertain to using var when the type is not truly anonymous.*

  • C# is not a Dynamic Language!  This may be bad or not ideal but it is fact.  The truth is not everyone is fluent in dynamic languages and they are not expecting to read code coded in a dynamic fashion when dealing with C#.
  • Code written in a dynamic fashion, i.e. implicitly typed , is harder to read, especially when you are not use to reading it.  I know what you are saying how is this hard to read?:
    1. var x = "This is not hard to read and understand what x is!";

    And you are correct, that example is not hard to read and figure what x is.  What about this?
    1. var x = from custs in dataContext.Customers
    2.         join orders in dataContext.Orders
    3.             on custs.CustomerId equals orders.CustomerId
    4.         join lines in dataContext.OrderLines
    5.             on orders.OrderId equals lines.OrderId
    6.         join products in dataContext.Products
    7.             on lines.ProductId equals products.ProductId
    8.             where products.Name.Contains("FooBar")
    9.         where custs.LastName.Contains("Smith")
    10.         select products

    I would much rather see and read;
    1. IQueryable<Product> x = from custs in dataContext.Customers
    2.                         join orders in dataContext.Orders
    3.                             on custs.CustomerId equals orders.CustomerId
    4.                         where custs.LastName.Contains("Foo")
    5.                         join lines in dataContext.OrderLines
    6.                             on orders.OrderId equals lines.OrderId
    7.                         where lines.Quantity > 10
    8.                         join products in dataContext.Products
    9.                             on lines.ProductId equals products.ProductId
    10.                         where products.Name.Equals("FooBar")
    11.                         where custs.LastName.Contains("Smith")
    12.                         select products;

              The truth is you know what your result is, at least you better or you have no business writing the code in the first place, so just declare it as such!

              One more thing,  var has no place in demo code, tutorials, and blog posts. The purpose of demo code, tutorials, and blog posts are to provide education and in doing so the code should be clean and concise and accessible to the masses.

              OK, let me have it.

              posted on Monday, January 30, 2012 10:00:02 AM (Central Standard Time, UTC-06:00)  #    Comments [12]
              # Monday, December 05, 2011

              Configuration of Entity Framework Code First is a necessary evil and you have to admit is a very well designed user friendly process.  But, in typical Microsoft fashion, the EF developers have given us more than one way to perform this configuration.

              1. Fluent API
                1. Fluent expression based configuration
                2. Performed during the OnModelCreating process of the DbContext.
                3. Allows for complex configurations that are not possible via Attribute based configuration
                  Fluent Configuration
                  1. protected override void OnModelCreating(DbModelBuilder modelBuilder) {
                  2.     modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
                  3.     modelBuilder.Entity<Model>().HasMany(x => x.AvailableEngines)
                  4.         .WithMany(x => x.AvailableOn)
                  5.         .Map(x => x.MapLeftKey("ModelId")
                  6.         .MapRightKey("EngineId")
                  7.         .ToTable("ModelEngine"));
                  8.     modelBuilder.Entity<Model>().Ignore(x => x.SomeDerivedProperty);
                  9.     base.OnModelCreating(modelBuilder);
                  10. }

              2. Attributes
                1. Attribute based configuration
                2. Performed directly on the Domain Model Class/Property being configured
                3. Allows the non-EF specific attributes to be used in other pieces of your application
                4. Allows validation of your Model at any time
                  Attribute Configuration
                  1. public class Manufacturer {
                  3.     public long ManufacturerId { get; set; }
                  5.     [StringLength(40)]
                  6.     [Required]
                  7.     public string Name { get; set; }
                  9.     [Required]
                  10.     [StringLength(40)]
                  11.     public string Country { get; set; }
                  13.     [Required]
                  14.     public DbGeography Location { get; set; }
                  16.     #region << Relationships >>
                  18.     public virtual IList<Model> Models { get; set; }
                  20.     #endregion
                  22. }


              So…When do you use which!?

              Use Fluent Configuration When:

              • Configuration is being done solely to make the database behave correctly.
              • Configuration has no effect on the design and/or behavior of your Domain Model.
              • Examples:
                • Specifying the database table the Domain Model is to be mapped to
                • Specifying the database table column the Domain Model Field is to be mapped to
                • Ignoring a Domain Model Field
                • Configuring the keys and table names for relationships not able to be picked up by EF

              Use Attribute Configuration When:

              • Configuration solely applies to your Domain Model.
              • Configuration has no effect on the design and/or behavior of your Database.
              • Examples:
                • Making a field Required
                • Validating a field (String length, Range, etc.)
              • Also…Don’t forget that for the most part these Attributes are not EF specific and can be used in the UI with MVC.
              posted on Monday, December 05, 2011 8:53:57 AM (Central Standard Time, UTC-06:00)  #    Comments [1]