This month we have a special speaker for our monthly St. Louis DotNetNuke User Group meeting.

This months speaker is Brandon Haynes, who I had the pleasure of meeting at last year's DotNetNuke Connections event in Las Vegas. He is an excellent speaker and an active, knowledgeable member of the community, so I hope you will be able to attend.

Of note this month, we're planning to make available a higher quality broadcast of the meeting. We'll be streaming from Brandon's computer (showing his slides,demos etc directly) with a "picture in picture" of Brandon speaking in the corner of the video.

This will be the first attempt at this arrangement for an actual meeting, but we've done some testing and are excited about the results so far. I believe this will bring our online viewers much nearer to a first class experience.

Help show your support for DotNetNuke in St. Louis and around the world by participating online! You'll be able to find our stream on our Bambuser channel and if you check the website the day of the meeting you can find our GoTo Webinar information.

About Brandon:

Brandon Haynes is a member of the DotNetNuke core team, and serves primarily by providing security-related and organizational guidance. He is the chief executive officer at Everysport.net Inc., which delivers enterprise resource planning, web-presence, e-commerce, and integration-related functionality to recreational organizations. With more than twenty years of experience in software development, Brandon’s professional interests are currently focused on the nexus between intellectual property law, technology, and business. He is currently pursuing a graduate degree at Harvard University.

We are once again in the heart of the planning season for the DotNetNuke DevConnections and SDC conferences. It is that time of year when we ask all of you to submit your session abstracts for this years DotNetNuke North American conference.  Later this week we’ll be opening up the official Call for Speakers on DotNetNuke.com, but I wanted to take the opportunity to give speakers a heads up so they could start preparing their abstracts so that they are ready once we open the submission form.  Like the last three years, we are accepting  session submissions in 4 different topic areas:  Development, Design, Administration and Open Source.

Development – These are basically session dealing with code.  Whether it is topic on module development or building custom providers or dissecting the internals of DotNetNuke, anything that would appeal to the software coders is fair game.

Design – This topic area is targeted at the web designers.  This goes beyond just talking about skins.  It also includes topics like SEO, and accessibility and can even include Localization.  These sessions should focus more on the aesthetic and usability aspects of building a DotNetNuke website.

Administration – This topic area is where speakers present sessions that address the needs of the end user.  How do they install DotNetNuke, how do they configure it for a Web Farm or to run in the cloud(this is different that writing a module that uses cloud services), how can they improve site performance.  These sessions really focus on the day to day use and administration of running a DotNetNuke website.  This topic area is also a catchall for any business related topics.

Open Source – This final topic area is designed to show attendees how they can incorporate other Open Source tools into their development, design and administration tasks.  It might be a topic on using Watin for testing or using GIMP and Paint.Net for creating your skin elements.  The idea here is to expand the attendees view of the Open Source community and to bring in fresh and complimentary ideas from other Open Source projects.  These sessions should still be relevant to DotNetNuke in a very meaningful way.  A topic showing all the wonders of using Wordpress for blogging is not appropriate.

Frequently Asked Questions.

Q. What are good topics?

A. Every year I get asked by speakers as to which topics would be good choices.  There is no good answer because we have to balance topics so that we cater to a wide variety of attendees.  We need topics for beginners as well as advanced users.  We need sessions on staples like security, but we also want sessions that cover cutting edge topics like hosting DotNetNuke in the cloud.  At the end of the day, speakers need to ask themselves this question – Would anyone pay a couple thousand dollars to attend your session?  Every user who attends one of the DotNetNuke conferences will spend a couple thousand dollars on lodging, transportation, meals, time off from work and conference registration.  Will your session appeal to a large enough number of attendees and make them feel like they are getting their moneys worth?  Will your session appeal to employers who will ultimately make the decision whether to send their employees or not?

Q. How can I improve my chances to get selected?

A.  Every year we have speakers who submit really good topics.  Unfortunately, they only submit one or two sessions.  In order to keep our costs inline with conference revenue, we require speakers to present multiple sessions.  If you only submit one or two sessions you significantly reduce your chances of getting selected.  If you only submit sessions on one specific topic area, you likewise limit your chances.  The most successful speakers have a range of sessions that they can deliver.  For example, if you are a designer, consider submitting sessions from three or 4 topic areas like SEO, XHTML compliance, CSS frameworks, or skinning basics.  If for some reason the selection committee did not like your SEO topic, then you still have other options that give the committee some flexibility. 

