teleren/devto huggingface dataset:
100 días de código: 11, Hacker Rank ¿te motiva o te desmotiva?
Tags: spanish, 100daysofcode, webdev, javascript
Published: 2021-11-14 01:26:40

¡Hey hey hey!

Bienvenidos a este nuevo día lleno de esperanzas y alegrías.
Hoy como cada sábado no tuve mucho tiempo realmente para codificar pero con una hora y un poco mas que conseguí logre llegar las dos estrellas en [Hacker Rank](https://www.hackerrank.com/) el cual era uno de mis objetivos semanales.

También avance un poco con la **codificación de mi pagina web**.
Cuando estaba realizándola llego a mi mente el pensamiento de que realmente no necesitaba una pagina tan grande.
No se si esto les pasara a los diseñadores pero a mi me pasa comúnmente que cuando hago un diseño despues de unos días pienso que a lo mejor podría haberlo mejorado.

Cuando estaba haciendo los ejercicios en **Hacker Rank** me di cuenta que al terminar cada uno de ellos te sientes lleno de energía y motivación pero despues de un poco de tiempo esa motivación ganada se esfuma como energía que proviene de una golosina alta en azúcar asi que les recomiendo tener una **meta mas grande** que realmente les haga ilusión ya sea laboral o personal.

Ah y se me olvidaba comentarles que hoy tuve la brillante idea de comenzar un canal de youtube para enseñar todo lo que voy aprendiendo y asi utilizar el método que viene de la frase de [Séneca](https://es.wikipedia.org/wiki/S%C3%A9neca).

Ahora sigamos con la sección regular.

### Ayer:
- Avance hasta la sección `Project recipes` del capitulo **HTML foundations** de la guia [The odin Project](https://www.theodinproject.com/) con lo cual ya realice mi objetivo de spring semanal.
- Cree unos cuantos repositorios para los proyectos que voy realizando en la guia.
- Comencé a codificar los estilos principales de mi pagina web.
- Repase las etiquetas de html. (se los recomiendo porque yo ya no recordaba algunas)

### Hoy:
- Logre obtener mi segunda estrella en la sección resolución de problemas de Hacker Rank.
- Practique los métodos `splice`, `split`, `parseInt`, `tostring` y `replace` en JavaScript.
- Avance con la codificación de mi pagina web, concretamente agregue varios estilos.

Aunque no fue un día en el que realmente pude dedicarme mucho a la codificación me siento realmente entusiasmado por mis logros esta semana. Sin duda la planeación semanal de Springs funciona de maravilla.

Que tengan mucho éxito y les vaya super bien en sus proyectos.
Adiós mundo!
The one code review method to rule them all
Tags: codereview, pairprogramming, pullrequests
Published: 2021-11-18 10:50:47

---
title: The one code review method to rule them all
published: true
date: 2021-11-14 00:00:00 UTC
tags: codereview,pairprogramming,pullrequests
canonical_url: https://jhall.io/archive/2021/11/14/the-one-code-review-method-to-rule-them-all/
---

One thing most of us can agree on, and for once [the data seems to support us](https://jhall.io/archive/2021/07/29/what-we-think-works-vs.-what-actually-works/), is that [code review is good for us](https://jhall.io/posts/why-code-review/).

What we _can’t_ seem to agree on is _how_ to do code reviews. There seem to be two basic camps these days; those who prefer either:

- Peer Programming
- Pull Requests

So which is the one true way?

There are some pretty strong arguments in favor of peer programming. This is by no means an exhaustive list:

- Real-time knowledge and context sharing
- Excellent mentoring opportunity when you pair a more senior dev with a less senior one
- No lag, waiting for code review in the PR model

Those sounds pretty compelling. So what are the arguments for pull requests? Also not an exhaustive list:

- They don’t require a synchronized schedule
- Avoids the potential problem of the code being reviewed by a peer who is “too close” to see the flaws
- Easily allows for more sets of eyes, when appropriate, which can be beneficial for mentoring

So both methods appear to have some benefits, and some drawbacks. So which method should you use?

The one true code review method is…

… **drum roll, please** …

_the method that optimizes for what your team and situation most needs!_

If fast throughput is the most important thing on your team, and you have enough engineers working concurrently, and you don’t care that your code may suffer by not being reviewed by someone who’s hasn’t been staring at the code for 8 hours, then using peer programming in lieu of pull requests is probably the right choice.

On the other hand, if your team often works asynchronously, or you value extra eyes on some of your code for the sake of either mentoring or code improvement, or you aren’t (yet?) comfortable with pair programming, then maybe pull requests are the best bet.

Of course, you can also do both. I once worked on a team that agreed that every line of code should be reviewed before merge, but that if the code was written during a pair programming session, that counted, and the PR could be merged immediately.

**TL;DR;** Find a method that works for you, and don’t let anyone guilt you into thinking your way is “wrong”, if it works.

* * *
_If you enjoyed this message, [subscribe](https://jhall.io/daily) to <u>The Daily Commit</u> to get future messages to your inbox._
Code Colocation is King
Published: 2021-11-19 19:52:13

---
title: Code Colocation is King
published: true
date: 2021-11-14 00:00:00 UTC
tags: 
canonical_url: https://blog.koenvangilst.nl/code-colocation-is-king/
---

One of the things I struggled with when I started out as a programmer was where to put my code. It was not something I could easily find in tutorials and for a long time I wondered why everyone was so focused on how to get framework X to do Y, when all I wanted to know was where to put the code that does Y.

Turns out that “where to put code” is one of the hardest things in software engineering and there are no silver bullets. That’s part of the reason why there are so few easy tutorials on this subject.

Most of the code structuring patterns out there (the MVC pattern or patterns recommended by libraries) make sense in their own way, but they often fail to tell you what to do in day-to-day cases. For instance, when you have a simple utility function that’s only used in one place, where should you put it? In the global `/utils` folder?

Over the years I’ve learned that the following principle helps to structure code in way that’s easy to understand and maintain: **keep the code that changes together close together**.

This means that if you have a helper function that’s specific for the feature you’re writing in `featureA/Table.tsx` it’s a good idea to keep this function close at hand. So put it either inside the `Table.tsx` file or right next to it if you have several helper functions. This way, when you have to change or understand the functionality of featureA, all the code you need is close at hand.

For this blog post I’ve chosen **Code Colocation is King** as a motto, but the principle is more often called **the principle of promixity** :

> The principle of proximity focuses on how well organised your code is with respect to readability and change. Proximity implies that functions that are changed together are moved closer together. Proximity is both a design principle and a heuristic for refactoring hotspots toward code that’s easier to understand.

— [Software Design X-Rays by Adam Tornhill](https://pragprog.com/titles/atevol/software-design-x-rays/)

So think about the Proximity Principle the next time you’re in doubt:

- whether it makes sense to move a function to the global `helpers` folder
- where the tests of the component you’ve just written should live
- whether component styling should be in a global `/styles` folder, or next to the implementation
- if the code that manages state should be moved to a separate file with all the other state updates

Like I said at the beginning of this post: There are no silver bullets for structuring code. And the proximity principle does not always tell you exactly where to put code. But when you’re in doubt it tells you to keep code close to where it’s relevant, until you’ve found a good reason not to do so anymore.
more news on WordPress 5.9: new Block theme-features and many enhancements
Published: 2021-11-13 23:55:45


Exploring WordPress 5.9: Block theme flows, Styling, Patterns Explorer, & more
https://www.youtube.com/watch?v=r59aR1tmY6k


-Block-Themes
-new Standard Block-Theme (default)
-Styles-Interface
-Navigation Block
-Pattern-improvements
-UI/UX - improvements
-Performance-enhancements

one week ago, the core leadership announced that all the proposed features and updates for WordPress 5.9 will be moving forward. Users can expect UI improvements, block themes, the new default Twenty-Twenty Two block theme, and more.



Let’s get to all of this week’s WordPress news…

The new version of Wordpress - v. 5.9: It will turn the evolution of themes upside down and many people will like it.

see more links and infos: 

Wplift.com: https://wplift.com/wordpress-5-9-proposed-scope-moving-forward
wptavern.com: https://wptavern.com 

Block Pattern Modal Explorer Coming to WordPress 5.9: https://wptavern.com/block-pattern-modal-explorer-coming-to-wordpress-5-9
Twenty Twenty-Two: https://make.wordpress.org/core/2021/10/06/introducing-twenty-twenty-two/
Github: https://github.com/wordpress/twentytwentytwo
Wordpress-news: https://wordpress.org/news/

wordpress.org/gutenberg: https://wordpress.org/gutenberg/
gutenberg-blocks: https://gogutenberg.com/
noch mehr Dinge:  https://gogutenberg.com/blocks/image/
gutenberghub.com: https://gutenberghub.com/

Block-Reference: https://blocks.wp-a2z.org/block/
Sonjas list of Gutenberg Features: https://www.webtimiser.de/top-10-gutenberg-features/
overview Gutenberg-blocks: https://blog.novatrend.ch/2020/01/06/immer-mehr-gutenberg-bloecke/
Gutenberg-Fibel: https://gutenberg-fibel.de
Gutenberg 11.9 Focuses on Navigation Menus and Block Theming: https://wptavern.com/gutenberg-11-9-focuses-on-navigation-menus-and-block-theming

Infos Theme twenty-tweny-two: https://make.wordpress.org/core/files/2021/10/TwentyTwentyTwo-Styles-highres.mp4
3 Reasons why I hate the "learn to code quickly" narrative
Tags: beginners, webdev, programming
Published: 2021-11-13 23:13:42

When I first started learning how to code, all I kept hearing was "Learn to code in 3 months and get a job".

My initial reaction was confusion.

"Isn't programming hard? How can I learn this in 3 months?"
"Who is going to hire me after only three months?"

For the record, I don't hate anyone who did land a job really soon after starting to learn how to code. 

But I think the narrative sends a dangerous message to those looking to enter into the industry.

Here are the 3 Reasons why I hate the "learn to code quickly" narrative.

## 1. It encourages people to rush through the learning process

For most people, learning how to code is a process and it takes a while to get comfortable with. Very few people can go from 0 to job ready in 3 months.

For those with STEM backgrounds, or previous coding experience, the process will probably go faster then those who are complete beginners. 

In a couple of months of coding, you probably have a basic understanding and can build basic apps. But you need more time to absorb the material and build more complex projects.

To become a good programmer, it takes years of study and practice. 

I have seen a lot of people rush through online courses and try to apply for jobs in a short period of time. But rushing through the learning process will just create serious holes in your foundation.

I see no benefit to learning how to code quickly. 

My advice to beginners is to take your time and learn it well. 

## 2. Organizations use this narrative to prey on people
There are a lot of courses that will guarantee you a job in 3 or 6 months for a fee. But unfortunately, a lot of those courses cannot produce the results.

I have seen so many people on forums and discords talking about the struggle to get a job after only a few months of study. But unfortunately, their quality of work is still on the basic side. 

My advice for beginners is to be leary of courses that can guarantee you a job in a short period of time. 

## 3.  People put all of their focus on getting a job quickly and it doesn't work out

I have seen a few people quit their jobs and spend all day learning how to code in hopes of getting a job in a few months.

If they are able to get a job, then that's great. But if they are not able to land a job, then things get really scary financially.

My advice to beginners is to explore all of your financial options and don't just quit your job in hopes of landing a programming job in a few months.

Try to build in a financial safety net so if the process takes longer, you don't end up in financial trouble. 

Plus, plenty of people have worked while learning how to code.

## Conclusion
Are there individuals that land programming jobs within a few months after learning? Yes.

Is it the norm? No.

The junior developer market is very competitive. When you are learning and looking for a job, you have to take into effect that it might take longer than you expect.

I hope you enjoyed my post and let me know your thoughts in the comments below. :smile:
Automatically upgrade your package on winget with GitHub Actions
Tags: actionshackathon21, github, winget, showdev
Published: 2021-11-13 23:13:09

### My Workflow

If you are an open source maintainer that wants to distribute your  project on Windows, you will probably want to publish it on the Windows Package Manager aka winget. That can be done by creating a package manifest and submitting it to the Windows Package Manager Community Repository (more details in the [documentation](https://docs.microsoft.com/en-us/windows/package-manager/package/)).

Because you have to do that for each version of your application/package it can quickly become tedious. Fortunately there is a tool called Windows Package Manager Manifest Creator aka Winget Create that can help you with that. That is why I decided to create a workflow that would automate the upgrade of an application manifest each time a new version of the application is released.

### Submission Category: 

DIY Deployments

### Yaml File or Link to Code

{% github https://github.com/TechWatching/winget-package-submission %}

```yml
name: Submit Nushell package to Windows Package Manager Community Repository 

on:
  release:
    types: [published]

env:
  packageFileName: windows.msi
  packageId: MyPackageIdInWinget
  
jobs:
  
  winget:
    name: Publish winget package
    runs-on: windows-latest
    steps:
      - name: Submit package to Windows Package Manager Community Repository
        run: |
          iwr https://aka.ms/wingetcreate/latest -OutFile wingetcreate.exe
          $github = Get-Content '${{ github.event_path }}' | ConvertFrom-Json
          $installerUrl = $github.release.assets | Where-Object -Property name -match ${env:packageFileName} | Select -ExpandProperty browser_download_url -First 1
          .\wingetcreate.exe update ${env:packageId} -s -v $github.release.tag_name -u $installerUrl -t ${{ secrets.Project_PAT }}
```

### Additional Resources / Info

More information about this workflow can be found in the README of the project.

This workflow I built is currently used on the open source project  [Nushell](https://github.com/nushell/nushell) (16,4k stars on GitHub). You can check the latest workflow executions [here](https://github.com/nushell/nushell/actions/workflows/winget-submission.yml) Each time a new version of Nushell is released, the new package manifest is submitted to the Windows Package Manager Community Repository.

If you want to have more details about how this workflow works, how it is used in Nushell or about the tool Winget Create this workflow uses, you can read the article I wrote about that [here](https://www.techwatching.dev/posts/wingetcreate).

Any other project that wants to distribute its package through winget (and wants to automate it) is more than welcome to use this workflow. Feel free to modify it to meet your project needs.
Project alert!
Tags: python, programming, opensource, github
Published: 2021-11-13 22:25:08

New project made by Jothin-kumar! Link: https://github.com/Jothin-kumar/virtual-operating-system

Fork it on github (don't forget to like).

Let's see what you are going to do with it.

Can you make something amazing?

You better start!
https://github.com/Jothin-kumar/virtual-operating-system
OpenGPG Proof
Tags: openpgp, gpg, gnupg, keyoxide
Published: 2021-11-13 22:22:19

This is an OpenPGP proof that connects [my OpenPGP key](https://keyoxide.org/bd4523e03e3d58e2ad6862b861132685b748e045) to [this dev.to account](https://dev.to/minecodes). For details check out https://keyoxide.org/guides/openpgp-proofs

[Verifying my OpenPGP key: openpgp4fpr:bd4523e03e3d58e2ad6862b861132685b748e045]
Image lazy load Just with HTML
Tags: html, javascript, css, webdev
Published: 2021-11-13 21:15:25

##What's new ? 

New attribute added to `img` tag that allow lazy loading when its needed.
Just do the following:
`<img src="image.png" loading="lazy" />`
That it ! 💁 Now let the browser do the work for you 👍.

####Note: safari not included 

I hope that was useful for all of you 💪
API1:2019 - Broken Object Level Authorization
Tags: cybersecurity, api, owasp, hacking
Published: 2021-11-13 20:52:51

This post is the start of a series about the 2019 version of OWASP API Security Top 10. My goal here is to learn more as I try to put the content I read into different words, and in this first post, we're gonna be talking about Broken Object Level Authorization.

## :national_park: Just Some Background

Very commonly, APIs use object identifiers (IDs) as a reference to which object will be the target for the action of a specific endpoint. Take this HTTP request below as an example:

> GET /v2/users/1337 HTTP/2
> Host: api.example.com

Apparently, it picks up the value `1337` as the user identifier, and returns the following content:

> HTTP/2 200 OK
> Content-Type: application/json
>
> {
> &nbsp;&nbsp;&nbsp;&nbsp;"user_id": 1337,
> &nbsp;&nbsp;&nbsp;&nbsp;"username": "leet",
> &nbsp;&nbsp;&nbsp;&nbsp;"super_secret_data": "R3D4CT3D"
> }

Notice that this response includes a field called `super_secret_data`. Judging by its name, we can assume that it contains data which should not be publicly visible. Let's also assume, for the sake of didactics, that only the user `leet` itself should be capable of get data from this endpoint while referencing to the user_id `1337`.

## :gear: Making It Secure

So...given this endpoint, how do we grant that only `leet` will be able to get data from `/v2/users/1337`, and other users not?

Well, some may think that:
> We just need to verify, before any operation, if the user who's asking for an action is really supposed to be doing it.

And also, sometimes:
> We could, whenever it's possible, avoid the use of object identifiers on requests, so we rely less on user input.

Both thoughts are simple, and both really help. But if it's so easy to avoid and fix, why does it get the TOP 1? Why is Broken Object Level Authorization the most common flaw we can find on APIs?

## :flushed: The Actual Problem

At the present moment, if we consider the most common tools that are used to construct APIs, there is no effective way to automatically handle access control limiting. It's something that has to be done by the developers, endpoint by endpoint, and human beings are terrible when it comes to repetitive tasks, so they will for sure forget to add this extra verification eventually.

It gets worse when we're talking about an API with countless endpoints, or an API that has to be maintained in different versions. Let's get back to our example request:

> GET /v2/users/1337 HTTP/2
> Host: api.example.com

In this new scenario, we did secure this endpoint by verifying if the session really belongs to the user with ID `1337`. Now, our application is 100% secure, right? :muscle:

Not necessarily, because maybe if an user change part of the path from `v2` to `v1`, our Broken Object Level Authorization will still be there. Also, if users change the HTTP method from `GET` to `PUT`, maybe they'll be able to update `leet`'s data as they want.

That's why it takes so much effort to prevent API1:2019, and that's the reason why it's so common. Hope this post was somehow useful :hugs:
Add Auto-logout To A React App
Tags: react, javascript
Published: 2021-11-13 20:40:55

---
title: Add Auto-logout To A React App
published: true
description: Learn how to correctly implement auto-logout logic in React
tags: react, javascript
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0czcaevccofsmyyn9oud.jpeg
---

## TL;DR
```jsx
const logoutTimerIdRef = useRef(null);

useEffect(() => {
  const autoLogout = () => {
    if (document.visibilityState === 'hidden') {
      const timeOutId = window.setTimeout(logoutUser, 5 * 60 * 1000);
      logoutTimerIdRef.current = timeOutId;
    } else {
      window.clearTimeout(logoutTimerIdRef.current);
    }
  };

  document.addEventListener('visibilitychange', autoLogout);

  return () => {
    document.removeEventListener('visibilitychange', autoLogout);
  };
}, []);
```

Let's take a look at what is going on in this code
1. When the component that contains this code mounts, we set an event listener to watch for when the page visibility changes, i.e. when the user leaves or comes back to the tab, and calls `autoLogout`
2. The `autoLogout` function checks whether the page is hidden or visible
3. If the page is hidden, we set a timer to log the user out after 5 minutes
4. If the page is visible, we clear the timer that was previously set
5. We return a cleanup function to remove the event listener before the component is unmounted

For brevity, I omitted the `logoutUser` function definition, which is out of the scope of this post

## Why `useRef` And Not `useState`
You can achieve the same thing with `useState`, and the only reason I'm not doing that is because setting a state value causes a re-render. While this is not an issue most of the time, it can be a problem when you have some other logic that runs on every update, a la `componentDidUpdate`

I've put up 2 Codesandbox playgrounds to demonstrate this. The first one uses `useState` and the second uses `useRef`. I've set both to auto logout after 10 seconds. If you leave this page and come back, you will notice that the render count in the first one increases by one each time, but the second one remains at 1

{% codesandbox 2vo84 %}
{% codesandbox zhgpy %}