WEBVTT
Kind: captions
Language: es

00:00:00.000 --> 00:00:08.680
Cuonda, la comunidad de podcast independientes en español.

00:00:08.680 --> 00:00:33.440
Bienvenidos a CAFÉ SWIFT, el podcast donde hablamos del lenguaje de programación SWIFT

00:00:33.440 --> 00:00:39.840
de Apple, solo no.

00:00:39.840 --> 00:00:45.240
Hablamos de programación, de herramientas para desarrolladores y de distintas experiencias,

00:00:45.240 --> 00:00:51.000
pero siempre desde el punto de vista de desarrolladores en entornos Apple y del lenguaje SWIFT.

00:00:51.000 --> 00:00:55.880
Y esos desarrolladores somos Arturo Rivas y Julio César Fernández.

00:00:55.880 --> 00:01:13.560
¡Comenzamos!

00:01:13.560 --> 00:01:25.560
Muy buenas y bienvenidos a un nuevo café intenso, con toques afrutados y una cosecha de calidad.

00:01:25.560 --> 00:01:33.880
En el que vamos a hablar de nuevo sobre desarrollo en entornos Apple.

00:01:33.880 --> 00:01:41.160
Bienvenidos a vuestro CAFÉ SWIFT y por supuesto no podemos tener un café de calidad si no

00:01:41.160 --> 00:01:47.680
tenemos a nuestro compañero barista Arturo, ¿qué tal Arturo?

00:01:47.680 --> 00:01:48.680
Muy buenas.

00:01:48.680 --> 00:01:50.280
Buenas, buenas Julio, ¿qué tal?

00:01:50.280 --> 00:01:53.960
Un placer, como siempre, a los oyentes también saludarles.

00:01:53.960 --> 00:02:02.400
Aquí estamos otra vez con la dosis de café, no ración, la dosis de café de calidad.

00:02:02.400 --> 00:02:14.080
Y a ponernos un poco al día porque, a ver, yo te veo que estás quemaete, yo tengo la

00:02:14.080 --> 00:02:21.600
impresión de que últimamente Apple no te ha tratado bien, no te ha tratado bien y estaba

00:02:21.600 --> 00:02:26.760
la cosa un poco, entonces claro, yo después de hablar con Arturo en privado, que de vez

00:02:26.760 --> 00:02:32.960
en cuando nos escribimos cada día o casi cada dos días o una cosa así, nos pasamos

00:02:32.960 --> 00:02:37.800
cotilleos del mundo Apple, mira lo que ha hecho este tal, no sé qué, o mira este tweet

00:02:37.800 --> 00:02:43.760
o mira lo que han sacado, muchas ocasiones casi coincidimos enviándonos la noticia a

00:02:43.760 --> 00:02:44.760
la vez.

00:02:44.760 --> 00:02:47.520
Se puede decir que somos un poco porteras al final.

00:02:47.520 --> 00:02:56.680
Sí, sí, es un poco, sí, totalmente, es como la nueva portería Swift y siempre estamos

00:02:56.680 --> 00:02:59.960
como, ay mira del tercero lo que ha dicho, ay de verdad, es que...

00:02:59.960 --> 00:03:00.960
¿Has visto este?

00:03:00.960 --> 00:03:01.960
¿Has visto este?

00:03:01.960 --> 00:03:05.800
He visto este, de verdad, es que no puede ser.

00:03:05.800 --> 00:03:09.720
Y bueno, pues comentando contigo, ¿no?

00:03:09.720 --> 00:03:14.600
Esta semana te habían tocado unas cuantas de Swift importantes, ¿no?

00:03:14.600 --> 00:03:21.480
Fíjate que también, como ya sabéis, esta semana, porque estamos grabando el domingo

00:03:21.480 --> 00:03:33.640
8 de octubre, salió Scope 15.1 beta, que además salió IOS 17.1 sin Scope y a la semana

00:03:33.640 --> 00:03:43.000
siguiente IOS 17.1 beta 2 con la Scope 15.1 beta 1 con Vision OS beta 4, o sea, es una

00:03:43.000 --> 00:03:45.760
cosa como un poco raruna.

00:03:45.760 --> 00:03:52.200
Y cuando salió, pudimos comprobar que el error de Swift Data, de no poder utilizar

00:03:52.200 --> 00:03:57.600
Swift Data en segundo plano, sigue presente, sigue ahí, no nada ha cambiado.

00:03:57.600 --> 00:04:00.520
Es que no sepa qué ha salido, o sea...

00:04:00.520 --> 00:04:05.600
La verdad que sí, pues te digo para qué, para arreglar cosas de Vision OS, porque es

00:04:05.600 --> 00:04:11.320
el gran cambio que tiene, porque Vision OS sí tiene corregidos el tema de los observables

00:04:11.320 --> 00:04:14.840
y tiene corregido todo lo de Swift Data, o sea, ahora mismo con Vision OS ya se puede

00:04:14.840 --> 00:04:21.320
usar observables y Swift Data igual que se puede usar con IOS, ¿no?

00:04:21.320 --> 00:04:23.920
Que hasta ahora no se podía porque había un error de tal y cual.

00:04:23.920 --> 00:04:29.920
Yo creo que ese es el motivo, porque por lo demás no se han visto cambios ni backfixes

00:04:29.920 --> 00:04:37.160
importantes en la versión, pero bueno, estamos haciendo tiempo para que la música de fondo

00:04:37.160 --> 00:04:44.840
termine, básicamente, y yo creo que a lo mejor es que pasemos directamente a que os

00:04:44.840 --> 00:04:50.720
contemos qué hemos estado haciendo durante estas dos últimas semanas porque Arturo nos

00:04:50.720 --> 00:04:58.000
trae cosas suculentas, así que si te parece, vamos a ver qué hemos estado haciendo estos

00:04:58.000 --> 00:04:59.000
días.

00:04:59.000 --> 00:05:11.320
Así que, a ver, desahógate.

00:05:11.320 --> 00:05:18.560
Pues, la verdad, ha sido una semana a ciega a título personal porque está malo hasta

00:05:18.560 --> 00:05:25.040
el perro en casa, o sea, hemos tenido... estaba la niña, el perro, ha sido un desastre de

00:05:25.040 --> 00:05:31.680
semana y, además, yo llevaba esperando, pues como has dicho antes, la beta nueva de Scode,

00:05:31.680 --> 00:05:37.320
una nueva versión nueva de Scode, que arreglase ciertas cosas y va Apple y, sorprendiendo

00:05:37.320 --> 00:05:43.640
a nadie, no ha arreglado estas cosas.

00:05:43.640 --> 00:05:49.320
Pero es que son cosas que, sinceramente, me parecen bastante gordas, de hecho, hicimos

00:05:49.320 --> 00:05:58.040
un post en LinkedIn que dio un poco de salseo porque, si queréis seguirnos, nosotros tenemos

00:05:58.040 --> 00:06:04.040
LinkedIn también, yo estoy en linkedin.com barra in barra jcfmunoz y el tuyo es Arturo

00:06:04.040 --> 00:06:10.160
Rivas A también, si no me equivoco, es igual, también lo tenéis en linkedin.com barra

00:06:10.160 --> 00:06:16.760
in barra Arturo Rivas A, claro, en LinkedIn la cosa es algo más serio, más profesional,

00:06:16.760 --> 00:06:23.120
etcétera, pero ahí pusimos un poco de salseo porque, realmente, a raíz de un post en X

00:06:23.120 --> 00:06:31.080
de Arturo, surgió este tema, un tema de un error que... un par de errores, realmente,

00:06:31.080 --> 00:06:38.920
que nos hacen pensar si realmente Apple está empezando a no darle la suficiente importancia

00:06:38.920 --> 00:06:43.240
o dejar de prestar atención a UIKit.

00:06:43.240 --> 00:06:45.280
Cuéntanos, Arturo, ¿qué es lo que te ha pasado?

00:06:45.280 --> 00:06:52.520
Pues sí, vamos a explicarlo desde el principio y el error en sí es que puede no aplicarse

00:06:52.520 --> 00:06:57.320
correctamente la configuración de fuentes en el Storyboard, es decir, tú asignas una

00:06:57.320 --> 00:07:03.480
fuente en el Storyboard y luego ejecutas la aplicación y esa fuente, en lugar de ser

00:07:03.480 --> 00:07:08.280
negrita no es negrita, o al revés, o no tiene que ser negrita es negrita, puede pasar cualquier

00:07:08.280 --> 00:07:09.280
cosa.

00:07:09.280 --> 00:07:10.280
A mí lo que me sorprende...

00:07:10.280 --> 00:07:11.280
Puede pasar y pasa.

00:07:11.280 --> 00:07:15.840
Pero es que lo que me sorprende es lo que acabas de decir, en un... podría, o sea,

00:07:15.840 --> 00:07:19.000
es como que es totalmente aleatorio, yo pensé que no era así.

00:07:19.000 --> 00:07:23.240
Sí, sí, sí, hay algunas fuentes que van y algunas fuentes que no.

00:07:23.240 --> 00:07:27.680
Y eso estaba así en la versión de Scope 15, ¿vale?, que salió.

00:07:27.680 --> 00:07:28.680
La final, la del App Store.

00:07:28.680 --> 00:07:29.680
La final.

00:07:29.680 --> 00:07:30.680
Hostia.

00:07:30.680 --> 00:07:40.520
Y sigue exactamente igual, pero eso sí, te pone esa maravillosa palabra workaround,

00:07:40.520 --> 00:07:41.520
puntos.

00:07:41.520 --> 00:07:49.640
Chetea las fuentes customizadas por código, que me parece, a ver, yo estoy empezando un

00:07:49.640 --> 00:07:54.920
proyecto nuevo, imagínate, empiezo, quiero utilizar Storyboard y UIKit por lo que sea,

00:07:54.920 --> 00:08:00.840
no me quieren en casa o lo que sea y tengo que utilizar en un nuevo proyecto UIKit.

00:08:00.840 --> 00:08:06.680
Pues bueno, digo, pues lo empiezo cheteándolo en el...

00:08:06.680 --> 00:08:12.880
Pero imagínate que es lo que me pasa, en este caso es un proyecto enorme que lleva bastantes

00:08:12.880 --> 00:08:19.480
años y todo está en los Storyboard, absolutamente todo está dividido en Storyboard, menos mal,

00:08:19.480 --> 00:08:21.720
pero la mayoría de cosas están en Storyboard.

00:08:21.720 --> 00:08:29.320
¿Tú sabes el tiempo que puede significar ir paso por paso migrándolo, probar?

00:08:29.320 --> 00:08:37.640
O sea, es increíble, o sea, es increíble que de repente digan esto y se ha añadido

00:08:37.640 --> 00:08:45.640
otra cosa, porque no acaba aquí, sino que sigue en esta beta, justo debajo hay otra

00:08:45.640 --> 00:08:53.120
cosa más, más grave diría incluso, y es que te dice que próximamente van a deprecar

00:08:53.120 --> 00:09:02.600
los IBDesignable, es decir, para los que no estéis muy metidos en el mundillo, tú puedes

00:09:02.600 --> 00:09:07.440
definir lo mismo que tú vas al Storyboard y digamos que puedes en las vistas cambiar

00:09:07.440 --> 00:09:13.720
fuentes, cambiar textos por diseño, el propio diseño, puedes ir modificándolo, pues esto

00:09:13.720 --> 00:09:14.720
te hace lo mismo.

00:09:14.720 --> 00:09:19.880
Sí, aparte del inspector de propiedades, que son parámetros que puedes cambiar dentro

00:09:19.880 --> 00:09:25.840
de la interfaz gráfica, que no tienes que programar, sino que tú tienes botones, selectores,

00:09:25.840 --> 00:09:30.480
selectores que dices, pues fuente de 14, fuente de tal, y todo eso se cambia a nivel de diseño.

00:09:30.480 --> 00:09:36.400
Eso es, pues te puedes crear tus propias propiedades que quieres cambiar también, digamos, de

00:09:36.400 --> 00:09:41.040
manera gráfica, te la puedes hacer, pues yo qué sé, le quieres decir, quieres cambiar

00:09:41.040 --> 00:09:46.120
que todavía no está hecho, yo qué sé, el color del sombreado o el radio del sombreado,

00:09:46.120 --> 00:09:50.000
cosas así, pues te creas tu propiedad y la expones.

00:09:50.000 --> 00:09:53.160
Yo lo uso mucho para el corner radius de las esquinas, por ejemplo.

00:09:53.160 --> 00:09:59.400
Te creas una extensión de la UI view o una UI view tuya particular y con las propias,

00:09:59.400 --> 00:10:04.400
haces una propiedad designable y lo que haces es que puedes configurártela desde el Storyboard.

00:10:04.400 --> 00:10:08.600
Pues el caso es que esas se van a deprecar, pues estamos en lo mismo, este proyecto tiene

00:10:08.600 --> 00:10:14.520
varios componentes con esas propiedades y si ponen que lo van a deprecar, significa

00:10:14.520 --> 00:10:24.840
que en Xcode 16 o en Xcode 14, o sea, 15.3 o 4 que salgan a abrir este año, ya no se

00:10:24.840 --> 00:10:25.840
van a poder utilizar.

00:10:25.840 --> 00:10:31.920
Con lo cual, el problema es que si tienes seteado ahí todas las propiedades, en el

00:10:31.920 --> 00:10:36.920
momento que ya no se usen, pues esas propiedades se desetean y ya no tienen los parámetros

00:10:36.920 --> 00:10:38.880
que has puesto, ¿no?

00:10:38.880 --> 00:10:50.560
Y ahí ya es cuando puse yo ese tuit que Apple está matando poco a poco, primero, no diría

00:10:50.560 --> 00:10:56.400
UIKit entero, sino ciertas partes como es el Storyboard, que recordemos que aparte de

00:10:56.400 --> 00:11:00.240
que yo creo que las tripas del Storyboard es bastante complicado, todo el código que

00:11:00.240 --> 00:11:05.160
te genera esa parte gráfica, no creo que sea algo muy sencillo, aparte ya tiene años

00:11:05.160 --> 00:11:09.560
y esa base de código, admiro a la gente que la tenga que tocar, ¿vale?

00:11:09.560 --> 00:11:14.480
Porque no creo que sea una tarea sencilla, pero a lo mejor no cargarse UIKit, pero ir

00:11:14.480 --> 00:11:20.320
dejando los Storyboards de lado, que ya han tenido varios problemas y ha habido muchas

00:11:20.320 --> 00:11:25.760
versiones de Xcode que no funcionaban como deberían, los Storyboards grandes, como no

00:11:25.760 --> 00:11:31.800
tengas un equipo potente, no hay Dios que los mueva, han hecho varias correcciones,

00:11:31.800 --> 00:11:38.640
pero bueno, siempre ha sido un componente bastante polémico, digamos, dentro de Xcode

00:11:38.640 --> 00:11:45.520
y yo creo que Apple con este movimiento de, primero, no corregir ese error, y segundo,

00:11:45.520 --> 00:11:50.800
decirte de repente que van a deprecar una de las funcionalidades avanzadas, digamos,

00:11:50.800 --> 00:12:00.440
que ofrece el Storyboard, para mí quiere decir que en Xcode 16, no sé, quizá tengamos

00:12:00.440 --> 00:12:07.600
todavía Storyboard, pero ya con idea de ir pensando que en una o dos versiones se acaba

00:12:07.600 --> 00:12:09.560
el chollo, no sé cómo lo ves tú, Julio.

00:12:09.560 --> 00:12:13.280
A ver, yo es que lo que veo son algunas cositas, ¿vale?

00:12:13.280 --> 00:12:17.800
Me refiero, yo la última vez que toqué UIKit, ¿vale?

00:12:17.800 --> 00:12:25.120
Con un palo, fue cuando di la parte de formación correspondiente en el Bootcamp, ¿vale?

00:12:25.120 --> 00:12:31.600
Que como los oyentes ya saben, el Bootcamp de Apple Coding Academy, pues, incluye el

00:12:31.600 --> 00:12:35.760
módulo de UIKit, porque obviamente UIKit a día de hoy sigue siendo importante.

00:12:35.760 --> 00:12:42.160
Entonces, cuando he ido, esta última vez, y luego cuando de vez en cuando me toca una

00:12:42.160 --> 00:12:47.480
aplicación de un cliente, tengo que tocar algo de UIKit, lo que yo me he dado cuenta

00:12:47.480 --> 00:12:53.680
es que, uno, no podemos olvidar que Apple recomienda encarecidamente desde hace tiempo

00:12:53.680 --> 00:12:59.520
en todos sus vídeos de UIKit que no usemos SIF, que no usemos X y VES, sino que usemos

00:12:59.520 --> 00:13:01.600
Storyboards, ¿vale?

00:13:01.600 --> 00:13:03.080
Porque es lo que Apple recomienda.

00:13:03.080 --> 00:13:10.040
Sin embargo, los Storyboards históricamente siempre han tenido problemas de redibujado,

00:13:10.040 --> 00:13:15.760
de tú haces un cambio y no se refleja y tienes que salirte del código y volver a entrar,

00:13:15.760 --> 00:13:20.320
de pronto se queda atascado, lógicamente tienes que estar refactorizando el Storyboard

00:13:20.320 --> 00:13:25.680
porque como metas muchas pantallas en un solo Storyboard, como tú bien dices, o tienes

00:13:25.680 --> 00:13:31.800
una máquina, pues eso, M1 Pro, M1 Max, una máquina así potentilla, con bastante memoria

00:13:31.800 --> 00:13:37.400
o le cuesta bastante renderizarlo, no podemos olvidar que un Storyboard no deja de ser un

00:13:37.400 --> 00:13:40.000
XML, que lo que está haciendo es leerse...

00:13:40.000 --> 00:13:42.240
Pero de un tamaño que no... que flipas.

00:13:42.240 --> 00:13:47.760
Claro, de un tamaño gigantesco y que tiene que ser leído y parseado en tiempo real y

00:13:47.760 --> 00:13:52.560
dibujado con la correspondiente configuración que tú tienes en el XML.

00:13:52.560 --> 00:13:59.400
Y ojo, porque es inviable que dos personas toquen la parte gráfica de un Storyboard.

00:13:59.400 --> 00:14:00.400
Exacto.

00:14:00.400 --> 00:14:01.400
Es que al final...

00:14:01.400 --> 00:14:08.000
Es inviable porque no es humanamente legible, os quiero decir, tú vas a hacer un Merge

00:14:08.000 --> 00:14:13.800
de algo que has cambiado y como te dio un conflicto y el propio Git en el Merge se puede

00:14:13.800 --> 00:14:17.520
liar perfectamente y cargarse el Storyboard.

00:14:17.520 --> 00:14:25.560
Entonces Apple no quiere que programemos porque, a ver, seamos sinceros, si ya tenemos una

00:14:25.560 --> 00:14:33.280
experiencia grande y estamos acostumbrados a manejar con código UIKit, bueno, pues adelante,

00:14:33.280 --> 00:14:38.520
es decir, se puede hacer con código las Constraints, se puede hacer con código todo, pero hacerlo

00:14:38.520 --> 00:14:41.600
con código todo, ojito, ¿vale?

00:14:41.600 --> 00:14:47.360
Pero en fin, hay que tener claro lo que estás haciendo, no es algo que todo el mundo sea

00:14:47.360 --> 00:14:52.320
capaz de hacer y, desde luego, el trabajo que te ahorras con los Storyboards a nivel

00:14:52.320 --> 00:14:56.680
de picar código es bastante importante, ¿vale?

00:14:56.680 --> 00:14:57.680
Yo no...

00:14:57.680 --> 00:15:07.920
A ver, yo he desarrollado UIKit tanto programáticamente como a través de XIBs, como a través de

00:15:07.920 --> 00:15:13.680
UIKit, ¿vale?, a través de Storyboards, y, desde luego, programáticamente es mucho

