Creating Print Stylesheets for Other Sites

Creating a print stylesheet for your website is a nice optimization that your visitors will appreciate, especially if your site features articles that are longer or are technical in nature. Print stylesheets don’t take too much effort to create and maintain over time along with your site CSS.

But what if you’d like to have print stylesheets on someone else’s website?

Here’s an approach I’ve used to hack together simple print stylesheets that I’ve sent to other site owners as a contribution. This works very well for personal blogs and open source projects, both of whom are usually open to contributions.

Make a Local Copy

The first step is to make a local copy of a representative page from the site. For example, if the site is a blog, pick a good sample post (not the home page or an index page).

These steps require wget which already exists on most Mac/Linux systems, or can be installed for Windows.

  1. Download the sample page with wget: wget -p --convert-links URL
  2. If the downloaded file doesn’t have extension .html, rename it (e.g. if the download was index.php, rename it to index.html)
  3. Open the .html file in a local browser and make sure everything looks okay; some dynamic content such as ads may not appear correctly, but that’s okay
  4. Edit the .html file and after all the other CSS includes, add reference to a new local file: <link rel="stylesheet" href="print.css" media="all" />
  5. Create the print.css file and start with something that will be obvious like: p {color:red;}
  6. Refresh the .html file in the browser and make sure the local print.css is being picked up

Create Print Stylesheet

Now we’ll go through and build up print.css to hide and adjust content sections as needed to create a good looking printout. For this step I usually use Chrome or Firefox with their built-in Inspect Element features. You can make iterative changes to the print.css and refresh in the browser.

Hide Sections

Find all sections/divs that are not the content. This will typically be the header, footer, sidebar, ads, comments, and so on. You’ll need to adjust your CSS selectors depending on the content, starting with the most general and working down as needed.

For each section identified, set it to display:none. For example:

header, footer, div#leftnav {
    display: none;
}

Adjust Widths

Most site designs will have a hierarchy of <div> elements which result in the main content being narrower than the full page. We want to adjust that out to 100% to be more appropriate for a printout. A good starting point is the following:

div#content, #main {
    width: auto;
    max-width: 100%;
    float: none !important;
}

Adjust Fonts

You might need to adjust the font settings, particularly the size. There is also the question of serif vs sans-serif and which works better for print. (You choose.) You may also need to reduce font size and margins for heading elements <h1>, <h2>, etc. if they are being printed too big.

For example:

div#content, #main {
    font: 11pt Georgia, "Times New Roman", Times, serif;
    line-height: 1.3;
}

Optional

Depending on the site content, here are some other things to consider:

  • Hide any embedded video objects like YouTube
  • Hide comments/discussion
  • Set color to black on white background
  • Add URLs after <a> links

Contribute Back to Site Owner

Once you have your print.css file ready to go, I suggest adding comments to clarify the different changes you made. That way, the recipient can better understand what you’ve done, and make selective changes if they want.

Send the file to the site owner as a .txt file, or via a service like pastebin. They can use your contribution either as a standalone print stylesheet (<link rel="stylesheet" href="print.css" media="print" />) or directly inside an existing stylesheet at the end (@media print { ... }).

Good luck. If you use this technique and are successful in creating a print stylesheet for someone else’s site, let me know!

Quick Guide to Vagrant on Amazon EC2

Here’s a really quick guide to using Vagrant to create virtual machines on Amazon Web Services EC2. I’ve gotten a lot of use out of Vagrant for local development, but sometimes it’s helpful to build out VMs in the cloud. (In particular, if your local machine isn’t very powerful.)

These steps assume you already have Vagrant installed and have an Amazon Web Services account (and know how to use both).

Installation

First you’ll need to install the Vagrant AWS plugin:

vagrant plugin install vagrant-aws
vagrant box add dummy https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box

Next login to your Amazon AWS console to get a few things:

  • AWS access key
  • AWS secret key
  • SSH keypair name
  • SSH private key file (.pem extension)
  • Make sure the default security group enables SSH (port 22) access from anywhere

I like to set these up as environment variables to keep them out of the Vagrantfile. On Mac or Linux systems you can add this to your ~.profile file:

export AWS_KEY='your-key'
export AWS_SECRET='your-secret'
export AWS_KEYNAME='your-keyname'
export AWS_KEYPATH='your-keypath'

Vagrantfile

Now we can configure our Vagrantfile with the specifics needed for AWS. Refer to the vagrant-aws documentation to understand all the options. In the example below we have all the AWS-related settings in the x.vm.provider :aws block:

VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.define :delta do |x|
    x.vm.box = "hashicorp/precise64"
    x.vm.hostname = "delta"

    x.vm.provider :virtualbox do |v|
      v.name = "delta"
    end

    x.vm.provider :aws do |aws, override|
      aws.access_key_id = ENV['AWS_KEY']
      aws.secret_access_key = ENV['AWS_SECRET']
      aws.keypair_name = ENV['AWS_KEYNAME']
      aws.ami = "ami-a7fdfee2"
      aws.region = "us-west-1"
      aws.instance_type = "m3.medium"

      override.vm.box = "dummy"
      override.ssh.username = "ubuntu"
      override.ssh.private_key_path = ENV['AWS_KEYPATH']
    end
  end
end

See this Github gist for a longer example file.

Now you can bring up the VM by specifying the AWS plugin as the provider:

vagrant up --provider=aws

After about a minute, the VM should be up and running and available for SSH:

$ vagrant up --provider=aws
Bringing machine 'delta' up with 'aws' provider...
==> delta: Launching an instance with the following settings...
==> delta:  -- Type: m3.medium
==> delta:  -- AMI: ami-a7fdfee2
==> delta:  -- Region: us-west-1
==> delta:  -- Keypair: briancantoni
==> delta:  -- Block Device Mapping: []
==> delta:  -- Terminate On Shutdown: false
==> delta:  -- Monitoring: false
==> delta:  -- EBS optimized: false
==> delta:  -- Assigning a public IP address in a VPC: false
==> delta: Waiting for instance to become "ready"...
==> delta: Waiting for SSH to become available...
==> delta: Machine is booted and ready for use!
==> delta: Rsyncing folder: /Users/briancantoni/dev/vagrant/aws/ => /vagrant

$ vagrant ssh
Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.13.0-29-generic x86_64)

ubuntu@ip-172-31-30-167:~$

Notes

  • You need to configure a specific AMI for Vagrant to use. I find the Ubuntu Amazon EC2 AMI Finder very helpful to match the version and region I wanted to use.
  • A common tripping point is the default security group not allowing SSH (port 22) from any IP address. Also make sure to add any other ports depending on your application (e.g., port 80 for HTTP).
  • Once you have the basics working, make sure to read through the vagrant-aws project to understand all the options available.
  • Make sure to vagrant destroy your VMs when done, and check the AWS Console to make sure they were terminated correctly (to avoid unexpected charges).

Using Vagrant for Local Cassandra Development

vagrant logo cassandra logo

Ever since joining DataStax this year, I’ve spent a lot of time learning and using both Cassandra and the DataStax Enterprise version of it. To really get into it, I wanted to be able to quickly build up and tear down local clusters, without affecting my primary development system (Mac PowerBook).

Vagrant’s tagline says it well:

Create and configure lightweight, reproducible, and portable development environments.

To help those that want to learn and develop with Cassandra, I’ve created a set of sample “getting started” templates and shared them on GitHub: bcantoni/vagrant-cassandra

Take a look at the screencasts linked below, then check out the GitHub project for the detailed instructions.

Installing DataStax Enterprise on Digital Ocean

These instructions explain how to install DataStax Enterprise on a set of Digital Ocean droplets. DataStax provides instructions for Installing on cloud providers, but currently only Amazon EC2 and HP Cloud are described specifically.

The steps below can be used for Digital Ocean, or more generally for any other cloud provider. We’ll create a set of Ubuntu droplets and install DataStax Enterprise (DSE) on them to create a Cassandra cluster.

Update: Scroll to the bottom for a video demo of these install steps.

These are the relevant DataStax documentation pages if you want to learn more details behind each step:

Prerequisites

  1. Register for DataStax Enterprise (free, allows use of DataStax Enterprise in dev/test environments)
  2. An active Digital Ocean account (referral link if you don’t have an account yet)

Creating Digital Ocean Droplets

  1. Login to the Digital Ocean and navigate to the control panel
  2. On your local system create an SSH key and store it in the Digital Ocean control panel (help)
  3. On the control panel click Create with settings like:
    • Hostname: node0
    • Size: 4 GB / 2 CPU
    • Region: default
    • Image: Linux Ubuntu 14.04 64-bit
    • SSH key: Select the one created previously
    • Settings: default
  4. Repeat for node1, node2, etc. (as many nodes as desired)
  5. As the nodes are coming up make note of the IP addresses

Installing DataStax Enterprise

For a faster install, see Parallel Installs below.

  1. SSH into the first node
  2. Confirm whether Java is already installed (it may be, depending on the Linux image); if not, install either OpenJDK Java or Oracle Java
  3. Add the DataStax repository using the username and password from your registration:

    echo "deb http://username:password@debian.datastax.com/enterprise stable main" | sudo tee -a /etc/apt/sources.list.d/datastax.sources.list

  4. Add the DataStax repository key:

    curl -L --silent https://debian.datastax.com/debian/repo_key | sudo apt-key add -

  5. Update the local package cache:

    sudo apt-get update

    (if you see any “403 Not Authorized” errors here, stop and make sure your username and password are correct)

  6. Install DataStax Enterprise:

    sudo apt-get install dse-full

  7. Edit /etc/hosts and add an entry for the host with its public IP address (replacing the 127.0.1.1 entry if it exists)

  8. Edit /etc/dse/cassandra/cassandra.yaml and change a couple of settings:

    • Set cluster_name as desired
    • In the seeds field, list the IP address of node0 (the first server will be the seed for the cluster)
    • Set listen_address to blank
    • Set num_tokens to 256
  9. Start the DSE service:

    sudo service dse start

  10. Repeat the above steps for the remaining nodes (node1, node2, etc.)

  11. SSH to any of the nodes and check the status of the DSE cluster:

    nodetool status

Parallel Installs

You can run the above install commands in parallel for a much faster setup time. On the Mac I use i2cssh which powers several iTerm2 consoles in parallel.

This technique is borrowed from Jake Luciani’s video How to set up a 4 node Cassandra cluster in under 2 minutes.

Steps:

  1. Install i2cssh and iTerm2
  2. Create a file ~/.i2csshrc with the server IP addresses. For example this file defines 3 servers included in a cluster named ‘digdemo’:

    version: 2
    iterm2: false
    clusters:
      digdemo:
        login: root
        hosts:
          - 54.176.126.209
          - 54.176.91.139
          - 50.18.136.76
    
  3. Launch parallel terminal sessions: i2cssh -c digdemo

  4. Enable broadcast mode in iTerm2 with Cmd-Opt-I

  5. Type commands from the install procedure above; they should be echoed on all sessions in parallel

Video Demo

Notes

Clean Up Your Twitter App Permissions

Twitter users should periodically review their application permission settings to clean out any old applications they have authorized. Over time these can pile up and it’s good to clean them out.

The steps are simple:

  1. Login to Twitter and navigate to the Application Settings page
  2. Review the list of applications and click Revoke Access for any you no longer need or don’t remember authorizing
Twitter App Permissions

Twitter App Permissions