Actores re-entrando

00:00 /2h08

Hoy Arturo se desahoga con algunos problemas que ha tenido con UIKit en las últimas semanas debido a cambios y elementos deprecados que las últimas versiones de Xcode.

Comentamos las novedades de la semana y hablamos de las aproximaciones a la concurrencia y cómo entender y programar de una forma más eficiente este paradigma y lo importante que es.

Todo a través de un ejemplo en que podemos ver que un Actor duplicaría entradas a través de las re-entradas del Actor en procesos no finalizados. Es decir, café del bueno.

Convierte en un Senior iOS Developer con el Swift Full Stack Bootcamp. Encuentra toda la información aquí: IV Swift Full Stack Bootcamp 2024.

Arturo Rivas

Julio César Fernández

Transcripción

Cuonda, la comunidad de podcast independientes en español. Bienvenidos a CAFÉ SWIFT, el podcast donde hablamos del lenguaje de programación SWIFT de Apple, solo no. Hablamos de programación, de herramientas para desarrolladores y de distintas experiencias, pero siempre desde el punto de vista de desarrolladores en entornos Apple y del lenguaje SWIFT. Y esos desarrolladores somos Arturo Rivas y Julio César Fernández.

¡Comenzamos! Muy buenas y bienvenidos a un nuevo café intenso, con toques afrutados y una cosecha de calidad. En el que vamos a hablar de nuevo sobre desarrollo en entornos Apple. Bienvenidos a vuestro CAFÉ SWIFT y por supuesto no podemos tener un café de calidad si no tenemos a nuestro compañero barista Arturo, ¿qué tal Arturo? Muy buenas. Buenas, buenas Julio, ¿qué tal? Un placer, como siempre, a los oyentes también saludarles.

Aquí estamos otra vez con la dosis de café, no ración, la dosis de café de calidad. Y a ponernos un poco al día porque, a ver, yo te veo que estás quemaete, yo tengo la impresión de que últimamente Apple no te ha tratado bien, no te ha tratado bien y estaba la cosa un poco, entonces claro, yo después de hablar con Arturo en privado, que de vez en cuando nos escribimos cada día o casi cada dos días o una cosa así, nos pasamos

cotilleos del mundo Apple, mira lo que ha hecho este tal, no sé qué, o mira este tweet o mira lo que han sacado, muchas ocasiones casi coincidimos enviándonos la noticia a la vez. Se puede decir que somos un poco porteras al final. Sí, sí, es un poco, sí, totalmente, es como la nueva portería Swift y siempre estamos como, ay mira del tercero lo que ha dicho, ay de verdad, es que... ¿Has visto este?

¿Has visto este? He visto este, de verdad, es que no puede ser. Y bueno, pues comentando contigo, ¿no? Esta semana te habían tocado unas cuantas de Swift importantes, ¿no? Fíjate que también, como ya sabéis, esta semana, porque estamos grabando el domingo 8 de octubre, salió Scope 15.1 beta, que además salió IOS 17.1 sin Scope y a la semana siguiente IOS 17.1 beta 2 con la Scope 15.1 beta 1 con Vision OS beta 4, o sea, es una

cosa como un poco raruna. Y cuando salió, pudimos comprobar que el error de Swift Data, de no poder utilizar Swift Data en segundo plano, sigue presente, sigue ahí, no nada ha cambiado. Es que no sepa qué ha salido, o sea... La verdad que sí, pues te digo para qué, para arreglar cosas de Vision OS, porque es el gran cambio que tiene, porque Vision OS sí tiene corregidos el tema de los observables y tiene corregido todo lo de Swift Data, o sea, ahora mismo con Vision OS ya se puede

usar observables y Swift Data igual que se puede usar con IOS, ¿no? Que hasta ahora no se podía porque había un error de tal y cual. Yo creo que ese es el motivo, porque por lo demás no se han visto cambios ni backfixes importantes en la versión, pero bueno, estamos haciendo tiempo para que la música de fondo termine, básicamente, y yo creo que a lo mejor es que pasemos directamente a que os contemos qué hemos estado haciendo durante estas dos últimas semanas porque Arturo nos

trae cosas suculentas, así que si te parece, vamos a ver qué hemos estado haciendo estos días. Así que, a ver, desahógate. Pues, la verdad, ha sido una semana a ciega a título personal porque está malo hasta el perro en casa, o sea, hemos tenido...

estaba la niña, el perro, ha sido un desastre de semana y, además, yo llevaba esperando, pues como has dicho antes, la beta nueva de Scode, una nueva versión nueva de Scode, que arreglase ciertas cosas y va Apple y, sorprendiendo a nadie, no ha arreglado estas cosas. Pero es que son cosas que, sinceramente, me parecen bastante gordas, de hecho, hicimos un post en LinkedIn que dio un poco de salseo porque, si queréis seguirnos, nosotros tenemos LinkedIn también, yo estoy en linkedin.com barra in barra jcfmunoz y el tuyo es Arturo

Rivas A también, si no me equivoco, es igual, también lo tenéis en linkedin.com barra in barra Arturo Rivas A, claro, en LinkedIn la cosa es algo más serio, más profesional, etcétera, pero ahí pusimos un poco de salseo porque, realmente, a raíz de un post en X de Arturo, surgió este tema, un tema de un error que...

un par de errores, realmente, que nos hacen pensar si realmente Apple está empezando a no darle la suficiente importancia o dejar de prestar atención a UIKit. Cuéntanos, Arturo, ¿qué es lo que te ha pasado? Pues sí, vamos a explicarlo desde el principio y el error en sí es que puede no aplicarse correctamente la configuración de fuentes en el Storyboard, es decir, tú asignas una fuente en el Storyboard y luego ejecutas la aplicación y esa fuente, en lugar de ser

negrita no es negrita, o al revés, o no tiene que ser negrita es negrita, puede pasar cualquier cosa. A mí lo que me sorprende... Puede pasar y pasa. Pero es que lo que me sorprende es lo que acabas de decir, en un... podría, o sea, es como que es totalmente aleatorio, yo pensé que no era así. Sí, sí, sí, hay algunas fuentes que van y algunas fuentes que no. Y eso estaba así en la versión de Scope 15, ¿vale?, que salió.

La final, la del App Store. La final. Hostia. Y sigue exactamente igual, pero eso sí, te pone esa maravillosa palabra workaround, puntos. Chetea las fuentes customizadas por código, que me parece, a ver, yo estoy empezando un proyecto nuevo, imagínate, empiezo, quiero utilizar Storyboard y UIKit por lo que sea, no me quieren en casa o lo que sea y tengo que utilizar en un nuevo proyecto UIKit. Pues bueno, digo, pues lo empiezo cheteándolo en el...

Pero imagínate que es lo que me pasa, en este caso es un proyecto enorme que lleva bastantes años y todo está en los Storyboard, absolutamente todo está dividido en Storyboard, menos mal, pero la mayoría de cosas están en Storyboard. ¿Tú sabes el tiempo que puede significar ir paso por paso migrándolo, probar? O sea, es increíble, o sea, es increíble que de repente digan esto y se ha añadido

otra cosa, porque no acaba aquí, sino que sigue en esta beta, justo debajo hay otra cosa más, más grave diría incluso, y es que te dice que próximamente van a deprecar los IBDesignable, es decir, para los que no estéis muy metidos en el mundillo, tú puedes definir lo mismo que tú vas al Storyboard y digamos que puedes en las vistas cambiar fuentes, cambiar textos por diseño, el propio diseño, puedes ir modificándolo, pues esto

te hace lo mismo. Sí, aparte del inspector de propiedades, que son parámetros que puedes cambiar dentro de la interfaz gráfica, que no tienes que programar, sino que tú tienes botones, selectores, selectores que dices, pues fuente de 14, fuente de tal, y todo eso se cambia a nivel de diseño. Eso es, pues te puedes crear tus propias propiedades que quieres cambiar también, digamos, de manera gráfica, te la puedes hacer, pues yo qué sé, le quieres decir, quieres cambiar

que todavía no está hecho, yo qué sé, el color del sombreado o el radio del sombreado, cosas así, pues te creas tu propiedad y la expones. Yo lo uso mucho para el corner radius de las esquinas, por ejemplo. Te creas una extensión de la UI view o una UI view tuya particular y con las propias, haces una propiedad designable y lo que haces es que puedes configurártela desde el Storyboard. Pues el caso es que esas se van a deprecar, pues estamos en lo mismo, este proyecto tiene

varios componentes con esas propiedades y si ponen que lo van a deprecar, significa que en Xcode 16 o en Xcode 14, o sea, 15.3 o 4 que salgan a abrir este año, ya no se van a poder utilizar. Con lo cual, el problema es que si tienes seteado ahí todas las propiedades, en el momento que ya no se usen, pues esas propiedades se desetean y ya no tienen los parámetros que has puesto, ¿no? Y ahí ya es cuando puse yo ese tuit que Apple está matando poco a poco, primero, no diría

UIKit entero, sino ciertas partes como es el Storyboard, que recordemos que aparte de que yo creo que las tripas del Storyboard es bastante complicado, todo el código que te genera esa parte gráfica, no creo que sea algo muy sencillo, aparte ya tiene años y esa base de código, admiro a la gente que la tenga que tocar, ¿vale? Porque no creo que sea una tarea sencilla, pero a lo mejor no cargarse UIKit, pero ir

dejando los Storyboards de lado, que ya han tenido varios problemas y ha habido muchas versiones de Xcode que no funcionaban como deberían, los Storyboards grandes, como no tengas un equipo potente, no hay Dios que los mueva, han hecho varias correcciones, pero bueno, siempre ha sido un componente bastante polémico, digamos, dentro de Xcode y yo creo que Apple con este movimiento de, primero, no corregir ese error, y segundo,

decirte de repente que van a deprecar una de las funcionalidades avanzadas, digamos, que ofrece el Storyboard, para mí quiere decir que en Xcode 16, no sé, quizá tengamos todavía Storyboard, pero ya con idea de ir pensando que en una o dos versiones se acaba el chollo, no sé cómo lo ves tú, Julio. A ver, yo es que lo que veo son algunas cositas, ¿vale? Me refiero, yo la última vez que toqué UIKit, ¿vale?

Con un palo, fue cuando di la parte de formación correspondiente en el Bootcamp, ¿vale? Que como los oyentes ya saben, el Bootcamp de Apple Coding Academy, pues, incluye el módulo de UIKit, porque obviamente UIKit a día de hoy sigue siendo importante. Entonces, cuando he ido, esta última vez, y luego cuando de vez en cuando me toca una aplicación de un cliente, tengo que tocar algo de UIKit, lo que yo me he dado cuenta

es que, uno, no podemos olvidar que Apple recomienda encarecidamente desde hace tiempo en todos sus vídeos de UIKit que no usemos SIF, que no usemos X y VES, sino que usemos Storyboards, ¿vale? Porque es lo que Apple recomienda. Sin embargo, los Storyboards históricamente siempre han tenido problemas de redibujado, de tú haces un cambio y no se refleja y tienes que salirte del código y volver a entrar,

de pronto se queda atascado, lógicamente tienes que estar refactorizando el Storyboard porque como metas muchas pantallas en un solo Storyboard, como tú bien dices, o tienes una máquina, pues eso, M1 Pro, M1 Max, una máquina así potentilla, con bastante memoria o le cuesta bastante renderizarlo, no podemos olvidar que un Storyboard no deja de ser un XML, que lo que está haciendo es leerse... Pero de un tamaño que no...

que flipas. Claro, de un tamaño gigantesco y que tiene que ser leído y parseado en tiempo real y dibujado con la correspondiente configuración que tú tienes en el XML. Y ojo, porque es inviable que dos personas toquen la parte gráfica de un Storyboard. Exacto. Es que al final... Es inviable porque no es humanamente legible, os quiero decir, tú vas a hacer un Merge de algo que has cambiado y como te dio un conflicto y el propio Git en el Merge se puede

liar perfectamente y cargarse el Storyboard. Entonces Apple no quiere que programemos porque, a ver, seamos sinceros, si ya tenemos una experiencia grande y estamos acostumbrados a manejar con código UIKit, bueno, pues adelante, es decir, se puede hacer con código las Constraints, se puede hacer con código todo, pero hacerlo con código todo, ojito, ¿vale? Pero en fin, hay que tener claro lo que estás haciendo, no es algo que todo el mundo sea

capaz de hacer y, desde luego, el trabajo que te ahorras con los Storyboards a nivel de picar código es bastante importante, ¿vale? Yo no... A ver, yo he desarrollado UIKit tanto programáticamente como a través de XIBs, como a través de UIKit, ¿vale?, a través de Storyboards, y, desde luego, programáticamente es mucho más complicado, sobre todo porque, sí, puede ser, porque yo he tenido alumnos que han podido

trabajar todo programáticamente con UIKit, pero previamente tú te tienes que haber montado una librería que te proporcione una forma simple de no tener que tirar las cientos de líneas de código que te van a quedar si lo vas a hacer simplemente por código, ¿vale? O sea, por código no es la solución, ¿vale? Yo sé que puede haber mucha gente que se sienta más a gusto con eso, me parece genial,

