Ruby 2.5.1 Publicado

20/11/2018
Artículo original

Ruby 2.5.1 ha se liberado.

Esta entrega contiene algunas correciónes de errores y seguridad.

Hay algunas correciones de errors también. Puedes ver commit logs para más detalles.

Descargas

  • https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.1.tar.gz

    SIZE:   15923244 bytes
    SHA1:   93fafd57a724974b951957c522cdc4478a6bdc2e
    SHA256: dac81822325b79c3ba9532b048c2123357d3310b2b40024202f360251d9829b1
    SHA512: 67badcd96fd3808cafd6bc86c970cd83aee7e5ec682f34e7353663d96211a6af314a4c818e537ec8ca51fbc0737aac4e28e0ebacf1a4d1e13db558b623a0f6b1
    
  • https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.1.zip

    SIZE:   19525307 bytes
    SHA1:   4fe511496f1eea0c3c1ac0c5f75ef11168ad1695
    SHA256: 5d8e490896c8353aa574be56ca9aa52c250390e76e36cd23df450c0434ada4d4
    SHA512: 490a52081e740b37f06215740734e9a6598ee9b492995b3161d720b5b05beadb4570aa526b3df01f686881b1e259aa7d4a59c1f398989dc2d5f8250342d986f7
    
  • https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.1.tar.bz2

    SIZE:   14000644 bytes
    SHA1:   251fdb5ac10783b036fe923aa7986be582062361
    SHA256: 0f5d20f012baca865381a055e73f22db814615fee3c68083182cb78a4b3b30cb
    SHA512: 82e799ecf7257a9f5fe8691c50a478b0f91bd4bdca50341c839634b0da5cd76c5556965cb9437264b66438434c94210c949fe9dab88cbc5b3b7fa34b5382659b
    
  • https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.1.tar.xz

    SIZE:   11348108 bytes
    SHA1:   0fb5da56f9e5fca45e36aa24ba842d935d1691c2
    SHA256: 886ac5eed41e3b5fc699be837b0087a6a5a3d10f464087560d2d21b3e71b754d
    SHA512: 31bacf58469953282cd5d8b51862dcf4b84dedb927c1871bc3fca32fc157fe49187631575a70838705fe246f4555647577a7ecc26894445a7d64de5503dc11b4
    

Comentarios de la entrega

Varios autores, desarrolladores, y usuarios que enviaron reportes de errores ayudaron a hacer esta entrega. Gracias por sus contribuciones.

Publicado por naruse el 2018-03-28
Traducción de zasman

El estado del ecosistema Java en 2018

19/11/2018
Artículo original

Snyk es una conocida empresa que ofrece un servicio de seguridad muy interesante: verifica todas las dependencias de tu proyecto y te dice cuáles pueden estar dándote problemas de seguridad porque tienen alguna vulnerabilidad conocida. Con la cantidad de dependencias que tienen las aplicaciones hoy en día es un servicio muy interesante, que además es gratuito para proyectos Open Source que tengas en Github.

Recientemente han liberado los resultados de una encuesta a gran escala realizada junto a Java Magazine, de Oracle, que entrevistó a más de 10.000 desarrolladores de Java de todo el mundo para ver qué uso están haciendo de la plataforma para preguntarles acerca del lenguaje y el JDK, las herramientas que usan, los procedimientos de trabajo y algunas otras cosas. El perfil de los usuarios es bastante alto puesto que son suscriptores a la revista, miembros activos de grupos de usuarios, etc., por lo que la información es de bastante interés.

Puedes leer el estudio completo aquí, pero vamos a comentar lo que nos ha parecido más interesante.

Uso de la plataforma Java, el JDK y los lenguajes

El 70% de los desarrolladores de Java utilizan el JDK de Oracle, mientras que el 21% utilizan OpenJDK para desarrollar. Estos números van a variar mucho en los próximos meses con toda probabilidad, a tenor las recientes noticias de cambio de licenciamiento del JDK de Oracle.

El resto de opciones como Eclipse OpenJ9/IBM J9 o Azul tienen una cuota muy pequeña de menos del 9% entre todas.

Gráfico de sectores con el reparto de usos de los diferentes JDK

El 79% de los desarrolladores todavía usan Java 8, e incluso un 9% utilizan todavía Java 7. Así que las cosas se mueven despacio. Java 9 y 10 se quedan en el 4% cada uno, y por supuesto el reciente Java 11 ni aparece en la adopción porque es pronto y porque la encuesta se hizo un poco antes de lanzarla. Y es que el mundo Java se mueve despacio y prima la estabilidad frente a las novedades:

Gráfico de barras con las diferentes versiones de Java utilizadas

De hecho, según la encuesta, solo el 8% de los desarrolladores tiene pensado actualizar la versión de Java que están utilizando a una más moderna, especialmente la 11 con el cambio de licencias.

El 40% de los encuestados indicaron que NO usan la versión empresarial de Java, Java EE, y de aquellos que sí lo hacen, casi el 30% están aún en Java EE 7:

Gráfico de barras con el uso de las versiones de Java EE

Una cuestión muy curiosa es ver que, a pesar de existir lenguajes alternativos muy interesantes basados en la plataforma Java, y que además están muy de moda, como por ejemplo Kotlin o Clojure, el 90% utilizan Java "puro", siendo los demás muy residuales: Clojure (3%), Kotlin (2,42%), Groovy (2,36%), Scala (1,83%) y otros (0,6%):

Popularidad de lenguajes de la plataforma Java

El exiguo 3% de Clojure, de todos modos, denota un alto interés por los lenguajes funcionales.

Aparte de los lenguajes puramente de la plataforma Java, es raro que no haya que usar otros lenguajes dentro de los proyectos, sobre todo si son proyectos Web. Así, dentro de los lenguajes más utilizados ajenos al ecosistema Java tenemos: JavaScript (57%), SQL (56%), Node.js (23%) o Python (21%). Dentro de desarrollo web el framework más popular es Spring Boot (40%), seguido muy de cerca por Spring MVC (36%), quedando los clásicos Struts o GWT hundidos en el 9% y el 6% respectivamente.

En cuanto a los ORM para acceso a datos, el más popular como era de esperar sigue siendo Hibernate, con un 54% (nos esperábamos incluso más), y mucha gente usa JDBC puro y duro para su acceso a datos (sencillez al máximo).

Herramientas para Java

En cuanto a las herramientas elegidas para desarrollar un gran porcentaje de los desarrolladores Java encuestados utilizan el entorno integrado de desarrollo IntelliJ IDEA de Jetbrains, alcanzando el 45%. De éstos, resulta curioso observar (por el entorno "alérgico" a pagar en el que nos movemos) que el 32% utiliza la edición de pago de este entorno, y solamente un 11% la edición "Community" gratuita. El siguiente más utilizado es Eclipse seguido ya de lejos del excelente Apache Netbeans:

Cuotas de los entornos de desarrollo más utilizados

En cuanto a las herramientas de build, la más utilizada por abrumadora mayoría es Apache Maven con un 60%, seguida muy de lejos por Gradle y Apache Ant:

Gráfico de barras con las herramientas de build

