Rickard Andersson

HashPeak – GPU mining hashrate peak detector

Here’s a plug for a small piece of software I wrote that is used to determine the optimal clock frequency for GPUs when mining cryptocurrencies.

HashPeak - Sample run

Determining the most effecient hashrate for GPU-based cryptocurrency mining is a tedious process. It usually involves manually trying a large number of GPU engine core frequencies and keeping track of the resulting hashrate to detect any peaks in hashrate. HashPeak automates this process.

HashPeak is a .NET 2.0 console application that connects to a running instance of sgminer or cgminer, sets a GPU engine clock, waits for the hashrate to stabilize and then measures the hashrate. The application is provided with a range of GPU clocks to test and then runs through them in succession. Upon completion, the application presents the user with the lowest GPU enging clock frequency that resulted in the highest possible hashrate.

In addition, HashPeak generates a CSV (Comma-Separated Values) file including all measured data as well as a plotted graph in the form of a PNG file.

There’s more info about HashPeak over in the release topic in the Bitcoin forums.

The code is available on Github.

Setting display name from the Sitecore page editor

In order to allow for SEO friendly URL:s in multi-language sites, the URL to an item needs to be different depending on the language that it is displayed in. For example, an article about Christmas presents might have the URL /articles/christmas-presents for the English version and /artiklar/julklappar for the Swedish version. Even though the URL:s are different, they point to the same item in the Sitecore content tree.

Sitecore supports this behavior via the display name field. If a display name is set for the current context language, Sitecore will use that name to construct the URL and if no display name is set, it will use the item name. The item name is shared between languages whereas display name is not. This works out of the box.

However, in order to allow authors to edit the display name directly in page editor, a few tweaks and a small workaround is needed, at least in the current release of Sitecore (6.5.0 update 5). We need to add an edit frame somewhere on the page and configure it to include display name as an editable field. Additionally, we need to override a handler method called by the page editor ribbon form.

Adding an edit frame is pretty straight-forward. In content editor, switch to the core database, and navigate to /sitecore/content/Applications/WebEdit/Edit Frame Buttons. Duplicate the default folder and give it a meaningful name. Then open up the folder, delete the items Insert and Edit the related item. Then edit the item called Edit and under Fields, enter __Display name.

The second step is to add the sc:EditFrame to our layout or sublayout. In our case, we wrapped the website logo in an edit frame so that when an author clicks the logo in page editor, the edit frame pops up. The final markup could look something like this:

<sc:editFrame runat="server" ID="efPage" Buttons="/sitecore/content/Applications/WebEdit/Edit Frame Buttons/Page">
    <!-- image tag here -->

Then set the DataSource for the edit frame to the current context item (e.g. Sitecore.Context.Item), either in the markup or from codebehind.

Now if you open up the page in page editor and click the logo, a Sitecore control popup should appear containing a button. If you click the button, the edit frame appears and you can edit the display name.

All is not well though. In changing display name, we are changing the URL to the page and unfortunately, page editor doesn’t pick this up when it saves the page. If you change display name and save the page, page editor will attempt to redirect you to the old URL instead of the new and you end up with a 404. The solution to this problem is a bit of a hack. We need to add our own implementation of the method SavedNotificationHandler in the page editor ribbon form. Here’s our implementation.

protected override void SavedNotification(Object sender, ItemSavedEventArgs args)
    Assert.ArgumentNotNull(sender, "sender");
    Assert.ArgumentNotNull(args, "args");

    var item = args.Item.Database.GetItem(new DataUri(new ItemUri(this.ContextUri)));

    if (item.ID == args.Item.ID)
        UrlString webSiteUrl = SiteContext.GetWebSiteUrl();

        webSiteUrl.Add("sc_mode", "edit");
        webSiteUrl.Add("sc_itemid", args.Item.ID.ToString());
        webSiteUrl.Add("sc_lang", args.Item.Language.ToString());

        SheerResponse.Eval("scNavigate(\"" + webSiteUrl.ToString() + "\", 1)");
        base.SavedNotification(sender, args);

Just put this method in a class somewhere. Now we need to edit the file /sitecore/shell/Applications/WebEdit/WebEditRibbon.aspx and replace the existing CodeBeside directive with your own. For example:

<sc:codebeside runat="server" Type="MySolution.Utils.Processor.SavedNotificationHandler, MySolution.Utils"></sc:codebeside>

What this means is that Sitecore will invoke our implementation of the SavedNotificationHandler instead of Sitecores native method. Be careful when updating Sitecore so that your change doesn’t get overwritten in the update process. It would be preferable to be able to override this method in less intrusive ways, but currently, this is the only way to solve this problem.

That’s it. You can now edit the display name of items directly from page editor.

If you want to enforce a particular naming standard for URL:s, you can add validation to the display name field, but that’s a topic for a different blog post.

Enforcing lowercase URLs in Sitecore

Allowing more than one URL to access the same content on a web site is bad practice. The reason being that search engines tend to dilute the rank of the page if it is accessible via more than one URL. This is common knowledge in the web developer community and often taken into account when designing web sites. It is also quite common to make sure your website generates URLs that only use lowercase letters. In Sitecore, there are various methods (here’s one, and another) that you can implement to support this.

However, often overlooked is the fact that URLs are in fact case sensitive. In the eyes of search engines, /foobar.html is not the same page as /FooBar.html. But most likely, if you pick a page in your Sitecore solution and change the case of some of the letters in the URL, the page still loads. But my web site doesn’t generate any links with uppercase letters, you say? True, but what if some high profile web site links to your site and they type in the URL manually using uppercase letters?

The solution to the problem is to detect if the URL contains any uppercase letters and if so, issue a 301 permanent redirect to the lowercase version of the same URL. That way, search engines, even though they were fed a mixed or uppercase version of the URL, will follow the redirect to the correct lowercase version of the URL.

You could implement this functionality in Sitecore using a LinkProvider, but in my opinion, the most elegant solution is to not involve Sitecore at all and instead use Microsoft’s URL Rewrite for IIS. The Rewrite Module supports pretty much all of the features of Apache’s mod_rewrite and even has import support for .htaccess style rules. For enforcing lowercase URLs, it has built-in standard rules that you can use. After you’ve installed the module, navigate to the site in question in IIS Manager, go to the URL Rewrite module and add a new rule. Under the SEO heading, you’ll find “Enforce lowercase URLs”. Apply the rule, and voila!

URL Rewrite Module

It should be noted that I have only tried this on content delivery servers, but I don’t think the Sitecore back-end will have any problems with this.

Update: Turns out that some features of page editor don’t work properly if you enable this on content management servers. In other words, don’t. Just use it on the front-end servers. Also, I forgot to mention this in the post, but when you apply a rule via IIS Manager, the rule is actually stored in your web.config, so be careful not to overwrite the file or your rules will disappear.

Incorrect count from the Twitter API user_timeline

I encountered an issue with the Twitter API the other day that I’m sure other people have run into as well. I found little or no information on the issue online though, so here goes.

If you’re using the Twitter API to fetch tweets for a particular user (i.e. statuses/user_timeline) and it appears the count parameter doesn’t quite do what it is supposed to, chances are you’re calling an old version of the API that doesn’t support native retweets. A native retweet is a retweet that’s created by clicking the retweet button on the Twitter site, as opposed to using “RT”.

If the URL you’re using contains a call to <username>.json where <username> is the user you’re fetching tweets from, you’re using the old version. The new version is called user_timeline.json and instead takes the user via the user_id or screen_name query string parameter.

When using the old version, native retweets would be excluded in the result, but still count as a “hit”. This means that if the latest tweet from the user was a native retweet and you set the count to 1, you would get back nothing. The new API properly supports native retweets and includes them in the result.

It should be noted that in order for the result to include retweets (native or otherwise), you have to include the include_rts=true parameter in your query.

A new record

As software applications that use SQL databases grow in functionality, so do the number of tables they use in the database. Not necessarily because they store more data but because they store more kinds of data. I believe PunBB, at least at the time I was working on it, had 17 tables. Microsoft’s App-V uses 46 tables. Ladok, the national system used for documentation of academic information at higher education institutions in Sweden, has 337 tables. But today, I almost fell out of my chair when I opened the database for CA Service Desk Manager, the service desk application we use in university IT. It has 2865 tables and 1388 views! Somebody likes to normalize their data.