Sometimes, you get spoiled by how things are done in organizations. I am having one of those moments today so I figured I should write about it. A good development environment needs a source of truth and a clear separation of concerns.

1) Source control is your source of truth. Anything not in source control did not happen. If you make a live edit to a file on the production server it is gone with the next update. This should never be allowed to happen. This is why I do a lot of deployments out of my  continuous integration server. The only way to deploy is for the server to get the latest version from source control and install it on the server. If it was not important to put into source control it was not important.

2) Be careful managing your database(s). I usually recommend each developer runs a local database. This way changes to the dev database don’t break other peoples code until you check your source code in. Having a system where change scripts are checked in an run can be troublesome to implement but it is worth it. The benefit being that when you migrate to your different environments you have a suite of scripts already written. Ensure these are in source control

3) Verification is a time consuming process. Having to diff filesystems and databases to find the truth is a time consuming process that is fraught with errors. One project I am inherited has source in four (or more) locations so establishing which is the most current is a frightening process.

4) Establish the different environments very clearly and limit access where appropriate. If you have a mess of servers with some running production and test and development you are going to hit points of confusion or have inadvertent updates to applications. It is simple enough to accidentally update the production database by accident if they are on the same server as your development database. I have always felt that developers should have almost zero access to the production system where possible. Yes, it makes it easier to debug but there are ways to allow developers to debug without making changes (e.g. access to the event log, read only access to the database / filesystem, etc.). I avoid even that due to security implications but if you need to then there are better options than admin rights to the production server.

