Posted on

Installing a Scythe Mini Ninja

After using my htpc for 4 months I sometimes became annoyed of the noise being produced by the system. It varied from day to day, so I decided to do something about it.

There were only 4 fans in the system, one on the cpu, two on the side of the case to get airflow going and one to cool down the psu. The loudest one was the stock cpu cooler, closely followed by the psu fan. The two 120mm fans are already quite good. After searching on the internet for a passive cpu cooler it seemed that the Scythe Mini Ninja was quite popular and ideal for the system that I have assembled. No computer parts shop in Belgium had it, or they were quite expensive, so I purchased one on eBay.

In the package you find: thermal paste, 3 mounting systems (meaning universal socket support), screws, one fan, clips to attach the fan and one big heatsink.

When removing the stock cpu cooler I noticed that there was not much of thermal paste on the standard heatsink, so removing any residue was quite easy. I also ignored all the advice of installing the Ninja outside the case, which would mean dismantling the htpc. In the end it didn’t save me that much time, since I had to remove the ram and some of the power cables to install the heatsink, also if you’ve got thicker fingers than me you probably won’t be able to reach all of the pins used to attach the Ninja to the motherboard. Make sure to apply an even layer of thermal paste on the cpu, you won’t need to use all of it since too much is as bad as too little.

I powered the system back on again, changed the bios to allow the absence of a cpu fan, and off it went. With the top of the case screwed back into place I first thought the upgrade didn’t change a lot, but I was sitting at 20cm from it. When I had placed the htpc back into it’s normal habitat and sat on a normal distance (2 meters) the psu fan was still audible but any ambient sound can overcome it. When I start a movie the system can’t be heard now.

To test the heatsink I started two instances of cpuburn and watched the result with speedfan. After 5-10 minutes the temperature reached around 50 degrees which is quite good, especially if you keep in mind that the two cores will never be under that amount of load under normal use.

So overall a great product.

Posted on

Using appSettings in your Spring configuration

This seems to be an undocumented feature that someone asked about on the user forum of the Spring.Net framework, I don’t know where I picked it up so I’m writing it down here.

When using .Net you tend to put configuration values in the appSettings section of your app or web.config. Entries like filepaths or other constants fit here nicely. If you’ve written an application powered by Spring.Net you’ll also have several spring configuration files which define the objects in use by your system. Most of their dependencies (if not all) are quite static but sometimes there’s the need for a configurable value. These tend to change more than other object relations so instead of searching through all your definitions to change them wouldn’t it be better to have a central place where you can manage them? Of course it would, so let’s use the appSettings section!

In order to reference the appSettings in your Spring configuration file you need to add this object definition to your configuration:

<object name="appConfigPropertyHolder" type="Spring.Objects.Factory.Config.PropertyPlaceholderConfigurer, Spring.Core">
  <property name="configSections">
    <value>appSettings</value>
  </property>
</object>

Your appSettings typically looks like this:

<appSettings>
  <add key="LoggerOutputFile" value="c:MyOutputFile.txt"/>
</appSettings>

Now you can reference this value using ${“LoggerOutputFile”} as illustrated below.

<object name="MyLogger" type="SpringAppSettingsConsole.Infrastructure.FileLogger, SpringAppSettingsConsole">
  <constructor-arg  value="${LoggerOutputFile}"/>
</object>

Full sample with source code can be downloaded here: SpringAppSettings.zip (247.31 kb)

Posted on

Updated to BlogEngine 1.4.5

A new BE version, means sql scripting time for MS SQL 2000 users. For a full upgrade guide you should go to Al Nyveldt’s blog.

If you are creating a new blog or are upgrading from 1.3.x, just use the correct script for you.

MSSQL2000_Setup1.4.5.0.sql (24.91 kb)

MSSQL2000_UpgradeTo1.4.5.0From1.3.x.sql (10.07 kb)

If you are currently using 1.4.0 there’s some more work you’ll need to do. In this new version the column ‘Settings’ in the table ‘DataStoreSettings’ has changed from binary datatype to varchar, the corresponding change on MS SQL 2000 means moving from the image datatype to ntext. This is not possible / allowed by the server. The easiest thing you can do is to take note of your settings under the extensions tab in the administration control panel and delete all rows from the table ‘DataStoreSettings’. Every extension will populate the table again with data the first time they get loaded with the new BE version, you can then configure the extensions again with the settings you want. It’s quite possible that you are still using the default settings of your extensions, like me, then you don’t need to worry about the old settings, just clear the table of its entries.

If you’ve used the script from my earlier post, when I upgraded from 1.3 to 1.4, there was one insert statement missing from the script. The insert statement added the widget bar with its default configuration. Since it was missing then and we are deleting all entries from the ‘DataStoreSettings’ I’ve included the insert statement, the default script that ships with BE 1.4.5 has an update statement in place for that entry in the DB.

MSSQL2000_UpgradeTo1.4.5.0From1.4.0.0.sql (3.20 kb)

Finally, if you are running SQL Membership and Role provider and are upgrading from an earlier version don’t forget to check the applicationName of the providers, in 1.4 this changed from BlogEngine.Net to BlogEngine. What you need to change is described in my earlier post.