Introducing Proaction Mentors… although it really could be written with an optional plural form:

Proaction Mentor(s)

Obviously this is something that I’m extremely excited about! I’m also super busy with billable client work and speaking engagements (all good problems to have!) I’ll be blogging about Proaction more in the weeks to come, especially as the website launches, the business plan solidifies, and new announcements develop! (Stay up to date by Like’ing Proaction on Facebook and following us on twitter.

In the mean time – I hope to see you at some of these upcoming events!

Improving’s Agile .NET Conf – Improving Enterprises (my good friends and former employer) hosted the Agile .NET Conference at Microsoft again this year. I was honored to be the only non-Improving person invited to speak! – April 30th

Dallas .NET User Group’s Visual Studio 2010 Community Launch! – to celebrate the RTM (release to market) of Visual Studio 2010, the Dallas .NET UG is having an all out bash… 8 speakers in 1 night! Come see my talk:
Silverlight 4 – World Domination! – May 13

Big (D)esign Conference is happening again! This time it’s over twice as BIG as last year! Seriously, my hat goes off to the organizers and the local DFW UPA! That put together an amazing conference last year that I was excited to be a part of (Silverlight 3: Bringing Back the Sexy) and this year, they’ve more that doubled the size and scope. Amazing! Hope you can make my strategic talk on “The 10 Practices that every developer should start right now”.  – May 28th & 29th

Dallas Tech Fest – What could be better than last year’s inaugural Tech Fest in Dallas? Why, the second year of Tech Fest of course! Tech Fests are unique in the way that they specifically work to pull in technologies from various stacks… not just .NET – expect to see .NET, Ruby, Java, Silverlight, Flex, iPhone development as well as a healthy open conference style area. I was a little crazy and submitted 5 different talks to this event, I’m certain I won’t do all of them… but I’m looking forward to seeing what Tim picks!- July 30th

Update: This just in.. there is a “rumor” that I might present at a two day work shop style event in Dallas some time in June. Stay tuned!

The first time that someone taught me about Software Design Patterns it went something like this:

• Them: “… and so that is the pattern.”
• Me: “That’s it”
• Them: “Well, yeah.”
• Me: “But that’s how I’ve always done that.”
• Them: “Well, then you’ve always been following that pattern”

I find that is how a lot of people react when they first learn about patterns. “So a pattern is just giving a name to good software development” Well, yes and no. On the one hand – yes, a software pattern is recognizing common software challenges and the approaches that have worked in the past to over come those challenges – and naming it. On the other hand, don’t underestimate the power of giving something a name.

Vocabulary

There is power in a common vocabulary. Think about it, every profession has one. From the dentist that cleans your teeth to the short order cook at Denny’s; from the mechanic that works on your car to the contractor that built your house. Every profession has it’s own vocabulary that gives people a fast and efficient way to communicate.

So that instead of taking time to walk through all of the details of your architecture and application design, you can have a conversation that goes something like this “We’re writing a facade layer here, and utilizing a DI container to act as our Abstract Factory, accessing our persistence layer with a repository pattern utilizing Interception for logging and MVVM to composite all of our UI.”

OK, so I know that there were a lot of buzz words thrown in there, but I hope you’re getting the point – a lot can be communicated in a couple of sentences.

Patterns

Let’s face it – there is more to learn than any of us has time for. Patterns are like that. There’s a pattern for everything – like a bad Apple commercial, there’s a pattern for that. The important part is not learning every pattern under the sun – but learning the common patterns for the common challenges is where you’ll get the most bang for your buck.

Component Patterns

Strategy | Factory | Abstract Factory – all related.

Factory. The goal of a factory pattern is to conceal the creation of an object from the consumers of the object. This is especially important for complex objects that take a lot of dependencies or configurations when you create them. Instead of repeating the set up code through out your application you move it to one place (the factory) and then call that from your code.

take this (slightly contrived) code example…

            SqlCommand cmd = new SqlCommand();

            SqlParameter parm1 = new SqlParameter();
            parm1.Direction = ParameterDirection.Input;
            parm1.ParameterName = "Id";
            parm1.Value = 5;
            cmd.Parameters.Add(parm1);

            SqlParameter parm2 = new SqlParameter();
            parm2.Direction = ParameterDirection.Input;
            parm2.ParameterName = "State";
            parm2.Value = "TX";
            cmd.Parameters.Add(parm2);

            // etc...
       

It would be much nicer to implement a reusable method as so…

      SqlCommand cmd = new SqlCommand();
            cmd.Parameters.Add(getInParm("Id", 5));
            cmd.Parameters.Add(getInParm("State", "TX"));

            // etc...
        }

        SqlParameter getInParm(string name, object value)
        {
            SqlParameter parm = new SqlParameter();
            parm.Direction = ParameterDirection.Input;
            parm.ParameterName = name;
            parm.Value = value;
            return parm;
        }

       

This probably seems like an obvious and simple example (because it is), but the point is that not all patterns are ground breaking or earth shattering, just simple approaches to make your code more usable, maintainable and testable.

Abstract Factory. If you set up your factory to return an Interface instead of a concrete class then it is an abstract factory. This is especially useful when you want to return different implementations in different scenarios. For example, you might have an IDataLayer and in some cases you want to return a fake version for testing, or perhaps you need a local storage version for offline scenarios etc.. moving the creation of your data layer, it’s configuration and set up to a factory would make a lot of sense. By the way, this is also a text book definition of Object Oriented Polymorphism – the same interface with different behaviors with various implementations. And that brings us to the Strategy Pattern.

Take our example above, if we were to move that bit of code in to a shared data access helper class, we might want to consider a more generic approach.

      IDbDataParameter getInParm(string name, object value)
       

Strategy Pattern. The original goal of the strategy pattern was the grouping various algorithms in to common interfaces. So, for example, working with DES, Triple DES or Blowfish encryption shouldn’t be any different than driving a V8 is different from driving a 4 cylinder car – what’s under the hood (the implementation) doesn’t matter as long as you know hot to use the steering wheel and pedals (Interface). No code examples here. Go take a look at encryption in .NET, or the common approaches that ADO uses for data access. Also, hang on, we’ll go in deeper to code examples in just a bit when we talk about composition over inheritance (which is closely related to Strategy Pattern)

Up next: UI Patterns for Testability, Maintainability and Extensibility!

(Followed by Composition over Inheritance)

Images Credit: http://www.flickr.com/photos/webtreatsetc/4229661317/sizes/o/

North Dallas .NET Users Group – March 3rd

First, Wednesday March 3rd, I’ll be at the North Dallas .NET Users Group talking about Model View View-Models (MVVM) for your Silverlight Applications. If you’ve ever seen my Dependency Injection for Silverlight talk, this is pretty much the follow up to that. (above is a snapshot from the last time that I spoke there.)

Technically Speaking DFW – March 27

Have you ever wanted to be a technical presenter, but you weren’t sure how to get started? Or do you want to take your technical presentation skills to the “next level”? This this is the event for you! I love the idea of events like this, and I was honored to be invited to participate. Maybe this will spark more interest in groups like Presenter Mentor?

Teresa Burger, awesome community member and talented developer over at Woot! is organizing this event. It’s $50 to attend, includes lunch, and is a full day of Dave Gunby, Microsoft’s Chris Koenig, MVP extraordinaire Tim Rayburn and also yours truly.

Register for both!

• Register for the North Dallas DNUG – Wednesday March 3rd (Free)
• Register for Technically Speaking DFW – Saturday March 27 ($50)

Yep, this is going to be a fun month! Hope to see you there!

