DEV Community: Jorge Alvarez

Developers will become pilots

Jorge Alvarez — Fri, 29 Mar 2024 12:29:56 +0000

20 or 30 years ago pilots where actually flying airliners. They were in charge of all aspects of the fly, taking all decisions themselves.

Today it's the plane itself that takes care of everything and pilots are just supervisors that only take control when there are unexpected conditions.

And that is exactly what is going to happen to developers. To me, that's the perfect analogy.

The AI will take care of most of the work and the developer will be supervising everything.

Image credits

When AI writes code, all code will be open source.

Jorge Alvarez — Thu, 14 Mar 2024 10:01:26 +0000

There is a lot of noise lately about Devin, an AI that can write code with a high degree of accuracy.

We know that AI will eventually write most of the code that companies produce. The only question is not if but when that will happen on a big scale.

The most important change that this will bring is that all code will be open source code.

If I can use an AI to, for instance, create an invoicing software it would make sense that I release that code as open source, and if I don't, somebody else will. Then we enter the same cycle as current open source projects. People add changes, that would be AI generated, or request features that we would ask the AI to implement.

Everybody will have access to any code because code now is a commodity.

We will see that companies that now offer SaaS products will be doing less Software and much more Service.

There will be still plenty of companies that will gladly pay to other companies to review, secure and deploy that open source code for them. But that's old news we currently have many companies that provide services based on open source projects. The difference is that we will be able to generate more open source code and faster.

It is also a big opportunity for small, agile companies that can now offer services that before where only offered by big companies with hundreds of employees. No more you would need 100s of persons to develop and maintain a crm or an erp software, small boutiques will be able to offer those services much more cheaper and efficiently.

As for us developers, there will still be a lot of work for us. It will just be more specialised. No more a 6 months boot-camp will grant you a job as a developer. I think the most demanded role will be someone with a mix of development, dev-ops and product skills. Those profiles will be able to gather good requirements, generate code using the AI, validating it and deploying it in a secure environment.

People who are capable of perform well on all those tasks will be in high demand and less specialised people will have to improve their skills.

In summary: AI will take care of the Software and small boutiques will take care of the Service. SaaS is here to stay.

Find in batches and pluck

Jorge Alvarez — Tue, 02 Jan 2024 16:34:00 +0000

How to use find in batches in Ruby on Rails along with pluck.

class NewYearJob
  def perform
    Employee.active.in_batches do |employees|
      rotate_jobs = employees.pluck(:id).map do |employee_id|
        RotateYearJob.new(employee_id)
      end

      ActiveJob.perform_all_later(rotate_jobs)
    end
  end
end

Normalise array in Rails 7.1

Jorge Alvarez — Tue, 10 Oct 2023 06:07:32 +0000

One of the (many) good features of Rails 7.1 is the normalizes method. This is how you can use it with fields of type array.

In this example there is a field called folders that we want to normalise removing blank entries and ensuring all entries are down cased.

normalizes :folders, with: ->(values) { (values || []).map(&:downcase).reject(&:blank?) }

Requesting a technical challenge is useless and rude

Jorge Alvarez — Thu, 28 Sep 2023 08:43:34 +0000

These are the main reasons why your company should remove the technical challenge step from the hiring process:

1) It's rude.

Requesting people to perform unpaid work in their free time for you is just impolite. Do Not Do That.

2) There is a better way to validate the technical abilities of a candidate: A personal interview.

Talking to candidates not only will help you detect their expertise and knowledge about any technical area but it will also help you detect if that person is a good team player, someone that can work nicely with others. You want to hire people that will get along well with the rest of your coworkers. You don't want to hire divas, no matter how skilled they are.

You can teach people best practices, patterns, technologies.... but you can't teach them manners, attitude, politeness.

3) You will discard good candidates.