Once you have identified key session topics, spend a little time developing good session abstracts.  The goal is to convince readers that your topic is both relevant and interesting.  You may have the greatest presentation ever created and be an awesome speaker, but the selection committee won’t know that unless you can convey in one or two paragraphs what you plan to talk about and why people will care.  Spend a little time reviewing the session abstracts from  previous conferences.  Speakers will often spend weeks and weeks developing material, so don’t shortcut the process and only spend 5 minutes on the session abstract.  This is the résumé for your presentation.  Make it count.

Q. Who Should Submit?

A.  Every conference relies on the quality of its speakers and as proven over the last three years, the DotNetNuke community has a lot of great speakers. While we anticipate that some core team members will want to speak, we are also interested in having speakers from the broader DotNetNuke community as well.  So please don't hesitate to offer your speaking services.  Even if you didn't get selected in past years, please submit sessions.  Every year we make a concerted effort to bring in fresh speakers who did not speak at the prior year’s conferences.

Q. How do I Submit my Sessions?

A. Instructions for submitting your sessions will be provided when we officially open the call for speakers for the two major conferences.

Q. What do I get if I am selected to speak?

A. In the past we have provided free conference registration and lodging for speakers.  We are still working on the final details for this year’s conferences and will announce the benefits when we officially open the call for speakers.

Q. When and where is the Conference?

A. This years DevConnections conference is being held in Las Vegas, Nevada at the Mandalay Bay Hotel and Casino from November 1st through the 4th.  There will also be pre-conference and post-conference workshops available.

Additional conference details will be posted on the DotNetNuke website as they become available.

At Open Force 2009 this past November, I attended a presentation by Kevin Schreiner (DotNetNuke on Speed and Performance) that spoke in part about the use of Sprites.  What on earth are sprites?  Well I had heard of the term sprites in relation to Computer Graphic programing, but not when it came to Web sites and DotNetNuke in particular.

So what are Sprites in terms of a Web site?  They present a way to reduce traffic between the server and the client.  Specifically, a sprite will contain a collection of images in one file, that can be reference to supply various graphic elements on a page. Since only one image file is required, the site will load faster. Additionally, since one image is used, less memory is used by the browser to render the page.

How is this done?  Well, after I had seen the presentation, I understood the concepts, but had yet to put into practice as I had no real need.  So it took me until now to sit down a try to use sprites.  Read on to see a simple example using sprites.
 

Joe Brinkman first came to Orlando on DotNetNuke® business a few years ago.  We had a local DNN vendor who sponsored bringing him down to be a speaker at the annual Orlando Code Camp.  Then, he came along with the other DNN Corporation founders to host the OpenForce Connect: Orlando event in 2008.  The last time that we’ve seen Joe visit Florida on DNN business was in June of 2009 for the first annual Day of DotNetNuke® in Tampa.  Well, he’s back!

Next Tuesday, the Orlando DotNetNuke® Users Group is hosting a meeting with Joe as our featured guest speaker.  How are we pulling this off this time?  Luckily, the ODUG is affiliated with INETA, so we were able to get INETA to foot the bill on this meeting.  Sweet!  We did this once before so far, bringing in DNN Core Team Member, Chris Hammond.  It was fantastic!

So, what is Joe going to talk about?  We all know that is a master (not Jack) of all trades, so you could easily guess pretty much anything.  (Which explains his current title of Technical Fellow at DNN Corp.)  He’s been known to recently talk about jQuery a lot, as well as Action Script in the past.  This time though, we’re in for something different. 

This time around, Joe is breaking XSLT out from his technology toolbox.  Here is the session abstract:

XSLT is a very powerful language for transforming XML and is extremely useful in web applications for generating HTML. Because of the power and flexibility provided by XSLT, it is used by several core and third party modules as a templating language. In this session, we'll look at how you can take advantage of XSLT for your DotNetNuke websites. We'll also show you some "tricks" for further extending XSLT and really turbo-charging your modules.

Whoa!  I don’t know about you, but this excites me!  People do not use XSLT as much as they could, and many people just haven’t tried using it.  This is a great time to come to the ODUG meeting and see what you’re missing.  You’d be surprised at how much you can leverage XSLT in DNN.

Register for the ODUG Meeting on 1/12/2010 @ 7:00 PM

Tampa to Follow

The very next night, Joe is scheduled to speak at the newly formed Tampa DotNetNuke®User Group.  There, he will be speaking about the widget framework in DotNetNuke®.  I love what the DNN framework provides to skinners and developers.  He is going to give an overview of them, why they are useful, and how to make your own.  I speak about this myself, so I am doubly-excited about his session.  Yes.  I am going to both meetings.  :)  You should too.  How could you miss so much FREE DNN-goodness?!

Register for the Tampa DNN Meeting on 1/13/2010 @ 7:00 PM

No matter which meeting you attend, lets hope that we don’t see this Joe show up.  :D  Hehehe…

