Recently, my friend shared a link on Facebook about some dudes who’d made their own infinity table. While I don’t necessarily have the time or dedication to build an actual table, I was intrigued by the idea of running an LED string using a Raspberry Pi. And so, one impulse purchase and a few days of development later – I had built PiLight!
In short, PiLight is the software that I came up with to configure and run my lights. PiLight is a Django (Python web-framework) application, so naturally there’s a web-based interface for tweaking the settings. This is a nice solution, because it means that you can configure the lights from literally any device that has a web browser – your phone, tablet, computer, etc. You can read more about how to download and install PiLight on the project page, so this blog post will focus instead on my own end-to-end experience with setting up the Raspberry Pi and getting PiLight working. You can follow it as an informal (but very detailed) guide to doing something like this yourself.
Wow, updates to the blog have been few and far between lately!
Recently I have been exploring the creation of video as an extension to my photography work – you can see some of the fruits of my labour on my YouTube channel. These have given me the taste for basic video production, and I decided to combine coding and videography, to put together an open-ended series of screencasts about how to create an XNA game for Windows Phone.
If you have any interest in this topic, I would love for the readers of my blog to go and check it out and let me know what you think!
Here’s the first episode:
You can find all of the episodes I have produced to date in a playlist. I am aiming to put a new video together roughly once a week – so be sure to subscribe if you like what you see!
The next iteration of the core .NET languages (C#, VB.NET) looks set to have some pretty cool language constructs for performing tasks asynchronously in a really easy fashion. Designed to “let you have your cake and eat it to” – write code as you would for synchronous operations, and let the compiler take care of asynchronous callbacks and so on. Very cool! Check out the PDC talk from Anders Hejlsberg.
Update: I have been super busy lately, so haven’t had time to update this post. Some parts may no longer be relevant, as the project is moving pretty quickly. There is now a page on Diaspora’s GitHub Wiki that describes some additional workarounds for Windows, so check there if your problem isn’t solved here.
So today the Diaspora team finally released their source for developers. This post describes my efforts in getting Diaspora to run on Windows. It’s actually very straightforward (considering the readme has no mention of Windows!) – anyone with a small amount of technical knowledge should be able to successfully follow the steps below. I’ve included some fixes for common pitfalls. Please leave a comment if you are having trouble, or manage to find the solution to a problem you are having.
Warning: Diaspora is classified as pre-alpha software. You should not be ditching Facebook and moving your online social persona to Diaspora – at least, not yet. It’s full of documented security holes and bugs. You should only be installing it to have a play with it and get a feel for what the system is going to be like.
The project readme describes the prerequisites for the project, and gives a basic installation guide (for Ubuntu and MacOS X). You will need to install all of them:
- Git (TortoiseGit with msysgit – you need both)
- Ruby 1.8.7 (version is important!). I used the RubyInstaller Windows package. Make sure you specify that Ruby binaries be placed on your PATH.
- You will also need to install the Ruby DevKit from the same download page in order to build native gems. Comprehensive installation instructions are available for the development kit. I used 3.4.5, but later versions should be fine.
- OpenSSL (Win32 v1.0.0a precompiled binary)
- ImageMagick (6.6.4-2-Q16 Win32 DLL)
- Bundler (type “gem install bundler” at the command line)
You’ll need to make sure most things are on your path (especially your Ruby\bin directory).
Getting the source and dependencies
First, git clone the source into a sensible place using TortoiseGit. The repository URI is as follows:
Then, at a command line, browse to the repository and run the following command to install project dependencies:
If you encounter an error about a native build failing, make sure you have installed the DevKit properly.
If you encounter an error about bundler not being able to find its functions, you will need to modify one of bundler’s source files. Open up Ruby\lib\ruby\gems\1.8\gems\bundler-1.0.0\lib\bundler\lockfile_parser.rb and modify line 14 so it reads as follows:
lockfile.split(/\r?\n+/).each do |line|
Then run the bundle install command again. (Thanks Kristoffer!)
When the command succeeds, you should see a pretty substantial list of items install (in the order of 50 or so). The Diaspora team certainly know how to reuse existing solutions!
There is an official guide to installing Mongo on Windows, and running it as a Windows service, so I won’t go into that here. Just make sure that it is running before continuing (preferably as a service). Then, run the following at the command line from the repository directory to start the development server:
bundle exec thin start
You might encounter an error that looks like the following:
rbreadline.rb:4404: uninitialized constant RbReadline::Encoding (NameError)
A quick search turned up a blog post that described commenting out the affected line, which seemed to work for me. Just open Ruby\lib\ruby\site_ruby\1.8\rbreadline.rb in Notepad or similar, and comment out line 4404. This shouldn’t break anything significant. (It might affect you if you are doing some development and need to use the test suite – otherwise shouldn’t make a difference if you’re just running Diaspora to have a play).
Run the bundle exec thin start command to start the server once more, and you should see something similar to the following:
>> Using rack adapter >> Thin web server (v1.2.7 codename No Hup) >> Maximum connections set to 1024 >> Listening on 0.0.0.0:3000, CTRL+C to stop
Opening localhost:3000 in my web browser, I am then presented with the following:
Success! I should mention that this is of course just a development server. If you close the command window then the server stops running.
Getting access to your Diaspora node
Update: To register on your server, browse to /get_to_the_choppa. [This may no longer work, see next update]. It seems they haven’t yet built a proper registration page (or at least, you’re not supposed to be able to go to a random server and register). [Official signup page is now present]. Interestingly, that page worked for a short time on the developers’ own nodes – it seems they’ve since plugged the hole though.
Update 2: I assume the fact they’ve plugged the hole means it’s also plugged in the latest copy of the source. Here’s the “official” way to be able to log into Diaspora. [This way still works fine, but you may prefer to start from scratch – see next update]. From a command line in your repository, run the following commands:
gem install rake
bundle exec thin start
The rake command prepopulates some data, allowing you to then log in with username tom and password evankorth.
Update 3: It seems a Sign Up link has now been added to the login page (and /get_to_the_choppa redirects to this). You may want to use this to gain access instead of one of the above steps. I would recommend using the method above however, as it populates some images and a “friend” to play with.
Here’s what my running version of Diaspora looks like:
Although, as you can see, image resizing seems to be broken at the moment – perhaps a problem with my ImageMagick install. Other than that, seems to functioning ok. Of course, the “excitement factor” of testing the experience of a social platform by oneself is not particularly great!
Updating your Diaspora installation
Code updates are being pushed pretty thick and fast currently. To upgrade your Diaspora node, run the following commands at the command line in your repository directory:
This gets the latest version of the source code. You may need to run a git stash first if it complains about uncomitted changes.
This will update and install new dependencies. You may encounter an error about a native build failing. To temporarily add DevKit to your path to allow building, first run devkitvars.bat from the extracted DevKit directory, then try running bundle install again.
This compiles code and runs the test suite. Don’t worry too much about failed tests! You can also optionally nuke your database to start fresh again by running:
mongo diaspora-development > db.dropDatabase()
Note that this requires MongoDB to be on your PATH. Finally, run the server again:
bundle exec thin start
Sometimes bugs really astound me. The current tom.net.nz theme has been active for at least 6 months. When I first developed the theme, it was in Firefox, and looked great. But then I started using Chrome and noticed the following:
That is, sidebar text that looked fine in Firefox was now weirdly spaced out in Chrome, and some elements (e.g. Archive date links) that were meant to be plain text now had Cufon styling.
For the longest time (well ok, maybe ~2 hours – still, a long time for such a minor annoyance), I searched my code, and tried out many different things in order to find a fix. I tried changing the Cufon selector (bypassing jQuery, for example), getting deep into the WordPress API to modify the output of the archive date list, messing with CSS, upgrading Cufon/jQuery, etc etc etc. Nothing I tried gave satisfactory results. Eventually I just gave up, and chalked it up as a behaviour oddity of jQuery selectors or Cufon, or something (I just knew it was nothing to do with me – how could it be, after putting so much time into it, right?!).
So today I was preparing to describe this oddity to someone as being a concrete example of weird JS in Chrome, and I happened to find this in part of the source:
See the problem? I had fudged the closing h1 tag. So basically, the behaviour I was seeing was not a bug in any of the libraries I was using, but rather Chrome and Firefox choosing to treat my broken code differently. It was also a frustratingly simple fix to what I had assumed was a complex problem (and had spent considerable time trying to fix). Going back for a second look, I found the 6-month-old bug almost by accident, in the space of about 30 seconds.
So at long last, my sidebar works correctly in all major browsers. Hurray! I just wish I’d had the aptitude to run my HTML through a validator or check it fully by hand back when the problem first manifested… Hindsight, as always, is 20/20.
Monday, September 13th, 2010 | Posted in Code | Comments Off on Still finding bugs