Our Blog

It’s day one of RailsConf 2018, and I’m in Pittsburgh with baby Ingrid (daycare FTW!). This is my 8th time at RailsConf and third time with a kid (SELECT DISTINCT kid FROM skardals). In my first few years of attendance, starting in 2009, I absorbed much more on the technical side, but the talks that have struck a chord in recent years of attendance have been more on the side of the human element of software and software engineering.

Concept Compression

DHH started the day with the opening keynote, and I perceived the main focus of his talk to be the idea of “Concept Compression”. Ruby on Rails has spent many years compressing concepts (e.g. ORM) to lower the barrier to entry. In theory, this should allow more diverse people to enter the software field, but the problem is that while we’ve been compressing concepts along our way, we’ve also added significantly to the list of things that developers ought to know before they start coding.

DHH has always been focused on developer happiness in Rails, so to me, this topic was another extension of developer happiness in talking about the progression of Rails over the years. If Rails isn’t careful, we’re bound to repeat mistakes of the past (e.g. too many concepts, too much to know, too much complexity), and the Rails ecosystem could implode, only to see the cycle start up again.

Scaling the Artisan

One of the first talks I attended was Scaling the Artisan by Coraline Ada Ehmke. She discussed how we as software engineers are artisans, not scientists, ‘hard’ engineers, or architects. She went through a few examples of the history of artisans and the products they crafted (e.g. screws, swords, guns). In these examples, industrialization and creation of interchangeable parts are just two examples that improved production and allowed artisans to focus on the innovation and creativity rather than production.

She drew many parallels to these historical artisanal practices to software engineering. She then went on to what...

Photo from AMOB

Ruby for many years has been proving to be an amazing language. It’s one of the most popular for creating web applications but also DevOps / systems administration tools.

It seems that languages are naturally finding their own niches. For Ruby it’s what I listed above, while Python seems to work well for computer vision and machine learning.

For performance reasons, some code should never be coded in either one. Topic boundaries are being crossed typically though. You might be working on the web app that does some high performance math in the background. To marry the two worlds, people were successful with creating compiled “extensions”. These extensions are typically coded in C. Both languages along with their interpreters are able to use those using native-to-language constructs.

One good example of this is the great numpy package. It brings high-performance linear algebra constructs that would be impossible to code in pure Python with the same performance.

In the Ruby land, a similar example is the nokogiri gem. It allows very fast XML / HTML processing thanks to the core of its functionality being coded in C.

You might also be working on a Ruby app having a need for a functionality that has already been written as a library with C interface available. One way to use it would be to create an extension that would operate on those external C functions. This involves quite a lot of prep-work though. The RubyGems guides describe the process in detail.

There is one more option and I’m about to show you what it is.

Referencing external functions directly

FFI stands for “Foreign Function Interface”. Most languages have a way to operate with external code (written in another language). The interface for doing so is what’s called FFI. Examples:

• Docs on FFI in Haskell
• Docs on FFI in Python via the cffi package
• Docs on FFI in Ruby
• Docs on FFI in Rust

In this article, we’re interested in using FFI in Ruby.

No matter what the host language, the...

Photo by Matthew Henry of Burst

Russian is Hard

Translation to Russian is tricky, and what’s even more tricky is coding logic to handle localization and pluralization of Russian (especially when you can’t read it). Here, I’ll explain some of the complexities and approaches I used for localization of a Ruby on Rails application.

Pluralization

In general, Rails claims to have good localization and pluralization support, but I found that the support for handling more complex translations required customization. The first thing to note is that pluralization in Russian is not quite as simple as it is in English.

English

In English, we are familiar with pluralization of regular nouns to be appending an ‘s’ to the end of the noun (except for those nouns ending in ‘y’ and ‘o’). Pluralization is irregular in some cases, e.g. “octopus” becomes “octopi”, and Rails can handle some of these special cases for English but may not necessarily understand rules for other languages. See:

pry(main)> pluralize 1, 'user'
=> "1 user"
pry(main)> pluralize 2, 'user'
=> "2 users"
pry(main)> pluralize 1, 'octopus'
=> "1 octopus"
pry(main)> pluralize 2, 'octopus'
=> "2 octopi"

Wikipedia has a thorough explanation of English plurals here for anyone interested.

Russian

Russian pluralization is more complex. In the most simplified terms (from my understanding), the mapping can boil down to:

• where count is zero, word has one ending
• where count is one, word has another ending
• where count is 2–4, 22–24, 32–34, word has yet another ending
• where count is 5–20, 25–30, 35–40, …: word has yet another ending

