Google financiará la implantación de Rust en el kernel de Linux, que quedará en manos de un programador español

18/06/2021
Artículo original

Google financiará la implantación de Rust en el kernel de Linux, que quedará en manos de un programador español

Hace ahora un año, Linux Torvalds —creador y responsable del desarrollo del kernel de Linux— afirmaba estar convencido de que, con el tiempo, presenciaría la sustitución de C como principal lenguaje de desarrollo del kernel. "Puede que sea a manos de Rust, o no".

Ahora, un año más tarde, descubrimos que lo más probable es que sí sea Rust. Y es que Google ha anunciado que financiará la implantación de este lenguaje en el kernel de Linux para que un programador pueda trabajar a tiempo completo en este proyecto de reescritura (parcial) de código.

La mayor parte del núcleo de Linux está escrito en C, un lenguaje robusto pero también antiguo (data de 1972)

Oficialmente, su empleador será el Internet Security Group, la misma organización sin ánimo de lucro responsable de gestionar la iniciativa Let's Encrypt que emite certificados SSL gratuitos. Y el programador en cuestión será el español Miguel Ojeda, implicado en la programación del software del Gran Colisionador de Hadrones del CERN.

El objetivo no es reescribir la totalidad del kernel

El pasado mes de abril, Ojeda desgranó en un mensaje a la lista de correo de desarrolladores del kernel las razones por las que había que apostar por introducir Rust, qué objetivo pretendía conseguir y qué aspectos negativos podía conllevar su apuesta. Ante todo, delimitó el alcance del desembarco de Rust:

"[El objetivo del proyecto consiste en] permitir la escritura de controladores y módulos similares en Rust [pero] no pretendemos reescribir el núcleo del núcleo ni los principales subsistemas del núcleo".

Ante todo, Ojeda ve esto como una oportunidad para implementar código más seguro (con un riesgo reducido de errores lógicos y de seguridad en la memoria), y de lograr que más programadores se involucren en el desarrollo del kernel gracias al uso de un lenguaje más moderno.

"Sabemos que existen enormes costos y riesgos al introducir un nuevo lenguaje principal en el kernel. Nos arriesgamos a dividir los esfuerzos y aumentamos el conocimiento necesario para realizar contribuciones a algunas partes del kernel.

Sin embargo, creemos que, incluso hoy, las ventajas de utilizar Rust superan el costo".

En cualquier caso, incluso con el respaldo de Google, aún no está claro que los cambios desarrollados por Ojeda vayan a implementarse finalmente en el kernel oficial: sus propuestas aún deberán recibir el visto bueno del equipo de administradores del mismo, liderados por el propio Torvalds.

Vía | mixx.io

(function() { window._JS_MODULES = window._JS_MODULES || {}; var headElement = document.getElementsByTagName('head')[0]; if (_JS_MODULES.instagram) { var instagramScript = document.createElement('script'); instagramScript.src = 'https://platform.instagram.com/en_US/embeds.js'; instagramScript.async = true; instagramScript.defer = true; headElement.appendChild(instagramScript); } })();

Diseño Web Responsive o Adaptable (Responsive Web Design)

17/06/2021
Artículo original

Ilustración de Kevin Cornell

Traducción del artículo original en inglés Responsive Web Design de Ethan Marcotte.

Nota: Este artículo, que data de 2010, es historia pura del desarrollo web y, en cierta forma, fue el que acuñó el término y dio el pistoletazo de salida al desarrollo web adaptable o responsive. Como curiosidad, aunque se suele tomar como referencia este artículo, su autor comentó en el décimo aniversario de este que ya había usado el término como ponente un mes antes en el primer evento AEA (An Event Apart)

Precauciones: El artículo original data de 2010, así que quédate con el mensaje subyacente. No te preocupes por las limitaciones técnicas que se indican al final, a no ser que tengas que desarrollar para navegadores muy, muy antiguos.

El control que los diseñadores conocen en el medio impreso y desean frecuentemente en el medio web, es simplemente una función de las limitaciones de la página impresa. Debemos aceptar el hecho de que la web no tiene esas mismas limitaciones, y diseñar entonces para su flexibilidad. Pero primero, debemos "aceptar el flujo y reflujo de las cosas".

John Allsopp, "A Dao of Web Design"

El arquitecto inglés Christopher Wren bromeó alguna vez diciendo que su profesión "aspiraba a la Eternidad", y hay algo atractivo en esa fórmula: a diferencia de la web, que siempre parece estar aspirando a la próxima semana en el mejor de los casos, la arquitectura es una disciplina definida por su permanencia.

Los cimientos de un edificio definen su planta, que define su estructura, que da forma a la fachada. Cada fase del proceso arquitectónico es más inmutable, más invariable que la anterior. Las decisiones creativas modelan, literalmente, un espacio físico, definiendo la forma en que la gente se moverá a través de sus límites por décadas o incluso siglos.

Trabajar en la web, sin embargo, es una cuestión completamente diferente. Nuestro trabajo está definido por ser efímero, y es a menudo refinado o reemplazado en el plazo de uno o dos años. Las ventanas de ancho inconsistente, las resoluciones de pantalla, las preferencias de los usuarios y las fuentes instaladas son tan sólo algunos de los intangibles con los que tenemos que lidiar cuando publicamos nuestro trabajo, y, a través de los años, nos hemos vuelto verdaderos expertos en ello.

