Mon, 07 Apr 2025 00:00:00 +0300

When I was writing the expiry calculator gem (extracted from a license management system), the library’s main logic has some sort of integration with ActiveRecord, and I needed to verify that the easy way.

Mocking the built-in active record connection pool and tables mapping showed to be cumbersome and may not ideally allow to validate the intended behaviour. Luckily, I found pieces in SO and Github to do the unit testing in few simple steps, with on the fly db (Sqlite). I have put it together in the following guide, polished for Rspec with ad-hoc migration methods.

Steps

1) Adding the required libraries in the dev group of our Gem spec file.

Gem::Specification.new do |spec|
  # ..
  spec.add_development_dependency "activerecord", "~> 7"
  spec.add_development_dependency "sqlite3", "~> 2"
end

2. The db setup logic is extracted in a helper.
Replace posts with your intended model with the attributes (columns) you need.

# spec/support/db_helper.rb
module TestDbHelper
  def establish_coonection
    ActiveRecord::Base.establish_connection adapter: "sqlite3", database: ":memory:"
  end

  def up
    ActiveRecord::Base.connection.create_table :posts do |t|
      t.integer :name
      t.date :ends_at
      t.timestamps
    end
  end

  def down
    ActiveRecord::Base.connection.drop_table :posts
  end
end

3. For convenience, I mixed in the helper in the example and example group classes of rspec.

require "support/db_helper"

RSpec.configure do |config|
  # ...
  config.include TestDbHelper
  config.extend TestDbHelper
end

4. Then, we invoke the db functions.
Also we build an anonymous model in let statements.

RSpec.describe MyGemClass do
  # ...
  context "Arguments" do

    establish_coonection

    before { up }
    after { down }

    let(:model_class) do
      Class.new(ActiveRecord::Base) { self.table_name = "posts" }
    end

    let(:model) { model_class.new(ends_at: Date.today + 10) }

  end
end

5. Lastly, we use the model to test against in our case (calculate here).

it "supports active_record parameter with attr accessor" do
  expect(subject.calculate(model, :ends_at)).to eq(10)
end

Done.

Tue, 12 Nov 2024 00:00:00 +0300

This post reviews four main virtualization options in short.

💡 VM technologies are essentially considered by people when addressing on-premise use cases or when building DR for data centers.

VMware Virtualization

Started at (2003).
Offers type-1 hypervisor that runs on bare-metal called ESXi with minimum disk image footprint (32MB), with resources, storage, and networking capabilities, and UI console (DCUI).

Includes distributed management system (vCenter) for managing ESXi hosts, access control, migration (vMotion), HA, and distrusted resource scheduler (DRS).
vSphere client UI: A web client for managing multiple ESXi hosts and vCenter resources.

Fig.1: Outline setup for VMware.

KVM

Started at (2007).
Linux based kernel virtual machines.
Free and open-source .
Basically, it’s a kernel module that allows the kernel to function as a hypervisor.
Originally designed for x86 processors then ported to others (ARM, ESA/390, PowerPC).
Supports HAV (hardware-assisted virtualization).
Libvirt is an abstraction library which facilitates working with KVM toolchains and its adapters.
License: GNU GPL v2.

Fig.2: KVM Internal Design.

Red Hat Virtualization

Started at (2009).
An enterprise solution based on Linux KVM.
Has integrations with AD and FreeIPA for domain and access control.
Servers management UI.
Superseded by OpenShift, now in maintenance mode since 2020.

Fig.3: RedHat virtual manager UI.

Hyper-V

Started at (2008) by Microsoft.
A native hypervisor for x86-64 systems only.
Separates VMs using isolated partitions running their guest OSs.
A single hyper-v with command line (CMD) is free.
Requires HAV (hardware-assisted virtualization).

Fig. 4: Hyper-V overview.

Fig. 5: Installation screen for Hyper-V 2019.

OpenStack

The largest open source cloud infrastructure solution.
Split to multiple components such as: Cinder (storage), Nova (compute), and Neutron (networking).
OpenStack requires dedicated review for it is own.
The main reference, and here’s a good comparision article between it and hyper-V for virtualization cases.

Fig. 6: OpenStack.

Takeaway:

VMware stands out as enterprise solution for corporate and regularity requirements, especially when the support is a must. Conversely, for small projects and applications, I find KVM-QEMU based setup a good option.

Finally, for building on-premise solution on top of open technologies, OpenStack is the obviously viable option.

Thu, 17 Oct 2024 00:00:00 +0300

This post is a follow up on the previous one where I discussed the concept of infrastructure as code and Terraform. In this post, I will provide few useful notes I took while working on IaC projects, with examples to illustrate the techniques on two of the public providers (AWS / Oracle).

🔖 Note: I'm using whitespace freely to break long lines, which is in most cases not allowed in HCL statements.

Tips and Tricks

Collect informative and actionable details about your environment using data blocks.
Seriously no need to hardcode these ids or names, instead using data blocks is one way to query from the external providers, By that, the automation code quality and modularity increase a bit.

Here are examples showing how to query for some network resources.

 data "aws_vpc" "apps" {
   filter {
     name = "tag:Name"
     values = ["apps-vpc"]
   }
 }

 data "aws_route_tables" "apps" {
   filter {
     name   = "vpc-id"
     values = [
       data.aws_vpc.apps_vpc.id
     ]
   }

   filter {
     name   = "tag:Name"
     values = [
       "*rt-private-a",
       "*rt-private-b",
       "*rt-private-c",
   }
 }

 data "oci_core_drgs" "my_drg" {
   compartment_id = data.comp.id
 }

Introduce variables to dry up and factorize your environment settings.
Conventionally, variables.tf file describes the specification of the configurable variables (type, default, description). Then, the variables are set either in terraform.tfvars file, passed as command arguments, or environment variables.

Reference the vars in your code blocks as follows${vars.my_var}:
```
 # variables.tf
 variable "c_id" {
   type = string
 }

 variable "routes" {
   type        = list(string)
   description = "VPN routes."
   default     = []
 }

 # tunnel.tf
 resource "oci_core_ipsec" "vpn" {
   compartment_id = var.c_id
   static_routes = var.routes
 }
```

Use output to express and state unknown information till after the apply.

 # user input
 output "vpc_cidr_range" {
   value = var.vpc_cidr_range
   description = "IPs CIDR."
 }

 # provisioned resource - aws
 output "main_zone_id" {
   value = try(
     aws_route53_zone.m.zone_id,
     ""
   )
 }

 # provisioned resource - oci
 output "instances_details" {
   value = module.i.instances_summary
 }

Declare a variable with sensitive flag for masking in logs and execution.

 output "auth_token" {
   sensitive = true
   value = random_password.p.result
 }

Add locals to shorten long configuration parts or variables chain.

 locals {
   az = data.
        aws_availability_zone.
        main.name_suffix

   db_name = "${var.prefix]}-db"
   db_admin_user = "postgres"
   conf_id = var.db_config_id

   tags = merge(
     tomap({ Env = var.env }),
     var.tags
   )
 }

Revise the variable types: string, number, boolean, list, map, and object.

 variable "db_ingress_ports" {
   type = list(object(
     { port = string }
   ))
 }

 db_ingress_ports = [
   { port = "5432" }
 ]

Refer to the docs for more.

Loop through repetitive resources using count and count.index

 resource "aws_eip" "eips" {
   count = 1
   tags = merge({
     "Name" =
     "lb_ip_${count.index}"
     }, local.tags)
 }

Utilize hashicorp/random module to generate ids or credentials.

 resource "random_password" "ec2" {
   length = 20
   special = true
   override_special = "@!-=+"
 }

Import child modules into the main module using source attribute from various sources:
local FS, git repository, github, a url, or the public terraform registry.

 # redshift database deployment,
 # via external module from the
 # registry.
 #
 module "redshift-db" {
   source = "terraform-aws-modules/redshift/aws"
   version = "3.4.1"

   cluster_identifier = "rd"
   cluster_number_of_nodes = 2
   cluster_node_type =
     "dc2.large"

   cluster_database_name = "rd"
   cluster_master_username =
     "rd-user"
   cluster_master_password =
     random_password.pass.result

   encrypted = true
   wlm_json_configuration =
     jsonencode([
       { auto_wlm = true }
     ])

   cluster_iam_roles = [
     local.s3_role.iam_role_arn
   ]

   subnets = data.aws_subnets.a

   enhanced_vpc_routing = true
   publicly_accessible  = true
   vpc_security_group_ids = []
   enable_logging = true

   tags = {}
 }

When using multiple modules structure, variables can be passed around in module block.

module "postgres" {
  source = "../base/oci_pg"

  tenancy_id = var.tenancy_id
  db_name = var.postgres_db_name

  tags = var.tags
  # etc ...
}

Use for_each iteration primitives (.key, value.*) for granular data structure looping over sets.

# basic looping.
data "aws_subnet" "subnet" {
  for_each = toset(
    data.aws_subnets.all.ids
  )
  id = each.value
}

# basic looping with mapping.
resource "aws_route53_record" "cns" {
  for_each = {
    for r in var.public_cnames :
    r[0] => {
      target : r[1], ttl : r[2]
    }
  }

  zone_id =
    aws_route53_zone.main.id
  type    = "CNAME"
  name    = each.key
  ttl     = each.value.ttl
  records = [each.value.target]

  depends_on = [
    aws_route53_zone.main
  ]
}

# advanced example.
resource "aws_route" "vpn_routes" {
  for_each = {
    for i in setproduct(
      data.aws_route_tables.p.ids,
      var.vpn_route) :
      "rt-entry.${i[0]}.${i[1]}" =>
      { rt_id = i[0], cidr = i[1] }
  }

  gateway_id =
    aws_vpn_gateway.vgw.id
  route_table_id =
    each.value.rt_id
  destination_cidr_block =
    each.value.cidr
}

review the built-in functions of interest to your configurations:
tolist(), toset(), upper(), join(), lower(), max(), endswith(), chomp(), regex(), map(), reverse(), flatten(), file(), base64*(), timestamp(), and much more.
```
locals {
  prefix = lower(var.acc_prefix)
}
```
```
provider "kubernetes" {
  cluster_ca_certificate =
    base64decode(
      data.aws_eks_cluster.main.
      certificate_authority.
      0.data
    )
}
```
They come in handy and can help solving several problems.
Refer to the docs here.

You can add validation rules and message to your module vars in variables.tf.
Here’s an example:

variable "prefix" {
  type = string

  validation {
    condition =
      length(var.prefix) < 10
    error_message =
      "only less than 10 chars."
  }
}

variable "db_storage_iops" {
  type = string
  default = "300000"

  validation {
    condition = contains(
      ["300000", "750000"],
      var.db_storage_iops
    )
    error_message =
      "Only IOPS: 300K / 750K."
  }
}

Use the state CLI command to show, list, or manipulate the state once needed (e.g. checking existing values, importing directly modified items outside IaC, etc.).

# view the current state items.
terraform state list

# clean outdated state.
terraform state rm \
 "aws_customer_gateway.main"

# importing drifted state.
terraform import \
  "aws_customer_gateway.main" \
  "cgw-new-id-XXX"

Use terraform console to quickly experiment with HCL syntax and explore the current module data.

# testing sorting out lists.
❯ terraform console
>
> tolist(concat(sort(
  ["10.200.18.0/24",
   "10.34.150.0/24",
   "10.10.100.0/25"]
  )))
tolist([
  "10.10.100.0/25",
  "10.200.18.0/24",
  "10.34.150.0/24",
])
>

Final Thought ..

Although, terraform and HCL definition language may have limitation around dynamic behavior sometimes, you will find ways to structure and approach your automation code declaratively, most of the time.

Fri, 31 Mar 2023 00:00:00 +0300

An interesting usecase I have encountered recently is establishing a secure path (bridge) between Traefik as ingress controller and its destination backends.

The post addresses traefik usage within Kubernetes, however it is applicable to other setups.

Case

A flow diagram is probably the way to explain the setup.

The main routing resource is a CRD that resembles the following snippet.

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: web-ingressroute
  namespace: web
spec:
  entryPoints:
  - websecure
  routes:
  - kind: Rule
    match: Host(`web.example.com`)
    services:
    - name: backend-svc
      namespace: web
      port: 443
      scheme: https
      passHostHeader: true
    secretName: web-ingressroute-tls

The secret here web-ingressroute-tls is a standard tls secret for the external route containing the private key, certificate, and ca certificate. Let’s mark it as secret (1).

The target backend is a classic sidecar container “nginx” fronting the main container.

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-conf
data:
  nginx.conf: |
    user nginx;
    worker_processes  3;
    ...
    http {
      server {
        listen 443 ssl;
        listen [::]:443 ssl;
        server_name  _;

        ssl_certificate /etc/nginx/ssl/cert.pem;
        ssl_certificate_key /etc/nginx/ssl/key.pem;

        location / {
          proxy_pass http://localhost:80;
          proxy_http_version 1.1;
          proxy_set_header X-Forwarded-Host $host;
          proxy_set_header X-Forwarded-Server $host;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $http_host;
          proxy_set_header X-Forwarded-Proto $scheme;
        }
      }
    }

The pod is exposed using a cluster service backend-svc as denoted in the ingress-route.

backend-tls contains SSL certificate files that nginx uses and mounts. At the same time, it is intended for traefik to trust as the target certificate. As expected for internal services, this is an automatically rotated self-signed certificate by an internal issuer or “let’s encrypt”. Here is the second tls secret (2).

Initial Approach

First, most resources out there might guide you to explore setting the TLS options of the route:

tls:
  options:
    name: backend-tls-opts
    namespace: web
---
apiVersion: traefik.containo.us/v1alpha1
kind: TLSOption
metadata:
  name: backend-tls-opts
  namespace: web
spec:
  cipherSuites: [...]
  clientAuth:
    clientAuthType: RequireAndVerifyClientCert
    secretNames:
    - backend-tls
  minVersion: VersionTLS12

But that didn’t work.
The router logs shows internal errors (500) when connecting to the upstream (pod IP).

traefikee-ingress-proxy-57.. 10.244.0.128 - - [15/Mar/2023:10:45:50 +0000] "GET / HTTP/2.0" 500 21 "-" "-" 2987228 "web-web-ingressroute-6cd908afc82ca51c00cf@kubernetescrd" "https://10.244.2.105:443" 2ms

This is despite that nginx was functioning fine when forwarded locally.

kubectl port-forward svc/backend-svc 8443:443

Serving requests and SSL/TLS settings were correct. The logs emit success (200) when reached over https. Basically, the backend itself was browsable.

After further review, it turns out that TLSOptions as implemented above was merely for client side certificate when reaching the ingress router, an implementation of mTLS and not our case of TLS passing.

Solution

ServersTransport was what is needed to let traefik trust the backend certificate instead of faulting.

kind: ServersTransport
metadata:
  name: web-transport
  namespace: web
spec:
  certificatesSecrets:
  - backend-tls
  rootCAsSecrets:
  - backend-tls
  serverName: web.example.com

And appending to the route:

serversTransport: web-transport

Of course you may turn off the destination certificate check by setting insecureSkipVerify: true but that would defeat the purpose we aim for, an end to end TLS flow (bridging) !

Wed, 28 Dec 2022 00:00:00 +0300

I have enjoyed reading this piece on stability and reliability by Colm MacCárthaigh. It is part of a concise and valuable series by AWS about the art of system operations collected under the name “Amazon Builders’ Library”.

The comparison between coffee urn and computers when building reliable operational model is perfect and up to the point. Then, three characteristics taken from this analogy are observed: 1. have a simple constant function that does not scale based on load stress solely, 2. no different modes or operational branching, 3. anti-fragility which is the preparations that hold systems reliable when most needed. The author mentions the coined term for these principles on reliability: “Constant Work Patterns”. Route 53 and S3 are presented as use cases that fit and demonstrate the model.

The article has references to other content in the library. I would definitely check them out!

Finally, thanks to whomever shared this recently on HN!

Sat, 08 Oct 2022 00:00:00 +0300

Helmfile is an orchestrator tool for collecting, building, and deploying cloud-native apps. Basically it’s the packager for helm chart based applications.

One of the interesting ideas I came along recently, is utilizing it for working in air-gapped environments, where access to the internet is not feasible.

Use Case

Let’s say you were deploying an application to a Kubernetes cluster. The idea is to package all dependencies and manifests beforehand in a local or control machine, then push the consolidated deployment directory to the offline machine.

The diagram below depicts the flow.

Example Deployment

The script below is a custom version of deploying Dex in offline mode, as an example.

A simplified helmfile would look like this:

# helmfile.yaml

repositories:
- name: dex
  url: https://charts.dexidp.io

helmDefaults:
  verify: true
  wait: true
  waitForJobs: true
  timeout: 600

releases:
  - name: dex
    namespace: dex
    createNamespace: true
    chart: dex/dex
    version: 0.11.1
    values:
      - config:
          issuer:
          {{ requiredEnv "OIDC_ISSUER" }}
          storage:
            type: kubernetes
            config:
              inCluster: true
          oauth2:
            skipApprovalScreen: true
          staticClients: []
          connectors: []

      - ingress: {}

The following script saves archived version of the chart’s assets inside ./output.

# offline.sh
#!/bin/bash

IMAGE_VERSION=v2.34.0
IMAGE=ghcr.io/dexidp/dex
CHART_REPO=https://charts.dexidp.io
CHART=dex/dex
CHART_VERSION=0.11.1

docker pull ${IMAGE}:${IMAGE_VERSION}

# tagging is optional
docker tag registry.local.lan/${IMAGE}:${IMAGE_VERSION} \
${IMAGE}:${IMAGE_VERSION}

docker save registry.local.lan/{IMAGE}:${IMAGE_VERSION} \
-o ./output/images/{IMAGE}:${IMAGE_VERSION}.tar

helm repo add ${CHART_REPO}
helm pull ${CHART} --version ${CHART_VERSION} --destination ./output/charts/

Then, it should be a matter of executing the following sequence to prepare the final build directory:

$ BUILD_TIME=$(date +%Y-%d-%m-at-%H-%M)
$ ./offline.sh
$ export $(cat .env | xargs)
$ helmfile fetch
$ helmfile build \
  > ./output/final-$BUILD_TIME.yml

In case helmfile binary is not available in the target environment, just template plain manifests.

$ helmfile template \
   > ./output/final-${BUILD_TIME}.yml

Finally, on the production node you would run something similar to this:

$ docker load -i ./output/*.tar
$ docker push
$ helmfile sync --skip-deps \
  -f ./output/final-*.yml

# In case `helm` is not available:
$ kubectl apply -f ./output/final-*.yml

As you can see, this method is extensible and can be generalized for any helm-based deployment. For the complete example listing, refer to the github repo here.

Conclusion

Certain security or compliance challenges imposed in air-gapped environments can make it hard to deliver cloud native deployments. Luckily, several CNCF projects (harbor, rancher, k3s, to name few) provide options to tackle such environments. Additionally, the presented approach above is generic for any helm application to be deployed properly in offline mode.

Fri, 23 Sep 2022 00:00:00 +0300

Terraform has emerged as one of the top open source infrastructure as code (IaC) tools, since its initial release by Hashicorp back in 2014.

The design philosophy behind the tool is to have declarative, and stateful representation for the underlying IT infrastructure (whether it be on public, on-premise, or hybrid cloud), which in turns simplify the control, collaboration, and auditing of the cloud resources.

The classical example to show the main idea creating a VM:

provider "aws" { }

resource "aws_vpc" "vpc" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_instance" "this" {
  ami = "ami-026b57f3c383c2eec"
  instance_type = "t2.micro"
  tags = {
    Name = "New example instance"
  }
}

This is not limited to only compute resources, many of AWS services are available as well.

Simplified Workflow

The main workflow is conventionally as follows:

The flow maps cleanly to CLI commands:

terraform init
terraform plan
terraform apply
terraform show

Additional linting commands available as well:

terraform fmt
terraform validate

Disposal of resources is simplified as well (without authoring .tf manifests):

terraform destroy

Structure

It is recommended to factorize input values across environments into variable blocks.
This enhances for security posture as well, like protecting sensitive data.

Moreover, output blocks provide a way to capture and log information after applying state changes.

The minimal structure of managed resources in terraform is shown below:

$ tree
├── main.tf
├── outputs.tf
├── terraform.tfstate
├── terraform.tfstate.backup
└── variables.tf

The variables and output files are separated to organize things up.

The state is tracked in .tfstate file, and managed internally by Terraform.

Providers

The mechanism behind provisioning the intended state of an infrastructure or platform, is performed on by “providers”. They are terraform extensions written in Go language exposing the resource types they implement, and interfacing with the target infrastructure / platform APIs.

provider "aws" {
  region = "us-east-1"
}

The major providers are available on the public terraform registry, along with many platform agnostic plugins, such as Helm and Kubernetes.

Here’s an example for a simple helm releasing technique:

provider "helm" {
  kubernetes { }
}

resource "helm_release" "redis" {
  name       = "redis-instance"

  repository = "https://charts.bitnami.com/bitnami"
  chart      = "redis"

  set {
    name  = "architecture"
    value = "replication"
  }
}

Terraform v.s. Ansible

Compared to Ansible as an orchestration tool on the infrastructure layer, I find that Terraform overall is more expressive and concise to enable building on modules in much elegant and feasible manner, with the excellent readability of HCL and dependency management of plugins.

The state is a major difference to consider here.

Ansible takes a stateless approach by always exchanging the desired state with the target resources in order to know the actual state then apply the delta, if needed. On the other hand, Terraform is stateful and manages the state in local or remote manner.

Summary

All in all, codifying infra and platform layers (e.g. using terraform) can bring key benefits to organizations in adopting the DevOps practices, leading to operational excellence, eventually.

Fri, 18 Feb 2022 00:00:00 +0300

Problem

Sometimes, when working with docker engine on CI systems, certain type of errors could arise from the challenging restrictions in the environment. This is typical due the inherent server-client architecture in docker.

Here’s one of the problems that I’ve seen recently. When a client is connecting to dockerd in order to build an image or pull external images:

failed to prepare a4mv4dh8qcq283c7x47a4nwpg: devmapper: Thin Pool has 161986 free data blocks which is less than minimum required 163840 free data blocks. Create more free space in thin pool or use dm.min_free_space option to change behavior

Analysis

As the log suggests, clearly this is related to the storage limit incurred for the device mapper driver. Here, Thin Pool needs additional space to create and pull newer images but the limit is exceeded.

To diagnose that, check disk usage on the daemon using df -h or docker system commands.

$ docker system info
$ docker system df

Resolutions

A workaround is to increase the volume size if you can.

Otherwise, you can run clean up procedure of outdated and unnecessary images.
Periodically or through cron tab.

 # delete specific images by pattern:
 IMAGES=my-apps
 docker images \
   | grep $IMAGES \
   | awk '{print $1 ":" $2}' \
   | xargs docker rmi

You can delete by label/date filtering:

 # delete 6 months old images:
 docker image prune -a \
   --force \
   --filter "until=4368h"

You may run prune to remove all dangling resources (images, containers, etc.)

 docker system prune

 # This will remove all unused images:
 docker image prune --all

Fri, 24 May 2019 00:00:00 +0300

Using universally unique identifiers (UUIDs) for exposed resource identifiers is more secure, and convenient for database distribution. It is relatively simple to configure Active Record to generate UUID primary keys in migrations.

Setup

Here are the steps:

Setup the default generation inside config/application.rb:

 # config/application.rb

 module SampleApp
   class Application < Rails::Application
     ...
     # Change the primary key
     # default type to UUIDs.
     config.generators do |g|
       g.orm :active_record,
             primary_key_type: :uuid
     end
   end
 end

Enable the database support:

PostgresSQL:

Enable uuid-ossp extension for random :uuid generation at the DB level.

 # db/migrations/xxxxx_enable_uuid_ossp_extension.rb.rb

 class EnableUuidOsspExtension <
       ActiveRecord::Migration[5.2]
   def change
     enable_extension 'uuid-ossp' unless extension_enabled?("uuid-ossp")
   end
 end

For new Postgres versions ( >= 9.4), pgcrypto extension can be used alternatively.

SQLite:

As UUID is not naively available in SQLite.

A workaround is to utilize generic varchar or blob(16) columns instead. Some people have reported they needed to load the adapter file in order for it to work.
SQL Server:

Has :uuid native support (through uniqueidentifier column type) with the generator.

Now newly generated tables will use :uuid by default for primary keys.

# db/migrations/xxxxx_create_customers.rb

class CreateCustomers <
      ActiveRecord::Migration[5.2]
 def change
   create_table :customers,
                id: :uuid do |t|
     t.string :full_name,
              null: false, index: true
     t.string :email, index: true

     t.uuid :ceeated_by, null: false
     t.uuid :updated_by, null: true

     t.timestamps
   end
   add_foreign_key :customers, :users,
                   column: :created_by
   add_foreign_key :customers, :users,
                   column: :updated_by
 end
end

The snippet above shows :uuid type usage for other non-primary key columns too.

In case you don’t require UUID key type, it’s possible to get the integer or bigint types back again:

create_table :cities,
             id: :integer do |t|
  t.string :name
  t.float :population
end

Ordering Results

A drawback of querying UUID-based tables is that ordering is not inferred as with the sequential keys. We have to set it up using default ordering scope, easily:

# app/models/customer.rb

class Customer < ApplicationRecord
 ...
 default_scope -> {
   order(created_at: :asc)
 }
end

Ensure that indices on created_at columns already added for boosted performance.

# db/migrations/xxxxx_add_created_at_indices.rb

class AddCreatedAtIndices < ActiveRecord::Migration[5.2]
 def change
   add_index :customers, :created_at
   add_index :surveys, :created_at
   add_index :more_info, :created_at
 end
end

Keep in mind the additional storage cost of :uuid keys compared to sequential ones, which requires balancing the trade-offs when designing your data models.

Tue, 30 Aug 2016 00:00:00 +0300

In many times you may need to optimze rapidly a bunch of images at your hands. There are handy utilities that can help you reduce image sizes with simple commands in the terminal. The following lists some of these tools:

1. OptiPNG: Advanced PNG Optimizer:

Get it for Mac OS X:

brew install optipng

For Linux Ubuntu:

apt-get install optipng

To optimize an image, run:

optipng <img-name>.png

To wildcard all images recursively in the current directory and sub directories:

find . -iname "*.png" -exec optipng -o7 {} \;

2. jpegoptim:

Install for Mac OS X:

brew install jpegoptim

Install for Linux Ubuntu:

sudo apt-get install jpegoptim

Run the next command to optimize an image, -m controls the image quality (0-100):

jpegoptim -m70 <img-name>

Or optimize all recursively:

find . -iname "*.jpg" -exec jpegoptim -m80 -o -p {} \;

3. gifsicle:

Install for Mac OS X:

brew install gifsicle

For Linux Ubuntu:

sudo apt-get install gifsicle

The commands for single image, and a group of images respectively, are:

# for single image.
gifsicle --batch -V -O2 <image-name>.gif

# to start from cureent dir and go down.
find . -iname "*.gif" -exec gifsicle --batch -V -O2 {} \;

Aliases

Here are some aliases to keep commands nearby for fast run on the active directory images.

Be warn that those (also the previously mentioned commands) all alter the original images.

alias compress_png="optipng -o7 *.png"
alias compress_jpg="jpegoptim -m80 *.jpg"
alias compress_gif="gifsicle --batch -V -O2 *.gif"

You can tweak the optimization level and other options to suit your needs.

ImageOptim

If you’d like to use a GUI application, ImageOptim is a pretty open source one for Mac OS X that supports multiple image formats.

Happy mature optimization :) !