Usually the technical challenge is employed as a first filter to remove candidates. Again that is not a good way of doing it. How somebody solves a specific problem is not a very good indicator. Someone that produces a mediocre solution to the challenge may still be a good hiring because they are a good fit for the team (culturally, soft skills...). Maybe the had time constraints and they couldn't deliver the best solution. Probably they are applying to other positions, their current job... Assuming that all candidates can allocate a few hours is just something you should not do.

4) It's them that will change, not you

It doesn't matter how well they organise their code or what standards they use because they will have to adapt and use your company's standards and best practices. You can teach people best practices, patterns, technologies.... but you can't teach them manners, attitude, politeness.

5) That code might not be theirs

People can cheat in the technical challenge but they can't cheat face to face. You never know if that code was actually produced by them or they got help from friends or other sources. When they are in an interview with you there is no way they can cheat.

6) Show them your code.

Instead of asking the candidate to write some code so you can discuss about it, just show them your own code. The same code they will have to work with if they get hired. Ask them about it, what they like, what they don't, what they will change... You will get much more useful insights than reviewing some arbitrary code.

Summary

Unless you want to hire robots that work in isolation you probably want to hire people that are skilled, have good technical knowledge but also good attitude, open, friendly and capable of working on a team. The technical challenge can't help you in any of those areas, on the contrary, it will eliminate good potential candidates.

Integration tests with minitest, Sorcery and Rails 7

Jorge Alvarez — Wed, 16 Aug 2023 13:02:44 +0000

The example app at https://github.com/Sorcery/sorcery-example-app/tree/master does not work for integration tests. Here is a configuration that helps you log in using Sorcery.

Edit your test_helper.rb file

class ActionController::TestCase
  include Sorcery::TestHelpers::Rails::Controller
end

class ActionDispatch::IntegrationTest
  include Sorcery::TestHelpers::Rails::Integration
end

module Sorcery
  module TestHelpers
    module Rails
      # Passwords? Where we are going, we don't need passwords.
      def login_user_post(email, route = nil)
        password = 'top-secret'
        user ||= @user
        user.password = password
        user.password_confirmation = password
        user.save!
        where = route.presence || user_sessions_path
        send(:post, where, params: { email:, password: })
      end
    end
  end
end

And now in your integration files you can log in using the method login_user_post with a user's email.

tests/integration/admin/settings_test.rb

class Admin::SettingsTest < ActionDispatch::IntegrationTest
  class NotManager < Admin::SettingsTest
    def setup
      @user = user(:user)
      login_user_post @user.email
    end

    test 'can not access admin area' do
      get admin_settings_url

      assert_response :redirect
    end
  end

  class Manager < Admin::SettingsTest
    def setup
      @user = user(:manager)
      login_user_post @user.email
    end

    test 'can access admin area' do
      get admin_settings_url

      assert_response :success
    end
  end
end

Write code that helps your users

Jorge Alvarez — Tue, 15 Aug 2023 14:34:03 +0000

We all know web developers that are so busy doing "technical" things that they don't have time to think about end users.

For them development is all about patterns, abstractions, refactors, technical debt (in another post I'll explain why technical debt doesn't really exist)...

Don't be one of those developers.

You write code to solve problems to the users of your application. Every time you are working on something that adds no value to those users you are doing it wrong.

It's been a productive day of work if you have made things faster for your users, if they need to click one less thing to perform their job, if a dashboard has the new data they've been requesting, better accessibility...

You have a job because your application has users. It's those users that pay your salary, not your company.

Prioritise work that improves the life of your users over work that only helps you and your fellow developers. Your priority is to make things easy for the users not for yourself. If you can have both then that's perfect but if you need to choose there is only one right choice.

In an ideal world we have unlimited time and resources but more often than not you need to take decisions. There are trade-offs to be made.

One of things that differentiates a senior developer from the rest is their ability to make those trade-offs. Another one is that they used to have user metrics in their dashboards. Application and server monitoring is absolutely necessary and so it is knowing what users do on your platform. How many times they access the application? What sections do they visit? What actions they perform the most? What reports they use?

Remember, the code you write is just a means to an end: Helping users on their daily tasks. Everything else can wait.