00:15:13.680 --> 00:15:21.120
más complicado, sobre todo porque, sí, puede ser, porque yo he tenido alumnos que han podido

00:15:21.120 --> 00:15:26.800
trabajar todo programáticamente con UIKit, pero previamente tú te tienes que haber montado

00:15:26.800 --> 00:15:33.760
una librería que te proporcione una forma simple de no tener que tirar las cientos de

00:15:33.760 --> 00:15:39.120
líneas de código que te van a quedar si lo vas a hacer simplemente por código, ¿vale?

00:15:39.120 --> 00:15:41.640
O sea, por código no es la solución, ¿vale?

00:15:41.640 --> 00:15:46.000
Yo sé que puede haber mucha gente que se sienta más a gusto con eso, me parece genial,

00:15:46.000 --> 00:15:51.640
si ya tienes una librería bien montada para hacerlo programáticamente, creo que es la

00:15:51.640 --> 00:15:57.800
forma mejor para evitar cualquier tipo de problema en el futuro, ¿vale?, y poder reutilizar

00:15:57.800 --> 00:16:03.780
todo eso, pero, desde luego, repito, en mi opinión no es la solución ideal porque requiere

00:16:03.780 --> 00:16:07.680
mucho trabajo previo para que eso esté afinado y funcionando bien.

00:16:07.680 --> 00:16:11.960
Si ya has hecho ese trabajo previo, perfecto, enhorabuena, tienes la solución, pero la

00:16:11.960 --> 00:16:16.160
mayoría de los mortales lo que hacemos es tirar de Storyboard a X y B porque es lo que

00:16:16.160 --> 00:16:18.560
nos facilita mucho ese aspecto.

00:16:18.560 --> 00:16:24.360
Pero como digo, parece que hay como una serie de errores, ¿vale?, que es a lo que iba,

00:16:24.360 --> 00:16:30.540
una serie de problemas con los Storyboards de redibujado, por ejemplo, los Designables,

00:16:30.540 --> 00:16:36.240
a mí me han fallado históricamente, es decir, es normal que de pronto el Designable te dé

00:16:36.240 --> 00:16:41.520
un error y te diga, no se ha podido compilar o no se ha podido generar la propiedad y tienes

00:16:41.520 --> 00:16:47.320
que salir, volver a entrar, a veces ni siquiera son capaces de... a lo mejor se dibuja o no

00:16:47.320 --> 00:16:51.560
porque sabes que los Designables tú puedes cambiar, por ejemplo, yo lo hacía, la propiedad

00:16:51.560 --> 00:16:59.180
del Cornet Radius, la cambias en lo que es el inspector de propiedades y se cambiaba

00:16:59.180 --> 00:17:04.280
en la propia interfaz y veías el efecto en la propia interfaz, pero eso funcionaba cuando

00:17:04.280 --> 00:17:11.120
le daba la gana, cuando no, etcétera, entonces yo lo que veo, en mi opinión al respecto,

00:17:11.120 --> 00:17:18.320
es que todo lo que a Apple le va a suponer un tiempo de encontrar por qué algo no funciona,

00:17:18.320 --> 00:17:22.960
su solución va a ser, lo quito y se acabó el problema, ¿vale?

00:17:22.960 --> 00:17:27.720
Es un poco como lo que han hecho con Swift Data, es decir, yo tengo un error, Swift Data

00:17:27.720 --> 00:17:34.360
funcionaba perfecto en segundo plano, ¿vale? Perfecto, hasta la beta 7, perdón, hasta la beta 6 de

00:17:34.360 --> 00:17:40.120
Scope 15, Swift Data funcionaba perfectamente todo en segundo plano y tú ponías un task

00:17:40.120 --> 00:17:47.240
y metías una carga en batch de miles de registros y la app no se paraba ni tenía ningún problema,

00:17:47.240 --> 00:17:51.840
iba genial, pero ¿cuál fue el problema? El problema es que en el momento en el que la

00:17:51.840 --> 00:17:59.480
base de datos grababa la información, no había forma de conectar esa llamada para que la interfaz

00:17:59.480 --> 00:18:07.040
se refrescara sobre lo que se había rellenado. ¿Qué ha hecho Apple? Decir, por la calle

00:18:07.040 --> 00:18:12.400
del medio lo meto todo en el main actor y ya tomás por saco, ¿vale? Entonces, ¿qué

00:18:12.400 --> 00:18:18.400
ha hecho? Cargarse la concurrencia para que la interfaz se refresque cuando hay un cambio

00:18:18.400 --> 00:18:23.080
en SwiftUI, es decir, han tirado por la calle del medio por la solución chapuza, fácil,

00:18:23.080 --> 00:18:31.200
rápida e ineficiente. ¡Hostia, Apple! Y esto del designable me suena a eso, me suena a

00:18:31.200 --> 00:18:37.400
esto es un marrón que hizo alguien que no sabemos ni quién es, que ya no está en Apple

00:18:37.400 --> 00:18:42.480
y que a saber qué puñetas hizo este por dentro para que funcionara, ¿quién se va a atrever

00:18:42.480 --> 00:18:49.040
a tocar este código? Lo quitamos y a volar. Es que me suena a eso, yo no sé cómo lo

00:18:49.040 --> 00:18:58.760
ves tú. Sí, sí, sí, yo de hecho en su día yo me parecía cuando sacaron Swift Playgrounds

00:18:58.760 --> 00:19:06.300
que la estrategia de Apple iba a ser como dejar de lado Scope o dejarlo como muy avanzado

00:19:06.300 --> 00:19:12.600
y ir vitaminando Playgrounds, pero también resulta que Playgrounds de repente dejó de

00:19:12.600 --> 00:19:19.280
hacerle caso, luego saca dos cosas cada dos años. Entonces me tiene un poco confundido,

00:19:19.280 --> 00:19:22.920
pero esto sí que suena a esto es algo que hemos arrastrado siempre, porque de hecho

00:19:22.920 --> 00:19:28.280
yo me acuerdo que de una versión menor a otra, de repente había veces que estabas

00:19:28.280 --> 00:19:32.160
dos o tres meses trabajando en una versión de Scope que cada poco tenías que, yo me

00:19:32.160 --> 00:19:36.920
acuerdo de cerrar y abrir Scope cada poco porque el Storyboard se iba a tomar por saco.

00:19:36.920 --> 00:19:41.680
O sea, me acuerdo de estar tiempo eso hasta que se acaba la siguiente versión de Scope,

00:19:41.680 --> 00:19:48.160
rezabas un poco y ostras, en esta sí funcionaba, pero que se te iba... Luego, por ejemplo,

00:19:48.160 --> 00:19:52.000
a mí muchas veces no me encuentra cuando me pongo en una de las vistas, no me encuentra

00:19:52.000 --> 00:19:55.440
la clase que tira de esa vista y es imposible. Tengo que cerrar el proyecto y volverlo a

00:19:55.440 --> 00:20:04.280
abrir porque no hace el match directo. No sé, yo creo que sí que Apple es... A ver,

00:20:04.280 --> 00:20:09.320
se junta que tiene muchos esfuerzos en la parte de Vision Pro, se junta que tenemos

00:20:09.320 --> 00:20:16.080
esfuerzos de lo que hemos hablado muchas veces, que hay escasez de personal cualificado, entonces

00:20:16.080 --> 00:20:21.000
pues no sé si les cuesta encontrar ingenieros y que aparte Apple tiene un poco esa política

00:20:21.000 --> 00:20:28.360
de no quiero contratar muchísima gente, quiero contratar con ojo a gente que sea buena y

00:20:28.360 --> 00:20:34.560
no meter a 800 en un proyecto y que al final nadie sepa hacer nada. Y están empezando

00:20:34.560 --> 00:20:40.720
como a elegir sus batallas. En plan, ahora tenemos otro sistema más que es Vision OS,

00:20:40.720 --> 00:20:46.880
pues eso, necesitamos más gente manteniéndolo, pues los marrones pues vamos a chutarlos y

00:20:46.880 --> 00:20:52.400
vamos a ir quitándolo y sobre todo teniendo alternativa, porque te dicen, pues mira, yo

00:20:52.400 --> 00:20:59.640
quiero que lo migres todo a SwiftUI. Y otra cosa que hemos hablado siempre, Apple cada

00:20:59.640 --> 00:21:05.680
vez que saca un sistema operativo nuevo, todas las aplicaciones de la propia Apple, podcasts,

00:21:05.680 --> 00:21:12.680
mensajes, todo, ya nos tienen que dar soporte a lo anterior. Es decir, que en iOS 17 probablemente

00:21:12.680 --> 00:21:18.440
la aplicación de mensajes a lo mejor ha adoptado una API nueva que no estaba en iOS 16 y esa

00:21:18.440 --> 00:21:22.960
parte de código hasta luego. Ahí se queda en el repositorio por si sacan una versión

00:21:22.960 --> 00:21:30.120
menor de iOS 16 para compilarlo todo junto, pero eso no lo vuelve a tocar nadie y en la

00:21:30.120 --> 00:21:36.200
base de código del sistema actual ya no está. Y si ahí se presenta un error, nadie lo va

00:21:36.200 --> 00:21:44.920
a corregir. Ese error va a quedar siempre. Al final, ¿qué sucede? Por ejemplo, Playgrounds,

00:21:44.920 --> 00:21:50.480
no la app Swift Playgrounds, sino lo que es el proyecto de Playgrounds en Scope, tiene

00:21:50.480 --> 00:21:58.440
un error desde hace... pues creo que desde... porque claro, yo en las formaciones uso mucho

00:21:58.440 --> 00:22:05.360
Playgrounds, porque es el entorno ideal para educación, para enseñar Swift y para enseñar

00:22:05.360 --> 00:22:13.640
temas prototipados de red, etcétera. Bueno, pues Playgrounds se va estropeando cada vez

00:22:13.640 --> 00:22:19.280
más. O sea, Playgrounds ha tenido un error histórico desde, creo yo, prácticamente

00:22:19.280 --> 00:22:27.000
Scope 12, estamos en la 15, de que cada vez que creas una página nueva, el analizador

00:22:27.000 --> 00:22:33.440
de código se resetea y deja de funcionar. Y tienes que salir del Playgrounds y volverlo

00:22:33.440 --> 00:22:42.840
a cargar otra vez, para que el motor de escritura, el motor de lo que sería el LSP, el motor

00:22:42.840 --> 00:22:50.600
de escritura de código, de ayuda... El archiconocido proceso SourceKit. Exacto, el proceso SourceKit

00:22:50.600 --> 00:22:54.880
famoso que se colgaba y que se sigue colgando cada vez que le da la gana y eso que se supone

00:22:54.880 --> 00:23:01.120
que cada año lo reescriben desde cero. Sí, sí, eso es una cosa que yo flipo. Pues eso

00:23:01.120 --> 00:23:06.880
da problemas con Playgrounds y no han sido capaces de arreglarlo. ¿Y este año han conseguido

00:23:06.880 --> 00:23:13.280
arreglar SourceKit en SwiftUI? Pues hombre, en una parte sí, pero en otra no. Cuando

00:23:13.280 --> 00:23:20.280
ya te metes a profundidad dentro de varios niveles de SwiftUI, se sigue perdiendo igual

00:23:20.280 --> 00:23:26.320
y te sigue dando errores que no existen o te da cosas raras. Luego, además, este año

00:23:26.320 --> 00:23:34.400
no sé por qué le han dado prioridad a la construcción sin usar los closers múltiples

00:23:34.400 --> 00:23:40.320
de cierre, cosa que yo cuando hago un botón, para mí un botón en SwiftUI es botón, llave,

00:23:40.320 --> 00:23:44.920
acción, espacio, label, dos puntos, llave y siguiente. Bueno, pues no hay huevos de

00:23:44.920 --> 00:23:51.040
construir el código de esa manera. Entonces es como, vamos a ver, o tonterías como lo

00:23:51.040 --> 00:23:56.520
que ya hemos comentado aquí alguna vez, de deprecar Corners Radius. Pero perdona, ¿qué

00:23:56.520 --> 00:24:03.720
estás haciendo? Son cosas que es como, no sé, como si tuvieran a alguien dentro que

00:24:03.720 --> 00:24:11.080
está tomando decisiones sin sentido a base de no me voy a molestar. Entonces, no sé,

00:24:11.080 --> 00:24:17.800
no entiendo, no entiendo hacia qué dirección van realmente. Y a mí me molesta bastante

00:24:17.800 --> 00:24:25.600
el hecho de que un entorno como Playground que tiene un potencial brutal esté, sientas

00:24:25.600 --> 00:24:31.840
sinceramente que está abandonado porque probablemente quien hizo el Playground en su momento ya

00:24:31.840 --> 00:24:36.440
no esté en Apple y nadie se atreve a tocar aquello porque, hostia, espérate, a ver esto

00:24:36.440 --> 00:24:40.840
cómo está hecho. Y en muchas ocasiones esa es la impresión que te da, que Apple abandona

00:24:40.840 --> 00:24:46.400
desarrollos porque la persona que los estaba haciendo ya no está en Apple y nadie se atreve

00:24:46.400 --> 00:24:53.240
a meterse en ese código a buscar o solucionar errores. Y como ahora todos son esfuerzos

00:24:53.240 --> 00:24:59.560
a los nuevos sistemas, pues el resto de cosas que la den por saquito. Entonces, no sé,

00:24:59.560 --> 00:25:02.440
se me escapa. No sé cómo ves tú esto al respecto.

00:25:02.440 --> 00:25:08.680
Yo es que tengo la misma opinión que, además, cosas como, por ejemplo, Playgrounds en su

00:25:08.680 --> 00:25:13.960
día, yo cuando lo mostraron aluciné. Dije, sobre todo, o sea, me viene bien a mí que

00:25:13.960 --> 00:25:17.680
ya llevo un tiempo, pero para alguien que está aprendiendo esto es una herramienta

00:25:17.680 --> 00:25:24.760
y casi que es un básico. Porque ahora yo creo que cada lenguaje que crean es como lo

00:25:24.760 --> 00:25:29.760
primero que crear es un Playground para que la gente investigue. O sea, es lo primero

00:25:29.760 --> 00:25:32.520
que tienes que hacer. Lo mínimo que tiene que tener un lenguaje es un Playground para

00:25:32.520 --> 00:25:38.840
que la gente en tiempo real, sin tener que compilar, lo pueda hacer. Y seguramente que

00:25:38.840 --> 00:25:44.220
sea algo como tú dices, porque supongo que, claro, haya muchas dependencias que se comparten

00:25:44.220 --> 00:25:49.560
y parece que actualizan ciertas dependencias, pero que hay otra capa que eso que la ha hecho

00:25:49.560 --> 00:25:53.560
alguien que ya no está o hay un marrón ahí de un código que se lleva tiempo sin tocar

00:25:53.560 --> 00:26:00.880
y que va a llevar tiempo, valga la redundancia, el arreglarlo o al adaptarlo a las nuevas

00:26:00.880 --> 00:26:08.320
dependencias que se han cambiado y no se hace. Se deja así un poco como está, no se dice

00:26:08.320 --> 00:26:15.360
nada y se deja como está y ya veremos.

00:26:15.360 --> 00:26:22.560
Son cosas que no entiendo y desde luego lo que se ve muy claramente, en mi opinión,

00:26:22.560 --> 00:26:30.840
es que Apple tiene ahora mismo una carencia muy grande de talento a nivel de desarrollo,

00:26:30.840 --> 00:26:38.440
que le falta tener más gente suficientemente cualificada para hacer todo lo que se han

00:26:38.440 --> 00:26:47.840
propuesto hacer. Y luego aparte, si juntamos lo que se comenta en los mentideros de que

00:26:47.840 --> 00:26:53.920
hay una presión terrible, de que los desarrolladores están echando más horas que tal porque hay

00:26:53.920 --> 00:27:01.120
una presión absoluta por entregar ciertos hitos o ciertas fechas, etcétera, y que incluso

00:27:01.120 --> 00:27:07.920
niegan vacaciones, etcétera, hay siempre ahí como un rumor por encima. Se han visto, lo

00:27:07.920 --> 00:27:13.880
hemos comentado en alguna ocasión, de una empresa que compraron hace poco en Barcelona

00:27:13.880 --> 00:27:18.960
de inteligencia artificial en el que uno de los empleados empezó a decir que ahí había

00:27:18.960 --> 00:27:24.280
un abuso terrible por parte y que Apple no hacía nada ni lo impedía. Y hay mucha gente

00:27:24.280 --> 00:27:32.680
que ha salido de Apple en los últimos años. Por ejemplo, recordamos a nuestra conocida

00:27:32.680 --> 00:27:39.320
Natalia Panferova, la muchacha esta que tiene el blog este de Neil Coalescence, que era

00:27:39.320 --> 00:27:45.880
una de las ingenieras de SwiftUI, pero que salió de Apple. Y yo no le he oído decir

00:27:45.880 --> 00:27:51.840
nunca por qué. Vale, sí he decir que estaba muy orgullosa, tal y cual, pero sí he oído

00:27:51.840 --> 00:27:56.720
a mucha gente decir que trabajar en Apple te quema mucho porque los niveles de presión

00:27:56.720 --> 00:28:04.640
que hay son muy altos y porque, lógicamente, se les está exigiendo un nivel de plazos,

00:28:04.640 --> 00:28:11.560
entregas, trabajo, etcétera. Y yo lo que veo desde fuera es que ahora mismo Apple tiene

00:28:11.560 --> 00:28:22.360
una enorme carencia de perfiles de alto nivel que se encarguen de tenerlo todo al día.

00:28:22.360 --> 00:28:27.640
Entonces, yo lo que veo es que no dan abasto. Esa es la impresión que da desde fuera, que

00:28:27.640 --> 00:28:32.720
no dan abasto. Y volvemos a repetir, esto no es cuestión de dinero. Tú puedes tener

00:28:32.720 --> 00:28:37.920
todo el dinero del mundo, que Apple lo tiene, ¿vale? Pero esto no es cuestión de dinero,

00:28:37.920 --> 00:28:45.080
es encontrar a gente que tenga el nivel de cualificación y conocimiento para poder hacer

00:28:45.080 --> 00:28:52.000
eso. Y eso que se le está pidiendo requiere de tan alta cualificación que, uno, es muy

00:28:52.000 --> 00:28:58.340
difícil de encontrar en el mercado. Dos, las leyes de trabajo en Estados Unidos no

00:28:58.340 --> 00:29:04.480
ayudan porque no podemos olvidar, por ejemplo, que Natalia vive en Nueva Zelanda y trabajaba

00:29:04.480 --> 00:29:11.080
en remoto con Apple. Es decir, estaba contratada desde Nueva Zelanda. Y Apple tiene sedes de

00:29:11.080 --> 00:29:17.120
desarrollo en un montón de países como, por ejemplo, tiene en Irlanda gente de desarrollo,

00:29:17.120 --> 00:29:23.400
tiene también aquí en España, tiene ciertos equipos que trabajan. Porque es imposible

00:29:23.400 --> 00:29:30.000
que todo el mundo esté en el Apple Park porque, además, irse a mudarse allí a California,

00:29:30.000 --> 00:29:35.560
en fin. Barato no es. Claro, por mucho que te paguen, a ti te pueden estar pagando fácilmente

00:29:35.560 --> 00:29:41.760
como ingeniero senior en Apple, pues fácil, 300.000 dólares al año, que aquí en España

00:29:41.760 --> 00:29:48.000
sería como algo abusivo en el sentido de decir, Dios mío, ¿qué es lo que estás haciendo?

00:29:48.000 --> 00:29:52.600
Y se lo están pagando un desarrollador senior, ¿vale? No es algo que sea un perfil muy alto