Pero el panorama está cambiando, quizás más rápido de lo que nos gustaría. Se espera que la navegación móvil supere a la navegación de escritorio dentro de entre tres y cinco años. Dos de las tres consolas de videojuegos dominantes tienen navegadores web (y uno de ellos es realmente excelente). Estamos diseñando para ratones y teclados, para teclados predictivos de móviles, para mandos de videojuegos, para interfaces táctiles. Dentro de poco, nos enfrentaremos con la mayor cantidad de dispositivos, interfaces y navegadores a la que jamás nos hayamos enfrentado.

En los últimos años, me he reunido cada vez con más compañías que solicitan “un sitio para iPhone” como parte de su proyecto. Es una frase interesante: de forma superficial habla por supuesto de la calidad de WebKit como navegador móvil, así como también de un poderoso modelo de negocio que está pensando para ir más allá del escritorio. Pero como diseñadores, creo que a menudo nos acomodamos ante este tipo de requerimientos explícitos, que nos permite compartimentar los problemas que tenemos ante nosotros. Podemos poner en cuarentena a la experiencia móvil en subdominios separados, espacios diferentes y alejados del "sitio no-iPhone". Pero, ¿qué viene después? ¿Un sitio para iPad? ¿Otro para el N90? ¿Realmente podemos comprometernos a soportar cada nuevo agente de usuario con su propia experiencia hecha a medida? Llega un momento en el que esto empieza a parecerse a un juego de suma cero. ¿Pero cómo podemos adaptarnos —y adaptar nuestros diseños—?

Cimientos flexibles

Consideremos este diseño de ejemplo. Aquí he construido una pequeña página para una hipotética revista; es un layout sencillo de dos columnas sobre una rejilla fluida, con no pocas imágenes flexibles salpicadas por aquí y allá. Como firme defensor, desde hace mucho tiempo, de los layouts no-fijos, siempre he pensado que serían más "a prueba de futuro" por tratarse de maquetaciones agnósticas de la distribución. Y hasta cierto punto es cierto: los diseños flexibles no asumen nada acerca del ancho de la ventana del navegador, y se adaptan de forma elegante a los dispositivos que tienen modos verticales y apaisados.

Las imágenes enormes son enormes. Nuestro layout, flexible como es, no responde bien a cambios de resolución o al tamaño de la vista.

Pero ningún diseño fluido ni fijo se escala sin problemas más allá del contexto para el cual fue pensado originalmente. El diseño del ejemplo se escala perfectamente cuando la ventana del navegador cambia su tamaño, pero aparecen puntos de tensión en las resoluciones más bajas. Cuando se observa en un viewport inferior a 800×600, la ilustración que está detrás del logo aparece cortada, el texto de navegación se acomoda de una manera poco natural y las imágenes que están en la parte inferior se hacen demasiado compactas como para ser legibles. Y no sólo se ven afectadas las resoluciones más pequeñas del espectro: cuando se observa el diseño en una pantalla panorámica, las imágenes crecen a tamaños enormes, amontonando el contenido que las rodea.

Resumiendo, nuestro diseño flexible funciona lo suficientemente bien en el contexto de ordenadores de escritorio para el cual fue diseñado, pero no está optimizado para extenderse mucho más allá.

Convirtiéndose en responsive

Recientemente, una disciplina emergente llamada “arquitectura adaptable” ha empezado a preguntarse cómo pueden adaptarse los espacios físicos a la presencia de la gente que está pasando a través de ellos. A través de una combinación de robótica embebida y materiales de tracción, los arquitectos están experimentando con instalaciones de arte y estructuras de paredes que se curvan, se doblan y se expanden cuando la gente se acerca a ellas. Los sensores de movimiento se pueden juntar con sistemas de control del clima para ajustar la temperatura de un cuarto y su luz ambiente a medida que se llena de gente. Las compañías ya han producido “tecnología de vidrios inteligentes” que pueden opacarse automáticamente cuando los ocupantes de un cuarto superan cierto nivel de densidad, dándoles una capa más de privacidad.

En su libro Interactive Architecture, Michael Fox y Miles Kemp describieron este acercamiento adaptativo como "un sistema de múltiples ciclos en el que uno entra en una conversación; un intercambio de información continuo y constructivo." El énfasis es mío, ya que pienso que es una sutil pero poderosa distinción: en vez de crear espacios inmutables e invariables que definen una experiencia particular, sugieren que los habitantes y la estructura pueden —y deben— influirse mutuamente.

Este es el camino a seguir. En lugar de hacer diseños a medida y desconectados para cada uno de los dispositivos web, siempre en crecimiento, podemos tratarlos como distintas caras de una misma experiencia. Podemos diseñar para una experiencia de visualización óptima, pero incrustar tecnologías basadas en estándares dentro de nuestros diseños para hacerlos no sólo más flexibles, sino más adaptables al medio que los renderiza. Resumiendo, necesitamos practicar un diseño web adaptable.(responsive web design, en el original, término que permaneció - N.delT.) ¿Pero cómo?

Presentando a la media query

Desde los días de CSS 2.1, nuestras hojas de estilos han disfrutado de algo así como "ser consciente del dispositivo" a través de los media types. Si alguna vez has escrito una hoja de estilos para impresión, ya tiene familiaridad con el concepto:

<link rel="stylesheet" type="text/css" href="core.css" media="screen" /> 
<link rel="stylesheet" type="text/css" href="print.css" media="print" />

