Cómo suavizar scrolls automáticos solo con CSS y scroll-behavior

07/01/2020
Artículo original

Scroll suave con scroll-behavior y CSS

Los enlaces internos dentro de un mismo documento HTML son una solución muy práctica y habitual, especialmente en páginas de preguntas frecuentes o ecommerce monoproducto.

Son muy cómodos porque te permiten acceder de forma muy rápida y fácil a diferentes secciones cuyo contenido quizá no es suficiente para disponer de su propia página.

Además, en este tipo de estructuras de contenido también es habitual encontrar un botón flotante con la típica flechita para volver hacia arriba, la cual funciona con el mismo sistema: un enlace interno que apunta al id de un elemento de la misma página.

El problema es que el salto por defecto entre diferentes secciones suele ser bastante brusco, lo que puede hacer que la experiencia de usuario se vea afectada, especialmente en páginas grandes con bastante scroll. Es decir, el usuario no sabe muy bien a qué altura de la página está. Y para qué negarlo, esa transición no es ni agradable ni bonita, que todo suma.

Un ejemplo del comportamiento por defecto:

Para solucionarlo, tradicionalmente tirábamos de librerías de JavaScript, ya fuesen específicas o con jQuery, pero hoy en día disponemos de una propiedad específica de CSS: scroll-behavior: smooth; y el navegador se ocupará de todo.

html {
        scroll-behavior: smooth;
       /*Comenta la línea (o dale el valor 'auto' a scroll behavior )
       para probar la diferencia con y sin scroll suavizado*/
    }

Obviamente no tendremos parámetros para personalizar la velocidad de la transición, pero la transición por defecto es suficientemente útil para el 99% de los casos, en mi humilde opinión. Se vería algo así.

La propiedad scroll-behavior: soporte, compatibilidad y usos

Hay algunas cosillas que debes tener en cuenta. Por defecto no se hereda y se la tendrás que aplicar al elemento contenedor que tendrá el scroll. En el caso del viewport del navegador, deberás aplicárselo al elemento raíz, ya sea a través del elemento html o del pseudo-elemento :root.

El soporte en navegadores es bastante bueno y se puede usar en la mayoría de los más populares, exceptuando Safari (al menos en el momento de escribir este artículo).

Ejemplo práctico con scroll-behavior: slider vertical solo con CSS

¿Te acuerdas de este slider que hicimos solo con CSS anteriormente en este blog?

Pues con un par de retoques podemos hacer que la transición sea en vertical. Básicamente, lo que he hecho es que, los elementos <li> que antes los posicionaba de manera absoluta para poder apilarlos y mostrarlos y ocultarlo usando la opacidad, ahora los apilo como elementos de bloque (display:block) para mostrarlos en función del scroll.

Yo lo he hecho con una lista, pero esto se puede hacer con div, span, article, section... Vamos, con lo que semánticamente te venga mejor. Y te puede servir tanto para una presentación insertada dentro de una página como para organizar todo el contenido:

 

Los dos ejemplos de este post te los puedes descargar aquí para probarlos en tu propio equipo.

Y como guinda del pastel, también le podríamos aplicar las propiedades del CSS Scroll Snap module que hace poco nos explicó en este mismo blog José Manuel Alarcón, nuestro profe especialista en Front-End y creador de nuestro curso de HTML5 y CSS3 (y coautor del curso de Maquetación Responsive, entre muchos otros), así podremos mejorar también la experiencia durante el scroll normal del usuario.

Pero esta parte ya te la dejo a ti, que tampoco te lo voy a dar todo hecho, ¿no?. ¯\_(ツ)_/¯ 

Espero que te haya resultado útil, y si te queda alguna duda, tienes los comentarios a tu disposición para plantearla.

Tras 20 años de desarrollo, finaliza el soporte de Python 2

03/01/2020
Artículo original

Tras 20 años de desarrollo, finaliza el soporte de Python 2

El 1 de enero finalizó oficialmente el soporte a la versión 2.7 del lenguaje de programación Python. La Python Software Foundation, liderada por el creador del lenguaje, Guido van Rossum, anunció que en el futuro dejaría de recibir actualizaciones de seguridad y correcciones de errores.

A priori podría no parecer algo demasiado grave, ya que el lanzamiento de su sucesor, Python 3, tuvo lugar hace nada menos que 14 años, en 2006. De hecho, el soporte para Python 2.7 tendría que haber finalizado en 2015. Sin embargo, la enorme popularidad de esta versión (sigue siendo la versión de Python por defecto en muchas distribuciones de Linux, por ejemplo) convenció a la fundación de la necesidad de apoyar ambas ramas de desarrollo, y de posponer la fecha de la 'muerte' Python 2.7.

La Python Software Foundation no quiere mirar atrás

Según el comunicado de la Python Software Foundation, el cambio a la versión 3.0 tuvo lugar porque "nos dimos cuenta de que necesitábamos hacer grandes cambios para mejorar Python. Muchos usuarios no actualizaron y no queríamos lastimarlos. Por lo tanto, durante muchos años, hemos seguido mejorando y publicando Python 2 y Python 3. Pero eso dificulta la tarea de mejorar Python".

Por eso, ahora avisan que, incluso si se detecta un problema de seguridad catastrófico en el software de Python 2, los voluntarios de la fundación no ayudarán a solventarlo, porque estarán centrados en el desarrollo de Python 3. Y recomienda a los rezagados que recurran a las herramientas de portabilidad (como el software 2to3) que la fundación lanzó para facilitar la migración de proyectos de una a otra rama de desarrollo del lenguaje.

Desde la fundación también se ha publicado una completa guía con consejos para portar el código a Python 3. Nick Coghlan, uno de sus directivos, afirmaba que "gracias a los esfuerzos combinados de un gran número de contribuyentes a lo largo del ecosistema Python, Python 3 ya está listo para cualquier tarea que pueda haber sido llevada a cabo previamente con Python 2. Este es un momento histórico para la comunidad Python".

Como último gesto hacia su versión más popular, la fundación ha anunciado que las mejoras que se han ido incorporando durante 2019 a la rama inestable de la 2.7 se lanzarán en abril, incorporadas a la que será su última versión estable. Y tras eso, no mirarán atrás: Python(2) ha muerto, viva Python (3).

Vía | Python.org

Imagen | Pexels

Carga diferida de imágenes en el navegador (lazy loading) de manera nativa

24/12/2019
Artículo original

