Tipos de programadores o perfiles de la industria

[Eskema]

Holas,

En twitter ha surgido el tipico debate, lazy programmers vs manitas, asi que vamos a postear aqui las impresiones de cada perfil a ver que opina cada uno

Nuestro buen amigo el ninja fever posteaba tal que asi:
Unity 3D empieza a inquietar. ¿Hasta qué punto es bueno que tantos desarrolladores dependan de una misma empresa? ¿Siguen siendo indies?

Y nuestro amigo MrGrihan contestaba algo tal que asi:
...si las nuevas generaciones de programadores se forman SÓLO en Unity, pfff...


Aqui se muestra una preocupacion, un miedo pq la empresa X no encuentra gente que sepa de C++ y solo encuentra noobs que saben manejar unity3d o engines similares.

Yo expondria que hay 2 perfiles basicos de programador (dejando de lado el junior/senior)

Perfil A: el manitas, el que le gusta la tecnologia y quiere saberlo todo, el que crea tecnologia, es la persona que crea engines o SDKs para que el resto de programadores los usen. Esta gente no usara unity ni udk ni nada de nada porque ellos quieren saberlo todo, controlarlo todo. Solo les interesa la tecnologia, no el fin.

Perfil B: el que usa la tecnologia. Gente que solo quiere usar el SDK tal o cual, o el engine tal o pascual, bien sea por falta de medios o por falta de interes/ganas. Esta gente quiere crear un producto, lease un juego o una app y no quiere perder el tiempo con engines, SDKs ni demas historias, persiguen un fin.

Yo diria aquello de, ¿donde esta el problema?, la "seleccion natural" hara que siempre hayan programadores del tipo A, porque siempre hay quien le pica el gusanillo, y siempre habran del tipo B muchos mas pq al fin y al cabo alguien tiene que hacer el trabajo, usea esa app/juego.

¿Esta bien depender de una tecnologia?, ¿y por que no?, considero que este negocio nuestro es de continuos cambios y siempre vas a estar saltando de novia en novia, no te vas a jubilar trabajando solo en C++ (segun en que circulos te muevas) por ejemplo ahora esta de moda iOS (ya se que no es nuevo, pero permitidme la licencia), asi que como programador si quiero encontrar un trabajo me tengo que aprender Obj-C y dedicarme a hacer apps/juegos pues es lo que las compañias buscan a dia de hoy.
Dentro de unos años cuando pase el boom de iOS pues me tocara evaluar que esta de moda y aprender esa herramienta/SDK y saltar a un nuevo trabajo donde haga lo mismo que antes pero con otra tecnologia.

Yo pienso que con la rapida absorcion de la tecnologia el problema es que las nuevas generaciones no aprenden la base, es decir el problema para mi no esta en usar unity o corona o udk o flash, si no en no entender la base y como funciona un engine por dentro. Yo siempre les digo a los nuevos que hagan juegos en C/C++ con la libreria SDL y se creen su propio engine2D con dicha libreria para entender la base, y luego ya daran el salto a unity o similares, pero como los jovenes son impacientes se van directos a unity que les da resultados rapidos, ergo no tienen ni zorra de como funciona algo por debajo, de como se cargan assets, de porque se estan cargando, de como se dibujan cosas en pantalla, de como te las apañas para gestionar tu escena con tus managers, etc.


Considero que tengo la inmensa suerte de haber aprendido lo basico, ni engines ni historias, juegos en C+SDL a pelo sin nada mas, a crearme mi propia libreria/engine para hacer mis juegos, aprender cosas de optimizacion tan basicas como pools, tiles, spritesheets, entender como funciona la logica interna y saber porque se actualiza todo en pantalla, como gestiono los assets. Todo esto hace que ahora al usar un engine entienda mucho de lo que pasa por debajo (dado que no hay codigo fuente los engine son black boxes y no sabemos lo que pasa) y me permita sentirme comodo sabiendo que no es magia lo que ocurre porque entiendo los procesos internos.

