Our Blog

The GraphQL gem is a great tool for any Rails developer who wants to add a full-​featured GraphQL API to their Rails applications.

I have been using GraphQL to serve an API in one of my Rails applications since late 2017 and have been very happy with the features and performance provided by the gem, but some of the domain-​specific syntax for building out my API schema never felt quite right when compared to the other Ruby code I was writing in my projects. Fortunately, the 1.8.0 release of the GraphQL Ruby gem brought with it a new default class-​based syntax while remaining compatible with existing code that predated the change.

The Class-based API guide that accompanied the changes does a good job of describing the upgrade path for developers who need to convert their existing schemas. The old .define syntax is eventually going to be removed with version 2.0 of the gem, so I was interested in converting my existing API over to the new style, both to see what benefits the newer syntax provides and to ensure that the API schema remains compatible with future releases of the gem.

The GraphQL gem provides some rake tasks like graphql:upgrade:schema and graphql:upgrade:member for automatic conversion of the older-​style .define files to the newer class-​based syntax. It worked quite well for updating my type definitions, but I also make heavy use of resolvers for containing the logic needed to return values in my GraphQL fields, and there was no way to automatically convert those files.

I found that the process of manually converting my resolvers was pretty straightforward and provided some benefits by cleaning up my QueryType file that was starting to look a little unwieldy.

Here is a before and after for comparison:

Old pre-1.8 '.define' syntax for types:

# app/graphql/types/query_type.rb
Types::QueryType = GraphQL::ObjectType.define do
  description 'Queries'

  field :instructor_names, types[types.String] do
    description 'Returns a collection of instructor...

I don’t consider myself a security expert. Still, to my surprise, I was asked to give a talk about security to all the End Point developers. Obviously I realized too late what I was getting myself into! Such an audience is not only pretty large, it is also challenging, many are more competent than me, and the risk to bore them is very high. Yet, the slides were prepared, the talk was given and the feedback was good.

It goes without saying that a broad, generic training about security, which still can give something to the listener, can’t be really improvised.

The platform for the talk was the OWASP Top Ten 2017 Project, which discusses the most critical security risks to web applications.

OWASP stands for Open Web Application Security Project and describes itself as “an open community dedicated to enabling organizations to develop, purchase, and maintain applications and APIs that can be trusted.” Its website provides plenty of resources to the developers.

The Top Ten consists of 10 broad classes of vulnerabilities. The data behind that comes from specialized firms and surveys, gathering information from 100,000 real-world applications and APIs. Some of these classes are very broad and have a taxonomic value. Saying, for example, “Broken access control” or “Security misconfiguration”, doesn’t say much what you are doing wrong. It still reminds us that a lot of things can actually go wrong and that when working on a service you should ask yourself how are you doing with regard to security.

The current (2017) Top Ten classes are:

1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with Known Vulnerabilities
10. Insufficient Logging & Monitoring

I’m not going over the Top Ten in detail like I did at the training, but I’m going to leave here a couple of brief notes.

Injections: in my naivety I was convinced that this...

I’ve always been an animal lover. I’ve currently got a dog, two cats, bees, and a flock of chickens in my tiny suburban home and I would get more if I could. Over the past few years I’ve taken up an interest in fostering animals through our local animal shelter. Above are our current fosters, two St. Bernard mix parvo pups.

I’m always looking for opportunities to do something in the community but as a busy mom with a full-​time job, it can be difficult to fit volunteering into your schedule. What I’ve discovered is that animal fostering is a great volunteer job for someone that works from home.

How Does It Work?

Our local shelter has a list of foster volunteers who’ve completed their application process and requisite trainings. When they have an animal or group of animals that needs to be out of the shelter for a certain amount of time, they email everyone with a description of the foster. You review the information and decide if you’re a good fit.

We’re very lucky in that our local humane society provides all the food, bedding, medicine, and instruction you need. Your job is to take care of the animal or litter, report back to the shelter as needed, and return the animal when it is ready to be adopted by the community at large.

These two parvo puppies came to stay with us. Parvo is very contagious and affected animals have to be cared for outside the shelter for the other animals’ safety.

Snuggle Breaks