El tamaño y la cantidad de los recursos asociados a las páginas (imágenes, hojas de estilo, scripts...) influye mucho sobre diversos factores de nuestro sitio web. Desde la velocidad de carga de la página, hasta el ancho de banda consumido. Cuanto más rápido cargue una página mejor, y puede tener un efecto muy importante sobre el factor de conversión de la misma (cada segundo es pera adicional hace que se vaya mucha gente). El ancho de banda puede ser también dinero, tanto para nosotros, puesto que muchos servicios cloud cobran por tráfico transferido aparte de otros indicadores, como para nuestros usuarios/visitantes que pueden estar accediendo a través de un móvil o de una conexión "medida" (y al final de mes, todo lo que no necesiten pero se descargue igual, influye en la factura o le puede acabar con la tarifa plana).

Por eso,  muchos sitios web, especialmente los que hacen uso intensivo de imágenes, implementan técnicas para que sólo se cargue lo estrictamente necesario en cada momento. A estas técnicas se les suele denominar de "lazy loading", es decir, de "carga perezosa" ya que en lugar de, por ejemplo, cargar todas las imágenes sólo se cargan las estrictamente necesarias a medida que se van necesitando. Así, por ejemplo, si estamos en un post en un blog que tiene muchas imágenes, si el usuario no pasa de los primeros párrafos, las imágenes que están mucho más abajo, ocultas, no se cargan mientras no haga scroll y empiecen a ser necesarias. Con esto se ahorra mucho ancho de banda y se gana en velocidad aparente de carga.

Hasta ahora, para conseguir esto era necesario hacer programación. Existen multitud de bibliotecas JavaScript para hacer lazy loading, por ejemplo Lazysizes o muchas otras.

Google implementó en Chrome 76, este verano de 2019, un nuevo atributo para imágenes llamado loading que nos permite controlar el comportamiento de la carga de imágenes (img) y marcos internos (iframe) en las páginas. Este atributo puede tomar tres valores:

  • auto: es el comportamiento por defecto. En realidad no significa que todas las imágenes se carguen inmediatamente en el orden en el que estén en la página, sino que el navegador decide las prioridades para cargarlas en función de dónde estén colocadas en el documento, aunque las carga todas lo antes posible. Poner este valor es como no poner nada ya que, como digo, es el comportamiento por omisión.
  • lazy: ese valor es el que hace que se comporten con "carga perezosa". Es decir, sólo se cargarán si están visibles o si se acercan al área visible. ¿Qué quiere decir esto?. Pues que dependiendo de el tipo de recurso que se vaya a cargar, de la velocidad de la conexión y otros factores, el navegador decide cuándo va a empezar la descarga del recurso para que esté totalmente cargado cuando llegue a la parte visible. A veces puede acertar y otras no (de modo que vemos cómo carga), pero no tenemos control sobre ello. Hay que tenerlo en cuenta, pero siempre es más acertado que lo que haga una determinada biblioteca JavaScript de las que se han usado tradicionalmente.
  • eager: es justo lo contrario a lo anterior: carga "ansiosa". Este valor lo que hace es que la imagen (o iframe) se cargue tan pronto como sea posible, aunque esté en la parte no visible de la página. ¿Pero este no es el comportamiento por defecto? Sí, en el escritorio, pero en Chrome para móviles existe un modo especial llamado "Lite Mode" que antes se llamaba "De ahorro de datos" que entre otras optimizaciones descarga algunas imágenes en diferido, y no de inmediato. Por eso, si recurso es muy importante para nosotros y queremos que esté disponible de inmediato por el motivo que sea, usando este valor lo estamos garantizando.

Por ejemplo, en una página de prueba he metido 50 imágenes aleatorias (de Lorem Picsum) de la manera convencional, sin usar el nuevo atributo. Podemos observar cómo, aunque solo hay 3 visibles, cargan todas, una detrás de otra (los text/html son redirecciones a la imagen real que se carga):

Ahora, a la misma página de prueba (ZIP, 730 bytes) le añado simplemente el atributo loading="lazy" y vemos cómo se comporta:

Observamos que sólo carga unas cuantas imágenes (más de las que están visibles, pero ni de lejos todas ellas), y a medida que empiezo a hacer scroll hacia abajo y se acercan al área visible, se van cargando las demás, que es el comportamiento que queremos.

Es importante que si la carga de las imágenes va a provocar que se haga un repintado de la página y se pueden producir efectos no deseados en el aspecto de la página, que le indiquemos las dimensiones de las imágenes con un estilo. De este modo ocuparán el espacio que les corresponde y al cargar no se modificará el flujo de la página.

Cómo digo, esto no es solo para imágenes y los iframes pueden sacar partido también al atributo. Así, si por ejemplo embebemos el típico vídeo de YouTube o Vimeo que usan un iframe para mostrarse podremos aplicarle el atributo y que sólo se cargue la vista previa de los vídeos cuando vayan a entrar en el área visible.

El soporte de este atributo por parte de los navegadores se reduce ahora mismo a los que usan Chromium como motor de renderizado, es decir, Chrome (tanto en escritorio como en móviles), Opera, Brave... y en breve también.

Microsoft Edge. Firefox, Safari (ni por supuesto Internet Explorer), y otros navegadores móviles de momento no lo soportan. Pero tampoco es un problema grave porque simplemente cargarán las imágenes de la manera convencional. Firefox tiene intención de implementarlo, pero en el momento de escribir esto no lo soporta.

Si necesitamos imperiosamente cargar de manera perezosa las imágenes en estos navegadores podemos usar un polyfill para la misma funcionalidad, o podemos utilizar alguna de las bibliotecas tradicionales (comentadas arriba) comprobando antes el soporte con un código similar a este:

if ('loading' in HTMLImageElement.prototype) {
  // Está soportado
} else {
  // NO está soportado, llamar al polyfill
}

Aunque yo me quedaría con el polyfill por ser transparente.

Se trata de un interesante añadido al arsenal del programador Web Front-End y esperemos que los demás navegadores lo incorporen pronto para que el soporte sea universal.

¡Espero que te resulte útil!

El regreso de la Droidcon Madrid 2019: la franquicia centrada en el desarrollo de Android vuelve a España

23/12/2019
Artículo original

El regreso de la Droidcon Madrid 2019: la franquicia centrada en el desarrollo de Android vuelve a España

Tres años sin un evento como la Droidcon en España ha sido mucho tiempo. A pesar de ello, la comunidad de desarrolladores de Android se ha mantenido bastante activa. Lo ha demostrado en diversos eventos como los DevFest promovidos por los grupos locales de GDGs, MADG, BADG, Codemotion, CommitConf, T3chfest y participando en otros eventos internacionales. Pero aún así, hacía faltaba recuperar la franquicia de la Droidcon. Gracias a Nicolás Patarino y Adrián Santalla que han tomado la riendas del evento creando una organización sin ánimo de lucro para llevarlo a cabo.

