Funcionalidad "Overrides" en Chrome 65: guardando cambios en tu CSS desde el navegador

14/05/2018
Artículo original

Lo que voy a contar a continuación estaba programado para que saliera en la versión 64 de Chrome, en Enero, pero al final la han sacado este mes con Chrome 65.

¿Cuántas veces has estado toqueteando una página que gestionas desde las herramientas del desarrollador? Seguro que muchas.  Lo típico es que un elemento rebelde no acaba de quedar en donde a ti te gustaría o quieres afinar mucho más un margen, un tamaño o un color. Así que abres las herramientas del desarrollador con F12 o con CTRL+MAYs+J (en Windows) y te pones a seleccionar elementos, ver sus reglas resultantes, cuáles influyen sobre el resultado final, y retocas directamente los estilos en el editor del lateral.

Esta funcionalidad ya la habríamos querido para nosotros los que estábamos en esto hace 20 años, pero aún así es un tanto limitada. Si tus cambios se reducen a un par de propiedades CSS puedes tomar nota en un archivo de texto y luego buscar en la CSS original para hacer los cambios. Pero como sean un poco más extensos e involucren unas cuantas propiedades y selectores o, peor aún, se realicen sobre varias hojas de estilo diferentes, entonces hacerles el seguimiento puede ser una locura.

Por suerte la gente detrás de Chrome siempre está al quite con este tipo de detalles y sacan de vez en cuando funcionalidades que nos hacen la vida más fácil. En Chrome 65 han lanzado lo que se denominan "Overrides" que son versiones locales de los mismos archivos que hay en el servidor en los que se van almacenando todos los cambios que hagamos.

Esto es sensacional, ya que nos permite tocar tanto como queramos los estilos de una página y ver los archivos originales ya modificados en nuestro disco duro. Luego solo hay que subirlos por encima de los del servidor y se incorporarán todos los cambios. Es súper-útil.

En el vídeo que pongo a continuación explico en la práctica cómo conseguir esto. Antes de verlo un par de cosas importantes:

  • Los cambios hechos sobre el DOM no se persisten. Es decir, que si añadimos algún estilo en línea con el atributo style o usando la zona element.styles del editor de propiedades CSS, estos cambios no quedarán guardados en ningún lado.
  • Chrome 65 también introduce una cosa muy interesante para verificar si un texto se lee lo suficientemente bien sobre su fondo (contraste) como para que cumpla con las reglas de accesibilidad. Lo comento, como inciso, en el vídeo.

Ahí lo dejo:

[youtube:zG1MXJJzZ6I]

¡Espero que te sea útil!

CSS3: propiedades background-origin y background-clip

14/05/2018
Artículo original

En CSS3 existen un par de propiedades que tienen que ver con cómo se colocan las imágenes de fondo en elemento HTML y que suelen provocar bastantes dudas entre los programadores cuando se las encuentran por primera vez. Se trata de las propiedades background-origin y background-clip. A continuación voy a explicarlas con un ejemplo que creo que las dejará totalmente claras.

La propiedad background-origin se utiliza para determinar a partir de dónde se calcula la posición del fondo de un elemento (combinada con la propiedad background-position). Los valores que puede tomar esta propiedad son:

  • border-box: la posición se empieza a medir desde el borde. Es la opción por defecto si no especificas nada.
  • padding-box: la posición se empieza a medir desde donde empieza el relleno, es decir, no se cuentan los bordes.
  • content-box: la posición se empieza a medir desde donde empieza el contenido, o sea, después del paddding que tenga aplicado el elemento.

Sin embargo la propiedad background-clip indica qué parte de la caja del elemento ocupa la imagen de fondo. Los valores son los mismos que la propiedad anterior.

Dado que su funcionalidad es parecida y los valores que toman son los mismos, causan mucha confusión. Además, en elementos sin borde o sinrelleno, o con valores muy pequeños para éstos, es muy difícil apreciar el efecto de ambas propiedades.

Así que la mejor forma de ver cómo funcionan es con algunos ejemplos prácticos...

Supongamos que tenemos un elemento de tipo <div>, cuadrado, como este:

<div id="fondo" class="clip"></div>

al que le queremos poner la siguiente imagen de fondo:

para lo cual le aplicamos estas reglas CSS (le he puesto un borde y un relleno (padding) bastante grandes para que se note más el efecto):

#fondo {
background: url(yin.jpg) 0 0 no-repeat;
width: 200px;
height: 200px;
border: 20px solid red;
padding: 50px;
}

Como la caja del div es mucho menor que el tamaño de la imagen (la suma de su tamaño + el relleno + los bordes 200+50*2+20*2 = 340 píxeles, porque dejamos el border-sizing por defecto), lo que veremos en este caso es que la imagen de fondo se corta, y con los valores por defecto se verá algo así:

y que la imagen se coloca desde dentro del borde y se ve a partir de ahí.

Podemos ver dónde está posicionada si muestro las dimensiones de cada elemento de la caja del div superpuesto para que se vea:

Teniendo en cuenta esto, si le aplicamos el siguiente selector y estilos en lo que respecta a las propiedades de las que estamos hablando:

#fondo.clip{
background-origin: border-box;
background-clip: content-box;
}

Ahora la imagen está colocada con su extremo superior izquierdo pegado a esos mismos bordes (arriba y a la izquierda, por el background-origin:border-box), pero no se comienza a ver hasta la zona del contenido (background-clip: content-box), así:

Fíjate en la imagen anterior con las dimensiones superpuestas: lo que está ocurriendo aquí es que el borde superior y el izquierdo de la imagen de fondo se pega al exterior del borde de la caja del elemento, es decir, al extremo más alejado de ésta que es la parte exterior del borde. O sea, frente a los valores por defecto lai magen se desplaza a la izquierda y arriba. Además como en el clipping hemos especificado que solo se debe ver a partir del contenido, todo el relleno (en este caso de 50 píxeles, tapa el fondo del div, y por eso aparece la imagen más cortada todavía.

Sin embargo si ahora lo cambiamos para que el clipping no afecte a la zona de relleno:

#fondo.clip{
background-origin: border-box;
background-clip: padding-box;
}

veremos esto otro:

Finalmente, si abarcamos también el borde con el clipping, de entrada no notaremos la diferencia con lo anterior salvo que el borde sea semi-transparente o use puntos o rayas, pues el borde sólido queda siempre por encima. Por ejemplo, poniendo el borde con un 50% de transparencia usando rgba, y colocando el clipping como border-box, veríamos esto:

Donde ya observamos que la imagen de fondo se posiciona totalmente contra el extremo exterior de los bordes y se ve completa porque hemos hecho que el borde sea semitransparente.

Una forma bueno de verlo es que te descargues el archivo de ejemplo y varíes los valores de estas dos propiedades usando las herramientas del desarrollador, algo así (pulsa para verla en grande):

En este gif animado puedes observar el efecto que hace cada uno de los posibles valores de las propiedades sobre cómo se posiciona y se ve el fondo, y cuáles son sus valores por defecto (al desactivarlos).

¡Espero que te resulte útil!

Los grandes bulos sobre tecnología

14/05/2018
Artículo original

Imagen ornamental de carteles antiguos de fenómenos de circo

Los bulos, los falsos mitos, las leyendas urbanas y las noticias falsas siempre han existido. Ya sean fruto del delirio, la divagación o los malentendidos, de mentes imaginativas o personas malintencionadas, o simplemente de la ignorancia, lo cierto es que desde el origen de la civilización humana siempre han circulado falsos rumores . Al ser humano le gustan las fábulas, y aún más confabular.

Antes de la era Internet los bulos se propagaban con mucha más lentitud. Pronto los medios de comunicación de masas se apuntaron al carro de la difusión de bulos en días señalados como el April's Fools Day en el mundo anglosajón (el 1 de abril) o el Día de los Santos Inocentes en España e Hispanoamérica (28 de diciembre).

Hoy en día por Internet circulan todo tipo de patrañas, falsas noticias y leyendas que en algunos casos tienen un fin malintencionado y que pueden manipular la opinión pública hasta el punto de distorsionar la realidad y causar resultados imprevistos en momentos decisivos como las elecciones o en la gestión de crisis de orden público, catástrofes naturales, etc... De hecho la situación es tan preocupante que han aparecido medios de comunicación que tienen como objeto desmentir los bulos que se generan con la intención de manipular a las personas.

El mundo tecnológico del software y el hardware tampoco está libre de patrañas. Existen bulos de todo tipo: historias falsas sobre empresas tecnológicas, leyendas urbanas sobre diferentes productos, falsos mitos sobre cómo hay que operar con una cierta tecnología para estar más seguros o para que los dispositivos duren más o rindan mejor, etc...

A continuación hemos recopilado algunos de los grandes bulos relacionados con el mundo de la tecnología. Seguro que hay más de uno que has escuchado antes. Si sabes o se te ocurre algún otro, no dudes en ponerlo en los comentarios.

El primer gran bulo de Internet

Este es uno de los primeros bulos en los albores de Internet, que se propagó en forma de email en cadena. Corría el año 1994 y saltó lo que hoy en día se conoce como el bulo de la adquisición de Microsoft. Una nota de prensa fraudulenta, supuestamente de la agencia Associated Press, afirmaba que Microsoft "adquiriría la Iglesia Católica Romana a cambio de un número indeterminado de acciones de la compañía", y que el gigante del software esperaba "un crecimiento exponencial en el mercado religioso en los próximos cinco a diez años...". Por otro lado el comunicado argumentaba que "que la combinación de los recursos de Microsoft y la Iglesia católica nos permitirán hacer de la religión algo más fácil, ameno y más divertido para una gama más amplia de personas".

Evidentemente muchas de las afirmaciones del comunicado de prensa no eran verosímiles, desde sugerir que los católicos pronto serían capaces de tomar la Sagrada Comunión a través del ordenador hasta afirmar que la conversión al catolicismo era un upgrade. A pesar de estas claras señales de advertencia en forma de falacia sobre la imposibilidad de la noticia, fueron varios lectores de dicha nota de prensa los que se pusieron en contacto con Microsoft para contrastar si era ciertas las afirmaciones de la broma, y el 16 de diciembre de 1994, Microsoft formalmente salió a negar la información difundida en la nota.

A pesar de la proliferación de los correos electrónicos en cadena que circulaban en Internet en aquella época (y que sigue siendo habitual en nuestros días, especialmente por aplicaciones de mensajería instantánea, y si no revisa los mensajes de tus padres), el bulo de la adquisición de Microsoft es considerado el primer gran engaño en alcanzar a una audiencia masiva a través de Internet.

Bulos relacionados con hardware, software y la programación

A continuación repasaremos una miscelánea de leyendas urbanas que están relacionadas con el mundo del hardware, el software y la tecnología en general.

Los informáticos y los ingenieros lo saben todo sobre ordenadores

El concepto de ordenador es un término muy amplio que se usa para muchos dispositivos y cuya definición más básica es: algo que puede aceptar una entrada, procesarla y darle salida.

Esta definición efectivamente incluye cualquier cosa, desde una calculadora hasta supercomputadores muy avanzados. La aviónica, la electrónica de coches, smartphones, satélites, etc. pueden ser todos considerados como dispositivos electrónicos.

No se puede esperar que un ingeniero informático o científico lo sepa todo acerca de esta amplia gama de productos, especialmente porque las personas que trabajan en las TIC tienden a especializarse en campos muy específicos. Esto seguro que es una obviedad para ti, pero no lo es tanto para mucha gente. Y seguro que lo has sufrido ;-)

Los ordenadores portátiles de Apple son mejores para la programación / Los Macs son mejores que los PCs:

No nos engañemos, los Macs son muy molones, y a muchos programadores nos encanta portarlos porque son tendencia. Hemos asociado el precio más alto de Mac al hecho de que por eso tienen más calidad. Sin embargo, no hay datos objetivos que respaldan el hecho de que un MacBook de Apple es mejor para la programación, y no vale sacar el argumento de que los Mac no tienen virus, ya que esa es otra leyenda urbana. Definitivamente, hay Macs que son mejores que algunos PCs pero también se da el caso contrario... ¡Anatamea, anatema!

Para un desarrollador emprender es más fácil

Otra idea falsa que circula en el imaginario colectivo es la creencia de que para los perfiles tecnológicos es más fácil emprender y abrir un negocio. A ver, es cierto que como programadores podemos implementar casi cualquier idea que nos venga a la cabeza sin necesitar a nadie a la hora de hacer un software. Pero una empresa de software no es solo software. Para arrancar un negocio sostenible en el tiempo se necesita mucho más. Tienes que ser igual de bueno en facetas como la organización, la gerencia, los procedimientos, las ventas (especialmente), y todos los otros términos que implica tener una empresa.

La inteligencia artificial nos traerá el apocalipsis

Es innegable que la inteligencia artificial se va a cargar algunos puestos de trabajo y hará tareas que hoy en día aún hacen las personas, el futuro apocalíptico que muchos predicen cuando se habla de la revolución de la inteligencia artificial es irresponsable y errado. Es algo más bien fruto de una película de ciencia ficción que otra cosa. El debate se centra en la regulación y la legislación, y ya ha habido alguna que otra guerra de egos por el tema.

La navegación privada/incógnito te mantiene anónimo

Existe una idea equivocada y generalizada de que navegar en modo "incógnito" o "privado" son sinónimos de permanecer anónimo. Si usas el modo incógnito en Google Chrome o la navegación privada en Safari, simplemente significa que el navegador no va a hacer un seguimiento de tu historial, ni importar tus marcadores, o iniciar sesión automáticamente en cualquiera de tus cuentas.

Básicamente, solo sirve para que las otras personas que utilizan tu ordenador no puedan ver lo que has estado haciendo. Pero no mantendrá tu identidad oculta de los sitios que visitas o de tu proveedor de servicios de Internet, así que tenlo en cuenta si estás visitando sitios que no deberías.

Vaciar la papelera de reciclaje elimina permanentemente los archivos

Tendría sentido que eliminar un archivo realmente lo eliminara. Pero cuando se vacía la papelera de reciclaje (Windows) o papelera (Mac), los datos no se borran, sólo se eliminan los "punteros" a los archivos completos. Un equipo al que se le ha dicho que elimine un archivo no lo eliminará, y en verdad lo que hace es desasignar el espacio que ocupa en el disco duro, abriendo ese espacio para que se escriba algo nuevo sobre él. Eso significa que aún quedan pedacitos de información dispersos, y cualquier hacker podría juntarlos para reconstruir lo que creías que había desaparecido para siempre. De hecho hay muchos programas de recuperación de archivos precisamente por eso.

Para eliminar archivos de forma definitiva y permanente, tienes indicarle al ordenador para vaya un paso más allá de simplemente vaciar la papelera de reciclaje. En un Mac, elige "Secure Empty Trash"; en un PC, tienes que utilizar un programa externo para ello. Uno muy conocido y utilizado es SDelete. Se trata de un programa gratuito que te permite borrar totalmente cualquier espacio libre o sólo archivos específicos usando la línea de comandos.

De todo esto se saca una ventaja: si accidentalmente eliminas algo y tienes que recuperarlo, en teoría, puedes.

Dejar el teléfono enchufado destruye la batería

Si eres como la mayoría de las personas, probablemente dejes tu teléfono enchufado durante toda la noche y queda ahí incluso después de que la batería esté completamente cargada.

Se solía decir que esto dañaría la vida de la batería de tu teléfono, pero de hecho, no hay ninguna prueba de que esto dañe la batería de tu teléfono de ninguna manera. Los smartphones modernos funcionan con baterías de iones de litio, que son lo suficientemente inteligentes como para dejar de cargarse cuando han alcanzado la capacidad de carga completa. De esto ya hemos hablado extensamente en otra ocasión.

Más megapíxeles siempre significa una mejor cámara

¿Cuál es la diferencia entre las cámaras de 12 megapíxeles y las cámaras de 8 megapíxeles? Pues en realidad no hay mucha. La calidad de una imagen se determina en gran parte por la cantidad de luz que el sensor es capaz de captar. Los sensores más grandes pueden venir con píxeles más grandes, y cuanto más grande es el píxel más luz puede absorber.

Por lo tanto, lo que realmente determina la calidad de una cámara es el tamaño de los píxeles más que el mero número de píxeles (un megapixel es simplemente una forma corta de decir un millón de pixeles).

Una mayor resolución de pantalla siempre es mejor en un smartphone

Muchos han argumentado que a partir de cierta magnitud, una mayor resolución de pantalla no importa en un smartphone. En su día, expertos de Apple, entre otros, afirmaron que el ojo humano no puede discernir más detalles cuando una pantalla empaca más de 300 píxeles por pulgada. A principios de 2017, LG reveló su primer smartphone Quad-HD, el G3, que tiene una resolución de 2560 x 1440. Eso es mucho más alto que el smartphone de gama alta medio, que por lo general viene con una resolución de pantalla de 1920 x 1080.

Pero no está claro si esos números realmente importan después de cierto punto, porque el ojo no puede discernir píxeles individuales más allá de cierta resolución...

Más barras de señal garantizan un gran servicio móvil

Aunque tener más barras ayuda a tener mejor servicio, no necesariamente garantiza una excelente recepción. Las barras sólo indican lo cerca que está de la torre celular más cercana. Pero existen otros factores que influyen en la rapidez con la que funciona internet en el teléfono, como el número de personas están utilizando la red de forma simultánea. Por eso cuando estás en un concierto o en un evento deportivo de masas puedes quedarte por momentos sin servicio a pesar de estar a tope de cobertura.

Cuánto más nuevo, mejor

Este bulo es muy común, pero si trabajas en el sector sabes que una tecnología más reciente no es mejor por el simple hecho de ser nueva. De hecho, muchas veces lo nuevo puede ser un fiasco absoluto.

Un ejemplo puede ser Windows 8 que tenía tantos errores que fue reemplazado rápidamente por Windows 8,1 y, posteriormente, Windows 10.

Antes del lanzamiento de Windows 8, muchos usaban Windows 7 (que es anterior) sin quejas ni muchos problemas. De hecho se sigue viendo mucho Windows 7 por ahí. La tecnología cuando es nueva necesita un tiempo para madurar, corregir errores y mejorar la experiencia del usuario. Es una de las razones por las que los equipos militares no se actualizan cada vez que surge algo nuevo :)

Conclusión

Hemos dejado muchas otras falsas creencias relacionadas con la tecnología, como la de que Windows es malo, o que el software de código abierto es gratis/barato, o que el software es testado en profundidad antes de ser lanzado, o que todas las actualizaciones son por temas técnicos y no por marketing/imagen, la lista tiende a infinito.

Si se te ocurre alguno y quieres compartirlo, no dudes en hacerlo en la zona de comentarios.

Las 7 razones para aprender SQL que quizá nunca te habías parado a pensar

14/05/2018
Artículo original

Si te dedicas al desarrollo (o simplemente estás dentro del sector tecnológico) probablemente estés de acuerdo conmigo en que últimamente el panorama se parece bastante al mito de Sísifo: cada vez que aprendes una tecnología nueva, a los seis meses (con suerte) te la cambian y vuelta a empezar.

Esto se agrava ante la abrumadora cantidad de lenguajes, herramientas y entornos de trabajo entre los que elegir nuestro set de herramientas. El coste de elegir mal nos puede salir caro.

En cambio, hay tecnologías que siempre han estado ahí, y que por el hecho de no brillar tanto en el escaparate de la fahion week del mundo del desarrollo muchas veces no se les presta la atención que se debería, especialmente por parte de los desarrolladores más noveles.

Me estoy refiriendo a SQL, y hoy quiero poner el foco sobre este lenguaje y destacar su importancia estratégica para la carrera profesional de alguien como tú, que seguramente se dedica al desarrollo o a alguna otra profesión relacionada dentro del mundo IT.

Antes de nada, damos por supuesto que ya sabes que SQL (Structured Query Language) es un lenguaje para bases de datos, ¿no? ;-) Allá va la lista:

1- SQL está en todas partes

SQL es para las empresas lo que la fuerza es para los Jedi: está en todas partes, fluye entre nosotros y nos rodea. Tanto en empresotes como Microsoft, Uber, Netflix, Airbnb... o incluso Facebook, Google y Amazon (que han desarrollado sus propios sistemas de Bases de Datos) como cualquier pequeña o mediana empresa que te imagines, todas, están usando SQL de alguna forma u otra. Da igual a dónde vayas, ya que seguro que le sacarás provecho.

2- Es fácil de aprender

SQL es fácil de aprender (al menos lo fundamental), y si lo comparas con los beneficios que aporta dominarlo, invertir en aprender bien SQL es extremadamente rentable. Ojo, incluso si no te dedicas a programar, le puedes sacar muchísimo partido a SQL.

Tira cómica original de XKDC

3- Es un conocimiento portable: no te ata a ningún fabricante

Una de las grandes ventajas de SQL frente a otros lenguajes es que es de uso transversal. Muchos desarrolladores a la hora de decidirse a aprender una nueva tecnología tienen dudas ante el coste de oportunidad de no aprender otras. Con SQL esto no ocurre. Si inviertes tiempo y dinero en convertirte en especialista en SQL Server, una gran parte de ese conocimiento y experiencia los podrás aprovechar si en el futuro cambias a una empresa donde, en su lugar, utilicen Oracle, MySQL o PostgreSQL (por citar solo algunas).

4- Muchos años de rodaje a sus espaldas

SQL nació a finales de los año 70 en los laboratorios de IBM (nada menos) y se empezó a explotar comercialmente por Oracle (otros don Nadie ¿verdad?) en 1979, pero sus orígenes teóricos se remontan al modelo relacional propuesto por E. F. Codd en 1970. O lo que es lo mismo, es una tecnología que no surgió de un día para otro y que lleva más de 40 solventes años entre nosotros dándolo todo. Pero eso no significa que esté obsoleta.

Sin ánimo de faltar al respeto a nadie, ahora compara esta evolución con el nonagésimosegundo framework molón de JavaScript que se sacaron un par de colegas en un fin de semana. Sí. Ya sé que es comparar churras con merinas, pero, independientemente de que son cosas diferentes, ¿qué te parece más fiable a la hora de invertir tu tiempo, dinero y energía en aprenderlo?

5- SQL nunca cambia

Si como desarrollador te estresan los cambios, SQL es al desarrollo lo que el oro a la inversión financiera. Esto es, un valor seguro. Cada fabricante lo implementa de manera distinta pero se suelen mantener muy cerca del estándar, y el núcleo duro de SQL apenas cambia.

Una vez entiendes los conceptos básicos de SQL y de la teoría relacional, te encontrarás muy a gusto desarrollando nuevas funcionalidades por encima y disfrutando de una enorme independencia que antes no tenías. Y todo esto sabiendo que no te van a poner patas arriba todo lo aprendido en los próximos meses. ¡Si Demócrito levantase la cabeza...!

No es fácil que un estándar se mantenga tan estable, según esta tira de XKDC

6- Está (muy) bien valorado por las empresas

Si ya los buenos desarrolladores están demandados, un experto en SQL es de lo más valorado y apreciado en el mundillo tecnológico. Y ya no solo porque las bases de datos son parte esencial de cualquier desarrollo (donde se necesita consultar, modificar y definir bases de datos, así como diseñarlas y optimizarlas) es que las empresas de cualquier sector actualmente manejan mucha información, y disponer de una persona que sepa sacarle provecho a esto en términos de negocio es un tesoro.

Así que no debe extrañarte que este lenguaje aparezca como el más demandado con diferencia por las empresas. Fíjate, en el momento de escribir este post, había disponibles en Indeed 1.250 ofertas de trabajo que incluían SQL (y me refiero solo en Madrid).

7- La información es poder

Ya se ha mencionado en el punto anterior, pero esto se merece su propio punto y además queremos recalcártelo por si no te había quedado claro. La información es poder. ¿Y quién puede manejar mejor la información en una empresa que un especialista en SQL? Tener a alguien que sepa bien lo que hace es crucial. Eso sí, recuerda que, como Spiderman, un gran poder conlleva una gran responsabilidad.

Vale, ya te he convencido ¿A que sí? Pues entonces vayamos al siguiente punto importante...

¿Y cuál es la mejor forma de aprender SQL?

Bueno, pues como todas las cosas importantes en la vida, depende. ¿De qué depende? Pues básicamente de donde estés y a dónde quieres llegar.

Ahí fuera encontraras miles de tutoriales, cursos y vídeos gratuitos. Si solo quieres echarle un vistacillo a SQL, ver un poco de qué va esto, y no esperas nada más de la vida, de acuerdo. Adelante, ve a por ellos.

Ahora bien. Si lo que quieres es aprender unas bases de SQL sólidas como la roca, con vistas a usarlo con solvencia en las trincheras de tu trabajo diario mientras sujetas un cuchillo entre los dientes... entonces quédate con nosotros. Quédate, porque hemos planificado y elaborado con el mimo de un artesano, el temario y los contenidos de los cursos que realmente necesitas.

Simplemente elige tu curso y, en menos de 3 meses, probablemente te estarás arrepintiendo de no haberte decidido a hacerlo mucho antes:

Y si esto no es exactamente lo que buscas, no dejes de pasarte por nuestra categoría de cursos de acceso a datos, a lo mejor lo encuentras allí.

Lo que los ordenadores te pueden enseñar sobre gestionar tu tiempo

14/05/2018
Artículo original

Tanto los seres humanos como los computadores comparten el reto de cómo hacer lo máximo posible en un tiempo limitado. Más o menos durante los últimos 50 años, los ingenieros informáticos han aprendido y desarrollado un montón de buenas estrategias para la gestión del tiempo de manera eficiente. Por el camino también han cogido experiencia de cosas que han salido rematadamente mal.

¿Qué podemos aprender de todo esto? ¿Se podrían aplicar estas enseñanzas a nuestro día a día para ser más eficientes en nuestro trabajo y vivir mejor?

Vamos a verlo...

El Pathfinder que procrastinaba

En el verano de 1997, el vehículo espacial de la NASA Pathfinder aterrizó sobre la superficie del planeta Marte y empezó a retransmitir a la tierra unas imágenes increíbles e icónicas, hito del que por cierto se cumplieron 20 años el verano pasado. Sin embargo, tras varios días sin problemas, algo empezó a ir fatal.

Las retransmisiones se detuvieron. El Pathfinder estaba de hecho procrastinando: se mantenía a sí mismo totalmente ocupado pero sin hacer su cometido más importante, que era retransmitir imágenes del planeta rojo a la tierra.

¿Qué estaba pasando? Pues resultó ser que había un bug, un error, en su planificador de tareas. Todo sistema operativo dispone de un elemento que se denomina planificador, que le dice a la CPU cuánto tiempo tiene que dedicarle a cada tarea antes de pasar a otra, además de decirle a qué tarea debe pasar.

Cuando todo va bien, los ordenadores pasan de una forma tan fluida de una actividad a otra y van cumpliendo con sus responsabilidades de forma tan armoniosa que parece que están haciendo todo de forma simultánea. Pero todos sabemos qué pasa cuando las cosas empiezan a ir mal: el ordenador se cuelga, se congela la imagen y entra en parálisis operativa.

A los seres humanos el hecho de que un ordenador se quede colgado nos debería servir, como mínimo, de consuelo. Incluso los ordenadores se ven abrumados y sobrepasados de vez en cuando.

El algoritmo cuadrático

Quizás aprender cosas de la ingeniería informática que hay detrás de la programación de tareas en los sistemas operativos de los ordenadores nos puede arrojar algo de luz sobre nuestras propias luchas y frustraciones con la gestión del tiempo.

Una de las primeras revelaciones que podemos descubrir es que todo el tiempo que le dedicas a ponerle prioridades a tus tareas es tiempo que no dedicas a completarlas.

Por poner un ejemplo, digamos que cuando abres tu correo electrónico, lo primero que haces es ojear por encima todos los mensajes, buscando el más importante. Una vez que has gestionado ese correo, repites el proceso hasta completar el segundo, y así sucesivamente. El enfoque parece razonable, pero en realidad tenemos un problema.

Es lo que se conoce como un algoritmo o función de complejidad cuadrática, denominado O(n<sup>2</sup>) en notación Big-O. Si tu buzón de entrada del correo electrónico está el doble de lleno, ¡esas ojeadas buscando cada email llevarán el doble de tiempo! y además tendrás que hacer la búsqueda el doble veces...

Conclusión: el trabajo se multiplica por cuatro.

Linux y los cubos de prioridades

Allá por el año 2003 los programadores del sistema operativo Linux se toparon con un problema parecido. Linux priorizaba cada una de sus tareas en función de su importancia y las programaba en cola siguiendo ese orden. El problema es que en muchas ocasiones se pasaba más tiempo priorizando y ordenando las tareas que ejecutándolas.

La solución que, contra toda intuición y sentido común, se les ocurrió a los programadores de Linux fue la de sustituir este sistema exhaustivo de priorización de tareas por otro basado en un número limitado de "cubos" de prioridad (también denominados "niceness" o "simpatía" de procesos). Una vez cubierto el cupo de un cubo, las tareas entran en ejecución. El sistema no tarda tanto en pensar qué hacer a continuación, y se centraba más en ejecutar tareas, logrando avanzar. Se comprobó que este nuevo sistema era más eficiente que el anterior.

Así que siguiendo con el ejemplo con tu buzón de entrada y tus emails, darle muchas vueltas en pensar qué hay que hacer a continuación siguiendo un criterio de importancia puede conducir a la catástrofe. Abrir el correo electrónico una mañana y ver que está tres veces más lleno de lo normal te llevaría nueve veces más de tiempo en gestionarlo. ¡Casi es mejor empezar por orden cronológico o incluso aleatoriamente!

Resulta sorprendente, pero en ocasiones no invertir energías en hacer las cosas siguiendo un orden perfecto puede resultar clave a la hora de conseguir ejecutar las tareas a tiempo.

Interrupciones y cambios de contexto

Otra conclusión que podemos obtener de la programación de tareas tiene que ver con una de las características más prevalentes en la vida moderna: las interrupciones. Cuando un ordenador pasa de una tarea a otra, tiene que hacer lo que se denomina un cambio de contexto, dejando una marca en la tarea que estaba realizando, retirando los datos antiguos de su memoria e incorporando los datos de la tarea nueva.

Cada una de estas acciones tiene un coste. La enseñanza que extraemos de esto es que se produce una incompatibilidad irreconciliable entre la productividad y la capacidad de dar respuesta a nuevas peticiones.

Sacar mucho trabajo adelante implica minimizar los cambios de contexto.

Pero, al mismo tiempo, tener capacidad de respuesta supone poder reaccionar cada vez que se necesita algo.

Los dos principios, minimizar cambios de contexto y poder dar respuesta a nuevas tareas, están en constante tensión de equilibrio.

La capacidad de identificar esta tensión nos permite decidir dónde queremos romper ese equilibrio. La solución más obvia sería la de minimizar las interrupciones.

El coste del cambio de contexto en un ordenador
Imagen obtenida del estupendo artículo sobre el tema de Bryan Braun

Una solución menos evidente es el hecho de agruparlas. Si no hay ninguna notificación o correo electrónico que requiera una acción o una respuesta urgente en el plazo de, por ejemplo, una hora, pues esta es la frecuencia con la que deberías consultarlos. Nada más que eso.

En ingeniería informática, esta idea se conoce como la coalescencia de interrupciones. En vez de gestionar los asuntos a medida que van surgiendo -¿se ha movido el ratón?, ¿se ha pulsado una tecla?, ¿se ha descargado una parte más de ese archivo?-, el sistema lo que hace es agrupar esas interrupciones en función de cuánto tiempo pueden permitirse esperar.

En 2013, este concepto (interrupt coalescing) supuso una mejora sustancial en la vida de las baterías de los portátiles y móviles. Esto sucede porque diferir las interrupciones le permite al sistema comprobar todo a la vez, y luego retornar a un estado de ahorro de batería.

Al igual que ocurre con los ordenadores, las personas también experimentan este fenómeno. Quizás si somos capaces de adoptar un enfoque similar podamos centrarnos más y mejor en nosotros mismos, y entonces igual seremos capaces de reconquistar aquello que tan escaso resulta en nuestra era moderna: el descanso.

Este artículo es una transcripción adaptada del vídeo de Brian Christian para TED-Ed de enero de 2018. Puedes ver el vídeo completo a continuación:

[youtube:iDbdXTMnOmE]

Conclusiones

  • TODOS, de vez en cuando, nos vemos sobrepasados. Mientras no sea frecuente no es algo de lo que debamos preocuparnos.
  • Analiza tu comportamiento para determinar su complejidad y reducirla
  • A veces el orden lógico no es el más eficiente
  • Agrupa tareas por prioridades y ejecuta estos grupos por orden
  • Minimiza las interrupciones y los cambios de contexto

Las 10 reglas de oro para escribir código de calidad

14/05/2018
Artículo original

Todos sabemos que escribir buen código es muchísimo más que conocer un lenguaje. Del mismo modo que saber hablar inglés no te convierte en Shakespeare, conocer C# o Java no te convierte en programador (y mucho menos en un Ingeniero de Software).

Que un programa resuelva un problema, que lo haga sin fallos y sin gastar más recursos de lo necesario, es el mínimo exigible. El "aprobado raspado", podría decirse.

Si se pretende alcanzar cotas de calidad más altas, el software debe tener muchas otras propiedades, más difíciles de ver a simple vista.

Un software excelente debe:

  • Ser fácilmente entendible
  • Ser extensible y reusable
  • Estar bien estructurado y testado
  • Facilitar el compartir conocimiento
  • Estar bien preparado para cambios futuros que no podemos prever.

¿Cómo se consigue todo eso?

Portada del libroCon este eBook gratuito...

Te presentamos el eBook "Las 10 reglas de oro para escribir código de calidad" que Iñaki Ayucar ha tenido a bien elaborar para nosotros.

Iñaki es un ingeniero informático muy experimentado que ha trabajado en toda clase de equipos, pequeños y grandes. Ha creado simuladores híper-realistas para marcas como Toyota o Bentley, y ha trabajado en desarrollo de juegos para Microsoft o Electronic Arts.

Y ahora ha reunido para ti en este eBook un decálogo de las reglas que en su opinión son las más importantes a la hora de construir software de calidad.

Puedes obtener este eBook gratuito en formato PDF (517KB) y descarga directa simplemente pulsando el siguiente enlace:

Descargar "Las 10 reglas de oro para escribir código de calidad" de Iñaki Ayucar

 Estamos seguros de que te resultará útil.

Y si tienes algún comentario, puedes hacerlo en el espacio de abajo, en esta página.

FRIKADAS: Convierte la pantalla de tu MacBook en táctil por menos de 1 euro

14/05/2018
Artículo original

El estudiante de doctorado del MIT Anish Athalye, con ayuda de tres amigos más, han logrado convertir la pantalla de su MacBook Pro en una pantalla táctil con sus propios medios, para lo cual ha utilizado una pieza que cuesta algo menos de 1€ (1 dólar para ser exactos) y un poco de visión artificial. En total han invertido unas 16 horas.

Lo han denominado Proyecto "Sistine" en honor al dedo de la pintura de Miguel Ángel en la capilla Sixtina del Vaticano:

Y han dejado todo el código fuente e instrucciones en el enlace anterior.

¿Cómo funciona?

El principio básico detrás de Sistine es simple. Las superficies, vistas desde un ángulo, tienden a verse brillantes y se puede saber si un dedo está tocando la superficie comprobando si está tocando su propio reflejo:

Uno de los miembros del equipo, Kevin Kwok, se había basado en eso anteriormente para crear un proyecto Open Source llamado ShinyTouch que aprovechaba el fenómeno para hacer esa detección. El problema es que ese proyecto hacía uso de una cámara web externa para "mirar" la pantalla. La prueba de concepto estaba bien (y una genial frikada) pero no era utilizable en la práctica.

La idea fue introducir algún tipo de espejo pequeño delante de la cámara integrada del MacBook de modo que "mirase" hacia abajo todo el rato, en un ángulo lo suficientemente pronunciado como para ver los dedos y capturar el movimiento.

Las piezas utilizadas fueron:

  • Un diminuto espejo
  • Un disco de papel rígido (cartulina dura)
  • La bisagra de una puerta
  • Cola para pegar

Tras hacer unas cuantas pruebas, lograron un diseño que se podía montar en unos minutos usando tan solo un cuchillo y una pistola de cola. El resultado fue este prototipo:

El software necesario para detectar el dedo y su reflejo, utiliza técnicas clásicas de visión artificial (es decir, nada de redes neuronales o AI), y básicamente lo que hace es:

  1. Filtra la imagen para localizar colores de la piel
  2. Localiza los contornos/bordes de los dedos
  3. Encuentra los contornos de mayor tamaño para asegurar que se superponen en la dirección horizontal, y que el menor está por encima del de mayor tamaño
  4. Identifica el punto de contacto como el punto intermedio de la línea que conecta la parte superior del contorno inferior con la parte inferior del contorno superior
  5. Distinguen entre tocar y moverse por encima usando la distancia vertical entre los dos contornos

En la imagen anterior podemos ver los contornos del dedo y de su reflejo (en verde), la caja que los contiene (en rojo) y el punto de contacto (el puntito magenta).

El paso final es realizar la calibración del sistema para que funcione bien en tu pantalla, para lo cual el sistema utiliza homografía.

En su página de Github tienes acceso al código utilizado, y en este artículo del blog de Anish está una explicación más detallada.

Una gran frikada pero con aplicaciones prácticas muy interesantes. Lo mejor es que es muy fácil de reproducir por tu cuenta y además se puede aprender mucho del código que han utilizado.

Cómo centrar y distribuir elementos HTML con el módulo flexbox de CSS

14/05/2018
Artículo original

Hace tiempo hablamos en este blog sobre cómo centrar elementos en una página web mediante CSS, y para ello era necesario considerar múltiples posibilidades, involucrando propiedades sobre posicionamiento, márgenes y alturas. Además, los métodos eran muy distintos según buscásemos centrado horizontal o vertical. En esta guía aprenderemos cómo dos propiedades pertenecientes al módulo Flexible Box Layout (también conocido como flexbox) de CSS nos pueden ayudar a centrar elementos, e ir un poco más allá. Este módulo ya está soportado en cualquier navegador moderno, pero no es adecuado si queremos que nuestra página se visualice correctamente en versiones antiguas de algunos navegadores, como Internet Explorer.

El objetivo del módulo flexbox es definir la organización de una serie de elementos que fluyen en una dirección, horizontal o vertical, que viene dada por la propiedad flex-direction. Es importante distinguirlo del sistema grid, que permite describir la estructura de los elementos tanto horizontal como verticalmente.

Para activar el uso de flexbox en un ítem, es necesario asignarle la propiedad display: flex;. Este será el contenedor en el cual centraremos o distribuiremos elementos. Comencemos con el siguiente ejemplo, un contenedor con un único elemento descendiente:

<div class="container">
  <div class="child">Bloque sin centrar</div>
</div>

<style>
.container {
  background: #e0e0e0;
  margin: 0 0 1rem;
  height: 10rem;
  display: flex;
  /* align-items por defecto tiene el valor `stretch` */
  align-items: start;
}
.child {
  background: #60e0b0;
  padding: .2rem;
}
</style>

Centrado horizontal y vertical de un elemento

En este apartado tomaremos nuestro ejemplo base y centraremos el elemento descendiente mediante el simple uso de dos propiedades del módulo flexbox: justify-content y align-items.

La propiedad justify-content del contenedor define cómo se deben distribuir sus elementos descendientes a lo largo del eje principal. Por defecto se acumulan los elementos horizontalmente desde el inicio del contenedor, pero en nuestro caso, nos interesa darle el valor center, que agrupa los elementos en el centro del eje. En la siguiente figura se puede observar el resultado de usar la propiedad:

Centrando un elemento horizontalmente

La propiedad align-items describe cómo se organizan los elementos del contenedor a lo largo del eje perpendicular al principal, en nuestro caso, el eje vertical. Si no se le asigna valor alguno, se comportará generalmente como stretch, es decir, los elementos tratarán de ocupar todo el alto del contenedor. Sin embargo, nos conviene ajustarlo a center, que buscará que los ítems se centren verticalmente:

Centrando elementos en el eje vertical

En conclusión, para centrar un único elemento dentro de un contenedor más grande, basta con usar el valor center para ambas propiedades. El código de nuestro ejemplo que permite hacer esto quedaría así:

<div class="container center-h center-v">
  <div class="child">
    <code>justify-content: center;<br>align-items: center;</code>
  </div>
</div>

<style>
.container {
  background: #e0e0e0;
  margin: 0 0 1rem;
  height: 10rem;
  display: flex;
  /* align-items por defecto tiene el valor `stretch` */
  align-items: start;
}
.center-h {
  justify-content: center;
}
.center-v {
  align-items: center;
}
.child {
  background: #60e0b0;
  padding: .2rem;
}
</style>

Distribución de varios elementos de bloque

Flexbox aporta mayor flexibilidad cuando se trata de colocar más de un elemento en un contenedor. Para ello, las propiedades que hemos estudiado en el apartado anterior aceptan otros valores. Para justify-content, los valores start, center y end simplemente agruparán los elementos uno tras de otro en la posición elegida, pero space-between, space-around y space-evenly dejarán cierto espacio entre los elementos. Las diferencias entre ellos son sutiles: con space-between no se deja espacio antes del primer elemento ni después del último, con space-around dicho espacio será la mitad que entre cada dos elementos, y con space-evenly dicho espacio será el mismo que entre cada dos elementos.

Por otro lado, también es posible que queramos distribuir nuestros elementos verticalmente en lugar de horizontalmente. Para ello podemos cambiar la dirección del flujo de elementos con flex-direction: column; (el valor por defecto es row). Cuando lo hagamos, justify-content pasará a afectar a la distribución vertical y align-items a la horizontal, es decir, al cambiar la dirección se intercambian los ejes de las propiedades. En la figura se muestran algunos ejemplos de estas propiedades y valores:

Distribución de varios elementos en línea

Lo último que quiero comentar es cómo trata flexbox a los elementos en línea (nodos de texto, <img>, <code>...). Si son los descendientes directos de un contenedor flex, ya no se respetará la continuidad de la línea sino que se tratarán como ítems separados, de forma similar a como se tratan los elementos de bloque. El ancho disponible del contenedor se distribuirá entre los elementos acorde con la longitud de cada uno.

Además, en este caso podremos alterar el alineamiento vertical para que coincidan las líneas base (baselines) de los elementos, mediante align-items: baseline. De esta forma, los renglones de texto de los distintos nodos estarán alineados entre sí. Como podemos ver en el siguiente ejemplo, además, también se tienen en cuenta las imágenes:

Espero haberte convencido de la enorme utilidad de flexbox y que estés deseando empezar a trastear con este módulo ya. Para ello, te dejo el código de ejemplo listo para jugar con él.

Fuentes y más información:

Cómo solucionar el error "java.lang.NoClassDefFoundError" en Java

14/05/2018
Artículo original

La excepción en el hilo "main" del tipo java.lang.NoClassDefFoundError es uno de los errores más comunes que te puedes encontrar al programar en Java. Y también una de las que más quebraderos de cabeza te pueden ocasionar dependiendo de la circunstancia que la cause.

Exception in thread "main" java.lang.NoClassDefFoundError

Dependiendo del tamaño de tu aplicación, resolver este error puede ser más o menos difícil (cuanto más grande más complicado, lógicamente).

Vamos a ver a continuación las causas más comunes de que se produzca este error y cómo podemos intentar resolverlo.

¿Qué significa este error y por qué se produce?

Antes de nada es necesario que sepamos a qué se debe la aparición de este error. Como su propio nombre indica, este error se produce cuando la máquina virtual de Java no es capaz de encontrar la definición de una clase de la que depende el programa para su funcionamiento. Es decir, cuando su ClassLoader no es capaz de encontrar la clase en su árbol de carga actual.

Si el programa compiló sin problema, quiere decir que la clase se encontró a la hora de compilar, pero luego, en ejecución, no aparece por ningún lado, lo cual puede parecer una cosa muy extraña, pero existen diversos motivos para que pueda ocurrir.

Para empezar, tiene mucho que ver el funcionamiento del ClassLoader. Sin profundizar ni entrar en mucho detalle (info detallada aquí), este objeto funciona de manera jerárquica, de modo que hay varios ObjectLoader a diferentes niveles que localizan y cargan clases. Por ello, por ejemplo, incluso aunque una clase se encuentre, dependiendo del nivel en el que aparezca, si la estamos usando en un nivel inferior es posible que se produzca el temido error que nos ocupa. O puede que si hay dos versiones diferentes del mismo paquete instaladas en el sistema, que se produzca también (generando lo que se conoce como el JAR Hell)

Hay muchas posibilidades. Para solucionar el problema, primero hay que determinar el motivo por el que está ocurriendo, y luego actuar en consecuencia.

Es interesante notar que la excepción java.lang.ClassNotFoundException, que se parece mucho a la que estamos tratando, solo se produce cuando intentamos cargar en tiempo de ejecución una clase utilizando su nombre. Son excepciones distintas aunque conceptualmente parecidas. Esta última es menos frecuente. La que nos ocupa tiene una ventaja y es que sabemos que durante la compilación la clase estaba presente.

Principales motivos para que se produzca la excepción NoClassDefFoundError

Por orden de importancia, los principales motivos de la excepción son:

1.- El paquete no está disponible en el Classpath

Esta es quizá la más común de las situaciones y se produce porque la JVM no es capaz de encontrar el paquete correspondiente en el Classpath de Java.

Si falta el archivo .jar o se ha renombrado (por ejemplo, se cambia de miPaquete.jar a miPaquete-v2.jar), la JVM no es capaz de encontrarlo. En estos casos lo más sencillo es simplemente localizar el paquete y copiarlo a donde debería estar (o dejarle el nombre antiguo).

Si tienes dudas sobre dónde está ubicado el Classpath puedes mostrar por pantalla la ruta usando:

 System.getproperty("java.classpath")

Otra opción de emergencia para salir de dudas sobre si estamos yendo al sitio adecuado es lanzar el programa especificando manualmente la ruta desde la que se van a cargar los paquetes locales, usando la opción -classpath (o -cp, abreviada) al ejecutar el programa:

java -cp C:\java\MisClases miPrograma

De este modo estaremos seguros de que, a pesar de estar usando la ruta correcta y tener en ella el paquete apropiado, el programa no es capaz de cargar la clase, así que debemos ver otras posibilidades.

Nota: La opción -cp también puede hacer referencia a archivos .jar directamente, uno o varios nombres separados por comas. Es habitual cuando una aplicación depende de código Java compilado (bibliotecas externas) que el classpath se mantenga apuntando al JRE de Java y luego se agregue con -cp la referencia a los archivos .jar de esas bibliotecas de terceros, que no forman parte del JRE sino que se distribuyen conjuntamente con la aplicación.

2.- Faltan permisos suficientes

Algún problema de permisos puede estar impidiendo que se puedan cargar las clases de un archivo .jar y que se produzca la excepción NoClassDefFoundError.

Debes asegurarte de que el usuario actual tiene permisos suficientes para acceder a los archivos. Esto es especialmente importante en el caso de que algún paquete sea compartido y por lo tanto pueda tener unos permisos establecidos por otro usuario, sin haber creado permisos que aseguren el acceso por parte de todos los usuarios.

3.- Falta alguna dependencia de terceros

Alguna dependencia del programa, por ejemplo una biblioteca nativa, no está disponible en el equipo actual, pero sí lo estaba en el equipo en el que se compiló.

Determina cuál es mirando el log de errores e instálala en el equipo actual.

4.- Falta de visibilidad entre niveles de la jerarquía del ClassLoader

En J2EE, como hemos explicado antes, la falta de visibilidad de la clase entre los diferentes niveles de la jerarquía en el proceso de carga puede provocar esta situación.

Esta es una situación compleja y puede dar bastante trabajo solucionarla, así que en lugar de escribir una larguísima explicación aquí te remito al excelente artículo de Pierre-Hugues Charbonneau en el blog de Java EE Support Partners, que lo explica detalladamente y con un ejemplo real paso a paso.

5.- Un script de inicialización sobrescribe a ClassPath

Una posibilidad menos frecuente, pero que puede darse es cuando un script de inicialización del programa está sobrescribiendo la variable de entorno Classpath, lo cual hace que el resto del programa no pueda encontrar los archivos .jar apropiados.

Prueba con lo comentado en el punto 1 para ver si se está usando la ruta correcta.

6.- Errores en un bloque de inicialización estática

Si el programa utiliza un bloque de inicialización estática (por ejemplo, es típico con clases de tipo Singleton, que no permiten más que una instancia), es posible que no se encuentre alguna referencia que se use desde ahí.

Puedes saberlo si en el archivo de log del error aparece referenciada la clase ExceptionInInitializerError.

Por ejemplo, si en un bloque estático de inicialización se declara una clase de tipo Singleton que se inicializa a sí misma en dicho bloque, y se produce un error, al querer utilizar la clase posteriormente desde el programa se produce un error de tipo NoClassDefFoundError, y en el log aparecerá la mencionada ExceptionInInitializerError.

7.- JDK desconfigurado o mal instalado

Si alguna de las variables ClassPath, JAVA_HOME o PATH está mal establecida debido a algún problema de la instalación de Java, vamos a obtener errores de tipo NoClassDefFoundError, por supuesto. En este caso habría que reinstalar el runtime de Java para solucionarlo.

No están todos los que son pero sí son todos los que están

En este artículo hemos procurado repasar las causas y las soluciones más comunes para este error habitual a la hora de programar en Java. Dependiendo de lo que lo esté causando puede ser muy fácil o muy complicado de arreglar.

Los puntos que hemos comentado son los más comunes, pero existen todavía algunas situaciones más que lo pueden producir, si bien son menos habituales.

Una buena recomendación, no solo para este caso, sería que procures utilizar siempre algún entorno integrado de desarrollo como NetBeans o Eclipse, ya que con sus ayudas integradas minimizan mucho las situaciones difíciles y los posibles errores. Aún así, va a ser inevitable que ocurran cosas como esta de vez en cuando. Si es tu caso, espero que al menos este artículo te ayude y proporcione alguna pista para solucionarlo.

Análisis de la encuesta Stackoverflow 2018

14/05/2018
Artículo original

Stackoverflowsurvey2018

Stack Overflow es, sin duda, la mejor y más potente herramientas de difusión de información de desarrollo en todo el mundo. Junto con Google se ha convertido en un favorito imprescindible para encontrar la solución a, prácticamente, cualquier duda relacionada con código.

Y cada año hacen una mega encuesta entre sus millones de usuarios sobre múltiples aspectos de la industria del desarrollo, en la cual se pueden desprender interesantes y sorprendentes análisis.

El análisis de Stack Overflow

Stackoverflow

Como dice en la portada de los resultados, este 2018 se han ampliado los temas que se preguntan en la encuesta de 30 minutos que han realizado miles y miles de desarrolladores. Y sus conclusiones más importantes son:

  • DevOps y el aprendizaje automático son tendencias importantes en la industria del software actual. Los lenguajes y frameworks asociados con este tipo de trabajos van en aumento, y los desarrolladores que trabajan en estas áreas obtienen los salarios más altos.
  • Solo un pequeño porcentaje de desarrolladores declaran que escribirían código poco ético; o que no tienen la obligación de considerar las implicaciones éticas del código. Pero más allá de eso, los encuestados ven un montón de ética dudosa. Los desarrolladores no están seguros de cómo denuncia los problemas éticos, y tienen diferentes ideas sobre quién es el responsable final de este código.
  • Los desarrolladores son en general optimistas sobre las posibilidades que ofrece la inteligencia artificial, pero no están de acuerdo sobre cuáles son sus peligros.
  • Python ha aumentado en los rangos de lenguajes de programación en nuestra encuesta, superando C # en popularidad este año, al igual que superó a PHP el año pasado.
  • Al evaluar una oferta de trabajo, los diferentes tipos de desarrolladores aplican diferentes conjuntos de prioridades. Las mujeres declaran que sus mayores prioridades son: la cultura de la compañía y las oportunidades para el desarrollo profesional; mientras que los hombres dicen que sus mayores prioridades son la compensación económica y el trabajo con tecnologías específicas.

Poniendo las cosas en contexto

Idea Context

Primero, como en toda opinión o conclusiones de un análisis, dudemos de todo.

Hay cosas que llaman poderosamente la atención, como que el 93.1% de los participantes sean hombres, dejando la presencia de las mujeres en un raquítico 6.7%. Como menos malo podría señalar que las cifras mejoran un poquito (0,5%) en los estudiantes. Pero sin duda hay que empezar a tomarse muy en serio el hacer estudios de las causas de esta inmensa disparidad para tomar, si fuera necesario, las medidas más adecuadas.

Es decir, Stack overflow es un enorme campo de nabos, con casi siete excepciones por cada 100 desarrolladores. Lo que marca un sesgo importante a las conclusiones que se puedan obtener del análisis de los datos.

Luego hay una contradicción bastante llamativa. Los dos países con más profesionales son USA y la India. Si sumamos la norteamericana anglosajona más Europa, no llegamos ni al 50% de los encuestados; de hecho, solo la suma de todos los participantes en Asia supera el 30%. Sin embargo, el 75% de los desarrolladores se declaran blancos o descendientes de europeos, lo cual pudiera ser contradictorio o señalar un sesgo racista en cómo nos vemos a nosotros mismos.

Otra cosa que me ha “escamado”, supongo que será por el perfil de quien contesta a esta encuesta, es que un poco menos de la mitad de los Developers declaran contribuir a proyectos de Código Abierto, lo cual está a años luz de mi contexto en España.

Perfil del desarrollador medio

Developer

Los desarrolladores son jóvenes (de menos de 35 años), que conforman una semblanza de capa media alta; hijos de universitarios, y que a su vez también lo son; tan apasionados de su trabajo que lo consideran también como su hobbie principal; que curran entre 8 y 12 horas; y que no hacen ejercicio físico así les vaya la salud en ello.

Aun siendo universitarios, la autoformación es el modo más normal y generalizado de aprender una vez integrados al mundo laboral. Lo cual sucede de forma inmediata o casi inmediata en cuanto se ponen en el mercado.

Sin duda es un sector con pleno empleo, lo cual atrae a un 40% de intrusismo profesional. Es decir, tener una formación que no tiene nada que ver con programar.

Viendo la experiencia en programación de acuerdo con el tipo de puesto en la empresa, las cifras indican que la mayoría de los encuestados no superan el lustro programando. Pudiéndose inferir que, lo de ir escalando posiciones hacia puestos de gestión o coordinación, es un camino que sigue aplicando en todo el mundo.

Sobre lenguajes y tecnologías

Html5

Imbatible, el front end en general y el javascript en particular, han batido a todos sus competidores (por sexto año consecutivo). Python es quien más crece, desbancando a C# (que parece que está perdiendo fuelle), pero aún lejos de Java – quien lo ha visto y quien lo ve -o de SQL.

Mi sorpresa ha llegado al ver tan retrasado a TypeScript (tenía la sensación de que estaba usándose cada vez más) y más teniendo en cuenta que el 67% de los encuestados lo “amán”.

En la parte de librerías, Node.js sigue siendo el rey, seguido de la lucha entre Angular y React, que está ganando el primero, aunque con el aliento del segundo pegado al cogote. Y otro resultado inesperado llega con la entrada fuerte de .NET Core, ya que tenía la sensación de que se estaba adoptando poco en producción.

Sobre bases de datos cuatro apuntes. La excelente salud de MySQL luego de las dudas que se generaron sobre su futuro, la caída a los abismos de Oracle, el buen hacer de Microsoft con SQL Server que, siendo una BD relacional completa y compleja es la segunda preferida, y el crecimiento imparable de las BD en Cloud.

El gráfico de tecnologías conectadas muestra algo que tenemos que tener muy en cuenta al escoger la plataforma sobre la cual desarrollamos. Solamente la propuesta de Microsoft comprende Front-Back y Cloud bajo un mismo conjunto. Sin duda siguen siendo los listos de la clase que, a la chita callando, se han arrimado a las sombras de todas las tecnologías más utilizadas en la actualidad y las han adoptado en su stack tecnológico.

Como muestra, el surgimiento y reinado de Visual Studio Code, que ha desplazado a Sublime como entorno de desarrollo, de sistemas o DevOps. Vim, todavía aguanta en cabeza en estos dos últimos ámbitos, pero a duras penas. Amazon sigue siendo el rey de la Nube, pero Azure ya le ha comido la mitad del mercado, seguido del siempre presente Google.

Por último, sigue la contradicción entre el sistema operativo de la máquina de desarrollo, en donde se desarrolla y del objetivo de despliegue.

La mitad utilizan Windows, mientras que el 50% restante se lo reparten entre MacOS y Linux (en ese orden). Sin embargo, Linux se pone a la cabeza como plataforma de desarrollo preferida, seguida por un 35% de Windows y un mínimo de 18% sobre Mac OS.

Luego, en producción, statcounter marca que Android es el más utilizado para consumir aplicaciones informáticas, seguido muy de cerca por Windows, dejando a lo lejos a iOS, y Linux que tiene una presencia residual centrada, sobre todo, en servidores.

Tendencias de futuro

Developer Image C

Me ha gustado mucho el enfoque de Stack Overflow para detectar tendencias en el sector, que divide las respuestas en “Amado”, “Temido” y “Deseado”, haciendo una distinción “fuzzy” que muestra inclinaciones y sensaciones personales.

Rust y Kotlin son los lenguajes que más satisfacción dan a sus programadores. Mientras que Python se muestra como el lenguaje con las mejores perspectivas de futuro al ser el tercero en ser más “amado” y el primero en ser “deseado”.

Por el otro lado, el vetusto Visual Basic 6.0, es el más temido/odiado, junto a Cobol y a CoffeScript. Ante los tres me asombra el número de personas que aún desarrollan con ellos, y sin visos de cambiar a corto o medio plazo.

Parece que React puede ganar la competencia frente a Angular en el transcurso del año, ya que le supera tanto en satisfacción como en ganas de ser aprendido.

La Inteligencia Artificial aparece en la lista por medio de TensorFlow, construido en Python (otra vez), que se utiliza para Deep Learning y consigue el mayor nivel de “amor” de sus programadores.

Mercado laboral

Computer Man Code Web Development 650 062317060629

Las cifras nos cuentan que seguimos siendo una industria privilegiada, con pleno empleo y sueldos altos (aunque con grandes variaciones entre los USA y el resto del mundo); contratos indefinidos, pero teniendo la certeza de que no nos jubilaremos en la empresa donde estamos; satisfechos con nuestro trabajo, que es nuestra actividad de ocio principal; y con una alta tasa de emprendimiento, que está llenando el mercado de consultores profesionales liberales.

Y esto no tiene visos de cambiar durante lo que queda de esta década, viendo las enormes dificultades que se tiene en todo el mundo para encontrar y contratar programadores/desarrolladores, tengan talento o no.

Por otro lado, el crecimiento constante del número de lenguajes, librerías, herramientas, frameworks, tecnologías, etc., muestra una pendiente ascendente en el volumen de conocimiento e información necesario para ser un desarrollador productivo; que, además, no está siendo seguido con suficiente rapidez por los sistemas educativos; y que abocan a la autoformación y a la información colaborativa como los medios más validos para mantenerse en la cresta de la ola tecnológica que, cada vez, es más alta y empinada.

¿Tal vez estemos ante una burbuja y algún día explote?

Más información | Stack OverFlow Developer Survey Results 2018

En GenbetaDev | El perfil del desarrollador en España desde la visión de RRHH, De cómo las tripas de Stack Overflow aguantan el éxito, Encuesta Stack Overflow 2016 I, II y III

También te recomendamos

Así serán las smart cities en 2025 de acuerdo a tres estudios, dos directivos y un profesor

De cómo las tripas de Stack Overflow aguantan el éxito

El desarrollo no es país para chicas... según la encuesta anual de Stack Overflow, por lo menos

-
La noticia Análisis de la encuesta Stackoverflow 2018 fue publicada originalmente en Genbeta Dev por Juan Quijano .

Página Anterior Página Siguiente