Cover image by: Nikkotations

How to create a secure password that you can remember

Jorge Alvarez — Mon, 18 Jan 2021 11:47:00 +0000

It's the eternal struggle, creating a strong password that is hard to crack yet easy to remember.

We are usually forced to use random letters uppercase and downcase, numbers and symbols and the password should be at least 8 characters long.

All of that is very good for security but very bad for our brains. If you try to remember: HP2Epzo&BTPuyQV chances are that you will end up writing it down on a piece of paper.

So here is the trick I use to generate passwords that are easy to memorize.

Use letters from a sentence

It has the perfect balance between security and rememberability.

Think of a sentence that you remember from a movie or from a song that you like and then use the first letter of each word to create the password.

To add an extra level of security you can:

Use the last letter from each word.
Alternate between the first and the last word.
Substitute one letter with a symbol like: # $ % & * . ,
Add numbers to the sentence if there are none.
Think of a song you don't like yet you know the lyrics instead of one that you like.

... be creative.

These are a couple of examples using Iron Maiden songs.

Fly on you way like an eagle, fly as high as the sun.

The resulting password is: foywlaefahats

Let's improve it a bit:

With an ampersand to join the two sentences: foywlae&fahats

Adding the year that the album was released: foywlae&fahats1983

Another example:

Oh Well, wherever, wherever you are, Iron Maiden's gonna get you, no matter how far.

The resulting password is: owwwyaimiggynmhf

That's a very good password by itself but we can spice it up.

Put Iron Maiden in uppercase: owwwyaIMiggynmhf

Add some numbers and symbols. I'm adding the year that the album was released and changing the first O with an asterisk.

The resulting password is: 1980*wwwyaIMiggynmhf

Summary

As you can see generating secure passwords that are easy to remember is not as hard as it may seems if you are creative.

Anyway what I would recommend you is to use a password manager if you can. Let them generate the passwords for you.

But even a password manager needs a password to open it and also there are other situations like starting a session in your computer, that requires you to enter a password.

With the help of your favorite movie/song and a bit of creativity you can create good passwords that are hard to crack and yet rememberable.

Open Source event tracking and gamification engine

Jorge Alvarez — Fri, 08 Jan 2021 14:43:37 +0000

Siete Valles

The goal of this application is to provide an easy way to integrate user engagement schemas and event tracking into your existent applications.

You can create specific schemas like an onboarding process and keep track of the progress of each individual employee. Or you can implement generic long term schemas and event tracking like tracking the activity of users on a website (articles, comments, likes, etc.).

Use cases and examples

Track important application events.
Measure user's engagement.
Lead users conducting important events like onboarding, placing an order...
Etc.

There are a few implementation examples available.

Technical details

Siete Valles has been developed with Ruby on Rails and it has a full featured Graphql A.P.I.

Detailed documentation available.

Technology

Rails 6.1
Graphql
Stimulus JS
TailwindCSS
Mysql

You can check all my open source projects.

Siete Valles means Seven Valleys and this is where the name comes from.

Svelte Router SPA now supports route localisation

Jorge Alvarez — Wed, 15 Jan 2020 15:15:29 +0000

Today I've released version 5.2.0 of Svelte Router.

It's an easy to use routing library for Single Page Applications developed with Svelte JS.

The biggest feature in this version is support for route localisation.

Features

Define your routes in a single interface
Layouts global, per page or nested.
Nested routes.
Named params.
Localisation.
Guards to protect urls. Public and private urls.
Track pageviews in Google Analytics (optional).
Use standard About elements to navigate between pages (or use for bonus features).

This is an example of how to define routes:

routes = [
        {
          name: '/',
          component: PublicIndex
        },
        { name: 'login', component: Login, lang: { es: 'iniciar-sesion' } },
        { name: 'signup', component: SignUp, lang: { es: 'registrarse' } },
        {
          name: 'admin',
          layout: AdminLayout,
          lang: { es: 'administrador' },
          nestedRoutes: [
            {
              name: 'report',
              component: ReportsIndex,
              lang: { es: 'informes' }
            },
            {
              name: 'employees',
              component: EmployeesIndex,
              lang: { es: 'empleados' },
              nestedRoutes: [
                {
                  name: 'show/:id',
                  component: ShowEmployeeLayout,
                  lang: { es: 'mostrar/:id', it: 'mostrare/:id' },
                  nestedRoutes: [
                    {
                      name: 'index',
                      component: ShowEmployee
                    },
                    {
                      name: 'calendar/:month',
                      component: CalendarEmployee,
                      lang: { es: 'calendario/:month', de: 'kalender/:month' }
                    }
                  ]
                }
              ]
            }
          ]
        }
      ]

What started as a small project has become now a full featured routing library for Svelte applications.

What's next in my TODO is refactoring some parts of the library to make the code easy to read and understand. It has a comprehensive suite of tests so it shouldn't be much of a problem.

If you use it in a project please send me your comments, suggestions and ideas here: https://github.com/jorgegorka/svelte-router/issues

Open source e-commerce Rails 6 & GraphQL with JWT

Jorge Alvarez — Wed, 30 Oct 2019 11:03:04 +0000

Demanda is an open source e-commerce made with Ruby on Rails, GraphQL and JWT.

It started as a student's material for a web development course I teach but it has evolved since.

Whether you are looking for a resource to learn more about GraphQL, Ruby on Rails and JWT authentication or just want a basic e-commerce platform that you can evolve to suit your needs Demanda can help you.

Backend is a ruby on rails well tested application using GraphQL and JWT for authentication.

There is also an example admin interface developed with Svelte JS and Apollo client. It uses TailwindCSS for styling.

I will post in detail about each aspect of the application like authentication, crud, testing, etc.

https://github.com/jorgegorka/demanda

Secure Firestore rules for Firebase

Jorge Alvarez — Tue, 09 Jul 2019 13:02:20 +0000

Firestore rules give us the possibility to configure and secure a Firebase database. In this article you will learn how to create a set of rules that are easy to read and maintain.

All the code mentioned in this article is availaible in the Svelte & Firebase repository and you can download it for free.

Some thoughts on security
Basic rules
- Grant/Deny access to documents
- Use functions to improve clarity
Advanced rules
- Return only a subset of documents
- Allow special permissions to administrators
- Filter by current user
Summary

Some thoughts on security

In a web application we can not trust the client. All the code that is being executed in somebody else's computer can be tampered and hacked.

If we do not configure our database properly anybody will be able to request any data from our database.

All the checks in Firestore rules take place in the Firebase servers so there is no chance for users to change them.

The only information we can trust is the authentication data. After a user successfully log in all comunications between our application and the Firebase database include a token with the session information.

This token is the only valid piece of information that can not be modified by the user.

The token gives us the possibility to save some extra information (user claims) that we can use to improve our rules.

Let's see all this in action:

Basic rules

This is an example of the basic structure for securing a document:

  match /teams/{teamId} {
    allow read: if isSignedIn();
    allow create: if userAndAdmin();
    allow update, delete: if companyAdmin()
  }

Firestore rules have basic read and write rules. Read rules can be broken into get and list while write rules can be broken into create, update and delete.

In the former example we are creating a rule for reads, another rule for create and another one for update and delete

Grant/Deny access to documents

The way to allow access to a document is

allow (read/write): if <condition>;

We just need to define the operation that we want to allow and add a condition. If the condition is true the rule will succeed and the document will be returned to the client. If the condition fails the document will not be returned to the client.

If we have more than one rule for a single document Firebase will succedd if any of the rules return true.

Use functions to improve clarity

A good tip to help you improve clarity and reuse code is to use functions to define your logic and use that functions in the rule definition.

Let's create our first rule. We want visitors to be able to read the contents of the teams document only if they are logged in.