si ya tienes una librería bien montada para hacerlo programáticamente, creo que es la forma mejor para evitar cualquier tipo de problema en el futuro, ¿vale?, y poder reutilizar todo eso, pero, desde luego, repito, en mi opinión no es la solución ideal porque requiere mucho trabajo previo para que eso esté afinado y funcionando bien. Si ya has hecho ese trabajo previo, perfecto, enhorabuena, tienes la solución, pero la

mayoría de los mortales lo que hacemos es tirar de Storyboard a X y B porque es lo que nos facilita mucho ese aspecto. Pero como digo, parece que hay como una serie de errores, ¿vale?, que es a lo que iba, una serie de problemas con los Storyboards de redibujado, por ejemplo, los Designables, a mí me han fallado históricamente, es decir, es normal que de pronto el Designable te dé un error y te diga, no se ha podido compilar o no se ha podido generar la propiedad y tienes

que salir, volver a entrar, a veces ni siquiera son capaces de... a lo mejor se dibuja o no porque sabes que los Designables tú puedes cambiar, por ejemplo, yo lo hacía, la propiedad del Cornet Radius, la cambias en lo que es el inspector de propiedades y se cambiaba en la propia interfaz y veías el efecto en la propia interfaz, pero eso funcionaba cuando le daba la gana, cuando no, etcétera, entonces yo lo que veo, en mi opinión al respecto,

es que todo lo que a Apple le va a suponer un tiempo de encontrar por qué algo no funciona, su solución va a ser, lo quito y se acabó el problema, ¿vale? Es un poco como lo que han hecho con Swift Data, es decir, yo tengo un error, Swift Data funcionaba perfecto en segundo plano, ¿vale? Perfecto, hasta la beta 7, perdón, hasta la beta 6 de Scope 15, Swift Data funcionaba perfectamente todo en segundo plano y tú ponías un task

y metías una carga en batch de miles de registros y la app no se paraba ni tenía ningún problema, iba genial, pero ¿cuál fue el problema? El problema es que en el momento en el que la base de datos grababa la información, no había forma de conectar esa llamada para que la interfaz se refrescara sobre lo que se había rellenado.

¿Qué ha hecho Apple? Decir, por la calle del medio lo meto todo en el main actor y ya tomás por saco, ¿vale? Entonces, ¿qué ha hecho? Cargarse la concurrencia para que la interfaz se refresque cuando hay un cambio en SwiftUI, es decir, han tirado por la calle del medio por la solución chapuza, fácil, rápida e ineficiente.

¡Hostia, Apple! Y esto del designable me suena a eso, me suena a esto es un marrón que hizo alguien que no sabemos ni quién es, que ya no está en Apple y que a saber qué puñetas hizo este por dentro para que funcionara, ¿quién se va a atrever a tocar este código? Lo quitamos y a volar. Es que me suena a eso, yo no sé cómo lo ves tú.

Sí, sí, sí, yo de hecho en su día yo me parecía cuando sacaron Swift Playgrounds que la estrategia de Apple iba a ser como dejar de lado Scope o dejarlo como muy avanzado y ir vitaminando Playgrounds, pero también resulta que Playgrounds de repente dejó de hacerle caso, luego saca dos cosas cada dos años. Entonces me tiene un poco confundido, pero esto sí que suena a esto es algo que hemos arrastrado siempre, porque de hecho yo me acuerdo que de una versión menor a otra, de repente había veces que estabas

dos o tres meses trabajando en una versión de Scope que cada poco tenías que, yo me acuerdo de cerrar y abrir Scope cada poco porque el Storyboard se iba a tomar por saco. O sea, me acuerdo de estar tiempo eso hasta que se acaba la siguiente versión de Scope, rezabas un poco y ostras, en esta sí funcionaba, pero que se te iba...

Luego, por ejemplo, a mí muchas veces no me encuentra cuando me pongo en una de las vistas, no me encuentra la clase que tira de esa vista y es imposible. Tengo que cerrar el proyecto y volverlo a abrir porque no hace el match directo. No sé, yo creo que sí que Apple es... A ver, se junta que tiene muchos esfuerzos en la parte de Vision Pro, se junta que tenemos esfuerzos de lo que hemos hablado muchas veces, que hay escasez de personal cualificado, entonces

pues no sé si les cuesta encontrar ingenieros y que aparte Apple tiene un poco esa política de no quiero contratar muchísima gente, quiero contratar con ojo a gente que sea buena y no meter a 800 en un proyecto y que al final nadie sepa hacer nada. Y están empezando como a elegir sus batallas.

En plan, ahora tenemos otro sistema más que es Vision OS, pues eso, necesitamos más gente manteniéndolo, pues los marrones pues vamos a chutarlos y vamos a ir quitándolo y sobre todo teniendo alternativa, porque te dicen, pues mira, yo quiero que lo migres todo a SwiftUI. Y otra cosa que hemos hablado siempre, Apple cada vez que saca un sistema operativo nuevo, todas las aplicaciones de la propia Apple, podcasts, mensajes, todo, ya nos tienen que dar soporte a lo anterior.

Es decir, que en iOS 17 probablemente la aplicación de mensajes a lo mejor ha adoptado una API nueva que no estaba en iOS 16 y esa parte de código hasta luego. Ahí se queda en el repositorio por si sacan una versión menor de iOS 16 para compilarlo todo junto, pero eso no lo vuelve a tocar nadie y en la base de código del sistema actual ya no está.

Y si ahí se presenta un error, nadie lo va a corregir. Ese error va a quedar siempre. Al final, ¿qué sucede? Por ejemplo, Playgrounds, no la app Swift Playgrounds, sino lo que es el proyecto de Playgrounds en Scope, tiene un error desde hace... pues creo que desde... porque claro, yo en las formaciones uso mucho Playgrounds, porque es el entorno ideal para educación, para enseñar Swift y para enseñar temas prototipados de red, etcétera.

Bueno, pues Playgrounds se va estropeando cada vez más. O sea, Playgrounds ha tenido un error histórico desde, creo yo, prácticamente Scope 12, estamos en la 15, de que cada vez que creas una página nueva, el analizador de código se resetea y deja de funcionar. Y tienes que salir del Playgrounds y volverlo a cargar otra vez, para que el motor de escritura, el motor de lo que sería el LSP, el motor de escritura de código, de ayuda...

El archiconocido proceso SourceKit. Exacto, el proceso SourceKit famoso que se colgaba y que se sigue colgando cada vez que le da la gana y eso que se supone que cada año lo reescriben desde cero. Sí, sí, eso es una cosa que yo flipo. Pues eso da problemas con Playgrounds y no han sido capaces de arreglarlo. ¿Y este año han conseguido arreglar SourceKit en SwiftUI? Pues hombre, en una parte sí, pero en otra no.

Cuando ya te metes a profundidad dentro de varios niveles de SwiftUI, se sigue perdiendo igual y te sigue dando errores que no existen o te da cosas raras. Luego, además, este año no sé por qué le han dado prioridad a la construcción sin usar los closers múltiples de cierre, cosa que yo cuando hago un botón, para mí un botón en SwiftUI es botón, llave, acción, espacio, label, dos puntos, llave y siguiente.

Bueno, pues no hay huevos de construir el código de esa manera. Entonces es como, vamos a ver, o tonterías como lo que ya hemos comentado aquí alguna vez, de deprecar Corners Radius. Pero perdona, ¿qué estás haciendo? Son cosas que es como, no sé, como si tuvieran a alguien dentro que está tomando decisiones sin sentido a base de no me voy a molestar.

Entonces, no sé, no entiendo, no entiendo hacia qué dirección van realmente. Y a mí me molesta bastante el hecho de que un entorno como Playground que tiene un potencial brutal esté, sientas sinceramente que está abandonado porque probablemente quien hizo el Playground en su momento ya no esté en Apple y nadie se atreve a tocar aquello porque, hostia, espérate, a ver esto cómo está hecho.

Y en muchas ocasiones esa es la impresión que te da, que Apple abandona desarrollos porque la persona que los estaba haciendo ya no está en Apple y nadie se atreve a meterse en ese código a buscar o solucionar errores. Y como ahora todos son esfuerzos a los nuevos sistemas, pues el resto de cosas que la den por saquito. Entonces, no sé, se me escapa.

No sé cómo ves tú esto al respecto. Yo es que tengo la misma opinión que, además, cosas como, por ejemplo, Playgrounds en su día, yo cuando lo mostraron aluciné. Dije, sobre todo, o sea, me viene bien a mí que ya llevo un tiempo, pero para alguien que está aprendiendo esto es una herramienta y casi que es un básico.

Porque ahora yo creo que cada lenguaje que crean es como lo primero que crear es un Playground para que la gente investigue. O sea, es lo primero que tienes que hacer. Lo mínimo que tiene que tener un lenguaje es un Playground para que la gente en tiempo real, sin tener que compilar, lo pueda hacer. Y seguramente que sea algo como tú dices, porque supongo que, claro, haya muchas dependencias que se comparten y parece que actualizan ciertas dependencias, pero que hay otra capa que eso que la ha hecho

alguien que ya no está o hay un marrón ahí de un código que se lleva tiempo sin tocar y que va a llevar tiempo, valga la redundancia, el arreglarlo o al adaptarlo a las nuevas dependencias que se han cambiado y no se hace. Se deja así un poco como está, no se dice nada y se deja como está y ya veremos. Son cosas que no entiendo y desde luego lo que se ve muy claramente, en mi opinión, es que Apple tiene ahora mismo una carencia muy grande de talento a nivel de desarrollo,

que le falta tener más gente suficientemente cualificada para hacer todo lo que se han propuesto hacer. Y luego aparte, si juntamos lo que se comenta en los mentideros de que hay una presión terrible, de que los desarrolladores están echando más horas que tal porque hay una presión absoluta por entregar ciertos hitos o ciertas fechas, etcétera, y que incluso niegan vacaciones, etcétera, hay siempre ahí como un rumor por encima.

Se han visto, lo hemos comentado en alguna ocasión, de una empresa que compraron hace poco en Barcelona de inteligencia artificial en el que uno de los empleados empezó a decir que ahí había un abuso terrible por parte y que Apple no hacía nada ni lo impedía. Y hay mucha gente que ha salido de Apple en los últimos años.

Por ejemplo, recordamos a nuestra conocida Natalia Panferova, la muchacha esta que tiene el blog este de Neil Coalescence, que era una de las ingenieras de SwiftUI, pero que salió de Apple. Y yo no le he oído decir nunca por qué. Vale, sí he decir que estaba muy orgullosa, tal y cual, pero sí he oído a mucha gente decir que trabajar en Apple te quema mucho porque los niveles de presión que hay son muy altos y porque, lógicamente, se les está exigiendo un nivel de plazos,

entregas, trabajo, etcétera. Y yo lo que veo desde fuera es que ahora mismo Apple tiene una enorme carencia de perfiles de alto nivel que se encarguen de tenerlo todo al día. Entonces, yo lo que veo es que no dan abasto. Esa es la impresión que da desde fuera, que no dan abasto.

Y volvemos a repetir, esto no es cuestión de dinero. Tú puedes tener todo el dinero del mundo, que Apple lo tiene, ¿vale? Pero esto no es cuestión de dinero, es encontrar a gente que tenga el nivel de cualificación y conocimiento para poder hacer eso. Y eso que se le está pidiendo requiere de tan alta cualificación que, uno, es muy difícil de encontrar en el mercado.

Dos, las leyes de trabajo en Estados Unidos no ayudan porque no podemos olvidar, por ejemplo, que Natalia vive en Nueva Zelanda y trabajaba en remoto con Apple. Es decir, estaba contratada desde Nueva Zelanda. Y Apple tiene sedes de desarrollo en un montón de países como, por ejemplo, tiene en Irlanda gente de desarrollo, tiene también aquí en España, tiene ciertos equipos que trabajan.

Porque es imposible que todo el mundo esté en el Apple Park porque, además, irse a mudarse allí a California, en fin. Barato no es. Claro, por mucho que te paguen, a ti te pueden estar pagando fácilmente como ingeniero senior en Apple, pues fácil, 300.000 dólares al año, que aquí en España sería como algo abusivo en el sentido de decir, Dios mío, ¿qué es lo que estás haciendo? Y se lo están pagando un desarrollador senior, ¿vale? No es algo que sea un perfil muy alto

y le pueden estar pagando fácil 200, 250, 300.000 dólares al año. El problema es que para pagarte una casa compartida ya está gastando 100.000, ¿vale? Porque ese es el nivel que ahora mismo en San José, en Cupertino, en fin, en toda esa zona de lo que es el Valle de Santa Clara.