Esperando que estuviéramos diseñando algo más que bellos formatos de páginas para imprimir, la especificación CSS nos suministró un grupo de media types aceptados, cada uno de ellos diseñado para apuntar a un tipo específico de dispositivo apto para la web. Pero la mayoría de los navegadores y los dispositivos nunca se han adherido al espíritu de la especificación, dejando varios media types mal implementados, cuando no, directamente, se hace caso omiso de ellos.

Por suerte, el W3C creó las media queries como parte de la especificación CSS3, mejorando la promesa de los media types. Una media query nos permite apuntar no sólo a ciertas clases de dispositivos, sino realmente inspeccionar las características físicas del dispositivo que está renderizando nuestro trabajo. Por ejemplo, a partir del reciente crecimiento de WebKit mobile, las media queries se han convertido en una popular técnica del lado del cliente para entregar una hoja de estilos a medida para el iPhone, los teléfonos con Android y sus semejantes. Para hacerlo, podemos incorporar una query dentro del atributo media de una hoja de estilos externa:

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="shetland.css" />

La query contiene dos componentes:

  1. un media type (screen), y
  2. la consulta entre paréntesis, conteniendo una característica a evaluar (max-device-width) seguida por el valor al que apuntamos (480px).

En otras palabras, le estamos preguntando al dispositivo si su resolución horizontal (max-device-width) es igual o menor que 480px. En caso afirmativo —en otras palabras, si estamos viendo nuestro trabajo en un dispositivo con una pantalla pequeña como el iPhone— entonces el dispositivo cargará shetland.css. De lo contrario, se hace caso omiso del link.

En el pasado, los diseñadores han experimentado con layouts atados a la resolución, dependiendo generalmente de soluciones en JS como el excelente script de Cameron Adams. Pero la especificación de media query provee una serie de características del medio que van mucho más allá de la resolución de la pantalla, ampliando el alcance de lo que podemos verificar con nuestras queries. Y lo que es mejor, puedes verificar múltiples valores de las propiedades en una sola query, encadenándolos con la palabra clave and:

<link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px) and (resolution: 163dpi)" href="shetland.css" />

Además, no estamos limitados a incorporar las media queries con la etiqueta link. Podemos incluirlas en nuestro CSS como parte de una regla @media:

@media screen and (max-device-width: 480px) {
  .column {
    float: none;
  }
}

O como parte de una directiva @import:

@import url("shetland.css") screen and (max-device-width: 480px);

Y en cada caso, el efecto es el mismo: si el dispositivo cumple la condición planteada por nuestra media query, el CSS que corresponda se aplica en nuestro código. Las media queries son, en resumen, comentarios condicionales para todos. En lugar de segmentar para una versión específica de un navegador concreto, podemos corregir quirúrgicamente problemas en nuestro layout cuando se escala fuera de su resolución inicial e ideal.

Adaptarse, responder e ir más allá

Llevemos nuestra atención a las imágenes en la base de nuestra página. En su layout por defecto, el CSS está así:

.figure {
  float: left;
  margin: 0 3.317535545023696682% 1.5em 0;   /* 21px / 633px */
  width: 31.121642969984202211%;             /* 197px / 633px */
}

li#f-mycroft,
li#f-winter {
  margin-right: 0;
}

He omitido algunas propiedades tipográficas para enfocarnos en la estructura principal de la maquetación: cada elemento .figure tiene un tamaño de aproximadamente un tercio de la columna que lo contiene, con el margen derecho en cero para las dos imágenes al final de cada fila (li#f-mycroft, li#f-winter). Y esto funciona bastante bien, hasta que la vista es o notablemente más pequeña o más ancha que nuestro diseño original. Con las media queries, podemos aplicar correciones puntuales para una determinada resolución, adaptando nuestro diseño para responder mejor a los cambios en la pantalla.

En primer lugar, ajustaremos nuestra página cuando el viewport cae por debajo de cierta resolución, digamos, 600px. Así que, al final de nuestra hoja de estilos crearemos un nuevo bloque @media, de la siguiente manera:

@media screen and (max-width: 600px) {
  .mast,
  .intro,
  .main,
  .footer {
    float: none;
    width: auto;
  }
}

Si observas nuestra página actualizada en un navegador moderno y reduces el tamaño de tu ventana por debajo de los 600px, la media query desactivará los floats de los principales elementos del diseño, apilando cada bloque encima del otro según el flujo del documento. Entonces nuestro diseño miniaturizado empieza a tener buen aspecto, pero las imágenes todavía no se reducen tan inteligentemente. Si introducimos otra media query, podemos alterar su layout de manera congruente:

@media screen and (max-width: 400px) {

  .figure, li#f-mycroft {
    margin-right: 3.317535545023696682%;    /* 21px / 633px */
    width: 48.341232227488151658%;          /* 306px / 633px */
  }

  li#f-watson, li#f-moriarty {
	margin-right: 0;
  }
  
}

No te fijes demasiado en los porcentajes ilegibles; simplemente estamos recalculando los anchos de la rejilla fluida para tener en cuenta el nuevo layout. En otras palabras, estamos moviéndonos de un layout de tres columnas a uno de dos columnas cuando el ancho de la vista cae por debajo de los 400px, haciendo más prominentes a las imágenes.

Nuestras figuras pueden cambiar su estructura de manera responsive para adaptarse mejor a pantallas más pequeñas.