En lo referente a las herramientas de calidad y análisis estático de código, SonarQube se lleva la palma con el 39% de cuota, seguida por Findbugs (27%), Checkstyle (23%) y PDM (15%). En lo que se refiere a test unitarios, JUnit es utilizado por el 78% consiguiendo una posición casi de monopolio, aunque hay otras herramientas que se usan en paralelo por parte de muchos, como Mockito (48%) para crear mocks o Selenium (29%) para automatización del navegador.

Respecto a la integración continua, el 21% no utiliza ninguna, pero hay una amplia mayoría del 57% que utilizan Jenkins, sin que ninguna de las herramientas alternativas para este proceso consiga más de un exiguo 5% de cuota.

Infraestructura de aplicaciones

El 43% de los desarrolladores Java encuestados NO utilizan la nube para desplegar sus aplicaciones, pero de los que lo hacen, el 63% utilizan Amazon AWS, el 20% Google Cloud y el 18% Azure (tradicionalmente más utilizado por desarrolladores .NET).

De los que usan la nube el 43% ya están utilizando contenedores para hacer sus despliegues, mientras que el 33% utilizan máquinas virtuales. Serverless (9%) y opciones de aplicaciones como servicio (PaaS, 10%) están muy lejos de la sencillez de despliegue de los anteriores.

Dado que Java es un producto de Oracle y muy relacionado siempre con esta plataforma, el 27% de los encuestados utilizan la base de datos Oracle, mientras que el 50% usan otras opciones (MySQL (21%), PostgreSQL (20%) y SQL Server con solo un 9%).

Otro dato curioso que nos ha llamado mucho la atención es que hay un 36% de desarrolladores inconscientes que no usan el mismo servidor de aplicaciones en desarrollo y en producción (y ya se sabe que eso de "Write Once, Run Everywhere" es solo un dogma de fe, pero luego hay grandes diferencias entre unos y otros servidores de aplicaciones). Entre los servidores de aplicaciones, el que reina sigue siendo desde hace años Tomcat (41%) seguido de lejos por JBoss (15%) o Jetty (9%)

Otros datos

Estos son los rangos de edad de los programadores de Java encuestados:

Edades de programadores de Java

La mayoría está entre 30 y 45 años pero los mayores de 50 son un número considerable (25%) y en general hay muchos años de experiencia en la muestra:

Experiencia de la muestra

En resumen: un interesante informe para conocer el pulso de la comunidad Java en todo el mundo que deberías tener cuenta para elegir qué herramientas aprender y utilizar, entre otras cosas.

Unete a la iniciativa initiativeQ el dinero del futuro y gana dinero gratis

17/11/2018
Artículo original

"La Iniciativa Q es un intento de ex empleados de PayPal para crear un nuevo sistema de pago en lugar de las tarjetas de crédito que se diseñaron en la década de 1950. El sistema utiliza su propia moneda, la Q, y para que las personas comiencen a utilizar el sistema una vez que esté listo, se están asignando Q de forma gratuita a las personas que se inscriban ahora (la cantidad disminuye a medida que se incorporan más personas, así que es mejor inscribirse temprano). Inscribirse es gratis y solamente te pedirán tu nombre y una dirección de correo electrónico. No hay nada que perder, pero si este sistema de pago se convierte en un método de pago líder en el mundo, tus Q pueden valer mucho. Este es mi enlace de invitación: https://initiativeq.com/invite/rEDzS5627 Este enlace dejará de funcionar una vez que se me acaben las invitaciones. Avísame después de que te hayas inscrito, porque necesito verificarte de mi parte."

 

Chrome Dev Summit 2018 Día 2: Frameworks, web components y el futuro de la web

14/11/2018
Artículo original

¡Hola desde San Francisco!

Segundo y último día del Chrome Dev Summit 2018. En el artículo de ayer te contaba que la mayoría de las conferencias impartidas intentaban hacer hincapié en lo importante que es cuidar el rendimiento y tiempo de respuesta de tu página web. Para refrescar un poco la memoria se presentaron tres herramientas (web.dev, visbug y squoosh) que te ayudan a analizar, optimizar y corregir los problemas que puedas tener en tu página web de una forma bastante interactiva. Además de varias charlas sobre optimización y buenas prácticas. Se podría decir que el foco de ayer consistía en analizar y mejorar la web actual.

El foco hoy ha sido distinto y parece que se pretendía mostrar cuál va a ser el futuro de la Web en los próximos años. El día comenzaba con una conferencia muy polémica: el uso de los frameworks JavaScript en el desarrollo actual. Polémica, por que siempre existe debate sobre lo idóneo de su uso, pero el equipo de Chrome ha tomado una posición que personalmente me agrada y con la que seguramente estés también muy de acuerdo.

La idea es muy sencilla: es cierto que los frameworks hacen que tu página sea más lenta a priori, pero también te ayudan a hacerla más rápida. Puede parecer contradictorio, pero tiene sentido si lo pensamos. Un framework puede ser pesado per se pero, debido a las buenas prácticas que normalmente te propone/impone, acabas creando aplicaciones de gran calidad.

Pongamos como ejemplo el framework de la casa, Angular y algunas de las novedades orientadas al rendimiento y a las buenas prácticas que trae su reciente versión 7 (mi curso online ya está actualizado a esta versión aparecida el mes pasado):

Gran parte de las optimizaciones que hace Angular por detrás, como los componentes, los paquetes, el chequeo de compatibilidades con versiones de los navegadores y otras características de este tipo, las desarrolla un equipo de profesionales de altísimo nivel dentro de Google. Y como prueba del apoyo a este tipo de frameworks de gran calidad, el equipo de Chrome ha anunciado que en el futuro algunos frameworks se podrán pre-cargar en el propio navegadorEsto significa que el usuario, por ejemplo, ya no tendrá que esperar primero a que se cargue Angular para poder empezar a usar una aplicación web, sino que Angular y otros frameworks ya vendrán “dentro” del navegador. Esta mejora no tiene ninguna fecha estimada pero sin duda es una iniciativa estupenda.

Mejoras en la paginación infinita o scroll virtual

Otra de las conferencias más esperadas era la de Gray Norton sobre la especificación del elemento <virtual-scroller>.

Para darte un poco de contexto sobre este elemento, a grandes rasgos se trata de un scroll con el que puedes controlar exactamente qué renderizas, lo cual puede ofrecer mejoras increíbles en lo que respecta a rendimiento. El caso de uso más claro es el de una lista "infinita" de digamos 5.000 elementos:

  • Sin virtual-scroll: si realizas una modificación dinámica (el ancho de un elemento mediante CSS, por ejemplo) afectarías a 5.000 elementos de tu DOM y seguramente sea lento.
  • Con virtual-scroll: si realizas la misma modificación tan sólo afectará a los elementos que estás renderizando en ese momento, con lo que el cambio es muy fluido.

A día de hoy este elemento sólo se puede conseguir a través de alguna librería externa como son: React Virtualized, Angular Material Virtual Scrolling o vue-virtual-scroller, según el framework que utilices. El uso de estas bibliotecas especializadas no está exento de contras. Por ejemplo, si no añades al DOM todos los elementos no puedes realizar una búsqueda o acabarías teniendo problemas de indexación dependiendo de para lo que uses el <virtual-scroller>. Lo que Gray Norton y su equipo están intentando conseguir es hacer que <virtual-scroller> sea un elemento estándar del navegador para evitar estos problemas, y obtener una especificación. Puedes conocer más sobre el proyecto en su página de GitHub.