00:29:52.600 --> 00:29:58.880
y le pueden estar pagando fácil 200, 250, 300.000 dólares al año. El problema es que

00:29:58.880 --> 00:30:04.320
para pagarte una casa compartida ya está gastando 100.000, ¿vale? Porque ese es el

00:30:04.320 --> 00:30:12.560
nivel que ahora mismo en San José, en Cupertino, en fin, en toda esa zona de lo que es el Valle

00:30:12.560 --> 00:30:18.480
de Santa Clara. Entonces, eso también es un problema para Apple, para captar talento.

00:30:18.480 --> 00:30:25.320
El problema de que sus oficinas son maravillosas y estupendas, pero vivir allí es muy caro,

00:30:25.320 --> 00:30:30.640
no hay suficiente sitio y luego pues tiene que contratar a nivel internacional. Y, obviamente,

00:30:30.640 --> 00:30:35.360
tener una persona que te está trabajando desde Nueva Zelanda o desde España supone, pues

00:30:35.360 --> 00:30:43.920
bueno, pues aquí en España tenemos nueve horas más que en California. Entonces, supone

00:30:43.920 --> 00:30:48.680
que si yo estuviera trabajando con Apple desde España, tendría que sincronizarme con sus

00:30:48.680 --> 00:30:55.840
horarios, ¿vale? Entonces, en fin, es bastante complicado y yo, en mi opinión, creo que

00:30:55.840 --> 00:31:02.600
Apple ahora mismo está superada a todos los niveles y necesita incorporar a más perfiles

00:31:02.600 --> 00:31:07.080
y no los encuentra, porque os garantizo que no los hay en el mercado. Entonces...

00:31:07.080 --> 00:31:12.520
Sí, sí, pero es que bueno, yo también lo veo en España, que en España perfiles altos

00:31:12.520 --> 00:31:16.120
de programación es que son muy difíciles de encontrar también.

00:31:16.120 --> 00:31:21.960
Y ya no hablamos de perfiles de entornos Apple, hablamos de perfiles de programación. O sea,

00:31:21.960 --> 00:31:30.480
tú hoy día encontrar a un tío programador que pilote a nivel premium máximo, o sea,

00:31:30.480 --> 00:31:37.000
un Mark o un Arturo o un Joe o alguien así que esté a un nivel de experiencia, de conocimiento,

00:31:37.000 --> 00:31:42.480
que sea capaz de coger un proyecto que no es suyo y arreglarlo o entenderlo en horas

00:31:42.480 --> 00:31:51.800
o en pocos días, hoy día somos unicornios, macho. Y como eso te digo, pues eso un Antonio

00:31:51.800 --> 00:31:59.880
Leiva en Android o alguien que tenga esos niveles de ser capaz de entender el código

00:31:59.880 --> 00:32:06.600
un poco más allá. Entonces, hay muy poca gente que tenga ese nivel tan alto de conocimiento,

00:32:06.600 --> 00:32:12.840
de abstracción y de análisis. Y claro, y luego encima, en un país como España, donde

00:32:12.840 --> 00:32:20.240
no se valora a la gente en la medida de lo posible y al final se provocan envidias, susceptibilidades,

00:32:20.240 --> 00:32:25.640
en fin, aquí tenemos un tejido productivo maravilloso, pues ya ni te cuento. Entonces,

00:32:25.640 --> 00:32:26.960
en fin.

00:32:26.960 --> 00:32:34.160
Pues sí, pero esperemos, Julio, yo tengo la esperanza de que la siguiente beta, de

00:32:34.160 --> 00:32:41.000
repente, mejore esta parte. Ojalá también para la parte que te toca. Bueno, que nos

00:32:41.000 --> 00:32:48.200
toca a todos, pero bueno, el deseo que tienes tú de ese refinamiento de Swift Data. Y quiero

00:32:48.200 --> 00:32:52.800
acabar lo que he estado haciendo yo con algo un poco más positivo, que siempre parece

00:32:52.800 --> 00:33:02.600
que venimos aquí a contar penas y desgracias, que es que, por ejemplo, en mi trabajo coincide

00:33:02.600 --> 00:33:12.040
que tenemos un equipo de IOS medio, medio, no voy a decir grande, pero medio, que yo

00:33:12.040 --> 00:33:16.680
en las empresas que me he cruzado no es muy normal. Lo normal es que sean 1, 2, 3 a lo

00:33:16.680 --> 00:33:24.320
sumo. Pero lo bueno de tener un equipo grande o medio y sobre todo de tener perfiles medio

00:33:24.320 --> 00:33:33.960
o senior, es que se genera mucho debate y se aprende muchísimo. Y es casi como una

00:33:33.960 --> 00:33:40.600
recomendación que os hago a los que estéis empezando, que si tenéis oportunidad de elegir,

00:33:40.600 --> 00:33:43.640
porque se lo digo a los que están empezando, porque los que llevan tiempo seguro que ya

00:33:43.640 --> 00:33:49.880
lo han descubierto también, que es muy bueno estar en un equipo y con gente que sabe tanto

00:33:49.880 --> 00:33:57.920
o más que tú, porque de verdad que se disfruta por eso. Porque hay cosas que yo al final

00:33:57.920 --> 00:34:02.640
muchas veces en otros puestos de trabajo que tenía, pues acababa teniendo que hablar con

00:34:02.640 --> 00:34:06.880
Julio fuera de mi área laboral. Pero aquí puedes aprovechar tu área laboral a algo

00:34:06.880 --> 00:34:11.240
que a la empresa también le viene muy bien, que es de la que estás desarrollando. Oye,

00:34:11.240 --> 00:34:16.640
voy a hacer esto. ¿Qué opináis de tal cosa? ¿Qué opináis de esto? Oye, creo que aquí

00:34:16.640 --> 00:34:22.480
voy a montar esto de esta manera. ¿Qué os parece? ¿Me dejo algo o no? Porque muchas

00:34:22.480 --> 00:34:28.960
veces es casi como hablarlo en alto, que te ayuda un poco a ti a darle una vuelta más.

00:34:28.960 --> 00:34:34.000
Y aparte, que otro te puede decir algo que, yo lo que digo, que a ti se te ha escapado

00:34:34.000 --> 00:34:39.880
o que no has puesto en la balanza donde has decidido lo que hacer, no está puesta esa

00:34:39.880 --> 00:34:45.200
acción. Y nada, pues ahora mismo en el trabajo que estoy, pues tengo la oportunidad de hacerlo

00:34:45.200 --> 00:34:51.160
y la verdad que es una experiencia muy buena que he tenido en estas últimas semanas. Por

00:34:51.160 --> 00:34:52.160
dar la nota positiva.

00:34:52.160 --> 00:35:02.240
Sí, al final, si se genera un debate interesante sobre, pues eso, porque es una cosa que yo

00:35:02.240 --> 00:35:07.920
muchas veces le digo a los alumnos, que es importante que los equipos estén bien sincronizados,

00:35:07.920 --> 00:35:13.920
que todos trabajen a la par, de que haya debates sobre cómo abordar tal problema, tal otro,

00:35:13.920 --> 00:35:18.520
etcétera. Entonces, bueno, la verdad que tener ese tipo de... y que te hagan ver cosas

00:35:18.520 --> 00:35:27.560
que a lo mejor tú no estás viendo o no has caído, etcétera, siempre es algo que es bastante

00:35:27.560 --> 00:35:28.560
interesante.

00:35:28.560 --> 00:35:34.240
Bueno, incluso Julio, y seguro que te pasa a ti también, a mí cuando he dado cursos

00:35:34.240 --> 00:35:40.360
me ha pasado alguna vez, que a veces me han hecho una pregunta de, pues esto jamás lo

00:35:40.360 --> 00:35:45.360
había visto desde este enfoque y alguien que a lo mejor no había programado en su vida,

00:35:45.360 --> 00:35:51.480
de repente te abren los ojos de algo, pues tienes razón de esto, que a lo mejor investigas

00:35:51.480 --> 00:35:56.040
y luego le encuentras alguna pega a lo que te cuentas, está claro. Pero muchas veces

00:35:56.040 --> 00:36:01.640
el simple... y yo lo hago muchas veces, lo de dar... incluso cuando estaba en un equipo

00:36:01.640 --> 00:36:05.320
más pequeño, a lo mejor entre todos los de tecnología, aunque no fueran programadores

00:36:05.320 --> 00:36:11.480
de iOS precisamente, ponía la idea, porque programadores de Android o de backend, a lo

00:36:11.480 --> 00:36:17.280
mejor en eso también se les ocurría algo o con su experiencia y muchas veces te daban

00:36:17.280 --> 00:36:22.120
como otra visión. Y nada, que me estoy extendiendo un montón, Julio, cuéntanos... bueno, primero

00:36:22.120 --> 00:36:28.240
cuéntanos qué tienes en la muñeca, que te veo como que te cuesta un poco levantar

00:36:28.240 --> 00:36:33.080
la mano izquierda y qué has estado haciendo estas dos semanas.

00:36:33.080 --> 00:36:40.760
He estado intentando no darle golpes con la hebilla de la... no darle golpes a la pantalla

00:36:40.760 --> 00:36:51.880
del Apple Watch Ultra 2 con la hebilla de la correa de trenzado fino, que... fino, fino

00:36:51.880 --> 00:36:59.400
filipino, trenzado filipino, bendito sea el poder de Jobs. ¡Madre mía! Uf, qué mala

00:36:59.400 --> 00:37:07.360
impresión, de verdad. Yo entiendo perfectamente el objetivo del nuevo tejido de Apple, lo

00:37:07.360 --> 00:37:17.720
aplaudo, ole Apple, pero la calidad es espantosa. Para mí, personalmente, no me gusta la calidad

00:37:17.720 --> 00:37:24.280
que tiene la correa. Lo que es la correa de trenzado fino me parece que no es un material

00:37:24.280 --> 00:37:31.600
agradable al tacto, que no es un material que dé una impresión de calidad premium.

00:37:31.600 --> 00:37:38.600
Recordemos que son 80 pavos de correa, ¿vale? 70-80 pavos de correa. Y luego, encima, no

00:37:38.600 --> 00:37:44.560
está bien pensada, porque la hebilla metálica, cuando te intentas quitar el reloj, como tiene

00:37:44.560 --> 00:37:51.320
como una especie como de huecos, ¿no? Como que va pa-pa-pa-pa-pa-pa-pa, ¿vale? Pues al

00:37:51.320 --> 00:37:56.400
tirar de ella, lo normal es que, con la hebilla, le hagas a la pantalla ¡plof! y le metas

00:37:56.400 --> 00:38:01.080
un guantazo, que es como, Dios mío, o sea, te da un mal rollo increíble, ¿vale?

00:38:01.080 --> 00:38:04.960
Veas pasar toda tu vida por delante. Sí, sí, totalmente. Entonces, es que no

00:38:04.960 --> 00:38:11.040
tiene ese tema, ¿vale? El material que tiene, pues es el trenzado fino de Apple, ¿vale?

00:38:11.040 --> 00:38:15.680
Que es un nuevo material creado por Apple, con huella de carbono cero, que además viene

00:38:15.680 --> 00:38:21.360
en la caja indicado con el símbolo de huella de carbono cero. Es un material que está

00:38:21.360 --> 00:38:27.480
hecho en un 68% de material de consumo reciclado, ¿vale? O sea, se supone que es como una especie

00:38:27.480 --> 00:38:34.120
de material a base de reciclado de otros productos, ¿vale? En el que se ha hecho una forma muy,

00:38:34.120 --> 00:38:40.520
muy, muy fina de material y con ese hilo fino, que tiene un aspecto como de, como una especie

00:38:40.520 --> 00:38:45.680
de hilo de pescar, ¿vale? Es como un nylon muy fuerte, ¿vale? No es algodón, que es

00:38:45.680 --> 00:38:49.960
un hilo más suave y tal, sino es como un hilo de nylon, pero como más grueso, como

00:38:49.960 --> 00:38:55.480
más tirando a hilo de pescar, ¿vale? Pero, insisto, muy finito. Entonces, ese hilo lo

00:38:55.480 --> 00:39:06.200
han creado en un patrón trenzado, ¿vale? Creando una textura determinada, que es el

00:39:06.200 --> 00:39:11.000
que permite hacer ese tejido con el que están hechas ciertas fundas de las que hay ahora

00:39:11.000 --> 00:39:17.360
para los iPhones, de Apple, ¿no? Algunas correas del Apple Watch, etcétera, etcétera.

00:39:17.360 --> 00:39:23.840
Yo es un material que ya probé en el Apple Store y es que no, no, no, no, no tiene, no...

00:39:23.840 --> 00:39:31.680
Repito, aplaudo el gesto de Apple, entiendo perfectamente que lo hayan hecho, me parece

00:39:31.680 --> 00:39:38.240
algo que está bien hecho, porque es algo para el planeta, pero hemos perdido como usuarios

00:39:38.240 --> 00:39:44.680
porque ahora más que nunca el precio no está justificado a nivel de la sensación de calidad

00:39:44.680 --> 00:39:51.040
percibida, ¿de acuerdo? Entonces, pues no, no me parece y al final pues acabas tirando

00:39:51.040 --> 00:39:55.880
de una correa de AliExpress, ¿vale? Porque es que es lo que tiene, ¿vale? Entonces bueno,

00:39:55.880 --> 00:40:01.840
pues en fin. Pero bueno, en cuanto a lo que es el reloj, pues bueno, venía de un Apple

00:40:01.840 --> 00:40:11.520
Watch Series 4 y bueno, pues entonces al final pues ese Apple Watch Series 4 pues se ha jubilado

00:40:11.520 --> 00:40:17.760
ya porque además él estaba rankeando, empezaba a fallarle la batería, los sensores, a lo

00:40:17.760 --> 00:40:22.920
mejor prácticamente no me movía durante el día y de pronto cerraba el círculo de ejercicio

00:40:22.920 --> 00:40:28.160
y era como pues no sé qué he estado haciendo para esto, no soy merecedor de tanto, de este

00:40:28.160 --> 00:40:33.560
cierre, ¿no? Y ahora bueno, pues ya con este pues ya sí tengo un reloj más moderno, con

00:40:33.560 --> 00:40:39.520
conectividad móvil, etcétera y bueno, la verdad que muy bien, muy contento. Entonces

00:40:39.520 --> 00:40:46.400
bueno, esa ha sido mi novedad, ¿vale? Yo en este, en estos días, ¿vale? Aunque no

00:40:46.400 --> 00:40:52.900
soy persona que le guste mucho hacerme público a este sentido, pues he cumplido 48 años

00:40:52.900 --> 00:40:59.260
ya, que se dice pronto, y entonces bueno, pues este ha sido mi autorregalo de, autorregalo

00:40:59.260 --> 00:41:04.600
y regalo a nivel general de la familia, de cumpleaños, ¿no? Entonces bueno, pues ha

00:41:04.600 --> 00:41:09.000
sido un poco el tema. Pero pareces más joven, Julio, que la edad es un número. Por el reloj,

00:41:09.000 --> 00:41:15.040
¿no? Lo has dicho. Te has comprado un reloj que es para gente que se juega la vida. Total,

00:41:15.040 --> 00:41:19.280
de hecho sentí unas ganas locas de subir el Everest en cuanto me lo puse, fue como

00:41:19.280 --> 00:41:27.160
un, Dios mío, tengo que ir al Everest, ¿no? Entonces bueno, pues eso es un poco el tema.

00:41:27.160 --> 00:41:31.920
Así que bueno, la verdad que bien, estoy contento en ese sentido, ¿vale? Y además

00:41:31.920 --> 00:41:38.960
pues ahora con el tema de la conectividad móvil, pues aunque hace cosas raras, ¿vale?

00:41:38.960 --> 00:41:47.040
Yo no sé si lo has notado tú, pero de pronto te llega un mensaje al móvil pero no te llega

00:41:47.040 --> 00:41:53.560
al reloj o te llega primero el reloj y luego tarda en llegar al móvil o de pronto me llaman

00:41:53.560 --> 00:41:58.240
y el móvil no se cosca pero me salta solo en el reloj. Hace cosas raras, ¿vale? O sea,

00:41:58.240 --> 00:42:01.040
no sé yo si eso es muy normal o no.

00:42:01.040 --> 00:42:05.080
Pues a mí sí que me funciona. Eso sí que me sincroniza bien, ¿eh?

00:42:05.080 --> 00:42:10.380
Pues a mí, por lo que sea, no sé qué le pasa, pero no lo está haciendo bien. De hecho,

00:42:10.380 --> 00:42:13.880
ni siquiera se sincronizó bien la primera vez. Tuve que volver a configurarlo desde

00:42:13.880 --> 00:42:20.320
cero porque, no sé por qué, se le fue la olla. No enviaba, o sea, yo le ponía esferas

00:42:20.320 --> 00:42:27.800
nuevas, ¿no? La esfera esta del cacharro, ¿vale? Y no había manera de que funcionara

00:42:27.800 --> 00:42:30.560
bien. Entonces, bueno, pues es una cosa un poco rara.

00:42:30.560 --> 00:42:38.720
Y luego también, bueno, también depende un poco de las, por ejemplo, o sea, no sé,

00:42:38.720 --> 00:42:44.640
por ejemplo, si funciona bien, por ejemplo, yo qué sé, pues con Telegram, ¿vale? Si

00:42:44.640 --> 00:42:50.120
te llaman por Telegram, sí salta en el reloj. Pero si te llaman por WhatsApp, no. ¿Por qué?

00:42:50.120 --> 00:42:55.800
Porque WhatsApp no tiene bien integrado el tema de las llamadas IP porque tienes que

00:42:55.800 --> 00:43:00.200
propagarlo al Apple Watch, tienes que tener una app de Apple Watch para que lo coja porque

00:43:00.200 --> 00:43:04.880
si no, no lo coge. O sea, que es un problema de desarrolladores, ¿vale? Entonces, bueno,

00:43:04.880 --> 00:43:10.560
pero bueno, en ese sentido, pues está… Estoy contento, la verdad, que estaban tanto bien

00:43:10.560 --> 00:43:17.280
en ese sentido. ¿Tú cuál ha sido tu percepción de reloj?

00:43:17.280 --> 00:43:21.040
Del Apple Watch. A mí… Porque has cambiado también, ¿no? De Apple

00:43:21.040 --> 00:43:24.000
Watch. Sí, sí. De hecho, el salto, o sea, porque

00:43:24.000 --> 00:43:32.000
tenía uno… Joder, ya no sé por qué series van. Tenía el anterior, el S8, con lo cual

00:43:32.000 --> 00:43:35.400
de velocidad y eso, pues no lo he notado, la verdad. Lo que sí que he dado el salto

00:43:35.400 --> 00:43:42.960
al Ultra y estoy maravillado con la batería. Sí, pero fíjate que… A ver, lo de la batería,

00:43:42.960 --> 00:43:47.880
genial, ¿vale? Yo creo que es lo mejor que tiene. Pero luego, aparte de eso, sigue siendo

00:43:47.880 --> 00:43:53.880
el mismo dispositivo. O sea, vamos a lo de siempre. Yo salto de un 4 a un Ultra 2, es

00:43:53.880 --> 00:44:01.240
decir, es un salto mayestático y, sin embargo, no podría decir, oye, es un dispositivo nuevo

00:44:01.240 --> 00:44:07.640
que me ha cambiado la vida. No. Es el mismo Apple Watch, pero con una pantalla más grande,

00:44:07.640 --> 00:44:12.600
por lo tanto es más fácil de ver, con una batería que le dura más, con mayor brillo

00:44:12.600 --> 00:44:20.180
en la pantalla, pero a nivel de funcionalidad y usabilidad no he visto cambio. Espero verlo

00:44:20.180 --> 00:44:26.060
a partir de ahora, cuando empiecen a salir aplicaciones para WatchOS 10. Pero por ahora,