Entonces, eso también es un problema para Apple, para captar talento. El problema de que sus oficinas son maravillosas y estupendas, pero vivir allí es muy caro, no hay suficiente sitio y luego pues tiene que contratar a nivel internacional. Y, obviamente, tener una persona que te está trabajando desde Nueva Zelanda o desde España supone, pues bueno, pues aquí en España tenemos nueve horas más que en California.

Entonces, supone que si yo estuviera trabajando con Apple desde España, tendría que sincronizarme con sus horarios, ¿vale? Entonces, en fin, es bastante complicado y yo, en mi opinión, creo que Apple ahora mismo está superada a todos los niveles y necesita incorporar a más perfiles y no los encuentra, porque os garantizo que no los hay en el mercado.

Entonces... Sí, sí, pero es que bueno, yo también lo veo en España, que en España perfiles altos de programación es que son muy difíciles de encontrar también. Y ya no hablamos de perfiles de entornos Apple, hablamos de perfiles de programación. O sea, tú hoy día encontrar a un tío programador que pilote a nivel premium máximo, o sea, un Mark o un Arturo o un Joe o alguien así que esté a un nivel de experiencia, de conocimiento,

que sea capaz de coger un proyecto que no es suyo y arreglarlo o entenderlo en horas o en pocos días, hoy día somos unicornios, macho. Y como eso te digo, pues eso un Antonio Leiva en Android o alguien que tenga esos niveles de ser capaz de entender el código un poco más allá.

Entonces, hay muy poca gente que tenga ese nivel tan alto de conocimiento, de abstracción y de análisis. Y claro, y luego encima, en un país como España, donde no se valora a la gente en la medida de lo posible y al final se provocan envidias, susceptibilidades, en fin, aquí tenemos un tejido productivo maravilloso, pues ya ni te cuento. Entonces, en fin. Pues sí, pero esperemos, Julio, yo tengo la esperanza de que la siguiente beta, de repente, mejore esta parte.

Ojalá también para la parte que te toca. Bueno, que nos toca a todos, pero bueno, el deseo que tienes tú de ese refinamiento de Swift Data. Y quiero acabar lo que he estado haciendo yo con algo un poco más positivo, que siempre parece que venimos aquí a contar penas y desgracias, que es que, por ejemplo, en mi trabajo coincide que tenemos un equipo de IOS medio, medio, no voy a decir grande, pero medio, que yo en las empresas que me he cruzado no es muy normal.

Lo normal es que sean 1, 2, 3 a lo sumo. Pero lo bueno de tener un equipo grande o medio y sobre todo de tener perfiles medio o senior, es que se genera mucho debate y se aprende muchísimo. Y es casi como una recomendación que os hago a los que estéis empezando, que si tenéis oportunidad de elegir, porque se lo digo a los que están empezando, porque los que llevan tiempo seguro que ya lo han descubierto también, que es muy bueno estar en un equipo y con gente que sabe tanto

o más que tú, porque de verdad que se disfruta por eso. Porque hay cosas que yo al final muchas veces en otros puestos de trabajo que tenía, pues acababa teniendo que hablar con Julio fuera de mi área laboral. Pero aquí puedes aprovechar tu área laboral a algo que a la empresa también le viene muy bien, que es de la que estás desarrollando.

Oye, voy a hacer esto. ¿Qué opináis de tal cosa? ¿Qué opináis de esto? Oye, creo que aquí voy a montar esto de esta manera. ¿Qué os parece? ¿Me dejo algo o no? Porque muchas veces es casi como hablarlo en alto, que te ayuda un poco a ti a darle una vuelta más. Y aparte, que otro te puede decir algo que, yo lo que digo, que a ti se te ha escapado o que no has puesto en la balanza donde has decidido lo que hacer, no está puesta esa

acción. Y nada, pues ahora mismo en el trabajo que estoy, pues tengo la oportunidad de hacerlo y la verdad que es una experiencia muy buena que he tenido en estas últimas semanas. Por dar la nota positiva. Sí, al final, si se genera un debate interesante sobre, pues eso, porque es una cosa que yo muchas veces le digo a los alumnos, que es importante que los equipos estén bien sincronizados, que todos trabajen a la par, de que haya debates sobre cómo abordar tal problema, tal otro,

etcétera. Entonces, bueno, la verdad que tener ese tipo de... y que te hagan ver cosas que a lo mejor tú no estás viendo o no has caído, etcétera, siempre es algo que es bastante interesante. Bueno, incluso Julio, y seguro que te pasa a ti también, a mí cuando he dado cursos me ha pasado alguna vez, que a veces me han hecho una pregunta de, pues esto jamás lo había visto desde este enfoque y alguien que a lo mejor no había programado en su vida,

de repente te abren los ojos de algo, pues tienes razón de esto, que a lo mejor investigas y luego le encuentras alguna pega a lo que te cuentas, está claro. Pero muchas veces el simple... y yo lo hago muchas veces, lo de dar... incluso cuando estaba en un equipo más pequeño, a lo mejor entre todos los de tecnología, aunque no fueran programadores de iOS precisamente, ponía la idea, porque programadores de Android o de backend, a lo

mejor en eso también se les ocurría algo o con su experiencia y muchas veces te daban como otra visión. Y nada, que me estoy extendiendo un montón, Julio, cuéntanos... bueno, primero cuéntanos qué tienes en la muñeca, que te veo como que te cuesta un poco levantar la mano izquierda y qué has estado haciendo estas dos semanas. He estado intentando no darle golpes con la hebilla de la...

no darle golpes a la pantalla del Apple Watch Ultra 2 con la hebilla de la correa de trenzado fino, que... fino, fino filipino, trenzado filipino, bendito sea el poder de Jobs. ¡Madre mía! Uf, qué mala impresión, de verdad. Yo entiendo perfectamente el objetivo del nuevo tejido de Apple, lo aplaudo, ole Apple, pero la calidad es espantosa.

Para mí, personalmente, no me gusta la calidad que tiene la correa. Lo que es la correa de trenzado fino me parece que no es un material agradable al tacto, que no es un material que dé una impresión de calidad premium. Recordemos que son 80 pavos de correa, ¿vale? 70-80 pavos de correa. Y luego, encima, no está bien pensada, porque la hebilla metálica, cuando te intentas quitar el reloj, como tiene como una especie como de huecos, ¿no? Como que va pa-pa-pa-pa-pa-pa-pa, ¿vale? Pues al

tirar de ella, lo normal es que, con la hebilla, le hagas a la pantalla ¡plof! y le metas un guantazo, que es como, Dios mío, o sea, te da un mal rollo increíble, ¿vale? Veas pasar toda tu vida por delante. Sí, sí, totalmente. Entonces, es que no tiene ese tema, ¿vale? El material que tiene, pues es el trenzado fino de Apple, ¿vale? Que es un nuevo material creado por Apple, con huella de carbono cero, que además viene

en la caja indicado con el símbolo de huella de carbono cero. Es un material que está hecho en un 68% de material de consumo reciclado, ¿vale? O sea, se supone que es como una especie de material a base de reciclado de otros productos, ¿vale? En el que se ha hecho una forma muy, muy, muy fina de material y con ese hilo fino, que tiene un aspecto como de, como una especie de hilo de pescar, ¿vale? Es como un nylon muy fuerte, ¿vale? No es algodón, que es

un hilo más suave y tal, sino es como un hilo de nylon, pero como más grueso, como más tirando a hilo de pescar, ¿vale? Pero, insisto, muy finito. Entonces, ese hilo lo han creado en un patrón trenzado, ¿vale? Creando una textura determinada, que es el que permite hacer ese tejido con el que están hechas ciertas fundas de las que hay ahora para los iPhones, de Apple, ¿no? Algunas correas del Apple Watch, etcétera, etcétera.

Yo es un material que ya probé en el Apple Store y es que no, no, no, no, no tiene, no... Repito, aplaudo el gesto de Apple, entiendo perfectamente que lo hayan hecho, me parece algo que está bien hecho, porque es algo para el planeta, pero hemos perdido como usuarios porque ahora más que nunca el precio no está justificado a nivel de la sensación de calidad percibida, ¿de acuerdo? Entonces, pues no, no me parece y al final pues acabas tirando

de una correa de AliExpress, ¿vale? Porque es que es lo que tiene, ¿vale? Entonces bueno, pues en fin. Pero bueno, en cuanto a lo que es el reloj, pues bueno, venía de un Apple Watch Series 4 y bueno, pues entonces al final pues ese Apple Watch Series 4 pues se ha jubilado ya porque además él estaba rankeando, empezaba a fallarle la batería, los sensores, a lo mejor prácticamente no me movía durante el día y de pronto cerraba el círculo de ejercicio

y era como pues no sé qué he estado haciendo para esto, no soy merecedor de tanto, de este cierre, ¿no? Y ahora bueno, pues ya con este pues ya sí tengo un reloj más moderno, con conectividad móvil, etcétera y bueno, la verdad que muy bien, muy contento. Entonces bueno, esa ha sido mi novedad, ¿vale? Yo en este, en estos días, ¿vale? Aunque no soy persona que le guste mucho hacerme público a este sentido, pues he cumplido 48 años

ya, que se dice pronto, y entonces bueno, pues este ha sido mi autorregalo de, autorregalo y regalo a nivel general de la familia, de cumpleaños, ¿no? Entonces bueno, pues ha sido un poco el tema. Pero pareces más joven, Julio, que la edad es un número. Por el reloj, ¿no? Lo has dicho.

Te has comprado un reloj que es para gente que se juega la vida. Total, de hecho sentí unas ganas locas de subir el Everest en cuanto me lo puse, fue como un, Dios mío, tengo que ir al Everest, ¿no? Entonces bueno, pues eso es un poco el tema. Así que bueno, la verdad que bien, estoy contento en ese sentido, ¿vale? Y además pues ahora con el tema de la conectividad móvil, pues aunque hace cosas raras, ¿vale? Yo no sé si lo has notado tú, pero de pronto te llega un mensaje al móvil pero no te llega

al reloj o te llega primero el reloj y luego tarda en llegar al móvil o de pronto me llaman y el móvil no se cosca pero me salta solo en el reloj. Hace cosas raras, ¿vale? O sea, no sé yo si eso es muy normal o no. Pues a mí sí que me funciona.

Eso sí que me sincroniza bien, ¿eh? Pues a mí, por lo que sea, no sé qué le pasa, pero no lo está haciendo bien. De hecho, ni siquiera se sincronizó bien la primera vez. Tuve que volver a configurarlo desde cero porque, no sé por qué, se le fue la olla. No enviaba, o sea, yo le ponía esferas nuevas, ¿no? La esfera esta del cacharro, ¿vale? Y no había manera de que funcionara bien.

Entonces, bueno, pues es una cosa un poco rara. Y luego también, bueno, también depende un poco de las, por ejemplo, o sea, no sé, por ejemplo, si funciona bien, por ejemplo, yo qué sé, pues con Telegram, ¿vale? Si te llaman por Telegram, sí salta en el reloj. Pero si te llaman por WhatsApp, no. ¿Por qué? Porque WhatsApp no tiene bien integrado el tema de las llamadas IP porque tienes que propagarlo al Apple Watch, tienes que tener una app de Apple Watch para que lo coja porque

si no, no lo coge. O sea, que es un problema de desarrolladores, ¿vale? Entonces, bueno, pero bueno, en ese sentido, pues está… Estoy contento, la verdad, que estaban tanto bien en ese sentido. ¿Tú cuál ha sido tu percepción de reloj? Del Apple Watch.

A mí… Porque has cambiado también, ¿no? De Apple Watch. Sí, sí. De hecho, el salto, o sea, porque tenía uno… Joder, ya no sé por qué series van. Tenía el anterior, el S8, con lo cual de velocidad y eso, pues no lo he notado, la verdad. Lo que sí que he dado el salto al Ultra y estoy maravillado con la batería.

Sí, pero fíjate que… A ver, lo de la batería, genial, ¿vale? Yo creo que es lo mejor que tiene. Pero luego, aparte de eso, sigue siendo el mismo dispositivo. O sea, vamos a lo de siempre. Yo salto de un 4 a un Ultra 2, es decir, es un salto mayestático y, sin embargo, no podría decir, oye, es un dispositivo nuevo que me ha cambiado la vida.

No. Es el mismo Apple Watch, pero con una pantalla más grande, por lo tanto es más fácil de ver, con una batería que le dura más, con mayor brillo en la pantalla, pero a nivel de funcionalidad y usabilidad no he visto cambio. Espero verlo a partir de ahora, cuando empiecen a salir aplicaciones para WatchOS 10. Pero por ahora, en lo que es el uso en sí, no he notado diferencia en ese sentido.

Te vas a quedar, Julio, con las aplicaciones del sistema, como me llevo yo. Yo uso mucho el Watch, sí que es verdad que es un dispositivo que me encanta, pero es que creo que tengo dos aplicaciones instaladas. Sí, de terceros hay muy pocas apps porque no están bien hechas. Y sí que está claro que el salto al Ultra… Eso, la pantalla también, que sea algo más grande, se nota porque puedes ver más información y como más clara y tal, pero sí que es verdad que

