Tom Slykhouse

Helping organizations apply technology to improve marketing results. Connect with me on Google+

    Posts by Tom Slykhouse

    Google+ Circles Explained

    I recently started to actually use my Google+ account. The thing that puzzled me the most were Google+ circles. After reading both the online help, and Guy Kawasaki’s eBook on Google+ I still didn’t completely get it. To figure out what really happens, I created a separate test account that enabled me to try out different scenarios. Here is what I discovered.

    1. When you add a person to one of your circles, you are essentially following them and you will see their posts. You can then filter the posts you are viewing to a specific circle. So circles allow you to control how you categorize and view posts from people you follow.

    2. When you add a person to one of your circles, they will not automatically see your posts. In order to see your posts, they need to follow you back by adding you to one of their circles.

    It appears however that the recently introduced Events function breaks this rule, and allows anyone to invite people they are following, but who are not following them to an event. This has raised a huge uproar in the Google+ community, and I expect will be changed so it will no longer be the case. It is interesting though because other event services like evite allow you to invite people based on their email address only, and don’t require their permission to do so. The challenge for Google is to make privacy work in a social network the same way it works in email. Or not, depending on what they are trying to accomplish. Maybe their goal is to use Google+ to encourage more people to follow people who might invite them to an event!

    3. The publisher of a post can elect to publish a post to one or more of his/her circles. But if the publisher mixes posts when they publish, there is no way a follower can filter the posts. For example, if the publisher posts work related information and personal information to one or more circles, followers receive both work and personal information. The same thing is true if the publisher marks the post as public. So circles are only useful to the publisher if they segment their followers by topic of interest.

    What I would like to see is for the follower to be able to subscribe to specific topics of interest for a given publisher. But that isn’t what circles are for.

    4. There is a sharing option called public. While you might think that this means your post will be published to the world, in fact it actually means that your post will be published to all of your followers, regardless of whether you are following them back (aka circled them) or not. This makes sense when you think about it. A celebrity can then communicate with their fans without having to follow them back as well. Once again there is no way for the follower to segment public posts.

    5. Comments and +1s are associated with the original post, and are not automatically sent to the commenter’s followers. Email notifications of the comment are distributed to the poster and previous commenters.

    Hopefully you now have a better understanding of how Google+ circles work. If you liked this article please share it with your friends.

    Generating a sitemap.xml file on Heroku with Ruby on Rails

    Here is a description of how to dynamically generate an xml sitemap every time it is accessed. If you have a larger site, you may want to generate the sitemap using a cron job, and publish it to a storage service like Amazon S3.

    Step 1:
    Remove /public/sitemap.xml if it exists.

    Step 2:
    Add the following to /config/routes.rb
    get “sitemap.xml” => “sitemap#index”, as: “sitemap”, defaults: { format: “xml” }
    Step 3:
    Create /app/controllers/sitemap_controller.rb

     class SitemapController < ApplicationController
       def index
         @static_pages = [root_url, about_url, contact_url, help_url]
         @users = User.all
         @posts = Post.all
         respond_to do |format|

    Step 4:
    Create /app/views/sitemap/index.xml.builder with the following content. Note that this sitemap.xml includes not only the links to the pages in the site, but also the links to the photographs that are embedded in the links, and which are stored on Amazon S3.

      'xmlns'.to_sym => "",
      'xmlns:image'.to_sym => ""
    ) do
      @static_pages.each do |page|
        xml.url do
          xml.loc "#{page}"
      @users.each do |user|
        xml.url do
          xml.loc "#{user_url(user)}"
      @posts.each do |post|
        xml.url do
          xml.loc "#{post_url(post)}"
          xml.lastmod post.updated_at.strftime("%F")
            xml.image :image do
              xml.image :loc, "#{request.protocol}#{request.host_with_port}#{}"

    Step 5:
    Commit and upload to heroku.


    Sending Email from Rails Using smtp on Heroku

    A recent project we worked on used Ruby on Rails running on Heroku. The actual domain, including all email services, DNS services are hosted elsewhere. In order to get this working, I needed to figure out how to configure Heroku to send email through a remote SMTP server.

    First of all configure the production server by adding the following lines to the project /config/environments/production.rb file. If you are going to be testing the SMTP mail functions on your development server you need to add the configuration information to /config/environments/development.rb as well.

    config.action_mailer.delivery_method = :smtp
    config.action_mailer.smtp_settings = {
      address: "",
      port: 25,
      authentication: "plain",
      user_name: "",
      password: ENV['SMTP_PASSWORD'],
      enable_starttls_auto: false
    config.action_mailer.raise_delivery_errors = true

    In your configuration replace address: ‘’ with your own SMTP server hostname, and replace the user_name: “” with the user name for a valid email account on your SMTP server.

    Depending on your situation, you may also have different values for port:, authentication: and enable_starttls_auto:. This is what works for a basic SMTP host running plain authentication and no TLS encryption. This configuration is not designed to work with gmail.

    Notice that the password to access your SMTP server is not specified here. It is generally a bad idea to store security credentials in a project file if that file is stored in a version control system like git. Anyone with access to that version control system will also get access to the production security information, which could be a big deal for some applications. So in this case the SMTP server password is stored in an environment variable called SMTP_PASSWORD. By setting this variable on the development and production machines, the mail configuration will be complete.

    On MAC or Linux development systems, the environment variable can be set one of 2 ways.

    Before running the development server (rails server), enter the following command on the command line, substituting the actual password for the word password in quotes.

    export SMTP_PASSWORD='password'

    Alternatively you can add the same export command to your ~/.bash_profile file.

    You can verify that the password has been set by typing:


    If you are running foreman as your development rails server, you can have foreman load the environment from a file named .env at the root of your project:


    If you are running version control, you should make sure that the .env file is not stored in your repository. If you are using git make sure the following line is in the .gitignore file.


    Once you have the mailer running on your development system using SMTP, you need to run one more command to make it work on heroku.

    $ heroku config:add SMTP_PASSWORD='password'

    This creates an environment variable on heroku that works the same as environment variables on your development system. At this point you can upload the new version of your project and you will have the ability to send mail using your existing SMTP server.

    Azgaard Launches Meeting Planner Toolkit

    Azgaard Systems is launching a new project, the Meeting Planner Tookit ( The purpose of this project is to provide meeting planners with online tools to better manage meetings and events.

    Azgaard Systems Provides Collaboration Services for Associations

    Azgaard Systems provides services to help association members network and collaborate more effectively by using Google Apps and Google Sites.

    Google Sites provides organizations with the ability to create web sites on demand to use in serving the needs of different groups in their organization. Azgaard Systems provides planning, development, deployment and training services to help organizations understand how to use Google Sites to best serve the needs of their organization.

    Member based associations are typically organized in a complex network of local, regional and national groups. Traditionally each part of the association had to rely on its own volunteers and staff to provide any kind of web-based tools to their members at that level in the association. With the advent of Google Apps with Google Sites, member based associations can now provide each sub-organization with the necessary tools to effectively support networking and collaboration amongst its members.

    Google Sites are available to individuals and organizations. By combining Google Sites with Google Apps, organizations can now harness the power of their communications infrastructure, their online document collaboration tools by making those documents and communications available through sites, tailored to the security and application needs of various groups in the organization.