Ahora mismo como programador del tipo B (mas que nada porque no me gusta trastear demasiado), estoy atado a unity3d porque cumple mis expectativas, dentro de unos años saldra el engine "fulanito" y dare el salto a ese, y luego al otro y etc, etc.
A dia de hoy cada vez son menos las empresas que trabajan con tecnologia propia y menos aun si son pequeñas, pues mantener un engine es tiempo, dinero y recursos muy escasos. Al mismo tiempo cada vez mas las nuevas tecnologias se separan mas de C++, todo son engines en C#, javascript, lua, (y otros lenguajes inventados propios) pero ninguno que use C++ como arma principal y por engines me refiero a engines 3D, ya se que cocos2dX funciona con C++ (y se que esta ogre3d), con lo que es dificil aprender/mantener los conocimientos de C++ aprendidos años atras.


¿Que opinais?, ¿somos mala gente los del tipo B por usar unity y similares? :P

[AgeR]

El problema no es ser de tipo A o B.

Por ejemplo Eskema, ahora mismo no eres lo que entiendo yo por tipo B, eres un tipo A que también sabe usar lo que usa un tipo B, pero que tienes los conocimientos básicos que hay por debajo de un juego. Sabes de renderizado, de ordenación, de gestión y carga de recursos...

Un programador tipo B estándar de hoy en día, solo sabe que le tira modelos directamente desde el Max y el Unity (por ejemplo) ya se apaña. Sabe añadir objetos a la escena y manipularlos, sabe hacer scripts más o menos complejos y sí, va a saber hacer un juego.

Ahora, ponle a hacer un plugin para Unity porque el juego requiere tal o cual feature y el Unity no la lleva de serie ni la encuentras en el Asset Store. Salvo que sea un tío del tipo A, estoy casi convencido al 100% que no sabría hacerlo.

O imagina que el cliente quiere un juego para consola (aunque dentro de nada estará Unity para casi todas las consolas también), además de iOS y Android.

Yo creo que es muy peligroso no aprender la base primero, porque un programador de tipo B seguramente no le sacará todo el partido a ningún motor si no tiene clara la base. Va a generar código poco óptimo y va a desaprovechar recursos del sistema.

Me parece muy normal el caso de Eskema, conocer A y B y elegir según el proyecto o el momento. El problema es que últimemente, se ven cada vez menos programadores A, y pasar de A a B es mucho más fácil que pasar de B a A.

Pero, como ya digo, es mi opinión.

[Eskema]

Las opiniones cuantas mas mejor, se aprende muchisimo escuchando las necesidades de los demas y sabiendo porque usan tal o cual :)

Ahi esta tambien el asunto de ver cada empresa/particular que necesidades tiene, por ejemplo no tengo ni zorra de java/android, asi que como dices, si toca hacer un plugin, o esta en la assets store (hablando de unity), o yo no se hacer ese plugin porque no he tocado android en la vida. Como dices si que sabria hacerlo en obj-c/ios, pero por vagancia si el plugin esta lo compro antes que hacerlo yo... lo sé, soy un vago.

