DEV Community: Uriel

How to kill a stuck Rails server

Uriel — Mon, 27 Apr 2020 05:02:37 +0000

When the Ctrl + C shortcut has abandoned you there's a simple way to kill your Rails server if you are under a UNIX OS, say MacOs or any Linux distribution.

The first thing you need is to find the PID of the process that is running the rails server, for it, go ahead and open the file under the following location: YOUR_PROJECT/tmp/pids/server.pid

Inside this file, you will find a number, that's the PID you are looking for, just copy it to use it in the kill command that we will use to kill the server.

Once you have the PID of the process, you may use the kill command on your terminal to end the rails server:

kill -9 <your-pid>

Alternatively, if you can't find your PID under the mentioned location, you can look for the processes running under the 3000 port to find the proper ID, depending on your OS, the command to find out what processes are running under a given port may differ.

And that's it, whether it's because your code went under a loop, or because you closed your VS Code editor without ending the rails server, this alternative will help you kill your rails server no matter what.

Why graphql is so important for Gatsby and modern web dev

Uriel — Fri, 29 Nov 2019 17:45:20 +0000

TL;DR; Gatsby uses graphql as a common interface to query data without assuming anything from your data source, by doing this it allows you to add, remove or change your data source without further implications for your code.

The power of ORMs

As a Ruby on Rails developer who also loves JavaScript, I have seen and used multiple Node.js frameworks without ever falling in love with any of them, and one of the main reasons for it is the ActiveRecord.

The ActiveRecord (commonly referred to as AR in the Rails community) is the ORM that comes prepacked with Ruby on Rails, it allows you to communicate with your database using an object-oriented interface that normally ends up being way more readable and expressive than plain SQL queries. And although one of the main features of the AR is its powerful and expressive API, it is probably the fact that it adds an additional layer between your data and your code what ends up being the most interesting feature from this ORM.

Adding that extra layer of communication allows developers to switch between database engines or even database paradigms (SQL or no SQL). And although switching a database engine is not a common thing to do for an application, you normally get to work with different data sources in different projects.

The ActiveRecord allows you to switch between database engines through different projects, to choose what fits best for your application, without having to relearn or adapt any of your previous implementations, which eventually, allows you to be way more productive in every new project you start.

Beyond ORMs

ORMs, like the ActiveRecord, end up being powerful implementations that come with enormous benefits (and some tradeoffs) when working with a database as a source of information, but in modern web development, data often comes from a more diverse pool of options, from traditional database to web services, the filesystem, cloud databases and so much more. It is common for modern web projects to bring data from a combination of diverse sources that an ORM is not made to understand.

Enter graphql. graphql is described according to their website(https://graphql.org/) as a query for your API, and although one may come first to mind is a web service, an API can actually be whatever source that exposes a way to communicate with your data, and this is where things get increasingly interesting for modern web development.

Given that graphql does not assume anything from your data source, just that it should have an interface of communication, you can actually use graphql to query data from any given source, precisely as Gatsby does, more from this later.

This gives you that extra layer of abstraction, that allows you to plug your application into different data sources, with probably a different API for each one of them, and communicate with them using a common API, the graphql query language.

This benefit gets more important in the current landscape for web development where data can come from a numerous and diverse pool of sources. Having a common API to communicate with any data sources allows you to add, remove, or change data sources for any project, depending on the needs of each individual project, without having to adapt your code or relearn anything.

Gatsby and graphql

Gatsby uses graphql for multiple reasons that are extensively explained in the docs(https://www.gatsbyjs.org/docs/why-gatsby-uses-graphql/), one of them is as a form of communication with whatever data source you are using.

Remember that Gatsby does not have an opinion on the kind of data source you may use for any web application you are building with Gatsby, so it is important for the framework to have a common interface of communication that does not change for any data source. This is where Gatsby and graphql make the perfect match.

With this combination, you may use the Wordpress graphql server, or the Wordpress REST API as a data source for one project, and the filesystem with a cloud database for another one, without having to relearn the framework or adapt your React components who may be reused across multiple projects.

The source plugins

What allows graphql to adapt to any data source, is that it is a super abstract API, with no implementations for any data source. This means that for any data source, you have to implement the communication between your graphql engine and the data source’s API.

Gatsby solves this for you through the implementation of plugins and the vibrant community around the framework that has implemented numerous plugins for hundreds of data sources. This means that any developer may only implement the integration between graphql and any data source once, then, if it is packaged as a plugin, this implementation may be reused between different projects and developers.

This makes Gatsby one of the first web frameworks that allow the usage of multiple data sources and APIs without forcing you to relearn anything, adapt your current implementations, or modify your code when changing data sources for an existing project.

This feels like the power of the ActiveRecord for Rails but way more powerful and it is the reason why after years of exploring Node.js frameworks, Gatsby felt like the right way of using JavaScript for modern web applications.

How to deal with critics.

Uriel — Tue, 24 Sep 2019 15:55:22 +0000

I have been creating content for about 8 years now, mostly for YouTube in a channel with over 500k subscribers, I also work for an online school with over 300k students signed up. During this time I've had awesome reviews, good reviews, bad reviews, angry reviews and all kind of ways to say both good and bad things, so I have had to learn how to deal with reviews, specially the bad ones since those are the ones that stay in your head the most

In this article I would like to give some advice to people who are starting creating content for the internet in order to help them pass through comments that can ruin your day immediately.

One for the reviewers

This is important to say and say it loud *words matter.

The way you say something, the way you give advice, feedback, or the way you complain matters to someone, so it is important to keep in mind that there are humans behind the content that you consume everyday so you can express what you want in a way that helps other grow, instead of just making them feel bad about it.

And keep in mind that if you have been rude to someone, any moment is a good one to retract yourself and say sorry.

The pain of bad reviews

I know, I know... depending on the day you are having, receiving a bad comment can really ruin your day, like I have had sleeplessness nights just thinking about that one comment that bashed my work, or that one rude person that keeps leaving bad reviews on my work. I have seen people leave the public space just to avoid dealing with rude people. So yeah, it is super important to have a plan or some advice to deal with this kind of comments.

I mention this just so you know that it is not only you, everyone receives bad reviews, even those who have been doing this for years. And you are not alone when feeling bad about it, you are not being dramatic and you are not overreacting to the words of someone you don't even know. Feeling bad about this is not only valid, but it is something every creator has to dealt with.

I understand that for many of us, getting our work criticized feels like being pointed towards you personally, so it is understandable tho feel bad about it.

How to deal with bad reviews

After validating our feelings, let's go to how to deal with this.

It is not personal (normally)

First of all, you are not your work and your talent or capacity can't be measured through just one thing you have done, so, don't take it personally.

Of course, in some cases the hate and the bad reviews are, in fact, personal, but in those cases it is important to use the blocking tools from social networks and to keep the haters away from you, block the noise and focus on those who want you to grow and for your work to get better.

Switch your perspective

A coworker I admire a lot always remember us how important is that someone invest they time in the content we create, in our case we teach programming so He keeps reminding us about the value of someone investing their time for learning.

This is important for me because it helps to keep working in improving the content I produce, but also to keep myself humble.

Learning to receive positive feedback it is also learning to be humble, because sometimes even if the person that leaves their review tries to do so in a positive way, it feels bad when someone didn't liked your content.

As important as the time you have invested producing content you also can think about the importance of people watching or consuming your stuff, so when someone comes to say stuff like "Audio was horrible", think not only about how that makes you feel as a content creator, but also, how does bad audio makes you feel as a consumer.

Keep your perspective as a consumer in front of you while reading reviews on your content.

Respond with kindness

This sounds silly but it is super effective. I understand if you don't have the wellness to go around responding with kindness to bad reviews, specially to the ones that didn't express the same kindness, but yeah, it works.

Try it out sometime, read what the consumer says, breath and then answer with ass much kindness as you can, wait for the response of the person behind that specific review, most of the times they will change their tone and that will probably lead them to also express what they liked about your work, not only the bad stuff about it.

Express gratitude about their feedback, express how does that make you feel in a kind way, express the importance that your work haves for you, express your intentions to make your work better or how much effort you are putting on creating.

Block the haters

Don't let the haters set the tone of the conversation, don't let them create noise around the positive feedback, just block them without hesitation or guilt.

Negative feedback is always louder

When was the last time that you received an excellent service and you stopped to express how good the service was? Like, when was the last time you order food that was excellent and you decided to express it to the personal? And now think, if instead of that, the food had been awful, what were the chances that you would have express that?

Now copy this quote "Negative feedback is always louder" paste it on Google Docs, Pages or Word, now print it and stick it in front of you and always remember it.

Like, this is probably the most important advice in dealing with bad reviews, they do not express the general feeling about your work. There is no general rule but for every bad review there are plenty of more people that felt good about what you did but didn't take the time to express it, and it is normal we are all like that, we tend to say stuff when we feel cheated or when we feel bad about something but not when we feel good about it.

This is also a reminder to say kind things to the people that produce the work you love, to leave good reviews, to thumb up the video, to subscribe, to like, to say "thank you", "awesome work", "keep doin these" and so on.

Remember, a bad review does not mean your work was bad!.

Don't expect everyone to like your work.

In México we say "No soy monedita de oro" which means, I am not a little coin of gold. The proverb means that no one is a coin of gold that everyone is going to love, and the same applies to your work, it is not a "monedita de oro".

For example, you can learn programming with videos, books, tutorials, live codings, presential classes, online courses, with a mentor, without one, through conferences, etc. There is no universal way to teach programming, and every person is going to like one way more than others, expect to have bad reviews not because your work is bad, but because it is going to work for some people but it won't for others.

Final thoughts

Just to summarize, there will be bad reviews, remember they are louder and nothing is a coin of gold, except well... coins of gold.

Be kind, if you fell like that, don't take it personal and in case someone makes it that way, feel free to block they, leave no space for the haters and the noise they produce.

Learn to accept constructive feedback with humility because remember, these people are also investing the only thing you cannot buy back, time.

And above all, do not stop, produce content for you, your creativity, you will get better at it, you will find your audience and you community, it just takes time.

How to use the methods from other objects in JavaScript

Uriel — Mon, 16 Sep 2019 18:48:29 +0000

I recently ran into this lines of code in JavaScript:

[].slice.apply(arguments)
[].slice.call(document.querySelectorAll('foo'))

And although hard to read, this lines of code are so useful because they allow you to apple array specific methods to collections that not necessarily are arrays, such as NodeLists and the Arguments object.

But what are these lines of code doing and what can they tell us about the flexibility of JavaScript?.

The how

According with the W3Schools, the slice method allows you to select and copy elements from one array into a new array. So the first thing that came to my mind while reading this line of code [].slice.apply(arguments) is, why are we calling slice in an empty array? If the purpose of this method is to select and copy elements from one array, how is it useful if we're calling it with an array that has no elements in it.

The thing is that this poor empty array is only exposing its precious slice method to be taken away. JavaScript allows you to change the context in which a method is called by using the apply and call methods. In other words, you can set the this value in a method' body, through call and apply.

Remember that every JavaScript function is actually an Object, and a clear example of it is that every JavaScript function has a call and an apply method, among another handful of methods that you can call through the function definition.

In practical words, for every JavaScript function, you can call other methods such as apply and call, for example:

function foo(){}
foo.apply();
foo.call();

So what this line of code is doing [].slice.apply(arguments) is that changes the context from the empty array, to the arguments object, to make it seem that the object that called slice was arguments and not the empty array itself.

What makes this work is that the arguments object has some properties that are similar to the ones that arrays have, such as length, and these similarities allows the slice method to work with both arguments and arrays as context.

After the first argument, the apply method allows you to send the arguments that will be passed as the arguments to the function call, in this case when calling the slice method, since in this case we're only passing one argument, the arguments object, the slice method receives no arguments, which according with the documentation means that all the array elements will be copied into the new array, which in resume means that this line of code copies all the elements from the arguments object into a new array.

Now, talking about readability, this methods does exactly the same that the Array.from ES6 method does.

Array.from(arguments) === [].slice.apply(arguments)

The why

This particular line of code [].slice.apply(arguments) allows us to easily convert an object that looks and possible behaves like an array but that is not array, another common example aside from the arguments object is the NodeList objects such as the ones returned from the querySelectorAll function.

This is super useful because it allows us to play with the collection as an array, we can then plug the result into a loop, using it in combination with other array methods such as concat, includes, etc.

Conclusion

What this line of code let me thinking about after reading it, was in how JavaScript allows us to call methods from objects that do not posses these methods in its prototype, which I believe fits into the duck typing philosophy that languages such as Ruby have made so popular.

So, as long as an object can provide the properties and methods for a method to work, you can set this object as the context of the method to effectively call a method from an object that does not have that object.

So, what do you think of the way JavaScript works in these scenarios? Let me know in the comments.

I'd also appreciate if you can report grammar errors or typos to me since english ain't my native language. Thanks in advance!

Caching AJAX requests with SessionStorage

Uriel — Wed, 26 Jun 2019 04:04:18 +0000

There are some scenarios when caching the response from an AJAX request will work better than having to make the same request everytime the user refreshes the page.

Such scenarios are easy to identify when you're working with:

Data that does not update very often.
APIs with a request limit, such as the GitHub Public API
Lazy loading elements that do not change very often

For some cases, it would be neccessary to create a complex system to save the response of the request in the AJAX, update it, expire it, keep it up to date, etc. But, for most cases, just a simple way to save it for a period of time is all you need, enter SessionStorage.

SessionStorage is the non so popular brother of LocalStorage, the most common storage brother in the JavaScript Web APIs family. What makes SessionStorage different from LocalStorage? Well, it turns out that whatever you save into SessionStorage expires after the user closes the browser, like every other session.

Given the nature of SessionStorage, a persistent storage that expires just after the user closes the browser, it's the perfect API to save something for a short period of time, whithout having to worry about expiring the data, just save it there and await for it to expire.

Using SessionStorage

SessionStorage has the same API than LocalStorage, the only difference between the tow of them is how they expire the data, while the browser will only delete the data from LocalStorage in case it requires it, SessionStorage data will be delated when the session finishes.

For those who have never used neither LocalStorage or SessionStorage, there's two common operations that you do with them, writing and reading:

  //Saves the string Hello world with the key message
  sessionStorage.setItem("message", "Hello world"); 
  // Retrieves the string using the key
  sessionStorage.getItem("message") // Returns "Hello world"

With these two operations we can now cache the response from an AJAX request, suppose we have to retrieve our repos from GitHub:

function getMyRepos(){
  const endpoint = "https://api.github.com/users/urielhdz/repos" //Replace urielhdz with your own username

  /* get_data */
}

Now, we'lll using the native fetch operation to retrieve data from the network in order to cache it later:

function getMyRepos(){
  const endpoint = "https://api.github.com/users/urielhdz/repos" //Replace urielhdz with your own username

  fetch(endpoint).then(r => r.json()); // the json method parses the response into a JSON object
}

To make the code more readable we'll use async functions, but keep in mind that this is not a crucial part of the tutorial, it's only syntactic sugar to make the code more clean:

async function getMyRepos(){
  const endpoint = "https://api.github.com/users/urielhdz/repos" //Replace urielhdz with your own username

  const data = await fetch(endpoint).then(r => r.json()); // the json method parses the response into a JSON object
}

Now the data constant stores the data response from the GitHub API, and here it comes the interesting part, cache that response to avoid unneccesary requests to the same API.

async function getMyRepos(){
  const endpoint = "https://api.github.com/users/urielhdz/repos" //Replace urielhdz with your own username

  const key = "githubRepos"; // Key to identify our data in sessionStorage

  // First check if there's data in SessionStorage
  let data = sessionStorage.getItem(key);

  if(data){
    // If there's somethin in the sessionStorage with our key, return that data:
    return JSON.parse(data);
  }

  //If there's nothing in the storage, make the AJAX request:
  data = await fetch(endpoint).then(r => r.json());

  //Then save it into the storage to avoid more requests later on:
  sessionStorage.setItem(key, JSON.stringify(data));

  return data;  
}

Keep in mind that both LocalStorage and SessionStorage can only save strings, so in order to save a more complex structure, such as a JSON object, we have to convert it into a string, that means that when we retrieve the data, we have to parse the string into the previous JSON object.

And that's it, now we have a method that will request data from GitHub only when neccessary, the data will expire as soon as the user closes the browser and that will allow us to keep the data updated.

Drawbacks

As pointed out by Scott Simontis in the comments, this solution with SessionStorage presents some problems:

SessionStorage is sync, so keep in mind that bot writing and reading data from the storage are operations that will block the main thread of your application.
Data stored in SessionStorage can be manipulated by the end user, so you shouldn't store sensitive or critical data for your application.

Thanks to Scott for pointing out this problems, as I add in the comments, this solution is aimed to simple and basic problems in which other cache solutions will appear too complex.

Stop with those complex examples while teaching programming

Uriel — Wed, 12 Jun 2019 18:57:50 +0000

At CódigoFacilito we've been teaching programming for over 8 years now, with hundreds of thousands of active students.

Let's say you decided to learn something new today, you want to update your knowledge to some new shiny technology, let's say you as a JavaScript beginner decided that you want to learn GraphQL.

So you search for an awesome course, or a tutorial, a post, whatever you prefer and the person behind the tutorial starts with a basic server, a database and you hear something like "Well, now let me add some quick validations" and then he proceeds to write like 15 lines of complex validation codes, because well... best practices.

Best practices vs Learning

To follow up with the previous example, a person, a new student decides that He or She wants to learn GraphQL, only to face himself or herself with the need to learn validations, or anything not related to the main topic (GraphQL in this example), only because the teacher decided that it's imperative to follow best practices, because what good will we do if we teach something without those precious best practices?

This is for me one of the easiest way to scare someone who is trying to learn something new, flow his or her mind with concepts unrelated to the main topic, throw lots of complex code to decorate your example, use complex analogies that only overcomplicate a tutorial just because you want to teach a real world example.

The other side of the story is using examples that are too far away from the real use cases, to teach something in an scenario so controlled that going one step away from this scenario means that the student no longer knows what to do, because he didn't learn the technology properly, or pushing him to do bad code because that's the way he learnt the technology.

This is the eternal battle educators face every time they produce content, is this part of code necessary to understand the main topic? is this example too complex? is it too easy? can he use this to build new and different examples?

So what can we do?

Set yourself in the middle

After teaching dozens of courses in programming topics at CódigoFacilito here are some recommendations I could give you to produce better examples for your programming tutorials:

1.- Prepare your entities

In most programming examples we have to deal with entities, like it's pretty common to use animals as entities while teaching OOP.

I'd recommend to use real world examples, but don't take them too far away, for example, there are very low probabilities to code something using an Animal class and a Dog one that inherits from it, so stay away from those kind of examples.

Some very good example I've seen around are Blogs(Article,User) for MVC, To do lists although very common are a good example, Documents (like with words and titles, and so on), Courses, Videos, Playlists, etc.

Don't use something that is too conceptual, like Animals, use something that can be code and I'd be useful, that does not need more than 3 different entities to work.

2. Don't do it unless is crucial

Let's get back to my validations example in a GraphQL tutorial, although validations are important, they are not a crucial part of teaching GraphQL, in fact, you could be a series of its own about validations, so, I'd not use validations in a GraphQL tutorial 😱.

There are two main reasons to ditch what's not crucial while teaching something.

If you're an expert, you already know how crucial validations are, and probably, you already know how to write validations so it's likely for you to get bored while listening to something that does not belong to the topic you searched for.
If you're a beginner, well, probably you're gonna get lost in this part of the tutorial, and and most importantly, you'd get wondering what does validations have to do with GraphQL? are validations GraphQL? does every GraphQL developer work with validations? how can I separate these concepts?

By throwing advanced knowledge from the sake of best practices you're demanding the user to get bored, or frustrated, you're probable making herself or himself feel dumb, or you're confusing him or her.

Try to keep it simple, and if necessary reference the user to other tutorials that cover the topic in isolation, like:

This is where we'd write validations to avoid receiving wrong data, you can read this other tutorial to learn more about validations in NodeJS, but since this is a GraphQL tutorial we will not cover it here"

3. Don't throw libraries to soon

Unless your tutorial is about a library, don't use it from the beginning. Like I'm starting to learn GraphQL and in my first tutorial they start using Apollo, and GraphiQL.

By using libraries and helpers to soon, you run in the possibility of your students associating both concepts as one, like I can assume from this experience that the way to write a GraphQL server is through Apollo, and every time I'm using GraphQL I have to use Apollo.

I'd recommend to always start teaching something with te minimum necessary to make the technology work, you know, that famous "Hello world" example, without using libraries, complex examples, analogies or anything that you'd not consider part of the technology you're introducing.

4. Organize your content as atoms

This is one of the most important things I've learnt while building CódigoFacilito, separate your knowledge in a way I can search it independently.

This is basically the same advice from point number 2, instead of throwing everything you need to make a real world example, separate everything in independent tutorials or use the content that already exists in the internet.

For example, instead of teaching Express, validations, ES2019 in the same GraphQL tutorial, write one article for each and reference them in the GraphQL tutorial

Here I'm using some ES2019 features, you can learn more about it in this other post"

If you don't know how to write an Express server, I'd recommend you to read this other article first"

This would help your audience read or watch your content independently from their level of expertise. Beginners will be able to read the fundamentals before the tutorial, and Experts will only read what they need instead of receiving an introduction to everything in every post

Conclusion

Teaching is hard, as it's teaching programming. I encourage every single person to teach because as experts can give their expertise, beginners can give their perspective of a technology from someone who is new to it, to someone who is some steps behind.

=====

At CódigoFacilito we teach spanish speaking students how to start with programming, web development, mobile development and other skills they need to succeed, and although we produce lots of free content, we also have a $9USD/month membership (or $90 yearly) for Premium content, if you'd like to sponsor a membership for someone that can't afford it, please let us know at uriel@codigofacilito.com