Leaving Sudolabs

Let’s start with a shocker. After 2 and a half years I’ve decided to part ways with Sudolabs. It was a really hard decision to make but we have decided that it would be the best for both parties. Parting ways took only 2 days which should make things easy. I’ve made strong bondings with my colleagues and it was heart-crushing to leave them. It’s not easy to write about these emotions after 2 weeks, either.

I want to thank everyone who helped me to grow and for all those amazing moments we spent together. It was by far the best experience I’ve had in a company. I hope we will still see each other and help each other even without any obligations to do so.

Treasure hunt

As I haven’t had any other job in sight, I’ve started to look around the job market. There are too many companies and even more recruiters. It’s going to be hard to find and pick one that will fulfill my expectations and I’d fit in. I have a pretty good vision of what I want to do next. Certainly, I’d like to have a much bigger focus on the development than on management. I would love to teach/mentor/coach my colleagues to perform at their best. That was the one thing I enjoyed the most.

I haven’t realized that I have built up a work routine. I have a hard time not focusing on programming during my time off. I have time to learn a lot about myself. I would like to use as much time effectively even if I don’t have to.

I have some interviews planned, but I don’t want to overdo them. I’m surprised by the variation between these processes. The job market is oversaturated and it shows in the interviewing process of companies of different scales. My prediction for the future is that we will have many smaller companies with their own little cultures and bubbles. Just like in code, we want our functions to be small, granular, composable, and focused on doing one thing only and doing it well, we will have many small companies focus on doing what they are good at and doing it well.

Scaling companies is hard. And it will be hard. People are searching for liberation. They are going to find a job that will allow them to work whenever they want in terms that, they are going to be satisfied with. Diversification is also a very important aspect. Having hard-stop rules, ladders, and a complicated onboarding process suited only for one type of developer is exactly what makes the stereotype jokes in your company target every single one of your employees.

Maybe I should build my own company. It is something I’ve been thinking of for a few months. I am just avoiding having responsibility for all the shit I’d have to deal with around bureaucracy. I’m still giving a chance to someone who is not scared of that and is more educated about managing finances and people.

DevBreak episode #2

So on the exact day that I’ve left Sudolabs, I have been able to save the DevBreak talk. Not me exactly. It has been saved by my awesome friends Daniela, Samuel, and Filip. They’ve attended HackKosice hackathon and were generous to talk about their experience and impressions on the DevBreak talk. Go check out the episode. They’ve brought a very good vibe and I had a great time talking with them.

I’ve already contacted my next guest for episode #3 and I am very excited for this one. As I have a wedding to plan and attend I don’t know when we will air the episode. But it will be a great one! Can’t wait.

Stream updates

We have set up a Discord server where you can chat with our community whenever. We share dev tips and memes, but I’d also like to receive feedback on the stream content.

The last 3 streams have been devoted to game development with Bevy game engine. I’ve started to fulfill my childhood dreams and started a journey full of learning stuff that I haven’t been used to. I’ve made some games before. But I would say that this one is going to be of a larger scale.

I want to build a card-based strategy game. Something similar to Hearthstone and Heroes of Might and Magic. There is a lot to learn about the engine itself so the mechanics of the game will be developed in later stages.

We have agreed with the community that we would like to also do some l33tcode challenges. So the variety will still be there. I’ll just want to gain more people to start doing exercises like this so we can compare our solutions with each other.

Getting married

This post is already filled with so much content, but I can’t skip this chapter.

My and my soon-to-be beautiful wife are getting married next Saturday. Very exciting times. I am going to meet my whole family after so many years. It’s going to be not only the party of the year but of a whole life.

Picks

• As I’ve been doing research on Bevy game engine, I’ve stumbled on this amazing series of tutorials by Logic Projects. It’s a really fast walkthrough of challenges during game development when starting with Bevy. It helped me build a better mental model of how should I structure entities and components for my own game.

• I’ve discovered a great podcast by Michal Truban. I’ve listened to some episodes and I have to say that it is educational. Nice tips from Andrea Vadkerti on coaching. Or from Matej Ftáčnik on how to run a successful company.

I’ve been very busy the last 3 weeks and I’m so so sorry I haven’t been able to post an update. Now, I have so many things in the pipeline, I hope I’ll be able to remind myself of everything.

I’m organizing a wedding with my beautiful soon-to-be wife, so I am running errands all over the world. I’m trying to still be available to stream and focus on learning in between.

Game dev research

In the latest stream, I’ve taken some time off coding and started to work on research for the upcoming side-project of creating a strategy card-based game similar to Blizzard’s Hearthstone. I’m still holding off specifying the rules and mechanics of the game. I’ve been searching for a game engine that will help me write code that I will be comfortable and productive with.

The engine that made me most excited was Bevy, built in Rust. The Entity Component System architecture looks very interesting and I would love to try it out. I see some potential for reusing the architecture in different programming languages and domains.

I’ve been also researching the ecosystem of the Go language. The ecosystem is very plain and I’ve been only able to find a single 3D game engine that didn’t have much learning materials or community around it. The language itself looks very simple, in a good sense of course. There aren’t that many concepts that need to be learned and people using it are very satisfied with their productivity. That is one thing I am worried about with Rust.

DevBreak #2

The next episode of my lifestyle talk show DevBreak is in the makings. I’ve got some people interested in the idea. We just have to agree on the exact time and place. Announcement preparations will start this week and hopefully, it will be a very cool episode. I think it will be very very interesting as we will have 2 different viewpoints on a very close topic to everyone in the IT field.

Headphone update

My brand new Beyerdynamic DT 900 PRO X headphones have finally arrived. I fell in love with them immediately. The initial date of arrival was estimated to be in May. One day I just received an SMS that they will be delivered the next day. I can’t promise a review because I don’t see myself as an expert in the field of HIFI headphones but I can recommend them to anyone who seeks out a very nice balanced sound with very comfortable construction.

Also, these are my first open-back headphones and they are amazing for very long listening sessions and home-office. The only downside is that they are not able to block noise from a washing machine or a vacuum robot.

Picks

• My inspiration The Primeagen has released a very good Youtube video on a comparison of performance between TypeScript, Go, and Rust. Very good content from him. I’d like to know what went bad with the Rust example as the performance bottlenecks look like can be optimized.

• Short article by Sylvain Kerkour but a very good explanation on why would anyone not choose Rust for some use-cases.

• We have been struggling with knowledge sharing in our codebase at work as it is growing and growing and the team is also growing. We’ve decided to focus more on documentation and I’ve found this gigantic guide on writing documentation. It looks like it’s focused on Open Source projects, but I think every project should be opened to communicate its inner workings in the same way. We don’t need to read the code of open source libraries when we use them. Why won’t we provide the same comfort to our colleagues as well?

• @xseman has linked me to this extension to the Gnome Desktop environment called Pop OS shell, during one of the streams. It brings almost all the things I am missing from i3 window manager into Gnome. It’s been developed for System76 Pop OS operating system, but it was no struggle to install it on my Fedora machine. Huge thanks to Filip!