A dia de hoy por ejemplo me encantaria usar un engine en C++, hace años que no lo toco el lenguaje y me gustaria hacer algo con eso, volver a manejar la memoria yo mismo (estoy hasta las narices del garbage collector de C#), y tocar un poco cosas "nativas" en plan toquetear un poco el gestor de assets, pero no veo nada que haga tilin para hacer un proyecto (no me gusta ogre3d).

Pero desde luego coincido contigo Ager en que es mas facil pasar de A a B, que de B a A

Aunque tambien depende un poco de la empresa, siempre se tiende a querer contratar gente con un perfil amplio mas que uno especifico, por ejemplo, ¿porque no usar ese programador B y tu te encargas del plugin?, el se encarga de su tarea especifica y tu rematas el trabajo.
Ojo como empresario se que obviamente no nos sobra la pasta para contratar a una persona que solo haga el juego, pero vamos que perfil como tal no lo veo mal, el hace una cosa, mientras la haga bien... cuando no lo necesite a la calle y a por otra persona. ¿no?

[AgeR]

Es que un programador exclusivamente B creo que no tiene lo necesario para llegar a senior, además de estar muy limitado.

Para una empresa pequeña creo que vale la pena fichar a alguien que conozca la base, aunque ahora se centre en Unity o cualquier otro motor de alto nivel. Nunca sabes lo que te va a pedir un cliente, ni si vas a estar más o menos ocupado para poder hacer las tareas que no sepa hacer el programador B.

Luego están los SDK de Ads, analytics, offerwalls y demás que te puede pedir el cliente y que tienes que integrar en el proyecto y que, salvo que haya plugins ya hechos, te va a tocar integrar.

Vamos, que me parece interesante conocer lo que no se ve y como dices, la gestión de memoria me parece algo crítico el poder controlarla a tu antojo.

De todos modos, sí que es cierto que depende del perfil de la empresa y el enfoque que lleve. En nuestro caso ahora mismo estamos orientados a móviles y tablets, pero estamos intentando dar el salto a PC y consolas, y sobre todo en consolas, conocer la máquina a bajo nivel es imprescindible.

También decir que el motor que usamos ya lo tenemos bastante trillado a base de proyectos, con herramientas, exportadores y demás.

Y por último, si un cliente nos pide algo en Unity3D pues se hace. De hecho alguna cosa hemos hecho. Pero prefiero tener esa opción, de elegir qué usar dependiendo del proyecto.

Luego está el tema de las licencias Pro + Android + iOS, que van por puesto, y si facturas más de $100k y tienes varios puestos te puedes llevar una sorpresa al sumar. Obviamente, para alguien freelance Unity me parece una opción perfecta. La mejor, de hecho.

[zunou]

Un tema complicado, yo creo que hoy en día Unity es una opción muy a tener en cuenta muchas empresas lo usan y hay demanda de gente que sepa usarlo. Cada vez cuesta mas hacer videojuegos, y los motores comerciales van a salir hasta de debajo de las piedras, XD pero claro, también tiene que haber gente que programe esos motores.

Personalmente el principal problema que yo le veo a usar Unity o cualquier otro motor comercial, es que dependes de ellos, y estas empresas deciden lo que puedes o no puedes hacer, tal vez quieras hacer algo para x plataforma, pero no exista una versión del motor para ella, o tal vez exista pero tengas que pagar otra vez por usarla... Unity por ejemplo tiene dos versiones en algunas plataformas, una pro de pago y una "Lite" gratis eso ya te limita, o pagas o solo podrás hacer x cosas.

Desde mi punto de vista, usar por ejemplo C++, OpenGL, SDL, etc... te da mucha más libertad que lo anterior, aparte raro es el sistema que no los soporta, y lo mejor, es siempre gratis XD aunque cuesta mas dominarlo eso si XD

Dicho esto no creo que sea mejor o peor usar Unity o el modo tradicional, aunque si es verdad que si quieres dedicarte a la programación de videojuegos, conocer el modo tradicional es muy recomendable porque sigue teniendo mucho peso y suele ser lo que más se pide realmente.

Al final es lo de siempre, si solo sabes c++, poco vas a hacer, necesitas conocer otros lenguajes, conocer OpenGL, SDL.... Unity, UDK... contra más mejor XD

[Fanakito]

El otro día leia un post en el blog de Aras Pranckevičius http://aras-p.info/blog/2013/08/30/on-having-an-ambitious-vision/ donde decía que el objetivo de Unity era convertirse en el motor para cualquier desarrollo. No cabe duda que, cada vez más, estan cerca de conseguirlo.

Y, aunque esto sea así, y que Unity sea el motor más adecuado para tu proyecto, yo creo que los skills que le concedeis al programador "manitas" son muy necesarios para desarrollar profesionalmente juegos. Uno puede aprender a manejarse con Unity y, muy posiblemente, puedas hacer cosas bastante chulas scripteando y arrastrando desde Max pero no he conocido a nadie capaz de desarrollar profesionalmente en Unity que no sea, un "manitas" o un diseñador (y en este caso lo que les gusta es la capacidad de prototipar).

Desarrollar juegos va más allá de hacer el Lunar Lander o el tutorial que encuentres. Incluso aunque encuentres todos los plugins en la Asset Store vas a tener que leer y entender la documentación. Ahora no lo encuentro pero recuerdo que un tio que vendía un motor de voxels en la asset store acabo muy quemado con las peticiones de soporte de su plugin. Sospecho que la mayoría de plugins de la asset store tienen un "soporte" limitado y te toca o forear o depurar tu problema y ese skill no es tan diferente del que se espera de un programador.

Quizás es que como yo vengo por el camino "clásico" no entiendo/conozco la nueva generación de usuarios de Unity que no saben programar (que podría ser). Ahora, si concibo al perfil "B" que comentáis como el programador que usa Unity pero no creo que sea vagancia, sino porque su objetivo es terminar un proyecto no aprender shaders o sobre BSPs. Creo que el perfil "B" es el de la gente que tiene más ese punto indie o de diseñador frente al perfil del programador más puro que lo que le preocupa/gusta es la tecnología.

[Hechelion]

Si me permiten, voy a agregar algo al tema, pero desde otra perspectiva.

Mi formación es más electrónica que de programación (que solo tengo los cursos básicos, el resto, es autodidacta) y mi trabajo principal hasta hace pocos años consistía en trabajar directo sobre el hardware, soy de los que puede hacer una calculadora usando solo puertas lógicas, en otras palabras cuando en C se escribe
variable3=variable2+variable1;
Se la "base" que hay por debajo y que permite que eso funcione y la misma discusión que hay ahora, la vi antes, pero con otros actores.
Donde estaba la gente que sabía la base y por el otro lado, la gente que simplemente usaba C para programar los microcontroladores de una marca en particular (Los PIC, por ejemplo). Hoy en día, cualquier programador podría aprender en poco tiempo a hacer desarrollos con estos equipos sin conocer nada de la base y si lo pensamos es exactamente el mismo escenario que se discute más arriba, con la salvedad que este escenario es más antiguo.

La tecnología cambia de forma rápida y cada vez se hace más difícil meter las manos en las partes internas de los diferentes sistemas que usamos (modificar la base), hace 50 años, se podía reparar o crear una radio desde 0, hoy en día, si un equipo moderno falla, no se repara (en parte, debido a la miniaturización de los componentes) se reemplaza la parte que falló y listo.
Por ejemplo, en un taller de reparación de PC, no necesitar tener 10 ingenieros electrónicos que conozcan la base de como funciona dicho ingenio, necesitas 9 técnicos que puedan cambiar partes y con suerte, 1 que sepa la base y pueda supervisar al resto en caso de necesidad.

Cuando hablan de la especialización del programados A y B, veo exactamente lo mismo (salvando las diferencias), por un lado tienes una persona que conoce una base (que para mi, siempre es importante tenerla) y que es capaz de hacer desarrollos desde 0, y por el otro, tienes a alguien que simplemente sabe usar un programa determinado para ensamblar cosas y obtener el resultado deseado, el problema es que el mercado y el avance tecnológico te lleva hacía eso, si eres una empresa que necesita crear juegos, quieres gente que haga juegos, no que sepa hacer motores, tal vez, en algún momento necesite hacer un plugin especial y es en ese momento donde necesitas a alguien con conocimientos profundos del tema, el problema, es que será una de cada 10 veces, por lo cual realmente no necesitas que los 10 programadores cumplan con el perfil A.

Personalmente creo que el perfil A es mejor por que mientras más conozcas, más fácil es adaptarte a nuevas tecnologías o modificar las existentes, pero tampoco hay que negar, que alguien que sea del perfil B le será más fácil aprender la base, que aprenderla de 0 y esto, como les comentaba, no es algo nuevo, ya ha pasado y nos guste o no, la tecnología nos lleva cada vez más a tener más gente del perfil B que del A. Lo bueno de esto, es que cuando se necesita a alguien que sepa más, puedes cobrar lo que vales.

[Vicente]

El problema para mi es la definición de manitas, porque sinceramente el programador B se va a hacer el plugin en Unity si lo necesita antes o después, y para eso no hace falta que el tio fuera capaz de hacerse un engine entero de arriba a abajo...

[Eskema]

Este es un tema largo y espinoso :)