When I was doing the rounds at the recent DotNetNuke OpenForce conference, I was surprised at the number of people who wanted to talk to me about the DNN Unit Testing framework I put together a few years back.   I use this on an almost daily basis, but it’s become part of the plumbing for all projects so I don’t really think about it as much as I used to.   I was recently contacted and asked to update it all for DNN 5, and I thought I would spend some time bringing it up to latest standards and generally re-visit the topic again.  It would seem there is a lot of interest in doing Test Driven Development with DNN, so this post will revisit all of that.

Should you be doing Test Driven Development with DotNetNuke?

Test Driven Development (TDD) is a worthy goal of any software project that aspires to good quality and the flexibility to change over time.  If this is true of your DotNetNuke module, then the answer is yes.  All non-trivial iFinity modules have Unit Test projects that are run before releases and after changes to check for breaking changes.  This has caught a number of errors over the years, and prevented them from showing up in an actually released software (sadly the unit test coverage is not 100%, hence some bugs do get out, rotten little things!)

What will you need?

All of the information presented in this post covers DotNetNuke 5.1.2 and later, uses Visual Studio 2008 Team Edition and was done on a Windows 7 machine.  None of this is really necessary : you don’t have to use the in-built unit testing of Visual Studio (nUnit will do) and you can really use any version of Visual Studio you like, as long you’ve hooked up a unit testing framework.  I will suggest, however, that you have loads of fast RAM and a blazing fast processor, or you will soon bore of the constant compiling, running and copying that is part of unit testing.  I’m not going to pretend that the process of setting up unit testing with DNN is straightforward, so any amount of frustration you can remove by throwing hardware at the problem will be justified (see, print that bit out and go ask your boss for a new computer).

Note, if you aren’t using the Visual Studio test tools, then you’ll have to do some refactoring to the code to get it to work.  If you do manage to, say, get it working with nUnit, let me know via the contents and I can make your work available (or write a blog post somewhere and I’ll reference it).

Contents of the Download

In my previous posts on this topic, I provided some DLLs and general instructions on setting up some procedures.  While this was useful, I decided to go a bit further and actually provide a complete example that you can download and setup, and (hopefully) press the magic ‘go’ button and see some tests running.  This is probably a very lofty goal given the territory, but everything should be there.

Solution Contents

When you download the solution, you’ll see the following projects:

• Solution items : the testSetupScript.cmd file, which prepares the test output for running a mock DNN environment, the ‘testrunconfig’ file, which references items to be deployed with the test, and the .vsmdi file, which contains a list of unit tests in the solution
• iFinity.Basic.UnitTest.Example project.  This is the unit test project.  It contains a single test class file, as well as the various config files required to make it work with DNN
• iFinity.DNN.Utilities : This is the Unit Testing framework I built to work with DNN.  It contains the code to create the Mock DNN environment in which to run unit tests
• iFinity.ExampleModule, iFInity.ExampleModule.Data : these two projects are pretend module DLLs.  This article is all about unit testing Private Assembly modules, and this setup is the standard way to construct a DNN PA module.  Note there is no UI code in these projects, just a class, a module controller and a data provider.  The idea is just to test the parts of the code that use the DNN framework (namely, reading/writing to the database)

How to use the download

1) Download the code, extract the zip file, open it up in your Visual Studio (note, you’ll need a version which contains the Unit Testing framework, this won’t work in the ‘free’ editions). 

2) Update the connection string in the app.config file to point at a DNN database that you have lying about somewhere.  If you don’t have a local test DNN database, then create a new instance of DNN just for unit testing purposes.  Actually, that’s not a bad idea anyway.  You can either use a .mdf file in the ‘user instance’ mode, or connect to a sql server database somewhere.  It depends on your objectives with testing and what you’ve got available.

3) Find the 01.00.00.SqlDataProvider file in the ‘iFinity.ExampleModule.Data’ project, under the ‘SqlDataProvider’ directory.  Then run this through the ‘host->sql’ page of the DNN install that belongs to your DNN database you’re going to use for testing.  If you can’t do that, then run the Sql in a normal sql query editor, but remember to find/replace the ‘{objectQualifier}’ and ‘{databaseOwner}’ tokens first.

4) Start the Unit tests with alt-shift-x, or find and click the ‘run tests’ button in Visual Studio (hint, it’s not the green “play” button that starts debugging)

5) Check the test results to see if you got it to work OK.

If you have any custom modules in your DNN install that need configuration changes, you might need to change the app.config file in your test project to match the web.config file of the associated DNN install.  It’s very important to realise that you are running a mock DNN application, and that mock application is using the app.config file of the test project, not the web.config file of the DNN project.

Test Setup

When you hit the magic ‘test it all for me’ button, there’s several things that go on.  In the background, the Unit Testing framework is compiling the versions of your components, and copying them to a special directory, created underneath the ‘TestResults’ directory.  By default this is in the solution folder.  However, this is just a flat directory with a pile of DLL’s in it : not unlike the \bin directory of a standard DNN install.  Our aim here is to make the DNN code run in a test context, and to do that, some parts of the DNN framework have to be re-created. 

This is achieved by the ‘TestSetupScript.cmd’ file.   This file simply creates a couple of bare-bones directories in the OUT directory of the test, to make it look a bit more like a DNN install to the DotNetNuke code that will be running in the test. Note that the portal is hard-coded in this script file, to match the entries in the ‘dnnUnitTest’ section.  This file needs to be hooked up to the ‘TestRunConfig’ file in the solution containing the Test project.  This tells the Test framework to run the file before testing starts. 

If you don’t set up this file, the code in the DNNUnitTest class coughs up a helpful error message, which will look something like this:

Unable to create instance of class iFinity.DNN.Modules.ExampleModule.Test.ExampleRecordInfoDBTest. Error:  System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values.
Parameter name: Supplied HostMapPath [..\iFinity.UnitTesting.Examples\TestResults\Bruce_WOMBAT 2009-12-02 14_35_39\Out\Website\portals\0\] is not valid. Specify a valid path on the target machine (Did you forget to run the testSetupScript.cmd file to create the portals directory??)

This message is supposed to be a slap to the forehead “Hey, wake up and include the TestSetupScript.cmd file!”

There are other files that DotNetNuke needs to run, as well.  These include the DotNetNuke.config file, and the SiteUrls.config file.  Both of these files will be searched for by the DNN framework as it is loaded.  So, these two files are also specified as required items in the .testrunconfig file, in the ‘Deployment’ section.  This ensures that they will be copied to the OUTPUT directory before testing starts.

How it Works

This framework works by creating a Mock (or fake) ASP.NET runtime context to run your unit tests within.  Tests normally run in the Visual Studio Test context – and if you do this, you can’t access server objects like HttpContext : which are vital for a web-based application like DotNetNuke.

This fits together because the TestClass inherits from the DNNUnitTest class contained within the ‘iFinity.DNN.Utilities’ project.  When the TestClass is instantiated to run the tests contained within, the constructor code in the DNNUnitTest class kicks off the type of initialisation normally run within the DNN startup code.  It also constructs a mock HttpContext object, and stores some of the key DNN global objects (like PortalSettings and HostSettings) in the HttpContext items.   It also loads some of the Providers used by DNN for key tasks such as database access, data caching and others.

Thus when your code runs and makes calls to items within the DotNetNuke namespace, the actual objects are there to take the calls and return the results.  This allows you to create unit tests to run pieces of code within your module that would otherwise fail because there was no DotNetNuke object there to receive and process them. 

Issues to Understand

Windows Vista/7/2008 Security

If you’re like me and have upgraded to the latest Windows offerings, you’ll soon run aground on the fact that Unit Testing is considered a highly risky business by the born-again security converts on the Windows team.  You may get an error like this one:

Test Run deployment issue: The location of the file or directory 'D:\DotNetNuke\Custom\Common\iFinity.UnitTesting.Examples\dnn510\DotNetNuke.dll' is not trusted.

This is because the DLL’s weren’t compiled on the machine you’re testing on, so you’re guilty of running code that someone else wrote.

The generally accepted solution is to ‘unblock’ the file(s) that cause the problem.  You should do this in the location they are referenced from rather than the location noted in the error message.  This is because when you debug and test, the new copies will be taken from the reference location and copied into the destination location.  To unblock the file, right click on the offending file, select ‘Properties’ and go to the ‘General’ tab.  At the bottom you’ll see a message looking something like this:

Click ‘unblock’ at the bottom, and you should be OK.  You might have to restart Visual Studio to fix this problem, so I’d suggest unblocking all of the referenced files at once, then doing a restart of VS – just to be sure.  A big thanks to whomever at Microsoft decided this was the way to go. 

If that doesn’t solve the problem for you, take a look at this StackOverflow topic, and see if you can glean some help.  You might also try recompiling the DNN solution on your local computer, and using the output from that.  This also has the benefit of giving up some up-to-date .pdb files to help with any debugging.

Changes for DNN 5 : the ‘Cannot register or retrieve components until ComponentFactory.Container is set’ error

As previously mentioned, this blog post came about as a result of people asking me about a DNN 5 compatible version of this code.  The big change comes about through the use of the ‘ComponentFactory’ component used to handle the loading of providers and components in DNN 5.  This completely changes the way that 4.x DNN used to load components on startup.

