Ahora hablaremos sobre las tarjetas en las que marcamos el trabajo pendiente y volcamos muchísima información útil. En Azure DevOps son los work items, y en GitHub… simplemente issues.

Esto es una serie de posts que pretende exponer y comparar poco a poco las features de las dos plataformas. Si hay conclusiones, serán al final de la misma serie, y no dejarán de ser una opinión personal. Si hay errores, no dudes en hacérmelo saber en la sección de comentarios para corregir lo antes posible. Para saber si te conviene o no, habrá que recurrir al infalible método de ‘ensayo y error’. ¡Prueba y descubre!

Estamos a punto de sumergirnos en, y esta es mi opinión, uno de los puntos más débiles de GitHub frente a Azure DevOps, en la comparación.

En Azure DevOps, tenemos diferentes procesos de trabajo a elegir, a elegir dependiendo de nuestras necesidades o metodología de trabajo… y eso influye en cómo funcionará la jerarquía de work items.

Por ejemplo, si escogemos el proceso SCRUM:

Dependiendo del proceso elegido, tenemos diferentes tipos de work items (tasks, bugs, PBI, user stories, features, epics…) dispuestas en diferentes jerarquías, para mejor organización y navegación. Podemos usar estas ventajas o no, eso depende de nuestra cultura de trabajo.

También los work items son altamente customizables, pudiendo añadir nuevos fields en los work items o crear automatismos para ciertas circunstancias.

¿Sabías que también puedes crear tu propio proceso custom? Es decir, si por ejemplo quieres usar agile pero con tus propios retoques… puedes hacerlo, heredando de un proceso ya existente y adaptándolo a las necesidades de tu equipo o empresa.

¿Y en GitHub?

Si nos mudamos a GitHub… ¿podemos mantener esta jerarquía? La respuesta es clara: no. Al menos todavía.

GitHub, en materia de recoger elementos de trabajo, work items, tareas… solo entiende de Issues, que estarán dentro de un Project. Un project puede estar asociado a tu user, a una organización o a un repositorio específico.

Los issues son tarjetas planas, que tienen un título, una descripción… y son asociables a pull requests, para llevar una traza del trabajo realizado en relación a ese elemento.

Los projects sí tiene diferentes layouts a la hora de disponer los diferentes elementos, tres para elegir: .

Pero luego tenemos las templates, que ya juegan con diferentes representaciones visuales… e incluso filtran lo que entra o no dentro de cada proyecto, de cada tablero:

Por ejemplo, la existencia de Feature release como template, nos indica que podríamos tener un tablero por cada feature a liberar dentro de un proyecto. Es organizado, pero también conlleva más trabajo de mantenimiento de cada tablero.

Ahí está la dificultad de todo esto, después de todo. Elegir bien la estrategia a implementar, porque cambiamos el paradigma. El peso está en los boards, en los projects, más que en los elementos individuales, issues en GitHub o work items en Azure DevOps.

Sin renunciar a Azure DevOps

No sé cuál es mejor opción, pero sí se que puedes tener cosas muy buenas de los mundos.

En caso de que necesites tener todo tu código, equipo en GitHub… y mantener los work items en Azure DevOps, ¡también puedes!

Es posible conectar commits, pull requests, branches e incluso issues a Azure Boards, pudiendo moverte entre ambos ecosistemas para no perder esa información tan valiosa que se encuentra en las jerarquías de work items, comentarios, estados…

Gestionar código es complicado pero gestionable si se tiene el conocimiento.

Aquí estamos hablando de otra cosa, que es la gestión de trabajo en la cultura del día a día. Es cuestión de explorar todas las opciones, ver cuál se ajusta mejor, cuál generará menos fricción en el equipo…

Una materia complicada, cuanto menos.

¿Tus proyectos admiten los issues como elementos con los que trabajar? ¿Renunciarías a los work items? ¿Cuál sería la template que más se ajuste a tu próximo proyecto?

Espero que esta información sea útil, ¡seguiremos explorando GitHub!

Al final estamos hablando de repositorios git, ahí no hay mucho misterio si llevamos tiempo picando código… pero hay detalles que GitHub nos ofrece y que merece la pena comentr.

Esto es una serie de posts que pretende exponer y comparar poco a poco las features de las dos plataformas. Si hay conclusiones, serán al final de la misma serie, y no dejarán de ser una opinión personal. Si hay errores, no dudes en hacérmelo saber en la sección de comentarios para corregir lo antes posible. Para saber si te conviene o no, habrá que recurrir al infalible método de ‘ensayo y error’. ¡Prueba y descubre!

En este momento, ya has creado tu organización, invitado a users, creado Teams para organizar a las personas… es hora de operar con lo que nos trae aquí: ¡código!

Hablemos de repos, de lo que podemos gestionar en ellos.

Lo primero es lo primero, y es gestionar la visibilidad del proyecto. ¿Quién puede verlo o descubrirlo en el ecosistema de GitHub?

Invitando a gente, ya sea de forma individual o en Teams, siempre encontrarás en cada repositorio una sección de Settings:

Si hablamos de código para cliente o empresas, lo más normal es que las licencias con las que operes sean privativas. Pero en caso de que no lo sean, puedes elegir entre varias licencias que se ajusten a tus necesidades o demandas. Existen muchas y quizás complejas en el argot legal, pero aquí es donde entra la web TL;DR Legal, donde te simplifican los términos de licencias a la mínima expresión o a un lenguaje más sencillo al alcance de todo el mundo (o intentarlo al menos).

Gestión y protección de ramas

Hay ramas intocables, que no deben ser eliminadas o recibir merges sin validaciones o procesos varios de forma previa. Todas estas gestiones y más se hacen desde las branch protection rules, donde puedes poner requisitos para merges, necesidad de firmado de commits, resolución de conversaciones… Todo bien granulado para tener un control total (¡o el justo y necesario!).

Sobre límites y herramientas varias

GitHub es amplio, pero tiene algunas limitaciones, como para los siguientes elementos:

• Pull requests abiertos sobre la misma rama
• Gigas de subida en un mismo push
• Gigas totales para un repo
• Profundidad en la estructura de directorios
• Número máximo de repositorios para cuentas personales y organizaciones

Por si se te ha ido el dedo hacia el botón de delete… también existe la opción de restauración de repositorios borrados, porque los accidentes ocurren.

Puedes crear templates o plantillas de repositorios, para después crear repos a partir de ellas. También, en caso de que lo necesites, puedes duplicarlos.

¡Esconde bien tus secretos!

Que de cosas para decidir solamente en cuanto al código en sí mismo… pero tal y como comentaba, en GitHub (y a diferencia de Azure DevOps) todo gira alrededor de los repositorios.

Porque no se trata solo de almacenar código y de forma segura. Es en repositorios donde también se congregan los secretos, tokens y keys… que utilizaremos en las automatizaciones en forma de workflows. Pero exploraremos qué son a su debido momento y de forma dedicada.

Y tantos otros elementos

Las Releases, o entregables, es lo más parecido que tenemos a Artifacts en Azure DevOps. Estos entregables se listan ordenados por fecha, incluyendo todo aquello que le especifiques en la generación. Ya sea el código empaquetado, ejecutables para diferentes plataformas destino…

También tenemos las Discussions, que podemos asociarlo a foros, donde se abren hilos de conversación para diferentes temas, que se pueden organizar por categorías. Si quieres que el conocimiento bien organizado a medida que se debate entre users que tengan implicación… esta herramienta es de lo mejor. Y mucho más accesible que en conversaciones de Slack, Teams o Discord, por mencionar algunos.

Y no olvidemos los Issues, aunque de eso hablaremos en un futuro próximo, en otro post dedicado específicamente a ello. Stay tuned!

Son muchos elementos a tener en cuenta, muchas lecturas que hacer y sobre todo muchas conversaciones que tener con el equipo que va a integrar estas herramientas, usarlas en el día a día…

Pero espero con estas palabras señalar las posibilidades y tenerlas en cuenta para una migración… ¡o descartarla para futuros mejores!

¡Nos leemos!

De vez en cuando vuelvo a asomarme para ver novedades y progresos… y esto es lo que descubro, en el otoño de 2025.

¡Se vienen muchas reflexiones!

TL;DR

¿Mucho texto y poco foco? Aquí tienes un resumen:

• Android ha cambiado mucho desde que empecé, como por ejemplo nuevas versiones, hasta tecnología interna…
• Google oscurece el proyecto open-source y cada vez es un ecosistema más restrictivo (bloqueando side-loading, por ejemplo)
• Hay alternativas como LineageOS, Calyx y Graphene… que merece la pena considerar

Poco queda del entorno que yo conocí… ¿qué ha cambiado desde entonces?

TODO… o casi todo

Empezamos por el cambio más notable, que es el movimiento desde Java hacia Kotlin como lenguaje para crear aplicaciones nativas. Android Studio se siente más ligero, pero igual es tremendo monstruo devora-recursos en tu equipo.

Con sus diferencias y bondades, Kotlin parece estar recibiendo mucho cariño tanto desde la comunidad como desde el equipo creador. Y mientras siga evolucionando, ese es el camino.

Con Kotlin, llegó también Jetpack Compose. Olvídate de interfaces en XML, ahora todo se hace de esta forma declarativa en Kotlin… a la que personalmente ya me he acostumbrado en Flutter, pero que se me hace alienígena en este ecosistema.

Reconozco que me daba mucha seguridad ver a tiempo real, en modo preview, cómo se debía ver mi app a medida que declaraba todo en XML:

También han llegado muchas versiones oficiales de Android desde entonces. En aquel momento, la versión más reciente era Android 7 (Nougat), pero no recuerdo que fuera la que estaba usando… en mi dispositivo móvil, que no era el más puntero, usaba Android 5 (Lollipop).

A septiembre de 2025, ya estamos en Android 16 (Baklava).

Y no nos podemos olvidar de Material Design, que también evoluciona. Ya se ha iniciado el terremoto con Material Expressive, o Material Design 3…

Las aplicaciones que se vienen en futuros próximos pueden ser impresionantes, poco queda de la homogeneidad que proponía Material Design en mis inicios.

Como el skeumorphism, pretendía generar un conocimiento, unas experiencias comunes, un aprendizaje durante la adaptación y recepción de dispositivos móviles. Pero ya es hora de seguir avanzando.