You might notice, that I’ve skipped 2 weeks of posting. I have a very good excuse. I’ve been on a vacation in Mauritius. It was the best vacation I’ve ever been on. The only unfortunate part was that the flight back home from Istanbul to Budapest was canceled. So the trip got prolonged for another 2 days but we weren’t prepared for the weather.

DevBreak #1

Anyway, the comeback from the vacation was strong. I’ve successfully started my own talk show - DevBreak. I’ve invited my very close friend Lukas Orgovan and we had a wonderful time together on the stream. You can check out the first episode here where we talked about the State Of JS survey results and much more about software development. I’ve also gathered some feedback and I am very happy with the responses I got. I will be trying to improve the show and the stream onwards. I still don’t know how often I should do the show, and who will I invite for the next one. I have to admit I am very excited to continue delivering this type of content further, so I am already working on figuring all these things out. Thanks to everyone who joined. I really appreciate it.

During the regular stream on Thursday, I’ve finished working on the mermaid integration for the blog. It was a short one as I had plans for the late night. The blog post on mermaid integration is already in the progress.

Picks

During the vacation time, I’ve stumbled upon a great article about markdown by Knut Melvær and its usefulness for programmers and content creators. It tackles the problem with markdown very well and made me think about how do I want to write my content. Currently, I am on the unfortunate end of writing content as it’s explained in the article. That’s why I enjoyed it so much!

The next one is a simpler tutorial on Hosting a React App with OpenFaaS. I am an advocate for open-source software and I am glad to see OpenFaaS being still developed and trying to be more accessible for typical use-cases.

Be ready for the next one, Thank you!

This episode aired on the 15th of March 2022 and is in the Slovak language.

Error handling guide

You can check out the new article on error handling here. It is basically a practical continuation of the first guide for error handling I’ve written a year ago.

Stream updates

This week we have been discussing the state of JS on the Tuesday stream. It went very well and I didn’t even manage to get through it to the end. I am planning to continue on the topic when I get back from vacation on the 15th of March. I will prepare a few advertising materials (probably just a poster) and share them across social media as I want to run the stream officially.

Mermaid diagram parsing

On the Thursday stream, I’ve not been able to find a guest to discuss any topics so I just went for coding the diagram support for mermaid diagrams in my posts. I wanted to make render diagrams on the backend. I was very surprised that the mermaid is directly dependent on the browser to be able to render SVG. I had to rethink all over again how I would implement it.

I haven’t finished it, yet. So prepare for a new article where I will present the solution. I will stream it on my twitch so if you’re interested, please follow me there.

Let’s keep it short. Thank you!

Application architecture

The application is a slack bot on top of node js, TypeScript and PostgreSQL database. We use 3rd party APIs to fetch data about the times which we need to accumulate and process to calculate valuable information to our users.

It will run on a server with a possibility of migrating into serverless when we decide if it’s a good use case for it. We’ve decided that we won’t experiment too much for development as we want to make it useful first.

API design

As it is not a classic web server application I had to come up with slightly different error handling as we are used to. I’ve been trying to find a semi-functional API with all the good practices described in my guide on error handling. The main goal is to not let users be presented with internal information about errors. We want to show user-friendly messages instead. I call this API semi-functional as I didn’t want to use monads and go 100% functional. We use simple asynchronous functions to handle interactions. The goal is to handle errors that are expected. Unexpected errors should still be thrown and caught by an “Error boundary” around the whole app that will handle and log the error.

Error types

Let’s create 2 types of Errors that all the other Errors can be extended from. These will allow us to distinguish if the thrown Error should be presented to the user. We want to handle InternalErrors differently. We might log them to different logs or trigger alarms before we convert them to a different PublishableError.

export class PublishableError extends Error {
  publishable = true
  constructor(message: string) {
    super(message)
    Object.setPrototypeOf(this, PublishableError.prototype)
  }
}

export class InternalError extends Error {
  publishable = false
  constructor(message: string) {
    super(message)
    Object.setPrototypeOf(this, InternalError.prototype)
  }
}

Then, we can create multiple app-specific errors by extending from these two.

We need to set Object.setPrototypeOf(...) as TypeScript introduced a breaking change that may cause the inheritance to now work properly.

Handling errors

I wanted to have a similar style of handling the error as the Ramda’s tryCatch function. I couldn’t just use Ramda’s tryCatch as it doesn’t support asynchronous functions. I’ve found inspiration in the fp-ts TaskEither type.

I’ve come up with the following solution:

/**
 * Tuple of error and a result of an asynchronous task that might throw an error
 */
export type Either<ResultType, ErrorType extends Error> = Promise<
  [error: null, result: ResultType] | [error: ErrorType, result: undefined]
>

/**
 * Try to execute an async function and return a tuple of `[Error, ResultType]`
 * If the operation is successful error will be `null`
 * If the operation fails, the `errorHandler` runs with the exception that was thrown, Result is `undefined`
 * It catches all errors that might happen in the passed async task
 * It will not catch any errors that are thrown from the `errorHander`
 */
export function wrapWithErrorHandler<
  ErrorType extends Error,
  // TS is still able to inherit function parameters
  // eslint-disable-next-line @typescript-eslint/no-explicit-any
  FunctionArgs extends Array<any>,
  ResultType
>(
  errorHandler: (error: ErrorType | unknown) => ErrorType,
  fn: (...args: FunctionArgs) => Promise<ResultType>
): (...args: FunctionArgs) => Either<ResultType, ErrorType> {
  return async (...args: FunctionArgs) => {
    try {
      const result = await fn(...args)
      return [null, result]
    } catch (exception) {
      const errorHandlerResult = errorHandler(exception)
      return [errorHandlerResult, undefined]
    }
  }
}

I struggled with the typings for a few minutes but I was impressed with the result. The goal of this function is to wrap an asynchronous function that might throw errors and let the errorHandler process the error and return an alternative result.

As most of the errors will be possibly handled by the same errorHandle we can create a genericErrorHandler that might be used in most situations.

/**
 * Generic Error handler that should be used in most common use cases
 * It will throw an error if any unexpected error is thrown
 * When used with `wrapWithErrorHandler` it is able to catch most of the expected errors
 */
export function genericErrorHandler<ErrorType extends Error>(
  exception: ErrorType | unknown
) {
  if (exception instanceof PublishableError) {
    // These errors are usually handled no need to log them
    return exception
  }
  if (exception instanceof InternalError) {
    // Log error and return publishable generic error
    return new PublishableError(
      "I'm sorry for the inconvenience, but my circuits have been overloaded :zap:"
    )
  }

  if (exception instanceof Error) {
    // This is unexpected error, better log it and let rethrow it further away
    throw exception
  }

  return exception as ErrorType
}

To spare some characters of redundant code I’ve applied a partial application principle to use these functions together. At first, I’ve tried to use Ramda’s partial, but it was not able to inherit correct types, so I’ve just written the partially applied function myself:

/**
 * Helper function with applied `genericErrorHandler` to `wrapWithErrorHandler`
 */
export function wrapWithGenericErrorHandlerFunction<
  FunctionArgs extends Array<any>,
  ResultType
>(fn: (...args: FunctionArgs) => Promise<ResultType>) {
  return wrapWithErrorHandler(genericErrorHandler, fn)
}

Usage

