Archive for February, 2011
Are you looking to configure MindTouch to use Gmail for external SMTP purposes? This can be performed, though Google does require a specific SSL certificate to do so. For more information on configuring Gmail for external SMTP, please take a look at our documentation here.
Have questions? Please feel free to contact our Support department by visiting our Support Portal.
A few short weeks after the migration of DReAM, we’ve now also migrated SGMLReader to GitHub. This will make it easier to accept contributions and coordinate development around this crucial .Net library.
As part of the move, we’ve done some cleaning up. First, extraneous solution and project files have been removed so there’s no confusion about which ones to use. Second, and more importantly, the old homebrew test suite has been converted into clean, standard NUnit tests. Finally, we’ve made sure the whole project compiles, runs, and also tests on MonoDevelop .
Running SGMLReader natively in MonoDevelop has been an eye-opening experience. Hats off to the Mono & MonoDevelop teams. They have done an amazing job building a feature rich, complete, and polished product. I’m now using it regularly when I hack on my couch while getting my weekly fix of TV shows. It’s not yet my primary IDE, but it’s pretty close.
Unfortunately, it has also been eye-opening about some glaring discrepancies between Mono and .Net. There are definitively problems with the Mono implementations of XmlTextWriter and XmlDocument that cause SGMLReader to fail on some tests. The good news is that Mono is on GitHub too and they have instructions for how to build it on OSX, meaning,we can set up a development environment and track down the discrepancies that cause the SGMLReader tests to fail and contribute those changes back.
Despite these failing tests SGMLReader has proven to be quite reliable on Mono — we’ve been using it on Mono for years — and it’s solid on .NET. The latest signed binaries are available from the SGMLReader Github page via the download button.
If you want to help us improve SGMLReader, or tackle one of the outstanding issues, get started by forking our repo and clone the bits into your local dev environment. Using your preferred IDE, help us address the remaining issues and submit your fixes or new unit tests. SGMLReader has grown into one of the most important .Net libraries and I’m excited contributing to it has just become a whole lot easier!
 Using MonoDevelop 2.4.2 with Mono 2.8.2 on OSX 10.6.6
One of the exciting new features in the next major release (code-named Pipestone), is the DekiScript Page Profiler. I’m confident this new feature will delight many DekiScript developers.
In the past, it has been a hassle to figure what part of a complicated, dynamically rendered page requires the most attention. Often, the only method was to comment out sections one by one to determine the offending line or page inclusion. This is now a thing of the past. The page profiler provides a detailed view of every single DekiScript function called and every page included. It’s your backstage pass to see exactly what’s going on!
The profiler output is split into 4 summaries:
- Rendered Content lists all the pages that were rendered and what functions were invoked on each page. Function invocations are grouped together by location to show what each line is doing. Additionally, each function includes an invocation count and total elapsed time.
- Function Summary lists all functions invoked across all pages with their total elapsed time, total invocation count, average time, and max time.
- Page Summary lists all pages with their total rendering time, inclusion count, average time, and max time.
- Data Access Summary lists how many database queries were issued and the performance of the optional cache.
Obtaining the page profiler report requires directly accessing the API, a task that shouldn’t be a hurdleto DekiScript developers.
Here is how you get your page profiler XML document:
- Identify the page ID of the page you want to profile. The easiest is to look at the page source and look for the line that says:
Deki.PageId = 123;
- The page meta-data for any page can be accessed by its ID:
- Now append
/contents/explainand you’ll get the page profiler report:
Depending on how many operations your page performs, the returned XML can become fairly large, but that’s because it contains lots of details. I would recommend looking at the function and page summaries first to get a sense for the potential culprits and use that information to track down the actual call that is causing the slowdown.
Finally, if your site your users report from sporadic slowdowns that you can’t reproduce, you can add this configuration key to have the profiler log its output when a page takes more than 3 seconds to render:
This will make it easier to capture those elusive moments where for some reason a page takes unusually long to render.
And remember when optimizing your pages: the fastest code is the one that never needs to run!