en ningún momento yo mi salto, que lo veo más que de generación a otra, lo veo del normal al Ultra, pues más pantalla y más batería que… A ver, sí que era un problema porque yo el iPhone me dura un día, lo cargo por la noche y ya está, punto. Pero el Watch es un dispositivo que duermo con él.

Entonces, claro, tenía como mucha rutina de lo cargo mientras me ducho y luego lo tengo también un rato mientras estoy trabajando o tal. Tenía que andar un poco pensando. Ahora es que muchas veces ni me acuerdo de cargarlo. De hecho, en dos horas ya lo tienes cargado. También es una cosa increíble en ese sentido. Yo casi aguanto con el rato que estoy entre que me ducho y me preparo.

A lo mejor son 10 o 15 minutos. Además, lo tengo en el cargado rápido que trae y cada tres días sí que aprovecho para cargarlo a tope cuando estoy presentado trabajando. Pero si no, me aguanta perfectamente con esas cargas que le doy puntuales. Sí, yo… Me llegó el día 5 y desde el día 5 estamos a la noche del 8 al 9.

Lo he cargado una vez y ahora está pues… Yo creo que aguantará toda la noche, ¿vale? Y ahora con eso… Claro, porque el problema que tenía también es cuando sales fuera y tiras de datos que se descargaba pero visto y no visto. Pues ahora cuando voy a correr o cuando saco al perro o cuando voy a comprar el pan, pues ya me dejo el móvil en casa porque voy escuchando podcast con el reloj y no consume tanta batería como consumía

antes. Pues sí, la verdad es que sí está bien. Y luego aparte de eso, pues ya el pasado día 2 de octubre, el lunes, pues hemos empezado el Swift Developer Program y entonces ahora estoy con 40 alumnos, que tú estuviste además en la inauguración del curso académico, pues con 40 personas, 40 almas que quieren aprender Swift, SwiftUI, asincronía, etcétera.

Y una introducción pequeñita a Vision OS y desde luego, pues la verdad que es algo interesante, ¿vale? Es algo que creo que puede ser muy bueno y que, bueno, pues ahora estamos en el comienzo. Es decir, estamos en el comienzo de que es una variable, que es una constante, operadores, flujos, for in, while, no sé qué, tal y cual.

Estamos con todo el comienzo. La primera semana hemos terminado, son clases de lunes a jueves, por lo tanto son 16 horas de formación por semana y en esas primeras 16 horas hemos llegado en Swift hasta todo lo que es la parte básica, ¿vale? Es decir, tipos de datos, la parte de lo que serían operadores, flujos, luego hemos visto las colecciones, ¿vale? De arrays, diccionarios, sets, etcétera, cadenas, tuplas, hemos visto también el tema del hashable, en fin, pues un poco lo que sería todo ese

embrollo, ¿no? Y por supuesto siempre comenzamos con la presentación, que es el primer día, ¿vale? De historia del desarrollo de entornos Apple, ¿no? Que al final es ponerlos un poco en contexto y meterlos, ¿no? Dentro del storyline de Swift y de lo que es y lo que ha supuesto y cómo hemos ido avanzando desde los Apple II hasta los últimos Vision OS, en fin, todo ese tema que fue una clase que también gustó bastante, ¿no? Entonces, bueno, y ahí tienen

ahora ya su primer conjunto de ejercicios. ¿Qué tienen que hacer? Un conjunto de ejercicios de, bueno, pues tienen 50 ejercicios de Swift para hacer en distintos niveles, todos de Swift básico, y bueno, y a ver qué tal les da lo que es la formación. A ver si, porque muchas veces cuando te pasa que lo ves al revés.

Hay veces que te parece que te están hablando en arameo y luego vas y te pones a hacer ejercicios y oye, más o menos te desenvuelves, pero es que pasa lo contrario. Tienes pinta de fácil, pero luego cuando bajas al barro alucinas un poco. Pero una pregunta, aquí estamos. ¿Te gusta más dar esta parte, digamos, básica o prefieres ya la parte avanzada ya de más de programar para iOS o eso? ¿O te gusta esta parte de las bases de Swift? La verdad que lo disfruto

todo cada uno a su manera, ¿vale? Porque al final esto es un poco, lo hemos comentado en algunas ocasiones. Yo cuando doy formación, repito mucho, ¿vale? A mí mucha gente que viene me dice, no, la gente que trabaja conmigo, o cuando hablo con empresas, no, no, nuestra gente tiene ya dos años de experiencia, tres años, cuatro años de experiencia, saben programar en Swift, lo conocen bien y tal.

Me he encontrado tantos casos de gente que lleva 2, 3, 4, 5 años manejando Swift y cree que sabe Swift, pero no lo sabe, que curiosamente cuando luego les preguntas después de esta semana, porque claro, hay gente que ha empezado el Swift Developer Program que ya lleva tiempo trabajando con Swift, ¿vale? Hay gente que empieza desde cero, pero hay gente que lleva tiempo trabajando con Swift.

Y les preguntas y ¿qué es lo que sucede? Pues que te dicen que, bueno, pues que ellos están descubriendo cosas que no conocían. Cosas que no conocían. Que no había visto de Fer en su vida. Claro, o sea, que no conocen cómo se hacía, o que no sabían qué era, o que no sabían por qué se hacía así y simplemente lo hacían.

Cosas así. Entonces, bueno, pues es algo que siempre me gusta, que disfruto y que al final pues es una cosa que es bastante sorprendente, ¿no? Ver a la gente, ver cómo va reaccionando, ¿no? Entonces, bueno, pues ahora mañana empezaremos ya, mañana lunes, con la parte de Swift intermedio, que son funciones, programación orientada a objetos, en fin, pues un poco ya entrar con palabras mayores, ¿no? Y bueno, y a ver qué tal se les ha dado el tema de la...

el tema de los ejercicios, ¿no? Que al final, como tú dices, bueno, hay algunos ejercicios muy simples, ¿no? De muéstrame un programa que haga los diez primeros números, ¿no? Pero luego hay otros al final que es como, venga, hazme una ecuación de segundo grado, ¿no? Es como ya la cosa se pone un poco más intensita, ¿no? Pero bueno, tienen que ser capaces de resolver estos ejercicios y se les han dado las herramientas para que puedan hacerlos.

Así que nada, a ver qué tal, qué tal se da. Bien, Julio, pues nada, pues que siga así de bien ese curso, a ver qué te cuentan mañana y yo creo que ya podemos pasar al apartado de noticias. ¿Y qué ha pasado en esta semana? Porque, macho, el tema Swift tampoco para nunca, ¿no? Siempre hay cositas. Pues sí, no ha sido la semana con más movimiento, pero bueno, sí que se han presentado algunas cosillas y las vamos a resumir.

Como digo, tampoco es nada del otro mundo, diríamos que son breves, por así decirlo. Pero bueno, la primera de ellas es que Apple, esa empresa hermética cerrada que solo hace su software y demás, pues sigue librando librerías. Y la última tiene el nombre de Swift Async DNS Resolver, ¿vale? Y como no podía ser menos y su nombre indica, pues es un grapper de varias librerías ya existentes en C, pero con APIs y estructuras de datos más, digamos, Swift-friendly, no sé cómo traducirlo, más

amigables con Swift o más orientadas a utilizar en Swift, pues para eso, para trabajar con resolución de nombres de dominios. Nada que nos vaya a cambiar la vida, pero bueno, a lo mejor te pillan algún proyecto que tiene que ver con esto o por lo que sea necesitas en tu programa, pues hacer este tipo de peticiones.

Y antes probablemente tendrías que bajar a algo compatible con C y bastante farragoso para conseguirlo. Y ahora, pues importas con Swift Package Manager esta librería. Y es que estoy viendo aquí los ejemplos y obviamente utilizas InkAway, ¿vale? Y nada, creas un resolvedor, un resolver, vamos a decirlo en inglés, que queda mejor y le haces las queries con el dominio y te devuelven la IP.

Simple, sencillo y para toda la familia. De hecho, esto viene un poco de la mano de una librería que yo cuando la cuento a los alumnos se quedan flipando como diciendo, ah, pero eso está ya, eso se puede usar, es la librería de HTTP, ¿vale? O sea, ya sabes que cuando yo hago un request de HTTP todos los parámetros hay que ponerlos a mano, ¿vale? Hay que poner a mano todos los content type, o sea, digamos los parámetros de cabecera, ¿no? El content type, el accept, el authorization,

en fin, los métodos hay que ponerlos a mano también con una cadena, etcétera, ¿vale? Pues ya hay una librería de métodos HTTP para cliente que permiten, que es una librería de Apple, que están en pruebas, ¿vale? Pero que se puede usar y que te trae numeraciones para todo eso y diccionarios donde mete las distintos elementos, un cambio de los requests, etcétera, y que la verdad pues es interesante, o sea, que Apple en ese sentido, claro, no

podemos olvidar que Apple está refactorizando toda la librería de Foundation y la parte de red, es una de las partes importantes. Pues se puede usar y se usa, Julio, porque yo ya la estoy usando. De hecho, bueno, todavía no está publicada la aplicación, todavía está en beta, ¿vale? Pero en un proyectillo que estoy metido, pues había que hacer una, es una aplicación sencilla, pero bueno, era todo nuevo y dije, uy, pero se basaba en peticiones HTTPS y dije, pues mira, qué mejor prueba

que meterla aquí y sí que, pues eso, te evita hacer, porque todos no sabemos, no tenemos nuestros helpers o no sé cómo llamarlo para estas cosas, pues mira, una cosa que te ahorras y mira, la que no he probado y tengo ganas y lo intenté, pero la API no me dejó sacarlo. Bueno, la API más bien el backend.

La que han hecho de OpenAPI, ¿vale? Que es una librería que yo también os hablamos aquí, que servía para la especificación OpenAPI, es una especificación, digamos, para que deberían cumplir, ¿vale? Todas las APIs que hay y que define, pues los para el tipo de servicio, si es un POST, un GET, los parámetros de entrada, la respuesta, ¿vale? Pues digamos que se puede hacer un fichero y en base a ese fichero, pues en muchos lenguajes, librerías como esta que os comentamos de Swiss, te genera todo lo que necesitas.

En Swiss, además, la hay compatible con URL Session, que es el framework que se utiliza en IOS y en los sistemas de Apple para acceder y también lo hay en otros frameworks como pueden ser BAP, ¿vale? Y sirve tanto para eso como para, por ejemplo, si tu backend que se está en Node.js con X framework de los 80.000 que hay, ¿vale? Te puedes portar ese archivo que tú luego le das a los frontend y los frontend, utilizando estas librerías,

se crean sus clases. Ese tengo ganas de utilizarlo y todavía no he podido y fue lo primero que intenté aquí. Digo, a ver si el framework con el que está hecho esto me permite exportarlo, pero no fue el caso. Pero bueno, una librería más que apuntar a las que está liberando Apple.

Y como digo, es un movimiento raro porque Apple precisamente es la empresa que siempre se ha dicho que libera todo con cuentagotas. Pero bueno, parece que la parte está de Swift. No sé si también un poco por qué provocado por esta necesidad de reclutar talento. En su día lo hablamos que para toda la parte de Machine Learning, los científicos, al final estos son más científicos casi que programadores, es gente que se basa mucho en publicar papers, publicar sus estudios.

Digamos que la reputación viene muy condicionada por lo que publicas. Pues Apple se vio obligada a crear una página y a dar visibilidad a la documentación que generaba esta gente, a los descubrimientos que publicaba esta gente. Pues a mí me parece que también hay algo aquí de eso, de que una de las cosas que dice Apple es, te voy a reclutar como programador, vas a entrar en Swift, que es open source.

Entonces si haces librerías, haces cosas, los vamos a publicar. Y es que esta librería, la de DNS, no lo sé, pero esta que os decíamos de HTTP Request, era una librería que empezaban a usar internamente en Apple. Y luego la publicaron a raíz de ser una librería utilizada por ellos.

Y no sé, no puedo estar más alegre porque ya os digo que seguramente estas librerías las acabemos utilizando todos en mayor o menor medida, ¿no, Julio? Pues sí, sí, sí, sí. Es que además, claro, todo esto es una estrategia a nivel de, pues eso, como hemos comentado, si tú tienes la librería de Foundation que está siendo refactorizada, ¿qué haces? ¿La refactorizas tú solo con un personal que no da abasto? ¿O la haces open source y así tienes a un montón de desarrolladores que van a trabajar gratis

porque su cobro es la reputación de haber trabajado en este tipo de proyectos? Y sobre todo, pues la posibilidad de que la propia Apple se pueda llegar a fijar en ti en un futuro, ¿no? Entonces es una plataforma de descubrimiento bastante importante, ¿no? Entonces yo creo que sí, que efectivamente puede ser una estrategia, una estrategia importante el decir, bueno, todo esto va a ir a código abierto porque así conseguimos que la gente,