Animal fostering is a really nice way to give yourself breaks during the day. When I worked in the office, I always liked to make the rounds to the water cooler and chat with coworkers. Having animals around can help you combat some of the isolation and loneliness that comes from a solo remote office.

Just a few minutes of petting a kitten or playing fetch in your backyard with a bored pup is a nice break from work and can help you recharge your brain juices to tackle the next item on your to-do list.

This older bonded pair of dogs came to stay with us...

Photo by bradleypjohnson · CC BY 2.0

It should be of little surprise that on January 14, 2020, after a decade of Windows 7, Microsoft will stop providing security updates and support for this older operating system. Windows 7 was released in 2009, and due to its stability enjoyed many years as the go-to operating system for home and business alike.

Even now, it is estimated by NetMarketShare that over 40% of businesses still rely on it. Despite Microsoft having ended mainstream support for Windows 7 in 2015, it still offered extended support because of the operating system’s popularity, and the generally slow adoption of newer releases. However, that support shall soon end, as will support for Windows Server 2008 R2 (release 2), which also remains in wide use. Organizations of all kinds will need to upgrade to newer operating systems to remain secure.

The corporate adoption of Windows 8 and 8.1 may have been slow in part due to Microsoft’s radical changes to the user interface, such as replacing navigation menus with information-​filled “live” tiles. Windows 10, however, was designed as a compromise, providing a Windows 7-​like Start menu, while preserving the live tile interface for accessing applications and services from the desktop. There are many compelling reasons for moving from Windows 7 to Windows 10. The most notable is that Windows 7 will no longer receive any security updates, creating serious security risk and compliance issues.

In 2018, Microsoft adopted a Semi-​Annual Channel (SAC) governed by the Modern Lifecycle Policy. This means that feature updates are released to the public twice a year, around March and September. Updates are cumulative. Updating to these releases is required to remain eligible for support from Microsoft. Security updates are released monthly and quarterly as rollups, and critical updates are released as needed. This is part of Microsoft’s plan to minimize vulnerabilities and security exposure in an ever-​changing digital...

Photo by Andrew E. Larsen · CC BY-ND 2.0

Right, so, show of hands: How many of you work on some bit of web code by doing a git clone to your own laptop, developing the feature or bug fix, running through manual testing of the app until you’re happy with it, and off it goes back up to the repo when done? I’m curious, and I have a few questions for you:

• Have you ever had a bit of code that worked locally, but didn’t in production because of some difference in systems, dependencies, or something else in the stack?
• How do you show off your work to a client or management for approval? Can you demo several alternate changes to the same site at the same time?
• How do you bring in coworkers to “look over your shoulder“ and help with something, especially ones that are far away?
• How do you get a new coworker up to speed if they’re doing development themselves?
• If you’re working on multiple things, do you create multiple clones?
• How’re your backups?

Are you fidgeting nervously thinking about that? Sorry. ☹ But also, check out this little thing: DevCamps. It’s been an End Point staple for quite a while now, so if you’ve read our blog before you might have heard about it.

Long story short: In addition to any local development you do, this system will spin up your own little environments (“camps”) on a remote development server. Each camp includes a checkout of the code, separate httpd/​nginx and app processes, and a dedicated database with a clone of the data. What’s that all mean?

• Well, figuring that dev server is configured the same, you’ll be working right in a stack identical to production.
• Each camp gets its own port, so you can link your beautiful results to someone and they’ll see exactly what the site will look like when deployed.
• Bring coworkers in to a shared tmux session for code review or pair programming.
• And if they just can’t resist working on the same project they can create their own camp, without having to install dependencies and get the stack operational...

IBM Model M SSK by njbair, used under CC BY-SA 2.0 / Cropped from original

Awesomplete is an “Ultra lightweight, customizable, simple autocomplete widget with zero dependencies, built with modern standards for modern browsers.”

Awesomplete caught my attention when I was looking for a lightweight autocomplete implementation to add to an existing, heavily styled form in a Vue.js single-​file component. There are no fewer than 10 options on the Awesome Vue.js list of autocomplete libraries, but many of them brought their own dependencies or custom styling and I was looking for something simpler to add autocomplete features to my form.

I have created a live JSFiddle demo showing an implementation of Awesomplete in a Vue.js app, but the remainder of this post contains more details about adding Awesomplete to a single-​file component in a larger Vue application.