00:44:26.060 --> 00:44:32.080
en lo que es el uso en sí, no he notado diferencia en ese sentido. Te vas a quedar, Julio, con

00:44:32.080 --> 00:44:36.320
las aplicaciones del sistema, como me llevo yo. Yo uso mucho el Watch, sí que es verdad

00:44:36.320 --> 00:44:41.920
que es un dispositivo que me encanta, pero es que creo que tengo dos aplicaciones instaladas.

00:44:41.920 --> 00:44:48.080
Sí, de terceros hay muy pocas apps porque no están bien hechas. Y sí que está claro

00:44:48.080 --> 00:44:52.280
que el salto al Ultra… Eso, la pantalla también, que sea algo más grande, se nota

00:44:52.280 --> 00:44:56.800
porque puedes ver más información y como más clara y tal, pero sí que es verdad que

00:44:56.800 --> 00:45:01.480
en ningún momento yo mi salto, que lo veo más que de generación a otra, lo veo del

00:45:01.480 --> 00:45:07.680
normal al Ultra, pues más pantalla y más batería que… A ver, sí que era un problema

00:45:07.680 --> 00:45:13.080
porque yo el iPhone me dura un día, lo cargo por la noche y ya está, punto. Pero el Watch

00:45:13.080 --> 00:45:19.200
es un dispositivo que duermo con él. Entonces, claro, tenía como mucha rutina de lo cargo

00:45:19.200 --> 00:45:24.120
mientras me ducho y luego lo tengo también un rato mientras estoy trabajando o tal. Tenía

00:45:24.120 --> 00:45:29.000
que andar un poco pensando. Ahora es que muchas veces ni me acuerdo de cargarlo.

00:45:29.000 --> 00:45:35.200
De hecho, en dos horas ya lo tienes cargado. También es una cosa increíble en ese sentido.

00:45:35.200 --> 00:45:39.480
Yo casi aguanto con el rato que estoy entre que me ducho y me preparo. A lo mejor son

00:45:39.480 --> 00:45:46.160
10 o 15 minutos. Además, lo tengo en el cargado rápido que trae y cada tres días sí que

00:45:46.160 --> 00:45:51.040
aprovecho para cargarlo a tope cuando estoy presentado trabajando. Pero si no, me aguanta

00:45:51.040 --> 00:45:54.280
perfectamente con esas cargas que le doy puntuales.

00:45:54.280 --> 00:46:05.560
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

00:46:05.560 --> 00:46:10.800
una vez y ahora está pues… Yo creo que aguantará toda la noche, ¿vale?

00:46:10.800 --> 00:46:16.240
Y ahora con eso… Claro, porque el problema que tenía también es cuando sales fuera y

00:46:16.240 --> 00:46:23.280
tiras de datos que se descargaba pero visto y no visto. Pues ahora cuando voy a correr

00:46:23.280 --> 00:46:27.040
o cuando saco al perro o cuando voy a comprar el pan, pues ya me dejo el móvil en casa

00:46:27.040 --> 00:46:32.240
porque voy escuchando podcast con el reloj y no consume tanta batería como consumía

00:46:32.240 --> 00:46:37.040
antes. Pues sí, la verdad es que sí está bien.

00:46:37.040 --> 00:46:46.160
Y luego aparte de eso, pues ya el pasado día 2 de octubre, el lunes, pues hemos empezado

00:46:46.160 --> 00:46:53.880
el Swift Developer Program y entonces ahora estoy con 40 alumnos, que tú estuviste además

00:46:53.880 --> 00:47:03.000
en la inauguración del curso académico, pues con 40 personas, 40 almas que quieren

00:47:03.000 --> 00:47:09.760
aprender Swift, SwiftUI, asincronía, etcétera. Y una introducción pequeñita a Vision OS

00:47:09.760 --> 00:47:15.560
y desde luego, pues la verdad que es algo interesante, ¿vale? Es algo que creo que

00:47:15.560 --> 00:47:20.240
puede ser muy bueno y que, bueno, pues ahora estamos en el comienzo. Es decir, estamos

00:47:20.240 --> 00:47:27.560
en el comienzo de que es una variable, que es una constante, operadores, flujos, for

00:47:27.560 --> 00:47:32.400
in, while, no sé qué, tal y cual. Estamos con todo el comienzo. La primera semana hemos

00:47:32.400 --> 00:47:39.960
terminado, son clases de lunes a jueves, por lo tanto son 16 horas de formación por semana

00:47:39.960 --> 00:47:45.160
y en esas primeras 16 horas hemos llegado en Swift hasta todo lo que es la parte básica,

00:47:45.160 --> 00:47:55.120
¿vale? Es decir, tipos de datos, la parte de lo que serían operadores, flujos, luego

00:47:55.120 --> 00:48:04.440
hemos visto las colecciones, ¿vale? De arrays, diccionarios, sets, etcétera, cadenas, tuplas,

00:48:04.440 --> 00:48:08.760
hemos visto también el tema del hashable, en fin, pues un poco lo que sería todo ese

00:48:08.760 --> 00:48:16.640
embrollo, ¿no? Y por supuesto siempre comenzamos con la presentación, que es el primer día,

00:48:16.640 --> 00:48:22.720
¿vale? De historia del desarrollo de entornos Apple, ¿no? Que al final es ponerlos un poco

00:48:22.720 --> 00:48:30.760
en contexto y meterlos, ¿no? Dentro del storyline de Swift y de lo que es y lo que ha supuesto

00:48:30.760 --> 00:48:37.080
y cómo hemos ido avanzando desde los Apple II hasta los últimos Vision OS, en fin, todo

00:48:37.080 --> 00:48:41.880
ese tema que fue una clase que también gustó bastante, ¿no? Entonces, bueno, y ahí tienen

00:48:41.880 --> 00:48:49.840
ahora ya su primer conjunto de ejercicios. ¿Qué tienen que hacer? Un conjunto de ejercicios

00:48:49.840 --> 00:48:58.200
de, bueno, pues tienen 50 ejercicios de Swift para hacer en distintos niveles, todos de

00:48:58.200 --> 00:49:06.880
Swift básico, y bueno, y a ver qué tal les da lo que es la formación. A ver si, porque

00:49:06.880 --> 00:49:12.240
muchas veces cuando te pasa que lo ves al revés. Hay veces que te parece que te están

00:49:12.240 --> 00:49:15.760
hablando en arameo y luego vas y te pones a hacer ejercicios y oye, más o menos te

00:49:15.760 --> 00:49:20.520
desenvuelves, pero es que pasa lo contrario. Tienes pinta de fácil, pero luego cuando

00:49:20.520 --> 00:49:32.000
bajas al barro alucinas un poco. Pero una pregunta, aquí estamos. ¿Te gusta más dar

00:49:32.000 --> 00:49:40.020
esta parte, digamos, básica o prefieres ya la parte avanzada ya de más de programar

00:49:40.020 --> 00:49:46.560
para iOS o eso? ¿O te gusta esta parte de las bases de Swift? La verdad que lo disfruto

00:49:46.560 --> 00:49:51.240
todo cada uno a su manera, ¿vale? Porque al final esto es un poco, lo hemos comentado

00:49:51.240 --> 00:49:56.480
en algunas ocasiones. Yo cuando doy formación, repito mucho, ¿vale? A mí mucha gente que

00:49:56.480 --> 00:50:03.380
viene me dice, no, la gente que trabaja conmigo, o cuando hablo con empresas, no, no, nuestra

00:50:03.380 --> 00:50:09.280
gente tiene ya dos años de experiencia, tres años, cuatro años de experiencia, saben

00:50:09.280 --> 00:50:15.380
programar en Swift, lo conocen bien y tal. Me he encontrado tantos casos de gente que

00:50:15.380 --> 00:50:25.560
lleva 2, 3, 4, 5 años manejando Swift y cree que sabe Swift, pero no lo sabe, que curiosamente

00:50:25.560 --> 00:50:29.880
cuando luego les preguntas después de esta semana, porque claro, hay gente que ha empezado

00:50:29.880 --> 00:50:35.520
el Swift Developer Program que ya lleva tiempo trabajando con Swift, ¿vale? Hay gente que

00:50:35.520 --> 00:50:40.760
empieza desde cero, pero hay gente que lleva tiempo trabajando con Swift. Y les preguntas

00:50:40.760 --> 00:50:50.040
y ¿qué es lo que sucede? Pues que te dicen que, bueno, pues que ellos están descubriendo

00:50:50.040 --> 00:50:55.360
cosas que no conocían. Cosas que no conocían. Que no había visto de Fer en su vida. Claro,

00:50:55.360 --> 00:51:01.480
o sea, que no conocen cómo se hacía, o que no sabían qué era, o que no sabían por

00:51:01.480 --> 00:51:05.640
qué se hacía así y simplemente lo hacían. Cosas así. Entonces, bueno, pues es algo

00:51:05.640 --> 00:51:13.560
que siempre me gusta, que disfruto y que al final pues es una cosa que es bastante sorprendente,

00:51:13.560 --> 00:51:19.840
¿no? Ver a la gente, ver cómo va reaccionando, ¿no? Entonces, bueno, pues ahora mañana

00:51:19.840 --> 00:51:27.320
empezaremos ya, mañana lunes, con la parte de Swift intermedio, que son funciones, programación

00:51:27.320 --> 00:51:32.760
orientada a objetos, en fin, pues un poco ya entrar con palabras mayores, ¿no? Y bueno,

00:51:32.760 --> 00:51:38.600
y a ver qué tal se les ha dado el tema de la... el tema de los ejercicios, ¿no? Que

00:51:38.600 --> 00:51:43.400
al final, como tú dices, bueno, hay algunos ejercicios muy simples, ¿no? De muéstrame

00:51:43.400 --> 00:51:48.960
un programa que haga los diez primeros números, ¿no? Pero luego hay otros al final que es

00:51:48.960 --> 00:51:54.600
como, venga, hazme una ecuación de segundo grado, ¿no? Es como ya la cosa se pone un

00:51:54.600 --> 00:52:01.240
poco más intensita, ¿no? Pero bueno, tienen que ser capaces de resolver estos ejercicios

00:52:01.240 --> 00:52:05.960
y se les han dado las herramientas para que puedan hacerlos. Así que nada, a ver qué

00:52:05.960 --> 00:52:07.560
tal, qué tal se da.

00:52:07.560 --> 00:52:16.440
Bien, Julio, pues nada, pues que siga así de bien ese curso, a ver qué te cuentan mañana

00:52:16.440 --> 00:52:26.040
y yo creo que ya podemos pasar al apartado de noticias.

00:52:26.040 --> 00:52:40.200
¿Y qué ha pasado en esta semana? Porque, macho, el tema Swift tampoco para nunca, ¿no?

00:52:40.200 --> 00:52:41.200
Siempre hay cositas.

00:52:41.200 --> 00:52:46.880
Pues sí, no ha sido la semana con más movimiento, pero bueno, sí que se han presentado algunas

00:52:46.880 --> 00:52:52.280
cosillas y las vamos a resumir. Como digo, tampoco es nada del otro mundo, diríamos

00:52:52.280 --> 00:53:02.000
que son breves, por así decirlo. Pero bueno, la primera de ellas es que Apple, esa empresa

00:53:02.000 --> 00:53:12.200
hermética cerrada que solo hace su software y demás, pues sigue librando librerías. Y

00:53:12.200 --> 00:53:22.440
la última tiene el nombre de Swift Async DNS Resolver, ¿vale? Y como no podía ser

00:53:22.440 --> 00:53:32.960
menos y su nombre indica, pues es un grapper de varias librerías ya existentes en C, pero

00:53:32.960 --> 00:53:40.000
con APIs y estructuras de datos más, digamos, Swift-friendly, no sé cómo traducirlo, más

00:53:40.000 --> 00:53:46.360
amigables con Swift o más orientadas a utilizar en Swift, pues para eso, para trabajar con

00:53:46.360 --> 00:53:52.000
resolución de nombres de dominios. Nada que nos vaya a cambiar la vida, pero bueno, a

00:53:52.000 --> 00:53:57.160
lo mejor te pillan algún proyecto que tiene que ver con esto o por lo que sea necesitas

00:53:57.160 --> 00:54:04.760
en tu programa, pues hacer este tipo de peticiones. Y antes probablemente tendrías que bajar

00:54:04.760 --> 00:54:11.560
a algo compatible con C y bastante farragoso para conseguirlo. Y ahora, pues importas con

00:54:11.560 --> 00:54:18.080
Swift Package Manager esta librería. Y es que estoy viendo aquí los ejemplos y obviamente

00:54:18.080 --> 00:54:24.840
utilizas InkAway, ¿vale? Y nada, creas un resolvedor, un resolver, vamos a decirlo en

00:54:24.840 --> 00:54:31.880
inglés, que queda mejor y le haces las queries con el dominio y te devuelven la IP. Simple,

00:54:31.880 --> 00:54:33.320
sencillo y para toda la familia.

00:54:33.320 --> 00:54:39.760
De hecho, esto viene un poco de la mano de una librería que yo cuando la cuento a los

00:54:39.760 --> 00:54:44.200
alumnos se quedan flipando como diciendo, ah, pero eso está ya, eso se puede usar,

00:54:44.200 --> 00:54:54.480
es la librería de HTTP, ¿vale? O sea, ya sabes que cuando yo hago un request de HTTP

00:54:54.480 --> 00:54:58.240
todos los parámetros hay que ponerlos a mano, ¿vale? Hay que poner a mano todos los content

00:54:58.240 --> 00:55:05.880
type, o sea, digamos los parámetros de cabecera, ¿no? El content type, el accept, el authorization,

00:55:05.880 --> 00:55:12.320
en fin, los métodos hay que ponerlos a mano también con una cadena, etcétera, ¿vale?

00:55:12.320 --> 00:55:20.080
Pues ya hay una librería de métodos HTTP para cliente que permiten, que es una librería

00:55:20.080 --> 00:55:25.780
de Apple, que están en pruebas, ¿vale? Pero que se puede usar y que te trae numeraciones

00:55:25.780 --> 00:55:31.840
para todo eso y diccionarios donde mete las distintos elementos, un cambio de los requests,

00:55:31.840 --> 00:55:36.120
etcétera, y que la verdad pues es interesante, o sea, que Apple en ese sentido, claro, no

00:55:36.120 --> 00:55:41.480
podemos olvidar que Apple está refactorizando toda la librería de Foundation y la parte

00:55:41.480 --> 00:55:45.520
de red, es una de las partes importantes.

00:55:45.520 --> 00:55:49.720
Pues se puede usar y se usa, Julio, porque yo ya la estoy usando. De hecho, bueno, todavía

00:55:49.720 --> 00:55:54.640
no está publicada la aplicación, todavía está en beta, ¿vale? Pero en un proyectillo

00:55:54.640 --> 00:55:59.160
que estoy metido, pues había que hacer una, es una aplicación sencilla, pero bueno, era

00:55:59.160 --> 00:56:08.120
todo nuevo y dije, uy, pero se basaba en peticiones HTTPS y dije, pues mira, qué mejor prueba

00:56:08.120 --> 00:56:14.120
que meterla aquí y sí que, pues eso, te evita hacer, porque todos no sabemos, no tenemos

00:56:14.120 --> 00:56:21.360
nuestros helpers o no sé cómo llamarlo para estas cosas, pues mira, una cosa que te ahorras

00:56:21.360 --> 00:56:26.400
y mira, la que no he probado y tengo ganas y lo intenté, pero la API no me dejó sacarlo.

00:56:26.400 --> 00:56:33.600
Bueno, la API más bien el backend. La que han hecho de OpenAPI, ¿vale? Que es una librería

00:56:33.600 --> 00:56:40.560
que yo también os hablamos aquí, que servía para la especificación OpenAPI, es una especificación,

00:56:40.560 --> 00:56:48.760
digamos, para que deberían cumplir, ¿vale? Todas las APIs que hay y que define, pues

00:56:48.760 --> 00:56:55.000
los para el tipo de servicio, si es un POST, un GET, los parámetros de entrada, la respuesta,

00:56:55.000 --> 00:57:00.280
¿vale? Pues digamos que se puede hacer un fichero y en base a ese fichero, pues en muchos

00:57:00.280 --> 00:57:05.160
lenguajes, librerías como esta que os comentamos de Swiss, te genera todo lo que necesitas.

00:57:05.160 --> 00:57:10.560
En Swiss, además, la hay compatible con URL Session, que es el framework que se utiliza

00:57:10.560 --> 00:57:16.520
en IOS y en los sistemas de Apple para acceder y también lo hay en otros frameworks como

00:57:16.520 --> 00:57:23.640
pueden ser BAP, ¿vale? Y sirve tanto para eso como para, por ejemplo, si tu backend

00:57:23.640 --> 00:57:30.760
que se está en Node.js con X framework de los 80.000 que hay, ¿vale? Te puedes portar

00:57:30.760 --> 00:57:35.000
ese archivo que tú luego le das a los frontend y los frontend, utilizando estas librerías,

00:57:35.000 --> 00:57:38.880
se crean sus clases. Ese tengo ganas de utilizarlo y todavía no he podido y fue lo primero que

00:57:38.880 --> 00:57:42.720
intenté aquí. Digo, a ver si el framework con el que está hecho esto me permite exportarlo,

00:57:42.720 --> 00:57:48.240
pero no fue el caso. Pero bueno, una librería más que apuntar a las que está liberando

00:57:48.240 --> 00:57:54.360
Apple. Y como digo, es un movimiento raro porque Apple precisamente es la empresa que

00:57:54.360 --> 00:57:59.160
siempre se ha dicho que libera todo con cuentagotas. Pero bueno, parece que la parte está de Swift.

00:57:59.160 --> 00:58:07.320
No sé si también un poco por qué provocado por esta necesidad de reclutar talento. En

00:58:07.320 --> 00:58:13.620
su día lo hablamos que para toda la parte de Machine Learning, los científicos, al final

00:58:13.620 --> 00:58:19.560
estos son más científicos casi que programadores, es gente que se basa mucho en publicar papers,

00:58:19.560 --> 00:58:27.080
publicar sus estudios. Digamos que la reputación viene muy condicionada por lo que publicas.

00:58:27.080 --> 00:58:33.080
Pues Apple se vio obligada a crear una página y a dar visibilidad a la documentación que

00:58:33.080 --> 00:58:37.640
generaba esta gente, a los descubrimientos que publicaba esta gente. Pues a mí me parece

00:58:37.640 --> 00:58:43.640
que también hay algo aquí de eso, de que una de las cosas que dice Apple es, te voy

00:58:43.640 --> 00:58:48.440
a reclutar como programador, vas a entrar en Swift, que es open source. Entonces si

00:58:48.440 --> 00:58:55.080
haces librerías, haces cosas, los vamos a publicar. Y es que esta librería, la de DNS,

00:58:55.080 --> 00:59:01.600
no lo sé, pero esta que os decíamos de HTTP Request, era una librería que empezaban a

00:59:01.600 --> 00:59:06.800
usar internamente en Apple. Y luego la publicaron a raíz de ser una librería utilizada por

00:59:06.800 --> 00:59:12.920
ellos. Y no sé, no puedo estar más alegre porque ya os digo que seguramente estas librerías

00:59:12.920 --> 00:59:18.720
las acabemos utilizando todos en mayor o menor medida, ¿no, Julio?

00:59:18.720 --> 00:59:24.920
Pues sí, sí, sí, sí. Es que además, claro, todo esto es una estrategia a nivel de, pues

00:59:24.920 --> 00:59:32.040
eso, como hemos comentado, si tú tienes la librería de Foundation que está siendo refactorizada,

00:59:32.040 --> 00:59:37.960
¿qué haces? ¿La refactorizas tú solo con un personal que no da abasto? ¿O la haces

