Uncategorized Archives - Page 11 of 43

February 14, 2010

Monitoring your BlogEngine.net installation – Health Monitoring and WebMonitor

When you have a web site, for instance an installation of BlogEngine, you often want to be able to know about errors on it and if it is down. There are a lot of tools to help you out here, but in this post I will talk about using a build-in ASP.NET feature called Health Monitoring and a tool I wrote called WebMonitor.

[more]

Health Monitoring

For ASP.NET developers Health Monitoring might not be something new and something that they know much about. My guess is that the average BlogEngine user/owner doesn’t know about this, why I decided to create this post. So, what is Health Monitoring in ASP.NET?

Well, Health Monitoring is a build-in feature in ASP.NET that gives you an easy way to get notified about your applications (BlogEngine in this case) health at run-time. You can read more about Health Monitoring here on MSDN. This means that with the setup I am going to explain below, you will be able to get an email when ever an error is occurring on your site. When I say “when ever an error occurring” it is really not totally true. Health Monitoring is intelligent in the way that it doesn’t just spam you EVERY time an error occur, it wait some time and send you one email, even if 20 errors occurred with in 5 seconds. But you can read more about that on the MSDN link above.
Let me also add here, that I’m not sure if Health Monitoring is fully functional on BlogEngine, as I haven’t tested it that much on the 1.6 release. If they implemented manually redirects in code in the “wrong” way in the BlogEngine, you might not get all the error emails as you should. But let me say that I have had Health Monitoring enabled on my blog for a long time and it seems to still be working in 1.6.

So, how do we enable this? Actually it’s pretty easy. You need to open up your root web.config from your BlogEngine installation. Between the <system.web> and the </system.web> you insert the code below.

<healthMonitoring enabled="true">
      <eventMappings>
        <clear />
        <!-- Log ALL error events -->
        <add name="AllErrors" type="System.Web.Management.WebBaseErrorEvent"
                                      startEventCode="0" endEventCode="2147483647" />
      </eventMappings>
      <providers>
        <clear />
        <add type="System.Web.Management.SimpleMailWebEventProvider"
                                      name="EmailWebEventProvider"
                                      from="ERROR@YOURDOMAIN.COM"
                                      to="YOUR@EMAIL.COM"
                                      bodyHeader=""
                                      bodyFooter=""
                                      buffer="false" />
      </providers>
      <rules>
        <clear />
        <add name="Auth Failure Audits Email" eventName="AllErrors"
                                      provider="EmailWebEventProvider" profile="Default" minInstances="1"
                                      maxLimit="Infinite" minInterval="00:00:05" />
      </rules>
    </healthMonitoring>

Now you change the ERROR@YOURDOMAIN.COM to the email address you want the email to come from. Then you change the YOUR@EMAIL.COM to your email, where the error emails should be send.

Now your done and you should start receiving emails about errors on your site (if your STMP settings is setup correctly, you setup them up either in the web.config or on the administration pages of BlogEngine).

You can setup up a lot of stuff on Health Monitoring via the web.config, so if you want to go deeper into this, see the MSDN page linked to earlier in the post or Google it. For instance you can make the errors go to a database instead of as email and you can setup which types of error you want etc.

WebMonitor

Another way to keep yourself updated on the “health” of your blog/site, is to use WebMonitor. WebMonitor is an application I made 2 years ago or so, as I needed to keep an eye on some servers that wasn’t responding from time to time.

So what does this “WebMonitor” tool do? Well, first of all, it’s a desktop application that you install on the machine that you are using, instead of having the server do stuff like in the Health Monitoring case. What you basically do is to setup of a “monitor” for a specific URL. The monitor will then make a request at a given time interval. You can then setup the monitor to react to different rules and notify you if something is wrong. For instance, if the response time is longer than 500 ms you can be notified with a balloon popup from the tray.

Hope it helps!

– Enjoy!

February 2, 2010

BlogEngine.Net 1.6 released – Maybe focus on SEO in next release?

So today it happened, finally, the new version of BlogEngine has been released. It comes with some major Comment Spam Protection changes, multi widget support and more. This is all great and I really hope that this can beat these bad comment spam bots, which I guess we all hate.

I have just upgraded my blog to this latest release and the upgrade went pretty good without any real problems. So far so good, now I just have to wait and see if the spam protection is working as intended.

[more]

SEO in next release?

As I mentioned in a previous post I would like to get my blog 100 % (or at least close to) SEO (Search Engine Optimized) to help people find my blog through search engines. I guess we all want that, which is why I think SEO would be a great focus for the next release of BlogEngine.

ScottGu recently blogged about Microsoft’s new SEO Tool for IIS7 see the blog post here: http://weblogs.asp.net/scottgu/archive/2009/06/03/iis-search-engine-optimization-toolkit.aspx