This is how we would create that rule:

  match /teams/{teamId} {
    allow read: if isSignedIn();
  }

and this is the function we create:

  function isSignedIn() {
    return (request.auth.uid != null)
  }

We are checking the request object, available in all rules, to see if there is an auth uid. If the request has been made by a logged in user auth.uid will return the user id of the user. It will be empty otherwise.

Now with this rule in place only logged in users will be able to read the teams documents.

Advanced rules

Now that we know how to create basic rules let's add some more rules to improve the security of our database.

Return only a subset of documents

With the only rule that we've created so far if you are logged in you have access to all the teams in our database. In our application users belong to a company so it makes sense that they can see only teams that belong to their company.

Let's create a function that checks that.

  function userBelongsToCompany() {
    return request.auth.token.companyId == resource.data.companyId
  }

I've mentioned before user claims. Those are pieces of information we can add to the session token with useful data. In our case when we create an employee we add two pieces of information: the Id of the company and the role. Check this code to see how to add custom user claims.

We are comparing the request.auth.token.companyId with the resource.data.companyId. In resource.data Firestore gives us access to each document that will be returned. If the companyId of the document does not match the companyId of the user the document won't be returned.

Now that we have the userBelongsToCompany function we can change our rule to use it:

  match /teams/{teamId} {
    allow read: if isSignedIn() && userBelongsToCompany();
  }

Now in order to read a document, or a list of documents two conditions must be met. The user must be logged in and the companyId of the user must match the companyId of the documents returned.

Allow special permission to administrators

Roles are a very common feature in many web applications. This is how we can apply roles to our rules :-).

  function userIsAdmin() {
    return request.auth.token.role == 'admin'
  }

We have another user custom claim defined called role. It's now very easy for us to check if the user is an admin.

For the sake of clarity we add another function like this:

  function userAndAdmin() {
    return isSignedIn() && userBelongsToCompany() && userIsAdmin()
  }

Now if we want that only admins would be able to create new teams we add a this new rule.

  match /teams/{teamId} {
    allow read: if isSignedIn() && userBelongsToCompany();
    allow create: if userAndAdmin();
  }

Only admin users that belong to our company can create new teams. Regular users can only read them.

Filter by current user

What if we want that regular users can edit their own documents but not others, while admins can edit any document? ... Rules to the rescue.

  function adminOrOwner() {
    return userBelongsToCompany() && (userAndAdmin() || resource.data.employeeId == request.auth.uid)
  }

I bet you saw that comming, right? We check a field in the data returned called employeeId and compare it to the id of the logged in user. If they match the rule will be successful. If they don't it would still succedd if the user is an admin. Whether the user is an admin or not they must belong to our company so the first check is the userBelongsToCompany function.

This is how we would implement that rule if we want employees (for instace) to be able to edit their own records.

  match /employees/{employeeId} {
    allow update: if adminOrOwner()
  }

Summary

You need to spend time thinking about who should have access to your Firestore databases. Never trust a client request since it may be compromised. Do all your checkings in the server using Firestore rules and the session information. With the help of custom user claims and functions it should be very easy to secure your database.

If you want to see these rules in action in a live application download the free Svelte and Firebase template.

DEV Community: Jorge Alvarez

Developers will become pilots

When AI writes code, all code will be open source.

Find in batches and pluck

Normalise array in Rails 7.1

Requesting a technical challenge is useless and rude

Summary

Integration tests with minitest, Sorcery and Rails 7

Write code that helps your users

How to create a secure password that you can remember

Use letters from a sentence

Summary

Open Source event tracking and gamification engine

Siete Valles

Use cases and examples

Technical details

Technology

Svelte Router SPA now supports route localisation

Features

Open source e-commerce Rails 6 & GraphQL with JWT

Secure Firestore rules for Firebase

Table of contents

Some thoughts on security

Basic rules

Grant/Deny access to documents

Use functions to improve clarity

Advanced rules

Return only a subset of documents

Allow special permission to administrators

Filter by current user

Summary