I’ve been using Windows Vista on occasion recently. When I used it for the first time, I was expecting to see the now infamous ‘Cancel or allow?’ dialog boxes popping up left and right. To my surprise there was nothing of the sort. It took me a moment and to realize that the default account that had been created for me in Vista was an ‘administrator’ account, which allows you to do anything.

I’m not really sure why this is the default account. It’s like your Linux box would log you in as root by default. But fair enough, if that’s the Vista way, that’s the Vista way. I went ahead and created a normal account for myself and logged into that account instead.

Everything was well until I restarted my Vista machine the next time. I found myself right back in the administrator account. Apparently Vista insists that Administrator is the right account to be in.

To make a long story short, it took me just about forever to figure out how to make Vista not log me in automatically this way. I’m going to post it here to help other people with the same problem.

1. Pull up the Run… menu (Windows + R on the keyboard)
2. Enter “netplwiz” and click “Ok”.
3. Check the “Users must enter a user name and password to use this computer” checkbox.

Hope that helps someone. It’s hard to find for sure. You can also check the box, and then click on another account name in the list, thus selecting it. Then uncheck the box again and you’ll be asked for the password for that account – now the selected account is your new default account. If you make this a non administrator account you should have increased your security a little bit during day to day computer use.

           

If you get the following error when you’re trying to ‘make world’ for a jail in FreeBSD,

can’t cd to /usr/src/tools/build/make_check

the problem is simply that you’ve forgotten to run cvsup to download the sources.

I’m posting it here so that in case someone else has this problem they won’t waste 20 minutes wondering what’s wrong and Googling fruitlessly like I did. :)

Agency Byte has a good article up about scope creep. Scope creep is the unfortunate tendency where project scopes tend to balloon up during a contracting job. Most clients don’t know what they want exactly, but they’ll be sure to tell you during your work. And they’ll expect you to add these new things that were obviously needed without any additional payment.

Personally I believe that an agile development method is a good way to counter scope creep. When you deliver small incremental improvements frequently there will be fever surprises for the customer and many more chances to make adjustments. In fact this might be one of the most important features of agile development. Of course you still need a clearly defined scope or your project may never end.

So for that agile scope, or if agile isn’t your thing at all, Agency Byte has plenty of advice for you. Here’s a good one:

“Defining what is “out of scope” can be as important as defining what is in, especially because you probably already know the areas in which clients usually tend to push the limits. Write them down and include them in your proposal.”

Read all of the tips from Agency Byte’s here.

In the past I have used MoinMoin Wiki for my wiki needs, with great success . MoinMoin Wiki is very easy to set up and doesn’t have all too fancy requirements on the server side. The other day I was setting up a new wiki, and unlike my previous wiki projects this one would be facing the public. In order to get the syntax, template system and features most people recognize I went with the famous, Wikipedia powering MediaWiki software instead.

MediaWiki requires much more manual work to install than MoinMoin Wiki. Unfortunately, I was unable to find a comprehensive guide detailing how to go from scratch to fully operational wiki. There is the Installation Guide which details the basic server setup. It then redirects you to two pages: one on configuration and one on administration. Most of these documents are fine but at the time of this writing the ‘configuration’ document is fairly empty and I was left wondering about many configuration options. Hence this guide which will try to tie together all the things you need in order to get up and running.

To keep things moving this guide will be written at a fairly advanced level. If you don’t feel comfortable installing server side software you may want to check out some of our other How To’s for inspiration.

These instructions are suitable for FreeBSD 5.3-RELEASE-p37 and MediaWiki 1.9.3, although you will probably find it useful regardless of the platform and MediaWiki version you use.

Basic Installation

This part is covered very well by the Installation page of MediaWiki. Here’s the super condensed FreeBSD take on installation:

To install MediaWiki in FreeBSD,

# cd /usr/ports/www/mediawiki
# make install

This will install MediaWiki into /usr/local/www/mediawiki/, by default. You will probably want to copy this installation to some other folder since MediaWiki changes files in its installation folder during use.

# cp -Rf /usr/local/www/mediawiki /www/mywiki

Then,

1. Make sure the config folder is writable by the httpd user (www usually).
2. Set up your web server to serve pages from the location.
3. Surf to your new wiki. You will be prompted to go through an installation procedure. This part is very straight forward.
4. Move config/LocalSettings.php to the root of the wiki installation. You can now delete the config folder.

Now that was the easy part. Here comes the stuff that took a little bit longer to figure out. Thanks to Playing With Wire you’ll be able to do it in minutes! :)

Additional Manual Configuration

The installer does some things but not everything. While many online applications such as WordPress come with fancy online configuration tools, MediaWiki uses more traditional configuration files which you’ll be editing by hand.

