DEV Community: Luke

Share intention on Twitter, Facebook websites & WhatsApp app

Luke — Wed, 27 Jan 2021 13:21:10 +0000

If You want to click on a link and share some custom text, url or hashtags on social networks websites then use the following examples on any href property of <a>

Share intention Twitter

<a href={`https://twitter.com/intent/tweet?text=${encodeURIComponent(TEXT)}&url=${encodeURIComponent(URL)}&hashtags=tag1,tag2}`}>Share on Twitter</a>

Share intention Facebook

<a href={`https://www.facebook.com/sharer.php?u=${encodeURIComponent(URL)}&quote=${encodeURIComponent(TEXT)}`}>Share on Facebook</a>

Share intention WhatsApp (mobile only)

<a href={`https://wa.me/?text=${encodeURIComponent(TEXT)}%20${encodeURIComponent(URL)}`}>Share on WhatsApp</a>

CodeSandbox available 🙂

📚 Read my other articles

English

You need to write CSS like that to improve your code quality

Spanish

Te voy a recomendar una forma práctica de documentar tu proyecto de software

Luke — Sat, 29 Aug 2020 20:45:51 +0000

🧐 Contexto

Hace poco leí la una frase que dice algo así: "Escribe un artículo de lo que te gustaría encontrar cuando buscas acerca de un tema en Google" así que siguiendo esta premisa voy a compartir con ustedes mi siguiente artículo 👀

Donde trabajo actualmente tenemos una sección mensual denominada Math.random() (a mi me gusta decirle Matemática Aleatoria) donde DEVs nos juntamos a compartir un rato nerd, hacer learn injections, exponer algún tema interesante, o comer sanguchitos de miga y charlar.

Recientemente me brindaron la posibilidad de exponer una pequeña charla acerca de documentación de proyectos. El entusiasmo me llevó a escribir este artículo con algunas opiniones, recomendaciones, buenas prácticas y algo más. Ojalá te sirva para tus proyectos!

🤔 El problema

Una de las principales cosas que me llamaron la atención al preparar la presentación, fue intentar definir qué significa documentar, me topé con lo siguiente en Wikipedia: "La documentación es la ciencia que consiste en documentar". Por supuesto esto no otorga mucha evidencia acerca de la definición así que comencé a buscar "¿Cómo documentar un proyecto de software?" en Google.

La cantidad de artículos relacionados es abismal, artículos muy buenos, muy detallados, que abarcan cada una de las etapas de un proyecto, con explicaciones de cómo documentar para metodologías waterfall y agile, diferenciar los tipos de documentación dependiendo si el target es un sector técnico, de marketing, usuario, etc. Momentos en los que se debe documentar y en los que no. En fin, sin duda la cantidad de contenido es increible y muy profesional.

Pero aún teniendo todo este material, seguí sin encontrar lo que estaba buscando, me tomé unos minutos y dije:

FUCK OFF (ノ°▽°)ノ︵┻━┻

😅 Las 4 excusas DEV para no documentar

Lo que buscaba es una forma práctica de recomendar cómo o por qué documentar y motivar al resto del equipo a que también lo haga. Reconociendo el problema intenté basarme en mi experiencia y determinar por qué alguien DEV no documentaría un proyecto de software. Entonces detecté que puede haber 4 excusas potenciales para no hacerlo.

Es aburrido: Documentar literalmente no es divertido
No es prioridad: Siempre va a ser mas importante resolver un bug, trabajar en un nuevo feature, etc
Se desactualiza rápido: Por la naturaleza evolutiva de un proyecto de software, si no se mantiene la documentación, puede quedar obsoleta muy rápido
Nadie lo lee: Muchas veces no todo el mundo está al tanto de lo que está docuemntado.

Pero si estas cuatro son excusas ciertas y totalmente válidas, ¿por qué estoy tratando de convencerte de que es importante documentar?

😱 Riesgos por no documentar