En Genbeta hemos tenido la oportunidad de estar presente este fin de semana (20 y 21 de Enero de 2019) de esta tan esperada Droidcon Madrid. El feedback ha sido bastante positivo, tal como nos han contado asistentes, ponentes y patrocinadores. Ya era hora que volviera un evento centrado en la comunidad Android.

Más de 250 asistentes y 34 ponentes de gran nivel ha sido el conjunto que ha formado este evento durante dos días en Madrid. Contado con 2 tracks en inglés totalmente y uno en español. Lo que ha dado la oportunidad a expandir el evento con ponentes y asistentes de fuera de España también. Y aprovechando las fechas, muchos desarrolladores expatriados que aprovechaban la visita navideña.

¿Cuáles han sido las tendencias de desarrollo Android en Droidcon Madrid?

Sin duda, Kotlin está muy presente en la comunidad de desarrollo de Android. Lejos quedan las charlas en las que se veía a Kotlin como una posibilidad futura, ahora mismo ya es una realidad presente. Un amplio número de desarrolladores usan Kotlin en producción y pocas empresas se niegan a usarlo en su stack tecnológico.

Android 10 Years

Esta Droidcon Madrid coincide con los diez años de desarrollo de Android. Uno de los GDE (Google Developer Experts) de Android más conocidos es Jorge Barroso. Abrió el evento con una keynote recordando los viejos componentes de Android, cómo empezamos a programar casi sufriendo una travesía en el desierto: con muy pocos ejemplos de calidad por parte de Google, APIs inestables, con un ausente cuidado por la arquitectura de las apps o, incluso con componentes bastante horribles de UI hasta la llegada de Material Design. Pero, afortunadamente, el presente y futuro de Android es mucho mejor a esos tiempos oscuros.

A nivel de arquitectura de aplicaciones, tenemos que estar muy atentos a Arch Components como una de las bases de las apps actuales. Lejos queda también hablar de patrones o de Clean Architecture, ahora nos desplazamos desde hace unos años con arquitecturas más reactivas como Flux y avanzando hacia MVI.

También estuvieron presentes, las Coroutines de Kotlin y cómo integrarlas en el flujo de Android usando Live Data. Gracias al equipo de Android Developer Relations Engineer con José Alcérreca y Manuel Vivo que contaron como desde Google andan mejorando todo el tema de la documentación y el tooling entorno a Android.

Por supuesto, no faltó Arrow como una de las librerías más activas del ecosistema Kotlin de la mano de 47 Deg explicando cómo aprovechar ArrowFx en el desarrollo Android en un entorno funcional más allá de las coroutines.

Y entre las preocupaciones más recurrentes en un entorno de mobile que avanza tan rápido estuvieron las excelentes charlas de cómo distribuir features de forma dinámicas con ejemplos prácticos con la app de Twitter o cómo escalar Dagger en aplicaciones modulares, con anuncio de librería open source, Scythe, dentro de poco aprovechando todo lo aprendido, tal como mencionó el Android Lead de Twitter, César Puerta.

Temas aún verdes para llevar a producción fueron la multiplataforma, es decir, cómo hacer una app con una base común en Kotlin para iOS y Android al mismo tiempo. O como Jetpack Compose cambiará la forma de construir el UI de las apps.

La evolución de la Droidcon en España hasta su vuelta en la Droidcon Madrid 2019

Que una comunidad de desarrollo, sin ánimo de lucro y sin ninguna empresa con colchón financiero detrás monté un evento de este calibre tiene mucho mérito

En Genbeta y Xataka Android tuvimos la oportunidad de estar presentes en el primer evento, allá por 2012. Siendo testigo de la evolución de la comunidad de desarrolladores de Android en España hasta hoy. Durante estos años hasta el 2016, hemos visto desfilar a grandes desarrolladores que forman parte de la llamada Spanish Mafia que a lo largo del mundo trabajan en distintas startups tecnológicas como Facebook, Twitter, Microsoft, Google, entre otras muchas otras y startups por medio mundo.

Por supuesto, otros meetups han ido llenando ese hueco de forma local, como comentábamos al principio, los DevFest promovidos por la comunidad GDG como gran aliada o el citado MADG y su homólogo en Barcelona Android Developer Group, pero aún así faltaba la referencia de la Droidcon plenamente orientada a la comunidad de desarrollo Android, sobre todo con la posibilidad de traer ponentes

La franquicia de eventos Droidcon nació en 2009 en Berlín de la mano de uno de sus fundadores Boris Jebsen. Actualmente, sigue trabajando años tras años por organizar un evento referente, el pasado evento de Droidcon Berlin cumplió diez años.

A lo largo del mundo existen 26 Droidcons. Entre las más conocidas se encuentra la Droidcon de Londres o la Droidcon de San Francisco y Nueva York. En la web de la propia Droidcon Global dejan claro lo que se necesita para montar un evento así.

A pesar del efecto de atracción que puede representar llevar el nombre de Droidcon un evento este calibre, soy bastante escéptico con este tipo de franquicias si los responsables de la franquicia no dan un empuje claro.

Entrevista a los organizadores de la Droidcon Madrid 2019, gracias a Antonio Leiva.

Montar un evento sostenible monetariamente es muy complicado. Es necesario cuadrar las cuentas entre los ingresos: patrocinios, subvenciones (si los logras), entradas y, por supuesto, los gastos de un buen lugar de conferencias, vuelos y hoteles para ponentes, comidas, material para el evento o los medios para grabar las charlas.

Organizacion

Así que viendo el resultado y los nervios previos cuando estuve hablando semanas previas del evento, sin duda ha sido un evento redondo. Que una comunidad de desarrollo, sin ánimo de lucro y sin ninguna empresa con colchón financiero detrás monté un evento de este calibre tiene mucho mérito. Muchas gracias a la organización de Droidcon Madrid 2019 y todos sus voluntarios. Esperamos un 2020 lleno de éxitos para la Droidcon.

Hasta que se suban los vídeos de las charlas podéis seguir el hashtag de #dcMadrid19 con todos los tweets que del evento y algunas de las presentaciones que compartieron los ponentes.

Java: Los 5 mejores frameworks para desarrollo Web

23/12/2019
Artículo original

Java es sin duda el lenguaje más demandado en el mercado laboral. Sirve para crear todo tipo de aplicaciones: desde el móvil hasta el servidor, pasando por el escritorio o la Web. Y es esto último precisamente lo que nos ocupa hoy: el desarrollo Web.

Aunque Java ofrece de serie todo lo necesario para crear aplicaciones para Internet, no sería muy inteligente ceñirse tan solo a eso, al igual que no lo haríamos así con ninguna otra plataforma. Simplemente sería demasiado complejo. Así que para abstraernos de la necesidad de bajar mucho de nivel, existe una amplia oferta de frameworks Java que nos ayudan con el desarrollo Web, ofreciéndonos ya hechas muchas de las funcionalidades que necesitamos: desde acceso a bases de datos, gestión de sesiones, creación de servicios, servir contenidos estáticos, crear vistas.... y por supuesto reutilizar código, probarlo, etc...