Podemos utilizar el mismo enfoque para las pantallas panorámicas. Para resoluciones más grandes, podemos adoptar un tratamiento de seis columnas para nuestras imágenes, situándolas todas en la misma fila:

@media screen and (min-width: 1300px) {

  .figure, li#f-mycroft {
    margin-right: 3.317535545023696682%;    /* 21px / 633px */
    width: 13.902053712480252764%;          /* 88px / 633px */
  }
  
}

Ahora nuestras imágenes están trabajando perfectamente en los dos extremos del espectro de resoluciones, optimizando su distribución según los cambios en el ancho de las ventanas y en las resoluciones de los dispositivos.

Especificando un min-width más ancho en una nueva media query, podemos mover a nuestras imágenes a un layout de una sola fila.

Pero esto es sólo el comienzo. Trabajando dentro de las media queries que incrustamos en nuestro CSS, podemos alterar mucho más que la manera de colocar de unas pocas imágenes: podemos introducir nuevos layouts alternativos ajustados para cada rango de resolución, quizás haciendo la barra de navegación más prominente en una vista de pantalla ancha, o reposicionándola encima del logo en pantallas más pequeñas.

Diseñando de forma responsive, no sólo podemos adaptar nuestro contenido en los dispositivos más pequeños, sino también optimizar su presentación a lo largo de un amplio rango de pantallas.

Pero un diseño responsive no está limitado a cambios en la distribución de elementos. Las media queries nos permiten practicar ajustes increíblemente precisos cuando nuestras páginas cambian de forma: podemos aumentar el área clicable de nuestros enlaces para pantallas más pequeñas, para cumplir mejor con la Ley de Fitts en los dispositivos táctiles; mostrar o esconder elementos de manera selectiva que pueden mejorar la navegación de una página; podemos incluso practicar una tipografía responsive que gradualmente altere el tamaño y espaciado de nuestro texto, optimizando la experiencia de lectura para la pantalla correspondiente.

Algunas notas técnicas

Debe mencionarse que las media queries disfrutan de un soporte increíblemente robusto entre los navegadores modernos. Todos los navegadores de escritorio como Safari 3+, Chrome, Firefox 3.5+ y Opera 7+ interpretan de forma nativa las media queries, como también lo hacen navegadores móviles más recientes como Opera Mobile y WebKit mobile. Por supuesto, las versiones más viejas de esos navegadores de escritorio no soportan media queries. Y aunque Microsoft se ha comprometido a dar soporte a las media queries en IE9, Internet Explorer actualmente no ofrece una implementación nativa.

Sin embargo, si estás interesado en implementar compatibilidad con los navegadores más viejos, hay ciertas alternativas basadas en JavaScript:

  • Un plugin de jQuery de 2007 ofrece un soporte limitado de las media queries, implementando sólo las propiedades min-width y max-width cuando se adjuntan a elementos link separados.
  • Recientemente se lanzó css3-mediaqueries.js , una biblioteca que promete "lograr que IE 5+, Firefox 1+ y Safari 2 analicen, testeen y apliquen las Media Queries de CSS3" cuando se incluyen mediante bloques @media. Aunque está en versión 1.0, me parece bastante robusto y pienso seguir su desarrollo.

Aunque es perfectamente entendible que no te atraiga usar JavaScript. Sin embargo, eso dotará de robustez a tu estructura en caso de que quieras construirla basándote en una rejilla flexible, asegurándo de que tu diseño disfruta cierta flexibilidad en los dispositivos y navegadores que no ven las media queries.

El camino a seguir

Las retículas fluidas, las imágenes flexibles y las media queries son los tres ingredientes técnicos para un diseño web responsive, pero también se requiere de una manera diferente de pensar. En lugar de poner en cuarentena nuestro contenido en experiencias diferenciadas, específicas para cada dispositivo, podemos usar las media queries para realzar progresivamente nuestro trabajo en los diferentes contextos de visualización. Eso no significa que no haya casos de negocio en los que sea preferible realizar sitios separados para dispositivos específicos; por ejemplo, si los objetivos del usuario para tu sitio móvil tienen un alcance limitado respecto al equivalente de escritorio, entonces servir contenido diferente para cada uno puede ser el mejor enfoque.

Pero ese tipo de pensamiento del diseño no tiene por qué ser la forma de pensar predeterminada. Ahora, más que nunca, estamos diseñando trabajos destinados a ser visualizados en una gran gama de experiencias diferentes. El diseño web responsive nos ofrece un camino a seguir, permitiéndonos finalmente "diseñar para el flujo y reflujo de las cosas".

Siete días en el Picandoverso: Arriba de una montaña

16/06/2021
Artículo original

Entre los destaques a nivel personal de los últimos siete días, el sábado pasado escalé dos munros más de Escocia. Con un amigo nos tomamos un tren a las 7 de la mañana hasta Glasgow y después Bridge of Orchy. De la estación de tren caminamos y escalamos ambas Beinn Dòrain (1076m) y Beinn an Dòthaidh (1004m). Hay 282 munros en Escocia y con estas dos llevo 5 en total, me quedan 277 por escalar. La aventura estuvo genial, tuvimos un clima relativamente bueno hasta que llegamos a ambas cimas donde la vista estaba completamente cubierta por las nubes. Pero […]

El post Siete días en el Picandoverso: Arriba de una montaña fue publicado originalmente en Picando Código.

Repaso de Nintendo en el E3 2021

