Introduction

C++ is a controversial language: you love it or you hate it. As always, knowing better about something allows one to make better arguments for or against that thing. This is what this series is about. Here I’ll explain some of the less known (except for C++ expert programmers, of course) features of C++.

Let’s start with templates, which account for such a huge part of the language.

Templates

Everyone knows that C++ has templates. Templates is an implementation of the «I have an algorithm that can be used with many different types» idea. This idea is called generic programming and is a pretty powerful one. This is why it is present in almost all modern languages.

Back to C++. C++ defines two kinds of templates: classes templates and function templates. Class templates define an infinite set of classes while function templates define an infinite set of functions. The elements of these sets of classes or functions are called specializations. Every template has a template-name which will be used to name a specific specialization.

Template declarations

Consider these two declarations

1
2
template <typename T>
struct my_list { ... }

1
2
template <typename T>
void max(T a, T b) { return a > b ? a : b; }

These are template declarations. The first one declares a class template and its template-name is my_list, the second one defines a function template and its template-name is max. A template declaration is just a declaration preceded with something without an official name that starts with template <…>, I will call it the template header (but note that this name is not blessed by the C++ standard at all, it just makes sense to me call it like this).

The template header defines what are the parameters of the template class. These are called the template parameters. A type-template parameter, like that T shown above, is a “type variable”. This is the most usual template parameter as it allows to parameterize the declaration over one or more type variables. C++, though, has two more kinds of template parameters: nontype-template parameters and (the funny named) template-template parameter. A nontype-template parameter allows us to parameterize the declaration over a (compile-time) constant integer value. Here “integer value” is a very broad term: of course it includes all integers, but also enum values (enumerators) and addresses of (statically allocated) variables and functions. A template-template parameter allows us to parameterize a declaration over another class template with appropiate template parameters.

1
2
template <typename T, int N> // N is a nontype-template parameter
struct my_fixed_array { };

1
2
template <template <typename T> MyContainer> // MyContainer is a template-template parameter
struct adaptor { };

Specializations

I said above that a class template or function template defines an infinite set of classes or function and that each element of that set was called a specialization. There is a specialization for every possible value that a template parameter can have. Such values are not bounded thus there is an infinite number of specializations (well, we could argue that constant integer values are finite in the language, but types are clearly not finite).

We give value to template parameters of a template by means of template arguments. These template arguments always appear in what is called a template-id. A template-id is just the template-name followed by a list of template-arguments enclosed in < and >.

1
2
my_list<int> l;// Here T has value int, we will write it as T ← int
max<float>(3.4f, 5.6f); // T ← float

Primary template and partial specializations

When we first declare a class template or a function template, such declaration defines the primary template.

1
2
template <typename T>
struct my_list { ... };

1
2
template <typename T>
void swap(T& a, T& b);

Class templates (but not function templates!) can have an extra set of template declarations called partial specializations. A partial specialization looks like a normal class template declaration but the template-name is now a template-id where the template-arguments partially specialize the given template parameters.

1
2
3
4
5
6
7
8
9
10
11
12
// 1) Partial specialization for "pointer to (any) P" type
template <typename P>
struct my_list<P*> { }; 

// 2) Partial specialization for "array of (any) Size of (any) Element"
template <typename Element, int Size>
struct my_list<Element[Size]> { };

// 3) Partial specialization for "pointer to function with two parameters 
// Arg1 and Arg2 returning Ret"
template <typename Ret, typename Arg1, typename Arg2>
struct my_list<Ret (*)(Arg1, Arg2)>;

A C++ compiler will always pick the partial specialization (if any) that is “closer” to the one requested in the template arguments. If no partial specialization matches, the primary template is chosen instead. The exact algorithm is not important here.

1
2
3
4
5
6
7
8
9
10
my_list<int> l0; // will pick the primary template T ← int

my_list<int*> l1; // will pick partial specialization 1) 
// where P ← int (note that respect to the primary template this is T ← int*)

my_list<int[10]> l2; // will pick partial specialization 2) 
// where Element ← int and Size ← 10

my_list<int (*)(float, double)> l3; // will pick partial specialization 3) 
// where Ret ← int, Arg1 ← float and Arg2 ← double

I think this is enough for today regarding C++ templates. More craziness to come. Stay tuned.

It's no secret that Google Mail has become, over the last years, the most widely used email server and client on the world. Not only it's basically free, but with the use of Google Apps you can even use it on your own domains.

Because so many people use it, even system administrators, it may be good to know how to use it to send system emails. Also, because Ruby is actually the only scripting language I feel comfortable with, I'll show you a simple library to send emails using Google SMTP server as an outgoing server, so you don't have to configure your server with sendmail, postfix or another typical UNIX mail server.

The first thing we will need is to include (and install) two gems:

• net/smtp (actually this comes from the Standard Library on Ruby 1.9)
• tlsmail

With those two libraries, we can already send a simple email, using the standard SMTP format:

def send_email from, to, mailtext
  begin 
    Net::SMTP.enable_tls(OpenSSL::SSL::VERIFY_NONE)
    Net::SMTP.start(@smtp_info[:smtp_server], @smtp_info[:port], @smtp_info[:helo], @smtp_info[:username], @smtp_info[:password], @smtp_info[:authentication]) do |smtp|
      smtp.send_message mailtext, from, to
    end
  rescue => e  
    raise "Exception occured: #{e} "
    exit -1
  end  
end

You can see here that the SMTP info is stored in a variable @smtp_info. We will take care of that later. Also, the variable mailtext passed to the method also needs a special format. More on that later as well. The really important fragment of code here is the one that calls enable_tls on the Net::SMTP module. This method is provided by the tlsmail gem and will allow our SMTP connection to use TLS as the authentication method. The other part of the code is pretty straightforward: we simply call the start method with a block, in which we actually send the email with send_message. Note that we have to provide the start method with the SMTP info of our Google Mail server account. This includes the server, which will be smtp.gmail.com, the port, which is 587, the HELO, which is gmail.com if using a standard account or your domain FQDN if using your own domain, and finally your username and password. For the authentication parameter we have to provide :plain (TLS will be used on top of that).

Now let's see how the mailtext string is built. In this case I'll be using a plain text format with two different variants: a simple text email, or an email with an attachment.

To send a simple text email, we have to follow the SMTP standard. I took the info from this tutorialspoint post. Here's the pattern we have to follow to build a compliant string:

def send_plain_email from, to, subject, body
  mailtext = <<EOF
From: #{from}
To: #{to}
Subject: #{subject}

#{body}
EOF
  send_email from, to, mailtext
end

Note the importance of the indenting here, as the from/to/subject lines must start at the first text column. With this simple method, you can then simply call the method we programmed before with the resulting string as a parameter and the email will be sent. Pretty easy.

Sending an attachment is a bit more complicated. As SMTP email is send in plain text, attachments are encoded in base64 strings, and are added to the message string in a special way. Here's how to do it in Ruby:

def send_attachment_email from, to, subject, body, attachment
# Read a file and encode it into base64 format
  begin
    filecontent = File.read(attachment)
    encodedcontent = [filecontent].pack("m")   # base64
  rescue
    raise "Could not read file #{attachment}"
  end

  marker = (0...50).map{ ('a'..'z').to_a[rand(26)] }.join
  part1 =<<EOF
From: #{from}
To: #{to}
Subject: #{subject}
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=#{marker}
--#{marker}
EOF

# Define the message action
  part2 =<<EOF
Content-Type: text/plain
Content-Transfer-Encoding:8bit

#{body}
--#{marker}
EOF

# Define the attachment section
  part3 =<<EOF
Content-Type: multipart/mixed; name=\"#{File.basename(attachment)}\"
Content-Transfer-Encoding:base64
Content-Disposition: attachment; filename="#{File.basename(attachment)}"

#{encodedcontent}
--#{marker}--
EOF

  mailtext = part1 + part2 + part3

  send_email from, to, mailtext
end

As you can see, in the first place the file is read and converted to a base64 string. After that, the message is generated. SMTP uses a special unique marker to delimit the attachment from the rest of the text. In here we use the line (0...50).map{ ('a'..'z').to_a[rand(26)] }.join (extracted from StackOverflow) to generate a 50 char length random string. Although it's very unlikely to happen, we should check that this random string does not appear anywhere else in the message body or the base64 converted attached file before using it as a delimiter.

After that, the rest of the message is built, specifying it has an attachment and its delimiter in the following lines:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=#{marker}
--#{marker}

The file is actually attached some lines below. After that, we can pass this new string to the method that sends the email, and all done.

Now, because our SMTP info can be sensitive (it contains our username and our password), it might not be a good idea to just hardcode this info in the email sending script. That's why I've used a yaml serialized hash to store this info, so we can load it at any time. Doing this is really easy with the yaml gem:

smtp_info = 
    begin
      YAML.load_file("/path/to/your/smtpinfo")
    rescue
      $stderr.puts "Could not find SMTP info"
      exit -1
    end

An example file would look like this:

---
:smtp_server: smtp.gmail.com
:port: 587
:helo: gmail.com
:username: user@gmail.com
:password: your_password_here
:authentication: :plain

Now that we have all the parts programmed, we should only pack it a little so it can be of use as a library. The following code contains a simple script with a class to send the emails and a little program that reads parameters from the command line:

require 'net/smtp'
require 'tlsmail'
require 'yaml'

class SMTPGoogleMailer
  attr_accessor :smtp_info

  def send_plain_email from, to, subject, body
    mailtext = <<EOF