00:59:37.960 --> 00:59:43.960
open source y así tienes a un montón de desarrolladores que van a trabajar gratis

00:59:43.960 --> 00:59:50.160
porque su cobro es la reputación de haber trabajado en este tipo de proyectos? Y sobre

00:59:50.160 --> 00:59:54.080
todo, pues la posibilidad de que la propia Apple se pueda llegar a fijar en ti en un

00:59:54.080 --> 01:00:01.040
futuro, ¿no? Entonces es una plataforma de descubrimiento bastante importante, ¿no?

01:00:01.040 --> 01:00:05.480
Entonces yo creo que sí, que efectivamente puede ser una estrategia, una estrategia importante

01:00:05.480 --> 01:00:11.240
el decir, bueno, todo esto va a ir a código abierto porque así conseguimos que la gente,

01:00:11.240 --> 01:00:16.840
bueno, pues pueda haber más gente interesada fuera de Apple y que pueda aportar y que

01:00:16.840 --> 01:00:22.760
a lo mejor es gente que es incluso de mayor nivel que la gente que puede haber en Apple.

01:00:22.760 --> 01:00:30.520
Y luego por otro lado, pues como tú has comentado, o sea, Apple empezó a tentar a científicos

01:00:30.520 --> 01:00:36.240
de Machine Learning para entrar en Apple y todos les decían que no, porque Apple decía,

01:00:36.240 --> 01:00:41.840
no, no, no, no, el trabajo que tú desempeñes en Apple es de Apple, tú no eres Paco Torres

01:00:41.840 --> 01:00:48.200
o Pepe Flores, no, tú eres un empleado de Apple y todo el trabajo que tú hagas científicamente

01:00:48.200 --> 01:00:52.080
es de Apple. Y entonces, claro, los científicos dijeron, vale, pues como eres de Apple, pues

01:00:52.080 --> 01:00:59.560
ahí te quedas y te mueres de asco. Y entonces al final tuvieron obligados que decir, pues

01:00:59.560 --> 01:01:04.600
ya está, pues vamos a tener que poner una página, machinelearning.apple.com, donde

01:01:04.600 --> 01:01:11.040
los científicos de computación de Machine Learning en Apple publiquen con nombres y

01:01:11.040 --> 01:01:18.280
apellidos sus estudios para que esto les dé, porque los estudios científicos, los papers,

01:01:18.280 --> 01:01:24.600
es lo que es el prestigio de la gente. Entonces, si tú no publicas tus trabajos a nivel científico,

01:01:24.600 --> 01:01:28.800
esto no solo sucede en Machine Learning, pasa en todos los campos científicos. Si tú como

01:01:28.800 --> 01:01:35.680
científico no publicas tus trabajos en revistas o publicas papers que se clasifican en ciertas

01:01:35.680 --> 01:01:42.000
webs, etc., tú no eres nadie. O sea, para tú ser alguien tienes que haber firmado papers

01:01:42.000 --> 01:01:50.280
y esto es algo que hace Google, que hace Microsoft, que hace OpenAI, ¿vale? Publicar estos papers

01:01:50.280 --> 01:01:56.160
para la gente que descubre ciertas cosas. Pero claro, ahí ya entra lo que es el problema

01:01:56.160 --> 01:02:03.440
de la propiedad intelectual, de la propiedad industrial, de que, pues bueno, yo soy OpenAI

01:02:03.440 --> 01:02:08.320
y ¿hasta qué punto me interesa sacar un paper donde le enseño a todo el mundo cómo crear

01:02:08.320 --> 01:02:13.200
su propio chat GPT? Pues resulta que a lo mejor no me interesa. Y eso es un problema

01:02:13.200 --> 01:02:18.880
porque la gente que ha creado chat GPT quiere tener el crédito de que han sido ellos los

01:02:18.880 --> 01:02:25.560
que están detrás de la forma en la que chat GPT está funcionando, repito, a nivel científico,

01:02:25.560 --> 01:02:30.360
no a nivel de desarrollo. Y si eso pasa a nivel científico, pues obviamente los desarrolladores

01:02:30.360 --> 01:02:36.000
tres cuartas de lo mismo. Hola, soy desarrollador y yo quiero que se sepa que yo he sido la

01:02:36.000 --> 01:02:40.380
persona que he estado haciendo tal cosa o tal otra, o que ha colaborado en tal versión

01:02:40.380 --> 01:02:46.120
del lenguaje, o que ha incorporado tal funcionalidad, porque eso es prestigio para mí. Entonces,

01:02:46.120 --> 01:02:50.200
si yo no puedo hacerlo porque Apple no me deja, pues tengo un problema. Entonces, bueno,

01:02:50.200 --> 01:03:00.040
pues todo esto en cierta forma ayuda a que haya ese elemento y que al final incluso tengamos

01:03:00.040 --> 01:03:05.960
pues como la siguiente noticia que tenemos, que es un problema que ha habido en Vapor,

01:03:05.960 --> 01:03:11.600
que Vapor es otro proyecto de código abierto que si no fuera por la comunidad no podría

01:03:11.600 --> 01:03:18.760
salir adelante. Vapor ahora mismo es un framework de lado servidor con una calidad y con un

01:03:18.760 --> 01:03:25.200
acabado brutal. O sea, yo estoy literalmente enamorado de las capacidades y de cómo se

01:03:25.200 --> 01:03:31.520
está mejorando día a día y evolucionando, y en gran parte esto es posible por la enorme

01:03:31.520 --> 01:03:36.760
comunidad que hay. Entonces, toda esa comunidad, ya no sólo a nivel de programación, sino

01:03:36.760 --> 01:03:42.240
a nivel de atención en los foros de Discord, a nivel de la documentación, que hemos hablado

01:03:42.240 --> 01:03:48.720
en ocasiones que se está entera refactorizando en DocC, etcétera, todo eso también es importante.

01:03:48.720 --> 01:03:54.280
Entonces ahora resulta que nos hemos encontrado con que Vapor tiene un error importante, una

01:03:54.280 --> 01:04:00.440
vulnerabilidad que ha sido corregida y además una vulnerabilidad que ha conseguido su propio

01:04:00.440 --> 01:04:09.280
código CVE. Los códigos CVE son códigos que clasifican vulnerabilidades que han sido

01:04:09.280 --> 01:04:16.320
parcheadas a nivel de seguridad y que demuestran que las herramientas son importantes. Entonces

01:04:16.320 --> 01:04:24.160
hay un CVE, que es el 202344386, que es una vulnerabilidad de denegación de servicio,

01:04:24.160 --> 01:04:29.080
que afecta a los usuarios de las versiones afectadas de Vapor, que son todas las anteriores

01:04:29.080 --> 01:04:36.200
a la 484.2, donde el controlador de errores, de lo que es el manejo de HTTP en la versión

01:04:36.200 --> 01:04:42.560
1.0, lo que hacía era cerrar conexiones cuando se producían errores de análisis HTTP en

01:04:42.560 --> 01:04:49.680
lugar de transmitirlos y eso podía permitir, atacando por ahí, conseguir un error de denegación

01:04:49.680 --> 01:04:57.640
de servicio, es decir, que bloquearas el servidor y terminara por denegar la entrada al mismo,

01:04:57.640 --> 01:05:04.280
pues porque al final lo saturas, porque no es capaz de funcionar de manera correcta.

01:05:04.280 --> 01:05:09.400
Entonces, bueno, pues esto ha sido parcheado, por lo tanto, bueno, pues un error que se

01:05:09.400 --> 01:05:15.360
ha corregido y entonces ahora ya, pues se puede, bueno, pues seguir trabajando bien

01:05:15.360 --> 01:05:20.300
y bueno, pues recomendamos a todo el mundo que actualice, que usa Vapor a una versión,

01:05:20.300 --> 01:05:25.240
la versión 484.2, que es la que ha parcheado esto y que esto está reportado, pues por

01:05:25.240 --> 01:05:30.880
un desarrollador que, pues de nuevo, es un desarrollador llamado Torchwood, que es el

01:05:30.880 --> 01:05:35.280
que es un ingeniero de seguridad, que es el que ha detectado este problema, lo ha reportado

01:05:35.280 --> 01:05:41.240
y pues bueno, pues se ha corregido. Entonces, de nuevo, esto no sería posible si no fuera

01:05:41.240 --> 01:05:48.480
por, pues eso, porque tienes a la comunidad Open Source detrás, probando, viendo, detectando

01:05:48.480 --> 01:05:53.080
en el código, etcétera, etcétera, etcétera.

01:05:53.080 --> 01:05:59.120
Pues enhorabuena, o sea, y fijaros que voy a decir que es enhorabuena al equipo de Vapor

01:05:59.120 --> 01:06:03.840
y ha tenido un error, ¿vale? Pero es que todo el software tiene un error. ¿Pero por

01:06:03.840 --> 01:06:10.160
qué mi enhorabuena? Porque uno, lo han parcheado, lo han encontrado y lo han parcheado y dos,

01:06:10.160 --> 01:06:15.440
han explicado. Oye, mira, pues teníamos esto y bueno, y aparte, como es Open Source, te

01:06:15.440 --> 01:06:20.000
puedes ir al commit para ver el nuevo código y pues ver incluso cómo lo han arreglado,

01:06:20.000 --> 01:06:23.440
pero bueno, han hecho, lo que ha comentado Julio, la explicación de qué consistía

01:06:23.440 --> 01:06:30.520
el ataque y dónde han tocado para mitigarlo, cosa que, pues al final sirve para aprender

01:06:30.520 --> 01:06:35.240
porque pues eso, toda la gente que haya visto este error, pues seguramente que el día de

01:06:35.240 --> 01:06:41.640
mañana no cometerá uno similar. Y entre otras cosas, esa es la grandeza, digamos,

01:06:41.640 --> 01:06:46.600
del software libre. Está claro que para meterte en un proyecto de estos, yo creo que lo hemos

01:06:46.600 --> 01:06:52.400
comentado también alguna vez, contribuir en un proyecto de estos es complicado, ¿vale?

01:06:52.400 --> 01:06:57.480
Porque es algo que lleva tiempo, que hay mucha gente detrás, ¿vale? Porque imagínate que

01:06:57.480 --> 01:07:03.080
te pones a hacer tu librería de parsear no sé qué, ¿sabes? Pues te pones, la haces

01:07:03.080 --> 01:07:06.760
tú solo y vas haciéndolo, porque claro, esto es un proyecto muy, muy grande, un proyecto

01:07:06.760 --> 01:07:11.840
en el que se discuten, se hacen pull requests, bueno, primero en foros se empieza a discutir

01:07:11.840 --> 01:07:17.480
una nueva funcionalidad. Una vez que se aprueba, se empieza el desarrollo, pero luego el desarrollo

01:07:17.480 --> 01:07:23.160
lleva un montón de tiempo, pues como pasa con Swift. Y es súper interesante, yo cuando

01:07:23.160 --> 01:07:29.400
tengo tiempo, que suele ser nunca, o veo a alguien que postea algo de un foro, de cómo

01:07:29.400 --> 01:07:33.520
se ha discutido algo, joder, mola un montón y aprendes un montón, pero también pierdes

01:07:33.520 --> 01:07:39.080
un montón de tiempo, o sea, leyéndote todas las propuestas y todo eso. Pero la verdad

01:07:39.080 --> 01:07:45.800
es que son muy interesantes y se agradece, pues, porque, a ver, hay gente que cobra dinero

01:07:45.800 --> 01:07:51.800
y gana dinero con esto y se gana la vida, pero hay muchos contribuyentes, contribuidores

01:07:51.800 --> 01:08:00.920
que lo hacen un poco por aprender y por seguir evolucionando en su carrera y nada, pues bienvenido

01:08:00.920 --> 01:08:09.840
sea el apoyo, porque luego hay nosotros mismos, Julio en el caso de Vapor y empresas que construyen

01:08:09.840 --> 01:08:15.800
sus sistemas en base a este software libre y que de otra manera, pues no sé, se tendrían

01:08:15.800 --> 01:08:22.000
que pagar licencias o no sé, se tendrían que buscar la vida de otra manera. Así que

01:08:22.000 --> 01:08:27.480
bravo por Vapor, por la librería en sí y por esta rápida respuesta ante los errores

01:08:27.480 --> 01:08:36.760
y por esta transparencia. Y si te parece, Julio, vamos a la última noticia, que también

01:08:36.760 --> 01:08:44.980
como esta es bastante breve y es algo que pudo pasar desapercibido, porque la versión

01:08:44.980 --> 01:08:53.840
de Swift 5.9 tampoco fue tan comentada, no traía demasiadas novedades y esta que os

01:08:53.840 --> 01:09:00.040
traemos es a raíz de un post que publicaron hace unos días en el blog de Swift donde

01:09:00.040 --> 01:09:09.160
nos cuentan algunas de las novedades que tienen en la parte del debug. Muy rapidillo os contamos,

01:09:09.160 --> 01:09:17.480
una de las novedades es que tiene una inspección de variables más rápida con los comandos

01:09:17.480 --> 01:09:24.720
p y p o. ¿Qué comandos son estos? Cuando nosotros ponemos un punto de ruptura nos salta

01:09:24.720 --> 01:09:30.240
la terminal, en el propio SCODE o si lo estamos ejecutando Swift desde la consola de comandos

01:09:30.240 --> 01:09:34.480
pues nos salta la terminal y desde ese punto de ruptura nosotros podemos preguntar por

01:09:34.480 --> 01:09:42.080
el valor de variables con los comandos p y p o. Y luego tiene tiene varios argumentos.

01:09:42.080 --> 01:09:47.960
Pues aquí han mejorado esa inspección y te da los resultados antes. A mí hay veces

01:09:47.960 --> 01:09:53.520
que me tardaba más y se hacía algo de lío y lo han mejorado. Luego lo que también han

01:09:53.520 --> 01:09:59.160
mejorado es la parte de los genéricos. Muchas veces se volvía loco al preguntar con estos

01:09:59.160 --> 01:10:04.920
comandos de p y p o por algún genérico, sobre todo cuando le pedías a algún tipo.

01:10:04.920 --> 01:10:10.480
Incluso te daba error o te decía que no lo encontraba. Pues esto se ha mejorado. Y por

01:10:10.480 --> 01:10:18.080
último han mejorado el scope, el ámbito de las variables. Había muchas veces que

01:10:18.080 --> 01:10:24.060
si tenías una variable que se llamaba igual en una clase como variable global y también

01:10:24.060 --> 01:10:28.040
como variable local de una función pues a veces te daba gato por liebre y te ponía

01:10:28.040 --> 01:10:33.460
una o te ponía otra. Luego a veces le preguntabas por una variable que aún no estaba definida

01:10:33.460 --> 01:10:37.520
y él ya te daba el resultado de esa variable que iba a tener luego. Pero dices pero es

01:10:37.520 --> 01:10:43.600
que todavía no se ha ejecutado este código. Pues lo han mejorado y ahora es mucho más

01:10:43.600 --> 01:10:51.160
fiable y sólo te da el resultado si esa variable está en su ámbito y ha sido definida.

01:10:51.160 --> 01:11:00.600
Variables pequeñas pero bueno pues la idea es la Swift 5.9 es una versión menor ya vendrá Swift 6 que

01:11:00.600 --> 01:11:04.560
hace un tiempo se hablaba más que ahora está un poco como dormida la cosa porque bueno

01:11:04.560 --> 01:11:13.920
debe haber varios elefantes en la habitación que resolver en Swift 6 y todavía están debatiendo.

01:11:13.920 --> 01:11:21.840
Pero bueno pues una curiosidad más y os aconsejo que utilicéis el debugger porque os saca de

01:11:21.840 --> 01:11:27.960
muchas cosas. Yo era muy, sobre todo en mis primeros años, muy de mucho print y muy poco

01:11:27.960 --> 01:11:36.000
breakpoint en el código. Y como dice Julio, descubres un mundo nuevo porque aparte Scode

01:11:36.000 --> 01:11:41.760
si te pones sobre las variables que ya han sido asignadas ya te da visualmente, te ofrece

01:11:41.760 --> 01:11:47.200
el valor. Pero con estos comandos de P y PO que son los básicos pero hay muchos más, podéis

01:11:47.200 --> 01:11:54.440
hacer un montón de cosas, te da mucha más información. Así que es mi consejo el menos

01:11:54.440 --> 01:11:56.240
print y más breakpoint.

01:11:56.240 --> 01:12:05.280
Sabio, sabio consejo. Sí, sí. De hecho yo a la gente, incluso a nivel de... les digo que pongan

01:12:05.280 --> 01:12:12.200
porque claro hay muchos que te dicen no pues el print, te haces una función de print que

01:12:12.200 --> 01:12:19.520
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

01:12:19.520 --> 01:12:26.000
un breakpoint que haga un PO cuando pase por ahí y no se pare y ya está y lo tienes ahí

01:12:26.000 --> 01:12:31.520
totalmente seguro y el breakpoint es algo que sabes que jamás se va a subir a... es que yo

01:12:31.520 --> 01:12:38.680
he llegado a ver aplicaciones con contenido de suscripción que en el print de la consola

01:12:38.680 --> 01:12:44.400
estaban dando la url abierta al contenido de suscripción que dices pero vamos a ver

01:12:44.400 --> 01:12:49.120
arma de cántaro que esto sale directamente en el log del dispositivo que cualquiera que

01:12:49.120 --> 01:12:52.560
lo tenga enchufado Scode puede sacar esa información hombre.

01:12:52.560 --> 01:12:57.600
De hecho es más para esas cosas para luego o sea para cosas que lo hagáis un momento

01:12:57.600 --> 01:13:00.800
está claro que es un breakpoint o sea que lo hagáis en momento de desarrollo un breakpoint

01:13:00.800 --> 01:13:05.480
seguro pero luego si queréis tener algo logueado pues incluso yo creo que lo hemos hablado

01:13:05.480 --> 01:13:12.800
la librería logger de Apple desde iOS 14 está unificada le hicieron como una unificación

01:13:12.800 --> 01:13:19.440
porque había un poco de lío entre varias librerías os permite hacer imprimir por pantalla

01:13:19.440 --> 01:13:26.880
el antiguo NSLog de Objective-C os permite imprimir por pantalla y aparte trae por defecto

01:13:26.880 --> 01:13:33.040
esa privacidad es decir por defecto en el log las variables que inyectéis o sea o que

01:13:33.040 --> 01:13:38.880
interpoléis los strings que interpoléis vienen con la privacidad activada y no se

01:13:38.880 --> 01:13:43.120
van a ver en el log sólo lo vas a ver en la consola de Scode aparte tenéis diferentes

01:13:43.120 --> 01:13:48.600
niveles de log de información de error de debug que precisamente sirven para eso pues

01:13:48.600 --> 01:13:52.720
hay algunos que sólo se quedan en memoria hay algunos que persisten en el dispositivo

01:13:52.720 --> 01:13:58.840
durante menos tiempo vale tenéis mucho más para esos logs que necesitáis tener para

01:13:58.840 --> 01:14:03.520
tiempo vale entonces si queréis tener eso en vuestra aplicación que sí que es muy

01:14:03.520 --> 01:14:09.280
útil luego además a partir de iOS 15 incluso en esa librería te los puedes enviar vale

01:14:09.280 --> 01:14:13.920
yo últimamente en las aplicaciones en las que estoy trabajando en las versiones a veces

01:14:13.920 --> 01:14:17.840
en producción vale pero otras veces no llega a esta producción pero en versiones de staging

01:14:17.840 --> 01:14:24.120
para los equipos de QA dejamos esta opción para que si hay algún error nos manden el

01:14:24.120 --> 01:14:28.480
log y además lo clasifica se puede clasificar también por categorías pero tienes un log

01:14:28.480 --> 01:14:33.560
para el bluetooth otro log para la parte de red vale y le dices mira al usuario pues

