Well we just had our bit April Fools Day prank.  You can find the mission at http://www.dailymission.com/mission/24b53/Never-Gonna/  The rundown is this: we created a mission offering up a $50,000 award and then took away the ability to compete.  Ok, so not the most inventive thing ever, but give us a break!  It was our first attempt and we didn't have time to do any elaborate coding like other sites.  I can safely say that we got at least a handful of people with it.  I got a few frantic emails and IMs along the lines of, "OMG I CAN'T PARTICIPATE FIX IT QUICK CUZ I HAVE A GOOD ONE I WILL WIN!"

So that's April Fools.  The big news is that we're working on a new layout.  We've finally found a graphic designer that "gets us."  He understand what DM is going to be and he is leading the way in the design.  It's great to work with a professional that doesn't need his hand held and to be told what to do every step of the way.

The redesign should launch sometime in the middle of April. Phil is heading upmost of the redesign.  Since my wife had a baby 2 weeks ago it's been not-so-easy to get the time I need.  Plus, this is one of those deals where too many cooks in the kitchen would mean disaster.  At least that's what I tell myself so to not feel bad about not helping Phil with the coding in this round!

Look for the new version soon.  I'll blog about it to let you know when it's done.

Cheers

 -eli

I've been bad at blogging lately.  I haven't had much time!  But I guess that's a good thing.  We've been busy.

A little late to make this post, see our full blog entry about daily mission beta 3's launch.

http://dailymission.vox.com/library/post/daily-mission-beta-3-released.html

So now that the site has launched, I can announce that the hybrid solution was for 1.FM.  First off, let me mention that DNN is "heavy."  I hate that it's a website and not a web application.  The build times are incredible.  I'd much rather build locally then upload and have it just work.  Instead, after you upload a file, it reocmpiles the whole application.  With an application as big as 1.FM, this can take a minute or two, even on their new 8-core server with 8GB of RAM!  The one time I thought IIS went down because it took so long.

However, with that said, I still say the benefits of the solution far outweigh the hurdles.  First of all, I get a prepackaged set of modules for purchase at www.snowcovered.com.  Second of all, it gives me a single authentication and authorization system for anything that I wanted to custom build.  Combined, there isn't much I can't dothat would be within 1.FM's needs.

At launch, we were faced with two performance issues that I think are worth mentioning.  The first is something to be ever aware of when using prepackaged software:  just because it looks like it does what you want, doesn't mean it does it well!  Most of the features that are on every page and that deal directly with 1.FM data I built myself and made heavy usage of data caching.  However, when we launched, there was something on the site that was just killing us and more or less bringing the site to a standstill (with about 4100 concurrent users).  After profiling with RedGate's Ants Profiler we found that it was the "latest videos" module on the homepage.  Apaprently it wasn't caching any of its data.  And of course it was the one boxed module I was relying on to be on every page!  We solved the issue by wrapping the module control in our own custom User Control and using OutputCache.  Since there was no need to ever hide videos -- all videos are public all the time -- there was no reason for us not to cache the rendered control itself.

And this brings us to the second issue.  I completely underestimated the power of caching controls!  I was very strict about the way that I cached the data.  Everything was cached and fetched in an application thread, so no user felt the burden of requesting data ever.  However, with 4000 people hitting the site at the same time, just databinding and rendering that data became a HUGE bottleneck.  We were maxing out the 8 CPU cores consistently.  With just a few strategically placed OutputCache's in my user controls (actually I think it only took _three_) we were able to keep the server load at approximately 20-30% CPU usage with that server load, which is more than acceptable.  I have to give all the credit to Phil for this one.  He stepped away from his project of the day to run the profiler and tell me what to look for while I coded away like a good little monkey. He tracked down the problem spots, I put in the cache control, and off we went.

We'll still be doing some maintenance and changes on the site.  I don't know if we're out of the woods just yet with the performance tuning!  But if I have to take one thing away from this it's never underestimate the power of a good profile.

 -eli

Just a quick update.  I had a lot of success implementing the hybrid solution.  I continued to keep my existing C# projects in tact and used post-build events to copy files from my existing C#/ASP.NET projects to the DNN root /Website folder.  I made a few small modifications to the DNN core to allow for some client-specific requirements, but otherwise left DNN alone.

Overally i'm happy with the solution as it stands.  It was a little difficult to work with since I had existing structure that I didn't want to have to re-code (for both time and for cost reasons!).  After this project wraps up, I'm going to try a ground-up approach to see if I can simplify DNN development for regular ASP.NET developers.  DNN offers a lot of infrastructure and modules at your disposal, but the caveat is that you have to be familiar with DNN to use it and expand upon it; my hope is to close that gap and let standard ASP.NET developers do amazing things in DNN... That is, I want to do all of that, if I have the time to build that framework

Cheers
 -eli

Last week I started a DNN/ASP.NET hybrid experiment.  I've worked with DNN in the past, and overall you get quick, easy, CMS solutions, but it feels a bit cookie cutter.  The way the modules are placed into the site often feels really static and "cheap."  The payoff, though, is that you get the support of literally thousands of developers at http://www.snowcovered.comthat all code to the same CMS, meaning you get lots and lots of out-of-the-boxfunctionality for aCMS or social website.

What I'm experimenting with now is whether or not I can mix and match ASP.NET directly with DNN.  Using a simple Control Wrapper module, which takes any given ASCX control and wraps it in a DNN module so you can insert it into a DNN page, I'm making entire controls for the new 1.FM that are essentiallythe "meat" of all the 1.FM pages.  That means I can still have my own custom admin pages and custom controls without having to code directly for DNN, but when I find an out-of-the-box module that I want to use, such as a forum, image gallery, reporting engine, chat room, or anything else, I can immediatley make sure of them.

So far, everything seems to be going smoothly.  I am planning on writing an article on the process once it's done, and I'll post another blog entry when I have my findings, so stay tuned.

 If this works, it could bring on a whole new way for developers to build websites.  No longer will you have to be a DNN Developer to take full advantage of the DNN infrastructure and supporting features.

To be continued.

 -eli