Yo casi que diria que es un problema de pasta (ahhh el querido dinero....), es decir, las empresas suelen ser pequeñas/modestas, y no pueden permitirse tener varios perfiles, con lo que no puede permitirse tener un tio B y le conviene mas tener tios A para que puedan hacer de todo en un momento dado.

Yo como programador A/B cada dia abandono mas la parte A sobre todo porque cuando trabajas como freelance la gente te viene con requisitos especificos, "queremos este juego en unity3d/cocos2d", asi que tus herramientas o tu engine te los puedes meter por donde te quepan xD

Tampoco hay herramientas que te permitan trastear mucho en los lenguajes base, lease C++, unity por ejemplo es cerrado, asi que darle un vistazo al codigo del engine y cambiar cosas a tu antojo queda descartado, con lo cual te vas olvidando de esa base y te vas moviendo mas al area B.

[Gallo]

Madre mia, es muy dificil ser objetivo con este tema. Comento que mencionais mucho lo de que no hay motores que te permitan trabajar con C++ pero CryEngine 3 y Unreal 4 van con C++, en Unreal 4 ya no hay unreal script. En cuanto a programación gráfica Unity Pro te permite experimentar bastante, pero Unity normal prácticamente nada.

Usar herramientas como Unity o Unreal puede volverse necesario por temas de tiempo o por ejemplo como medio para prototipar una idea para luego implementarla en motor propio. Yo me podría considerar mayormente programador del tipo A, y lo bueno de ser A es que el conocimiento de lo que hay detrás hace que uses herramientas como Unity o Unreal mucho mejor, sabes lo que está pasando ahí debajo, esto pasa con cualquier libreria o SDK, cuanto mas "mágico" sea para ti lo que hace, mas posibilidades de utilizarlo mal tienes, un motor debería ser un medio para ahorrar tiempo y no para enviar monos a hacer una exploración espacial, solo por que puedan sentarse en  el transbordador. Te puedes adaptar a cualquier herramienta y en el momento dado puedes desarrollar tu mismo una parte o desde 0 aquello que necesitas. En resumen, el programador A es mejor programador de Unity que el B pese a no haberse especializado, aunque cuando pueda, intentará prescindir de esas herramientas.

