Forem: Oriol Gual

Talk Club Sessions: #1 Dark patterns

Oriol Gual — Mon, 23 Sep 2019 09:28:23 +0000

Originally published at Codegram's blog

From Lunch talks to The Talk Club™

During this year we had a few posts on the lunch talks series: every two weeks one of us would prepare a video playlist around a topic and then we watched the videos during our lunchtime.

It was a nice experience but it had some issues:

Only the people that were at the office could watch the talks at the same time
We were forcing everyone to do the same at the same time, not having much flexibility
Not a lot of discussions sparked since we didn't have a lot of time after watching the videos

For these many reasons, we decided to try a new approach: The Talk Club! It's like a book club but not limited to books: anything we can learn from can be discussed.

Instead of forcing everyone to do the same altogether, we propose a date to talk about an interesting video, article or piece of technology. People consume the content at their own preferred time and pace, take some notes, prepare some questions or topics to talk about, and then we have a nice chat in a remote-friendly meeting.

Dark patterns

In this first session we talked about Dark Patterns: User Interfaces Designed to Trick People:

Dark Patterns are tricks used in websites and apps that make you do things that you didn't mean to, like buying or signing up for something

This video by Harry Brignull from 2014 introduces the concept of Dark Patterns, it's just 30 minutes long and a highly recommended watch. If you are in a hurry or just want a a compact and short version you can try How Dark Patterns Trick You Online from Nerdwriter.

This isn't a new topic, but it was nonetheless interesting. We spent over an hour discussing the various patterns and discovered we've also resorted to them in some occasions.

The conversation triggered some interesting topics and questions:

Should there be an ethics code for the industry? If so, how could it be even implemented?
How can we persuade our own clients not to use this kind of practices? Especially when they are so effective
As software developers, how should we deal when a manager tells us to implement a dark pattern? Could I lose my job if I object to do it?
When working in Decidim, we were able to say no to some features since we were backed by its social contract. Having such contracts empowers developers into taking responsibility and prevents discussions about whether something should make into the product or not
In other industries, such as food or ads, there are laws against what could be considered dark patterns, would it be possible to create similar laws for the digital world?
We (as an industry) seem to be obsessed by metrics, and making every decision based on how well are we performing on said metrics. This seems to push people into using more doubtful techniques to keep the numbers growing, even at the cost of the user experience (see Goodhart's law)

As you can see, we didn't change the world or even get some answers, but I couldn't be happier with this first edition. We had a very nice chat and it made us think and reflect on our work. I'm sure these conversations will have an impact in our future work and I'm eager to share more experiences like this in the upcoming months, I highly recommend trying this with your team!

Building a Ruby Serverless CI & CD pipeline

Oriol Gual — Thu, 29 Aug 2019 09:14:02 +0000

Originally published at Codegram's blog.

When facing a serverless project, the last thing we probably want to worry about as developers is infrastructure or deployment. We just want to make sure that as soon as we are certain our app is working OK, it is deployed as easily as possible. This could also be applied to any kind of project of course, but I think it fits specially well in a serverless one.

In this example, we're going to use the Serverless framework, which already does a lot of the work, but I still found myself repeating the same tasks and code between different projects each time I had to create the continuous integration & deployment pipeline.

The pipeline

So, how should this pipeline look? Which steps do we want to have to make sure everything works OK? To me, it should look something like this:

The developer works on a new feature on a new Git branch.
They create a new Pull Request to keep pushing the changes.
A Continuous Integration system runs the test suite and maybe some linters.
When the Pull Request is approved and reviewed by their peers, it gets merged to the main branch.
The Continuous Deployment system kicks in (which can be the same as the CI) and deploys the new features.

After repeating this process in different projects, I thought it was time to abstract some of the common code and best practices like dealing with dependencies, CI cache, building, deployment and so on.

A real world example

Continuing from a previous post on how to create a Serverless GraphQL API with Ruby, I updated the project to add some tests and auto-deployment with CircleCI. Check out this pull request to see how easy it was!

To start, we'll need a CircleCI account and setup the project with it. Then add the AWS credentials to Circle so it can be automatically deployed. I recommend following these instructions to create an IAM user for your project.

To add the AWS credentials go to the project's settings page, and add the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY variables with the values you goot from the AWS console. Since this are the default environment variable names, Serverless will use them when deploying.

After that, we need to add CircleCI's configuration to the project:

.circleci/config.yml

version: 2.1

  orbs:
   serverless-ruby: codegram/serverless-ruby@0.0.3

  workflows:
   main:
     jobs:
       - serverless-ruby/test
       - serverless-ruby/deploy:
           requires:
             - serverless-ruby/test
           filters:
             branches:
               only: master

This file uses our Circle CI Serverless Ruby orb (more on this later) and then sets a workflow with two jobs: one to run the test suite and one to deploy the code when it's merged to the master branch.

Finally, we need to tune the serverless.yml file in order to get smaller builds with just these lines:

serverless.yml

package:
  exclude:
    - '**'
  include:
    - app/**
    - vendor/**
    - '*.rb'

These lines tell the Serverless framework to exclude all the files in the root directory and only include our application code at app, the packaged gems at vendor and all Ruby files at the root, since there's where app.rb is located (the project's entrypoint; the file AWS Lambda calls to process each request).

That's it, we now have a fully CI & CD serverless pipeline 🎉.

CI & CD process explained

Early on I mentioned that we were using a CircleCI orb. For those who don't know: orbs are a way to share common configuration, jobs, commands, etc. in a CircleCI configuration file. This way you don't have to repeat the same code and setup between projects and you can benefit when an orb is updated. We created it not only to avoid repeating code but also to share some best practices and solve common issues in this kind of projects.

In the example project, previously to using the orb, the deploy process was far from ideal. Lambda needs to package all your code and dependencies into a single ZIP file and since we're in the Ruby land this means packaging also our gems. Usually when using Bundler all your gem sources are stored in your home directory, but this doesn't work when you need to include them in the ZIP file. So what I needed a Serverless plugin to hook into the package step, run bundle install --deployment to include all the gems content at the project folder, then deploy and then cleanup the mess by removing the vendor and .bundle directories from the project root.

This approach was quite prone to errors since I was deploying from my own computer and the gem dependencies weren't built in the same environment they would run.

So, what does the orb do?

Builds the gem dependencies using Docker, this allows having gems with native extensions since they'll be compiled with the same environment as AWS Lambda.
Efficiently manages all the caches so the builds are fast between runs and you don't lose time waiting on them.
If your project uses DynamoDB, it will install the dependencies and start a database before the test suite runs.
Runs the test suite with rspec and uploads the test results using RspecJunitFormatter
Deploys the project with serverless and excludes all test and development dependencies with each commit to master.

All these steps could be migrated to your favourite CI system, as they don't depend on CircleCI.

I'm very happy with the end result, now our Serverless Ruby projects are deployed blazingly fast and with the certainty that everything is working OK. An improvement could be creating different deployments for each Pull Request so we don't have to deploy development environments from our computer, but this is a story for another time!

Ruby & AWS Lambda, 💖 BFF 💖

Oriol Gual — Wed, 02 Jan 2019 10:00:00 +0000

Originally published at Codegram's blog

As a Serverless enthusiast at Codegram it was about time I published a new blog post since AWS Lambda has introduced official support for Ruby 🎉.

You can read more at the official release blog post which also has an example Sinatra app to get started. If you want an in-depth review of the example and release, I recommend this nice review from EquiValent.

I was thrilled to learn that I can finally use Ruby with Lambda, but using Sinatra as an example feels wrong. If you want to build an API with it, you would want to have API Gateway do all the routing and request handling. Adding an extra layer to do the same at the application level is unnecessary and seems like an anti-pattern (I understand it’s used as an example of migrating microservices, but it’s still confusing).

After talking about it with my fellow Codegrammers I decided to build a small proof-of-concept GraphQL API with Ruby and Lambda, using Serverless to simplify the deployment and infrastructure, without Sinatra, Rack or any boilerplate.

The objective was to demonstrate that you can build an API and almost forget that you’re actually dealing with web requests, just focus on the GraphQL schema and the business logic. How does it look like? There are three key elements: serverless.yml exposes our function through an HTTP POST:

service: serverless-ruby-graphql

provider:
  name: aws
  runtime: ruby2.5
  region: eu-west-1
  stage: dev

functions:
  api:
    handler: app.request
    events:
      - http:
          path: api
          method: post

plugins:
  - serverless-hooks-plugin

custom:
  hooks:
    package:initialize:
      - bundle install --deployment
    deploy:finalize:
      - rm -fr .bundle
      - rm -fr vendor
      - bundle install

app.rb handles the incoming requests and delegates all the work to GraphQL Ruby:

require 'json'
require_relative "app/graphql/schema"

def request(event:, context:)
  puts "Received Request: #{event}"

  body = Schema.execute(event["body"]).to_json

  {
    statusCode: 200,
    body: body
  }
rescue StandardError => e
  puts e.message
  puts e.backtrace.inspect

  {
    statusCode: 400,
    body: JSON.generate("Bad request, please POST a request body!")
  }
end

And finally, app/ a folder with all the GraphQL schemas and models:

https://github.com/oriolgual/serverless-ruby-graphql/tree/master/app

Although this works OK, keep in mind that it is not production-ready code.

Let's build everything with Lambda

Well, maybe not. Building things with AWS Lambda and Ruby is straightforward, but would I build my next GraphQL API with it? Probably not.

I’m not entirely sold on using AWS Lambda with user-facing APIs; response times are too unpredictable and quite high (yes, even if you keep your Lambdas warm). Things get [even]((https://www.robertvojta.com/aws-journey-api-gateway-lambda-vpc-performance/) slower if your Lambda needs to access resources inside a VPC (which is necessary if you want to access a database for example).

I really like Lambda, but I think it shines when used to respond to events (such as S3 uploads or Kinesis streams) where you don’t really care about some extra latency but scalability can be an issue.

I’m eager to try something similar with Knative, Kubeless or OpenWhisk. So far I’ve only used AWS Lambda, and I’d like to compare it to other solutions and get a better idea whether it would be a good option to deploy serverless, user-facing APIs.