To accomplish this translation and pluralization in Rails, I implemented the following mapping found here:

{:ru =>  
  { :i18n =>  
    { :plural =>  
      { :keys => [:zero, :one, :few, :other],
        :rule => lambda { |n| 
          if n == 0
            :zero
          elsif
            ( ( n % 10 ) == 1 ) && ( ( n % 100 != 11 ) ) 
            # 1, 21, 31, 41, 51, 61...
     ...

Introduction

The purpose of creating this post is to show how fast can you build web applications with Vue.js on the front-end and Drupal on the back-end side.

Let’s call our project “Awesome Nerds”.

What do we need?

• Debian/Ubuntu system
• Internet
• 30 minutes
• Vagrant & VirtualBox
• Git
• Vim
• Yarn

Step by step

Here’s what we’re going to do:

• Install Vagrant, VirtualBox, and Git
• Setup a new Drupal 8 project that will be our back-end project
• Setup a new Vue.js project that will be our front-end application
• Let’s code

Install Vagrant, VirtualBox, and Git

Open your console and run:

$ sudo apt-get install software-properties-common - getting some common libraries

$ sudo apt-add-repository ppa:ansible/ansible

$ sudo apt-get update

$ sudo apt-get install ansible - installing Ansible

$ wget ‘https://releases.hashicorp.com/vagrant/2.0.2/vagrant_2.0.2_x86_64.deb’ && dpkg -i vagrant_2.0.2_x86_64.deb - installing Vagrant

$ sudo apt-get install dkms

$ deb https://download.virtualbox.org/virtualbox/debian <mydist> contrib

$ wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -

$ wget -q https://www.virtualbox.org/download/oracle_vbox.asc -O- | sudo apt-key add -

$ sudo apt-get update

$ sudo apt-get install virtualbox-5.2 git vim nfs-kernel-server - installing VirtualBox

$ vagrant plugin install vagrant-vbguest

$ curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -

$ echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list

$ sudo apt-get update && sudo apt-get install yarn - installing Yarn

Now we can continue to the back-end project installation.

Install and setup back-end project

Create a new folder for the project:

$ mkdir awesome_nerds && cd awesome_nerds

$ mkdir frontend backend

We need to clone the DrupalVM repository. DrupalVM is a Drupal setup that helps to encapsulate services with Vagrant. Run:

$ cd backend

$ git clone git@github.com:geerlingguy...

Photo by Sarah Pflug of Burst

Recently I was working on a Python script to do some parsing and processing on the output of shell commands in Ubuntu. The output that showed up was truncated.

The below sections will walk through the debugging process to identify the root cause and implement a solution with detailed explanation, using Python 2.

Problem

The following code block shows the output of a shell command which lists the installed packages, name and version, in Ubuntu.

# dpkg -l | grep ^ii | awk '{print $2 "    " $3}'
accountsservice    0.6.35-0ubuntu7.3
acl    2.2.52-1
adduser    3.113+nmu3ubuntu3
ant    1.9.3-2build1
ant-optional    1.9.3-2build1
apache2    2.4.7-1ubuntu4.18
apache2-bin    2.4.7-1ubuntu4.18
apache2-data    2.4.7-1ubuntu4.18
apache2-utils    2.4.7-1ubuntu4.18
apparmor    2.10.95-0ubuntu2.6~14.04.1

The same shell command executes in the Python console but the output shows truncated values for a few packages’ versions, for example, accountsservice, adduser, apache2, etc.

>>> import subprocess
>>> installed_packages = subprocess.check_output(['dpkg -l | grep ^ii | awk \'{print $2 "    " $3}\''], shell=True)
>>> print installed_packages
accountsservice    0.6.35-0ubuntu7.
acl    2.2.52-1
adduser    3.113+nmu3ubuntu
ant    1.9.3-2build1
ant-optional    1.9.3-2build1
apache2    2.4.7-1ubuntu4.1
apache2-bin    2.4.7-1ubuntu4.1
apache2-data    2.4.7-1ubuntu4.1
apache2-utils    2.4.7-1ubuntu4.1
apparmor    2.10.95-0ubuntu2

Root Cause

To identify the root cause of the problem, I started with source command dpkg -l command without any filters and processing. I have noticed two different results for this command, with and without less command. The less command showed the complete result with scrolling as below.

# dpkg -l | less
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                            ...

Photo by Matthew Henry of Burst

Hi! I’m Steph. I’ve been working 10+ years now as a software engineer, and I’ve spent ~4 years of that as an in-house developer at 2 different companies and 7+ years as a consultant here at End Point and as an independent contractor. Whenever I’ve started a new position, I get asked “What’s it like on the other side?” or something along the lines of “Is the grass greener?” I thought my answer to this was good blog fodder, so here we are.

If you google “in-house vs. consultant”, much of the results are written from the perspective of a company looking to hire either in-house engineers or looking to outsource to consulting companies. Here’s my approach to answer the question as it relates to employee happiness, skill development, and job satisfaction.

Working as an in-house engineer

• Working as an in-house engineer can mean that you may focus on one technology (or one web stack) and even one main codebase, although this isn’t necessarily true. When I worked for Backcountry.com a while back, the main application was an ecommerce application running on Interchange, and that’s where I spent most of my dev time. But as my experience grew, I began working on other internal B2B tools as well.
• With a small team, it’s possible you might adopt consistent style rules in the code.
• In an engineering role as an in-house dev, you might not be directly involved in sales efforts of the company.
• With a small, single team, there is only one set of team dynamics that you have to navigate between, which might allow you to build stronger relationships with those team members and understand how to work with those team members efficiently. Of course the disadvantage of this is if you don’t get along with a team member, you should learn how to work with them.
• Working as an engineer for a product company might mean a steady stream of income and less micromanaging of expenses. This might translate to benefits like maternity leave, simply because the revenue...

Search engine optimization (SEO) is critical to the success of your website, and therefore critical to the success of your business. A high Google ranking means more page views—​and more conversions. Google rewards websites that are user-friendly and easy-to-navigate, with fresh content and frequent updates. At End Point, we design with SEO in mind from the beginning of the project to help you get the most value from your online presence.

These are the five main areas that we focus on to improve your ranking:

1. Content Strategy—​You want to provide your users with quality content. We can provide a content strategy to help ensure that your site stays on target, with clear copy, focused messaging, and consistent branding. We’ll help you put together a site that gets visitors where they want to be—​and you’ll reap the rewards with an increase in traffic to your site.

2. Sitemap, Keywords, and Semantic Markup—​We dive into the nuts and bolts of your site to make sure that it can be crawled and indexed easily by Google. We produce a prioritized XML sitemap, relevant, long-tail keywords and metadata, descriptive page headings, titles, and URLs. Your site’s code will utilize HTML5 semantic markup to produce a well-structured, hierarchical document that will be easily read by web crawlers—​and humans, too.

3. Blogging and Social Media—​Keeping your website fresh with new links and content is critical for SEO success. Setting up a blog platform makes it easy to quickly generate new content that can draw more visitors to your site. We can also connect you with social media platforms such as Twitter and Facebook to help carry your messages across the web.

4. Analytics—​Google Analytics allows you to watch in real time how users are finding and interacting with your site. Figure out which pages perform the best, which are underperforming, identify trends in user behavior, and calibrate your site to help users get the most out of their experience.

5. Mobile Support—​With just over half

Photo by Rüdiger Stehn, cropped, CC BY-SA 2.0

Definition

Multi-tenant architecture allows one instance of an application to serve multiple customers/​organizations. Each customer/​organization is called a tenant. Each has its own apparent separate application and is not aware of the other tenants. The tenant has the ability to customize their own UI, users and groups, etc. Every tenant typically has these features:

View: Tenants can define the overall styling to their application.

Business rules: Tenant can define their own business rules and logic for their application.

Database schema: Tenant can define their own database schema (real or apparent) for the application. They can add/​remove database tables, rename database fields, etc.

Users and groups: Tenant can define their own rules to achieve data access control.

Types of multi-tenancy

There are 3 main types of multi-tenant architecture:

(1) Multi-tenancy with a single multi-tenant database: This is the simplest form of multi-tenancy. It uses single application instance and the single database instance to host the tenants and store/​retrieve the data. This architecture is highly scalable, and when more tenants are added the database is easily scaled up with more data storage. This architecture is low-cost due to shared resources. Operational complexity is high, especially during application design and setup.

(2) Multi-tenancy with one database per tenant: This is another type of multi-tenancy. It uses a single application instance and an individual database for each tenant. The scalability of this architecture may be lower and the cost higher than multi-tenancy with a single multi-tenant database because each database adds overhead. We can increase the scalability of this architecture by adding more database nodes but it depends on the workload. Operational complexity is low due to usage of individual databases.

(3) Standalone single-tenant app with single-tenant database: In this architecture...