Puedes ver la charla completa aquí (en inglés): virtual-scroller, que haya menos DOM.

Polymer, el framework de componentes de Google desaparece para multiplicarse

Otra de las conferencias que más impacto mediático tuvo fue la del equipo de Polymer en la que quizás lo más importante no ocurrió en el escenario sino detrás de éste. En la conferencia se hizo hincapié en las mejoras en las que se está trabajando sobre su nueva librería LitElement, pero a lo largo del Chrome Dev Summit 2018 se han anunciado las siguientes novedades:

Este último punto puede parecer una nimiedad, pero es increíblemente importante ya que ha desaparecido el framework de Polymer y han aparecido los tres nuevos proyectos que he citado anteriormente dejando sólo en mantenimiento ciertas partes de Polymer. ¿Qué significa esto?

Personalmente llevo varios meses siguiendo el trabajo que el equipo de Polymer está poniendo en estas librerías y con este cambio en mi opinión están dando a entender que Polymer desaparecerá como framework. Por lo que si ahora mismo me preguntases si empezaría un proyecto con Polymer la respuesta es rotundamente no. Pero sí puedo empujarte a probar LitElement + lit-html. Llevo trabajando con ellas un tiempo y sin duda son dos proyectos a los que habrá que seguir muy de cerca (aún no están en producción pero son muy estables). Su foco sigue siendo el mismo que el de Polymer: crear web-components universales algo que en mi opinión no está consiguiendo ningún framework actualmente.

Lista de charlas

A lo largo del día de hoy ha habido multitud de anuncios y charlas increíblemente interesantes. ¡Te animo a verlas en el listado a continuación para enterarte de primera mano de todas las novedades que nos esperan como desarrolladores!

Chrome Dev Summit 2018 Día 1: rendimiento web, optimización, velocidad y algunas nuevas herramientas

13/11/2018
Artículo original

¡Hola desde San Francisco!

Para ponerte un poco en contexto, los días 12 y 13 de Noviembre está teniendo lugar la edición edición 2018 del Chrome Dev Summit, un evento de Google enfocado en y para el desarrollo web, presentando novedades que veremos a continuación y también ponentes del nivel de Jason Miller (creador de preact) o Katie Hempenius entre otros.

El foco de este primer día ha sido reivindicar la web bien construida y sus bondades, haciendo mucho hincapié en todo lo que tiene que ver con el rendimiento y la experiencia de usuario.

El evento empezó como no podía ser de otra forma, alabando las bondades del desarrollo web bien hecho, con compañías del nivel de Starbucks, Spotify o Pinterest, mostrando métricas sobre por qué invertir en rendimiento web y en optimización merece la pena.

Números como los de Starbucks Rewards, en donde la inversión en la mejora de rendimiento de su página web hizo que aumentase un 65% su uso. O que la implementación del reproductor de música de Spotify en el navegador móvil incrementase en un 54% las reproducciones en tan sólo un día, son estadísticas que se quedan muy cortas frente a Pinterest: la inversión en la mejora de su web hizo que aumentase su uso en un 600%. Son cifras muy claras de la visibilidad que ofrecen hoy en día las páginas web.

Puedes ver la ponencia completa aquí: Hablemos de negocios: Por qué la Web importa (en inglés). 

Otras ponencias del día fueron (en inglés todas):

Después del inicio del evento sin duda ha quedado clara una cosa, merece la pena invertir en web, pero merece la pena invertir bien. Fíjate que en la mayoría de casos hablamos de mejorar la página web o lo que es lo mismo, mejorar la experiencia de usuario. Y en esta cuestión radica el segundo objetivo del Chrome Dev Summit que no es otro que enseñar técnicas y buenas prácticas a los desarrolladores.

 Hoy también se presentaron varias nuevas herramientas que pretenden ayudar en los procesos de desarrollo:

  • web.dev (beta): haciendo uso de Lighthouse, analiza tu página web y saca métricas de rendimiento analizando posibles errores y ofreciendo soluciones.
  • visbug (alfa): resumiéndolo mucho, se trata de una especie de "dev tools", pero para diseñadores, haciendo especial hincapié en la accesibilidad. Muy interesantes para afinar esa página que se te resiste...
  • squoosh: una aplicación web progresiva que te ayuda a codificar las imágenes usando los mejores códecs (MozJPEG, WebP y OptiPNG) para conseguir la mayor compresión de imágenes sin pérdida de calidad. Funciona sin conexión y es capaz de usar todos esos códecs aunque tu navegador no los soporte gracias al uso de WebAssembly:

¡Seguiremos informando!

Los principales errores en los 100 sitios web más importantes del mundo y cómo evitarlos

08/11/2018
Artículo original

Nota: este artículo es un traducción de Errors on the world’s top 100 websites and how to avoid them de Jennifer Marsh en el blog de Rollbar, traducido con el permiso expreso de esta empresa especializada en herramientas para diagnóstico de errores en programación.

Cuando se piensa en las 100 principales páginas web del mundo, se piensa en dominios de mucho tráfico y en páginas programadas a la perfección. Sin embargo, incluso los sitios web más populares del mundo tienen errores que se esconden entre bastidores y que se pueden ver en las herramientas de desarrollo de tu navegador. Estos pueden afectar directamente a tu experiencia de usuario, crear datos de seguimiento inexactos o fallos de seguridad, e incluso pueden hacer que la empresa propietaria de la web pierda ingresos.

Hemos encontrado que la mayoría de las 100 páginas más visitadas presentaban varios errores que podían ser fácilmente controlados y prevenidos por sus correspondientes equipos de TI. Si se producen errores en estos sitios tan populares, con más razón pueden ocurrir en el sitio web de tu empresa.

A continuación te mostramos los errores más comunes en los principales 100 sitios web del mundo, y te enseñamos cómo evitarlos.

Descripción general de los errores encontrados en los 100 principales sitios de Alexa

Cómo encontramos los errores

Utilizamos la clasificación de Alexa para identificar los 100 mejores sitios web en función del número de visitantes. Visitamos cada uno de estos sitios web utilizando el popular navegador Google Chrome y desactivamos todas las extensiones para obtener la experiencia más nativa posible. A continuación, registramos los errores que se mostraban en la consola de herramientas para desarrolladores.

Puedes ver estos errores tú mismo abriendo la función de herramientas de desarrollo de tu navegador. En Chrome está en el menú Más herramientas -> Herramientas para desarrolladores. Así es como se ve, por ejemplo, en el Huffington Post:

Herramientas para desarrolladores de Chrome mostrando una lista de errores de HuffingtonPost

¡Es un lío leerlo! Lo simplificaremos agrupando los principales tipos de errores en temas comunes. Luego, te explicaremos qué las causa y cómo evitarlas en tu propio sitio.

Fallos en el seguimiento de usuarios y en los anuncios