15/06/2021
Artículo original

Terminó el E3 de este año, y por mi parte quedé conforme con las noticias de Nintendo. En el pasado 7 días en el Picandoverso comentaba algunas predicciones que me resultaban relativamente seguras, y con algunas acerté: algún luchador de Smash Bros., algún adelanto más de Splatoon 3 o la secuela a The Legend Of Zelda: Breath Of The Wild. Sería sorpresa ver algo de Metroid Prime 4 (o la trilogía Prime que tanto se viene rumoreando para Switch), o que revivan alguna de las propiedades intelectuales que llevan tiempo descansando como Star Fox o F-Zero. La mejor sorpresa sería […]

El post Repaso de Nintendo en el E3 2021 fue publicado originalmente en Picando Código.

Mini pique: Ruby – Usar las notificaciones del sistema para notificarnos de tareas

14/06/2021
Artículo original

Esto es más bien una idea que se me ocurrió trabajando, pero me pareció buena compartirla como mini pique. Por lo menos para no olvidarme en el futuro que esto es una posibilidad, al escribir un post al respecto me queda más grabado en la memoria. La gema libnotify nos permite interactuar con la biblioteca libnotify de nuestro sistema y generar notificaciones de manera muy sencilla. Este código: > require 'libnotify' > Libnotify.show( body: "Hola Mundo", summary: "Picando Código informa", icon_path: "/usr/share/icons/Humanity/apps/32/terminal.svg" ) Genera esta notificación: Además de las posibilidades de uso en cualquier app Ruby, podemos aprovecharla cuando queremos […]

El post Mini pique: Ruby – Usar las notificaciones del sistema para notificarnos de tareas fue publicado originalmente en Picando Código.

Perfiles para tu Webcam: ajustar y guardar sus parámetros en cualquier condición de luz en Windows

14/06/2021
Artículo original

El icono de camPropsLas webcams, por caras que sean, no dejan de ser cámaras sencillas con muy pocas posibilidades de conseguir una gran calidad de imagen. Sin embargo, si te gastas unos eurillos (al menos 80 o 100) puedes tener una calidad razonablemente buena en la mayoría de las circunstancias.

Un grave problema que tienen es que, salvo que estés en una habitación a oscuras con iluminación artificial, es muy difícil que con los ajustes predeterminados te den la mejor imagen siempre. Para lograr mejorar la imagen, todas permiten de una manera u otra ajustar el brillo, contraste, saturación, etc... y así adaptarte a las condiciones de luz que tengas en cada momento (por cierto, los programas propios de la marca suelen ser todos nefastos, complicados, y ocupan mucho espacio en disco: no merece la pena instalarlos).

El mayor problema de hacer estos ajustes es que, lo que te sirvió por la mañana, hace que a la tarde se vea la imagen quemada y tú más blanco que la leche o al revés. Y los ajustes que te valen para un día de lluvia no tienen nada que ver con los de un día soleado, por ejemplo. Y ajustar estos parámetros de cada vez es un dolor: se tarda y no ha manera de acordarse cuáles eran los mejores para cada caso. Encima, cada dos por tres, o si reinicias el equipo, se resetean y quedan los valores de fábrica.

Hoy te voy a hablar de un software para Windows que te permite ajustar los parámetros de cualquier cámara web y guardar diferentes perfiles para poder reutilizarlos cuando los necesites con un solo clic. A mi me ha sido de gran utilidad durante la pandemia de COVID-19 y las muchas reuniones online.

Se trata de CamProps, del programador alemán Roland Weigelt. Está creado con .NET Core.

Es un software muy sencillo de utilizar que te permite definir distintos perfiles, ajustar la cámara para ellos y guardarlos para ser reutilizados.

El programa lo descargas desde la página de CamProps y viene dentro de un ZIP (pesa unos 57 MB). Dentro hay unos HTMLs y un archivo .msi que es el programa de instalación. Ejecuta el archivo CamPropsSetup.msi y dale a Siguiente hasta que esté instalado. Muy simple.

Ahora la idea es la siguiente: deberás crear un perfil diferente de ajustes de la webcam para cada una de las diferentes condiciones de luz que tengas en tu espacio de trabajo.

No las puedes hacer todas a la vez, sino que a medida que vayan cambiando, vas creando una nueva y la vas guardando.

El proceso es el siguiente y tendrás que hacerlo cada vez que cambien las condiciones de luz, para ir acumulando perfiles:

1.- Abre la cámara de Windows o una aplicación que muestre la imagen de tu webcam (por ejemplo OBS Studio o Skype). Lo necesitarás para poder ir viendo cómo afectan los ajustes, ya que con el diálogo de ajustes solamente no podrás ver su efecto.

2.- Arranca CamProps y dale al botón con un + de la parte de abajo para crear un nuevo perfil, dándole un nombre apropiado para reconocerlo luego:

Diálogo que te pide un nombre

Eso lo meterá en la lista de perfiles, pero no hará nada más de momento.

3.- Pulsa en el icono de los diales, al lado del perfil, para lanzar el diálogo de configuración nativo de Windows para la cámara:

Botón de editar perfil

Nota: Yo lo primero que hago, antes de nada, es crear un perfil con los valores por defecto de la cámara, para poder resetearla si meto la pata (es el segundo que ves en la captura anterior). Hazlo y luego empieza a crear tus perfiles cada vez que cambien las condiciones de luz.