To sum it up, I’d like to present you the way how this API is used:

const [error, memberId] = await wrapWithGenericErrorHandlerFunction(getUserId)(
  user.token
)
if (error) {
  await respond(error.message)
  return
}

This API allows me to keep the separation of concerns between the tasks and error handling into two separate functions. It also allows us to use the wrapWithErrorHandler with different errorHandler when we need to take special care. Also, I am still able to throw errors from the errorHandler that might be caught by a different errorHandler from an upper scope.

Thank you for reading!

Streaming setup

I use my Samsung Galaxy S21 as a camera via DroidCam. I have even bought the DroidCamX, just because it is the only software that successfully allowed me to connect my phone camera with the PC.

I needed to improve my camera angle. I was surprised by how quickly I was able to resolve this. We went shopping with my fiance and I found a wireless selfie stick that can be put into stand mode at the cash registers. I’ve immediately added it into the basket. It serves as a camera holder.

I was thinking about how I could leverage scenes in OBS to make the streaming settings more maintainable. A thought hit me that I can compose scenes into each other just like objects in programming. I couldn’t be the first to think of it, so I’ve tried to find somewhere on the internet a tutorial on how others manage it. I’ve found a great tutorial on YouTube by Gaming Careers, where he gives some tips on how to manage and compose scenes. I’ve created some scenes to be able to start streaming.

I asked one of my colleagues for a favor to encourage me to start to stream. We went on a call and I’ve started to stream. We were just talking about basic stuff around programming, but I’ve really enjoyed it. I left a note for myself that this post is being written during the first broadcast.

I am streaming right now as I am writing this post!

Broadcasting is very demanding for resources so to make better quality content I will eventually have to buy a dedicated computer. I’ve set a new sub goal for buying a streaming PC. I’ll buy it when the stream will reach 50 subs. Wish me luck!

Picks for this week

Last week I’ve been showing off new headphones that I’ve ordered and the YouTube algorithm has been suggesting great videos on the topic since. I will give another shoutout. This time it is to Joshua’s Valour YouTube channel

My next pick will be a podcast Lifespan hosted by Dr. David Sinclair where he talks about what we can do and how should we treat our bodies to live a longer and healthier life.

In our management course, we’ve been learning about different person typologies. That helped me to understand how I should treat other people and how to communicate better with them.

That’s it for this week. Thank you very much!

I’d like to resurrect a series of articles called Weeklys. It’s a weekly round-down of things I’ve learned, discovered, or caught my attention. I came up with this idea a few years ago when I’ve started blogging. I think it’s a good idea to keep up with writing on regular basis.

Headphone upgrade

I’ve been searching for new headphones for a few months. My current ATH-SR50BT from audio-technica headphones started to peel their skin off and they also have their headband holder broken. I’ve tried to find replacement parts but I’ve been already redirected 2 times to a different support company and the vision of repairing them started to fade away. I’ve been looking around the internet to find a new pair and I would like to shout out some of the few good resources I’ve stumbled on. I recommend checking out DMS YouTube channel for professional and interesting opinions on the performance of the most popular headphones out there. I’ve also found an online magazine headphonecheck.com. It features reviews and rankings of various types of headphones. In the end, I was searching for sustainable studio overhead open-backed headphones and I managed to order bayerdynamics new DT 900 Pro X.

Preview of the beyerdynamic DT 900 Pro X headphones

I can’t wait till they arrive. I got an unpleasant estimate of the arrival of 31th of May in my order confirmation mail. So I guess I will forget that I’ve ordered them and made myself a nice birthday surprise.

Stream setup

I always wanted to use my mobile phone camera as the main camera for the stream. Mainly because of the quality of the camera and the ability to have much better visuals. It would not look good on the stream to have a full-screen scene of just my notebook camera. I tried so many apps to accomplish this but finally, I’ve managed to get it working I was hoping that I can make the DroidCam OBS combination of OBS plugin and Android application to work but for some unknown reason the OBS plugin couldn’t find the camera through a USB connection. Instead, I’ve managed to connect through the plain DroidCam application. I’ve had to install a few missing libraries for the video capture and got it working. I’m really pumped up about this and started to plan out first testing streams and then planning on making something more official. Something like a talk show with some guests and just casual streams around coding and lifestyle.

Weeklys

I think that around the New year I wanted to start writing more often and bring back this idea of writing weekly updates. I must have forgotten about that because a whole month just went by and I haven’t written a single thing yet. But, I am happy that I made myself write this. I certainly want to write much more and create more content. In this series, I’d also like to post articles that caught my eye, but I don’t think that this week I’ve read any interesting ones. We’ve been introduced to the 7 delegations level for a delegation poker workshop that we did with management at work to align with each other. I hope it brings a valuable outcome. We yet have to see.

Ok, Thank you very much for reading and see you next week!

Different language ecosystems offer a different set of tools to develop automated tests. In this article, I am going to describe how various types of tests can be utilized to cover the most common testing scenarios for Web/Mobile applications development with 3rd party integrations.

• Unit tests
  • Tools that help writing unit tests
  • Additional resources for unit tests
• Snapshots
  • Additional resources on snapshots
• Integration testing
  • Tools that help writing integration tests
  • Additional resources for integration tests
• End to End (e2e) testing
  • Element selectors
  • Form validation
  • Authentication
  • Dedicated API routes
  • Screenshot matching
  • Tools that help writing e2e tests
  • Additional resources for e2e tests
• Component tests
  • Tools and resources for component testing
• Code coverage
  • Additional resources for code coverage

Unit tests

Unit tests are functions that test a single specific part of the application in small units. Function can be interpreted as a logical unit. Unit tests verify if this function has correct behavior with different arguments or its dependencies. A test consists of a description of the requirement that should be satisfied.

describe('Location formatter', () => {

  it('should format location based on a passed primaryLocation', () => {
    const formattedLocation = formatLocation({
      primaryLocation: 'Pennsylvania',
      city: null,
      countryIsoCode: 'US',
    })
    expect(formattedLocation).toBe('Pennsylvania, US')
  })
  
  it('should format location based on a passed city', () => {
    const formattedLocation = formatLocation({
      primaryLocation: null,
      city: 'Svidník',
      countryIsoCode: 'SK',
    })
    expect(formattedLocation).toBe('Svidník, SK')
  })

  it('should format location based on a passed primaryLocation with city being ignored', () => {
    const formattedLocation = formatLocation({
      primaryLocation: 'Pennsylvania',
      city: 'Košice',
      countryIsoCode: 'US',
    })
    expect(formattedLocation).toBe('Pennsylvania, US')
  })
})

These tests can run after any code change and they don’t affect other resources other than CPU. They are also good for practicing test-driven development as they are fast to execute and give immediate feedback to the developer.

If the tested unit is dependent on some external resource like time, browser setting, API response, or some service,mocking can be used to substitute the resource to the unit. Mocking is especially useful with a technique called dependency injection

The effect of the unit can be then tested on these mocks:

const service = {
  fetch: jest.fn(() => responseFixture)
}

// Using dependency injection
const result = fetchAndParseResponse(service, 'path')
// -- snip expecting correct result
// It's expected that `fetchAndParseResponse` will call the `fetch` only once
expect(service.fetch).toHaveBeenCalled(1)

Unit tests can also make use of snapshots.

Tools that help writing unit tests

• Jest testing framework
• mocha test runner - Usually paired with assertion library of choice
• Chai assertion library
• jest-date-mock - Testing functionality that is dependent on the Date

Additional resources for unit tests

• Jest mocking guide
• How to Start Unit Testing Your JavaScript Code by Ondrej Polesny @ FreeCodeCamp
• The importance of test driven development by Godswill Okwara @ medium.com

Snapshots

Snapshot matchers will save the input object as an artifact and they will use that artifact to compare the snapshot with the snapshot of the next test run.

it('should create a JSON response', () => {
  const feed = createFeedResponse();
  expect(JSON.parse(feed)).toMatchSnapshot('parsed feed');
});

On subsequent test runs, Jest will compare the output with the previous snapshot. If they match, the test will pass. If they don’t match, either the test runner found a bug in your code that should be fixed, or the implementation has changed and the snapshot needs to be updated.

These snapshots help to detect changes in the output of some functionality. They can also be used with a component renderer to detect changes in the output of component’s HTML, DOM or virtual DOM. Snapshots are created and updated by the test runner automatically so they lower the churn of updating tests over time.

Snapshot artifacts should be committed into the code repository alongside the tests, so they can be used as an input for the next test runs. Snapshots can be utilized for many types of tests.

If the expected result includes some varying data, property matchers can be utilized to verify the type of the data instead.

Additional resources on snapshots

• Jest snapshot testing

Integration testing

Integration tests are meant to validate the behavior of the individual components and their interaction with different system modules.

Take an API resolver as an example:

1. Resolver is given different parameters
2. It fetches some data from a database
3. Makes an action given the data
4. Returns a response to the client

An integration test should test and validate the functionality of this resolver. It should simulate a client request and assert desired response output. It should also verify the actions that the resolver is making.

// Mock the e-mail service, we don't want to send real emails
jest.mock('../email.js')

it('should send activation email', async () => {
  const client = await Client.query().findOne({
    firstName: 'testing',
    lastName: 'user',
  })
  const sendActivationEmail = await apolloClient.mutate({
    mutation: SEND_ACTIVATION_EMAIL_MUTATION,
    variables: { clientId: client.id },
  })

  expect(sendActivationEmail.errors).not.toBeDefined()
  // One email should be sent
  expect(email.send).toHaveBeenCalledTimes(1)

  // Verify that the email was sent with correct parameters
  expect(email.send).toHaveBeenCalledWith({
    templateId: EMAIL_TEMPLATE_IDS.CLIENT_EMAIL_ACTIVATION,
    to: client.contactEmail,
    data: {
      client_first_name: client.firstName,
    },
  })
})

It might be useful to mock some dependencies such as a database or a 3rd party API to ensure that these tests can run multiple times in sandboxed environment.

Sometimes it is desired to have a database, that is set up just for integration tests to avoid mocking. It can be also used for validating integration in between the tests. In this scenario, it is very useful to seed the database. The database can be then truncated and seeded in between the tests ensuring predictable and stable test results.

Integration tests can be run with the same test runner as the unit tests, but with a different configuration. Configuration might include a setup and a teardown process. When running tests with a database in place the tests could fail because the same data dependency is being modified in multiple tests at once, therefore it is required for these tests to run in serial mode.

Keep in mind that you should avoid testing 3rd party libraries or code that is not part of the application logic. This code is usually tested by the authors of those libraries.

Tools that help writing integration tests

• casual or faker - Fake data generators
• Utilities for testing Apollo Server
• supertest - HTTP request assertion library
• jest-fetch-mock - Request mocking
• SinonJS - Standalone test spies, stubs and mocks

Additional resources for integration tests

• What is API testing by Archana Choudary @ edureka.com
• GraphQL integration tests with apollo-server-testing, jest-mongodb and nock by Julien Deflaux @ medium.com

End to End (e2e) testing

e2e tests should guarantee that our users can browse and use the application. Every part of the application, whether it is a front-end, back-end, or a 3rd party integration, will be tested. We look to verify the behavior of the application in response to events triggered by the user or any different side-effect. The goal is to test the application from the user’s perspective.

Element selectors

There are different frameworks and approaches for creating DOM elements. These elements can have different representations of their state in the HTML. Developers should agree on the practice of selecting these elements in tests that suits them best. You should try to target elements in a way that you can be sure that the results will be consistent even after different layout changes that might happen throughout the lifetime of the project. Therefore I’d say that XPath is not the recommended way. To have selectors that are reliable and not changing with different layout changes we can use id attributes or even more sophisticated data-* attributes. With data-* attributes we can target multiple nodes with the same identifier and establish a convention that will make sure that the elements with these attributes are being used in the tests so if they are changed/deleted, there will have to be a change in the tests as well.

<button data-test-id="close-modal-button">Close</button>

You don’t have to mark all targeted elements with id you can use CSS selectors as well. Ensure, that you will not have to change stable test cases because of new additional features, which are not relevant to the established tested features.

Form validation

Forms should be tested for correctly evaluating validation. The errors should appear when the validation fails. It’s also good user experience testing when tests require validation errors to be displayed only if the elements were previously touched or the form was submitted.

it('should display validation errors', () => {
  // Form is submitted with `enter`
  cy.get('[data-test-id="first-name-input"]').type('{enter}')

  // All validation errors should be visible
  cy.get('[data-test-id="first-name-hint"]')
    .should('exist')
    .and('contain', 'First Name is a required field')
  cy.get('[data-test-id="last-name-hint"]')
    .should('exist')
    .and('contain', 'Last Name is a required field')
  cy.get('[data-test-id="email-hint"]')
    .should('exist')
    .and('contain', 'Email is a required field')
  cy.get('[data-test-id="password-hint"]')
    .should('exist')
    .and('contain', 'Password is a required field')
  cy.get('[data-test-id="terms-accepted-hint"]')
    .should('exist')
    .and('contain', 'You have to accept the terms of use')

  // Email field validation
  cy.get('[data-test-id="email-input"]').type(
    `invalid{enter}`
  )
  cy.get('[data-test-id="email-hint"]')
    .should('exist')
    .and('contain', 'Invalid email')
})

Form submission should be tested as well, to see if the back-end works correctly. It should be expected to see correct error messages being shown to the user when the submission fails. For example logging in with wrong password:

it('should toast wrong password', () => {
  cy.get('[data-test-id="email-input"]').type('user@login.test')
  cy.get('[data-test-id="password-input"]')type(
    `wrongpassword{enter}`
  // -- snip -- wait for submission
  cy.get('[data-test-id="error-message"]')
    .should('exist')
    .and('contain', 'The password is invalid or the user does not have a password.')
})

While submission is in progress, the loading state of the form can be expected for having disabled input fields. There should be a way to wait for asynchronous operations to be completed, so we can reliably test the loading behavior. Cypress has an intercept method, that allows us to hold the response and do as many expectations until it is desired for the response to be let go with the wait method.

cy.intercept('**/submit').as('submission')
// -- snip -- fill the form
cy.get('[data-test-id="submit-button"]').click()
// Expecting loading state
cy.get('[data-test-id="submit-button"]').should('have.class', 'loading').and('be.disabled')
// If submission request is already done if will be witheld from resolving until `cy.wait` is called
// Otherwise it will wait until the request is completed
cy.wait('@submission')

Authentication

Don’t try to log in to the application for every test that needs authenticated user. Test the login flow as a proper test case, but just for that sake only. For tests that require a user to be logged in, create a separate log-in functionality that will authenticate the user in the background without any browser interaction. This will speed up the testing process tremendously. Read cypress documentation on login for more examples.

Dedicated API routes

Sometimes it’s beneficial to implement a dedicated testing API route/resolver which will help seed individual tests or perform a clean up after some tests. Also, can be used for simulating a result of integration with 3rd party API without accessing 3rd party resources. Make sure that, these routes can only be run in a non-production environment.

Screenshot matching

Many plugins can be integrated into the testing environment, that enable testing visual regressions.

Screenshot snapshot matching allows to:

• Ensure, that the layout is not broken for different window sizes
• Check visual changes of every component as part of a review
• Prevent accidental visual regression in components

Screenshots can be taken of the whole viewport or individual components. Be sure to not include any variable data (Dates, IDs, etc.) in the screenshots as they will easily cause a mismatch.

Tools that help writing e2e tests

• Cypress testing framework - Next generation front-end testing framework
• Playwright - Playwright is a library to automate Chromium, Firefox and WebKit with a single API
• Puppeteer - High level API to control Chromium
• Jest-image-snapshot Matching image comparisons
• Percy - Visual review platform for visual regression tests

Additional resources for e2e tests

• Cypress testing strategies
• BrowserStack e2e testing guide by Shreya Bose

Component tests

Component tests take individual components and test them as a unit. These can run in the browser or just DOM simulator.

These tests, just like unit tests, should ensure that the expected output of the component is rendered based on the component input. They should also test the behavior of the component when any internal state change happens. For example, when you open an accordion, you should expect the children to be shown in the output. You can also expect, that the passed callbacks are being called according to event triggers.

Most often, these tests rely on snapshots. They reveal changes in the output of the components. Also, they save a tremendous amount of time and pain while maintaining these tests.

Tools and resources for component testing

• Cypress component testing
• React testing overview

Code coverage

While being an important metric it can also be misleading. It is a measure, that indicates how much of the source code is being executed while testing. Coverage can identify branches of code, that haven’t been validated. Having 100% coverage does not mean, that you have successfully tested your application. High coverage does not guarantee to have bug-free code. Therefore, it’s important to test all possible scenarios and validate the code according to requirements.

Additional resources for code coverage

• Jest code coverage report explained
• Code Coverage Tutorial

I have to admit, it was a wonderful experience and I’ve enjoyed it. I’d like to do it again in the future.

The episode was recorded in Slovak language. You can listen to the podcast episode here:

1. Use a logger

Do not use console directly. Programs should be able to define logging strategies dependant on the environment. We strongly recommend using a logging library such as Winston (commonly used in node.js programs).

Libraries should provide an easy way to choose a transport which will be used as on output for logs. Examples of transports:

• File
• Console
• 3rd party monitoring tools (e.g: loggly)

2. Log levels

You can set up as many log levels as needed. npm uses these 7:

{
  error: 0,
  warn: 1,
  info: 2,
  http: 3,
  verbose: 4,
  debug: 5,
  silly: 6
}

These are sorted by priority and should be used appropriately. What is logged depends on the environment(dev, test, prod…) in which the program operates. In the production environment, debug logs won’t be displayed since they would cause a lot of unnecessary noise. Verbose logs might be useful for staging environments where you want to see more information about what is happening in the system.

3. What to log

It is very important to log all the information required for developers and DevOps to retrieve as much valuable information from the logs as possible.

Messages are usually generated in a way where developers don’t have to add things like timestamps, log levels, etc., and repeat themselves. Timestamps and log levels are attached to the messages automatically.

Errors

Not every error should be logged. Validation errors and expected errors such as handled errors are common and they’re expected to happen frequently, so they shouldn’t interrupt the system in any way whatsoever. Therefore they should not be seen in logs. They can be shown in the access logs.

Unexpected errors should be logged with the highest priority (error). These errors should be monitored, prevented, and handled.

System state changes

Back-end apps strive to be stateless but they also do have some state like:

• served endpoint, port
• database connection
• 3rd party integrations

Changes in the system with valuable information should be logged with the info level. They serve as a great source of information about the system prior to the failure.

Debug

Don’t be hesitant to use debug logs. They can always be turned off or turned on back again while debugging. Most of the time developers tend to use console.log and then remove it before committing. I’d encourage you to use debug level and leave it there. It can be a big help in the future which can point you to the part of the code which is responsible for the manipulation of the data.

4. Don’t log sensitive information

Never, ever log credentials, passwords, or any sensitive information.

Front-end

Front-end logging is fundamentally different from the back-end. There is a new instance of the program for every opened window and it is only opened for 1 particular client. Developers should not expose the functionality to users.

There is an npm package debug that enables developers to write debug logs that persist in the codebase. To reveal the logs in the console, they have to be enabled.

There are 3rd party error monitoring services, that can help us collect information from errors that occur in different parts of the application.

• bugsnag
• Sentry

Let me show you some examples of what kind of errors there might happen and how to treat them.

Common scenarios

Don’t pay attention to the coding style here. There might be a different kind of libraries and conventions used in applications. Code samples are written just for the demonstration of the various scenarios and what should happen in those scenarios. Please read through the comments as they explain how errors should be treated.

Back-end application - Single run script or a CRON job

  try {
    // This can be any type of action that might fail
    Database.connect().insert({ value: 'Some information' })
  } catch (err) {
    // It's important to **log these** errors with highest priority (error)
    logger.error('Error happened while trying to insert some information', err) // Error context is passed here

    // Should the script continue?
    return
  }

It is necessary to pass the error along with context information, that will help to trace and resolve the issue.

Back-end application - Responding to client requests

This is usually how web applications are built and the most common scenario where errors should be properly handled as it might be a security threat.

  app.post('/message', (req, res) => {
    const { message, author } = req
    try {
      Database.connect().insert({ message, authorId: author.id })
    } catch (err) {
      if (err instanceof ValidationError) {
        // Validation errors are expected to happen often.
        // They are caused by a bad input from the user.
        // There is no need to log these errors as they don't cause a system crash.

        // Client should be informed on the matter of what went wrong with the request.
        res.status(400).json({
          message: `Invalid input. ${err.message}`
        })
      } else if (err instanceof RecoverableError) {
        // As a `RecovarableError` we can think of an error that most usually doesn't happen
        // but can and we have a way to continue the rest of the process and handle the error recovery later.
        // As an example we can imagine a case of sending an email to users with some information.
        logger.error('Error while sending mail', err, { message, author })

        // Sending an email is not a crucial part of the functionality and can be done later.
        // So we continue the functionality but we log the error so we know that we have to handle it. 
        res.status(200).json(data)
      } else {
        // This is an example of an **unexpected** error.
        // It doesn't only apply to a `Database`. You can replace the `Database` with any other 3rd party system.
        // These type of errors can be programmers fault for not handling certain scenarios correctly,
        // but also be caused by unexpected events happening in the system
        // (ex. Database server is down, usage of the wrong ID of relations in SQL queries)

        // In this case we want to `log` this error with full context,
        // so it can be found and fixed if it is a programmer's fault.
        logger.error('Unexpected error happened', err, { message, author })

        // Client should be informed of such an error but without the context, as it might reveal proprietary information about the system
        res.status(500).json({
          message: 'Unexpected error happened'
        })
      }
    }
  })

It is very important to keep all proprietary information about the system secure and private only to developers and system administrators. It is a security threat and it might be abused by malicious hackers when any of the information gets leaked. It doesn’t matter if the information is shown to the users or not, while it’s being sent to the client it can be discovered. I

However, if there is an additional error handling functionality in place which is able to filter out the error context in the production environment, it might be a good practice to include the error context in the development environment, as it will speed up the error discoverability.

To implement such a feature I’d recommend splitting message types sent to the client, so there isn’t a chance that someone would accidentally send proprietary information to the client.

  function sendError(body) {
    if (process.env === 'production') {
      return omit(body, 'errorContext')
    }
    return body
  }

  res.status(500).json(sendError({
    message: 'Unexpected error happened',
    errorContext: {req, message: `Error while submitting ${req.path}`, err}
  })

Front-end application - Handle an error from back-end

When an error happens on the back-end we should show this error to the client so the user knows that his action was not successfully fulfilled.

If the back-end handles errors correctly and sends the client an appropriate message, the client should be able to just show the informative description of the error that occurred.

Translating errors

If your application is built with any internationalization framework or with a translation system in general, there has to be some kind of mapping from error sent from the back-end to the translated message.

Simple mapping could be done by having a table of error codes for any application error that might happen. These codes don’t have to be strictly numeric. They can consist of some rules like having separators to distinguish services or parts that fail and which way. Examples RESOURCE-404, POST-404. It’s a good practice to have always a default message for unexpected errors which often do happen.

Front-end application - Network Error

These types of errors are least expected by developers but they happen regularly. Users usually lose connection when they browse while traveling or are connected to an unreliable mobile connection. It should always be anticipated that these errors can happen and the application should recover from the failure and allowed to retry their action.

Front-end application - unexpected error in application code

Errors which happen only on front-end are often a coding error. Most common examples would be not covering all possible cases of application logic or accessing properties that are undefined because of the unexpected shape of response data. While back-end applications can recover from their errors by restarting the process, it doesn’t apply to client applications where these types of errors might cause a crash or a freeze of an application. Some frameworks allow to recover from these crashes by implementing an error boundaries. See React Error Boundaries for example. I can only highly recommend using such a type of recovery.

If you use an external error monitoring tool like Sentry or bugsnag, don’t forget to log these errors from the error boundary.

Rules

To summarize this, we can create a list of rules:

• Error messages have to be informative for the client, but they can’t reveal private and proprietary information about the system architecture
• Errors should be logged only when they require additional action
• Errors that are recoverable should not crash the system
• Unexpected errors should turn into expected errors and be handled properly
• Failures between connections of the systems should be anticipated
• Client applications should be always able to recover from unexpected errors just as from expected ones

So I’ve been trying to set access to my CMS for a long time now. The problem was that in order to have CMS accessible through my domain, it requires an OAuth server. I’ve figured out that creating a custom serverless function which will handle the authentication with GitHub would be sufficient. So I’ve took some inspiration from the 2 repositories linked in Netlify CMS documentation:

• netlify-serverless-oauth2-backend
• netlify-cms-github-oauth-provider

The reason because I link both of these was that I’ve used the almighty AWS Amplify CLI to create an API for me, which has bootstrapped an express application for me. This turned out to be way easier then to make 4 independent functions as Amplify is not providing a different way of creating simple shared repository of multiple functions like serverless-framework does.

At one point as I was struggling with the Amplify CLI it managed to delete whole API once as I was trying to synchronize my changes with the cloud. But somewhere in the development process of the Amplify framework they made some changes which had made my previously used backend environments unusable. I wasn’t able to find any migration information about these changes or anything. I’d found some GitHub issues about similar problems which haven’t been resolved in any user friendly manners. So I’ve decided to just re-create these environments. I was lucky that I haven’t had anything important published in these. Also my IDE had saved me and I was able to restore deleted files from cache.

Turning point

After several attempts to publish the API on the AWS I figured out that to be able to use this API I have to configure a custom domain for it because AWS API Gateway appends /${stage} to every URL that it is published. This wouldn’t be so bad for any API but I was trying to create a OAuth authentication for Netlify CMS which required the base_name to be equal to the origin of the API. I was trying to configure custom domain name for this API then. Thinking that Amplify will be able to help me, but this isn’t a concern for its use case yet. So I’ve managed to create a certificate for the domain first. Waited half an hour for validation. And then finally I’ve got to the point that to be able to configure that custom domain name for this API I will have to configure AWS Route58, which is their DNS configuration service, to manage my entire domain which I haven’t set up yet as I didn’t think it would be necessary. My site has been working correctly just with CNAME configuration just right.

That was my the moment I’ve decided to quit AWS completely. This was after 2 days configuring and debugging a very simple think such as creating a simple API with 4 routes.

Alternatives

I’ve done some research and was looking between 2 main contenders to host my precious website:

• Netlify
• Vercel

I haven’t found a big decider feature in any of these so I just went with the one I already had an account set up - Netlify. I was able to configure whole deployment of my website in 8 minutes. The instructions where so clear and simple that I’ve also transfered my DNS nameserver too. I didn’t have to search in 10 different services and documentations. I’ve just went with the flow. Didn’t had to change a single line of code. I’ve just removed the amplify folder and I don’t want to see any of the AWS docs ever again.

It got me so pumped that I’ve immediately logged in to the CMS (finally) through my own domain and written this article.

By planning regular tasks like:

• Upgrading dependencies, gathering information about migrations, and creating tasks for those which require attention.
• Solving action points discussed on retrospective.
• Finding and creating tasks for dealing with technical debt.

Assign a certain amount of story points for each sprint to those tasks which have been accumulated and prioritized.

Action points are tasks agreed upon on retrospectives. These are the points which the team has agreed on. They should be solved in the upcoming sprint to make the developer experience better for the whole team.

I’ve used these notes for the discussion.

What should have been already known

WebAssembly is a new type of code that can be run in modern web browsers — it is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages such as C/C++ and Rust with a compilation target so that they can run on the web. It is also designed to run alongside JavaScript, allowing both to work together.

• https://developer.mozilla.org/en-US/docs/WebAssembly

The list of the languages that compile to WebAssembly is getting bigger and bigger. But does it support _.sample(popularLanguages)? Most probably: yes, it does. Someone already made a language designed for WebAssembly called Assembly script. It is heavily inspired by Typescript, and it targets web developers that don’t want to learn a new language.

Motivation behind WebAssembly

WebAssembly is a safe, portable, low-level code format designed for efficient execution and compact representation. Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.

• https://webassembly.github.io/spec/core/intro/introduction.html

As the WebAssembly programs are compiled into portable binary-code format, they are fast to transfer over the wire and also parse by clients.

Use of such technology allows new types of programs to be ran inside the web browser, such as:

• Image / Video editors
• AAA Games
• ML / AI-powered applications
• Scientific visualizations and simulations
• Live video augmentation
• Language interpreters and VMs
• CAD applications

Brief history

• 2013 - Mozilla designed asm.js, subset of JavaScript which allowed compiling C / C++ applications to be compiled for web while maintaining performance characteristics.
  • Compiling is done via Emscripten, which is still used as of today to port C applications to WASM.
• 2015 - WebAssembly announced with a feature set of asm.js
• 2017 - Initial MVP API designed and agreed upon in between 4 major browser vendors
• 2018 - Core specification released

Specification

Standardization process of WebAssembly is done in public at Github and is very similar to standardization process of JavaScript language.

Current version of the API is 1.1. It is intended that it will be superseded by new incremental releases with additional features in the future.

Here is a list of latest standartized features which are being implemented in browsers: Roadmap

List of applications making use of WebAssembly

• Figma
  • Figma has improved load times 3x with WASM
• Google Earth
• Photon Image processing
• Baldur’s Gate II
• Doom 3
• Flash virtualization
• AutoCAD
• ebay using WASM for barcode scanning
• Dropbox compression algorithm

Endless possibilities

What it could be used for

• Cross platform application development
• Hardware made directly for consuming WebAssembly instructions
  • If WASM is emergint to become the standard format for executables, tailor-made hardware chips migth become more efficient in the future. No more competing architectures.
• Transformation of the web to more efficient platform would have ecological impact on the environment. If the bundles are smaller and easier to parse that means it will significantly lower need for resources (less power consumption, cheaper hardware).

Web application frameworks

Blazor

Blazor is an open source and cross-platform web UI framework for building single-page apps using .NET and C# instead of JavaScript. Blazor is based on a powerful and flexible component model for building rich interactive web UI. You implement Blazor UI components using a combination of .NET code and Razor syntax: an elegant melding of HTML and C#. Blazor components can seamlessly handle UI events, bind to user input, and efficiently render UI updates.

Blazor WebAssembly is now the second supported way to host your Blazor components: client-side in the browser using a WebAssembly-based .NET runtime. Blazor WebAssembly includes a proper .NET runtime implemented in WebAssembly, a standardized bytecode for the web. This .NET runtime is downloaded with your Blazor WebAssembly app and enables running normal .NET code directly in the browser. No plugins or code transpilation are required. Blazor WebAssembly works with all modern web browsers, both desktop and mobile. Similar to JavaScript, Blazor WebAssembly apps run securely on the user’s device from within the browser’s security sandbox. These apps can be deployed as completely standalone static sites without any .NET server component at all, or they can be paired with ASP.NET Core to enable full stack web development with .NET, where code can be effortlessly shared with the client and server.

• https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-now-available/

Blazor overview

Yew

Yew is a modern Rust framework for creating multi-threaded front-end web apps with WebAssembly.

• Features a macro for declaring interactive HTML with Rust expressions. Developers who have experience using JSX in React should feel quite at home when using Yew.
• Achieves high performance by minimizing DOM API calls for each page render and by making it easy to offload processing to background web workers.
• Supports JavaScript interoperability, allowing developers to leverage NPM packages and integrate with existing JavaScript applications.
• github repository
• Sample app

Oak

Really simple framework for Golang Github

Conclusion

The discussion went for about 2 hours and it sparked many ideas. I am really glad that I’ve found time to do prepare and organize it. We talked a lot about how WebAssembly could be used in front-end frameworks for computational parts to increase the speed of calculations of DOM changes. In virtual-dom frameworks for example it could calculate the diffs more efficiently. I think, the frameworks presented are doing something similar, but with use of different languages. Which I think is for better. This sparked another discussion about programming languages. Especially how JavaScript is useful enough but is also ergonomic and friendly for programmers to use?

Discussions lasted for few days. I am really excited about the feedback I’ve received. I’ll definitely organize something similar in the near future.

What is RSS feed

RSS stands for Rich Site Summary. It is a specification for a XML formatted file which should provide short summary of the site content. First version was built in 1999 and the standard is still de facto standard across the web.

The feed should be short so the consuming applications can download these feeds on regular basis without too much data being transferred.

As I was looking into how could I implement RSS feed for this blog I was pretty unsatisfied with the information on the internet as there weren’t that many recipes or tutorials. The web was full of plugins or suggestions of dedicated software applications. Nothing really straight forward.

Alternatives

As the use of the internet changed through out the years there came some alternatives to the RSS feed specifications. First one that is also XML based is called Atom.

Atom was created as a response to the frozen RSS 2.0.1 specification which was not satisfying to use anymore. It requires feed to specify some required fields so its easier for feed readers to parse and display.

On the other side there is JSON Feed specification which takes the modern approach of minimalism and even more broader use. It only specifies a little information as required and supports a case of microblogging. The reason for JSON is that it is much commonly used in this information era than the XML format. I personally feel that way as well but the downside of this specification is that it is not very well known and used in consumer applications.

I am sure you can find much more information about Atom and JSON Feed on the internet.

How to create a feed for sapper site

This blog is created with sapper so to generate a feed I needed to create following file structure:

  - src
    + components
    - routes
      + blog
      - feed
        _feed.js
        index.json.js
        index.xml.js

_feed.js contains logic for creating the feed and the index.json.js and index.xml.js are there to provide desired path for the feeds. As you can tell I’ve built RSS feed as well as JSON one. For feed construction I’ve used node library https://github.com/jpmonette/feed which provides a way to export constructed feed into multiple formats. That’s why there is a _feed.js file which contains this logic that can be easily reused. Speaking of reusing logic. For the content I just refactored the blog listing logic and put the parser of the blog files into separate function and that was it.

I use export functionality of sapper so constructing the feed was not enough. As the export uses a crawler to find linked content on your site from the entry point, I had 2 options. Either add the path of the feeds to the export command to the AWS console or just link the feeds somewhere accessible in the site. Therefore I went for the generally better option and I’ve linked these feeds in the footer so now you can subscribe and receive updates with your feed consuming application of choice.

Discoverability

One thing that I’d struggled with was finding out information about how to let know these consumer applications where they can find my feeds. It took me some time to find but in the end it is just one <meta> tag in the <head> for each feed I offer.

<link rel="alternate" type="application/rss+xml" title="RSS feed for latest posts" href="https://michalvanko.dev/feed.xml" />
<link rel="alternate" title="JSON feed for latest posts" type="application/json" href="https://michalvanko.dev/feed.json" />

I’m pretty happy about implementing these feeds as I’ve learned something new about the possibilities of subscribing to content that I can filter myself and is not controlled by anyone else. I am trying out some applications that I’ve found and perhaps make a review of those at some point.

Sound quality

This is the number one priority for me that I seek in any headphones or speakers. I want to listen to music as it was composed to be listened. Sound has to be balanced and clear. I don’t like the amplified bass that most of the speakers are trying to do to hide the lack of the quality of the higher tones.

With the Buds+ I am really satisfied. For ear buds they have a very good sound. Nothing I ever experienced before. The listening still doesn’t match the enjoyment of listening on monitors but it’s very convienient for traveling or walking.

Noise cancellation

There is no active noise cancellation but I don’t think it’s even required. They even have butter noise cancellation then my other over-head headphones with active cancellation. They isolate as you put them inside your ear. It doesn’t even occur to me that I would have to re-adjust them. They fit nicely and stay and hold tight.

Ambient sound

Both buds have integrated microphone so when you have them on and don’t want to get them off you can just turn ambient sound and be back in the reality. The ambient sound is also loud enough that you don’t have to turn music off while doing some work, but when you try to communicate it really helps to turn it off. I don’t know how I should feel about not pulling them off while conversations because there isn’t really any downside to using ambient sound.

I wish that the microphone will be able to recognize wind and not cause my ears to bleed. It would make cycling a lot more enjoyable.

Comfort

These pair of buds is convenient to use. You can pick either one bud and use only that one. There is no limitation on which one has to be used as both are able to receive signal right from the source. They last as long as advertised. I charge them once a week and the charging speed is incredible. I am not going to put any numbers here because they charge so fast I don’t even notice them when they are fully charged.

One thing I was sceptical about truly wireless headphones is their ability to hold tight in ear without causing any pain. At first it was bothering me as I was not used to any of the plug headphones but in one week I got used to them. When I have my ears blocked with headphones I can feel the beat of my feet in my head, but that one got lost as well, or it’s not that significant anymore.

I didn’t had any technical difficulties.

Controls

There is still a room for improvement. I’d expect the controls to be more responsive. It often happens to me that I will prematurely press the “button” one more time than I wanted to because of the late sound feedback. Also there is this setting that I can control sound volume with a precise hit of the corner of the buds, but after many attempts I was not successful to find it. On the other hand, I really like the functionality of turning on ambient sound just by long-press.

Extra tip

There is one issue with the volume level by default. Buds have their own volume control when paired with some (old) phones and the volume is not set to be on maximum which can make you think that these do not perform very well at all. To fix this you have to:

1. go to the Wearables app and set controls on to volume controls.
2. Set the volume on maximum.
3. You can set the controls back to any of your preferences.
4. Enjoy?

Summary

In overall I recommend these or trying any truly wireless headphones out there. They are a revolutionary piece of hardware.

“What more can I say? Are you not entertained”?

What is Colemak keyboard layout

Lazy explanation would be that it is something between QWERTY and Dvorak. It keeps the most used shortcuts unchanged and moves the keys that are most frequently used to the middle.

Colemak keyboard layout preview

At the time of writing this it is the 3rd most used keyboard layout after those 2 mentioned above.

To get to know Colemak better I’d visit the official website.

In last article you might get sense of how I got passional for keyboards and it was a gateway for how can I improve my typing experience even more. I had no idea that there was something like Colemak before that. I knew that there is Dvorak but also knew that it is completely different and if I were to learn something new I had to see an easier path. Somewhere on the YouTube I saw few videos and presentations where there were comparisons between layouts and the typical “Why are we even using QWERTY in 21st century.” And I couldn’t agree more. It is never too late to learn something but I start to regret I haven’t done that much sooner.

The best argument to choose Colemak instead of Dvorak was that the most used and sometimes destructive keyboard shortcuts are kept at the same spot. So keys like Q W A Z X C V are not moved and will still be accessible used with Ctrl key. I did have a little problem with these keys anyway as I learned to use all 10 fingers as I was learning Colemak. According to Colemak website “Only 2 keys move between hands”. Which means that other keys moved only a little.

How I’ve learned it

The best way to learn it is to not get frustrated. So don’t set high expectations on yourself. I’ve decided to practice each evening for at least 20 - 30 minutes. I started with the home row practice on https://thetypingcat.com/. I’d go from using only 4 keys to whole row by adding 2 keys each time until I’ve got to 30 words per second.

I’ve set Colemak as the primary keyboard layout in GNOME which made all shortcuts to only work as I was on Colemak even if I were using QWERTY while I was working. That turned up to be a great start because my brain thinks of shortcuts not by its key but what it usually does. The first shortcut that caused me pain was Ctrl-S even thou it only moved one key to the right. I am used to save my files manually so I press this combination a lot. Fortunately Ctrl-R does nothing in my VS Code so nothing bad happens when I miss the save. I’ve lasted for 2 weeks and then I had a comfortable time just being on this weird setup where I had different shortcuts but still familiar keyboard until I’ve built myself a keyboard and decided to only type with Colemak on it. So I did it. I’ve known only home row and some other shortcuts (Ctrl-P to open file, Ctrl-F to find). And without any practice of other rows I’ve jumped into the water and started to write on keyboard layout with much difficulties but I have to say it is the best way to learn it as you just have to learn what key does what.

For the first week I had a browser tab opened with the keyboard layout so I look up a key and find it that way rather than try out every key. As Sean “Day 9” Plott says: “You don’t click the building in the menu. You find the shortcut and press it anyway so you learn it along the way.” As he is teaching how to play StarCraft. Inspired by this, I don’t have to have the keys printed out on the keyboard. I have to memorize their position by using them.

You may ask how was I able to work when I was barely able to write? Well as a programmer I don’t write that much code. Most of the time the programming consist of reading someone elses code and thinking how to implement certain feature. The writing part is the smallest one really. Most of the writing is done in between the programmers themselves. Yeah I had much struggles responding to messages as I was typing a single sentence for whole minute. This frustrated me but I was progressing very quickly.

After few months I’ve discovered that I can also setup Colemak on the mobile phone as well. So I immediately did. Writing on mobile is completely different experience because I tend to miss-click a lot more because of the size of the buttons. And mistakes are harder to auto-correct as it isn’t build with the premise of using different layout. The E and I keys are now next to each other and which causes these mistakes to happen.

Common struggles

Shortcuts

The first most common struggle was with shortcuts. Simply my brain is not connecting the letters to the actions but it just remembers that when I press certain combinatation it does that action which I got used to. The most destructive shortcuts are at the same position so I haven’t got any serious issues.

Finding a key

Sounds simple but I often used to just hit the same spot for single key over and over and it just wasn’t there. Also quotes are moved on the P key position which is hard to find on keyboard as you don’t expect a non letter key over there. But it turned out to be a great change.

Passwords

Another one that your brain don’t even think of how it types out, it just does. Well all passwords automatically changed for me so I had to le-learn to write them differently.

Current state

At this point I am comfortable using Colemak layout without any reoccurring struggles. The typing speed is not even close to what it used to be but that doesn’t matter that much. I do a lot of mistakes so the Backspace button is used more often. That was the first thing that I got used to actually. The CapsLock button being transformed into Backspace is great idea. I haven’t used CapsLock ever.

I’ve started to struggle to type on QWERTY layout instead. Every time I have to type with it I have to look at the keyboard and only type with 4 fingers which is pretty ugly. I’m also used to tap CapsLock whenever I do mistake which happens a lot.

In overall I am very happy with the switch. It’s not only that I learned typing with all 10 fingers but the layout is much more comfortable as well.