March 2008 Archives

So you have decided to add full-text searching to your Ruby on Rails application. After some investigation (see here and here) Sphinx with the Ultrasphinx plugin looks like the best solution for your needs. Just one problem, despite your deployment environment being Linux, for various reasons your current development environment is Windows. While Sphinx runs on Windows, it explicitly states it prefers to run on other systems and there are a few little gotchas. Here is the step by step guide to getting it working:

1.       Download the Windows binaries rather than the source code.

2.     Extract the contents of the bin/release folder in the zip file you just downloaded into a location of your choice (eg. C:\Sphinx).

3.       Add the location of the folder in step 2 into your system path.

4.       Install chronic - gem install chronic

5.       Install Ultrasphinx - 'svn export svn://rubyforge.org/var/svn/fauna/ultrasphinx/trunk vendor/plugins/ultrasphinx'

6.       Copy the example default.base to the app config folder and edit it. The path variable is the path to the location of the index (created in step 10), not the Sphinx binaries. Also, find the "set_rotate" option and set it to 0. This is not supported on Windows at the time of writing. You probably want to have this set differently in production.

7.       Run rake ultrasphinx:configure  You should now have a Sphinx conf file.

8.       Add indexing to your model.

9. Edit the Ultrasphinx.rake (in plugins/ultrasphinx/tasks) and where you see '#{Ultrasphinx::CONF_PATH}' remove the apostrophes, otherwise the rake task below won't be able to find the configuration file.

10. Run rake ultrasphinx:index  You should now have an index in the location specified in the conf path.

11.   Run rake ultrasphinx:daemon:start  The sphinx daemon should start up.

You are done and should be able to search. Good luck.

Update: In case you are not reading the comments, Naomi Novik has pointed out that
Sphinx/Ultrasphinx doesn't seem to want to work if the Rails project is in a directory with spaces in the path.

Update: Some people have had problems beyond those I mentioned above. Take a look at this and this if you have extra problems.

Design

| | Comments (0) | TrackBacks (0)

A recent Java Posse podcast discussed UI design and mentioned that some places like Apple take design very seriously, actually starting the development process by deciding what the finished product will visually look like. This has worked very well for Apple (I love my Apple stuff) and is probably a good way to go if your product's end users may not be technically oriented. Unfortunately I have no design skills (it is beginning to show in my project) and a key part of what I'm trying to develop is that is easy to use, mainly because it is not targeted at technical people.

 

I like to think of designs as a state-space (this itself is probably a bad start!). Imagine a mountain range, the higher the peak the better the design, so you want to stand at the highest point you can. Starting at any random place in the range, you can either climb the mountain you are on to the top or go down to climb a different taller mountain. It all depends on whether you can see a taller mountain nearby. For the purposes of this metaphor, I am nearly blind. Unless very lucky I will not end up very high. Much like most of the other software engineers I know!

 

Knowing these shortcomings, instead of a normal design process, I follow the "Break & Enter" school of design. That is I find something simple I like and largely copy it. That's fine for corporate websites or GUIs, but I'm not sure how well it will work with the general public. This is something I need to think about (comments welcome). At least it's a common problem. In the Java Posse podcast there were repeated questions around how to instil a design culture or hire for design skills - I don't remember there being a good answer.

Code

| | Comments (0) | TrackBacks (0)

After having the simple idea (see here) over the New Year holiday, I next needed to decide how to implement it. Many people would say I needed to write design/spec/use case documents first, but for this project I think best to start working and see what happens. It would be easy to draw diagrams and think about problems with nifty solutions. However, the main goal is to DELIVER. I want to get something up and running quickly, get some people to use it and then improve it. I believe the longer it takes to get something up in front of people, the more likely I never will reach that point or go further. Having people use the system (even as testers) is a form of commitment.


As a result I chose to use Ruby on Rails for development - something many people who know me may find surprising. I have never programmed in Ruby before, so I'm learning it at the same time as trying to quickly develop a new system with fuzzy requirements. What happened to avoiding development risks and not trying to do too much at once? If I did a project risk assessment like most of my previous employers this would raise some serious red flags - the project would not be allowed to go ahead. Although, no previous employer would allow my idea to go ahead anyway, they would see it as too small. So why did I make the Ruby decision?


For the last 6 years I have almost entirely developed in Java (and before that a mix of Java, C++ and other languages that will never appear on my resume). I have worked on developing a wide range of systems from the large (over 100 people for a few years) to the very small (just me for a couple of weeks), although mainly for large financial firms. However, I specifically did not want to develop in Java. I may be faster in Java, but there are a number of reasons I thought it best not use it this time. People say it can be heavier to develop, with more boilerplate code, and I can certainly understand that. There are also less decent internet hosting options for Java, nearly every hosting firm provides PHP or Ruby options, but finding a good Java host is harder. However, the main reason for me was that with Java I was liable to get bogged down in the intricacies of the language and various libraries or third party tools. With a new language I wouldn't have time to think further than the next problem I was facing and finding a solution for it - there would be fewer distractions simply because there wouldn't be time to lose focus or investigate interesting side issues.


Choosing the language was difficult. There were so many I wanted to try as I haven't properly taught myself new language since C# some years ago. I have been reading (with interest) blog posts arguing (flaming?) the pros and cons of various web development languages and frameworks. Ruby on Rails seems to have a large following and been around for a while. The basic idea has been copied so many times by other languages (Groovy on Rails, Rhino on Rails, ...) that I felt there must be something useful in there. I rejected all the derivatives because I didn't think they would be mature enough yet and didn't have a large enough community behind them. After all a framework with a backlash must have reached a certain level of maturity! The speed issue was my main concern. At work code execution speed is extremely important and has a direct affect on the bottom line (I work on financial trading systems). However, the performance requirements for my system are far less than at work. Ruby will probably be fast enough - or at least fast enough at the start to see if the idea is worth pursuing. So I decided to just give Ruby a try. If it didn't work out I could quickly move onto something else.


Anyway, I've been writing Ruby on Rails code for nearly the last two months in my spare time - probably only the equivalent of only a handful of workdays in total. Yet I am quite impressed by how much functionality I have implemented. I  am probably only a couple of weeks away from being ready for alpha testing on the functionality (the website design is still a mess). So far I have to say that Ruby on Rails has been a positive experience, although I am yet to properly test its performance.