El diálogo de configuración de Windows es my espartano, pero a través de sus dos pestañas te permite configurar todos los parámetros de tu webcam:

Pestaña de propiedades de luz de la Webcam

Pestaña de propiedades de control de la Webcam

4.- Toca los diferentes parámetros como mejor te parezca, y observa en tiempo real cómo afectan a la imagen que se ve en la cámara que abriste en el primer paso.

Te recomiendo, en general, que quites los automáticos y los ajustes manualmente para obtener el mejor resultado. En especial el de compensación de poca luz y el de balance de blancos, que suelen hacer más daño que ayuda.

Cuando des con el punto en el que la imagen te convenza, simplemente pulsa el botón de OK abajo. El diálogo se cierra y quedan guardados los ajustes. ¡Yuhuuu!

---

A medida que vayas creando más perfiles podrás reutilizarlos con tan solo pulsar sobre ellos en el programa. ¡Un clic y listo!

Puedes reorganizarlos o eliminarlos pulsando en el botón de 3 puntos a la derecha de cada uno:

Menú contextual para ordenar cada perfil

Y si tienes mas de una cámara web pinchada a tu equipo, puedes desplegar la parte superior para cambiar de una a otra y crear perfiles específicos para ella.

Además, podrás guardar a disco una copia de seguridad de los ajustes de cada webcam de modo que si reinstalas Windows los puedas recuperar sin tener que pasar el trabajo de nuevo:

Menú para hacer copia de seguridad y restaurar los perfiles

Una aplicación simple, gratuita y de gran utilidad.

¡Espero que te resulte útil!

Google Cloud Industries revela que la COVID ha acelerado la implementación de la Inteligencia artificial en la industria

14/06/2021
Artículo original

Imagen abstracta sobre IA por Joshua Sortino: https://unsplash.com/photos/LqKhnDzSF-8

A finales de 2020 Google Cloud realizó una encuesta entre más de 1.100 altos ejecutivos pertenecientes a empresas de producción de más de 500 empleados en 7 países (Alemania, Corea del Sur, Estados Unidos, Francia Japón y Reino Unido) y ahora acaba de publicar los resultados.

El informe de Google Cloud Industries titulado "Artificial Intelligence acceleration among manufacturers" revela que la pandemia de COVID-19 puede haber provocado un aumento significativo en el uso de la inteligencia artificial entre las empresas de fabricación, así como la implantanción de otros habilitadores digitales.

El 76% de los fabricantes ha recurrido a habilitadores digitales y tecnologías disruptivas debido a la pandemia.

En el enlace anterior puedes descargar el informe en inglés, al final del mismo encontrarás unas tablas con las preguntas realizadas y los resultados, pero te ofrecemos los resultados más interesantes.

¿Quiénes (sectores), dónde (procesos) y por qué se usa cada vez más IA en la industria?

El 66% de los fabricantes que utilizan IA en sus operaciones diarias afirman que su dependencia de la IA está aumentando y un 25% ya destina la mitad o más de su gasto total en TI a la IA.

¿Quién?

Las tres principales industrias que implementan IA en la actualidad son:

  • La automoción / OEM (76%)
  • Los proveedores de automoción (68%) y
  • Los fabricantes de maquinaria pesada (67%).

El uso de IA está aumentando rápidamente en los siguientes sectores:

  • Metales (75%),
  • Ensamblaje industrial (72%) y
  • Maquinaria pesada (69%).

¿Dónde?

Las cinco áreas principales donde se implementa la IA incluyen:

  • Inspecciones de calidad (39%): por ejemplo, si se usa IA para la inspección visual de los productos terminados, los trabajadores de la línea de producción pueden invertir el tiempo que antes dedicaban a hacer inspecciones repetitivas de productos, a llevar a cabo tareas más complejas.
  • Gestión de la cadena de suministro (36%): en campusMVP hemos dedicado un artículo completo al uso de la IA en la cadena de suministro.
  • Gestión de riesgos (36%)
  • Controles de calidad de productos y / o líneas de producción (35%), y
  • Gestión de inventarios (34%)

Aunque no debemos olvidar que la IA también se aplica a muchos otros casos de uso, desde alimentar fábricas conectadas hasta ayudar con el mantenimiento predictivo, tal y como indica el informe. Los modelos personalizados de aprendizaje automático pueden predecir eventos de la máquina que, si no se controlan, podrían causar tiempos de inactividad no programados e impactar negativamente en los programas de producción. La inteligencia artificial puede ayudar a reducir los errores críticos que conducen a retrasos, al tiempo que optimizan el consumo de energía y respaldan la logística y la programación de tareas complejas.

¿Por qué?

La investigación realizada por Google muestra que las empresas que actualmente utilizan la inteligencia artificial en las operaciones diarias buscan principalmente:

  • Asistencia con la continuidad del negocio (38%),
  • ayudar a que los empleados sean más eficientes (38%) y
  • en general, que sean útiles para los empleados (34%).

Barreras para el uso de IA

La barrera más común señalada en este informe es la falta de personal cualificado. Parece que el paso del tiempo no ha subsanado este obstáculo ya señalado en un estudio anterior realizado por la comisión europea que ya analizamos aquí.

Otros obstáculos son:

  • Carecer de la infraestructura tecnológica adecuada para implantar IA
  • Coste de implementación
  • La IA no es una tecnología probada
  • No contar con apoyo para implementar la tecnología

