David Anguita

Lessons learned from over 15 years of software consulting

2024-03-05T13:40:00+00:00

I’ve been involved in software, offering consultancy, advising, and engaging in various projects for over 15 years now. I started my journey with a small agency and eventually transitioned to freelancing, taking on gigs for clients all around the world. Here, I’d like to summarize a few key lessons I’ve learned over the years.

Each gig is unique

Each gig is a different beast. It presents a unique opportunity to learn, grow, and, more importantly, to share. It is a bi-directional process. One important lesson for me is that you should not be afraid of sharing knowledge, experiences, tips, or ideas of any kind. While my services generally center around technology, I’ve found that product or even business-related contributions were always more welcome than I thought. Do not leave anything for yourself; treat your client as if it were your own company.

People first

Culture is about people, and people are key in an engineering team. You must listen, ask questions, think critically, analyze, while not taking ownership from the permanent team. Once you’ve understood the dynamics, you can offer your insights, suggest changes, and share your way of working to see how it fits into the process. But do it in a very respectful manner, as you are a guest in their house. Don’t pretend to be the main character; you are not.

Also, cultivate your soft skills, provide honest but constructive feedback and, once again, treat the team as if it were your own company, fostering a sense of ownership and dedication.

Communicate effectively

Apart from what has just been mentioned, I believe that having good communication skills and practices is key in this job. To me, it’s very important to communicate often and effectively. By communication, I don’t simply mean broadcasting information, but rather ensuring that the message and all its details reach every individual involved. For that, I rely a lot on documentation. I often support my communications with attachments such as an architectural proposal in the company’s internal repository, feedback in a Pull/Merge Request, a summary of notes from a recent meeting, or just some drawings on a virtual whiteboard—whatever it takes to make the message clear and easily understood, even asynchronously.

Get your hands dirty

As a consultant, it’s often easy to feel like a redundant asset, perhaps not entirely necessary, or just hard to fit in. Of course, while you’ve been hired for a purpose, the goals of the collaboration might still be unclear or were not communicated clearly. In such situations, staying too high-level and not getting involved in the internal ceremonies, such as getting into the code, doing peer-code reviews, or helping out with some nasty bug, might work against building trust from your peers, who are also your clients. I’ve been in many situations in which I unexpectedly joined a conversation, ended up pairing and doing “real engineering stuff,” and felt like everyone’s trust started to increase, which allowed me to work more confidently as well.

Tools are secondary

Nowadays there are almost infinite ways to approach building software products, with a myriad of tools and methodologies available. Often, we tend to base engineering decisions primarily on the choice of tools rather than focusing on more fundamental things. When I refer to ‘tools,’ I mean frameworks, stacks, programming languages, vendors, service providers, and so on. While being proficient with specific technologies can provide valuable insights (and it’s necessary for some gigs, of course), it’s equally important to prioritize identifying participant domains and their interactions, establishing the right communication architecture, and laying the necessary foundations for the project or piece of software in general.

I’ve learned that there are not many truly fundamental things in engineering which are sometimes overlooked. It’s also gratifying when you start to recognize these patterns, even when using different tools.

Nothing is written in stone

Every company I’ve collaborated with has had its own unique processes. It doesn’t matter if they are very well-funded or more relaxed, only a few aspects should be set in stone. From an outsider’s perspective, it’s easier to identify when something’s not working, but it’s often so deeply ingrained within the team’s culture that making a change looks like an impossible feat. As a consultant, you can introduce fresh ideas and perspectives based on past experiences and your own learning journey.

Know your strengths and weaknesses

I tend to become personally involved with products and teams I like to work with, which leads to a strong personal commitment that makes me stay present and honestly concerned about the product’s success. This is, in a way, both a strength and a weakness, and I’m still learning how to deal with it.

Another weakness I’d like to highlight is my tendency to delve too deeply into details, making it challenging for me to delegate tasks. And, when I do manage to delegate, I often try to anticipate and prepare as much as possible to facilitate a smooth transition, which is not always the most efficient approach.