Here’s what you’ll need to do:

1. Copy AdminSettings.sample to AdminSettings.php in the base folder. Edit the new file. The config file requires you to configure a database account for maintenance scripts. Presumably you may use the same account you used for the wiki, although I didn’t run any of the maintenance scripts yet to test this.
2. Edit LocalSettings.php. This file has been created for you by the installer, so it will contain some good defaults.

LocalSettings.php is the primary configuration file of your new wiki. This file contains the actual basic settings for MediaWiki, and it overrides the defaults found in includes/DefaultSettings.php. You shouldn’t edit DefaultSettings.php directly, but it should be your first stop if you’re wondering what variables you can put in LocalSettings.php.

Linking up the Help Pages

By default MediaWiki ships without help pages. Unless you want to write them yourself you have a couple of options. The option I chose is to simply copy all Help sections from the primary MediaWiki site – they’re released into the public domain. Follow the instructions on Help:Copying to do this.

You may wish to export the following pages:

Help:Contents
Help:Navigation
Help:Searching
Help:Tracking_changes
Help:Editing_pages
Help:Starting_a_new_page
Help:Formatting
Help:Links
Help:Categories
Help:Images
Help:Templates
Help:Tables
Help:Variables
Help:Managing_files
Help:Preferences
Help:Skins
Help:Namespaces
Help:Interwiki_linking
Help:Special pages
Template:PD_Help_Page
Template:Meta
Template:Admin_tip
Template:Prettytable
Template:Hl2
Template:Hl3
Template:Thankyou
Image:Example.jpg
Image:Geographylogo.png
Help:Editing
Image:PD-icon.svg

This is the same list as found on the Help:Copying page at the time of this writing, with the addition of the two last entries.

Notice that Template:Languages isn’t included in this list, although it is referenced from Template:PD_Help_Page. You may wish to edit the PD Help Page template and remove the {{Languages}} part towards the end to get rid of this dependency.

You will have to download and upload the images separately by clicking them and finding their respective file downloads. Upload the images using the normal ‘Upload file’ link from your wiki. The .svg image probably won’t upload by default. We’ll tackle the SVG format later.

Nice URLs

At this point the installer script has probably given you URLs that look like,

http://www.yourdomain.com/index.php/My_Page

(Unless your PHP runs as a CGI script in which case things might even look worse. Don’t run as CGI.)

To make your URLs more readable, you’ll need to configure both your web server and MediaWiki to cooperate. Here’s a good resource: Using a very short URL.

Basically you will want to edit your httpd.conf, if you can do that, or an appropriate .htaccess file, if you have to. Remember that a .htaccess file is slower than httpd.conf. If you can use httpd.conf, do that and disable .htaccess support.

Here’s how to set things up within Apache’s httpd.conf. Edit your Directory entry to resemble the following:

<Directory /www/mysite.com/>
        Options Includes FollowSymLinks

        AllowOverride None

        RewriteEngine On
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^(.+)$ /index.php?title=$1 [L,QSA]

Notice the AllowOverride None line. This is the part that turns off .htaccess support. It’ll give you a bit of a speed boost since your web server won’t have to look for a .htaccess file for every request made.

Next, add this line to LocalSettings.php:

$wgArticlePath = "$wgScriptPath/$1";

Change the Wiki Theme or Looks

MediaWiki’s term for themes is ‘skins’. The default skin looks exactly like Wikipedia, so you may want to change this if you’re looking to achieve a spiffy unique look for your public wiki.

To find out what skins came with your MediaWiki installation, look in your skins/ folder. You will see something like,

# ls skins 
Chick.deps.php          Nostalgia.php           common
Chick.php               Simple.deps.php         disabled
CologneBlue.php         Simple.php              htmldump
MonoBook.deps.php       Skin.sample             monobook
MonoBook.php            SkinPHPTal.sample       myskin
MySkin.deps.php         Standard.php            simple
MySkin.php              chick

From this list you can infer the list of available skins. In this case it looks like we have Chick, CologneBlue, MonoBook, MySkin, Nostalgia, Simple and Standard. The folder names (the lower case names) are the skin names.

To make the change, edit your LocalSettings.php file again and alter the line that reads,

$wgDefaultSkin = ...

In our case we might put,

$wgDefaultSkin = 'cologneblue';

If you make a mistake setting the property you will get a default skin.

You can find more skins here. Each skin is accompanied by instructions for how to set it up. Normally this involves downloading a zip file and unzipping it into the skins/ folder. You may also have to edit theme files to set up proper paths.

Changing User Access Levels

If you want to disable anonymous editing, you can add something like the following to LocalSettings.php:

$wgGroupPermissions['*'    ]['createaccount']   = true; 
$wgGroupPermissions['*'    ]['read']            = true;
$wgGroupPermissions['*'    ]['edit']            = false;
$wgGroupPermissions['*'    ]['createpage']      = false;
$wgGroupPermissions['*'    ]['createtalk']      = true;

For other possible settings, take a look at the defaults provided in includes/DefaultSettings.php. Again, remember not to edit the defaults file: just copy the lines you want to change to LocalSettings.php and make your changes there.

Support for SVG images

The SVG image file format is very useful but turned off by default in MediaWiki. Look in include/DefaultSettings.php and locate the SVG related stuff. For my installation this is what I had to add to LocalSettings.php:

$wgSVGConverter = 'inkscape';
$wgSVGConverterPath = '';
$wgSVGMaxSize = 1024;
$wgMaxImageArea = 1.25e7;
$wgThumbnailEpoch = '20030516000000';
$wgIgnoreImageErrors = false;
$wgGenerateThumbnailOnParse = true;

$wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'svg' );

You will also need to install inkscape. There are options to use rsvg, ImageMagick and others instead but none of those options worked for me. Rsvg and ImageMagick didn’t render gradients right, and I was unable to install the other alternatives on FreeBSD without crashes or other problems. This is unfortunate because inkscape is positively enormous if you also consider all the pre-requirements that you normally wouldn’t have to install on a server. It is the one program that does things right though and SVG is a really nice format to have support for.

Conclusion

That’s it. You are all set. Your next steps will probably be to create your own account and then use the Sysop account to turn your own account into an admin account. Happy writing!

           

Spotplex is a new service that launched a few days ago. It is squarely positioned to be a kind of digg competitor. The spin is that instead of working with user voting, they let people vote with their feet. If a lot of people view a certain article in a day, then that article is deemed ‘popular.’ Simply put, popular articles end up on their front page precisely because they’re popular.

While there isn’t much material on the site detailing their intentions, the idea is presumably that the visitor count method will prevent rigging the game as what may happen with digg. (Kevin Rose and the digg team is fiercely fighting cheaters though.) On digg, supposedly people sell their vote, or work together in teams to promote certain articles to the front page. On Spotplex this is meant to be more difficult. On digg it may be sufficient to get 40 willing people with digg accounts to end up the front page. But to do the same thing on Spotplex, you would need to get thousands of people with unique IP addresses to surf to your page.

There will probably be some way to trick Spotplex too – someone with access to a lot of zombie computers could do it perhaps. But in general it should be harder. Spotplex has a lot more data to go on – they can check IP numbers, referrer addresses, browsers and so on and look for patterns among the thousands of views an article needs to get on the front page. They should be able to prevent at least all basic forms of cheating with much less effort than digg.

Another distinguishing characteristic of Spotplex is that they use AJAX like there’s no tomorrow. The front page is nothing but a frame with little windows and the javascript necessary to fill those windows with dynamically sourced data. The first thing you see when you come to the front page is in fact nothing of interest at all. Instead there will be three major panes which all have a subtle little ‘loading’ tag in the background.

Spotplex doing its thing: ‘Loading…’

Apparently this dynamic design is putting quite a strain on the servers Spotplex invested in initially. Although not a very scientific test, we’ve been checking in on the front page of Spotplex once in a while for the last couple of days and we have usually been greeted only with lots of spinning ‘please wait’ indicators. Most of the time these last for several long seconds and that’s after the actual page took a few seconds to load too. The site feels tired just loading the front page.

Unfortunately Spotplex seems to be having more trouble than that. When Playing With Wire was invited to join the first 1,000 blogs to be on Spotplex, we received an invitation code. That invitation code could be used on the Spotplex page to get a code number. Supposedly the same page was to provide HTML code meant to go on the actual blog pages, but there was some kind of issue and we didn’t get any. No matter, we contacted Spotplex support who gave us the code promptly. Next, we inserted the code on our pages – you might have noticed the Spotplex image in the side bar.

This seemed to work well initially, and the page for our code started registering both a little bit of our page views and what articles were currently popular. Alas, about two days into the test Spotplex ceased to count our views and our number of views for the last 24 hours steadily declined to 0 on the Spotplex site.

At the time of this writing the Spotplex front page is loading as slow as ever, the Spotplex ‘get the code for your blog’ page is still not producing any actual code, and a search for “www.playingwithwire.com” on Spotplex returns no results. So apparently Spotplex is still struggling with the basics of their service. They will need get on top of this quickly, because the greater problem demands attention: can they really prevent people from generating fake ‘views’ for their blogs? Before they can compete with digg at all, they will have to prove that spam won’t rule their front page.

Update 1: We contacted Spotplex and they let us know that they are working on a potential database problem affecting Playing With Wire.