Qué son la programación 'low-code' y la 'no-code', qué se diferencian y cómo están democratizando la creación de aplicaciones

13/06/2021
Artículo original

Qué son la programación 'low-code' y la 'no-code', qué se diferencian y cómo están democratizando la creación de aplicaciones

Según la consultora IDC, de aquí a 2023 se desarrollarán e implementarán más de 500 millones de aplicaciones, tantas como en los 40 años previos. Dado que el número de desarrolladores no ha experimentado un crecimiento similar ni por asomo, responder a esta creciente demanda pasa inevitablemente por dar las herramientas a usuarios menos avanzados para que sean capaces de crear sus propias aplicaciones.

Eso, claro, exige minimizar la importancia de la codificación a la hora de desarrollarlas. Y ahí es donde entran dos conceptos en auge en los últimos años y que, según un reciente informe de Research and Markets, dentro de 9 años podrían estar generando unos ingresos de 187.000 millones de dólares, frente a los 10.900 millones que generaban en 2019…

Dichos conceptos son 'no-code' y 'low-code', y nos los encontraremos mencionadas de forma conjunta en múltiples fuentes porque, sencillamente, no siempre está clara la frontera entre ambos.

"La programación no va de escribir, sino de pensar" (Chris Wanstrath, CEO de GitHub)

Tanto las soluciones low-code como las no-code ofrecen todo lo necesario para crear una aplicación de manera rápida y relativamente sencilla, normalmente contando con un entorno de desarrollo de naturaleza fundamentalmente visual (por ejemplo, mediante sistemas de arrastrar y soltar bloques, como en los sistemas de aprendizaje de programación para los más pequeños).

Sin embargo, existen diferencias entre las mismas.

  • Low-Code: Requiere de ciertos conocimientos previos de programación 'tradicional'. Como su nombre indica ('bajo código' en español), siguen requiriendo codificación, si bien esta es ocasional y/o con una sintaxis muy sencilla. La pretensión de este enfoque radica en acelerar el desarrollo y el despligue de cada aplicación permitiendo que los programadores centren sus esfuerzos en ese 10% de la misma que la hace diferente de otras similares, y que es la porción de la misma que le aporta valor al cliente.

  • No-Code: Por el contrario, la programación no-code está pensada para su uso por parte de usuarios empresariales o por los llamados 'desarrolladores ciudadanos'; esto es, por personas que no conocen (ni necesitan conocer) ningún lenguaje de programación 'tradicional' para poder desarrollar una herramienta.

Un ejemplo y algunos inconvenientes

Un ejemplo de esta clase de herramientas lo constituye la plataforma Power Apps, de Microsoft, que recientemente ha anunciado la integración de inteligencia artificial en la misma para poder 'codificar' dando instrucciones en lenguaje natural que posteriormente son traducidas a código de programación por la plataforma. Así, instrucciones como

"encuentra productos cuyo nombre incluya 'para niños'"

se convierten en

"Filter ('BC Orders' Left ('Product Name', 4) ="para niños")"

en su lenguaje propio Power Fx, que ya de por sí constituye un ejemplo de programación simplificada dirigida a usuarios empresariales.

La mayoría de estas soluciones se centran en crear aplicaciones con fines y funcionamiento muy concreto, con poco margen para la personalización y, sobre todo, para la optimización. Además, tanto low-code como no-code sufren de otra desventaja: los potenciales problemas de seguridad derivados del hecho de que las empresas que implementan una aplicación desconozcan 'las tripas'.

Un cambio no tan revolucionario

Y la misma existencia de estas 'tripas' también son un recordatorio de que low-code y no-code no han desembarcado en el mercado para expulsar del mismo a los programadores tradicionales: estos seguirán siendo necesarios para programar las herramientas que permiten crear aplicaciones a los 'programadores ciudadanos'.

Por otro lado, si lo pensamos bien, hace ya décadas que las herramientas no-code y low-code tienen un papel preponderante en nuestro día a día como usuarios informáticos, sólo que no las hemos llamado así hasta ahora porque no competían con los lenguajes de programación, sino con los de marcado.

Html Low Code Lo que Power Apps es a las aplicaciones corporativas, los CMS lo llevan siendo desde hace años para las webs: todo va de hacer accesible la tecnología a quien no sabe programar.

Así, sin ir más lejos, los gestores de contenidos web como Wordpress, Drupal, Blospot o Wix serían —según el caso— herramientas de low-code o no-code con respecto a la tradicional programación web (HTML+CSS+Javascript+PHP): un ejemplo de 'democratización' en la creación de 'aplicaciones web', ahora al alcance de los no-programadores.

Y, por otro lado, ¿qué son —sino soluciones no-code— los procesadores de texto WYSIWYG con respecto a tecnologías como LaTeX/PostScript, aún vigentes pero relegadas a su uso por usuarios expertos, a la hora de crear documentos dotados de maquetación y elementos gráficos?

(function() { window._JS_MODULES = window._JS_MODULES || {}; var headElement = document.getElementsByTagName('head')[0]; if (_JS_MODULES.instagram) { var instagramScript = document.createElement('script'); instagramScript.src = 'https://platform.instagram.com/en_US/embeds.js'; instagramScript.async = true; instagramScript.defer = true; headElement.appendChild(instagramScript); } })();

Noticias de programación campusMVP #23: 2ª semana de junio 2021 - Especial Apple Developers Conference WWDC21

12/06/2021
Artículo original