Speaking about strenghts, I would say that raw experience is one facet that I try to exploit. After having had the opportunity to collaborate with several companies of different sizes during my career, I often experience the infamous “I’ve been there” feeling. When a familiar solution presents itself, I reflect on previous successes and failures, adapting the approach to meet current needs.

Also, I’m basically a tech guy who has a product-oriented mindset as well. I’ve been in the situation of taking a product from 0 to 1 many times and I know it’s easy to forget things when you are fundamentally a technical person. Do not forget that in the end, it’s all about making things work for the users. Don’t stay exclusively in the technical side of things and ask questions such as “will the users understand this?”, or “does it make sense from the user’s perspective?”, “wouldn’t it be more cost-effective if we do this instead of that”?

If you’ve been in a similar situation than me, I would love to hear your own experiences or lessons learned. Please, drop me a line at hola@davidanguita.name or use the comments section below.

The postmodern development environment

2020-05-22T13:40:00+00:00

My fancy, very expensive MacBook Pro’s keyboard broke, and the battery started failing shortly after. I was a happy GNU/Linux user not so long ago, so I decided to take a step further and buy a Lenovo ThinkPad to make it my new daily driver. TL;DR The experience couldn’t be better, but I kept looking for ways to increase my productivity while ensuring the reliability of my main production machine. In this post I would like to share with you what I have learned in the process.

In my search for a minimal, lightweight distribution, I’ve been through Debian, Ubuntu, Arch, and finally, Void Linux. I like most of the key features of the latest (that’s probably a topic for another post), it’s very well documented, extremely fast, and comes with a pretty lightweight package manager, so I’m stick with it for now.

^ That’s a nice neofetch output.

I do software development for a living, but stuff like image or light video editing could be part of my day too. That’s why I need hardware and software that I can trust and rely on, or at least around which I can build tools that keep me productive and worry-free in my day-to-day.

Fast, reproducible installation

The Void Linux live image allows me to download and run a custom installation script right after getting it booted up (via a USB drive, SD card, or even a CD-ROM thingy if you miss the 90s), as the installation process starts with an empty shell with root privileges. I am aware that this can be achieved in almost every other distro out there as you can always switch to one of the tty available and do your stuff, but Void does it by design. A kind of guided installation process is also available by launching the void-installer script, which is a good TUI if you don’t need any extra features such as file system encryption, but it can be skipped completely.

For the system itself, I use my own install.sh script, which deals with disk partitioning, file system encryption, setting up the bootloader, and so on, and ends up creating an initial user ready to log in with a kickstart.sh script in its home folder, which is precisely the second part of this process. It is definitely not the most polished shell scripting in the world but does the job.

→ install.sh

Here is an example of what you can find in the script regarding configuration:

# -- Configuration. Set values carefully.

# Block device in which the system will be installed on.
device=/dev/sda # It typically is `/dev/nvme0n1` in NVMe drives.

# See https://docs.voidlinux.org/installation/live-images/partitions.html#swap-partitions.
swap_partition_size=2G

# Kernel version the system will boot on.
kernel_version=linux5.4

# Time zone in `zoneinfo` format.
time_zone=Europe/Madrid

# Locale.
lang=en_US.UTF-8

# Hostname.
hostname=void

# Initial user. Will be created automatically with `sudo` privileges.
user=david

# XBPS repo to download the base packages from. Default should be good.
xbps_repo_url=https://alpha.de.repo.voidlinux.org/current

# Kickstart script. Can be left blank.
kickstart_script_url=https://raw.githubusercontent.com/danguita/scripts/master/kickstart/kickstart-void.sh

# Do not change these values unless you know what you're doing.
boot_partition="${device}1" # i.e. `/dev/sda1`
root_partition="${device}2" # i.e. `/dev/sda2`

# -- End of Configuration.

That kickstart.sh script is intended to be run by any user other than root, for the sake of security, and manages to install all the packages that I need on a daily basis, apart from setting up my personal configuration. To allow some granularity, any optional packages are installed only on user confirmation, which leaves me the possibility of having a slightly less bloated system on certain scenarios.