bueno, pues pueda haber más gente interesada fuera de Apple y que pueda aportar y que a lo mejor es gente que es incluso de mayor nivel que la gente que puede haber en Apple. Y luego por otro lado, pues como tú has comentado, o sea, Apple empezó a tentar a científicos de Machine Learning para entrar en Apple y todos les decían que no, porque Apple decía, no, no, no, no, el trabajo que tú desempeñes en Apple es de Apple, tú no eres Paco Torres

o Pepe Flores, no, tú eres un empleado de Apple y todo el trabajo que tú hagas científicamente es de Apple. Y entonces, claro, los científicos dijeron, vale, pues como eres de Apple, pues ahí te quedas y te mueres de asco. Y entonces al final tuvieron obligados que decir, pues ya está, pues vamos a tener que poner una página, machinelearning.apple.com, donde los científicos de computación de Machine Learning en Apple publiquen con nombres y

apellidos sus estudios para que esto les dé, porque los estudios científicos, los papers, es lo que es el prestigio de la gente. Entonces, si tú no publicas tus trabajos a nivel científico, esto no solo sucede en Machine Learning, pasa en todos los campos científicos. Si tú como científico no publicas tus trabajos en revistas o publicas papers que se clasifican en ciertas webs, etc., tú no eres nadie.

O sea, para tú ser alguien tienes que haber firmado papers y esto es algo que hace Google, que hace Microsoft, que hace OpenAI, ¿vale? Publicar estos papers para la gente que descubre ciertas cosas. Pero claro, ahí ya entra lo que es el problema de la propiedad intelectual, de la propiedad industrial, de que, pues bueno, yo soy OpenAI y ¿hasta qué punto me interesa sacar un paper donde le enseño a todo el mundo cómo crear su propio chat GPT? Pues resulta que a lo mejor no me interesa.

Y eso es un problema porque la gente que ha creado chat GPT quiere tener el crédito de que han sido ellos los que están detrás de la forma en la que chat GPT está funcionando, repito, a nivel científico, no a nivel de desarrollo. Y si eso pasa a nivel científico, pues obviamente los desarrolladores tres cuartas de lo mismo.

Hola, soy desarrollador y yo quiero que se sepa que yo he sido la persona que he estado haciendo tal cosa o tal otra, o que ha colaborado en tal versión del lenguaje, o que ha incorporado tal funcionalidad, porque eso es prestigio para mí. Entonces, si yo no puedo hacerlo porque Apple no me deja, pues tengo un problema. Entonces, bueno, pues todo esto en cierta forma ayuda a que haya ese elemento y que al final incluso tengamos pues como la siguiente noticia que tenemos, que es un problema que ha habido en Vapor,

que Vapor es otro proyecto de código abierto que si no fuera por la comunidad no podría salir adelante. Vapor ahora mismo es un framework de lado servidor con una calidad y con un acabado brutal. O sea, yo estoy literalmente enamorado de las capacidades y de cómo se está mejorando día a día y evolucionando, y en gran parte esto es posible por la enorme comunidad que hay.

Entonces, toda esa comunidad, ya no sólo a nivel de programación, sino a nivel de atención en los foros de Discord, a nivel de la documentación, que hemos hablado en ocasiones que se está entera refactorizando en DocC, etcétera, todo eso también es importante. Entonces ahora resulta que nos hemos encontrado con que Vapor tiene un error importante, una vulnerabilidad que ha sido corregida y además una vulnerabilidad que ha conseguido su propio código CVE.

Los códigos CVE son códigos que clasifican vulnerabilidades que han sido parcheadas a nivel de seguridad y que demuestran que las herramientas son importantes. Entonces hay un CVE, que es el 202344386, que es una vulnerabilidad de denegación de servicio, que afecta a los usuarios de las versiones afectadas de Vapor, que son todas las anteriores a la 484.2, donde el controlador de errores, de lo que es el manejo de HTTP en la versión 1.0, lo que hacía era cerrar conexiones cuando se producían errores de análisis HTTP en

lugar de transmitirlos y eso podía permitir, atacando por ahí, conseguir un error de denegación de servicio, es decir, que bloquearas el servidor y terminara por denegar la entrada al mismo, pues porque al final lo saturas, porque no es capaz de funcionar de manera correcta. Entonces, bueno, pues esto ha sido parcheado, por lo tanto, bueno, pues un error que se ha corregido y entonces ahora ya, pues se puede, bueno, pues seguir trabajando bien

y bueno, pues recomendamos a todo el mundo que actualice, que usa Vapor a una versión, la versión 484.2, que es la que ha parcheado esto y que esto está reportado, pues por un desarrollador que, pues de nuevo, es un desarrollador llamado Torchwood, que es el que es un ingeniero de seguridad, que es el que ha detectado este problema, lo ha reportado y pues bueno, pues se ha corregido.

Entonces, de nuevo, esto no sería posible si no fuera por, pues eso, porque tienes a la comunidad Open Source detrás, probando, viendo, detectando en el código, etcétera, etcétera, etcétera. Pues enhorabuena, o sea, y fijaros que voy a decir que es enhorabuena al equipo de Vapor y ha tenido un error, ¿vale? Pero es que todo el software tiene un error.

¿Pero por qué mi enhorabuena? Porque uno, lo han parcheado, lo han encontrado y lo han parcheado y dos, han explicado. Oye, mira, pues teníamos esto y bueno, y aparte, como es Open Source, te puedes ir al commit para ver el nuevo código y pues ver incluso cómo lo han arreglado, pero bueno, han hecho, lo que ha comentado Julio, la explicación de qué consistía el ataque y dónde han tocado para mitigarlo, cosa que, pues al final sirve para aprender

porque pues eso, toda la gente que haya visto este error, pues seguramente que el día de mañana no cometerá uno similar. Y entre otras cosas, esa es la grandeza, digamos, del software libre. Está claro que para meterte en un proyecto de estos, yo creo que lo hemos comentado también alguna vez, contribuir en un proyecto de estos es complicado, ¿vale? Porque es algo que lleva tiempo, que hay mucha gente detrás, ¿vale? Porque imagínate que

te pones a hacer tu librería de parsear no sé qué, ¿sabes? Pues te pones, la haces tú solo y vas haciéndolo, porque claro, esto es un proyecto muy, muy grande, un proyecto en el que se discuten, se hacen pull requests, bueno, primero en foros se empieza a discutir una nueva funcionalidad.

Una vez que se aprueba, se empieza el desarrollo, pero luego el desarrollo lleva un montón de tiempo, pues como pasa con Swift. Y es súper interesante, yo cuando tengo tiempo, que suele ser nunca, o veo a alguien que postea algo de un foro, de cómo se ha discutido algo, joder, mola un montón y aprendes un montón, pero también pierdes un montón de tiempo, o sea, leyéndote todas las propuestas y todo eso.

Pero la verdad es que son muy interesantes y se agradece, pues, porque, a ver, hay gente que cobra dinero y gana dinero con esto y se gana la vida, pero hay muchos contribuyentes, contribuidores que lo hacen un poco por aprender y por seguir evolucionando en su carrera y nada, pues bienvenido sea el apoyo, porque luego hay nosotros mismos, Julio en el caso de Vapor y empresas que construyen sus sistemas en base a este software libre y que de otra manera, pues no sé, se tendrían

que pagar licencias o no sé, se tendrían que buscar la vida de otra manera. Así que bravo por Vapor, por la librería en sí y por esta rápida respuesta ante los errores y por esta transparencia. Y si te parece, Julio, vamos a la última noticia, que también como esta es bastante breve y es algo que pudo pasar desapercibido, porque la versión de Swift 5.9 tampoco fue tan comentada, no traía demasiadas novedades y esta que os

traemos es a raíz de un post que publicaron hace unos días en el blog de Swift donde nos cuentan algunas de las novedades que tienen en la parte del debug. Muy rapidillo os contamos, una de las novedades es que tiene una inspección de variables más rápida con los comandos p y p o.

¿Qué comandos son estos? Cuando nosotros ponemos un punto de ruptura nos salta la terminal, en el propio SCODE o si lo estamos ejecutando Swift desde la consola de comandos pues nos salta la terminal y desde ese punto de ruptura nosotros podemos preguntar por el valor de variables con los comandos p y p o. Y luego tiene tiene varios argumentos. Pues aquí han mejorado esa inspección y te da los resultados antes.

A mí hay veces que me tardaba más y se hacía algo de lío y lo han mejorado. Luego lo que también han mejorado es la parte de los genéricos. Muchas veces se volvía loco al preguntar con estos comandos de p y p o por algún genérico, sobre todo cuando le pedías a algún tipo. Incluso te daba error o te decía que no lo encontraba.

Pues esto se ha mejorado. Y por último han mejorado el scope, el ámbito de las variables. Había muchas veces que si tenías una variable que se llamaba igual en una clase como variable global y también como variable local de una función pues a veces te daba gato por liebre y te ponía una o te ponía otra.

Luego a veces le preguntabas por una variable que aún no estaba definida y él ya te daba el resultado de esa variable que iba a tener luego. Pero dices pero es que todavía no se ha ejecutado este código. Pues lo han mejorado y ahora es mucho más fiable y sólo te da el resultado si esa variable está en su ámbito y ha sido definida. Variables pequeñas pero bueno pues la idea es la Swift 5.9 es una versión menor ya vendrá Swift 6 que hace un tiempo se hablaba más que ahora está un poco como dormida la cosa porque bueno

debe haber varios elefantes en la habitación que resolver en Swift 6 y todavía están debatiendo. Pero bueno pues una curiosidad más y os aconsejo que utilicéis el debugger porque os saca de muchas cosas. Yo era muy, sobre todo en mis primeros años, muy de mucho print y muy poco breakpoint en el código.

Y como dice Julio, descubres un mundo nuevo porque aparte Scode si te pones sobre las variables que ya han sido asignadas ya te da visualmente, te ofrece el valor. Pero con estos comandos de P y PO que son los básicos pero hay muchos más, podéis hacer un montón de cosas, te da mucha más información. Así que es mi consejo el menos print y más breakpoint. Sabio, sabio consejo.

Sí, sí. De hecho yo a la gente, incluso a nivel de... les digo que pongan porque claro hay muchos que te dicen no pues el print, te haces una función de print que tenga un if debug y así no se mételo con el código tal y cual. Es que es más fácil poner un breakpoint que haga un PO cuando pase por ahí y no se pare y ya está y lo tienes ahí totalmente seguro y el breakpoint es algo que sabes que jamás se va a subir a...

es que yo he llegado a ver aplicaciones con contenido de suscripción que en el print de la consola estaban dando la url abierta al contenido de suscripción que dices pero vamos a ver arma de cántaro que esto sale directamente en el log del dispositivo que cualquiera que lo tenga enchufado Scode puede sacar esa información hombre. De hecho es más para esas cosas para luego o sea para cosas que lo hagáis un momento

está claro que es un breakpoint o sea que lo hagáis en momento de desarrollo un breakpoint seguro pero luego si queréis tener algo logueado pues incluso yo creo que lo hemos hablado la librería logger de Apple desde iOS 14 está unificada le hicieron como una unificación porque había un poco de lío entre varias librerías os permite hacer imprimir por pantalla el antiguo NSLog de Objective-C os permite imprimir por pantalla y aparte trae por defecto

esa privacidad es decir por defecto en el log las variables que inyectéis o sea o que interpoléis los strings que interpoléis vienen con la privacidad activada y no se van a ver en el log sólo lo vas a ver en la consola de Scode aparte tenéis diferentes niveles de log de información de error de debug que precisamente sirven para eso pues hay algunos que sólo se quedan en memoria hay algunos que persisten en el dispositivo

durante menos tiempo vale tenéis mucho más para esos logs que necesitáis tener para tiempo vale entonces si queréis tener eso en vuestra aplicación que sí que es muy útil luego además a partir de iOS 15 incluso en esa librería te los puedes enviar vale yo últimamente en las aplicaciones en las que estoy trabajando en las versiones a veces en producción vale pero otras veces no llega a esta producción pero en versiones de staging

para los equipos de QA dejamos esta opción para que si hay algún error nos manden el log y además lo clasifica se puede clasificar también por categorías pero tienes un log para el bluetooth otro log para la parte de red vale y le dices mira al usuario pues vete aquí a este menú que te hemos puesto y seleccionas la categoría de bluetooth y mándame el log del último día vale y te lo mandan es un txt y ves lo mismo y puedes

debuguearlo y la verdad que está muy bien entonces para el takeaway de hoy menos print y más breakpoint vale y si queréis log para dejar ahí en el código vale utilizar esta librería de login que es una librería que trabaja con el strut logger si no me equivoco y te permite pues coger y crearte información a nivel de depuración a nivel de información a nivel de notificaciones a nivel de errores a nivel de fallos más gordos vale y lo único

que hay que hacer es crear un logger a partir de una a partir de un de una instancia vale simplemente ponemos default log es igual a logger paréntesis paréntesis vale y a partir de ahí pues ya decimos defaultlog.log no sé qué o defaultlog.debug lo que sea y podemos ir mandando así un montón de mensajes de distinto tipo vale en el que bueno pues tienes ahí la la indicación de cómo de cómo funciona y de hecho hay también una librería de log