[youtube:wzv91ccjfvo]

Enlaces mencionados en el vídeo:

 

Apple WWDC 2021

Otros

Perfiles tu Webcam: ajustar y guardar sus parámetros en cualquier condición de luz en Windows

11/06/2021
Artículo original

El icono de camPropsLas webcams, por caras que sean, no dejan de ser cámaras sencillas con muy pocas posibilidades de conseguir una gran calidad de imagen. Sin embargo, si te gastas unos eurillos (al menos 80 o 100) puedes tener una calidad razonablemente buena en la mayoría de las circunstancias.

Un grave problema que tienen es que, salvo que estés en una habitación a oscuras con iluminación artificial, es muy difícil que con los ajustes predeterminados te den la mejor imagen siempre. Para lograr mejorar la imagen, todas permiten de una manera u otra ajustar el brillo, contraste, saturación, etc... y así adaptarte a las condiciones de luz que tengas en cada momento (por cierto, los programas propios de la marca suelen ser todos nefastos, complicados, y ocupan mucho espacio en disco: no merece la pena instalarlos).

El mayor problema de hacer estos ajustes es que, lo que te sirvió por la mañana, hace que a la tarde se vea la imagen quemada y tú más blanco que la leche o al revés. Y los ajustes que te valen para un día de lluvia no tienen nada que ver con los de un día soleado, por ejemplo. Y ajustar estos parámetros de cada vez es un dolor: se tarda y no ha manera de acordarse cuáles eran los mejores para cada caso. Encima, cada dos por tres, o si reinicias el equipo, se resetean y quedan los valores de fábrica.

Hoy te voy a hablar de un software para Windows que te permite ajustar los parámetros de cualquier cámara web y guardar diferentes perfiles para poder reutilizarlos cuando los necesites con un solo clic. A mi me ha sido de gran utilidad durante la pandemia de COVID-19 y las muchas reuniones online.

Se trata de CamProps, del programador alemán Roland Weigelt. Está creado con .NET Core.

Es un software muy sencillo de utilizar que te permite definir distintos perfiles, ajustar la cámara para ellos y guardarlos para ser reutilizados.

El programa lo descargas desde la página de CamProps y viene dentro de un ZIP (pesa unos 57 MB). Dentro hay unos HTMLs y un archivo .msi que es el programa de instalación. Ejecuta el archivo CamPropsSetup.msi y dale a Siguiente hasta que esté instalado. Muy simple.

Ahora la idea es la siguiente: deberás crear un perfil diferente de ajustes de la webcam para cada una de las diferentes condiciones de luz que tengas en tu espacio de trabajo.

No las puedes hacer todas a la vez, sino que a medida que vayan cambiando, vas creando una nueva y la vas guardando.

El proceso es el siguiente y tendrás que hacerlo cada vez que cambien las condiciones de luz, para ir acumulando perfiles:

1.- Abre la cámara de Windows o una aplicación que muestre la imagen de tu webcam (por ejemplo OBS Studio o Skype). Lo necesitarás para poder ir viendo cómo afectan los ajustes, ya que con el diálogo de ajustes solamente no podrás ver su efecto.

2.- Arranca CamProps y dale al botón con un + de la parte de abajo para crear un nuevo perfil, dándole un nombre apropiado para reconocerlo luego:

Diálogo que te pide un nombre

Eso lo meterá en la lista de perfiles, pero no hará nada más de momento.

3.- Pulsa en el icono de los diales, al lado del perfil, para lanzar el diálogo de configuración nativo de Windows para la cámara:

Botón de editar perfil

Nota: Yo lo primero que hago, antes de nada, es crear un perfil con los valores por defecto de la cámara, para poder resetearla si meto la pata (es el segundo que ves en la captura anterior). Hazlo y luego empieza a crear tus perfiles cada vez que cambien las condiciones de luz.

El diálogo de configuración de Windows es my espartano, pero a través de sus dos pestañas te permite configurar todos los parámetros de tu webcam:

Pestaña de propiedades de luz de la Webcam

Pestaña de propiedades de control de la Webcam

4.- Toca los diferentes parámetros como mejor te parezca, y observa en tiempo real cómo afectan a la imagen que se ve en la cámara que abriste en el primer paso.

Te recomiendo, en general, que quites los automáticos y los ajustes manualmente para obtener el mejor resultado. En especial el de compensación de poca luz y el de balance de blancos, que suelen hacer más daño que ayuda.

Cuando des con el punto en el que la imagen te convenza, simplemente pulsa el botón de OK abajo. El diálogo se cierra y quedan guardados los ajustes. ¡Yuhuuu!

---

A medida que vayas creando más perfiles podrás reutilizarlos con tan solo pulsar sobre ellos en el programa. ¡Un clic y listo!

Puedes reorganizarlos o eliminarlos pulsando en el botón de 3 puntos a la derecha de cada uno:

Menú contextual para ordenar cada perfil

Y si tienes mas de una cámara web pinchada a tu equipo, puedes desplegar la parte superior para cambiar de una a otra y crear perfiles específicos para ella.

Además, podrás guardar a disco una copia de seguridad de los ajustes de cada webcam de modo que si reinstalas Windows los puedas recuperar sin tener que pasar el trabajo de nuevo:

Menú para hacer copia de seguridad y restaurar los perfiles

Una aplicación simple, gratuita y de gran utilidad.

¡Espero que te resulte útil!

Página Siguiente