→ kickstart.sh

Just as an example, here is the block that manages to add Docker support:

if confirm "Docker"; then
  install_package docker docker-compose
  enable_service docker
  add_user_to_group docker
fi

^ First boot after a fresh installation. The kickstart.sh script is there waiting to be executed.

And here comes the script that puts all pieces together: My dotfiles repo, which holds the actual configurations, is publicly available on GitHub so the kickstart.sh script can just clone it and execute the installation script provided (it’s a good old make install). All my configuration files and scripts should be there in a couple of minutes. At this time, the machine is pretty much ready for production. Remember that we started with a root shell just a few minutes ago, and the process basically required me to set some passwords and hit the enter key a couple of times, which is nice.

→ dotfiles

Here is the function that manages to install the dotfiles:

install_dotfiles() {
  mkdir -p "$dotfiles_path"
  git clone --recurse-submodules "$dotfiles_repo_url" "$dotfiles_path"
  make -C "$dotfiles_path" install
}

Just for the record, there is a fourth step that consists of restoring a backup from a previous installation. It puts all my workspace files back using rsync, and does it very quickly too. Nothing fancy here, just handcrafted backup.sh and restore.sh scripts that archive and restore some selected paths given a $HOSTNAME. You know, even though it is not required there is always code, documentation, and other stuff that you may want to keep between installations.

A full backup (this mode includes some extra paths) over a specific destination (this is a fictitious remote machine) can be triggered by running:

$ FULL_BACKUP=true DEST_PATH=wadus:/home/david/Private ./backup.sh

As you would expect, the restore script works symmetrically:

$ FULL_RESTORE=true SRC_PATH=wadus:/home/david/Private ./restore.sh

Now that the system is up and running, let me show you some of the key parts of my day-to-day development environment.

Window manager

I spend most of my time between terminals and browser windows on a laptop screen, thus I look for an environment that is simple to use and to maintain at this level too.

Like many of you, I ended up getting comfortable with tiling window managers. No desktop environments or display managers, just the window manager itself, and a bunch of daemonized processes that help with keybindings, system events, on-screen notifications, and other stuff.

For instance, here is a simplified version of my ~/.xinitrc:

# Custom keybindings
xbindkeys &

# On-screen notifications
dunst &

# Start window manager
exec dwm 2> ~/tmp/dwm.log

^ Check out the complete version in my dotfiles repo.

So, these two daemonized processes and the WM itself get started by running startx.

At the time of writing this I’m using dwm, which stands for “dynamic window manager”. I would probably write about it in a separate post, but coming from GNOME, and i3 for a while, the experience is going very well so far. My workflow fits perfectly in dwm’s master-stack approach, and the tool itself is incredibly lightweight and fast. Just as a curiosity, you set your preferences right in dwm’s source code (in a header file, to be precise) so they get applied after compiling it. Not very user friendly, but I have to admit that it is extremely efficient (“suckless”, they say).

^ Intentionally busy desktop, just for the screenshot :shrug:

Text editor

My text editor of choice is Neovim, which I use for almost everything, although my current configuration is fully compatible with Vim 8+. When programming, I rely on coc.nvim for adding Language Server support through extensions, à la VS Code.

There’s not much to say on this set up except that I try to keep dependencies to a very minimum. I uninstall those that I don’t use often, or that can just be replaced with a core function or a small script, so apart from Coc, no other plugin is really relevant at this point.

^ Rust Language Server (RLS) in action.

Maintenance

Unlike install.sh, which is a one-shot script, kickstart.sh was implemented with idempotency in mind so that it can be executed as many times as required.

Apart from that, the dotfiles repo already provides an updating script to keep any dependencies up to date: make update does the job. See all tasks available.

Bonus point: Get prepared for the worst

In the case of catastrophic hardware or software failure, I have some production-ready virtual machines stored in an external drive that have been installed using the same scripts described in this post. This is pretty convenient in case you have something urgent to attend to, and it’s a good way of getting your scripts tested from time to time.

List of files