Y lo cierto es que pueden dar paso a apps muy originales.

AOSP también está mutando

Siglas de Android Open Source Project… que cada vez es menos open-source.

En marzo de 2025, se anunciaba que todo el desarrollo de Android se realizaría internamente, sin compartir avances en tiempo real. Esto simplificaría el proceso de release, por no tener que estar sincronizando de forma constante el repositorio público con el privado e interno…

Se comprometían también a hacer esta liberación de código después de cada lanzamiento de una versión oficial.

Perdemos transparencia, visibilidad del proyecto, y no sabemos si se cumplirán las promesas de ir liberando versiones en circunstancias especiales. Menos control, menos poder sobre la tecnología.

Fuente: Exclusive: Google will develop the Android OS fully in private, and here’s why

¿El camino es lo nativo?

Cuando lo aprendía en su momento, Java era el lenguaje para crear apps en el ecosistema del androide, con sus ventajas y sus males. En el ámbito multiplataforma, pocas opciones había. Me hablaron de Xamarin, como único camino hacia lo multiplataforma, al menos que conociesen en el ecosistema Microsoft.

Justo cuando terminaba mis estudios, Kotlin empezaba a resonar y ya se alentaba a cambiar desde Java. Y siempre estará ahí, donde sabemos que jugamos en casa y contamos con lo último de lo último.

Pero no se ha quedado solo en este campo. Para multiplataforma, ahora hay tantas opciones que resulta casi absurdo. React Native, Flutter (creado y mantenido desde la misma Google), .NET MAUI, Ionic, Nativescript, Lynx como último contendiente del que tengo constancia… aunque seguro que habrá alguno que se me escapa del radar.

Cada vez más cerca de iOS

Y por si fuera poco, Google comienza a convertir el ecosistema en algo… cada vez más prohibitivo. Bajo la bandera de la seguridad y privacidad, quieren prohibir el side-loading.

¿Qué es side-loading? Es la capacidad, dentro del sistema operativo, para instalar aplicaciones en el dispositivo de fuentes que no son de tiendas oficiales. Es decir, instalar directamente desde una APK, desde tiendas alternativas de F-Droid…

Cada vez nos acercamos más a la premisa:

Tu dispositivo hardware, nuestras reglas

¿Y no era esto lo que precisamente encontramos en iOS, ecosistema del que huimos porque buscamos horizontes más libres?

Fuente: Google plans to block side-loading like Apple, declaring war on Android freedom

Desde un punto de vista de user, cada vez menos libertades y menos flexibilidad. Como creadoras y developers, más burocracia, complicaciones…

Hay incluso una petición en change.org para exigir cambios en esta dirección. Te animo a firmar si estas cuestiones te inquietan.

Alternativas a día de hoy

Con todos estos cambios, novedades, giros de volante… es posible que quieras quitarte de problemas y cambiar de sistema operativo (para encontrar nuevos problemas, solo que diferentes a los que habrás encontrado antes).

Quiero aclarar que no tengo experiencia ni estoy recomendando ninguna de estas opciones, me limito a listarlas para dar puntos de partida a las interesadas.

En sistemas operativos, tenemos LineageOS, Calyx, Graphene, eOS, UbuntuTouch…

Si quieres usar cualquiera de ella, tienen sus propias listas de dispositivos compatibles, seguramente con muchas guías para superar diferentes casuísticas que puedas encontrar en el camino.

Cada una de estas alternativas tendrá una comunidad más o menos activa, amable, quizás solo hablen inglés… es un camino más angosto, quizás solitario en ocasiones, pero puede abrirte muchas fronteras.

Y en hardware, tenemos Fairphone. Tengo entendido que viene instalado con Android, pero admite cualquiera de las opciones que hemos mencionado arriba. Y también Volla, que tiene su propio sistema operativo, VollaOS, pero que es compatible con otros sistemas operativos alternativos.

Y se podrían escribir ríos y ríos de tinta sobre todas las combinaciones, pero eso es una investigación personal hasta encontrar lo que necesitas o lo que te hace falta en tu día a día. ¡Mucha suerte en la búsqueda, si te embarcas!

La dependencia mobile…

Y al final de todo, tenemos una dependencia brutal a los dispositivos mobile. Cosas que en el pasado hacía en mi PC, ya fuera laptop o sobremesa, y que ahora (por velocidad aunque no necesariamente agilidad) lo hago a través de mi teléfono móvil.

Estamos atadas a estos dispositivos, cada vez por más motivos y servicios. Y atrapadas, porque no existen opciones estables, sólidas, a las que migrar en masa y que generen confianza en la mayoría de las users.

No existe un cambio radical, de la noche a la mañana. Es cuestión de ir poco a poco, si queremos cambiar. Porque (al menos de momento) nadie está dispuesto a invertir cantidades astronómicas para impulsar alternativas.

¿Y ahora qué?

Esto ha sido un viaje de mis inicios, los cambios del ecosistema, la perspectiva de developers (si no optamos por native), las alternativas que hay si no queremos pasar por Android… empezó como un recuerdo, una cronología, y parece que ha acabado como un manifesto de «abandonemos Android». No era la intención, pero quizás ayude a alguien a tomar perspectivas.

