
Not many services can enjoy the reputation on the level of Cypress and I've always known it's not all talk. Unfortunately, even though writing tests in it was nothing but a joy every time I tried it out, I felt like it is above my head to try to include it in an actual CI/CD pipeline. Now, I am happy to report that this assumption was just that - an assumption, wrong one at that. **GitHub Actions enables building an E2E testing pipeline at no cost[*](https://github.com/pricing): nor time, nor financial.**

In the next couple of paragraphs, thanks to the wonderful combination of Cypress and GitHub Actions, we will set up a basic CI/CD that will be capable of running our E2E tests on different devices and operating systems, intercepting requests on their way to the API and returning a video of the actual interactions if the test run has failed.

#### Agenda

1. Setting up a basic Next.js application
2. Creating an endpoint in Next.js
3. Adding Cypress and writing a test
4. Integrating Cypress into GitHub
5. Running Cypress via GitHub Actions

#### Useful links
- [Cypress](https://www.cypress.io)
- [GitHub Actions](https://github.com/features/actions)
- [Next.js Documentation](https://nextjs.org/docs)
- [💻 Code (GitHub)](https://github.com/useo-pl/blog-cypress-gh)

---

## 1. Setting up a basic Next.js application

For the purpose of this article, I built a simple Next.js application containing a form with asynchronous logic. I chose Next.js purely out of my convenience, Cypress is completely agnostic of the front-end technology you use and you can point it to run tests on any existing website. Anyway, our main point of focus is a file `Form.js` that looks like this:

```jsx
// src/components/Form.js

import React from 'react'
import styles from '../../styles/Home.module.css'

// our request to a Next.js endpoint
const sendForm = () =>
  fetch('/api/ping', {
    method: 'POST',
  })

const Form = () => {
  const [loading, setLoading] = React.useState(false)
  const [error, setError] = React.useState(null)
  const [data, setData] = React.useState(false)

  const submitHandler = async (e) => {
    e.preventDefault()
    setData(false)
    setLoading(true)
    try {
      const response = await sendForm()
      await response.json()
      setData(true)
      setLoading(false)
      setError(null)
    } catch (error) {
      setData(false)
      setLoading(false)
      setError(error)
    }
  }

  return (
    <form className={styles.form} onSubmit={submitHandler}>
      <label>
        First Name
        <input type="text" name="first_name" />
      </label>
      <label>
        Last Name
        <input type="text" name="last_name" />
      </label>
      <button type="submit">Submit</button>
      {loading && <h2>Loading...</h2>}
      {error && <h2>Error :(</h2>}
      {data && <h2>Success!</h2>}
    </form>
  )
}

export default Form
```

The use-case is very simple: the user fills all the fields, clicks submit, waits for the response from quite a slow server, and enjoys a big ugly heading "Success!".

## 2. Creating an endpoint in Next.js

In order to be as close to a real-world scenario, we will not mock our request like savages but rather use a native Next.js feature called [API Routes](https://nextjs.org/docs/api-routes/introduction) to build an actual (although very simple) endpoint:

```jsx
// pages/api/ping.js

export default (req, res) => {
  setTimeout(() => {
    res.status(200).json({})
  }, 3000);
}
```

All this endpoint does is returning the status `200` after wasting 3 seconds of our lives. Fortunately, this is all we need to start testing our application.

## 3. Adding Cypress and writing a test

Now things are about to get spicy. We are adding a dependency that is an absolute star of today's show: [Cypress](https://www.cypress.io).

```bash
yarn add cypress --dev

// or

npm install cypress --save-dev
```

The people behind Cypress call it "a next-generation front-end testing tool built for the modern web" but I would rather describe it as **"the only tool that can ever make you excited about testing 😎"**. E2E tests by definition are much closer to simulating the actual user experience, therefore they are much more pleasant to write (because you are not diving into the implementation details) but Cypress takes it to another level.

Cypress has [excellent documentation](https://docs.cypress.io/guides/overview/why-cypress) with tons of examples out of which I especially recommend you take a look at [this one called Kitchen Sink](https://docs.cypress.io/examples/examples/applications#Kitchen-Sink) because it contains just about every scenario you may encounter in your application. Unfortunately, today's article will not necessarily focus on the power of Cypress in terms of writing assertions and simulating user interactions, but rather the ease of setting everything up in a configuration that can be useful in production-grade applications.

First time you run Cypress through `yarn/npm run cypress open` it will generate a basic folder structure with a bunch of files and I suggest you don't cross them out right away because, f.e., the examples provided in `cypress/integration/examples` can be quite useful.

Cypress comes in with a very handy GUI that lets us browse and manage all of our tests.

![](images/blog/2021/cypress-github-actions/Untitled.png)

It will prove its worth once we finally write our first test:

```jsx
// cypress/integration/form.spec.js

describe('The form', () => {
  it('shows success message when submitted correctly', () => {
		cy.visit("http://localhost:3000");
    cy.get('[name="first_name"]').type("Adrian");
    cy.get('[name="last_name"]').type("Pilarczyk");
    cy.get('[type="submit"').click();
    cy.get('form').should('contain', 'Success!')
  });
});
```

Let's break down what's going on here:

```jsx
// cypress/integration/form.spec.js

// the name of the test suite
describe('The form', () => {
	// the description of the individual test
  it('shows success message when submitted correctly', () => {
		// command: tell Cypress to visit this address
		cy.visit("http://localhost:3000");

		// command: select an element of name === "first_name"
    cy.get('[name="first_name"]')
			.type("Adrian"); /* <- command: type a string into it */

		// repeat the above
    cy.get('[name="last_name"]').type("Pilarczyk");

		// command: find an element of a type === "submit" and click it
    cy.get('[type="submit"').click();

		// command: find a form element
    cy.get('form')
			.should('contain', 'Success!') /* assertion: check whether it has a content saying "Success!" */
  });
});
```

I wanted to make this explicit distinction between "commands" and "assertions" (the same way [Cypress documentation](https://docs.cypress.io/guides/core-concepts/retry-ability#Commands-vs-assertions) does it) to highlight what is the main intuition behind writing Cypress tests (and any other UI tests really): first we select an element and then we either run an action on it or we check whether it passes certain conditions.

What's really worth pointing out in this example is the last line:

```jsx
(...).should('contain', 'Success!')
```

Notice that I didn't have to specify what kind of content Cypress is supposed to expect, I just informed it that it will contain the string "Success!". The people behind Cypress are aware of what chore testing is for most of us, so you can expect a lot of [KISS](https://en.wikipedia.org/wiki/KISS_principle)es of encouragement from them.

Right away, our test should land in the Cypress GUI. Let's run it there:

![](/images/blog/2021/cypress-github-actions/Untitled_1.png)

If you are lucky, this is what you should see:

![](/images/blog/2021/cypress-github-actions/Untitled_2.png)

In the left column, Cypress gives us a rundown of all of the actions it performed for us. We also see the result of our assertion, which - and I hope you will see that often - in this case, is a success.

In this simple test, we unconsciously made a certain E2E testing design decision that Cypress dedicated [an entire article](https://docs.cypress.io/guides/guides/network-requests#Testing-Strategies) to: **we decided to send a request to an actual endpoint**. Any time the results of our tests actually reach the database, we get ourselves a whole new layer to maintain. Do we clean the database up after we run the tests? Do we do it on production? Or do we set up a special staging environment for it? 🤯

On the other hand: **this is as real-world as it gets**, this is the exact experience the user can expect, which is the motivation behind E2E testing. We don't need to worry about mocking the server responses (which can also change over time), but besides babysitting the data we also have to be aware of the time it takes to finish the request. As we all know, the oldest saying in the world is "time is money", so I assume we may want to be able to address it in our tests.

Luckily, Cypress provides us with a method called `intercept` that does exactly that - it catches the requests that we try to send and return a response we specify in our test. In other words, it allows us to mock network requests. With this modest addition...

```jsx
describe('The form', () => {
  it('shows success message when submitted correctly', () => {
    cy.intercept('POST', '**/api/ping', {
      statusCode: 200,
      body: {},
    })

    cy.visit('http://localhost:3000')
    cy.get('[name="first_name"]').type('Adrian')
    cy.get('[name="last_name"]').type('Pilarczyk')
    cy.get('[type="submit"').click()
    cy.get('form').should('contain', 'Success!')
  })
})
```

...we can expect our test to take slightly less time:

![](/images/blog/2021/cypress-github-actions/Untitled_3.png)

## 4. Integrating Cypress into GitHub

Now that we have our first test, it's time to move it from our local environment to an actual CI/CD. This starts with integrating Cypress into our repository which is enabled by a service called Cypress Dashboard. The entire process is perfectly described in the [Cypress documentation](https://docs.cypress.io/guides/dashboard/github-integration#Install-the-Cypress-GitHub-app).

Once we are authorized, we must initialize our project:

![](/images/blog/2021/cypress-github-actions/Untitled_4.png)

Following the instructions from Cypress Dashboard, we add the `projectId` to `cypress.json` that Cypress should have created for us on its first run. The entire process, if executed correctly, should result in the presence of Cypress integration in the GitHub "Integrations" section in the repository settings.

![](/images/blog/2021/cypress-github-actions/Untitled_5.png)

This is where the final and the most fun part begins.

## 5. Running Cypress via GitHub Actions

[GitHub Actions](https://github.com/features/actions) is an awesome automation pipeline that we will use to run our Cypress test suite on each Pull Request in our repository. We will do so by providing it with a `.yml` file that will include all of the instructions needed for our tests to run:

```yaml
# .github/workflows/e2e.yml

name: e2e
on: [pull_request]
jobs:
  cypress-run:
    name: Cypress run
    runs-on: ubuntu-16.04
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Cypress run
        uses: cypress-io/github-action@v2
        with:
          build: npm run build
          start: npm run start
          wait-on: http://localhost:3000
```

Just a moment ago you were about to quit because you never planned on becoming a dev-ops, right? The fear of that had been a show-stopper for my usage of Cypress in a commercial environment for far too long. However, pushing those few lines, by courtesy of GitHub Actions and Cypress (and their predefined routines called [cypress-io/github-action](https://github.com/cypress-io/github-action)), made my jaw drop the first time I saw it in action:

![](/images/blog/2021/cypress-github-actions/Untitled_6.png)

![](/images/blog/2021/cypress-github-actions/Untitled_7.png)

You thought that was cool? How would you call adding a recording of our tests with just 4 lines of config, then?

```yaml
# .github/workflows/e2e.yml

name: e2e
on: [pull_request]
jobs:
  cypress-run:
    name: Cypress run
    runs-on: ubuntu-16.04
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Cypress run
        uses: cypress-io/github-action@v2
        with:
          build: npm run build
          start: npm run start
          wait-on: http://localhost:3000
      - uses: actions/upload-artifact@v1
        if: always() # / if: failure() <- more suitable for production
        with:
          name: cypress-videos
          path: cypress/videos
```

![](/images/blog/2021/cypress-github-actions/Untitled_8.png)

The possibilites don't end here. Cypress plugin for GitHub Actions allows you to do all sorts of crazy things like: [specyfing different browsers](https://github.com/cypress-io/github-action#browser), [narrowing down which tests to run](https://github.com/cypress-io/github-action#specs) or [tests parallelization](https://github.com/cypress-io/github-action#parallel). Combine it with a knowledge of [GitHub Actions events](https://docs.github.com/en/actions/reference/events-that-trigger-workflows) and you can get yourself a tailored E2E testing workflow.

Aaaaand that's a wrap! If that doesn't make you like writing some tests, there is no hope for you 💀.

Integrate E2E testing in your PRs with GitHub Actions & Cypress



I have the pleasure to introduce you to a new gem created to support a [JSON:API-based](https://jsonapi.org) web applications. Standalone pagination support.

## Why another pagination gem?

Well, I know what are you thinking - WHY I bothered to build another pagination gem? There are plenty of pagination plugins for ruby web applications out there, to list just a few popular ones:

- [Kaminari](https://github.com/kaminari/kaminari)
- [Will Paginate](https://github.com/mislav/will_paginate)
- [Pagy](https://github.com/ddnexus/pagy)

The first two are "kaminari" and "will_paginate". Both are closely tight to *ActiveRecord* which can be a good or bad thing depending on your needs. For sure, implementing any of those above is extremely easy as they just extend your models!

However, they have two big issues.

1. It's super hard to use them out of the ActiveRecord-based collections.
2. They are slow.

Fortunately, smart people out there **already addressed** both of those problems and invented [Pagy](https://github.com/ddnexus/pagy).

_Pagy_ is a much more attractive gem, as it's dozens of times faster than any of the solutions listed above and really framework-agnostic. It can be used in any Rack applications and I use it (directly or indirectly) in all my projects no matter what framework I play with.

However, It also comes with at least 2 issues I think are important.

### 1. The architectural flaws

First of the issues I've faced is that _Pagy_ based on modules and a lot of [assumptions](https://ddnexus.github.io/pagy/how-to.html#out-of-the-box-assumptions) that forces the user to do a lot of configuration in case she wants to use the gem outside of standard Rails-Based controllers.

For example, pagy assumes that there is a `params` method accessible in the class you include the `Pagy::Backend` module. If we want to add metadata and related link information, we need to require an extension which also needs to be included, **but this one assumes**, we have a `request` method accessible!

All that is not a problem if we want to use it inside of _Rails_ applications, but it generates issues in case of more fancy use cases.

Let's say, we want to have a `Query` object, that will select the records from the database, and deliver the paginated result. Or an `Endpoint` instance, where you would love to get as a result **already serialized and paginated response**. Instead of injecting the dependencies like a `request` instance into the Pagy object, we need to define methods in the caller class.

This is a serious flaw in the architecture, as the caller needs to have wide knowledge about how the paginator paginates resources. Also, the pagination engine used by the caller forces the specific implementation on the caller which makes it really hard to replace in the future if there is a need for that.

I'm not sure why it had been designed this way, where the pagination control is based on overriden methods and global state, but it's unnecessary complexity and a lot of problems introduced without a need for that. There is a much simpler way.

### The JSON:API support

The other issue is, that as this gem is so framework-agnostic, there is always a bit of code you'd need to write to make it compatible with JSON:API standard and not only for that. For example, pagy by default assumes, that you have `page` and `per_page` parameters and will crash for custom pagination params. As JSON:API suggests to control your pagination using a nested query parameter `page[size]` and `page[number]`, The pagy gem needs to be adjusted in order to use it effectively.

As I work with multiple projects everyday, it would be really tedious to repeat that over and over again.

### **The JSOM:Pagination**

To solve both of the issues listed above, I've decided to write a tiny wrapper around **`pagy`**, to deliver a convenient experience for any JSON API-compatible app - and named it: **`jsom-pagination`**.

[JSOM:Pagination](https://github.com/useo-pl/jsom-pagination)  is a simple class that we can use in any place of the application **(not only in the controllers!)** - and in any kind of ruby application. You don't need additional fancy configuration, you don't need different modules being included to use it in Rails or Hanami, or raw IRB session!

Here are two examples how to use it in your app.

First you need to instantiate. the instance of a paginator

```ruby
require 'jsom-pagination'
paginator = JSOM::Pagination::Paginator.new

```

And to paginate an array you just need to call it with a collection, parameters hash and the base URL value - to generate the related pagination links, like next, last, and so on.

```ruby
collection = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
pagination_params = { number: 2, size: 3 }
paginated = paginator.call(collection, params: pagination_params, base_url: 'https://example.com')

```

In _Rails_ controllers and _ActiveRecord_ collection, it would look like this:

```ruby
collection = Article.published
pagination_params = params.permit(page: [:number, size]))[:page]
paginated = paginator.call(collection, params: pagination_params, base_url: request.url)

```

### **So what is the cool thing about it?**

It may not look amazing at the start, but injecting the dependencies into the paginator allows us to run the pagination everywhere easily. Also, the JSON:API support is built in.

All the meta information is accessible right away:

```ruby
paginated.meta
# => #<JSOM::Pagination::MetaData total=10 pages=4>

paginated.meta.to_h
# => {:total=>10, :pages=>4}

```

The same applies to links to the related pages.

```ruby
paginated.links
# => #<JSOM::Pagination::Links:0x00007fdf5d0dd2b8 @url="https://example.com", @page=#<JSOM::Pagination::Page number=2 size=3>, @total_pages=4, @first="https://example.com?page[size]=3", @prev="https://example.com?page[size]=3", @self="https://example.com?page[number]=2&page[size]=3", @next="https://example.com?page[number]=3&page[size]=3", @last="https://example.com?page[number]=4&page[size]=3">

paginated.links.to_h
# => {
#   :first=>"https://example.com?page[size]=3",
#   :prev=>"https://example.com?page[size]=3",
#   :self=>"https://example.com?page[number]=2&page[size]=3",
#   :next=>"https://example.com?page[number]=3&page[size]=3",
#   :last=>"https://example.com?page[number]=4&page[size]=3"
# }

```

And that's all.

## **Serializing the paginated collection**

`jsom-pagination` does not force you to use any particular serialization method to return those data. You can use anything you want to serialize the result. For example, if you want to use [jsonapi-serializer](https://github.com/jsonapi-serializer/jsonapi-serializer), here is how to do it

```ruby
options = { meta: paginated.meta.to_h, links: paginated.links.to_h }
render json: ArticleSerializer.new(paginated.items, options)

```

### **Something extra for Rails users**

Specifically for rails users, I've written a simple concern, where we can collect all the pagination-related methods to simplify the usage as much as possible.

```ruby
# app/controllers/concerns/paginable.rb

# Collects methods related to paginating resources
# Requires 'serializer' to be defined.
#
module Paginable
  extend ActiveSupport::Concern

  def paginate(collection)
    paginator.call(
      collection,
      params: pagination_params,
      base_url: request.url
    )
  end

  def paginator
    JSOM::Pagination::Paginator.new
  end

  def pagination_params
    params.permit(page: [:number, :size])[:page]
  end

  def render_collection(paginated)
    options =
      {
        meta: paginated.meta.to_h,
        links: paginated.links.to_h
      }
      result = serializer.new(paginated.items, options)
    render json: result, status: :ok
  end
end

```

With this, we can use `render_collection` method, to serialize the collection under the hood:

```ruby
# app/controllers/articles_controller.rb

def index
  paginated = paginate(Article.all)
  render_collection(paginated)
end

```

Now, the controller knows almost nothing about how to paginate collections, and we can easily use this feature wherever we want, keeping our classes skinny and easy to manage.

It's a huge improvement and I hope you enjoyed it so far!

## **Summary**

Writing useful gems is not a trivial thing. But in Ruby world, I see things often overcomplicated and assuming too much. It's surprising that **such a simple problem as pagination generates so many issues** during the implementation and usage of the suggested solutions.

I hope that [jsom-pagination](https://github.com/useo-pl/jsom-pagination) will help you go around them!

Let me know on [Twitter](https://twitter.com/sebwilgosz) what do you think about it!


Introducing JSOM-Pagination - a standalone pagination gem


In our line of work, this is an up-to-date topic not only during the pandemic. However, this will not be a text about applications supporting remote work or facilitating team management – everyone has already mastered these. It will be a text about something which is much more difficult in remote work, i.e. about the human factor – emotions, communication, and relations in a team.

For the last year, my team – much like the rest of the world – has been primarily working remotely, but like many developers implementing projects for foreign clients, we had to learn this art much earlier. Over the years, some of us have been working in our Wrocław office, and others in various places around the world. Hence, **we’ve developed our own methods for not only effective work but also for reducing frustration and conflicts**. Let's start with the rules that apply to the entire team.

#### Overcommunication is the key

In asynchronous communication, we always use the overcommunication rule. This means that if I give someone a task that they will start to carry out when, for example, I am already in bed, I do not just send them the task with the information "it's your turn". Instead, I describe everything that may be of use to them and even more – as all the stuff obvious to me will be new to someone who has not been in the project as long as me. **It’s always better to write those two more sentences, even if they seem unnecessary** than to find ourselves in a situation when someone has to wait 6 hours until I get up to ask me for some detail. This hinders both the work of the said developer and the entire project as well.

#### The benefit of the doubt

When someone takes over a task from another team member or when we do a code review, i.e. another developer checks if the first one hasn’t made a mistake or overlooked something obvious, the following situation quite often occurs:

The task was complicated, so the developer spent several hours working on it and produced a few lines of code. He/she went through various scenarios, tested all possible options, and chose the best one. There was a problem to be solved, and he/she solved it as was their task. And the person who is only supposed to check if everything is OK (a frequent case with young developers) looks at the code and says that it makes no sense, it should have been done differently, in a simpler way, and “how on earth did you spend so much time on it”? The reviewer doesn't take into account that this obvious answer which immediately occurred to him/her, wasn't the best one at all, and the person who had been working on the problem probably had to discard this very solution right at the beginning. **There’s not enough faith in the fellow team member and no assumption that they actually know what they’re doing** and have chosen this particular solution for some good reason. He/she thought it over, checked it, tested it. It's easy to criticize someone's hours of work in 5 minutes, but we won't get far with such an attitude.

Of course, it would be ideal if the first developer, when submitting the code for review, mentioned that they also tested three other solutions and this is one the best because of this and that… This would dispel the reviewer’s doubts straight away which brings us right back to overcommunication.

#### Short messages and perspective

**In written communication where emotions are invisible (or somehow hidden), proper perspective and initial assumptions are important**. We often write something quickly and laconically in order to give someone a reply and push their work forward, but at the same time to quickly get back to our own tasks, because we are busy ourselves, we’re rushing to a meeting or we are already after working hours. If replying to you is a man or woman a few time zones away, who is just on his/her way to pick up the children from the kindergarten, then they simply have no time for "great to hear from you, we haven't talked for a while". They will focus on giving you an answer that will keep you working – laconic but to the point. And you start to wonder if the person feels offended or irritated by your question, if something’s wrong or if that was maybe a dot of hate. Well no – usually it was just rush, so the basic **assumption should always be that the person on the other side has neither bad emotions nor bad intentions**.

#### Clear message and agreement

Sometimes it is easier and faster to clarify matters by calling someone than by sending messages. Even before the pandemic, we often asked if someone had a moment to call us. Now we have an agreement that when someone is available on Slack, we just call them just as if we approached them in the office and asked something. This is obvious, but when making calls, **it makes sense to use the camera – it's easier to communicate when you can see somebody’s emotions**. It’s 5 minutes of talking instead of 3 hours of typing.

And if a team doesn’t have fixed working hours (like mine) then it is worth informing each other who’s working when. If someone knows that they will be gone between 11 and 12 because they have to take Grandma to the doctor, they let us know, and we include it in our work schedule and don’t call them during this time. If someone’s working some unusual hours this particular week, they inform us exactly when, so as not to hinder the work of others and to facilitate communication.

**Remote work gets drastically more difficult when developers working in different time zones have less than four hours of shared working time**. It’s difficult to expect someone to call a developer from the other side of the world at 10 p.m. and explain some issues. That’s why – even with all the good intentions and following all the rules – the work often grinds into a halt. So if we have these four hours, we need to plan them well, exchange as much information as possible, and agree with the other party on everything that may be useful later.

#### Good and bad types of meetings

Let's move on to what a team leader can and shouldn’t do to improve remote work.

Unnecessary meetings that take half a day are the curse of our time. Hence, if the matter isn’t important, we do not organize meetings, if the problem isn’t urgent, we do not call. When someone pulls us away from our work, we need a minimum of 15 minutes to return to the task we were dealing with and focus on it again. Switching from one topic to another takes away a lot of productivity.

But there are also types of meetings, or rather conversations, which I believe – especially during the pandemic – have become important and necessary. These are those conversations that previously happened casually while making coffee, during the break between tasks – a simple chat with a man or woman at the next desk. To me, it’s very important to have close contact with the people I work with and whom I employ – to know what's going on outside of work.

At first glance, such meetings – be it one-on-one or in groups – are useless. However, they maintain personal contacts, and thanks to them I get to know my employees better and they get to know one another, and this, in turn, affects all the points I’ve discussed above. **It facilitates communication, builds trust and the conviction that other people know what they are doing and do the best they can at a given moment**. And if we know that someone is going through a stressful moment in their life, we won’t be angry at them when they reply with short messages. It’s better to work in a good and harmonious team.

In the office, such conversations happened naturally but during the pandemic, you have to find the time and plan for them, because this is an element that reminds everyone that apart from duties, tasks, and deadlines, there are also human beings on the other side of the screen.

The second type of meetings worth organizing regularly, not only during a pandemic, are strategic meetings. This means: “Let's talk about how the company is doing, what projects we are doing, what we are going to do, what the whole team would like to do, which way to develop”, etc. **This builds a sense of community and shared responsibility**. It shifts the burden a little from "I" to "we" and allows us to take into account a wider perspective when discussing specific solutions.


About communication, emotions, and relations in remote work


Some tips for anyone thinking of changing jobs and embarking on a career in software development – from the perspective of a software company owner.

#### Current market situation

Working in the programming industry, and more specifically with start-ups, I sometimes observe changes and trends occurring in the field. In Poland, there has been a massive increase in the number of people who have decided to retrain and become software developers. The market has never experienced such interest and influx of candidates. At the same time, many companies are willing to employ experienced developers rather than people taking their first steps in the profession. For all those who are just starting out, finding their first job turns out to be quite a difficult experience.

Their decision is often motivated by a good salary which I fully understand. The problem arises when it’s the only reason for someone to start coding. After all, we do not take such momentous life decisions as a complete change of our professional path only to realize that we don’t really like our new job at all. And quite a unique kind of job, come to that.

But just suppose it was a carefully thought-out decision. You have already completed a few courses, you have also learned a lot yourself, you are starting to look for your first job. What challenges are you going to face?

#### Employer's perspective

There are quite a few software companies on the market, and yet it may take a while to find one that will give you a shot and hire a developer with no commercial experience.

At the beginning, the company will have to invest in you a lot of time of their more experienced developers who will train you, explain the rules, introduce you to projects, answer questions and help in case of any problems. Sure – it all depends on the difficulty of a given project and how quickly you learn – but I know from my own experience that such training takes from 3 months to a year. And it doesn't matter if you are a recent IT graduate or you came from a completely different sector. In your first job, you just have to learn a lot of new things that you have never had a chance to learn before.

Each boss, when deciding to hire an employee with no experience, has to invest his team's time in them. And this is a considerable investment.

The second reason is pure cost calculation. If a potential employee has high financial expectations (since that’s the reason they’ve probably become developers in the first place), and they will code twice or even three times slower than senior developers, additionally "devouring" their time for training, then employing someone with experience may simply be cheaper for the company.

##### A place for newbies

I know that this may all have sounded rather discouraging so far, but awareness of the employers' situation will allow you to better understand the recruitment process of new employees and properly prepare for interviews. Because there are also lots of reasons why companies should hire novice developers.

The IT industry is changing so fast that finding someone truly experienced on the market is becoming more and more difficult. In fact, hiring a junior developer and training them sometimes seems faster than the constant search for a senior developer who just wants to change jobs.

#### Developer’s first job

When looking for When looking for a perfect first employer, remember about the most important features of such a company:a first company on your professional path as a coder there are a few things worth keeping in mind.

Ideal first company for someone with no commercial experience should have specific characteristics:
1. It shouldn’t be very small. You need people to learn from – if a company employs several senior developers, there is a higher probability that there will always  be someone who will have time for you. The more experienced people to observe at work, the better for you.
2. Larger companies have larger budgets, so it’s easier for them to invest in hiring and training you.
3. At the beginning, you may find it easier to navigate through smaller projects. Look for a company that deals with such projects. Large and complex projects can be a great option if they are at their initial stage. Then you can learn as the project develops.
4. You don't know what projects the company deals with? Do thorough research. Finding this information may not be the easiest thing to do, but knowing what technology a company is using, browsing through its portfolio, and looking through its website will give you a good idea.

You also need to know that if a company isn’t currently doing a project that they can hire you on, that doesn't necessarily mean they won't be doing such a project in a few months. After some time, write them an e-mail, ask if anything has changed and just remind them about yourself. Maybe they now have something new, or maybe next time they will remember you.

The same goes for sending out your CV. You will probably send dozens of them. Do not be discouraged by the lack of a reply – I know from my own experience that such e-mails are surprisingly easy to overlook in a busy workload. Send a reminder after a week or two.

#### Competition in the developer market

The company has invited you for an interview? Great! In that case, it’s good to be aware of two things:
1. You compete with students and graduates who have just left universities. Even if you have the same level of knowledge and skills, age is their undeniable advantage. The employer in Poland pays much lower taxes for employees under the age of 26.
2. Moreover, a younger employee usually has lower financial expectations. Although it’s not always the case, usually people who change jobs are at a different stage than students. They have personal and financial obligations and are used to a certain standard of living. The initial salary they expect will, therefore, be higher than that of people who are just beginning their professional life. And even if your financial expectations are the same, remember about the those lower taxes.

Unfortunately, such are the facts. So what you can do is convince your potential boss that you are better than other candidates and it will pay off to hire you:
1. Your advantage is experience from previous work and what you already know about yourself as an employee. Maybe you have leadership qualities, maybe you get along well with clients, you are a master in organizing your own work or you have always met your deadlines. Use these things.
2. Write at least one app, but what's important – make sure it's the best code you've ever written. You think it's not bad, but one or two things could be a little better? Then make them better. Correct everything you can before showing it to your prospective employer.
3. Be determined. People who are considering hiring you want to see that you care about this job – that you are committed and that you would really like to work with them.
4. There are several things you can do regarding the financial side. If you've never been self-employed, consider starting your own business. During the first years you will have considerable tax discounts, thanks to which you will be able to lower your salary expectations towards the employer and you will have exactly the same amount of money in your account.
5. Another way – make a suggestion that for some time you will be prepared to work for less (it must be, however, a clearly specified period). This time will give you a chance to show your skills and prove yourself. The employer, on the other hand, will be able to assess your competences and contribution to their team's effort. After this period, you will be able to revisit the subject of your salary.

These are, of course, just examples. Since creativity is also important in this industry, feel free to suggest your own solutions.

Haven’t got a response from the company you were interviewed for? Send a short email and remind them about yourself. Even if they have chosen someone else, you'll get valuable feedback and learn what you should work on.

#### Remote work

While you’re still a junior developer, your boss will probably prefer you to work in the office rather than from home. There are several reasons for that:
- Face-to-face exchange of information is much quicker, so you learn faster,
- You have better contact with experienced developers – for them it’s easier to train you in the workplace, and for you it’s easier to get help,
- You get to know the team and become part of it.

So if you are entering the profession with the idea of ​​working remotely, you must have good arguments. Find tools that will allow you to work from home and learn how to use them well; check  what aspects of work they will facilitate. Working remotely requires much better communication skills, especially when team members do not synchronize their work and perform their tasks at different times of day (and sometimes at night). Find your own way to do that, suggest solutions. You need to convince your employer that you can handle it and that your work will be as effective as in the office.

#### To sum up…

The decision to change your profession and start programming is not and probably should not be easy. There are hundreds of hours ahead of you in front of the computer, lots of exercise in motivation and self-discipline, and finding your first job can be time-consuming and stressful. However, just getting through these stages says a lot about your determination and readiness for hard work. That’s a good start!

If you are tempted by IT, but the final decision is yet to be made, remember that there are many more possibilities than just programming. The software development process itself requires testers, sellers, analysts, designers and many other people. Before you decide - check, maybe you will find something more to your taste than programming.


Before you change your career and become a software developer

Up and running with Next.js and Hasura in no time


As a developer, I constantly look for improving my code. Also in terms of tests. For me, it's important to keep tests clean in order to add new tests to be a pleasure, not a drudgery.

First time I stumbled across the shared context when I was looking for something that can help me to extract some constantly repeated variables in tests. The shared context was exactly what I was looking for. I will show you how to use it and what are the benefits of that.

## What do we test?

Assume we have to write a few policy objects. They can look like this following one:

```ruby
# lib/policies/user_settings_policy.rb

class UserSettingsPolicy
  def can_show?
    user.admin? || user.id == resource.id
  end

  private

  attr_reader :user, :resource

  def initialize(user, resource)
    @user = user
    @resource = resource
  end
end
```

Somewhere we have defined  `User` and `UserSettings` classes which instances are connected by `user_id`. They may resemble ActiveRecord objects and a database relationship or they may be objects built based on events. Having that we can go to write tests. In this example, `first_name`, `last_name`, and `email` are required to create a user object.

To test the policy object we need an admin user and a user who is the owner of a resource. Obviously the resource as well.

```ruby
# spec/policies/user_settings_policy_spec.rb

RSpec.describe UserSettingsPolicy do
  let(:user) do
    Models::User.new(
      id: SecureRandom.uuid,
      first_name: 'Nick',
      last_name: 'Owen',
      email: 'nick.owen@exam.com'
    )
  end
  let(:admin) do
    Models::User.new(
      id: SecureRandom.uuid,
      first_name: 'Jack',
      last_name: 'Jones',
      email: 'jones@exam.com',
      role: :admin
    )
  end
  let (:resource) { Models::UserSettings.new(user_id: user.id) }

  describe '#can_show?' do
    context 'when a user has an admin role' do
      subject { described_class.new(admin, resource) }

      it 'returns true' do
        expect(subject.can_show?).to be_truthy
      end
    end

    context 'when a user has a user role' do
      subject { described_class.new(user, resource) }

      ...
    end
  end
end
```

You have to admit these `let`s took somewhat place. Ok, we can take care of testing the next policy object. Hmmmm... it means we need to declare the user and the admin in the subsequent spec file. This isn't the way.

## It's time for the shared context

I've created the `shared` directory inside of the `spec` catalogue. Inside of that, I've created the `users` file. I named it so to accurately specify the content of the file.

```ruby
# spec/shared/users.rb

RSpec.shared_context :users do
  let(:user_id) { SecureRandom.uuid }
  let(:user) do
    Models::User.new(
      id: user_id,
      first_name: 'Nick',
      last_name: 'Owen',
      email: 'nick.owen@exam.com'
    )
  end

  let(:admin_id) { SecureRandom.uuid }
  let(:admin) do
    Models::User.new(
      id: admin_id,
      first_name: 'Jack',
      last_name: 'Jones',
      email: 'jones@exam.com',
      role: :admin
    )
  end
end
```

The content of this file includes `let`s that we saw before in the policy spec file. The only difference is that I extracted ids to separate variables because I don't want to use `[user.id](http://user.id)` every time. There is still one thing to do, we have to load the shared context in the `spec_helper.rb` file, like so:

```ruby
Dir[File.expand_path('shared/**/*.rb', __dir__)].each { |f| require f }
```

The line above loads all `.rb` files from the `shared` directory.

Having that we can start to use the shared context what is pretty simple. Let's take a look at the spec file. Now, it's clearer, is it?

```ruby
# spec/policies/user_settings_policy_spec.rb

RSpec.describe UserSettingsPolicy do
  include_context :users

  let (:resource) { Models::UserSettings.new(user_id: user_id) }

  describe '#can_show?' do
    context 'when a user has an admin role' do
      subject { described_class.new(admin, resource) }

      it 'returns true' do
        expect(subject.can_show?).to be_truthy
      end
    end

    context 'when a user has a user role' do
      subject { described_class.new(user, resource) }

      ...
    end
  end
end
```

As you could notice, we need to include the context by using  `include_context :users`.
After that, we can use everything that we've defined inside of our context file. Now, we can write another policy object and tests for it without duplicating the users declarations.

## Summary

The shared context is a good place to put variables that we use in more than one spec file. If you need you can also put mocks in your context. Sometimes it's hard to write a shared context that not contains unused variables but no worry, unused variables are `let`s and they are initialized when you use them in a test file. Despite that, I really encourage you to write small shared contexts in order to easily include just what you need and keep the proper naming of context files.

Thanks

[Geralt](https://pixabay.com/users/geralt-9301/) for the background photo

[Sebastian Wilgosz](https://github.com/swilgosz) for inspiring and encouraging me to write this article


Keep DRY your tests - a little bit about the shared context in RSpec


Since I watched the [Ruby/JS WAT?](https://www.destroyallsoftware.com/talks/wat) video, I always see it in front of my eyes, whenever I discover my personal WATs in all parts of my life. And I always want to write about them, so here is one such thing.

**I've found a bug in GIT.**

How likely is that to happen? Give me any lottery you can think of and still I can argue if it's harder to win in it or find a bug in GIT. Still - it happened to me and the funniest thing is, that **it happened while working on a blog application**. When I worked on it **alone!**

No big teams, merges, overriding history... nothing. Just basic features had been used there.

Here is how it happened...

> For people who don't know the word *WAT*: It's a term describing a thing that shouldn't have a place. Something completely unexpected and non-intuitive.

## React blog application

I wanted to rewrite [my blog](https://driggl.com/blog) from Nuxt (Vue.js) to Next (React.js) to test a very weird behavior related to the Nuxt API proxy.

During the development, I've realized, that I've named one of the component's files wrongly - `Logo.js` instead of `logo.js`. No big deal, one could say. Just rename it, commit changes and voila! You're ready to go.

However, not everything went so smoothly.

### Module Not found

The continuous integration tool - in this case, it was a [Now from Zeit](http://github.com/zeit/now) company - reported that the path to my *logo* component could not be found.

![](/images/blog/i-found-a-bug-in-git/now-log.png)

I was stunned. Ok, I expected that I have a typo somewhere in the `import` or the file name, but I haven't.

My components file list was very small and flat, there was no place for an error:

![](/images/blog/i-found-a-bug-in-git/component-file-list.png)

Components file list in Driggl's blog application

The same applied to the importing part, where I just needed to import the file from the same folders, when I had just this one-line responsible for importing the Logo component:

```jsx
import Logo from './logo'
```

The weirdest thing was that actually everything worked locally, and it only crashed when deploying to production.

I was really confused until I've shown the code to my teammate. He had cloned the repository and we've realized, that the logo component file is named wrongly despite the fact I had no uncommited changes!

![](/images/blog/i-found-a-bug-in-git/wrong-file-name.png)

## GIT has issues.

It was a really interesting discovery, that when I've checked the GIT mechanism, it'd shown me that GIT does not recognize renaming files when the only change you do in the file name is the letter's capitalization!

So basically, even though I had the *logo* file renamed, GIT'd never noticed it! I was looking like:

![](/images/blog/i-found-a-bug-in-git/what_1_small.jpg)

And here I am - WAT?

Try it yourself:

```bash
touch something.txt
git add -A .
git status
```

![](/images/blog/i-found-a-bug-in-git/Untitled.png)

Then play with the file name a little bit:

```bash
mv something.txt Something.txt
git status
```

Has anything changed for you?

Now try to reset the staged changes and check the status again:

```bash
git reset
git status
```

![](/images/blog/i-found-a-bug-in-git/Untitled 1.png)

Voila! The GIT magically recognized the file name!

## Takeaways

This little experience taught me that **everybody writes buggy code** sometimes. We should never assume anything is perfect, as every little part of the software we use is written by a human. And humans can make mistakes.

And, if it comes to GIT, **just always - ALWAYS do the review of your own changes**.

I occasionally write about [GIT hacks and tricks](https://driggl.com/blog/a/git-hooks-commit-msg), but this one was the most interesting thing I've found in the last few years.


I’ve found a bug in GIT – WAT? The GIT Lottery


Over the last ten years of our presence in the industry, we managed to keep the same, through-the-roof, level of passion for something once started as a harmless hobby, only to later become a pillar of our careers: web development. During this ongoing journey, we’ve met so many selfless individuals completely devoted to the mission of spreading knowledge, it’s hard not to feel inspired by them. This is why through today’s blog launch, we want to start contributing to the beautiful idea of accelerating the growth of the community of web developers.

What exactly can we offer you in exchange for your time? First, you have to get to know us a little better. USEO is a software development company located in the charming city center of Wroclaw, Poland. Our experience comes from many years of cooperation with clients from all around the world that we helped build fascinating projects. We value long-lasting friendly business relationships and don’t shy away from the challenges of different magnitudes. Trust, honesty and pleasant atmosphere at work are crucial for us.

Even though we’ve dipped our toes in multiple technologies, throughout history we stayed most loyal to Ruby on Rails. Loved by many startups around the world Ruby on Rails was and still is one of the fastest ways to build web applications, MVPs or even large, scalable and efficient production environments. Our area of expertise much exceeds the beloved technology thanks to our growing experience with ReactJS, Docker, Kubernetes or VueJS. The passionate team of developers at USEO stays up to date with all the hottest web development trends, so you can be sure that the lists of topics covered on our blog will only get broader. Our company is also open to collaborating on articles with external authors, so we can provide you an extra perspective on some of the things we may be missing.

Thanks to many years of our experience while working on various projects with teams around the world we’ve came across very fascinating problems which we had to solve. We are sure that we will be able to produce value not only on the technical level, but also in the area of soft and business related topics. You can bet on seeing some sweet career, time-management and project organisation tooling tips in the very near future. These and plenty other topics have been boiling in our heads for years and now we have a platform where we can finally share them with you.