To summarize, here are all the files that have been mentioned in this post:

Dockerizing a Phoenix project

2016-07-28T13:40:00+00:00

I personally love to keep all my projects isolated in one way or another. In some cases –the most complex ones– I need to provision Virtual Machines by using tools like Vagrant and Ansible, but in most of them I can just define a bunch of Docker containers within the project’s context, which is my preferred approach so far for ease and portability.

I wanted to share my experiencie preparing a Docker environment to develop a sample project using the Elixir language and the Phoenix framework.

Let’s dive in:

The application image

In Phoenix projects we have some dependencies related to the Elixir language and the platform that it leverages from: Erlang VM. To easily match those requirements, there’s an official Elixir repo of Docker images, so let’s take advantage of that.

Here’s the Dockerfile to build the main image. It is the only one in this sample application since it provides all dependencies to run any other Phoenix application instances, and we’re just gonna use it in both development and test environments:

# ./Dockerfile

# Starting from the official Elixir 1.3.2 image:
# https://hub.docker.com/_/elixir/
FROM elixir:1.3.2
MAINTAINER David Anguita <david@davidanguita.name>

ENV DEBIAN_FRONTEND=noninteractive

# Install hex
RUN mix local.hex --force

# Install rebar
RUN mix local.rebar --force

# Install the Phoenix framework itself
RUN mix archive.install --force https://github.com/phoenixframework/archives/raw/master/phoenix_new.ez

# Install NodeJS 6.x and the NPM
RUN curl -sL https://deb.nodesource.com/setup_6.x | bash -
RUN apt-get install -y -q nodejs

# Set /app as workdir
WORKDIR /app

The containers

We’ll use Docker Compose to build and run containers. This sample application will use PostgreSQL 9.5 as database, and let’s say there aren’t extra dependencies in the test environment, to keep things simple:

# ./docker-compose.yml

web:
  build: .
  dockerfile: Dockerfile # That's our Dockerfile path
  env_file: .env # Set environment variables from an `.env` file, if needed
  command: mix phoenix.server # Start the server if no other command is specified
  environment:
    - MIX_ENV=dev # That's the environment mode, you know
    - PORT=4000
    - PG_HOST=postgres
    - PG_USERNAME=postgres
  volumes:
    - .:/app # Here we're mounting our project's root directory inside the container
  ports:
    - "4000:4000"
  links:
    - postgres

test:
  image: phoenixbootstrap_web # We're just using the already built `web` image here
  env_file: .env
  command: mix test # Run the entire test suite if no other command is specified
  environment:
    - MIX_ENV=test # That's key
    - PORT=4001
    - PG_HOST=postgres
    - PG_USERNAME=postgres
  volumes_from:
    - web
  links:
    - postgres

postgres:
  image: postgres:9.5 # https://hub.docker.com/_/postgres/
  ports:
    - "5432"

Configuring the repo

Before starting the containers, let’s configure our Ecto adapter to match the environment settings:

# ./config/dev.exs

config :app, App.Repo,
  adapter: Ecto.Adapters.Postgres,
  username: System.get_env("PG_USERNAME"),
  password: System.get_env("PG_PASSWORD"),
  hostname: System.get_env("PG_HOST"),
  database: "app_dev",
  pool_size: 10

# ./config/test.exs

config :app, App.Repo,
  adapter: Ecto.Adapters.Postgres,
  username: System.get_env("PG_USERNAME"),
  password: System.get_env("PG_PASSWORD"),
  hostname: System.get_env("PG_HOST"),
  database: "app_test",
  pool: Ecto.Adapters.SQL.Sandbox

Running the environment

We should be now ready to go on our Dockerized Phoenix application. Here’s a generic check-list to get everything up and running:

Development environment

# Build the Docker image and start the `web` container, daemonized
$ docker-compose up -d web

# Install application's dependencies and compile them all
$ docker-compose run web mix do deps.get, compile

# Create database and run migrations
$ docker-compose run web mix ecto.create && mix ecto.migrate

# Install (mostly) JS dependencies through `npm`
$ docker-compose run web npm config set strict-ssl false && npm install

# Execute the seeding script, if needed
$ docker-compose run web mix run priv/repo/seeds.exs

# Restart the `web` container to ensure everything's up
$ docker-compose restart web

Your application should just be reachable at http://<your_docker_host>:4000/ 🎉

Test environment

To deal with the test environment, for which we already have a proper container:

# Execute all tests (It's a `$ mix test` actually)
$ docker-compose run test

# Execute tests for specific files
$ docker-compose run test mix test test/models/user_test.exs

So, I’d say that’s a good starting point for covering any other environment needs. Thanks for reading, and please share your thoughts in the comments!

Simple data visualization stack with Docker, InfluxDB and Grafana

2015-08-29T13:00:00+00:00

As a software engineer, I eventually need to collect metrics from my development environment to be graphed and measured. I found a very portable solution based on Docker containers, InfluxDB as time series store and Grafana as visualization tool.

Let’s start by installing the Docker environment in Mac OS X:

Installing Docker

VirtualBox

In OS X, Docker containerization process is based on a Virtual Machine image (boot2docker.iso), so you would need to have VirtualBox installed:

$ brew cask install virtualbox

docker-machine

After that, let’s install the docker client and docker-machine interface:

$ brew install docker docker-machine

To create a new development machine using the VirtualBox driver:

$ docker-machine create --driver virtualbox dev

Run this command to set all needed environment variables to run Docker containers:

$ eval "$(docker-machine env dev)"

As you see, this output can be fetched by using the following command, so all these environment variables can be exported manually in case you need:

$ docker-machine env dev

Docker Hub

You need to be registered and logged in Docker Hub to be able to download and run any registered containers. You can create your account directly on Docker Hub website or by running this command:

$ docker login

Just to test your Docker environment, you can run the hello-world container this way:

$ docker run hello-world

If you get this output, it’s working fine:

[...]

Hello from Docker.
This message shows that your installation appears to be working correctly.

Containers

I chose InfluxDB as data store for Grafana, which is a great metrics dashboard and graph editor.

Here’re the containers we will be running in the following steps:

InfluxDB container

Now that your Docker environment is ready, run this command to download and start the tutum/influxdb container and pre-create a testing database named wadus:

docker run -d -p 8083:8083 -p 8086:8086 \
  -e PRE_CREATE_DB="wadus" \
  --expose 8090 --expose 8099 \
  --name influxdb \
  tutum/influxdb

After having checked that the Docker process is running (docker ps) and the container output looks fine (docker logs influxdb), you can reach the InfluxDB Admin page at port 8083:

http://<your_docker_host_ip>:8083/

Or, to dynamically get your Docker host IP and open that URL in your default browser, you can just run:

$ open http://$(docker-machine ip dev):8083

Grafana container

Let’s run the Grafana Docker process linked with the influxdb one:

docker run -d -p 3000:3000 \
  --link influxdb:influxdb \
  --name grafana \
  grafana/grafana

So we now have a Grafana web UI at port 3000. Just open this URL in your browser:

http://<your_docker_host_ip>:3000/

Or run:

$ open http://$(docker-machine ip dev):3000

You can login there by using admin as username and password:

Load InfluxDB with data

You would need to load your data at this point. There’re clients for several languages, I will use the official Ruby client as I’m eventually integrating it in some of my Ruby apps. Its usage is quite simple as well:

require "influxdb"

module InfluxDB
  module Playground
    class Populator
      HOST     = "192.168.99.100"
      PORT     = "8086"
      DATABASE = "wadus"
      USER     = "root"
      PASSWORD = "root"

      def write_data_points
        client.write_points(data_points)
      end

      private

      def client
        @client ||= InfluxDB::Client.new(
          host: HOST,
          port: PORT,
          database: DATABASE,
          user: USER,
          password: PASSWORD
        )
      end

      def data_points
        [
          {
            series: "score",
            values: { value: rand(200) }
          },
          {
            series: "searches",
            values: { value: rand(200) }
          }
        ]
      end
    end
  end
end

# populator = InfluxDB::Playground::Populator.new
# populator.write_data_points

Add InfluxDB data source in Grafana

To access your time series from Grafana, you need to set up the InfluxDB server as a data source. The InfluxDB HTTP API runs on 8086 port, so just remember to set your Docker host IP as part of the URL:

Create Grafana dashboard

Now that Grafana can access InfluxDB HTTP API, you are finally ready to create a Dashboard and visualize your data. As you see, all your InfluxDB database measurements are available to be used on graph queries:

So it’s time to play with your Dashboard and collected data:

That’s all. Your environment is isolated as Docker processes and can be recreated at any time. Now you can see the currently running Docker containers and stop or destroy them:

$ docker ps

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                                                                NAMES
aaea0c5ac8e9        grafana/grafana     "/usr/sbin/grafana-se"   28 hours ago        Up About an hour    0.0.0.0:3000->3000/tcp                                               grafana
f6451be21c8f        tutum/influxdb      "/run.sh"                45 hours ago        Up About an hour    0.0.0.0:8083->8083/tcp, 8090/tcp, 8099/tcp, 0.0.0.0:8086->8086/tcp   influxdb

To stop grafana and influxdb containers:

$ docker stop grafana influxdb

And finally, to stop the Docker machine:

$ docker-machine stop dev

I hope you find this article handy ;)

Setting up a cheap Redmine server using Unicorn and Apache

2013-03-03T16:04:00+00:00

Redmine is an excellent web-based project management tool. It’s open source, free and is built using Ruby on Rails.

We use Redmine as our main tool for planning, issue tracking and documenting processes. It’s an everyday tool so we need to have an always ready Redmine instance within our private domain.

Get a small VPS server

We use an Amazon EC2 t1.micro instance running Ubuntu Precise 64-bit as development server.

This machine is mainly managing a Git server with dozens of repos (and backing them up as a S3 filesystem) and a Redmine instance.

As described on Amazon EC2 docs, this instance type has pretty basic resources, but are enough for running some lightweight processes with low I/O load.

Add your service user

We’re so bad choosing funny names so our service username is service.

Redmine

$ mkdir -p ~/apps/redmine
$ git clone git://github.com/redmine/redmine.git ~/apps/redmine

Install and set up your database engine server (MySQL, PostgreSQL…) and edit the ~/apps/redmine/config/database.yml file to match these settings. Then you’ll be ready to set up the production environment:

$ cd ~/apps/redmine
$ bundle install --without development test
$ RAILS_ENV=production bundle exec rake db:migrate

Unicorn

“unicorn” gem

Add the unicorn gem as an application dependency by adding a Gemfile.local file (unobtrusive way to add dependencies) with this content:

# ~/apps/redmine/Gemfile.local

source 'https://rubygems.org'

gem 'unicorn'

After that you should run bundle install again:

$ cd ~/apps/redmine
$ bundle install --without development test

Filesystem

We do store all shared resources such as config, logs or process pids in a folder named shared:

$ mkdir -p ~/shared/{config/redmine,log/redmine,pid/redmine,socket/redmine}

The previous command will create the following structure under /home/service:

├── shared
│   ├── config
│   │   └── redmine
│   ├── log
│   │   └── redmine
│   ├── pid
│   │   └── redmine
│   └── socket
│       └── redmine

Config

$ curl -o ~/shared/config/redmine/unicorn.rb https://raw.github.com/defunkt/unicorn/master/examples/unicorn.conf.rb

Once you get the Unicorn config example, you will need to tweak a few lines:

worker_processes: Number of Unicorn workers you need.
working directory: working_directory "/home/service/apps/redmine"
pid: pid "/home/service/shared/pid/redmine/unicorn.pid"
socket: listen "/home/service/shared/socket/redmine/unicorn.sock"
log: stderr_path "/home/service/shared/log/redmine/unicorn.stderr.log" stdout_path "/home/service/shared/log/redmine/unicorn.stdout.log"

“Automate everything”

We put all service-related scripts in the ~/script directory. These commands might help you on launching and stopping Unicorn processes:

cd /home/service/apps/redmine && unicorn_rails -c /home/service/shared/config/redmine/unicorn.rb -p 5000 -E production -D

Command explanation:

-c sets the config file (/home/service/shared/config/redmine/unicorn.rb)
-p sets the port of the master Unicorn process (5000)
-E sets the environment (production)
-D daemonizes the command

# ~/script/stop-redmine-unicorn

kill -QUIT $(cat /home/service/shared/pid/redmine/unicorn.pid)

Because Unicorn is Unix you can send a QUIT signal to the master process to stop all its workers.

Apache

Modules

You will need to enable some Apache2 modules:

sudo a2enmod rewrite
sudo a2enmod proxy
sudo a2enmod proxy_balancer
sudo a2enmod proxy_http

Proxy Unicorn processes

Now we have to set up a new VirtualHost as a proxy balancer of the master Unicorn process running at 127.0.0.1:5000:

Note that Apache logging was disabled for reducing I/O load. Feel free to set it up if your resources are not being affected by I/O operations.

Applying it all

After enabling the new VirtualHost and restarting the apache2 service, a proxy will be listening for processes on the specified host and port.

Now run the Unicorn process as shown above (launch-redmine-unicorn script) and Redmine application should start and be served through the new VirtualHost.

Now it’s time to do some tests in order to adjust the number of Unicorn workers you need to have running on your server.

Bonus: Setting up Nginx as a frontend of Unicorn

As some of you have mentioned, Nginx is generally a better choice for micro instances. It consumes much less RAM and it’s faster than Apache due its event-driven approach.

Setting up Nginx instead of Apache2 as a frontend of Unicorn processes is trivial too so there we go:

First of all, ensure you have defined the Unicorn socket path on unicorn.conf.rb (listen option), so your socket can be located in a path like this one: /home/service/shared/socket/redmine/unicorn.sock.

Then, we’ll tweak some options from the sample nginx.conf file shipped with Unicorn in order to serve our Unicorn processes:

Tweaks explained:

UNIX domain socket: server unix:/home/service/shared/socket/redmine/unicorn.sock fail_timeout=0; (L8)
Name and proxy the upstream server: upstream redmine_unicorn (L2) and proxy_pass http://redmine_unicorn; (L78)
Site settings: server_name (L30) and statics root path (38)

Thank you for all your comments.

Paperclip defaults for Amazon S3 virtual hosted-style requests

2012-12-07T16:47:00+00:00

Paperclip is a great gem for adding file attachments to your Rails models. It ships with some storage adapters including Amazon S3 but the documentation isn’t totally clear for virtual hosted-style requests.

If you need to use classic path-style requests like http://s3.amazonaws.com/yourbucket, add these defaults to your environment file:

# config/environments/production.rb

config.paperclip_defaults = {
  :storage => :s3,
  :s3_credentials => {
    :bucket => ENV['AWS_BUCKET'],
    :access_key_id => ENV['AWS_ACCESS_KEY_ID'],
    :secret_access_key => ENV['AWS_SECRET_ACCESS_KEY']
  }
}

Otherwise, if you need to use virtual hosted-style requests like http://yourbucket.s3.amazonaws.com, you must specify the path and url options:

# config/environments/production.rb

config.paperclip_defaults = {
  :storage => :s3,
  :url => ":s3_domain_url",
  :path => ":class/:id.:style.:extension",
  :s3_credentials => {
    :bucket => ENV['AWS_BUCKET'],
    :access_key_id => ENV['AWS_ACCESS_KEY_ID'],
    :secret_access_key => ENV['AWS_SECRET_ACCESS_KEY']
  }
}

Important notes

For now (3.3.1) you will get a Paperclip::InfiniteInterpolationError exception if the path option is not specified.
The value of the url option must be ":s3_domain_url" as a string, not as a symbol.
The path option is fully customizable. The shown pattern will produce filepaths like http://yourbucket.s3.amazonaws.com/images/1.thumb.png.