Ante ayer mismo charlando con otro programador muy fan de Unity, contestando a que Unreal 4 utilizaba C++, me comentó que lo de utilizar C++ para hacer videojuegos le parecía volver hacia atras, frenar la evolución, que habiendo lenguajes como C#, el C++ quedaba obsoleto. Me sorprendió mucho esta frase viniendo de alguien que vive de esto, obviamente estoy totalmente en desacuerdo, claro que en su trabajo diario no usará C++, y que se alegra de no tener que volver a usar ese engorroso lenguaje del que le examinaban en la carrera, pero si un día quiere cambiarse a una empresa donde no usen Unity creo que lo tiene jodido, y que probablemente no entiende la mitad de cosas que están pasando en Unity durante su ejecución.

Lo de Unity ciertamente da un poco de miedo, es normal que algunos estudios apuesten por el motor para agilizar el desarrollo, Blizzard mismo lo ha estado usando para su próximo juego, el Hearthstone, me puede parecer normal, pero no hay que cerrarse y decir "es el mejor motor" o "la herramienta definitiva", quitando HST que en realidad es 3D, no puedo entender como se ha hecho tan popular para hacer juegos 2D cuando ni siquiera estaba diseñado para ello hasta su versión mas reciente.

En fins, veremos como evoluciona esto, probablemente haga mas grande el abismo entre programadores que se limitan a crear la lógica del juego y programadores que crean la tecnología, por que para hacer juegos ya no hace falta ser un manitas, lo cual, degrada la profesión y hace que se ofrezcan salarios mas bajos. Miedo tengo que la famosa frase de "la web me la hace mi sobrino de 15 años" pase a ser "el juego nos lo hace mi sobrino de 15 años", por que vamos por el mismo camino.

[Eskema]

Bieeen Gallo, un comentario muy interesante :)

Yo me quejo de la falta de motores con C++ por una sencilla razon, a dia de hoy SOLO me interesan los moviles, el mercado del pc/mac/linux en este preciso momento no me interesa lo mas minimo. Cryengine no vale para moviles (creo recordar), y unreal 4 acaba de salir y no se como anda, pero ¿vale para indies?, se que la version actual de UDK soporta iOS, pero android ya tienes que meterte en una licencia de las gordas.

Ergo, para "solitarios" como yo, es decir NO para una empresa y queriendo hacer cosas para moviles, ¿que motor hay en C++?. Yo no encuentro nada tan completo como unity, y ahi me he quedado, a la espera de algun otro engine con su editor visual que me haga dar el salto.

Yo tambien comparto ese miedo, no ya por el abismo entre programador A y B, que no lo veo demasiado mal, son 2 perfiles que pueden co-existir perfectamente, yo me encargo de la logica y si neceisto algo del motor te lo pido a ti que eres el del departamento de tecnologia, no veo porque tengo que ser el manitas que lo maneja todo, zapatero a tus zapatos, tu cacharreas pues meteme el oclusion culling en el engine.