para el lado servidor que es una API de que está también en apple que es la apple.github.io barra swift guión log vale que es una librería de la propia apple que para lo que es lado servidor como va a por etcétera pues igual simplemente te creas un logger con un label que lo identifique y a partir de ahí pues eso logger.info, logger tal, logger cual y vas lanzando los mensajes y te los va cogiendo sin ningún problema y que es además pues

obviamente multiplataforma funciona en linux y en cualquier otro sistema operativo no sé si lo tendrán enganchado porque por ejemplo en escode 15 que no todo va a ser malo en escode 15 todo esto depende del nivel te lo ponen un color luego también puedes filtrar por las categorías estas que os comentaba la verdad es que está te los auto detecta estas categorías vale y los puedes filtrar la verdad es que está está muy potente y

sobre todo que en cada versión de ellos apple es una de las cosas que apple está prestando atención pues sí son cositas que bueno entran dentro de la de la prioridad vale así que echarle un ojo a vuestro funcionamiento con estos temas vale y bueno hoy vamos a intentar que el programa vale vamos a intentar que los programas duren algo menos vale vamos a intentar que los programas estén más cercanos a la hora y media que a las dos horas vale

por lo tanto bueno pues cerramos el bloque de noticias y lo que hacemos es comentar pues un par de cositas que teníamos por aquí apuntadas curiosas vale de temas que han surgido esta semana vale que queremos que son interesantes de comentar y con esto pues ya vamos cerrando así que vamos a nuestro bloque principal pues cuéntame arturo porque eres tú quien ha hecho estas anotaciones que la verdad que

me parecen bastante curiosas e interesantes hablando pues de algunos temas que han surgido en qué contexto cuéntanos pues precisamente a colación de lo que os contaba en el primer bloque de que había estado haciendo pues estos debates que se han dado en en mi trabajo pues eso que al final a la hora de implementar cosas pues algunas que nos hemos dado cuenta entre todos que a veces pues eso sobre todo con las novedades pues hay veces que lo mira

rápido hasta que no te metes en profundidad pues hay algunas cosas que digamos que se pueden escapar y estos debates son muy buenos precisamente porque a lo mejor hay algún compañero que lo ha revisado a fondo y te saca de algún error o de algo que no habías visto y eso pues te sirve al final de aprendizaje para no meter la pata cuando te toque hacerlo a ti y la primera de ellas es referente a los actores vale para los que no lo sepan

una pregunta sinceramente tú crees que la gente está usando actores pues no hay dos opciones hay mucha gente que ha optado por pongo actor en todo y ya está vale y me quito de líos y otra gente que está sobreactuando sobreactuando y hay otros que están infractuando porque si no están dando cuenta y son o son jim carrey o ya se van al extremo de la roca no hay un plan o de estos ojos no se me ocurre ahora ninguno pero de estos actores que luego

les escuchas en entrevistas y son ellos actuando también te quiero decir que hacen el mismo papel en todas tipos ya ni con son que él es igual que muchos de sus papeles pues este tema de los actores y por explicarlo rápido tampoco liarnos mucho el actor o actor en inglés centro es un nuevo tipo de su y se introdujo con así en cagüey vale con un nuevo modelo de concurrencia para evitar los data races vale y aquí otro punto que es un data race la

explicación oficial es cuando varios hilos intentan acceder a una variable y al menos uno de esos accesos es una escritura vale porque eso da un pete una excepción vale en el sistema cuando se produce esto y que además no te dice ni dónde ni cuándo ni nada vale por eso es algo que hay que defenderse de ello es decir hay que desarrollar pensando en ello porque no es un error que te vayas a encontrar o sea que si te vas a encontrar el error pero luego no vas a saber dónde está ese

error y vas a tener que va a costar llegar a esa parte del código entonces se crearon los actores claro lo peor de todo es que puede ser que tengas un data race no cuelgue la aplicación y lo que tenga sea una desincronía de información vale yo una de las cosas que les enseño a los alumnos y que se quedan flipando para enseñarles lo que es el data race es poner en una cuenta de banco vale yo tengo una cuenta a que va a transferir mil veces un dólar de la cuenta 1 a la 2 y luego

otras mil transferencias de un dólar de la cuenta 2 a la 1 teóricamente esas mil transferencias da igual cuando se hagan siempre tienen que dar que el contenido se quede igual que estaba vale porque estoy metiendo mil veces metiendo mil dólares uno a uno y metiendo mil dólares en la otra de vuelta por lo tanto da igual el orden en el que se hagan las operaciones siempre tiene que dejar las cuentas con el mismo saldo en el momento en el que lo metes dentro de un dispatch queue global

que es asíncrono barra concurrente y empiezas a tirar las transferencias lanzas y de pronto te dice saldo final de las cuentas 500 y 100 lo lanzas otra vez saldo final 1200 y 3000 cuando deberían ser 3.000 y 5.000 que es de la que parte el ejemplo vuelves a tirar y te pone 1.500 y o sea imaginar lo que es un mismo código que cada vez que lo ejecutas devuelve un resultado totalmente distinto porque porque esos mil trans esas mil transacciones se están pisando la una a la otra

vale porque si tú vas a leer un dato para escritura tú tienes primero que leer el dato llevártelo a la memoria de tu aplicación cambiar ese dato y luego volverlo a poner en la memoria cambiado si en esos pasos vale que tú estás haciendo resulta que a la vez está entrando otro proceso y se lee varias veces el valor antes de ser escrito tienes una desincronía en la que de esos mil procesos el valor que entra es el que le da la gana entonces insisto es mil y mil y ves perfectamente

como cada ejecución devuelve un resultado totalmente distinto entonces es algo que obviamente hay que evitar y cuando eso lo metes haciendo que la clase de la cuenta bancaria sea un actor le das mil veces y siempre devuelve 3.000 5.000 3.000 5.000 3.000 5.000 perfecto o sea y yo cuando enseño eso a los alumnos se me quedan flipando como diciendo hostia y eso que ha pasado ahí jaja no que ha pasado y cómo haces el actor vale pues así lo que lo que hace también sé antes de que vinieran los

actores vale se podía hacer con logs y cosas pero lo que tienes que hacer es cuando alguien va a acceder a esa variable bloquearla vale entonces te convierte todas las propiedades que declares en ese en ese actor de la bueno variables mejor dicho de las convierte en asíncronas vale es decir que si tú quieres cambiar la de fuera pues tienes que hacer una wait o bueno si quieres cambiarla también desde una función del código igual el código se va a suspender ahí y va a

esperar a que se toque esa variable para el siguiente vale y va acumulando secuencialmente toda la gente que quiere acceder a esa variable vale muy bien y para el ejemplo de julio nos vale con eso lo tenemos hecho ese programa va a ir siempre bien porque nos da exactamente igual que se hagan tres transacciones de A a B luego dos de B a A luego con que se hagan mil para un lado y mil para otro lado al final de la ejecución las cuentas se van a quedar exactamente igual y

eso va a pasar porque no se van a pisar pero este aquí el problema que ese acceso secuencial a la variable no significa acceso secuencial a la función a una función que llames vale os pongo el caso imaginaros que en lugar de ser esa variable lo que comentaba julio que es el saldo de una cuenta vale es una caché de imágenes en la que guardo un diccionario y el data vale el png data de esa imagen vale y lo guardo en una variable en memoria y tengo una función que es fetch image

que le doy la url vale si la encuentro en esa caché me devuelve directamente el data ese y si no hace una llamada url y me devuelve de ahí y lo guarda en caché vale pues yo hago dos llamadas seguidas a esta función con la misma url vale y qué me pasa que me va las dos veces a internet dice si porque si esto se ejecuta secuencialmente porque a la variable de la caché se accede secuencialmente y es que no porque porque yo llamo esta función él va a decir no está en la caché y

empieza a ejecutar la llamada de red y esa llamada de web de red se hace con un try await es decir que se suspende entonces claro el actor dice vale pues yo voy a mi cola de peticiones a mí que de hecho le llaman el inbox de los mensajes vale porque hacen como el símil de los mensajes y curso la siguiente y que le va a pasar a la siguiente pues que también va a decir uy no estoy en la caché salto para abajo entonces aquí tenemos el problema que no solucionamos menuda

caché más mala que he creado si le estoy haciendo una petición y la misma petición la misma imagen y las dos veces ha ido a internet vale esto no es caché ni es nada cómo se minimiza esto pues al final en lugar de guardar en la caché el resultado lo que guardo es la tarea vale las tasks se pueden guardar la referencia como un dato vale entonces cuando hago esa llamada de red luego en una nueva task vale que la espero también se puede hacer una await task o await de la variable donde tengo

la task y espero el valor entonces de esta manera sí que la primera petición se va a parar se va a suspender porque va a hacerlo esta petición de red asíncrona pero la siguiente también se va a parar ahí hasta que se curse no va a detectar que está en la caché pero se va a parar ahí y me va a devolver a las dos llamadas el retorno de esa tarea vale los datos de retorno de esa tarea entonces ya lo

guardaría en caché y ya sí que la siguiente que llegue de esa misma imagen me lo pasaría y esto es algo que salió en la discusión y es de hecho salió en la discusión de otro día pero es que a mí también me pasó una vez que tuve que hacer o sea tenía hecho mi manager perfecto para sincronizar unos datos con el servidor que hacía la petición que lo guardaba en disco que tal para no repetir

peticiones cada 12 horas bueno súper chulo y cuando me pongo a hacer los test unitarios digo hoy pero si siempre me la está sacando del mismo sitio y esfocando que ahí digo vale salado es que las peticiones se ponen de manera asíncrona pero una vez que lo suspendo el actor puede volver puede seguir con la secuencia en la cola y todavía no estar preparado no estar cacheado el dato vale y pasar dos veces entonces por eso lo quería traer aquí porque parece o sea de hecho apple julio

me contó con antes cuando estábamos hablando antes del programa que sí que luego apple puso un ejemplo pero a mí me suena que uno de los primeros vídeos de asínca way no sé si cuando estaba todavía en desarrollo ya uno de los vídeos de apple ponían como tu pon actor y ya está sabes y ya tienes la vida solucionada y no es del todo cierto porque hay casos como este en el que no sólo vale con con crear el actor esto se llama actos reentran si vale reentrada de actores y

efectivamente había un vídeo en la wwdc donde se generaba una solución a este problema vale la solución este problema cuál es es usar algo que mucha gente no conoce de asina wait vale el año asín a weight no fue muy bueno a nivel didáctico vale la gente que se encargó de hablar de todo esto no todos tenían una buena didáctica y no fueron capaces de encontrar una forma de explicarlo de manera clara vale y esto es una cosa que luego penaliza de acuerdo porque al final hay muchísima

gente que asín a weight lo está usando para hacer un dar un uno de sesión share punto data y ya está pero luego no no hace secuencias asíncronas no sabe cómo funcionan las continuaciones no sabe desde luego cómo van los grupos de tareas o incluso piensan como me ha pasado a mí que poner cuatro traya weights uno debajo del otro ya es concurrencia no señores es serialización porque está esperando cada línea para que termine vale si lo quieres hacer concurrente hay que poner tu

plas vale para que se solucionen al mismo tiempo de acuerdo es decir tendrías que poner un traya weight y dentro la resolución de cuatro funciones o cinco o seis o las que quieras poner dentro de la de la tupla para que así sean concurrentes o meterlas en una secuencia síncrona y hacer un for traya weight in donde también tienes ahí la posibilidad de esas secuencias asíncronas a partir de un encolado con las grupos de tareas vale las cosas que esta cosa bonita vale pero el tema del

actor re-entrancy que bonito que es actor re-entrancy básicamente es utilizar programación estructurada basada en asina weight es decir cuando yo pongo asina weight lo que hago es poner un task y ya y ya y ya stacks vale pero no es esa la solución cuando yo pongo un task el task es capaz de devolverse porque el task es un futuro de un result vale el task es un futuro de un tipo resultado por lo tanto el task se define si tú el task lo metes dentro de una constante

verás que dependiendo de lo que el task devuelva vas a tener un genérico de lado de success lado de fallo de acuerdo entonces si tú pones un traya weight si tú pones simplemente let cosa es igual a task abro llave y dentro pongo traya weight de get imagen lo que sea vale si yo pongo eso veremos que la constante cosa es un task genérico de UIImage,error vale entonces si ese task dentro de otro task vale de forma estructurada lo utilizo ese task tiene dos propiedades a las que podemos

acceder que son una de tipo await y otra de tipo traya weight la propiedad de tipo await cuál es el result type del que procede el task por lo que si el task es UIImage,error tienes un task punto result que es un await es una en realidad es una async vale que se invoca solo con await sin el tray que te devuelve el result type de ese UIImage,error como el error va en el result type por eso no es tray vale pero también puedes acceder a la propiedad value que la propiedad value es

