Forem: Manu Rodríguez

Creando objetivos reales

Manu Rodríguez — Tue, 01 Aug 2023 13:12:07 +0000

Uno de los errores más comunes es el de imponernos objetivos poco realistas o difíciles de alcanzar en un corto plazo de tiempo (terminar tareas grandes en un solo día, refactorizar toda una funcionalidad en una sola sesión, etc…).

Muchas veces esto lo hacemos de manera inconsciente por querer mejorar o ser más productivos y con la falsa idea de que cuanto más trabajo entreguemos en el menor tiempo seremos mejores desarrolladores, sin pararnos a pensar en los efectos colaterales que puede tener esta decisión. Esto puede provocar varias cosas, por ejemplo:

Código poco legible o de mala calidad
Errores en el diseño que pueden provocar otros errores mayores
Frustración por querer terminar la tarea en el menor tiempo posible
Sensación de que no avanzamos debido a los errores que han aparecido, lo que puede hacer que la sensación de frustración sea mayor todavía

Las cosas importantes no se construyen en un día

Para evitar esta situación, intenta dividir tu objetivo en otros objetivos más pequeños que te asegures que puedes realizar en un breve espacio de tiempo (horas o incluso días, no tienes que ser un superhéroe).

Gracias a dividir tu objetivo en objetivos más pequeños, podrás ir viendo algunas mejoras en tu trabajo y en ti mismo como individuo:

Un código mucho más limpio y de mejor calidad
Diseño mucho más pensado y meditado para un correcto uso. Se darán menos errores, aunque seguirán existiendo (no somos perfecto, cometeremos errores)
Satisfacción por cumplir metas.

Uno de los puntos más importantes a mi parecer es el poder tener esa satisfacción de un trabajo terminado y que hemos conseguido entregar. Además nos impulsará a poder seguir con otros objetivos.

Gracias a poder cumplir estos objetivos más pequeños, veremos como cada vez estamos más cerca de poder cumplir ese objetivo mayor que teníamos al principio como meta.

Abrazando el equilibrio dinámico

Es muy normal pensar que tenemos siempre que hacer un mínimo de cosas para sentirnos productivos o que tenemos que hacer las tareas en un “tempo” definido porque sino estaremos por debajo de un estándar de productividad y dejaremos de ser productivos. A esto lo podríamos llamar “equilibrio estático” (por ejemplo: todos los días hacer un número determinado de tareas, dedicarle todos los días 1 hora a aprender algo…). Pero ese término se aleja bastante de la realidad.

Tenemos que ser conscientes de que habrá momentos de nuestra vida que podremos hacer más cosas y otras veces menos (tendremos más energía o menos, habrá situaciones personales o familiares que nos favorezca o no…), pero lo importante es el computo global de cosas que se han hecho a lo largo de un periodo largo de tiempo. Además si estas tareas las realizamos en un “tempo” en el que nos sentimos cómodos para su realización, no nos sentimos con una sobrecarga de trabajo, nos motiva o gusta el trabajo que estamos haciendo… veremos que los resultados son muchísimo mejores en un periodo largo de tiempo. Esta idea la llamó un amigo “equilibrio dinámico”.

Dentro de ese equilibrio dinámico, tenemos que ser capaces de dedicar tiempo a poder descansar y dedicarle tiempo a cosas que nos gusten (familia, amigos, hobbies…). No es necesario que estemos constantemente buscando el sentirnos aceptados como desarrolladores por tener más o menos proyectos personales, hacer/grabar cursos, preparar charlas… debemos de recordar que ante todo somos personas, y como personas, tenemos el derecho a sentirnos cansados.

How to Build Maintainable iOS Apps with Dependency Injection

Manu Rodríguez — Sat, 29 Apr 2023 18:43:46 +0000

Hey there fellow developers! Are you tired of your iOS apps becoming an unmaintainable mess of spaghetti code?

Fear not, for there is a solution: dependency injection. In this article, we'll show you how to use dependency injection to create clean, testable code that's easy to maintain.

If you're new to dependency injection or just want to improve your iOS development skills, then this article is for you. Let's get started!

Take Control of Your Code: 5 Key Benefits of Dependency Injection in iOS Programming

Before we dive into the nitty-gritty, let's talk about the benefits of using dependency injection in your iOS apps:

Increased modularity: Dependency injection allows objects to be created outside of a class and passed as parameters, making code more modular.
Reduced coupling: Injected objects are not coupled to a particular class, making code more flexible and easier to maintain.
Increased code reuse: Injected objects can be reused in multiple classes and applications, reducing code duplication and improving efficiency.
Easier testing: Dependency injection makes it easier to perform unit testing on code, as injected objects can be replaced with test objects.
Improved performance: By avoiding the creation of unnecessary objects, dependency injection can improve the performance of the application.

Dependency Injection in action!

Let's say you want to retrieve a list of users from a repository. Normally, you might create an instance of the repository directly in your view or presenter class. But with dependency injection, we can create an interface for the repository and pass in an implementation of it at runtime.

protocol UserRepository {
    func getUsers(completion: @escaping ([User]) -> Void)
}

Next, we create an implementation of the repository that uses an instance of UserService to retrieve the data:

class UserRepositoryImp: UserRepository {
    private let userService: UserService

    init(userService: UserService) {
        self.userService = userService
    }

    func getUsers(completion: @escaping ([User]) -> Void) {
        userService.fetchUsers { users in
            completion(users)
        }
    }
}

In this example, UserRepositoryImp uses an instance of UserService to retrieve the data. By using dependency injection, we can pass any implementation of UserService to UserRepositoryImp and use it to retrieve the data.

Now, to use UserRepositoryImp in our application, we can inject it into our view or presenter class, for example:

class UserListPresenter {
    private let userRepository: UserRepository
    private var users: [User] = []

    init(userRepository: UserRepository) {
        self.userRepository = userRepository
    }

    func getUsers() {
        userRepository.getUsers { [weak self] users in
            self?.users = users
            // update view with users
        }
    }
}

In this example, UserListPresenter uses UserRepository to retrieve the data. By using dependency injection, we can pass any implementation of UserRepository to UserListPresenter and use it to retrieve the data.

And… how to do tests with dependency injection?

Finally, to perform unit testing on our code, we can create a mocked implementation of UserRepository that returns test data and pass it to our test class:

class MockUserRepository: UserRepository {
    func getUsers(completion: @escaping ([User]) -> Void) {
        let users = [User(name: "User 1"), User(name: "User 2"), User(name: "User 3")]
        completion(users)
    }
}

class UserListPresenterTests: XCTestCase {
    func testGetUsers() {
        let mockRepository = MockUserRepository()
        let presenter = UserListPresenter(userRepository: mockRepository)

        presenter.getUsers()

        XCTAssertEqual(presenter.users.count, 3)
        XCTAssertEqual(presenter.users[0].name, "User 1")
        XCTAssertEqual(presenter.users[1].name, "User 2")
        XCTAssertEqual(presenter.users[2].name, "User 3")
    }
}

In this example, we create a mocked implementation of UserRepository called MockUserRepository, which returns a list of test users. We then create an instance of UserListPresenter with MockUserRepository injected and call the getUsers() method to retrieve the data. Finally, we check that the data was retrieved correctly.

I hope this example helps you understand how to use dependency injection to retrieve data from a repository and implement an interface to aid in testing.

Look Around, a window to reality

Manu Rodríguez — Tue, 04 Oct 2022 16:17:22 +0000

One of the main innovations that Apple showed at the last WWDC was undoubtedly the improvements in MapKit and the new features that it incorporated in its latest version to provide the user with a better user experience. Perhaps one of the most striking has been the possibility of adding the functionality of Look Around (name given to the Street View developed by Apple) in your application, which allows us to see in 360 a location as if we were on site.

Requirements

To be able to use this new functionality, you must meet the following requirements

Xcode 14.0
iOS 16.0

Adding it to your application

Our first step will be to generate an MKLookAroundScene, which we can obtain from a location that we pass to the MKLookAroundSceneRequest class as shown in the example code:

Once we have obtained our MKLookAroundScene, we will have to create a MKLookAroundViewController (it will be in charge of showing our street view). For it we can do it in the following way:

Oops... something went wrong

Ok... at this point you are probably thinking that you can use MKLookAroundViewController as another UIViewController inside your application and make a classic navigation with this controller (present, push...), surely if you have tried it without reading on you will have found that something strange is happening with your player, like you can't navigate through the streets, the name of the street doesn't appear, etc...

This is because in order to use this new UIViewController, you cannot use it as if it was a classic UIViewController with its own navigation system. You must use it as an embedded view inside a UIViewController of your view hierarchy as in the following example:

Handicaps

A priori it seems a little strange to have to use this functionality in this way and not be able to use MKLookAroundViewController as if it were an independent UIViewController, it is something that hopefully Apple will end up solving in future versions of Swift.
MKLookAroundViewController has another handicap at the time of being used and it is the following one: it cannot be used on a view that comes from a modal present, since in the case of being used in that view, this one will appear disabled when our MKLookAroundViewController is closed.
If you need to display it over a view that has been displayed through a present, you must display the parent view using the .overFullScreen mode.

parentViewController.modalPresentationStyle = .overFullScreen

Congratulations on getting this far! You have successfully implemented Look Around in your brand new application. Now you will give your users a better user experience if they want to know what is near a location.

Automating things

Manu Rodríguez — Tue, 20 Sep 2022 17:44:06 +0000

Surely if you are more or less new to the world of programming you will have heard one or two things about "CI/CD" or heard the word "Jenkins" being mentioned.

If you don't know what those words mean... this is the post for you! I will try to explain everything you need to know about CI/CD in case you want to take your first steps (if you are a veteran you are also welcome).

What is CI/CD?

This is a code distribution methodology that covers the entire code life cycle. From the time new code is developed and integrated into the existing code, until a version of the application is deployed or distributed with the new code, along with subsequent version monitoring to check for possible bugs.

When we refer to CI/CD we are referring to two different terms or work philosophies based on the automation of tasks, which are:

CI → Continuous Integration

CD → Continuous Delivery/Deployment

Let's look at these two concepts separately.

Continuous Integration, a.k.a. "CI".

It is very common that in your work environment you do not work alone but you work together with other team members and each of you work on completely different parts of the project. This is most common, and what is even more common is the "merge day", that wonderful day when all the code is brought together to work in harmony.

But... oh boy! Something went wrong. Too many changes in the project, everyone is in pain and what seemed to be a wonderful day, turns into a gray day of regrets and disappointments.

Continuous integration to the rescue

Continuous integration (CI) consists of a work philosophy based on integrating the code written by a developer into the main project as soon as possible (it is no good uploading code with bugs, we already know that...).

In this way, this code is made accessible to the rest of the teammates, in some cases on the same day.

To avoid possible errors in the integration, it is necessary to have different tools such as :

Unit Tests
Integration Test
Code analysis
Code review, etc...

It is not necessary to incorporate all these tools to your project. They can be incorporated progressively depending on the needs you want to cover or the size of the project. If it is a small project, you may not need to add a code analyzer, such as SonarCloud, SonarQube, DeepSource, etc...

Continuous Delivery VS Continuous Deployment

Sometimes we could make the mistake of not knowing how to differentiate between continuous delivery and continuous deployment. At first glance, both concepts seem very similar since the final objective is the same, to release a version.

The difference lies in who performs the action, i.e., whether it is the developer or a third party who performs the action of deploying the version (either by pressing a button in Slack, launching a command in the terminal or simply sending a version for review), we are talking about continuous delivery.

On the other hand, if the developer or a third party is not required to perform this action but it is executed in a fully automated way, we speak of continuous deployment.

And who controls this?

At this point, you are probably wondering what you need to do to set up your project with CI/CD and see if this works for you or not.

It is very common to think that you need a whole team of people to set up an IC/DC ecosystem for your application, to set up a big rack of machines connected to a big network with a very high connection speed and to do super complicated and complex tasks like you are entering the Matrix. And no, you're not.

The developer also set up pipelines

Normally we tend to think that this is a task that should be done by the infrastructure or SRE team in the development team, but I believe that this is not the case.

The infrastructure team should provide you with the environment to set up your workflows (virtual machine, Kubernetes, etc...), but developers should be autonomous enough to be able to set up the workflows or pipelines by themselves and make the necessary modifications.

Let's think about it more carefully... the developer is the one who best knows the requirements of the application environment, what he needs to test, how he needs to test it, how he needs to generate the versions and so on and so forth. In the same way, the infrastructure team knows much better all the security aspects of the VPN you use to work, where the hosted repository is located, etc... That is why I consider that it is the responsibility of the developer to set up the pipelines or workflows since he/she is ultimately responsible for making sure that his/her code works in the best possible way.

Okay, so what do I do if I can't maintain the IC/DC system myself?

Nowadays there are very easy to use tools that allow you to have a CI/CD ecosystem in a few minutes by editing just one file.

GitHub Actions (includes support for iOS) allows you in a few steps - and by setting up a YAML file - to create a whole ecosystem of workflows that will be executed when a pull request is opened, a tag is created, a commit is uploaded to a branch, etc...

Here’s is an example of how we can set up a simple workflow in Github Action to run some tests of our application on different versions of MacOS

# This is a basic workflow to help you get started with Actions

name: Testing

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the "master" branch
  pull_request:
    branches: [ "master" ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  macos:
    strategy:
      fail-fast: false
      matrix:
        macos:
          - 11
          - 12
        xcode:
          - latest-stable
        include:
          - macos: 11
            xcode: latest
    runs-on: macos-${{ matrix.macos }}
    steps:
      - name: Get Sources
        uses: actions/checkout@v2

      - name: Setup Xcode
        uses: maxim-lobanov/setup-xcode@v1.4.0
        with:
          xcode-version: "13.1"

      - name: Build Package
        run: swift build -v

      - name: Run tests
        run: swift test --enable-code-coverage -v

Apart from GitHub Actions there are many other options, such as: CircleCI, Bitrise, CodeMagic... you simply have to find the solution that best suits you and start testing!

I can only leave you with one last opinion about integrating CI/CD to your project, and here it is: