Forem: Josué Rodríguez (He/Him)

What are your goals for 2023?

Josué Rodríguez (He/Him) — Mon, 02 Jan 2023 03:33:50 +0000

Happy new year everybody! I hope this new year brings many good things to all of you and it may be a year where you grow as professionals and people.

Let's talk about your goals. What were your goals for last year? Did you accomplish those goals? Are they still in progress? Remember that progress, whether small or big, is still progress, and you should feel really proud of yourself!

What are your goals for this new year? Before starting to write this article, I was writing on a notebook some of the things that I want to accomplish for this year, and I wanted to share with you some of the things I wrote:

Start my journey in data science. I've always found this topic very interesting but never made the time to actually study. This year, as a way of making myself study, I bought a year subscrition to some data science courses.
Travel more, both inside and outside of my country. Fun fact about myself, I've never traveled outside of my country. I want to change that this year.
Learn more about personal finances and manage my money better.
Write more articles in here.
Practice more with my guitar and learn a silly skill like card tricks or playing with dices (I want to learn how to stack them in a cup).
Read a book monthly (Open to suggestions! Let me know books that you like).
Go to more live music events.

Let me know in the comments about some of your goals for this year!

Flask folder structure and init.py file

Josué Rodríguez (He/Him) — Mon, 28 Jun 2021 00:36:40 +0000

Hello everybody!

Last week I started studying about how to develop a REST API with Flask. I know very little about Python, basically just syntax and how to run a script, but I'm completely blank when it comes to folder structure and special files (such as the __init__.py file). I have strong knowledge of JavaScript and TypeScript and about backends with Node (Express and Nest).

My first question is about the folder structure, I would like to know what is the best practice for structuring my project. Right now, my project is looking like this (trying to replicate how I do it with Node):

my_project/
-src/
--__init__.py
--blueprints/
---books/
----__init__.py
-tests/
--__init__.py
--test_books.py
-run.py

(Your answers don't necessarily need to be for a Flask project, if you tell how you structure your random Python projects that would help too!)

My second question is about the __init__.py file. I've read that by adding that file you are making the folder a package or module. I had it inside my blueprints folder, but I removed it just to see what would happen and my project was unaffected.

So, my questions would be:

When should I add this file to my folders and when should I not?
When should I leave that file blank and when should I write code to it?

Thanks in advance for your time and your answers ✨

Open-Closed Principle

Josué Rodríguez (He/Him) — Wed, 09 Jun 2021 22:41:02 +0000

The Open-Closed Principle states that classes must remain open for extension but closed for modification.

Classes must remain open for extension but closed for modification.

This means that if we want to add more functionality to a class we should do it by extending the behavior of the class without actually changing the class itself. This may seem pretty confusing at first, but will make sense with the code example.

The objective of this principle is to avoid modifications that may lead to bugs where the class is being used.

Example

Let's imagine that we are developing a Checkout functionality for a store that offers discounts to Senior clients and Pregnant clients. At first, our base code will be the following:

class Checkout {
  getTotalToPay(total, clientType) {
    let totalToPay = total;
    let discount = 0;

    if (clientType === 'Senior') {
      discount = total * 0.25;
      totalToPay = totalToPay - discount;
    } else if (clientType === 'Pregnant') {
      discount = total * 0.15;
      totalToPay = totalToPay - discount;
    }
    return totalToPay;
  }
}

const checkout = new Checkout();
console.log(checkout.getTotalToPay(100, 'Senior'));
console.log(checkout.getTotalToPay(100, 'Pregnant'));
console.log(checkout.getTotalToPay(100, 'Regular Client'));

By looking at the code you may think that everything is okay, but the reality is we are breaking the Open-Closed Prinicple. This is because, even though the class is open for extension as we may have as many client types as we like, it is not closed for modification.

Let's say that we want to add the Veteran type of client. To do this, we would simply need to add another else if to our code. The resulting code will be the following:

class Checkout {
  getTotalToPay(total, clientType) {
    let totalToPay = total;
    let discount = 0;

    if (clientType === 'Senior') {
      discount = total * 0.25;
      totalToPay = totalToPay - discount;
    } else if (clientType === 'Pregnant') {
      discount = total * 0.15;
      totalToPay = totalToPay - discount;
    } else if (clientType === 'Veteran') {
      discount = total * 0.10;
      totalToPay = totalToPay - discount;
    }
    return totalToPay;
  }
}

const checkout = new Checkout();
console.log(checkout.getTotalToPay(100, 'Senior'));
console.log(checkout.getTotalToPay(100, 'Pregnant'));
console.log(checkout.getTotalToPay(100, 'Veteran'));
console.log(checkout.getTotalToPay(100, 'Regular Client'));

Since we had to modify our code to allow this new type of client, we broke the Closed part of the principle.

To adhere to the principle, we may split every type of client into a class and handle the checkout calculation by abstraction. The refactoring of the code would be the following:

class Checkout {
  getTotalToPay(total, clientType) {
    let discount = clientType.getDiscount(total);
    let totalToPay = total - discount;
    return totalToPay;
  }
}

class SeniorClient {
  getDiscount(total) {
    return total * 0.25;
  }
}

class PregnantClient {
  getDiscount(total) {
    return total * 0.15;
  }
}

class VeteranClient {
  getDiscount(total) {
    return total * 0.1;
  }
}

class RegularClient {
  getDiscount(total) {
    return total * 0;
  }
}
const checkout = new Checkout();
console.log(checkout.getTotalToPay(100, new SeniorClient()));
console.log(checkout.getTotalToPay(100, new PregnantClient()));
console.log(checkout.getTotalToPay(100, new VeteranClient()));
console.log(checkout.getTotalToPay(100, new RegularClient()));

By splitting each client type into different classes, we don't need to touch the Checkout class again. If we wanted to add another client type we would only need to create it as a new class and pass it to the getTotalToPay function, following the Open-Closed Principle.

Liskov Substitution Principle

Josué Rodríguez (He/Him) — Thu, 03 Jun 2021 15:18:10 +0000

The Liskov Substitution Principle states that in an inheritance, a parent class should be substitutable for its child class without any problem.

A parent class should be substitutable for its child class without any problem.

This is because in inheritance, the child class should be able to do everything the parent class can do, delivering the same or even improved results.

Getting into more detail about the definition of the class, the principle also implies that the child class's methods should have the same amount of arguments and the arguments type and return type should be of the same type of the parent class that they override.

The objective behind this principle is to strengthen consistency so that parent and children classes can be used in the same way without any errors.

Example

Imagine we have a parent class Animal and it has two children, Dog and Cat. Each animal has its unique sound, dogs can bark and cats can meow. At first, our class declarations will look like this:

class Animal {
  bark() {
    return 'This is a bark sound!';
  }

  meow() {
    return 'This is meow sound!';
  }
}

class Dog extends Animal {
  bark() {
    return 'Woof woof';
  }

  meow() {
    return new Error(`Dogs can't meow`);
  }
}

class Cat extends Animal {
  bark() {
    return new Error(`Cats can't bark`);
  }

  meow() {
    return 'Meow meow';
  }
}

const dog = new Animal();
const cat = new Animal();

// The following method calls will print 'This is an bark sound!'
console.log(dog.bark());
console.log(cat.bark());

// The following method calls will print 'This is a meow sound!'
console.log(dog.meow());
console.log(cat.meow());

Both bark method calls will print "This is a bark sound!" and both meow method calls will print "This is a meow sound!". Now, if we were to substitute the parent class with the corresponding children, we would have a problem and a violation of the Liskov Substitution Principle. This is because dogs can't meow and cats can't bark, or in other words, they can't perform all the actions their parent can. Also, on the children class, some methods are returning a different type compared to what their parent returns. The code for this violation would be the following:

// Change Animal to the corresponding children
const dog = new Dog();
const cat = new Cat();

// The dog will bark and the cat will throw an error
console.log(dog.bark());
console.log(cat.bark());

// The cat will meow and the dog will throw an error
console.log(dog.meow());
console.log(cat.meow());

To fix this violation of the principle, we will create a more generic method for the animal sounds instead of specific methods for each animal sound. And also, we will make sure that every method returns the same type. The refactoring of this code will be the following:

class Animal {
  makeSound() {
    return 'This is an animal sound';
  }
}

class Dog extends Animal {
  makeSound() {
    return 'Woof woof';
  }
}

class Cat extends Animal {
  makeSound() {
    return 'Meow meow';
  }
}

let dog = new Animal();
let cat = new Animal();

// These method calls will print 'This is an animal sound!'
console.log(dog.makeSound());
console.log(cat.makeSound());

dog = new Dog();
cat = new Cat();

// The dog will bark and the cat will meow
console.log(dog.makeSound());
console.log(cat.makeSound());

As you can see, we successfully substituted the parent class with any of their children and the classes were able to handle the requests without a problem, just as the Liskov Substitution Principle states.

Interface Segregation Principle

Josué Rodríguez (He/Him) — Mon, 24 May 2021 21:46:35 +0000

The Interface Segregation Principle states that a client should never be forced to implement an interface that it does not use, or clients shouldn't be forced to depend on methods they do not use.

A client should never be forced to implement an interface that it does not use, or clients shouldn't be forced to depend on methods they do not use.

The objective behind this principle is to remove unnecessary
code from Classes in order to reduce unexpected bugs when the Class does not have the ability to perform an action. We split actions into smaller sets so a Class only executes the actions it requires.

Example

I'll be giving two examples, one with JavaScript since it's the programming language we've been using on the previous principles, and another general example on how to implement this principle on different programming languages.

Since JavaScript does not implement interfaces, we'll be demonstrating this principle through composition by adding pieces of functionality to the classes that need specific actions.

Imagine we have a streaming platform that has two types of user, a FreeUser and a PremiumUser, both extending from User. At first, the code looks something like this:

class User {
  constructor(username) {
    this.username = username;
  }

  skipAd() {
    console.log(`I'm going to skip if I'm premium`);
  }

  startParty() {
    console.log(`I'm going to start a party if I'm premium`);
  }
}

class FreeUser extends User {
  constructor(username) {
    super(username);
  }

  skipAd() {
    return null;
  }

  startParty() {
    return null;
  }
}

class PremiumUser extends User {
  constructor(username) {
    super(username);
  }

  skipAd() {
    console.log(`Ad was skipped.`);
  }

  startParty() {
    console.log(`Party started, invite your friends!`);
  }
}

// The following code will execute
// and print the message
const premium = new PremiumUser(`premium_username`);
premium.skipAd();
premium.startParty();

// The following code will execute
// but return null
const free = new FreeUser(`free_username`);
free.skipAd();
free.startParty();

Taking into consideration that only a PremiumUser is able to skip ads and start parties, we are violating the Interface Segregation Prinicple by forcing both User and FreeUser to implement these actions. To apply the principle, we may use composition to only give these functionalities to PremiumUser. After applying the principle, the code would be the following.

class User {
  constructor(username) {
    this.username = username;
  }
}

class FreeUser extends User {
  constructor(username) {
    super(username);
  }
}

class PremiumUser extends User {
  constructor(username) {
    super(username);
  }
}

const premiumBenefits = {
  skipAd() {
    console.log('Ad was skipped.');
  },
  startParty() {
    console.log('Party started, invite your friends!');
  },
};

Object.assign(PremiumUser.prototype, premiumBenefits);

// The following code will execute
// and print the message
const premium = new PremiumUser('premium_username');
premium.skipAd();
premium.startParty();

// The following code will throw an exception
// because a FreeUser does not implement these methods
const free = new FreeUser('free_username');
free.skipAd();
free.startParty();

Now every class is implementing only the functionalities that they need, adhering to the principle.

To apply this principle to other programming languages, we may use something I like to call "cascading specialization" in which we start on the most general specialization and then, on each level of the inheritance, we add specific actions that the interface needs. The following diagram shows this idea.

Following our FreeUser and PremiumUser example, we may have these inheritances, each one of them adding specific functioanlities depending on the subscription type.

Dependency Inversion Principle

Josué Rodríguez (He/Him) — Fri, 23 Apr 2021 00:38:48 +0000

The Dependency Inversion Principle states that entities must depend on abstractions, not on concretions. High-level modules should not depend on low-level modules. Both should depend on abstraction.

High-level modules should not depend on low-level modules. Both should depend on abstraction.

When we talk about high-level modules we are referring to a class that executes an action implementing a tool or library, and when we talk about low-level modules we are referring to the tools or libraries that are needed to execute an action.

The principle allows for decoupling, which means to separate, disengage or dissociate something from something else. This helps us by reducing dependency and allowing for easier implementations of other tools in the future.

Example

Let's imagine that we have a Candy Store and we are developing the checkout process. In the beginning, we only planned to implement Stripe as our payments processor. Stripe needs for the amount to be passed on as cents to make the transaction. Our classes will look something like this:

//Checkout.js
class Checkout {
  constructor() {
    this.paymentProcessor = new Stripe('USD');
  }

  makePayment(amount) {
    //Multiplying by 100 to get the cents
    this.paymentProcessor.createTransaction(amount * 100);
  }
}

//Stripe.js
//Custom Stripe implementation that calls the Stripe API
class Stripe {
  constructor(currency) {
    this.currency = currency;
  }

  createTransaction(amount) {
    /*Call the Stripe API methods*/
    console.log(`Payment made for $${amount / 100}`);
  }
}

Notice that we created a dependency between our Checkout class (high-level module) and Stripe (low-level module), violating the Dependency Inversion Principle. The dependency is especially noticeable when we convert the amount to cents. The Checkout should not care about which payment processor is being used, it only cares about making a transaction.

To decouple these two modules, we would have to implement an intermediary between the checkout and the payment processor, creating an abstraction so that no matter what payment processor we use, the Checkout class will always work with the same method calls. The new PaymentProcessor class will be in charge of adapting everything to payment processor to be used (in this case, Stripe). The intermediary class will have the following code:

//PaymentProcessor.js
class PaymentProcessor {
  constructor(processor, currency) {
    this.processor = processor;
    this.currency = currency;
  }

  createPaymentIntent(amount) {
    const amountInCents = amount * 100;
    this.processor.createTransaction(amountInCents);
  }
}

As you can see, the createPaymentIntent on the PaymentProcessor class is converting the amount to cents. And now we refactor the Checkout class to implement the abstraction:

//Checkout.js
class Checkout {
  constructor(paymentProcessor) {
    this.paymentProcessor = paymentProcessor;
  }

  makePayment(amount) {
    this.paymentProcessor.createPaymentIntent(amount);
  }
}

Now, if we ever need to change our payment processor, we can do so by passing the new processor instead of Stripe to the PaymentProcessor constructor. Then, we pass the PaymentProcessor to the Checkout:

//index.js
const paymentProcessor = new PaymentProcessor(new Stripe('USD'), 'USD');
const checkout = new Checkout(paymentProcessor);

Imagine that now we are asked to replace Stripe with another payment processor that does not require for the amount to be converted to cents but on every transaction asks for the currency that's going to be used. The resulting code will be the following:

//Checkout.js
class Checkout {
  constructor(paymentProcessor) {
    this.paymentProcessor = paymentProcessor;
  }

  makePayment(amount) {
    this.paymentProcessor.createPaymentIntent(amount);
  }
}

//PaymentProcessor.js
class PaymentProcessor {
  constructor(processor, currency) {
    this.processor = processor;
    this.currency = currency;
  }

  createPaymentIntent(amount) {
    this.processor.createTransaction(amount, this.currency);
  }
}

//BetterProcessor.js
class BetterProcessor {
  createTransaction(amount, currency) {
    console.log(`Payment made for ${amount} ${currency}`);
  }
}

//index.js
const paymentProcessor = new PaymentProcessor(new BetterProcessor(), 'USD');
const checkout = new Checkout(paymentProcessor);

Notice how we only changed the processor passed to the PaymentProcessor class and how the Checkout class remained untouched. We adapted the intermediary class PaymentProcessor to the processor needs.

We removed the dependency between Checkout and the processor used by implementing the intermediary class PaymentProcessor, following the Dependency Inversion Principle.

Single Responsibility Principle

Josué Rodríguez (He/Him) — Tue, 13 Apr 2021 23:41:38 +0000

The Single Responsibility Principle states that a class should have one and only one reason to change. It also states that each class should only have one job and do it well.

A class should have one and only one reason to change.

The reason behind this principle is to separate responsibilities or behaviors so that debugging and refactoring shouldn't cause problems to other parts of a project.

A good way to see if a class adheres to this principle is to say out loud the responsibilities the class has and be on the lookout for and's. Every and should go on a separate class.

Example

Let's say we have an Employee Management class that's responsible for basic CRUD operations over Employees and Logging the results on the console (👀). In this class, we have a function that pushes employees to an array and a function to log the result of the operation. The code would be something like this:

//EmployeeManagement.js

class EmployeeManagement {
  constructor() {
    this.employees = [];
  }

  addEmployee(employee) {
    this.employees.push(employee);
    this.logResult('[LOG] EMPLOYEE ADDED');
  }

  logResult(message) {
    console.log(message);
  }
}

Suppose that you're asked to apply the following changes to the code:

Add a validation so that the employee's name isn't empty.
Log operations results into a file and not the console.

Let's apply change number 1. The resulting code will be the following:

//EmployeeManagement.js

class EmployeeManagement {
  constructor() {
    this.employees = [];
  }

  addEmployee(employee) {
    if (employee.name) {
      this.employees.push(employee);
      this.logResult('[LOG] EMPLOYEE ADDED');
    } else {
      this.logResult('[ERROR] NAME MUST NOT BE EMPTY');
    }
  }

  logResult(message) {
    console.log(message);
  }
}

Validating that the employee's name is not empty is still a behavior expected from an Employee Management class. The reason to change was to improve the creation of employees.

Now let's apply change 2. The resulting code will be the following:

//EmployeeManagement.js

class EmployeeManagement {
  constructor() {
    this.employees = [];
  }

  addEmployee(employee) {
    if (employee.name) {
      this.employees.push(employee);
      this.logResult('[LOG] EMPLOYEE ADDED');
    } else {
      this.logResult('[ERROR] NAME MUST NOT BE EMPTY');
    }
  }

  logResult(message) {
    /*writeToFile is a mock function, just for educational purposes*/
    writeToFile(message);
  }
}

Logging the result of the operation into a file is not a behavior related to Employees Management. Does it relate to CRUD operations?.

You can tell by now that the Employee Management class had two reasons to change, going against the Single Responsibility Principle. Did you notice when I explained what the class was going to do I used one "and" 👀?

Let's say we have an Employee Management class that's responsible for basic CRUD operations over Employees and Logging the results on the console.

To apply the principle, we should have the logResult function on a separate Logger class so that if we ever want to change the way we log the results, it should be on its own, separate class. The refactor of the classes should be as follows:

//EmployeeManagement.js

class EmployeeManagement {
  constructor() {
    this.employees = [];
    this.logger = new Logger();
  }

  addEmployee(employee) {
    if (employee.name) {
      this.employees.push(employee);
      this.logger.logResult('[LOG] EMPLOYEE ADDED');
    } else {
      this.logger.logResult('[ERROR] NAME MUST NOT BE EMPTY');
    }
  }
}

//Logger.js
class Logger {
  logResult(message) {
    /*writeToFile is a mock function, just for educational purposes*/
    writeToFile(message);
  }
}

Remember that we want each class to have one and only one reason to change. With the new code, if we want to change the way we add an employee or the way we log the results of an operation we can do so in their own, separate classes, following the Single Responsibility Principle.

Introduction to SOLID Principles

Josué Rodríguez (He/Him) — Tue, 13 Apr 2021 23:41:07 +0000

The code is the main source of truth of what developers are really made of. Writing clean and maintainable code is something everybody should aim for. Personally, I've been on both ends: being the one who writes smelly code and being the one who refactors smelly code. Along the way, I've learned many principles that have really improved my code. A set of those principles are the SOLID Principles.

What is SOLID?

SOLID is an acronym for five software development principles stated by Robert C. Martin, also known as Uncle Bob, for object-oriented programming. Applying these principles will make your code become easier to scale and maintain. It will also make your project development more productive through decomposition and decoupling by removing code smells and reducing time spent on refactoring.

The acronym stands for:

S - Single-responsibility Principle
O - Open-closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

SOLID tends to improve code rigidity, fragility, reusability, and remove needless complexity.

Common misconceptions about SOLID

Is SOLID made for programming languages, frameworks, or what?

SOLID is neither a framework, nor a library, nor a pattern. It is also not bound to any particular technology. You can apply these principles to your favorite programming language such as TypeScript or Java, or to your favorite framework such as React or Express.

Is there an order to apply the principles?

Not really. They have only been arranged this way to spell SOLID and make it catchy. I read once that the acronym came to life because a friend of Robert C. Martin told him that if he swapped the order of the letters, they would spell SOLID.

Do I have to apply the 5 principles to my project?

The number of principles you will apply to your project will depend on the smells your code has. Each principle addresses a specific problem, and if your code does not have that problem, there's no reason to apply the principle.

How SOLID is my code?

SOLID principles are not something you can measure. There isn't something like saying "My code is 100% SOLID".

Closing words

I'll create a series explaining every SOLID principle. The explanation will be beginner-friendly and with code examples. I'm always open to suggestions and comments since I'm still a newbie at writing blogs 😋

Expo Pedometer not returning step count in Android

Josué Rodríguez (He/Him) — Wed, 04 Mar 2020 19:11:47 +0000

Hello everybody, today I need help.
I'm developing an app with React Native and Expo.

I'm having issues with the Pedometer included in "expo-sensors". The problem is, the function Pedometer.getStepCountAsync does not work in Android, the function returns "Getting step count for date range is not supported on Android yet". I've been reading about this issue and found out that it is an Expo problem, the function worked perfectly around Expo 32, but with the updates, it stopped working.

Does anyone know a workaround for this issue? Or does anyone know how to retrieve the steps the user has taken in the day (with this module or any other)? I would really appreciate any help!

March 26, 2021 Edit:

One year later, I didn't find a solution for this. I've seen the issue I opened on GitHub getting more comments about "I've got the same issue. If many people have this issue why don't they do something?", but no concrete answer (at least, since the last time I checked).

The most promising thing I found (but didn't test since I was moved from that project) was using the Google Fit API to record the steps the user takes. Hope this helps somebody, and if anybody ever finds a working solution, please leave it in the comments for everyone to see 😊

Today I learned how to retrieve your WiFi password from Windows

Josué Rodríguez (He/Him) — Wed, 15 Jan 2020 17:53:09 +0000

Hey guys, it's JD again! I want to share with you a little trick that I learned because a friend forgot her WiFi password and I offered to help. I'm going to show you how to retrieve your WiFi password from your Windows computer. You should consider the following:

This will only work with admin rights.
You have to be connected to the WiFi network.

Let's begin!

First, open your Control Panel and locate the Network and Internet option. Click where it says View network status and tasks.

Now, let's click where it says Change adapter settings

This will open a new window. Next, right-click on WiFi and click on the Status option.

On the window that pops, click the button that says Wireless Properties which will open yet another window. We'll click on the tab that says Security.

And finally, click the checkbox that says Show characters.

And there you have it! That's how you retrieve a WiFi password from Windows!

Conclusion

This little tip may help a friend or family member that forgot their WiFi password, and that'll be your time to shine✨. It's a nice little tip to know. That's it guys, see you later! 😁

Installing FiraCode on Windows and Ubuntu

Josué Rodríguez (He/Him) — Mon, 13 Jan 2020 02:59:36 +0000

Hello again, JD here. Today I'm writing about how to install FiraCode on Windows and Ubuntu. This post is copying and pasting some commands on the console (at least that's the way I do it). So let's get to it.

About FiraCode

FiraCode is a monospaced font with programming ligatures developed by Nikita Prokopov (tonsky on GitHub).

tonsky / FiraCode

Free monospaced font with programming ligatures

Fira Code: free monospaced font with programming ligatures

Read in Español | 简体中文 | 日本語

Problem

Programmers use a lot of symbols, often encoded with several characters. For the human brain, sequences like ->, <= or := are single logical tokens, even if they take two or three characters on the screen. Your eye spends a non-zero amount of energy to scan, parse and join multiple characters into a single logical one. Ideally, all programming languages should be designed with full-fledged Unicode symbols for operators, but that’s not the case yet.

Solution

Fira Code is a free monospaced font containing ligatures for common programming multi-character combinations. This is just a font rendering feature: underlying code remains ASCII-compatible. This helps to read and understand code faster. For some frequent sequences like .. or //, ligatures allow us to correct spacing.

Download & Install

Then:

View on GitHub

By the time I discovered FiraCode I was working on some JavaScript projects and that's the main reason I became so attracted to the font. FiraCode gives the arrow functions, the "===" and many other things an amazing look.

Installing on Windows

To install FiraCode on Windows we are going to use Chocolatey.
Note: If you have Python installed on Windows, I suggest you run the following command to verify if you have Chocolatey installed. Python installs Chocolatey to fetch some dependencies.



choco -v

If it returns the version number, then you're all set and you can jump directly to FiraCode command. If it doesn't, then run one of the following commands with administrative permissions to install Chocolatey.

Run this command on the CMD



@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"

Or run this command on PowerShell



Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

FiraCode command

Finally, run this command to install FiraCode:



choco install firacode

And voilà! We've got FiraCode installed on Windows!

Installing on Ubuntu

To install FiraCode on Ubuntu you have to enable the universe repository. To do this we have to run the following commands on the terminal:



sudo add-apt-repository universe
sudo apt update

If that command doesn't work, try this one instead:



sudo add-apt-repository "deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc) universe"
sudo apt update

And finally, run the command:



sudo apt install fonts-firacode

Ta-da! FiraCode is now on Ubuntu!

Conclusion

That's it! We've successfully installed FiraCode on both Windows and Ubuntu! Let me know in the comments if this was helpful, or if there's something I should improve! 😁

My VS Code customization

Josué Rodríguez (He/Him) — Sat, 11 Jan 2020 04:51:17 +0000

Hey guys! JD here with my first post. VS Code is a powerful editor used by millions of developers all over the world. Based on my experience, most of the users I know only install a theme and that's their whole customization! So I'm dedicating my first post to show you how I customized my VS Code. Feel free to leave any comments sharing your customization!

Fun fact: With some classmates, we have a saying that goes "Hay que afilar el machete" which translates to "Sharpen the machete" or "Sharpen the knife", basically meaning to sharpen your tool of work.

Themes and Icons

One of the first things we do when we install VS Code is looking for the right theme. I'm a Dark theme user myself, but the themes I'm about to mention include various options in black, white and even red! These themes include:

Dark+ Material (The one I currently have installed).
Material Theme
Dracula Official

As for icons, I like two options equally and always have a hard time deciding on which one to use:

Material Icon Theme
vscode-icons

Extensions

I've got two extensions that are a must-have:

Bracket Pair Colorizer
Live Share

Bracket Pair Colorizer helps you by coloring each pair of (), {} and [], so you can keep track of the scope you're in and also highlights the body of the scope you're in. Live Share is a powerful tool for working remotely with your teammates. The latest versions of Live Share now include a chat and audio sharing. Other two useful extensions that I've used are Eslint and Prettier for React projects. Here's a guide on how to set them!

Article No Longer Available

You can install all of the above directly from the VS Code Marketplace.

Editing the Settings (JSON)

Now we're getting to the juicy part! We're going to edit the JSON that holds all the settings for VS Code. Don't worry, nothing will explode (probably). To access this JSON file, hit F1 on your computer and type Settings (JSON).

NOTE: Some themes modify this JSON, so if there's some configuration that you didn't write, don't worry about it. Remember to save the file after you make changes for the customizations to take place.

FiraCode

FiraCode is an awesome font with ligatures! Here's my guide on installing FiraCode on Windows and Ubuntu!

Installing FiraCode on Windows and Ubuntu

Josué Rodríguez (He/Him) ・ Jan 13 '20

#firacode #fonts #windows #ubuntu

To enable Firacode on our VS Code, add the following lines to the Settings JSON:

{
  "editor.fontFamily": "Fira Code",
  "editor.fontLigatures": true 
}

Rendering the minimap

VS Code's minimap is helpful and unreadable. So why even bother on trying to render the characters? Let's give the minimap a better look by disabling the render option by adding the following line to the JSON:

{
  "editor.minimap.renderCharacters": false
}

Here's how the minimap looks without rendering:

Customizing the cursor looks and behavior

You can customize your cursor by adding some lines to the JSON file. I have configured it like this:

{
  "editor.cursorBlinking": "expand",
  "editor.cursorSmoothCaretAnimation": true,
  "editor.cursorStyle":"line",
  "editor.cursorWidth": 2
}

I encourage you to play with the cursorBlinking and the cursorStyle to find the one that suits you better. You can customize cursorBlinking with blink, expand, phase, smooth or solid and the cursorStyle with block, block-outline, line, line-thin, underline or underline-thin.

Changing comments color

Sometimes we need to locate comments as fast as possible, so what better way to do it than by giving them an annoyingly bright color? Add this line to the JSON file, just change the hex to one of your choice:

{
  "editor.tokenColorCustomizations": {
    "comments": "#00ff00"
  }
}

Making method and function names bold

Finally, we arrived to my favorite customization! This is the type of customization I didn't know I needed, and now that I have it, I can't live without it! Making method and function names bold gives them an awesome look and makes them easier to identify in our code. Here's the JSON:

{
  "editor.tokenColorCustomizations": {
    "textMateRules": [{
      "scope": [
        "entity.name.function",
        "entity.name.method",
      ],
      "settings": {
        "fontStyle": "bold"
      }
    }]
  }
}

Try playing around with the "entity" option, it has many different options you can add.

Conclusion

Here's my JSON:

{
  "editor.minimap.renderCharacters": false,
  "editor.cursorBlinking": "expand",
  "editor.cursorSmoothCaretAnimation": true,
  "editor.cursorStyle":"line",
  "editor.cursorWidth": 2,
  "editor.fontFamily": "Fira Code",
  "editor.fontLigatures": true,
  "editor.tokenColorCustomizations": {
    "comments": "#00ff00",
    "textMateRules": [{
      "scope": [
        "entity.name.function",
        "entity.name.method",
      ],
      "settings": {
        "fontStyle": "bold"
      }
    }]
 }
}

And that's it! If you know any other customization feel free to share it with me in the comments!

Forem: Josué Rodríguez (He/Him)

What are your goals for 2023?

Flask folder structure and __init__.py file

Open-Closed Principle

Example

Liskov Substitution Principle

Example

Interface Segregation Principle

Example

Dependency Inversion Principle

Example

Single Responsibility Principle

Example

Introduction to SOLID Principles

What is SOLID?

Common misconceptions about SOLID

Is SOLID made for programming languages, frameworks, or what?

Is there an order to apply the principles?

Do I have to apply the 5 principles to my project?

How SOLID is my code?

Closing words

Expo Pedometer not returning step count in Android

Today I learned how to retrieve your WiFi password from Windows

Let's begin!

Conclusion

Installing FiraCode on Windows and Ubuntu

About FiraCode

tonsky / FiraCode

Free monospaced font with programming ligatures

Fira Code: free monospaced font with programming ligatures

Problem

Solution

Download & Install

Installing on Windows

Run this command on the CMD

Or run this command on PowerShell

FiraCode command

Installing on Ubuntu

Conclusion

My VS Code customization

Themes and Icons

Extensions

Article No Longer Available

Editing the Settings (JSON)

FiraCode

Installing FiraCode on Windows and Ubuntu

Josué Rodríguez (He/Him) ・ Jan 13 '20

Rendering the minimap

Customizing the cursor looks and behavior

Changing comments color

Making method and function names bold

Conclusion

Flask folder structure and init.py file