When writing software, we often don’t think about the security implications of our actions. Probably because we write software to do something, we’re not always aware of what it shouldn’t do. Their are a lot of guidelines for writing secure code, and designing secure systems. Rather than going in to all of the areas, let me just hit on some of the especially important topics that I’ve come across…

In addition to this post, I’ve included a slide deck that I use when I give talks about writing secure code. A lot of the original slides I got from a talk that Ron Jacobs did at TechEd. I hope you enjoy both!

Buffer Overflows and Overruns

OK… so I’m mostly going to deal with issues that affect .NET developers. .NET prevents Buffer overflows by not giving your code direct access to memory addresses and instead by managing memory access for you and by making sure that everything is type safe.

Here’s my non-technical version of what a Buffer Overflow is. First, a Buffer overflow is something that affects unmanaged code (or unsafe C#). Let’s say that a memory address is designed to hold 9 bits of user input, and instead the user forces 10 bits a information in to it. Normally, the last bit of memory is a return address and tells the code where to go next. In a Buffer overflow attack, a different return address is forced in to that last slot so that the attack can control the flow of the code.

For example, the code might say something like, “If the user is not authorized return to login” and instead the attack forces a return code so that it ends up doing something like this “If the user is not authorized go to the bank account withdrawal screen”. By simply changing the flow of an application, and attacker can do really bad things.

Fixes:

1. Use .NET (and get out of that unmanaged C++ code )
2. Use safe libraries. Many of the C++ common libraries have been re-written to help prevent Buffer Overflow exposure. Make sure that you are using the updated libraries.
3. Check out the “Banned.h” header file from Microsoft. It’s is a sanitizing resource which supports the SDL requirement to remove banned functions from a code. It lists all banned APIs Download.
4. Use the /GS Compiler switch. This was introduced by Microsoft to automatically add safety checking to your code when it compiles.

XSS

XSS is an abbreviation for Cross Site Scripting attack. (I know, but CSS was already taken ) XSS attacks are something that has affected every major web site at one time or another.

Background: When you connect to a website, like amazon or ebay (or any other site that you log in to) it often uses a session cookie to know who you are, and what you are allowed to see (your account info for example). Cookies are not a problem in and of them selves, in fact, your browser makes sure that it only send cookies to the web site that it was issued from. See – your browser trusts the site that you are on.

What is it: In a XSS attack, a malicious user figures out how to load their JavaScript to a trusted site. So that when your browser sends them your cookie, the malicious JavaScript has access to your cookie and forwards it on to the attacker. Then the attacker can impersonate you and access your information.

How it works: Have you ever searched for a random product on a site, like foo, and received a response message that said something like “your search for foo was not found.”? Try searching for “<b>foo</b>”. What happened? If the message looks like this: “your search for foo was now found.”, then they are probably not sufficiently checking the user input. Now image searching for this:

If you get a pop up that say’s “oh noes!” then this site is definitely vulnerable.  You see, as far as your browser is concerned, this JavaScript is coming from the server that is generating the result page. Now imagine sending someone an email with a link to go check out this great deal on a new bike [inline] http://newbikesforSale.com[/inline]!

The link above looks legitimate, but it’s actually a link that contains JavaScript to open an simple alert box. You can trust it (it won’t hurt you I promise), but in a XSS attack an attacker uses HTML mixed with JavaScript to embed their JS code in an email link, or more likely on a comment thread, in a blog review, or any place that will let it in.

Fix: All user input is considered evil until proven otherwise. The problem is that we haven’t traditionally considered search forms and product reviews as user input in to our systems, but they are. You can scrub user input easily enough by doing something like string SafeToDisplay = Server.HTMLEncode(userInput); but really you should look at incorporating some of the libraries that are specifically designed to handle these scenarios. Check out Microsoft’s Anti-Cross Site Scripting Library, it’s very comprehensive and covers many more scenarios.

SQL Injection

All user input should be considered evil until proven otherwise. This has never been more true than it is with SQL Injection vulnerabilities.

How it works: Imagine that you have an application with a log in: User name and password.

Pretty simple so for huh? Now think about the SQL that you would write to validate a user…  It *might* start off looking something like this:

So far so good… as long as everyone enters a user name and password in to the correct textbox on the screen this should validate them perfectly…

but what happens when you enter something unexpected in to one of the boxes..

what would the resulting SQL?

the problem here is that the text from the form is now being executed as part of the SQL statement itself. SQL injection just allowed this person to operate this application with the username BillG… I’m sure that wouldn’t be a problem!

Not just Log In Screens. Any place that user input is translated in to a query to the database is open to attack. Search fields are a notoriously overlooked place for SQL Injections, and not just for logging, at this point the attack can do anything that the application can do. Even worse, many application run as SA (Sql Administrator) just to make “life easy” on the developer. That opens up a whole new problem. Imagine a random user being able to log in to your system, add themselves as an administrator, shut down your server, rewrite your website, reformat your hard rive all from a search box. See the problem?

Fix: the fix is easy, don’t let user input run as SQL. You can prevent SQL Injection by moving away from concatenated string for building sql queries. if you need the flexibility of ad-hoc sql, then write your adhoc sql using parameterized SQL.  Otherwise you can move to stored procedures or an ORM like Linq to SQL, Microsoft’s Entity Framework, or nHibernate that will automatically use parameterized sql for you.

White List vs Black List Principle

One thing that I want to call out at this point. It is very tempting to try and “sanitized” every user input instead of moving to one of the more robust solutions mentioned above. I had a friend (a very good developer) that was sanitizing all user input for “bad” words before he would process it. In his words, “we don’t have any products called drop, delete, execute… so I should be able to do a string.Replace on those words and then be fine.

Here’s the problem with that. In Security there is a concept of White List vs Black Lists. A white list approach says, here is what I will allow, and throw away anything else. A Black list take the approach that says, “here is what I won’t allow, I’ll let in anything else that’s not on this list.” The problem with the black list approach is that security is a moving target, there are vulnerabilities today that we didn’t know about yesterday, there will be more tomorrow that I don’t know about today. Just because something isn’t on my “bad” list today, doesn’t mean that it shouldn’t be.

I went to my friends bad word scrubber and entered this : ‘deldeleteete” do you see the word delete in there? What will  happen after your scrubber removes it… you’ll be left with “delete”. He started using parameterized SQL.

Encryption

I once interviewed a really smart computer science guy that wanted to come work for our consulting company (primarily focus on business applications). Saying this guy was smart is an understatement. He was a Computer Science PhD candidate with cross disciplines in artificial intelligence and game theory. wow! The problem was that he had very little knowledge or experience writing actual applications. When I asked him about if we should write out own encryption for some application that we were working on, he got all excited and started to go in the details about what it would take to implement out own encryption. I’m pretty sure he had taken a class on this, wrote some thesis on it or something because he was really excited that I had asked him about this topic. Here the thing, never write your own encryption.

Getting encryption done right is hard.. like really hard. In fact, if you are good at it, maybe you should go work for the government, or a university, or RSA directly, but you have no business trying to do that for a business application. Use the tried and true, multiple encryption, publically available libraries to do it right.

3-Types of encryption.

Private Private Key, also known as a symmetrical encryption uses the same key to encrypt and unencrypt. Symmetrical encryption is very fast, so it’s great for encryption transmissions and it used for things like secure communication and SSL. the problem is that it’s less secure because you have to have a secure way to hand out the private key.

Public Private Key, also known as asymmetrical encryption uses two different keys. One key (the public key) is used for encryption, the private key is used for decryption. The benefit here, is that you can yell out for the world to here your public key, but only the person with the private key can do the decrypting. The problem is that it’s very slow and computationally expensive.

So how can two computers talk securely to each other in an open environment like the Internet? The answer is a combination of the above. SSL, or secure socket layer uses a public key to securely transmit a “session” key that will be used for symmetrical encryption for the rest of the communication.

1-Way Hashes cannot be encrypted. How is that helpful? It’s very helpful. A hash can me used to make sure that two values are equal without actually knowing what the values are. For example, my application should never store plain text passwords. If they did it might be possible for those passwords to become compromised. By storing a 1-way hash instead the password cannot be retrieved even if the database (or a backup of the database) is compromised. How do I log user in to the system then? Simple, I take the password they give me, I has it using the same method and compare the two results.

Digital Certificates – Digital Certificate use a combination of the above concepts to support secure communication and identification. We’re just not going to go in to all of that now.

Least Privilege Principle

Reduce your Attack Surface – if you don’t need a service, turn it off. If your application doesn’t need permission to do something, don’t supply it. By limiting the scope of what can be done, you also limit what can be broken if and when things go bad.

Default to Fail – Here’s an example.

What’s wrong with this code? (ok, a lot ) But what we want to focus on is that if there is an exception along the way, it will default to the user being authenticated. The [valid] should have been set to false, until proven otherwise.

Don’t reveal more than is helpful to the user. Be helpful, but you don’t have to thrown up every SQL exception on your users.. log that stuff, let the debug team look at it, but knowing what version of SQL server you’re running or what the stack address is completely useless to your users… but bad people love that stuff.

I love this screen shot. Is that error helpful to you? It says “Error 0x80090022” but it means “No smart card inserted in reader.

Don’t give away your system internals, at the same time make sure that your user errors are helpful!

More resources…

OK.. as you can imagine there’s a lot more that we could cover, but instead take a look at some of these resources.

Threat Modeling Tool – Threat modeling is all about identifying assets, vulnerabilities, resolutions, evaluating a business value on assets, then balance the cost of a resolution with real business value.

SDL Process Template for Team System – SDL is the Security Development Lifecycle, it’s a set of practices and tools that help integrate secure development in to all aspects of SDLC (Software Development Life Cycle). This is Microsoft’s template to integrate SDL with Team Foundation Server (Microsoft’s Application Lifecycle Management Server).

SDL Process Tools – There’s a ton here, check it out.

MSDN Security – Read the blogs, latest news, and downloads regarding Microsoft security and development.

Happy Coding (securely)!

Images Credit: http://www.flickr.com/photos/carbonnyc/2294144289/

Update: This post was picked up by DZone, go vote it up!

Ok, before you dig in to the post, let’s get two things out of the way first.  1.Go read the authority on SOLID principles from the man himself, Uncle Bob Martin.  2nd.Go get the very cool Inspirational SOLID images from the guys over at Los Techies. They released them under a Creative Commons License which I think is pretty cool! Alright, got that out of the way? Good. Let’s get started.

Few things have come a long OO history that resonate so well with so many developers than the SOLID principle. One of the reasons they resonate with so many developers is because they communicate several practices that many developers have been doing all along. The beauty and power of the SOLID principals in in there ability to communicate, what I call code architecture, in such a memorable and practical way.

Like any good thing, however, taken to an extreme can become a hindrance on any project. So, I’m going to tackle these principals like I tackle everything in this series… give you my take on it. So here you go: SOLID according to Caleb.

[SOLID Motivational Posters, by Derick Bailey, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License. Get them here.]

S – Single Responsibility Principal #

"There should never be more than one reason for a class to change." — Robert Martin, SRP paper linked from The Principles of OOD

Abuse: I’ve seen this taken to an extreme. I’ve seen good clean readable code turned in to multiple classes (even multiple projects) to break up “responsibility”. The end result was much harder to maintain and even harder to read.

Applied: “One reason to change” does not mean that every class has one and only one thing (that would be called a method), it does mean that you should focus on the area (or areas) of responsibility that a class should have and then stick with those boundaries. Code bloat (overly large classes with overly large methods) is a real code smell that you need to watch out for. The more things that a class is responsible for, the more likely you’ll have to change it and the harder it will be to test.

Your code should be broken in to manageable pieces, reduce any unnecessary couplings… Practice writing Libraries not Frameworks.

O – Open Closed Principle #

"Software entities should be open for extension, but closed for modification." — Robert Martin paraphrasing Bertrand Meyer, OCP paper linked from The Principles of OOD

Abuses – I’ve worked on code bases that were so extensible, so configurable, so full of AOP indirection and configuration that following the flow of what they were actually doing was almost impossible.

Applied – Code is going to change, that’s a part of life. The Open Closed Principal is more about reducing how often you have to change your code and in how many places. In other words: Code to Interfaces and maintain your abstraction boundaries.

I recently worked with a Linq to SQL project where the Data Context object was being passed around through out all of the layers in the application. That meant that most of the application was impossible to unit test and if I were to change a column or table in the database I would have to go through the entire code base and find all of the places that broke. We fixed that by creating a specific data interface that all interactions had to go through, only passing domain objects (DTO Models). We kept the DB Context in the Data Layer implementation where it was super useful, but no longer forced us to recompile the entire source for simple data changes. I like how approach that Jeffery Palermo described and an Onion Architecture.

I also worked on another project where 8 layers of abstract classes were used to distinguish between three different types of physical devices… any change in the application behavior had to be propagated across all of the implementations. We fixed that by concealing the device differences behind a single command interface that was then injected in to the application “behaviors” via an abstract factory.

What did you just say?

So in other words… imagine having three different devices (blue, red, green) that all needed to be turned on (behavior), but the command to turn on each was different and defined by the manufacture… the code *might* look like this:

Now imagine that there were multiple points within your application where you were working with the devices… now, every time you need to support a new device you end up with this if/else statement being redone just about everywhere…

By externalizing the device differences behind a factory and encapsulating them in an Interface you now only have one place to change to add a new device. You could reduce that further using an extension manager like Microsoft MEF, but we won’t go in to that right now.

L – Liskov Substitution Principle #

"Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it." — Robert Martin, LSP paper linked from The Principles of OOD

Abuses: I like to think of this principle as “Use Interfaces”.  I haven’t really seen abuses of this practice, but I have seen some bad implementations. The rough ones, are where developers rely on a base abstract class instead of an Interface also. The doesn’t sound like a problem until you start putting parameters in the constructor of the base class. Now any derived classed have to enforce those same dependencies even if you are creating an entirely different implementation.

Applied: Use Interfaces. If you find that a base class would meet some of your needs more closely, that’s fine, just make sure that you back that base class up with an Interface, and then code to the Interface.. you’ll thank me later.

Side Note: Their are different schools of thought around backing domain models with Interfaces. I do, the main reason is that even if I end up using an ORM (like Entity Framework, or LinqToSQL) that “forces*” me to a specific domain model implementation, I can save myself a lot of headache later and make my models more mobile if I connect those domain models to an Interface.

* – no toolkit should force your architecture or design, any implementation can be abstracted around, Domain Model Interfaces help move your DTO’s through layers of your application without carrying heavy dependencies with you.

I – Interface Segregation Principle #

"Clients should not be forced to depend upon interfaces that they do not use." — Robert Martin, ISP paper linked from The Principles of OOD

Let’s say you have a service class for working with Invoices, your IManageInvoices interface exposes three methods, Add(IInvoice), Delete(IInvoice) and Update(IInvoice). Because of deployment and security concerns you are going to create two different classes to implement this.

One, InvoiceCreator will implement the Add method and run in untrusted environments. The other class, InvoiceUpdater, will implement the other two methods and will only run in secure, verified and authenticated context. So what should each class do with the other methods?

Violated: One “option” would be to implement them, but then throw a “Not-Implemented Exception” or set up Void methods that don’t actually do anything, both of those options are ugly and bad choices.

Applied: The better option is to split your Interface, create a ICreateInvoices Interface with the Add method, and a IUpdateInvoices interface with the other methods. That way, you are actually implementing the methods of your interface, and are not hiding are making implementation decisions that break your abstraction and require special knowledge of the class.

D – Dependency Inversion Principle #

"(A) High level modules should not depend upon low level modules. Both should depend upon abstractions. (B) Abstractions should not depend upon details. Details should depend upon abstractions." — Robert Martin, DIP paper linked from The Principles of OOD

All code has dependencies, the question is how to you resolve those dependencies.

Example: my class will access a service, I could write it like this:

or like this:

Can you spot the difference? It’s subtle, yet very very powerful. In the first instance, you are using an Interface to define your Shipping Service (and that’s a good thing!), but then you are forcing your class to be dependent on the UPS shipping service… I don’t have anything again UPS, but I do know that company contracts are constantly changing, and just because we were using UPS when we designed and had the customer (business owner) sign off on the application, doesn’t mean that that’s who we are going to use when we go to production!

You might be tempted just to replace the “new UPS” instantiation with an Abstract Shipping Factory ( shipService = factory.getShippingService() )… that wouldn’t necessarily be a bad idea, except now you’ve shifted your code from a UPS dependency to a factory dependency.

Notice in the second option, we hand our class the implementation that we want to use through the constructor. That’s called constructor injection, we could have also used a property or method to set the shipping service. I like constructor injectors for anything that my class requires to operate. This allows us to define our IShipping service implementation completely independent of the class that’s consuming it.

This also makes are code much easier to test by allowing us to creating a mock (fake) version of our IShipping service for testing the main class. We might even use something like RhinoMocks to help our automated unit tests even more, but we’ll save that discussion for another time.

No Framework Required

You may have noticed that this dependency injection is not dependent on any special tooling or frameworks (so we’re not introducing new dependencies just to get rid of another!)

Dependency Injection or DI, is really a style of coding that makes your code more composable, testable and maintainable. DI Frameworks (or Containers) are specifically designed to be used in two stages.

Register, then Resolve

First, you register your Interface to Class mappings, then you can reference the container anytime and resolve an Interface to a concrete class. Containers can also provide other nice benefits like controlling the life cycle of an object (singelton, vs per thread, vs per request for example). Some DI frameworks also provide the ability register special handlers (or Interceptors) that get invoked whenever a method or a property is called. This in a concept known as AOP or Aspect Oriented Programming that is useful for cross-cutting concerns like automatic logging and security checks.

For more information on Dependency Injection and Inversion of control I suggest checking out my DI in Silverlight slide deck, as well as the Ninject, Castle, Microsoft Unity and Structure Map projects.

Enjoy!

If you are going to read through my “10 practices that every developer should start right now” series, then you probably want to know where these 10 practices came from, why I chose these 10 – really, what so important about secure coding anyway?   - I think that it’s important to know that these aren’t just 10 random items to fill a couple of blog posts. These are all practices that have been thoroughly thought out. This list is something that I started to formulate over a year ago based on my experience as a consultant, working as a technical editor, and discussions with countless MVPs, other consultants and in my interviews with potential consultants...

Experience. First, these 10 practices have come from over 15 years of professional development work, working with countless customers when I was at Microsoft, as well as the numerous development shops and enterprise customers that I’ve been a consultant for over the last many years. These are, what I consider, to be the biggest bang for your buck, the low hanging fruit that you can quickly implement and the practices that will yield the greatest value in the shortest time.

Writing a Book. I once had the privilege of working as a Technical Editor on a C# 3.0 book. That experience was both rewarding and frustrating. It was rewarding to go through the process, engage with the executive editors, author and see the whose process of writing a technical book move forward. It was also frustrating to know that – while everything in the book was technically accurate – it often was not the content that I would have wanted to cover. These are the things that I want to talk about.

Hiring. Over the years, but especially during my time as a Principal consultant for Improving Enterprises and now as the Senior Software Architect for Six Flags, I’ve spent countless hours interviewing various – really smart people – that often fell short. (I’m a nice guy – but apparently a pretty heavy handed interviewer). I’ve discovered that the things that matter in software development – are often not taught, even in the best schools. These are the topics that I wish every CIS/ MIS department would start covering to some extent. I sometimes wished that I had a “quick read” book that I could hand to people on their way out and say “here, read this. This is what you should know before you try to work here.”

Scope – Obviously any one of these topics could be a whole book in and of itself. So none of these posts are going to be intended as a “complete” reference or anything like that. More like “Caleb’s thoughts on the matter.”… and hopefully some useful insights, and enough information to let you, Dear Reader, move forward and know where to go from here.

So that’s my introduction. I hope that you’ll join me as we dig in to all 10 practices.

Enjoy the ride!

photo credit: flickr

This morning I turned on my computer to see that Todd Weiss and the folks at Linux.com had featured this idea on their home page. Go check it out the full article!

Related

• Featured article on Linux.com
• ars techica’s article on the Codeplex Foundation
• Jeremy’s Post on CodeBetter
• Scott Bellware chimed in on this "watershed moment, a turning point for the Microsoft platform and .NET community" - I couldn't agree more.
• Phil Haack is shedding some more light on Codeplex Foundation
• Red Monk's Q&A on the CodePlex Foundation

Enabling the exchange of code and understanding among software companies and open source communities

Sam’s primary focus is to drive Microsoft’s Linux and Open Source Strategy, working together with Microsoft technology development teams and open source communities to build interoperable solutions

Microsoft's open source strategy is no longer just locked in a single ‘lab' on campus - now OSS is an important part of many product groups and strategies across the company

Three reasons Microsoft needs an Open Source Officer

1. The Timing is Right – The Momentum is there. Change is in the air. Sam is moving on. The Codeplex foundation has launched, there’s a new Chief Architect in town, and Microsoft has embraced many aspects of OSS is so many areas of their business because they have realized that – when it makes sense and in the right environment, OSS is good for business and good for your customers.
2. It’s a different world out there. Not only has the world inside of Microsoft changed, so has the competition. Microsoft is increasingly competing in an open web world, with open standards against open platforms. More and more, these competitors also become their partners and customers.
3. Go big or go home. I believe that it is the spirit of Microsoft to take on new challenges, to put there money where there mouth is, and to embrace a big future with a strong vision.

… I’m just sayin.

In June I’ll be the local Silverlight expert, leading a technology track on Rich Internet Applications (RIA) at a Microsoft’s BizSpark event, SparkStart.

From the official announcement:

SparkStart is a full day of business and technology discussion (open format) and learning event for startups (“startup bootcamp”). This event will also be a networking opportunity for those startups who are new to the BizSpark program and not yet enrolled in the program and would like to mingle and learn from key business and technology influencers. It will also be an event for those startups who are recently enrolled and need to keep the momentum going by learning key strategies for success, both in business, and in technology.

I’m looking forward to checking out Microsoft’s new Technology Center in Las Colinas, TX – It’s an amazing building!

It’s going to be an incredible event for startups and entrepreneurs to learn, network and get to know some of the incredible technologies that are now available. I’m especially looking forward to hanging out with some of the other people that will be presenting at the event. (too name a few)

• Local start up expert, Alex Muse
• Social Media Expert, Giovanni Gallucci
• Blake Burris of Facebook development and CoHabitat fame
• Angel investment and venture consulting mastermind Marc Nathan
• Microsoft User Experience Architect Christian Thilmany
• Microsoft Architect Brian Gorbett

Check out SparkStart on twitter and read some of Christian’s other related posts. Be sure to register. It’s going to be an amazing day!