I Already Googled It

Here’s a quick disclaimer before I begin: I’m not a web designer.  I don’t want to be a web designer.  This picture pretty much sums up why:

On top of the excellent points raised by the above graphic (I actually do have my own keyboard at work.  I don’t “bring” it though, I bought an extra one so I could leave it there and so it’d always be there waiting for me…) there’s also the fact that I really don’t care how things look.  When you think about it, it doesn’t matter either.  Why does it matter if your website has a billion little JavaScript tricks et cetera as long as it gets the point across?

It doesn’t.

In fact, I’ve noticed that how pretty a site is, and the quality of its content, seem to be inversely correlated.

And then there’s the fact that 9 out of 10 “pretty” sites just don’t work.  At all.

Anyway, this post is about the dirge that is “negative space“.  You go to a site, and you see somewhere in the area of seven miles of totally wasted space on either side of the content.  Either these people never understood that you can size things in CSS proportionally (i.e. set a div to 95% of the screen’s width rather than 800 pixels to appeal to the non-existent viewer who’s still trapped on a circa 1997 monitor), or they think that it’s somehow artistic and appealing.

Sure, negative space is an accepted idea in art and photography, but this is web design.  You’re not trying to appeal to the user with art, you’re attempting to present content, and content has to be read or viewed, and to do that screen real estate is required.  What are you hoping to achieve by wasting 2/3rds of the screen?  Is it your mission in life to make your users use the scroll wheel more?

Here’s an example—the Battle.NET forums (inb4: WoW lol) (I’ve just cut out the left half the screen so the image isn’t too wide/large):

(Haha idiot can’t spell “looking“…)

Seriously, what in the name of God? This might be alright if it was just the topic listing that was like this, but the thread display has this same design, so you wind up scrolling something like 3-4 times the normal amount. Do they think that users find longer pages more appealing or impressive?

If the point of your website is to allow users to enjoy your content, let them enjoy your content! Your “content“—hopefully—isn’t so small that you need “tricks” like this to make appear bigger, or merely the design itself, because if either is the case, you’re pretty fucking vapid, and you need to worry about other things than how nice your page looks.

Or maybe you’re worried about users on widescreen monitors having to constantly look side-to-side?

NEWSFLASH: I bought a widescreen monitor for a reason; I actually wanted it to be wide.  Don’t take that choice away from me you asshole, if I wanted to be compulsive scroll wheel user I would’ve bought a 4:3 monitor, but I didn’t so I don’t.

Also: I’m pretty sure all window managers from the Explorer shell to X Server allow you to resize windows.  If I’m so stupid that I don’t realize my eyeballs move side-to-side in their sockets, and my neck gets sore or something else, I’m either too fucking stupid to matter, or I’ll just make the window thinner and put it in the middle of my widescreen monitor and it will look the same!

So I recently switched my Windows Mobile phone over to Android (thanks to all the hackers at HTCPedia and XDA Developers), have been busily pimping it out for a week or so now, and recently decided that I wanted to run an SSH server on it.  Since putting OpenSSH Server on my Windows web server using CYGWIN, I’ve found a plethora of wonderful uses for SSH and SCP, and being able to move files back-and-forth between my phone and my PC across SSH (rather than having to plug in with USB or move an SD card around) would be a welcome convenience.

Searching (I would say “Googling” but I use Bing so that would be misleading) around the web I’ve found great instructions on how to do this and get it setup with public/private key authentication (my favourite), but finding a download for the Dropbear (an SSH server) binaries with the Android patch (Android is not multi-user, which confuses Dropbear without the patch) presented a slight challenge.

You see, people seem to imagine that the instructions they put on the internet will only be used for maybe a week, and then no one will ever look at them again, so invariably you use the power of a search engine, months after their instructions were posted, and wind up finding great instructions, with a broken download link.

Is it really that hard to keep a file that’s a few megabytes hosted?  Seriously?  I understand these people aren’t being paid (I had an even bigger rage fit trying to find the Linux Integration Components for Hyper-V because every microsoft.com download link 404′d…), but still, it should be a matter of pride that you link something, and the link works.  I have literally thousands of images sitting on this web server just because I may have linked them at some point and I don’t want that link to suddenly start 404ing.