Here is a screenshot and sample code for a simplified version of the Vue single-​file component that I was working with:

<template>
  <div>
    <h2>Search by Name</h2>
    <p>
      <em>
        Options: {{ names.join(', ') }}
      </em>
    </p>

    <form>
      <input
        id="name-input"
        placeholder="Enter a name"
        type="text"
      >
    </form>
  </div>
</template>

<script>
export default {
  data () {
    return {
      names: [
        'Colin Creevey',
        'Seamus Finnigan',
        'Lee Jordan'
      ]
    }
  }
}
</script>

In my actual application I was populating the data object with API data via vue-apollo, but I’ve hard-​coded the array of strings here for simplicity.

Adding autocomplete to my form with Awesomplete was as easy as adding the package to my project with yarn awesomplete and then updating the Vue component to load the library and attach it to my form:

<template>
  ...
</template>

<script>
import Awesomplete from 'awesomplete'

export default {
  data () {
    return {
      names: [
        'Colin Creevey',
        'Seamus Finnigan',
        'Lee Jordan...

One of our clients had a Java-​based application stack on Linux that connected to a pretty old version of SQL Server on Windows. We wanted to migrate the entire system to a more consistent unified stack that developers are efficient with, and that is current so it receives regular updates.

We decided to migrate the database from SQL Server to PostgreSQL on Linux because porting the database, while not entirely quick or simple, was still much simpler than porting the app to .NET/C# would have been. Rewriting the application would have taken far longer, been much riskier to the business, and cost a lot more.

I experimented with a few approaches to the migration and decided to go with the process of schema migration and then the data migration approach which is referred to on the Postgres wiki. Let’s walk through the process of migration step by step.

Schema Migration

A schema of the SQL Server database tables and views needs to be exported to perform schema conversion. The following steps will show you how to export the schema.

Export SQL Server Database Schema

In SQL Management Studio, right click on the database and select Tasks → Generate Scripts.

Choose “Select specific database objects” and check only your application schema Tables (untick dbo schema objects and others if any).

Ensure that “Types of data to script” in advanced options is set to “Schema only”.

Review and save the database tables schema file tables.sql. Use WinSCP and public key auth to transfer tables.sql to the Linux server.

Convert Schema from SQL Server to Postgres

sqlserver2pgsql is a good migration tool written in Perl to convert SQL Server schemas to Postgres schemas. Clone it from GitHub to your database server and execute the following commands to convert the tables schema:

$ git clone https://github.com/dalibo/sqlserver2pgsql.git
$ cd sqlserver2pgsql
$ perl sqlserver2pgsql.pl -f tables.sql -b tables-before.sql -a tables-after.sql -u tables-unsure.sql

The converted...

In 2017, End Point donated a Liquid Galaxy to The Institute of Pure and Applied Mathematics (IMPA) in Rio De Janeiro. The Institute is home to VISGRAF, a laboratory specializing in computer graphics research, including AR, VR, visualization, and computer vision.

IMPA recently formed a partnership with a leading Brazilian cultural institution, the Moreira Salles Institute (IMS). The IMS stewards a vast collection of culturally important Brazilian photography, music, literature, and art. IMS moved to collaborate with IMPA because of its core mission of promoting broad access to these historically valuable artifacts.

The head of VISGRAF, Professor Luiz Velho, views the partnership as a way of empowering Brazilian culture. “The IMS collection is invaluable, and we can do unprecedented things with it,” he said in a press release. Researchers from IMPA are working to geolocate the photos, analyze them with computer vision, improve their resolution, and enable immersive engagement with them on the Liquid Galaxy.

Professor Velho has co-authored an interesting working paper with Julia Giannella of IMPA discussing how IMPA and IMS can take advantage of the Liquid Galaxy. The paper goes into detail on how our Content Management System (CMS) can enable curators and researchers to present the IMS’ collection in novel ways. It also describes the physical setup of the Liquid Galaxy at IMS, and discusses how applications enabled for the Liquid Galaxy, like Panotour and Sketchfab, will contribute to the partnership’s work.

We are supporting their Liquid Galaxy use and look forward to our continued collaboration with this talented team of researchers.