Bueno, resulta que no documentar un proyecto tiene ciertos riesgos que pueden ser problemáticos, molestos y costar tiempo o dinero. Basandome en mi experiencia detecté que podrían existir 3 riesgos principales relacionados con el tiempo y la información.

Riesgo 1: El mayor riesgo de no documentar es tener que hacerlo cuando no tenés tiempo ni recordás nada.
Riesgo 2: Puede perderse información valiosa por olvidarse de algo importante o por simple rotación de DEVs.
Riesgo 3: Perder demasiado tiempo buscando solución a un problema ya conocido.

OK, hasta ahora tenemos un montón de excusas para no documentar y varios riesgos que podrían existir por no hacerlo. ¿Entonces que debería hacer como DEV para evitar estos problemas?

😎 Establecer prioridades prácticas

Entender el problema nos pone en contexto y hace que comencemos a organizar la información en nuestro cerebro de tal forma que eventualmente podamos establecer las prioridades adecuadas para ir proponiendo soluciones viables a los problemas que vimos anteriormente. Lo que me lleva a hacer la siguiente recomendación:

Una mínima documentación es más viable que prometer la mejor documentación que nunca vas a escribir.

Vamos a dividir el proceso y prioridades de documentación en 3 partes para que puedan ser útiles y prácticas.

1. Documentar lo básico (MVP)

Un problema muy común cuando solicitas ayuda, o cuando hacés un onboarding a algún compañero/a de equipo es que esa persona no tenga forma de levantar o hacer correr el proyecto sin tener al menos algún tipo de problema por desconocimiento o falta de información. Por eso es muy impotante y es básico de cualquier proyecto que tenga documentado estas 3 características, no existen excusas para que no lo hagas.

Comandos para levantar o correr el proyecto
Variables de entorno necesarias para establecer una configuración inicial o similar
Preguntas frecuente a problemas comunes.

2. Extender el detalle de la documentación

Ya documentado lo básico, hay que pensar en los términos a mediano y largo plazo (más de 4 meses). Cuando se empieza a trabajar en el proyecto y hay varios equipos involucrados en el desarrollo (ej: un equipo frontend y otro backend) es muy importante que ambos equipos esten sincronizados, que conozcan como se está construyendo el software, entender y estar al tanto de los datos que se transfieren de un equipo al otro, etc. Por eso considero que en este punto es indispensable al menos documentar los siguientes tres puntos:

Arquitectura del proyecto (front, back, infra) indicando quién es el responsable de cada área o proceso. (Recomiendo documentarlo como un diagrama de flujo o similar)
Contratos entre el backend y el frontend.
Decisiones tecnológicas, librerías, frameworks y herramientas utilizadas.

3. Centralizar la información del cliente

El último paso para comenzar a tener una documentación sólida es centralizar la información que se obtiene del cliente en el proyecto. Una Wiki debería usarse como "la fuente de la verdad" un lugar centralizado donde encontrar información útil para cualquier miembro del equipo.

Accesos y credenciales a herramientas, VPN, etc.
Datos de ambientes del cliente (ej: servidores, plataformas, IPs, etc)
Material de seguimiento y seguridad (tracking IDs scripts para Google Analytics, Hotjar, reCAPTCHA, etc)
Documentación visual de componentes (frontend) o tests de integracioens (backend)

😮 ¿De qué me sirve documentar?

Ahora que definimos las 3 prioridades que te pueden ayudar a iterar la documentación a lo largo de la construcción de tu proyecto. Me gustaría explicar por qué es importante documentar, para qué sirve o definir cuál es el propósito.

Documentar ayuda a tus compañeros/as de equipo a tener una visión global del proyecto, reafirmar el conocimiento sobre áreas poco relevantes.
Ayuda a que los equipos esten sincronizados y se evitan dependencias de personalidades del equipo, por ejemplo recurrir a determinadas personas continuamente para obtener información relevante.
Proporciona un ahorro y optimización de tiempo ya que al tratar la documentación como una fuente de la verdad, solo hay que ir a buscar la información allí y utilizarla.