Con diferencia, el error más común que vimos fueron los fallos en los píxeles de seguimiento (tracking) y fallos de tiempos de espera de los anuncios. Un solo sitio web puede tener docenas de píxeles o anuncios de seguimiento. Un patrón común eran los errores de resolución DNS o errores de redes publicitarias externas. Los sitios que estaban llenos de anuncios no sólo se cargaban lentamente en el navegador, sino que también tenían numerosos problemas de 404 (archivo no encontrado) y de tiempo de espera en segundo plano cuando se conectaban a las URL de las redes publicitarias. A los usuarios probablemente no les importe si el seguimiento o los anuncios están rotos, pero pueden resultar en la pérdida de oportunidades de ingresos para la empresa. Por ejemplo, en Walmart:

Lista de errores de Walmart.com

Numerosos portales cometieron estos errores, pero las peores páginas web fueron las que se mencionan a continuación: Walmart, Buzzfeed, Twitch, HuffingtonPost, BestBuy, NYTimes, WashingtonPost, CNN y eBay.

La mayoría de los sitios tenían al menos un recurso de publicidad fallido. El error común era HTTP 404, que indica que falta un archivo. Esto podría significar que la red publicitaria ya no está disponible o que la ubicación de su píxel incrustado ha cambiado. Cuando el márketing deja de funcionar con una red publicitaria, a menudo no avisan a los desarrolladores, que deben eliminar el píxel del código. Si no lo hacen, el resultado es que el píxel da un 404.

Los píxeles de anuncios normalmente superaban el tiempo de espera. Esta podría ser la causa de que los sitios cargados con múltiples píxeles publicitarios tendiesen a ser más lentos que los sitios sin ellos. Algunos sitios como Buzzfeed y HuffingtonPost parecieron estar cargándose en el navegador durante varios segundos. El contenido de los sitios se cargaba en el interfaz, pero detrás el navegador seguía cargando contenido, en concreto los píxeles incrustados inaccesibles.

El impacto para la empresa es triple. Se ha demostrado que los sitios lentos afectan a la interacción de los usuarios y que éstos podrían salir e ir a otro sitio. El segundo efecto es sobre los ingresos por impresiones de anuncios o clics perdidos, así como por la pérdida de la oportunidad de retener a los usuarios con contenido personalizado y segmentado. Por último, estas páginas pierden la función de rastrear con precisión el contenido que lleva a los usuarios a pasar más tiempo en la página, por lo tanto, la empresa no puede promover o invertir en el mejor contenido.

Advertencias de certificado HTTPS obsoleto

Aunque, que un certificado SSL esté obsoleto no es un error en sí mismo, las advertencias indican que estos sitios utilizan certificados SSL de Symantec en los que Google Chrome ya no confía. Las webs que utilizan recursos multi-sitio en dominios externos con recursos cifrados SSL de Symantec también generarán un error en Chrome, por lo que este problema es bastante grave para los propietarios de página webs y cualquier dominio que utilice recursos externos con el mismo tipo de advertencias, sobre todo si desconocen la iniciativa de Google de dejar de reconocer los certificados HTTPS expedidos por Symantec.

Certificado SSL expirado

La iniciativa surge de una auditoría de Google de 2015 en la que se descubrió que Symantec había emitido certificados de prueba no autorizados con el nombre de su marca registrada, lo que viola los requisitos básicos de las autoridades de certificación.

Desde octubre de 2018, estos sitios generan un error en Chrome ya que el navegador no reconocerá los certificados. Varios de los principales sitios de Alexa están bajo advertencia de caducidad SSL. HuffingtonPost, Amazon, Twitch, PayPal, Target, USPS, CapitalOne, AOL, Salesforce, Etsy, Quora, Intuit y WashingtonPost son sólo algunos de los sitios que utilizan un certificado SSL emitido por Symantec o un enlace a otro dominio que utiliza uno.

Si tu sitio usa un certificado de Symantec y no lo has renovado recientemente, mira a ver si no tienes este problema. De todos modos sería conveniente que revisases con cierta frecuencia los errores relacionados con certificados.

Errores de CORS y Recursos Web

Para acelerar un sitio web, no es raro servir recursos web desde alojamientos en la nube como por ejemplo una CDN. Las fuentes web y los archivos CSS se almacenan normalmente en la nube porque se cargan más rápido que los archivos almacenados localmente en el servidor de dominio. Los navegadores están programados para cargar con cierta cautela los recursos externos para tratar de evitar los ataques de scripting multi-sitio (Cross-Site Scripting o X_-Site_). Si no se realizan comprobaciones entre los sitios, un atacante puede inyectar sigilosamente un archivo CSS o JS, y los usuarios se exponen al robo de cuentas. Aquí tienes un ejemplo de error CORS que encontramos:

Font from origin '[https://ABCDEFG.cloudfront.net](https://abcdefg.cloudfront.net/)' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '[https://sub.domain.com](https://sub.domain.com/)' is therefore not allowed access.

Encontramos que los errores CORS eran comunes en sitios que usan CDNs, como Amazon Cloudfront, sin los permisos de configuración apropiados. Office, Microsoft, Xfinity, CNN, Thesaurus, Target, Dailymail y Forbes son las que presentan más errores de autorización entre todos los principales sitios web. CNN extrae el contenido de todos sus sitios asociados, y no pudo cargar recursos de nueve dominios diferentes.

Para solucionarlo, los desarrolladores del sitio web deben decirle al navegador que extraer recursos y ejecutarlos desde un dominio de confianza externo está permitido dentro de la configuración de CORS. Por ejemplo, si estás usando un servidor web como Apache, necesitas añadir esta cabecera a su archivo .htaccess:

Header add Access-Control-Allow-Origin "tu-dominio.com"

Tipo MIME erróneo

Un tema común entre las grandes páginas web de venta al por menor como Walmart fue el siguiente error:

Refused to execute script from 'https://tpc.googlesyndication.com/safeframe/1-0-23/html/%3Cscript%20type=%22text/javascript%22%20src=%22https://c.betrad.com/durly.js?;ad_w=300;ad_h=250;coid=329;nid=111025;%22%3E%3C/script%3E' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

Walmart no fue la única página con este error. Slickdeals, Blackboard, CBSsports, BankofAmerica, Salesforce, BBC, Netflix y Lifedaily tenían errores MIME en sus sitios web y podían cargar recursos embebidos.

El problema es con el tipo MIME indicado en los recursos externos, cuando se solicitan archivos usando JavaScript. La llamada JavaScript a un recurso externo asigna un tipo de dato incorrecto. Si el navegador piensa que el tipo de dato es un documento de texto, no tiene sentido ejecutarlo como un script. Estos pequeños errores pueden interrumpir la producción del backend, como el marketing, los anuncios y el seguimiento de los clientes. Puedes anular este comportamiento configurando la respuesta HTTP X-Content-Type-Options, aunque esto también puede suponer un problema de seguridad para ejecutar datos arbitrarios, así que ojo. Una mejor opción es establecer la respuesta apropiada de Content-Type para la aplicación/javascript en lugar del texto/html predeterminado, aunque a veces esto no está bajo tu control si es un proveedor externo.

Elementos con ID duplicado en el DOM