una propiedad que va directa a la parte del success del result type y esa parte del success del result type lo que se devuelve con un tray await porque si hay un error en ese success te lo va a propagar a través del tray vale entonces eso es lo que hacía Apple, Apple metía un diccionario y ese diccionario era nombre de imagen dos puntos task, task genérica de UIImage,error vale entonces si tú volvías a llamar a la función cuando todavía porque aquí el problema está

como ha comentado Arturo en que tú llames a una función para pedir una imagen y cuando aún no sea descargado vuelvas a llamar a la misma función para la misma imagen entonces te genera doble llamada por lo que lo que hace el sistema es detectar si tú estás teniendo una si tú ya tienes activa la llamada en un diccionario a esa misma imagen y en vez de devolverte la imagen te devuelve el value el task.value tray await de la imagen vale de acuerdo entonces la primera

vez mete esa tarea dentro de un diccionario y cuando el diccionario termina la resuelve y la devuelve pero si vuelve a entrar y la tarea está en el diccionario te devuelve directamente el tray await del punto value quiere decir que si hay dos tres funciones que llaman a la misma imagen de manera concurrente la primera que llame va a recibir realmente la primera petición con el proceso de tray await que va a hacer que se espere hasta que se devuelva pero las demás concurrentes

van a recibir el punto value de ese task por lo tanto las cuatro cinco seis llamadas concurrentes que vayan a la misma imagen mientras esa imagen se descarga cuando la imagen esté descargada de la primera vez que se pidió recibirán todas a la vez la imagen descargada desde un mismo proceso y con eso se soluciona el problema de la reentrada del actor a través de funciones asíncronas vale ahora es cuando hay que decir aquello de así de simple y así de sencillo.

Sí a ver bueno es que iba a decir que luego se ve pero no o sea yo cuando me di cuenta y cuando dije cómo lo como lo mitigó tienes que saber bastante para mitigar eso de hecho es que la confieso que la primera vez que lo implementé no me di cuenta hasta que no fui a los test y en los test dije ostras porque está llamando y claro luego te pones a analizar el código dices claro si es que pones puntos de ruptura como os he dicho antes y ves que el círculo se va cerrando empezamos con el principio

luego vamos a la mitad del programa y luego al final vale pues la la siguiente cosilla que quería comentar es el tema de las capturas de variable en los closers vale hemos visto que muchas veces cuando las son cuando queremos ejecutar un closer que necesita algo de un que esté fuera del ámbito necesitamos capturarlo pero una cosa que muchas veces se nos puede pasar por alto es que la captura de esos valores se hace en bueno y ya en su día hablamos de capturar con

con wik valores o sea valores por referencia porque luego pueden no existir además se crea un conteo o sea se suma a un conteo vale pero bueno es harina de otro costal que dicen aquí voy con el momento en el que captura las variables por ejemplo un valor una variable que por valor claro esa captura se realiza en el momento de definir el closure que no es el mismo momento en el que se ejecuta el closure pero como estamos capturando algo por valor el valor ya lo hemos

capturado antes si alguien viene y me cambia esa variable un entero vale que en el momento de definirlo valía 2 pero en el momento de ejecutarlo vale 4 vale 4 la variable pero lo que he capturado vale 2 y eso te puede generar problemas es otra cosa que hay que darse cuenta que cuando capturamos un valor lo capturamos en el momento que definimos el closure vale el closure digamos que una vez que tú lo declaras vale donde lo declaras pues en una función que llamas o lo que sea o lo guardes en

alguna variable en ese momento ese closure queda empaquetadito para el momento en que se ejecute vale no es que cuando tú vayas a ejecutarlo se vuelva a evaluar no no no no se ha evaluado en el momento que lo defines vale entonces hay que tener en cuenta que va a tener el valor del momento en el que lo estás definiendo cuando lo pasamos cosas por valor vale no por no por referencia no sé si julio te has encontrado algo de este calibre

pues a ver claro es que este tema es complejo vale porque teóricamente teóricamente en un porque claro aquí es a ver aquí estás comentando el típico problema de la roba escaping que pasa con los con las clases vale y que teóricamente pues con los struts no se da o eso dice apple no pero efectivamente si puede llegar a darse no se me ha pasado nunca vale porque al final yo la mayoría de las veces lo que uso son dentro del contexto de sus joyes más complicado que que suceda pero

claro este tipo de reglas de copia por valor esto puede ser un motivo por el que ahora tenemos un modificador que yo creo que nadie conoce que es el modificador copaya vol no sé si lo has visto pues el modificador copaya vol es para modificar la lo que sería el ciclo de vida de las el ciclo de vida de los de los elementos vale es decir tú en swift puedes hacer que un un strut vale sea copiable vale entonces al ser copiable lo que estás haciendo es que no

sea una nueva copia sino que sea vale esto lo puedes definir es una una una propuesta que es la 390 que son los non copia bols struts and nums vale es decir tú puedes hacer que un strut sea copiable o que un strut sea no copiable vale entonces de esta manera puedes cambiar la forma en la que se están gestionando vale los distintos elementos de lo estoy explicando así un poco por encima vale porque no no tengo muy claro exactamente qué es porque no lo he trabajado vale sé que está

lo he visto etcétera etcétera pero no lo he trabajado como tal ni lo he probado como tal vale pero básicamente creo que lo que hace es cambiar ese paradigma de la copia por valor que te genera ese problema vale entonces de esa manera lo que tú haces es decirle que retenga en memoria como una referencia un strut para que luego tú puedas a partir de ahí bueno pues evitar esos problemas y que la instancia del strut pues sea de una manera no sé como más sencillo pero esto es

algo que yo te digo no lo he tocado como veis no estoy explicándolo muy bien porque no lo he tocado ni lo he entendido nunca pero sé que está ahí vale sé que es una posibilidad de utilizar estos struts y estas enumeraciones en un modo no copiable para que esa copia por valor no se vea no se haga vale en ciertos casos donde pues bueno te sea necesario hacer este tema vale o sea sería algo así como intentar permitir que los desarrolladores puedan definir tipos que sean

strut y enums que no se copien de manera automática para pues ciertos elementos que intenten evitar los problemas vale entonces tú puedes añadir un atributo arroba non copiable vale y eso lo que hace es que cuando tú pases el elemento lo pase como una especie de referencia en vez de pasarlo como una copia por valor vale no sé cómo lo no sé si conocías esto no te digo de hecho cuando lo has dicho me quería sonar pero y estoy viendo que es que es de swift 5.9 sí sí es de 5.9 vale de hecho

parece ser que evita que puedas hacer implementaciones de tipo hacer una asignación etcétera etcétera vale que no que te impida no que el elemento pueda ser copiado para tener una una tal vale se parece ser que no puedes usar el operador de igualdad vale ni puedes utilizarlo en tipos de contexto que requieran conformidad con el protocolo copiable copiable vale es como una forma de limitar el uso de los struts y los enums para evitar este problema de la compartición de las

de los datos copiados de tipo por valor esto ya dando muy fino ya sí sí es lo que te iba a decir que pero ves como por eso hay que hablar con gente y con programadores de tu nivel o mayor para este tipo de cosas por eso a pesar de que yo tampoco sé muy bien cómo funciona porque no lo he mirado ya se ha ido a hablar ya me voy a la cama sabiendo que lo que tengo esa opción bueno de hecho se supone que que bueno que apple estaría por cambiar o pensar al menos eso se dijo en su momento que en

su ip6 yo puedo retener el ciclo de vida con una especie especie de retail release vale es decir sabemos que si yo dentro de un ámbito creo una constante cuando el ámbito acaba la constante muere porque funciona por arc pues el modelo de memoria va a cambiar a un modo no exclusivo en el que podríamos decirle créame está constante pero manténla en memoria más allá del ámbito donde está y ya te diré yo cuando tienes que liberarla ahora claro es que una de las cosas

buenas que tiene su y es que no tiene punteros vale que todo este de reten cosas y demás pero claro luego tiene como el ejemplo este del in out de las de las funciones vale que puedes sacarlo fuera pero claro luego hay cosas que tiene que incorporar el propio lenguaje que a lo mejor con una estructura de punteros y de otro modelo de memoria se podrían hacer pero aquí hay que hay que poner cada caso y dejarlos es que yo una de las cosas que me explotó la cabeza o el principio

cuando estaba utilizando su y eso cuando te cuentan no es que una estructura es por valor y una clase es por referencia y tú what que me estás contando si sabes porque y eso que yo conocía cosas de punteros y demás pero un puntero dice no yo es que le pongo todo es igual pero le pongo una cosa es el puntero y otra cosa es la variable en sí claro y entonces ahí te explota un pelín la cabeza y pues si ya para no liarnos más si te parece voy a comentar otras cosas que surgió y es que

hemos hablado también antes ya para cerrar el círculo de swift 6 vale y una de las cosas que ya están por aquí en swift 5.x son esas palabras de SAM y ENI vale el SAM nos acordáis que empezó con SwiftUI de hecho Apple hizo su implementación interna y luego lo liberó la gente se enfadó un poquito sabes con ese con ese tema es decir es un lenguaje open source y metes una característica sí o sí porque os apetece a vosotros vale pues swift 6 la intención es que se pongan mucho más

punkis por así decirlo y te obliguen siempre que utilices un protocolo a definirlo o a implementarlo en alguna de tus en una clase o como argumento de una propiedad de una estructura de una de una clase o un argumento de una función que siempre venga acompañado de este SAM y de este ENI así a grandes rasgos la diferencia entre ambos es que SAM en tiempo la diferencia es cuando sabes qué tipo es vale con SAM tú aseguras y estás obligado a que en tiempo de compilación el

compilador sepa eso que es exactamente vale es se conforma al protocolo codable pero que es exactamente vale sin embargo ENI es sabido es desempaquetado en tiempo de ejecución cuál es la diferencia pues que este ENI es más flexible por un lado pero por otro exige más cómputo vale entonces en swift 6 lo que se quiere hacer es hincapié en que cuando utilices ENI o sea minimices el uso de ENI y que cuando lo utilices tengas que poner la palabra reservada antes para saber

que estás incurriendo en un coste a la hora de hacer esa ejecución el ejemplo más rápido vale que fue ya yo cuando estuvimos hablando de esto también nos explotaba un poco la cabeza a todos me hice un playground vale y qué diferencia qué diferencia había entre las dos que por ejemplo yo defino una clase una estructura vale y tiene dos ejemplos una propiedad y una función vale que tiene la propiedad es un protocolo no defino un protocolo no defino un tipo concreto y en la

función defino también en uno de los argumentos tiene un protocolo vale en la propiedad sí o sí tengo que poner ENI porque tengo que poner ENI porque esa cuando se compila esa clase o esa estructura vale el compilador como no está instanciada no sabe qué es eso entonces siempre es ENI porque en tiempo de compilación no se sabe qué es eso cuando luego ya esa código compilado lo utilice en otro sitio de mi aplicación y cree esa clase le voy a decir oye esta clase es de este

protocolo es este tipo concreto pero hasta ese momento va a ser un protocolo con lo cual ENI sí o sí pero en la función yo le puedo poner como SAM porque cualquier cualquiera que se haya conformado a ese o sea cualquier instancia de esa clase cuando utilice esa función me va a tener que decir en tiempo de compilación qué es qué tipo es vale entonces ahí sí me va a tragar el SAM vale es un poco lío hasta ahora no estás obligado a utilizarlo vale tú te puedes definir una clase e ir

a poner directamente una propiedad que cumpla un protocolo y punto vale el problema es el mismo vale que no se va a saber hasta tiempo de ejecución y vas a tener cierta sobrecarga pero ahora mismo no te obliga pero para Swift 6 pues ya ya lo vamos a tener de hecho la diferencia y así por explicarlo a grandes rasgos porque tiene una sobrecarga porque es una resolución dinámica vale es decir no se sabe ya y no se compila sino que digamos que hay que poner hay que compilar cierta lógica para que

en el momento de ejecución se ejecute esa lógica para saber qué es eso vale entonces es la diferencia de la resolución estática y la resolución dinámica de tipos no sé cómo ves esto julio si has tenido tuya que lidiar con sams y ennis pero se avecinan curvas con swift 6 o sea vamos a tener que reaprender o estudiar varias cosas yo es que como el tema de los genéricos a ver por ejemplo a mí si quiero poner una función por ejemplo normalmente pongo la función acotada entre menor y mayor y

meto ahí el genérico si tengo que pegarlo a un protocolo lo pongo ahí directamente sin embargo ahora en la última versión de swift el compilador me está diciendo que mejor ponga were genérico igual a protocolo vale me cuesta me cuesta que sí que está muy bien porque todo eso nos va a permitir tener un código más genérico valga la redundancia pero yo creo que lo de las reglas del sam y del enni es un poco confuso vale es un poco como lo que me ha pasado todos los