01:14:33.560 --> 01:14:38.800
vete aquí a este menú que te hemos puesto y seleccionas la categoría de bluetooth y

01:14:38.800 --> 01:14:45.080
mándame el log del último día vale y te lo mandan es un txt y ves lo mismo y puedes

01:14:45.080 --> 01:14:53.440
debuguearlo y la verdad que está muy bien entonces para el takeaway de hoy menos print

01:14:53.440 --> 01:14:59.160
y más breakpoint vale y si queréis log para dejar ahí en el código vale utilizar esta

01:14:59.160 --> 01:15:10.120
librería de login que es una librería que trabaja con el strut logger si no me equivoco

01:15:10.120 --> 01:15:16.080
y te permite pues coger y crearte información a nivel de depuración a nivel de información

01:15:16.080 --> 01:15:22.920
a nivel de notificaciones a nivel de errores a nivel de fallos más gordos vale y lo único

01:15:22.920 --> 01:15:29.280
que hay que hacer es crear un logger a partir de una a partir de un de una instancia vale

01:15:29.280 --> 01:15:35.440
simplemente ponemos default log es igual a logger paréntesis paréntesis vale y a partir

01:15:35.440 --> 01:15:43.240
de ahí pues ya decimos defaultlog.log no sé qué o defaultlog.debug lo que sea y podemos

01:15:43.240 --> 01:15:48.960
ir mandando así un montón de mensajes de distinto tipo vale en el que bueno pues tienes

01:15:48.960 --> 01:15:57.000
ahí la la indicación de cómo de cómo funciona y de hecho hay también una librería de log

01:15:57.000 --> 01:16:06.760
para el lado servidor que es una API de que está también en apple que es la apple.github.io

01:16:06.760 --> 01:16:13.920
barra swift guión log vale que es una librería de la propia apple que para lo que es lado

01:16:13.920 --> 01:16:19.000
servidor como va a por etcétera pues igual simplemente te creas un logger con un label

01:16:19.000 --> 01:16:24.920
que lo identifique y a partir de ahí pues eso logger.info, logger tal, logger cual y

01:16:24.920 --> 01:16:29.720
vas lanzando los mensajes y te los va cogiendo sin ningún problema y que es además pues

01:16:29.720 --> 01:16:34.720
obviamente multiplataforma funciona en linux y en cualquier otro sistema operativo no sé

01:16:34.720 --> 01:16:40.320
si lo tendrán enganchado porque por ejemplo en escode 15 que no todo va a ser malo en

01:16:40.320 --> 01:16:47.480
escode 15 todo esto depende del nivel te lo ponen un color luego también puedes filtrar

01:16:47.480 --> 01:16:51.760
por las categorías estas que os comentaba la verdad es que está te los auto detecta

01:16:51.760 --> 01:16:55.840
estas categorías vale y los puedes filtrar la verdad es que está está muy potente y

01:16:55.840 --> 01:17:00.160
sobre todo que en cada versión de ellos apple es una de las cosas que apple está prestando

01:17:00.160 --> 01:17:08.720
atención pues sí son cositas que bueno entran dentro de la de la prioridad vale así que

01:17:08.720 --> 01:17:17.640
echarle un ojo a vuestro funcionamiento con estos temas vale y bueno hoy vamos a intentar

01:17:17.640 --> 01:17:22.560
que el programa vale vamos a intentar que los programas duren algo menos vale vamos

01:17:22.560 --> 01:17:28.840
a intentar que los programas estén más cercanos a la hora y media que a las dos horas vale

01:17:28.840 --> 01:17:33.880
por lo tanto bueno pues cerramos el bloque de noticias y lo que hacemos es comentar pues

01:17:33.880 --> 01:17:40.440
un par de cositas que teníamos por aquí apuntadas curiosas vale de temas que han surgido

01:17:40.440 --> 01:17:46.240
esta semana vale que queremos que son interesantes de comentar y con esto pues ya vamos cerrando

01:17:46.240 --> 01:18:00.960
así que vamos a nuestro bloque principal

01:18:00.960 --> 01:18:04.400
pues cuéntame arturo porque eres tú quien ha hecho estas anotaciones que la verdad que

01:18:04.400 --> 01:18:11.640
me parecen bastante curiosas e interesantes hablando pues de algunos temas que han surgido

01:18:11.640 --> 01:18:16.520
en qué contexto cuéntanos pues precisamente a colación de lo que os contaba en el primer

01:18:16.520 --> 01:18:22.600
bloque de que había estado haciendo pues estos debates que se han dado en en mi trabajo

01:18:22.600 --> 01:18:28.800
pues eso que al final a la hora de implementar cosas pues algunas que nos hemos dado cuenta

01:18:28.800 --> 01:18:34.080
entre todos que a veces pues eso sobre todo con las novedades pues hay veces que lo mira

01:18:34.080 --> 01:18:38.640
rápido hasta que no te metes en profundidad pues hay algunas cosas que digamos que se

01:18:38.640 --> 01:18:42.300
pueden escapar y estos debates son muy buenos precisamente porque a lo mejor hay algún

01:18:42.300 --> 01:18:48.160
compañero que lo ha revisado a fondo y te saca de algún error o de algo que no habías

01:18:48.160 --> 01:18:54.200
visto y eso pues te sirve al final de aprendizaje para no meter la pata cuando te toque hacerlo

01:18:54.200 --> 01:19:02.600
a ti y la primera de ellas es referente a los actores vale para los que no lo sepan

01:19:02.600 --> 01:19:16.480
una pregunta sinceramente tú crees que la gente está usando actores pues no hay dos

01:19:16.480 --> 01:19:22.000
opciones hay mucha gente que ha optado por pongo actor en todo y ya está vale y me quito

01:19:22.000 --> 01:19:33.640
de líos y otra gente que está sobreactuando sobreactuando y hay otros que están infractuando

01:19:33.640 --> 01:19:41.360
porque si no están dando cuenta y son o son jim carrey o ya se van al extremo de la roca

01:19:41.360 --> 01:19:47.600
no hay un plan o de estos ojos no se me ocurre ahora ninguno pero de estos actores que luego

01:19:47.600 --> 01:19:51.720
les escuchas en entrevistas y son ellos actuando también te quiero decir que hacen el mismo

01:19:51.720 --> 01:20:00.080
papel en todas tipos ya ni con son que él es igual que muchos de sus papeles pues este

01:20:00.080 --> 01:20:06.400
tema de los actores y por explicarlo rápido tampoco liarnos mucho el actor o actor en

01:20:06.400 --> 01:20:13.400
inglés centro es un nuevo tipo de su y se introdujo con así en cagüey vale con un nuevo

01:20:13.400 --> 01:20:22.720
modelo de concurrencia para evitar los data races vale y aquí otro punto que es un data race la

01:20:22.720 --> 01:20:30.120
explicación oficial es cuando varios hilos intentan acceder a una variable y al menos uno de esos

01:20:30.120 --> 01:20:37.040
accesos es una escritura vale porque eso da un pete una excepción vale en el sistema cuando se

01:20:37.040 --> 01:20:43.440
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

01:20:43.440 --> 01:20:47.880
defenderse de ello es decir hay que desarrollar pensando en ello porque no es un error que te

01:20:47.880 --> 01:20:52.240
vayas a encontrar o sea que si te vas a encontrar el error pero luego no vas a saber dónde está ese

01:20:52.240 --> 01:20:57.320
error y vas a tener que va a costar llegar a esa parte del código entonces se crearon los actores

01:20:57.320 --> 01:21:06.480
claro lo peor de todo es que puede ser que tengas un data race no cuelgue la aplicación y lo que

01:21:06.480 --> 01:21:13.560
tenga sea una desincronía de información vale yo una de las cosas que les enseño a los alumnos

01:21:13.560 --> 01:21:21.160
y que se quedan flipando para enseñarles lo que es el data race es poner en una cuenta de banco

01:21:21.160 --> 01:21:29.240
vale yo tengo una cuenta a que va a transferir mil veces un dólar de la cuenta 1 a la 2 y luego

01:21:29.240 --> 01:21:38.120
otras mil transferencias de un dólar de la cuenta 2 a la 1 teóricamente esas mil transferencias da

01:21:38.120 --> 01:21:45.680
igual cuando se hagan siempre tienen que dar que el contenido se quede igual que estaba vale porque

01:21:45.680 --> 01:21:52.400
estoy metiendo mil veces metiendo mil dólares uno a uno y metiendo mil dólares en la otra de vuelta

01:21:52.400 --> 01:21:57.800
por lo tanto da igual el orden en el que se hagan las operaciones siempre tiene que dejar las

01:21:57.800 --> 01:22:04.040
cuentas con el mismo saldo en el momento en el que lo metes dentro de un dispatch queue global

01:22:04.040 --> 01:22:14.960
que es asíncrono barra concurrente y empiezas a tirar las transferencias lanzas y de pronto te

01:22:14.960 --> 01:22:26.600
dice saldo final de las cuentas 500 y 100 lo lanzas otra vez saldo final 1200 y 3000 cuando deberían

01:22:26.600 --> 01:22:34.480
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

01:22:34.480 --> 01:22:41.360
imaginar lo que es un mismo código que cada vez que lo ejecutas devuelve un resultado totalmente

01:22:41.360 --> 01:22:49.080
distinto porque porque esos mil trans esas mil transacciones se están pisando la una a la otra

01:22:49.080 --> 01:22:57.240
vale porque si tú vas a leer un dato para escritura tú tienes primero que leer el dato llevártelo a

01:22:57.240 --> 01:23:04.440
la memoria de tu aplicación cambiar ese dato y luego volverlo a poner en la memoria cambiado

01:23:04.440 --> 01:23:12.120
si en esos pasos vale que tú estás haciendo resulta que a la vez está entrando otro proceso

01:23:12.120 --> 01:23:19.280
y se lee varias veces el valor antes de ser escrito tienes una desincronía en la que de esos mil

01:23:19.280 --> 01:23:27.480
procesos el valor que entra es el que le da la gana entonces insisto es mil y mil y ves perfectamente

01:23:27.480 --> 01:23:32.640
como cada ejecución devuelve un resultado totalmente distinto entonces es algo que obviamente hay que

01:23:32.640 --> 01:23:40.760
evitar y cuando eso lo metes haciendo que la clase de la cuenta bancaria sea un actor le das mil veces

01:23:40.760 --> 01:23:47.840
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

01:23:47.840 --> 01:23:54.040
alumnos se me quedan flipando como diciendo hostia y eso que ha pasado ahí jaja no que ha pasado

01:23:56.080 --> 01:24:02.200
y cómo haces el actor vale pues así lo que lo que hace también sé antes de que vinieran los

01:24:02.200 --> 01:24:07.040
actores vale se podía hacer con logs y cosas pero lo que tienes que hacer es cuando alguien va a

01:24:07.040 --> 01:24:11.720
acceder a esa variable bloquearla vale entonces te convierte todas las propiedades que declares

01:24:11.720 --> 01:24:18.880
en ese en ese actor de la bueno variables mejor dicho de las convierte en asíncronas vale es

01:24:18.880 --> 01:24:23.280
decir que si tú quieres cambiar la de fuera pues tienes que hacer una wait o bueno si quieres

01:24:23.280 --> 01:24:28.040
cambiarla también desde una función del código igual el código se va a suspender ahí y va a

01:24:28.040 --> 01:24:33.640
esperar a que se toque esa variable para el siguiente vale y va acumulando secuencialmente

01:24:33.640 --> 01:24:40.240
toda la gente que quiere acceder a esa variable vale muy bien y para el ejemplo de julio nos vale

01:24:40.240 --> 01:24:44.880
con eso lo tenemos hecho ese programa va a ir siempre bien porque nos da exactamente igual

01:24:44.880 --> 01:24:52.440
que se hagan tres transacciones de A a B luego dos de B a A luego con que se hagan mil para un lado

01:24:52.440 --> 01:24:58.000
y mil para otro lado al final de la ejecución las cuentas se van a quedar exactamente igual y

01:24:58.000 --> 01:25:07.200
eso va a pasar porque no se van a pisar pero este aquí el problema que ese acceso secuencial a la

01:25:07.200 --> 01:25:15.080
variable no significa acceso secuencial a la función a una función que llames vale os pongo

01:25:15.080 --> 01:25:21.960
el caso imaginaros que en lugar de ser esa variable lo que comentaba julio que es el saldo de una

01:25:21.960 --> 01:25:31.040
cuenta vale es una caché de imágenes en la que guardo un diccionario y el data vale el png data

01:25:31.040 --> 01:25:37.960
de esa imagen vale y lo guardo en una variable en memoria y tengo una función que es fetch image

01:25:37.960 --> 01:25:43.120
que le doy la url vale si la encuentro en esa caché me devuelve directamente el data ese y si

01:25:43.120 --> 01:25:50.120
no hace una llamada url y me devuelve de ahí y lo guarda en caché vale pues yo hago dos llamadas

01:25:50.120 --> 01:25:59.120
seguidas a esta función con la misma url vale y qué me pasa que me va las dos veces a internet

01:25:59.120 --> 01:26:04.520
dice si porque si esto se ejecuta secuencialmente porque a la variable de la caché se accede

01:26:04.520 --> 01:26:11.440
secuencialmente y es que no porque porque yo llamo esta función él va a decir no está en la caché y

01:26:11.440 --> 01:26:17.880
empieza a ejecutar la llamada de red y esa llamada de web de red se hace con un try await es decir

01:26:17.880 --> 01:26:24.480
que se suspende entonces claro el actor dice vale pues yo voy a mi cola de peticiones a mí que de

01:26:24.480 --> 01:26:29.160
hecho le llaman el inbox de los mensajes vale porque hacen como el símil de los mensajes y

01:26:29.160 --> 01:26:33.040
curso la siguiente y que le va a pasar a la siguiente pues que también va a decir uy no

01:26:33.040 --> 01:26:40.880
estoy en la caché salto para abajo entonces aquí tenemos el problema que no solucionamos menuda

01:26:40.880 --> 01:26:46.200
caché más mala que he creado si le estoy haciendo una petición y la misma petición la misma imagen

01:26:46.200 --> 01:26:53.560
y las dos veces ha ido a internet vale esto no es caché ni es nada cómo se minimiza esto pues al

01:26:53.560 --> 01:27:02.160
final en lugar de guardar en la caché el resultado lo que guardo es la tarea vale las tasks se pueden

01:27:02.160 --> 01:27:10.520
guardar la referencia como un dato vale entonces cuando hago esa llamada de red luego en una nueva

01:27:10.520 --> 01:27:18.160
task vale que la espero también se puede hacer una await task o await de la variable donde tengo

01:27:18.160 --> 01:27:24.560
la task y espero el valor entonces de esta manera sí que la primera petición se va a parar se va a

01:27:24.560 --> 01:27:33.120
suspender porque va a hacerlo esta petición de red asíncrona pero la siguiente también se va a parar

01:27:33.120 --> 01:27:38.520
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

01:27:38.520 --> 01:27:45.960
a las dos llamadas el retorno de esa tarea vale los datos de retorno de esa tarea entonces ya lo

01:27:45.960 --> 01:27:51.360
guardaría en caché y ya sí que la siguiente que llegue de esa misma imagen me lo pasaría y esto

01:27:51.360 --> 01:27:58.040
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

01:27:58.040 --> 01:28:03.800
mí también me pasó una vez que tuve que hacer o sea tenía hecho mi manager perfecto para sincronizar

01:28:03.800 --> 01:28:07.880
unos datos con el servidor que hacía la petición que lo guardaba en disco que tal para no repetir

01:28:07.880 --> 01:28:14.720
peticiones cada 12 horas bueno súper chulo y cuando me pongo a hacer los test unitarios digo

01:28:14.720 --> 01:28:21.360
hoy pero si siempre me la está sacando del mismo sitio y esfocando que ahí digo vale salado es que

01:28:21.360 --> 01:28:29.360
las peticiones se ponen de manera asíncrona pero una vez que lo suspendo el actor puede volver puede

01:28:29.360 --> 01:28:35.200
seguir con la secuencia en la cola y todavía no estar preparado no estar cacheado el dato vale y

01:28:35.200 --> 01:28:42.520
pasar dos veces entonces por eso lo quería traer aquí porque parece o sea de hecho apple julio

01:28:42.520 --> 01:28:46.800
me contó con antes cuando estábamos hablando antes del programa que sí que luego apple puso

01:28:46.800 --> 01:28:53.160
un ejemplo pero a mí me suena que uno de los primeros vídeos de asínca way no sé si cuando

01:28:53.160 --> 01:29:00.720
estaba todavía en desarrollo ya uno de los vídeos de apple ponían como tu pon actor y ya está sabes

01:29:00.720 --> 01:29:05.800
y ya tienes la vida solucionada y no es del todo cierto porque hay casos como este en el que no

01:29:05.800 --> 01:29:14.560
sólo vale con con crear el actor esto se llama actos reentran si vale reentrada de actores y

01:29:14.560 --> 01:29:22.440
efectivamente había un vídeo en la wwdc donde se generaba una solución a este problema vale la

01:29:22.440 --> 01:29:29.680
solución este problema cuál es es usar algo que mucha gente no conoce de asina wait vale el año

01:29:29.680 --> 01:29:34.920
asín a weight no fue muy bueno a nivel didáctico vale la gente que se encargó de hablar de todo

01:29:34.920 --> 01:29:40.560
esto no todos tenían una buena didáctica y no fueron capaces de encontrar una forma de explicarlo

01:29:40.560 --> 01:29:47.880
de manera clara vale y esto es una cosa que luego penaliza de acuerdo porque al final hay muchísima

01:29:47.880 --> 01:29:56.000
gente que asín a weight lo está usando para hacer un dar un uno de sesión share punto data y ya está

01:29:56.000 --> 01:30:03.160
pero luego no no hace secuencias asíncronas no sabe cómo funcionan las continuaciones no

01:30:03.160 --> 01:30:09.200
sabe desde luego cómo van los grupos de tareas o incluso piensan como me ha pasado a mí que poner

01:30:09.200 --> 01:30:16.560
cuatro traya weights uno debajo del otro ya es concurrencia no señores es serialización porque

01:30:16.560 --> 01:30:21.360
está esperando cada línea para que termine vale si lo quieres hacer concurrente hay que poner tu

01:30:21.360 --> 01:30:27.520
plas vale para que se solucionen al mismo tiempo de acuerdo es decir tendrías que poner un traya

01:30:27.520 --> 01:30:33.920
weight y dentro la resolución de cuatro funciones o cinco o seis o las que quieras poner dentro de

01:30:33.920 --> 01:30:40.320
la de la tupla para que así sean concurrentes o meterlas en una secuencia síncrona y hacer un

01:30:40.320 --> 01:30:46.080
for traya weight in donde también tienes ahí la posibilidad de esas secuencias asíncronas a partir

01:30:46.080 --> 01:30:53.320
de un encolado con las grupos de tareas vale las cosas que esta cosa bonita vale pero el tema del

01:30:53.320 --> 01:31:01.000
actor re-entrancy que bonito que es actor re-entrancy básicamente es utilizar programación

01:31:01.000 --> 01:31:06.440
estructurada basada en asina weight es decir cuando yo pongo asina weight lo que hago es

01:31:06.440 --> 01:31:15.240
poner un task y ya y ya y ya stacks vale pero no es esa la solución cuando yo pongo un task el

01:31:15.240 --> 01:31:27.240
task es capaz de devolverse porque el task es un futuro de un result vale el task es un futuro de

01:31:27.240 --> 01:31:34.720
un tipo resultado por lo tanto el task se define si tú el task lo metes dentro de una constante

01:31:34.720 --> 01:31:41.520
verás que dependiendo de lo que el task devuelva vas a tener un genérico de lado de success lado

