Santiago-j-s

Santiago-j-s

const DIAS_CRITICIDAD_MEDIA = 20;
const DIAS_CRITICIDAD_ALTA = 10;
const DIAS_VENCIDO = 0;

const isProximoAVencer = (context) =>
  context?.days <= DIAS_CRITICIDAD_ALTA;
const isVencido = (context) => context?.days <= 0;
const isCriticidadMedia = (context) =>
  context?.days <= DIAS_CRITICIDAD_MEDIA;

Santiago-j-s

Caminos de aprendizaje

Cada día en twitter veo algún comentario del estilo "los devs deberían saber X, quienes no saben X no son buenos devs", siendo la segunda parte usualmente tácita.

X cada día es algo diferente:

• Saber CSS en lugar de tailwind
• Conocer JS en lugar de frameworks
• Saber de grafos, algoritmos y estructuras de datos
• Saber de deployment si haces back

Santiago-j-s

<?php
set_time_limit(1000);
$curl = curl_init();

curl_setopt_array($curl, [
    CURLOPT_RETURNTRANSFER => 1,
    CURLOPT_URL => 'https://www.freetogame.com/api/games'
]);

Santiago-j-s

function validTime(time) {
  return time.match(/\d?\d:\d?\d/) !== null;
}

function toMinutes(time) {
  if (!validTime(time)) {
    throw 'time must be of format hh:mm';
  }

  const parts = time.split(":");

Santiago-j-s

• Los procesadores CISC tienen instrucciones complejas
• Estas instrucciones se dividen en una serie de pasos más pequeños
• Estos pasos se ejecutan en serie en diferentes partes del procesador (forman algo similar a una línea de ensamble)
• Ante un branch (un if) no se puede anticipar cual va a ser la siguiente instrucción que hay que meter en el pipeline
• Detener todo el pipeline hasta saber que instrucción va a ejecutarse destruye cualquier mejora en la performance que el pipeline pueda ofrecer
• Intentar predecir que camino va a tomar el branch es una mejor opción
• Al errarle al camino hay que reconstruir pipeline, es mucho más lento

Los procesadores RISC igual tienen pipeline, las instrucciones sin embargo son mucho más simples y el pipeline suele ser muy pequeño.

Santiago-j-s

# https://github.com/hardcoreplayers/dotfiles/blob/master/tmux/.tmux.conf

# battery colors
set -g @batt_color_charge_secondary_tier8 'colour0'
set -g @batt_color_charge_secondary_tier7 'colour0'
set -g @batt_color_charge_secondary_tier6 'colour0'
set -g @batt_color_charge_secondary_tier5 'colour0'
set -g @batt_color_charge_secondary_tier4 'colour15'
set -g @batt_color_charge_secondary_tier3 'colour15'
set -g @batt_color_charge_secondary_tier2 'colour15'

Santiago-j-s

call plug#begin('~/.vim/plugged')

" git
Plug 'tpope/vim-fugitive'
Plug 'mhinz/vim-signify'

" status line
Plug 'itchyny/lightline.vim'

" start screen

Santiago-j-s

# PRODUCTION DOCKERFILE
# ---------------------
# Sourced from: https://github.com/Saluki/nestjs-template/blob/master/Dockerfile
# 
# This Dockerfile allows to build a Docker image of the Express application
# and based on a NodeJS 12 image. The multi-stage mechanism allows to build
# the application in a "builder" stage and then create a lightweight production
# image containing the required dependencies and the JS build files.
# 
# Dockerfile best practices

Santiago-j-s

# coding: utf-8
import requests
import datetime

API_KEY = '' # Get a free API KEY on https://api.nasa.gov/ 
URL = 'https://api.nasa.gov/planetary/apod'
START = datetime.date(2019, 1, 1)
END = datetime.date.today()
IMGS_FOLDER = 'imgs'
ERROR_FILE = 'apod_errors.txt'