I was helped immensely by Charles Nurse, who has an excellent series on creating testable modules on his blog : http://www.charlesnurse.com/post/Creating-Testable-Modules-Part-1.aspx

Interestingly enough, he mainly advocates a completely different approach than what I do (in terms of the mock objects and environment, not the methodology) which is definitely worth reading and understanding.  One of the largest differences is that he is discussing the MVP (Model View Presenter) pattern, whereas this article discusses more the traditional pattern of DNN module development.

However, the key item that I took away from this blog series was the changes in the way that DNN 5 loads up providers and other components.  This is actually all done in the ‘global.asax.vb’ file (which runs at application start).  This is one of the reasons many people had DNN 5 upgrade problems (and encountered the ‘componentFactory.Container’ error) – some modules and developers replace the global.asax.vb file with one of their own making – or fail to copy in the new one.  This removes the important instantiation of the Component Factory Container, and results in lots of bad errors all over the place.  Don’t modify the core code!

The end result for the iFinity.DNN.Utilities is that the startup code had to change.  This was done by copying the relevant startup code from the global.asax.vb file, which creates the container and loads the components for the various types of providers supported in DNN.  However, not all the various components are loaded : some are commented out in the ‘InstallComponents’ list.  These can be re-installed, but you’ll also need to reference the matching DLL from the DotNetNuke \bin directory.  For example, if you enable the ‘friendlyUrl’ provider, you’ll need to copy in and reference the matching Friendly Url Provider, as configured in your app.config ‘friendlyUrl’ section.

However, as an upshot of this, the previous problems I had encountered with the BuildManager.GetType() calls in DNN 4.8.0 have disappeared.  So this code has been removed from the DNNUnitTest class, and replaced with the aforementioned DNN 5 method.

Visual Studio 2008 Web Context / Host Adapter

Within Visual Studio 2008 Unit Testing, there is a new feature for running Unit Tests in the context of an ASP.NET website.  This solution doesn’t take advantage of this : primarily because it’s an evolution of my work done in Visual Studio 2005, which didn’t have this feature in the Unit Testing.   Instead, this creates a mock HttpContext to host the DNN application.  The end result is similar, although I suspect the Visual Studio version would probably be superior.  If time and inclination permits, I may investigate this in the future and modify the DNNUnitTest code to match.

Recommendations for Testing Module Code

Hopefully you have managed to setup the example test project and have got the code running.  You can step through the individual tests and investigate how it all works.  About now is the time you should start thinking about how to adapt this to your projects.  If you develop your modules in a similar way, then you can just remove the ‘iFinity.Example’ module, and replace with your own project.  Or, more realistically, either include the iFinity.DNN.Utilities module in with your existing project solution, or just build and reference the DLL once you have it working.  You can then add a test project to your solution, copy across the various components of the example test, and start writing your tests.

In the example module tests, you’ll see there is a test for each property set/get.  You may think this is overkill, but you’d be surprised how many times this will catch a small but lethal bug from a mistyped property accessor.  Also, in this example module, you’ll see that a flag is kept over whether the data in the object has changed since the last check.  The logic determines if this code is running correctly.

You’ll also see that the module CRUD code is tested against the database.  This is an obvious choice, but don’t forget all the other bits and pieces your module may do, such as reviewing saving/retrieving module settings, generating Urls, creating emails : you should test as much as you can.

As most of you who read this know, AppTheory had a booth at OpenForce ‘09 last week in Las Vegas where we handed out flyers and discussed DotNetNuke with anyone who stopped by and wanted to chat. Surprisingly, there were many people who had tons of questions. I say surprisingly because at first I thought they just wanted to take a break and sit down on our couches at our booth but after they sat down we started some pretty good conversations. Besides that I also got to accept our Community Choice Award for the www.sakesocial.com web site we worked on as it won the e-commerce category. Although I was not present for the announcement, it was announced that I was recognized as part of the new PEG program which you can read about here. So, my thanks to those who voted for AppTheory for the Community Choice Award as well as my thanks to those who voted for me as part of the PEG program.

What I found most interesting about this trip wasn’t the awards, announcements or the chatting at the booth, it was what I saw overall: Non-Developers interested in DotNetNuke. When I go to a conference like this I expect to see two groups of people: Vendors and Developers. At this years event I saw representatives of both groups but I also saw non-developers. In my opinion this is great, not only is it the people who really use DotNetNuke discussing how they use it (and thus providing us with more use cases) but it also allows this group direct access to people like Shaun Walker or Navin Nagiah. Being involved in the core team for all these years I take it for granted that Shaun and other Board/Team members are always available for discussion but in reality I know they can’t be this easily available for all 750k of you!

In closing, I recommend to all of you developers and end users who are truly interested in DotNetNuke, make the trip next year if possible. You will get direct access to Shaun, Navin and a good portion of the DotNetNuke team who are all there to answer any and all questions (unless it is something top secret). You also get direct access to all the system integrators and trainers as well. On a side note, I heard it will be a little earlier in November next year so start making plans now!

This was my second time in a row to have the honor of presenting my knowledge about the most widely adopted .NET framework called DotNetNuke. One of the most appealing reasons for me to devote my time to help build a better open-source framework like DotNetNuke is the wonderful community. I had to admit, I have never involved in using too many frameworks out there closely so I can't tell how great their communities are. But one thing I can assure you that DotNetNuke has a very intimate community that pretty much everyone knows each other and have used each other products.

Paul Scarlett is one of the regulars in the community I ran into this year and he commented "I came to this conference because of the people". Paul is not the only one who has this kind of feeling. I am one of them as well. I came to the conference not just to share my knowledge to the community, but to meet and greet people I've worked with through the phone, e-mail, messenger... and any other mean of communication you can think of but I've never gotten to meet them in person. And this conference is just a perfect opportunity to finally interact in person.

This past Tuesday was a number of things… The Marine Corps birthday, the release of Modern Warfare 2, and it was of course the day of our November meeting for the Orlando DotNetNuke® Users Group (ODUG).  There were many challenges coming into this meeting, which each could possibly ruin the entire meeting.  However, all of those challenges were successfully met and overcome.

So… What Challenges?

This meeting had a lot going against it.  Here is a run down of the challenges that we faced:

• We had a new venue.  For anyone that has run any kind of meeting that hosts volunteer attendees, you immediately know that this is a problem.  Your attendance usually drops dramatically for at least 1-2 meetings. 
• With the new venue being in Downtown Orlando, parking is a problem.  There is nearly nowhere that you can park without paying a (premium) fee. 
• Our venue has a security lock on the front door and in the elevator.  I didn’t know this until I got there.
• Our speaker flew in from out of town, and I was making sure he was taken care of.
• We were going to do a live video with Joe Brinkman from OpenForce in Las Vegas.  This required us to use a phone to speak with Joe, and for us to show a stream on our projector.
• The projector didn’t work when we first arrived.

If you’ve gotten this far, you probably are already thinking what I was… Any ONE of those bullet points is a huge challenge for a user group meeting, yet we faced all of these challenges in a single night!

The new venue was at a company called CoLab.  This place was really cool.  It has all of the room we need right now, and it has all of the bandwidth we need too.  So, in the future we will have plenty of room for our stream and to allow our members to use the internet connection.  The venue came with free parking, even if it was a 5-minute walk from the building.  I am happy about that for myself, since I don’t walk enough.

Luckily for me, our user group is full of intelligent and helpful people.  Sam McCloud fixed the projector in short order, and we posted a “door man” in the form of another user group leader, Jim Begley, of the Tampa DNN User Group.

Our speaker was Antonio Chagoury from InspectorIT, who is also a Microsoft MVP, and a DNN Core Team Member.  Taking care of him was easy.  I picked him up from the airport, got him checked into his hotel, got him fed, and then took him to the meeting and back.  More on him later…

Interview with the DotNetNuke Corporation

Our meeting usually begins with a little bit of an introduction of myself, the other board members, and things going on in the user group.  However, right when we were about to start, Joe Brinkman shot me a message saying that he was ready for the streamed interview.  So we stopped everything and we began with the stream.

The stream couldn’t have went more smoothly!  Joe used UStream to broadcast to us, and I asked him questions over the phone.  Live streams generally have a 3-5 second delay, so I immediately had to begin adjusting my conversation style to account for this. 

Joe first began by giving us a little intro to OpenForce, and then showed us all of the DNN vendors on the exhibition floor.  He walked to each booth, introducing us to the people that were there.  Following this, I began interviewing Joe by asking questions about OpenForce.  Nearly all of the details are already available online, so I won’t go into the specifics.  Following my questions, I opened the questions to our user group members.  We had some great questions.

I received nothing but great feedback on the interview from our user group members.  I was incredibly pleased!

Antonio Chagoury

We couldn’t have asked for a better speaker and presentation.  Antonio presented a session covering implementing RESTful services into DotNetNuke®.  He had demos for Twitter, various URL shortening services, and Bing maps!  There were hiccups in the demos, but we always expect that from any technical presentation.  Even the most rehearsed demos have problems.  Other than that, Antonio had a complete mash-up of the previously mentioned services.  They worked great!  His demonstration module could easily be adapted to be a first generation mash-up module for DNN.