01:31:41.520 --> 01:31:49.000
de fallo de acuerdo entonces si tú pones un traya weight si tú pones simplemente let cosa es igual

01:31:49.000 --> 01:31:55.960
a task abro llave y dentro pongo traya weight de get imagen lo que sea vale si yo pongo eso

01:31:55.960 --> 01:32:08.080
veremos que la constante cosa es un task genérico de UIImage,error vale entonces si ese task dentro

01:32:08.080 --> 01:32:19.640
de otro task vale de forma estructurada lo utilizo ese task tiene dos propiedades a las que podemos

01:32:19.640 --> 01:32:27.280
acceder que son una de tipo await y otra de tipo traya weight la propiedad de tipo await cuál es

01:32:27.280 --> 01:32:35.520
el result type del que procede el task por lo que si el task es UIImage,error tienes un task punto

01:32:35.520 --> 01:32:42.960
result que es un await es una en realidad es una async vale que se invoca solo con await sin el

01:32:42.960 --> 01:32:48.960
tray que te devuelve el result type de ese UIImage,error como el error va en el result type por

01:32:48.960 --> 01:32:55.200
eso no es tray vale pero también puedes acceder a la propiedad value que la propiedad value es

01:32:55.200 --> 01:33:03.520
una propiedad que va directa a la parte del success del result type y esa parte del success

01:33:03.520 --> 01:33:12.280
del result type lo que se devuelve con un tray await porque si hay un error en ese success te

01:33:12.280 --> 01:33:18.880
lo va a propagar a través del tray vale entonces eso es lo que hacía Apple, Apple metía un diccionario

01:33:18.880 --> 01:33:27.520
y ese diccionario era nombre de imagen dos puntos task, task genérica de UIImage,error vale

01:33:27.520 --> 01:33:35.400
entonces si tú volvías a llamar a la función cuando todavía porque aquí el problema está

01:33:35.400 --> 01:33:41.360
como ha comentado Arturo en que tú llames a una función para pedir una imagen y cuando aún no

01:33:41.360 --> 01:33:47.400
sea descargado vuelvas a llamar a la misma función para la misma imagen entonces te genera doble

01:33:47.400 --> 01:33:54.520
llamada por lo que lo que hace el sistema es detectar si tú estás teniendo una si tú ya

01:33:54.520 --> 01:34:01.920
tienes activa la llamada en un diccionario a esa misma imagen y en vez de devolverte la imagen

01:34:01.920 --> 01:34:11.840
te devuelve el value el task.value tray await de la imagen vale de acuerdo entonces la primera

01:34:11.840 --> 01:34:17.520
vez mete esa tarea dentro de un diccionario y cuando el diccionario termina la resuelve y la

01:34:17.520 --> 01:34:23.640
devuelve pero si vuelve a entrar y la tarea está en el diccionario te devuelve directamente el

01:34:23.640 --> 01:34:29.080
tray await del punto value quiere decir que si hay dos tres funciones que llaman a la misma

01:34:29.080 --> 01:34:38.080
imagen de manera concurrente la primera que llame va a recibir realmente la primera petición con el

01:34:38.080 --> 01:34:43.000
proceso de tray await que va a hacer que se espere hasta que se devuelva pero las demás concurrentes

01:34:43.000 --> 01:34:50.440
van a recibir el punto value de ese task por lo tanto las cuatro cinco seis llamadas concurrentes

01:34:50.440 --> 01:34:55.920
que vayan a la misma imagen mientras esa imagen se descarga cuando la imagen esté descargada de la

01:34:55.920 --> 01:35:02.920
primera vez que se pidió recibirán todas a la vez la imagen descargada desde un mismo proceso y con

01:35:02.920 --> 01:35:10.920
eso se soluciona el problema de la reentrada del actor a través de funciones asíncronas vale ahora

01:35:10.920 --> 01:35:18.200
es cuando hay que decir aquello de así de simple y así de sencillo. Sí a ver bueno es que iba a

01:35:18.200 --> 01:35:24.200
decir que luego se ve pero no o sea yo cuando me di cuenta y cuando dije cómo lo como lo mitigó

01:35:24.200 --> 01:35:31.640
tienes que saber bastante para mitigar eso de hecho es que la confieso que la primera vez que

01:35:31.640 --> 01:35:36.120
lo implementé no me di cuenta hasta que no fui a los test y en los test dije ostras porque está

01:35:36.120 --> 01:35:40.280
llamando y claro luego te pones a analizar el código dices claro si es que pones puntos de

01:35:40.280 --> 01:35:48.280
ruptura como os he dicho antes y ves que el círculo se va cerrando empezamos con el principio

01:35:48.280 --> 01:35:54.920
luego vamos a la mitad del programa y luego al final vale pues la la siguiente cosilla que

01:35:54.920 --> 01:36:02.760
quería comentar es el tema de las capturas de variable en los closers vale hemos visto que

01:36:02.760 --> 01:36:08.520
muchas veces cuando las son cuando queremos ejecutar un closer que necesita algo de un

01:36:08.520 --> 01:36:15.280
que esté fuera del ámbito necesitamos capturarlo pero una cosa que muchas veces se nos puede pasar

01:36:15.280 --> 01:36:24.000
por alto es que la captura de esos valores se hace en bueno y ya en su día hablamos de capturar con

01:36:24.000 --> 01:36:29.360
con wik valores o sea valores por referencia porque luego pueden no existir además se crea

01:36:29.360 --> 01:36:35.280
un conteo o sea se suma a un conteo vale pero bueno es harina de otro costal que dicen aquí

01:36:35.280 --> 01:36:40.520
voy con el momento en el que captura las variables por ejemplo un valor una variable que por valor

01:36:40.520 --> 01:36:49.560
claro esa captura se realiza en el momento de definir el closure que no es el mismo momento

01:36:49.560 --> 01:36:57.880
en el que se ejecuta el closure pero como estamos capturando algo por valor el valor ya lo hemos

01:36:57.880 --> 01:37:04.880
capturado antes si alguien viene y me cambia esa variable un entero vale que en el momento de

01:37:04.880 --> 01:37:13.160
definirlo valía 2 pero en el momento de ejecutarlo vale 4 vale 4 la variable pero lo que he capturado

01:37:13.160 --> 01:37:20.920
vale 2 y eso te puede generar problemas es otra cosa que hay que darse cuenta que cuando capturamos

01:37:20.920 --> 01:37:26.920
un valor lo capturamos en el momento que definimos el closure vale el closure digamos que una vez que

01:37:26.920 --> 01:37:33.640
tú lo declaras vale donde lo declaras pues en una función que llamas o lo que sea o lo guardes en

01:37:33.640 --> 01:37:39.800
alguna variable en ese momento ese closure queda empaquetadito para el momento en que se ejecute

01:37:39.800 --> 01:37:47.040
vale no es que cuando tú vayas a ejecutarlo se vuelva a evaluar no no no no se ha evaluado en

01:37:47.040 --> 01:37:52.520
el momento que lo defines vale entonces hay que tener en cuenta que va a tener el valor del momento

01:37:52.520 --> 01:37:58.040
en el que lo estás definiendo cuando lo pasamos cosas por valor vale no por no por referencia

01:37:58.040 --> 01:38:03.320
no sé si julio te has encontrado algo de este calibre

01:38:05.480 --> 01:38:08.680
pues a ver

01:38:11.520 --> 01:38:21.880
claro es que este tema es complejo vale porque teóricamente teóricamente en un porque claro

01:38:21.880 --> 01:38:30.480
aquí es a ver aquí estás comentando el típico problema de la roba escaping que pasa con los con

01:38:30.480 --> 01:38:40.160
las clases vale y que teóricamente pues con los struts no se da o eso dice apple no pero

01:38:40.160 --> 01:38:47.800
efectivamente si puede llegar a darse no se me ha pasado nunca vale porque al final yo la mayoría

01:38:47.800 --> 01:38:54.520
de las veces lo que uso son dentro del contexto de sus joyes más complicado que que suceda pero

01:38:54.520 --> 01:39:01.520
claro este tipo de reglas de copia por valor esto puede ser un motivo por el que ahora tenemos un

01:39:01.520 --> 01:39:07.560
modificador que yo creo que nadie conoce que es el modificador copaya vol no sé si lo has visto

01:39:07.560 --> 01:39:21.520
pues el modificador copaya vol es para modificar la

01:39:23.680 --> 01:39:28.280
lo que sería el ciclo de vida de las

01:39:28.280 --> 01:39:36.840
el ciclo de vida de los de los elementos vale es decir tú en swift puedes hacer que un

01:39:36.840 --> 01:39:47.600
un strut vale sea copiable vale entonces al ser copiable lo que estás haciendo es que no

01:39:47.600 --> 01:39:56.760
sea una nueva copia sino que sea vale esto lo puedes definir es una una una propuesta que es

01:39:56.760 --> 01:40:05.320
la 390 que son los non copia bols struts and nums vale es decir tú puedes hacer que un strut sea

01:40:05.320 --> 01:40:12.720
copiable o que un strut sea no copiable vale entonces de esta manera puedes cambiar la forma

01:40:12.720 --> 01:40:23.280
en la que se están gestionando vale los distintos elementos de lo estoy explicando así un poco por

01:40:23.280 --> 01:40:29.680
encima vale porque no no tengo muy claro exactamente qué es porque no lo he trabajado vale sé que está

01:40:29.680 --> 01:40:35.120
lo he visto etcétera etcétera pero no lo he trabajado como tal ni lo he probado como tal

01:40:35.120 --> 01:40:41.600
vale pero básicamente creo que lo que hace es cambiar ese paradigma de la copia por valor que

01:40:41.600 --> 01:40:49.240
te genera ese problema vale entonces de esa manera lo que tú haces es decirle que retenga en memoria

01:40:49.240 --> 01:40:58.080
como una referencia un strut para que luego tú puedas a partir de ahí bueno pues evitar esos

01:40:58.080 --> 01:41:07.120
problemas y que la instancia del strut pues sea de una manera no sé como más sencillo pero esto es

01:41:07.120 --> 01:41:13.480
algo que yo te digo no lo he tocado como veis no estoy explicándolo muy bien porque no lo he tocado

01:41:13.480 --> 01:41:23.080
ni lo he entendido nunca pero sé que está ahí vale sé que es una posibilidad de utilizar estos

01:41:23.080 --> 01:41:30.680
struts y estas enumeraciones en un modo no copiable para que esa copia por valor no se vea

01:41:30.680 --> 01:41:40.000
no se haga vale en ciertos casos donde pues bueno te sea necesario hacer este tema vale o sea sería

01:41:40.000 --> 01:41:46.200
algo así como intentar permitir que los desarrolladores puedan definir tipos que sean

01:41:46.200 --> 01:41:53.320
strut y enums que no se copien de manera automática para pues ciertos elementos que intenten evitar

01:41:53.320 --> 01:42:01.360
los problemas vale entonces tú puedes añadir un atributo arroba non copiable vale y eso lo que

01:42:01.360 --> 01:42:08.080
hace es que cuando tú pases el elemento lo pase como una especie de referencia en vez de pasarlo

01:42:08.080 --> 01:42:17.440
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

01:42:17.440 --> 01:42:26.880
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

01:42:26.880 --> 01:42:33.280
parece ser que evita que puedas hacer implementaciones de tipo hacer una asignación etcétera etcétera

01:42:33.280 --> 01:42:40.400
vale que no que te impida no que el elemento pueda ser copiado para tener una una tal vale se parece

01:42:40.400 --> 01:42:45.680
ser que no puedes usar el operador de igualdad vale ni puedes utilizarlo en tipos de contexto

01:42:45.680 --> 01:42:51.680
que requieran conformidad con el protocolo copiable copiable vale es como una forma de

01:42:51.680 --> 01:42:57.800
limitar el uso de los struts y los enums para evitar este problema de la compartición de las

01:42:57.800 --> 01:43:04.360
de los datos copiados de tipo por valor esto ya dando muy fino ya sí sí es lo que te iba a decir

01:43:04.360 --> 01:43:11.760
que pero ves como por eso hay que hablar con gente y con programadores de tu nivel o mayor para este

01:43:11.760 --> 01:43:17.160
tipo de cosas por eso a pesar de que yo tampoco sé muy bien cómo funciona porque no lo he mirado

01:43:17.160 --> 01:43:28.760
ya se ha ido a hablar ya me voy a la cama sabiendo que lo que tengo esa opción bueno de hecho se

01:43:28.760 --> 01:43:36.280
supone que que bueno que apple estaría por cambiar o pensar al menos eso se dijo en su momento que en

01:43:36.280 --> 01:43:47.720
su ip6 yo puedo retener el ciclo de vida con una especie especie de retail release vale es decir

01:43:47.720 --> 01:43:53.280
sabemos que si yo dentro de un ámbito creo una constante cuando el ámbito acaba la constante

01:43:53.280 --> 01:43:59.680
muere porque funciona por arc pues el modelo de memoria va a cambiar a un modo no exclusivo en

01:43:59.680 --> 01:44:05.960
el que podríamos decirle créame está constante pero manténla en memoria más allá del ámbito

01:44:05.960 --> 01:44:13.280
donde está y ya te diré yo cuando tienes que liberarla ahora claro es que una de las cosas

01:44:13.280 --> 01:44:19.840
buenas que tiene su y es que no tiene punteros vale que todo este de reten cosas y demás pero

01:44:19.840 --> 01:44:27.560
claro luego tiene como el ejemplo este del in out de las de las funciones vale que puedes sacarlo

01:44:27.560 --> 01:44:34.440
fuera pero claro luego hay cosas que tiene que incorporar el propio lenguaje que a lo mejor con

01:44:34.440 --> 01:44:39.760
una estructura de punteros y de otro modelo de memoria se podrían hacer pero aquí hay que hay

01:44:39.760 --> 01:44:46.600
que poner cada caso y dejarlos es que yo una de las cosas que me explotó la cabeza o el principio

01:44:46.600 --> 01:44:51.800
cuando estaba utilizando su y eso cuando te cuentan no es que una estructura es por valor y una clase

01:44:51.800 --> 01:44:58.120
es por referencia y tú what que me estás contando si sabes porque y eso que yo conocía cosas de

01:44:58.120 --> 01:45:03.840
punteros y demás pero un puntero dice no yo es que le pongo todo es igual pero le pongo una cosa

01:45:03.840 --> 01:45:11.520
es el puntero y otra cosa es la variable en sí claro y entonces ahí te explota un pelín la cabeza

01:45:11.520 --> 01:45:19.080
y pues si ya para no liarnos más si te parece voy a comentar otras cosas que surgió y es que

01:45:19.080 --> 01:45:25.480
hemos hablado también antes ya para cerrar el círculo de swift 6 vale y una de las cosas que

01:45:25.480 --> 01:45:36.320
ya están por aquí en swift 5.x son esas palabras de SAM y ENI vale el SAM nos acordáis que empezó

01:45:36.320 --> 01:45:42.480
con SwiftUI de hecho Apple hizo su implementación interna y luego lo liberó la gente se enfadó un

01:45:42.480 --> 01:45:48.320
poquito sabes con ese con ese tema es decir es un lenguaje open source y metes una característica

01:45:48.320 --> 01:45:54.920
sí o sí porque os apetece a vosotros vale pues swift 6 la intención es que se pongan mucho más

01:45:54.920 --> 01:46:08.120
punkis por así decirlo y te obliguen siempre que utilices un protocolo a definirlo o a implementarlo

01:46:08.120 --> 01:46:15.720
en alguna de tus en una clase o como argumento de una propiedad de una estructura de una de una

01:46:15.720 --> 01:46:22.480
clase o un argumento de una función que siempre venga acompañado de este SAM y de este ENI así

01:46:22.480 --> 01:46:29.800
a grandes rasgos la diferencia entre ambos es que SAM en tiempo la diferencia es cuando sabes

01:46:29.800 --> 01:46:36.760
qué tipo es vale con SAM tú aseguras y estás obligado a que en tiempo de compilación el

01:46:36.760 --> 01:46:44.000
compilador sepa eso que es exactamente vale es se conforma al protocolo codable pero que es

01:46:44.000 --> 01:46:53.560
exactamente vale sin embargo ENI es sabido es desempaquetado en tiempo de ejecución cuál es la

01:46:53.560 --> 01:47:01.160
diferencia pues que este ENI es más flexible por un lado pero por otro exige más cómputo vale

01:47:01.160 --> 01:47:07.280
entonces en swift 6 lo que se quiere hacer es hincapié en que cuando utilices ENI o sea minimices

01:47:07.280 --> 01:47:13.680
el uso de ENI y que cuando lo utilices tengas que poner la palabra reservada antes para saber

01:47:13.680 --> 01:47:21.360
que estás incurriendo en un coste a la hora de hacer esa ejecución el ejemplo más rápido vale

01:47:21.360 --> 01:47:25.600
que fue ya yo cuando estuvimos hablando de esto también nos explotaba un poco la cabeza a todos

01:47:25.600 --> 01:47:32.560
me hice un playground vale y qué diferencia qué diferencia había entre las dos que por ejemplo

01:47:32.560 --> 01:47:42.880
yo defino una clase una estructura vale y tiene dos ejemplos una propiedad y una función vale

01:47:42.880 --> 01:47:51.520
que tiene la propiedad es un protocolo no defino un protocolo no defino un tipo concreto y en la

01:47:51.520 --> 01:48:00.360
función defino también en uno de los argumentos tiene un protocolo vale en la propiedad sí o sí

01:48:00.360 --> 01:48:08.920
tengo que poner ENI porque tengo que poner ENI porque esa cuando se compila esa clase o esa

01:48:08.920 --> 01:48:15.760
estructura vale el compilador como no está instanciada no sabe qué es eso entonces siempre

01:48:15.760 --> 01:48:23.280
es ENI porque en tiempo de compilación no se sabe qué es eso cuando luego ya esa código compilado lo

01:48:23.280 --> 01:48:30.200
utilice en otro sitio de mi aplicación y cree esa clase le voy a decir oye esta clase es de este

01:48:30.200 --> 01:48:35.200
protocolo es este tipo concreto pero hasta ese momento va a ser un protocolo con lo cual ENI

01:48:35.200 --> 01:48:44.200
sí o sí pero en la función yo le puedo poner como SAM porque cualquier cualquiera que se haya

01:48:44.200 --> 01:48:50.640
conformado a ese o sea cualquier instancia de esa clase cuando utilice esa función me va a tener que

01:48:50.640 --> 01:48:57.840
decir en tiempo de compilación qué es qué tipo es vale entonces ahí sí me va a tragar el SAM vale

01:48:57.840 --> 01:49:06.080
es un poco lío hasta ahora no estás obligado a utilizarlo vale tú te puedes definir una clase e ir

01:49:06.080 --> 01:49:12.600
a poner directamente una propiedad que cumpla un protocolo y punto vale el problema es el mismo

01:49:12.600 --> 01:49:19.880
vale que no se va a saber hasta tiempo de ejecución y vas a tener cierta sobrecarga pero ahora mismo

01:49:19.880 --> 01:49:25.960
no te obliga pero para Swift 6 pues ya ya lo vamos a tener de hecho la diferencia y así por explicarlo

01:49:25.960 --> 01:49:33.600
a grandes rasgos porque tiene una sobrecarga porque es una resolución dinámica vale es decir no se

01:49:33.600 --> 01:49:39.000
sabe ya y no se compila sino que digamos que hay que poner hay que compilar cierta lógica para que

01:49:39.000 --> 01:49:44.240
en el momento de ejecución se ejecute esa lógica para saber qué es eso vale entonces es la diferencia

01:49:44.240 --> 01:49:50.560
de la resolución estática y la resolución dinámica de tipos no sé cómo ves esto julio si has tenido

01:49:50.560 --> 01:49:58.200
tuya que lidiar con sams y ennis pero se avecinan curvas con swift 6 o sea vamos a tener que

01:49:58.200 --> 01:50:08.880
reaprender o estudiar varias cosas yo es que como el tema de los genéricos a ver por ejemplo a mí

01:50:11.240 --> 01:50:19.240
si quiero poner una función por ejemplo normalmente pongo la función acotada entre menor y mayor y

01:50:19.240 --> 01:50:30.280
meto ahí el genérico si tengo que pegarlo a un protocolo lo pongo ahí directamente sin embargo

01:50:30.280 --> 01:50:36.360
ahora en la última versión de swift el compilador me está diciendo que mejor ponga

01:50:36.360 --> 01:50:53.240
were genérico igual a protocolo vale me cuesta me cuesta que sí que está muy bien porque todo

01:50:53.240 --> 01:51:01.000
eso nos va a permitir tener un código más genérico valga la redundancia pero yo creo que lo de las

01:51:01.000 --> 01:51:06.920
reglas del sam y del enni es un poco confuso vale es un poco como lo que me ha pasado todos los

01:51:06.920 --> 01:51:14.800
alumnos cuando usan el sam en swift UI no entienden que el sam tiene que tener el mismo tipo de

01:51:14.800 --> 01:51:21.880
devolución vale que sí que tiene que cumplir tú pones sam view y sam view es que tú vas a devolver

01:51:21.880 --> 01:51:28.200
un view pero si tú tienes tres salidas y en cada una de ellas envías un tipo distinto conformado

01:51:28.200 --> 01:51:35.960
con view no sirve tienes que devolver el mismo tipo es un botón otra un texto y en otra un

01:51:35.960 --> 01:51:41.280
rectángulo no puedes te dice el compilador que pa casa que pa casa porque el sam tiene que ser

01:51:41.280 --> 01:51:47.920
el mismo tipo ya que al final es un genérico vale todo es el genérico una vez está fijado por el

01:51:47.920 --> 01:51:56.360
compilador ya no puede cambiar vale o sea es como si tú creas un genérico y usaste y usaste en todo

01:51:56.360 --> 01:52:02.320
el código y luego cuando lo invocas dices que t es un entero pues t ya es un entero si quieres

01:52:02.320 --> 01:52:07.520
usar también un doble como genérico tendrás que poner u o tendrás que poner otro genérico que

01:52:07.520 --> 01:52:13.280
sea de otro tipo distinto vale ese es el por qué en el momento en el que tú has fijado el tipo

01:52:13.280 --> 01:52:20.640
del genérico del protocolo a text pues ya todas las salidas tienen que ser text pero es confuso

01:52:20.640 --> 01:52:26.360
vale y sobre todo por ejemplo con el tema de los errores a mí cada dos por tres cuando uso mis

01:52:26.360 --> 01:52:36.240
propios tipos de error me está diciendo no no esto es un error y es como uff entonces yo creo

01:52:36.240 --> 01:52:45.040
que es algo que a nivel didáctico creo que swift está cogiendo ciertos cambios para las para las

01:52:45.040 --> 01:52:51.920
funcionalidades más avanzadas haciendo demasiado caso a gente muy purista que lo que quiere es

01:52:51.920 --> 01:53:02.080
poder con perdón de la expresión pero en botija y no y me parece que no porque están rompiendo el

01:53:02.080 --> 01:53:09.280
espíritu verdadero de swift que es el de ser un lenguaje fácilmente entendible no sé cómo lo

01:53:09.280 --> 01:53:15.720
entiende con esto si no porque hay una parte que sí que es verdad que swift y una curva de

01:53:15.720 --> 01:53:22.800
aprendizaje comparada con otros lenguajes bastante poco pronunciado vale bastante suave el problema

01:53:22.800 --> 01:53:30.200
es que swift cuando en las primeras errores va guay pero pero pasas una curva y de pronto pasas

01:53:30.200 --> 01:53:34.960
de algo muy guay a algo de hostia que ha pasado aquí porque de pronto se convierte en algo súper

01:53:34.960 --> 01:53:42.880
complejo pero claro el problema que veo es que es tan sencillo que luego hay cosas como los data

01:53:42.880 --> 01:53:51.360
rays y demás que estaría muy bien que en tiempo de o sea cuando estás escribiendo el código lo

01:53:51.360 --> 01:53:58.520
sepas y yo creo que esto busca un poco el aunque es claro es complicado de hacer busca un poco eso

01:53:58.520 --> 01:54:03.720
que es en plan mira el error este muchas veces de que estás utilizando un genérico que luego se

01:54:03.720 --> 01:54:10.200
tiene que resolver de forma dinámica de sobrecarga lo puedes hacer pero tienes que escribir una

01:54:10.200 --> 01:54:16.680
palabreja que sabes que algo pasa ahí pero claro es lo que siempre decimos un lenguaje que empieza

01:54:16.680 --> 01:54:22.800
a tener 800 palabras reservadas no sé cuántos modificadores como el arroba ahora vienen las

01:54:22.800 --> 01:54:31.840
macros hostia que eso también te grita que yo he decidido no dar macros en las formaciones de

01:54:31.840 --> 01:54:39.160
apple con academy que a ver qué es lo de siempre a mí para para una api me parecen geniales lo que

01:54:39.160 --> 01:54:43.440
se va a hacer es algo que no vas a hacer en tu vida salvo que hagas una api y seas un crack

01:54:43.440 --> 01:54:49.800
porque tengo que hacer un sdk yo creo que seguro que tienes mil marrones que hacer más que ponerte

01:54:49.800 --> 01:54:57.200
a no voy a dejarlo con una macro así es que las macros están pensadas para eso entonces yo haré

01:54:57.200 --> 01:55:06.480
una formación grabada para el que la quiera hacer pero yo no voy a meter en una formación en la que

01:55:06.480 --> 01:55:12.520
no todos tienen el mismo nivel algo que yo sinceramente considero que es de un nivel de

01:55:12.520 --> 01:55:21.320
programación muy avanzada yo creo que es de lo más complejo que tiene swift de calle las

01:55:21.320 --> 01:55:29.680
posibilidades son brutales o sea lo que se puede conseguir con una macro es de locos vale pero su

01:55:29.680 --> 01:55:39.280
implementación es tan compleja que yo lo veo como algo que es inasumible para un alumno que si el

01:55:39.280 --> 01:55:47.360
árbol de navegas por el árbol y bueno es que es una movida nada más el código de macro que

01:55:47.360 --> 01:55:52.720
extienden todo otras que extienden sólo funciones otra que nada más que con que vean las macros de

01:55:52.720 --> 01:55:59.800
expresión que son las más simples y veas que para recuperar cada uno de los valores que se han metido

01:55:59.800 --> 01:56:06.600
dentro de la expresión tienes que hacer una función que recupere de manera genérica los valores y que

01:56:06.600 --> 01:56:16.400
luego algún casting porque tal es algo muy muy yo le veo una similitud muy grande a los lenguajes

01:56:16.400 --> 01:56:25.760
de bach a hacer shs con linux o con mac porque al final tienes eso no es como cojo un código

01:56:25.760 --> 01:56:30.960
luego lo pongo aquí luego tal pero yendo un poco más allá vale yo cuando en las formaciones enseño

01:56:30.960 --> 01:56:37.560
eso la gente se queda flipando diciendo porque a ver lo he enseñado en un par de ellas simplemente

01:56:37.560 --> 01:56:45.760
enseñar cómo es el famoso hash url para que te devuelva la url no como un opcional y cuando les

01:56:45.760 --> 01:56:51.120
he enseñado el código he visto las caras a la segunda clase que le puse eso y vi la cara que te

01:56:51.120 --> 01:56:58.320
pusieron dije nunca más o sea no voy a dar esto esto lo sacaré fuera lo daré como algo para que el

01:56:58.320 --> 01:57:04.800
friki piki plus lo pueda aprender y pueda sacarle provecho y lo va a flipar pero para la gente

01:57:04.800 --> 01:57:10.240
normal que además la gente normal no va a usar ese tipo de herramienta vale porque esto es una

01:57:10.240 --> 01:57:17.000
cosa que está más pensada para que la use la propia apel o la gente que lo va por o claro

01:57:17.000 --> 01:57:22.360
pa por la gente que haga sdks que haga frameworks de alto nivel etcétera vale que son muy pocos por

01:57:22.360 --> 01:57:27.760
eso yo lo enseñaré para que aquel que quiera aprenderlo lo aprenda pero no lo voy a meter en

01:57:27.760 --> 01:57:35.800
clase porque es que se me suicidan o sea no no hay no tengo no soy capaz de verdad de encontrar

01:57:35.800 --> 01:57:46.240
una curva donde meter eso y que tenga sentido y repito es brutal me parece increíble que lo hayan

01:57:46.240 --> 01:57:56.160
metido pero es una programación muy muy muy avanzada entonces claro porque al final es

01:57:56.160 --> 01:58:03.680
estandarizar eso como cómo hacer crecer un código te tienes lo que coges es al código y lo transforma

01:58:03.680 --> 01:58:12.520
pero claro la manera de entrar para hacerlo es muy muy muy farragosa porque el problema es que

01:58:12.520 --> 01:58:18.720
como esa capa de macro se está ejecutando en runtime y es capaz de resolverse en runtime y

01:58:18.720 --> 01:58:28.760
devolver horrores en runtime pues obviamente estás es algo tan engorroso como el que se pone a jugar

01:58:28.760 --> 01:58:39.400
con la API de mirror para ver propiedades de SwiftUI que la palabra farragoso toma un nuevo sentido con

01:58:39.400 --> 01:58:46.480
ella si además a ver calculó que la de macro no haga lo mismo pero a mí la de la de mirror la

01:58:46.480 --> 01:58:55.120
reflexión y tal de una versión para otra de Swift se me cargaron un montón porque antes por ejemplo

01:58:55.120 --> 01:59:05.400
para sacar como en la clase un nombre para la clase un lío y al final son son de mirror por

01:59:05.400 --> 01:59:10.480
ejemplo yo creo que Codable utiliza toda la parte está de mirror para sacar todas las variables y

01:59:10.480 --> 01:59:20.120
crearte un montón de código pero por eso Codable puede ser una de las cosas que a lo mejor te pongan

01:59:20.120 --> 01:59:32.240
una macro pues no lo descartaría porque ahora requiere una API como muy de bajo nivel y

01:59:32.240 --> 01:59:38.640
probablemente con una macro se resolvería de forma más más sencilla y sobre todo que aunque cambies

01:59:38.640 --> 01:59:43.600
las APIs de bajo nivel no te no te cargas nada sino no y que al final pues sea simplemente en

01:59:43.600 --> 01:59:49.640
vez de conformar al protocolo Codable pues pongas arriba arroba Codable y a volar y eso cambia la

01:59:49.640 --> 01:59:53.080
implementación interna y hace que funcione de una manera más rápida ahora que lo están haciendo

01:59:53.080 --> 02:00:01.680
desde cero en Swift pues sería una opción interesante en fin pues bueno nosotros queríamos

02:00:03.560 --> 02:00:09.320
queríamos hora y media pero bueno en fin nos vamos liando liando así que lo dejamos aquí

02:00:09.320 --> 02:00:34.760
le llevamos a las dos horas y entonces pues nos vamos al bloque final de despedida y poco más

02:00:34.760 --> 02:00:43.280
poco más que ya ha sido bastante que ya ha sido bastante sí como siempre cuando vamos a empezar

02:00:43.280 --> 02:00:49.320
siempre decimos arturo yo bueno a ver si el programa hoy nos falta contenido y tal no sé

02:00:49.320 --> 02:00:56.920
qué pero no no es que has hablado de reducirlo de dos horas y media a hora y media yo creo que

02:00:56.920 --> 02:01:03.320
es más bien es de dos horas y media o tres a dos horas si nosotros vamos a intentar para

02:01:03.320 --> 02:01:08.640
ahorita el niño jobs colocarnos en la hora y media pero esto es un poco como el que te dice

02:01:08.640 --> 02:01:13.960
no no hemos quedado a las ocho pero se lo dice al que siempre llega tarde para que así en realidad

02:01:13.960 --> 02:01:18.280
han quedado a las ocho y media y entonces así el que siempre llega tarde pues no llega tan tarde

02:01:18.280 --> 02:01:24.920
que julio si te pones con un café con un colega a hablar de las cosas que te gustan es que el

02:01:24.920 --> 02:01:35.120
tiempo se va sobre todo como tú dices que al final bueno pues comentas cosas hablas tal pones

02:01:35.120 --> 02:01:42.880
en común temas que normalmente no sueles hablar con tu familia y con la gente así más allegada

02:01:42.880 --> 02:01:50.840
por su bien mental y es como si un médico se pone a hablar de pruebas diagnóstica o una o un

02:01:50.840 --> 02:01:58.160
economista se pone a hablar de los tipos de la inflación y del tal pues ya sabes que son temas

02:01:58.160 --> 02:02:04.800
muy así entonces bueno pues siempre viene bien el tener a un buen compañero que con el que puedas

02:02:04.800 --> 02:02:11.000
hablar de estas cosas y poner en común conocimientos noticias experiencias que las experiencias al

02:02:11.000 --> 02:02:17.880
final uno de los motivos principales por los que nos gustó la idea del qué es lo que hacemos que

02:02:17.880 --> 02:02:25.360
está heredado del podcast de stack 3 vale que no sé si sigue o no lo hablamos hace poco han perdido

02:02:25.360 --> 02:02:31.320
regularidad si han perdido regularidad verdad pues esta actriz empezaba siempre así y la verdad

02:02:31.320 --> 02:02:37.360
que era algo que aportaba bastante porque al final este esta sección de que hemos estado haciendo

02:02:37.360 --> 02:02:43.120
pues saca la palestra un montón de temas y un montón de cosas y el que se pueda de alguna manera

02:02:43.120 --> 02:02:50.160
no debatir que siempre es algo que es muy muy interesante ya sabéis que si queréis escribirnos

02:02:50.160 --> 02:02:59.400
cualquier cosa opiniones preguntas lo que sea enviarnos un pago de miles de euros o de tal

02:02:59.400 --> 02:03:05.840
también podemos aceptarlo podéis hacerlo menos el mail del príncipe nigeriano cualquier cosa exacto

02:03:05.840 --> 02:03:11.960
el príncipe nigeriano ya lo tenemos superado podéis hacerlo a café swift con dos efes arroba

02:03:11.960 --> 02:03:20.280
gmail.com o también podéis encontrarnos en redes sociales como arroba café swift o también en

02:03:20.280 --> 02:03:27.840
redes sociales en x vale y en más todo donde estamos como arroba café swift arroba cuonda

02:03:27.840 --> 02:03:34.200
punto social ya sabéis que café swift es un podcast que pertenece a la comunidad independiente

02:03:34.200 --> 02:03:40.840
de podcast cuonda vale y es ahí pues donde tenemos el alojamiento del podcast y todo lo

02:03:40.840 --> 02:03:47.160
que es el fin la difusión del mismo de hecho pues sabéis que estamos en cuonda punto com barra café

02:03:47.160 --> 02:03:56.000
con dos efes guión medio swift y a ti dónde puede encontrarte la gente arturo pues a mí en mi otro

02:03:56.000 --> 02:04:02.000
podcast videos digitales que también estamos intentando coger periodicidad por cierto y

02:04:02.000 --> 02:04:11.200
cuando mejor me encontré es en x arroba arturo rivas a más todo en arturo rivas a arroba más

02:04:11.200 --> 02:04:16.160
todo un punto cloud y bueno toda esta información la podéis encontrar en mi página web que es tres

02:04:16.160 --> 02:04:23.040
sobredobles punto arturo rivas punto com y a mí pues si queréis contactarme igualmente verme en

02:04:23.040 --> 02:04:31.040
redes sociales seguirme pero no por la calle pues podéis hacerlo en x como arroba jc f1 o pues en

02:04:31.040 --> 02:04:38.160
cualquier red como jc f1 mal estoy ahí en instagram en facebook en fin si tengo facebook

02:04:38.160 --> 02:04:43.780
todavía ya lo sé porque es un señor mayor julio es porque es un señor mayor efectivamente no lo

02:04:43.780 --> 02:04:50.200
uso porque no tiene pero bueno ahí está desde siglos inmemoriales y luego pues igual en más

02:04:50.200 --> 02:04:58.520
todo un como jc f1 o arroba arroba jc f1 o arroba más todo un punto social también estoy en blue

02:04:58.520 --> 02:05:08.440
sky jc f1 o arroba bs ky punto social no sé si estoy también por ahí en y luego pues aquí en

02:05:08.440 --> 02:05:14.480
los directos en twitch punto tv barra apple coding y también en youtube en youtube punto

02:05:14.480 --> 02:05:21.520
com barra arroba apple coding y para arroba apple coding academy que es donde están colgados estos

02:05:21.520 --> 02:05:27.600
programas una vez ya se terminan y se producen y se lanzan así que bueno fijaros en la cantidad

02:05:27.600 --> 02:05:33.920
de lugares donde podéis encontrarnos para bueno pues para cualquier cosa así que lo dicho muchísimas

02:05:33.920 --> 02:05:39.760
gracias a todos por estar ahí a los que están en directo viendo la grabación en twitch y a todos

02:05:39.760 --> 02:05:47.400
los que nos escuchan gracias a las miles de personas que escuchan cada programa que la verdad

02:05:47.400 --> 02:05:55.280
que me maravilla la increíble comunidad swift de desarrollo swift que tenemos y si eso ya me

02:05:55.280 --> 02:06:03.440
maravilla y me da una esperanza lo que más nos alucina y lo que más agradecemos arturo y yo

02:06:03.440 --> 02:06:10.360
es la gente que nos escucha y que no es desarrolladora de swift pero lo hace porque le

02:06:10.360 --> 02:06:18.480
gusta lo que contamos porque le parece interesante porque aprende cosas nuevas la verdad que a todos

02:06:18.480 --> 02:06:28.520
ellos un saludo muy especial desde aquí así que ahora sí ya no poco más si yo creo que ha sido un

02:06:28.520 --> 02:06:35.920
programa un programa redondo porque hemos ido volviendo a temas que que habíamos hablado quizás

02:06:35.920 --> 02:06:41.320
sí que hoy hemos entrado un poco técnico perdón si no se ha entendido porque es complicado sin

02:06:41.320 --> 02:06:48.120
un medio visual transmitir estas cosas pero bueno si os ha quedado algo en el tintero pues ya os

02:06:48.120 --> 02:06:56.880
hemos dicho dónde contactarnos nos nos ponéis un post que ahora se llama en x un correo lo o lo

02:06:56.880 --> 02:07:03.040
que sea y oye podemos dedicarle os contestamos es un segundo pero si no podemos dedicarle otro

02:07:03.040 --> 02:07:08.920
ratillo en otro programa para andar y muchísimas gracias por escucharnos como ha dicho julio por

02:07:08.920 --> 02:07:13.000
por llegar hasta aquí esto lo hacemos también porque nos gusta la verdad porque es nuestro

02:07:13.000 --> 02:07:19.480
rato de hablar nuestras cosas de un café que en una empresa no podemos hacer porque si todos los

02:07:19.480 --> 02:07:28.920
días tomas un café de dos horas acaban echando seguro pero nada un placer estar aquí julio

02:07:28.920 --> 02:07:37.240
siga cumpliendo años por supuesto que me regalen muchos relojes pues y hasta el próximo capítulo

02:07:37.240 --> 02:07:42.560
y a ver si estamos cogiendo marcha a ver si si no decae la cosa durante la temporada exacto y

02:07:42.560 --> 02:07:47.600
como siempre no olvidéis jugar con el código hasta pronto

02:08:12.560 --> 02:08:28.880
puedes escuchar más episodios en cuando.com la comunidad de podcast independientes en español