Something I’ve held out on for a while now has been to switch over the settings for ActionMailer in
my application(s) to point to my hosted Google apps account. I figured it was probably time to do
so as piping email notifications through my comcast email account is generally, probably, a bad idea
(courtesy of the “No Duh” department).
Seems like it should be rather easy, no? Just change action mailer to resemble:
ActionMailer::Base.smtp_settings = {
:address => "smtp.gmail.com",
:port => 587,
:domain => "hosteddomain.com",
:authentication => :plain,
:user_name => "account@hosteddomain.com",
:password => "omgsup3rsecret"
}
Meh. Looks easy enough, right? Except for the fact Google’s got some magic TLS authentication thing
going on – you’ll run into an error in your mailers resembling Must issue a STARTTLS command
first.. Enough to make you work a little harder to get the magic working.
For those of you/us that are running Ruby 1.8.7 and Rails 2.3.x the answer is rather simple – add
:enable_starttls_auto => true to your smtp settings, which will result in :
ActionMailer::Base.smtp_settings = {
:enable_starttls_auto => true,
:address => "smtp.gmail.com",
:port => 587,
:domain => "hosteddomain.com",
:authentication => :plain,
:user_name => "account@hosteddomain.com",
:password => "omgsup3rsecret"
}
And for the rest of you/us (that would be me) that are still sticking with Ruby 1.8.6, there is an
answer in the form of the action_mailer_tls gem. Following the readme will get you to right
where you want to be – shoveling all the mail you would like into the ether that is the interwebs.
What a huge pain in the ass.
I just spent hours trying to get every combination of these two to work
together and nothing worked. A handful of versions of libmemcached had no
problems installing – .24, .25 and .26 were all easy to install, both from
source and from macports. However, getting the memcached gem to install proved
to be way way more difficult.I tried with a myriad of options – the most
promising piece of information looked to be from this gentleman’s website
– but also proved fruitless.The final solution, after a LOT of googling and
clicking around the rubygem forums – this post at Evan Weaver’s blog. The
libmemcached-0.25.14.tar.gz and memcached-0.13.gem tarball and gem,
respectively, installed easily without any problems. After downloading all I
had to run was:
tar -xzvf libmemcached-0.25.14.tar.gz
cd libmemcached-0.25.14
./configure && make && sudo make install
cd ..
sudo gem install memcached --no-rdoc --no-ri
Done. Finally.
Update: There seems to be a few issues with the gem I link
to being installed correctly in Snow Leopard. After spending too much time
trying to figure out why the gem wouldn’t install, I installed the current
memcached gem (from gemcutter) on a whim – and it compiled, and worked, without
a problem instantly. So, if you’re running Snow Leopard and looking to
install the memcached gem, try out the latest version first.One caveat – I’m
still using the memcached server I linked to above, version 0.25.14, still
from Evan Weaver’s site
#
Here’s something I lost hours to thanks to my own boneheaded mistake (I think I might have “lack of sleep” to blame for this one – in conjunction with ignorance).
I changed my Rails app to use memcached as the caching store for obvious reasons. Some sql queries are just too expensive so why keep hitting the damn db over and over again? Here comes memcached to the rescue! … or not?
I made all the appropriate changes, installed memcache-client, and restarted my local dev environment only to be hit with an ugly
session_id “whole lots of letters and numbers blarghedy blargh” is invalid
With the last file in the stacktrace being mem_cache_store.rb. “What the hell? Everything looks good though!”After uninstalling any and every plugin that I didn’t need thinking maybe they were interfering with the cache store – newrelic_rpm, query_reviewer and of course cache_fu – the problem remained. I reverted to regular built in filesystem caching and another error shows up – something about a cookie being tampered with.
*Ding*
Where the hell is the session id stored? Of course it’s in a cookie. After bringing up firebug and deleting the cookie (or conversely probably just restarting the browser) the problem was gone.
My fatal flaws? I overwrote the config.action_controller.session :secret I had originally in development.rb with a new one in environment.rb and I didn’t restart my browser or delete that session cookie.
Ain’t that a bitch?
#
In getting up to speed with the new bells and whistles in Rails 2.0s RESTful routing capabilities I ran into something that puzzled me. Of the options for a resource defined among your routes there were two similar pieces that, for one reason or another, I could just not find a solid and bulletproof explanation for – :collection and :member. The :member part of it I got pretty easily for some reason, because its description is inherent in its own name … “a member among the default restful actions”. The :collection part? Notsomuch. After some digging in the Rails mailing list I ran into a great, and worthy, explanation for this knucklehead by a contributer named “deegee”:
For example, with map.resources :reviews, if you want to add a method ‘delete_all’ that deletes all reviews at once. You may want to call that with ‘/reviews/delete_all’ and method PUT (never use GET to delete something). This method is acting on all resources (a collection), so the route should be:
map.resources :reviews, :collection => { :delete_all => :put }
If you want to have a custom action acting on a specific resource, e.g. ‘/reviews/3/give_rating’, then your action is on a member and the route would be
map.resources :reviews, :member => { :give_rating => :put }
So that’s it! They’re the same other than :member working on a single resource, while :collection works on multiple. DONE!
Over at Thredded I am still using Rails 1.2.3 (I’m a little gun-shy to upgrade to 2.0) and, of course, felt that slugged links were necessary for both search engine optimization and making things like assessing site analytics a little easier. It doesn’t even need justification as it’s a matter of fact and necessity for any and all social platforms – blogging, forums, etc. With RoR 1.2.3 the best way to get your links slugging it out was to incorporate a plugin like acts_as_sluggable. It works like a charm, really, and I’ve never had any case where I needed extra functionality.
… Until now. I’ve started incorporating some auto-updating magic to Thredded and needed to grab a lot of data back from an AJAX call (sorry Steve – XHR) in the form of JSON. All well and good so far. But, when new links needed to be built on the client side, I didn’t have my handy built-in Rails ActiveRecord overrides to spit out my new slugged-up link! What to do?!
I dug through the plugin source and found the function that built the url’s slug -
def make_slug(string)
string.to_s.downcase.gsub(/[^a-z0-9] /, '-').gsub(/- $/, '').gsub(/^- $/, '')
end
… And thought the quickest solution was just to rewrite it as a simple JS function.
function slug(id, title)
{
title = title.toLowerCase().replace(/[^a-z0-9] /g,'-').replace(/- $/g,'').replace(/^- $/g,'');
return(id '-' title);
}