I know the BlogEngine theme can’t help people posting broken url’s, making bad themes etc. What they could do were to try and make the default theme (the Standard one) as close to 100% search engine optimized. I just tried setting my blog to use this Standard theme and then let the SEO Toolkit run over my blog. This is the result I got.

As you can see, this isn’t very good. As mentioned, I have some broken links etc, that’s my own problem, but some of the major ones should be able to be fixed by the BlogEngine team. I don’t want to go through all the points that the BlogEngine team could do something about, I think they can see them self :)

I have considered just making changes to the source for my blog to make my blog be more SEO, but then at a second thought I don’t want to, as I then need to take over my changes to each new release of the BlogEngine and that would be a nightmare. Another reason for letting the official team put it into the engine is that we would all like to have this, right?

So, lets hope the BlogEngine team will look into this, I guess much of it would be pretty easy fixes. I have posted about this in the discussion at codeplex: http://blogengine.codeplex.com/Thread/View.aspx?ThreadId=82862

– Enjoy!

January 31, 2010October 18, 2014

Little Longhorn – Part 6 – Two weeks in the name of progress

About two weeks ago I wrote this post about how we decided to try and change the focus on how we develop this game. We have for a long time coded on the “engine” part of the game, so we have something solid to build the game on. This is very exciting and very needed, we just started to hit a point where we felt like we needed to have something we could “show” people. We needed to have a simple “playable” prototype of the game that we could show people and they could try. There were mainly two reasons for this:

We were starting to have a hard time finding the motivation to code on the project, as all the things we did were “non-visual”, like all the engine work, which didn’t gave anything to the game, visually or game play-wise. Motivation is a pretty important factor when you are doing a hobby project like this :)
We are both (me and Allan Hansen) very interesting in designing code as good as possible, which is why we usually talk a lot of how we can do stuff before we start coding it. This actually a good thing, but in this case, we saw that we needed a different approach.

So, with the points from above in mind, we wanted to do something about it, which is what we did the last two weeks.

[more]

Deadline

To help motivate our self, we set a deadline for when we needed to have a “playable” version of the game ready. Allan were holding his birthday/house-warning party Saturday 30th January 2010 and that became the deadline. It turned out that this deadline, even though it were just set by our self (keep in mind this is a hobby project) and no one really knew it or were expecting anything, help very much on the motivation for getting a “playable” version of Little Longhorn ready.

Making progress

The last two weeks we have made major progress. We went from a kind of tech/developer/proof-of-concept version to a playable version with menu, better graphics (still just dummy stuff), music/sound, menu, game play flow like start->play->game over->restart->complete level and much more. The way we did this were to focus only on getting features implemented, even though we didn’t knew if we did it the “right” way, code-wise. It has turned out that we could get something together this way pretty fast and we now have many idea how to do stuff better. So this has really helped us a lot. Here are some before and after screen shots.

Before:

After:

The good stuff is that we have something playable now, even though it is still of course far from what we have in mind for the final release. We can now look at the code we have and easily see how we can improve it and make it better, because we have something that actually works.

Show time

So the day arrived where we needed to have the game ready. We made it, but of course still had some last minute changes, right up to it were deployed on the Xbox. We started out by showing it where we played the game to explain people what the game were all about and that it were a early prototype etc. (You know, all the crap developers say to let “normal people” understand that this is NOT a final game :) ) Then we handed over the controller to some of the guests at the party and they started to play it. It were actually pretty funny to see people play the game and see how fast they understood the goal of the game, which is a very good thing and something that got noted by us (the developers). Even thought it is a prototype people actually found it pretty challenging and funny to play.
A funny thing that we discovered were that a minor change we did to some of the collision code, turned out to make the game lag like crazy after wave 5 or so. So from wave 5 to wave 8 (the game have 8 waves in all levels at this point) it were kind of a “slide show” :) That were funny by it self, but what were even more fun were that people insisted on keep playing, even though they saw 2 frame per second, because they wanted to see if the totems they placed could beat the enemies. Some of the guests actually managed to complete the level this way, pretty cool! I see this last thing as a good indication on that the game actually can become very funny and challenging to play.

We also recorded a video while we showed the game and people were playing it.

Next step

As mentioned before, we now have a kind of working game, but the code can be done much better many places. So what we need to do next is to go through the code and refactor. I’m not talking about performance improvements here, I’m talking about generally better architecture of the game. Well, we of course need to fix the collision bug I mentioned (lag from wave 5 to 8), but besides that, we will not do performance improvements yet, as it’s way to early to do that.
When we are done refactoring/cleaning up the code, we will start implementing an level editor. This will be for use internally by us at this point to make levels faster and easier (right now it’s raw XML editing when doing levels), but it might be possible for players to make levels also in the future, but no promises here.

Hope you enjoy following the progress of this game, please let me know what you think about it, by leaving a comment :)

– Enjoy!