Antonio had a ton of questions, and even more information available to us.  Of all of the speakers, he is the first one to have a full circle of people around him asking him questions after his presentation.

The best thing I loved about his demo is that it could easily have been done on a custom ASP.Net site, instead of DNN.  You didn’t have to be a DNN developer to understand his code demos.

If you can get Antonio to speak at your user group, book him!  He is a great presenter.

After Party

Usually, we meet about 2 miles away from our meeting a a TGI Fridays.  However, this time we have a great social location on the ground floor of the very building we were meeting in.  We met at Finnhenry’s.  This place is run by a nice lady named Caitlin, and she gave us a discount and great service! 

The music was a bit too loud to converse, but we dealt with it.  Their prices are great, and their staff is very helpful and friendly.  You can catch them on their Facebook page too.

We had a ton of fun at Finnhenry’s.  We wrapped it all up at 11pm.

Our next meeting is going to be a DotNetNuke Speaker Idol meeting.  See our website for more details.

Last year at OpenForce, DotNetNuke Corporation was on the verge of closing our first round of funding.  2006, 07 and 08 were challenging years as we struggled to find a business model that would support our company of 6 and allow us to grow.  Shaun, Scott, Nik and I formed DotNetNuke Corp. with the goal of building a company that would allow us to better manage the project and improve DotNetNuke with access to increased resources.  With the investment we received in 2008 we have been able to grow the company to nearly 30 employees and contractors.  As we have brought in additional employees, it has allowed us to further focus our efforts rather than running around trying to do everything ourselves.

One of our first people we hired after OpenForce last year was Cathal Connolly from the core team.  Cathal joined Charles Nurse who already worked for DotNetNuke Corp and brought his deep understanding of DotNetNuke security to the company.  At the same time we began to build out our engineering office in Abbotsford, British Columbia, Canada – not far from Vancouver.  We quickly hired Sarah Darkis and John Lucarino who both had prior experience working with Shaun and who also had extensive experience working with DotNetNuke and ASP.Net.  This was our engineering team for the better part of the first 9 months in 2009.

As sales of DotNetNuke Professional continued to grow, we were able to start a second round of hiring.  We brought in Ken Grierson this past summer. Ken is a senior test engineer, with many years of experience working as a tester at Microsoft.  He has worked hard to help us add more rigor to our testing and QA processes which is starting to pay off as we near our 5.2.0 release.  Ken has also started working with our community QA team to ensure that we are fully aligned with our QA efforts on the community side. 

Around this same time we were able to hire a network engineer.  What many people did not know is that this is a role that sort of fell in Scott Willhite’s lap several years ago.  Scott is not a network engineer, but has been able to keep the DotNetNuke infrastructure for both the project and the corporation running quite well over the past 7 years.  I am often amazed at how well he did, but know that it involved quite a few late nights and long weekends.  When we hired Konstantine Tcherenkov for the network engineering position in September, Scott was able to finally able to begin focusing on his primary responsibilities as Director of Community Relations.  Konstantine quickly came up to speed on our infrastructure and has already begun work on a restructuring of our servers and infrastructure to provide greater stability, redundancy and scalability for many of our critical systems.

Another recent addition to the engineering team is Chris Kendall who was hired to head up our support team.  If you are a Professional Edition customer, you have probably already had a chance to talk with Chris as he is managing our customer support for Professional and Elite customers.  This has been one part of my job over the last year, but a part I was quite happy to turn over to Chris.  Chris brings a passion for the job that is unbelievable and even without  a lot of DotNetNuke experience was able to jump in and begin making a huge difference from his very first week onboard the team. 

As everyone already knows, Shaun has also worn many hats during the first 7 years of DotNetNuke’s growth.  Like all of the founders, Shaun has been pulled in many different directions and desperately needed some additional help in engineering to manage our growing team.  We were very fortunate to be able to entice Rob Chartier to join DotNetNuke Corp as the Director of Engineering.  As an ASP.Net Insider, Microsoft MVP and longtime DotNetNuke user and evangelist, Rob was a natural fit for the position.  Rob’s brings his background in agile development practices to the engineering team and is using those skills as he heads up feature development for the community and commercial DotNetNuke editions.

With Rob onboard, I have formally taken on responsibility for the Quality, Support and Maintenance side of the engineering department.  I have the privilege of working with Ken, Chris, and Cathal to ensure we are putting out the best possible product.  We are focused on ensuring that we have a good grasp on all of the items that exist in Gemini for the DotNetNuke Core as well as Professional and Elite editions and will be working hard over the coming weeks to close them as quickly as possible, and putting the appropriate tests in place that they do not re-appear in future releases.