Para orientarte en el camino sobre qué aprender para desarrollar aplicaciones Web con Java hemos creado esta lista con los 5 frameworks más importantes, los cuales son todos gratuitos y Open Source:

1.- Spring MVC

Imagen ornamnetal - Logo de Sping

El conocido framework Spring es seguramente el más popular y utilizado del mundo. Se trata de un framework de desarrollo de aplicaciones ligero para Java EE que en realidad se puede utilizar para todo tipo de aplicaciones, no sólo para la Web, pero que es especialmente útil para éstas. 

Nos ayuda a crear cualquiera de las capas de la aplicación, cosa en la que otros frameworks son más limitados. Dispone de varios sub-frameworks como: Spring Core, que dota de funcionalidad a todo lo demás; SpringMVC, para la parte que UI que se devuelve al navegador; Spring ORM, para el acceso a datos; Spring Security, para autenticación y autorización de las aplicaciones; etc...

Aumenta la productividad, reduce los errores y hace que las aplicaciones sean más fáciles de mantener. Soporta la configuración de su comportamiento a partir de XML o mediante anotaciones en el código. Permite usar JDBC para el acceso a datos si lo preferimos. También facilita el testing del código web. Ofrece una documentación muy buena.

Lo utiliza... prácticamente todo el mundo, pero hay muchas empresas conocidas que desarrollan con Spring: Netflix, Amazon o eBay por poner algunos ejemplos.

2.- Hibernate

Imagen ornamental - Logo de Hibernate

Vale, esto no es específico para desarrollo Web, sino para cualquier desarrollo con Java que utilice acceso a datos. Pero es el framework de datos más utilizado del mundo y en cualquier desarrollo web lo vas a acabar utilizando.

Hibernate es un ORM que nos permite crear la capa de acceso a datos de nuestra aplicación utilizando objetos en lugar de consultas, disminuyendo la fricción entre el mundo de las bases de datos relacionales y la Programación Orientada a Objetos. Vamos, como cualquier ORM. La diferencia con otros es que Hibernate es con diferencia el más utilizado y ello significa que hay mucho más soporte y comunidad que para cualquier otro y te resultará más fácil resolver cualquier problema y obtener nuevas funcionalidades.

Su mayor desventaja es seguramente su tamaño y que puede resultar complejo a veces. Pero es algo que, si programas en Java hay que conocer sí o sí.

Al igual que en el caso de Spring, Hibernate lo usa casi todo el mundo para desarrollar en Java: la propia Oracle, IBM, Accenture...

3.- Struts

Imagen ornamental, logo de Struts

Otro framework de desarrollo para Java lleno de características, mantenido en este caso por la Fundación Apache. Es bastante antiguo pero por el mismo motivo está muy probado y lo utiliza mucha gente, y sacan versiones constantemente. Es comparable en muchos sentidos con Spring, que mencionamos antes. Está basado en el patrón MVC y su enfoque es en crear aplicaciones de nivel empresarial de manera rápida y que sean fáciles de mantener.

Dispone de una arquitectura basada en plugins que permiten extenderlo fácilmente con cualquier funcionalidad que requieras y no tenga de serie. Trae muchos plugins de serie para hacer de todo (procesar JSON, crear servicios REST...) y existen muchos más creados por la comunidad.

Lo puedes combinar con otros frameworks para conseguir funcionalidad que no tenga. Por ejemplo, puedes usar inyección de dependencias a través de Spring, o Hibernate para el acceso a datos.

Su mayor pega quizá sea que es más complejo que otros y que te fuerza a seguir un determinado estilo de programación y ciertas reglas (lo cual, en muchas empresas es una ventaja).

4.- JavaServer Faces (JSF)

JavaServer Faces es en realidad una especificación "estándar" para la creación de interfaces de usuario para aplicaciones Web, aunque se puede usar también para crear aplicaciones nativas. La creó la propia Oracle y su primera versión data del año 2004, así que es algo muy estable y probado también. Al igual que otros, utiliza el patrón MVC, y está basado en componentes. El objetivo es que puedas construir componentes de interfaz de usuario que sean reutilizables, pudiendo gestionar su estado, conectarlos a orígenes de datos y atarlos a eventos para realizar acciones.

Tiene un sistema de plantillas para crear los componentes que se llama Facelets y que utilizan XML en lugar de Java para definirlas, aunque puedes usar otros métodos para lo mismo sin salirte de JSF (usando Java directamente si quieres).

Es bastante complejo y no es el más rápido, pero tiene dos ventajas fundamentales: está incluido con Java EE (y los principales IDEs dan soporte de serie para usarlo) y la documentación es muy buena ya que está creada y mantenida por Oracle.

5.- Grails

Grails es un framework de desarrollo Web que utiliza el lenguaje Groovy para la plataforma Java. Groovy es un lenguaje orientado a objetos que compila a Bytecode y que está enfocado a fondo en la productividad del desarrollador. Por ese motivo, Grails lo que te da es una productividad altísima y te permite estar produciendo código para tu aplicación de manera casi inmediata (en 1 hora puedes tener tu primera aplicación probada y en marcha).

Aunque programas con Groovy y no con Java directamente, la sintaxis es compatible con Java y además funciona de maravilla con otras tecnologías Java como Hibernate o incluso Spring. De hecho está basado en Spring Boot, por lo que incluye características como la inyección de dependencias. Sigue buenas prácticas y principios de desarrollo modernos como convención sobre configuración.

Escala bien y te servirá tanto para proyectos pequeños como muy grandes. El soporte de los diferentes IDEs es muy bueno. Tiene centenares de plugins para hacer casi cualquier cosa que se te ocurra.

La documentación de Grails es muy buena, y tiene también unas guías paso a paso de Grails muy buenas.

 

line-height sin unidades en CSS: ¿para qué se utiliza?

17/12/2019
Artículo original

La propiedad CSS llamada line-height, como su propio nombre indica, define la altura que ocupan los elementos con visualización inline. El nombre viene de la altura que tienen las líneas de texto, que son los elementos inline por antonomasia.

El valor por defecto de esta propiedad es simplemente normal, que quiere decir que el navegador decide un valor "razonable" para la altura que le va a poner a las líneas (a los elementos inline) y que depende del navegador, del tipo de letra, etc... pero que suele andar en torno a 1,12 o 1,13 veces el tamaño del tipo de letra del elemento.

Además le podemos asignar una unidad de longitud CSS, es decir, píxeles, em, rem, porcentajes...

Por ejemplo, si tenemos un párrafo de texto en una página y le establecemos las siguientes propiedades CSS:

.contenido {
    line-height: 1.5em;
}

Veremos que la altura de las líneas cambia de la siguiente manera:

Cambio de altura de línea

siendo las líneas más pegadas, el valor por defecto (1.13 en Chrome, que es la captura) , y las que están más separadas el 1.5em que le acabamos de poner. Al haber indicado em como unidades de longitud lo que estamos diciendo es que la altura de la línea deberá ser un 50% mayor que el tamaño de la letra de dicha línea.

Bien, hasta aquí todo normal. La cuestión es que te vas a encontrar por ahí muchas veces propiedades line-height que no usan unidades, es decir, esto:

.contenido {
    line-height: 1.5;
}

Es decir, ni em, ni px, ni nada. Sólo un número. WTF?

Bien, esto es un valor totalmente válido en el caso de line-height, y quiere decir que se utilice 1,5 veces el tamaño de la letra del elemento, o sea, exactamente lo mismo que en el caso anterior con em. Entonces ¿para qué obviar las unidades? Sería mucho mejor ponerlas y así sabemos seguro qué estamos haciendo, además de que en otras propiedades CSS con unidades de longitud no se pueden obviar las unidades.

La diferencia entre poner las unidades o no poner nada es pequeña pero sutil: si no ponemos la unidades, los elementos hijos del actual acomodarán el tamaño de sus líneas al tamaño de letra que tengan, ya que heredan el valor de esta propiedad, en lugar de usar el mismo valor que el elemento "padre".

Es decir, si ponemos 1.5em y este valor resulta en 24px (el tamaño de letra por defecto suele ser 16px), si tenemos un elemento hijo tendrá también esos 24px como valor de su altura de línea, independientemente del tamaño de la letra que tengan. Pero si no especificamos unidades, entonces no heredan el valor fijo, sino que heredan el multiplicador, y adaptarán su altura de línea al tamaño de letra que tengan, sin usar el del padre.

Para verlo mejor vamos a considerar un ejemplo muy simple, pero ilustrativo. Tenemos un par de elementos de bloque uno dentro de otro, conteniendo texto (el texto es un elemento en línea) y con dos tamaños de letra muy diferentes: el elemento padre con un tamaño grande de 30px y el hijo uno pequeño de 10px. Al padre le aplicamos un line-height: 1.5em. El resultado sería este:

line-height con unidades

Fíjate en cómo el texto del elemento interno hereda el mismo valor exactamente de altura de línea que el elemento superior, por lo que queda una enorme separación entre ellas y se monta en el elemento inferior.

Sin embargo, si cambiamos la altura de la línea y no especificamos unidades, dejando tan solo el multiplicador, de manera automática el navegador entiende que queremos ese multiplicador en función del tamaño de letra de cada elemento en línea, y en este caso al tener el elemento "hijo" un tamaño de letra muy inferior, se adapta de manera correcta y se muestra en un espacio mucho más reducido:

line-height sin unidades

Es una diferencia sutil pero muy importante y que, si no la conoces, hará que tengas que estar metiendo a mano las alturas de línea en todos los elementos que hereden esta propiedad de elementos superiores, y variándola cada vez que toques los tamaños de letra. Sabiendo esto puedes establecer el valor una única vez y todos los elementos se adaptarán adecuadamente.

Es por esto que verás más a menudo la propiedad line-height sin unidades que con ellas, y no debe extrañarte.

¡Espero que te resulte útil!

Ruby 2.7.0-preview3 Publicado

16/12/2019
Artículo original

Nos complace anunciar la publicación de Ruby 2.7.0-preview3.

Es una versión previa que se publica para obtener retroalimentación sobre la versión final planeada para Diciembre.

Esta versión preview3 se publica principalmente para confirmar la compatibilidad de los argumentos que son palabras clave.

También introduce una serie de características nuevas y mejoras de desempeño, las más notorias son:

  • Compactar en el Recolector de Basura (GC)
  • Reconocimiento de patrones
  • Mejoras en REPL
  • Separación de argumentos posicionales y con palabra clave

Compactar en el recolector de basura (GC)

Esta versión introduce compactar en el recolector de basura, que defragmenta un espacio de memoria fragmentado.

Algunos programas Ruby de múltiples hilos pueden causar fragmentación en la memoria, que conlleva a un alto uso de la memoria y a que se degrade la velocidad.

El método GC.compact se introduce para compactar el montón (heap). Esta función compacta los objetos vivos en el montón de forma que usen menos páginas y que el montón sea más amigable con la técnica de administración de recursos compartidos “Copiar ante Escritura” (Copy on Write o CoW). [Característica #15626]

Reconocimiento de patrones [Experimental]

El reconocimiento de patrones, es una característica ampliamente usada en lenguajes de programación funcional, se introduce como característica experimental. [Característica #14912]

Puede recorrer un objeto dado y asignar su valor si concuerda con un patrón.

json ='{
	"nombre": "Alice",
	"edad": 30,
	"hijos": [
		{
			"nombre": "Bob",
			"edad": 2
		}
	]
}'
case JSON.parse(json, symbolize_names: true)
in {nombre: "Alice", hijos: [{nombre: "Bob", edad: edad}]}
  p edad
  ...
end

Puede ver más detalles en Pattern matching - New feature in Ruby 2.7.

Mejoras a REPL

irb, el ambiente interactivo incluido con Ruby (REPL; Read-Eval-Print-Loop; Bucle-Leer-Evaluar-Presentar), ahora soporta edición de múltiples líneas. Es potenciado por reline, la implementación en puro Ruby de readline. También provee integración con rdoc. En irb puede presentar el manual de referencia para una clase dada, para un modulo o para un método. [Característica #14683], [Característica #14787], [Característica #14918]

Además, ahora se presentan con colores tanto el código fuente de su programa al iniciar una sesión IRB con binding.irb como los resultados de inspeccionar los objetos de las clases del núcleo de ruby.

Separación de argumentos posicionales y con palabra clave

Se desecha la conversión automática de argumentos con palabra clave a argumentos posicionales, y tal conversión se eliminará en Ruby 3. [Característica #14183]

  • Si la llamada a un método pasa un diccionario (Hash) cómo último argumento y si no pasa palabras clave, y si el método llamado acepta palabras clave, se emitirá una advertencia. Para seguir tratando el diccionario como palabras clave, agregue un operador doble splat al llamar para evitar la advertencia y asegurar el comportamiento correcto en Ruby 3.
  def foo(key: 42); end; foo({key: 42})   # advertencia
  def foo(**kw);    end; foo({key: 42})   # advertencia
  def foo(key: 42); end; foo(**{key: 42}) # OK
  def foo(**kw);    end; foo(**{key: 42}) # OK
  
  • Si la llamada a un método pasa palabras clave a un método que acepta palabras clave, pero no pasa suficientes argumentos posicionales requeridos, las palabras clave se tratarán como los argumentos posicionales finales que requiera el método pero se emitirá una advertencia. Pase el argumento como un diccionario en lugar de palabras clave para evitar la advertencia y asegurar el comportamiento correcto en Ruby 3.
  def foo(h, **kw); end; foo(key: 42)      # warned
  def foo(h, key: 42); end; foo(key: 42)   # warned
  def foo(h, **kw); end; foo({key: 42})    # OK
  def foo(h, key: 42); end; foo({key: 42}) # OK
  
  • Si un método acepta palabras clave especificas, pero no una palabra clave splat, y si en la llamada al método se pasa un diccionario o palabra clave con unas llaves que sean símbolos y otras que no sean símbolos, el diccionario será dividido y se emitirá una advertencia. Tendrá que actualizar el código que hace la llamada para pasar diccionarios separados y asegurar el comportamiento correcto en Ruby 3.
  def foo(h={}, key: 42); end; foo("key" => 43, key: 42)   # warned
  def foo(h={}, key: 42); end; foo({"key" => 43, key: 42}) # warned
  def foo(h={}, key: 42); end; foo({"key" => 43}, key: 42) # OK
  
  • Si un método no acepta palabras clave, y se llama con palabras clave, las palabras clave se tratarán como un diccionario posicional, sin advetencias. Este comportamiento seguirá operando en Ruby 3.
  def foo(opt={});  end; foo( key: 42 )   # OK
  
  • Las cadenas que no sean símbolos se aceptarán como llaves en argumentos con palabras clave si el método acepta palabras clave arbitrarias. [Característica #14183]
  def foo(**kw); p kw; end; foo("str" => 1) #=> {"str"=>1}
  
  • **nil se permite en la definición de métodos para marcar explicitamente que el método no acepta palabras clave. Llamar a un método así con palabras clave resultará en un ArgumentError. [Característica #14183]
  def foo(h, **nil); end; foo(key: 1)       # ArgumentError
  def foo(h, **nil); end; foo(**{key: 1})   # ArgumentError
  def foo(h, **nil); end; foo("str" => 1)   # ArgumentError
  def foo(h, **nil); end; foo({key: 1})     # OK
  def foo(h, **nil); end; foo({"str" => 1}) # OK
  
  • Si se pasa una palabra clave splat vacía a un método que no acepta palabras clave, ya no pasará un diccionario vacío, a menos que el diccionario vacío sea necesario para una parámetro requerido, en cuyo caso se emite una advertencia. Elimine el doble splat para continuar pasando un diccionario posicional. [Característica #14183]
  h = {}; def foo(*a) a end; foo(**h) # []
  h = {}; def foo(a) a end; foo(**h)  # {} and warning
  h = {}; def foo(*a) a end; foo(h)   # [{}]
  h = {}; def foo(a) a end; foo(h)    # {}
  

NOTA: Muchos mensajes de obsolecencia por incompatibilidad de argumentos de palabra clave han sido señalados de ser muy extensos. En el momento, se discuten dos soluciones posibles; deshabilitar los mensajes de obsolecencia por omisión (#16345) o suprimir las advertencias duplicadas (#16289). La decisión final no se ha tomado, pero se adoptará una con la versión oficial.

Otras caracerísticas nuevas y notables

  • Un operador para referenciar un método, .:, se introdujo como característica experimental en versiones preview anteriores, pero se ha revertido. [Característica #12125], [Característica #13581] [Característica #16275]

  • Como característica experimental se introducen paramétros numerados como parámetros por omisión en bloques. [Característica #4475]

  • Un rango sin inicio se introduce de forma experimental. Podría no ser tan útil como un rango sin terminación, pero es bueno para lenguajes específicos para un domino (DSL). [Característica #14799]

    ary[..3]  # identico a ary[0..3]
    rel.where(ventas: ..100)
    
  • Se añade Enumerable#tally. Que cuenta las ocurrencias de cada elemento.

    ["a", "b", "c", "b"].tally
    #=> {"a"=>1, "b"=>2, "c"=>1}
    
  • Ahora se permite llamar un método privado conself. [Característica #11297], [Característica #16123]

  def foo
  end
  private :foo
  self.foo
  
  • Se añade Enumerator::Lazy#eager. Que genera un enumerador no-perezoso a partir de un enumerador perezoso. [Característica #15901]
  a = %w(foo bar baz)
  e = a.lazy.map {|x| x.upcase }.map {|x| x + "!" }.eager
  p e.class               #=> Enumerator
  p e.map {|x| x + "?" }  #=> ["FOO!?", "BAR!?", "BAZ!?"]
  

Mejoras en desempeño

  • JIT [Experimental]

    • El código compilado con JIT es recompilado a uno menos optimizado cuando los supuestos de la optimización dejan de ser válidos.

    • Un método se puede ejecutar en línea (method inlining o inserción en lugar de llamado) cuando un método se considera puro. Esta optimización aún es experimental y muchos métodos aún NO se consideran puros.

    • El valor por omisión de --jit-min-calls cambió de 5 a 10,000

    • El valor por omisión de --jit-max-cache cambió de 1,000 a 100

  • Symbol#to_s, Module#name, true.to_s, false.to_s y nil.to_s ahora siempre retornan una cadena congelada. La cadena retornada es siempre la misma para un objeto dado. [Experimental] [Característica#16150] revertido

  • Se mejora el desempeño de CGI.escapeHTML. GH-2226

  • Se mejora el desempeño de `Monitor y MonitorMixin [Característica #16255]

Otros cambios notables desde la versión 2.6

  • Se actualizaron algunas librerías estándar
    • Bundler 2.1.0.pre.3 (Historia)
    • RubyGems 3.1.0.pre.3 (Historia)
    • CSV 3.1.2 (NOVEDADES)
    • Racc 1.4.15
    • REXML 3.2.3 (NOVEDADES)
    • RSS 0.2.8 (NOVEDADES)
    • StringScanner 1.0.3
    • Algunas de las otras librerías que no tienen versión original también se actualizaron.
  • Se promovieron de stdlib a gemas por omisión
    • Las siguientes gemas por omisión se publicaron en rubygems.org
      • benchmark
      • cgi
      • delegate
      • getoptlong
      • net-pop
      • net-smtp
      • open3
      • pstore
      • singleton
    • Las siguientes gemas por omisión se promovieron en ruby-core pero aún no se han publicado en rubygems.org
      • monitor
      • observer
      • timeout
      • tracer
      • uri
      • yaml
  • Proc.new y proc sin bloque en un método llamado con un bloque ahora produce una advertencia.

  • lambda sin un bloque en un método llamado con un bloque produce un error.

  • Actualizada la versión de Unicode y de Emoji de 11.0.0 a 12.0.0. [Característica #15321]

  • Actualizada la versión de Unicode a 12.1.0, añadiendo soporte para U+32FF SQUARE ERA NAME REIWA. [Característica #15195]

  • Date.jisx0301, Date#jisx0301, y Date.parse soportan la nueva era japonesa. [Característica#15742]

  • Requiere compiladores que soporten C99 [Misc #15347]
  • ~~ Regexp#match{?} con nil` lanza TypeError con String y Symbol. [Característica #13083]~~ revertido

3895 archivos cambiados, 213426 inserciones(+), 96934 eliminaciones(-)

Vea más detalles en el archivo NEWS o en la bitácora de cambios.

Con estos cambios, stat desde Ruby 2.6.0!

¡Disfrute programando con Ruby 2.7!

Descargas

  • https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.0-preview3.tar.bz2

    SIZE: 14630824
    SHA1: 1fa35d8a26dfc814e92fa259095f4cf70f386f87
    SHA256: df2ddee659873e6fc30a8590ecffa49cf3a4ef81fa922b0d09f821b69ee88bc3
    SHA512: 5d8e99e3fd984c7d05c0bc483e1504e81ccdb920cbb2d78cad3c314e197b30316b692fd0199f836acac41246e3a713cb81dc6dd64c27cba56f807df4c193db1a
    
  • https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.0-preview3.tar.gz

    SIZE: 16723536
    SHA1: 7554926ee29a344da4b53d67fc296d70fdbe60ca
    SHA256: 9baa1f5096ebc2a0923df628d7dc7105da3789c1bf8b873469d9010249736b00
    SHA512: 8fad3e761fd54036fee974a9f33e4db31d9a8a878b1181a08724388f5a1da548ab249136356f675797e9c43b565777bf22e6a419db1364336f134b31f4e75b33
    
  • https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.0-preview3.tar.xz

    SIZE: 11923988
    SHA1: f3c54538915483e5ddc714ac23414e7c47048b12
    SHA256: ad9d61e55ac224e3447a762e001965839846f9658f87a0e792840887cfe61b8c
    SHA512: 2b6844f34d32f1013dc3110043e6ece33a083b20f1343dea9a14311bda0017e8f56fc7d73be1616999b22ce430d7ba59a77bb0892d27c6d1ec243c3860086133
    
  • https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.0-preview3.zip

    SIZE: 20691541
    SHA1: d18b494cda4db751d8b3f5026404e348f3f682e3
    SHA256: 2bc95f67f271b6a41fc3dd40536705b4a7974df8a2fa33ff0758a60822291781
    SHA512: af9f728aebc53693cbd9f78a632c82e851e9f83dfc0c53979fdc37c627b11482c8435ce12dbb1d5a7253e998ea989759be699e6a00aae18384d2d765650cb0d7
    

¿Qué es Ruby?

Ruby fue desarrollado primero por Matz (Yukihiro Matsumoto) en 1993, y ahora es desarrollado como Código Abierto. Corre en múltiples plataformas y se usa en todo el mundo especialmente para desarrollo web.

Publicado por naruse el 2019-11-23
Traducción de vtamara

Superchollos 200$ = 181€ GRATIS por registrarte en COINSBIT

05/12/2019
Artículo original

¡Nuevo chollo cripto! El exchange Coinsbit, de forma similar a como hicieron anteriormente Coinbase u Keybase, está regalando 2000 CNB por registrarte y verificar tu cuenta, que según dicen ellos equivaldrán a $200 a partir de 24 de diciembre.

Pasos a seguir:

1. Registrarse en Coinsbit con este link 

2. Confirmas el email y verificas tu cuenta aquí

Y ya está, a finales de año, coinsbit te regalará 2000 unidades de su nueva moneda, por valor de 200$ los cuales los puedes convertir a bitcoins o pasarlos a euros, como tu quieras.

 

Tu empresa parece una secta

05/12/2019
Artículo original

Tu empresa parece una secta

No nos sorprende que se hable del agotamiento de los empleados como uno de los mayores problemas en la industria tecnológica. Empresas como Credit Karma, Twitch, Nvidia, Expedia, Oath, Oracle, Intuit,Snapchat, Lyft, Cisco o Amazon encabezan la lista de las principales compañías con las tasas más altas de agotamiento de empleados.

Cultura del esfuerzo, jornadas de trabajo interminables, sacrificar el tiempo personal en jornadas 996 y el “Evangelio del Trabajo Duro” son, sin duda, unos de los temas más controvertidos de Silicon Valley. Por no hablar del escándalo que generó la publicación del libro de “Brotopia que nos dejó impactados a muchos de nosotros.

Desde mi punto de vista, muchos de estos comportamientos me han parecido sectarios. Son entornos tan obsesionados por la cultura de empresa que si no piensas, ni sientes, ni te comportas como ellos. No eres de los suyos:

  • Cuando está mal visto (hasta por tus propios compañeros) que cumplas tu horario y no hagas horas extras.
  • Cuando se predica que la empresa es una gran familia.
  • Cuando se fomenta en exceso el compartir aficiones con los demás compañeros.
  • Cuando no haces amistades en el trabajo.
  • Cuando a tus compañeros les molesta que tengas una vida después del trabajo.
  • Cuando se confunde trabajar en equipo con querer pasar más tiempo con tu equipo.
  • Cuando tienes pánico a equivocarte porque se castiga el error.
  • Cuando no quieres ir a desayunar, comer o cenar con tus jefes.
  • Cuando tienes que esforzarte en caer bien a todos para que no te consideren como el antisocial.
  • Cuando te obligan o te “sugieren sin compromiso” que tienes que ir a todos los eventos, conferencias, afterworks, team building, etc de la empresa. Y, por supuesto, con la camiseta como bandera.
  • Cuando tienes que vestir igual que el resto de tus compañeros.
  • Cuando hay un extremo buen rollo que no te permite quejarte de nada ni dar tu opinión.
  • Cuando detrás de ese positivismo y buen rollismo, sabes que como no “caigas en gracia”, serás discriminado o irán a por ti por ser el causante del mal ambiente.

Cuando tu tiempo, tus pensamientos, tus sentimientos, tus comportamientos, tu personalidad, tus aficiones, tus prioridades, tus circunstancias... Dejan de ser tuyas para ser de tus jefes y compañeros.

Respeto a las diferencias individuales y a la diversidad

Las diferencias individuales son el conjunto de características o rasgos que diferencian a una persona de las demás. Cada uno de nosotros es diferente y es lo que nos hace únicos.

Cada profesional, tiene sus prioridades, su personalidad y sus circunstancias. Si un empleado prefiere pasar más tiempo con su familia o dedicar tiempo para él mismo y no a su empresa, no tiene por qué ser un antisocial, raro o mal compañero.

Hay gente que le encanta estar en la oficina e incluso después del trabajo hacen quedadas. Su vida personal es una prolongación de su vida profesional. Eso está bien, si es elegido!. Lo que no se puede es forzar la camaradería y el buen rollismo tanto en el trabajo como fuera de él.

Desde mi punto de vista, una entorno de trabajo que busca controlar y forzar que todos los profesionales encajen hasta tal punto que sacrifiquen su individualidad, ni favorece ni cree en la diversidad ni en las diferencias individuales.

Respeto al tiempo de los demás

No sabemos cómo hemos llegado a normalizar horarios interminables. Hasta el punto de sentirnos culpables por irnos a nuestra casa y dejar ahí a nuestros compañeros

Muchos de nosotros hemos vivido, trabajar más de lo firmado por contrato. Es decir, realizar horas extras (sin cobrar) porque el resto de los compañeros lo hacían. No como algo puntual, sino como algo habitual e incluso normalizado que forma parte de la cultura de empresa.

Si no te quedas trabajando (o simplemente haciendo que trabajas), no solo te miran mal tus jefes, sino también tus compañeros. Y según como intérpretes esta situación, sabrás si estás dentro o fuera del grupo.

No sabemos cómo hemos llegado a normalizar horarios interminables. Hasta el punto de sentirnos culpables por irnos a nuestra casa y dejar ahí a nuestros compañeros. Ese horrible sentimiento de culpa de que estás haciendo algo fatal, sintiéndote mal profesional, mal compañero... Culpable por querer ser dueño de tu vida.

Si eres de los que no te importa (o crees que no te queda otra) hacer horas extras en tu empresa, bien. Pero no obligues a que los demás lo hagan ni mucho menos le hagas sentir culpable por elegir su manera de vivir.

Si después de tantas y tantas horas de trabajo, los compañeros son los que presionan a otro por no seguir trabajando, el mal compañero no es él.

De la misma forma que hay que respetar a quien elige su tiempo para estar con sus compañeros, hay que respetar que otros terminen su jornada y no quieren verles hasta el día siguiente.

Compañerismo y trabajo en equipo

No nos tomemos de manera personal que un compañero no pase tiempo con nosotros, fuera del horario laboral.

Y hablando de ser buenos o malos compañeros, hablamos de trabajo en equipo. No confundamos amistad con compañerismo. No confundamos trabajo en equipo con querer pasar más tiempo con tu equipo. Se puede ser buen compañero y saber trabajar en equipo, pero no “irte de cañas” con ellos. (e incluso no beber alcohol).

  • Se puede ser buen compañero y saber trabajar en equipo, pero no compartir aficiones con ellos.
  • Se puede ser buen compañero y saber trabajar en equipo, cumpliendo tu horario.
  • Se puede ser buen compañero y saber trabajar en equipo, aunque no hagas amigos en el trabajo.

No nos tomemos de manera personal que un compañero no pase tiempo con nosotros, fuera del horario laboral. Tenemos que entender que cada uno tenemos una vida y que es completamente sano y equilibrado elegir con quién pasarla. Lo importante es eso, elegir con quién!. Si no hay elección, ahí tenemos el problema.

Se puede ser buen profesional, tanto queriendo como no queriendo pasar más tiempo en tu entorno laboral.

Claves para una cultura de empresa sana

La cultura de una empresa está formada por comportamientos, procedimientos, normas, hábitos, percepciones, sentimientos, actitudes, formas de relacionarse, etc. Algunos están formalizados en documentos, otros no suelen estar por escrito pero forman la esencia o el ADN de cada compañía.

No es fácil hablar de sentimientos, actitudes, percepciones, valores y personalidad. Todos y cada uno, definen a la empresa y conforman parte de la cultura organizacional. Por tanto, cuando un profesional se incorpora, tiene que adaptarse. Ese proceso de adaptación, puede resultar a un profesional muy sencillo, en cambio a otro un sobresfuerzo inmenso.

Según mi experiencia, unos de los motivos por los que candidatos no avanzan en los procesos de selección es porque no están alineados con la cultura de la empresa. No es nada malo. No todos encajamos en todos los sitios y creo que cada profesional tiene que estar donde menos esfuerzo tenga que hacer por encajar. El problema es fomentar una cultura tendenciosa, es decir: “Como no piensas, ni sientes, ni te comportas como nosotros, no eres de los nuestros. No encajas”.

Desde mi punto de vista, si queremos fomentar una cultura de empresa sana:

  1. La empatía, el respeto y entendimiento hacia los demás son pilares básicos de una cultura saludable. Hay que comprender que cada profesional es diferente y valorar esas diferencias.
  2. La comunicación y la colaboración facilita que los empleados se sientan bienvenidos y respetados.
  3. Los valores deben estar reflejados en los comportamientos de todos los empleados. No hay que forzar sentir esos valores. Si en una empresa el trabajo en equipo constituye uno de los valores más importantes de su cultura organizacional, esto debe comunicarse y demostrarse claramente.
  4. La organización de actividades, más allá del trabajo, favorece la cohesión de los equipos, pero creo que no deberían ser “obligatorios” sino una elección.
  5. Establecer objetivos comunes favorece el trabajo en equipo, no es necesario ir a todos los eventos, conferencias, afterworks, team building, etc de la empresa.

Al fin y al cabo, lo importante es ser colaborativo y buen profesional, y eso es imposible si no dejamos a los demás ser como son y ser dueños de tu vida, su tiempo y sus decisiones.

En nuestro trabajo, tenemos que ser felices, pero nunca más que en nuestra casa.

Foto | Mario Gogh on Unsplash

Bitcoins GRATIS por ver videos

05/12/2019
Artículo original

Hola, hoy hemos conseguido hasta 50 euros en bitcoins por ver 4 videos desde coinbase, para ello, os dejamos las invitaciones para poder ganar bitcoins y otras crypto monedas (convertibles gratis a bitcoin) totalmente gratis.

Para registrarse, ir a siguiente link 

Una vez registrado sigue los siguientes links para ver videos y obtener cryptos gratis:

EXTRA 1: Si quieres ganar 200$ en la nueva moneda Coinsbit, solo teneis que registraros en el siguiente link

EXTRA 2 : Ganar bitcoins gratis con bonos aleatorios casi diarios:

BTC surf https://btcsurf.io/r/48537

 

Página Anterior Página Siguiente