From: #{from}
To: #{to}
Subject: #{subject}

#{body}
EOF
    send_email from, to, mailtext
  end

  def send_attachment_email from, to, subject, body, attachment
# Read a file and encode it into base64 format
    begin
      filecontent = File.read(attachment)
      encodedcontent = [filecontent].pack("m")   # base64
    rescue
      raise "Could not read file #{attachment}"
    end

    marker = (0...50).map{ ('a'..'z').to_a[rand(26)] }.join
    part1 =<<EOF
From: #{from}
To: #{to}
Subject: #{subject}
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=#{marker}
--#{marker}
EOF

# Define the message action
    part2 =<<EOF
Content-Type: text/plain
Content-Transfer-Encoding:8bit

#{body}
--#{marker}
EOF

# Define the attachment section
    part3 =<<EOF
Content-Type: multipart/mixed; name=\"#{File.basename(attachment)}\"
Content-Transfer-Encoding:base64
Content-Disposition: attachment; filename="#{File.basename(attachment)}"

#{encodedcontent}
--#{marker}--
EOF

    mailtext = part1 + part2 + part3

    send_email from, to, mailtext
  end

  private

  def send_email from, to, mailtext
    begin 
      Net::SMTP.enable_tls(OpenSSL::SSL::VERIFY_NONE)
      Net::SMTP.start(@smtp_info[:smtp_server], @smtp_info[:port], @smtp_info[:helo], @smtp_info[:username], @smtp_info[:password], @smtp_info[:authentication]) do |smtp|
        smtp.send_message mailtext, from, to
      end
    rescue => e  
      raise "Exception occured: #{e} "
      exit -1
    end  
  end
end

if __FILE__ == $0
  from = ARGV[1]
  to = ARGV[2]
  subject = ARGV[3]
  body = ARGV[4]
  attachment = ARGV[5]
  smtp_info = 
    begin
      YAML.load_file(ARGV[0])
    rescue
      $stderr.puts "Could not find SMTP info"
      exit -1
    end

  mailer = SMTPGoogleMailer.new
  mailer.smtp_info = smtp_info

  if ARGV[4]
    begin
      mailer.send_attachment_email from, to, subject, body, attachment
    rescue => e
      $stderr.puts "Something went wrong: #{e}"
      exit -1
    end
  else
    begin
      mailer.send_plain_email from, to, subject, body
    rescue => e
      $stderr.puts "Something went wrong: #{e}"
      exit -1
    end
  end
end

And that's all! You can use the script as a standalone command to send an email with some command line arguments or just require it in your ruby script and use the class to send the messages.

Ruby on Rails performance is a topic that has been widely discussed. Whichever the conclusion you want to make about all the resources out there, the chances you'll be having to use a cache server in front of your application servers are pretty high. Varnish is a nice option when having to deal with this architecture: it has lots of options and flexibility, and its performance is really good, too.

However, adding a cache server in front of your application can lead to problems when the page you are serving has user dependent content. Let's see what can we do to solve this problem.

Some days ago I learnt about The FizzBuzz Test and did a simple implementation in Ruby. The FizzBuzz test is a simple algorithm that is supposed to do the following:

For each number from 1 to 100:

• If the number is divisible by 3, print "Fizz"
• If the number is divisible by 5, print "Buzz"
• If the number is divisible by both 3 and 5, print "FizzBuzz"
• Otherwise print the number

I was just reading about how you can use the Enumerator class to have generators in the Programming Ruby 1.9 book, and thought that a good implementation could be done using just an Enumerator, so here it is, along with a simple RSpect test:

FizzBuzz = Enumerator.new do |yielder|
  count = 1
  loop do
    if count % 3 == 0
      if count % 5 == 0
        yielder.yield "FizzBuzz"
      else
        yielder.yield "Fizz"
      end
    elsif count % 5 == 0
      yielder.yield "Buzz"
    else 
      yielder.yield count
    end
    count += 1
  end
end

require_relative 'fizzbuzz'

describe FizzBuzz do
  before(:all) do
    @fizzbuzzes = FizzBuzz.first(100)
  end

  it "returns 'Fizz' for all multiples of 3" do
    @fizzbuzzes[3-1].should == 'Fizz'
  end

  it "returns 'Buzz' for all multiples of 5" do
    @fizzbuzzes[5-1].should == 'Buzz'

  end

  it "returns 'FizzBuzz' for all multiples of 3 and 5" do
    @fizzbuzzes[60 - 1].should == 'FizzBuzz'

  end

  it "returns the passed number if not a multiple of 3 or 5" do
    @fizzbuzzes[1 - 1].should == 1
  end
end

You can also find the code in its GitHub repository: https://github.com/brafales/ruby-fizzbuzz.

If you ever wondered how to push the tags you set locally to a remote repository in git, you can do it with the following simple command:

git push --tags