🤩 Tips & Tricks

Me gustaría mencionarte algunos otros consejos que me parecen importantes para que apliques a tu documentación.

Precauciones a tener en cuenta

La documentación es una herramienta viva, no hay que permitir que se desactualice. Dedicarle tiempo al menos 1 vez cada dos semanas o cuando sea necesario.
Documentar lo importante en archivos (ej: README.md, CONTRIBUTION.md) asi pueden migrar junto con el proyecto y no quedan separados en una Wiki o similar.
No asumir por entendido lo que nos parece obvio ya que no tenemos los mismos seniorities ni pertenecemos a las mismas áreas.

Debe entenderse por sobre todo

La documentación debe ser lo mas práctica y directa posible, evita párrafos extensos, aburridos y burocráticos.
Usar emojis ayuda mucho a referenciar visualmente una sección o ítem. Cuando estamos trabajando en varias tareas al mismo tiempo o tenemos la cabeza en otra actividad de mayor importancia, los elementos visuales son de gran ayuda.
Usar índices en la parte superior de la documentación provee una mejor experiencia de uso. Si leer una documentación es costoso y aburrido, al menos intentemos hacer que sea lo más ameno posible.

📌 Conclusiones

Sean prácticos, directos y prolijos
Sean explícitos pero no aburridos ni burocráticos
No dejen la documentación para la última etapa del proyecto.
Traten a la documentación como un "bonsai de software"

Recordá siempre intentar agregar valor a todo lo que hagas como dev en el lugar en donde trabajes.

Muchos éxitos!
Luke✨ Seguime en Twitter

📚 Mis otros artículos

¿Estás OK para tu primer trabajo como dev?

Luke — Wed, 29 Jul 2020 04:09:58 +0000

Cuando tuve mi primer entrevista laboral no sabía nada. Cuando digo nada es literalmente nada, cero. No sabía lo que era un condicional, no sabía lo que era un ciclo, mucho menos lo que significaba programar. Pero en mi tiempo libre, me gustaba mucho cambiarle los colores a los templates de Blogspot (R.I.P.) y aunque no tenía ni idea de lo que estaba haciendo, me tiré de cabeza a la pileta. Con todo este increíble conocimiento y la recomendación de un amigo fui a mi primer entrevista y quedé para el puesto. Fue medio de casualidad pero fue el salto mas "a todo o nada" que hice en mi carrera profesional hasta el momento.

Puede que al momento de leer esto ya hayas pasado por tu primer entrevista o en el mejor de los casos, para el propósito de este artículo, estés terminando un curso, un bootcamp, o cursando en la universidad. Y que de alguna forma se está acercando ese momento desafiante de comenzar a hacer valer lo aprendido en una entrevista laboral.

🧐 Aprende de las entrevistas

Una de las sensaciones más comunes de ir a una entrevista es no saber si realmente estás preparado para contestar todo lo que te puedan preguntar, sobre todo aquellas cosas técnicas. Probablemente con el tiempo esa sensación vaya menguando y con la experiencia adquirida a través de los años y cambios laborales, puedas anticiparte a preguntas claves o capciosas.

Si tu próxima entrevista va a ser una de las primeras prepárate para transpirar. Los nervios, la incertidumbre y la tensión física son síntomas que vas a experimentar a menudo en situaciones así, es simplemente una reacción corporal como consecuencia de la alerta extrema para intentar dar lo mejor que tenés. Para contrarrestar esto tratá de no estar a la defensiva y sentite uno más del lugar de trabajo, aunque todavía no trabajes ahí.