I finally found someone who downloaded and re-hosted the patched Dropbear binaries, so here’s a link to him, and a thank-you, along with awsm.jpg to express my joy.

More specifically, the IIS version of URL rewriting.  Everyone knows that Apache has mod_rewrite, but these tools on the Windows side seem to get less attention, which is upsetting to me, since IIS has about 20% of the web server market, being second only to Apache.

To me at least, the allure of stable ASP.NET support—mod_mono, while cool, is anything but stable (it doesn’t even have full support for System.Net.SmtpClient, a feature I’d think would be essential in a web development platform)—is enough of a reason to stick with IIS, and there there’s the fact that IIS 7.5 with FastCGI is wicked fast, even when hosting non-ASP.NET pages (eww PHP…).

Anyway, URL rewriting exists for IIS—mod_rewrite/Apache is not the only contender—and it’s very easy to use.  It not only has a GUI which is added to the IIS Management Console, but you can also create rules through XML in web.config in much the same way you can with mod_rewrite/Apache and .htaccess.

URL rewriting is especially useful with things like what I posted about yesterday, since it allows things like raw HTTP request handling to be much more transparent to the user.  Also: Even if you’ve rewritten the original URL, it can still be accessed by the server variable “HTTP_X_ORIGINAL_URL“, which allows you to create ASP.NET HTTP handlers which look at the original URL and do something based on it.  For example, you could host images, but want to do some advanced analytics/request filtering which can’t be accomplished any other way.  You can have the web server re-write all requests for image files (by making a rewrite rule which examines their file extension—regular expressions for the win!—and then rewrites the request to point to an *.ashx, which will then look up “HTTP_X_ORIGINAL_URL“, and use this to find the image, set the content type, and return the image, while seamlessly—from the user’s point-of-view—doing whatever filtering/analysis you want.

What I found coolest when I started using WordPress with the URL Rewrite Module installed, was the fact that WordPress has native support for it.  When I enabled permalinks, it modified the web.config file for my “blog” folder automatically:

Here’s the XML that it wrote:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
                <rule name="wordpress" patternSyntax="Wildcard">
                    <match url="*"/>
                        <conditions>
                            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true"/>
                            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true"/>
                        </conditions>
                    <action type="Rewrite" url="index.php"/>
                </rule></rules>
    </rewrite>
  </system.webServer>
</configuration>

In case you can’t tell, this rewrites all requests to http://rleahy.ca/blog/* which aren’t either a physical file or directory to index.php—the heart of the WordPress system—WordPress then uses “HTTP_X_ORIGINAL_URL” to decide what to display, whether a permalinked blog post or something else.

This is quite different—and perhaps more flexible/desireable—than the usual/tradition manner of beautifying parameters embedded in URLs, which uses regex to reassign the parameters—disguised as folders—to a query string.

I’ve been magically using syntax highlighting in some of my blog posts.

No, I don’t accomplish this by having no life and doing it by hand.  There are some nice tools available that’ll allow you to get HTML syntax-highlighted code snippets.

The first of these is very straightforward. PHP has a built in syntax highlighter, and, if enabled, will automatically spit out HTML syntax-highlighted PHP code when you visit a *.phps file.

To enable this behaviour—and it’s not recommended on production servers since sensitive data can hide in source code—you have to add a handler mapping in IIS for “*.phps” files, and map it to php-cgi.exe with the command line option -s.

Once you’ve enabled it, rename the *.php file that you want the syntax-highlighted source for to a *.phps file, visit it in a web browser, use “View Source“, copy and paste.

For C#/XML, I use this handy tool (also in “Links” in the sidebar).  You do need to embed his stylesheet in the <head> of your page, but he provides the source to do that (make sure you download and re-host his *.css file).  If you’re using WordPress, you’re going to need to find the header.php file for your theme, and stick it in there.

The thing that I love most about ASP.NET is the fact that it’s very clean, very well-organized, and gives you exceptional control over the web server.

Working closely with the web server—ending the current response, sending a redirect, transferring seamlessly to a different page, sending a custom HTTP status code, et cetera—is so easy and seamless with ASP.NET that I often take it for granted, and am mortified when I somehow wind up coding PHP:

Yes, it looks like that.

The problem with a lot of these useful methods linked above is the fact that they’re seemingly quick and easy, but are actually woefully inefficient.  If you prematurely end the processing of an *.aspx, ASP.NET accomplishes this by throwing an exception, which bubbles up through the stack and is eventually caught—it is obviously not of the type to bubble all the way up and cause a 500.  If you know anything about exception generation/handling, you know that exceptions have a sizeable overhead.  Not to say that they should be avoided, merely that they’re not good for all situations—specifically, the situation of ending an HTTP response prematurely.  Imagine—for example—socket programming without exceptions.  Inversely, imagine if a StreamReader threw an exception—rather than returning null—when you called ReadLine and there was nothing to read.

Bottom line: There’s a time and a place for everything—including exceptions.  Conventional “should I use an exception?” logic dictates that ending an HTTP response is not a place for an exception.

The narrow use case of ending a response prematurely aside, there are many things that you want to do programmatically with the power of ASP.NET which don’t require the ridiculous number of features you get from a Page.  Pages are extremely robust, and have a lot of features and flexibility, but features and flexibility come with a trade off—i.e. overhead.

So what about when you want something lightweight to see if a user is authenticated before allowing him to access a page?  It’s bad HCI to just wantonly throw 4xx status codes in the user’s face, but if the user is going out of his or her way to request pages that require a login when he’s not logged in, it’s not such a bad idea—why waste server processing time/bandwidth generating and sending him actual HTML?  However, generating the abstraction of a Page just to destroy it without actually using any of it except for the PreInit event doesn’t really make sense, does it?

Fortunately, there’s a way around this: *.ashx files.

An *.ashx file is an ASP.NET HTTP handler file, and contains code that is used to process—or pre-process, depending on your use of it—an HTTP connection.  The interface that all *.ashx files implement—IHttpHandler—contains only one method—ProcessRequest—which is called when the *.ashx file is requested.  This single method takes as an argument an HttpContext, which allows you to perform all of the granular manipulation you can in an *.aspx page without the associated overhead.  In fact, an *.ashx page is up to 10 times as fast as an *.aspx (assuming, of course, you were using the *.aspx for something which the paradigm was not intended for, as discussed above).

The other advantage to this is that since all the page’s processing is done in one method—rather than in a bunch of functions pointed to by a bunch of delegates and called as events happen—there’s no need for a “kill switch” like Response.End().  You need only to use structured programming techniques to make these conditions which would otherwise require a call to Response.End() fall to the end of the function, and you’ve accomplished the goal of skipping further processing and ending the response without any messy exception throwing/catching down within the Framework.

So I’m happy that I can now see who’s linking to my blog—whether they use PingBacks et cetera or not—which got me thinking that it’d be somewhat cool to do the same thing for my homepage, which is written in ASP.NET.

So here’s code that does exactly the same thing as the PHP code I posted in my last blog post, except with ASP.NET (and C#):

try {

    if (Request.UrlReferrer!=null) {

        Response.Write(
            "<div class=\"categorybox\">You were linked to here from <a href=\""+
            Request.UrlReferrer.ToString()+
            "\">here</a>.</div>"
        );

        Boolean exists=false;
        using (System.IO.StreamReader read=new System.IO.StreamReader(
            new System.IO.FileStream(
                System.IO.Path.Combine(
                    Server.MapPath(null),
                    "referrerlist.txt"
                ),
                System.IO.FileMode.OpenOrCreate,
                System.IO.FileAccess.Read,
                System.IO.FileShare.Read
            )
        )) {

            String holdthis;
            while ((holdthis=read.ReadLine())!=null) {

                if (Request.UrlReferrer.Host==holdthis) {

                    exists=true;
                    break;

                }

            }

        }

        if (!exists) {

            using (System.IO.StreamWriter write=new System.IO.StreamWriter(
                new System.IO.FileStream(
                    System.IO.Path.Combine(
                        Server.MapPath(null),
                        "referrerlist.txt"
                    ),
                    System.IO.FileMode.Append,
                    System.IO.FileAccess.Write,
                    System.IO.FileShare.None
                )
            )) {

                write.WriteLine(Request.UrlReferrer.Host);

            }

            System.Net.Mail.SmtpClient mail=new System.Net.Mail.SmtpClient("192.168.50.4",25);
            mail.Send(
                "noreply@rleahy.ca",
                "rleahy@rleahy.ca",
                "Your Website Has Been Linked To",
                "The domain "+
                    Request.UrlReferrer.Host+
                    " has started linking to your site from "+
                    Request.UrlReferrer.ToString()+
                    "."
            );

        }

    }

} catch { }

Since .NET’s SmtpClient doesn’t pull from a configuration file–unlike PHP’s mail, which pulls SMTP settings from php.ini—there are few more “fill in the blanks” as opposed to yesterday:

• Your SMTP server’s IP/hostname.
• Your SMTP server’s port.
• The from address for your server.
• The to address (just like the PHP script).

If you want to be a real keener—or if it just fits in with your application—you can replace these “blanks” with calls to ConfigurationManager.AppSettings and store all of that in your web.config file.

Other than that, just put it between <% and %> anywhere in your *.aspx file, and you’re set.

If your environment uses authentication or SSL for SMTP, read the SmtpClient documentation and adjust the mailer portion accordingly.

Afterthought: This is the first blog post I’ve made before midnight…what a night owl I am…

So—being that I’m new at this whole WordPress thing—I was playing around with the blogroll today, and was wondering if it sent PingBacks when I linked someone’s blog (maybe this is something retarded to think, I don’t know, just something I was thinking about since I’ve seen “PingBack from [...]” in so many bloggers’ comments).

Turns out, it doesn’t.  I tried both by linking my own blog and by linking a friend’s.  Which got me to wondering, how would you know if someone was linking your blog?  Go through the IIS logs (Apache sucks and is therefore irrelevant)?  That’s lame.

While it may seem immaterial to some people, but I like knowing all the goings on on my web server—because it is mine, none of that hosted garbage, this baby sits in my basement.

So—like all good nerds—I invented a way: A simple PHP script that you include in WordPress’ index.php, so it runs everytime index.php is loaded, and tests for a referrer from a domain it hasn’t seen before (you could easily modify it to look for a page it hasn’t seen before, but I don’t really care about that).  When it sees a referrer from such a domain, it logs it to a file—so it doesn’t get all excited about it again—and sends you an e-mail letting you know.

Here’s the script—referrer.php:

<?php

    if (isset($_SERVER['HTTP_REFERER'])) {

        if (preg_match("#^http://(.+?)/#i",$_SERVER['HTTP_REFERER'],$matches)!=0) {

            $handle=fopen("./referrerlist.txt",'r');

            $exists=false;
            $regexed="#^".preg_replace("#\.#","\.",$matches[1])."$#i";
            while (($holdthis=fgets($handle))!=NULL) {

                if (preg_match($regexed,$holdthis)!=0) {

                    $exists=true;
                    break;

                }

            }

            fclose($handle);

            if (!$exists) {

                $handle=fopen("./referrerlist.txt",'a');
                flock($handle,LOCK_EX);
                fwrite($handle,$matches[1]."\n");
                flock($handle,LOCK_UN);
                fclose($handle);

                mail(
                    "rleahy@rleahy.ca",
                    "New link to your blog!",
                    "The domain ".
                        $matches[1].
                        " has started linking to your blog, from the URL ".
                        $_SERVER['HTTP_REFERER'].
                        "."
                );

            }

        }

    }

?>

Obviously you’re going to want to replace my e-mail address with your own.

Once you’ve done this, save it in the root of your WordPress site, and then create an empty text file called referrerlist.txt—this is where the script will store the list of domains.

Last, but not least, open index.php—the heart of WordPress—and add this line:

include('./referrer.php');

Then visit your blog, and click one of the links it has to itself (such as opening a blog entry). You should immediately receive an e-mail notifying you that you’re linking to yourself (lol), and your domain should appear in referrerlist.txt.

I’m currently using it in my blog—which you’re ostensibly reading —so it doesn’t fuck with your WordPress or anything (unless my WordPress is fucked?).

Oh, and, copyleft et cetera.

So, for this Linux Systems Administration course I’m currently taking, we had the pleasure (?) of choosing a “project” and doing it on Linux servers that we’d been carefully building, adding to, and maintaining throughout the term.

I—being an unashamed M$ fanboy—chose to install and configure mono, XSP, and mod_mono.

Turns out that this was a bad idea.  Then again, being that it’s Linux we’re dealing with, what wouldn’t've been a bad idea?  Being like half the class and just typing yum install webmin?

No…that’s just not how I roll…

Anyway, we were making a wiki, so I couldn’t just install and then configure, and then tinker and tinker until it was just right, and then call it a day, which has pretty much been my approach with all the labs so far.  I had to get the installation and configuration down to a science.  So it makes a good blog post to save other souls from my 3 hour ordeal.

That’s right.  3 hours to make Linux do something Windows Server 2008 R2 does just by adding the IIS “feature“.  But that’s to be expected—it’s Linux.

Anyway.  You’ll find a lot of tutorials on-line which give you horribly convoluted information on how to get mono/mod_mono installed and working.  Being that they’re horribly convoluted, they’re not of much help.  I’m pretty sure they’re the result of people taking the approach I spoke of, and then trying to convert that into instructions…

…which doesn’t go so well.

So you’re going to want to install mono itself—and all its components—on CentOS (which is what we’re using) this is yum groupinstall mono.

Then you’re going to want to get XSP.  If you’re using CentOS this is yum install xsp.  Be careful if you’ve installed the mono repos, however, when you try and yum install xsp, the CentOS repos will feed you a CentOS version, and the mono repos will try and feed you the RHEL version, and then you’ll have two versions, and it won’t work at all—first-hand experience talking here—so for the love of your sanity, be pro-active using yum list to see if there are two packages, and then just use yum install with the specific one that’s suited to you.

Last, you need mod_mono itself.  If you’re using CentOS this is yum install mod_mono.  The advisory from above still applies.

Now that you’re got everything installed, you’re ready to configure.

You’re probably expecting me to launch into lines and lines of things copy pasted from httpd.conf, but that’s just not how I roll.

I’m going to give you the link that saved my ass (that’s it right there).  After 2 hours getting mod_mono working (albeit barely), I got in my head to tinker with it (this usually happens to me…I’m too curious for my own good) and wound up somehow, mysteriously, breaking it.  Then it was another hour (or an hour-and-a-half…time just melts away while you’re fighting with Linux) going back through all those horribly convoluted instructions, which wound up all being bunk in the end.

So use the link, and don’t read those other instructions.

Oh, and don’t forget to restart Apache after you do your configuration.

There’s the proof.

So a buddy and I decided to work on an AJAX-based chat server/client, as an exercise in ASP.NET, .NET Sockets and Threading, and JavaScript, and it really brought to the forefront the reasons that I alternately love and hate JavaScript…

As it stands we’re both working on it separately—being that it’s an academic exercise—but eventually I think we’ll merge out efforts and work to our strengths (I’m really good at writing back-end code, but am terrible at HTML/CSS, which is good because it means I probably won’t have to write JavaScript again…).

Anyway, working with JavaScript is really one of those love/hate things for me, and I guess I felt compelled to blog about it. I went to blog about it about 12 hours ago—while I was actually writing it—but decided that my post would be too rage-filled…

…and that might be too overwhelming for a first blog post.

The great part (i.e. the “love” part) of JavaScript is when you’re finished. It does really, really cool shit, doesn’t even take that long to write, and there’s a lot of boilerplate code out there to work from.  AJAX is especially awesome, watching this HTML—which you have this expectation of being static—get “pushed” chat messages is nothing short of magical (not to sound like Steve Jobs…).

The bad part (i.e. the “hate” part) is actually writing the JavaScript.  I can’t think of a single language I hate more (not even Java, and I hate Java) than JavaScript.  The main problem I have with it is the fact that it’s so cross-platform, so cross-browser, that the debugging errors that are given are totally meaningless.  Take this line of code for example:

document.GetElementById("chat_div").Style.Display="none";

Seems fine, but it’s not, because JavaScript is case sensitive (which seems bizarre for a scripting language, but whatever) and uses the camelCase convention.  While in a sensible language—like C# —you’d get a helpful (or at least semi-helpful…) error message, in JavaScript you get “Object expected”, which leads you to believe that DOM couldn’t find the element with ID “chat_div”, which just isn’t the case at all.

Compound this with the fact that I already have high blood pressure…