I needed to send an email to all the users of Codaset, and wanted a quick and easy way to do so. So I just wrote a quick Rake task that will loop through all the users in the Codaset database, and send each one an email. However, when I was looking at how to send the emails, there didn’t seem to be an easy way to do so without having to write several lines of code just to send one email. What I needed was something similar to PHP’s mail() function which lets me send an email with one line of code:
php
1
mail('you@example.com', 'My Subject', $message);
I don’t need to use an SMTP server to send it, as it works just fine with sendmail.
Unfortunately, Ruby and Rails built in mail classes don’t offer such simplicity, which is very rare. But then I found Pony, which is a Ruby gem that mimics PHP’s mail function. Now I can can send an email in Ruby with one short line of code, and no configuration needed:
For those of you who are interested, here is my rake task in its entirety:
ruby
123456789101112131415161718192021222324
require "pony"
require "erb"
desc "Send an email to all users"
task :email_users => :environment do
raise "No template provided. Please set TEMPLATE=file_name" if ENV['TEMPLATE'].blank?
template = File.read ENV['TEMPLATE']
subject = ENV['SUBJECT'] || "Hello from Codaset"
if ENV['TEST']
name = 'Joel Test'
Pony.mail :to => 'joel@developwithstyle.com', :from => "Codaset <help@codaset.com>", :subject => subject, :body => ERB.new(template).result(binding)
puts "Email test ('#{subject}') sent to joel@developwithstyle.com"
else
User.find_each do |user|
unless user.email.blank?
name = user.title
Pony.mail :to => user.email, :from => "Codaset <help@codaset.com>", :subject => subject, :body => ERB.new(template).result(binding)
puts "Email ('#{subject}') sent to #{user.email}"
end
end
end
end
This simply loops through each user in the database, and sends them an email. The body of the email is built using a templated file, that uses ERB. Which means I can use it as a normal view template. I run it like this:
ruby
1
rake email_users RAILS_ENV=production TEMPLATE=my_email_template.txt SUBJECT='Look at my email i sent ya!'
Concerns is a simple Rails plugin that provides you with a simple way to organise your Controllers, Models and Mailers, and split them into smaller chunks of logic. It is especially useful when you have lengthly models, and get fed up with having to scroll through several hundred lines of code.
How does it work?
So let’s say we have a Post model (doesn’t everyone?!) which is getting a bit lengthy, and frankly not very nice to look at. With the Concerns plugin, we can split it up into nice little chunks. Because we have lots of validations, let’s start by pulling them out and placing them within a concern file.
Then, create a new directory in your app/models drectory and call it “post”, which is the same name as your model.
Within this new directory, create a new file at app/models/post/validations.rb. Now all this should do is reopen your Post model, and define your validations like this:
ruby
123456
class Post < ActiveRecord::Base
validates_presence_of :title, :body
validates_uniqueness_of :title, :scope => :project_id, :case_sensitive => false
validates_exclusion_of :title, :in => %w(edit new blog delete destroy create update post posts)
validates_inclusion_of :markup_language, :in => %w( markdown textile wikitext ), :allow_nil => true
end
It’s just like writing your model again.
Now within your main Post model; right at the top, we simply call:
ruby
1
concerned_with :validations
Multiple concerns can be called like so:
ruby
1
concerned_with :validations, :class_methods
And we’re done!
You can do this as many times as you wish, and with as many concerns as you want. And it works with models, controllers and mailers.
Need help?
This is a reprint of an announcement made a few minutes ago at Codaset.com…
I am very pleased to announce that Codaset has ended it’s private beta phase, and is now open to all. The beta tag is still in place, so the site is effectively in public beta. This means that no invite is needed to register and create an account. Anyone can create projects, and anyone can take part in any activity on the site.
Along with this announcement, also brings with it a few bug fixes, and minor improvements. Nothing huge, but you should find that browsing the site in Safari is much improved, and several styling bugs have been fixed. I also added URL slugs to milestones, which means your Milestones look prettier and are more familiar to browse.
So I am hoping that with this announcement and release, we will start to see an increase in the number of registered users, and active users. And of course, Codaset is one step closer to a final release. So if there are any features you want to see in the final release; and if there is not already a ticket for it, please create one now. If there is a ticket already created for your requested feature, please vote it up. Voting for tickets is the best way for me to see what you want.
I’ve found myself creating a number of new Rails apps as of late, and found it very cumbersome to set each one up with my favoured list of gems and plugins. So I created my own Rails Template.
Rails templates are single ruby scripts which contain a few commands that help you setup any new Rails app in a snap. So you can specify a list of Gems to have installed and part of your environment.rb, and also install a bunch of plugins, amongst other things.
You should take a look at Pratik Naik’s blog post for full details on what Rails templates can do.
So my default Rails template is called Railings, and is available now on Codaset. It is sure to grow by the day, but for now, this is what you get:
jQuery 1.3.2
Blueprint CSS Framework
Initializes as a Git repo and creates .gitignore
Creates staging environment
Creates application layout
A default database.yml, and a modified database.example.yml which is ued with the ‘Wheres my database.yml dude?’ rake task
Creates Vlad the Deployer deploy.rb config file
Time formats initializer
The following gems:
thoughtbot-factory_girl
rubyist-aasm
mislav-will_paginate
hpricot
RedCloth
emk-safe_erb
settingslogic
vlad
vlad-git
The following plugins setup as Git submodules:
limerick_rake
mile_marker
squirrel
rspec
rspec-rails
exception_notifier
monkey-magic
gravatar
So the next time you start a new rails app, run this command and you will have the world at your fingertips:
I was just browsing through my tweets and came across this little gem as put forward my Nate Abele; he of CakePHP lead developer fame…
It got me thinking about how I organise my CSS files and code, and as I have been writing a lot of CSS recently when developing Codaset, it made me realise that I have developed a bit of a habit with my own CSS. So I thought I’d share it all with you.
Over the last year or so, there seems to have been an explosion of CSS frameworks. I suppose it was inevitable really, as it happened with Javascript, so why not CSS. ANd to be honest, I would say that is a good thing, and there are some decent ones out there. But my CSS framework of choice is the excellent Blueprint framework. It’s a great starting point for all your CSS, and sets some good reset points. It’s also very lite-weight.
Before I continue, I just want to say that I will not be telling you how to use Blueprint or indeed, how to write CSS. I use Blueprint’s grid classes, but again, I won’t be talking about them. This post is more about how I use a class based system for my CSS.
First, if I don’t already have one, I create a css directory within my public root, the place Blueprint’s three CSS base files within a sub-directory. I usually call that blueprint. (surprise, surprise). Then I create two files within my css directory called base.css and site.css.
I’ve used this structure for this site:
Pretty obvious so far! Now let me explain what I do with the base.css and site.css file.
base.css
Blueprint has a great set of resets or default styles, but sometimes, I want to overwrite these. I also find myself writing my own default styles, so I put all these within the base.css file. A simple rule of thumb is that only classes are allowed in the base.css file.
Since I started using Blueprint, I’ve started using it’s default classes a lot. Classes such as .quiet and .small make it very obvious what I am doing to a particular element. So if I want told make a line of text a little smaller, I can simply wrap the text with a div or a span, and give that div or a span a class of small:
html
123
<div class="small">
Here is some text I made a little smaller than the rest.
</div>
If I wanted it to be colored a little lighter too, then I can add another class to the div:
html
123
<div class="small quiet">
Here is some text I made a little smaller than the rest, and it's quieter.
</div>
Both those classes and more are all ready to go as part of Blueprint. But I know also want to make this text bold. So I could either give this div an id and create a CSS rule for that new ID like this:
css
123
#myNewDiv {
font-weight: bold;
}
html
123
<div class="small quiet" id="myNewDiv">
Here is some text I made a little smaller than the rest, and it's quieter and now bolded.
</div>
But that’s a bit daft, as I am likely to want to make other elements bold. So a new class would be better:
css
123
.bold {
font-weight: bold;
}
html
123
<div class="small quiet bold">
Here is some text I made a little smaller than the rest, and it's quieter and now bolded.
</div>
Now I could easily have given this div an ID instead and done away with all the classes completely. But again, that isn’t reusable. Another thing I like about the above, is that is very readable and obvious what the classes are doing. It’s very expressive, and even makes it very easy and fast to style, as all I need to do is assign a few classes, rather than creating any new CSS styles. It’s like a pick and mix for CSS!
So I’m now finding that my HTML is full of classes, and I’m seeing less and less ID’s. I only tend to use an ID to style an element if that element is more complex, or has specific needs that are not used elsewhere.
site.css
So the site.css file is therefore used for element specific styling. So any CSS styles that are defined with an ID, are placed in this file. Not much more to say about that actually.
For more about how it all fits in, check out the source and CSS of this site and of . I would love to know your thoughts and feedback on this. Comment away…
So I had a need when developing the beginnings of Codaset, for a nice looking javascript modal/dialog window implementation. I wanted to be able to easily and quickly open up any link in a great looking dialog. I had no shortage of options, as there are tons and tons of jQuery lightbox scripts, or thickbox inspired plugins. But they all seem to want to be the best at absolutely everything.
All I wanted was a simple way to open up a link via ajax into a nice looking dialog window. I didn’t need to show a slideshow or open up the contents of a div. And I really couldn’t find one that did just that and did it well.