:show action on create or update of a resource. Personally, I’d rather redirect to the :index action as long as the resource is valid.
You can overwrite ActiveAdmin’s default behavior using the controller block.
Notice, I’m adding “if resource.valid?” to make sure we only redirect when there are no validation errors. If we didn’t have that extra bit, the actions would always redirect to the :index action regardless.
There are gems available that will add a honeypot for you, but if you prefer to implement it yourself, it’s very straightforward.
In your form, just add an extra field that you’ll use to detect unauthorized submissions. Make sure to name it something normal so spam bots will populate it. I prefer to use the name “content”. Notice that the field has its tabindex attribute set to -1. This will prevent the field from being selected if a user tabs through the field. I’ve also added some inline hint text in case a user with a screen reader fills out the form.
In your stylesheet, just add some styles to make sure that a human won’t see the field on a desktop or mobile device.
The final step is to add a check in your controller to only process the form if the value of the field is blank. For me, I’m only sending a notification email if the form submission is certified anti-spam.
Here are my (admittedly contrived) models. You can see that a User belongs to an Account and an Account belongs to a Group. For this example, let’s say I want a filter in ActiveAdmin on the User resource that lists all the Groups.
Here’s my simplified ActiveAdmin resource, with the added filter.
To hook it up to the model, I just need to add a scope and a call to the built-in MetaSearch method search_methods.
RAND() function and have it return an identical list each time it’s called.
Since I want each person to get a uniquely randomized list of members, I set a cookie with a seed which is randomly generated (1-100).
I set the seed in a before_filter in my ApplicationController.
Notice, I only set the cookie if it doesn’t exist. I also set the expiration of the cookie to 15 minutes because I don’t want the user to get the same list of members all the time.
Now, in the MembersController, I can pass that seed to mySQL and get a repeatable sequence of random records.
A little while after I built the site, I decided to move it from a personal VPS to Heroku. To do that, I needed to convert the database to PostgreSQL (or pay for a mySQL option). After a little research, I found out that PostgreSQL is a bit trickier than mySQL when it comes to using a seed with the random() function. You have to run a separate select query to set the seed before the query that gets the list of records.
PostgreSQL’s setseed() function requires a number between -1 and 1, so we need to switch to a random float instead of an integer in the ApplicationController
There we go. A repeatable, randomized set of records in mySQL or PostgreSQL.
]]>If your tracking code looks like below, then you have the newer Analytics tracking code that uses the ga function instead of the _gaq array.
Add the following code to your router:
If your tracking code looks like this:
Add the following code to your router:
PhoneGap has File and FileTransfer plugins that allow you to access the device’s file system and even upload/download files. The problem with these plugin are, almost all of the actions trigger callbacks, so it’s hard to keep the thread of what is happening. The PhoneGap documentation for these plugins are slightly lacking, so it was difficult to figure out how to accomplish what I needed. Through a lot of Googling and trial & error, I was finally able to get the following code working.
Ok, we have the files downloaded, but how to we show them in our app. As far as I could find, you can’t refence images on the device’s filesystem form the PhoneGap app.
Luckily, the PhoneGap File plugin has a way to read files from the filesystem. It includes a method to read the file as a data url which converts it to a base64-encoded string.
My app was written using Backbone with Handlebars templates. So, to display the image, I wrote a Handlebars helper to get the image from the file system and return it as a base64-encoded string. You’ll notice that the helper actually gets an element via jQuery and sets it src attribute. I had to do it this way since all of the File plugin methods are asynchronous and handled with callback.
The helper can be called like so:
git checkout mastergit pull origin master (or fetch and merge)git checkout topic-branchgit rebase masterOnce you’re done with your topic branch, it might look something like this:
git checkout mastergit merge topic-branchgit push origin masterThat’s a lot of work, and as a developer we can definitely make that process easier. About 4 years ago, I came across a set of bash scripts that simplified this workflow greatly. The creator, Rein Henrichs, named them Hack && Ship.
These tools worked great, but weren’t flexible enough for me. They assumed that you would always be rebasing and pushing to the master branch. If this wasn’t the case, you had to do everything by hand.
Here are my updated versions of Hack && Ship that allow you to rebase and push to any branch (such as staging or qa):
To use them, create two files named hack and ship somewhere in your path (like /usr/local/bin maybe) and make them executable. Then, you can invoke them like so:
hack or hack staging
push or push qa
hack && ship
Make sure you have the gems for both db types you’ll be accessing.
This will connect to the database that you are copying structure/date from.
authusername and authpassword can be whatever you want. This will be used to authenticate when pulling from this db server.
Make sure the new database has been created.
Done!
]]>There are a ton of extra options you can use with the association matchers (pretty much any option you can pass to an association). Below are just a few.
There are even more options for use with the validation matchers. Here’s a small sampling (including some mass assignment matchers).
These are just a few of the extras that shoulda_matchers offers. I would highly recommend that you read through the documentation to discover all the things you can do.
]]>msyqld process died, and neither of us noticed it for almost 24 hours. That meant that the site was completely useless that entire time. Needless to say, the client wasn’t thrilled about this.
I told him that I’d look into setting up a monitoring service to, at the very least, notify me if msyqld ever crashed. During my research, I stumbled upon the god gem (which I’d used in the past to monitor mongrel processes back in the days before Passenger). I didn’t realize it could be used to monitor other processes as well, such as msyqld.
God is a rubygem, so it’s easy to install on any *nix operating system. It’s config files are also written in Ruby, so that makes it even better.
What you’ll need to get the script running:
Install the god gem (as root).
sudo gem install god
Find the location of your msyqld pid file.
mysqladmin -u root -p variables | grep pid_file
Determine the command to start/stop/restart the msyqld service. Usually /etc/init.d/mysqld
Here is the config file I wrote to watch my mysqld process:
A few things to note about my script:
mysqld restarted, but apache hadn’t. YMMV.sendmail, or you can exclude the email notifications altogether.-D flag. This runs god in non-daemonized mode so all output is piped to STDOUT. That way, you can watch what it’s doing to ensure everything is working correctly.For more information about the god gem, see their site: god.rubyforge.org
]]>The domain is already saved in the database, but I needed to tell the router to look for any incoming requests to a domain that doesn’t match my primary domain (in this example, we’ll say my primary domain is example.com). Thanks to Rails 3, I could just add a routing constraint (which can take a class as argument), like so
Notice that the root path is below the domain routes. This is important because it will get triggered before the domain routes otherwise (because routes are first come, first served). With these routes in place, it’s as easy as finding the user by domain when we get a request.
We added the Domain class as a constraints argument, now we need to add that file. You can add the following domain.rb to your lib folder and make sure it’s getting loaded on application boot.
It’s as easy as that. We just check to make sure the domain is present and that it doesn’t match our primary domain. This constraint will match any domain other than our primary domain.
As for server configuration, you have to tell your server to accept all incoming requests, regardless of domain. Below is a sample Apache virtualhost to accomplish this. Notice that we don’t specify a ServerName or ServerAlias, we want it to match everything.
IMPORTANT: You need to ensure that this virtualhost entry is loaded last. If you have any other virtualhosts that specify a ServerName, then they need to be loaded before this one. We’re using this entry as a catch-all to route to our rails app. If you have all of your virtualhosts in one file, just put this entry last. If each entry is in its own file, just make sure this file is loaded last (you might add a zzz_ to the start of the filename to make sure).
This file should live at config/deploy.rb.