Instead, you should do something similar to what Geoffrey Grosenbach suggests in Rails Code Review — BTW, we translated that PDF in Italian: have a YAML file in your config directory where you store all of the settings for your app grouped by environment.

I said you should do something similar, because what Geoffrey suggests is just a starting point and that solution can be made a tad more elegant.
Which is what our new plugin is about!

ConfigurationManager allows you to have a single YAML file where you can store all of your settings, then setup a single constant which can be used all over your app by doing something like ConstantName.setting_name; or even ConstantName.group_of_settings.setting_name.

The YAML file should be placed in config/configuration_manager.yml and it should contain your settings like this:

everyone: &every_env
  key1: value1
  inner_hash:
    key2: value2

development: &non_production_env
  <<: *every_env
  key3: value3

test:
  <<: *non_production_env

production:
  <<: *every_env
  key4: value4

Then in your environment.rb you put the following:

MyConfig = ConfigurationManager.new_manager

Which will allow you to access your settings wherever you need them:

MyConfig.inner_hash.key2 #=> value2
MyConfig.key4 #=> value4
etc...

I hope you get the idea…it should make sense. :)

Development of the plugin is on Github, but you can install it from our usual Google Code repository:

script/plugin install http://wonsys.googlecode.com/svn/plugins/configuration_manager/

If you find any bugs, please let us know using our bug tracker.

It’s been a long a time since our last post, but in the past few months we’ve been incredibly busy working on a few projects: both for ourselves and for our clients.
Of course, we love being busy and don’t complain about it, but we had to put the blog on hold.

However, the idea right now is to get back to it and find the time to write more often, alternating longer and more insightful posts with short-and-to-the-point ones.

Let’s see if we can keep this beast alive! ;)

16bugs was introduced almost two years ago and we felt the need to rewrite it from scratch to include all the valuable feedback you have been sending our way.

We released the first part of the upgrade, with a few more features coming in the next weeks.

This upgrade includes:

• Custom member groups inside each company (no more Project Manager, Developer and Beta Testers)
• Per-project permissions for each single member of the company
• Project activity to always be on top of what’s happening
• Improved syndication feeds and email notifications
• Watch single projects/bugs via email
• Ability to pay in advance for more than one month
• Bug IDs limited to company
• Increased upload size (because 1MB wasn’t enough) and no more limits on which files you can upload
• Refined UI and lots of small tweaks

This new version shouldn’t break anything — knocking on wood — except for one small thing: we greatly improved feeds for companies and single projects and we had to break compatibility with the old feeds. Refresh your feeds and you should find instructions on how to subscribe to the new feeds. We’re very sorry for this inconvenience, but we’re sure it will benefit everyone.

To celebrate this release with you, use coupon code newbugs to get 50% off when upgrading or extending your subscription for up to 1 year.

Please, let us know if you notice anything strange by sending an email or submitting a bug.

Pixménage allows photographers to manage their digital — or digital-ized, as I prefer them ;) — photos with ease.
You can create an online portfolio and share photos with clients and colleagues, or even family.
It’s a great archiving tool, as it allows you to tag photos, put them in albums, crop and rotate them, and all sort of useful stuff.

It was built with professional photographers in mind, so it supports basically all kind of RAW files, it can import/export from FTP, it allows for collaborative work on photo selections with clients, etc.

No wonder working with huge 250MB RAW files wasn’t as easy as pie: while in development mode, it’s no biggie, because you know you’re processing only one photo at a time, but we had to develop it as if there were hundreds of users uploading photos at the same time, so we built a very simple, yet extremely powerful queuing mechanism which allows us to asynchronously process photos while leaving the users free to do whatever they want. And should we need more power, we can simply drop one more server in the processing cloud.
We tried to work with stuff like Backgroundrb, but they didn’t live up to expectations, so we had to opt for the custom tailored solution — which in the end, is the best choice, at least most of the times.
In the future we might give EC2 a try, also considering we’re using S3 for storing photos, but right now we’re very happy with our own stack.

Give it a try and let us know what you think.
We’re constantly improving it, so we’re very open to feedback.

As promised yesterday, here we are with another announcement: today, we’re launching a new website: Music Milker.

Music Milker is a blog about music where we will post a new song from an up and coming artist everyday.
Every week, we will have the artist of the week, with an interview with the artist and, hopefully, some sort of give away — we’re starting with Topher Mohr, who’s been very kind and provided a free song for everyone to download.

Every now and then we’ll throw in a song from the past, just to make sure you don’t forget songs that made a difference in the history of music.
Still, most of the songs will be from new artists, indeed, we believe there’s a lot of untapped potential around the Web, so we’ll try to spread the word about it.

I suggest you add it to your feed reader and see what comes through it.

We were in charge of the development of the platform — the design was given to us and we only had to make a few UX changes –, which, of course, is built on top of our beloved Ruby on Rails.
There’s a bit of MySQL trickery here and there — especially for shows matching between users and full-text search –, but most of it is pure Ruby.

With every new project we learn something new, and this one was not different: we had a lot of custom SQL queries, joins, and queries that couldn’t be trimmed down using eager loading, still, we couldn’t allow for slow pages with tens of queries.
Luckily enough, there’s a lot you can do to improve your apps with clever usage of Ruby/Rails and MySQL.
Remember, ActiveRecord is nice and good for most situations, but at times you must get your hands dirty and work directly on the DB if you want your site to perform properly.

Make sure you give Episode39 a spin if you can understand Italian and let us know what you think about it.

Stay tuned for a couple more announcements during the next few days!

A lot of smart people are talking and I’m sure it’ll be a great conference.
We’re organizing a Web development panel on the second day, so make sure you stop by if you can.

If anyone is coming, we’ll be very happy to meet you there and have a little chat.

See you in Pisa! :)

In the past, we fixed this behaviour by adding the email to a queue in the DB which was then processed by a cron script every few minutes.
Sure, it worked, but what about using Sendmail’s own queue to achieve the same result? What if Rails could simply pass the email to Sendmail and then get back to work?

Here’s an easy way to achieve this.
Add the following to your config/environments/production.rb:

config.action_mailer.sendmail_settings = 
    {:arguments => "-i -t -O DeliveryMode='b'"}

Pros&cons: using the DB queue will allow for easier error handling, but then emails will be delayed by a few minutes depending on you cron settings. Using Sendmail’s queue allows for instant email delivery, but makes error handling a tad harder.
I think going the Sendmail route is the right decision for most projects. You choose. :)

We’ve never been really happy with what was available to perform full-text searches in Rails.
We tried a whole bunch of different plugins — most notably acts_as_ferret and acts_as_sphinx –, but none seemed to work as expected.

Ferret is great, but we couldn’t determine why it was throwing all kinds of indexing errors at us.
After a short investigation, we supposed Ferret — or more probably acts_as_ferret — couldn’t cope with the high number of writes in our system.
So we decided to move to Sphinx and while it seemed to be working fine for a while, it suddenly started behaving strangely: the daemon was running, but the plugin couldn’t connect to it, then it stopped updating the index and so on.

I’m sure we could’ve find the culprits for all of those issues, but in the end we hadn’t got the time to do it.
That’s why we decided to move to MySQL’s very own full-text search.

MySQL full-text support might be less powerful than Ferret’s, still, it should work for 80% of the times in which full-text search is needed.
We only had two issues with it:

1. Indexing only works for MyISAM tables
2. We didn’t want to have a separate index for all of the different tables we had to search into, since most of the times we would have to search in all of them at once

The fix was kinda easy: we would use a dedicated MyISAM table to perform searches.
The table needed to have a way to refer to the original objects, so we decided to opt for the same approach adopted by polymorphic associations: storing both id and type.
Then we had to store the data and, given we didn’t need to give different weights to different fields, we decided to store all of the data in a single field, actually merging different fields into one.

So, a few hours — and coffees — later we had a working plugin that updates the searchable table after each save is made and performs fast and reliable searches.
Of course, the plugin is available for your own searching pleasure. Just keep in mind it doesn’t allow for the sort of flexibility you might have using something like Ferret, however, it should be just perfect if all you need is to perform basic searches on a few tables.

Keep in mind we only spent a few hours on it and it definitely needs some more love — tests, I’m looking at you –, but it works, and we’re currently using it.
Should you have any issues, please submit a bug report or send an email to info at wonsys dot net.

You can install the plugin by following the steps above:

1. Install the plugin:
   script/plugin install http://wonsys.googlecode.com/svn/plugins/acts_as_fulltextable/

2. Add the following code to the model that should be included in searches:
   acts_as_fulltextable :fields, :to, :include, :in, :index

3. Create the migration:
   script/generate fulltext_rows model1 model2 model3 ...
   Then execute it:
   rake db:migrate

To perform searches you can:

1. run a search on a single model:
   Model.find_fulltext('query to run', :limit => 10, :offset => 0)
2. run it on more models at once:
   FulltextRow.search('query to run', :only => [:only, :this, :models], :limit => 10, :offset => 0)

Unilife was our first project as a company and not just as a bunch of friends, indeed, it was the very reason for incorporating Wonsys in the first place.
It was always meant to be a starting point, something from which to grow, and it served this purpose incredibly well.

Thanks to Unilife, we grew a lot as people and as a business, not financially maybe, but it allowed us to understand a lot of the nitty-gritty, meet a lot of people and basically learn how things go.

Happy birthday Unilife! And thanks to everyone who has helped during the past 12 months.

P.S.
If you’re registered on Unilife, log in to know everything about the party we’re having this Friday to celebrate Unilife’s first birthday.