I have published the FB 1.1 Beta (http://code.google.com/p/fluent-build/downloads/list).

This release contains some big changes.

Task Syntax

Gone are things like Run.[option].[option].Execute() and they have been replaced with Task.Run.Nunit(options=>options.specific.to.runner). This removes the need to remember to use .Execute() all the time (I was constantly forgetting and I wrote the thing). I am fairly happy with it so far.

Exampes:

Task.Build.Csc.Target.Library(compiler => compiler.AddSources(sourceFiles)
.AddRefences(thirdparty_rhino, thirdparty_nunit)
.OutputFileTo(assembly_FluentBuild_Tests));

Task.Run.UnitTestFramework.Nunit(nUnitRunner=>nUnitRunner.FileToTest(assembly_FluentBuild));

Task.Run.Zip(x=>x.Compress

.SourceFolder(directory_compile)
.UsingCompressionLevel.Nine
.To(directory_release.File(“release.zip”)));

FTP Publishing
As I mentioned in a previous post I added some quick and dirty FTP publishing. It only publishes a file at a time currently so its not a full fledged FTP publishing tool.

Errors
For a while I only had the error message publishing but I have switched that to include the full exception as it was problematic to find errors before. There have also been some internal changes to how return codes are handled from programs. If a third party program throws an error then FB will return an error code of 1, not the error code of the third part application.

Logger
The message logger code has been simplified a lot and will probably get another round of cleanup soon. It has been moved to Defaults.Logger for now but will probably get moved right into the BuildFile class you inherit from as that makes more sense to me from a user point of view.

Whats Next?
I am getting fairly happy with the application right now but I would like to do more testing before I release it. I will be tweaking a bit of code and adding some more functional tests to the build but I hope not to have any big changes for the next while.

One thing I really like about MSTest is that you can turn code coverage on so you can see where unit tests are lacking (or non-existent).

One thing I don’t like is that in VB there is a class generated for settings in the “My” namespace. While it is handy for coding in some cases it irks me that it gets included in my code coverage result.

The only way to exclude it (that I have found anyways), is to add the DebuggerNonUserCode attribute to the MySettings class in the project. Not very intuitive I know but maybe we can get a IgnoreFromTestCoverage result attribute someday. (NOTE: I did try to create my own custom attribute but DebuggerNonUserCode is not inheritable).

This class can be found by selecting the project in solution explorer, selecting “show all files”, then finding the Settings.settings file in the “My Project” folder. Alternatively you should be able to create a partial class if you want to avoid it being lost if the code is regenerated.

For those of you who have not been exposed to the Single Responsibility Principle it states that an object should have a single responsibility and therefore a single reason to change. This results in a codebase having many small classes that do one task.

Today I got asked why SRP is important and came up with a few good reasons off the top of my head:

Readability: The class is easier to read as it performs one task. Anyone should be able to spend under a minute and fully comprehend what the class does.
Testability: There is only one things to test so you write simple small tests that cover the few scenarios the object will experience
Reusability: The class is easier to reuse as it is not locked into one scenario. It can be used in multiple ways as it has set input/output expectations.
Easier To Code: It is easier and faster to code in small chunks than it is in large segments. When coding with SRP it is easy to break off a small chunk of functionality, write it, test it, then tackle another small chunk.
Bugs: By having code broken into many small classes bugs become easier to track down. If you have a 2000 line function and an exception occurs you will know there is a problem in that method. If the code is properly broken out into small 5-20 line methods you can track it down to that small function and usually spot the error in seconds.
Navigation:
Now many developers hate SRP as they end up having hundreds to thousands of classes in their projects. To me this is the only mild detractor of SRP but it is really not that hard to break classes into logical folders/namespaces to make it manageable. And honestly I find this makes things even easier to work with. If I want to get the data for student attendance by day report I may just type:

var reportDataRetriever = new Reporting.Students.Attendance.ByYear.Retriever();
var data = reportDataRetriever.GetDataFor(DateTime.Now.Year);

I find that this is quicker to navigate as I know first off that I want a report and that is in the “Reporting” namespace. Then Intellisence prompts me with all the possible things I can report off of so I pick “Students”. Then what I want for the student and that is “Attendance”. And on and on we go of narrowing things down. This allows me to find what I am looking for without having to remember the name of the class I would want to call.

I have seen way to many classes like this:
Public Class Reports
{
  Public Function GetAllStudentsAttendanceByYear(int year)
  Public Function FindTeachersWhoTaught(Course course)
  …. 20 other report methods
  Public Function StudentAttendanceFor(DateTime startDate, DateTime endDate)
  Public Function GetTeachersWhoTaught(int courseId)
  … 30 other report methods
}

To use this class becomes completely unwieldy. Naming convents first off are not consistent which is quite common so it makes it hard to use in intellisense if you have to try “Get______” or “Find_____” or “Student______”. If this was done with SRP then you would still have an inconsistent naming conventions but it would not be a problem as your code would still be easily navigable.

You will also notice that the Reports class example has two methods that return teachers who taught a course. This happens more than one might think in that a developer thought the method did not exist as they did not take the time to look through a massive class to find it did already so they created their own. If you were using SRP you would see in seconds that in the Reports\Teachers\ folder a class called something like a file named WhoTaughtCourse.cs or something similarly named that easily communicates that this work is already done.

A good debate in the development community is whether or not to specialize in something and tout yourself as an expert in just that. If you do specialize you probably will be able to find some good money as people pay well for an expert. On the other hand work is harder to find as you are in a niche and need to find people looking for an expert. Also when your specialization is not popular any longer you need to re-specialize in a new area.

One of the popular sayings in the development circuit is “Specialization is for Insects” taken from Heinlein’s Time Enough For Love. Most of us feel that specialization is the sure way to be good at something and terrible at everything else. Lets face it, as developers we need to solve many different problems and need a well rounded background to solve those problems effectively. Bringing in an expert may solve one problem but then they are discarded and the rest of the team carries on.

One overlooked item is that our offices need diversification (and not just in the we need more than white males working in our industry kind of diversification). By having and encouraging developers to learn things that others don’t know contributes to the entire knowledge of the team. If we are approaching a client/server design and one developer only knows COM+ but the other has a knowledge of WCF then we can discuss the pros/cons of each technology to make an informed choice.

I feel that is important to not have a homogeneous team in some areas. To debate something shows the strengths and weaknesses of decisions and yields a better outcome in most cases. Encourage and hire people that don’t 100% match what you do and bring their diversity into yours. It can help you open up doors to new clients or solve problems with current ones.

That’s right. We all knew it had to happen sometime…… SSL certificates are now spoofable. That’s right you can now create an SSL certificate that causes all major browsers to think that an SSL certificate is valid and from a trusted certificate authority.

How

The real problem here is that SSL supports the use of the MD5 hash function which has had known collision problems for many many years. A collision happens when two separate inputs generate the same hash i.e.:

md5(“asdgasdlghgds”)  -> %#QAJHAE%UNAW#$#E%QU*QABS
md5(“56832ujxdf175”)  -> %#QAJHAE%UNAW#$#E%QU*QABS

this reduces the time it takes to discover the input used to generate the hash drastically.

Most certificate authorities use a stronger algorithm like SHA-2, but a handful still use MD5 and therefore the SSL spec still supports MD5 and so all web browsers are vulnerable.

The details are not entirely clear yet but The Register reports that the spoofing is carried out by farming together more than 200 PS3 consoles to generate certificates until they found a pair that had a collision on the MD5 hash.

They first requested a legitimate certificate from an MD5 only certificate authority. Then they created their own CA credential and copied the legitimate signature into the rouge credential and re-signed it using the MD5 hash. By doing this it looks like the certificate was purchased from and signed (using MD5) from a legitimate company but in fact was generated and never purchased.

Effect

The big effect is that it could make it easy for phishers to impersonate sites if they can generate SSL certificates that are for sites like banking or other important websites. I wonder if PS3 sales will go up?

The Fix

This is a tricky issue to fix as all browser support MD5 signing and some certificate authorities only use MD5 signing. To fix this issue the browsers will need to be patched to not support (or at least warn) about MD5 signing. Also the certificate authorities that use MD5 will have to stop using MD5, switch to a new algorithm, and re-issue all certificates that are signed with an MD5 hash.

Should I Really Run For The Hills?

It really depends what the response is from the parties involved and how quickly attackers are able to exploit this. Currently the researchers have announced and demonstrated the attack but have not released any fine details that would allow an attacker to create their own but it is only a matter of time.

To execute a phishing attack against a user the attacker would need spoof both the DNS lookup and the SSL certificate of the site. While this is possible so many people fall for the simple attacks I am not sure that attackers will jump on this.

On the other hand it could give rise to companies selling counterfeit SSL certificates but that remains to be seen.

*UPDATE: the actual paper can be found here: http://www.win.tue.nl/hashclash/rogue-ca/

So a few of the passionate conversations here at the MVP summit have been around sacrificing testing when a deadline looms. Apparently this is a common practice amongst MVPs which I think a lot of us were quite surprised at.

D’arcy, Rod, and myself were talking about this at lunch so I thought I would add our thoughts to the mix:

There are a few things you can do when under a looming deadline:

Add Resources
By adding resources to a project you can get more done in more time…. in theory. Granted there is only so much a new person can do. They have to be interviewed, trained, and not be a drag on the team. Adding more resources could actually cause you to not meet your deadline unless a lot of foresight and careful consideration is taken into place.

Cut Features
Its much easier to hit a deadline when there is nothing to do. This is usually one of the best options to give your clients I/we feel. A client is usually happy to delay a small / lower priority item in order to get the higher priority items on time. Then follow up with a small release with the one feature or simply move it to the next cycle/release.

One “feature” that lots of people cut is security. Security is an easy thing for people to think of dropping as when you remove security from the application, the application still works and has all the functions the user wants. In my experience when security becomes a second class citizen it never quite comes back to the same level it would be.

Cut Quality
This is the debated one. If you just throw testing out the window you are more than likely going to have a buggy product and on the next cycle will spend lots of time fixing/managing/coordinating bugs which make that cycle take longer (so we should cut more quality out so we can spend time fixing issues from the last time we cut quality). This is usually quite a short sighted view in our opinion.

Push The Deadline
This is often the one that is not thought about. Why not delay for a week or two to get this out? What we are doing usually does not have peoples lives depending on it (even if it did I am sure we would want it to be right rather than right on time). The thing here is to manage expectations. Tell your consumers as early as possible that there might be a delay and that we can either be late or remove features (or remove quality apparently although I/we don’t agree that is acceptable usually).

Wording
A few funny sayings/wordings came out of our chat:
“Drop testing? Sure we can drop quality. Not a problem.”
“I want a car tomorrow. I know it will catch on fire half way down the street but we can patch that later right?”
“If our coders don’t produce quality without tests then we will just replace the coders until we get better ones. They are in infinite supply after all”

Okay, I have to come clean. I have to admit to this as it’s been twinkling in my feeble brain for some time now. Now with the shutdown of the CLI_DEV (formerly the altnetconf mailing list) I may as well spill it.

I am not Steve Ballmer. I am not Richard M. Stallman. I am not Scott Bellware.

I am altnet pursefight.

There. I said it. It’s out. Let the chips fall where they may.

How did this sad tale of hidden identity come to pass?

The heathens of the original altnetconf mailing list were just bickering and acting too much like children. So I opted to do the only thing that made sense, be the red-headed step child and tell the world like it was. Unbiased, unadulterated, and unaltered. From the trenches with bullets of bullshit firing left, right, and centre. Natterings of nonsense all around me. With me in the middle, sifting through the mess and bring up the nuggets of crap to the top of the cess pool.

First I thought I would register altnetpursefight.com and post from there, but then that wouldn’t work as I’m a cheapskate and wasn’t willing to foot the privacy bill to hide my name. Next I thought about setting up a blog somewhere using SharePoint (the CKS:EBE was just released and would have done the job) but that was too much effort for a venture that may have blown up in my face.

So I turned to Blogspot.

There I was able to post anonymously and distill the word amongst the cretins known as the ALT.NET readers.

I also setup a Twitter account to respond to the backlash, which I knew would come post haste. I even posted a message on my own blog trying to throw off would be hunters for the elusive identity of the one with the knowledge, but I’m not sure how successful that was.

Then I sat back and waited.

And waited.

And waited.

And finally… the first post! Which got my own little thread in the mailing list wondering who I was. And other threads followed suit but there was much fodder for my posts. There were thoughtful posts of course, but then there was the crap. The banana infested baby Vista like poo-poo that really made my blogspot site shine. The heresy, the name calling, the knock-down-drag-out cat fights that ensued.

My favorites were of course my own name calling (like comparing Scott Bellware to a raving shopping cart bag lady) or The “Law of Two Feet”, a farce made up by people who don’t want to engage you on an intellectual level, so they make up passive-agressive, bullshit granola ideas like the Law of Two Feet to shield themselves from an actual, fundamental critique of their ideas (whew, that was a real mouthful).

Anywho, there it is. You now know the obvious truth that has plagued the ALT.NET community for months now. The secret it out and I am it. Next up, the identity of Mini-Microsoft!

In the last year I have had the pleasure of attending many speaking events both as a presenter and an attendee. To that extent I would like to point out some tips that may be helpful to other people planning events.

Note that I have never planned an event myself. This is just my outside view of things.

Do have wireless access for everyone. I have never heard more complaints than events that don’t have Internet access.

Do provide lunch. Especially when in a remote area where it is not easy to find lunch.

Do not order in a hot lunch. Getting that much hot food co-coordinated could possibly fail. Having something like sandwiches or wraps is easy to have pre-made and less prone to having issues

Do have a map to the facility. People like to know where they are going

Do have the building the event is in clearly marked. If it is in a non obvious area have signage directing attendees through the building

Do have feedback sheets for the presenters. These help presenters improve there talks and are also required for some funding and awards.

Do not change the schedule a lot. If there are going to be lots of changes do not release it until it is mostly stable

Do pre-release the schedule to speakers before the general public. Many speakers will need to re-arrange their times due to flights or wanting to attend other speakers talks.

Do have backup speakers. There will always be a few speakers that need to withdraw from the event so having people lined up to fill in is essential.

Do not change the schedule the night before the talk. I would recommend having it set in stone one week before the event.

Do get all the speakers contact information before the talk. If there is some last minute change you can then contact them.

Do give out your contact information to speakers in case they need to notify you of a last minute change.

Do try to get a group rate at a hotel if you are expecting speakers/attendees from out of town.

Do not have an event at unseasonable times. Extremely hot/cold times of the year will discourage speakers/attendees. Also avoid times when lots of people are on vacation.

Do have someone that ensures speakers get hooked up to the projectors and running in a timely manner. Having technical delays can be a pain for all so having someone who can quickly get a speaker up and going is great.

Do have someone go into the presentations and give a five minute warning. This is great for keeping speakers and the event on time.

Do have a green room for speakers that is locked/guarded at all times. Having a place where speakers or even attendees can leave there valuables is a great feature to have. Also being able to work on last minute talk changes/fixes in a quiet place is great.

Do have an event for the speakers. Going out for dinner/drinks after the event is a great way to reflect on your event and is a nice way to thank the speakers for their time.

Do not expect an event to go off without a hitch. Lots of things can go wrong and something always will. Try to plan for things and adapt.

Do have an army of volunteers. Many hands make light work sure is true. If things go wrong it is easy enough to have 5 people try to find an extension cord than just yourself.

Do have swag to give away. Everyone likes to win something.

Do have at least the grand prize draw picked from evaluations. This encourages attendees to fill them out.

Maybe have tickets for other swag draws. This cuts down on trying to read someone’s name off a sheet that may be hard to read or pronounce.

Do get feedback for not only the speakers but the event itself so it can be improved for the next time.

Do keep the standard format for talks. For code camps these are 1 hour and 15 minutes and user groups are 2 hours. Most speakers craft their talks for these durations. If your sessions are going to be shorter make sure everyone knows well in advance.

Do not start your event at a time that is hard for people to make. Weekday events should start 1 hour after 5pm (or later if people have to make long commutes). Code Camps should start as late as possible as it is weekend time and we all like to sleep in a bit on weekends.

Maybe have a keynote. This can be good for explaining the happenings for the day or to introduce something that everyone will want to see. If there is something everyone wants to see no one else will want to speak in that time slot.

Do ensure that all session materials are available to attendees.

Do have the schedule printed out and available to all attendees as they come in the door.

Do mark the rooms so they correlate to the schedule.

I recently took over a project that was quite region heavy (ok every property, function, and field was wrapped in a region). So to remove them I wrote a little find replace regular expression that I thought I would share: