While building a new website for a small ISV, I was asked to integrate a forum – should be simple I thought, I’ll just use WordPress as a CMS and bbPress. Simple? Not quite.
To make things easier, I used Platform Pro by Pagelines (a great platform IMHO) and so used their “deep integration” instructions (while they are intended for Platform Pro users, the steps are virtually identical for all other setups). While the setup went quite smoothly, it wasn’t until it came time to test user registrations that the issue came up: when a new user tried to register they would receive an error stating that “email is required,” even if they had entered a valid email address. This effectively made it impossible for users to register, and thus made the forum useless.
After a bit of research, it looks like there is a conflict between newer versions of WordPress (3.0+) and bbPress 1.0.2 (I’m not sure if older versions have the same issue, but I would assume so). The fix for this is actually quite simple: install a plugin. The plugin itself is quite simple – containing only around a half-dozen executable lines of code, and works around the issue with a simple hack.
Unfortunately, the plugin description is rather vague and required a fair bit of research to identify as the fix, and the official documentation makes no reference to the issue or that this plugin can be used as a workaround.
Overall, a simple workaround but a major issue if you don’t notice that it’s broke (as is quite easy to do).
I recently had an idea for a small web application, and seeing as I’ve not spent as much time as I’ve wanted to using Rails – I opted to build it the latest version of Rails. A decision that caused far more grief than I expected.
If you are using Dreamhost’s PS offering (a managed VPS for those that don’t know), the seemingly simple task of getting a Rails 3 application up and running is actually quite complex. The root cause of this is that Dreamhost’s OS image is based on Debian etch, which was released in April 2009 and has since been replaced; which means etch has become fairly outdated.
Here’s the process I used, and so far it seems to be working quite well:
Domain Setup:
When adding your domain to the Dreamhost panel, you’ll want to enable Passenger.
Once your application is uploaded to the server, you’ll be greeted with a particularly unhelpful error message (something like “uninitialized constant Bundler“) from Passenger (or perhaps just a 500 error page).
Server Updates:
This is where the work starts, and gets somewhat ugly. As a warning, it’s quite possible that you could damage your configuration doing this; though thankfully you can restore your server to a working state within a few minutes from the Dreamhost panel should something go wrong. You’ll also need to have an “admin user” for this task, as much of what needs to be done has to be done as root.
First step: Get your PS up to date; even after performing a restore on my server, there were a number of updates that are available to be installed. So let’s start off by getting those out of the way.
sudo apt-get update sudo apt-get upgrade sudo apt-get -f install
Once you get past those three commands, the next step is to update SQLite to the latest version, as the version Dreamhost uses is quite old and won’t work with Rails 3.0 (well, to be accurate it won’t work with the latest version of sqlite3-ruby, which is the default database provider for Rails 3).
wget http://www.sqlite.org/sqlite-autoconf-3070400.tar.gz tar zxvf sqlite-autoconf-3070400.tar.gz cd sqlite-autoconf-3070400 sudo ./configure --bindir=/usr/bin --libdir=/usr/lib sudo make sudo make install
If you don’t update SQLite you’ll get an error like this:
sudo gem install sqlite3 Building native extensions. This could take a while... ERROR: Error installing sqlite3: ERROR: Failed to build gem native extension. /usr/bin/ruby1.8 extconf.rb checking for sqlite3.h... yes checking for sqlite3_libversion_number() in -lsqlite3... yes checking for rb_proc_arity()... no checking for sqlite3_initialize()... no sqlite3-ruby only supports sqlite3 versions 3.6.16+, please upgrade! *** extconf.rb failed ***
or if you install the updated version, but don’t force it to /usr/lib you’ll get an error like this:
sudo gem install sqlite3 Building native extensions. This could take a while... ERROR: Error installing sqlite3: ERROR: Failed to build gem native extension. /usr/bin/ruby1.8 extconf.rb checking for sqlite3.h... yes checking for sqlite3_libversion_number() in -lsqlite3... no sqlite3 is missing. Try 'port install sqlite3 +universal' or 'yum install sqlite3-devel' *** extconf.rb failed ***
Once that is taken care of SQLite, the rest is easy.
sudo gem update
At this point if you visit your new Rails site, it should be working!
Notes:
- I’ve not tested this extensively, and I’ve no idea if this breaks anything. All I can say for certain, if that all of my sites still work, but your mileage may vary. <Disclaimer />
- I was a fairly early Dreamhost PS adopter, and part way through this process I reset my server to get it back to a clean state. After resetting, I noticed some differences with the behavior of
apt-get(404s onupdateandupgradeare gone), so for other early adopters it may be necessary to perform a reset to get your servers configuration in-sync with the latest official setup. - I can’t say for a fact that this is completely necessary, though you’ll likely need to selectively update a few packages if you skip this step. Also, for me,
gemwas broken until I ransudo apt-get -f install. - Special thanks to Matt for helping me get this working; troubleshooting the SQLite install was more than a little time consuming.
While performing some testing on a Windows 7 Professional workstation running a VL build from MSDN found that a feature I needed was missing – the new Multi-Monitor RDP support. After a little research I found that only the Ultimate and Enterprise editions support this feature; which thanks to Windows 7′s Anytime Upgrade feature I assumed this would be no issue.
But, it was an issue.
It turns out that the build of Windows 7 I was using was missing WindowsAnytimeUpgradeUI.exe and the other related files needed to make the Anytime Upgrade work – and copying the files from another box doesn’t work. It seems this build simply can’t be upgraded in this fashion. So I tried a few other tricks, hoping to find something that would work:
- Reactivate Windows with an Ultimate key; fails with an error indicating that a Professional key is required.
- Run Ultimate edition installer from Windows; fails with this error indicating that you can’t perform edition upgrades.
So being stubborn and determined not to re-install Windows to make this feature work, I started looking for other options. Thanks to a hack for upgrading the RC builds to Final, I found what I needed.
I edited the EditionID and ProductName to reflect Ultimate instead of Professional, rebooted, and then ran the Ultimate installer from within Windows. This time the installer ran without issue and after an hour and a couple reboots it was done. This in-place upgrade/repair procedure allows you to jump to a different edition with fairly little pain. A couple of Windows settings needed to be corrected (primarily display related) and Visual Studio 2010 had to be re-installed, though otherwise everything worked just as it did before.
This is the only method for upgrading these Windows 7 builds that I’ve found, the only other option is to re-install Windows from scratch.
Setting up the Android SDK on Windows 7 64bit, with a 64bit JDK / JRE is a bit less straightforward than one would expect, thankfully though the solution is quite simple. There are two settings that need to be adjusted to make this work – otherwise you’ll get an error indicating that Java can’t be found.
Step 1: Modify your PATH to include the bin folder of the JRE. Mine looks like this:
C:\Program Files\Java\jre6\bin
Step 2: Set the ANDROID_SWT variable (you’ll probably need to add it) to the \tools\lib\x86_64 folder of the Android SDK. Mine looks like this:
C:\Android\SDK\tools\lib\x86_64
With these two changes, everything seems to work as expected. Why this is required on 64bit but not 32bit I’m not sure, but this does seem to solve the problem.
Do you use MD5 or SHA1 to store passwords? Think they are secure? Think again.
While generic hashing algorithms are certainly better than storing passwords in plain text, it’s still not as secure as it should be. Users place great trust in us to ensure that their credentials will be secure and treated with the utmost respect; it’s our responsibility to live up to these expectations.
With the simplicity and speed of these general purpose algorithms, it’s possible to generate hashes looking for collisions (or even the original value) extremely quickly. It’s this speed that introduces the fatal flaw; with a database dump containing MD5 hashed passwords, with a fairly small investment most could be recovered within a very small amount of time (mere days for a large database).
Many people are moving to bcrypt as a solution. In Coda Hale’s “How To Safely Store A Password” he covers this topic in more detail, complete with useful stats and links to implementations in languages from C# to Ruby (even Erlang is represented).
If you are looking for ways to better protect your user’s data, take a closer look at your password storage.
When you move on to your next challenge how will those that inherit your code think of you? Noble or notorious, innovator or insane? This is a question that all developers should ask themselves frequently; though too few ever do. You should always write with the assumption that someday a new developer will take over your code, and they will question every decision and assumption you’ve made. When this happens, what will they think of you?
Perhaps I’m more aware of this because I maintain an internally developed shared library that my company uses in every application; but regardless of the scope of the project you should always assume that someday you will hand the project off. Many developers think little about what happens to their code after it passes on to another; what other developers will have to deal with, or how their efforts will be perceived.
When I’m training a new developer there are a few points I try to reinforce as much as possible:
- Code is only good if other developers can work on it without extensive training. If it takes days or weeks of introduction to get a new developer up to speed, then you’ve done something wrong1.
- Clever solutions are no better than an ugly hack if it’s not clear what you are doing. If the code isn’t clear then it’s not maintainable, if it’s not maintainable then it’s junk.
- Assume you’ll be hit by a bus. Always write code with the assumption that you won’t have the opportunity to cleanly pass the code off to a new maintainer. Never assume that you’ll have time to come back and clean things up later.
- Always perform design reviews, no matter the size of the project2. Once you have a design in mind, talk it through with a at least two other developers. Just because you think it’s clean and clear doesn’t mean that others will see it that way as well.
- Be consistent, always. I’ve seen more projects ruined by people doing things “their way” than anything else. Match style and design when working on an existing project. Be careful when adding new techniques, technologies, or methodologies to an existing project; unless you are willing to update the entire code-base, you can easily create a minefield without realizing it.
If you want your work to be seen positively after you move on, start thinking about your heirs today. The opinion they have of you will be almost entirely based on what they see in your code – not the stories or memories left behind.
1 – There are always exceptions; these are generalized guidelines, not hard and fast rules.
2 – This includes “throw away” projects, many projects that are intended to have a short life end up living far longer than intended. This is the most likely place that your heirs will find code that makes them question the quality of your work.