With the exception of Cathal, all of our engineering hires work from our Abbotsford office.  This is great for building team cohesion and simplifying communications.  Unfortunately, many of the great developers in the DotNetNuke community don’t live near Abbotsford.  With a solid core engineering team in place, I was happy to hear that were approved to make a few hires from outside the Abbotsford area.  Over the past couple of years Shaun and I had the opportunity to hear from a number of people in the community that they were interested in joining DotNetNuke Corp. whenever we had an opening.

Well, the day has finally come, where I am happy to say that we have hired two more members of the DotNetNuke Core team.  Both of the individuals have been working with DotNetNuke for many years and have a passion for the project that matches that of almost anybody in the community.  Shaun and I recognized that as capable as Ken, Chris, Cathal and I are, it is probably not enough to meet the goals we have for the quality and maintenance team.  We needed some additional people with a deep understanding of DotNetNuke who could immediately jump in and begin helping our support, quality and maintenance efforts on their first day.

I am happy to welcome aboard Phil Beadle to the DotNetNuke Corp. team.  As many of you already know, Phil was a founding member of the Core Team and was recently named a Trustee in our latest team re-organization.  Phil has worked for the past four years at Readify where he built up an impressive resume working on some very cutting edge DotNetNuke projects.  Phil was the lead architect of the Readify team working on the Afl.com.au and Nrl.com.au sites, some of the largest public DotNetNuke sites anywhere in the world.  Like Rob, Phil also comes from an agile development background.  I am looking forward to working with Phil to use his knowledge to implement automated unit testing and improved continuous integration practices.  Phil is a great addition to our engineering team and I am looking forward to December 7th when he will officially begin work as a new member of the DotNetNuke Corp. engineering team.

The second core team member who has accepted a position with the engineering team is someone who may come as a surprise to many people.  I am happy to welcome Alex Shirley as our newest member of the support and quality team.  Anyone who frequents the forums or pays attention to our bug tracking system, knows that Alex has been a very dedicated member of the DotNetNuke QA team for the past several years.  As a core team member Alex has been a passionate advocate for improving the quality of our releases.  As the release manager for the past couple of years for the project, I often have the task of making sure we get releases out the door.  Even when Alex and I have disagreed on issues regarding the project releases, we both wanted what was best for the DotNetNuke project.  I love Alex’s passion and willingness to be a strong advocate for his position.  During his tenure on the core team he has kept the team focused on making sure that each release was the best possible version of DotNetNuke given the constraints that we often are forced to live with.  I look forward to working with Alex to help put in place additional processes to ensure that we are living up to his high quality standards.  Alex will also have the opportunity to work with Chris Kendall on the support team and to ensure that issues found by our customers are getting the appropriate attention from our maintenance team.

Our final hire is someone that Rob Chartier has worked with in the past, Keivan Beigi.  Keivan joins the Abbotsford/Vancouver team and helps round out the DotNetNuke development team with his real-world enterprise experience.  Recently, he has worked with many of the large US Telco providers, not to mention many of the Fortune 500 with the design, implementation, deployment and support of various projects focused around transaction processing.  It is in his enterprise experience we will gain the most value.

I am really excited at all the growth that has occurred on engineering team this year.  I look forward to continuing this trend in 2010 and further improving DotNetNuke.  This is an exciting time to be a member of the DotNetNuke Corporation engineering team and the DotNetNuke Community.  I can’t wait to sit at OpenForce 2010 and talk about all the great things we accomplished in 2010.

Not everyone can go to OpenForce this year.  Many things might be a factor in that decision.  But if you’re in Central Florida, and not going to OpenForce, you should be coming to the next Orlando DotNetNuke® Users Group (ODUG) meeting.  Why?  We will be having special (virtual) guests at the beginning of our next meeting.  Who are they?  You name it.  It’s the members of the DotNetNuke Corporation!  That’s right.  OpenForce 2009 is happening next week which happens to be the same time that we are having our meeting.  All of the members of DNN Corp will be having a dinner at OpenForce at the same time as our meeting, so there’s no telling who we’ll talk to!

We will be hearing about the OpenForce event from the founders of DNN Corp.  I don’t know about you, but that’s awesome!  We will not be steaming the interview, so you must be present at the meeting to hear and watch the interview, as well as ask your own questions.

Register for the meeting on the ODUG website

A week ago the first OpenForce (the main DNN conference series) ended. Two days of presentations surrounded by lots of downtime with DNN colleagues. As a speaker I got the best of it this year. Paid hotel accommodations, paid food, paid drinks. What more could you want? Plus you get the wonderful Holland tour the day after the conference. This is where the conference speakers are shown a piece of folkloric Holland to remember their trip by. Here is a quick ‘n dirty report from those days.