Tu primer trabajo no es ser desarrollador de software sino asistir a entrevistas de desarrollo de software. Esto puede enseñarte mucho. Puede que tengas suerte o que seas bueno y te acepten a la primera, aunque de no ser así, te pido que no te deprimas, suele ser normal. A cuantas más entrevistas asistas más experiencia vas a tener en la próxima y sabrás que mejorar. Tampoco te enamores de la primer oferta laboral que escuches, ya que en el mercado hay mucha demanda. Conocer varias de estas propuestas puede darte perspectiva para hacer una mejor elección, ya sea evaluando el clima laboral, la remuneración, la ubicación, aspectos legales, posibilidad de crecimiento, beneficios extra, tipo de empresa, o aquello que más te convenga.

Las entrevistas suelen ser diversas, me han tocado entrevistas muy técnicas, entrevistas tramposas, entrevistas muy relajadas, entrevistas en dónde quien hacía las preguntas era yo (las más divertidas), incluso entrevistas donde había alguien conocido. Por lo tanto es bastante impredecible intentar adivinar qué es lo que te puede tocar. De acuerdo a quién te está entrevistando, tenés que definir si querés "ser" o "parecer". Uno tiene que "ser" cuando está muy confiado del lugar a donde se está postulando o si tiene algún conocido que lo está entrevistando. "Ser" como uno es, crea fidelización, uno se muestra tal cual es, no necesita generar un nuevo vínculo y por supuesto es lo ideal para mostrar más de tus capacidades. Pero por otro lado a veces hay que "parecer", sobre todo si estás solito entre un puñado de gente que te va a poner a prueba. "Parecer" hará que te muestres en tu mejor forma a personas nuevas y así generar el mejor de los impactos para crear un nuevo vínculo, no es lo ideal, pero es efectivo y abre tu abanico de posibilidades. No me malinterpretes, "parecer" no significa mentir sino realzar, o levemente exagerar, aquellas cualidades que consideres que te pueden servir para la entrevista, siempre habrá momento para "ser" como uno es.

😎 No te subestimes

Puede que la entrevista tenga un buen contenido técnico y es fundamental que vayas preparado, esto significa simplemente refrescar algunos conocimientos pasados o hablar con alguien conocido y enviale el detalle de la propuesta laboral así te da una opinión. Es importante que en la entrevista te desenvuelvas de manera natural, que seas sincero, educado y humilde, que aquellas preguntas técnicas que no puedas responder simplemente contestes que no lo sabés. Te podés llevar la sorpresa en donde el entrevistador te lo termine explicando.

Sin embargo no subestimes tu conocimiento. En el área del desarrollo de software muchas empresas tienen la estrategia de conformar equipos de personas de diferentes perfiles y seniority. Si todavía no asististe a ninguna entrevista, o es una de las primeras, probablemente tu puesto corresponda a un desarrollador trainee o junior (alguien que recién empieza). Es común que en latinoamérica, debido a la gran demanda, las empresas grandes tengan una cuota de contratación para perfiles trainee con el objetivo de capacitarlos internamente. Por supuesto también hay puestos para perfiles junior donde pueden ingresar a un proyecto y estár productivos al instante, acompañados por supuesto de alguien con mayor experiencia.

Esto me hace pensar en las redacciones de ofertas laborales que se ven a menudo en Linkedin o similares. Generalmente las ofertas las escriben consultoras de recruitment o personas en puestos de recursos humanos, aunque no siempre es así. Muchos de estos roles, y sobre todo en empresas grandes, se definen a sí mismos como "headhunters" o algo así como "cazadores de talento". Es normal que estas personas reciban un bono, plus, extra, comisión (o como quieras llamarlo) por cada contratación que hagan en la empresa para la cual trabajan y esto hace que muchas ofertas laborales se redacten de una forma que parezca que requieren personas extraterrestres, solicitando una enorme cantidad de conocimiento que abarcan distintas disciplinas, roles o que incluso apunten a un seniority inadecuado. El motivo de esto es generar una propuesta laboral lo suficientemente amplia para poder "cazar" una mayor cantidad de devs. Por lo tanto, mi recomendación es: si al menos conocés el 50% de lo que ves en la propuesta laboral, lo mejor que podés hacer es sencillamente aplicar al puesto. En el mejor de los casos puede que tu perfil coincida con lo que están buscando y te elijan. En el peor de los casos te llevas una experiencia más de cómo es una entrevista laboral y qué conocimientos tenés que reforzar.

🤗 Aprende del entorno

Para ir terminando, una vez que consigas tu primer trabajo como dev vas a haber dado el primer gran paso. Te sugiero que te nutras de la experiencia de tus compañeros tanto como puedas, sigas alimentando tu curiosidad, continúes aprendiendo, te rodees de gente que te haga sentir motivado y que llegado el momento adecuado vuelvas a repetir todo el proceso pero ahora con una mochila de experiencia en tus hombros que te permita tener más confianza para la próxima. Nunca sientas que traicionas a una empresa por cambiar de trabajo, recordala con los momentos buenos y los malos. Y por sobre todas las cosas siempre intenta agregar valor a todo lo que hagas allí dentro.

Muchos éxitos!
Luke✨ 🐦 Seguime en twitter

¿Querés escribir mejor CSS? Lee este otro artículo [inglés]

You need to write CSS like that to improve your code quality 🧐

Luke — Wed, 20 Nov 2019 00:03:14 +0000

Hi everyone. This is my first post in DEV 🥳
I'm from Argentina and i'm currently working at Aerolab.co ❤️ as a UI dev.

This post will be about how to write better CSS (TL;DR)

The problem 🙈

Unorganized properties in a CSS selector
Sometimes, every developer write code according their own rules and preferences
Hard to maintain
Code smells
Bad code quality

Approach 👀

Organize the CSS properties
Separate CSS properties into categories

/* Concept */
.selector {
  /* layout */
  /* position and dimensions */
  /* margin and padding */
  /* box enhancements */
  /* font enhancements */
  /* others */
}

Advantages 🙌

Better readability across devs and teams
Avoid possible redundant code
Easy refactoring
Easy to find some property
Easy to explain
Better code quality

Examples

The wrong way 🤢

The following is a really bad example, it works of course, but you need to avoid this type of code because it is hard to read and maintain. When you write code like this you are dropping the quality of your code and you are spreading bad practices to your teammates.

/* Avoid coding like this*/

.myBadClass {
  font-family: sans-serif;
  font-size: 22px;
  background-color: silver;
  border: 1px solid gray;
  box-shadow: 0 0 3px 20px black;
  display: flex;
  margin-right: auto;
  margin-left: auto;
  padding: 20px;
  margin-bottom: 30px;
  overflow: hidden;
  width: 100%;
  height: 50px;
  top: 0;
  border-radius: 7px;
  flex-direction: column;
  justify-content: center;
  cursor: crosshair;
  align-items: center;
  color: black;
  line-height: 1.5;
  position: relative;
}

The best way 😎

The following is a better way to write CSS, because it is better structured and easy to read. Just start proposing good practices so that your teammates also acquire them.

/* Do this way */

.myGoodClass {
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;

  position: relative;
  top: 0;
  width: 100%;
  height: 50px;

  margin-left: auto;
  margin-right: auto;
  margin-bottom: 30px;
  padding: 20px;

  background-color: silver;
  border: 1px solid gray;
  border-radius: 7px;
  box-shadow: 0 0 3px 20px black;

  font-family: sans-serif;
  font-size: 22px;
  color: black;
  line-height: 1.5;

  overflow: hidden;
  cursor: crosshair;
}

If you have a small set of properties you can following the same pattern. Follow the example below.

.myOtherGoodClass {
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;

  color: black;

  overflow: hidden;
}

Feedback 👂

What do you think about this practice?
How do you write better CSS?
Are you considering apply this on future projects?
If not agree whit this pattern. Why?
Any other way to keep writing better CSS?

Have a good week! and Thanks for reading 🙂