¿Cambiará Google de opinión y se retractará de la decisión en cuanto a side-loading?

¿La solución podría ser que todo el mundo aprenda a programar para aportar a alternativas creadas e impulsadas por comunidades?

¿Se empezará a tomar más conciencia y se empezarán a financiar mejor los proyectos open-source?

¿Es momento de des-Googlificarse? Aquí tenemos una guía sobre cómo podemos empezar a abandonar (al menos) algunos servicios de Google:

Pero si tomamos este camino debemos tener claro que todo pasa por la incomodidad. La incomodidad de renunciar a cosas, a servicios que nos facilitan la vida, de interactuar con interfaces que no son las habituales, de abandonar la centralización a la que tanto nos habíamos acostumbrado, de aprender muchas cosas nuevas, de buscar ayuda…

No es fácil, pero puede ser liberador.

Espero que estas palabras sean útiles, ¡mucho éxito en la búsqueda!

seeU!

Tras los anuncios de Liquid Glass y Material Expressive, el terremoto de cambios en el mundo del desarrollo todavía se deja sentir.

La última de la que tengo noticia y que va para largo son los cambios que se ejecutarán en Flutter, donde el framework se va a sacudir hasta los cimientos.

Porque, dadas las novedades que se dan como Liquid Glass y otros cambios que se pueden dar en el tiempo, han decidido separar, desacoplar Cupertino y Material Design del core del framework. Ambos sistemas de diseño, estándares en iOS y Android hasta la fecha, se convertirán en packages independientes en el futuro.

¡Se abre un océano de posibilidades!

Tras mucho debate en issues de GitHub, finalmente el equipo de desarrollo anunciaba lo siguiente:

The material and cupertino libraries are being decoupled into standalone packages to accelerate feature development. All new work for Material 3 Expressive will happen in the new packages once established in flutter/packages. (#168813)

En nuestro idioma, tanto Material como Cupertino se van a desacoplar en paquetes independientes, para mejorar en varios sentidos. Y así otros sistemas de diseño para ambos sistemas operativos en el futuro también vendrán de forma independiente, con muchos beneficios para el framework desde la parte más core.

Y es que entre Liquid Glass y M3 Expressive lo han sacudido todo, poniendo en evidencia que se necesita herramientas agnósticas (o todo lo posible al menos) a sistemas de diseño ligados a sistemas operativos. En la actualidad, están conviviendo o se espera que convivan, dos o más sistemas de diseño para ambas plataformas. Y más que se puedan dar en el futuro.

Y se aplicarán o no dependiendo de demasiadas variables, necesitando cada vez más flexibilidad a la hora de tomar esas decisiones, y que su ejecución sea lo menos dolorosa posible.

Los cambios que vienen como futuros estándares son muy diferentes a lo que conocemos hasta ahora.

Así se aspira a que se vean las nuevas apps en el ecosistema Android, en Material 3 Expressive:

Y así es como las veremos en el futuro en iOS, con Liquid Glass:

Liquid Glass sigue evolucionando y mejorando en sus diferentes betas. Y aunque había dudas sobre si podía ser abandonado o postergado, los cambios que se implementan en las últimas betas de verano indican que va a ser definitivo.

Flutter es un framework en constante evolución y con una base de users cada vez más grande. Necesita adaptarse a las plataformas a las que apunta de una forma cada vez más fácil y sencilla.

También necesita dejar flexibilidad para aquellos proyectos o grupos de desarrollo que quieren ir por libre y no acoger ningún sistema de diseño. Y aunque es muy útil contar con un sistema de diseño por defecto, como Material Design, en nuestros primeros pasos con la herramienta… es necesario pensar a largo plazo y en proyectos de gran envergadura.

Es un paso más hacia nuevas etapas de madurez en Flutter, así que recapitulemos:

No partiremos por defecto por un sistema de diseño preestablecido, si no que tendremos widgets agnósticos, raw, puros… como queramos llamarlos. Estos widgets mantendrían lógica esperable para los dispositivos en los que se ejecutan, como reaccionar a taps, clicks, slides, dragging… poniendo el foco en la accesibilidad y su funcionamiento, pero sin un diseño específico.

Un lienzo en blanco, por fin.

¿Qué ganamos?

• Evolución más rápida e independiente
• Actualizaciones y correcciones más rápidas
• Equipos de desarrollo tendrían mayor control sobre las migraciones y versiones de UI
• Mayor flexibilidad para personalizar widgets o implementar sistemas de diseño propios
• Una arquitectura más limpia y coherente al separar los sistemas de diseño del framework central

Requerirá de mucho trabajo, sin duda, pero creo que merece la pena de cara a continuidad y mantenimiento en el proyecto. Es una decisión que, tal vez por la carga que conlleva, se ha tardado mucho tiempo en tomar. En lo personal, me parecía inevitable, que debía llegar eventualmente.

Pero una vez dado el anuncio, tengo muchas ganas de conocer el proceso y avances a lo largo del tiempo.

¿Y en qué fechas?

Nada concreto, y no creo que deberían dar plazos o rangos de fechas específicas. Eso solo añadiría presión al equipo, y no es el punto de todo esto. Seguramente veamos progresos a lo largo de 2025 y 2025, y al ser un proyecto de código abierto, siempre se puede intentar contribuir de diferentes formas.

Me considero una entusiasta de Flutter, aunque no he podido trabajar profesionalmente con el framework a día de hoy. Aún así, me gusta estar al tanto de estos temas, me da más conocimiento de lo que ocurre en las entrañas de esta tecnología.

Gracias a Liber por poner este debate en el foco y atraer mi interés, en su contenido en forma de vídeo para el disfrute de la comunidad hispanohablante:

Seguiremos aprendiendo y atentas a las novedades, disfrutando del viaje. Mientras tanto, para seguir ampliando conocimientos, puedes leer la documentación o lanzarte directamente al código fuente.

¡Nos vemos entre widgets!

Pero todo cambia y GitHub ha tomado cada vez más fuerza, dejando lugar a dudas sobre si deberíamos arrancar o migrar proyectos a la plataforma.

¿Qué cosas debemos tener en cuenta? ¿Qué tan diferente puede ser en el día a día? ¿Qué ganamos y qué perdemos al cambiar desde Azure DevOps a GitHub?

Iremos, paso por paso, desgranando estas cuestiones y abriendo otras muchas que bien merecen consideración.

Esto es una serie de posts que pretende exponer y comparar poco a poco las features de las dos plataformas. Si hay conclusiones, serán al final de la misma serie, y no dejarán de ser una opinión personal. Si hay errores, no dudes en hacérmelo saber en la sección de comentarios para corregir lo antes posible. Para saber si te conviene o no, habrá que recurrir al infalible método de ‘ensayo y error’. ¡Prueba y descubre!

En mayo de 2025, celebrábamos en Málaga una instancia de Global Azure, el momentum a nivel global que Microsoft empuja para traer la conversación sobre Azure y el ecosistema cloud dentro de estas tecnologías. Tuve la fortuna de asistir como speaker, para hablar sobre GitHub, hablando de cosas a tener en cuenta si queremos migrar de una solución tan estandarizada y expandida como Azure DevOps.

Porque no se trata tanto de la migración a un nivel técnico, que puede ser más o menos difícil.

Es un cambio de herramienta, de paradigma, de costumbres y prácticas diarias, casi de cultura… a una aplicación que, para empezar, cuenta con un modelo de entidades totalmente diferente.

Donde empezamos con organizaciones que contienen proyectos en Azure DevOps, y estos tienen asociados work items, repos y demás… en GitHub es muy diferente.

Creando una organización

Así que puedes empezar creando tu organización, eligiendo el plan de suscripción que más te convenga, por las capacidades que ofrece.

Existen organizaciones, users… pero no proyectos como tales, al menos no como los entendíamos en Azure DevOps.

Si tienes tus proyectos en Azure DevOps, te habrás acostumbrado a un ecosistema cerrado, aislado, un remanso de paz en el que nadie más puede pisar… En GitHub esto es muy diferente. El concepto original de GitHub es de una red social para developers, y así entras, tus proyectos, organizaciones, repositorios… se encuentran en mitad de todo el ecosistema, «susceptibles a ser descubiertos» dentro de la plataforma, por así decirlo.

Es más importante que nunca poner el foco en la seguridad, y conseguir que el código y todo lo que a tu organización corresponde solo esté a la vista de quien corresponda. GitHub no es menos seguro por definición, es solo que difiere en el aislamiento que provee o se deja sentir en cuanto a nuestros elementos con respecto a Azure DevOps.

Licencias y otras hierbas

¿Pero qué pasa a nivel de licencias? En el pasado, necesitabas pagar por separado las licencias para diferentes users en GitHub y Azure DevOps. Pero desde febrero de 2025, los users con GitHub Enterprise Cloud obtienen acceso gratuito al nivel Azure DevOps Basic.

Así que tenemos ventajas por esa parte, no la dejes escapar.

Users y teams

Cada persona necesitará su propio user, y este user debe pertenecer a su vez a los diferentes Teams o Equipos que le correspondan, para permisos. Hay mucha información alrededor de las vicisitudes alrededor de los tipos de cuentas de user, y sobre los Teams, ten en cuenta son grupos de miembros de una organización para darle estructura a nivel de permisos.

Bien puedes crear diferentes teams para los proyectos de cliente que vayas a abordar, diferenciando entre quienes se dedican al front, backend, QA… Creando estructuras similares a project1-frontend, project2-backend… Dependiendo de lo que se precise para cada situación o dinámica de grupo.

Así podrás gestionar los diferentes accesos a repositorios, el control y la seguridad no son opcionales, mucho menos cuando se trata de código. Y precisamente para saber bien lo que se hace dentro de la organización cuentas con los audit logs, para comprobar fácilmente quién hace qué sobre qué elemento y en qué momento.

Por lo tanto, algunos de los primeros pasos que tendrás que dar cuando te decidas para mudarte a GitHub para actividades empresariales, serán:

• Crear una organización con el pricing plan que mejor convenga
• Invitar a users en la empresa y empezar a asignar licencias
• Crear y asignar permisos a Teams, para después agregar a users correspondientes

Estos son solo los primeros pasos para arrancar con GitHub, pero queda mucho camino por delante. Por lo pronto, hemos desgranado cuáles serían los primeros pasos para estar presentes en la plataforma.

En el siguiente post, hablaremos sobre tareas, los work items en Azure DevOps, y cómo se manifiestan en GitHub.

¡Nos leemos!

Solo que… no me esperaba todo lo que pasó alrededor de Liquid Glass, la nueva propuesta de diseño de UI para dispositivos iOS anunciada en la WWDC 2025.

¡Empezamos!

Llega junio de este año y con el calor, también la World Wide Developers Conference. Es el encuentro anual en el que Apple muestra sus novedades y propuestas de cara al ecosistema, muy orientado al negocio y poco hacia la comunidad de desarrollo:

Pero problemas de devs aparte, la introducción de Liquid Glass fue algo increíble.

Antes de empezar, debo decir que no soy user de iOS ni ningún otro producto del ecosistema de Apple. Estas palabras las escribo desde la curiosidad y el interés por el diseño de UI/UX, no desde la perspectiva de alguien con expertise en la materia. ¡Disfrutad!

Liquid Glass es un estilo de diseño skeumorphic, o más bien neumorphic, para dispositivos que usen iOS 26, iPadOS 26, macOS Tahoe, watchOS 26 y tvOS 26… y que esperan ser lanzados de forma oficial en septiembre de este mismo año.

No vamos a entrar en las especificaciones del dispositivo, solo nos centraremos en el diseño que quiere dar a las interfaces un look and feel de un cristal denso, con animaciones que emulan una sustancia acuosa. Como si los botones, switches, sliders… estuvieran hechos de un material líquido que cristalizase, creando un efecto difuminado.

La reacción del público ha sido atroz.

Y no podemos olvidar este error en los thumbnails de los vídeos de presentación en YouTube… donde al no probar con suficiente detalle, el botón de iniciar reproducción del vídeo en YouTube se comía las letras G y L… haciendo que se leyese «Liquid ass». Pura poesía.

Aquí podéis encontrar el vídeo de la presentación:

Y aunque recordemos que se trata de una propuesta que aún podemos considerar en beta, existen problemas más o menos preocupantes.

Puede no gustarte, y eso es totalmente legítimo. Pero hay muchas dudas sobre cuanto va a afectar este tipo de animaciones al rendimiento de los dispositivos y por supuesto a la batería.

Quitando el lado del hardware, ¿qué hay de la accesibilidad?

En la siguiente imagen, se puede ver una captura de pantalla de bloqueo de un dispositivo usando Liquid Glass, con un fondo de colores azules. Las notificaciones, sin contraste alguno en caja o texto, son completamente indescifrables:

Hay mucho caos con los contrastes, con las dificultades que suponen para las personas con dificultades para ver, como la mencionada, pero también en los cambios de modo noche/día. Los difuminados o blur son demasiado suaves, dificultando la legibilidad. No hay suficiente diferencia entre los elementos UI y el fondo, haciendo difícil operar con este diseño, como en la siguiente imagen:

Es difícil diferenciar la barra de reproducción de música en activo, la tab bar de navegación del sistema operativo y el fondo blanco de la que supongo es la app de Spotify.

Son muchos detalles, los que he mencionado y los que seguro no escapan a un ojo experto, que han causado una mala primera impresión. Pero con todo, recordemos que se trata de una beta.

Estoy segura de que este nuevo diseño, este lenguaje, mejorará e irá corrigiendo sus errores.

Al momento de escribir estas palabras, desde Apple están corrigiendo poco a poco algunos detalles, como la nula legibilidad del Control Center, con fixes añadidos en la segunda beta para developers. Por lo que el resultado final no está lejos, y veremos cómo resulta entre el público. Si quieres probarlo, también enlazo una guía para instalar estas betas en tus dispositivos.

Desde la perspectiva como developer, es muy curioso ver cómo Liquid Glass ya está calando en algunos lenguajes y frameworks. Hay guías para desgranar cómo se aplica en CSS, un package específico para implementarlo en Flutter y también una lib para React.

En lo personal me gusta el concepto de Liquid Glass. Hay mucho que perfeccionar, pero es muy bonito de ver. No sé si un producto de Apple necesitaba este gran giro en cuanto a diseño, es como querer dar solución a un problema que no existe… Porque a veces, poder hacer algo no significa que debas hacerlo.

Aún así, creo que tiene potencial, y tal vez pueda funcionar. El tiempo dirá que ocurre, así que hasta entonces, ¡a disfrutar y seguir aprendiendo!

seeU!

Y desde entonces, tengo un cariño particular por esta distro.

En la primera mitad de 2025, decidí volver a usarlo, y desde ahí escrito estas palabra.

No es algo especial en particular, simplemente openSUSE era una distro que se le hacía cómoda a mi profesor, conocía su funcionamiento y le resultaba útil. Ubuntu (con Unity) tenía mucha magia en su uso, pero openSUSE se me quedó en el corazón.

En la actualidad, estoy usando la versión Leap 15.6 con KDE (Plasma 11.X).

Alejándome de Windows

Soy user asidua de tecnologías Microsoft, pero no significa que las decisiones que toman me parezcan acertadas. Una que me parece realmente desafortunada es la finalización de soporte para Windows 10, 8 y 7 en octubre de 2025. La fecha deja poco margen para actuar y empuja una migración forzosa a Windows 11… pero también una oportunidad para adoptar alternativas, como Linux.

Y es que cada vez más herramientas, videojuegos… están disponibles en los pingüinos, alejándonos de la hegemonía de Microsoft en el escritorio.

Cada vez hay más tutoriales, puertas de entrada más accesibles para users que no quieren complicaciones para usar un sistema operativo de escritorio.

Viendo que había una oportunidad, simplemente me apetecía más que nunca volver a openSUSE, no como camino único y correcto. Solo una opción más de entre las que hay disponibles.

Empatía y paciencia, son nuestras aliadas en este camino.

Pensando en código

A la hora de seguir trabajando y programar desde openSUSE, no he encontrado grandes obstáculos.

Tenemos Kate como editor de código de forma nativa en esta configuración, pero puedo seguir usando Visual Studio Code sin mayores problemas.

Instalando Flutter

Entre muchas cosas que considero necesarias en un equipo en el que navegar, estudiar, escribir… ¡también puedo trabajar con Flutter!

Siguiendo dos guías en concreto, una para instalar Flutter y otra para habilitar la ejecución de apps de escritorio en openSUSE. Es importante evitar cualquier proceso de instalación de Flutter que implique snapd, porque… simplemente no funciona.

Lo uso en mis proyectos personales y también pude utilizarlo en mi demo durante la OpenSouthCode 2025, en un combo open-source muy potente.

¡Jueguitos!

De forma nativa, después de instalar openSUSE con KDE Plasma, encontré una gran colección de videojuegos que despertaron mi ilusión (y también mi nostalgia).

SuperTux 2, Dune Legacy, SuperTuxKart, minetest, Lugaru, Frozen Bubble… una barbaridad de juegos que (re)descubrir desde mi etapa con Guadalinex, la distro que usábamos en mi comunidad autónoma mientras estudiaba en la secundaria.

Cositas, detalles que ponen muy difícil aburrirse en openSUSE.

Disfrutar del camino con herramientas que nos lo ponen fácil, creo que es el camino. En esta etapa, estaré usando openSUSE, hasta que encuentre una opción que se ajuste mejor a mis necesidades del momento.

El distrohopping es interesante, pero es otro tipo de experiencia, casi un hobbie, por lo que queda descartado para mí.

Ojalá estas palabras ayuden a alguien y/o le sirvan de inspiración. Mientras tanto, ¡a seguir tecleando!

seeU!

Y es que las modas y tendencias son cíclicas, ¿no? Quién sabe si en algún momento esta tendencia regresa y se impone como una nueva norma.

¿Qué es?

El skeuomorphism, diseño skeuomorphic, esqueumorfismo… es la forma en que diseñamos en el entorno digital, emulando o haciendo mímica de un objeto real, que encontramos en el mundo físico.

En las fases más tempranas de las apps móviles y smartphones, podíamos encontrar estos diseños como apps de grabación de sonido con una imagen de un micrófono condensador; una brújula realista en nuestra app para señalar el norte; libros digitales dispuestos como si fueran en una estantería física mostrando sus portadas; una cámara de fotos haciendo como que cerraba el obturador a cada disparo; una animación de pasar páginas en una agenda de contactos…

Estos son los ejemplos que se pueden ver en la siguiente imagen:

Fue una tendencia muy útil en la adopción de nuevas tecnologías como los smartphones, porque se emulaba el uso del objeto original al que se emula de una forma digital.

¿Por qué cambió?

Una vez nos adaptábamos más y más a alternativas digitales para objetos de nuestra vida real, este diseño que hacía de paso intermedio se hacía cada vez más innecesario.

Se ocupaba más espacio físico en cada vista, complicando el diseño o forzando a alargar procesos que ahora caben en una sola interfaz, o en dispositivos de tamaño más reducido.

Y a medida que pasa el tiempo, cada vez menos personas han utilizado o saben reconocer los objetos que se pretenden emular en esta corriente de diseño.

Otras tendencias

A raíz de ponerme nostálgica con este tipo de diseño, conocí otros términos, como el neumorphism y el glassmorphism, que también me parecen fascinantes.

El glassmorphism, que podríamos traducir como cristalmorfismo, es acercar los diseños al look and feel del cristal.

Desenfocado de fondo, transparencia como el cristal… De los ejemplos más claros, se pueden observar en los diferentes menús de apps en de macOS Big Sur, la major release 11 del sistema operativo, lanzada en 2020… aunque ya se haya quedado atrás puesto que estamos en la versión Sequoia, major release 15.

Y también el neomorfismo o neumorphism, donde entran en juego las luces y las sombras. También llamado nuevo skeumorphism, como una evolución espiritual, es un juego de texturas.

En lugar de elementos superpuestos en diferentes capas, los elementos se «hunden» o «surgen» de una superficie, como si fuera una misma textura. Ahí es donde entra la luz y las sombras, dando la sensación de que es todo parte de una misma pieza.

Los resultados son como los que se ven en la colección de botones, sliders, switches… de la siguiente imagen:

Todo esto me hace preguntarme, como casi con todas las áreas, cuantas otras tendencias y estilos me serán desconocidos y serán igual de increíbles.

En la educación

Mientras compartía mi entusiasmo por esta tendencia, hubo aportes muy interesantes, con nostalgia, escepticismo… o un punto de vista desde la educación:

quería decir que dar clases de informática era más sencillo cuando los objetos en la pantalla recordaban a las cosas de la vida real, Fernando Álvarez desde masto.es

Enfrentarte al lienzo o la página en blanco es muy difícil, y al ponernos a diseñar puede ser todavía más duro, especialmente si tu tiempo es limitado (porque se esperan resultados, hay más temario que impartir…).

Es entonces cuando estas tendencias pueden ser muy útiles a la hora de proponer aplicaciones con las que empezar a crear y desarrollar.

¿Regresará?

Lo dudo bastante, aunque sin duda sería fascinante ver una nueva oleada de skeumorphism. ¿Cómo sería? ¿En qué se diferenciaría de la original? ¿Traería consigo una nostalgia similar a la que siento cuando veo retro tecnología o escucho synthwave?

Muchas preguntas que solo el tiempo puede responder. Mientras tanto, sigo entusiasmándome con estos temas, y aprendiendo mucho en el camino.

seeU!

Desde hace un tiempo, se nos aconseja usar pipelines en formato texto, y para asegurarnos de seguir esa buena práctica, podemos forzar a que esta sea la única forma de hacerlo.

Desde enero de 2023, se añadió la posibilidad de deshabilitar estas pipelines, tanto para release como para build. Descubramos cómo podemos hacerlo.

Sobre permisos

No cualquier persona puede deshabilitar estas pipelines, requerirá de diferentes permisos dependiendo del nivel en el que queramos establecer esta regla:

• A nivel de organización, necesitarás permisos de Project Collection Administrator
• A nivel de proyecto, necesitarás permisos de Project Administrator

El proceso

Una vez tenemos claro que vamos a prohibir esta forma de creación de pipelines,

A nivel de proyecto, entramos en Project Settings. Viajamos a la sección de Pipelines, dónde encontramos otra sección específica de settings. Activaremos el último toggle, que reza «Disable creation of classic build and classic release pipelines».

A nivel de organización, entraremos en Organization Settings, donde podemos seguir un proceso similar. El último toggle de Pipeline settings, y tendremos prohibida la creación de classic pipelines.

Cuando intentemos añadir una nueva pipeline, ya no veremos la opción de crearlas a través del modo classic. Tampoco podremos importar classic pipelines, como vemos en la imagen:

Se ha deshabilitado totalmente la posibilidad de crear classic release pipelines y classic build pipelines. Y eso incluye, obviamente, a todas las APIs relacionadas con crear classic build pipeline, classic release pipeline, task groups y deployment groups.

¿Significa esto que las classic pipelines van a desaparecer? Desde el mismo artículo de Microsoft, anuncian que no, seguirán funcionando en el futuro, pero tenemos una herramienta para forzar esta regla en nuestra organización o proyecto concreto.

Puedes leer el anuncio en el siguiente artículo de Azure DevOps Blog, Disable creation of classic pipelines – Azure DevOps Blog (microsoft.com).

Espero que sea útil, ¡nos vemos entre pipelines!

Este post fue publicado originalmente el 15 de marzo de 2023 en Azurebrains

La realidad demostraría esas habilidades dadas por hecho estaban muy lejos de ser dominadas.

Por eso me pregunto… ¿ocurrirá lo mismo con las generaciones que crezcan con la naturalización y normalización de la inteligencia artificial?

Dando por hecho que la inteligencia artificial (especialmente la generativa, con sus claros y oscuros (más oscuros que claros, si me preguntan)) está para quedarse. Que lo va a cambiar todo y ya no hay punto de retorno, que no es un bluff o una burbuja a punto de estallar.

Para las personas que estamos viviendo este terremoto, ya se está viendo un abandono para ciertas habilidades que se dan por hecho estarán automatizadas… o simplemente se opta por la opción de generar un resultado a través de AI. Tanto que se puede dar cierta «atrofia» en estas habilidades en desuso.

Bien podría ser leer, escribir, dibujar, diseñar, escribir código… podría ser cualquier cosa. Y como cualquier habilidad, se puede atrofiar.

Pero para algunas de ellas, en las generaciones futuras… ¿daremos por hecho que se sabe todo? ¿Que ya son expertas? ¿Que no se necesita guía o mentoría en los casos de duda?

Donde la inteligencia artificial no llegue o si alguien quiere ahondar en el código que se genera por IA, ¿qué harán si no tienen esos conocimientos? ¿Les tenderemos la mano, como comunidades? ¿O daremos por hecho que ya saben todo, abandonándolas a su suerte y con el sufrimiento/estrés/ansiedad en consecuencia?

Cuando llegue el momento, sería fantástico estar preparadas, quizás con formaciones ad-hoc para impartir, comunidades activas y preparadas para escuchar.

No creo que se trate de altanería, dar por hecho que nosotras o nuestros conocimientos eternamente necesarios. Solo es prepararnos para esas circunstancias.

E igual que no podemos salvar a nadie que no quiera ser salvada, podremos ayudar a aquellas que quieran y pidan ayuda.

Aquí seguiremos, escribiendo, creando, compartiendo, re-pensando las formas de enseñar y aprender.

seeU!