La mayoría de los desarrolladores saben que cada elemento DOM en HTML necesita un ID único, pero a veces se le puede colar a la gente de control de calidad y testing, ya que los navegadores permiten que estos elementos se rendericen igualmente. Los problemas no se presentan hasta que JavaScript llama al ID o se produce un evento POST en un formulario que utiliza HTML con IDs (y name) no únicos, como en este formulario de Facebook:

Error de Facebook con IDs de doble elemento

Facebook, NYTimes y WellsFargo cometieron el error de tener elementos HTML con identificaciones no únicas.

Tener dos elementos con el mismo ID afecta a la funcionalidad del sitio. Puede causar errores al utilizar el elemento en JavaScript, o puede causar errores de backend cuando la página de procesamiento recupera los valores de un envío POST del usuario.

Errores misceláneos pero notables

Algunas páginas web contenían pequeños errores generales que seguían siendo notables simplemente por su facilidad de ser corregidos, pero que sólo se producían en uno o dos dominios. Quizás los desarrolladores pasaron por alto el problema, o pensaron que los errores no eran críticos.

NIH.gov tenía un simple error de jQuery que puede ser corregido colocando la librería jQuery JS encima de la llamada de función "ready".

  	Uncaught ReferenceError: $ is not defined

Por cierto, al visitar el sitio ahora no se muestra tal error, por lo que los desarrolladores de NIH lo han encontrado y corregido recientemente.

HuffingtonPost tiene errores al conectarse a un servicio en 127.0.0.0.1 en los puertos no asignados 4387-4389. Por el código subyacente, parece que se están intentando conectar a un servicio localhost pero cerraron los puertos. Los puertos podrían haberse cerrado por razones de seguridad, pero el servidor web no puede cargar el servicio, lo que indica que lo han desactivado, pero se olvidaron de eliminarlo del código. Otra posibilidad es que el sitio esté comprobando si hay robots ejecutándose en su máquina.

Ganadores de la web sin errores en la página de inicio

No todos los portales tienen muchos errores. Es interesante resaltar que los sitios web que se ejecutan sobre bases de código más antiguas, con menos dependencia de JavaScript, son los que más fácil entraron en esta lista. De los 100 sitios web principales de Alexa, los sitios que no informan de errores en Chrome incluyen:

  • Reddit
  • Wikia (aunque no redirecciona a una versión segura del sitio)
  • Wikipedia
  • Discordapp
  • Slack
  • StackOverflow
  • StackExchange
  • Patch

Si buscas un patrón, los sitios web que no usan anuncios en su página de inicio (o cualquiera como Wikipedia) no tienen errores. Stack Overflow y Stack Exchange son sitios comunes para encontrar soluciones a estos errores, por lo que deben ser felicitados por no tener ninguno. Estos sitios también se cargan rápidamente, y funcionan mejor que otras páginas web.

Los peores infractores

Mientras que los mejores del grupo son pocos, encontramos varios malhechores con numerosos errores en su sitio web. Algunos de los peores infractores han sido:

  • HuffingtonPost - 34 errores en la página de inicio
  • Buzzfeed - 13 errores después de comprobar 3 páginas
  • Xfinity - 12 errores en la página de inicio de sesión
  • Twitch - 10 errores en la página de inicio
  • Forbes - 9 errores en la página principal

Controla los errores en tu propio sitio web

Puedes encontrar la mayoría de los tipos de errores usando Chrome o las herramientas de desarrollo de Firefox. Sin embargo, comprobar esto manualmente es un proceso que consume mucho tiempo. Cada vez que hagas alguna modificación, es necesario que compruebes todos los cambios que realices en tu sitio web por si dan algún error y que los pruebes en una variedad de navegadores y dispositivos.

Si tienes una aplicación web importante de la que dependan muchos usuarios, entonces deberías usar una solución de monitorización de errores como Rollbar. Rastrea los errores que encuentran los usuarios reales y puede avisarte cuando surgen o ocurren nuevos errores con frecuencia. En la captura de pantalla siguiente, puedes ver los errores más comunes por el número total de veces que ocurrieron, cuántas IPs únicas se ven afectadas, cuándo ocurrió por última vez, y más cosas.

enter image description here

Rollbar es fácil de integrar con sólo unas pocas líneas de código y funciona con los principales navegadores. Tienen una versión gratuita que permite gestionar 5.000 errores al mes en tu sitio web. Ofrece muchas más funcionalidades para ayudarte a solucionar y arreglar problemas rápidamente, incluyendo la telemetría de lo que condujo al error, el soporte de mapas de origen (sourcemaps) para trazas de pilas, y mucho más. ¡Es importante detectar estos errores antes que tus usuarios!

TRUCO: Cómo resaltar la inicial de un texto con CSS

06/11/2018
Artículo original

Aspecto, muy profesional, de la primera letra utilizando el pseudo-elemento first-letterEn revistas de papel es habitual encontrar las iniciales de los textos resaltadas de algún color y en mayor tamaño, como una indicación visual del lugar por donde se empieza a leer el texto. Si quieres introducir este elemento práctico y decorativo en una web, hay varias formas de conseguirlo. En este artículo estudiaremos cómo funcionan y sus ventajas e inconvenientes.

Método básico

La forma más directa de abordar el problema es separar la primera letra en un elemento span con una clase o identificador y aplicarle el estilo CSS apropiado. Tenemos dos opciones, bien hacer la inicial más grande en la misma posición (conocida como raised cap) o bien que esta ocupe varias líneas y se adentre en el párrafo de texto (denominada drop cap). Para el primer caso basta con aumentar el font-size de la letra en cuestión y ajustar line-height en caso de que fuera necesario. El segundo es más complicado y requiere del uso de float para mezclar la letra con el texto. Supongamos que tengamos el siguiente marcado HTML:

<p><span class="drop-cap">G</span>ranada ama lo diminuto. (...)</p>

Entonces, agrandamos la letra, la convertimos en flotante y realizamos ajustes de margen para que no aparezca demasiado cerca del texto de alrededor:

.drop-cap-span .drop-cap {
  float: left;
  font-size: 5.4em;
  line-height: 1;
  margin-right: .6rem;
}

El resultado de ese código, así como aplicando algo de estilo adicional con un color y otra tipografía, sería el de la siguiente imagen:

Resultado de drop-cap básico con dos tipografías diferentes

Este método tiene ciertos inconvenientes. Por un lado, introduce un elemento de marcado extra (el <span>) que puede que no podamos añadir en determinadas situaciones, por ejemplo, que el texto se cargue de forma dinámica y no se pueda modificar. Además, tiene efectos negativos para la accesibilidad, ya que un lector de textos posiblemente lea la inicial y el resto de la palabra separadas. Por otro lado, utilizar el elemento span nos permite personalizar cada una de las iniciales que construyamos, mediante clases distintas.

El pseudo-elemento ::first-letter

CSS proporciona un selector que crea un pseudo-elemento en la primera letra (y casi cualquier puntuación que la rodee), pudiendo aplicarle estilos sin necesidad de modificar el marcado HTML. En este caso, podemos simplemente tener el siguiente código en la página:

<article class="drop-cap">
<p>El diminutivo no tiene más misión que la de limitar(...)</p>
</article>

Y utilizar estas líneas de CSS para activar la inicial decorativa:

.drop-cap p:first-child::first-letter {
  float: left;
  font-size: 5.5em;
  line-height: 1;
  margin: 0.2rem;
  margin-right: 0.6rem;
  padding: 1rem;
  background: #a070c0;
  box-shadow: 0 0 0 .2rem #a070c0;
  border: .2rem solid black;        
}

Esta vez hemos añadido un fondo para la letra y un borde, de forma que la letra tiene un espacio propio y queda bien separada del texto normal. El resultado sería el que ves en la imagen:

Aspecto, muy profesional, de la primera letra utilizando el pseudo-elemento first-letter

La ventaja de ::first-letter es que se puede aplicar a cualquier texto, estático o dinámico, y que no empeora la accesibilidad del sitio. Por otro lado, si queremos ajustar el posicionamiento de cada inicial respecto al texto es más difícil hacerlo de forma distinta para cada letra, ya que tenemos un único estilo para todas las iniciales. Esto puede ser incómodo en ciertos casos ya que cada navegador ajusta el elemento flotante de forma distinta y algunas letras pueden quedar demasiado o muy poco separadas del texto, así como desplazar más líneas de texto en unos navegadores que en otros.

La propiedad initial-letter

Como hemos visto, las iniciales grandes en la web sufren de un problema de posicionamiento y ajuste a un número determinado de líneas. CSS ha introducido recientemente una nueva propiedad específica para resolverlo, initial-letter. Sin embargo, el soporte de navegadores es muy escaso, únicamente disponible en aquellos que utilicen el motor Webkit (Safari en macOS y Epiphany en Linux) y en ocasiones es necesario el prefijo -webkit. La idea de esta propiedad es que sean los navegadores los encargados de adaptar el tamaño de la letra según el número de líneas que queremos que ocupe. De esta forma siempre se puede ajustar a la línea base o baseline del renglón conveniente.

Los parámetros de la propiedad initial-letter son dos: el número de líneas correspondiente al tamaño que deseamos que tenga la inicial, y el número de líneas que debe "hundirse". Es decir, la inicial puede hundirse tres líneas y sobresalir una si tiene el tamaño de 4 líneas, en cuyo caso la propiedad tendría el valor 4 3. En nuestro caso, para imitar los ejemplos anteriores, haremos que la letra ocupe 4 líneas hacia abajo, lo cual podemos conseguir simplemente con el valor 4:

@supports (initial-letter: 4) or (-webkit-initial-letter: 4) {
  .drop-cap p:first-child::first-letter {
    -webkit-initial-letter: 4;
    initial-letter: 4;
  }
}

Puesto que el soporte de esta propiedad aún no está muy extendido hemos utilizado una query de tipo @supports para que nos permita implementarlo con mejora progresiva: usando la propiedad nueva sólo si está soportada, y en otro caso podríamos usar el método anterior. El resultado debe ser parecido al de la imagen, renderizado en Epiphany (el soporte en Epiphany es aún experimental y podría cambiar ligeramente):

Aspecto de nuestra letra inicial con un navegador que soporta initial-leter

Te dejo el código con los tres ejemplos que hemos estudiado para que puedas experimentar por tu cuenta y comprobar sus similitudes y diferencias.

Fuentes y más información:

De Fabric a Firebase: la migración obligada por Google para integrar toda su plataforma de desarrolladores en 2019

04/11/2018
Artículo original

De Fabric a Firebase: la migración obligada por Google para integrar toda su plataforma de desarrolladores en 2019

Desde la compra de Fabric por Google a principios de 2017 sabiamos lo que iba a pasar. Google había adquirido también hace unos años Firebase y desde entonces lo está convirtiendo en su principal suite de herramientas para desarrolladores. Sobre todo con el foco puesto en las apps y todo lo que rodea: crash reporting, performance, analiticas, push notification y herramientas cloud serverless.

La duplicidad de servicios acabaría en una integración que conlleva el fin de ciertos servicios y migraciones de plataforma. Lo más suave posible, tal como han anunciado. Fabric irá apagándose en favor de Firebase. Pero tranquilos, como ya han anunciado este cambio será poco a poco, cada uno de los servicios de Fabric tendrá acogida en Firebase o serán sustituidos por la combinaciones de algunos de Firebase y Google.

Más de 600.000 desarrolladores integran Fabric en sus desarrollos, empezando por Crashlytics, quizás el servicio más longevo y más conocido, de hecho en su historia ya ha pasado por varias manos. Ahora se enfrenta a un roadmap escalonado para finales de año, el cual implica algunas concesiones con las que tendremos que convivir los desarrolladores durante al menos la mitad de 2019, fecha en la que se despedirá definitivamente a Fabric y todo debería ser utilizado desde Firebase.

El primero en moverse de casa ha sido Crashlytics. El cual tendrá a partir de este mes de noviembre que ser usado desde la consola Firebase, la app de Fabric tanto en Android como iOS desaparece.

Con suerte, no hay que hacer cambios en el SDK de Crashlytics que actualmente usa las apps donde lo tengamos integrado. Siempre que tengas una versión relativamente reciente de él, claro. Tan sólo tienes que confirmar los datos de las aplicación y darle permisos a Firebase para acceder a los datos. Ojo, el historial no va con ellos y algunas funcionalidades como la adopción o el impacto de una reciente release necesitarás integrar el SDK Google Analytics, lo que sustituirá Answers.

Roadmap de Fabric a Firebase

Firebase Crashlytics

Crashlytics ya es el sistema de reporting de crashes principal de Firebase. Después de que Firebase lo sustituyera por el desarrollo que intentaba competir con Crashlytics. Para ello, a través del enlace para combinar las cuentas es posible ver los datos directamente desde la consola de Firebase del mismo modo que se hacia desde Fabric. Aunque con ligeras difeencias hasta que concluyan las migraciones. Entre ellas se encuentra el soporte para filtrar entre las principales versiones de la app distribuidas o hacer A/B testring. De las ventajas de la migración nos podemos quedar con la integración de BigQuery o Cloud Funtions para analizar los crash y realizar acciones.

Answers

Pasará a formar parte de de Google Analytics. Del mismo modo que el crash reporting podemos obtener los eventos en brutos y analizarlos a través de BigQuery, además del acceso en real time de las métricas. Para poder usarlo deberemos integrar el SDK de Google Analytics en el código de nuestra app para que comience a enviar eventos tal como los teniamos configurados en Fabric Answers.

Beta

Parte del uso de muchos de los desarrolladores también era la distribucción de betas a través de Fabric. Un concepto alejado del beta testing que ya aporta, por ejemplo, Google Play Console. Muy útil para trabajar en sesiones de QA o distribuir branches en desarrollos integrandolos en el CI.

Distribuir Apps Firebase Fabric Beta

De momento Firebase ha anunciado que habrá que esperar a usar su nueva app integrada en Firebase para distribuir APK/IPAs. Y aún está lejo tener una app para la distribucción de betas de nuestas aplicaciones. De momento, seguiremos usando Fabric.

Digits

El servicio de autenticación a través de telefono queda integrado a través de Firebase Authentication, tanto la validación de número de telefono y la API de verificación.

Los kits de desarrollo third-party

De momento seguirán funcionando, pero tal como esté disponible el nuevo Crashlytics SDK en Firebase dejaran de estarlo. Salvo algunas que puedan continuar, lo más lógico es que deben integrarse de forma independiente.

Recordemos que Fabric hacia de directorio de servicio y podiamos instanciar tan solo teniendo el SDK instalado y la librería correspondiente el servicios como Appsee, Branch, Mapbox, PubNUb, etc..

Más información | Fabric Migration

CSS: cómo cambiar los estilos de un conjunto de elementos cuando haya más de un número determinado de ellos

02/11/2018
Artículo original

Imagina que en una aplicación web tienes un listado de fichas de producto en el que cada elemento es una pequeña estructura HTML para mostrar toda la info de cada uno de los productos del listado: foto, nombre, descripción, tamaños, colores, precio... Además, ese conjunto de elementos de información se generan desde una aplicación en el lado servidor, en función de alguna búsqueda o filtro de la base de datos, de modo que no puedes saber de antemano desde tu HTML cuántos elementos hay en la lista.

Dependiendo de cuántos haya, quieres cambiar el diseño del listado de resultados. Por ejemplo, si hay muy pocos (3 o menos) quieres que se vean más grandes, con la foto más prominente, más anchos y resaltándolos todo lo que puedas. Sin embargo si hay más de 3 (4 o más) la foto será más pequeña, ocultarás la descripción y en general la ficha de cada producto en el listado será menos llamativa.

Para hacer esto, cabría pensar que necesitarías algún tipo de colaboración por parte del servidor: enviarte el número de elementos en una variable de JavaScript o cambiar la estructura del HTML de cada producto o los estilos antes de enviar la página al navegador. Por supuesto, todo esto y otras cosas se pueden hacer pero ¿no sería mucho más interesante hacerlo sin necesidad de programar, usando tan solo CSS?.

Esto es precisamente lo que vamos a hacer.

Para lograrlo podríamos pensar en utilizar algún tipo de contador CSS o algo similar. Sin embargo podemos conseguirlo de una manera mucho más sencilla sacando partido a un par de pseudo-clases: una muy común y otra menos utilizada.

Primero, vamos a ver el ejemplo que voy a utilizar de muestra. No me voy a complicar la vida maquetando un listado de productos (lo mío no es el diseño, sino la programación), así que simplemente voy a meter una sencilla lista de elementos dentro de una caja, pero todo lo que voy a explicar serviría igual cambiando los selectores por los apropiados para tu diseño. Lo que importa es el concepto.

Así, si tengo este código HTML:

<div id="caja">
<ul id="lista">
<li>Elemento 01</li>
....
<li>Elemento N</li>
</ul>
</div>

y esta simple regla CSS:

#caja {
border: 1px solid black;
width: 500px;
height: 75px;
overflow: hidden;
}

que hace que la caja contenedora tenga un cierto ancho pero sea mucho más baja, con una relación de aspecto grande, lo que veré por pantalla al renderizar la página será esto:

Es decir, a partir de 3 elementos ya no se verá nada porque la caja los tapará. Lo que quiero conseguir en este ejercicio es que, cuando la lista tenga 4 o más elementos (o sea, más de 3) el estilo de éstos cambie y en lugar de mostrarlos con el aspecto por defecto (con la bolita a la izquierda y unos debajo de otros), los muestre unos al lado de los otros (en línea) y con un separador entre ellos. Algo así:

De modo que aprovechen el espacio horizontal y puedan caber todos.

Vale, este es un ejemplo feo, pero sirve para ver la idea y ponerla en práctica sin complicarnos con estructuras de HTML muy complicadas.

Vamos a ver cómo hacerlo...

En primer lugar necesitamos ver cómo podemos determinar que hay más de "x" elementos en la lista. Para ello podemos intentar lo más evidente, que es usar la pseudo-clase :nth-child que sirve para seleccionar los elementos hijo de otro, usando para ello una fórmula. Por ejemplo:

#lista li:nth-child(4) {
color: red;
}

selecciona el cuarto elemento de tipo li que forma parte de la lista #lista, y le pone un color rojo a su texto. Si quisiésemos que seleccionase no solo el cuarto, sino también todos los siguientes, podríamos escribir:

#lista li:nth-child(n+4) {
color: red;
}

en este caso la variable n se sustituye los valores 0, 1, 2... y así sucesivamente y se aplica la fórmula para determinar qué elementos serán seleccionados (la fórmula general es an+b, siendo a y b constantes que nosotros ponemos y n la variable que se sustituye por parte de CSS). De este modo, todos los elementos del cuarto (incluído) en adelante tendrán un aspecto diferente, dejando los tres primeros con el aspecto por defecto:

(he quitado la altura a la caja para que se puedan ver todos y ver que han cambiado)

Esto estaría bien si siempre quisiésemos que los 3 primeros tuvieran un determinado aspecto y los siguientes otro diferente. Pero no es lo que buscamos. Lo que necesitamos es que cambien TODOS el aspecto cuando haya más de un número determinado, no solo los que sobrepasen dicho número.

Para lograrlo vamos a seguir una estrategia parecida pero inversa, que aprovechará un combinador de selectores especial para alcanzar nuestro objetivo.

Existe otra pseudo-clase complementaria de la anterior, :nth-last-child, que se comporta igual pero empieza a contar los elementos desde el final, o sea, al revés. Si ponemos:

#lista li:nth-last-child(n+4) {
color: red;
}

Lo que conseguiremos es seleccionar todos los elementos a partir del tercero desde el final, así:

Es decir, justo lo contrario que lo anterior. No parece que hayamos ganado demasiado... Aguanta un poco conmigo y verás porqué esto, a pesar de parecerse, nos va a ayudar a conseguir lo que buscamos...

Otro de las pseudo-clases que tenemos disponibles en CSS es :first-child que nos permite seleccionar el primer elemento hijo de otro. Así, si por ejemplo escribo:

#lista li:first-child {
color: red;
}

seleccionaré el primer elemento:

Una cosa que no es muy común ver por ahí pero que se puede hacer es combinar dos pseudo-clases para forzar que se cumplan a la vez.

¿Qué ocurre si combinamos las dos pseudo-clases que acabamos de ver?, es decir, esto:

#lista li:first-child:nth-last-child(n+4) {
color: red;
}

pues que vamos a seleccionar el primero de los elementos de lista dentro de la lista #lista que además forme parte de los que están desde el 3º del final hasta el principio. El resultado es exactamente el mismo que el anterior, o sea, esto:

ya que se selecciona el primer elemento, pero la diferencia estriba en que ahora solo se seleccionará el primer elemento si hay al menos 4 (o sea, 3 o más), ya que se deben cumplir las dos condiciones. Si por ejemplo eliminamos de la lista todos los elementos menos los 2 o 3 primeros, el selector no seleccionará al primer elemento, que no se verá rojo (puedes probarlo). ¡Genial!

De todos modos aún no tenemos la solución ya que de momento solo hemos seleccionado el primer elemento, eso sí, cuando se cumpla la condición que queríamos. ¿Cómo hacemos que además se seleccionen todos los elementos en este caso?

Muy sencillo: haciendo uso del combinador general de hermanos, denotado por el símbolo ~ (la virgulilla o tilde). Lo que hace este operador cuando lo metemos en un selector es que selecciona todos los hermanos del elemento actual que estén a continuación en el DOM. Es decir, en el mismo nivel y después del actual.

Dado que con las pseudo-clases anteriores tenemos seleccionado el primer elemento solo cuando haya más de "x" (3 en nuestro ejemplo), basta con añadirle este combinador y elegir todos los elementos posteriores con él, así:

#lista li:first-child:nth-last-child(n+4) ~ li {
color: red;
}

que selecciona todos los elementos de la lista a continuación del primero solo cuando haya 4 o más, o sea, veremos esto:

Con esto CASI tenemos lo que queríamos. En realidad así seleccionamos todos menos el primero de la lista. Para incluirlo, lo único que tenemos que hacer es combinar los dos últimos selectores que hemos visto usando la coma para que actúen los mismos estilos en ambos casos: el que selecciona el primero cuando hay más de "x" y el que selecciona a los restantes, así:

#lista li:first-child:nth-last-child(n+4),
#lista li:first-child:nth-last-child(n+4) ~ li {
color: red;
}

¡Listo! Así tenemos a todos seleccionados.

Si en vez de cambiarle el color a rojo le cambiamos el estilo de visualización para que se muestren en línea (restaura también la altura de la caja), tendríamos esto:

#lista li:first-child:nth-last-child(n+4),
#lista li:first-child:nth-last-child(n+4) ~ li {
display: inline;
}

y veríamos esto cuando haya más de 3 elementos:

Lo único que nos falta es incluir un separador entre ellos, como decíamos al principio que íbamos a necesitar. Esto es muy sencillo y directo usando el pseudo-elemento ::before, así:

#lista li:first-child:nth-last-child(n+4) ~ li:before {
content: " | ";
}

que lo que hace es meter ese carácter de barra vertical (pipe) como separador en todos los elementos menos en el primero (mira la lógica de esto más arriba, pues es la misma que expliqué cuando conseguíamos que se seleccionaran todos menos el primero cuando hay más de "x".

Usando estas dos últimas reglas a la vez, conseguimos exactamente el efecto que buscábamos: solo se cambiará el aspecto cuando haya más de un número determinado de elementos en la lista.

Esto lo puedes extrapolar muy fácilmente a cualquier diseño HTML que se repita dentro de una página, aunque sea complejo. Si además usas SASS puedes crear muchas reglas basadas en esto sin tener que repetir este selector tan largo todo el rato.

Te dejo mi ejemplo aquí (ZIP, 640 bytes) para que juegues con él.

Esta técnica me encanta porque es un ejemplo más que demuestra que, a veces, CSS puede llegar a ser muy potente y otorgar algo de lógica a una estructura con un lenguaje muy limitado.

¡Espero que te resulte útil!

Creación de aplicaciones WPF con Xamarin.Forms

31/10/2018
Artículo original

La semana pasada os comentaba cómo Xamarin.Forms proporciona la posibilidad de crear aplicaciones de escritorio para Linux y otros sistemas operativos (Windows y macOS)

Además, Xamarin.Forms proporciona también soporte para crear aplicaciones con WPF. WPF es la abreviatura de Windows Presentation Foundation. Hablamos de un conjunto de APIs destinadas a crear interfaces de usuario enriquecidas para Windows.

Logo no oficial de WPF

Esto nos proporciona la posibilidad de crear Apps Windows clásicas con interfaces de usuario avanzadas, pero que están soportadas en versiones anteriores a Windows 10.

Veamos cómo...

Crear nuevo proyecto

Comenzamos creando un nuevo proyecto Xamarin.Forms con una librería .NET Standard:

.NET Standard

A continuación, vamos a añadir un proyecto WPF. Dentro de la categoría escritorio clásico de Windows, elegimos la opción Aplicación de WPF:

Aplicación WPF

A continuación, vamos a actualizar el paquete de Xamarin.Forms para utilizar la versión 3.0 o superior.

Al proyecto WPF añadimos también el paquete NuGet Xamarin.Forms.Platform.WPF.

Ya tenemos todo listo en lo que se refiere a dependencias. Es hora de cambiar levemente el código por defecto para poder inicializar Forms.

Actualizamos la ventana principal, MainWindow.xaml para utilizar FormsApplicationPage:

<wpf:FormsApplicationPage x:Class="WPFSample.WPF.MainWindow"
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
     xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
     xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
     xmlns:wpf="clr-namespace:Xamarin.Forms.Platform.WPF;assembly=Xamarin.Forms.Platform.WPF"
     mc:Ignorable="d"
     Title="MainWindow" Height="350" Width="525">
     <Grid>
 
     </Grid>
</wpf:FormsApplicationPage>

También actualizaremos el tipo del code behind en MainWindow.xaml.cs, así:

using Xamarin.Forms.Platform.WPF;

namespace WPFSample.WPF
{
     public partial class MainWindow : FormsApplicationPage
     {
          public MainWindow()
          {
               InitializeComponent();
          }
     }
}

Todo listo, ¡ejecutamos!:

Aplicación WPF con Xamarin.Forms

Y tendremos una simple ventana vacía con poco más que el título, pero es una aplicación de escritorio con interfaz moderna basada en WPF y que puede funcionar en cualquier versión moderna de Windows, no solo en Windows 10 como ocurre con las aplicaciones UWP.

Un nuevo backend de Xamarin.Forms como este ofrece la posibilidad de llegar a nuevas plataformas, así que es normal querer probar todas las posibilidades. ¡No te preocupes, vamos a ver un a continuación un buen ejemplo!.

Puedes descargar WeatherApp (ZIP, 139KB) y ver una aplicación más completa. Es otro ejemplo de aplicación Xamarin.Forms con soporte a WPF que sirve para ver la información meteorológica de forma muy visual:

WeatherApp

¿Algo más?

Ahora que tienes algo de lo que partir, es hora de ponerse la gorra de diseñador de UX y comenzar a explorar los cambios necesarios para adaptar la aplicación a esta nueva plataforma.

Estilos

Échale un vistazo al estilo de la interfaz de usuario para Linux. Es posible que el mismo estilo utilizado en los dispositivos móviles no se vea bien. ¡Esto lo cambiamos fácilmente!

Con los cambios recientes realizados en OnPlatform, ahora puedes seleccionar valores concretos para cada plataforma soportada que quieras utilizar. Eso incluye a WPF.

Desde XAML:

<Button.TextColor>
     <OnPlatform x:TypeArguments="Color">
           <On Platform="iOS" Value="White"/>
           <On Platform="WPF" Value="White"/>
           <On Platform="Android" Value="Black"/>
     </OnPlatform>
</Button.TextColor>

O desde C#:

if (Device.RuntimePlatform == Device.WPF)
     return "Images/image.jpg";
else if (Device.RuntimePlatform == Device.UWP)
     return "Assets/image.jpg";
else
     return "image.jpg";

Demo time!

Al igual que en el post de la semana pasada, también te dejo este vídeo en el que explico brevemente cómo podemos crear una aplicación WPF con Xamarin.Forms:

[youtube:pbyJkcXuYkA]

Página Anterior Página Siguiente