alumnos cuando usan el sam en swift UI no entienden que el sam tiene que tener el mismo tipo de devolución vale que sí que tiene que cumplir tú pones sam view y sam view es que tú vas a devolver un view pero si tú tienes tres salidas y en cada una de ellas envías un tipo distinto conformado con view no sirve tienes que devolver el mismo tipo es un botón otra un texto y en otra un rectángulo no puedes te dice el compilador que pa casa que pa casa porque el sam tiene que ser

el mismo tipo ya que al final es un genérico vale todo es el genérico una vez está fijado por el compilador ya no puede cambiar vale o sea es como si tú creas un genérico y usaste y usaste en todo el código y luego cuando lo invocas dices que t es un entero pues t ya es un entero si quieres usar también un doble como genérico tendrás que poner u o tendrás que poner otro genérico que sea de otro tipo distinto vale ese es el por qué en el momento en el que tú has fijado el tipo

del genérico del protocolo a text pues ya todas las salidas tienen que ser text pero es confuso vale y sobre todo por ejemplo con el tema de los errores a mí cada dos por tres cuando uso mis propios tipos de error me está diciendo no no esto es un error y es como uff entonces yo creo que es algo que a nivel didáctico creo que swift está cogiendo ciertos cambios para las para las funcionalidades más avanzadas haciendo demasiado caso a gente muy purista que lo que quiere es

poder con perdón de la expresión pero en botija y no y me parece que no porque están rompiendo el espíritu verdadero de swift que es el de ser un lenguaje fácilmente entendible no sé cómo lo entiende con esto si no porque hay una parte que sí que es verdad que swift y una curva de aprendizaje comparada con otros lenguajes bastante poco pronunciado vale bastante suave el problema es que swift cuando en las primeras errores va guay pero pero pasas una curva y de pronto pasas

de algo muy guay a algo de hostia que ha pasado aquí porque de pronto se convierte en algo súper complejo pero claro el problema que veo es que es tan sencillo que luego hay cosas como los data rays y demás que estaría muy bien que en tiempo de o sea cuando estás escribiendo el código lo sepas y yo creo que esto busca un poco el aunque es claro es complicado de hacer busca un poco eso que es en plan mira el error este muchas veces de que estás utilizando un genérico que luego se

tiene que resolver de forma dinámica de sobrecarga lo puedes hacer pero tienes que escribir una palabreja que sabes que algo pasa ahí pero claro es lo que siempre decimos un lenguaje que empieza a tener 800 palabras reservadas no sé cuántos modificadores como el arroba ahora vienen las macros hostia que eso también te grita que yo he decidido no dar macros en las formaciones de apple con academy que a ver qué es lo de siempre a mí para para una api me parecen geniales lo que

se va a hacer es algo que no vas a hacer en tu vida salvo que hagas una api y seas un crack porque tengo que hacer un sdk yo creo que seguro que tienes mil marrones que hacer más que ponerte a no voy a dejarlo con una macro así es que las macros están pensadas para eso entonces yo haré una formación grabada para el que la quiera hacer pero yo no voy a meter en una formación en la que no todos tienen el mismo nivel algo que yo sinceramente considero que es de un nivel de

programación muy avanzada yo creo que es de lo más complejo que tiene swift de calle las posibilidades son brutales o sea lo que se puede conseguir con una macro es de locos vale pero su implementación es tan compleja que yo lo veo como algo que es inasumible para un alumno que si el árbol de navegas por el árbol y bueno es que es una movida nada más el código de macro que extienden todo otras que extienden sólo funciones otra que nada más que con que vean las macros de

expresión que son las más simples y veas que para recuperar cada uno de los valores que se han metido dentro de la expresión tienes que hacer una función que recupere de manera genérica los valores y que luego algún casting porque tal es algo muy muy yo le veo una similitud muy grande a los lenguajes de bach a hacer shs con linux o con mac porque al final tienes eso no es como cojo un código luego lo pongo aquí luego tal pero yendo un poco más allá vale yo cuando en las formaciones enseño

eso la gente se queda flipando diciendo porque a ver lo he enseñado en un par de ellas simplemente enseñar cómo es el famoso hash url para que te devuelva la url no como un opcional y cuando les he enseñado el código he visto las caras a la segunda clase que le puse eso y vi la cara que te pusieron dije nunca más o sea no voy a dar esto esto lo sacaré fuera lo daré como algo para que el friki piki plus lo pueda aprender y pueda sacarle provecho y lo va a flipar pero para la gente

normal que además la gente normal no va a usar ese tipo de herramienta vale porque esto es una cosa que está más pensada para que la use la propia apel o la gente que lo va por o claro pa por la gente que haga sdks que haga frameworks de alto nivel etcétera vale que son muy pocos por eso yo lo enseñaré para que aquel que quiera aprenderlo lo aprenda pero no lo voy a meter en clase porque es que se me suicidan o sea no no hay no tengo no soy capaz de verdad de encontrar

una curva donde meter eso y que tenga sentido y repito es brutal me parece increíble que lo hayan metido pero es una programación muy muy muy avanzada entonces claro porque al final es estandarizar eso como cómo hacer crecer un código te tienes lo que coges es al código y lo transforma pero claro la manera de entrar para hacerlo es muy muy muy farragosa porque el problema es que como esa capa de macro se está ejecutando en runtime y es capaz de resolverse en runtime y

devolver horrores en runtime pues obviamente estás es algo tan engorroso como el que se pone a jugar con la API de mirror para ver propiedades de SwiftUI que la palabra farragoso toma un nuevo sentido con ella si además a ver calculó que la de macro no haga lo mismo pero a mí la de la de mirror la reflexión y tal de una versión para otra de Swift se me cargaron un montón porque antes por ejemplo

para sacar como en la clase un nombre para la clase un lío y al final son son de mirror por ejemplo yo creo que Codable utiliza toda la parte está de mirror para sacar todas las variables y crearte un montón de código pero por eso Codable puede ser una de las cosas que a lo mejor te pongan una macro pues no lo descartaría porque ahora requiere una API como muy de bajo nivel y probablemente con una macro se resolvería de forma más más sencilla y sobre todo que aunque cambies

las APIs de bajo nivel no te no te cargas nada sino no y que al final pues sea simplemente en vez de conformar al protocolo Codable pues pongas arriba arroba Codable y a volar y eso cambia la implementación interna y hace que funcione de una manera más rápida ahora que lo están haciendo desde cero en Swift pues sería una opción interesante en fin pues bueno nosotros queríamos queríamos hora y media pero bueno en fin nos vamos liando liando así que lo dejamos aquí

le llevamos a las dos horas y entonces pues nos vamos al bloque final de despedida y poco más poco más que ya ha sido bastante que ya ha sido bastante sí como siempre cuando vamos a empezar siempre decimos arturo yo bueno a ver si el programa hoy nos falta contenido y tal no sé qué pero no no es que has hablado de reducirlo de dos horas y media a hora y media yo creo que es más bien es de dos horas y media o tres a dos horas si nosotros vamos a intentar para

ahorita el niño jobs colocarnos en la hora y media pero esto es un poco como el que te dice no no hemos quedado a las ocho pero se lo dice al que siempre llega tarde para que así en realidad han quedado a las ocho y media y entonces así el que siempre llega tarde pues no llega tan tarde que julio si te pones con un café con un colega a hablar de las cosas que te gustan es que el tiempo se va sobre todo como tú dices que al final bueno pues comentas cosas hablas tal pones

en común temas que normalmente no sueles hablar con tu familia y con la gente así más allegada por su bien mental y es como si un médico se pone a hablar de pruebas diagnóstica o una o un economista se pone a hablar de los tipos de la inflación y del tal pues ya sabes que son temas muy así entonces bueno pues siempre viene bien el tener a un buen compañero que con el que puedas hablar de estas cosas y poner en común conocimientos noticias experiencias que las experiencias al

final uno de los motivos principales por los que nos gustó la idea del qué es lo que hacemos que está heredado del podcast de stack 3 vale que no sé si sigue o no lo hablamos hace poco han perdido regularidad si han perdido regularidad verdad pues esta actriz empezaba siempre así y la verdad que era algo que aportaba bastante porque al final este esta sección de que hemos estado haciendo pues saca la palestra un montón de temas y un montón de cosas y el que se pueda de alguna manera

no debatir que siempre es algo que es muy muy interesante ya sabéis que si queréis escribirnos cualquier cosa opiniones preguntas lo que sea enviarnos un pago de miles de euros o de tal también podemos aceptarlo podéis hacerlo menos el mail del príncipe nigeriano cualquier cosa exacto el príncipe nigeriano ya lo tenemos superado podéis hacerlo a café swift con dos efes arroba gmail.com o también podéis encontrarnos en redes sociales como arroba café swift o también en

redes sociales en x vale y en más todo donde estamos como arroba café swift arroba cuonda punto social ya sabéis que café swift es un podcast que pertenece a la comunidad independiente de podcast cuonda vale y es ahí pues donde tenemos el alojamiento del podcast y todo lo que es el fin la difusión del mismo de hecho pues sabéis que estamos en cuonda punto com barra café con dos efes guión medio swift y a ti dónde puede encontrarte la gente arturo pues a mí en mi otro

podcast videos digitales que también estamos intentando coger periodicidad por cierto y cuando mejor me encontré es en x arroba arturo rivas a más todo en arturo rivas a arroba más todo un punto cloud y bueno toda esta información la podéis encontrar en mi página web que es tres sobredobles punto arturo rivas punto com y a mí pues si queréis contactarme igualmente verme en redes sociales seguirme pero no por la calle pues podéis hacerlo en x como arroba jc f1 o pues en

cualquier red como jc f1 mal estoy ahí en instagram en facebook en fin si tengo facebook todavía ya lo sé porque es un señor mayor julio es porque es un señor mayor efectivamente no lo uso porque no tiene pero bueno ahí está desde siglos inmemoriales y luego pues igual en más todo un como jc f1 o arroba arroba jc f1 o arroba más todo un punto social también estoy en blue sky jc f1 o arroba bs ky punto social no sé si estoy también por ahí en y luego pues aquí en

los directos en twitch punto tv barra apple coding y también en youtube en youtube punto com barra arroba apple coding y para arroba apple coding academy que es donde están colgados estos programas una vez ya se terminan y se producen y se lanzan así que bueno fijaros en la cantidad de lugares donde podéis encontrarnos para bueno pues para cualquier cosa así que lo dicho muchísimas gracias a todos por estar ahí a los que están en directo viendo la grabación en twitch y a todos

los que nos escuchan gracias a las miles de personas que escuchan cada programa que la verdad que me maravilla la increíble comunidad swift de desarrollo swift que tenemos y si eso ya me maravilla y me da una esperanza lo que más nos alucina y lo que más agradecemos arturo y yo es la gente que nos escucha y que no es desarrolladora de swift pero lo hace porque le gusta lo que contamos porque le parece interesante porque aprende cosas nuevas la verdad que a todos

ellos un saludo muy especial desde aquí así que ahora sí ya no poco más si yo creo que ha sido un programa un programa redondo porque hemos ido volviendo a temas que que habíamos hablado quizás sí que hoy hemos entrado un poco técnico perdón si no se ha entendido porque es complicado sin un medio visual transmitir estas cosas pero bueno si os ha quedado algo en el tintero pues ya os hemos dicho dónde contactarnos nos nos ponéis un post que ahora se llama en x un correo lo o lo

que sea y oye podemos dedicarle os contestamos es un segundo pero si no podemos dedicarle otro ratillo en otro programa para andar y muchísimas gracias por escucharnos como ha dicho julio por por llegar hasta aquí esto lo hacemos también porque nos gusta la verdad porque es nuestro rato de hablar nuestras cosas de un café que en una empresa no podemos hacer porque si todos los días tomas un café de dos horas acaban echando seguro pero nada un placer estar aquí julio

siga cumpliendo años por supuesto que me regalen muchos relojes pues y hasta el próximo capítulo y a ver si estamos cogiendo marcha a ver si si no decae la cosa durante la temporada exacto y como siempre no olvidéis jugar con el código hasta pronto puedes escuchar más episodios en cuando.com la comunidad de podcast independientes en español

Episodios recientes

3⨯10 Lista de deseos para la WWDC24
3⨯9 La nueva IA generativa de Apple a través de Swift
3⨯8 Especial debate: Apple y los cambios en la Unión Europea (con Noelia Leiro y Marc Hervera)

Programas relacionados

Apple Coding Daily Comentario y análisis de las últimas novedades del mundo de la tecnología por, para o relacionado con los entornos Apple, desde el punto de vista del desarrollo y la programación. tecnologia
Nebuchadnezzar A bordo de la Nebuchadnezzar, Oliver Nabani y Julio César Fernández repasarán cada 15 días la actualidad tecnológica, analizando y descubriendo lo que hay detrás de la misma. tecnologia
Apple Coding Apple Coding, todo sobre el desarrollo en sistemas Apple. Julio César Fernández, evangelist de desarrollo, te trae cada semana análisis, noticias, charlas... para conocer cómo funciona la tecnología por dentro. tecnologia