Mi miedo es porque cada dia es mas facil hacer un juego, tienes cocos2d, corona, phonegap, unity, etc con las que haces un juego sin tener ni zorra de lo que hay por debajo y visto lo visto vamos a ese "mi sobrino hace el juego ese en 2 tardes, te pago 500€ y lo haces tu", bueno no vamos a eso, eso ya pasa, en las webs de freelances todo son ofertas de ese palo, juego X por 300-500€, porque total eso en un plis lo haces.



UPDATEO: para decir que he visto la web de unreal y unreal 4 NO se puede poner en ninguna lista a dia de hoy, salvo que seas empresa y con pasta para licencias, vamos que no es como UDK que es "gratis". Asi que para los que curran solos como yo a dia de hoy sigue sin haber nada mejor que unity o tan completo

[Hans]

Un programador tipo A puede hacer el trabajo del B, al revés difícilmente, por no decir imposible. Para mi Unity fue cosa de 1 día, porque todo me sonaba y me parecía obvio, porque era básicamente todo lo que llevo usando a pelo en C++ con Ogre durante años pero enfocado a click and drag.

Para mi un programador Tipo B pocas veces me parece un programador de verdad. No es por ser clasista pero lo veo más cerca de un maquetador de webs que de otra cosa, aunque está claro que hay de todo.

De todas formas para hacer cosas avanzadas en Unity y hacerlas bien hace falta programar scripts decentes, incluyendo herencias y mil polladas (al menos como lo hago yo, usando C#). Usar la enésima plantilla de "personaje que salta" es muy fácil, extender el código para que haga otras cosas requiere saber lo que se hace.

[Vicente]

En fins, veremos como evoluciona esto, probablemente haga mas grande el abismo entre programadores que se limitan a crear la lógica del juego y programadores que crean la tecnología, por que para hacer juegos ya no hace falta ser un manitas, lo cual, degrada la profesión y hace que se ofrezcan salarios mas bajos. Miedo tengo que la famosa frase de "la web me la hace mi sobrino de 15 años" pase a ser "el juego nos lo hace mi sobrino de 15 años", por que vamos por el mismo camino.

Esto no tiene ni pies ni cabeza. El salario de un crack de C++ de videojuegos ha sido siempre más bajo que el programador de gestion de banco de VB6. El problema de los salarios en la industria del videojuego no es el lenguaje ni la preparación, es que en general son unos cutres.

[Eskema]

Y eso es bien triste Vicente, porque en general programar un juego es mucho mas duro que estar en el banco tocandose las narices para una cutre-app de gestion.
Lo de cutre no lo digo por desprestigiar, si no por el hecho de que en un juego te suelen exigir hechar muchas horas y el nivel de complicacion suele ser mucho mayor.

[[EX3]]

Y eso es bien triste Vicente, porque en general programar un juego es mucho mas duro que estar en el banco tocandose las narices para una cutre-app de gestion.
Lo de cutre no lo digo por desprestigiar, si no por el hecho de que en un juego te suelen exigir hechar muchas horas y el nivel de complicacion suele ser mucho mayor.

Tampoco generalicemos ni hablemos de lo que no sabemos, por favor. Yo vengo del mundo de la banca y te puedo asegurar, y más como están las cosas en este país (el banco te escatima en licencias de tecnología y demás herramientas adecuadas para tu trabajo critico), que en mi experiencia, a veces considero más complicado y duro el trabajo de desarrollar aplicaciones de banca que el de juegos, y lo dice alguien que entra en el perfil de programador A desde hace más de 10 años, y quien me conoce sabe que es cierto, en cuanto a hacerse sus propios motores y frameworks, y pasar hasta ultima hora de cosas como Unity3D o similares.

En fin, ya quisiera a muchos ver ponerse al frente de aplicaciones criticas para gestión de bolsa o conexión de datos entre bancos de distintos países mediante Murex o cualquiera de los desarrollos que se mueven a nivel internacional en la red exterior de BBVA como en los que he trabajado, a ver si es cierta esa afirmación de que en banca te tocas las narices respecto a juegos. Ni hacer banca o gestion es fácil ni hacer juegos es más difícil, y te puedo asegurar que echas tantas horas o más en uno que en otro.

Salu2...