Después de 100 episodios, yo creo que ha llegado el momento de poner punto final a este podcast que, justo coincide con el final del año y en un número bonito y redondo: el 100. Así que, ha llegado el momento de acabarlo. Este, es el primer podcast que hago y la verdad es que estoy muy contento con él. Con el feedback que me ha ido llegando, creo que he podido solucionar muchas preguntas que hay sobre el mundo de las aplicaciones móviles. Con que haya resuelto un par de dudas, la verdad me doy por satisfecho. Sí que es verdad que podría continuar con él y hablar de algunos temas que quedaron pendientes, pero creo que es un bueno momento para acabar, básicamente por dos motivos. Por un lado, he cubierto las principales dudas o preguntas que se pueden tener sobre el desarrollo de aplicaciones móviles y, no quiero entrar en temas que no serían de mucho interés; tampoco quisiera duplicar contenido y repetir cosas ya explicadas. Por otro lado, me apetece hacer cosas diferentes. Me encanta la programación de aplicaciones móviles y es algo que voy a hacer siempre y por mucho tiempo. Sin embargo, quiero cambiar este podcast por otra cosa. Sin lugar a dudas, me gusta hacer otras cosas relacionadas con la programación y que no estén relacionadas con la programación. Es como un periodo de descanso para mí y muy necesario si eres programador. No es viable hacerlo más de 8 horas del día, siendo productivo al 100%. Algunos de vosotros, a lo largo del podcast, me han sugerido hacer algún tipo de cursos o libro con todos los temas de interés y ordenados. Aun no estoy seguro por que me voy a decantar, pero algo nuevo voy a hacer de cara a este 2019; obviamente parado, no me voy a quedar. Para acabar, gracias por estar ahí y escucharme; así como por el feedback que me ha ido llegando, lo que me ha animado a continuar todos los días. The post 100. Continuará… appeared first on Diego Laballós.

Después de 100 episodios, yo creo que ha llegado el momento de poner punto final a este podcast que, justo coincide con el final del año y en un número bonito y redondo: el 100. Así que, ha llegado el momento de acabarlo. Este, es el primer podcast que hago y la verdad es que estoy muy contento con él. Con el feedback que me ha ido llegando, creo que he podido solucionar muchas preguntas que hay sobre el mundo de las aplicaciones móviles. Con que haya resuelto un par de dudas, la verdad me doy por satisfecho. Sí que es verdad que podría continuar con él y hablar de algunos temas que quedaron pendientes, pero creo que es un bueno momento para acabar, básicamente por dos motivos. Por un lado, he cubierto las principales dudas o preguntas que se pueden tener sobre el desarrollo de aplicaciones móviles y, no quiero entrar en temas que no serían de mucho interés; tampoco quisiera duplicar contenido y repetir cosas ya explicadas. Por otro lado, me apetece hacer cosas diferentes. Me encanta la programación de aplicaciones móviles y es algo que voy a hacer siempre y por mucho tiempo. Sin embargo, quiero cambiar este podcast por otra cosa. Sin lugar a dudas, me gusta hacer otras cosas relacionadas con la programación y que no estén relacionadas con la programación. Es como un periodo de descanso para mí y muy necesario si eres programador. No es viable hacerlo más de 8 horas del día, siendo productivo al 100%. Algunos de vosotros, a lo largo del podcast, me han sugerido hacer algún tipo de cursos o libro con todos los temas de interés y ordenados. Aun no estoy seguro por que me voy a decantar, pero algo nuevo voy a hacer de cara a este 2019; obviamente parado, no me voy a quedar. Para acabar, gracias por estar ahí y escucharme; así como por el feedback que me ha ido llegando, lo que me ha animado a continuar todos los días. The post <a href="https://diegolaballos.com/podcast/100-continuara/" rel="nofollow" target="_blank">100. Continuará…</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

100. Continuará…

Cuando tienes una idea debes decidir quién la va a llevar a cabo. Esto es muy importante ya que, seguramente estés muy motivado, te juegues bastante y quieres que todo salga bien. Evidentemente si ya tienes un proyecto, lo has pensado y ya estás imaginando cómo llevarlo a cabo, es muy importante elegir correctamente el tipo de persona que lo llevará a la luz. Aquí, por normal general, tenemos dos opciones: un freelancer o una empresa. Ambos tienen sus pros y sus contras. Evidentemente, mi opinión está un poco condicionada, ¿Por qué negarlo? Pero, voy a intentar ser lo más objetivo posible. De hecho, cuando voy a grabar un episodio, lo que hago es ordenar todos los puntos y mis ideas; después, acudo a internet a consultar otros blogs o recursos para ver qué dicen sobre el tema. Sobre todo, para ver si me he olvidado de algún punto importante, tengo que añadir o matizar cosas, etc.; en fin, para complementar todas mis ideas e información que quiero transmitir. El caso es que, en esta ocasión ha ocurrido algo curioso. Cuando iba a mirar la comparación entre freelancer y empresas, he encontrado que, dependiendo de la fuente, los puntos a favor y en contra eran totalmente distintos. Por ejemplo, si leía un blog de una empresa de desarrollo de software, me daba cuenta que mostraban muchos puntos a favor, y muy pocos en contra. Por otra parte, si me iba a una fuente contraria de algún freelancer o una persona no tan a favor de las empresas de software, me encontraba con todo lo contrario. Todo es muy subjetivo y todo depende; esta es la conclusión a la que he llegado. Todo depende de qué empresa y qué freelancer elijas. No se pueden concretar ni generalizar ciertos puntos a favor de un lado o del otro porque depende. Por ejemplo, en cuanto a la comunicación, había blogs que por un lado decían que esta era mejor de lado de la empresa porque el freelancer podría desaparecer de un día para otro o podría no ser tan accesible. Sin embargo, yo considero que la comunicación es mucho más fácil con un freelancer puesto que hablas directamente con la persona encargada del proyecto, y no con intermediarios. Por tanto, no voy a indicar puntos a favor o en contra, como he hecho en otros episodios, sino que voy a comentar los principales puntos y utilizaré muchos condicionales porque depende, todo depende. 1. Coste Por normal general, podríamos decir que las empresas tienen costes superiores por diversas razones. Una empresa está constituida por una serie de socios que quieren generar beneficios económicos, lo cual no es ningún descubrimiento. Para ello, necesitan personal y más infraestructura que un freelancer; todo esto tiene costes que se repercuten en los proyectos. Después de que se han cubierto los costes dentro de un proyecto, se añade el beneficio que genera la empresa. Por otra parte, un freelancer tiene menos costes fijos y seguramente, lo único que tiene que pagar es su propio sueldo que, quizás sería más alto que un trabajador de una empresa. Esto explica porque, por normal general, es más alto el presupuesto de una empresa que el de una persona individual. Dicho esto, también puede darse el caso de que un freelancer, cobre más que una empresa; es obvio. Quizás porque su coste por hora sea elevado, por la experiencia, por sus saber-hacer, pero no es una normal que se cumpla siempre. 2. Comunicación En proyectos de programación, es muy importante la comunicación. Es importante que sea fluida, fácil de llevarse a cabo y constante. Si la comunicación falla, es muy probable que el proyecto no salga como debería salir. Si lo miramos desde el punto de vista de una empresa, podríamos decir que hay un inconveniente principal: la comunicación no suele ser tan directa y no hablas directamente con la persona que está in situ trabajando en tu proyecto (programador, diseñador, etc.). Te comunicas con un intermediario. Esto, hace que la comunicación sea menos fluida cuando contratas una empresa. Por otra parte, puede ser que sea difícil contactar con un freelancer. Depende de cómo organice su tiempo y como atienda a las personas con las que trabaja. Una vez más, todo depende. Puede ser que haya empresas que tengan una comunicación perfecta, y otras que sean un caos. De la misma manera, puede que haya freelancers con quienes sea una odisea poder contactarlos; y, otros con quienes sea muy sencillo. Quizás, en el caso de los freelancers, un punto a tener en cuenta, es elegir bien a esa persona; que hable tu idioma o uno que ambos manejen; o, que esté dentro de tu misma zona horaria. Esto último es muy importante. Imagina que contratas a alguien que está al otro lado del mundo; alguien que está durmiendo cuando tu estás trabajando y trabajando cuando tu estás durmiendo. No es que sea algo que debas evitar a toda costa pues se puede trabajar perfectamente bien así, pero considera que la comunicación es más lenta así. No es más que un punto a tomar en cuenta a la hora de contratar un freelancer. 3. La especialización Esto consiste en saber hacer algo en concreto; únicamente algo en concreto, pero hacerlo bien. Esto se traduce en saber más de tu campo, estar más al día, ser más productivo, etc. Un ejemplo puede ser una empresa o freelancer que solo se dedica al desarrollo de aplicaciones móviles y nada más.  Como en todos los puntos, esto depende: puede haber empresas especializadas o freelancers especializados. Asimismo, pueden existir empresas generalistas y freelancers generalistas. En mi opinión, por norma general, la especialización es mejor que alguien generalista. Pero claro, debes ver que encaje dentro de lo que buscas. Quizás hay ciertos momentos o proyectos en donde es mejor tratar con una empresa / freelancer generalista; que “toque muchos palos” porque lo necesitas así. Si, por ejemplo, quieres desarrollar una sola app, sería bueno que busques una empresa / freelancer especializado en el desarrollo de apps, en vez de contactar a alguien que hace de todo: webs, apps, y programas para Windows y Mac. En mi opinión, es mejor buscar a alguien especializado. Sin embargo, si lo que tu quieres es crear una web o app para Android y luego, una aplicación de escritorio para Windows; en este caso quizás necesites a alguien generalista. Si lo buscas es algo concreto, un freelancer puede encajar en tus preferencias. Pero, si quieres algo más genérico que requiera muchas especializaciones, una empresa con un enfoque más general, te convenga mas ya que tendrán personal con distintos perfiles. 4. La oferta Con este punto, me refiero a la cantidad de empresas o personas que puedes encontrar. Sería difícil decir si hay más empresas o más freelancers para desarrollar ciertos proyectos. En gran medida, dependerá de que quieras hacer y qué tecnología quieras usar. De todas maneras, algo que quiero dejar en claro aquí, es que siempre debes estar en posesión de lo que se desarrolla, ya sea códigos de programación, herramientas, servidores, infraestructura. Si no lo haces, lo que va a pasar es que, al cambiar de persona o empresa, tendrás que lidiar con un caos: una situación de lock in porque solo ellos tienen el código, el servidor o cierta tecnología desarrollada por ellos que no pueden modificar otros. Esto siempre es malo. Siempre tienes que estar en posesión de lo que se haga y todo tiene que estar bien documentado para que, en caso de ser necesario, cualquier otra persona o empresa pueda cambiar el proyecto. Nadie puede retenerte contra tu voluntad y siempre que no estés contento con lo que se hace, tienes que poder cambiarte. 5. Confianza, seguridad y calidad Quería hablar de estos tres aspectos juntos. Podría haberlos separado, pero creo que se pueden resumir en un solo punto: la confianza es la seguridad de que esa persona / empresa va a llevar a cabo el trabajo, y lo hará bien hecho y de calidad; algo que no va a dejar a medias o entregar con mil errores. ¿Por qué todo esto en un solo punto? Porque es algo muy relativo y aunque sí puede existir la sensación de que una empresa es seria, transmite confianza y aporta calidad; muchas veces puede ser falso, en mi opinión. Al fin y al cabo, las empresas son personas. Todos estos aspectos, van a depender de las personas que estén detrás de esa empresa.  Asimismo, en el caso de un freelancer, estos aspectos van a depender de él mismo. Si es una persona profesional, sabe lo que está haciendo y hace bien las cosas, todos estos puntos serán positivos; da igual si es una persona o freelancer. Todo se resume en las personas y al final, tanto freelancer como empresas son personas. La diferencia fundamental es que, con el freelancer tienes un contacto más directo; mientras que, con una empresa, ves al “ente”. Sin embargo, al final, son personas. Personalmente, yo prefiero trabajar con freelancers. Freelancers que transmiten seguridad, confianza y calidad; con quienes sé que obtendré un producto terminado de buena calidad. Es mi opinión. Creo que las personas prefieren trabajar con otras personas directamente. 6. La reputación Este es un punto importante tanto para la empresa como para el freelancer. Ambos quieren que las cosas salgan bien para tener clientes contentos y que esto se traduzca en más clientes. A veces, puede parecer que a un freelancer le dé igual pero no es del todo así. Imagina que encuentras a alguien que trabaja como desarrollador en una empresa y que, además, desarrolla proyectos en sus tiempos libres; o, alguien que tiene un perfil en alguna plataforma de freelancers. En estos casos, quizás la persona puede más fácilmente abandonar un proyecto si ve que se complica o pierde las ganas de hacerlo pues al fin y al cabo no tiene mucho que perder; no tiene una gran reputación que perder. Ahora, imagina un freelancer que lleva ya mucho tiempo trabajando como tal, con una reputación y una gran marca personal; y, que es públicamente accesible en distintos lugares. ¿De verdad crees que no le importa su reputación y, que de un día para otro va a huir?  Le importa más que a una empresa que, mañana podría cambiar su nombre y hacer lo mismo que ha venido haciendo. Si alguien da la cara, y es transparente, seguro tiene una reputación que mantener y eso, le importa. Todo depende, puede ser empresa o puede ser freelancer. The post 99. Freelancer o empresa. ¿A quién elegir para desarrollar una app? appeared first on Diego Laballós.

Cuando tienes una idea debes decidir quién la va a llevar a cabo. Esto es muy importante ya que, seguramente estés muy motivado, te juegues bastante y quieres que todo salga bien. Evidentemente si ya tienes un proyecto, lo has pensado y ya estás imaginando cómo llevarlo a cabo, es muy importante elegir correctamente el tipo de persona que lo llevará a la luz. Aquí, por normal general, tenemos dos opciones: un freelancer o una empresa. Ambos tienen sus pros y sus contras. Evidentemente, mi opinión está un poco condicionada, ¿Por qué negarlo? Pero, voy a intentar ser lo más objetivo posible. De hecho, cuando voy a grabar un episodio, lo que hago es ordenar todos los puntos y mis ideas; después, acudo a internet a consultar otros blogs o recursos para ver qué dicen sobre el tema. Sobre todo, para ver si me he olvidado de algún punto importante, tengo que añadir o matizar cosas, etc.; en fin, para complementar todas mis ideas e información que quiero transmitir. El caso es que, en esta ocasión ha ocurrido algo curioso. Cuando iba a mirar la comparación entre freelancer y empresas, he encontrado que, dependiendo de la fuente, los puntos a favor y en contra eran totalmente distintos. Por ejemplo, si leía un blog de una empresa de desarrollo de software, me daba cuenta que mostraban muchos puntos a favor, y muy pocos en contra. Por otra parte, si me iba a una fuente contraria de algún freelancer o una persona no tan a favor de las empresas de software, me encontraba con todo lo contrario. Todo es muy subjetivo y todo depende; esta es la conclusión a la que he llegado. Todo depende de qué empresa y qué freelancer elijas. No se pueden concretar ni generalizar ciertos puntos a favor de un lado o del otro porque depende. Por ejemplo, en cuanto a la comunicación, había blogs que por un lado decían que esta era mejor de lado de la empresa porque el freelancer podría desaparecer de un día para otro o podría no ser tan accesible. Sin embargo, yo considero que la comunicación es mucho más fácil con un freelancer puesto que hablas directamente con la persona encargada del proyecto, y no con intermediarios. Por tanto, no voy a indicar puntos a favor o en contra, como he hecho en otros episodios, sino que voy a comentar los principales puntos y utilizaré muchos condicionales porque depende, todo depende. <h3>1. Coste</h3> Por normal general, podríamos decir que las empresas tienen costes superiores por diversas razones. Una empresa está constituida por una serie de socios que quieren generar beneficios económicos, lo cual no es ningún descubrimiento. Para ello, necesitan personal y más infraestructura que un freelancer; todo esto tiene costes que se repercuten en los proyectos. Después de que se han cubierto los costes dentro de un proyecto, se añade el beneficio que genera la empresa. Por otra parte, un freelancer tiene menos costes fijos y seguramente, lo único que tiene que pagar es su propio sueldo que, quizás sería más alto que un trabajador de una empresa. Esto explica porque, por normal general, es más alto el presupuesto de una empresa que el de una persona individual. Dicho esto, también puede darse el caso de que un freelancer, cobre más que una empresa; es obvio. Quizás porque su coste por hora sea elevado, por la experiencia, por sus saber-hacer, pero no es una normal que se cumpla siempre. <h3>2. Comunicación</h3> En proyectos de programación, es muy importante la comunicación. Es importante que sea fluida, fácil de llevarse a cabo y constante. Si la comunicación falla, es muy probable que el proyecto no salga como debería salir. Si lo miramos desde el punto de vista de una empresa, podríamos decir que hay un inconveniente principal: la comunicación no suele ser tan directa y no hablas directamente con la persona que está in situ trabajando en tu proyecto (programador, diseñador, etc.). Te comunicas con un intermediario. Esto, hace que la comunicación sea menos fluida cuando contratas una empresa. Por otra parte, puede ser que sea difícil contactar con un freelancer. Depende de cómo organice su tiempo y como atienda a las personas con las que trabaja. Una vez más, todo depende. Puede ser que haya empresas que tengan una comunicación perfecta, y otras que sean un caos. De la misma manera, puede que haya freelancers con quienes sea una odisea poder contactarlos; y, otros con quienes sea muy sencillo. Quizás, en el caso de los freelancers, un punto a tener en cuenta, es elegir bien a esa persona; que hable tu idioma o uno que ambos manejen; o, que esté dentro de tu misma zona horaria. Esto último es muy importante. Imagina que contratas a alguien que está al otro lado del mundo; alguien que está durmiendo cuando tu estás trabajando y trabajando cuando tu estás durmiendo. No es que sea algo que debas evitar a toda costa pues se puede trabajar perfectamente bien así, pero considera que la comunicación es más lenta así. No es más que un punto a tomar en cuenta a la hora de contratar un freelancer. <h3>3. La especialización</h3> Esto consiste en saber hacer algo en concreto; únicamente algo en concreto, pero hacerlo bien. Esto se traduce en saber más de tu campo, estar más al día, ser más productivo, etc. Un ejemplo puede ser una empresa o freelancer que solo se dedica al desarrollo de aplicaciones móviles y nada más. Como en todos los puntos, esto depende: puede haber empresas especializadas o freelancers especializados. Asimismo, pueden existir empresas generalistas y freelancers generalistas. En mi opinión, por norma general, la especialización es mejor que alguien generalista. Pero claro, debes ver que encaje dentro de lo que buscas. Quizás hay ciertos momentos o proyectos en donde es mejor tratar con una empresa / freelancer generalista; que “toque muchos palos” porque lo necesitas así. Si, por ejemplo, quieres desarrollar una sola app, sería bueno que busques una empresa / freelancer especializado en el desarrollo de apps, en vez de contactar a alguien que hace de todo: webs, apps, y programas para Windows y Mac. En mi opinión, es mejor buscar a alguien especializado. Sin embargo, si lo que tu quieres es crear una web o app para Android y luego, una aplicación de escritorio para Windows; en este caso quizás necesites a alguien generalista. Si lo buscas es algo concreto, un freelancer puede encajar en tus preferencias. Pero, si quieres algo más genérico que requiera muchas especializaciones, una empresa con un enfoque más general, te convenga mas ya que tendrán personal con distintos perfiles. <h3>4. La oferta</h3> Con este punto, me refiero a la cantidad de empresas o personas que puedes encontrar. Sería difícil decir si hay más empresas o más freelancers para desarrollar ciertos proyectos. En gran medida, dependerá de que quieras hacer y qué tecnología quieras usar. De todas maneras, algo que quiero dejar en claro aquí, es que siempre debes estar en posesión de lo que se desarrolla, ya sea códigos de programación, herramientas, servidores, infraestructura. Si no lo haces, lo que va a pasar es que, al cambiar de persona o empresa, tendrás que lidiar con un caos: una situación de lock in porque solo ellos tienen el código, el servidor o cierta tecnología desarrollada por ellos que no pueden modificar otros. Esto siempre es malo. Siempre tienes que estar en posesión de lo que se haga y todo tiene que estar bien documentado para que, en caso de ser necesario, cualquier otra persona o empresa pueda cambiar el proyecto. Nadie puede retenerte contra tu voluntad y siempre que no estés contento con lo que se hace, tienes que poder cambiarte. <h3>5. Confianza, seguridad y calidad</h3> Quería hablar de estos tres aspectos juntos. Podría haberlos separado, pero creo que se pueden resumir en un solo punto: la confianza es la seguridad de que esa persona / empresa va a llevar a cabo el trabajo, y lo hará bien hecho y de calidad; algo que no va a dejar a medias o entregar con mil errores. ¿Por qué todo esto en un solo punto? Porque es algo muy relativo y aunque sí puede existir la sensación de que una empresa es seria, transmite confianza y aporta calidad; muchas veces puede ser falso, en mi opinión. Al fin y al cabo, las empresas son personas. Todos estos aspectos, van a depender de las personas que estén detrás de esa empresa. Asimismo, en el caso de un freelancer, estos aspectos van a depender de él mismo. Si es una persona profesional, sabe lo que está haciendo y hace bien las cosas, todos estos puntos serán positivos; da igual si es una persona o freelancer. Todo se resume en las personas y al final, tanto freelancer como empresas son personas. La diferencia fundamental es que, con el freelancer tienes un contacto más directo; mientras que, con una empresa, ves al “ente”. Sin embargo, al final, son personas. Personalmente, yo prefiero trabajar con freelancers. Freelancers que transmiten seguridad, confianza y calidad; con quienes sé que obtendré un producto terminado de buena calidad. Es mi opinión. Creo que las personas prefieren trabajar con otras personas directamente. <h3>6. La reputación</h3> Este es un punto importante tanto para la empresa como para el freelancer. Ambos quieren que las cosas salgan bien para tener clientes contentos y que esto se traduzca en más clientes. A veces, puede parecer que a un freelancer le dé igual pero no es del todo así. Imagina que encuentras a alguien que trabaja como desarrollador en una empresa y que, además, desarrolla proyectos en sus tiempos libres; o, alguien que tiene un perfil en alguna plataforma de freelancers. En estos casos, quizás la persona puede más fácilmente abandonar un proyecto si ve que se complica o pierde las ganas de hacerlo pues al fin y al cabo no tiene mucho que perder; no tiene una gran reputación que perder. Ahora, imagina un freelancer que lleva ya mucho tiempo trabajando como tal, con una reputación y una gran marca personal; y, que es públicamente accesible en distintos lugares. ¿De verdad crees que no le importa su reputación y, que de un día para otro va a huir? Le importa más que a una empresa que, mañana podría cambiar su nombre y hacer lo mismo que ha venido haciendo. Si alguien da la cara, y es transparente, seguro tiene una reputación que mantener y eso, le importa. Todo depende, puede ser empresa o puede ser freelancer. The post <a href="https://diegolaballos.com/podcast/99-freelancer-o-empresa-a-quien-elegir-para-desarrollar-una-app/" rel="nofollow" target="_blank">99. Freelancer o empresa. ¿A quién elegir para desarrollar una app?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

99. Freelancer o empresa. ¿A quién elegir para desarrollar una app?

La situación que me planteo en este episodio es la siguiente: un negocio o una persona que tiene una web y quiere llegar al mundo móvil porque sabe la importancia que tiene. En este caso, ¿qué se puede hacer? ¿Web responsive o app móvil? ¿Web responsive o app móvil? Cada vez se consume más Internet, más aplicaciones, más web y más contenido en general desde los móviles en comparación con los ordenadores de toda la vida. Este mercado tiene una importancia muy grande. Así que, lo que se puede plantear esta persona que tiene una web, es si realmente necesita una aplicación móvil nativa, o quizá con una web responsive que se vea bien en estos dispositivos  sea suficiente. Por un lado, la web responsive consiste en adaptar la web existente para que se visualice bien en dispositivos pequeños. Este proceso, básicamente consiste en adaptar los tamaños de las letras, evitar ese scroll lateral de tal forma que sólo haya que ir hacia abajo o hacia arriba; adaptar las imágenes, etc. En fin, colocar todas las imágenes de tal forma que se vea bien en dispositivos móviles con pantallas más pequeñas que las de un ordenador tradicional. Por otro lado, está la aplicación nativa a través de Google Play y App Store, que está desarrollada de forma independiente a la web; es un desarrollo completamente distinto y se hace para aquellos sistemas que se quieran soportar. Es decir, si se quiere Android o iOS; o solo Android o solo iOS. El caso es que es una aplicación nativa independiente de la web. 1. Visibilidad Vamos a ir punto por punto, mirando los pros y los contras de cada una de estas opciones. En primer lugar, está la visibilidad.  En términos de visibilidad podríamos decir las tiendas de aplicaciones ofrecen un nuevo escaparate.  Al fin y al cabo, si tú haces una web responsive, vas a mejorar en cuanto posicionamientos SEO en Google. Quizás tu página aparezca en las mejores posiciones si tu web está optimizada para móviles, que si no lo estuviera. Lo que quiero decir aquí, es que uno no quita al otro. Es decir, yo creo que hoy en día es obligado tener una web responsive ya que gran parte del internet se consume desde los móviles. Y, si no tienes una web responsive, prácticamente no tendrás tráfico de calidad en tu web. Aquí, básicamente estamos hablando de la visibilidad de lo que vienen a ser ambas opciones. Como decía, la web responsiva es básicamente el mismo escaparate: posicionamiento en buscadores y poco más. Sin embargo, las aplicaciones nativas tienen este nuevo escaparate, básicamente es en las tiendas donde las aplicaciones se pueden posicionar a través de los distintos rankings que hay, de las categorías, de las aplicaciones relacionadas. Si tú, por ejemplo, tienes un ecommerce de una tienda de deportes, y alguien se ha descargado la aplicación de Decathlon, que es otra tienda de deportes, tú, sin tener una necesidad de posicionamiento, puedes aparecer en las búsquedas relacionadas de una persona que precisamente está interesada en este tipo de aplicaciones. Así que, este escaparate es nuevo, es completamente distinto y puede atraer a muchos nuevos usuarios. Es un punto muy a favor de las aplicaciones nativas. Sin embargo, hay que dejar en claro que no por subir una app a estas tiendas de aplicaciones va a tener un aluvión de usuarios ni mucho menos. Si tú no promocionas tu aplicación y no lo haces bien, a pesar de que podrías tener descargas de la nada, no serían muchas. No podrás esperar de un aluvión de usuarios, simplemente por subir una app. Al contrario, hay todo un trabajo detrás. Claro está que, si se hace bien, puedes tener muchos usuarios. 2. Accesibilidad Una app nativa es mucho más accesible que una web. En el mundo de la tecnología cada mínima barrera que le pongas al usuario es importante. Y, aunque parezca una tontería tener que ir al navegador, poner la URL de la web y entrar, es un paso de segundos que hay que hacer. Sin embargo, con la aplicación nativa ya tienes un icono que te sale en la pantalla y a través de un clic, ya se abre esa aplicación que quieres y puedes ver el contenido.  Precisamente estos iconos que salen en la pantalla principal, hacen que sea muy accesible y, a menudo actúan como pequeños recordatorios de que la app está ahí; una suerte de «pequeñas campañas de marketing»: no me acordaba que estaba esta aplicación aquí, pero aquí está este logo y voy a entrar a ver que hay quizás consuma lo que me ofrece. Es una forma de recordarte que ese negocio existe y está ahí porque lo ves casi cada día, aunque realmente no lo percibas al 100%, a pesar de que a veces ni nos damos cuenta de que aplicaciones tenemos instaladas; pero sí que nos fijamos y las recordamos. 3. Experiencia de usuario El tercer punto es la experiencia de usuario cuando comparamos una web responsive con una aplicación. La verdad es que las aplicaciones nativas son mucho más rápidas y fluidas que una web, además de ofrecer una mejor experiencia de usuario. Esto es así, porque básicamente la web se carga encima de un navegador y hay que esperar a que llegue el contenido. Las aplicaciones son mucho más rápidas; también tienes que hacer una llamada al servidor y tienes que esperar para ciertas cosas, pero, en términos de la fluidez de la interfaz, es mucho más rápida ya que está creada precisamente para ese dispositivo y ese sistema. Además, puedes acceder sin límite a ciertos sensores del móvil, ofrecer un modo offline, y disfrutar de más fluidez durante la navegación. Todo esto, lleva a que el usuario disfrute más la experiencia y que tenga más posibilidades de implementar ciertas funcionalidades para un negocio determinado. Al fin y al cabo, esto lleva a que el usuario esté más dispuesto a utilizar esta aplicación y por tanto a el producto o servicio que se ofrezca. Siempre que algo es fácil y agradable de utilizar es más propenso que acabe por ser utilizado o comprado. Hay un estudio de Flurry que muestra que el 90% del tiempo que se invierte en los dispositivos móviles se hace en aplicaciones, mientras que tan sólo un 10% se hace en el navegador que tiene integrado el móvil. Así que, esto es una clara muestra de que las aplicaciones son más agradables, fáciles de utilizar y más populares que las webs responsivas. 4. La aplicación nativa es más interactiva El cuarto punto a tener en cuenta es que la aplicación nativa es más interactiva y crea usuarios más leales. Cómo comentaba anteriormente, el icono en la pantalla principal, facilita que un usuario vuelva a entrar a la aplicación. Al fin y al cabo, cuando el usuario la instala, la ve casi cada día en su pantalla principal, aunque la gran mayoría de las veces la vaya a ignorar lo cual, es más que evidente.  Es probable que este icono en medio de la pantalla tenga mucho que ver con esto ya que, una cosa es ver el icono de la pantalla cada día y volver a entrar a utilizar este producto o servicio; y otra, es tener que ir de nuevo al navegador, acordarte de la URL concreta y volver a entrar. Además, no debemos olvidar los de las push notifications que, es una opción de marketing que tienen las aplicaciones nativas y que es muy efectiva. A pesar de que, en mi opinión, esto no es algo que tenga que ser mostrado con estudios, sí que hay algunos que indican que esas notificaciones que recibimos en los móviles, son muchísimo más efectivas que cualquier otra técnica de marketing (emails o SMS). Estos estudios, como media, indican que sobre un 90% de las notificaciones que se envían, se ven; y sobre un 40%, se abren. Son porcentajes muy elevados comparados con otras técnicas como el envío de emails o SMS. La verdad sea dicha, las push notifications también tienen sus restricciones: no las puedes utilizar, así como así, ni tampoco crear campañas de marketing para hacer spam. Pero, bien implementadas pueden ser tremendamente efectivas. A pesar de que en la web también existe la posibilidad, a través de ciertos navegadores, de enviar notificaciones, no tienen nada que ver con las notificaciones de los móviles. 5. Presupuesto  Todo esto nos lleva al quinto y último punto: el presupuesto. Hasta aquí, está muy claro que la aplicación nativa es mucho mejor que una web móvil. Todos los estudios y datos indican que los usuarios prefieren a las aplicaciones que, a las webs responsive, por lo que se crean usuarios más leales que disfrutan más la aplicación y que probablemente acaben gastando más en nuestro producto o servicio. Sin embargo, ¿cuál es el problema? Precisamente el coste y tiempo de desarrollo. Una web móvil responsive es sencilla de implementar. De hecho, la gran mayoría de tecnologías web lo llevan incluido por defecto, como los grandes CMS. Aunque se tenga que desarrollar algo, no tiene un gran coste. Simplemente hay que adaptar unas cuantas cosas que llevaría unos cuantos días de desarrollo.  Por otro lado, las apps tienen un coste de desarrollo muy elevado en comparación con estas webs responsive. Por tanto, llega el momento en el que hay de que decidir si realmente vale la pena y pueda haber un retorno real de esa inversión. Es probable que en cuanto más grande sea el negocio más retorno puede haber. Sin embargo, ahora con tecnologías como Flutter, también hay que decir que pueden hacerse apps menos costosas sin afectar su calidad. The post 98. ¿Aplicación o web responsive? ¿Cuál elegir? appeared first on Diego Laballós.

La situación que me planteo en este episodio es la siguiente: un negocio o una persona que tiene una web y quiere llegar al mundo móvil porque sabe la importancia que tiene. En este caso, ¿qué se puede hacer? ¿Web responsive o app móvil? <h3>¿Web responsive o app móvil?</h3> Cada vez se consume más Internet, más aplicaciones, más web y más contenido en general desde los móviles en comparación con los ordenadores de toda la vida. Este mercado tiene una importancia muy grande. Así que, lo que se puede plantear esta persona que tiene una web, es si realmente necesita una aplicación móvil nativa, o quizá con una web responsive que se vea bien en estos dispositivos sea suficiente. Por un lado, la web responsive consiste en adaptar la web existente para que se visualice bien en dispositivos pequeños. Este proceso, básicamente consiste en adaptar los tamaños de las letras, evitar ese scroll lateral de tal forma que sólo haya que ir hacia abajo o hacia arriba; adaptar las imágenes, etc. En fin, colocar todas las imágenes de tal forma que se vea bien en dispositivos móviles con pantallas más pequeñas que las de un ordenador tradicional. Por otro lado, está la aplicación nativa a través de Google Play y App Store, que está desarrollada de forma independiente a la web; es un desarrollo completamente distinto y se hace para aquellos sistemas que se quieran soportar. Es decir, si se quiere Android o iOS; o solo Android o solo iOS. El caso es que es una aplicación nativa independiente de la web. <h3>1. Visibilidad</h3> Vamos a ir punto por punto, mirando los pros y los contras de cada una de estas opciones. En primer lugar, está la visibilidad. En términos de visibilidad podríamos decir las tiendas de aplicaciones ofrecen un nuevo escaparate. Al fin y al cabo, si tú haces una web responsive, vas a mejorar en cuanto posicionamientos SEO en Google. Quizás tu página aparezca en las mejores posiciones si tu web está optimizada para móviles, que si no lo estuviera. Lo que quiero decir aquí, es que uno no quita al otro. Es decir, yo creo que hoy en día es obligado tener una web responsive ya que gran parte del internet se consume desde los móviles. Y, si no tienes una web responsive, prácticamente no tendrás tráfico de calidad en tu web. Aquí, básicamente estamos hablando de la visibilidad de lo que vienen a ser ambas opciones. Como decía, la web responsiva es básicamente el mismo escaparate: posicionamiento en buscadores y poco más. Sin embargo, las aplicaciones nativas tienen este nuevo escaparate, básicamente es en las tiendas donde las aplicaciones se pueden posicionar a través de los distintos rankings que hay, de las categorías, de las aplicaciones relacionadas. Si tú, por ejemplo, tienes un ecommerce de una tienda de deportes, y alguien se ha descargado la aplicación de Decathlon, que es otra tienda de deportes, tú, sin tener una necesidad de posicionamiento, puedes aparecer en las búsquedas relacionadas de una persona que precisamente está interesada en este tipo de aplicaciones. Así que, este escaparate es nuevo, es completamente distinto y puede atraer a muchos nuevos usuarios. Es un punto muy a favor de las aplicaciones nativas. Sin embargo, hay que dejar en claro que no por subir una app a estas tiendas de aplicaciones va a tener un aluvión de usuarios ni mucho menos. Si tú no promocionas tu aplicación y no lo haces bien, a pesar de que podrías tener descargas de la nada, no serían muchas. No podrás esperar de un aluvión de usuarios, simplemente por subir una app. Al contrario, hay todo un trabajo detrás. Claro está que, si se hace bien, puedes tener muchos usuarios. <h3>2. Accesibilidad</h3> Una app nativa es mucho más accesible que una web. En el mundo de la tecnología cada mínima barrera que le pongas al usuario es importante. Y, aunque parezca una tontería tener que ir al navegador, poner la URL de la web y entrar, es un paso de segundos que hay que hacer. Sin embargo, con la aplicación nativa ya tienes un icono que te sale en la pantalla y a través de un clic, ya se abre esa aplicación que quieres y puedes ver el contenido. Precisamente estos iconos que salen en la pantalla principal, hacen que sea muy accesible y, a menudo actúan como pequeños recordatorios de que la app está ahí; una suerte de «pequeñas campañas de marketing»: no me acordaba que estaba esta aplicación aquí, pero aquí está este logo y voy a entrar a ver que hay quizás consuma lo que me ofrece. Es una forma de recordarte que ese negocio existe y está ahí porque lo ves casi cada día, aunque realmente no lo percibas al 100%, a pesar de que a veces ni nos damos cuenta de que aplicaciones tenemos instaladas; pero sí que nos fijamos y las recordamos. <h3>3. Experiencia de usuario</h3> El tercer punto es la experiencia de usuario cuando comparamos una web responsive con una aplicación. La verdad es que las aplicaciones nativas son mucho más rápidas y fluidas que una web, además de ofrecer una mejor experiencia de usuario. Esto es así, porque básicamente la web se carga encima de un navegador y hay que esperar a que llegue el contenido. Las aplicaciones son mucho más rápidas; también tienes que hacer una llamada al servidor y tienes que esperar para ciertas cosas, pero, en términos de la fluidez de la interfaz, es mucho más rápida ya que está creada precisamente para ese dispositivo y ese sistema. Además, puedes acceder sin límite a ciertos sensores del móvil, ofrecer un modo offline, y disfrutar de más fluidez durante la navegación. Todo esto, lleva a que el usuario disfrute más la experiencia y que tenga más posibilidades de implementar ciertas funcionalidades para un negocio determinado. Al fin y al cabo, esto lleva a que el usuario esté más dispuesto a utilizar esta aplicación y por tanto a el producto o servicio que se ofrezca. Siempre que algo es fácil y agradable de utilizar es más propenso que acabe por ser utilizado o comprado. Hay un estudio de Flurry que muestra que el 90% del tiempo que se invierte en los dispositivos móviles se hace en aplicaciones, mientras que tan sólo un 10% se hace en el navegador que tiene integrado el móvil. Así que, esto es una clara muestra de que las aplicaciones son más agradables, fáciles de utilizar y más populares que las webs responsivas. <h3>4. La aplicación nativa es más interactiva</h3> El cuarto punto a tener en cuenta es que la aplicación nativa es más interactiva y crea usuarios más leales. Cómo comentaba anteriormente, el icono en la pantalla principal, facilita que un usuario vuelva a entrar a la aplicación. Al fin y al cabo, cuando el usuario la instala, la ve casi cada día en su pantalla principal, aunque la gran mayoría de las veces la vaya a ignorar lo cual, es más que evidente. Es probable que este icono en medio de la pantalla tenga mucho que ver con esto ya que, una cosa es ver el icono de la pantalla cada día y volver a entrar a utilizar este producto o servicio; y otra, es tener que ir de nuevo al navegador, acordarte de la URL concreta y volver a entrar. Además, no debemos olvidar los de las push notifications que, es una opción de marketing que tienen las aplicaciones nativas y que es muy efectiva. A pesar de que, en mi opinión, esto no es algo que tenga que ser mostrado con estudios, sí que hay algunos que indican que esas notificaciones que recibimos en los móviles, son muchísimo más efectivas que cualquier otra técnica de marketing (emails o SMS). Estos estudios, como media, indican que sobre un 90% de las notificaciones que se envían, se ven; y sobre un 40%, se abren. Son porcentajes muy elevados comparados con otras técnicas como el envío de emails o SMS. La verdad sea dicha, las push notifications también tienen sus restricciones: no las puedes utilizar, así como así, ni tampoco crear campañas de marketing para hacer spam. Pero, bien implementadas pueden ser tremendamente efectivas. A pesar de que en la web también existe la posibilidad, a través de ciertos navegadores, de enviar notificaciones, no tienen nada que ver con las notificaciones de los móviles. <h3>5. Presupuesto </h3> Todo esto nos lleva al quinto y último punto: el presupuesto. Hasta aquí, está muy claro que la aplicación nativa es mucho mejor que una web móvil. Todos los estudios y datos indican que los usuarios prefieren a las aplicaciones que, a las webs responsive, por lo que se crean usuarios más leales que disfrutan más la aplicación y que probablemente acaben gastando más en nuestro producto o servicio. Sin embargo, ¿cuál es el problema? Precisamente el coste y tiempo de desarrollo. Una web móvil responsive es sencilla de implementar. De hecho, la gran mayoría de tecnologías web lo llevan incluido por defecto, como los grandes CMS. Aunque se tenga que desarrollar algo, no tiene un gran coste. Simplemente hay que adaptar unas cuantas cosas que llevaría unos cuantos días de desarrollo. Por otro lado, las apps tienen un coste de desarrollo muy elevado en comparación con estas webs responsive. Por tanto, llega el momento en el que hay de que decidir si realmente vale la pena y pueda haber un retorno real de esa inversión. Es probable que en cuanto más grande sea el negocio más retorno puede haber. Sin embargo, ahora con tecnologías como Flutter, también hay que decir que pueden hacerse apps menos costosas sin afectar su calidad. The post <a href="https://diegolaballos.com/podcast/98-aplicacion-o-web-responsive-cual-elegir/" rel="nofollow" target="_blank">98. ¿Aplicación o web responsive? ¿Cuál elegir?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

98. ¿Aplicación o web responsive? ¿Cuál elegir?

Después de unas seis versiones en modo pruebas de Flutter, Google lanzó la versión final 1.0; la que está lista para producción de framework para desarrollar aplicaciones móviles con Android y IOS. Esta versión 1.0, básicamente lo que quiere decir es que ya está preparada para utilizarse en cualquier tipo de aplicación móvil en producción, aunque la verdad las versiones de pruebas anteriores, por lo menos las últimas utilizadas con las que se ha trabajado, no tenían muchos problemas, pero esta es la versión de producción oficial. 1. Flutter es rápido El primer punto de Flutter es que es rápido, es una tecnología rápida; no como otras tecnologías.  Según qué tecnologías, algunas web u otras; tienen cierto problema con esto, que no son igual de fluidas que las aplicaciones nativas que se crean exactamente y únicamente para un sistema operativo. Con Flutter, como todo el código de la aplicación se compila a código máquina que entiende el dispositivo; este problema no está ahí y funciona muy, muy rápido. 2. Versatilidad El segundo punto es que Flutter te permite crear aplicaciones que tengan cualquier tipo de diseño. l.a verdad es que esto en las aplicaciones nativas también era posible. Sí que es posible crear casi cualquier tipo de diseño que te envíen, que quiera tener la persona que encargue la aplicación, lo que pasa y la gran diferencia es la dificultad para llegar a crear ese diseño. Normalmente con las aplicaciones nativas estás bastante restringido con el sistema operativo y tienes que pelearte ahí con el propio sistema y el SDK las herramientas que te da para conseguir esas animaciones o ese diseño que te han pasado. Aun así, es posible hacerlo, sin embargo, con Flutter esto es muchísimo más sencillo y mucho más rápido conseguir un diseño concreto.  3. Productividad El tercer punto de Flutter es que te hace productivo y quizás este es el más importante de todos. Te hace ser un programador muy, muy productivo. Lo más importante y el punto principal es que tienes una sola base de código que sirve para todas las plataformas que quieras soportar; eso quiere decir básicamente que vas a necesitar mucho menos tiempo y en caso de mirar temas de presupuesto; mucho menos dinero para conseguir esas aplicaciones móviles. En vez de desarrollar dos veces la misma aplicación para distintos sistemas, únicamente la vas a desarrollar una vez y esto también tiene otros beneficios, como el tema de los errores que tendrás después. Si tienes aplicaciones nativas y tienes distintos proyectos, tendrás distintos errores; tendrás que hacer un seguimiento distinto. Sin embargo, con Flutter tienes únicamente una sola base de código con la cual los errores van a estar en ambas plataformas, no vas a tener unos errores en una y en otra no, etc. Sólo vas a tener que hacer un único seguimiento. Luego los tiempos de compilación, el tiempo que tarda el programador en ver los cambios que está haciendo en su código para ver si funciona o no. Esto sobre todo es un problema que tienen las aplicaciones nativas, más concretamente Android por lo menos. Cada vez que tú estás programado y quieres ver esos cambios reflejados en el dispositivo en el cual estás probando la aplicación, tarda mucho tiempo. Dependiendo del tamaño de la aplicación esto puede ir desde 30 segundos, hasta un minuto o incluso más. Y esto afecta muchísimo a la productividad, cada vez que haces un cambio tienes que esperar un montón de tiempo para ver ese cambio y este bucle lo vas haciendo muchas veces en el día. Al final resulta que pierdes muchísimo tiempo simplemente esperando. Con flutter esto no pasa porque tenemos lo que se llama el hot reload que básicamente tarda cuestión de 1,2,3 segundos en reflejar el cambio en el dispositivo y esto hace que puedas ir iterando mucho más y el programador pueda ir probando cosas más rápidamente. Luego el tercer punto en cuanto a la productividad es el tema de que te mantiene el estado de cuando estás programado de las pantallas; esto que quiere decir que,  imaginemos que estamos solucionando un error o estamos programando cualquier cosa en una pantalla que está al final de una navegación de cuatro pantallas. Imaginemos que, por ejemplo estamos programando una app de productos de compra-venta de segunda mano y resulta que estamos haciendo algo nuevo, estamos retocando cosas o corrigiendo cualquier error de la forma en la cual se le asigna un nuevo precio al producto; para llegar a esta pantalla, el problema es que tienes que entran en la aplicación. Luego seguramente tienes que ir a tu perfil, luego a tus productos, luego seleccionar tu producto, luego a editar al precio y ahí seguramente vas a llegar a esa pantalla que es la de edición de precio, por poner un ejemplo. Esto con las aplicaciones nativas y con muchísimas tecnologías, el gran problema que crea es que cada vez que tú haces un cambio y lo quieres ver reflejado, vas a tener que hacer toda esa navegación hasta esa pantalla que realmente te interesa. Y aunque pueda parecer poco tiempo, si esto lo haces varias veces, ií es un bucle constante en el cual estás probando cosas y mirar a ver si funciona al final suma muchos segundos, muchos minutos. Sin embargo con flutter la tecnología, que se llama hot reload  lo que pasa es que siempre que tú haces un cambio te va a mantener en la última pantalla en la que estabas con lo cual cuando vuelvas a hacer el segundo cambio para ver si funciona, no vas a tener que navegar hasta esa pantalla otra vez por la aplicación, sino que automáticamente va a salir la misma pantalla en la cual lo habías dejado y esto una vez más.  Si sumas segundos al final del día son muchos minutos de productividad y de hacer realmente lo que es importante, que es programar, arreglar o corregir lo que tengas que hacer. Al fin y al cabo, estos tres principales beneficios de flutter, lo que hacen es hacer que la programación sea más rápida y tenga un menor coste y esto es muy importante. The post 97. ¿Qué debes saber sobre Flutter 1.0? appeared first on Diego Laballós.

Después de unas seis versiones en modo pruebas de Flutter, Google lanzó la versión final 1.0; la que está lista para producción de framework para desarrollar aplicaciones móviles con Android y IOS. Esta versión 1.0, básicamente lo que quiere decir es que ya está preparada para utilizarse en cualquier tipo de aplicación móvil en producción, aunque la verdad las versiones de pruebas anteriores, por lo menos las últimas utilizadas con las que se ha trabajado, no tenían muchos problemas, pero esta es la versión de producción oficial. <h3>1. Flutter es rápido</h3> El primer punto de Flutter es que es rápido, es una tecnología rápida; no como otras tecnologías. Según qué tecnologías, algunas web u otras; tienen cierto problema con esto, que no son igual de fluidas que las aplicaciones nativas que se crean exactamente y únicamente para un sistema operativo. Con Flutter, como todo el código de la aplicación se compila a código máquina que entiende el dispositivo; este problema no está ahí y funciona muy, muy rápido. <h3>2. Versatilidad</h3> El segundo punto es que Flutter te permite crear aplicaciones que tengan cualquier tipo de diseño. l.a verdad es que esto en las aplicaciones nativas también era posible. Sí que es posible crear casi cualquier tipo de diseño que te envíen, que quiera tener la persona que encargue la aplicación, lo que pasa y la gran diferencia es la dificultad para llegar a crear ese diseño. Normalmente con las aplicaciones nativas estás bastante restringido con el sistema operativo y tienes que pelearte ahí con el propio sistema y el SDK las herramientas que te da para conseguir esas animaciones o ese diseño que te han pasado. Aun así, es posible hacerlo, sin embargo, con Flutter esto es muchísimo más sencillo y mucho más rápido conseguir un diseño concreto. <h3>3. Productividad</h3> El tercer punto de Flutter es que te hace productivo y quizás este es el más importante de todos. Te hace ser un programador muy, muy productivo. Lo más importante y el punto principal es que tienes una sola base de código que sirve para todas las plataformas que quieras soportar; eso quiere decir básicamente que vas a necesitar mucho menos tiempo y en caso de mirar temas de presupuesto; mucho menos dinero para conseguir esas aplicaciones móviles. En vez de desarrollar dos veces la misma aplicación para distintos sistemas, únicamente la vas a desarrollar una vez y esto también tiene otros beneficios, como el tema de los errores que tendrás después. Si tienes aplicaciones nativas y tienes distintos proyectos, tendrás distintos errores; tendrás que hacer un seguimiento distinto. Sin embargo, con Flutter tienes únicamente una sola base de código con la cual los errores van a estar en ambas plataformas, no vas a tener unos errores en una y en otra no, etc. Sólo vas a tener que hacer un único seguimiento. Luego los tiempos de compilación, el tiempo que tarda el programador en ver los cambios que está haciendo en su código para ver si funciona o no. Esto sobre todo es un problema que tienen las aplicaciones nativas, más concretamente Android por lo menos. Cada vez que tú estás programado y quieres ver esos cambios reflejados en el dispositivo en el cual estás probando la aplicación, tarda mucho tiempo. Dependiendo del tamaño de la aplicación esto puede ir desde 30 segundos, hasta un minuto o incluso más. Y esto afecta muchísimo a la productividad, cada vez que haces un cambio tienes que esperar un montón de tiempo para ver ese cambio y este bucle lo vas haciendo muchas veces en el día. Al final resulta que pierdes muchísimo tiempo simplemente esperando. Con flutter esto no pasa porque tenemos lo que se llama el hot reload que básicamente tarda cuestión de 1,2,3 segundos en reflejar el cambio en el dispositivo y esto hace que puedas ir iterando mucho más y el programador pueda ir probando cosas más rápidamente. Luego el tercer punto en cuanto a la productividad es el tema de que te mantiene el estado de cuando estás programado de las pantallas; esto que quiere decir que, imaginemos que estamos solucionando un error o estamos programando cualquier cosa en una pantalla que está al final de una navegación de cuatro pantallas. Imaginemos que, por ejemplo estamos programando una app de productos de compra-venta de segunda mano y resulta que estamos haciendo algo nuevo, estamos retocando cosas o corrigiendo cualquier error de la forma en la cual se le asigna un nuevo precio al producto; para llegar a esta pantalla, el problema es que tienes que entran en la aplicación. Luego seguramente tienes que ir a tu perfil, luego a tus productos, luego seleccionar tu producto, luego a editar al precio y ahí seguramente vas a llegar a esa pantalla que es la de edición de precio, por poner un ejemplo. Esto con las aplicaciones nativas y con muchísimas tecnologías, el gran problema que crea es que cada vez que tú haces un cambio y lo quieres ver reflejado, vas a tener que hacer toda esa navegación hasta esa pantalla que realmente te interesa. Y aunque pueda parecer poco tiempo, si esto lo haces varias veces, ií es un bucle constante en el cual estás probando cosas y mirar a ver si funciona al final suma muchos segundos, muchos minutos. Sin embargo con flutter la tecnología, que se llama hot reload lo que pasa es que siempre que tú haces un cambio te va a mantener en la última pantalla en la que estabas con lo cual cuando vuelvas a hacer el segundo cambio para ver si funciona, no vas a tener que navegar hasta esa pantalla otra vez por la aplicación, sino que automáticamente va a salir la misma pantalla en la cual lo habías dejado y esto una vez más. Si sumas segundos al final del día son muchos minutos de productividad y de hacer realmente lo que es importante, que es programar, arreglar o corregir lo que tengas que hacer. Al fin y al cabo, estos tres principales beneficios de flutter, lo que hacen es hacer que la programación sea más rápida y tenga un menor coste y esto es muy importante. The post <a href="https://diegolaballos.com/podcast/97-que-debes-saber-sobre-flutter-1-0/" rel="nofollow" target="_blank">97. ¿Qué debes saber sobre Flutter 1.0?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

97. ¿Qué debes saber sobre Flutter 1.0?

¿Qué es la productividad? Básicamente la productividad es hacer el máximo trabajo posible, durante el tiempo que pasas trabajando o, en otras palabras; no distraerte y no hacer cosas que no sean del trabajo, cuando estás trabajando. Cuánto más productivo seas, menos tiempo necesitarás para hacer las cosas. Hay muchos libros de productividad y muchas técnicas y mucha información sobre esto, pero no todas son aplicables a todas las personas y todos los sectores. Lo mejor es simplemente, probar y probar. Y ver qué te funciona, hay que dejar en claro que somos personas y no máquinas, necesitamos descansar, relajarnos y eso es necesario.  Intentar ser híper productivo, puede traer malas consecuencias a medio largo plazo, como acabar quemado de tu trabajo, de lo que haces, de lo que hasta el momento te gustaba hacer, u olvidar otros aspectos importantes de tu vida. 1. Trabajar sin distracciones El primero de todos es trabajar solo. En término de productividad, esto es lo mejor; en términos de relaciones sociales quizás no lo sea tanto, ya que a veces trabajando solo puedes echar en falta el hablar con otras personas. En una oficina hay muchas distracciones que pueden afectar tu productividad. Cuando estás programando sobre todo necesitas estar focalizado en lo que estás haciendo y a veces esa mínima distracción de alguien que te habla, que te pregunta, de un ruido que hace alguien te puede hacer perder el hilo de lo que estabas haciendo o hacerte de nuevo empezar a volver a meterte en el tema en el cual estabas focalizado. Así que, como programador, programar solo ayuda un montón. 2. Time Boxing El segundo es el “time boxing” sobre todo esto es importante cuando tienes varias cosas que hacer. Por ejemplo en el caso de los freelancers, si tienes varios clientes, si tienes que escribir un blog, hacer un podcast, tienes varios proyectos, varios problemas que solucionar…Si no te organizas bien el tiempo, no vas a ser productivo. La técnica del “time boxing” consiste en establecer día y hora para cada tarea. Básicamente puedes utilizar cualquier aplicación de calendario y ahí vas colocando los bloques de trabajo que vas a hacer. Cuando trabajas sin la técnica del “time boxing” es muy fácil olvidarte de hacer las cosas simplemente porque no tienes una fecha concreta y una hora para hacerlo.  3. Establecer objetivos El tercer punto es planear el día con objetivos y esto completamentaría un poco la idea del “time boxing”. Lo que se tiene que hacer es establecer una serie de objetivos a la mañana; a primera hora mirar, lo primero que se hace es mirar el calendario y ver esas cosas que tienes que hacer, y establecerte esos objetivos pequeños, objetivos del día. Sería algo así, como, por ejemplo acabar el login de “x” proyecto, grabar un podcast, corregir el error de este otro proyecto, y así una serie de cuatro-cinco objetivos que tendrías, que cumplir teóricamente ese día.  Esto lo que te permite es estar motivado día tras día cumpliendo los objetivos y encontrando esa pequeña motivación que te hace sentirte productivo al final del día, cuando ves que esos objetivos se han cumplido. 4. Establecer una oficina El cuarto punto tiene que ver con el tema de trabajar en casa y es básicamente que la oficina en casa, es como no estar en casa. Esto es importante si trabajas desde casa.  Se basa en mentalizarte en que tu oficina no está dentro de tu casa, sino como si fuera una oficina dentro de un edificio de oficinas (valga la redundancia). Para ello básicamente lo que ayuda es tener un habitáculo, una habitación que tenga pinta de oficina, que tenga material de oficina y que únicamente sirva para ello. El objetivo es que no vayas a hacer un descanso cuando te dé la gana a ver la tele, a coger algo en la nevera, a tirarte en el sofá; tienes que imaginarte que estás en un edificio de oficinas y si necesitas practicar algo entre horas, simplemente tráetelo a la mañana antes dentro de la oficina. Obviamente, comer utilizando tu cocina, esa es una de las ventajas de trabajar en casa, pero te tienes que organizar los descansos, y en esas horas de la mañana y horas de la tarde; a hacer esos bloques de quizás cuatro horas a la mañana, cuatro horas a la tarde dentro de tu oficina; como si estuvieras realmente de un edificio únicamente que tuviera oficinas. También ligado a esto; otro tema que es importante, aunque quizás no lo puede parecer mucho al principio; es vestirte como si fueras a trabajar. Si estás en casa no quiere decir  que puedas ir en pijama básicamente por dos motivos. Uno, porque no creas ambiente de trabajo y eso quieras que no psicológicamente se nota y afecta. Y el segundo es que, igualmente, aunque trabajes desde casa; tienes que estar presentable para otra gente con la que tengas que hablar. Ya que, si trabajas desde casa, lo más seguro es que tengas muchas reuniones a través de Skype, a través de vídeo llamada; y obviamente estar despeinado y en pijama no es quizás la mejor forma de dar buena impresión a otra persona. Así que siempre tienes que estar presentable y vestirte como si fueras a trabajar, porque crea esa sensación de trabajo igual que la habitación que utilizas como oficina. 5. Bloquear distracciones El quinto tip es bloquear toda distracción y esto también va ligado que trabajar en una oficina es un foco de distracciones, pero trabajar desde casa también tiene sus propias distracciones sobre todo relaciones con redes sociales, emails, teléfono… Si estás trabajando en algo céntrate únicamente en ello para no desconcentrarte y luego cuando acabes, pues ya podrás consultar esa red social, ese email que te ha llegado, esa llamada que te habían hecho… Quizás estas tres son los focos más importantes de distracciones que tienes cuando trabajas desde casa o trabajas desde la oficina también, pero hay muchos programas, muchas técnicas de bloquear todos estos focos de distracción. 6. Estabelecer bloques de trabajo cortos Y el sexto punto es establecer bloques de trabajo cortos y alternando tareas. Sobre todo en programación esto es importante. Necesitas dos cosas: Descansos entre medias con bloques de trabajo de una-dos horas y alternar tareas.  Esto último básicamente significa no tener un día entero de programación, sino que se pueden ir alternando con tareas más amenas, o que no requieren tanta concentración, o algo diferente simplemente. Después de seis horas de programación, quizás en la últimas dos te apetezca escribir un artículo, ponerte a mirar una conferencia quizás de algo interesante, antes que programar dos horas más. Porque lo más seguro es que ya no seas muy productivo, después de hacer estado seis horas programando. Así que busca otras tareas en las cuales puedas seguir siendo productivo, ya que no requieras de esa concentración; y estos son los principales métodos para ser más productivo. Seguro hay algunos otros tips que pueden ser útiles, pero los principales están ya cubiertos. The post 96. Productividad para programadores appeared first on Diego Laballós.

¿Qué es la productividad? Básicamente la productividad es hacer el máximo trabajo posible, durante el tiempo que pasas trabajando o, en otras palabras; no distraerte y no hacer cosas que no sean del trabajo, cuando estás trabajando. Cuánto más productivo seas, menos tiempo necesitarás para hacer las cosas. Hay muchos libros de productividad y muchas técnicas y mucha información sobre esto, pero no todas son aplicables a todas las personas y todos los sectores. Lo mejor es simplemente, probar y probar. Y ver qué te funciona, hay que dejar en claro que somos personas y no máquinas, necesitamos descansar, relajarnos y eso es necesario. Intentar ser híper productivo, puede traer malas consecuencias a medio largo plazo, como acabar quemado de tu trabajo, de lo que haces, de lo que hasta el momento te gustaba hacer, u olvidar otros aspectos importantes de tu vida. <h3>1. Trabajar sin distracciones</h3> El primero de todos es trabajar solo. En término de productividad, esto es lo mejor; en términos de relaciones sociales quizás no lo sea tanto, ya que a veces trabajando solo puedes echar en falta el hablar con otras personas. En una oficina hay muchas distracciones que pueden afectar tu productividad. Cuando estás programando sobre todo necesitas estar focalizado en lo que estás haciendo y a veces esa mínima distracción de alguien que te habla, que te pregunta, de un ruido que hace alguien te puede hacer perder el hilo de lo que estabas haciendo o hacerte de nuevo empezar a volver a meterte en el tema en el cual estabas focalizado. Así que, como programador, programar solo ayuda un montón. <h3>2. Time Boxing</h3> El segundo es el “time boxing” sobre todo esto es importante cuando tienes varias cosas que hacer. Por ejemplo en el caso de los freelancers, si tienes varios clientes, si tienes que escribir un blog, hacer un podcast, tienes varios proyectos, varios problemas que solucionar…Si no te organizas bien el tiempo, no vas a ser productivo. La técnica del “time boxing” consiste en establecer día y hora para cada tarea. Básicamente puedes utilizar cualquier aplicación de calendario y ahí vas colocando los bloques de trabajo que vas a hacer. Cuando trabajas sin la técnica del “time boxing” es muy fácil olvidarte de hacer las cosas simplemente porque no tienes una fecha concreta y una hora para hacerlo. <h3>3. Establecer objetivos</h3> El tercer punto es planear el día con objetivos y esto completamentaría un poco la idea del “time boxing”. Lo que se tiene que hacer es establecer una serie de objetivos a la mañana; a primera hora mirar, lo primero que se hace es mirar el calendario y ver esas cosas que tienes que hacer, y establecerte esos objetivos pequeños, objetivos del día. Sería algo así, como, por ejemplo acabar el login de “x” proyecto, grabar un podcast, corregir el error de este otro proyecto, y así una serie de cuatro-cinco objetivos que tendrías, que cumplir teóricamente ese día. Esto lo que te permite es estar motivado día tras día cumpliendo los objetivos y encontrando esa pequeña motivación que te hace sentirte productivo al final del día, cuando ves que esos objetivos se han cumplido. <h3>4. Establecer una oficina</h3> El cuarto punto tiene que ver con el tema de trabajar en casa y es básicamente que la oficina en casa, es como no estar en casa. Esto es importante si trabajas desde casa. Se basa en mentalizarte en que tu oficina no está dentro de tu casa, sino como si fuera una oficina dentro de un edificio de oficinas (valga la redundancia). Para ello básicamente lo que ayuda es tener un habitáculo, una habitación que tenga pinta de oficina, que tenga material de oficina y que únicamente sirva para ello. El objetivo es que no vayas a hacer un descanso cuando te dé la gana a ver la tele, a coger algo en la nevera, a tirarte en el sofá; tienes que imaginarte que estás en un edificio de oficinas y si necesitas practicar algo entre horas, simplemente tráetelo a la mañana antes dentro de la oficina. Obviamente, comer utilizando tu cocina, esa es una de las ventajas de trabajar en casa, pero te tienes que organizar los descansos, y en esas horas de la mañana y horas de la tarde; a hacer esos bloques de quizás cuatro horas a la mañana, cuatro horas a la tarde dentro de tu oficina; como si estuvieras realmente de un edificio únicamente que tuviera oficinas. También ligado a esto; otro tema que es importante, aunque quizás no lo puede parecer mucho al principio; es vestirte como si fueras a trabajar. Si estás en casa no quiere decir que puedas ir en pijama básicamente por dos motivos. Uno, porque no creas ambiente de trabajo y eso quieras que no psicológicamente se nota y afecta. Y el segundo es que, igualmente, aunque trabajes desde casa; tienes que estar presentable para otra gente con la que tengas que hablar. Ya que, si trabajas desde casa, lo más seguro es que tengas muchas reuniones a través de Skype, a través de vídeo llamada; y obviamente estar despeinado y en pijama no es quizás la mejor forma de dar buena impresión a otra persona. Así que siempre tienes que estar presentable y vestirte como si fueras a trabajar, porque crea esa sensación de trabajo igual que la habitación que utilizas como oficina. <h3>5. Bloquear distracciones</h3> El quinto tip es bloquear toda distracción y esto también va ligado que trabajar en una oficina es un foco de distracciones, pero trabajar desde casa también tiene sus propias distracciones sobre todo relaciones con redes sociales, emails, teléfono… Si estás trabajando en algo céntrate únicamente en ello para no desconcentrarte y luego cuando acabes, pues ya podrás consultar esa red social, ese email que te ha llegado, esa llamada que te habían hecho… Quizás estas tres son los focos más importantes de distracciones que tienes cuando trabajas desde casa o trabajas desde la oficina también, pero hay muchos programas, muchas técnicas de bloquear todos estos focos de distracción. <h3>6. Estabelecer bloques de trabajo cortos</h3> Y el sexto punto es establecer bloques de trabajo cortos y alternando tareas. Sobre todo en programación esto es importante. Necesitas dos cosas: Descansos entre medias con bloques de trabajo de una-dos horas y alternar tareas. Esto último básicamente significa no tener un día entero de programación, sino que se pueden ir alternando con tareas más amenas, o que no requieren tanta concentración, o algo diferente simplemente. Después de seis horas de programación, quizás en la últimas dos te apetezca escribir un artículo, ponerte a mirar una conferencia quizás de algo interesante, antes que programar dos horas más. Porque lo más seguro es que ya no seas muy productivo, después de hacer estado seis horas programando. Así que busca otras tareas en las cuales puedas seguir siendo productivo, ya que no requieras de esa concentración; y estos son los principales métodos para ser más productivo. Seguro hay algunos otros tips que pueden ser útiles, pero los principales están ya cubiertos. The post <a href="https://diegolaballos.com/podcast/96-productividad-para-programadores/" rel="nofollow" target="_blank">96. Productividad para programadores</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

96. Productividad para programadores

¿Qué quiere decir ser un buen desarrollador? Esto puede ser bastante subjetivo.. ¿Qué significa ser un desarrollador o qué cualidades debería tener un buen programador? 1. Saber hacer Lo primero es saber hacer. Obviamente esto es un requisito indispensable. Saber sobre el tema que tratas es la regla número uno de cualquier profesional. Si estás ofreciendo un servicio, si ofreces algo, debes de saber bien lo que estás haciendo; porque al fin y al cabo te van a estar pagando por eso. Así que es algo que se da por hecho. Debes saber lo que haces, no que seas el mejor del mundo ni el mejor de tu país, porque para empezar esto es muy subjetivo y también muy complicado; y por no ser imposible siempre va a haber alguien mejor que tú. El caso es que tú intentes mejorar día a día y que vayas siendo mejor un día tras otro. Básicamente lo que esto significa en programación es que tienes que ser consciente de lo que estás haciendo y aplicar buenas prácticas. Temas de testing, temas de código limpio. Y, ¿por qué esto es importante para la persona que contrata un programador? En programación esto es importante por diferentes motivos. En primer lugar, un proyecto mal programado por un programador que no sabe lo que hace, acaba siendo hasta un proyecto mal programado, básicamente no tiene futuro. Lo que acabará pasando al final es que, si un proyecto está mal hecho, no se puede seguir escalando, no puede evolucionar. Se acabará programando otra vez de cero por otro desarrollado y al principio lo que quizás había salido barato o quizás no, pues acabará saliendo caro. Otro punto a tener en cuenta, es que el proyecto seguramente tenga muchos más errores de lo normal. En programación los errores son normales. Es una cosa que pasa y es lo más normal del mundo. Lo que pasa es que, si un proyecto está programado, lo más seguro es que tenga muchísimos más errores de lo normal; si no se siguen unas buenas prácticas. Y finalmente el proyecto seguramente avance más lentamente a la hora de hacer cambios, a la hora de actualizar, a la hora de cambiar cosas ya desde una vista de negocio. Si el proyecto está mal hecho, va a ser mucho más difícil cambiar cosas, cambiar las cosas más rápido o cambiar ciertas cosas. Esto lo que va a hacer es ralentizar mucho el proyecto, mucho cada actualización que se quiera hacer y moverse rápido muchas veces es algo importante. Sobre todo en el mundo de las aplicaciones móviles. Al final todo acabará afectando a los usuarios y al negocio en sí mismo; lo complicado de esto es que todos estos puntos, quizás no se vean en el corto plazo, sino que se ven en el medio-largo plazo. 2. Buena comunicación El segundo punto que tiene que tener un desarrollador es una buena comunicación. La comunicación es un tema importantísimo, sobre todo porque estás hablando de algo complejo. Seguramente con alguien que no tiene por qué saber y entender de ese mundo. Así que saber explicar bien las cosas es vital. Ya sea que estés trabajando dentro de una empresa, dentro de un equipo o como freelance. Seguramente como freelance tiene un poco más de importancia. Saber comunicar y comunicarse habitualmente es importante. No se trata de que tengas que estar disponible las 24 horas del día, los 7 días de la semana, pero sí que debes ser fácilmente accesible. La comunicación también es importante a la hora de definir un proyecto, porque evita muchos conflictos en un futuro, cosas como, por ejemplo: qué cosas incluye un proyecto, cierto presupuesto, qué cosas no, qué cosas sí; es complejo y si no lo comunicas bien, es fácil acabar teniendo un mal entendido sobre ciertas cosas. Otro punto serían las estimaciones y tiempos de desarrollo. Esto es algo que es complejo en sí mismo, es difícil calcular cuánto vas a tardar en hacer algo, pero es importante saber definir cómo vas a organizar un proyecto, , cuántas horas estimas que vas a tardar en hacer algo. Simplemente tienes que ser responsable con lo que estás haciendo y saber cómo organizas tu proyecto y lo que funciona mejor para ti. Todo esto básicamente en lo que ayuda es en la comunicación.  3. Responsabilidad El tercer punto es la responsabilidad. Un programador tiene que ser un buen programador. Tiene que ser responsable con lo que hace y aquí sobre todo a lo que me quiero referir es al tema de errores, porque los errores en programación son algo habitual. Simplemente tienes que ser responsable y saber qué errores son tuyos y cuáles no son tuyos. Esto se traduce quizás a qué errores, pues quizás deben de ser presupuestados por otro lado, qué cosas son de esperar que tendrían que contarse como un trabajo nuevo y qué errores son culpa tuya. Si acabas de entregar un proyecto y a la semana siguiente hay tres errores que son bastante obvios, quizás esto no es algo que debas presupuestar aparte o echarle la culpa a quien sea y  tengas que ser responsable, y apoquinar con los errores que has cometido y, por lo tanto, arreglarlos sin coste alguno. Aquí se trata más del tema del freelancing. Simplemente tienes que reconocer qué errores has cometido y son culpa tuya y qué errores no son culpa tuya del todo, y son esperables. Una vez más esto va ligado mucho con la comunicación, pero lo que hace es evitar mal entendidos entre cliente-programador en esta relación. 4. Pensar en el largo plazo Siempre que empiezas un proyecto debes tener en cuenta qué pasará en el largo plazo. Lo más seguro es un futuro (90% de las veces) lo más seguro es que ese proyecto que tú estás programando; vaya a ser dado por otros programadores, por otros motivos, pero es lo más seguro que años vista pase eso, por lo menos si el proyecto funciona y va bien. Aquí lo que se trata es de que cuando estás trabajando en el proyecto inicialmente, pienses en qué va a pasar en el largo plazo, qué va pasar con ese proyecto. Esto quiere decir dejar un código que sea entendible, documentado, código limpio, en fin, buenas prácticas de programación, que lo que permita es que sea fácil escalar y mantener ese mismo proyecto por otra persona.  Son tareas que quizás no te benefician a ti de forma directa, pero que como buen desarrollador debes tener en cuenta, ya que tu trabajo es el proyecto en su totalidad y no sólo los meses que tú vas a trabajar en él inicialmente. Si quieres contratar un desarrollador es importante que esto se cumpla. Sobre todo a la hora de pensar en futuros trabajadores que vayan a heredar este proyecto, que se pueda seguir utilizando, que sea útil lo que has hecho en el pasado y que se pueda mantener a lo largo del tiempo. Y el problema aquí es que si el programador no ha pensado en el largo plazo y solo ha pensado en ese corto plazo en su propio interés; vas a tener un problema, porque seguramente ese proyecto va a ser difícil de seguir manteniendo y evolucionarlo. 5. Estar actualizado Estar al día, esto es básico en programación, donde las cosas cambian muchísimo y muy rápido, debes estar al día y sugerir actualizaciones o cambios en el proyecto sí es necesario. Es tu tarea como programador. Por ejemplo si sale una nueva cosa en el sistema operativo que puede ser interesante para una app o si sale una nueva herramienta de programación, pues que mejoraría ciertas cosas; en fin, estar informado al cien por cien de lo que está pasando en tu mundo y cómo puedes aplicar esas mejoras que van saliendo. Como persona que contrata un desarrollador, esto supone que tu app se mantenga actualizada con las últimas tendencias y también que utilice las últimas herramientas disponibles que hagan que el proyecto funcione mejor, que sea más fácil de desarrollarlo, etc. The post 95. La importancia de encontrar un buen programador appeared first on Diego Laballós.

¿Qué quiere decir ser un buen desarrollador? Esto puede ser bastante subjetivo.. ¿Qué significa ser un desarrollador o qué cualidades debería tener un buen programador? <h3>1. Saber hacer</h3> Lo primero es saber hacer. Obviamente esto es un requisito indispensable. Saber sobre el tema que tratas es la regla número uno de cualquier profesional. Si estás ofreciendo un servicio, si ofreces algo, debes de saber bien lo que estás haciendo; porque al fin y al cabo te van a estar pagando por eso. Así que es algo que se da por hecho. Debes saber lo que haces, no que seas el mejor del mundo ni el mejor de tu país, porque para empezar esto es muy subjetivo y también muy complicado; y por no ser imposible siempre va a haber alguien mejor que tú. El caso es que tú intentes mejorar día a día y que vayas siendo mejor un día tras otro. Básicamente lo que esto significa en programación es que tienes que ser consciente de lo que estás haciendo y aplicar buenas prácticas. Temas de testing, temas de código limpio. Y, ¿por qué esto es importante para la persona que contrata un programador? En programación esto es importante por diferentes motivos. En primer lugar, un proyecto mal programado por un programador que no sabe lo que hace, acaba siendo hasta un proyecto mal programado, básicamente no tiene futuro. Lo que acabará pasando al final es que, si un proyecto está mal hecho, no se puede seguir escalando, no puede evolucionar. Se acabará programando otra vez de cero por otro desarrollado y al principio lo que quizás había salido barato o quizás no, pues acabará saliendo caro. Otro punto a tener en cuenta, es que el proyecto seguramente tenga muchos más errores de lo normal. En programación los errores son normales. Es una cosa que pasa y es lo más normal del mundo. Lo que pasa es que, si un proyecto está programado, lo más seguro es que tenga muchísimos más errores de lo normal; si no se siguen unas buenas prácticas. Y finalmente el proyecto seguramente avance más lentamente a la hora de hacer cambios, a la hora de actualizar, a la hora de cambiar cosas ya desde una vista de negocio. Si el proyecto está mal hecho, va a ser mucho más difícil cambiar cosas, cambiar las cosas más rápido o cambiar ciertas cosas. Esto lo que va a hacer es ralentizar mucho el proyecto, mucho cada actualización que se quiera hacer y moverse rápido muchas veces es algo importante. Sobre todo en el mundo de las aplicaciones móviles. Al final todo acabará afectando a los usuarios y al negocio en sí mismo; lo complicado de esto es que todos estos puntos, quizás no se vean en el corto plazo, sino que se ven en el medio-largo plazo. <h3>2. Buena comunicación</h3> El segundo punto que tiene que tener un desarrollador es una buena comunicación. La comunicación es un tema importantísimo, sobre todo porque estás hablando de algo complejo. Seguramente con alguien que no tiene por qué saber y entender de ese mundo. Así que saber explicar bien las cosas es vital. Ya sea que estés trabajando dentro de una empresa, dentro de un equipo o como freelance. Seguramente como freelance tiene un poco más de importancia. Saber comunicar y comunicarse habitualmente es importante. No se trata de que tengas que estar disponible las 24 horas del día, los 7 días de la semana, pero sí que debes ser fácilmente accesible. La comunicación también es importante a la hora de definir un proyecto, porque evita muchos conflictos en un futuro, cosas como, por ejemplo: qué cosas incluye un proyecto, cierto presupuesto, qué cosas no, qué cosas sí; es complejo y si no lo comunicas bien, es fácil acabar teniendo un mal entendido sobre ciertas cosas. Otro punto serían las estimaciones y tiempos de desarrollo. Esto es algo que es complejo en sí mismo, es difícil calcular cuánto vas a tardar en hacer algo, pero es importante saber definir cómo vas a organizar un proyecto, , cuántas horas estimas que vas a tardar en hacer algo. Simplemente tienes que ser responsable con lo que estás haciendo y saber cómo organizas tu proyecto y lo que funciona mejor para ti. Todo esto básicamente en lo que ayuda es en la comunicación. <h3>3. Responsabilidad</h3> El tercer punto es la responsabilidad. Un programador tiene que ser un buen programador. Tiene que ser responsable con lo que hace y aquí sobre todo a lo que me quiero referir es al tema de errores, porque los errores en programación son algo habitual. Simplemente tienes que ser responsable y saber qué errores son tuyos y cuáles no son tuyos. Esto se traduce quizás a qué errores, pues quizás deben de ser presupuestados por otro lado, qué cosas son de esperar que tendrían que contarse como un trabajo nuevo y qué errores son culpa tuya. Si acabas de entregar un proyecto y a la semana siguiente hay tres errores que son bastante obvios, quizás esto no es algo que debas presupuestar aparte o echarle la culpa a quien sea y tengas que ser responsable, y apoquinar con los errores que has cometido y, por lo tanto, arreglarlos sin coste alguno. Aquí se trata más del tema del freelancing. Simplemente tienes que reconocer qué errores has cometido y son culpa tuya y qué errores no son culpa tuya del todo, y son esperables. Una vez más esto va ligado mucho con la comunicación, pero lo que hace es evitar mal entendidos entre cliente-programador en esta relación. <h3>4. Pensar en el largo plazo</h3> Siempre que empiezas un proyecto debes tener en cuenta qué pasará en el largo plazo. Lo más seguro es un futuro (90% de las veces) lo más seguro es que ese proyecto que tú estás programando; vaya a ser dado por otros programadores, por otros motivos, pero es lo más seguro que años vista pase eso, por lo menos si el proyecto funciona y va bien. Aquí lo que se trata es de que cuando estás trabajando en el proyecto inicialmente, pienses en qué va a pasar en el largo plazo, qué va pasar con ese proyecto. Esto quiere decir dejar un código que sea entendible, documentado, código limpio, en fin, buenas prácticas de programación, que lo que permita es que sea fácil escalar y mantener ese mismo proyecto por otra persona. Son tareas que quizás no te benefician a ti de forma directa, pero que como buen desarrollador debes tener en cuenta, ya que tu trabajo es el proyecto en su totalidad y no sólo los meses que tú vas a trabajar en él inicialmente. Si quieres contratar un desarrollador es importante que esto se cumpla. Sobre todo a la hora de pensar en futuros trabajadores que vayan a heredar este proyecto, que se pueda seguir utilizando, que sea útil lo que has hecho en el pasado y que se pueda mantener a lo largo del tiempo. Y el problema aquí es que si el programador no ha pensado en el largo plazo y solo ha pensado en ese corto plazo en su propio interés; vas a tener un problema, porque seguramente ese proyecto va a ser difícil de seguir manteniendo y evolucionarlo. <h3>5. Estar actualizado</h3> Estar al día, esto es básico en programación, donde las cosas cambian muchísimo y muy rápido, debes estar al día y sugerir actualizaciones o cambios en el proyecto sí es necesario. Es tu tarea como programador. Por ejemplo si sale una nueva cosa en el sistema operativo que puede ser interesante para una app o si sale una nueva herramienta de programación, pues que mejoraría ciertas cosas; en fin, estar informado al cien por cien de lo que está pasando en tu mundo y cómo puedes aplicar esas mejoras que van saliendo. Como persona que contrata un desarrollador, esto supone que tu app se mantenga actualizada con las últimas tendencias y también que utilice las últimas herramientas disponibles que hagan que el proyecto funcione mejor, que sea más fácil de desarrollarlo, etc. The post <a href="https://diegolaballos.com/podcast/95-la-importancia-de-encontrar-un-buen-programador/" rel="nofollow" target="_blank">95. La importancia de encontrar un buen programador</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

95. La importancia de encontrar un buen programador

Lo primero que hay que aclarar aquí, es que Flutter, es esa nueva herramienta, framework o tecnología que nos permite crear aplicaciones móviles de una forma más rápida, con una calidad nativa, y en fin, son muchos beneficios los que tiene. El caso es que es de lo que vendría a pasar a ser del desarrollo nativo en Android a Flutter para desarrollar aplicaciones tanto para Android como IOS, es un proceso que lleva su tiempo; concretamente uno de los distintos beneficios que tiene flutter es, desde el lado de convencer a alguien que quizás no tiene un conocimiento técnico, para utilizar flutter como tecnología para desarrollar esa aplicación que se quiere hacer. Esto quizás, puede ser, pues a un socio que quizás no tiene un conocimiento técnico, quizás a un superior; si estás trabajando como programador en una empresa o quizás a un cliente (si eres freelance). Flutter es gratis Flutter es gratis y open source, esto de que sea gratis, quizás es la más obvia de todas, pero no debe de darse por sentado. De hecho, hay muchas tecnologías que tienen un coste, pero precisamente no es el caso de flutter. La otra característica, el hecho de que sea opensuse. Es importante sobre todo de cara al desarrollador, a la comunidad que se crea y a la facilidad de los desarrolladores, para ver, para inspeccionar ese código.  Esto al fin y al cabo, se traduce en tener menos errores, en ir más rápido y en encontrarte con menos barreras, con menos errores que son más difíciles de solucionar, porque tienes más comunidad, puedes entrar dentro del código y en fin, haces todo más rápido. Ahorro tiempo y costes Flutter crea aplicaciones para Android y IOS de una sola tirada; olvídate de programar dos veces la misma cosa, una vez para Android y otra para IOS. Con flutter no necesitas hacer esto, no necesitas hacer todo dos veces y eso supone mucho tiempo y muchísimo ahorro de costes. Cuanto menos código tengas, menos dinero te habrá costado hacerlo, menos tiempo tardarás y sobre todo menos tiempo tendrás que dedicar a mantener ese código.  Por ejemplo: con el caso de los errores. Si tenemos una aplicación nativa, donde está el proyecto de Android y el proyecto de IOS, cada uno tendrá sus errores, estos errores pueden ser los mismos, pueden ser distintos. Puede ser que un error que esté en Android solucionado, no lo esté en IOS; puede ser lo mismo y al revés. En fin, cada uno va por su lado y cada uno tendrá su coste de mantenimiento. Sin embargo, si tenemos flutter, tenemos un único proyecto. Sí resolvemos un error que está pasando en una plataforma, automáticamente va a quedar resuelto para la otra, porque básicamente habría ese mismo error.  La velocidad del desarrollo no es sólo importante al inicio de crear un proyecto, el tiempo, que vayas a tardar en tenerlo listo, sino que también es importante después de crear esa primera versión, ya que te permitirá hacer cambios y experimentar mucho más rápido con la aplicación para así poder seguir mejorándola.  Cuanto más rápido puedas avanzar y cambiar cosas, o solucionar errores (por ejemplo) mucho mejor va a ser la aplicación, porque más tiempo, más interacciones vas a poder hacer para mejorarla. Además de por sí, el desarrollo en flutter, es mucho más rápido que en una aplicación nativa móvil, sobre todo, debido a los tiempos de compilación.  Hay que saber que cada cambio que hace el desarrollador automáticamente queda reflejado en su dispositivo en cuestión de dos, tres segundos. Mientras que, en una aplicación nativa, por ejemplo, en el caso de Android pueden llegar a ser minutos, es decir, es tiempo que el desarrollador está esperando para que ese cambio surja efecto y pueda ver sí ha funcionado o no. Esto al final se traduce en una menor productividad. Hay que tener en cuenta que esto es un bucle constante dentro de un día. El desarrollador va haciendo cambios y compila cómo se ve en el móvil para ver si se ha arreglado; bien este proceso puede darse muchas, muchas veces durante el día.  Si esto tarda segundos en vez de minutos, al final del día tienes un desarrollador mucho más productivo y al final son menos costes. Calidad nativa El tercer punto es que las aplicaciones tienen una calidad nativa pese a que pueda considerarse una tecnología híbrida.  Una de las razones por las que no se recomienda utilizar una tecnología híbrida hasta el momento, es precisamente ésta. Las tecnologías que había en su momento, algunos años atrás, no me acababan de convencer del lado de lo que sería la fluidez de la aplicación, la rapidez, lo bien o mal que funcionaba porque básicamente no estaban preparadas, para competir con las aplicaciones nativas, en cuanto a que lo que rapidez y fluidez se refiere. Sin embargo, esto ahora está solucionado con flutter, el código de las aplicaciones de flutter se compila a código nativo que entiende el dispositivo a bajo nivel ¿y cuál es el resultado? Pues que la aplicación funciona mucho más rápida, que son más fluidas y que funcionan al fin y al cabo mucho mejor; todo ello, básicamente hace que tengan una mejor experiencia de usuario que otras tecnologías. Fácilmente personalizable El cuarto punto, es que fácilmente personalizable; el diseño de una app es muy importante con miles y miles de aplicaciones ahí afuera. El diseño es uno de los puntos diferenciales, y además es importante dar cara a la experiencia de usuario. Flutter tiene dos grandes puntos aquí, el primero es que por defecto nos proporciona muchos elementos que crean una aplicación moderna con poco código, con poco diseño externo; en pocos pasos podemos tener algo decente. Y el segundo punto, es que es fácil implementar diseños personalizados al gusto de un diseñador; es mucho más sencillo que hacerlo en una aplicación nativa, por lo menos desde Android.  Flutter es como un pequeño ending de juegos, que te permite dibujar cualquier cosa por pantalla fácilmente, con lo cual puedes hacer realidad todas esas animaciones, todos esos diseños tan quizás complejos desde la vista de un programador; puedes hacerlos de una forma mucho más sencilla. En resumen, qué es más fácil crear estos diseños y animaciones, que hacen que estos prototipos de una app se vean tan bien y al fin y al cabo crean una aplicación más bonita y que gustará más a los usuarios.  Además, también nos ahorramos el problema de algunas herramientas híbridas donde vemos distintas interfaces, dependiendo de la marca del móvil, dependiendo del sistema del usuario, de la versión del sistema, si no que se ve igual en todos los dispositivos, igual no; sino que depende de la plataforma.  Obviamente sigue las guías de diseño de Android y las de IOS, así que tenemos esta distinción que siempre es muy buena, también hay que tener en cuenta que tenemos total libertad para cambiar esto y hacer que las versiones de Android y IOS sean totalmente distintas; así que en este aspecto no hay ningún problema. Y el quinto punto, es la facilidad de adaptación a los cambios: esto es muy importante, ya que ¿quién piensa que la tecnología que tenemos ahora, se mantendrá en un periodo de cinco-diez años? Pues nadie, cada día hay más y más dispositivos; pantallas inteligentes, los coches, tenemos muchas opciones y muchos dispositivos van a ir saliendo y que aún no han salido. Pese que flutter está ahora centrado en IOS y Android, es muy fácilmente trasladable a cualquier otra plataforma que tenga como medio principal de comunicación una pantalla. Es como un ending de juegos, ya se han creado herramientas para que funcione sobre Mac, Windows o Linux, esto quiere decir, que puedes crear una aplicación en Flutter para estos sistemas operativos. Y, de hecho, el propio flutter es la base sobre la que se sustenta Fuchsia, el nuevo sistema de Google, que seguramente va a tener muchas cosas que decir; esto quiere decir que es fácilmente adaptable a lo que pueda pasar en un futuro, tanto si salen nuevos sistemas operativos por el coste o el tiempo, o el contratar personal que nos va a requerir este nuevo sistema operativo.  Si queremos estar en él, si mañana sale un nuevo sistema operativo móvil, por ejemplo, si tenemos aplicaciones nativas, vamos a tener que contratar otro equipo con sus costes y tiempo de desarrollo para estar en esa plataforma; o por ejemplo, si queremos que nuestra app se expanda a sistemas operativos que ya existen.  Por ejemplo: digamos que tenemos una aplicación móvil y queremos crear una aplicación de escritorio para Mac, para Windows o para Linux. Imaginemos que tenemos una aplicación parecida a Whatsapp o alguna mensajería instantánea y creamos la aplicación móvil para Android y IOS, y la cosa va bien, y se decide que por ejemplo: sería una buena idea ir hacia Mac y hacia Windows. Si tuviéramos una aplicación nativa esto habría que pensarlo más de dos veces, porque esto supondría contratar desarrolladores que pudieran hacerlo para Windows y para Mac, aunque fueran los mismos desarrolladores. Tendrían que dedicar su tiempo a volver a programar todo para esas plataformas extra. Sin embargo, si tenemos flutter, si podemos portar la aplicación automáticamente, ajustando cuatro cosas a esos nuevos sistemas, sin tener que desarrollar todo desde cero, el resultado es que vamos a tener un coste muchísimo, muchísimo más bajo, y un tiempo de desarrollo mucho más bajo también.  Y no vamos a requerir de un personal extra, ni vamos a requerir que las personas que tenemos aprendan esa nueva tecnología. Sino que con la que ya saben, van a poder utilizarlo y portar esa aplicación hacia los ordenadores, en este caso; con un click lo tendríamos listo, podríamos decir. The post 94. ¿Cómo convencer a un cliente para utilizar Flutter? appeared first on Diego Laballós.

Lo primero que hay que aclarar aquí, es que Flutter, es esa nueva herramienta, framework o tecnología que nos permite crear aplicaciones móviles de una forma más rápida, con una calidad nativa, y en fin, son muchos beneficios los que tiene. El caso es que es de lo que vendría a pasar a ser del desarrollo nativo en Android a Flutter para desarrollar aplicaciones tanto para Android como IOS, es un proceso que lleva su tiempo; concretamente uno de los distintos beneficios que tiene flutter es, desde el lado de convencer a alguien que quizás no tiene un conocimiento técnico, para utilizar flutter como tecnología para desarrollar esa aplicación que se quiere hacer. Esto quizás, puede ser, pues a un socio que quizás no tiene un conocimiento técnico, quizás a un superior; si estás trabajando como programador en una empresa o quizás a un cliente (si eres freelance). <h3>Flutter es gratis</h3> Flutter es gratis y open source, esto de que sea gratis, quizás es la más obvia de todas, pero no debe de darse por sentado. De hecho, hay muchas tecnologías que tienen un coste, pero precisamente no es el caso de flutter. La otra característica, el hecho de que sea opensuse. Es importante sobre todo de cara al desarrollador, a la comunidad que se crea y a la facilidad de los desarrolladores, para ver, para inspeccionar ese código. Esto al fin y al cabo, se traduce en tener menos errores, en ir más rápido y en encontrarte con menos barreras, con menos errores que son más difíciles de solucionar, porque tienes más comunidad, puedes entrar dentro del código y en fin, haces todo más rápido. <h3>Ahorro tiempo y costes</h3> Flutter crea aplicaciones para Android y IOS de una sola tirada; olvídate de programar dos veces la misma cosa, una vez para Android y otra para IOS. Con flutter no necesitas hacer esto, no necesitas hacer todo dos veces y eso supone mucho tiempo y muchísimo ahorro de costes. Cuanto menos código tengas, menos dinero te habrá costado hacerlo, menos tiempo tardarás y sobre todo menos tiempo tendrás que dedicar a mantener ese código. Por ejemplo: con el caso de los errores. Si tenemos una aplicación nativa, donde está el proyecto de Android y el proyecto de IOS, cada uno tendrá sus errores, estos errores pueden ser los mismos, pueden ser distintos. Puede ser que un error que esté en Android solucionado, no lo esté en IOS; puede ser lo mismo y al revés. En fin, cada uno va por su lado y cada uno tendrá su coste de mantenimiento. Sin embargo, si tenemos flutter, tenemos un único proyecto. Sí resolvemos un error que está pasando en una plataforma, automáticamente va a quedar resuelto para la otra, porque básicamente habría ese mismo error. La velocidad del desarrollo no es sólo importante al inicio de crear un proyecto, el tiempo, que vayas a tardar en tenerlo listo, sino que también es importante después de crear esa primera versión, ya que te permitirá hacer cambios y experimentar mucho más rápido con la aplicación para así poder seguir mejorándola. Cuanto más rápido puedas avanzar y cambiar cosas, o solucionar errores (por ejemplo) mucho mejor va a ser la aplicación, porque más tiempo, más interacciones vas a poder hacer para mejorarla. Además de por sí, el desarrollo en flutter, es mucho más rápido que en una aplicación nativa móvil, sobre todo, debido a los tiempos de compilación. Hay que saber que cada cambio que hace el desarrollador automáticamente queda reflejado en su dispositivo en cuestión de dos, tres segundos. Mientras que, en una aplicación nativa, por ejemplo, en el caso de Android pueden llegar a ser minutos, es decir, es tiempo que el desarrollador está esperando para que ese cambio surja efecto y pueda ver sí ha funcionado o no. Esto al final se traduce en una menor productividad. Hay que tener en cuenta que esto es un bucle constante dentro de un día. El desarrollador va haciendo cambios y compila cómo se ve en el móvil para ver si se ha arreglado; bien este proceso puede darse muchas, muchas veces durante el día. Si esto tarda segundos en vez de minutos, al final del día tienes un desarrollador mucho más productivo y al final son menos costes. <h3>Calidad nativa</h3> El tercer punto es que las aplicaciones tienen una calidad nativa pese a que pueda considerarse una tecnología híbrida. Una de las razones por las que no se recomienda utilizar una tecnología híbrida hasta el momento, es precisamente ésta. Las tecnologías que había en su momento, algunos años atrás, no me acababan de convencer del lado de lo que sería la fluidez de la aplicación, la rapidez, lo bien o mal que funcionaba porque básicamente no estaban preparadas, para competir con las aplicaciones nativas, en cuanto a que lo que rapidez y fluidez se refiere. Sin embargo, esto ahora está solucionado con flutter, el código de las aplicaciones de flutter se compila a código nativo que entiende el dispositivo a bajo nivel ¿y cuál es el resultado? Pues que la aplicación funciona mucho más rápida, que son más fluidas y que funcionan al fin y al cabo mucho mejor; todo ello, básicamente hace que tengan una mejor experiencia de usuario que otras tecnologías. <h3>Fácilmente personalizable</h3> El cuarto punto, es que fácilmente personalizable; el diseño de una app es muy importante con miles y miles de aplicaciones ahí afuera. El diseño es uno de los puntos diferenciales, y además es importante dar cara a la experiencia de usuario. Flutter tiene dos grandes puntos aquí, el primero es que por defecto nos proporciona muchos elementos que crean una aplicación moderna con poco código, con poco diseño externo; en pocos pasos podemos tener algo decente. Y el segundo punto, es que es fácil implementar diseños personalizados al gusto de un diseñador; es mucho más sencillo que hacerlo en una aplicación nativa, por lo menos desde Android. Flutter es como un pequeño ending de juegos, que te permite dibujar cualquier cosa por pantalla fácilmente, con lo cual puedes hacer realidad todas esas animaciones, todos esos diseños tan quizás complejos desde la vista de un programador; puedes hacerlos de una forma mucho más sencilla. En resumen, qué es más fácil crear estos diseños y animaciones, que hacen que estos prototipos de una app se vean tan bien y al fin y al cabo crean una aplicación más bonita y que gustará más a los usuarios. Además, también nos ahorramos el problema de algunas herramientas híbridas donde vemos distintas interfaces, dependiendo de la marca del móvil, dependiendo del sistema del usuario, de la versión del sistema, si no que se ve igual en todos los dispositivos, igual no; sino que depende de la plataforma. Obviamente sigue las guías de diseño de Android y las de IOS, así que tenemos esta distinción que siempre es muy buena, también hay que tener en cuenta que tenemos total libertad para cambiar esto y hacer que las versiones de Android y IOS sean totalmente distintas; así que en este aspecto no hay ningún problema. Y el quinto punto, es la facilidad de adaptación a los cambios: esto es muy importante, ya que ¿quién piensa que la tecnología que tenemos ahora, se mantendrá en un periodo de cinco-diez años? Pues nadie, cada día hay más y más dispositivos; pantallas inteligentes, los coches, tenemos muchas opciones y muchos dispositivos van a ir saliendo y que aún no han salido. Pese que flutter está ahora centrado en IOS y Android, es muy fácilmente trasladable a cualquier otra plataforma que tenga como medio principal de comunicación una pantalla. Es como un ending de juegos, ya se han creado herramientas para que funcione sobre Mac, Windows o Linux, esto quiere decir, que puedes crear una aplicación en Flutter para estos sistemas operativos. Y, de hecho, el propio flutter es la base sobre la que se sustenta Fuchsia, el nuevo sistema de Google, que seguramente va a tener muchas cosas que decir; esto quiere decir que es fácilmente adaptable a lo que pueda pasar en un futuro, tanto si salen nuevos sistemas operativos por el coste o el tiempo, o el contratar personal que nos va a requerir este nuevo sistema operativo. Si queremos estar en él, si mañana sale un nuevo sistema operativo móvil, por ejemplo, si tenemos aplicaciones nativas, vamos a tener que contratar otro equipo con sus costes y tiempo de desarrollo para estar en esa plataforma; o por ejemplo, si queremos que nuestra app se expanda a sistemas operativos que ya existen. Por ejemplo: digamos que tenemos una aplicación móvil y queremos crear una aplicación de escritorio para Mac, para Windows o para Linux. Imaginemos que tenemos una aplicación parecida a Whatsapp o alguna mensajería instantánea y creamos la aplicación móvil para Android y IOS, y la cosa va bien, y se decide que por ejemplo: sería una buena idea ir hacia Mac y hacia Windows. Si tuviéramos una aplicación nativa esto habría que pensarlo más de dos veces, porque esto supondría contratar desarrolladores que pudieran hacerlo para Windows y para Mac, aunque fueran los mismos desarrolladores. Tendrían que dedicar su tiempo a volver a programar todo para esas plataformas extra. Sin embargo, si tenemos flutter, si podemos portar la aplicación automáticamente, ajustando cuatro cosas a esos nuevos sistemas, sin tener que desarrollar todo desde cero, el resultado es que vamos a tener un coste muchísimo, muchísimo más bajo, y un tiempo de desarrollo mucho más bajo también. Y no vamos a requerir de un personal extra, ni vamos a requerir que las personas que tenemos aprendan esa nueva tecnología. Sino que con la que ya saben, van a poder utilizarlo y portar esa aplicación hacia los ordenadores, en este caso; con un click lo tendríamos listo, podríamos decir. The post <a href="https://diegolaballos.com/podcast/94-como-convencer-a-un-cliente-para-utilizar-flutter/" rel="nofollow" target="_blank">94. ¿Cómo convencer a un cliente para utilizar Flutter?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

94. ¿Cómo convencer a un cliente para utilizar Flutter?

Primero, hay que definir TDD. Son las siglas de Test Driven Development y básicamente consiste en programar tests automatizados antes incluso de programar una nueva funcionalidad.  Formas de añadir tests automatizados Volveremos a esta definición, pero antes, vamos a situarnos. Generalmente, hay varias formas de añadir tests automatizados. Cuando decidimos que los vamos a incluir en nuestro proyecto, hay varias formas de añadirlas.  La primera, es programar una aplicación y ya después, una vez que tenga varias funcionalidades y quizás haber estado publica para su descarga, se decide añadir estos test automatizados a posteriori, es decir, una vez la app está desarrollada. La segunda opción es ir programando funcionalidades e inmediatamente después añadir estos tests.  Finalmente, la tercera, es programar primero los tests y después programar la funcionalidad. Esta última en concreto, es la metodología TDD. Vayamos una por una y viendo qué ventajas e inconvenientes tienen Programar primero y añadir a posteriori tests automatizados En primer lugar, la opción de programar primero y después añadir estos tests automatizados (opción 1), tienen la ventaja de que puedes ir más rápido inicialmente, lo cual ya comentamos en el episodio anterior.  Si no tienes que programar estos tests automatizados, vas a necesitar menos tiempo para programar la aplicación, ya que es menos código el que tienes que escribir. Esto, también supone que el coste de desarrollo va a ser menor, por lo menos inicialmente. Entre las desventajas, está el coste que comentamos en todo el episodio anterior. Generalmente, se deciden añadir cuando se ve el problema, cuando se ve que el testing manual no es suficiente, que salen errores por todos lados y que hay que hacer algo. El problema aquí, es que puede ser muy complicado añadir tests, una vez que la aplicación está en una fase avanzada de desarrollo. La razón, es que para tener estos tests, se tienen que programar todas las funcionalidades de manera tal que sea testeable; y, esto, no es algo sencillo muchas veces. Es decir, tienes que programar teniendo en cuenta que luego tienes que escribir test automatizados fiables y que se puedan ejecutar bien. Si no programas con esto en la cabeza, es muy fácil que sigas avanzando y luego sea muy complicado añadir los tests. Otra desventaja clara, es que como añadirlos a posteriori va a ser más complicado, va a llevar más tiempo y, en consecuencia, más costoso.  No solo por añadir tests automatizados, sino por el hecho de que va a ser más complicado añadirlos y vamos a necesitar más tiempo para pensar como poder incluirlos dentro del proyecto. Asimismo, es muy probable que se tenga que tocar mucho código ya desarrollado. Programar funcionalidades y añadir a posteriori los tests La opción de programar funcionalidades e inmediatamente después añadir los tests, se observa con el siguiente ejemplo: cuando estés programando y decidas añadir un nuevo botón que muestra una imagen, lo que haces es programar esa pequeña funcionalidad y luego inmediatamente añades un tests que compruebe que lo que has hecho, está bien.  La ventaja de esto, es que tenemos tests, lo que significa estar seguro de que las funcionalidades que hemos programado funcionan y podemos demostrarlo rápidamente sin necesidad de recurrir a tests manuales que nos llevarían mucho tiempo. La primera desventaja, es que tardaremos un poco más programar, lo cual ya habíamos comentado. Si añades tests automatizados, tardas más en programar una funcionalidad porque tienes que escribir un poco más de código. Una segunda desventaja sería, por ejemplo, cuando empiezas a programar una funcionalidad y luego decides añadir unos tests, es muy fácil de que olvides de algunos casos de uso.  Programas muchas cosas, y luego, no te acuerdas de que hay cierta situación en donde tenías que añadir un test automatizado, y simplemente añades unos pocos. Por lo tanto, no cubres todos esos casos de uso que comentamos. Finalmente, puede darse el inconveniente de que tienes que cambiar la forma en la que has programado algo porque quizás te des cuentas que no es testeable o compatible con los tests automatizados que quieres escribir y, esto te llevaría más tiempo. Metodología TDD Por último, tenemos el método TDD que consiste en programar primero los tests, y luego las funcionalidades.  ¿En qué consistiría esto exactamente? Imaginemos una pantalla en donde al darle clic a un botón, aparece una imagen que viene de un servidor. Lo que haríamos con TDD, sería dividir en “micro tareas” esta gran tarea.  Primero, añadiríamos un test automatizado que, obviamente, al principio va a fallar porque no hay código escrito aún, y escribiríamos el código de programación hasta que este test funcionara. Luego, seguiríamos con la siguiente micro tarea, haciendo exactamente lo mismo. Por ejemplo, creo un test que me “comprueba que la imagen sale cuando doy clic a este botón”. En un principio, dado que el test va a fallar, lo que hago es programar esta funcionalidad hasta que sirva.  Posteriormente, voy a la siguiente micro tarea que por ejemplo sería, crear un test que “muestra un mensaje de error, si el servidor que arroja esta imagen, no responde”. De nuevo, lo mismo: el test que ejecuto al principio, no va a funcionar, por lo que escribo el código hasta que esto se cumpla. Así, sucesivamente, hasta terminar con todos los casos de uso. La ventaja de esto, es la misma que en la metodología anterior: tenemos tests y, por lo tanto, su beneficio que consiste en saber que estamos haciendo las cosas de forma segura y podemos demostrarlo.  La desventaja, es que tardamos más en programarlo. En este punto, ya es evidente que siempre que queramos añadir tests automatizados, vamos a tener esta desventaja que, en realidad no lo es, si recordamos todo lo que vimos en el episodio anterior. The post 93. ¿En qué consiste la metodología TDD? appeared first on Diego Laballós.

Primero, hay que definir TDD. Son las siglas de Test Driven Development y básicamente consiste en programar tests automatizados antes incluso de programar una nueva funcionalidad. <h3>Formas de añadir tests automatizados</h3> Volveremos a esta definición, pero antes, vamos a situarnos. Generalmente, hay varias formas de añadir tests automatizados. Cuando decidimos que los vamos a incluir en nuestro proyecto, hay varias formas de añadirlas. La primera, es programar una aplicación y ya después, una vez que tenga varias funcionalidades y quizás haber estado publica para su descarga, se decide añadir estos test automatizados a posteriori, es decir, una vez la app está desarrollada. La segunda opción es ir programando funcionalidades e inmediatamente después añadir estos tests. Finalmente, la tercera, es programar primero los tests y después programar la funcionalidad. Esta última en concreto, es la metodología TDD. Vayamos una por una y viendo qué ventajas e inconvenientes tienen <h3>Programar primero y añadir a posteriori tests automatizados</h3> En primer lugar, la opción de programar primero y después añadir estos tests automatizados (opción 1), tienen la ventaja de que puedes ir más rápido inicialmente, lo cual ya comentamos en el episodio anterior. Si no tienes que programar estos tests automatizados, vas a necesitar menos tiempo para programar la aplicación, ya que es menos código el que tienes que escribir. Esto, también supone que el coste de desarrollo va a ser menor, por lo menos inicialmente. Entre las desventajas, está el coste que comentamos en todo el episodio anterior. Generalmente, se deciden añadir cuando se ve el problema, cuando se ve que el testing manual no es suficiente, que salen errores por todos lados y que hay que hacer algo. El problema aquí, es que puede ser muy complicado añadir tests, una vez que la aplicación está en una fase avanzada de desarrollo. La razón, es que para tener estos tests, se tienen que programar todas las funcionalidades de manera tal que sea testeable; y, esto, no es algo sencillo muchas veces. Es decir, tienes que programar teniendo en cuenta que luego tienes que escribir test automatizados fiables y que se puedan ejecutar bien. Si no programas con esto en la cabeza, es muy fácil que sigas avanzando y luego sea muy complicado añadir los tests. Otra desventaja clara, es que como añadirlos a posteriori va a ser más complicado, va a llevar más tiempo y, en consecuencia, más costoso. No solo por añadir tests automatizados, sino por el hecho de que va a ser más complicado añadirlos y vamos a necesitar más tiempo para pensar como poder incluirlos dentro del proyecto. Asimismo, es muy probable que se tenga que tocar mucho código ya desarrollado. <h3>Programar funcionalidades y añadir a posteriori los tests</h3> La opción de programar funcionalidades e inmediatamente después añadir los tests, se observa con el siguiente ejemplo: cuando estés programando y decidas añadir un nuevo botón que muestra una imagen, lo que haces es programar esa pequeña funcionalidad y luego inmediatamente añades un tests que compruebe que lo que has hecho, está bien. La ventaja de esto, es que tenemos tests, lo que significa estar seguro de que las funcionalidades que hemos programado funcionan y podemos demostrarlo rápidamente sin necesidad de recurrir a tests manuales que nos llevarían mucho tiempo. La primera desventaja, es que tardaremos un poco más programar, lo cual ya habíamos comentado. Si añades tests automatizados, tardas más en programar una funcionalidad porque tienes que escribir un poco más de código. Una segunda desventaja sería, por ejemplo, cuando empiezas a programar una funcionalidad y luego decides añadir unos tests, es muy fácil de que olvides de algunos casos de uso. Programas muchas cosas, y luego, no te acuerdas de que hay cierta situación en donde tenías que añadir un test automatizado, y simplemente añades unos pocos. Por lo tanto, no cubres todos esos casos de uso que comentamos. Finalmente, puede darse el inconveniente de que tienes que cambiar la forma en la que has programado algo porque quizás te des cuentas que no es testeable o compatible con los tests automatizados que quieres escribir y, esto te llevaría más tiempo. <h3>Metodología TDD</h3> Por último, tenemos el método TDD que consiste en programar primero los tests, y luego las funcionalidades. ¿En qué consistiría esto exactamente? Imaginemos una pantalla en donde al darle clic a un botón, aparece una imagen que viene de un servidor. Lo que haríamos con TDD, sería dividir en “micro tareas” esta gran tarea. Primero, añadiríamos un test automatizado que, obviamente, al principio va a fallar porque no hay código escrito aún, y escribiríamos el código de programación hasta que este test funcionara. Luego, seguiríamos con la siguiente micro tarea, haciendo exactamente lo mismo. Por ejemplo, creo un test que me “comprueba que la imagen sale cuando doy clic a este botón”. En un principio, dado que el test va a fallar, lo que hago es programar esta funcionalidad hasta que sirva. Posteriormente, voy a la siguiente micro tarea que por ejemplo sería, crear un test que “muestra un mensaje de error, si el servidor que arroja esta imagen, no responde”. De nuevo, lo mismo: el test que ejecuto al principio, no va a funcionar, por lo que escribo el código hasta que esto se cumpla. Así, sucesivamente, hasta terminar con todos los casos de uso. La ventaja de esto, es la misma que en la metodología anterior: tenemos tests y, por lo tanto, su beneficio que consiste en saber que estamos haciendo las cosas de forma segura y podemos demostrarlo. La desventaja, es que tardamos más en programarlo. En este punto, ya es evidente que siempre que queramos añadir tests automatizados, vamos a tener esta desventaja que, en realidad no lo es, si recordamos todo lo que vimos en el episodio anterior. The post <a href="https://diegolaballos.com/podcast/93-en-que-consiste-la-metodologia-tdd/" rel="nofollow" target="_blank">93. ¿En qué consiste la metodología TDD?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

93. ¿En qué consiste la metodología TDD?

La principal razón por la que hago este episodio es que a veces es difícil explicar, a alguien que no tiene el conocimiento técnico, el por qué estos tests automatizados son necesarios y por qué hay que invertir en ellos. Para ello, vamos a hacer un breve resumen de lo que son, de qué tratan y cuál es su utilidad. ¿Cómo funcionan los tests automatizados? En primer lugar hay que mencionar que los tests automatizados son básicamente código de programación que verifica que todo funciona como debería. Es decir, código de programación que verifica otro código de programación. Sí es un poco enreversado, pero es así. Para verlo mejor con un ejemplo, imaginemos una aplicación muy simple que tiene un botón que, cuando se clica se va a la siguiente pantalla y nos muestra el tiempo que hace en Barcelona. Esto es un ejemplo muy simple, pero va a servir para verlo. Básicamente esta aplicación puede parecer algo muy sencillo, incluso podríamos definirla con una sola frase, con unas pocas palabras, es decir, una aplicación en la que clicas en un botón y obtienes el tiempo a través de un servidor; de un servidor cualquiera que tiene un servicio que devuelve los datos del tiempo en Barcelona. Tratando el tema de los test automatizados, lo que haríamos aquí es programar test automatizados que comprobarían que todo lo que vamos a programar funciona como debería.  Por ejemplo, el primer test podría ser que, cuando abro la app, me aparece un botón para ver el tiempo; y, otro test podría ser que cuando le doy a este botón obtengo la información de la temperatura que hace en Barcelona. Básicamente estos tests cumplen la misma función que haría una persona que prueba la aplicación, pero la diferencia es que, en vez de minutos en este caso, tardaría segundos.  El problema es que estos test hay que programarlos y esto tiene un coste y aquí es donde viene la cuestión que planteaba en un principio. Esta cuestión es que es difícil a veces si no se explica bien, justificar este coste a una persona que no tiene un perfil o un conocimiento tecnológicos; podríamos decir que esta aplicación tan simple, sin ningún tipo de tests automatizados, y solo programando lo que vendría a ser la funcionalidad, podríamos dar (por decir algo) 150 euros. Sin embargo, sí queremos añadir estos test automatizados, es decir, queremos programar estos tests para que se hagan de forma automatizada y que no los haga una persona manualmente; podríamos decir que tendría un coste extra de unos 50 euros; así que se situaría en torno a unos 200 más o menos. ¿Por qué no optar por la solución económica? Aquí viene el problema. SI lo miras desde esta perspectiva, simplemente con el coste es fácil optar por la solución económica, ya que el beneficio que obtienes de estos test automatizados, no parece ser tan grande.  Al fin y al cabo, es algo que puedes hacer manualmente en unos pocos minutos y te ahorras unos 50 euros. Pero, vamos a ver los costes reales de no explicar esto y en qué consisten exactamente los tests y donde está el beneficio real.  El primer punto a tener en cuenta es cualquier aplicación por simple que parezca no lo es tanto realmente. En este caso que estamos poniendo de ejemplo, se ha descrito esto como una app que, a través de un botón te da la temperatura de Barcelona. Sin embargo, vamos a ver todas las situaciones que realmente se pueden dar en esta aplicación tan sencilla. En primer lugar, tendríamos que verificar que la app muestre el botón inicial en la pantalla principal, después tendríamos que verificar qué pasa si estamos consultando el tiempo cuando no tenemos conexión a internet, que se muestre un mensaje de error coherente. Luego ¿Qué pasa si obtenemos la información del servidor, pero este no responde por cualquier motivo. ¿Qué pasa si el servidor responde, pero con unos datos que la aplicación no entiende, porque está algo mal el servidor y nos devuelve unos datos que están mal; ¿Qué mostramos al usuario en ese caso? También puede ser, que obviamente el servidor te devuelva la información correcta, en ese caso tienes que poder ver la información del tiempo en Barcelona. Y también finalmente deberíamos comprobar que después de consultar el tiempo, puede volver atrás para volver a consultarlo otra vez; poder navegar entre las dos pantallas sin ningún problema. Lo que era una app, sencilla, extremadamente sencilla, ahora ya no lo es tanto. Tiene varios casos de uso. Ahora vamos a imaginar esto con una app de verdad o ya puestos, con esta misma aplicación, pero añadiéndole algo más como opciones para consultar cualquier localidad, para ponerla tú a través del teclado, quizás una opción para obtener la localidad automáticamente a través del GPS, mostrar más datos del tiempo, etc. Podríamos seguir añadiendo cosas hasta hacerla una aplicación que realmente fuera útil, que realmente fuera una aplicación de verdad. Los casos de uso como se pueden ver, se van incrementando, incrementando exponencialmente ¿qué pasa? Cada vez que añadamos algo más dentro de la aplicación, que la actualicemos, que hagamos cualquier cosa, deberíamos probar todos estos casos uno por uno, para asegurarnos que todo funciona. Da igual el cambio que hagamos, que sea un cambio muy pequeño, que sea una cosa que sólo afecte una parte de la app. Cualquier cambio en el código, puede afectar cualquier parte de la aplicación y puede producir un error; esto es así y es cómo funciona la programación.  A todo esto, tenemos que añadirle un punto súper importante dentro de los móviles, y es que lo que funciona en un móvil puede ser que no funcione en otro. O, lo que funciona en una versión de Android o de IOS, puede ser que no funcione en otra. Hay muchos motivos por los cuales esto puede pasar, pero esto es así.  De repente todas las situaciones se van incrementando cada vez más; en un mundo ideal tendríamos que ir paso a paso por todas estas situaciones, a través de diferentes móviles y de versiones de sistema operativo para estar seguros de que nuestra app funciona al cien por cien. Si no lo hacemos, básicamente no podemos estar seguros de que nuestra app funciona y si aparece un error, es lo más normal del mundo, puede pasar y cuanto menos probemos, más posibilidades tenemos de que aparezca un error. Obviamente es imposible probar todo al cien por cien, aunque tengamos test automatizados, aunque hagamos miles y miles de test manuales; es imposible estar seguro y los errores van a aparecer, es algo que está ahí, que todas las aplicaciones tienen. El problema es que cuanto menos probemos, más errores vamos a tener. Esto nos lleva al tema del episodio:  el coste de no tener test automatizados. Desventajas de no tener test automatizados Supongamos que una app normal tiene unas cien situaciones que deberíamos probar y, realmente estoy siendo muy generoso, porque cualquier aplicación tiene más de 20,30,40, 50 funcionalidades y estas pueden tener diferentes situaciones; se pueden ver envueltas en distintas situaciones. En el caso de que no tengamos test automatizados, tendremos una persona, la figura del tester que se encargará de probar todos estos tests, los hará manualmente y básicamente se va a dedicar a ello. Esta persona, obviamente va cobrar un salario por hacer ese trabajo y cuantos más casos de uso tengamos, más tiempo va a necesitar esa persona o más personas vamos a necesitar.  Por otro lado, si tenemos test automatizados, la figura del tester sigue siendo imprescindible, por lo menos para probar los casos principales, pero quizás un 80% de los casos pueden estar cubiertos por estos test automatizados, que lo hacen en pocos segundos. Y lo más importante de todo, no cobran nada por hacerlo, porque básicamente son máquinas; si hacemos cuentas, los test automatizados, aunque tengamos que invertir un poco en su desarrollo inicialmente y luego de vez en cuando son infinitamente mucho más económicos que probar todo manualmente, que tener varias personas probando la aplicación constantemente cada vez que haces un cambio; y aquí es donde se ve el coste real. Los tests, una vez están hechos, no necesitan cambiarse si nada es diferente. Sin embargo, los test manuales son imposibles de automatizar, porque, al fin y al cabo, son manuales. Vas a tener que estar pagando a esa gente, que se ocupa de hacerlos de forma manual con lo cual si comparas los salarios de esa gente que tienes que tener, con el coste que te supone desarrollar los test automatizados únicamente una vez, no hay ni comparación con el coste. The post 92. El coste de no tener tests automatizados appeared first on Diego Laballós.

La principal razón por la que hago este episodio es que a veces es difícil explicar, a alguien que no tiene el conocimiento técnico, el por qué estos tests automatizados son necesarios y por qué hay que invertir en ellos. Para ello, vamos a hacer un breve resumen de lo que son, de qué tratan y cuál es su utilidad. <h3>¿Cómo funcionan los tests automatizados?</h3> En primer lugar hay que mencionar que los tests automatizados son básicamente código de programación que verifica que todo funciona como debería. Es decir, código de programación que verifica otro código de programación. Sí es un poco enreversado, pero es así. Para verlo mejor con un ejemplo, imaginemos una aplicación muy simple que tiene un botón que, cuando se clica se va a la siguiente pantalla y nos muestra el tiempo que hace en Barcelona. Esto es un ejemplo muy simple, pero va a servir para verlo. Básicamente esta aplicación puede parecer algo muy sencillo, incluso podríamos definirla con una sola frase, con unas pocas palabras, es decir, una aplicación en la que clicas en un botón y obtienes el tiempo a través de un servidor; de un servidor cualquiera que tiene un servicio que devuelve los datos del tiempo en Barcelona. Tratando el tema de los test automatizados, lo que haríamos aquí es programar test automatizados que comprobarían que todo lo que vamos a programar funciona como debería. Por ejemplo, el primer test podría ser que, cuando abro la app, me aparece un botón para ver el tiempo; y, otro test podría ser que cuando le doy a este botón obtengo la información de la temperatura que hace en Barcelona. Básicamente estos tests cumplen la misma función que haría una persona que prueba la aplicación, pero la diferencia es que, en vez de minutos en este caso, tardaría segundos. El problema es que estos test hay que programarlos y esto tiene un coste y aquí es donde viene la cuestión que planteaba en un principio. Esta cuestión es que es difícil a veces si no se explica bien, justificar este coste a una persona que no tiene un perfil o un conocimiento tecnológicos; podríamos decir que esta aplicación tan simple, sin ningún tipo de tests automatizados, y solo programando lo que vendría a ser la funcionalidad, podríamos dar (por decir algo) 150 euros. Sin embargo, sí queremos añadir estos test automatizados, es decir, queremos programar estos tests para que se hagan de forma automatizada y que no los haga una persona manualmente; podríamos decir que tendría un coste extra de unos 50 euros; así que se situaría en torno a unos 200 más o menos. <h3>¿Por qué no optar por la solución económica?</h3> Aquí viene el problema. SI lo miras desde esta perspectiva, simplemente con el coste es fácil optar por la solución económica, ya que el beneficio que obtienes de estos test automatizados, no parece ser tan grande. Al fin y al cabo, es algo que puedes hacer manualmente en unos pocos minutos y te ahorras unos 50 euros. Pero, vamos a ver los costes reales de no explicar esto y en qué consisten exactamente los tests y donde está el beneficio real. El primer punto a tener en cuenta es cualquier aplicación por simple que parezca no lo es tanto realmente. En este caso que estamos poniendo de ejemplo, se ha descrito esto como una app que, a través de un botón te da la temperatura de Barcelona. Sin embargo, vamos a ver todas las situaciones que realmente se pueden dar en esta aplicación tan sencilla. En primer lugar, tendríamos que verificar que la app muestre el botón inicial en la pantalla principal, después tendríamos que verificar qué pasa si estamos consultando el tiempo cuando no tenemos conexión a internet, que se muestre un mensaje de error coherente. Luego ¿Qué pasa si obtenemos la información del servidor, pero este no responde por cualquier motivo. ¿Qué pasa si el servidor responde, pero con unos datos que la aplicación no entiende, porque está algo mal el servidor y nos devuelve unos datos que están mal; ¿Qué mostramos al usuario en ese caso? También puede ser, que obviamente el servidor te devuelva la información correcta, en ese caso tienes que poder ver la información del tiempo en Barcelona. Y también finalmente deberíamos comprobar que después de consultar el tiempo, puede volver atrás para volver a consultarlo otra vez; poder navegar entre las dos pantallas sin ningún problema. Lo que era una app, sencilla, extremadamente sencilla, ahora ya no lo es tanto. Tiene varios casos de uso. Ahora vamos a imaginar esto con una app de verdad o ya puestos, con esta misma aplicación, pero añadiéndole algo más como opciones para consultar cualquier localidad, para ponerla tú a través del teclado, quizás una opción para obtener la localidad automáticamente a través del GPS, mostrar más datos del tiempo, etc. Podríamos seguir añadiendo cosas hasta hacerla una aplicación que realmente fuera útil, que realmente fuera una aplicación de verdad. Los casos de uso como se pueden ver, se van incrementando, incrementando exponencialmente ¿qué pasa? Cada vez que añadamos algo más dentro de la aplicación, que la actualicemos, que hagamos cualquier cosa, deberíamos probar todos estos casos uno por uno, para asegurarnos que todo funciona. Da igual el cambio que hagamos, que sea un cambio muy pequeño, que sea una cosa que sólo afecte una parte de la app. Cualquier cambio en el código, puede afectar cualquier parte de la aplicación y puede producir un error; esto es así y es cómo funciona la programación. A todo esto, tenemos que añadirle un punto súper importante dentro de los móviles, y es que lo que funciona en un móvil puede ser que no funcione en otro. O, lo que funciona en una versión de Android o de IOS, puede ser que no funcione en otra. Hay muchos motivos por los cuales esto puede pasar, pero esto es así. De repente todas las situaciones se van incrementando cada vez más; en un mundo ideal tendríamos que ir paso a paso por todas estas situaciones, a través de diferentes móviles y de versiones de sistema operativo para estar seguros de que nuestra app funciona al cien por cien. Si no lo hacemos, básicamente no podemos estar seguros de que nuestra app funciona y si aparece un error, es lo más normal del mundo, puede pasar y cuanto menos probemos, más posibilidades tenemos de que aparezca un error. Obviamente es imposible probar todo al cien por cien, aunque tengamos test automatizados, aunque hagamos miles y miles de test manuales; es imposible estar seguro y los errores van a aparecer, es algo que está ahí, que todas las aplicaciones tienen. El problema es que cuanto menos probemos, más errores vamos a tener. Esto nos lleva al tema del episodio: el coste de no tener test automatizados. <h3>Desventajas de no tener test automatizados</h3> Supongamos que una app normal tiene unas cien situaciones que deberíamos probar y, realmente estoy siendo muy generoso, porque cualquier aplicación tiene más de 20,30,40, 50 funcionalidades y estas pueden tener diferentes situaciones; se pueden ver envueltas en distintas situaciones. En el caso de que no tengamos test automatizados, tendremos una persona, la figura del tester que se encargará de probar todos estos tests, los hará manualmente y básicamente se va a dedicar a ello. Esta persona, obviamente va cobrar un salario por hacer ese trabajo y cuantos más casos de uso tengamos, más tiempo va a necesitar esa persona o más personas vamos a necesitar. Por otro lado, si tenemos test automatizados, la figura del tester sigue siendo imprescindible, por lo menos para probar los casos principales, pero quizás un 80% de los casos pueden estar cubiertos por estos test automatizados, que lo hacen en pocos segundos. Y lo más importante de todo, no cobran nada por hacerlo, porque básicamente son máquinas; si hacemos cuentas, los test automatizados, aunque tengamos que invertir un poco en su desarrollo inicialmente y luego de vez en cuando son infinitamente mucho más económicos que probar todo manualmente, que tener varias personas probando la aplicación constantemente cada vez que haces un cambio; y aquí es donde se ve el coste real. Los tests, una vez están hechos, no necesitan cambiarse si nada es diferente. Sin embargo, los test manuales son imposibles de automatizar, porque, al fin y al cabo, son manuales. Vas a tener que estar pagando a esa gente, que se ocupa de hacerlos de forma manual con lo cual si comparas los salarios de esa gente que tienes que tener, con el coste que te supone desarrollar los test automatizados únicamente una vez, no hay ni comparación con el coste. The post <a href="https://diegolaballos.com/podcast/92-el-coste-de-no-tener-tests-automatizados/" rel="nofollow" target="_blank">92. El coste de no tener tests automatizados</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

92. El coste de no tener tests automatizados

Lanzar una aplicación en su versión 1.0, es en realidad el primer paso; no todo el trabajo está hecho ni mucho menos. De hecho, cualquier versión 1.0 de toda aplicación, es la peor versión que va a tener. En teoría, esa tiene que ser la primera de muchas más versiones. Cada versión posterior, tiene que ser mejor y mejor, al menos, idealmente. Hay muchas razones para actualizar una app y ya hablamos de ello en otro episodio, pero en esta ocasión, nos vamos a centrar en las actualizaciones que se hacen simplemente para seguir mejorando la aplicación. Hay muchas formas en las cuales podemos mejorar una app: corregir errores, hacer pequeños cambios en la interfaz de un usuario, hacerla más rápida, añadir más funcionalidades (o incluso eliminarlas). Lo importante, es saber si lo que hacemos tiene efecto o no. Esto, lo podemos hacer básicamente de dos formas. La primera es basarnos en la intuición y en nuestras opiniones de lo que creemos que va a ser mejor, va a gustar más, y que va a hacer que la aplicación sea mejor de cara a los usuarios. Sin embargo, esta no es una buena opción, ya que te estás basando en la opinión/intuición de una sola persona o de unas cuantas para seguir mejorando una aplicación de cara a muchísimos usuarios que pueden tener opiniones muy distintas a la tuya. La otra opción que tenemos, es la de mejorar una aplicación basándonos en los datos, en lo que los usuarios ya están haciendo dentro de la app. Obviamente, ésta es mejor, porque si te estás basando en los datos, no te estás basando en la opinión de una única persona, sino que lo haces con base en la de muchas más personas que están utilizando esa aplicación y que están interesadas en ese producto o servicio. Concepto de Funnel / KPIs Para ello, lo primero que debemos saber, es cómo medimos si un cambio ha sido para peor o para mejor, y esto nos lleva al concepto de funnel o de KPIS. Estos proyectos están muy presentes en metodologías que también hemos comentado aquí, como el Lean Startup o el Growth Hacking. Funnel, es la serie de pasos que un usuario tiene que seguir para completar una acción que queremos que haga. Por ejemplo, en un e-commerce, el funnel, podría ser, por ejemplo, en orden, descargarse la aplicación, registrarse, añadir productos al carrito de la compra, y al final, comprar el producto. Este, es el funnel o la serie de pasos que queremos que hagan nuestros usuarios. Este funnel, lo que indica, es el porcentaje de usuarios que se van perdiendo en cada paso hasta llegar al paso final que nos interesa.  Por ejemplo, quizás se dé el caso de que un 80% de usuarios sí se registran; un 50% añaden un producto al carrito y finalmente, solo un 20% compran algo.  sto es lo que pasa en cualquier aplicación hasta que queremos que lleguen a ese punto final; siempre vamos perdiendo usuarios y los motivos pueden ser bastante distintos. Lo importante es saber cuántos usuarios estamos perdiendo en cada paso para poder irlo mejorando.  Por otro lado, los KPIs, son algo muy parecido: son indicadores que nos hacen ver de una forma más rápida si nuestros objetivos se están cumpliendo o no.  Por ejemplo, en el e-commerce, podemos tener ciertos indicadores como los ingresos por usuarios, o la tasa de registros que nos darán una información muy rápida de lo que está pasando dentro de nuestra aplicación. Por ejemplo, en el caso de los ingresos por usuario en una aplicación de e-commerce, podríamos decir que inicialmente, empieza con 20 euros por usuario y, el objetivo sería tener al menos 100 euros por usuario.  Sucede lo mismo con la tasa de registro o cualquier tipo de KPI. Es más o menos igual al funnel. Nos permite ver de forma rápida cómo está funcionando nuestra aplicación; si va mejor o si va peor.  El objetivo es utilizarlos para medir todos los cambios que vamos añadiendo. Cada uno de ellos (funnels o KPIs) que tengamos, van a depender del tipo de proyecto y de los objetivos que tengamos con la aplicación.  También hay que decir que estos conceptos se basan en los datos que tienes de tu aplicación. Es decir, que, sobre todo, debes tener un sistema de analytics que te permita crear esto. Si no tienes analytics, no tienes datos, y por lo tanto, no puedes hacer nada: ni funnels, ni KPIs. Quizás si podrías hacer algo con la base de datos, pero lo normal, es tener un sistema de analytics que además de guardar todos esos datos que recibes de los usuarios, te permita crear estos funnels y KPIs de forma más visual, agradable y automatizada; y no tener que crear estos funnels y KPIs, que sería mucho más tedioso. Si tienes un sistema de analytics, automáticamente estos datos se van actualizando a cada momento, y es muy fácil ver a la evolución. ¿De que nos sirven esos indicadores? Así que, a través de estos indicadores podemos ver fácilmente si un cambio surte efecto; así como medir su nivel de éxito o fracaso: corregir un error, cambios y aceleración de la interfaz, inclusión o eliminación de funcionalidades, etc. Por ejemplo, retomando el ejemplo de la aplicación de e-commerce, podemos suponer una tasa de registro baja, de un 60% (sólo un 60% de los usuarios que descargan la app, se registran). Un problema que podríamos tener es que tenemos una modalidad de registro basada en el e-mail, y éste, siempre es un poco complicado a través de los móviles, ya que lo tienes que hacer manualmente y el teclado de un móvil no es como el del ordenador. Por tanto, podríamos hacer la hipótesis de que si añadimos registro con redes sociales (los botones de Facebook o Google) y hacerlo mucho más fácil para el usuario (quizás en 2 segundos se puedan registrar), seguramente podríamos tener más registros y, por tanto, mejor la tasa de registros.  Al añadir este cambio, podemos mirar cómo ha evolucionado nuestro funnel o KPIs y analizar si esa funcionalidad que acabamos de añadir, ha mejorado la tasa de registro, o no. Si no la ha mejorado, lo que tenemos que hacer es volver atrás, al registro con email y mirar otra forma de mejorar esa tasa; en cambio, si la ha mejorado y se ha cumplido nuestra hipótesis, dejamos ese cambio y seguimos adelante con nuevos hipótesis y así, continuar mejorando esa tasa en caso de ser necesario. Podríamos poner otro ejemplo: una aplicación que tiene anuncios, en donde queremos mejorar los ingresos por usuario. Una hipótesis inicial podría ser, que, poniendo más anuncios en alguna parte de la pantalla de la aplicación, podríamos obtener más ingresos, al tener generar más vistas de esos anuncios.  ¿Ha surtido efecto el cambio? De la misma forma, si lo implementamos y luego medimos esa tasa de ingresos, podemos ver fácilmente si ha surtido efecto o no.  Un aspecto importante, es que no solo hay que fijarse si un KPI determinado ha mejorado o no; sino que siempre tenemos que mirar “en general” si una funcionalidad, podría estar afectando a otro KPI o punto del funnel y podríamos no darnos cuenta si solo valoramos un paso del funnel o KPI. Me explico, en este ejemplo de los anuncios, nuestra hipótesis de aumentar los anuncios, podría funcionar en el corto plazo y ese KPI de los ingresos por usuario, suba. Esto tiene mucho sentido porque estás poniendo mas anuncios.  Sin embargo, por otro lado, estaríamos perdiendo en el KPI de retención de usuarios: por poner más anuncios, los usuarios se enfadan y están menos tiempo en la aplicación; de una semana de retención, pasaríamos a 3 días, porque los usuarios se cansan de ver anuncios y la desinstalan. Así que, puede ser que un cambio afecte positivamente a una parte del funnel, y afecte negativamente a otra. Por lo tanto, la valoración siempre tiene que ser en general. Al fin y al cabo, para mejorar nuestra app, tenemos que seguir la metodología lean start up: hacer una hipótesis, implementarla, verificarla, mantenerla / eliminarla. Y así en todo momento, es un bucle sin fin. The post 91. ¿Cómo mejorar una aplicación? appeared first on Diego Laballós.

Lanzar una aplicación en su versión 1.0, es en realidad el primer paso; no todo el trabajo está hecho ni mucho menos. De hecho, cualquier versión 1.0 de toda aplicación, es la peor versión que va a tener. En teoría, esa tiene que ser la primera de muchas más versiones. Cada versión posterior, tiene que ser mejor y mejor, al menos, idealmente. Hay muchas razones para actualizar una app y ya hablamos de ello en otro episodio, pero en esta ocasión, nos vamos a centrar en las actualizaciones que se hacen simplemente para seguir mejorando la aplicación. Hay muchas formas en las cuales podemos mejorar una app: corregir errores, hacer pequeños cambios en la interfaz de un usuario, hacerla más rápida, añadir más funcionalidades (o incluso eliminarlas). Lo importante, es saber si lo que hacemos tiene efecto o no. Esto, lo podemos hacer básicamente de dos formas. La primera es basarnos en la intuición y en nuestras opiniones de lo que creemos que va a ser mejor, va a gustar más, y que va a hacer que la aplicación sea mejor de cara a los usuarios. Sin embargo, esta no es una buena opción, ya que te estás basando en la opinión/intuición de una sola persona o de unas cuantas para seguir mejorando una aplicación de cara a muchísimos usuarios que pueden tener opiniones muy distintas a la tuya. La otra opción que tenemos, es la de mejorar una aplicación basándonos en los datos, en lo que los usuarios ya están haciendo dentro de la app. Obviamente, ésta es mejor, porque si te estás basando en los datos, no te estás basando en la opinión de una única persona, sino que lo haces con base en la de muchas más personas que están utilizando esa aplicación y que están interesadas en ese producto o servicio. <h3>Concepto de Funnel / KPIs</h3> Para ello, lo primero que debemos saber, es cómo medimos si un cambio ha sido para peor o para mejor, y esto nos lleva al concepto de funnel o de KPIS. Estos proyectos están muy presentes en metodologías que también hemos comentado aquí, como el Lean Startup o el Growth Hacking. Funnel, es la serie de pasos que un usuario tiene que seguir para completar una acción que queremos que haga. Por ejemplo, en un e-commerce, el funnel, podría ser, por ejemplo, en orden, descargarse la aplicación, registrarse, añadir productos al carrito de la compra, y al final, comprar el producto. Este, es el funnel o la serie de pasos que queremos que hagan nuestros usuarios. Este funnel, lo que indica, es el porcentaje de usuarios que se van perdiendo en cada paso hasta llegar al paso final que nos interesa. Por ejemplo, quizás se dé el caso de que un 80% de usuarios sí se registran; un 50% añaden un producto al carrito y finalmente, solo un 20% compran algo. sto es lo que pasa en cualquier aplicación hasta que queremos que lleguen a ese punto final; siempre vamos perdiendo usuarios y los motivos pueden ser bastante distintos. Lo importante es saber cuántos usuarios estamos perdiendo en cada paso para poder irlo mejorando. Por otro lado, los KPIs, son algo muy parecido: son indicadores que nos hacen ver de una forma más rápida si nuestros objetivos se están cumpliendo o no. Por ejemplo, en el e-commerce, podemos tener ciertos indicadores como los ingresos por usuarios, o la tasa de registros que nos darán una información muy rápida de lo que está pasando dentro de nuestra aplicación. Por ejemplo, en el caso de los ingresos por usuario en una aplicación de e-commerce, podríamos decir que inicialmente, empieza con 20 euros por usuario y, el objetivo sería tener al menos 100 euros por usuario. Sucede lo mismo con la tasa de registro o cualquier tipo de KPI. Es más o menos igual al funnel. Nos permite ver de forma rápida cómo está funcionando nuestra aplicación; si va mejor o si va peor. El objetivo es utilizarlos para medir todos los cambios que vamos añadiendo. Cada uno de ellos (funnels o KPIs) que tengamos, van a depender del tipo de proyecto y de los objetivos que tengamos con la aplicación. También hay que decir que estos conceptos se basan en los datos que tienes de tu aplicación. Es decir, que, sobre todo, debes tener un sistema de analytics que te permita crear esto. Si no tienes analytics, no tienes datos, y por lo tanto, no puedes hacer nada: ni funnels, ni KPIs. Quizás si podrías hacer algo con la base de datos, pero lo normal, es tener un sistema de analytics que además de guardar todos esos datos que recibes de los usuarios, te permita crear estos funnels y KPIs de forma más visual, agradable y automatizada; y no tener que crear estos funnels y KPIs, que sería mucho más tedioso. Si tienes un sistema de analytics, automáticamente estos datos se van actualizando a cada momento, y es muy fácil ver a la evolución. <h3>¿De que nos sirven esos indicadores?</h3> Así que, a través de estos indicadores podemos ver fácilmente si un cambio surte efecto; así como medir su nivel de éxito o fracaso: corregir un error, cambios y aceleración de la interfaz, inclusión o eliminación de funcionalidades, etc. Por ejemplo, retomando el ejemplo de la aplicación de e-commerce, podemos suponer una tasa de registro baja, de un 60% (sólo un 60% de los usuarios que descargan la app, se registran). Un problema que podríamos tener es que tenemos una modalidad de registro basada en el e-mail, y éste, siempre es un poco complicado a través de los móviles, ya que lo tienes que hacer manualmente y el teclado de un móvil no es como el del ordenador. Por tanto, podríamos hacer la hipótesis de que si añadimos registro con redes sociales (los botones de Facebook o Google) y hacerlo mucho más fácil para el usuario (quizás en 2 segundos se puedan registrar), seguramente podríamos tener más registros y, por tanto, mejor la tasa de registros. Al añadir este cambio, podemos mirar cómo ha evolucionado nuestro funnel o KPIs y analizar si esa funcionalidad que acabamos de añadir, ha mejorado la tasa de registro, o no. Si no la ha mejorado, lo que tenemos que hacer es volver atrás, al registro con email y mirar otra forma de mejorar esa tasa; en cambio, si la ha mejorado y se ha cumplido nuestra hipótesis, dejamos ese cambio y seguimos adelante con nuevos hipótesis y así, continuar mejorando esa tasa en caso de ser necesario. Podríamos poner otro ejemplo: una aplicación que tiene anuncios, en donde queremos mejorar los ingresos por usuario. Una hipótesis inicial podría ser, que, poniendo más anuncios en alguna parte de la pantalla de la aplicación, podríamos obtener más ingresos, al tener generar más vistas de esos anuncios. <h3>¿Ha surtido efecto el cambio?</h3> De la misma forma, si lo implementamos y luego medimos esa tasa de ingresos, podemos ver fácilmente si ha surtido efecto o no. Un aspecto importante, es que no solo hay que fijarse si un KPI determinado ha mejorado o no; sino que siempre tenemos que mirar “en general” si una funcionalidad, podría estar afectando a otro KPI o punto del funnel y podríamos no darnos cuenta si solo valoramos un paso del funnel o KPI. Me explico, en este ejemplo de los anuncios, nuestra hipótesis de aumentar los anuncios, podría funcionar en el corto plazo y ese KPI de los ingresos por usuario, suba. Esto tiene mucho sentido porque estás poniendo mas anuncios. Sin embargo, por otro lado, estaríamos perdiendo en el KPI de retención de usuarios: por poner más anuncios, los usuarios se enfadan y están menos tiempo en la aplicación; de una semana de retención, pasaríamos a 3 días, porque los usuarios se cansan de ver anuncios y la desinstalan. Así que, puede ser que un cambio afecte positivamente a una parte del funnel, y afecte negativamente a otra. Por lo tanto, la valoración siempre tiene que ser en general. Al fin y al cabo, para mejorar nuestra app, tenemos que seguir la metodología lean start up: hacer una hipótesis, implementarla, verificarla, mantenerla / eliminarla. Y así en todo momento, es un bucle sin fin. The post <a href="https://diegolaballos.com/podcast/91-como-mejorar-una-aplicacion/" rel="nofollow" target="_blank">91. ¿Cómo mejorar una aplicación?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

91. ¿Cómo mejorar una aplicación?

¿Quieres crear una app? ¿Quieres aprender a desarrollarlas tú mismo? ó ¿simplemente tienes curiosidad por saber qué hay detrás de todas esas aplicaciones que utilizamos hoy en día? Quizás te pueda interesar este podcast semanal que hago cada miércoles a partir de las 8 AM.

Creando Apps

En este episodio número 10 del podcast trataremos de aclarar un poco más el tema del desarrollo backend. Que mejor manera de hacerlo que con un invitado que se dedica precisamente a ello, Nate Gentile. Con él volveremos a ver qué es un servidor y trataremos de explicar de una forma sencilla de qué se encargan. Veremos que los servidores son los cerebros reales de todas las aplicaciones que utilizamos hoy en día y que, aunque no los vemos, estamos comunicándonos con ellos cada día. Nate nos intentará explicar un poco en qué consiste el trabajo de un desarrollador backend. Nos contará cómo tiene que definir toda la lógica de un sistema informático, definir cómo se guardarán los datos y establecer unos métodos de comunicación para las aplicaciones que utilicen todos estos datos. Como nos explicará nuestro invitado, el mundo backend es un poco más extenso y complejo que el de las aplicaciones móviles y hay muchos lenguajes y tecnologías a nuestra disposición. Es por esto que si queremos encontrar un desarrollador backend para nuestro proyecto, deberemos tratar de encontrar a alguien con conocimientos técnicos que nos asesore para saber qué tecnología sería más conveniente utilizar. De todas maneras, si no tenemos acceso a esta persona técnica que nos ayude, una buena decisión sería elegir una tecnología o lenguaje popular para poder acceder a un abanico más amplio de profesionales. También como ya hicimos con Android y iOS, Nate nos recomendará algunos recursos por si queremos empezar a estudiar y adentrarnos en este mundo del desarrollo backend. Concretamente nos recomendará las webs de Coursera y Udacity. Podéis encontrar a Nate principalmente en su canal de Youtube, donde explica temas relacionados con la informática, la programación y el mundo de los videojuegos. Para acabar, si este podcast te parece útil, puedes dejarme una recomendación en iTunes o en iVoox. Para cualquier duda o sugerencia puedes contactar directamente conmigo a través de mi formulario de contacto. ¡Hasta el miércoles que viene a las 8 AM! The post 10. ¿A qué se dedica un desarrollador backend? – Con Nate Gentile appeared first on Diego Laballós.

En este episodio número 10 del podcast trataremos de aclarar un poco más el tema del desarrollo backend. Que mejor manera de hacerlo que con un invitado que se dedica precisamente a ello, Nate Gentile. Con él volveremos a ver qué es un servidor y trataremos de explicar de una forma sencilla de qué se encargan. Veremos que los servidores son los cerebros reales de todas las aplicaciones que utilizamos hoy en día y que, aunque no los vemos, estamos comunicándonos con ellos cada día. Nate nos intentará explicar un poco en qué consiste el trabajo de un desarrollador backend. Nos contará cómo tiene que definir toda la lógica de un sistema informático, definir cómo se guardarán los datos y establecer unos métodos de comunicación para las aplicaciones que utilicen todos estos datos. Como nos explicará nuestro invitado, el mundo backend es un poco más extenso y complejo que el de las aplicaciones móviles y hay muchos lenguajes y tecnologías a nuestra disposición. Es por esto que si queremos encontrar un desarrollador backend para nuestro proyecto, deberemos tratar de encontrar a alguien con conocimientos técnicos que nos asesore para saber qué tecnología sería más conveniente utilizar. De todas maneras, si no tenemos acceso a esta persona técnica que nos ayude, una buena decisión sería elegir una tecnología o lenguaje popular para poder acceder a un abanico más amplio de profesionales. También como ya hicimos con Android y iOS, Nate nos recomendará algunos recursos por si queremos empezar a estudiar y adentrarnos en este mundo del desarrollo backend. Concretamente nos recomendará las webs de <a href="https://www.coursera.org/" rel="nofollow" target="_blank">Coursera</a> y <a href="https://www.udacity.com/" rel="nofollow" target="_blank">Udacity</a>. Podéis encontrar a Nate principalmente en su <a href="https://www.youtube.com/channel/UC36xmz34q02JYaZYKrMwXng" rel="nofollow" target="_blank">canal de Youtube</a>, donde explica temas relacionados con la informática, la programación y el mundo de los videojuegos. Para acabar, si este podcast te parece útil, puedes dejarme una recomendación en <a href="https://itunes.apple.com/es/podcast/apprendiendo-lanza-tu-aplicacion/id1203392005" rel="nofollow" target="_blank">iTunes</a> o en <a href="http://www.ivoox.com/podcast-apprendiendo-lanza-tu-aplicacion-movil_sq_f1388837_1.html" rel="nofollow" target="_blank">iVoox</a>. Para cualquier duda o sugerencia puedes contactar directamente conmigo a través de <a href="/contactar" rel="nofollow" target="_blank">mi formulario de contacto</a>. ¡Hasta el miércoles que viene a las 8 AM! The post <a href="https://diegolaballos.com/podcast/10-a-que-se-dedica-un-desarrollador-backend-con-nate-gentile/" rel="nofollow" target="_blank">10. ¿A qué se dedica un desarrollador backend? – Con Nate Gentile</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

10. ¿A qué se dedica un desarrollador backend? – Con Nate Gentile

Como comentaba en la introducción, hasta el momento, por un lado hemos visto que para crear aplicaciones en Android necesitábamos aprender Java y Android, o contactar a un desarrollador de aplicaciones para Android; y por otro lado, para crear aplicaciones en iPhone y  IPad  necesitábamos aprender o bien Swift y iOS, o contactar con un desarrollador de aplicaciones para iOS. ¿En qué consiste el desarrollo backend Pues bien, si dejáramos de lado el desarrollo back-end, que habíamos comentado por arriba y no habíamos visto, las aplicaciones que podríamos crear con esto, serían muy básicas; serían aplicaciones que no utilizarían internet. ¿Por qué? Porque para crear aplicaciones que utilicen internet, necesitaríamos tener un servidor.  Esta parte es la que hasta ahora estábamos llamando desarrollo back-end y lo estábamos dejando un poco de lado porque necesitaba un capítulo entero para explicarlo, así que vamos a ello. Para entender esto, vamos a ver un poco por encima como funciona la gran mayoría de aplicaciones que utilizamos hoy en dia. Veamos por ejemplo, cómo funciona Facebook, muy por encima. Cada vez que abres Facebook, te salen una serie de publicaciones ¿De dónde salen estas publicaciones? Estas publicaciones salen de internet sí, pero esto es un poco general. En realidad, están saliendo de un servidor de Facebook. Un servidor no es mas que un ordenador en algún lugar del mundo conectado a internet, que se encarga de conectar y servir información de una aplicación. En este caso concreto, los servidores de Facebook se encargan de almacenar toda la información de la red social y la distribuyen a los distintos usuarios que la pidan.  Realmente, el corazón de Facebook, lo que lo hace funcionar,  no está en nuestros móviles ni en nuestro navegador del ordenador; está todo en un servidor, en un almacén inteligente podríamos decir. Lo que tu móvil hace cada vez que entras a la aplicación de Facebook, es preguntar a este servidor de Facebook que le proporcione las siguientes publicaciones a mostrar, por ejemplo. ¿Cómo lo hace? Se comunica a través de internet. De la misma manera que en un ordenador, vamos a Google Chrome y visitamos Facebook.com, nuestra aplicación móvil hace algo parecido pero de forma oculta podríamos decir. En ambos casos se está preguntando al servidor a través de internet por una información y, el servidor responde con todo lo que le pedimos. Al igual que recibimos información, también podemos enviar nosotros cosas a este servidor. Por ejemplo, cuando subimos una foto nueva, ya sea a través del web o del móvil, le estamos diciendo al servidor Hey servidor, súbeme esta foto a mi perfil de Facebook. Es lo mismo que anteriormente pero la información va al revés. En este caso el servidor recibe nuestra foto y sabe que hacer con ella, donde guardarla, como posicionarla y toda la información que va en ella.  Lo importante aquí es el papel del servidor. Realmente es lo que hace funcionar a Facebook o cualquier otra aplicación. Android, iOS, o la web, son simplemente interfaces de usuario que muestran estos datos de una forma visual. Podríamos hacer un símil con la vida real. Por ejemplo, la televisión. ¿Qué pasa si compras una televisión y no le conectas una antena? Pues poco podrás hacer la verdad. Quien realmente tiene los datos de las imágenes y el audio de la tele, es el cable de la antena. Lo que pasa es que, para transformar los datos en algo visible, necesitamos una televisión. Realmente en este caso, el cable no sería el servidor, sino el medio mediante el cual se transmite. Sería el internet en el caso de las aplicaciones. Creo que se puede entender. Vamos a ver otro ejemplo para poder aclarar esto del servidor. Imaginemos Whatsapp. Cada vez que estamos enviando un mensaje, realmente no estamos enviando mensajes de un dispositivo a otro directamente; siempre hay un servidor de por medio. En primer lugar, estamos diciéndole al servidor envía este mensaje, a esta persona. Y, el servidor, es el encargado de decir vale, le envío a esta persona que tiene tal dispositivo. Siempre, está el servidor de por medio. Esto es lo mismo con casi cualquier aplicación. La gran mayoría de aplicaciones que tenemos instaladas en nuestro móvil, tienen sus propios servidores. ¿Por qué es importante saber esto? Porque si nosotros queremos crear una aplicaicones, seguramente tenemos que tener uno. Pero, ¿Cuándo necesito un servidor y cuando no? ¿Por qué realmente no tienes que necesitar uno? Pues bien, si tus usuarios pueden crear cuentas y logearse; si pueden comunicarse con otros usuarios, si pueden buscar información dinámica y cambiante en la aplicación, esto es un signo de que necesitaras un servidor. El único caso en donde tu app no necesitaba un servidor es si esta app es muy simple y no necesita acceder a internet. Por ejemplo, un reloj, una calculadora, una cámara o un reproductor de música, serían aplicaciones que podrían funcionar sin un servidor. Sin embargo, aplicaciones como redes sociales, de compra-venta de productos, reservas de hoteles, de mensajería, todas ellas van a necesitar sí o sí un servidor.  En general, como decía, si tu aplicación sirve información cambiante o tiene que poder comunicar a usuarios entre sí, necesitará un servidor. Vamos a imaginar al servidor como un almacén; realmente será eso, un almacén de datos. Por ejemplo, en el caso de una red social, en nuestro servidor, almacenaríamos todos los usuarios, su información personal y sus publicaciones. Pero, como ya hemos visto, el servidor no es solo un almacén; es un almacén inteligente. Cada vez que alguien le pregunta por algo, sabe cómo reaccionar ante ello. Si un móvil, le pide subir una publicación, sabe donde tiene que guardarla; si otro le pregunta por las publicaciones de “Pepito”, sabe cuales son y dónde están. Programación de servidores Pero, ¿Cómo puede tener esa inteligencia? Pues porque el servidor es programable. Una vez más, recordar que el servidor no es más que un ordenador, y como cualquier ordenador, se puede programar sobre él. Muy bien, y ¿Quién programa esto? Pues, esto nos lleva al punto que resumíamos en dos palabras: desarrollador back-end. Podríamos decir que un desarrollador back-end, es el encargado de configurar y programar tu almacén de datos o servidor. Se encarga de guardar todos tus datos de forma ordenada y de establecer unos métodos de comunicación para tus aplicaciones. A través de estos métodos de comunicación que desarrolle el programador back-end, tus aplicaciones podrán preguntar por datos y dar órdenes al servidor. ¿Qué pasa si no tenemos un servidor para almacenar los datos de nuestra aplicación? En este caso, la información no podría ser guardada más allá del dispositivo del usuario.  Imaginemos una red social sin servidor, ¿Podría hacerse? Sí que podría hacerse pero sería un poco inservible. El usuario podría empezar a subir fotos pero estas se guardarían en su dispositivo. Obviamente, no podría ver las fotos de nadie, porque cada usuario tendría las fotos en su móvil y no irían más allá; no hay una forma de que compartan información entre ellos. Además, en el momento en que el usuario desinstalara la aplicación de su móvil, todos sus datos se perderían. Se borra la aplicación y los datos asociados en el dispositivo así que, ¿Dónde quedarían todas esas publicaciones? En ningún lugar, porque no hay un servidor que las esté almacenando. The post 9. ¿Qué es un servidor y qué funciones cumple? appeared first on Diego Laballós.

Como comentaba en la introducción, hasta el momento, por un lado hemos visto que para crear aplicaciones en Android necesitábamos aprender Java y Android, o contactar a un desarrollador de aplicaciones para Android; y por otro lado, para crear aplicaciones en iPhone y IPad necesitábamos aprender o bien Swift y iOS, o contactar con un desarrollador de aplicaciones para iOS. <h3>¿En qué consiste el desarrollo backend</h3> Pues bien, si dejáramos de lado el desarrollo back-end, que habíamos comentado por arriba y no habíamos visto, las aplicaciones que podríamos crear con esto, serían muy básicas; serían aplicaciones que no utilizarían internet. ¿Por qué? Porque para crear aplicaciones que utilicen internet, necesitaríamos tener un servidor. Esta parte es la que hasta ahora estábamos llamando desarrollo back-end y lo estábamos dejando un poco de lado porque necesitaba un capítulo entero para explicarlo, así que vamos a ello. Para entender esto, vamos a ver un poco por encima como funciona la gran mayoría de aplicaciones que utilizamos hoy en dia. Veamos por ejemplo, cómo funciona Facebook, muy por encima. Cada vez que abres Facebook, te salen una serie de publicaciones ¿De dónde salen estas publicaciones? Estas publicaciones salen de internet sí, pero esto es un poco general. En realidad, están saliendo de un servidor de Facebook. Un servidor no es mas que un ordenador en algún lugar del mundo conectado a internet, que se encarga de conectar y servir información de una aplicación. En este caso concreto, los servidores de Facebook se encargan de almacenar toda la información de la red social y la distribuyen a los distintos usuarios que la pidan. Realmente, el corazón de Facebook, lo que lo hace funcionar, no está en nuestros móviles ni en nuestro navegador del ordenador; está todo en un servidor, en un almacén inteligente podríamos decir. Lo que tu móvil hace cada vez que entras a la aplicación de Facebook, es preguntar a este servidor de Facebook que le proporcione las siguientes publicaciones a mostrar, por ejemplo. ¿Cómo lo hace? Se comunica a través de internet. De la misma manera que en un ordenador, vamos a Google Chrome y visitamos <a href="http://Facebook.com" rel="nofollow" target="_blank">Facebook.com</a>, nuestra aplicación móvil hace algo parecido pero de forma oculta podríamos decir. En ambos casos se está preguntando al servidor a través de internet por una información y, el servidor responde con todo lo que le pedimos. Al igual que recibimos información, también podemos enviar nosotros cosas a este servidor. Por ejemplo, cuando subimos una foto nueva, ya sea a través del web o del móvil, le estamos diciendo al servidor Hey servidor, súbeme esta foto a mi perfil de Facebook. Es lo mismo que anteriormente pero la información va al revés. En este caso el servidor recibe nuestra foto y sabe que hacer con ella, donde guardarla, como posicionarla y toda la información que va en ella. Lo importante aquí es el papel del servidor. Realmente es lo que hace funcionar a Facebook o cualquier otra aplicación. Android, iOS, o la web, son simplemente interfaces de usuario que muestran estos datos de una forma visual. Podríamos hacer un símil con la vida real. Por ejemplo, la televisión. ¿Qué pasa si compras una televisión y no le conectas una antena? Pues poco podrás hacer la verdad. Quien realmente tiene los datos de las imágenes y el audio de la tele, es el cable de la antena. Lo que pasa es que, para transformar los datos en algo visible, necesitamos una televisión. Realmente en este caso, el cable no sería el servidor, sino el medio mediante el cual se transmite. Sería el internet en el caso de las aplicaciones. Creo que se puede entender. Vamos a ver otro ejemplo para poder aclarar esto del servidor. Imaginemos Whatsapp. Cada vez que estamos enviando un mensaje, realmente no estamos enviando mensajes de un dispositivo a otro directamente; siempre hay un servidor de por medio. En primer lugar, estamos diciéndole al servidor envía este mensaje, a esta persona. Y, el servidor, es el encargado de decir vale, le envío a esta persona que tiene tal dispositivo. Siempre, está el servidor de por medio. Esto es lo mismo con casi cualquier aplicación. La gran mayoría de aplicaciones que tenemos instaladas en nuestro móvil, tienen sus propios servidores. ¿Por qué es importante saber esto? Porque si nosotros queremos crear una aplicaicones, seguramente tenemos que tener uno. Pero, ¿Cuándo necesito un servidor y cuando no? ¿Por qué realmente no tienes que necesitar uno? Pues bien, si tus usuarios pueden crear cuentas y logearse; si pueden comunicarse con otros usuarios, si pueden buscar información dinámica y cambiante en la aplicación, esto es un signo de que necesitaras un servidor. El único caso en donde tu app no necesitaba un servidor es si esta app es muy simple y no necesita acceder a internet. Por ejemplo, un reloj, una calculadora, una cámara o un reproductor de música, serían aplicaciones que podrían funcionar sin un servidor. Sin embargo, aplicaciones como redes sociales, de compra-venta de productos, reservas de hoteles, de mensajería, todas ellas van a necesitar sí o sí un servidor. En general, como decía, si tu aplicación sirve información cambiante o tiene que poder comunicar a usuarios entre sí, necesitará un servidor. Vamos a imaginar al servidor como un almacén; realmente será eso, un almacén de datos. Por ejemplo, en el caso de una red social, en nuestro servidor, almacenaríamos todos los usuarios, su información personal y sus publicaciones. Pero, como ya hemos visto, el servidor no es solo un almacén; es un almacén inteligente. Cada vez que alguien le pregunta por algo, sabe cómo reaccionar ante ello. Si un móvil, le pide subir una publicación, sabe donde tiene que guardarla; si otro le pregunta por las publicaciones de “Pepito”, sabe cuales son y dónde están. <h3>Programación de servidores</h3> Pero, ¿Cómo puede tener esa inteligencia? Pues porque el servidor es programable. Una vez más, recordar que el servidor no es más que un ordenador, y como cualquier ordenador, se puede programar sobre él. Muy bien, y ¿Quién programa esto? Pues, esto nos lleva al punto que resumíamos en dos palabras: desarrollador back-end. Podríamos decir que un desarrollador back-end, es el encargado de configurar y programar tu almacén de datos o servidor. Se encarga de guardar todos tus datos de forma ordenada y de establecer unos métodos de comunicación para tus aplicaciones. A través de estos métodos de comunicación que desarrolle el programador back-end, tus aplicaciones podrán preguntar por datos y dar órdenes al servidor. ¿Qué pasa si no tenemos un servidor para almacenar los datos de nuestra aplicación? En este caso, la información no podría ser guardada más allá del dispositivo del usuario. Imaginemos una red social sin servidor, ¿Podría hacerse? Sí que podría hacerse pero sería un poco inservible. El usuario podría empezar a subir fotos pero estas se guardarían en su dispositivo. Obviamente, no podría ver las fotos de nadie, porque cada usuario tendría las fotos en su móvil y no irían más allá; no hay una forma de que compartan información entre ellos. Además, en el momento en que el usuario desinstalara la aplicación de su móvil, todos sus datos se perderían. Se borra la aplicación y los datos asociados en el dispositivo así que, ¿Dónde quedarían todas esas publicaciones? En ningún lugar, porque no hay un servidor que las esté almacenando. The post <a href="https://diegolaballos.com/podcast/9-que-es-un-servidor-y-que-funciones-cumple/" rel="nofollow" target="_blank">9. ¿Qué es un servidor y qué funciones cumple?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

9. ¿Qué es un servidor y qué funciones cumple?

Primera duda que puede tener cualquier persona que se plantee empezar a crear aplicaciones para iOS: ¿es difícil o puede hacerlo cualquier persona? Lo mismo que dije en el episodio 5: la programación, que será lo que necesitamos aprender para crear aplicaciones, no es algo que sea difícil, sino más bien complejo. Hay muchos conceptos nuevos y muchas cosas que aprender. Pero, es algo que, si se estudia poco a poco y se entiende, no es difícil. Así que, ¿está al alcance de cualquier persona? Yo diría que sí, teniendo ganas de aprender y dedicando tiempo. Pero, obviamente cada persona es distinta y cada una necesitará más o menos tiempo para aprender todos estos nuevos conceptos. Antes de ver qué pasos tenemos que seguir para aprender a programar para iOS, debemos saber qué tenemos exactamente que estudiar y cuál es nuestra meta final. Para ello, tenemos que ver los lenguajes de programación de iOS. Lenguajes de programación utilizados en iOS Cuando salió iOS con el lanzamiento del primer iPhone, el lenguaje con el cual se podían programar aplicaciones, se llamaba Objective-C. Sin embargo, en 2014, Apple lanzó un nuevo lenguaje llamado Swift que, hoy en día, es el principal lenguaje utilizado para programar para cualquier sistema de Apple. Este nuevo lenguaje, va recibiendo año tras año nuevas actualizaciones y mejorándose a sí mismo. Actualmente estamos en la versión de Swift 3. Así que, hoy en día, tenemos dos opciones para programar una app en iOS: Objective-C o Swift. Objective-C vs Swift Ahora bien, ¿cuál deberíamos aprender y qué diferencias hay entre ellos? En primer lugar, Objective-C, era un lenguaje un poco más enrevesado, complejo y a bajo nivel podríamos decir. Swift, por lado, es un lenguaje más moderno, más parecido a lenguajes comunes de más alto nivel. Generalmente, se necesitan más líneas para hacer lo mismo en Objective-C, que, en Swift, por lo cual podríamos hacer una conclusión rápida que Swift es un lenguaje más sencillo y más apropiado para estos tiempos. Vistas estas diferencias y teniendo en cuenta que Apple lo creó hace poco y lo está actualizando constantemente, yo te recomendaría, sin ninguna duda, que aprendieras Swift. Y, es el que vamos a proponer aquí como ejemplo. Barrera de entrada para programar para iOS Perfecto, ahora ya sabemos que nuestro objetivo es aprender a programar en Swift, que es el lenguaje principal para crear aplicaciones para Ios. Ahora, tenemos que ver una pequeña barrera de entrada que tenemos a la hora de crear aplicaciones para iPhone, IPad, incluso Mac y todo lo que tienen que ver con el mundo Apple. Resulta que, para crear aplicaciones en estos sistemas, necesitamos un programa llamado Xcode. Este programa, es el encargado de facilitarnos la vida a la hora de crear aplicaciones y nos permitirá convertir a todo nuestro código en una aplicación real. Este programa, obviamente propiedad de Apple sólo está disponible en macOS, el sistema operativo que llevan todos los Mac. Con lo cual, quiere decir que necesitaremos un Mac para poder programar para iOS. Es una pequeña barrera de entrada que no tiene Android, donde puedes programar tanto en Mac, Windows o Linux, da igual el sistema en el que estés. Pasos para programar para iOS Visto este apunte, vamos a ver los pasos que tendríamos que seguir e iremos bastante rápido porque como ya hemos dicho, tenemos que seguir los mismos pasos de Android al principio.  El primero es la programación básica. Tendremos que empezar a estudiar todo esto de la programación y empezar a ver instrucciones básicas como los condicionales, los bucles o las variables. El problema aquí, es que la mayoría del material que se puede encontrar en internet, de programación básica, no va a estar en Swift. La mayor parte de libros, artículos o cursos, suelen estar en otros lenguajes más generalistas o populares como Java o PHP. Swift, como ya hemos visto, es un lenguaje muy reciente y que, además, nos sirve solamente para desarrollar para sistemas de Apple, lo cual ambas cosas contribuyen a que no sea un lenguaje muy popular a la hora de enseñar en la educación.  De todas maneras, en el caso de que no puedas encontrar un curso de iniciación en Swift, no pasa nada. Puedes aprender programación básica en Java que, al fin al cabo, es lo mismo. Luego, simplemente tendrás que aprender cómo hacer lo mismo en Swift, pero, verás como simplemente cambian cuatro pinceladas; el concepto que es lo más importante, es el mismo. Dejaré en las notas del programa dos cursos para este paso. El primero es un curso de Udacity, completamente gratuito, pero en inglés, donde se ve programación básica con Swift.  El segundo es un curso también de Udacity enfocado para alguien que ya sabe programación básica y simplemente necesita ver cómo se hace en Swift. Este curso sería muy útil para lo que ya comentaba anteriormente, de aprender con otro lenguaje. De todas formas, para alguien que no sabe nada de programación, yo le recomendaría aprender con alguno de los materiales que proponía en el capítulo 5, ya que entran más en profundidad a ver y entender los conceptos, aunque estén hechos en Java. Y, después, una vez que los conceptos están aprendidos, me iría a ver este curso que decía ahora de Swift, para gente que ya sabe de programación básica. El siguiente paso, después de la programación básica (ya sea porque hemos hecho un curso de programación básica con Swift o, como recomiendo yo, haciendo uno de programación básica en otro lenguaje y luego pasar por Swift), es la programación orientada a objetos (POO). Como comentábamos en el mismo capítulo 5 al que hago referencia, la POO es una forma de programar.  Necesitamos estudiar a fondo todos los conceptos de POO porque iOS, al igual que Android, es un sistema totalmente orientado a objetos. Creo recordar que los cursos de Udacity que decía antes, ya introducen la POO. Así que, de alguna manera, ya estaríamos aprendiendo esta programación. De la misma manera que recomendaba hacer un curso más completo de programación básica en otro lenguaje, lo mismo digo aquí. Recomendaría hacer uno de los cursos de POO que proponía en el capítulo de Android y luego, extrapolarlo a Swift porque, una vez más, todo es lo mismo o casi igual. El concepto que es lo que realmente importa, va a ser el mismo. Con lo cual, es mejor incluso hacer un curso en otro lenguaje que entre más a fondo en los conceptos y luego, traducirlo a Swift. Vamos al siguiente gran y último paso: aprender iOS. Ahora mismo, tendríamos que saber programar tanto a nivel básico como orientado a objetos, a través del lenguaje Swift. Ahora tenemos que estudiar de qué se componen las aplicaciones de iOS, crear interfaces de usuario, responder a los eventos, utilizar el hardware del móvil, etc. Todo ello lo haremos estudiando iOS, el framework. Como dije en Android, lo mismo en iOS, este paso es infinito. iOS es un sistema enorme con miles de funcionalidades y es imposible saber utilizar todas y cada una de ellas. Se trata de obtener una buena base y a partir de ahí, ir aprendiendo a medida que los proyectos que hagamos, lo vayan necesitando. 3 recursos para aprender a programar para iOS Para ello voy a dejar en las notas del programa, tres recursos, todos ellos bastante completos y que nos guiaran paso a paso a través de todo este mundo de iOS. El primero está en inglés y gratuito de la web que llevo diciendo todo el rato, pero es muy buena: Udacity y son una serie de cursos. El segundo es en inglés también y es de una web de pago: Raywanderlich que está, sobre todo, especializada en el desarrollo de iOS. Son cursos en video que cubren desde lo más básico hasta incluso cosas bastante avanzadas. Por último, una web de cursos en español que ya mencioné en el capítulo de Android: Platzi, donde encontraremos varios cursos interesantes de desarrollo de iOS. Ahora que en este podcast ya hemos temas de desarrollo en Android y iOS, nos falta una gran pieza del desarrollo de aplicaciones: el desarrollo back-end. Y si, esto será el tema del siguiente capítulo. Veremos temas de servidores, de comunicación con aplicaciones, bases de datos, etc. Empezaremos a indagar en todos estos conceptos que la gran mayoría de aplicaciones utilizan y hacen verdaderamente útil una aplicación. Si solo programáramos en Android o iOS, sin un desarrollo back-end, la verdad que las aplicaciones no serían tan útiles como hoy en día. De todas maneras, por ahora vamos a dejarlo ahí y en el siguiente capítulo veremos todo lo que hay detrás del desarrollo o programación back-end. Links:  Swift para principiantes – Udacity Aprende la sintaxis de Swift – Udacity Swift para desarrolladores – Udacity Introducción a iOS – Udacity Principios de UIKit – Udacity Web de cursos de iOS – Raywenderlich Curso de programación iOS – Platzi  The post 8. ¿Qué necesito aprender para crear aplicaciones para iOS? appeared first on Diego Laballós.

Primera duda que puede tener cualquier persona que se plantee empezar a crear aplicaciones para iOS: ¿es difícil o puede hacerlo cualquier persona? Lo mismo que dije en el episodio 5: la programación, que será lo que necesitamos aprender para crear aplicaciones, no es algo que sea difícil, sino más bien complejo. Hay muchos conceptos nuevos y muchas cosas que aprender. Pero, es algo que, si se estudia poco a poco y se entiende, no es difícil. Así que, ¿está al alcance de cualquier persona? Yo diría que sí, teniendo ganas de aprender y dedicando tiempo. Pero, obviamente cada persona es distinta y cada una necesitará más o menos tiempo para aprender todos estos nuevos conceptos. Antes de ver qué pasos tenemos que seguir para aprender a programar para iOS, debemos saber qué tenemos exactamente que estudiar y cuál es nuestra meta final. Para ello, tenemos que ver los lenguajes de programación de iOS. <h3>Lenguajes de programación utilizados en iOS</h3> Cuando salió iOS con el lanzamiento del primer iPhone, el lenguaje con el cual se podían programar aplicaciones, se llamaba Objective-C. Sin embargo, en 2014, Apple lanzó un nuevo lenguaje llamado Swift que, hoy en día, es el principal lenguaje utilizado para programar para cualquier sistema de Apple. Este nuevo lenguaje, va recibiendo año tras año nuevas actualizaciones y mejorándose a sí mismo. Actualmente estamos en la versión de Swift 3. Así que, hoy en día, tenemos dos opciones para programar una app en iOS: Objective-C o Swift. <h3>Objective-C vs Swift</h3> Ahora bien, ¿cuál deberíamos aprender y qué diferencias hay entre ellos? En primer lugar, Objective-C, era un lenguaje un poco más enrevesado, complejo y a bajo nivel podríamos decir. Swift, por lado, es un lenguaje más moderno, más parecido a lenguajes comunes de más alto nivel. Generalmente, se necesitan más líneas para hacer lo mismo en Objective-C, que, en Swift, por lo cual podríamos hacer una conclusión rápida que Swift es un lenguaje más sencillo y más apropiado para estos tiempos. Vistas estas diferencias y teniendo en cuenta que Apple lo creó hace poco y lo está actualizando constantemente, yo te recomendaría, sin ninguna duda, que aprendieras Swift. Y, es el que vamos a proponer aquí como ejemplo. <h3>Barrera de entrada para programar para iOS</h3> Perfecto, ahora ya sabemos que nuestro objetivo es aprender a programar en Swift, que es el lenguaje principal para crear aplicaciones para Ios. Ahora, tenemos que ver una pequeña barrera de entrada que tenemos a la hora de crear aplicaciones para iPhone, IPad, incluso Mac y todo lo que tienen que ver con el mundo Apple. Resulta que, para crear aplicaciones en estos sistemas, necesitamos un programa llamado Xcode. Este programa, es el encargado de facilitarnos la vida a la hora de crear aplicaciones y nos permitirá convertir a todo nuestro código en una aplicación real. Este programa, obviamente propiedad de Apple sólo está disponible en macOS, el sistema operativo que llevan todos los Mac. Con lo cual, quiere decir que necesitaremos un Mac para poder programar para iOS. Es una pequeña barrera de entrada que no tiene Android, donde puedes programar tanto en Mac, Windows o Linux, da igual el sistema en el que estés. <h3>Pasos para programar para iOS</h3> Visto este apunte, vamos a ver los pasos que tendríamos que seguir e iremos bastante rápido porque como ya hemos dicho, tenemos que seguir los mismos pasos de Android al principio. El primero es la programación básica. Tendremos que empezar a estudiar todo esto de la programación y empezar a ver instrucciones básicas como los condicionales, los bucles o las variables. El problema aquí, es que la mayoría del material que se puede encontrar en internet, de programación básica, no va a estar en Swift. La mayor parte de libros, artículos o cursos, suelen estar en otros lenguajes más generalistas o populares como Java o PHP. Swift, como ya hemos visto, es un lenguaje muy reciente y que, además, nos sirve solamente para desarrollar para sistemas de Apple, lo cual ambas cosas contribuyen a que no sea un lenguaje muy popular a la hora de enseñar en la educación. De todas maneras, en el caso de que no puedas encontrar un curso de iniciación en Swift, no pasa nada. Puedes aprender programación básica en Java que, al fin al cabo, es lo mismo. Luego, simplemente tendrás que aprender cómo hacer lo mismo en Swift, pero, verás como simplemente cambian cuatro pinceladas; el concepto que es lo más importante, es el mismo. Dejaré en las notas del programa dos cursos para este paso. El primero es un curso de Udacity, completamente gratuito, pero en inglés, donde se ve programación básica con Swift. El segundo es un curso también de Udacity enfocado para alguien que ya sabe programación básica y simplemente necesita ver cómo se hace en Swift. Este curso sería muy útil para lo que ya comentaba anteriormente, de aprender con otro lenguaje. De todas formas, para alguien que no sabe nada de programación, yo le recomendaría aprender con alguno de los materiales que proponía en el capítulo 5, ya que entran más en profundidad a ver y entender los conceptos, aunque estén hechos en Java. Y, después, una vez que los conceptos están aprendidos, me iría a ver este curso que decía ahora de Swift, para gente que ya sabe de programación básica. El siguiente paso, después de la programación básica (ya sea porque hemos hecho un curso de programación básica con Swift o, como recomiendo yo, haciendo uno de programación básica en otro lenguaje y luego pasar por Swift), es la programación orientada a objetos (POO). Como comentábamos en el mismo capítulo 5 al que hago referencia, la POO es una forma de programar. Necesitamos estudiar a fondo todos los conceptos de POO porque iOS, al igual que Android, es un sistema totalmente orientado a objetos. Creo recordar que los cursos de Udacity que decía antes, ya introducen la POO. Así que, de alguna manera, ya estaríamos aprendiendo esta programación. De la misma manera que recomendaba hacer un curso más completo de programación básica en otro lenguaje, lo mismo digo aquí. Recomendaría hacer uno de los cursos de POO que proponía en el capítulo de Android y luego, extrapolarlo a Swift porque, una vez más, todo es lo mismo o casi igual. El concepto que es lo que realmente importa, va a ser el mismo. Con lo cual, es mejor incluso hacer un curso en otro lenguaje que entre más a fondo en los conceptos y luego, traducirlo a Swift. Vamos al siguiente gran y último paso: aprender iOS. Ahora mismo, tendríamos que saber programar tanto a nivel básico como orientado a objetos, a través del lenguaje Swift. Ahora tenemos que estudiar de qué se componen las aplicaciones de iOS, crear interfaces de usuario, responder a los eventos, utilizar el hardware del móvil, etc. Todo ello lo haremos estudiando iOS, el framework. Como dije en Android, lo mismo en iOS, este paso es infinito. iOS es un sistema enorme con miles de funcionalidades y es imposible saber utilizar todas y cada una de ellas. Se trata de obtener una buena base y a partir de ahí, ir aprendiendo a medida que los proyectos que hagamos, lo vayan necesitando. <h3>3 recursos para aprender a programar para iOS</h3> Para ello voy a dejar en las notas del programa, tres recursos, todos ellos bastante completos y que nos guiaran paso a paso a través de todo este mundo de iOS. El primero está en inglés y gratuito de la web que llevo diciendo todo el rato, pero es muy buena: Udacity y son una serie de cursos. El segundo es en inglés también y es de una web de pago: Raywanderlich que está, sobre todo, especializada en el desarrollo de iOS. Son cursos en video que cubren desde lo más básico hasta incluso cosas bastante avanzadas. Por último, una web de cursos en español que ya mencioné en el capítulo de Android: Platzi, donde encontraremos varios cursos interesantes de desarrollo de iOS. Ahora que en este podcast ya hemos temas de desarrollo en Android y iOS, nos falta una gran pieza del desarrollo de aplicaciones: el desarrollo back-end. Y si, esto será el tema del siguiente capítulo. Veremos temas de servidores, de comunicación con aplicaciones, bases de datos, etc. Empezaremos a indagar en todos estos conceptos que la gran mayoría de aplicaciones utilizan y hacen verdaderamente útil una aplicación. Si solo programáramos en Android o iOS, sin un desarrollo back-end, la verdad que las aplicaciones no serían tan útiles como hoy en día. De todas maneras, por ahora vamos a dejarlo ahí y en el siguiente capítulo veremos todo lo que hay detrás del desarrollo o programación back-end. <h3>Links:</h3> <ul> <li><a href="https://www.udacity.com/course/swift-for-beginners--ud1022" rel="noopener noreferrer nofollow" target="_blank">Swift para principiantes – Udacity</a></li> <li><a href="https://www.udacity.com/course/learn-swift-programming-syntax--ud902" rel="noopener noreferrer nofollow" target="_blank">Aprende la sintaxis de Swift – Udacity</a></li> <li><a href="https://www.udacity.com/course/swift-for-developers--ud1025" rel="noopener noreferrer nofollow" target="_blank">Swift para desarrolladores – Udacity</a></li> <li><a href="https://www.udacity.com/course/intro-to-ios-app-development-with-swift--ud585" rel="noopener noreferrer nofollow" target="_blank">Introducción a iOS – Udacity</a></li> <li><a href="https://www.udacity.com/course/uikit-fundamentals--ud788" rel="noopener noreferrer nofollow" target="_blank">Principios de UIKit – Udacity</a></li> <li><a href="https://www.raywenderlich.com/" rel="noopener noreferrer nofollow" target="_blank">Web de cursos de iOS – Raywenderlich</a></li> <li><a href="https://platzi.com/cursos/programacion-apps-iphone-ipad-swift/" rel="noopener noreferrer nofollow" target="_blank">Curso de programación iOS – Platzi</a></li> </ul> The post <a href="https://diegolaballos.com/podcast/8-que-necesito-aprender-para-crear-aplicaciones-para-ios/" rel="nofollow" target="_blank">8. ¿Qué necesito aprender para crear aplicaciones para iOS?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

8. ¿Qué necesito aprender para crear aplicaciones para iOS?

Lo primero que debemos de decir sobre este tema es que en nuestra opinión no hay una opción mejor ni una opción peor, simplemente depende de la persona; a una persona le puede parecer mejor una opción y otra persona le puede parecer mejor la otra opción.  No hay una respuesta universal, de todas formas, vamos a intentar dividir todas estas diferencias, estos puntos débiles a través de distintos puntos y comentarlos de la forma más objetiva posible. Facilidad para empezar El primer punto que queremos comentar es la facilidad para empezar, de introducirte en el mundo, de empezar a funcionar En el caso de trabajar para una empresa es la facilidad de conseguir ese primer trabajo y en el caso de ser freelance sería la facilidad de conseguir los suficientes clientes como para vivir de ello. Aquí no tenemos ninguna duda de que lo mejor es trabajar para una empresa, aunque encontrar un primer trabajo siempre es difícil, más difícil es conseguir los primeros clientes. La diferencia es que una vez consigas el primer trabajo ya lo tienes, ya has empezado, ya estás dentro. Todo va a ser mucho más fácil.  Sin embargo, en el caso de ser freelance en el caso de coger tu primer cliente, no significa nada sino consigues más o si sólo te dura un mes ese proyecto. Tienes que estar constantemente buscando nuevos clientes o manteniendo los que ya tienes con lo cual es mucho, mucho más difícil. Futuro y progresión La verdad es que esto es bastante relativo; para una empresa puedes llegar a puestos de mucha responsabilidad, de la misma manera trabajando como freelance también puedes hacerlo, puedes optar a proyectos bastante grandes.  En mi opinión es más fácil tener responsabilidades como freelance. Las tienes desde el primer momento ya que vas a llevar proyectos por ti mismo, quizás al principio más pequeños, pero a medida que vas avanzando también serán más grandes, digamos que puedes llegar alto en ambos casos. Sin embargo, en mi opinión, como freelance llegas más rápido a proyectos grandes y de responsabilidad. El sueldo El sueldo también es algo muy relativo. Inicialmente sueles cobrar más trabajando para una empresa, esto es obvio, empiezas con un trabajo, ya tienes un sueldo fijo. Cuando tú empiezas como freelance y al principio no tienes muchos clientes, obviamente vas a cobrar bastante menos.  El empezar como freelance es complicado, sin embargo, a largo plazo es más sencillo cobrar como freelance que en una empresa.En una empresa también puedes llegar a cobrar sueldos más altos, pero es mucho más complicado, al fin y al cabo, siendo freelance eres tu propia empresa, cuando tú trabajas como freelance cobras el proyecto íntegro. Una empresa, sin embargo, no destina todas sus ganancias a los sueldos, digamos hay gasto de oficina, gastos de personal; obviamente se reparten unos beneficios o genera unos beneficios, que es a lo que normalmente una empresa está destinada. Y normalmente esta empresa no está hecha para que sus trabajadores ganen más dinero, sino que lo hagan los inversores, los accionistas, llámalo como quieras.  Siendo freelance tú eres tu propio inversor, eres tu accionista, así que el dinero que ganes va a ir mucho más íntegro a lo que viene a ser, podríamos decir tu sueldo. Inicialmente puede ser más fácil cobrar más en una empresa, pero a la larga va a ser más fácil cobrar más como freelance, al fin y al cabo, estás trabajando para ti mismo. Tú vas a decidir lo que cobras y con el paso del tiempo vas a ver que puedes ir cobrando más por lo que haces. Tienes más experiencia, accedes a más clientes, etc.  Flexibilidad y libertad Aquí sí absolutamente no hay ninguna duda y quizás sea el punto que más nos gusta de ser freelance, por mucho que algunas empresas se esfuercen por temas de flexibilidad horaria y libertad para el trabajador; ser freelance te hace mucho, mucho más flexible y te dará mucha más libertad. Obviamente, también dependerá como te lo montes, con qué tipo de clientes trabajes, si trabajas en una oficina o desde casa, si haces trabajos presenciales en las oficinas de los clientes o sólo en remoto, pero en general como freelance tienes más libertad para elegir en qué proyectos, con qué clientes quieres trabajar, a qué horas y en dónde quieres trabajar, y cuándo quieres o no tomarte un descanso. Experiencia y aprendizaje Una vez más es otro punto relativo; si como freelance te organizas bien y dedicas tiempo a seguirte formando, puedes aprender mucho más que trabajando en una empresa.  Además, tú vas a elegir qué aprender, qué tecnologías utilizar en función de lo que veas. Sin embargo, como estamos haciendo generalizaciones y siendo objetivo vamos a dar este punto al trabajar para una empresa, por dos motivos.  El hecho de trabajar día a día con más personas de tu sector, te enriquece mucho más: preguntar, hablar de temas de trabajo con gente que se dedica a ello y compartir conocimiento con tus compañeros de trabajo. Aunque, por otro lado, el hecho de tenerte que sacar tú mismo las castañas del fuego cuando estás como freelance, como autónomo es otra forma muy buena de aprender; en segundo lugar, el concentrarte únicamente en tu trabajo hace que trabajar para una empresa te permita progresar más el aspecto puramente técnico a lo que te dedicas. Como freelance, tienes que preocuparte de muchas otras cosas, como ya dijimos; clientes, ventas, contabilidad, auto-gestión, formación. Todo esto, puede dejarte menos tiempo para dedicarte tiempo a lo que realmente haces y para seguir mejorando en aquello que realmente haces. Pero, todo es cuestión de organización, así que aquí vamos a decir que es mejor trabajar para una empresa sobre todo en un momento inicial cuando eres principiante. Tranquilidad y preocupaciones Cuando tú trabajas para una empresa es mucho, mucho más tranquilo, es decir, tú entras a trabajar, haces tus ocho horas y una vez acabas, sales, te olvidas y ya está, de alguna manera te da igual lo que pase, la empresa no es tuya. Tú haces tus ocho horas y listo te olvidas del trabajo, que la empresa quiebra, pues que quiebre te buscas otro trabajo, es algo más o menos así, exagerándolo un poco.  Cuando tú trabajas como freelance es todo lo contrario, es como una jornada laboral de 24 horas (como quien dice) estás pensando constantemente en temas de trabajo quieras o no lo quieras, es bastante difícil desconectar. Y tienes que estar alerta de cualquier problema a todas horas Sin duda es mucho más tranquilo, muchas menos preocupaciones, el hecho de trabajar para una empresa. Una vez más a modo general, sin embargo, esto es una cosa que va con cada persona; hay gente que está hecha para una cosa y hay gente que está hecha para otra.  Todo depende de la persona, si quieres entrar a trabajar, hacer tus ocho horas y olvidarte, trabaja para una empresa. Si quieres progresar mucho más, comerte la cabeza, hazte freelance. Estabilidad y riesgo Qué es más estable o qué tiene más riesgo, una vez más depende de la forma en que lo veamos.  Inicialmente sin duda tiene menos estabilidad ser freelance, hasta que no pase un tiempo y tengas una serie de clientes, es más difícil, es menos estable económicamente y hay más riesgo siendo freelance que trabajando para una empresa donde desde el primer día vas a tener un sueldo fijo. Si lo miramos a largo plazo, vamos a cambiar el punto de vista un poco. Imagina que como freelance tienes 5-10 clientes para los que trabajas habitualmente; ahora piensa en el trabajar para una empresa, como ya dijimos en el capítulo anterior, cuando tú trabajas para una empresa eres como un freelance con un solo y único cliente. Entonces, qué es más posible. Que pierdas los diez clientes de golpe como freelance o que pierdas tu único cliente al trabajar para una empresa, que dejes de cobrar diez mini sueldos como freelance, por ejemplo o que dejes de cobrar un solo sueldo al trabajar con una sola empresa. Una empresa no es una ONG, si algo va mal, si tiene que prescindir de ti lo van a hacer, al igual que un cliente que tienes como freelance. En nuestra opinión es más seguro a largo plazo el freelancing al menos. También hay que decir una cosa, en el mundo de la programación, como ya dijimos, por lo menos hoy en día, hasta el momento es bastante difícil quedarte en el paro, si tienes experiencia, si estás trabajando (ahí queda esa reflexión). Satisfacción personal Este es un punto que hemos añadido y que quizás no es tan medible; por decirlo de alguna manera, pero junto al punto de la libertad y la flexibilidad es otro de los principales motivos por los cuáles, actualmente somos freelance. Qué satisface más, trabajar para ti mismo, conseguir méritos por ti mismo o trabajar para otro o conseguir méritos formando parte de un gran equipo. Personalmente nos satisface más trabajar más para nosotros mismos, conseguir nuestros propios méritos, es nuestra opinión. Al igual que la otra, puede ser perfectamente válida y perfectamente respetable, pero hay que pensar una cosa. Un día tiene 24 horas de los cuales dormimos idealmente unas 8 horas. Nos quedan 16 horas para “vivir” de estas 16 horas, vamos a contar que 8 de estas estamos trabajando y vamos a sumar una o dos horas que incluirán el desplazamiento, que quieras que no tardas en llegar al trabajo y entre que te pones y no te pones a trabajar. Así que estamos unas 10 horas trabajando; resumen nos quedan 6 horas libres. Dicho de otra forma, que se verá mejor: de nuestro día hábil sin contar las horas que dormimos nos pasamos alrededor de un 60% de nuestra vida trabajando, es decir, más de la mitad de tu vida te la vas a pasar trabajando. Quieres pasar la mitad de tu vida trabajando para otro o trabajando para ti mismo; ahí queda la pregunta.  Trabajar para una empresa o freelance tiene sus puntos buenos y sus puntos malos; la facilidad para empezar, pues es más fácil trabajar para una empresa. Progresión y futuro, quizás tengas más siendo freelance; en cuanto a sueldo a nivel general un freelance gana más que una persona que trabaja para una empresa, por lo menos a largo plazo. En cuanto a la flexibilidad y sin duda la propia palabra lo dice; freelance, autónomo. Tienes mucha, mucha más libertad trabajando para ti mismo, libertad de decisión, libertad de cuándo trabajar.  La facilidad de aprender, sobre todo inicialmente, quizás te sea más sencillo aprender en una empresa junto a otra gente que quizás tenga más experiencia que tú. Si lo que quieres es tranquilidad y las menores preocupaciones posibles; sin duda olvida todo lo anterior y vete a trabajar para una empresa. Estabilidad y riesgo; generalmente se dice que una empresa es más estable, pero ¡Ojo! Que a la larga que cuando freelance tienes más clientes, estás establecido, no es del todo así. Pensemos que trabajando para una empresa tienes un único cliente. El último punto, que hemos comentado, que es la satisfacción personal. Sin duda trabajar para uno mismo, conseguir los méritos para uno mismo, produce más satisfacción personal que conseguirlos dentro de una empresa. Aunque en una empresa formes parte de un equipo más grande y los méritos quizás sean más importantes, más grandes.  Cualquier mérito por pequeño que sea conseguido por ti mismo, produce mucha más satisfacción personal en nuestra humilde opinión.  The post 29. ¿Trabajar para una empresa o ser freelance? appeared first on Diego Laballós.

Lo primero que debemos de decir sobre este tema es que en nuestra opinión no hay una opción mejor ni una opción peor, simplemente depende de la persona; a una persona le puede parecer mejor una opción y otra persona le puede parecer mejor la otra opción. No hay una respuesta universal, de todas formas, vamos a intentar dividir todas estas diferencias, estos puntos débiles a través de distintos puntos y comentarlos de la forma más objetiva posible. <h3>Facilidad para empezar</h3> El primer punto que queremos comentar es la facilidad para empezar, de introducirte en el mundo, de empezar a funcionar En el caso de trabajar para una empresa es la facilidad de conseguir ese primer trabajo y en el caso de ser freelance sería la facilidad de conseguir los suficientes clientes como para vivir de ello. Aquí no tenemos ninguna duda de que lo mejor es trabajar para una empresa, aunque encontrar un primer trabajo siempre es difícil, más difícil es conseguir los primeros clientes. La diferencia es que una vez consigas el primer trabajo ya lo tienes, ya has empezado, ya estás dentro. Todo va a ser mucho más fácil. Sin embargo, en el caso de ser freelance en el caso de coger tu primer cliente, no significa nada sino consigues más o si sólo te dura un mes ese proyecto. Tienes que estar constantemente buscando nuevos clientes o manteniendo los que ya tienes con lo cual es mucho, mucho más difícil. <h3>Futuro y progresión</h3> La verdad es que esto es bastante relativo; para una empresa puedes llegar a puestos de mucha responsabilidad, de la misma manera trabajando como freelance también puedes hacerlo, puedes optar a proyectos bastante grandes. En mi opinión es más fácil tener responsabilidades como freelance. Las tienes desde el primer momento ya que vas a llevar proyectos por ti mismo, quizás al principio más pequeños, pero a medida que vas avanzando también serán más grandes, digamos que puedes llegar alto en ambos casos. Sin embargo, en mi opinión, como freelance llegas más rápido a proyectos grandes y de responsabilidad. <h3>El sueldo</h3> El sueldo también es algo muy relativo. Inicialmente sueles cobrar más trabajando para una empresa, esto es obvio, empiezas con un trabajo, ya tienes un sueldo fijo. Cuando tú empiezas como freelance y al principio no tienes muchos clientes, obviamente vas a cobrar bastante menos. El empezar como freelance es complicado, sin embargo, a largo plazo es más sencillo cobrar como freelance que en una empresa.En una empresa también puedes llegar a cobrar sueldos más altos, pero es mucho más complicado, al fin y al cabo, siendo freelance eres tu propia empresa, cuando tú trabajas como freelance cobras el proyecto íntegro. Una empresa, sin embargo, no destina todas sus ganancias a los sueldos, digamos hay gasto de oficina, gastos de personal; obviamente se reparten unos beneficios o genera unos beneficios, que es a lo que normalmente una empresa está destinada. Y normalmente esta empresa no está hecha para que sus trabajadores ganen más dinero, sino que lo hagan los inversores, los accionistas, llámalo como quieras. Siendo freelance tú eres tu propio inversor, eres tu accionista, así que el dinero que ganes va a ir mucho más íntegro a lo que viene a ser, podríamos decir tu sueldo. Inicialmente puede ser más fácil cobrar más en una empresa, pero a la larga va a ser más fácil cobrar más como freelance, al fin y al cabo, estás trabajando para ti mismo. Tú vas a decidir lo que cobras y con el paso del tiempo vas a ver que puedes ir cobrando más por lo que haces. Tienes más experiencia, accedes a más clientes, etc. <h3>Flexibilidad y libertad</h3> Aquí sí absolutamente no hay ninguna duda y quizás sea el punto que más nos gusta de ser freelance, por mucho que algunas empresas se esfuercen por temas de flexibilidad horaria y libertad para el trabajador; ser freelance te hace mucho, mucho más flexible y te dará mucha más libertad. Obviamente, también dependerá como te lo montes, con qué tipo de clientes trabajes, si trabajas en una oficina o desde casa, si haces trabajos presenciales en las oficinas de los clientes o sólo en remoto, pero en general como freelance tienes más libertad para elegir en qué proyectos, con qué clientes quieres trabajar, a qué horas y en dónde quieres trabajar, y cuándo quieres o no tomarte un descanso. <h3>Experiencia y aprendizaje</h3> Una vez más es otro punto relativo; si como freelance te organizas bien y dedicas tiempo a seguirte formando, puedes aprender mucho más que trabajando en una empresa. Además, tú vas a elegir qué aprender, qué tecnologías utilizar en función de lo que veas. Sin embargo, como estamos haciendo generalizaciones y siendo objetivo vamos a dar este punto al trabajar para una empresa, por dos motivos. El hecho de trabajar día a día con más personas de tu sector, te enriquece mucho más: preguntar, hablar de temas de trabajo con gente que se dedica a ello y compartir conocimiento con tus compañeros de trabajo. Aunque, por otro lado, el hecho de tenerte que sacar tú mismo las castañas del fuego cuando estás como freelance, como autónomo es otra forma muy buena de aprender; en segundo lugar, el concentrarte únicamente en tu trabajo hace que trabajar para una empresa te permita progresar más el aspecto puramente técnico a lo que te dedicas. Como freelance, tienes que preocuparte de muchas otras cosas, como ya dijimos; clientes, ventas, contabilidad, auto-gestión, formación. Todo esto, puede dejarte menos tiempo para dedicarte tiempo a lo que realmente haces y para seguir mejorando en aquello que realmente haces. Pero, todo es cuestión de organización, así que aquí vamos a decir que es mejor trabajar para una empresa sobre todo en un momento inicial cuando eres principiante. <h3>Tranquilidad y preocupaciones</h3> Cuando tú trabajas para una empresa es mucho, mucho más tranquilo, es decir, tú entras a trabajar, haces tus ocho horas y una vez acabas, sales, te olvidas y ya está, de alguna manera te da igual lo que pase, la empresa no es tuya. Tú haces tus ocho horas y listo te olvidas del trabajo, que la empresa quiebra, pues que quiebre te buscas otro trabajo, es algo más o menos así, exagerándolo un poco. Cuando tú trabajas como freelance es todo lo contrario, es como una jornada laboral de 24 horas (como quien dice) estás pensando constantemente en temas de trabajo quieras o no lo quieras, es bastante difícil desconectar. Y tienes que estar alerta de cualquier problema a todas horas Sin duda es mucho más tranquilo, muchas menos preocupaciones, el hecho de trabajar para una empresa. Una vez más a modo general, sin embargo, esto es una cosa que va con cada persona; hay gente que está hecha para una cosa y hay gente que está hecha para otra. Todo depende de la persona, si quieres entrar a trabajar, hacer tus ocho horas y olvidarte, trabaja para una empresa. Si quieres progresar mucho más, comerte la cabeza, hazte freelance. <h3>Estabilidad y riesgo</h3> Qué es más estable o qué tiene más riesgo, una vez más depende de la forma en que lo veamos. Inicialmente sin duda tiene menos estabilidad ser freelance, hasta que no pase un tiempo y tengas una serie de clientes, es más difícil, es menos estable económicamente y hay más riesgo siendo freelance que trabajando para una empresa donde desde el primer día vas a tener un sueldo fijo. Si lo miramos a largo plazo, vamos a cambiar el punto de vista un poco. Imagina que como freelance tienes 5-10 clientes para los que trabajas habitualmente; ahora piensa en el trabajar para una empresa, como ya dijimos en el capítulo anterior, cuando tú trabajas para una empresa eres como un freelance con un solo y único cliente. Entonces, qué es más posible. Que pierdas los diez clientes de golpe como freelance o que pierdas tu único cliente al trabajar para una empresa, que dejes de cobrar diez mini sueldos como freelance, por ejemplo o que dejes de cobrar un solo sueldo al trabajar con una sola empresa. Una empresa no es una ONG, si algo va mal, si tiene que prescindir de ti lo van a hacer, al igual que un cliente que tienes como freelance. En nuestra opinión es más seguro a largo plazo el freelancing al menos. También hay que decir una cosa, en el mundo de la programación, como ya dijimos, por lo menos hoy en día, hasta el momento es bastante difícil quedarte en el paro, si tienes experiencia, si estás trabajando (ahí queda esa reflexión). <h3>Satisfacción personal</h3> Este es un punto que hemos añadido y que quizás no es tan medible; por decirlo de alguna manera, pero junto al punto de la libertad y la flexibilidad es otro de los principales motivos por los cuáles, actualmente somos freelance. Qué satisface más, trabajar para ti mismo, conseguir méritos por ti mismo o trabajar para otro o conseguir méritos formando parte de un gran equipo. Personalmente nos satisface más trabajar más para nosotros mismos, conseguir nuestros propios méritos, es nuestra opinión. Al igual que la otra, puede ser perfectamente válida y perfectamente respetable, pero hay que pensar una cosa. Un día tiene 24 horas de los cuales dormimos idealmente unas 8 horas. Nos quedan 16 horas para “vivir” de estas 16 horas, vamos a contar que 8 de estas estamos trabajando y vamos a sumar una o dos horas que incluirán el desplazamiento, que quieras que no tardas en llegar al trabajo y entre que te pones y no te pones a trabajar. Así que estamos unas 10 horas trabajando; resumen nos quedan 6 horas libres. Dicho de otra forma, que se verá mejor: de nuestro día hábil sin contar las horas que dormimos nos pasamos alrededor de un 60% de nuestra vida trabajando, es decir, más de la mitad de tu vida te la vas a pasar trabajando. Quieres pasar la mitad de tu vida trabajando para otro o trabajando para ti mismo; ahí queda la pregunta. Trabajar para una empresa o freelance tiene sus puntos buenos y sus puntos malos; la facilidad para empezar, pues es más fácil trabajar para una empresa. Progresión y futuro, quizás tengas más siendo freelance; en cuanto a sueldo a nivel general un freelance gana más que una persona que trabaja para una empresa, por lo menos a largo plazo. En cuanto a la flexibilidad y sin duda la propia palabra lo dice; freelance, autónomo. Tienes mucha, mucha más libertad trabajando para ti mismo, libertad de decisión, libertad de cuándo trabajar. La facilidad de aprender, sobre todo inicialmente, quizás te sea más sencillo aprender en una empresa junto a otra gente que quizás tenga más experiencia que tú. Si lo que quieres es tranquilidad y las menores preocupaciones posibles; sin duda olvida todo lo anterior y vete a trabajar para una empresa. Estabilidad y riesgo; generalmente se dice que una empresa es más estable, pero ¡Ojo! Que a la larga que cuando freelance tienes más clientes, estás establecido, no es del todo así. Pensemos que trabajando para una empresa tienes un único cliente. El último punto, que hemos comentado, que es la satisfacción personal. Sin duda trabajar para uno mismo, conseguir los méritos para uno mismo, produce más satisfacción personal que conseguirlos dentro de una empresa. Aunque en una empresa formes parte de un equipo más grande y los méritos quizás sean más importantes, más grandes. Cualquier mérito por pequeño que sea conseguido por ti mismo, produce mucha más satisfacción personal en nuestra humilde opinión. The post <a href="https://diegolaballos.com/podcast/29-trabajar-para-una-empresa-o-ser-freelance/" rel="nofollow" target="_blank">29. ¿Trabajar para una empresa o ser freelance?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

29. ¿Trabajar para una empresa o ser freelance?

En primer lugar, que una app haga lo que tiene que hacer, no significa que esté bien hecha. Esto es algo que ya damos por hecho. Por ejemplo, si tenemos Spotify, damos por hecho que tiene que reproducir canciones; si estamos en Netflix, damos por hecho que podemos reproducir series, películas, etc. Estas son cosas que ya damos por hecho, así que vamos a ver los distintos puntos que nos pueden hacer ver si una app está bien o mal programada. Eso sí, los vamos a dividir en dos grupos: los puntos visibles que podemos ver a simple vista que, podemos ver sin entender nada de programación; y los no visibles, que son aquellos en donde necesitamos ver el código interno de la aplicación y entenderlo. ¿Cómo saber si una app está bien hecha?: Puntos visibles En primer lugar, una aplicación tiene que responder rápidamente a la interacción del usuario; tiene que ser rápida. Al abrirse, al tocar un botón, al cambiar de pantalla, tiene que responder automáticamente a lo que hacemos; tiene que mostrar una reacción cada vez que interactuamos con ella. Por ejemplo, cuando hacemos scroll en una lista de canciones, series, películas (siguiendo con los ejemplos anterior), tiene que ir rápido, debe ser un scroll suave y no ir a “trompicones”. O, cuando tocamos un botón, debe mostrar una reacción, como cambiar de color o escalarse un poco. En el móvil, a veces no es tan fácil saber que se ha aplicado un botón; son pantallas pequeñas y a veces la gente tiene dedos grandes. No sabes si realmente has tocada el botón o no. De hecho, hay aplicaciones que no muestran ninguna reacción o prueba de que ese botón se ha toca. Entonces, lo que hacemos es tocarlo constantemente.  Lo que tiene que hacer una app, es mostrar que se ha interactuado con ella. Otra cosa, es cuando una aplicación va a llevar a cabo algún tipo de acción que requiere cierto tiempo procesar. Por ejemplo, en cuanto a descargas web, la aplicación tiene que mostrar que está pasando algo, ya sea un texto, animación (la típica de que algo está cargando) o algo para mostrarle al usuario de que “algo” realmente está pasando. No podemos bloquear la aplicación sin mostrar qué está pasando, cuando hacemos algo por detrás porque eso puede confundir al usuario.  Imagínate que vas descargar una aplicación y no pasa absolutamente nada en la interfaz de usuario. Lo que vas a pensar, es que no ha pasado nada y le vas a volver a dar constantemente. Lo mejor es mostrar que está pasando algo. Aunque como veremos más adelante, una aplicación tiene que tener las mínimas interacciones directas con la conexión a internet. ¿Cómo saber si una aplicación está bien hecha? : Diseño moderno Otro punto es el diseño actual y moderno, acorde con el sistema operativo. Las aplicaciones móviles forman parte de un sistema operativo, ya sea Android o iOS, y tiene que estar en concordancia con él. Para ello, cada sistema, tiene sus guías de diseño donde se explica básicamente como tiene que ser una aplicación, qué tiene que tener, qué cosas puedes y hacer y qué cosas no. No significa que tengas que calcar cada punto, pero sí tendrías que inspirarte un poco en ello. La idea es que, un usuario de iOS sabe o intuye dónde están o cómo funcionan ciertas funciones en iOS; y, lo mismo con Android. Si hacemos algo totalmente diferente a lo que hacen la mayoría de aplicaciones que siguen las guías de diseño, será más difícil aprender a utilizar la aplicación. Todo lo que implique añadir dificultad a lo que haga la app juega en nuestra contra ya que tenemos muchas probabilidades de ser desinstalados. Los usuarios móviles (digamos la verdad) no tenemos mucha paciencia a la hora de utilizar las apps. Además, el diseño tiene que ser agradable y actual. Como digo, tiene que formar parte del sistema operativo; es decir, una aplicación que sigue las guías de diseño de Android, por ejemplo. En otras palabras, esto quiere decir que la aplicación forma parte del sistema operativo; es una pieza más del sistema. No puede ser que nuestra app tenga un diseño de hace 4 años porque hasta “daña” la vista realmente. Podéis comparar las aplicaciones de ese entonces con las de ahora en cualquier sistema operativo y no tienen nada que ver; en ambos sistemas han cambiado muchísimo. ¿Cómo saber si una aplicación está bien hecha? : Diseño simple Este es otro punto que va ligado a algo que decía: cuanto más simple sea nuestra app de utilizar, mejor. Las apps están pensadas para funcionar en pantallas pequeñas de móviles, así que tienen que resolver un problema en concreto y tener una función principal; y esto lo tienen que hacer bien. Luego se pueden añadir funciones secundarias o más ocultas, pero no podemos llenar la pantalla de mil y un opciones porque si no será un descontrol en una pantalla tan pequeña. ¿Cómo saber si una aplicación está bien hecha? : La menor cantidad de errores posibles Esto es algo obvio. Una aplicación tiene que tener los mínimos errores posibles y en un mundo ideal no debería tener ninguno. ¿Por qué en un mundo ideal? Porque en los móviles esto es bastante complicado debido a la fragmentación de sistemas y fabricantes. Seguro que a más de uno nos ha pasado que se ha cerrado la aplicación de golpe o dado error. Esto pasa incluso en aplicaciones tan grandes y “top” como Facebook o Netflix. Es realmente muy difícil controlarlo; solo hace falta mirar las descripciones de las actualizaciones que se hacen de las apps en las tiendas. Si nosotros, desde nuestro móvil, vamos a ver los detalles de las aplicaciones que se han actualizado, estoy seguro que más de la mitad de las aplicaciones van a tener un texto parecido a “errores menores solucionados” o “bugfixes”. Esto quiere decir que únicamente se ha hecho esa actualización para corregir ciertos errores. Dicho esto, una aplicación debe tener los mínimos errores por una razón obvia: nadie quiere que se cierre una aplicación en su cara; es bastante frustrante la verdad. Si nos damos una vuelta por las reviews de App Store o Google Play, veremos que la gran mayoría de puntuaciones negativas se deben precisamente a algo relacionado con esto: que a la gente se le cierra la aplicación, que le da error, que no le deja hacer X cosa, etc. Esto es algo que les importa bastante a los usuarios. ¿Cómo saber si una aplicación está bien hecha? : Punto visible Comportamiento en situaciones no ideales ¿Qué pasa si pruebas la app con mala conexión?, ¿Qué pasa si no tienes conexión a internet? Estas situaciones son más comunes de lo que pensamos. Por ejemplo, estás en un parking, sótano, en un ascensor subiendo a casa, o estás en un tren a las afueras de una ciudad donde no hay buena conexión. Todas estas situaciones son más comunes de lo que pensamos. Una app siempre tiene que ofrecer una experiencia offline; una experiencia alternativa. Por ejemplo, en Spotify podemos escuchar música si antes hemos descargado las canciones; en Netflix también podemos ver algunas series que hemos previamente guardado.  Asimismo, en ambas aplicaciones podemos ver nuestras listas y películas guardadas o favoritas, sin que hayan sido descargadas. En otras palabras, si entramos en estas aplicaciones sin estar conectados a internet, van a funcionar exactamente igual. Una app tendría que depender lo menos posible de una conexión a internet. Por ejemplo, en WhatsApp, puedo enviar un mensaje sin necesidad de tener conexión en ese momento. Yo envío el mensaje y en su momento, se enviará al destinatario; el usuario no tiene por qué esperar. Esto, WhatsApp lo añadió hace poco, pero otras apps de mensajería ya lo tenían, como Telegram. A todo esto, quizás, este es el punto que más complicaciones tiene porque significa tener una base de datos local y una remota, y sincronizar ambas cuando se necesite. Pero bueno, dejemos el tema técnico de lado. Lo que pasa es que muchas veces probamos la app antes de lanzarla, en condiciones ideales: en un dispositivo de última generación, con conexión al Wifi de la oficina que va a toda velocidad.  Pues bien, esas no son las condiciones que van a tener todos tus usuarios. Si no pruebas tu app en malas condiciones, tus usuarios lo van a hacer por ti; y, te aseguro que, si la experiencia no es buena, cuando veas una mala review en Google Play, te arrepentirás de no haberlo hecho antes. Obviamente, en una app que funciona sin internet, se presupone que no podrás hacer todas esas cosas que se hacen con internet. No obstante, lo que, sí tiene que ofrecer, es una experiencia alternativa. No puede quedarse la pantalla en blanco, ni mostrar errores, ni mostrar algo que se está cargando; no puede ser así. ¿Cómo saber si una aplicación está bien hecha? : Uso razonable de los recursos del sistema Esto significa no ser intrusivo con las notificaciones “push”; no hay nada que moleste más que notificaciones que no te importan para nada. Tampoco se debe hacer un uso excesivo de la batería porque en los dispositivos móviles es algo crítico. De la misma forma, tampoco se debe abusar del uso de los datos cuando no hay wifi porque los megas hoy en día, son casi un tesoro. Otra cosa, es no abusar de los permisos que una aplicación necesita porque si pedimos demasiados, crean desconfianza. Por ejemplo, una aplicación de calendario que pide un permiso para la cámara; bueno, puede ser que lo necesite en este caso, pero si pide el de la cámara, micrófono, GPS, etc., ya crea un poco de desconfianza; quizás no es tan necesario pedirlos todos. Y a todo esto, ¿Por qué hay que hacer un uso razonable de los recursos del sistema? Porque además de lo que he dicho, en las últimas versiones del sistema se ha estado haciendo mucho hincapié en darle esta información al usuario. Se puede ver cuánta batería o megas gasta una aplicación; se pueden quitar los permisos que se han concedido previamente a una aplicación o deshabilitar totalmente las notificaciones. No solo porque el usuario pueda deshabilitar ciertos requisitos de nuestra app, sino porque va a empezar a haber datos, que, si son negativos, quizás incentiven la desinstalación de la aplicación. Vistos estos puntos visibles, algunas de las apps que a mí me gustan y que yo considero que son buenos ejemplos son Netflix, Pocketcasts (la aplicación de podcasts que recomendé hace unos capítulos), Spotify, Gmail, Google Drive… en general, las aplicaciones de Google están bastante bien. Vinculación entre los puntos visibles y los no visibles Como comentaba al principio, hay una serie de puntos que indican que una app está bien hecha y que no son visibles porque tenemos que acceder al código; son temas más internos. Son más difíciles de detectar porque tienes que tener acceso al código y entenderlo. De todas maneras, por norma general, los puntos visibles y los no visibles suelen ir bastante ligados. Es decir, una app que cumple bien los puntos visibles, generalmente va a cumplir también los puntos no visibles; y lo mismo, a la inversa. Sin embargo, puede darse el caso de que, aunque una app luzca bien por fuera, no esté tan bien por dentro. Un edificio puede ser bonito, pero estar construido fatal. Puede tener paredes de papel y que se escuche todo entre los vecinos; puede ser que salgan humedades en el baño; puede ser que salgan grietas. En fin, creo que se entiende el paralelismo: una aplicación puede estar bien por fuera, pero mal por dentro. Una aplicación que está bien construida, tiene que facilitar los cambios. El código de una aplicación tiene que estar preparado para sufrir cambios. Cualquier sistema informático tiene que estar preparado al máximo para cambiar ciertas cosas. Por ejemplo, si en una pantalla ahora sale un texto, y quiero que ahora salga una imagen, tiene que ser relativamente sencillo hacerlo y no que lleve un mes. Otro punto, es que debe ser entendible para otros programadores y estar bien organizado. Los programadores a veces, tendemos a pensar que vamos a ser las únicas personas que vamos a tocar el código que estamos haciendo, cuando en realidad tendremos que programar de forma tal que otra persona lo pueda entender. O, incluso, que nosotros mismos, después de un año sin tocar ese código, seamos capaces de volver, revisarlo rápidamente y entender cómo funcionaba. El código de una aplicación tiene que estar organizado de forma coherente y ser entendible a cualquier persona que lo quiera modificar (obviamente con conocimientos de la tecnología). En palabras más sencillas, tiene que ser fácil para una persona realizar un cambio. Una aplicación debe ser escalable. Esto, va muy ligado a la facilidad de hacer cambios, pero, lo he querido separar un poco. Que una app sea escalable quiere decir que puede seguir ampliando sus funcionalidades sin necesidad de modificar las existentes o, modificarlas lo menos posible. El concepto de “testing” en programación, es algo a lo que se le puede dedicar un capítulo entero, pero de forma rápida: una aplicación puede contener cierto código que se encargue de automatizar el testeo de las diferentes funcionalidades. Para que se entienda rápidamente, imagina que instalas una app en tu móvil, y cuando la abres empieza a funcionar sola, empieza a rellenar los datos del login, entra, sube una foto, le da “me gusta” a un comentario, etc; prueba todas las funcionalidades de la app. Como ya decía, quizás estos puntos no visibles, sean algo más difíciles de ver. Muchas veces no vamos a saber si una app está bien construida en este aspecto hasta el momento en que nos encontremos el problema; principalmente porque necesitamos a alguien que sepa del tema. Una buena opción para tener una idea de este punto, es contratar un profesional de referencia y con experiencia, para que únicamente nos revise esto; contratar a alguien para que nos diga cómo está nuestra app por dentro y, por lo tanto, actuar en consecuencia. De todas maneras, esto se evitaría desde un principio si se contratara a un verdadero profesional con experiencia, que nos hiciera la app. The post 24. ¿Qué diferencia una buena de una mala aplicación? appeared first on Diego Laballós.

En primer lugar, que una app haga lo que tiene que hacer, no significa que esté bien hecha. Esto es algo que ya damos por hecho. Por ejemplo, si tenemos Spotify, damos por hecho que tiene que reproducir canciones; si estamos en Netflix, damos por hecho que podemos reproducir series, películas, etc. Estas son cosas que ya damos por hecho, así que vamos a ver los distintos puntos que nos pueden hacer ver si una app está bien o mal programada. Eso sí, los vamos a dividir en dos grupos: los puntos visibles que podemos ver a simple vista que, podemos ver sin entender nada de programación; y los no visibles, que son aquellos en donde necesitamos ver el código interno de la aplicación y entenderlo. <h3>¿Cómo saber si una app está bien hecha?: Puntos visibles</h3> En primer lugar, una aplicación tiene que responder rápidamente a la interacción del usuario; tiene que ser rápida. Al abrirse, al tocar un botón, al cambiar de pantalla, tiene que responder automáticamente a lo que hacemos; tiene que mostrar una reacción cada vez que interactuamos con ella. Por ejemplo, cuando hacemos scroll en una lista de canciones, series, películas (siguiendo con los ejemplos anterior), tiene que ir rápido, debe ser un scroll suave y no ir a “trompicones”. O, cuando tocamos un botón, debe mostrar una reacción, como cambiar de color o escalarse un poco. En el móvil, a veces no es tan fácil saber que se ha aplicado un botón; son pantallas pequeñas y a veces la gente tiene dedos grandes. No sabes si realmente has tocada el botón o no. De hecho, hay aplicaciones que no muestran ninguna reacción o prueba de que ese botón se ha toca. Entonces, lo que hacemos es tocarlo constantemente. Lo que tiene que hacer una app, es mostrar que se ha interactuado con ella. Otra cosa, es cuando una aplicación va a llevar a cabo algún tipo de acción que requiere cierto tiempo procesar. Por ejemplo, en cuanto a descargas web, la aplicación tiene que mostrar que está pasando algo, ya sea un texto, animación (la típica de que algo está cargando) o algo para mostrarle al usuario de que “algo” realmente está pasando. No podemos bloquear la aplicación sin mostrar qué está pasando, cuando hacemos algo por detrás porque eso puede confundir al usuario. Imagínate que vas descargar una aplicación y no pasa absolutamente nada en la interfaz de usuario. Lo que vas a pensar, es que no ha pasado nada y le vas a volver a dar constantemente. Lo mejor es mostrar que está pasando algo. Aunque como veremos más adelante, una aplicación tiene que tener las mínimas interacciones directas con la conexión a internet. <h3>¿Cómo saber si una aplicación está bien hecha? : Diseño moderno</h3> Otro punto es el diseño actual y moderno, acorde con el sistema operativo. Las aplicaciones móviles forman parte de un sistema operativo, ya sea Android o iOS, y tiene que estar en concordancia con él. Para ello, cada sistema, tiene sus guías de diseño donde se explica básicamente como tiene que ser una aplicación, qué tiene que tener, qué cosas puedes y hacer y qué cosas no. No significa que tengas que calcar cada punto, pero sí tendrías que inspirarte un poco en ello. La idea es que, un usuario de iOS sabe o intuye dónde están o cómo funcionan ciertas funciones en iOS; y, lo mismo con Android. Si hacemos algo totalmente diferente a lo que hacen la mayoría de aplicaciones que siguen las guías de diseño, será más difícil aprender a utilizar la aplicación. Todo lo que implique añadir dificultad a lo que haga la app juega en nuestra contra ya que tenemos muchas probabilidades de ser desinstalados. Los usuarios móviles (digamos la verdad) no tenemos mucha paciencia a la hora de utilizar las apps. Además, el diseño tiene que ser agradable y actual. Como digo, tiene que formar parte del sistema operativo; es decir, una aplicación que sigue las guías de diseño de Android, por ejemplo. En otras palabras, esto quiere decir que la aplicación forma parte del sistema operativo; es una pieza más del sistema. No puede ser que nuestra app tenga un diseño de hace 4 años porque hasta “daña” la vista realmente. Podéis comparar las aplicaciones de ese entonces con las de ahora en cualquier sistema operativo y no tienen nada que ver; en ambos sistemas han cambiado muchísimo. <h3>¿Cómo saber si una aplicación está bien hecha? : Diseño simple</h3> Este es otro punto que va ligado a algo que decía: cuanto más simple sea nuestra app de utilizar, mejor. Las apps están pensadas para funcionar en pantallas pequeñas de móviles, así que tienen que resolver un problema en concreto y tener una función principal; y esto lo tienen que hacer bien. Luego se pueden añadir funciones secundarias o más ocultas, pero no podemos llenar la pantalla de mil y un opciones porque si no será un descontrol en una pantalla tan pequeña. <h3>¿Cómo saber si una aplicación está bien hecha? : La menor cantidad de errores posibles</h3> Esto es algo obvio. Una aplicación tiene que tener los mínimos errores posibles y en un mundo ideal no debería tener ninguno. ¿Por qué en un mundo ideal? Porque en los móviles esto es bastante complicado debido a la fragmentación de sistemas y fabricantes. Seguro que a más de uno nos ha pasado que se ha cerrado la aplicación de golpe o dado error. Esto pasa incluso en aplicaciones tan grandes y “top” como Facebook o Netflix. Es realmente muy difícil controlarlo; solo hace falta mirar las descripciones de las actualizaciones que se hacen de las apps en las tiendas. Si nosotros, desde nuestro móvil, vamos a ver los detalles de las aplicaciones que se han actualizado, estoy seguro que más de la mitad de las aplicaciones van a tener un texto parecido a “errores menores solucionados” o “bugfixes”. Esto quiere decir que únicamente se ha hecho esa actualización para corregir ciertos errores. Dicho esto, una aplicación debe tener los mínimos errores por una razón obvia: nadie quiere que se cierre una aplicación en su cara; es bastante frustrante la verdad. Si nos damos una vuelta por las reviews de App Store o Google Play, veremos que la gran mayoría de puntuaciones negativas se deben precisamente a algo relacionado con esto: que a la gente se le cierra la aplicación, que le da error, que no le deja hacer X cosa, etc. Esto es algo que les importa bastante a los usuarios. <h3>¿Cómo saber si una aplicación está bien hecha? : Punto visible Comportamiento en situaciones no ideales</h3> ¿Qué pasa si pruebas la app con mala conexión?, ¿Qué pasa si no tienes conexión a internet? Estas situaciones son más comunes de lo que pensamos. Por ejemplo, estás en un parking, sótano, en un ascensor subiendo a casa, o estás en un tren a las afueras de una ciudad donde no hay buena conexión. Todas estas situaciones son más comunes de lo que pensamos. Una app siempre tiene que ofrecer una experiencia offline; una experiencia alternativa. Por ejemplo, en Spotify podemos escuchar música si antes hemos descargado las canciones; en Netflix también podemos ver algunas series que hemos previamente guardado. Asimismo, en ambas aplicaciones podemos ver nuestras listas y películas guardadas o favoritas, sin que hayan sido descargadas. En otras palabras, si entramos en estas aplicaciones sin estar conectados a internet, van a funcionar exactamente igual. Una app tendría que depender lo menos posible de una conexión a internet. Por ejemplo, en WhatsApp, puedo enviar un mensaje sin necesidad de tener conexión en ese momento. Yo envío el mensaje y en su momento, se enviará al destinatario; el usuario no tiene por qué esperar. Esto, WhatsApp lo añadió hace poco, pero otras apps de mensajería ya lo tenían, como Telegram. A todo esto, quizás, este es el punto que más complicaciones tiene porque significa tener una base de datos local y una remota, y sincronizar ambas cuando se necesite. Pero bueno, dejemos el tema técnico de lado. Lo que pasa es que muchas veces probamos la app antes de lanzarla, en condiciones ideales: en un dispositivo de última generación, con conexión al Wifi de la oficina que va a toda velocidad. Pues bien, esas no son las condiciones que van a tener todos tus usuarios. Si no pruebas tu app en malas condiciones, tus usuarios lo van a hacer por ti; y, te aseguro que, si la experiencia no es buena, cuando veas una mala review en Google Play, te arrepentirás de no haberlo hecho antes. Obviamente, en una app que funciona sin internet, se presupone que no podrás hacer todas esas cosas que se hacen con internet. No obstante, lo que, sí tiene que ofrecer, es una experiencia alternativa. No puede quedarse la pantalla en blanco, ni mostrar errores, ni mostrar algo que se está cargando; no puede ser así. <h3>¿Cómo saber si una aplicación está bien hecha? : Uso razonable de los recursos del sistema</h3> Esto significa no ser intrusivo con las notificaciones “push”; no hay nada que moleste más que notificaciones que no te importan para nada. Tampoco se debe hacer un uso excesivo de la batería porque en los dispositivos móviles es algo crítico. De la misma forma, tampoco se debe abusar del uso de los datos cuando no hay wifi porque los megas hoy en día, son casi un tesoro. Otra cosa, es no abusar de los permisos que una aplicación necesita porque si pedimos demasiados, crean desconfianza. Por ejemplo, una aplicación de calendario que pide un permiso para la cámara; bueno, puede ser que lo necesite en este caso, pero si pide el de la cámara, micrófono, GPS, etc., ya crea un poco de desconfianza; quizás no es tan necesario pedirlos todos. Y a todo esto, ¿Por qué hay que hacer un uso razonable de los recursos del sistema? Porque además de lo que he dicho, en las últimas versiones del sistema se ha estado haciendo mucho hincapié en darle esta información al usuario. Se puede ver cuánta batería o megas gasta una aplicación; se pueden quitar los permisos que se han concedido previamente a una aplicación o deshabilitar totalmente las notificaciones. No solo porque el usuario pueda deshabilitar ciertos requisitos de nuestra app, sino porque va a empezar a haber datos, que, si son negativos, quizás incentiven la desinstalación de la aplicación. Vistos estos puntos visibles, algunas de las apps que a mí me gustan y que yo considero que son buenos ejemplos son Netflix, Pocketcasts (la aplicación de podcasts que recomendé hace unos capítulos), Spotify, Gmail, Google Drive… en general, las aplicaciones de Google están bastante bien. <h3>Vinculación entre los puntos visibles y los no visibles</h3> Como comentaba al principio, hay una serie de puntos que indican que una app está bien hecha y que no son visibles porque tenemos que acceder al código; son temas más internos. Son más difíciles de detectar porque tienes que tener acceso al código y entenderlo. De todas maneras, por norma general, los puntos visibles y los no visibles suelen ir bastante ligados. Es decir, una app que cumple bien los puntos visibles, generalmente va a cumplir también los puntos no visibles; y lo mismo, a la inversa. Sin embargo, puede darse el caso de que, aunque una app luzca bien por fuera, no esté tan bien por dentro. Un edificio puede ser bonito, pero estar construido fatal. Puede tener paredes de papel y que se escuche todo entre los vecinos; puede ser que salgan humedades en el baño; puede ser que salgan grietas. En fin, creo que se entiende el paralelismo: una aplicación puede estar bien por fuera, pero mal por dentro. Una aplicación que está bien construida, tiene que facilitar los cambios. El código de una aplicación tiene que estar preparado para sufrir cambios. Cualquier sistema informático tiene que estar preparado al máximo para cambiar ciertas cosas. Por ejemplo, si en una pantalla ahora sale un texto, y quiero que ahora salga una imagen, tiene que ser relativamente sencillo hacerlo y no que lleve un mes. Otro punto, es que debe ser entendible para otros programadores y estar bien organizado. Los programadores a veces, tendemos a pensar que vamos a ser las únicas personas que vamos a tocar el código que estamos haciendo, cuando en realidad tendremos que programar de forma tal que otra persona lo pueda entender. O, incluso, que nosotros mismos, después de un año sin tocar ese código, seamos capaces de volver, revisarlo rápidamente y entender cómo funcionaba. El código de una aplicación tiene que estar organizado de forma coherente y ser entendible a cualquier persona que lo quiera modificar (obviamente con conocimientos de la tecnología). En palabras más sencillas, tiene que ser fácil para una persona realizar un cambio. Una aplicación debe ser escalable. Esto, va muy ligado a la facilidad de hacer cambios, pero, lo he querido separar un poco. Que una app sea escalable quiere decir que puede seguir ampliando sus funcionalidades sin necesidad de modificar las existentes o, modificarlas lo menos posible. El concepto de “testing” en programación, es algo a lo que se le puede dedicar un capítulo entero, pero de forma rápida: una aplicación puede contener cierto código que se encargue de automatizar el testeo de las diferentes funcionalidades. Para que se entienda rápidamente, imagina que instalas una app en tu móvil, y cuando la abres empieza a funcionar sola, empieza a rellenar los datos del login, entra, sube una foto, le da “me gusta” a un comentario, etc; prueba todas las funcionalidades de la app. Como ya decía, quizás estos puntos no visibles, sean algo más difíciles de ver. Muchas veces no vamos a saber si una app está bien construida en este aspecto hasta el momento en que nos encontremos el problema; principalmente porque necesitamos a alguien que sepa del tema. Una buena opción para tener una idea de este punto, es contratar un profesional de referencia y con experiencia, para que únicamente nos revise esto; contratar a alguien para que nos diga cómo está nuestra app por dentro y, por lo tanto, actuar en consecuencia. De todas maneras, esto se evitaría desde un principio si se contratara a un verdadero profesional con experiencia, que nos hiciera la app. The post <a href="https://diegolaballos.com/podcast/24-que-diferencia-una-buena-de-una-mala-aplicacion/" rel="nofollow" target="_blank">24. ¿Qué diferencia una buena de una mala aplicación?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

24. ¿Qué diferencia una buena de una mala aplicación?

Antes de entrar en el tema, vamos a resolver una pregunta hecha a través de iVoox por José Nieto en el último capítulo: ¿crees que, en un corto o mediano plazo, las aplicaciones híbridas pueden llegar a ser iguales o incluso superiores a las aplicaciones nativas? Esto es algo que, desde el principio, siempre han intentado las aplicaciones híbridas. Es decir, las aplicaciones híbridas siempre intentan parecerse lo más posible a las aplicaciones nativas, ya sea en cuanto a diseño de interfaz, potencia, etc. Su objetivo principal es llegar a ser como las aplicaciones nativas y su idea principal de desarrollar un proyecto para todos los sistemas operativos móviles, es sencillamente genial; sería lo óptimo. Sin embargo, aquí hay un gran problema: las dos grandes empresas detrás de los sistemas operativos móviles (Apple y Google) tiran cada una por su lado. Es decir, cada uno desarrolla sus cosas y en su propio lenguaje. La verdad es que, si se quisieran poner de acuerdo para desarrollar las aplicaciones con un solo lenguaje, quizás podrían hacerlo. El problema es que no lo hacen porque al fin y al cabo se están haciendo la competencia uno a otro. Este es el mismo problema que tenemos en los ordenadores desde hace años y años. Tenemos Windows y Mac y las aplicaciones que están hechas para uno u otro sistema operativo, funcionan mucho mejor y más rápido que aquellas aplicaciones que están hechas a través de tecnologías que permiten el desarrollo de programas para su funcionamiento en los dos sistemas como Java. Pues bien, después de años y años, el panorama sigue igual. En mi opinión, los sistemas operativos móviles y en las aplicaciones móviles, esto va a seguir igual. Sí creo que las aplicaciones híbridas se seguirán acercando un poco más a las nativas, porque ya lo vienen haciendo desde hace años. Es decir, no es lo mismo una aplicación híbrida de hace cuatro años, que las de hoy en día; han mejorado muchísimo. Sin embargo, veo difícil que consigan colocarse a la par en cuanto a calidad, potencia y otros aspectos. Dicho esto, espero que quede la pregunta resuelta y vamos con el tema del día. En el capítulo anterior, estuvimos viendo las dos formas de programar: de forma nativa, o híbrida. Si lo queremos de forma nativa, tendremos que desarrollar un proyecto para cada sistema operativo; la aplicación híbrida viene a ser desarrollar un solo proyecto utilizando ciertas plataformas/tecnologías híbridas, para hacer que ese único proyecto funcione en cualquier sistema operativo. App makers: Crear aplicaciones sin saber programar Vistas estas dos formas de programar aplicaciones, tenemos otra opción que es crear aplicaciones sin saber programar y esto es a partir de los app makers. Este concepto no es nada nuevo en el mundo de la tecnología; ya existen programas para hacer juegos o diseñar webs sin saber programar ni conocer HTML o CSS. Esto es exactamente lo mismo, pero con aplicaciones móviles. Hay muchas plataformas y webs que se dedican a crear aplicaciones sin necesidad de saber programar. Para este capítulo, he echado un vistazo a tres de los principales porque al fin y al cabo todos vienen a ser lo mismo. He probado GoodBarber, Mobincube y App Yourself, así que vamos a ver exactamente qué son. Básicamente webs que te permiten crear aplicaciones, ya está. ¿Cómo? Pues desde la web, podemos acceder a un panel de control en el cual, arrastrando elementos, podemos crear la app. Por ejemplo, imagínate una web completamente en blanco con un panel de control desde donde puedes arrastrar botones o imágenes. Básicamente es eso, puedes arrastrar componentes de la aplicación y vas diseñando tu interfaz. Además, puedes añadir mods y plugins de funcionalidades específicas que la plataforma te ofrece. Por ejemplo, si quieres mostrar un mapa interactivo de Google Maps donde se vea una localización, pues tú podrías utilizar ese plugin, arrastrarla, configurarla con los parámetros básicos y ya lo tendrás funcionando. ¿Cómo se publican en las tiendas? Pues normalmente, a través de su panel de control, cuando terminas de crear tu aplicación, puedes generar el archivo de la app. Por ejemplo, para Android podrás descargar un archivo .APK y para iOS, un archivo. IPA. Hay que decir que los app makers, como ya dije, también utilizan plataformas híbridas. Con lo cual, con un solo proyecto, podrás crear la aplicación para tantos sistemas operativos como quieras. A partir de aquí, una vez tengas tu archivo, tendrás que crear tu propia cuenta ya sea de Google o Apple y tendrás que publicar y administrar tu aplicación.  Simplemente tendrás el archivo con la aplicación ya preparada que es lo que te va a dar la plataforma.  ¿Hasta dónde podemos llegar con los App Makers? ¿Qué podemos hacer?, ¿hasta qué punto son potentes los app makers? Básicamente, podemos hacer lo que la plataforma nos permita. Estaremos limitados a los plugins, diseños y características que ellos nos ofrezcan.  Por ejemplo, si queremos algo muy personalizado como un chat a través del cual se pueden mandar imágenes y que estas caduquen (que ya no se puedan descargar o que ya no sean visibles) al cabo de 60 segundos; seguramente no lo vamos a poder hacer. Algunas plataformas tienen algunos plugin /módulos de chats, pero como digo, nos vamos a tener que atener a lo que tengan ellos. Es decir, si el chat, únicamente tiene texto, pues es lo que vamos a tener que utilizar porque no hay más. ¿Cuánto cuestan? Estas plataformas suelen hacer un cobro recurrente al año. Una vez tu las estás utilizando, tienes que pagar anualmente para mantener, actualizar y modificar tu aplicación. Más o menos, por lo que he visto, estamos hablando de unos 100-500 euros anuales. Cada una, tiene planes distintos: te dejan hacer mas o menos cosas en función de lo que quieras pagar. Limitaciones de las App Makers Obviamente, este tipo de plataformas donde puedes hacer aplicaciones sin saber programar tienen sus limitaciones. La mayor de estas es la que ya he dicho: que no puedes hacer más de lo que ellos te ofrecen y permiten. Sí que hay unas plataformas con opciones para ampliar las funcionalidades a través de programación, de sus propias reglas. Normalmente será a través de lenguajes como Javascript, pero obviamente vas a necesitar un programador o saber programar para seguir ampliando o modificando el comportamiento de tu aplicación.  Sin embargo, hay que decir que estas ampliaciones o modificaciones también son limitadas. Por ejemplo, como experiencia propia, en un proyecto de Mobincube que tuve a través de una empresa que me contrató, el objetivo era instalar la app en unas tabletas que se iban a regalar a los clientes. El tema era que la aplicación necesitaba iniciarse automáticamente. Esto es algo que, con un desarrollo nativo o incluso híbrida, puede hacerse, no es mucho problema. El problema es que, como la aplicación estaba hecha en MobinCube, no se podía tocar el código. Una vez que tengas la aplicación, a pesar de que te pertenece a ti, tú no puedes entrar al código y modificarlo (por lo menos en esa plataforma). Por tanto, se tuvo que hacer una cosa distinta porque no se podía modificar el código. Con esto, me refiero a que las aplicaciones que puedes hacer, son limitadas. Otros temas, son la calidad/potencia de las aplicaciones. Como ya decía, esto no vienen a ser otra cosa que aplicaciones web híbridas, así que obviamente van a tener una potencia menor que las aplicaciones nativas o incluso híbridas, porque son menos configurables. El Lock In Si algún día quieres irte de la plataforma, vas a tener que rehacer casi totalmente tu aplicación. Es decir, si tu creas una aplicación con uno de estos App Makers, vas a tener que estar ligado a esta plataforma si no quieres empezar de cero tu proyecto otra vez.  Algunas plataformas si te dejan migrar datos, como una base de datos que hayas recopilado (usuarios, por ejemplo), pero, la interfaz y las funcionalidades que quieras desarrollar en tu aplicación, vas a tener que empezar desde cero. ¿Son útiles los App Makers? Dicho esto, ¿son realmente útiles? Si, obviamente cada tecnología tiene su utilidad y los App Makers la tienen. Al igual que los programas que te dejan crear juegos o web y, que sirven para unas cosas y no para otras. El gran punto a favor que tienen, es la simplicidad y el precio económico en comparación con un desarrollo personalizado. Por lo tanto, para proyectos simples que no requieren algo muy personalizado o nuevo que usan cosas comunes, puede valer. Por ejemplo, una app para un evento promocional, que tiene un calendario y un mapa de donde está cada cosa, pues podría valer crearla en una app maker. O también proyectos donde no quieres un diseño exacto o personalizar las funciones, y donde el precio y el tiempo de desarrollo, tienen un valor importante, pues también puede valer para esto. Incluso también, puede valer para prototipos de apps iniciales, y probar una idea. Aunque hay que tomar en cuenta que, si quieres evolucionar tu aplicación, vas a tener que empezarla desde cero. The post 23. App makers : Crear apps sin saber programar appeared first on Diego Laballós.

Antes de entrar en el tema, vamos a resolver una pregunta hecha a través de iVoox por José Nieto en el último capítulo: ¿crees que, en un corto o mediano plazo, las aplicaciones híbridas pueden llegar a ser iguales o incluso superiores a las aplicaciones nativas? Esto es algo que, desde el principio, siempre han intentado las aplicaciones híbridas. Es decir, las aplicaciones híbridas siempre intentan parecerse lo más posible a las aplicaciones nativas, ya sea en cuanto a diseño de interfaz, potencia, etc. Su objetivo principal es llegar a ser como las aplicaciones nativas y su idea principal de desarrollar un proyecto para todos los sistemas operativos móviles, es sencillamente genial; sería lo óptimo. Sin embargo, aquí hay un gran problema: las dos grandes empresas detrás de los sistemas operativos móviles (Apple y Google) tiran cada una por su lado. Es decir, cada uno desarrolla sus cosas y en su propio lenguaje. La verdad es que, si se quisieran poner de acuerdo para desarrollar las aplicaciones con un solo lenguaje, quizás podrían hacerlo. El problema es que no lo hacen porque al fin y al cabo se están haciendo la competencia uno a otro. Este es el mismo problema que tenemos en los ordenadores desde hace años y años. Tenemos Windows y Mac y las aplicaciones que están hechas para uno u otro sistema operativo, funcionan mucho mejor y más rápido que aquellas aplicaciones que están hechas a través de tecnologías que permiten el desarrollo de programas para su funcionamiento en los dos sistemas como Java. Pues bien, después de años y años, el panorama sigue igual. En mi opinión, los sistemas operativos móviles y en las aplicaciones móviles, esto va a seguir igual. Sí creo que las aplicaciones híbridas se seguirán acercando un poco más a las nativas, porque ya lo vienen haciendo desde hace años. Es decir, no es lo mismo una aplicación híbrida de hace cuatro años, que las de hoy en día; han mejorado muchísimo. Sin embargo, veo difícil que consigan colocarse a la par en cuanto a calidad, potencia y otros aspectos. Dicho esto, espero que quede la pregunta resuelta y vamos con el tema del día. En el capítulo anterior, estuvimos viendo las dos formas de programar: de forma nativa, o híbrida. Si lo queremos de forma nativa, tendremos que desarrollar un proyecto para cada sistema operativo; la aplicación híbrida viene a ser desarrollar un solo proyecto utilizando ciertas plataformas/tecnologías híbridas, para hacer que ese único proyecto funcione en cualquier sistema operativo. <h3>App makers: Crear aplicaciones sin saber programar</h3> Vistas estas dos formas de programar aplicaciones, tenemos otra opción que es crear aplicaciones sin saber programar y esto es a partir de los app makers. Este concepto no es nada nuevo en el mundo de la tecnología; ya existen programas para hacer juegos o diseñar webs sin saber programar ni conocer HTML o CSS. Esto es exactamente lo mismo, pero con aplicaciones móviles. Hay muchas plataformas y webs que se dedican a crear aplicaciones sin necesidad de saber programar. Para este capítulo, he echado un vistazo a tres de los principales porque al fin y al cabo todos vienen a ser lo mismo. He probado GoodBarber, Mobincube y App Yourself, así que vamos a ver exactamente qué son. Básicamente webs que te permiten crear aplicaciones, ya está. ¿Cómo? Pues desde la web, podemos acceder a un panel de control en el cual, arrastrando elementos, podemos crear la app. Por ejemplo, imagínate una web completamente en blanco con un panel de control desde donde puedes arrastrar botones o imágenes. Básicamente es eso, puedes arrastrar componentes de la aplicación y vas diseñando tu interfaz. Además, puedes añadir mods y plugins de funcionalidades específicas que la plataforma te ofrece. Por ejemplo, si quieres mostrar un mapa interactivo de Google Maps donde se vea una localización, pues tú podrías utilizar ese plugin, arrastrarla, configurarla con los parámetros básicos y ya lo tendrás funcionando. ¿Cómo se publican en las tiendas? Pues normalmente, a través de su panel de control, cuando terminas de crear tu aplicación, puedes generar el archivo de la app. Por ejemplo, para Android podrás descargar un archivo .APK y para iOS, un archivo. IPA. Hay que decir que los app makers, como ya dije, también utilizan plataformas híbridas. Con lo cual, con un solo proyecto, podrás crear la aplicación para tantos sistemas operativos como quieras. A partir de aquí, una vez tengas tu archivo, tendrás que crear tu propia cuenta ya sea de Google o Apple y tendrás que publicar y administrar tu aplicación. Simplemente tendrás el archivo con la aplicación ya preparada que es lo que te va a dar la plataforma. <h3>¿Hasta dónde podemos llegar con los App Makers?</h3> ¿Qué podemos hacer?, ¿hasta qué punto son potentes los app makers? Básicamente, podemos hacer lo que la plataforma nos permita. Estaremos limitados a los plugins, diseños y características que ellos nos ofrezcan. Por ejemplo, si queremos algo muy personalizado como un chat a través del cual se pueden mandar imágenes y que estas caduquen (que ya no se puedan descargar o que ya no sean visibles) al cabo de 60 segundos; seguramente no lo vamos a poder hacer. Algunas plataformas tienen algunos plugin /módulos de chats, pero como digo, nos vamos a tener que atener a lo que tengan ellos. Es decir, si el chat, únicamente tiene texto, pues es lo que vamos a tener que utilizar porque no hay más. <h3>¿Cuánto cuestan?</h3> Estas plataformas suelen hacer un cobro recurrente al año. Una vez tu las estás utilizando, tienes que pagar anualmente para mantener, actualizar y modificar tu aplicación. Más o menos, por lo que he visto, estamos hablando de unos 100-500 euros anuales. Cada una, tiene planes distintos: te dejan hacer mas o menos cosas en función de lo que quieras pagar. <h3>Limitaciones de las App Makers</h3> Obviamente, este tipo de plataformas donde puedes hacer aplicaciones sin saber programar tienen sus limitaciones. La mayor de estas es la que ya he dicho: que no puedes hacer más de lo que ellos te ofrecen y permiten. Sí que hay unas plataformas con opciones para ampliar las funcionalidades a través de programación, de sus propias reglas. Normalmente será a través de lenguajes como Javascript, pero obviamente vas a necesitar un programador o saber programar para seguir ampliando o modificando el comportamiento de tu aplicación. Sin embargo, hay que decir que estas ampliaciones o modificaciones también son limitadas. Por ejemplo, como experiencia propia, en un proyecto de Mobincube que tuve a través de una empresa que me contrató, el objetivo era instalar la app en unas tabletas que se iban a regalar a los clientes. El tema era que la aplicación necesitaba iniciarse automáticamente. Esto es algo que, con un desarrollo nativo o incluso híbrida, puede hacerse, no es mucho problema. El problema es que, como la aplicación estaba hecha en MobinCube, no se podía tocar el código. Una vez que tengas la aplicación, a pesar de que te pertenece a ti, tú no puedes entrar al código y modificarlo (por lo menos en esa plataforma). Por tanto, se tuvo que hacer una cosa distinta porque no se podía modificar el código. Con esto, me refiero a que las aplicaciones que puedes hacer, son limitadas. Otros temas, son la calidad/potencia de las aplicaciones. Como ya decía, esto no vienen a ser otra cosa que aplicaciones web híbridas, así que obviamente van a tener una potencia menor que las aplicaciones nativas o incluso híbridas, porque son menos configurables. <h3>El Lock In</h3> Si algún día quieres irte de la plataforma, vas a tener que rehacer casi totalmente tu aplicación. Es decir, si tu creas una aplicación con uno de estos App Makers, vas a tener que estar ligado a esta plataforma si no quieres empezar de cero tu proyecto otra vez. Algunas plataformas si te dejan migrar datos, como una base de datos que hayas recopilado (usuarios, por ejemplo), pero, la interfaz y las funcionalidades que quieras desarrollar en tu aplicación, vas a tener que empezar desde cero. <h3>¿Son útiles los App Makers?</h3> Dicho esto, ¿son realmente útiles? Si, obviamente cada tecnología tiene su utilidad y los App Makers la tienen. Al igual que los programas que te dejan crear juegos o web y, que sirven para unas cosas y no para otras. El gran punto a favor que tienen, es la simplicidad y el precio económico en comparación con un desarrollo personalizado. Por lo tanto, para proyectos simples que no requieren algo muy personalizado o nuevo que usan cosas comunes, puede valer. Por ejemplo, una app para un evento promocional, que tiene un calendario y un mapa de donde está cada cosa, pues podría valer crearla en una app maker. O también proyectos donde no quieres un diseño exacto o personalizar las funciones, y donde el precio y el tiempo de desarrollo, tienen un valor importante, pues también puede valer para esto. Incluso también, puede valer para prototipos de apps iniciales, y probar una idea. Aunque hay que tomar en cuenta que, si quieres evolucionar tu aplicación, vas a tener que empezarla desde cero. The post <a href="https://diegolaballos.com/podcast/23-app-makers-crear-apps-sin-saber-programar/" rel="nofollow" target="_blank">23. App makers : Crear apps sin saber programar</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

23. App makers : Crear apps sin saber programar

Para empezar, vamos a hacer un pequeño recordatorio de los tipos de aplicaciones que teníamos según la forma en la que se desarrollaban.  Las aplicaciones móviles nativas En primer lugar, tenemos las aplicaciones nativas, las cuales son las “típicas” y se desarrollan para un sistema operativo en concreto con el lenguaje de ese sistema. Por ejemplo, en Android, tenemos que desarrollar en Java principalmente; y en el caso de iOS, en Swift. El desarrollo nativo, significa que tendremos un proyecto independiente para cada sistema operativo que queramos soportar. Si queremos lanzar nuestro proyecto para Android y iOS y queremos desarrollar una aplicación nativa, tendremos que tener un proyecto para cada sistema operativo en su respectivo lenguaje. Las aplicaciones híbridas Lo que vimos en el capítulo anterior, es que existe otra manera de desarrollar aplicaciones y estas son, las aplicaciones híbridas. Estas, hacen uso de ciertas tecnologías que vienen de la web para que, con solo desarrollar un proyecto, poder hacer que funcione en distintos sistemas operativos. En este caso, si quisiéramos desarrollar nuestra aplicación para Android y iOS de forma híbrida, solo necesitaríamos un proyecto; después, con unos mínimos cambios ya podríamos tener esa aplicación lista para funcionar en ambos sistemas operativos. A simple vista, vemos que no hay diferencias. Ambas son aplicaciones, tanto la nativa como la híbrida son aplicaciones que van a estar en la store de turno, ya sea Google Play o App Store, las vas a poder descargar al móvil y tendrás el icono para acceder a ellas. Asimismo, podrás acceder al hardware como la cámara y el GPS. Pero, aun así, y aunque a simple vista sean aplicaciones, sí que tienen grandes diferencias y es lo que vamos a ver en este capítulo. Vamos a ver esos grandes puntos básicos donde se diferencian y vamos a tratar de ver cuál es mejor en cada uno de estos puntos. Voy a hacerlo desde un punto de vista lo más objetivo posible porque obviamente yo tengo mi idea y mi preferencia; al fin y al cabo, soy desarrollador de aplicaciones móviles nativas para Android. Coste y tiempo de desarrollo En primer lugar, tenemos el tiempo de desarrollo y coste, los cuales son de los puntos más importantes a veces, a la hora de desarrollar una aplicación. Son dos puntos que van muy ligados porque entre más tiempo de desarrollo, más coste va a tener. Obviamente aquí, las aplicaciones híbridas ganan siempre que tengamos en cuenta que se desarrollara la aplicación para más de un sistema operativo. En caso de desarrollar para un solo sistema, el tiempo sería muy parecido, pero recordemos lo que hemos dicho: si para hacer una aplicación híbrida para Android y iOS, necesito un solo proyecto y para hacerlo de manera nativa, necesito dos proyectos independientes, en este último caso es mas tiempo de desarrollo y esto es clarísimo. Ahora bien, si el desarrollo es para un solo sistema, el tiempo de desarrollo es muy parecido. Obviamente, no solo es tiempo y coste; también puedes suponer que puede entrar más gente a formar parte del proyecto.  Normalmente, un programador especializado en el desarrollo de Android, no tiene porque estar especializado en el desarrollo de iOS; y, lo mismo al revés. Es decir, si nosotros queremos desarrollar nuestra aplicación de forma nativa para Android y iOS, seguramente vamos a necesitar otro programador. Por otro lado, si creamos nuestra aplicación híbrida, normalmente vamos a coger un solo programador o un par; ellos mismos van a desarrollar la app para las dos plataformas. En este punto, para mí, ganan las aplicaciones híbridas. Potencia y rendimiento El segundo punto es potencia, rendimiento y experiencia de usuario, ¿a qué me refiero con todo esto? A la fluidez de una aplicación: que se abra rápido y que funcione fluidamente; cuando hagamos scroll en una lista, no vaya dando saltos o efectos extraños. En general, que todo vaya bien, que tenga potencia, que vaya rápido y que no tenga errores. ¿Por qué es importante esto? Pues, obviamente porque a todos nos gusta tener aplicaciones que funcionan rápido. ¿Cuántas veces hemos descargado aplicaciones, las hemos probado una vez, y las hemos desinstalado? Esto es muy común porque es muy fácil descargarlas, probar nuevas aplicaciones y, como solemos tener un ojo bastante crítico con ellas, a la mínima que algo no nos gusta… fuera. Muchas aplicaciones se instalan, se prueban una vez y se desinstalan. Esto lo muestran las estadísticas de una web llamada Localytics : un 26% de las aplicaciones solo se abre una vez; y un 33%, dos veces. A partir de aquí, el porcentaje va decreciendo mucho hasta que están las típicas aplicaciones que se abren más de 11 veces como WhatsApp o Facebook. Esto es importante porque más de un 39% de las aplicaciones solo se abren 1 o 2 veces; lo que quiere decir que la primera impresión cuenta muchísimo. Otras estadísticas que muestran lo importante que es la potencia o fluidez de una aplicación son las de Similarweb. En este caso, hay dos estadísticas muy interesantes. La primera, es sobre una la pregunta ¿Qué tan importante te parece la fluidez de una aplicación, que no tenga errores, etc.? Un 34% de la gente consideraba que era muy importante; un 50%, bastante importante; y luego un 11%, un 4% y un 1% lo consideraban no tan importante. Más de un 84% de la gente en este caso, consideraba la fluidez de una aplicación como algo muy importante. La otra estadística que tiene es sobre como relacionaba la gente a partir de una mala experiencia en una aplicación, ya sea porque iba lenta o daba errores. Pues bien, el 48% de la gente decía que seguramente no iba a volver a esa app; un 34% dijo que se iba a cambiar a la app de la competencia; y, un 31% que iba a contar a otras personas esa mala experiencia. Es decir, tenemos un ojo demasiado crítico con las aplicaciones y eso de demuestra si miramos las reviews que hay el Google Play o App Store. Enseguida la gente se queja mucho o pone calificaciones de una estrella. Por tanto, este punto es bastante importante. Hay que decir aquí, que la gran mayoría de aplicaciones grandes que se utilizan, son nativas. Y es que, aquí sí hay que decir que las aplicaciones nativas son más rápidas, potentes y fluidas que las aplicaciones híbridas. De esto, no hay ninguna duda: aquí ganan claramente las aplicaciones nativas porque tratan directamente con el sistema operativo; no hay intermediarios por lo que, toda la comunicación va a ser bastante rápida. Sin embargo, hay que decir que una app híbrida muy bien hecha puede llegar a una nativa que no esté tan bien hecha. Esto es como hacer una carrera entre un Ferrari y un Seat: un mal conductor con un Ferrari, podría perder ante un buen conductor con un Seat; pero, en condiciones normales, un Ferrari ganará. Esto es más o menos lo mismo, la aplicación nativa siempre va a ser más potente que la híbrida, pero esta última, si está bien hecha, puede ser superior. Mantenimiento y errores Aquí hay dos puntos a tener en cuenta. El primero, es que las apps nativas tienen el inconveniente de tener más líneas de código, si contamos que tenemos un proyecto para cada sistema operativo. Cuantas más líneas de código haya, más propensa a errores será la aplicación. Esto es lo mismo a que, por ejemplo, cuanto más deporte hagas, más riesgos a lesionarte tienes; si no haces deporte, tienes muy pocas posibilidades de hacerte un esguince en el tobillo. Desde este punto, podríamos decir que las aplicaciones nativas pueden ser más propensas a tener errores de código, por el hecho de que hay más líneas de código. Sin embargo, el otro punto desde el cual se puede ver esto, es que las aplicaciones híbridas tienen como un punto conflictivo, el hecho de que intentan englobar demasiadas cosas en un solo sistema. A veces, los sistemas creados por las distintas plataformas híbridas traen algunos errores ellas mismas, que pueden ser muy difíciles de corregir por el programador que está creando una aplicación. Otra cosa, es que muchas veces va a ser difícil que funcione o que las cosas se vean exactamente igual en todos los dispositivos. Con esto, no voy a dar como ganador a ninguno de los dos porque ambas pueden tener problemas. Encontrar programadores El último punto que quería comentar es la facilidad de encontrar gente para trabajar en el proyecto. Este punto es bastante importante y más de lo que puede parecer. Vamos a ver que trato de explicar aquí. Tanto si la aplicación la va a desarrollar un trabajador de la empresa, o tanto si la va a desarrollar un freelance; siempre tenemos que tener en cuenta que puede llegar un día en el que esa persona no esté encargada del proyecto. En mi opinión esto muy importante en la tecnología. No basarse en lo que una sola persona crea o decida por su propio gusto, sino por donde va el mercado. Por ejemplo, si tú vas a instalar ordenadores en tu empresa, lo más común es que instales Windows, porque además de que muchos programas funcionan sobre él, es lo que la gente sabe utilizar. Si pusieras Mac, Linux o cualquier otro sistema operativo minoritario, a la gente le costaría más adaptarse a ese sistema; habría menos programas para utilizar, menos recursos y menos soporte. Pues bien, desarrolladores Android nativos hay muchos; desarrolladores iOS nativos, hay otros tantos; desarrolladores de apps híbridas los hay también, pero cuidado: estos usualmente están especializados en una tecnología de las varias que hay. Por lo tanto, tú no vas a elegir un desarrollador de aplicaciones híbridas sino uno especializado en una tecnología híbrida en concreto. Con lo cual, en función de la tecnología híbrida que utilices, te será más difícil encontrar a otra persona para continuar el proyecto en el caso de que la persona anterior se tenga que ir por cualquier motivo. Es un punto a tener en cuenta y quería añadirlo junto con los demás que son más técnicos. Así que, en este caso, para el desarrollo de aplicaciones nativas, sin duda va a ser más fácil encontrar gente que sepa del proyecto y de esa tecnología. Las aplicaciones híbridas tienen la gran ventaja de ahorrar costes y tiempos de desarrollo; esto es sin duda, un punto muy fuerte y muy interesante para mucha gente. Las aplicaciones nativas, por otro lado, son más potentes, rápidas y eficientes; son menos propensas a errores y tienen un completo acceso al hardware y a las últimas novedades. Asimismo, tienen una comunidad de desarrolladores detrás. ¿Cuál es mi opinión? Dicho esto, ¿Cuál elegimos? Yo voy a dar mi opinión en los distintos escenarios. Por ejemplo, si queremos desarrollar una aplicación en Android para gestionar una empresa, yo aquí me iría por el desarrollo nativo por el tiempo y el coste. Esto también es el punto fuerte de las aplicaciones híbridas, pero en este caso, tampoco va a ser un punto tan fuerte si queremos desarrollar una sola aplicación; el tiempo y el coste será muy parecido a la nativa. Segunda situación: una app para varios sistemas y que es un prototipo inicial, en el cual el tiempo y el precio tienen mucha importancia por cualquier motivo. En este caso, sin duda, haría una aplicación híbrida. Si vamos a hacer un prototipo inicial, si queremos ir rápido y ahorrar costes, la aplicación híbrida es sin duda la mejor. Tercera opción: una app para varios sistemas que tampoco es el corazón del negocio, sino que es una cosa secundaria y tampoco requiere una gran excelencia. En este caso, podríamos hacer una aplicación híbrida o una nativa. Sin embargo, como digo, como es una cosa secundaria del negocio, imagino que el coste y el tiempo serán importantes, quizás me decante por una híbrida. Finalmente, un cuarto escenario: una app que va a ser el corazón de tu proyecto y tu idea y buscas una calidad excelente. En este caso, sin duda, aunque sean dos sistemas operativos, haría una aplicación nativa. Si es el corazón de tu negocio, tu idea, tu proyecto y es lo que van a ver tus usuarios, sin duda tienes que buscar la excelencia, y esta está en las aplicaciones nativas. Aunque tengas que pagar más por ello y tardes un poco más en desarrollarlo. Esta es mi opinión y lo que yo recomendaría a alguien que me preguntara. Así que, resumiendo todo, las aplicaciones nativas son más potentes que las híbridas. Ahora bien, tienen el gran inconveniente de que son más costosas y lleva más tiempo hacerlas. Las aplicaciones híbridas son más sencillas, si se trata de lograr lo más parecido a una aplicación nativa con el mínimo esfuerzo posible. Ambas formas, son métodos totalmente viables para crear una app y se adaptan mejor a unas u otras circunstancias. Simplemente hay que ver qué necesidades tenemos y qué puntos son más importantes para nosotros. The post 22. Aplicación nativa o aplicación híbrida. ¿Cuál elegir? appeared first on Diego Laballós.

Para empezar, vamos a hacer un pequeño recordatorio de los tipos de aplicaciones que teníamos según la forma en la que se desarrollaban. <h3>Las aplicaciones móviles nativas</h3> En primer lugar, tenemos las aplicaciones nativas, las cuales son las “típicas” y se desarrollan para un sistema operativo en concreto con el lenguaje de ese sistema. Por ejemplo, en Android, tenemos que desarrollar en Java principalmente; y en el caso de iOS, en Swift. El desarrollo nativo, significa que tendremos un proyecto independiente para cada sistema operativo que queramos soportar. Si queremos lanzar nuestro proyecto para Android y iOS y queremos desarrollar una aplicación nativa, tendremos que tener un proyecto para cada sistema operativo en su respectivo lenguaje. <h3>Las aplicaciones híbridas</h3> Lo que vimos en el capítulo anterior, es que existe otra manera de desarrollar aplicaciones y estas son, las aplicaciones híbridas. Estas, hacen uso de ciertas tecnologías que vienen de la web para que, con solo desarrollar un proyecto, poder hacer que funcione en distintos sistemas operativos. En este caso, si quisiéramos desarrollar nuestra aplicación para Android y iOS de forma híbrida, solo necesitaríamos un proyecto; después, con unos mínimos cambios ya podríamos tener esa aplicación lista para funcionar en ambos sistemas operativos. A simple vista, vemos que no hay diferencias. Ambas son aplicaciones, tanto la nativa como la híbrida son aplicaciones que van a estar en la store de turno, ya sea Google Play o App Store, las vas a poder descargar al móvil y tendrás el icono para acceder a ellas. Asimismo, podrás acceder al hardware como la cámara y el GPS. Pero, aun así, y aunque a simple vista sean aplicaciones, sí que tienen grandes diferencias y es lo que vamos a ver en este capítulo. Vamos a ver esos grandes puntos básicos donde se diferencian y vamos a tratar de ver cuál es mejor en cada uno de estos puntos. Voy a hacerlo desde un punto de vista lo más objetivo posible porque obviamente yo tengo mi idea y mi preferencia; al fin y al cabo, soy desarrollador de aplicaciones móviles nativas para Android. <h3>Coste y tiempo de desarrollo</h3> En primer lugar, tenemos el tiempo de desarrollo y coste, los cuales son de los puntos más importantes a veces, a la hora de desarrollar una aplicación. Son dos puntos que van muy ligados porque entre más tiempo de desarrollo, más coste va a tener. Obviamente aquí, las aplicaciones híbridas ganan siempre que tengamos en cuenta que se desarrollara la aplicación para más de un sistema operativo. En caso de desarrollar para un solo sistema, el tiempo sería muy parecido, pero recordemos lo que hemos dicho: si para hacer una aplicación híbrida para Android y iOS, necesito un solo proyecto y para hacerlo de manera nativa, necesito dos proyectos independientes, en este último caso es mas tiempo de desarrollo y esto es clarísimo. Ahora bien, si el desarrollo es para un solo sistema, el tiempo de desarrollo es muy parecido. Obviamente, no solo es tiempo y coste; también puedes suponer que puede entrar más gente a formar parte del proyecto. Normalmente, un programador especializado en el desarrollo de Android, no tiene porque estar especializado en el desarrollo de iOS; y, lo mismo al revés. Es decir, si nosotros queremos desarrollar nuestra aplicación de forma nativa para Android y iOS, seguramente vamos a necesitar otro programador. Por otro lado, si creamos nuestra aplicación híbrida, normalmente vamos a coger un solo programador o un par; ellos mismos van a desarrollar la app para las dos plataformas. En este punto, para mí, ganan las aplicaciones híbridas. <h3>Potencia y rendimiento</h3> El segundo punto es potencia, rendimiento y experiencia de usuario, ¿a qué me refiero con todo esto? A la fluidez de una aplicación: que se abra rápido y que funcione fluidamente; cuando hagamos scroll en una lista, no vaya dando saltos o efectos extraños. En general, que todo vaya bien, que tenga potencia, que vaya rápido y que no tenga errores. ¿Por qué es importante esto? Pues, obviamente porque a todos nos gusta tener aplicaciones que funcionan rápido. ¿Cuántas veces hemos descargado aplicaciones, las hemos probado una vez, y las hemos desinstalado? Esto es muy común porque es muy fácil descargarlas, probar nuevas aplicaciones y, como solemos tener un ojo bastante crítico con ellas, a la mínima que algo no nos gusta… fuera. Muchas aplicaciones se instalan, se prueban una vez y se desinstalan. Esto lo muestran las estadísticas de una web llamada Localytics : un 26% de las aplicaciones solo se abre una vez; y un 33%, dos veces. A partir de aquí, el porcentaje va decreciendo mucho hasta que están las típicas aplicaciones que se abren más de 11 veces como WhatsApp o Facebook. Esto es importante porque más de un 39% de las aplicaciones solo se abren 1 o 2 veces; lo que quiere decir que la primera impresión cuenta muchísimo. Otras estadísticas que muestran lo importante que es la potencia o fluidez de una aplicación son las de Similarweb. En este caso, hay dos estadísticas muy interesantes. La primera, es sobre una la pregunta ¿Qué tan importante te parece la fluidez de una aplicación, que no tenga errores, etc.? Un 34% de la gente consideraba que era muy importante; un 50%, bastante importante; y luego un 11%, un 4% y un 1% lo consideraban no tan importante. Más de un 84% de la gente en este caso, consideraba la fluidez de una aplicación como algo muy importante. La otra estadística que tiene es sobre como relacionaba la gente a partir de una mala experiencia en una aplicación, ya sea porque iba lenta o daba errores. Pues bien, el 48% de la gente decía que seguramente no iba a volver a esa app; un 34% dijo que se iba a cambiar a la app de la competencia; y, un 31% que iba a contar a otras personas esa mala experiencia. Es decir, tenemos un ojo demasiado crítico con las aplicaciones y eso de demuestra si miramos las reviews que hay el Google Play o App Store. Enseguida la gente se queja mucho o pone calificaciones de una estrella. Por tanto, este punto es bastante importante. Hay que decir aquí, que la gran mayoría de aplicaciones grandes que se utilizan, son nativas. Y es que, aquí sí hay que decir que las aplicaciones nativas son más rápidas, potentes y fluidas que las aplicaciones híbridas. De esto, no hay ninguna duda: aquí ganan claramente las aplicaciones nativas porque tratan directamente con el sistema operativo; no hay intermediarios por lo que, toda la comunicación va a ser bastante rápida. Sin embargo, hay que decir que una app híbrida muy bien hecha puede llegar a una nativa que no esté tan bien hecha. Esto es como hacer una carrera entre un Ferrari y un Seat: un mal conductor con un Ferrari, podría perder ante un buen conductor con un Seat; pero, en condiciones normales, un Ferrari ganará. Esto es más o menos lo mismo, la aplicación nativa siempre va a ser más potente que la híbrida, pero esta última, si está bien hecha, puede ser superior. <h3>Mantenimiento y errores</h3> Aquí hay dos puntos a tener en cuenta. El primero, es que las apps nativas tienen el inconveniente de tener más líneas de código, si contamos que tenemos un proyecto para cada sistema operativo. Cuantas más líneas de código haya, más propensa a errores será la aplicación. Esto es lo mismo a que, por ejemplo, cuanto más deporte hagas, más riesgos a lesionarte tienes; si no haces deporte, tienes muy pocas posibilidades de hacerte un esguince en el tobillo. Desde este punto, podríamos decir que las aplicaciones nativas pueden ser más propensas a tener errores de código, por el hecho de que hay más líneas de código. Sin embargo, el otro punto desde el cual se puede ver esto, es que las aplicaciones híbridas tienen como un punto conflictivo, el hecho de que intentan englobar demasiadas cosas en un solo sistema. A veces, los sistemas creados por las distintas plataformas híbridas traen algunos errores ellas mismas, que pueden ser muy difíciles de corregir por el programador que está creando una aplicación. Otra cosa, es que muchas veces va a ser difícil que funcione o que las cosas se vean exactamente igual en todos los dispositivos. Con esto, no voy a dar como ganador a ninguno de los dos porque ambas pueden tener problemas. <h3>Encontrar programadores</h3> El último punto que quería comentar es la facilidad de encontrar gente para trabajar en el proyecto. Este punto es bastante importante y más de lo que puede parecer. Vamos a ver que trato de explicar aquí. Tanto si la aplicación la va a desarrollar un trabajador de la empresa, o tanto si la va a desarrollar un freelance; siempre tenemos que tener en cuenta que puede llegar un día en el que esa persona no esté encargada del proyecto. En mi opinión esto muy importante en la tecnología. No basarse en lo que una sola persona crea o decida por su propio gusto, sino por donde va el mercado. Por ejemplo, si tú vas a instalar ordenadores en tu empresa, lo más común es que instales Windows, porque además de que muchos programas funcionan sobre él, es lo que la gente sabe utilizar. Si pusieras Mac, Linux o cualquier otro sistema operativo minoritario, a la gente le costaría más adaptarse a ese sistema; habría menos programas para utilizar, menos recursos y menos soporte. Pues bien, desarrolladores Android nativos hay muchos; desarrolladores iOS nativos, hay otros tantos; desarrolladores de apps híbridas los hay también, pero cuidado: estos usualmente están especializados en una tecnología de las varias que hay. Por lo tanto, tú no vas a elegir un desarrollador de aplicaciones híbridas sino uno especializado en una tecnología híbrida en concreto. Con lo cual, en función de la tecnología híbrida que utilices, te será más difícil encontrar a otra persona para continuar el proyecto en el caso de que la persona anterior se tenga que ir por cualquier motivo. Es un punto a tener en cuenta y quería añadirlo junto con los demás que son más técnicos. Así que, en este caso, para el desarrollo de aplicaciones nativas, sin duda va a ser más fácil encontrar gente que sepa del proyecto y de esa tecnología. Las aplicaciones híbridas tienen la gran ventaja de ahorrar costes y tiempos de desarrollo; esto es sin duda, un punto muy fuerte y muy interesante para mucha gente. Las aplicaciones nativas, por otro lado, son más potentes, rápidas y eficientes; son menos propensas a errores y tienen un completo acceso al hardware y a las últimas novedades. Asimismo, tienen una comunidad de desarrolladores detrás. <h3>¿Cuál es mi opinión?</h3> Dicho esto, ¿Cuál elegimos? Yo voy a dar mi opinión en los distintos escenarios. Por ejemplo, si queremos desarrollar una aplicación en Android para gestionar una empresa, yo aquí me iría por el desarrollo nativo por el tiempo y el coste. Esto también es el punto fuerte de las aplicaciones híbridas, pero en este caso, tampoco va a ser un punto tan fuerte si queremos desarrollar una sola aplicación; el tiempo y el coste será muy parecido a la nativa. Segunda situación: una app para varios sistemas y que es un prototipo inicial, en el cual el tiempo y el precio tienen mucha importancia por cualquier motivo. En este caso, sin duda, haría una aplicación híbrida. Si vamos a hacer un prototipo inicial, si queremos ir rápido y ahorrar costes, la aplicación híbrida es sin duda la mejor. Tercera opción: una app para varios sistemas que tampoco es el corazón del negocio, sino que es una cosa secundaria y tampoco requiere una gran excelencia. En este caso, podríamos hacer una aplicación híbrida o una nativa. Sin embargo, como digo, como es una cosa secundaria del negocio, imagino que el coste y el tiempo serán importantes, quizás me decante por una híbrida. Finalmente, un cuarto escenario: una app que va a ser el corazón de tu proyecto y tu idea y buscas una calidad excelente. En este caso, sin duda, aunque sean dos sistemas operativos, haría una aplicación nativa. Si es el corazón de tu negocio, tu idea, tu proyecto y es lo que van a ver tus usuarios, sin duda tienes que buscar la excelencia, y esta está en las aplicaciones nativas. Aunque tengas que pagar más por ello y tardes un poco más en desarrollarlo. Esta es mi opinión y lo que yo recomendaría a alguien que me preguntara. Así que, resumiendo todo, las aplicaciones nativas son más potentes que las híbridas. Ahora bien, tienen el gran inconveniente de que son más costosas y lleva más tiempo hacerlas. Las aplicaciones híbridas son más sencillas, si se trata de lograr lo más parecido a una aplicación nativa con el mínimo esfuerzo posible. Ambas formas, son métodos totalmente viables para crear una app y se adaptan mejor a unas u otras circunstancias. Simplemente hay que ver qué necesidades tenemos y qué puntos son más importantes para nosotros. The post <a href="https://diegolaballos.com/podcast/22-aplicacion-nativa-o-aplicacion-hibrida-cual-elegir/" rel="nofollow" target="_blank">22. Aplicación nativa o aplicación híbrida. ¿Cuál elegir?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

22. Aplicación nativa o aplicación híbrida. ¿Cuál elegir?

Hasta ahora, hemos visto el desarrollo de aplicaciones móviles nativas. Una aplicación nativa significa que ha sido desarrollada para un sistema en concreto. Por ejemplo, como hemos visto hasta ahora, para desarrollar una aplicación en Android, necesitaremos programarla en Java principalmente, mientras que, en iOS, utilizaremos el lenguaje Swift (también principalmente, porque en ambas existen otras alternativas). ¿Qué son las aplicaciones híbridas? La aplicación desarrollada en Java, vale únicamente para Android; no podemos llevarla hacia iOS. Si queremos desarrollar una aplicación para este último, tendremos que hacerlo en Swift que, a su vez, tampoco vale para Android. Así que, si queremos desarrollar nuestra aplicación de forma nativa, tendremos que crear dos proyectos separados: uno para Android, y otro para iOS. Esto, es lo que viene llamarse desarrollo de aplicaciones móviles nativas. Es lo que yo hago personalmente con Android: crear aplicaciones nativas para Android. ¿Hay alternativas para desarrollar aplicaciones móviles? Ahora bien, ¿existe una manera alternativa de desarrollar aplicaciones móviles? Es decir, que no sea directamente utilizando el lenguaje de cada plataforma y así, estar obligado a desarrollar tantas versiones de la aplicación como sistemas operativos queramos soportar.  Pues sí existe, y se engloba dentro de las llamadas tecnologías híbridas. Es decir, tecnologías que nos permiten desarrollar aplicaciones móviles sin tener que depender o utilizar el lenguaje específico de la plataforma / sistema operativo. Una aplicación híbrida, es una aplicación hecha con tecnologías híbridas, lo cual es bastante fácil de entender. A simple vista, es una aplicación “más”: podrás subirla a las tiendas de aplicaciones, descargarla a tu móvil, acceder a ella a través del típico icono del móvil; y utilizar la cámara, el GPS, y en general todos los sensores del móvil. ¿Dónde está la diferencia?  ¿Cuál es la idea principal de las aplicaciones híbridas? Podríamos decir que el “lema” de estas, es desarrollar una sola aplicación que valga para cualquier sistema. En otras palabras, en vez de desarrollar una aplicación en Java para Android, y en Swift para iOS, hacer solo una única versión, con una sola tecnología y que automáticamente pueda correr en cualquier sistema. La verdad, suena muy bien, ya que, desarrollando un solo proyecto, ahorraremos en costes, tiempo de desarrollo y también en el esfuerzo de mantener dos proyectos paralelos (o como tantos sistemas queramos soportar). Asimismo, ahorra personal. Por ejemplo, para una aplicación nativa, quizás se necesite una persona para el desarrollo en iOS y otra para Android. De esta manera, si solo estamos utilizando una sola tecnología, podemos tener una o un par de personas que estén desarrollando ese proyecto que automáticamente valga para todos los sistemas. Pero, como todo en la vida las aplicaciones híbridas no solo tienen ventajas, sino también inconvenientes. Entonces, ¿Cómo es posible desarrollar una app que valga para más de un sistema, si al principio dijimos que cada sistema operativo específico?, ¿Qué pasa con las personas que hacen aplicaciones nativas (como yo) ?, ¿no se han “enterado” de esto o siguen anclados en el pasado?  No es del todo así, porque el desarrollo de aplicaciones tanto nativas como híbridas tienen sus desventajas y ventajas. Podríamos decir, que las híbridas hacen un poco de “trampa” para ejecutarse. La esencia de la tecnología híbrida La idea detrás de esta tecnología es la siguiente: si miramos en cualquier sistema operativo móvil moderno (Android, iOS, Windows Phone), hay un navegador web (Chrome y Safari son ejemplos en Android y iOS respectivamente). Estos, se pueden utilizar dentro del desarrollo de aplicaciones. Es decir, los desarrolladores pueden incrustar un navegador dentro de una aplicación. ¿Cómo funciona esto? Seguro que alguna vez os habéis dado cuenta. Por ejemplo, estás en Twitter y picas un enlace. Si os fijáis, no vas a salir hacia el navegador real como Chrome en Android; sino que vas a ir a un navegador dentro de la propia aplicación de Twitter. Pues bien, eso es un navegador incrustado, dentro de Twitter. Sabiendo esto, la web se desarrolla con una tecnología base que siempre es la misma: HTML, CSS y JavaScript. Cuando desarrollas una web, únicamente construyes una sola; no es como en las aplicaciones móviles nativas. ¿Por qué? Porque todos los navegadores entienden esas tres tecnologías, ya sea Chrome o Safari. Ambos van a pintar igual una misma web. Por lo tanto, la idea de las plataformas que permiten desarrollar aplicaciones híbridas, es conectar todos estos puntos anteriores y decir ¿Qué pasa si creamos una aplicación básica, únicamente con un navegador incrustado a pantalla completa? Y, a partir de aquí creamos la aplicación básica con HTML, CSS y JavaScript porque el navegador móvil que va integrado dentro de la app, también muestra estas tecnologías. Y así es, como básicamente funciona la mayoría de tecnologías híbridas. En resumen, el desarrollador no estará programando directamente contra el sistema operativo, sino que lo estará haciendo contra un navegador. Es decir, no dejará de hacer otra cosa que programar una web. Lo que pasa, es que esa web no se va a acceder desde el típico navegador que podemos tener en el móvil u ordenador; sino, que se va a ejecutar desde un navegador incrustado dentro de una aplicación. Otra cosa que seguramente os podéis preguntar es, ¿Cómo pueden acceder al hardware del móvil, como la cámara y demás sensores? Porque como hemos dicho, es una aplicación. Aunque lo que estemos desarrollando vaya dentro del navegador, este está dentro de la aplicación (hay que pensar esto como una serie de capas: aplicación, navegador y nuestra aplicación que corre sobre el navegador, el cual a su vez corre sobre la aplicación. Es un poco lioso, pero hay que pensarlo como una serie de tres capas. Las plataformas que crean estas tecnologías híbridas, se encargan de conectar esta parte nativa de los sensores con el navegador. Es decir, si la parte nativa del navegador está en la capa debajo de todo, y luego tenemos el navegador, las empresas que están detrás de estas tecnologías híbridas, se encargan de conectar el móvil con la aplicación y esta con el navegador. De esta manera, los desarrolladores pueden acceder desde el propio navegador al hardware del móvil. También hay que hacer un apunte que no exactamente todas las tecnologías híbridas funcionan de esta manera. Hay algunas como Xamarin o ReactNative que traducen el código que es escribe, al de cada plataforma. Ejemplos de tecnologías híbridas PhoneGap, Ionic, SenchaTouch y las dos que había mencionado antes, son algunas de las más populares actualmente, aunque aún existen algunas más, así que, en el caso de que quieras desarrollar una aplicación híbrida, y si no sabes cómo hacerla tú mismo, tendrás que buscar un programador especializado en estas tecnologías porque normalmente un programador va a estar especializado en una u otra tecnología; es muy difícil que domine todas las tecnologías híbridas ya que hay grandes diferencias entre ellas. Por otro lado, y de la mano de las aplicaciones híbridas, tampoco me quería olvidar de los llamados app makers. Estas son webs que permiten desarrollar una aplicación sin tener conocimientos de programación.  Lo que hacen básicamente, es ofrecernos un panel web desde donde nosotros podemos ir arrastrando componentes y crear nuestra interfaz de usuarios. Además, suelen tener un sistema de plugins para añadir ciertas funcionalidades más complejas como e-commerce o mapas. Estas plataformas, no dejan de ser aplicaciones híbridas. Lo que están haciendo es desarrollar tu aplicación con una tecnología híbrida y lo único que hacen es ofrecerte un panel de control o interfaz para que tú, sin necesidad de saber programar, puedas crearla como tu quieres.  Algunos ejemplos pueden ser GoodBarber y Mobincube. No obstante, como dije, en las tecnologías híbridas existen muchas otras plataformas. Como se puede ver, el tema de las aplicaciones híbridas es bastante complejo; existen muchas tecnologías y aunque la mayoría de ellas funcione como he explicado al principio, con el tema del navegador, no todas funcionan exactamente igual.  The post 21. ¿Qué son las aplicaciones híbridas? appeared first on Diego Laballós.

Hasta ahora, hemos visto el desarrollo de aplicaciones móviles nativas. Una aplicación nativa significa que ha sido desarrollada para un sistema en concreto. Por ejemplo, como hemos visto hasta ahora, para desarrollar una aplicación en Android, necesitaremos programarla en Java principalmente, mientras que, en iOS, utilizaremos el lenguaje Swift (también principalmente, porque en ambas existen otras alternativas). <h3>¿Qué son las aplicaciones híbridas?</h3> La aplicación desarrollada en Java, vale únicamente para Android; no podemos llevarla hacia iOS. Si queremos desarrollar una aplicación para este último, tendremos que hacerlo en Swift que, a su vez, tampoco vale para Android. Así que, si queremos desarrollar nuestra aplicación de forma nativa, tendremos que crear dos proyectos separados: uno para Android, y otro para iOS. Esto, es lo que viene llamarse desarrollo de aplicaciones móviles nativas. Es lo que yo hago personalmente con Android: crear aplicaciones nativas para Android. <h3>¿Hay alternativas para desarrollar aplicaciones móviles?</h3> Ahora bien, ¿existe una manera alternativa de desarrollar aplicaciones móviles? Es decir, que no sea directamente utilizando el lenguaje de cada plataforma y así, estar obligado a desarrollar tantas versiones de la aplicación como sistemas operativos queramos soportar. Pues sí existe, y se engloba dentro de las llamadas tecnologías híbridas. Es decir, tecnologías que nos permiten desarrollar aplicaciones móviles sin tener que depender o utilizar el lenguaje específico de la plataforma / sistema operativo. Una aplicación híbrida, es una aplicación hecha con tecnologías híbridas, lo cual es bastante fácil de entender. A simple vista, es una aplicación “más”: podrás subirla a las tiendas de aplicaciones, descargarla a tu móvil, acceder a ella a través del típico icono del móvil; y utilizar la cámara, el GPS, y en general todos los sensores del móvil. ¿Dónde está la diferencia? ¿Cuál es la idea principal de las aplicaciones híbridas? Podríamos decir que el “lema” de estas, es desarrollar una sola aplicación que valga para cualquier sistema. En otras palabras, en vez de desarrollar una aplicación en Java para Android, y en Swift para iOS, hacer solo una única versión, con una sola tecnología y que automáticamente pueda correr en cualquier sistema. La verdad, suena muy bien, ya que, desarrollando un solo proyecto, ahorraremos en costes, tiempo de desarrollo y también en el esfuerzo de mantener dos proyectos paralelos (o como tantos sistemas queramos soportar). Asimismo, ahorra personal. Por ejemplo, para una aplicación nativa, quizás se necesite una persona para el desarrollo en iOS y otra para Android. De esta manera, si solo estamos utilizando una sola tecnología, podemos tener una o un par de personas que estén desarrollando ese proyecto que automáticamente valga para todos los sistemas. Pero, como todo en la vida las aplicaciones híbridas no solo tienen ventajas, sino también inconvenientes. Entonces, ¿Cómo es posible desarrollar una app que valga para más de un sistema, si al principio dijimos que cada sistema operativo específico?, ¿Qué pasa con las personas que hacen aplicaciones nativas (como yo) ?, ¿no se han “enterado” de esto o siguen anclados en el pasado? No es del todo así, porque el desarrollo de aplicaciones tanto nativas como híbridas tienen sus desventajas y ventajas. Podríamos decir, que las híbridas hacen un poco de “trampa” para ejecutarse. <h3>La esencia de la tecnología híbrida</h3> La idea detrás de esta tecnología es la siguiente: si miramos en cualquier sistema operativo móvil moderno (Android, iOS, Windows Phone), hay un navegador web (Chrome y Safari son ejemplos en Android y iOS respectivamente). Estos, se pueden utilizar dentro del desarrollo de aplicaciones. Es decir, los desarrolladores pueden incrustar un navegador dentro de una aplicación. ¿Cómo funciona esto? Seguro que alguna vez os habéis dado cuenta. Por ejemplo, estás en Twitter y picas un enlace. Si os fijáis, no vas a salir hacia el navegador real como Chrome en Android; sino que vas a ir a un navegador dentro de la propia aplicación de Twitter. Pues bien, eso es un navegador incrustado, dentro de Twitter. Sabiendo esto, la web se desarrolla con una tecnología base que siempre es la misma: HTML, CSS y JavaScript. Cuando desarrollas una web, únicamente construyes una sola; no es como en las aplicaciones móviles nativas. ¿Por qué? Porque todos los navegadores entienden esas tres tecnologías, ya sea Chrome o Safari. Ambos van a pintar igual una misma web. Por lo tanto, la idea de las plataformas que permiten desarrollar aplicaciones híbridas, es conectar todos estos puntos anteriores y decir ¿Qué pasa si creamos una aplicación básica, únicamente con un navegador incrustado a pantalla completa? Y, a partir de aquí creamos la aplicación básica con HTML, CSS y JavaScript porque el navegador móvil que va integrado dentro de la app, también muestra estas tecnologías. Y así es, como básicamente funciona la mayoría de tecnologías híbridas. En resumen, el desarrollador no estará programando directamente contra el sistema operativo, sino que lo estará haciendo contra un navegador. Es decir, no dejará de hacer otra cosa que programar una web. Lo que pasa, es que esa web no se va a acceder desde el típico navegador que podemos tener en el móvil u ordenador; sino, que se va a ejecutar desde un navegador incrustado dentro de una aplicación. Otra cosa que seguramente os podéis preguntar es, ¿Cómo pueden acceder al hardware del móvil, como la cámara y demás sensores? Porque como hemos dicho, es una aplicación. Aunque lo que estemos desarrollando vaya dentro del navegador, este está dentro de la aplicación (hay que pensar esto como una serie de capas: aplicación, navegador y nuestra aplicación que corre sobre el navegador, el cual a su vez corre sobre la aplicación. Es un poco lioso, pero hay que pensarlo como una serie de tres capas. Las plataformas que crean estas tecnologías híbridas, se encargan de conectar esta parte nativa de los sensores con el navegador. Es decir, si la parte nativa del navegador está en la capa debajo de todo, y luego tenemos el navegador, las empresas que están detrás de estas tecnologías híbridas, se encargan de conectar el móvil con la aplicación y esta con el navegador. De esta manera, los desarrolladores pueden acceder desde el propio navegador al hardware del móvil. También hay que hacer un apunte que no exactamente todas las tecnologías híbridas funcionan de esta manera. Hay algunas como Xamarin o ReactNative que traducen el código que es escribe, al de cada plataforma. <h3>Ejemplos de tecnologías híbridas</h3> PhoneGap, Ionic, SenchaTouch y las dos que había mencionado antes, son algunas de las más populares actualmente, aunque aún existen algunas más, así que, en el caso de que quieras desarrollar una aplicación híbrida, y si no sabes cómo hacerla tú mismo, tendrás que buscar un programador especializado en estas tecnologías porque normalmente un programador va a estar especializado en una u otra tecnología; es muy difícil que domine todas las tecnologías híbridas ya que hay grandes diferencias entre ellas. Por otro lado, y de la mano de las aplicaciones híbridas, tampoco me quería olvidar de los llamados app makers. Estas son webs que permiten desarrollar una aplicación sin tener conocimientos de programación. Lo que hacen básicamente, es ofrecernos un panel web desde donde nosotros podemos ir arrastrando componentes y crear nuestra interfaz de usuarios. Además, suelen tener un sistema de plugins para añadir ciertas funcionalidades más complejas como e-commerce o mapas. Estas plataformas, no dejan de ser aplicaciones híbridas. Lo que están haciendo es desarrollar tu aplicación con una tecnología híbrida y lo único que hacen es ofrecerte un panel de control o interfaz para que tú, sin necesidad de saber programar, puedas crearla como tu quieres. Algunos ejemplos pueden ser GoodBarber y Mobincube. No obstante, como dije, en las tecnologías híbridas existen muchas otras plataformas. Como se puede ver, el tema de las aplicaciones híbridas es bastante complejo; existen muchas tecnologías y aunque la mayoría de ellas funcione como he explicado al principio, con el tema del navegador, no todas funcionan exactamente igual. The post <a href="https://diegolaballos.com/podcast/21-que-son-las-aplicaciones-hibridas/" rel="nofollow" target="_blank">21. ¿Qué son las aplicaciones híbridas?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

21. ¿Qué son las aplicaciones híbridas?

Alguien tiene una idea que piensa es la “del millón”, que va a funcionar perfectamente. Y, entonces piensa que, si se la cuenta a la gente, a conocidos, amigos, etc., se la pueden copiar. Entonces piensa: “Tengo que proteger esta idea de alguna manera hasta que me ponga a hacerla”. ¿Debes proteger tu idea? Aquí, quiero hacer una diferenciación entre las personas ante las cuales tendrías que proteger. Por un lado, están las personas en general como amigos, conocidos y desconocidos; gente en común. Y, por otro lado, tenemos la persona o empresa que se encarga de desarrollar tu proyecto. ¿Por qué lo digo? Para mí, en cuanto al primer grupo de personas que no va a tener nada que ver con tu proyecto, el no contarles tu idea u ocultarles lo que quieres hacer, es en cierto modo una tontería, y veremos porqué digo esto. Mientras que, proteger tu idea de la persona o empresa que la desarrolla, si puede tener algún sentido y también veremos por qué. ¿Por qué deberías contar tu idea a la gente en general? Empecemos viendo por qué no contar tu idea a la gente en general (conocidos, amigos, etc.), no me parece una buena idea. Dicho de otra manera, ¿Por qué no deberías proteger tu idea y deberías contársela a todo el mundo? Básicamente, el motivo principal que alguien tiene cuando no quiere contar su idea o la oculta, es porque tiene miedo de que alguien se le adelante o le copie. Y bueno, en cierta manera, el ser el primero en algo, en sacar determinado producto, sí que te da cierta ventaja, pero no lo es todo, así como la idea tampoco lo es todo. Lo que realmente importa, es quien la tira hacia adelante. Es decir, el procedimiento de hacer realidad la idea; una idea de por sí, no vale absolutamente nada. Somos muchas mentes pensando en este mundo, y no podemos creer que hemos sido los únicos en tener esa idea; hay millones de personas en el mundo y acaso vamos a pensar que la idea que hemos tenido nosotros, ¿nadie, en ningún país, en ningún sitio de este mundo, la ha pensado alguna vez? Seguramente ya la ha pensado alguien. De alguna otra manera, o mas parecida, o mas diferente, pero la habrá pensado. Así que, el hecho de que tu vayas contando tu idea a la gente, no implica nada. Es decir, tu idea ya la habrá tenido alguien antes; la gran diferencia está en quien la hace y no en quien la piensa. ¿De qué vale una idea si no la haces realidad? Absolutamente nada; la idea de por sí, no va a generar ingresos y no la va a descargar nadie. Es una idea, no es nada. ¿Acaso a nadie se le había ocurrido hacer un Facebook antes de que apareciera?, ¿A nadie se le había ocurrido hacer un buscador de internet como Google?, ¿a nadie se le había ocurrido hacer un Twitter? Segurísimo que sí. La gran diferencia está en que, la gente que creó esas empresas, en primer lugar, lo hizo; en segundo lugar, lo hizo bien. Así que, ni una idea, ni el hecho de ser el primero en hacer algo, te va a asegurar nada. Yo creo que tiene que quedar claro que, el hecho de contar tu idea a la gente, no va a poner en peligro tu proyecto. Ahora mismo, me podría poner a contar 20 ideas que tengo en mente, y no tendría ningún problema en dar todos los detalles porque si alguien lo hace… pues olé. Es muy raro que tu cuentes una idea y alguien diga: “Esto es muy genial, lo voy a hacer”. Lo normal es que la gente te dé su opinión y ya está, no te van a copiar nada. Puede darse el caso, pero es muy raro. ¿Qué estás perdiendo al no contar tu idea? Una vez visto que, el no contar tu idea a alguien tampoco te va a asegurar muchas cosas, vamos que estás perdiendo al no contarle tu idea a la gente. Como he dicho más de una vez, la opinión de una persona no cuenta para nada, frente a la de otras 100. Que tu pienses que una idea va a funcionar, no quiere decir que el resto de personas lo piensen; es más, ¿cómo vas a saber si realmente va a funcionar, si no sabes la opinión de nadie, más que la tuya? Esto es lo que pierdes: saber lo que piensa la gente, que, seguramente es muchísimo más valioso que el hecho de que nadie sepa tu idea o el riesgo de que te puedan copiar. Ahora piensa otra cosa. Quizás tus conocidos o la gente a quienes les cuentas tu idea, no te vayan a copiar porque no tengan recursos, tiempo o lo que sea. Pero, imagina ahora, que vas a buscar financiación para tu proyecto, el cual es un paso bastante común y necesario. Seguramente, tendrás que ir a un foro de inversores o algo parecido, y contarles tu idea de arriba abajo con el fin de convencerlos, porque, el argumento de “es una idea que nadie tiene y voy a petarlo, pero no os puedo contar nada porque es secreto”, no va a convencer a nadie. Por tanto, tendrás que contar tu idea de arriba a abajo, a gente que tiene el dinero y te podría copiar sin necesitarte a ti. Pues bien, no te van a copiar; lo que van a buscar no es la idea en sí, sino el equipo y la forma de tirarla hacia adelante. Como digo, una idea no vale nada de por sí. Suponiendo que pudieras llevar a cabo tu idea sin contarle a absolutamente nadie, y la llevarás hasta el final, llegaría un momento que la sacarías al público. Imagina que no funciona, ¿Qué crees?, ¿Qué no te van a intentar copiar mil y una veces, y empresas y personas que seguramente tienen más recursos que tú?  Es eso, la clave no está en la idea en sí, porque en el momento en que funcione, te van a copiar; la clave está en muchas cosas más allá de la propia idea, y no contar tu idea inicialmente, no te va a ayudar mucho. La cuestión con los copyrights, trademarks y patentes Otra cosa a tomar en cuenta, es que los recursos que tenemos para proteger una idea, no son como muchos podríamos pensar de inicio: copyright, trademarks y patentes. Todos ellos, no van a hacer que tu idea no sea desarrollada por otra persona. Es decir, no van a hacer que otra persona o empresa desarrolle esa misma idea de negocio. Por ejemplo, el copyright, protege recursos específicos: imágen, canción. El trademark por su parte, protege una marca, un nombre, un logo. Finalmente, las patentes protegen inventos. Las ideas no pueden ser patentadas. Además, es difícil, costoso y probablemente suponga un esfuerzo que la mayoría de veces no valga la pena. Si fuera tan fácil registrar una patente o una idea, habría mucha gente viviendo, únicamente de pensar ideas y registrarlas como patentes, y que venga alguien y pague; no funciona así. Se pueden patentar cosas, pero cosas muy específicas. Como digo, una idea de negocio no puede ser patentada. En general, no perdería mucho tiempo con el tema de las patentes. Al final, si tu idea funciona, vas a tener competencia. No pierdas tiempo en registrar algo que ni siquiera sabes si va a funcionar. Mejor dedícate a comprobar si realmente puede funcionar. Y, como digo, el primer paso es contarle tu idea a la máxima gente posible, lo que además permitiría que obtengas feedback que seguramente no habías pensado: “¿Qué tal si cambias esto o añades esto?, ¿yo añadiría esto?, ¿Qué pasa si sucede esto?”. En general, son cosas que inicialmente no has podido pensar y gracias a ese feedback de la gente dices: “Ah vale, pues ahora lo voy a hacer mejor” Cuéntale tu idea a personas que no conozcas tanto Otra cosa de la que tampoco me quería olvidar es que a veces, es hasta incluso mejor contarle tu idea a personas que no conoces (no me refiero a desconocidos, sino a gente que no sea de tu máxima confianza) porque, al fin y al cabo, una persona que es cercana a ti, o un familiar, quizás tenga la tentación de decirte que es una buena idea o que le parece bien, simplemente por el hecho de animarte o no desilusionarte. Mientras que, una persona que no conozcas tanto, podría ofrecerte una opinión más sincera; es algo que pienso que podría serte útil. ¿Qué pasa cuando decides contratar a alguien? Volvamos ahora al principio del capítulo donde separaba los dos tipos de personas de quienes tendrías que protegerte o no. Ahora veamos, qué pasa cuando desarrollas tu idea, y decides contratar a alguien; este es el segundo grupo de personas que decía al principio. Ya sea una empresa o un freelance, da igual, ¿debes proteger tu idea de ellos? Aquí le puedo ver sentido por varios motivos: 1) ya estás poniendo dinero sobre la mesa, así como tiempo y esfuerzo; 2) estás desarrollando tu idea; ya no será una simple idea, sino que será el proceso de desarrollarla; y 3) hay mecanismos más sencillos para protegerte sin tener que recurrir a temas de patentes y demás. ¿A qué me refiero con protegerte? No quiero decir que encargues un proyecto, te lo hagan, pagues y luego se queden con el proyecto. Esto, sería directamente denunciable sin tener que proteger nada. Me refiero a que alguien que desarrolle tu proyecto, pueda ir dando información sobre él a otras personas o incluso, que pueda desarrollar un proyecto paralelo por el otro lado; todo esto, mientras te desarrollan tu propio proyecto. La verdad no es una cosa muy ética. Una persona que se encarga de desarrollar un proyecto, no tendría que hacerlo, por lo menos, alguien decente. Pero bueno, hay mecanismos sencillos para evitar este tipo de cosas. En primer lugar, la confianza, asegúrate al máximo de la gente que contratas para hacer tu idea. Busca información de la empresa o persona y que te transmita confianza, porque esto es lo más básico. En segundo lugar, están los NDA (Non-disclosure agreement) que básicamente es un documento estándar firmado por ambas partes donde la persona que se encarga del proyecto, se compromete a no transmitir información sobre él. Como digo, es algo estándar y hasta podrás encontrar plantillas de ejemplos en línea. Yo he firmado más de uno de estos documentos en proyectos en los que he trabajado y no he tenido ningún problema; es simple, fácil, y el propietario se queda más tranquilo de que su proyecto, no sale más allá del ámbito del desarrollo. Por último, tenemos los NCA (Non-competence agreement). Estos, son acuerdos de no competencia, en donde básicamente, la persona encargada del proyecto, se compromete a no participar en proyectos que se consideren competencia del mismo, durante X tiempo. Esto, no es tan común y personalmente, no he firmado ninguno, pero están ahí. Una vez que hayas firmado estos contratos, lo que hay que tener en cuenta, es que hay que compartir el máximo de información posible con la persona o empresa que se encarga de desarrollar tu proyecto. La comunicación entre desarrollador y propietario es vital para el proyecto. De hecho, hasta el propio encargado de desarrollar el proyecto, te podría aportar de sus ideas para incorporarlas como sugerencia. The post 20. ¡Tengo una idea para una app! ¿Debo protegerla? appeared first on Diego Laballós.

Alguien tiene una idea que piensa es la “del millón”, que va a funcionar perfectamente. Y, entonces piensa que, si se la cuenta a la gente, a conocidos, amigos, etc., se la pueden copiar. Entonces piensa: “Tengo que proteger esta idea de alguna manera hasta que me ponga a hacerla”. <h3>¿Debes proteger tu idea?</h3> Aquí, quiero hacer una diferenciación entre las personas ante las cuales tendrías que proteger. Por un lado, están las personas en general como amigos, conocidos y desconocidos; gente en común. Y, por otro lado, tenemos la persona o empresa que se encarga de desarrollar tu proyecto. ¿Por qué lo digo? Para mí, en cuanto al primer grupo de personas que no va a tener nada que ver con tu proyecto, el no contarles tu idea u ocultarles lo que quieres hacer, es en cierto modo una tontería, y veremos porqué digo esto. Mientras que, proteger tu idea de la persona o empresa que la desarrolla, si puede tener algún sentido y también veremos por qué. <h3>¿Por qué deberías contar tu idea a la gente en general?</h3> Empecemos viendo por qué no contar tu idea a la gente en general (conocidos, amigos, etc.), no me parece una buena idea. Dicho de otra manera, ¿Por qué no deberías proteger tu idea y deberías contársela a todo el mundo? Básicamente, el motivo principal que alguien tiene cuando no quiere contar su idea o la oculta, es porque tiene miedo de que alguien se le adelante o le copie. Y bueno, en cierta manera, el ser el primero en algo, en sacar determinado producto, sí que te da cierta ventaja, pero no lo es todo, así como la idea tampoco lo es todo. Lo que realmente importa, es quien la tira hacia adelante. Es decir, el procedimiento de hacer realidad la idea; una idea de por sí, no vale absolutamente nada. Somos muchas mentes pensando en este mundo, y no podemos creer que hemos sido los únicos en tener esa idea; hay millones de personas en el mundo y acaso vamos a pensar que la idea que hemos tenido nosotros, ¿nadie, en ningún país, en ningún sitio de este mundo, la ha pensado alguna vez? Seguramente ya la ha pensado alguien. De alguna otra manera, o mas parecida, o mas diferente, pero la habrá pensado. Así que, el hecho de que tu vayas contando tu idea a la gente, no implica nada. Es decir, tu idea ya la habrá tenido alguien antes; la gran diferencia está en quien la hace y no en quien la piensa. ¿De qué vale una idea si no la haces realidad? Absolutamente nada; la idea de por sí, no va a generar ingresos y no la va a descargar nadie. Es una idea, no es nada. ¿Acaso a nadie se le había ocurrido hacer un Facebook antes de que apareciera?, ¿A nadie se le había ocurrido hacer un buscador de internet como Google?, ¿a nadie se le había ocurrido hacer un Twitter? Segurísimo que sí. La gran diferencia está en que, la gente que creó esas empresas, en primer lugar, lo hizo; en segundo lugar, lo hizo bien. Así que, ni una idea, ni el hecho de ser el primero en hacer algo, te va a asegurar nada. Yo creo que tiene que quedar claro que, el hecho de contar tu idea a la gente, no va a poner en peligro tu proyecto. Ahora mismo, me podría poner a contar 20 ideas que tengo en mente, y no tendría ningún problema en dar todos los detalles porque si alguien lo hace… pues olé. Es muy raro que tu cuentes una idea y alguien diga: “Esto es muy genial, lo voy a hacer”. Lo normal es que la gente te dé su opinión y ya está, no te van a copiar nada. Puede darse el caso, pero es muy raro. <h3>¿Qué estás perdiendo al no contar tu idea?</h3> Una vez visto que, el no contar tu idea a alguien tampoco te va a asegurar muchas cosas, vamos que estás perdiendo al no contarle tu idea a la gente. Como he dicho más de una vez, la opinión de una persona no cuenta para nada, frente a la de otras 100. Que tu pienses que una idea va a funcionar, no quiere decir que el resto de personas lo piensen; es más, ¿cómo vas a saber si realmente va a funcionar, si no sabes la opinión de nadie, más que la tuya? Esto es lo que pierdes: saber lo que piensa la gente, que, seguramente es muchísimo más valioso que el hecho de que nadie sepa tu idea o el riesgo de que te puedan copiar. Ahora piensa otra cosa. Quizás tus conocidos o la gente a quienes les cuentas tu idea, no te vayan a copiar porque no tengan recursos, tiempo o lo que sea. Pero, imagina ahora, que vas a buscar financiación para tu proyecto, el cual es un paso bastante común y necesario. Seguramente, tendrás que ir a un foro de inversores o algo parecido, y contarles tu idea de arriba abajo con el fin de convencerlos, porque, el argumento de “es una idea que nadie tiene y voy a petarlo, pero no os puedo contar nada porque es secreto”, no va a convencer a nadie. Por tanto, tendrás que contar tu idea de arriba a abajo, a gente que tiene el dinero y te podría copiar sin necesitarte a ti. Pues bien, no te van a copiar; lo que van a buscar no es la idea en sí, sino el equipo y la forma de tirarla hacia adelante. Como digo, una idea no vale nada de por sí. Suponiendo que pudieras llevar a cabo tu idea sin contarle a absolutamente nadie, y la llevarás hasta el final, llegaría un momento que la sacarías al público. Imagina que no funciona, ¿Qué crees?, ¿Qué no te van a intentar copiar mil y una veces, y empresas y personas que seguramente tienen más recursos que tú? Es eso, la clave no está en la idea en sí, porque en el momento en que funcione, te van a copiar; la clave está en muchas cosas más allá de la propia idea, y no contar tu idea inicialmente, no te va a ayudar mucho. <h3>La cuestión con los copyrights, trademarks y patentes</h3> Otra cosa a tomar en cuenta, es que los recursos que tenemos para proteger una idea, no son como muchos podríamos pensar de inicio: copyright, trademarks y patentes. Todos ellos, no van a hacer que tu idea no sea desarrollada por otra persona. Es decir, no van a hacer que otra persona o empresa desarrolle esa misma idea de negocio. Por ejemplo, el copyright, protege recursos específicos: imágen, canción. El trademark por su parte, protege una marca, un nombre, un logo. Finalmente, las patentes protegen inventos. Las ideas no pueden ser patentadas. Además, es difícil, costoso y probablemente suponga un esfuerzo que la mayoría de veces no valga la pena. Si fuera tan fácil registrar una patente o una idea, habría mucha gente viviendo, únicamente de pensar ideas y registrarlas como patentes, y que venga alguien y pague; no funciona así. Se pueden patentar cosas, pero cosas muy específicas. Como digo, una idea de negocio no puede ser patentada. En general, no perdería mucho tiempo con el tema de las patentes. Al final, si tu idea funciona, vas a tener competencia. No pierdas tiempo en registrar algo que ni siquiera sabes si va a funcionar. Mejor dedícate a comprobar si realmente puede funcionar. Y, como digo, el primer paso es contarle tu idea a la máxima gente posible, lo que además permitiría que obtengas feedback que seguramente no habías pensado: “¿Qué tal si cambias esto o añades esto?, ¿yo añadiría esto?, ¿Qué pasa si sucede esto?”. En general, son cosas que inicialmente no has podido pensar y gracias a ese feedback de la gente dices: “Ah vale, pues ahora lo voy a hacer mejor” <h3>Cuéntale tu idea a personas que no conozcas tanto</h3> Otra cosa de la que tampoco me quería olvidar es que a veces, es hasta incluso mejor contarle tu idea a personas que no conoces (no me refiero a desconocidos, sino a gente que no sea de tu máxima confianza) porque, al fin y al cabo, una persona que es cercana a ti, o un familiar, quizás tenga la tentación de decirte que es una buena idea o que le parece bien, simplemente por el hecho de animarte o no desilusionarte. Mientras que, una persona que no conozcas tanto, podría ofrecerte una opinión más sincera; es algo que pienso que podría serte útil. <h3>¿Qué pasa cuando decides contratar a alguien?</h3> Volvamos ahora al principio del capítulo donde separaba los dos tipos de personas de quienes tendrías que protegerte o no. Ahora veamos, qué pasa cuando desarrollas tu idea, y decides contratar a alguien; este es el segundo grupo de personas que decía al principio. Ya sea una empresa o un freelance, da igual, ¿debes proteger tu idea de ellos? Aquí le puedo ver sentido por varios motivos: 1) ya estás poniendo dinero sobre la mesa, así como tiempo y esfuerzo; 2) estás desarrollando tu idea; ya no será una simple idea, sino que será el proceso de desarrollarla; y 3) hay mecanismos más sencillos para protegerte sin tener que recurrir a temas de patentes y demás. ¿A qué me refiero con protegerte? No quiero decir que encargues un proyecto, te lo hagan, pagues y luego se queden con el proyecto. Esto, sería directamente denunciable sin tener que proteger nada. Me refiero a que alguien que desarrolle tu proyecto, pueda ir dando información sobre él a otras personas o incluso, que pueda desarrollar un proyecto paralelo por el otro lado; todo esto, mientras te desarrollan tu propio proyecto. La verdad no es una cosa muy ética. Una persona que se encarga de desarrollar un proyecto, no tendría que hacerlo, por lo menos, alguien decente. Pero bueno, hay mecanismos sencillos para evitar este tipo de cosas. En primer lugar, la confianza, asegúrate al máximo de la gente que contratas para hacer tu idea. Busca información de la empresa o persona y que te transmita confianza, porque esto es lo más básico. En segundo lugar, están los NDA (Non-disclosure agreement) que básicamente es un documento estándar firmado por ambas partes donde la persona que se encarga del proyecto, se compromete a no transmitir información sobre él. Como digo, es algo estándar y hasta podrás encontrar plantillas de ejemplos en línea. Yo he firmado más de uno de estos documentos en proyectos en los que he trabajado y no he tenido ningún problema; es simple, fácil, y el propietario se queda más tranquilo de que su proyecto, no sale más allá del ámbito del desarrollo. Por último, tenemos los NCA (Non-competence agreement). Estos, son acuerdos de no competencia, en donde básicamente, la persona encargada del proyecto, se compromete a no participar en proyectos que se consideren competencia del mismo, durante X tiempo. Esto, no es tan común y personalmente, no he firmado ninguno, pero están ahí. Una vez que hayas firmado estos contratos, lo que hay que tener en cuenta, es que hay que compartir el máximo de información posible con la persona o empresa que se encarga de desarrollar tu proyecto. La comunicación entre desarrollador y propietario es vital para el proyecto. De hecho, hasta el propio encargado de desarrollar el proyecto, te podría aportar de sus ideas para incorporarlas como sugerencia. The post <a href="https://diegolaballos.com/podcast/20-tengo-una-idea-para-una-app-debo-protegerla/" rel="nofollow" target="_blank">20. ¡Tengo una idea para una app! ¿Debo protegerla?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

20. ¡Tengo una idea para una app! ¿Debo protegerla?

Lean Startup es un método de desarrollo de productos que se enfoca sobre todo a iniciar un proyecto con lo mínimo posible; establece una metodología para ir creciendo y adaptándose a los cambios. Sé que esta definición puede no tener sentido ahora; al fin y al cabo, las definiciones formales nunca tienen mucho sentido al inicio, pero, tranquilidad porque ahora vamos a ir entrando a fondo en el concepto. Es una metodología que, como veremos, está pensada para negocios donde existe mucha incertidumbre. Es decir, productos nuevos que no se sabe si pueden funcionar o no. Por ejemplo, para abrir un negocio de toda la vida como una panadería, puede no tener mucho sentido. Sin embargo, para una app nueva puede tener todo el sentido del mundo, ya que, no se sabe exactamente si eso puede funcionar o no. Esta metodología, tiene un libro base del autor Eric Ries, llamado precisamente lean start-up; se lo recomendaría a cualquier persona que tiene en mente desarrollar algún proyecto como una app. ¿En qué consiste la metodología lean start-up? Después de esta breve introducción al método, vamos a ver a fondo de qué trata. Seguramente, no podré cubrir exactamente todo lo que explica esta teoría porque el libro habla de bastantes cosas y conceptos, pero, creo que va a quedar una idea bastante clara, así que, vamos por puntos. El primer concepto es el de “mvp” (esto no hace referencia al mejor jugador valorado de un partido de la NBA) que quiere decir “mínimum viable product” -mínimo producto viable-. Vamos a verlo con un ejemplo: imaginemos que hemos tenido una nueva idea y queremos hacer una app para poner en contacto gente que tiene perros, con gente que quiere ganar un dinero extra, paseándolos. Vamos a suponer que sabemos que hay mucha gente con perro, pero que no tiene tiempo para sacarlo a pasear (al menos todo lo que debería); y, que hay gente que querría ganarse un dinero extra, paseando estos perros. Normalmente, cuando pensamos en una nueva idea de negocio (producto, app, servicio, etc.) lo normal, es que pase lo siguiente: Vamos a sacar una app para Android y iOS porque son los sistemas principales. Vamos a hacer que el usuario, se registre con el mail o redes sociales. Vamos a dejar que creen el perfil y suban su foto, editen su nombre, etc. También, tendrán que elegir si quieren que paseen a su perro, o si quieren pasear perros. De paso, debemos permitir que las personas puedan hacer ambas cosas. También, debemos dejar que añadan un perfil para el perro. Vamos a hacer que en un principio puedan buscar cuidadores a su alrededor que, en principio, podría ser a través de una lista; pero, posteriormente, sería recomendable hacerlo en un mapa de Google Maps. Por supuesto, vamos a permitir que puedan pagar al cuidador a través de la aplicación, sea con PayPal, tarjeta o incluso bitcoin. Los cuidadores acumularan saldo y, al final del mes, se los depositaremos. Por tanto, tendremos que añadir más opciones en el perfil del cuidador, para que pueda ver sus ingresos en un gráfico para que sea vea bonito. Es importante que tenga un chat para que la gente se pueda poner en contacto. Incluso, sería importante que se puedan mandar fotos en el chat por si el cuidador quiere ver al perro. Esto, sirve como ejemplo para ver por donde voy. Normalmente, cuando queremos sacar un nuevo producto, queremos que sea perfecto, que no falte nada, y que roce la excelencia. Pues bien, el concepto de MVP dice todo lo contrario. ¿Qué dice MVP? Lo que dice es: “Saca el mínimo producto que puedas”. Un producto que tenga solo tu idea básica. ¿Por qué? El objetivo es comprobar si existe mercado para lo que tú estás haciendo, de la manera más rápida y minimizando los gastos (dinero, tiempo y esfuerzo). No hace falta que tu idea incluya mil funcionalidades para comprobar si es viable o no, o si la gente se interesa en ella. Siguiendo esto, entonces ¿Cuál sería un MVP para el ejemplo que he dicho antes? Quizás una app en Android, por ahora (no hace falta que la saquemos en iOS aún); que tenga registro por mail y redes sociales; que te permite elegir si quieres pasear perros o quieres que te los cuiden; añadir a los cuidadores en una lista; y, ponerse en contacto con ellos. Ya está. Esto, puede perfectamente representar una base de nuestra idea para poder validar si tiene mercado. No nos haría falta que el pago fuera a través de la app. Aunque bueno, esto ya sería otra discusión sobre si el pago debería ir desde un inicio o no (en marketing, hay un principio básico: es fácil bajar precios; pero es difícil subirlos. Más aún que algo que solía ser gratis, ahora sea de pago). Nivel de gastos entre MVP o una aplicación con todas las funcionalidades Evidentemente MVP es más fácil y lo que es más importante, nos permitirá ver si hay un interés real por nuestra idea sin tener que gastar tantos recursos; si tenemos que equivocarnos, que sea gastando un mes de esfuerzo + 1000 euros, que 10 meses + 10,000 euros. Si nuestra app, no se la descarga nadie, que más da que lo tenga todo. Si es un MVP, y la gente se interesa en ella, sabremos que tiene mercado y tendremos tiempo de mejorarla. Lo que pasa, es que podemos tener la tentación y decir: “Oh, pero si no incluyo todas estas funcionalidades, a la gente no le va a gustar tanto”. En este caso, la respuesta es un sí y no. Si la gente la descarga y la usa, puedes ir a tope con la idea. Es más, ya tienes la prueba y puede valerte de mucho para que busques inversión, por ejemplo. Si quieres convencer a alguien para que invierta en tu idea, ¿Qué es mejor? ¿Suponer cosas o datos reales? Por otro lado, si a la gente le interesa tu idea, no la va a dejar de usar porque no tiene una funcionalidad. Ninguna aplicación hoy en día, vino con todas las funcionalidades desde el primer día. Otra cosa a tener en cuenta es que, el hecho de que tú creas que una función de tu aplicación es una nota más, no quiere decir que el resto de la gente lo piense. Lo que tu pienses o yo piense, no tiene porque ser lo mismo que los demás piensan. Además, el hecho de tener demasiadas funcionalidades puede ser hasta perjudicial ¿Cuántas veces han descargado un software y lo terminan desinstalando por no saber utilizarlo? Da mucha pereza tener que aprenderlo todo de golpe. Por tanto, cuanto más simple mejor. Debes validar cada paso que das El segundo pilar de la teoría lean start-up es validar cada paso que das. Una vez que tienes tu MVP y has comprobado que hay gente interesada, lo que tienes que hacer, es estar seguro que cada funcionalidad que hagas, será de interés a la gente. La clave aquí, es hacer lo que la gente quiere; y no hacer lo que tú piensas que la gente quiere. Por ejemplo, puedes pensar que añadir un mapa con los cuidadores, en vez de una lista, puede ser una buena idea. Sin embargo, los usuarios no tienen por qué pensar lo mismo y, quizás, hasta les molesta. Esto no es fácil de hacer. Cuando tienes miles de usuario de todas las partes del mundo, no puedes meter a todos en una sala y pedirles que voten, así que, lo que propone la metodología del lean start-up, es añadir cosas provisionalmente y validar que la gente las quiere, antes de confirmar que las vas a dejar. En el caso de que no las quieran, las eliminas. Pero, ¿Cómo lo hacemos? En primer lugar, no añadir mil cosas a la vez. Tenemos que ir añadiendo cosas poco a poco (1 en 1, 2 en 2, 3 en 3, etc.). Antes de añadir las siguientes funcionalidades que se nos ocurran, tenemos que ver si la gente las quiere o no, y en función de eso, confirmar si se quedan o no. Uso de analytics ¿Cómo sabemos si han gustado? Pues por medio de analytics. Hay muchas maneras de recoger datos de tu aplicación y saber qué hacen tus usuarios. De hecho, todos los que tengan una aplicación, deberían tener esto implementado: Google Analytics, Mix Panel, Firebase Analytics, etc. Lo que dice lean start-up, es que debemos establecer analytics accionables, lo que es otro concepto importante. Volvamos a la función del mapa que decíamos antes. Imaginemos que decidimos añadir dos funciones para listar a los cuidadores de perros: mapa y listas. Lo que hacemos, es implementarlo y añadirlo en la aplicación. Una vez que se haya puesto esta nueva funcionalidad, tenemos que decidir si esto ha gustado o no, a los nuevos usuarios, con lo cual, tendremos que mirar los analytics de nuestra aplicación. Una posible métrica, sería decir: “Si la gente sigue usando la app, o al menos se incrementa su uso puedo decir que funciona; mientras no vaya mal, puedo darle por bueno”. Por lo tanto, me fijaría en las métricas de cuanta gente entra al día; o de cuánto tiempo están utilizando la aplicación. Esto, lo compararía con la versión anterior que no tenía el mapa. Esto, no sería una métrica accionable. La métrica accionable consiste en encontrar un dato que te diga de forma precisa, lo que está pasando con esta funcionalidad. Lo que he dicho ahora, se puede deber a muchas otras cosas. Por ejemplo, una métrica accionable para esta funcionalidad sería, el porcentaje de gente que busca por mapa, y el porcentaje de gente que busca con la lista. Si hay más de un 30% que usa el mapa, podría darlo por bueno y voy a mantener esta funcionalidad. Si hay menos del 30% voy a considerar que no es tan importante y puede molestar más que ayudar. Incluso podríamos ir más allá. Veo cuanta gente usa el mapa, y al final, contacto a alguien para preguntar y así poder medir la efectividad que tiene el mapa. Es decir, voy a medir la efectividad de usar el mapa, y lo voy a comparar con la lista. Quizás, no mucha gente utiliza el mapa, pero quienes lo hacen contactan más fácilmente con cuidadores. De esta manera, esta idea de validación, implica que estás construyendo esta aplicación con base en el feedback directo de tus usuarios, y no en tus opiniones. Una vez hecho esto, se repite el ciclo: construir, medir, aprender. En otras palabras: desarrollo una funcionalidad; mido si hay interés; y, la descarto o la mantengo. Como dice el refrán, haciendo y deshaciendo, se va aprendiendo. Es un bucle sin fin. Hay muchas empresas que han empezado con un MVP. Ha habido casos en los que solamente han salido en una plataforma. El ejemplo mas claro, yo diría que es Instagram, el cual, estuvo muchísimo tiempo disponible solo en iOS. Tenía millones de usuarios ya, antes de salir en Android. Evidentemente, obtuvo muchos más usuarios en Android. Otro ejemplo claro, es Airbnb. Al inicio, era una web muy simple hecha en WordPress; no tenía muchas de las funcionalidades que tiene ahora. The post 19. ¿Qué es Lean Startup? appeared first on Diego Laballós.

Lean Startup es un método de desarrollo de productos que se enfoca sobre todo a iniciar un proyecto con lo mínimo posible; establece una metodología para ir creciendo y adaptándose a los cambios. Sé que esta definición puede no tener sentido ahora; al fin y al cabo, las definiciones formales nunca tienen mucho sentido al inicio, pero, tranquilidad porque ahora vamos a ir entrando a fondo en el concepto. Es una metodología que, como veremos, está pensada para negocios donde existe mucha incertidumbre. Es decir, productos nuevos que no se sabe si pueden funcionar o no. Por ejemplo, para abrir un negocio de toda la vida como una panadería, puede no tener mucho sentido. Sin embargo, para una app nueva puede tener todo el sentido del mundo, ya que, no se sabe exactamente si eso puede funcionar o no. Esta metodología, tiene un libro base del autor Eric Ries, llamado precisamente lean start-up; se lo recomendaría a cualquier persona que tiene en mente desarrollar algún proyecto como una app. <h3>¿En qué consiste la metodología lean start-up?</h3> Después de esta breve introducción al método, vamos a ver a fondo de qué trata. Seguramente, no podré cubrir exactamente todo lo que explica esta teoría porque el libro habla de bastantes cosas y conceptos, pero, creo que va a quedar una idea bastante clara, así que, vamos por puntos. El primer concepto es el de “mvp” (esto no hace referencia al mejor jugador valorado de un partido de la NBA) que quiere decir “mínimum viable product” -mínimo producto viable-. Vamos a verlo con un ejemplo: imaginemos que hemos tenido una nueva idea y queremos hacer una app para poner en contacto gente que tiene perros, con gente que quiere ganar un dinero extra, paseándolos. Vamos a suponer que sabemos que hay mucha gente con perro, pero que no tiene tiempo para sacarlo a pasear (al menos todo lo que debería); y, que hay gente que querría ganarse un dinero extra, paseando estos perros. Normalmente, cuando pensamos en una nueva idea de negocio (producto, app, servicio, etc.) lo normal, es que pase lo siguiente: Vamos a sacar una app para Android y iOS porque son los sistemas principales. Vamos a hacer que el usuario, se registre con el mail o redes sociales. Vamos a dejar que creen el perfil y suban su foto, editen su nombre, etc. También, tendrán que elegir si quieren que paseen a su perro, o si quieren pasear perros. De paso, debemos permitir que las personas puedan hacer ambas cosas. También, debemos dejar que añadan un perfil para el perro. Vamos a hacer que en un principio puedan buscar cuidadores a su alrededor que, en principio, podría ser a través de una lista; pero, posteriormente, sería recomendable hacerlo en un mapa de Google Maps. Por supuesto, vamos a permitir que puedan pagar al cuidador a través de la aplicación, sea con PayPal, tarjeta o incluso bitcoin. Los cuidadores acumularan saldo y, al final del mes, se los depositaremos. Por tanto, tendremos que añadir más opciones en el perfil del cuidador, para que pueda ver sus ingresos en un gráfico para que sea vea bonito. Es importante que tenga un chat para que la gente se pueda poner en contacto. Incluso, sería importante que se puedan mandar fotos en el chat por si el cuidador quiere ver al perro. Esto, sirve como ejemplo para ver por donde voy. Normalmente, cuando queremos sacar un nuevo producto, queremos que sea perfecto, que no falte nada, y que roce la excelencia. Pues bien, el concepto de MVP dice todo lo contrario. <h3>¿Qué dice MVP?</h3> Lo que dice es: “Saca el mínimo producto que puedas”. Un producto que tenga solo tu idea básica. ¿Por qué? El objetivo es comprobar si existe mercado para lo que tú estás haciendo, de la manera más rápida y minimizando los gastos (dinero, tiempo y esfuerzo). No hace falta que tu idea incluya mil funcionalidades para comprobar si es viable o no, o si la gente se interesa en ella. Siguiendo esto, entonces ¿Cuál sería un MVP para el ejemplo que he dicho antes? Quizás una app en Android, por ahora (no hace falta que la saquemos en iOS aún); que tenga registro por mail y redes sociales; que te permite elegir si quieres pasear perros o quieres que te los cuiden; añadir a los cuidadores en una lista; y, ponerse en contacto con ellos. Ya está. Esto, puede perfectamente representar una base de nuestra idea para poder validar si tiene mercado. No nos haría falta que el pago fuera a través de la app. Aunque bueno, esto ya sería otra discusión sobre si el pago debería ir desde un inicio o no (en marketing, hay un principio básico: es fácil bajar precios; pero es difícil subirlos. Más aún que algo que solía ser gratis, ahora sea de pago). <h3>Nivel de gastos entre MVP o una aplicación con todas las funcionalidades</h3> Evidentemente MVP es más fácil y lo que es más importante, nos permitirá ver si hay un interés real por nuestra idea sin tener que gastar tantos recursos; si tenemos que equivocarnos, que sea gastando un mes de esfuerzo + 1000 euros, que 10 meses + 10,000 euros. Si nuestra app, no se la descarga nadie, que más da que lo tenga todo. Si es un MVP, y la gente se interesa en ella, sabremos que tiene mercado y tendremos tiempo de mejorarla. Lo que pasa, es que podemos tener la tentación y decir: “Oh, pero si no incluyo todas estas funcionalidades, a la gente no le va a gustar tanto”. En este caso, la respuesta es un sí y no. Si la gente la descarga y la usa, puedes ir a tope con la idea. Es más, ya tienes la prueba y puede valerte de mucho para que busques inversión, por ejemplo. Si quieres convencer a alguien para que invierta en tu idea, ¿Qué es mejor? ¿Suponer cosas o datos reales? Por otro lado, si a la gente le interesa tu idea, no la va a dejar de usar porque no tiene una funcionalidad. Ninguna aplicación hoy en día, vino con todas las funcionalidades desde el primer día. Otra cosa a tener en cuenta es que, el hecho de que tú creas que una función de tu aplicación es una nota más, no quiere decir que el resto de la gente lo piense. Lo que tu pienses o yo piense, no tiene porque ser lo mismo que los demás piensan. Además, el hecho de tener demasiadas funcionalidades puede ser hasta perjudicial ¿Cuántas veces han descargado un software y lo terminan desinstalando por no saber utilizarlo? Da mucha pereza tener que aprenderlo todo de golpe. Por tanto, cuanto más simple mejor. <h3>Debes validar cada paso que das</h3> El segundo pilar de la teoría lean start-up es validar cada paso que das. Una vez que tienes tu MVP y has comprobado que hay gente interesada, lo que tienes que hacer, es estar seguro que cada funcionalidad que hagas, será de interés a la gente. La clave aquí, es hacer lo que la gente quiere; y no hacer lo que tú piensas que la gente quiere. Por ejemplo, puedes pensar que añadir un mapa con los cuidadores, en vez de una lista, puede ser una buena idea. Sin embargo, los usuarios no tienen por qué pensar lo mismo y, quizás, hasta les molesta. Esto no es fácil de hacer. Cuando tienes miles de usuario de todas las partes del mundo, no puedes meter a todos en una sala y pedirles que voten, así que, lo que propone la metodología del lean start-up, es añadir cosas provisionalmente y validar que la gente las quiere, antes de confirmar que las vas a dejar. En el caso de que no las quieran, las eliminas. Pero, ¿Cómo lo hacemos? En primer lugar, no añadir mil cosas a la vez. Tenemos que ir añadiendo cosas poco a poco (1 en 1, 2 en 2, 3 en 3, etc.). Antes de añadir las siguientes funcionalidades que se nos ocurran, tenemos que ver si la gente las quiere o no, y en función de eso, confirmar si se quedan o no. <h3>Uso de analytics</h3> ¿Cómo sabemos si han gustado? Pues por medio de analytics. Hay muchas maneras de recoger datos de tu aplicación y saber qué hacen tus usuarios. De hecho, todos los que tengan una aplicación, deberían tener esto implementado: Google Analytics, Mix Panel, Firebase Analytics, etc. Lo que dice lean start-up, es que debemos establecer analytics accionables, lo que es otro concepto importante. Volvamos a la función del mapa que decíamos antes. Imaginemos que decidimos añadir dos funciones para listar a los cuidadores de perros: mapa y listas. Lo que hacemos, es implementarlo y añadirlo en la aplicación. Una vez que se haya puesto esta nueva funcionalidad, tenemos que decidir si esto ha gustado o no, a los nuevos usuarios, con lo cual, tendremos que mirar los analytics de nuestra aplicación. Una posible métrica, sería decir: “Si la gente sigue usando la app, o al menos se incrementa su uso puedo decir que funciona; mientras no vaya mal, puedo darle por bueno”. Por lo tanto, me fijaría en las métricas de cuanta gente entra al día; o de cuánto tiempo están utilizando la aplicación. Esto, lo compararía con la versión anterior que no tenía el mapa. Esto, no sería una métrica accionable. La métrica accionable consiste en encontrar un dato que te diga de forma precisa, lo que está pasando con esta funcionalidad. Lo que he dicho ahora, se puede deber a muchas otras cosas. Por ejemplo, una métrica accionable para esta funcionalidad sería, el porcentaje de gente que busca por mapa, y el porcentaje de gente que busca con la lista. Si hay más de un 30% que usa el mapa, podría darlo por bueno y voy a mantener esta funcionalidad. Si hay menos del 30% voy a considerar que no es tan importante y puede molestar más que ayudar. Incluso podríamos ir más allá. Veo cuanta gente usa el mapa, y al final, contacto a alguien para preguntar y así poder medir la efectividad que tiene el mapa. Es decir, voy a medir la efectividad de usar el mapa, y lo voy a comparar con la lista. Quizás, no mucha gente utiliza el mapa, pero quienes lo hacen contactan más fácilmente con cuidadores. De esta manera, esta idea de validación, implica que estás construyendo esta aplicación con base en el feedback directo de tus usuarios, y no en tus opiniones. Una vez hecho esto, se repite el ciclo: construir, medir, aprender. En otras palabras: desarrollo una funcionalidad; mido si hay interés; y, la descarto o la mantengo. Como dice el refrán, haciendo y deshaciendo, se va aprendiendo. Es un bucle sin fin. Hay muchas empresas que han empezado con un MVP. Ha habido casos en los que solamente han salido en una plataforma. El ejemplo mas claro, yo diría que es Instagram, el cual, estuvo muchísimo tiempo disponible solo en iOS. Tenía millones de usuarios ya, antes de salir en Android. Evidentemente, obtuvo muchos más usuarios en Android. Otro ejemplo claro, es Airbnb. Al inicio, era una web muy simple hecha en WordPress; no tenía muchas de las funcionalidades que tiene ahora. The post <a href="https://diegolaballos.com/podcast/19-que-es-lean-startup/" rel="nofollow" target="_blank">19. ¿Qué es Lean Startup?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

19. ¿Qué es Lean Startup?

Lo primero que hay que decir, es que el desarrollo de aplicaciones móviles es una tecnología complicada y cara, si la comparamos con otras tecnologías, como la web. Esto es, básicamente por varios motivos.  En primer lugar, la tecnología es relativamente nueva y las aplicaciones existen desde hace 5-7 años y esto, obviamente, hace que haya menos conocimiento, herramientas y gente que se dedique a ello. También, la fragmentación de sistemas que existe hoy en día, no ayuda a que sea fácil programarlas sin ningún tipo de error. Tenemos muchos fabricantes, muchos sistemas (y varias versiones). Además, no hay frameworks o, en otras palabras, herramientas que nos faciliten las cosas como sí sucede en la web con los CMS como WordPress o Joomla, que facilitan mucho el desarrollo de una web. En general, la tecnología es compleja. Implica lidiar con bases de datos locales, interacciones con un servidor, acceso al hardware del móvil (cámara, GPS, etc.). También está el hecho de tener recursos limitados en el dispositivo como la batería, conexiones lentas / limitadas, procesadores no tan potentes como en los ordenadores; pantallas de todo tipo, etc. En fin, es algo bastante complejo. Formas de obtener algún producto o servicio Dicho esto, todos sabemos que para contratar cualquier servicio o comprar cualquier producto, existen dos formas de hacerlo. Una es premiando principalmente el precio, lo que serían los servicios low-cost. Generalmente, significa sacrificar calidad por precio. Es decir, vas a comprar algo barato, pero tampoco esperas que tenga una calidad extrema. Por otro lado, puedes comprar premiando la calidad y entonces, te vas encontrar servicios o productos en teoría top, de calidad alta, sacrificando obviamente el precio. Estás dispuesto a pagar por algo de más calidad. Obviamente, esto es una generalización. Siempre puede ser lo contrario, pero creo que la gran mayoría de gente estará de acuerdo conmigo en que es así. Puedes pagar un producto caro y que te salgo malo o puedes pagar por algo barato y que sea muy bueno. Pero bueno, en general, el precio va en concordancia con la calidad. Por ejemplo, si me compro un móvil de 900 euros (un iPhone o un Google Pixel) espero que vayan rápido, que funcionen sin problemas y que me dure mucho tiempo en caso de que no lo quiera cambiar.  Por otro lado, si me compro un móvil de 50 euros, pues espero que simplemente funcione; tampoco puedo esperar mucho de él y solo espero que me aguante un año hasta que ya sea un sacrificio seguir utilizándolo. Con las aplicaciones pasa lo mismo Al igual que con todo, con las aplicaciones pasa lo mismo. Podemos contratar un desarrollo low-cost o freelancers de bajo coste desde páginas de freelance como Freelancer o Upwork.  Por otro lado, podemos contratar desarrolladores o empresas de referencia que entienden, que tienen un perfil y que han trabajado en proyectos grandes. O, ¿Por qué no? Desde webs de freelancers pero gente con buenas opiniones, con mucho porcentaje de éxito, etc. Básicamente, son estas las dos opciones que tenemos. Aquí, la verdad es que salen muchos capítulos para un podcast. Sin duda, me apuntaré a mi lista de capítulos pendientes cosas como ¿Qué diferencia un desarrollador low-cost de uno profesional? o ¿Cómo elegir un desarrollador? Quedan apuntados. Sin embargo, hoy lo que quería tratar es algo diferente. Quería ponerme de lado de una persona que quiere crear una app, no tiene un conocimiento técnico y, que por los motivos que sean, tiene un presupuesto bajo para llevarla a cabo. Obviamente, lo que quiere, es crear una app lo mejor posible, pero con el mínimo precio. En otras palabras, quiere encontrar la mejor relación calidad-precio. Pero, sobre todo, mirando al precio. Hay que decir que, lo que la gente hace cuando quiere algún trabajo de software barato, es ir a páginas de freelancer y contratar al desarrollador más barato. La gran mayoría de veces se hace esto, aunque, lo siento mucho, es un fracaso asegurado. Te puede salir bien la jugada, sí, y yo mañana podría ganar el Euromillones. La diferencia es que yo, pobre de mí, solo tengo una ligera esperanza de que me toque. Sin embargo, si lo que quiero es crear una app o software, estoy seguro que lo que tienes no es una ligera esperanza; lo que tu quieres es que te hagan el proyecto lo mejor posible y que salga bien.  Así que, vamos a ver algunos consejos para reducir la posibilidad de fracaso cuando reduces el coste de un proyecto. 1.No vayas por lo más barato El primero es el más obvio de todos: no ir hacia lo más barato. Entiendo que quieras crear una app de bajo presupuesto pero seamos realistas, ¿a qué no se te pasa por la cabeza comprarte un coche nuevo por 100 euros?  El problema quizás, es que no harías lo del coche porque sabes lo que cuesta mas o menos un coche nuevo. Mucha gente no sabe lo que cuesta una app aproximadamente y quizás este es el gran problema (aquí un capítulo más para hacer en el futuro: ¿Cuánto cuesta una app?). En mi opinión, una buena técnica, sería la siguiente. En primer lugar, pregunta por presupuestos aproximados de tu aplicación, a empresas de tu alrededor, aquellas que consideres buenas pero que no puedes acceder a ellas por un tema de presupuesto. De todas maneras, no pierdes nada por preguntar cuánto costaría aproximadamente el desarrollar esa aplicación con ellos. Después, haz lo mismo, pero con freelancers que consideres de referencia y que podrían desarrollar correctamente tu aplicación, y que por temas de presupuesto tampoco llegarías a ellos.  El tercer paso, es que, con estos presupuestos, te vayas a buscar programadores en páginas web de freelancers, como he dicho antes, que entren dentro de tus expectativas. Ahora bien, vamos a decir que el presupuesto que te han dado las empresas se sitúa alrededor de los 10.000 euros; y el de los freelancers de “referencia” se sitúa en los 7.000 euros. Ahora, sabiendo estos presupuestos, no pretendas que te hagan la app por 200 euros. Sí, hay diferencias entre países y hay algunos que son más económicos, pero cuidado, estamos en un mundo globalizado y el mundo de la programación, sobre todo el trabajo remoto, está a la orden del día. Quiero decir que una persona que es buena programando y son de países como India o China (que tienen fama de trabajar barato) no va a trabajar por 5 euros la hora; esto es así. Si eliges un presupuesto de 200 euros cuando tenías una media de 8.000 euros, no te puedes echar las manos a la cabeza cuando pase lo inevitable: que el proyecto salga mal por cualquier cosa.  Así que, mi primer consejo es que no vayas por lo más barato, porque al final, lo barato sale caro. Busca un precio económico, pero tampoco te pases. Ahora que tienes presupuestos aproximados de lo que te costaría. Si tu aplicación está presupuestada en 8.000 euros, quizás podrías encontrar un precio económico entre 4.000-5.000 euros, o 3.000 si me apuras. Pero si empiezas a bajar de ahí, te estás asegurando el fracaso. Una persona que sabe lo que hace en programación, por normal general, no va a trabajar gratis. 2.Busca un experto que esté al mando del proyecto Este segundo punto trata de tener a alguien que guíe el proyecto. Es decir, una persona o freelance de referencia al cual no puedes acceder a temas de presupuesto pero que sí podrías encontrarlo por muchísimas menos horas para que lleve el proyecto y diga por dónde ir y qué hacer. Pero en este caso, la gran parte del trabajo, lo desarrollaría un freelance que tenga una tarifa más baja y acorde con tu presupuesto.  De esta manera, estarías pagando las horas justas para enderezar el proyecto de ese freelance “experto”. Sin embargo, esto es difícil de conseguir; es difícil convencer a un programador experto a que haga esto, porque generalmente, a los programadores, lo que les gusta, es programar. Además, suelen trabajar en proyectos grandes y no pequeños. Es decir, un freelance, suele premiar más un proyecto grande donde hay muchas horas de trabajo, a uno pequeñito y que implique pocas horas. Prefiere concentrar sus esfuerzos en proyectos grandes, así que es un poco difícil convencer a una persona experta a que haga esto, pero no pierdes nada al escribir unos cuantos mails. 3.Buscar un experto que te de pautas iniciales y finales En este caso, si no te funciona la anterior, puedes buscar un experto que te de pautas iniciales y finales. Es decir, dedicar muy pocas horas, unas 3-4 horas, para que te de una serie de guías iniciales y finales. Por ejemplo, inicialmente, te podría decir cómo tendría que estar estructurado el proyecto, qué tecnología utilizar, etc. Unas guías que permitan al programador menos experimentados seguirlas.  La verdad es que esto puede ser bastante útil tanto para la persona que encarga la aplicación, como para el propio programador menos experimentado porque le va a ser más fácil realizar el proyecto. De la misma manera, también te podrían realizar el proyecto al final, más que nada para que sepas lo que tienes entre manos: una aplicación mal o bien programada. En el caso de que esté mal programada, actuaría en consecuencia. 4.Miéntele al programador amateur Por último, si ni la segunda ni tercera opción te han funcionado, puedes intentar una cosa mucho más sencilla y simple. Es una pequeña mentira, pero puede ser muy útil. Básicamente consiste en decirle al programador de la app (el menos experimentado) que el código va a estar bajo revisión por otro profesional experto, sin que realmente sea así. Esto obliga a un programador a esforzarse. Muchas veces si tú como programador, sabes que tu código no lo vas a ver más que tú mismo, puedes tener la tendencia a relajarte (aunque no deberías) y crear código de menos calidad. Si crees que tu código va a ser revisado, te vas a esforzar más. De esta manera, quizás consigas que el programador dé lo mejor de sí, y se esfuerce al máximo. Estos son los 4 consejos que se me ocurren para obtener la máxima calidad-precio de un desarrollo low-cost. Obviamente, si quieres tener algo de calidad, si quieres tener una buena comunicación con el desarrollador; en definitiva, si quieres desarrollar un proyecto sin miedo de lo que pueda pasar, de si va a salir o no; no elijas un desarrollo low-cost porque lo barato sale caro. Y créeme, en el ámbito de la programación, esto se acentúa mucho más. Un proyecto, por pequeño que sea, si de base, está mal programado, va a traer muchos problemas a la larga. Seguramente, si sigue creciendo, va a tener que ser empezado totalmente desde cero porque eso ya lo he visto más de una vez. De hecho, hace ya bastante tiempo algunos de los proyectos personales que hacía para mí mismo, acabaron así: al cabo de un tiempo tenía que re-hacerlos. La parte buena, es que así se aprende en programación; aunque claro, esto es bueno en cierta manera para el programador, pero no para el cliente. Entonces, si te pasa esto, comete el error tú mismo en proyectos tuyos y que no se lo coma un cliente. Al fin y al cabo, la programación es construir un software, diseñar programas.  Al igual que un arquitecto que diseña una casa, si ésta se construye con un mal diseño puedes ir arreglando grietas o tapando fallos. Pero, si está mal construida, no se te va a ocurrir construir 5 plantas más porque seguramente acabará en desastre (si no se cae antes el edificio). Tal vez no sea la comparación más exacta ya que el software tiene que ser más escalable que un edificio. No creo que estos se construyen pensando en añadirle 5 plantas más, pero creo que se entienda.  The post 25. Crear apps baratas sin perder calidad appeared first on Diego Laballós.

Lo primero que hay que decir, es que el desarrollo de aplicaciones móviles es una tecnología complicada y cara, si la comparamos con otras tecnologías, como la web. Esto es, básicamente por varios motivos. En primer lugar, la tecnología es relativamente nueva y las aplicaciones existen desde hace 5-7 años y esto, obviamente, hace que haya menos conocimiento, herramientas y gente que se dedique a ello. También, la fragmentación de sistemas que existe hoy en día, no ayuda a que sea fácil programarlas sin ningún tipo de error. Tenemos muchos fabricantes, muchos sistemas (y varias versiones). Además, no hay frameworks o, en otras palabras, herramientas que nos faciliten las cosas como sí sucede en la web con los CMS como WordPress o Joomla, que facilitan mucho el desarrollo de una web. En general, la tecnología es compleja. Implica lidiar con bases de datos locales, interacciones con un servidor, acceso al hardware del móvil (cámara, GPS, etc.). También está el hecho de tener recursos limitados en el dispositivo como la batería, conexiones lentas / limitadas, procesadores no tan potentes como en los ordenadores; pantallas de todo tipo, etc. En fin, es algo bastante complejo. <h3>Formas de obtener algún producto o servicio</h3> Dicho esto, todos sabemos que para contratar cualquier servicio o comprar cualquier producto, existen dos formas de hacerlo. Una es premiando principalmente el precio, lo que serían los servicios low-cost. Generalmente, significa sacrificar calidad por precio. Es decir, vas a comprar algo barato, pero tampoco esperas que tenga una calidad extrema. Por otro lado, puedes comprar premiando la calidad y entonces, te vas encontrar servicios o productos en teoría top, de calidad alta, sacrificando obviamente el precio. Estás dispuesto a pagar por algo de más calidad. Obviamente, esto es una generalización. Siempre puede ser lo contrario, pero creo que la gran mayoría de gente estará de acuerdo conmigo en que es así. Puedes pagar un producto caro y que te salgo malo o puedes pagar por algo barato y que sea muy bueno. Pero bueno, en general, el precio va en concordancia con la calidad. Por ejemplo, si me compro un móvil de 900 euros (un iPhone o un Google Pixel) espero que vayan rápido, que funcionen sin problemas y que me dure mucho tiempo en caso de que no lo quiera cambiar. Por otro lado, si me compro un móvil de 50 euros, pues espero que simplemente funcione; tampoco puedo esperar mucho de él y solo espero que me aguante un año hasta que ya sea un sacrificio seguir utilizándolo. <h3>Con las aplicaciones pasa lo mismo</h3> Al igual que con todo, con las aplicaciones pasa lo mismo. Podemos contratar un desarrollo low-cost o freelancers de bajo coste desde páginas de freelance como Freelancer o Upwork. Por otro lado, podemos contratar desarrolladores o empresas de referencia que entienden, que tienen un perfil y que han trabajado en proyectos grandes. O, ¿Por qué no? Desde webs de freelancers pero gente con buenas opiniones, con mucho porcentaje de éxito, etc. Básicamente, son estas las dos opciones que tenemos. Aquí, la verdad es que salen muchos capítulos para un podcast. Sin duda, me apuntaré a mi lista de capítulos pendientes cosas como ¿Qué diferencia un desarrollador low-cost de uno profesional? o ¿Cómo elegir un desarrollador? Quedan apuntados. Sin embargo, hoy lo que quería tratar es algo diferente. Quería ponerme de lado de una persona que quiere crear una app, no tiene un conocimiento técnico y, que por los motivos que sean, tiene un presupuesto bajo para llevarla a cabo. Obviamente, lo que quiere, es crear una app lo mejor posible, pero con el mínimo precio. En otras palabras, quiere encontrar la mejor relación calidad-precio. Pero, sobre todo, mirando al precio. Hay que decir que, lo que la gente hace cuando quiere algún trabajo de software barato, es ir a páginas de freelancer y contratar al desarrollador más barato. La gran mayoría de veces se hace esto, aunque, lo siento mucho, es un fracaso asegurado. Te puede salir bien la jugada, sí, y yo mañana podría ganar el Euromillones. La diferencia es que yo, pobre de mí, solo tengo una ligera esperanza de que me toque. Sin embargo, si lo que quiero es crear una app o software, estoy seguro que lo que tienes no es una ligera esperanza; lo que tu quieres es que te hagan el proyecto lo mejor posible y que salga bien. Así que, vamos a ver algunos consejos para reducir la posibilidad de fracaso cuando reduces el coste de un proyecto. <h3><a href="http://1.No" rel="nofollow" target="_blank">1.No</a> vayas por lo más barato</h3> El primero es el más obvio de todos: no ir hacia lo más barato. Entiendo que quieras crear una app de bajo presupuesto pero seamos realistas, ¿a qué no se te pasa por la cabeza comprarte un coche nuevo por 100 euros? El problema quizás, es que no harías lo del coche porque sabes lo que cuesta mas o menos un coche nuevo. Mucha gente no sabe lo que cuesta una app aproximadamente y quizás este es el gran problema (aquí un capítulo más para hacer en el futuro: ¿Cuánto cuesta una app?). En mi opinión, una buena técnica, sería la siguiente. En primer lugar, pregunta por presupuestos aproximados de tu aplicación, a empresas de tu alrededor, aquellas que consideres buenas pero que no puedes acceder a ellas por un tema de presupuesto. De todas maneras, no pierdes nada por preguntar cuánto costaría aproximadamente el desarrollar esa aplicación con ellos. Después, haz lo mismo, pero con freelancers que consideres de referencia y que podrían desarrollar correctamente tu aplicación, y que por temas de presupuesto tampoco llegarías a ellos. El tercer paso, es que, con estos presupuestos, te vayas a buscar programadores en páginas web de freelancers, como he dicho antes, que entren dentro de tus expectativas. Ahora bien, vamos a decir que el presupuesto que te han dado las empresas se sitúa alrededor de los 10.000 euros; y el de los freelancers de “referencia” se sitúa en los 7.000 euros. Ahora, sabiendo estos presupuestos, no pretendas que te hagan la app por 200 euros. Sí, hay diferencias entre países y hay algunos que son más económicos, pero cuidado, estamos en un mundo globalizado y el mundo de la programación, sobre todo el trabajo remoto, está a la orden del día. Quiero decir que una persona que es buena programando y son de países como India o China (que tienen fama de trabajar barato) no va a trabajar por 5 euros la hora; esto es así. Si eliges un presupuesto de 200 euros cuando tenías una media de 8.000 euros, no te puedes echar las manos a la cabeza cuando pase lo inevitable: que el proyecto salga mal por cualquier cosa. Así que, mi primer consejo es que no vayas por lo más barato, porque al final, lo barato sale caro. Busca un precio económico, pero tampoco te pases. Ahora que tienes presupuestos aproximados de lo que te costaría. Si tu aplicación está presupuestada en 8.000 euros, quizás podrías encontrar un precio económico entre 4.000-5.000 euros, o 3.000 si me apuras. Pero si empiezas a bajar de ahí, te estás asegurando el fracaso. Una persona que sabe lo que hace en programación, por normal general, no va a trabajar gratis. <h3>2.Busca un experto que esté al mando del proyecto</h3> Este segundo punto trata de tener a alguien que guíe el proyecto. Es decir, una persona o freelance de referencia al cual no puedes acceder a temas de presupuesto pero que sí podrías encontrarlo por muchísimas menos horas para que lleve el proyecto y diga por dónde ir y qué hacer. Pero en este caso, la gran parte del trabajo, lo desarrollaría un freelance que tenga una tarifa más baja y acorde con tu presupuesto. De esta manera, estarías pagando las horas justas para enderezar el proyecto de ese freelance “experto”. Sin embargo, esto es difícil de conseguir; es difícil convencer a un programador experto a que haga esto, porque generalmente, a los programadores, lo que les gusta, es programar. Además, suelen trabajar en proyectos grandes y no pequeños. Es decir, un freelance, suele premiar más un proyecto grande donde hay muchas horas de trabajo, a uno pequeñito y que implique pocas horas. Prefiere concentrar sus esfuerzos en proyectos grandes, así que es un poco difícil convencer a una persona experta a que haga esto, pero no pierdes nada al escribir unos cuantos mails. <h3>3.Buscar un experto que te de pautas iniciales y finales</h3> En este caso, si no te funciona la anterior, puedes buscar un experto que te de pautas iniciales y finales. Es decir, dedicar muy pocas horas, unas 3-4 horas, para que te de una serie de guías iniciales y finales. Por ejemplo, inicialmente, te podría decir cómo tendría que estar estructurado el proyecto, qué tecnología utilizar, etc. Unas guías que permitan al programador menos experimentados seguirlas. La verdad es que esto puede ser bastante útil tanto para la persona que encarga la aplicación, como para el propio programador menos experimentado porque le va a ser más fácil realizar el proyecto. De la misma manera, también te podrían realizar el proyecto al final, más que nada para que sepas lo que tienes entre manos: una aplicación mal o bien programada. En el caso de que esté mal programada, actuaría en consecuencia. <h3>4.Miéntele al programador amateur</h3> Por último, si ni la segunda ni tercera opción te han funcionado, puedes intentar una cosa mucho más sencilla y simple. Es una pequeña mentira, pero puede ser muy útil. Básicamente consiste en decirle al programador de la app (el menos experimentado) que el código va a estar bajo revisión por otro profesional experto, sin que realmente sea así. Esto obliga a un programador a esforzarse. Muchas veces si tú como programador, sabes que tu código no lo vas a ver más que tú mismo, puedes tener la tendencia a relajarte (aunque no deberías) y crear código de menos calidad. Si crees que tu código va a ser revisado, te vas a esforzar más. De esta manera, quizás consigas que el programador dé lo mejor de sí, y se esfuerce al máximo. Estos son los 4 consejos que se me ocurren para obtener la máxima calidad-precio de un desarrollo low-cost. Obviamente, si quieres tener algo de calidad, si quieres tener una buena comunicación con el desarrollador; en definitiva, si quieres desarrollar un proyecto sin miedo de lo que pueda pasar, de si va a salir o no; no elijas un desarrollo low-cost porque lo barato sale caro. Y créeme, en el ámbito de la programación, esto se acentúa mucho más. Un proyecto, por pequeño que sea, si de base, está mal programado, va a traer muchos problemas a la larga. Seguramente, si sigue creciendo, va a tener que ser empezado totalmente desde cero porque eso ya lo he visto más de una vez. De hecho, hace ya bastante tiempo algunos de los proyectos personales que hacía para mí mismo, acabaron así: al cabo de un tiempo tenía que re-hacerlos. La parte buena, es que así se aprende en programación; aunque claro, esto es bueno en cierta manera para el programador, pero no para el cliente. Entonces, si te pasa esto, comete el error tú mismo en proyectos tuyos y que no se lo coma un cliente. Al fin y al cabo, la programación es construir un software, diseñar programas. Al igual que un arquitecto que diseña una casa, si ésta se construye con un mal diseño puedes ir arreglando grietas o tapando fallos. Pero, si está mal construida, no se te va a ocurrir construir 5 plantas más porque seguramente acabará en desastre (si no se cae antes el edificio). Tal vez no sea la comparación más exacta ya que el software tiene que ser más escalable que un edificio. No creo que estos se construyen pensando en añadirle 5 plantas más, pero creo que se entienda. The post <a href="https://diegolaballos.com/podcast/25-crear-apps-baratas-sin-perder-calidad/" rel="nofollow" target="_blank">25. Crear apps baratas sin perder calidad</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

25. Crear apps baratas sin perder calidad

En el episodio anterior, veíamos algunos consejos para desarrollar una app low-cost con la menor pérdida de calidad posible ya que cuando desarrollamos algo con un bajo presupuesto o compramos algo barato, debemos tener en cuenta que estamos sacrificando de algún modo, la calidad del producto o servicio.  Desarrollar apps no es barato ni sencillo Hoy vamos a ver estos puntos que estamos sacrificando y por qué quizás, no sea una buena idea hacerlo.  En primer lugar, el desarrollo de apps, no es sencillo ni barato; tal y como he repetido en otros capítulos. Pero en las aplicaciones es algo relativamente nuevo, en comparación con otras tecnologías; no hay tantas herramientas que faciliten el desarrollo, como puede haber en la web, por ejemplo. Es un mundo más cambiante y mucho más fragmentado. Pensemos en la arquitectura de una web básica. Al fin y al cabo, es un servidor y ya está; nuestra web siempre funciona sobre un servidor, ordenador en la nube.  Lo que ven los usuarios no es más que el output, el resultado de unas operaciones que corren sobre el servidor. Si pensamos en la arquitectura de una aplicación, existe casi siempre un servidor, así como muchos clientes y dispositivos móviles en donde corre nuestra aplicación. Sí, muchas decisiones se toman en el servidor; pero muchas otras, se toman en estos móviles y clientes, que son muy distintos entre sí. Si tenemos en cuenta que estos dispositivos van a ser diferentes, por el fabricante, sistema operativo, versiones, etc., la cosa se complica más. Hay que tener en cuenta que el desarrollo de una app conlleva también en cierto modo, el desarrollo de una web. Pues bien, este y otros puntos, nos hacen ver que el desarrollo móvil no es algo sencillo. Habría que pensar si realmente es necesario/apropiado, el desarrollar una aplicación teniendo un presupuesto muy limitado.  Los usuarios son muy exigentes En segundo lugar, los usuarios somos muy exigentes con las aplicaciones móviles. Solo hay que ver las reviews en Google Play y App Store. A la mínima que una aplicación no funciona del todo bien, la crujen en las opiniones. Queremos utilizar aplicaciones rápidas y que funcionen sin errores. Si desarrollamos con un presupuesto limitado, tendremos que tener en cuenta que estemos puntos pueden acentuarse más. Ojo, con un presupuesto normal, podríamos también tener problemas pero, teóricamente, deberían ser menos. Si nuestra aplicación no funciona del todo bien, si empezamos a tener malas puntuaciones y opiniones, vamos a causar una mala impresión en las tiendas, cuando otros usuarios vean estas opiniones: quizás usuarios que la iban a probar, ya no la probarán y, además, tanto Google Play como App Store, los posicionarán más abajo. Buena comunicación En los proyectos informáticos en general, la comunicación entre el programador y el cliente, es vital.  El programador tiene que plasmar y crear exactamente lo que le cuenta el cliente; tiene que transformar una idea en el producto final. Además, idealmente tendría que colaborar en las ideas de ese proyecto, con los conocimientos técnicos que él tiene. Muchas veces, al contratar a un desarrollador low-cost, implica contratar a alguien que no comparte tu misma zona geográfica. Esto quiere decir, aunque no necesariamente, que quizás no compartan el mismo idioma u horario de trabajo. Es decir, mientras tú estás durmiendo, él está trabajando, y a la inversa. Al fin y al cabo, esto dificulta más esta comunicación que, en mi opinión tendría que ser casi diaria en el desarrollo de un proyecto. La comunicación debe ser a través de Skype, e-mail o incluso presencial si se necesitara.  Abandono del proyecto Este, es un punto temido. ¿Cuántas veces habéis escuchado que un programador ha dejado tirado a alguien? En mi opinión, esto pasa por contratar un desarrollo low-cost.  Si contratamos a alguien que nos hace una aplicación muy barata, puede ser porque está estudiando y quiere sacarse un sueldo extra. Puede ser que la persona ya tenga su trabajo y haya decidido también sacarse un sueldo extra haciendo proyectos por su cuenta con otras personas. Por último, la otra posibilidad es que esa persona acaba de empezar e intenta coger proyectos rebajando el precio porque tiene menos experiencia. ¿Qué pasa con esto? En el momento en que el proyecto tenga alguna complicación, puede existir la tentación de dejarlo pasar. El programador dice “pff, lo dejo pasar; me voy a ahorrar dolores de cabeza y me voy a otra cosa”  Si no te dedicas completamente a ello y no tienes una reputación que mantener, lo fácil es dejar el problema e intentar ir a otra cosa. Esto es mi opinión, pero creo que es lo que pasa en estos abandonos. Relación a largo plazo Las aplicaciones conllevan una relación a largo plazo con el programador. Una app, tiene un gran trabajo de mantenimiento una vez desarrollada; solo tenemos que ver las aplicaciones que tenemos instaladas en el móvil.  Cada semana tenemos actualizaciones de la misma aplicación. Si creas una web y no la tocas en 5 años, lo más seguro es que vaya a seguir funcionando pero quedará anticuada en cuanto al diseño y con un algún fallo de seguridad. Las aplicaciones son más complejas. Se hacen tantos cambios en los sistemas operativos que, según qué características, dejan que funcionar si no los modificamos y adaptamos a los nuevos sistemas. Además, como ya se menciona, en cuanto a diseño quedan muy desfasadas rápidamente.  Ya sabemos que el diseño va muy acorde a la versión del sistema operativo. En cuanto cambia éste el diseño de las aplicaciones también cambia. Esto implica, que los cambios se hacen año tras año. Las aplicaciones de hace 3-4 años, en comparación con las de ahora, no tienen absolutamente nada que ver, por lo menos en cuanto al diseño. Pues bien, los desarrolladores low-cost, suelen serlo por lo que he dicho antes: no suele ser sostenible estar desarrollando aplicaciones a 5 euros la hora; o te cansas, o te vuelves loco. Lo normal, es que un desarrollador vaya cogiendo experiencia y vaya incrementando su precio-hora. Con lo cual, si queremos seguir con un desarrollador low-cost durante un largo tiempo, vamos a tener que estar cambiando de desarrollador cada cierto tiempo. En mi opinión, lo mejor es mantener a un desarrollador el máximo tiempo posible.  Cuando un programador entra de nuevo en un proyecto, requiere cierto tiempo de aprendizaje y cierta complejidad hasta que conoce ese proyecto.  No podemos estar cambiando de desarrollador cada 3 meses porque además de que les va a llevar más tiempo, tendremos más posibilidades de que el proyecto, en algún punto, se haga insostenible porque han pasado muchos programadores.  Cuantos más programadores pasen por un proyecto, es más probable que alguno no sea el mejor. Un mal desarrollo inicial te seguirá por siempre Un mal desarrollo al principio, es un peso que se arrastrará a lo largo del tiempo. Ya lo comenté en el episodio anterior: si nuestra intención es desarrollar una app barata para “probar”, tenemos que tener en cuenta que es posible que se rehaga en el futuro. Si lo sabes, y estás consciente de ello, está bien: “Voy a probar a hacer algo económico; si funciona ya lo re-haré si hace falta. Soy consciente de ello, solo quiero probar y si funciona, gastaré más dinero y lo haré bien”. Pero, si no eres consciente de esto, y quieres seguir en el mismo proyecto aplicando parches y parches, porque inicialmente no estaba bien, tienes que saber que la cosa puede acabar bastante mal.  Idealmente, cualquier app o sistema informático tendría que estar desarrollado bien desde un principio, pensado para que pueda crecer y dar facilidades para ello. De esta manera, aunque al principio, se tarde más en pensar y desarrollar el proyecto, a la larga será mucho más fácil mantenerlo. Como decía en el capítulo anterior, un proyecto que, inicialmente está mal hecho, por pequeño que sea el problema, puede que, a la larga, implique mayor tiempo para añadir cosas, modificarlo y corregir errores. Seguridad, confianza y tranquilidad Finalmente, estos son aspectos muy a tener en cuenta para no desarrollar un proyecto low-cost. Al fin y al cabo, cuando encargas algo y pagas por ello, lo que haces, es delegar esa tarea porque quieres que lo haga otra persona que lo puede hacer mejor que tú.  En cierto modo, quieres des-preocuparte: “Pago porque me hagan esto; no lo quiero hacer yo, o no lo se hacer yo, y quiero despreocuparme”. Si tienes que estar con el miedo de si saldrá, de si no saldrá, de estar con la duda, al fin y al cabo, estás haciendo doble trabajo. Por un lado, estás preocupado por el proyecto; y, por otro, estás pagando por ello. Lo normal es que contrataras a alguien y, en cierto modo te quedarás tranquilo de que el proyecto va a salir, y bien. También hay que decir que un proyecto no necesariamente tiene que ser siempre una aplicación. Si estamos limitados de presupuesto, ¿Por qué no optar por otra alternativa como la web, que suele ser más sencilla y barata porque hay herramientas para hacerlo de forma más sencilla y barata? Ahora bien, si estás forzado a hacer la aplicación sí o sí con un presupuesto bajo, puedes ignorar este capítulo e irte al anterior que, quizás te resulte más útil. Si quieres crear una aplicación barata porque te ves forzado por un presupuesto limitado, ten en cuenta que el desarrollo de apps, no es sencillo ni barato y que los usuarios móviles son muy exigentes con las aplicaciones móviles. En los proyectos informáticos, la comunicación entre el cliente y el desarrollador, es vital y, muchas veces, un desarrollador low-cost, por algunos de los motivos que hemos comentado pueden no tener una comunicación ideal. También tienes que saber que el riesgo de que el programador te abandone y deje tirado el proyecto, es más alto y que las aplicaciones necesitan una relación de largo plazo con un programador Un mal desarrollo inicial puede ser un gran peso que arrastrar a lo largo del tiempo y finalmente, la tranquilidad que te ofrecerá una empresa o freelance de referencia es mucho mayor que la que te ofrece un desarrollo low-cost, en la cual estarás pensando constantemente en si va a salir o no En mi opinión, éstas son las razones por las cuales yo no utilizaría un desarrollo low-cost. Obviamente, cada quien puede hacer lo que quiera pero ahí queda. The post 26. ¿Por qué no crear apps low-cost? appeared first on Diego Laballós.

En el episodio anterior, veíamos algunos consejos para desarrollar una app low-cost con la menor pérdida de calidad posible ya que cuando desarrollamos algo con un bajo presupuesto o compramos algo barato, debemos tener en cuenta que estamos sacrificando de algún modo, la calidad del producto o servicio. <h3>Desarrollar apps no es barato ni sencillo</h3> Hoy vamos a ver estos puntos que estamos sacrificando y por qué quizás, no sea una buena idea hacerlo. En primer lugar, el desarrollo de apps, no es sencillo ni barato; tal y como he repetido en otros capítulos. Pero en las aplicaciones es algo relativamente nuevo, en comparación con otras tecnologías; no hay tantas herramientas que faciliten el desarrollo, como puede haber en la web, por ejemplo. Es un mundo más cambiante y mucho más fragmentado. Pensemos en la arquitectura de una web básica. Al fin y al cabo, es un servidor y ya está; nuestra web siempre funciona sobre un servidor, ordenador en la nube. Lo que ven los usuarios no es más que el output, el resultado de unas operaciones que corren sobre el servidor. Si pensamos en la arquitectura de una aplicación, existe casi siempre un servidor, así como muchos clientes y dispositivos móviles en donde corre nuestra aplicación. Sí, muchas decisiones se toman en el servidor; pero muchas otras, se toman en estos móviles y clientes, que son muy distintos entre sí. Si tenemos en cuenta que estos dispositivos van a ser diferentes, por el fabricante, sistema operativo, versiones, etc., la cosa se complica más. Hay que tener en cuenta que el desarrollo de una app conlleva también en cierto modo, el desarrollo de una web. Pues bien, este y otros puntos, nos hacen ver que el desarrollo móvil no es algo sencillo. Habría que pensar si realmente es necesario/apropiado, el desarrollar una aplicación teniendo un presupuesto muy limitado. <h3>Los usuarios son muy exigentes</h3> En segundo lugar, los usuarios somos muy exigentes con las aplicaciones móviles. Solo hay que ver las reviews en Google Play y App Store. A la mínima que una aplicación no funciona del todo bien, la crujen en las opiniones. Queremos utilizar aplicaciones rápidas y que funcionen sin errores. Si desarrollamos con un presupuesto limitado, tendremos que tener en cuenta que estemos puntos pueden acentuarse más. Ojo, con un presupuesto normal, podríamos también tener problemas pero, teóricamente, deberían ser menos. Si nuestra aplicación no funciona del todo bien, si empezamos a tener malas puntuaciones y opiniones, vamos a causar una mala impresión en las tiendas, cuando otros usuarios vean estas opiniones: quizás usuarios que la iban a probar, ya no la probarán y, además, tanto Google Play como App Store, los posicionarán más abajo. <h3>Buena comunicación</h3> En los proyectos informáticos en general, la comunicación entre el programador y el cliente, es vital. El programador tiene que plasmar y crear exactamente lo que le cuenta el cliente; tiene que transformar una idea en el producto final. Además, idealmente tendría que colaborar en las ideas de ese proyecto, con los conocimientos técnicos que él tiene. Muchas veces, al contratar a un desarrollador low-cost, implica contratar a alguien que no comparte tu misma zona geográfica. Esto quiere decir, aunque no necesariamente, que quizás no compartan el mismo idioma u horario de trabajo. Es decir, mientras tú estás durmiendo, él está trabajando, y a la inversa. Al fin y al cabo, esto dificulta más esta comunicación que, en mi opinión tendría que ser casi diaria en el desarrollo de un proyecto. La comunicación debe ser a través de Skype, e-mail o incluso presencial si se necesitara. <h3>Abandono del proyecto</h3> Este, es un punto temido. ¿Cuántas veces habéis escuchado que un programador ha dejado tirado a alguien? En mi opinión, esto pasa por contratar un desarrollo low-cost. Si contratamos a alguien que nos hace una aplicación muy barata, puede ser porque está estudiando y quiere sacarse un sueldo extra. Puede ser que la persona ya tenga su trabajo y haya decidido también sacarse un sueldo extra haciendo proyectos por su cuenta con otras personas. Por último, la otra posibilidad es que esa persona acaba de empezar e intenta coger proyectos rebajando el precio porque tiene menos experiencia. ¿Qué pasa con esto? En el momento en que el proyecto tenga alguna complicación, puede existir la tentación de dejarlo pasar. El programador dice “pff, lo dejo pasar; me voy a ahorrar dolores de cabeza y me voy a otra cosa” Si no te dedicas completamente a ello y no tienes una reputación que mantener, lo fácil es dejar el problema e intentar ir a otra cosa. Esto es mi opinión, pero creo que es lo que pasa en estos abandonos. <h3>Relación a largo plazo</h3> Las aplicaciones conllevan una relación a largo plazo con el programador. Una app, tiene un gran trabajo de mantenimiento una vez desarrollada; solo tenemos que ver las aplicaciones que tenemos instaladas en el móvil. Cada semana tenemos actualizaciones de la misma aplicación. Si creas una web y no la tocas en 5 años, lo más seguro es que vaya a seguir funcionando pero quedará anticuada en cuanto al diseño y con un algún fallo de seguridad. Las aplicaciones son más complejas. Se hacen tantos cambios en los sistemas operativos que, según qué características, dejan que funcionar si no los modificamos y adaptamos a los nuevos sistemas. Además, como ya se menciona, en cuanto a diseño quedan muy desfasadas rápidamente. Ya sabemos que el diseño va muy acorde a la versión del sistema operativo. En cuanto cambia éste el diseño de las aplicaciones también cambia. Esto implica, que los cambios se hacen año tras año. Las aplicaciones de hace 3-4 años, en comparación con las de ahora, no tienen absolutamente nada que ver, por lo menos en cuanto al diseño. Pues bien, los desarrolladores low-cost, suelen serlo por lo que he dicho antes: no suele ser sostenible estar desarrollando aplicaciones a 5 euros la hora; o te cansas, o te vuelves loco. Lo normal, es que un desarrollador vaya cogiendo experiencia y vaya incrementando su precio-hora. Con lo cual, si queremos seguir con un desarrollador low-cost durante un largo tiempo, vamos a tener que estar cambiando de desarrollador cada cierto tiempo. En mi opinión, lo mejor es mantener a un desarrollador el máximo tiempo posible. Cuando un programador entra de nuevo en un proyecto, requiere cierto tiempo de aprendizaje y cierta complejidad hasta que conoce ese proyecto. No podemos estar cambiando de desarrollador cada 3 meses porque además de que les va a llevar más tiempo, tendremos más posibilidades de que el proyecto, en algún punto, se haga insostenible porque han pasado muchos programadores. Cuantos más programadores pasen por un proyecto, es más probable que alguno no sea el mejor. <h3>Un mal desarrollo inicial te seguirá por siempre</h3> Un mal desarrollo al principio, es un peso que se arrastrará a lo largo del tiempo. Ya lo comenté en el episodio anterior: si nuestra intención es desarrollar una app barata para “probar”, tenemos que tener en cuenta que es posible que se rehaga en el futuro. Si lo sabes, y estás consciente de ello, está bien: “Voy a probar a hacer algo económico; si funciona ya lo re-haré si hace falta. Soy consciente de ello, solo quiero probar y si funciona, gastaré más dinero y lo haré bien”. Pero, si no eres consciente de esto, y quieres seguir en el mismo proyecto aplicando parches y parches, porque inicialmente no estaba bien, tienes que saber que la cosa puede acabar bastante mal. Idealmente, cualquier app o sistema informático tendría que estar desarrollado bien desde un principio, pensado para que pueda crecer y dar facilidades para ello. De esta manera, aunque al principio, se tarde más en pensar y desarrollar el proyecto, a la larga será mucho más fácil mantenerlo. Como decía en el capítulo anterior, un proyecto que, inicialmente está mal hecho, por pequeño que sea el problema, puede que, a la larga, implique mayor tiempo para añadir cosas, modificarlo y corregir errores. <h3>Seguridad, confianza y tranquilidad</h3> Finalmente, estos son aspectos muy a tener en cuenta para no desarrollar un proyecto low-cost. Al fin y al cabo, cuando encargas algo y pagas por ello, lo que haces, es delegar esa tarea porque quieres que lo haga otra persona que lo puede hacer mejor que tú. En cierto modo, quieres des-preocuparte: “Pago porque me hagan esto; no lo quiero hacer yo, o no lo se hacer yo, y quiero despreocuparme”. Si tienes que estar con el miedo de si saldrá, de si no saldrá, de estar con la duda, al fin y al cabo, estás haciendo doble trabajo. Por un lado, estás preocupado por el proyecto; y, por otro, estás pagando por ello. Lo normal es que contrataras a alguien y, en cierto modo te quedarás tranquilo de que el proyecto va a salir, y bien. También hay que decir que un proyecto no necesariamente tiene que ser siempre una aplicación. Si estamos limitados de presupuesto, ¿Por qué no optar por otra alternativa como la web, que suele ser más sencilla y barata porque hay herramientas para hacerlo de forma más sencilla y barata? Ahora bien, si estás forzado a hacer la aplicación sí o sí con un presupuesto bajo, puedes ignorar este capítulo e irte al anterior que, quizás te resulte más útil. Si quieres crear una aplicación barata porque te ves forzado por un presupuesto limitado, ten en cuenta que el desarrollo de apps, no es sencillo ni barato y que los usuarios móviles son muy exigentes con las aplicaciones móviles. En los proyectos informáticos, la comunicación entre el cliente y el desarrollador, es vital y, muchas veces, un desarrollador low-cost, por algunos de los motivos que hemos comentado pueden no tener una comunicación ideal. También tienes que saber que el riesgo de que el programador te abandone y deje tirado el proyecto, es más alto y que las aplicaciones necesitan una relación de largo plazo con un programador Un mal desarrollo inicial puede ser un gran peso que arrastrar a lo largo del tiempo y finalmente, la tranquilidad que te ofrecerá una empresa o freelance de referencia es mucho mayor que la que te ofrece un desarrollo low-cost, en la cual estarás pensando constantemente en si va a salir o no En mi opinión, éstas son las razones por las cuales yo no utilizaría un desarrollo low-cost. Obviamente, cada quien puede hacer lo que quiera pero ahí queda. The post <a href="https://diegolaballos.com/podcast/26-por-que-no-crear-apps-low-cost/" rel="nofollow" target="_blank">26. ¿Por qué no crear apps low-cost?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

26. ¿Por qué no crear apps low-cost?

Empecemos con Android y iOS a nivel de usuario. Esto, es una decisión bastante más personal y subjetiva; y, depende de la opinión de cada uno. De todos modos, tal y como dice Alberto (quién recomendó el tema), ambos tienen cosas buenas y malas. Exactamente pasa lo mismo desde la perspectiva de alguien que quiere lanzar una app. Android tiene aspectos en los cuales es mejor que iOS, y lo mismo pasa al revés. Al fin y al cabo, si hubiera un sistema mejor que otro, se comería a todo el mercado y acabaríamos con un solo sistema. La verdad ya hace unos años que conviven juntos y no pasa esto. Así que, el tema general del capítulo, es que simplemente no hay un sistema mejor; simplemente, habrá un sistema mejor en función de las necesidades u objetivos de cada quien: ya sea una persona que se quiere comprar un móvil o desde la perspectiva de alguien que quiere lanzar un proyecto. Cosas buenas y malas de iOS A nivel de usuario, yo he probado ambos. Actualmente tengo Android, pero también he tenido iOS. Si tuviera que decir las cosas buenas de iOS, diría que es un sistema simple, minimalista. Asimismo, es muy sencillo de utilizar y funciona muy bien ya que los dispositivos que llevan iOS, son de gama alta (quitando alguna versión del iPad mini, que es más simple), por lo que es normal que funcione bien y rápido. En cuanto a las cosas malas de iOS, está que no es muy personalizable y no tiene tantas opciones. Con respecto al tema iTunes (música, videos, imágenes, etc.) no es lo mejor; yo odio iTunes personalmente. En general, es un sistema bastante cerrado; es lo que te dan ellos y ya está, solo Apple. Cosas buenas y malas de Android Por el otro lado, entre las cosas buenas de Android, está lo contrario: es un sistema más abierto, con muchas más opciones, y tiene muchos dispositivos entre los cuales elegir porque hay muchos fabricantes.  Con respecto a las cosas malas, dependiendo del fabricante que elijas, a veces no acaba de funcionar todo lo bien que debería. Pero claro, esto no es una cosa del sistema operativo; es más del fabricante. Así que, en general, me parece mejor el sistema operativo Android; pero es mi opinión personal. Visto esto a nivel de usuario en general que como digo, es bastante subjetivo y depende de cada quien, vamos a ver desde el punto de vista de crear una app, ¿Qué pasa? En muchos casos, cuando se quiere realizar y lanzar una app, se puede hacer en más de un solo sistema, ya sea para ahorrar costos o porque realmente se necesita en un solo sistema, etc. El caso, es ver qué sistema es más interesante inicialmente. Cantidad de usuarios Aquí no es ningún secreto que Android se lleva la palma; tiene muchísimos más usuarios que iOS. Esto, viene muy marcado por el hecho de que hay muchos dispositivos Android, muchos diseños y precios distintos, lo que hace que hace que haya más gente con Android que iOS. Cuando vamos a una tienda de móviles, vemos que de cada 50 hay 10 o incluso 5, que son iOS, y los demás son Android (y algún Windows Phone por ahí marginado) y ya está. Si vamos a mirar estadísticas reales y serias, y no opiniones, según un estudio de Gartner, actualmente la proporción de Android con respecto a iOS se sitúa en un 86% de móviles Android, por un 13% de iOS. Más o menos, 8 de cada 10 móviles son Android; y 1 de cada 10 son iOS. Si miramos otra estadística, esta vez de AppAnnie, una web que también hace estudios de mercado de aplicaciones móviles, vemos que, en Google Play, se producen el doble de descargas a nivel general que en iOS. En el punto de la cantidad de usuarios, la conclusión es, que, si tu app tiene que llegar al máximo número de personas, una buena elección sería Android. Sin embargo, como iremos viendo quizás hay otros puntos que puedan interesar más, además de la cantidad de usuarios. Monetización Este es otro punto interesante a la hora de crear una app. Saber qué usuarios son más propensos a pagar por algo, dentro del ecosistema móvil. Aquí se produce un dato contradictorio con la cantidad de usuarios, pero veremos que puede tener sentido: mientras que en Android se producen el doble de descargas que, en iOS, en este último se ingresa el doble que en aquel. Esto no lo digo yo sino un estudio de App Annie. Lo normal es que, si lanzamos una app y miramos las estadísticas a nivel general, lo normal es que nuestra app para Android, tuviera el doble de descargas que iOS. Sin embargo, tendríamos el doble de ingresos en iOS que en Android. Si lo pensamos un poco, puede llegar a tener sentido. Tenemos que pensar que ahora mismo, si tu te vas a comprar un móvil Android, puedes encontrarlos desde 50-900 euros (no sé ahora mismo cual es el más caro). En cambio, si nos vamos a iOS, estamos obligados a comprar el IPhone, cuyo último modelo, se sitúa a partir de 750 euros. Mirando esto, podemos sacar la conclusión general, que la gente que tiene iOS puede tener un poder adquisitivo más alto y, por lo tanto, estar dispuesta a pagar más. En conclusión, atendiendo a las estadísticas generales, lo normal es que ingresemos más dinero en una app de iOS que en la de Android. Coste y desarrollo de mantenimiento Con esto, me refiero al coste de desarrollo de la aplicación, y del mantenimiento que hay que hacerle. Yo diría desde mi experiencia, que el costo de desarrollo en ambos sistemas, es bastante parecido. Al fin y al cabo, son dispositivos móviles que son muy parecidos, aunque tienen algunas son muy distintas a la hora de desarrollarlas. Sin embargo, si me la tuviera que jugar a decir cual puede costar más dinero y llevar más tiempo, yo diría que Android. Aquí existe un problema derivado del hecho de que la compañía que le da mantenimiento a este, no es la misma que el fabricante. Es decir, tenemos muchos fabricantes, por un lado, y por otro, una única compañía que fabrica el software. Por lo tanto, hay un poco de lío aquí; no está tan coordinado como Apple que fabrica su propio software y hardware. Con esto, quiero decir que existe una fragmentación bastante grande en Android. En otras palabras, nos podemos encontrar con muchos dispositivos y cada uno, con versiones del sistema diferentes. Mientras que, en iOS, para hacer una app, tenemos que tener en cuenta el iPhone y sus dos o tres últimos modelos, en Android tenemos que considerar muchos más dispositivos y sistemas. Además, el 90% de los usuarios de iOS suelen estar en la última versión del sistema operativo; mientras que, en Android, no pasa eso ni mucho menos. Este punto, afecta bastante al desarrollo porque tienes que tener en cuenta muchas más versiones, muchas más cosas que pueden pasar, muchos más fallos que se pueden producir, etc. Para concluir esta parte, el tiempo y coste de desarrollo será más o menos igual pero quizás, Android sea un poquito más costoso y lleve más tiempo el desarrollo. Datos demográficos Hemos estado comentando el tema de la cantidad de usuarios, pero lo que no hemos dicho, es que esta proporción, obviamente no es la misma según la región que estemos mirando. Si nuestra app es para un país en concreto, un dato bastante interesante sería la proporción exacta que existe en ese país o región; me refiero a la proporción Android – iOS. Por ejemplo, yo he encontrado un estudio a nivel de continente, bastante general, donde se ve la proporción de Android con iOS (también sale Windows Phone que, es bastante ridículo el porcentaje que tiene, pero sale).  Por ejemplo, en Asia, existe un 71% de Android, por un 27% de iOS; en Norteamérica un 46% de Android por un 52% de iOS. Como vemos, en Norteamérica se igual bastante e incluso iOS supera un poquito a Android. En Europa, 62% Android y Windows Phone 34%. En Sudamérica, 80% Android y 16% iOS; aquí Android gana de calle. En África, más o menos lo mismo, 74% Android y 11% iOS. Finalmente, Oceanía con 41% Android y 58% iOS. En resumen, podríamos decir que, en países desarrollados o pioneros en el mundo de la tecnología, la proporción se ajusta un poco más. Incluso iOS puede llegar a superar a Android, por lo menos eso indica este estudio que he visto. Probablemente, en otro, los datos difieran, pero no deberían ser muy diferente. Sin embargo, en el resto de continentes, Android arrasa directamente. Por ejemplo, Sudamérica, África e incluso Asia. Tablets Esto era algo de lo que no me quería olvidar: el mercado de las tabletas. SI vamos a crear una app que sea principalmente para tabletas, como una app de lectura o una app que requiere de una pantalla más grande, por ejemplo, de videos. En general, un proyecto donde las tabletas tengan más importancia. Tenemos que saber que aquí, iOS arrasa, es el ganador. Si miramos las principales tabletas que se utilizan, entre las 10 primeras tabletas utilizadas, aparece un modelo del iPad siete veces. Así que, si nuestra app va muy enfocada en tabletas, quizás sería buena idea empezar por iOS. Aplicaciones de gestión empresarial interna ¿A qué me refiero con esto? Por ejemplo, las aplicaciones que llevan los repartidores de paquetería. Normalmente, cuando llegan a casa y te entregan un paquete, vienen con un dispositivo móvil, escanean el código de barras del paquete y te hacen firmar en este dispositivo. Pues bien, esa es una aplicación que utiliza la empresa para su gestión interna. Son aplicaciones privadas no disponibles al público, que simplemente se utilizan a nivel interno para gestionar. En este caso, pensemos lo siguiente: imagina que eres el dueño de una empresa de paquetería / correos, y quieres implementar una aplicación para acelerar todo el proceso de entrega, de gestión de paquetes, su ubicación, etc. Claro, tienes que encargar una aplicación, pero, también vas a tener que comprar dispositivos. Imagina que tienes 100 trabajadores y vas a necesitar 100 dispositivos, ¿Qué harías?, ¿Comprar 100 iPhone de 800 euros y gastarte en total 8000 euros, más los posibles gastos de reparación o perdida? O, ¿comprar 100 Android de 100 euros, que en total te saldría en 1000 euros? Aquí, la diferencia es bastante abismal. Si nos fijamos, es muy raro que una empresa de gestión interna utilice iPhone; que venga un repartidor te gestione ese pedido, haga el escaneo de código de barras y te haga firmar en un iPhone. Lo más normal es que tenga un Android u otro sistema. Aquí, el hecho de tener muchos fabricantes y dispositivos distintos y muchos rangos de precios, es claramente un punto diferencial. Así que, si quieres hacer una aplicación de gestión interna, sin duda yo elegiría Android. The post 18. ¿Android o iOS? ¿Qué sistema es mejor? appeared first on Diego Laballós.

Empecemos con Android y iOS a nivel de usuario. Esto, es una decisión bastante más personal y subjetiva; y, depende de la opinión de cada uno. De todos modos, tal y como dice Alberto (quién recomendó el tema), ambos tienen cosas buenas y malas. Exactamente pasa lo mismo desde la perspectiva de alguien que quiere lanzar una app. Android tiene aspectos en los cuales es mejor que iOS, y lo mismo pasa al revés. Al fin y al cabo, si hubiera un sistema mejor que otro, se comería a todo el mercado y acabaríamos con un solo sistema. La verdad ya hace unos años que conviven juntos y no pasa esto. Así que, el tema general del capítulo, es que simplemente no hay un sistema mejor; simplemente, habrá un sistema mejor en función de las necesidades u objetivos de cada quien: ya sea una persona que se quiere comprar un móvil o desde la perspectiva de alguien que quiere lanzar un proyecto. <h3>Cosas buenas y malas de iOS</h3> A nivel de usuario, yo he probado ambos. Actualmente tengo Android, pero también he tenido iOS. Si tuviera que decir las cosas buenas de iOS, diría que es un sistema simple, minimalista. Asimismo, es muy sencillo de utilizar y funciona muy bien ya que los dispositivos que llevan iOS, son de gama alta (quitando alguna versión del iPad mini, que es más simple), por lo que es normal que funcione bien y rápido. En cuanto a las cosas malas de iOS, está que no es muy personalizable y no tiene tantas opciones. Con respecto al tema iTunes (música, videos, imágenes, etc.) no es lo mejor; yo odio iTunes personalmente. En general, es un sistema bastante cerrado; es lo que te dan ellos y ya está, solo Apple. <h3>Cosas buenas y malas de Android</h3> Por el otro lado, entre las cosas buenas de Android, está lo contrario: es un sistema más abierto, con muchas más opciones, y tiene muchos dispositivos entre los cuales elegir porque hay muchos fabricantes. Con respecto a las cosas malas, dependiendo del fabricante que elijas, a veces no acaba de funcionar todo lo bien que debería. Pero claro, esto no es una cosa del sistema operativo; es más del fabricante. Así que, en general, me parece mejor el sistema operativo Android; pero es mi opinión personal. Visto esto a nivel de usuario en general que como digo, es bastante subjetivo y depende de cada quien, vamos a ver desde el punto de vista de crear una app, ¿Qué pasa? En muchos casos, cuando se quiere realizar y lanzar una app, se puede hacer en más de un solo sistema, ya sea para ahorrar costos o porque realmente se necesita en un solo sistema, etc. El caso, es ver qué sistema es más interesante inicialmente. <h3>Cantidad de usuarios</h3> Aquí no es ningún secreto que Android se lleva la palma; tiene muchísimos más usuarios que iOS. Esto, viene muy marcado por el hecho de que hay muchos dispositivos Android, muchos diseños y precios distintos, lo que hace que hace que haya más gente con Android que iOS. Cuando vamos a una tienda de móviles, vemos que de cada 50 hay 10 o incluso 5, que son iOS, y los demás son Android (y algún Windows Phone por ahí marginado) y ya está. Si vamos a mirar estadísticas reales y serias, y no opiniones, según un estudio de Gartner, actualmente la proporción de Android con respecto a iOS se sitúa en un 86% de móviles Android, por un 13% de iOS. Más o menos, 8 de cada 10 móviles son Android; y 1 de cada 10 son iOS. Si miramos otra estadística, esta vez de AppAnnie, una web que también hace estudios de mercado de aplicaciones móviles, vemos que, en Google Play, se producen el doble de descargas a nivel general que en iOS. En el punto de la cantidad de usuarios, la conclusión es, que, si tu app tiene que llegar al máximo número de personas, una buena elección sería Android. Sin embargo, como iremos viendo quizás hay otros puntos que puedan interesar más, además de la cantidad de usuarios. <h3>Monetización</h3> Este es otro punto interesante a la hora de crear una app. Saber qué usuarios son más propensos a pagar por algo, dentro del ecosistema móvil. Aquí se produce un dato contradictorio con la cantidad de usuarios, pero veremos que puede tener sentido: mientras que en Android se producen el doble de descargas que, en iOS, en este último se ingresa el doble que en aquel. Esto no lo digo yo sino un estudio de App Annie. Lo normal es que, si lanzamos una app y miramos las estadísticas a nivel general, lo normal es que nuestra app para Android, tuviera el doble de descargas que iOS. Sin embargo, tendríamos el doble de ingresos en iOS que en Android. Si lo pensamos un poco, puede llegar a tener sentido. Tenemos que pensar que ahora mismo, si tu te vas a comprar un móvil Android, puedes encontrarlos desde 50-900 euros (no sé ahora mismo cual es el más caro). En cambio, si nos vamos a iOS, estamos obligados a comprar el IPhone, cuyo último modelo, se sitúa a partir de 750 euros. Mirando esto, podemos sacar la conclusión general, que la gente que tiene iOS puede tener un poder adquisitivo más alto y, por lo tanto, estar dispuesta a pagar más. En conclusión, atendiendo a las estadísticas generales, lo normal es que ingresemos más dinero en una app de iOS que en la de Android. <h3>Coste y desarrollo de mantenimiento</h3> Con esto, me refiero al coste de desarrollo de la aplicación, y del mantenimiento que hay que hacerle. Yo diría desde mi experiencia, que el costo de desarrollo en ambos sistemas, es bastante parecido. Al fin y al cabo, son dispositivos móviles que son muy parecidos, aunque tienen algunas son muy distintas a la hora de desarrollarlas. Sin embargo, si me la tuviera que jugar a decir cual puede costar más dinero y llevar más tiempo, yo diría que Android. Aquí existe un problema derivado del hecho de que la compañía que le da mantenimiento a este, no es la misma que el fabricante. Es decir, tenemos muchos fabricantes, por un lado, y por otro, una única compañía que fabrica el software. Por lo tanto, hay un poco de lío aquí; no está tan coordinado como Apple que fabrica su propio software y hardware. Con esto, quiero decir que existe una fragmentación bastante grande en Android. En otras palabras, nos podemos encontrar con muchos dispositivos y cada uno, con versiones del sistema diferentes. Mientras que, en iOS, para hacer una app, tenemos que tener en cuenta el iPhone y sus dos o tres últimos modelos, en Android tenemos que considerar muchos más dispositivos y sistemas. Además, el 90% de los usuarios de iOS suelen estar en la última versión del sistema operativo; mientras que, en Android, no pasa eso ni mucho menos. Este punto, afecta bastante al desarrollo porque tienes que tener en cuenta muchas más versiones, muchas más cosas que pueden pasar, muchos más fallos que se pueden producir, etc. Para concluir esta parte, el tiempo y coste de desarrollo será más o menos igual pero quizás, Android sea un poquito más costoso y lleve más tiempo el desarrollo. <h3>Datos demográficos</h3> Hemos estado comentando el tema de la cantidad de usuarios, pero lo que no hemos dicho, es que esta proporción, obviamente no es la misma según la región que estemos mirando. Si nuestra app es para un país en concreto, un dato bastante interesante sería la proporción exacta que existe en ese país o región; me refiero a la proporción Android – iOS. Por ejemplo, yo he encontrado un estudio a nivel de continente, bastante general, donde se ve la proporción de Android con iOS (también sale Windows Phone que, es bastante ridículo el porcentaje que tiene, pero sale). Por ejemplo, en Asia, existe un 71% de Android, por un 27% de iOS; en Norteamérica un 46% de Android por un 52% de iOS. Como vemos, en Norteamérica se igual bastante e incluso iOS supera un poquito a Android. En Europa, 62% Android y Windows Phone 34%. En Sudamérica, 80% Android y 16% iOS; aquí Android gana de calle. En África, más o menos lo mismo, 74% Android y 11% iOS. Finalmente, Oceanía con 41% Android y 58% iOS. En resumen, podríamos decir que, en países desarrollados o pioneros en el mundo de la tecnología, la proporción se ajusta un poco más. Incluso iOS puede llegar a superar a Android, por lo menos eso indica este estudio que he visto. Probablemente, en otro, los datos difieran, pero no deberían ser muy diferente. Sin embargo, en el resto de continentes, Android arrasa directamente. Por ejemplo, Sudamérica, África e incluso Asia. <h3>Tablets</h3> Esto era algo de lo que no me quería olvidar: el mercado de las tabletas. SI vamos a crear una app que sea principalmente para tabletas, como una app de lectura o una app que requiere de una pantalla más grande, por ejemplo, de videos. En general, un proyecto donde las tabletas tengan más importancia. Tenemos que saber que aquí, iOS arrasa, es el ganador. Si miramos las principales tabletas que se utilizan, entre las 10 primeras tabletas utilizadas, aparece un modelo del iPad siete veces. Así que, si nuestra app va muy enfocada en tabletas, quizás sería buena idea empezar por iOS. <h3>Aplicaciones de gestión empresarial interna</h3> ¿A qué me refiero con esto? Por ejemplo, las aplicaciones que llevan los repartidores de paquetería. Normalmente, cuando llegan a casa y te entregan un paquete, vienen con un dispositivo móvil, escanean el código de barras del paquete y te hacen firmar en este dispositivo. Pues bien, esa es una aplicación que utiliza la empresa para su gestión interna. Son aplicaciones privadas no disponibles al público, que simplemente se utilizan a nivel interno para gestionar. En este caso, pensemos lo siguiente: imagina que eres el dueño de una empresa de paquetería / correos, y quieres implementar una aplicación para acelerar todo el proceso de entrega, de gestión de paquetes, su ubicación, etc. Claro, tienes que encargar una aplicación, pero, también vas a tener que comprar dispositivos. Imagina que tienes 100 trabajadores y vas a necesitar 100 dispositivos, ¿Qué harías?, ¿Comprar 100 iPhone de 800 euros y gastarte en total 8000 euros, más los posibles gastos de reparación o perdida? O, ¿comprar 100 Android de 100 euros, que en total te saldría en 1000 euros? Aquí, la diferencia es bastante abismal. Si nos fijamos, es muy raro que una empresa de gestión interna utilice iPhone; que venga un repartidor te gestione ese pedido, haga el escaneo de código de barras y te haga firmar en un iPhone. Lo más normal es que tenga un Android u otro sistema. Aquí, el hecho de tener muchos fabricantes y dispositivos distintos y muchos rangos de precios, es claramente un punto diferencial. Así que, si quieres hacer una aplicación de gestión interna, sin duda yo elegiría Android. The post <a href="https://diegolaballos.com/podcast/18-android-o-ios-que-sistema-es-mejor/" rel="nofollow" target="_blank">18. ¿Android o iOS? ¿Qué sistema es mejor?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

18. ¿Android o iOS? ¿Qué sistema es mejor?

Ser freelance, es lo que se conoce en España como ser autónomo. Podríamos decir que el término freelance es más usado a nivel internacional y ¿por qué no? queda más cool. Se trata de buscarte tus propios clientes.  Si trabajar para una empresa sería como trabajar para un único cliente, trabajar como freelance significa trabajar para varios clientes, trabajar por proyectos generalmente. Básicamente, se trata de ser tu propia empresa. Tú tienes que buscar tus clientes, realizar tus proyectos, gestionarlos y cobrar por ellos. Entonces, ¿Qué tan fácil es ser freelance y empezar cómo uno? ¿Es difícil ser freelance? Es una pregunta un poco difícil de responder. ¿Es más difícil que trabajar para una empresa? Yo diría que sí, por varios motivos.  Para empezar, tienes que buscarte tus propios clientes. Cuando decides trabajar para una empresa, podríamos decir que esta búsqueda solo la haces una vez, cuando estás realizando la entrevista y te contratan. En ese momento, ya has captado tu único cliente. Siendo freelance, tienes que estar buscando clientes constantemente. También, tienes que convencer al cliente de que puede confiar en ti para realizar un determinado proyecto. En una empresa, generalmente formas parte de un equipo más grande y no hay tanta responsabilidad como cuando eres freelance, aunque a veces, también puedes ser el único responsable. También hay que decir que tienes más competencia como freelance que cuando vas a trabajar para una empresa. ¿Contra cuantos compites en una empresa de trabajo? ¿10, 20? Depende del sector, aunque en programación tampoco hay tantas personas. Como freelance, no vas a competir solo contra los otros freelances (que también hay bastantes) sino, con otras empresas a la vez, como empresas de consultoría por decir un ejemplo.  Hay otros temas que también hacen más complicado el ser freelance que están más alejados de lo puramente técnico. En otras palabras, tienes que saber gestionarte tanto a nivel técnico, como económico.  Debes tener constancia en el trabajo ya que no vas a tener un jefe interno, sino clientes, lo cual puede ser más arriesgado. Un error, quizás no te suponga una bronca con tu jefe, pero quizás si perder un cliente que es aún peor.  Es importante también que sepas venderte y tratar con la gente. Tu eres tu propio departamento de ventas, marketing, contabilidad, desarrollo de proyectos; eres todo. Si nos vamos al tema fiscal en cuanto a empezar como freelance, es un tema completamente aparte; depende de cada país, pero, en general, no es algo por lo que yo me preocuparia mucho, puedes encargar todo esto a un gestor y olvidarte de ello; al menos, es lo que yo hago. Lo realmente importante es todo lo anterior.  En resumen, me parece más difícil empezar como freelance, que conseguir trabajo en una empresa. ¿Dónde conseguir clientes? Ahora vamos a lo realmente interesante, ¿dónde darte a conocer? Ya te adelanto que, con crearte una web con tu nombre, no va a servir de nada por sí sola. Aquí empezamos con el fascinante mundo del marketing o de darte a conocer para que la gente te pueda contratar. Plataformas de freelancers Una de las formas más sencillas para empezar, son las plataformas de freelancers que ya he mencionado aquí más de una vez. Siempre las he comentado como un lugar donde encontrar programadores para que trabajen en tus proyectos. Pero, al igual que los puedes contratar, también puedes formar parte de ellos. Puedes apuntarte totalmente gratis en la gran mayoría de estas plataformas. Básicamente, te van a pedir rellenar tus datos básicos, indicar tu precio-hora, subir tu portfolio y hablar de tu experiencia. Lo último que resta, es apuntarte a las ofertas que hay. La verdad es que estas plataformas darían para un capítulo entero, ya que tienen cosas buenas y malas. De forma muy rápida y por encima, por cosas buenas tenemos que accedes a muchos clientes rápidamente y existe una gran facilidad para comunicarse pues estas plataformas tienen herramientas que te facilitan estas cosas.  Como cosas malas, hay mucha competencia, es difícil diferenciarte por que todos los perfiles son iguales (una foto, una descripción, algunos proyectos y opiniones). Asimismo, hay muchos proyectos low-cost y, para conseguir buenos proyectos tienes que acumular mucha experiencia y muchas buenas opiniones, lo cual es difícil en un inicio. Además, es importante decir que estas plataformas viven de algo y a veces se llevan una no tan pequeña comisión de todos los proyectos que haces a través de ellas.  Como digo, da para un capítulo entero, pero, en resumen y en mi opinión, estas plataformas están bastante bien para empezar. De hecho, en su día, yo empecé en alguna de ellas (ahora bien, más adelante te van a interesar otras cosas que comentaremos a continuación: crearte tu propia marca). Hay otra posibilidad de coger estas plataformas y utilizarlas para algo a largo plazo. Si consigues tener un buen perfil y buenas opiniones a lo largo del tiempo, puede ser una gran fuente de clientes. Es decir, cuando busquen en el listado de freelance y si tú tienes muchas y buenas opiniones, podrías captar muchos clientes. En mi opinión, no es una situación ideal; hay mejores formas de captar clientes, pero es una opción. Algunas de estas plataformas, que ya he dicho antes, son www.freelancer.com, www.upwork.com y www.peopleperhour.com. Crear tu propia página web Dejando de lado las plataformas, esta es otra opción para crear tu marca personal. Anteriormente decía que una web por si sola no va a atraer clientes si no haces nada más, pero es algo básico que tienes que tener. Si te dedicas al mundo de la programación, tienes que tener una web forzosamente. Una web que diga que indique qué has hecho, quién eres y una forma de contactar contigo. Por si sola no hará nada, pero tiene que ser en un lugar en donde las acciones que veremos a continuación tienen que ir a parar; en donde puedan contactar contigo. Creación de contenido Ésta es la parte más interesante. La creación de contenido, es posiblemente la mejor forma de darte a conocer y captar gente. Crear contenido de valor que sea útil para otras personas y que te permita darte a conocer. ¿De qué formas? Pues tienen que ser medios: blogs, podcast, YouTube, etc. En mi caso personal, tengo un blog donde escribo cuando puedo y, sin ir más lejos, este podcast también es contenido de utilidad. Yo ofrezco todo esto gratis, intento ofrecer la máxima cantidad de información posible desde lo que yo humildemente sé y, gracias a esto, la gente me conoce. Evidentemente, tienes que crear contenido acorde con lo que haces. Por ejemplo, si yo hiciera un podcast de como cultivar hortalizas estaría interesante, pero no sería beneficioso para mí como freelance. Además, la información no sería muy buena ya que no tengo mucha idea de ello. Así que una buena forma de que te conozcan y captes clientes, es crear contenido acorde con lo que haces y demostrar lo que sabes. La creación de contenido es una de las mejores formas de publicitarte. AdWords Sin embargo, tiene un gran punto débil: no es la forma más rápida de conseguir clientes y  seguramente, eso es lo que vas a querer en un inicio. Esto, nos lleva a la cuestión de las plataformas de AdWords. Si quieres algo bueno y rápido, te va a costar dinero y, para ello, tenemos herramientas como ésta. Por sí misma, merece un capítulo entero, pero, vamos a verlo muy por encima. Básicamente, es una de las herramientas de publicidad de Google (la principal diría yo).  Imagínate que quieres dedicarte al desarrollo web. Tienes la posibilidad desde el primer día, de pagar por salir en las primeras posiciones cuando alguien busca “desarrollador web freelance”.  Estos son los 2-3 primeros resultados que aparecen en Google, normalmente destacados, son publicidad y normalmente la gente paga por estar ahí. Pagas, cuando alguien da click en tu anuncio y que se supone los lleva a tu web. Es una forma muy rápida para llegar a gente interesada en contratarte rápidamente y desde el primer día. A cambio, pagarás por cada click.  El precio depende mucho. Está en función del sector, de la palabra por la cual compitas ya que el precio va en relación con la cantidad de gente que hay por esa misma palabra.  Para darte una idea general del precio que pagarías por una palabra clave relacionada con el sector de “programadores freelance”, cada click costaría entre 1 euro y 3 euros. Boca a boca Ésta es la última fuente para conseguir clientes. Es posiblemente la más sencilla, aunque también difícil de conseguir. Es una de las mejores fuentes por la confianza que genera. SI alguien que tu conoces, te recomienda a una persona, ya vas plenamente confiado a trabajar con ella. No obstante, tiene la gran desventaja de que es lenta. Antes, tendrías que haber trabajado para otros clientes y, evidentemente, haberlo hecho bien. No es algo que tengas que buscar, pues simplemente pasa. Si eres bueno y profesional, te pasará sin que tú tengas que intervenir. Es una forma sencilla de captar clientes, pero a la vez complicada. Sin duda, la parte más difícil de ser freelance, es empezar y encontrar los primeros clientes. Una vez los hayas conseguido y, siempre y cuando seas profesional y hayas hecho los proyectos bien, todo va a ser mucho más fácil. Así que, ahora que hemos visto estos dos enfoques: trabajo como programador y cómo empezar de freelance, puede ser interesante compararlos ¿Qué tiene de bueno cada uno de estos?, ¿Cuál elegir?, ¿Cuál es mejor? Es un tema que da mucho de sí, por lo que ya tenemos capítulo para el miércoles siguiente.  Si quieres ser un programador freelance, tienes que tener en cuenta que inicialmente va a ser más difícil conseguir clientes que buscar empleo en una empresa. Ser freelance, se trata de ser tu propio departamento de “todo”: ventas, marketing, desarrollo, contabilidad e incluso recursos humanos si quieres tener colaboradores. Para empezar a buscar clientes, puedes recurrir a portales de freelance, hacerte tu propia web, crear contenido de calidad (podcast, YouTube, blogs), recurrir a plataformas de publicidad como AdWords y finalmente, recurrir al boca a boca que, si lo haces bien, llegará. The post 28. ¿Cómo empezar de freelance en programación? appeared first on Diego Laballós.

Ser freelance, es lo que se conoce en España como ser autónomo. Podríamos decir que el término freelance es más usado a nivel internacional y ¿por qué no? queda más cool. Se trata de buscarte tus propios clientes. Si trabajar para una empresa sería como trabajar para un único cliente, trabajar como freelance significa trabajar para varios clientes, trabajar por proyectos generalmente. Básicamente, se trata de ser tu propia empresa. Tú tienes que buscar tus clientes, realizar tus proyectos, gestionarlos y cobrar por ellos. Entonces, ¿Qué tan fácil es ser freelance y empezar cómo uno? <h3>¿Es difícil ser freelance?</h3> Es una pregunta un poco difícil de responder. ¿Es más difícil que trabajar para una empresa? Yo diría que sí, por varios motivos. Para empezar, tienes que buscarte tus propios clientes. Cuando decides trabajar para una empresa, podríamos decir que esta búsqueda solo la haces una vez, cuando estás realizando la entrevista y te contratan. En ese momento, ya has captado tu único cliente. Siendo freelance, tienes que estar buscando clientes constantemente. También, tienes que convencer al cliente de que puede confiar en ti para realizar un determinado proyecto. En una empresa, generalmente formas parte de un equipo más grande y no hay tanta responsabilidad como cuando eres freelance, aunque a veces, también puedes ser el único responsable. También hay que decir que tienes más competencia como freelance que cuando vas a trabajar para una empresa. ¿Contra cuantos compites en una empresa de trabajo? ¿10, 20? Depende del sector, aunque en programación tampoco hay tantas personas. Como freelance, no vas a competir solo contra los otros freelances (que también hay bastantes) sino, con otras empresas a la vez, como empresas de consultoría por decir un ejemplo. Hay otros temas que también hacen más complicado el ser freelance que están más alejados de lo puramente técnico. En otras palabras, tienes que saber gestionarte tanto a nivel técnico, como económico. Debes tener constancia en el trabajo ya que no vas a tener un jefe interno, sino clientes, lo cual puede ser más arriesgado. Un error, quizás no te suponga una bronca con tu jefe, pero quizás si perder un cliente que es aún peor. Es importante también que sepas venderte y tratar con la gente. Tu eres tu propio departamento de ventas, marketing, contabilidad, desarrollo de proyectos; eres todo. Si nos vamos al tema fiscal en cuanto a empezar como freelance, es un tema completamente aparte; depende de cada país, pero, en general, no es algo por lo que yo me preocuparia mucho, puedes encargar todo esto a un gestor y olvidarte de ello; al menos, es lo que yo hago. Lo realmente importante es todo lo anterior. En resumen, me parece más difícil empezar como freelance, que conseguir trabajo en una empresa. <h3>¿Dónde conseguir clientes?</h3> Ahora vamos a lo realmente interesante, ¿dónde darte a conocer? Ya te adelanto que, con crearte una web con tu nombre, no va a servir de nada por sí sola. Aquí empezamos con el fascinante mundo del marketing o de darte a conocer para que la gente te pueda contratar. <h3>Plataformas de freelancers</h3> Una de las formas más sencillas para empezar, son las plataformas de freelancers que ya he mencionado aquí más de una vez. Siempre las he comentado como un lugar donde encontrar programadores para que trabajen en tus proyectos. Pero, al igual que los puedes contratar, también puedes formar parte de ellos. Puedes apuntarte totalmente gratis en la gran mayoría de estas plataformas. Básicamente, te van a pedir rellenar tus datos básicos, indicar tu precio-hora, subir tu portfolio y hablar de tu experiencia. Lo último que resta, es apuntarte a las ofertas que hay. La verdad es que estas plataformas darían para un capítulo entero, ya que tienen cosas buenas y malas. De forma muy rápida y por encima, por cosas buenas tenemos que accedes a muchos clientes rápidamente y existe una gran facilidad para comunicarse pues estas plataformas tienen herramientas que te facilitan estas cosas. Como cosas malas, hay mucha competencia, es difícil diferenciarte por que todos los perfiles son iguales (una foto, una descripción, algunos proyectos y opiniones). Asimismo, hay muchos proyectos low-cost y, para conseguir buenos proyectos tienes que acumular mucha experiencia y muchas buenas opiniones, lo cual es difícil en un inicio. Además, es importante decir que estas plataformas viven de algo y a veces se llevan una no tan pequeña comisión de todos los proyectos que haces a través de ellas. Como digo, da para un capítulo entero, pero, en resumen y en mi opinión, estas plataformas están bastante bien para empezar. De hecho, en su día, yo empecé en alguna de ellas (ahora bien, más adelante te van a interesar otras cosas que comentaremos a continuación: crearte tu propia marca). Hay otra posibilidad de coger estas plataformas y utilizarlas para algo a largo plazo. Si consigues tener un buen perfil y buenas opiniones a lo largo del tiempo, puede ser una gran fuente de clientes. Es decir, cuando busquen en el listado de freelance y si tú tienes muchas y buenas opiniones, podrías captar muchos clientes. En mi opinión, no es una situación ideal; hay mejores formas de captar clientes, pero es una opción. Algunas de estas plataformas, que ya he dicho antes, son <a href="http://www.freelancer.com" rel="nofollow" target="_blank">www.freelancer.com</a>, <a href="http://www.upwork.com" rel="nofollow" target="_blank">www.upwork.com</a> y <a href="http://www.peopleperhour.com" rel="nofollow" target="_blank">www.peopleperhour.com</a>. <h3>Crear tu propia página web</h3> Dejando de lado las plataformas, esta es otra opción para crear tu marca personal. Anteriormente decía que una web por si sola no va a atraer clientes si no haces nada más, pero es algo básico que tienes que tener. Si te dedicas al mundo de la programación, tienes que tener una web forzosamente. Una web que diga que indique qué has hecho, quién eres y una forma de contactar contigo. Por si sola no hará nada, pero tiene que ser en un lugar en donde las acciones que veremos a continuación tienen que ir a parar; en donde puedan contactar contigo. <h3>Creación de contenido</h3> Ésta es la parte más interesante. La creación de contenido, es posiblemente la mejor forma de darte a conocer y captar gente. Crear contenido de valor que sea útil para otras personas y que te permita darte a conocer. ¿De qué formas? Pues tienen que ser medios: blogs, podcast, YouTube, etc. En mi caso personal, tengo un blog donde escribo cuando puedo y, sin ir más lejos, este podcast también es contenido de utilidad. Yo ofrezco todo esto gratis, intento ofrecer la máxima cantidad de información posible desde lo que yo humildemente sé y, gracias a esto, la gente me conoce. Evidentemente, tienes que crear contenido acorde con lo que haces. Por ejemplo, si yo hiciera un podcast de como cultivar hortalizas estaría interesante, pero no sería beneficioso para mí como freelance. Además, la información no sería muy buena ya que no tengo mucha idea de ello. Así que una buena forma de que te conozcan y captes clientes, es crear contenido acorde con lo que haces y demostrar lo que sabes. La creación de contenido es una de las mejores formas de publicitarte. <h3>AdWords</h3> Sin embargo, tiene un gran punto débil: no es la forma más rápida de conseguir clientes y seguramente, eso es lo que vas a querer en un inicio. Esto, nos lleva a la cuestión de las plataformas de AdWords. Si quieres algo bueno y rápido, te va a costar dinero y, para ello, tenemos herramientas como ésta. Por sí misma, merece un capítulo entero, pero, vamos a verlo muy por encima. Básicamente, es una de las herramientas de publicidad de Google (la principal diría yo). Imagínate que quieres dedicarte al desarrollo web. Tienes la posibilidad desde el primer día, de pagar por salir en las primeras posiciones cuando alguien busca “desarrollador web freelance”. Estos son los 2-3 primeros resultados que aparecen en Google, normalmente destacados, son publicidad y normalmente la gente paga por estar ahí. Pagas, cuando alguien da click en tu anuncio y que se supone los lleva a tu web. Es una forma muy rápida para llegar a gente interesada en contratarte rápidamente y desde el primer día. A cambio, pagarás por cada click. El precio depende mucho. Está en función del sector, de la palabra por la cual compitas ya que el precio va en relación con la cantidad de gente que hay por esa misma palabra. Para darte una idea general del precio que pagarías por una palabra clave relacionada con el sector de “programadores freelance”, cada click costaría entre 1 euro y 3 euros. <h3>Boca a boca</h3> Ésta es la última fuente para conseguir clientes. Es posiblemente la más sencilla, aunque también difícil de conseguir. Es una de las mejores fuentes por la confianza que genera. SI alguien que tu conoces, te recomienda a una persona, ya vas plenamente confiado a trabajar con ella. No obstante, tiene la gran desventaja de que es lenta. Antes, tendrías que haber trabajado para otros clientes y, evidentemente, haberlo hecho bien. No es algo que tengas que buscar, pues simplemente pasa. Si eres bueno y profesional, te pasará sin que tú tengas que intervenir. Es una forma sencilla de captar clientes, pero a la vez complicada. Sin duda, la parte más difícil de ser freelance, es empezar y encontrar los primeros clientes. Una vez los hayas conseguido y, siempre y cuando seas profesional y hayas hecho los proyectos bien, todo va a ser mucho más fácil. Así que, ahora que hemos visto estos dos enfoques: trabajo como programador y cómo empezar de freelance, puede ser interesante compararlos ¿Qué tiene de bueno cada uno de estos?, ¿Cuál elegir?, ¿Cuál es mejor? Es un tema que da mucho de sí, por lo que ya tenemos capítulo para el miércoles siguiente. Si quieres ser un programador freelance, tienes que tener en cuenta que inicialmente va a ser más difícil conseguir clientes que buscar empleo en una empresa. Ser freelance, se trata de ser tu propio departamento de “todo”: ventas, marketing, desarrollo, contabilidad e incluso recursos humanos si quieres tener colaboradores. Para empezar a buscar clientes, puedes recurrir a portales de freelance, hacerte tu propia web, crear contenido de calidad (podcast, YouTube, blogs), recurrir a plataformas de publicidad como AdWords y finalmente, recurrir al boca a boca que, si lo haces bien, llegará. The post <a href="https://diegolaballos.com/podcast/28-como-empezar-de-freelance-en-programacion/" rel="nofollow" target="_blank">28. ¿Cómo empezar de freelance en programación?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

28. ¿Cómo empezar de freelance en programación?

Lo primero que hay que decir, es que encontrar trabajo es complicado. Al fin y al cabo, encontrar un trabajo, es un trabajo en sí mismo. El hacer el currículum, enviarlo; o el ir a entrevistas implican tiempo y al final, no deja de ser un trabajo en sí mismo. Todo esto se complica más cuando no tienes experiencia laboral, cuando tienes que encontrar el primer trabajo, cuando empiezas a apuntarte a ofertas y ves que piden carrera, muchísimas tecnologías (en el caso de la programación) y años de experiencia. La buena noticia es que en el ámbito de la programación, la tasa de paro es casi de 0. Dejaré un par de artículos interesantes en la descripción del episodio. Por ejemplo, uno de El Confidencial titulado “España necesita medio millón de expertos en informática, más de los que puede aportar” y, otro de El País, con título “Los informáticos no entienden el paro”. Aunque con una simple búsqueda en Google obtendréis resultados similares y podréis encontrar información de este tipo. Además de estos artículos, lo sé por experiencia propia de gente que conozco: si quieres trabajar para una empresa de programador, no te van a faltar lugares donde trabajar. Claro que quizás el primer trabajo sea el más complicado de encontrar y básicamente es lo que vamos a contar aquí.  Este capítulo, lo vamos a dividir desde tres perspectivas distintas: La primera es si vas a estudiar programación a través de un curso o prácticas en empresas. La segunda situación es si vas a estudiar por tu cuenta o en algún lugar donde no tengas esta oportunidad de hacer prácticas en empresas. Por último, vamos a ver que pasa una vez que ya tienes el primer trabajo y que tan difícil es seguir progresando en la programación. Estudiar programación en un curso que conlleve prácticas Aquí puede ser FP, universidad o algún curso que las ofrezca. Simplemente, si tienes la oportunidad de hacer prácticas, hazlas. Quizás no serán el mejor trabajo que tengas en tu vida. De hecho, fueron una m****. Seguramente, al terminarlas, no seguirás en ese puesto, pero esto ya depende. No obstante, tanto si te quedas como si no, te van a servir bastante para aprender y para ver como es el mundo de la programación en un entorno real y no de ejercicios de un curso. Además, cogerás experiencia para tu currículo y dejará de estar ese apartado en blanco. Con suerte, si te quedas en el puesto, tendrás tu primer trabajo. Así que, en el caso que tengas esta oportunidad de hacer prácticas en empresas, hazlas. Si tienes la suerte de quedarte, tendrás trabajo; y en el caso de que no, tendrás experiencia que te valdrá para conseguir tu primer trabajo. Autoaprendizaje y cursos que no contemplen prácticas En este caso, si estás aprendiendo por tu cuenta, estás haciendo un curso que no tiene estas prácticas, o incluso si ya concluiste tus prácticas donde no te han cogido por cualquier motivo; una cosa buena que tiene la programación es que no necesitas absolutamente a nadie para demostrar lo que sabes.  Me explico: en la programación tú puedes crear algo de la nada, con un presupuesto 0 (o casi 0, en el caso de que pagues por el uso de un servido, por licencias de tiendas de aplicaciones móviles, etc) Lo que quiero decir es que, la clave está en los proyectos propios, así que, para demostrar lo que realmente sabes, crea tus propios proyectos. Crea y publica tus propios proyectos ¿Qué quieres buscar un trabajo como programador de apps? Pues crea un par de apps, aunque sean simples y publícalas, haz que sean visibles; si quieres ser desarrollador web, crea un par de webs y publícalas.  Al fin y al cabo, se trata de demostrar lo que sabes hacer. Aunque no tengas experiencia laboral en un puesto en una empresa, puedes hacerlo de esta manera.  Ponte en el lugar de alguien que está revisando currículos. Revisa decenas o hasta cientos de ellos; todos iguales: un papel con estudios, experiencia, etc. Lo que quiere ver es algo distinto, tienes que destacar y llamar la atención.  Imaginemos que para un puesto de desarrollo de apps ya sea para Android o iOS, hay una persona que está revisando currículos.  Tiene tres de ellos: uno de alguien sin experiencia, con únicamente un tipo formación; otro con experiencia de 2 años en una empresa, pero con ningún proyecto público y la misma formación que el anterior; finalmente, tiene otro de una persona sin experiencia laboral, con la misma formación que los otros dos, pero tres aplicaciones publicadas en Google Play y App Store, que se pueden ver y probar. En este caso, a mí, me llamaría más la atención y seleccionaría al tercero, siempre y cuando los proyectos fueran interesantes, estuvieran bien desarrollados y fueran acordes con el puesto. Lo que quiero decir es que, con proyectos propios, puedes incluso llamar más la atención que con una experiencia en una empresa. Así que, aquí no hay excusas. Si no tienes experiencia laboral, fabrícatela tu mismo. La clave es suplir esta falta de experiencia laboral con proyectos propios. Compartir tu código en GitHub Otro punto importante aquí, es el hecho de mostrar tu código. Esto es interesante para la persona que va a revisar tu currículum o te va a entrevistar desde un punto de vista técnico.  Aquí, la herramienta más utilizada para compartir tu código es GitHub. Este en su sitio donde, podríamos decir que se guarda el código, es una red social de programadores donde se comparte código. Se utiliza realmente para muchas cosas, pero lo interesante aquí, es que nosotros podemos publicar el código de nuestros proyectos para que una persona de perfil técnico pueda consultarlo y verlo. Además, es totalmente gratis hacer esto; os podéis dar de alta y subir ahí todo el código que queráis. Dónde encontrar ofertas de trabajo A partir de aquí, para acceder a todas las ofertas, los canales que tenemos son los que hay para cualquier puesto de trabajo: LinkedIn, InfoJobs, o incluso aún mejor, contactar directamente con la empresa.  Por ejemplo, si ves una oferta en InfoJobs de una empresa, prueba a intentar ponerte en contacto directo y que se note que te interesa más por esa oferta. Otra opción también, son las webs personales. Si quieres hacer un currículo distinto, créate una web y coloca todos tus datos ahí, al fin y al cabo, es cuestión de imaginación. Simplemente para tener ideas de como sorprender y destacar frente al resto, deja de pensar en “estoy buscando trabajo y tiro currículos durante 30 minutos en esta web o en aquella” Piensa más en que eres la persona que está seleccionando: ¿Qué te llamaría la atención y que te llevaría a decidir por alguien? Es fácil, ponte en el lugar de esa persona y se te van a ocurrir miles de ideas para sorprender y destacar sobre el resto. Qué ocurre cuando ya tienes experiencia Finalmente, una vez que tengas experiencia, ¿Qué pasa cuando tienes ya tu trabajo y quieres seguir progresando o cambiar de trabajo?  Aquí, básicamente lo que hay que decir es que cambiar de trabajo en programación, es bastante fácil. Hay muchos puestos y no hay bastante gente para cubrirlos como comentaban los artículos del principio. Simplemente, a través de los medios que comentaba antes (LinkedIn, InfoJobs, etc.) o contactar directamente con la empresa, puedes cambiar de trabajo y seguir progresando. La idea obviamente no es cambiar de trabajo porque sí, sino ir escalando hacia trabajos mejores. A medida que vayas escalando, también irás subiendo el nivel. Depende de hacia dónde quieras llegar, la cosa se complica más. Hay puestos de programación que están muy bien, donde se tienen responsabilidad y donde se hacen cosas “wise” y donde se cobra muy bien por ello. Ahora bien, tienes que valer para ello. Por decirlo de alguna manera, un puesto de nivel medio en programación, es muy fácil conseguir. En cuanto a un nivel alto, la cosa se complica un poco más. Pero, si tienes ganas y le pones empeño, puedes llegar a ello. Básicamente, estos son los consejos que yo daría a alguien que quiere buscar su primer trabajo como programador. Por lo que solo una de las ideas que he expuesto te sirva o te hayan dejado con ella, me doy por satisfecho. Así que, en resumen, si estudias a través de un curso que hagan algún tipo de prácticas, hazlas. La experiencia puede ser mejor o peor, pero siempre te van a aportar algo. En el caso de que no tengas esta posibilidad, o si las prácticas no te han servido para conseguir el primer trabajo, crea tus propios proyectos. Dicen que una imagen vale más que mil palabras. Pues en mi opinión, en los currículos, un proyecto vale más que mil experiencias… bueno, mil quizás no, pero dos, sí.  Una vez que tengas tu trabajo, no te costará ir progresando al principio. Ahora bien, una vez quieras acceder a puestos más altos, la cosa se irá complicando, pero también tiene su gracia porque de otra forma, sería muy aburrido. The post 27. ¿Cómo encontrar trabajo de programador? appeared first on Diego Laballós.

Lo primero que hay que decir, es que encontrar trabajo es complicado. Al fin y al cabo, encontrar un trabajo, es un trabajo en sí mismo. El hacer el currículum, enviarlo; o el ir a entrevistas implican tiempo y al final, no deja de ser un trabajo en sí mismo. Todo esto se complica más cuando no tienes experiencia laboral, cuando tienes que encontrar el primer trabajo, cuando empiezas a apuntarte a ofertas y ves que piden carrera, muchísimas tecnologías (en el caso de la programación) y años de experiencia. La buena noticia es que en el ámbito de la programación, la tasa de paro es casi de 0. Dejaré un par de artículos interesantes en la descripción del episodio. Por ejemplo, uno de El Confidencial titulado “España necesita medio millón de expertos en informática, más de los que puede aportar” y, otro de El País, con título “Los informáticos no entienden el paro”. Aunque con una simple búsqueda en Google obtendréis resultados similares y podréis encontrar información de este tipo. Además de estos artículos, lo sé por experiencia propia de gente que conozco: si quieres trabajar para una empresa de programador, no te van a faltar lugares donde trabajar. Claro que quizás el primer trabajo sea el más complicado de encontrar y básicamente es lo que vamos a contar aquí. Este capítulo, lo vamos a dividir desde tres perspectivas distintas: La primera es si vas a estudiar programación a través de un curso o prácticas en empresas. La segunda situación es si vas a estudiar por tu cuenta o en algún lugar donde no tengas esta oportunidad de hacer prácticas en empresas. Por último, vamos a ver que pasa una vez que ya tienes el primer trabajo y que tan difícil es seguir progresando en la programación. <h3>Estudiar programación en un curso que conlleve prácticas</h3> Aquí puede ser FP, universidad o algún curso que las ofrezca. Simplemente, si tienes la oportunidad de hacer prácticas, hazlas. Quizás no serán el mejor trabajo que tengas en tu vida. De hecho, fueron una m****. Seguramente, al terminarlas, no seguirás en ese puesto, pero esto ya depende. No obstante, tanto si te quedas como si no, te van a servir bastante para aprender y para ver como es el mundo de la programación en un entorno real y no de ejercicios de un curso. Además, cogerás experiencia para tu currículo y dejará de estar ese apartado en blanco. Con suerte, si te quedas en el puesto, tendrás tu primer trabajo. Así que, en el caso que tengas esta oportunidad de hacer prácticas en empresas, hazlas. Si tienes la suerte de quedarte, tendrás trabajo; y en el caso de que no, tendrás experiencia que te valdrá para conseguir tu primer trabajo. <h3>Autoaprendizaje y cursos que no contemplen prácticas</h3> En este caso, si estás aprendiendo por tu cuenta, estás haciendo un curso que no tiene estas prácticas, o incluso si ya concluiste tus prácticas donde no te han cogido por cualquier motivo; una cosa buena que tiene la programación es que no necesitas absolutamente a nadie para demostrar lo que sabes. Me explico: en la programación tú puedes crear algo de la nada, con un presupuesto 0 (o casi 0, en el caso de que pagues por el uso de un servido, por licencias de tiendas de aplicaciones móviles, etc) Lo que quiero decir es que, la clave está en los proyectos propios, así que, para demostrar lo que realmente sabes, crea tus propios proyectos. <h3>Crea y publica tus propios proyectos</h3> ¿Qué quieres buscar un trabajo como programador de apps? Pues crea un par de apps, aunque sean simples y publícalas, haz que sean visibles; si quieres ser desarrollador web, crea un par de webs y publícalas. Al fin y al cabo, se trata de demostrar lo que sabes hacer. Aunque no tengas experiencia laboral en un puesto en una empresa, puedes hacerlo de esta manera. Ponte en el lugar de alguien que está revisando currículos. Revisa decenas o hasta cientos de ellos; todos iguales: un papel con estudios, experiencia, etc. Lo que quiere ver es algo distinto, tienes que destacar y llamar la atención. Imaginemos que para un puesto de desarrollo de apps ya sea para Android o iOS, hay una persona que está revisando currículos. Tiene tres de ellos: uno de alguien sin experiencia, con únicamente un tipo formación; otro con experiencia de 2 años en una empresa, pero con ningún proyecto público y la misma formación que el anterior; finalmente, tiene otro de una persona sin experiencia laboral, con la misma formación que los otros dos, pero tres aplicaciones publicadas en Google Play y App Store, que se pueden ver y probar. En este caso, a mí, me llamaría más la atención y seleccionaría al tercero, siempre y cuando los proyectos fueran interesantes, estuvieran bien desarrollados y fueran acordes con el puesto. Lo que quiero decir es que, con proyectos propios, puedes incluso llamar más la atención que con una experiencia en una empresa. Así que, aquí no hay excusas. Si no tienes experiencia laboral, fabrícatela tu mismo. La clave es suplir esta falta de experiencia laboral con proyectos propios. <h3>Compartir tu código en GitHub</h3> Otro punto importante aquí, es el hecho de mostrar tu código. Esto es interesante para la persona que va a revisar tu currículum o te va a entrevistar desde un punto de vista técnico. Aquí, la herramienta más utilizada para compartir tu código es GitHub. Este en su sitio donde, podríamos decir que se guarda el código, es una red social de programadores donde se comparte código. Se utiliza realmente para muchas cosas, pero lo interesante aquí, es que nosotros podemos publicar el código de nuestros proyectos para que una persona de perfil técnico pueda consultarlo y verlo. Además, es totalmente gratis hacer esto; os podéis dar de alta y subir ahí todo el código que queráis. <h3>Dónde encontrar ofertas de trabajo</h3> A partir de aquí, para acceder a todas las ofertas, los canales que tenemos son los que hay para cualquier puesto de trabajo: LinkedIn, InfoJobs, o incluso aún mejor, contactar directamente con la empresa. Por ejemplo, si ves una oferta en InfoJobs de una empresa, prueba a intentar ponerte en contacto directo y que se note que te interesa más por esa oferta. Otra opción también, son las webs personales. Si quieres hacer un currículo distinto, créate una web y coloca todos tus datos ahí, al fin y al cabo, es cuestión de imaginación. Simplemente para tener ideas de como sorprender y destacar frente al resto, deja de pensar en “estoy buscando trabajo y tiro currículos durante 30 minutos en esta web o en aquella” Piensa más en que eres la persona que está seleccionando: ¿Qué te llamaría la atención y que te llevaría a decidir por alguien? Es fácil, ponte en el lugar de esa persona y se te van a ocurrir miles de ideas para sorprender y destacar sobre el resto. <h3>Qué ocurre cuando ya tienes experiencia</h3> Finalmente, una vez que tengas experiencia, ¿Qué pasa cuando tienes ya tu trabajo y quieres seguir progresando o cambiar de trabajo? Aquí, básicamente lo que hay que decir es que cambiar de trabajo en programación, es bastante fácil. Hay muchos puestos y no hay bastante gente para cubrirlos como comentaban los artículos del principio. Simplemente, a través de los medios que comentaba antes (LinkedIn, InfoJobs, etc.) o contactar directamente con la empresa, puedes cambiar de trabajo y seguir progresando. La idea obviamente no es cambiar de trabajo porque sí, sino ir escalando hacia trabajos mejores. A medida que vayas escalando, también irás subiendo el nivel. Depende de hacia dónde quieras llegar, la cosa se complica más. Hay puestos de programación que están muy bien, donde se tienen responsabilidad y donde se hacen cosas “wise” y donde se cobra muy bien por ello. Ahora bien, tienes que valer para ello. Por decirlo de alguna manera, un puesto de nivel medio en programación, es muy fácil conseguir. En cuanto a un nivel alto, la cosa se complica un poco más. Pero, si tienes ganas y le pones empeño, puedes llegar a ello. Básicamente, estos son los consejos que yo daría a alguien que quiere buscar su primer trabajo como programador. Por lo que solo una de las ideas que he expuesto te sirva o te hayan dejado con ella, me doy por satisfecho. Así que, en resumen, si estudias a través de un curso que hagan algún tipo de prácticas, hazlas. La experiencia puede ser mejor o peor, pero siempre te van a aportar algo. En el caso de que no tengas esta posibilidad, o si las prácticas no te han servido para conseguir el primer trabajo, crea tus propios proyectos. Dicen que una imagen vale más que mil palabras. Pues en mi opinión, en los currículos, un proyecto vale más que mil experiencias… bueno, mil quizás no, pero dos, sí. Una vez que tengas tu trabajo, no te costará ir progresando al principio. Ahora bien, una vez quieras acceder a puestos más altos, la cosa se irá complicando, pero también tiene su gracia porque de otra forma, sería muy aburrido. The post <a href="https://diegolaballos.com/podcast/27-como-encontrar-trabajo-de-programador/" rel="nofollow" target="_blank">27. ¿Cómo encontrar trabajo de programador?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

27. ¿Cómo encontrar trabajo de programador?

Empecemos por mis estudios previos a la programación. Yo hice toda la educación obligatoria aquí en España. Al acabar la ESO, vino mi primera elección: continuar hacia el bachillerato o hacer una FP de grado medio o entrar a trabajar directamente. Como tampoco sabía claramente qué quería hacer ni qué quería estudiar, me decante por hacer el bachillerato que, después te abre más puertas como ir a la universidad o una FP de grado superior. Hasta aquí, todo bien. Complete el bachillerato y llegó la segunda decisión: una vez acabas los dos años del bachillerato, te toca elegir entre ir a la universidad u otras alternativas. Dos cosas que influyeron en mi decisión En este punto, quiero aclarar yo no sabía nada de la programación. Cuando digo nada, es nada; no sabía ni que existía casi. No me llamaba la atención; sabía que había algo, pero tampoco le prestaba mucha atención realmente. Lo que sé me pasaba eran dos cosas. En este punto, ya sabía que me gustaba la informática, pero me interesaba a niveles de usuario en general, como arreglar ordenadores. Me gustaba trastear más allá de usar el internet u Office. Era la típica persona que tenía mil programas instalados como los de rendimiento (que al final lo que hacen, es que el ordenador vaya peor); eso era lo que me gustaba. El otro punto que me influyó bastante en esta decisión, es que estaba muy cansado de estudiar cosas que veía, en cierta manera, poco útiles. Volvemos a lo que dije en el capítulo anterior: casi cualquier cosa que aprendas, nunca va a estar de más (el saber no ocupa lugar), pero llega un momento en que toca ser más práctico y empezar a estudiar cosas que realmente te vayan a servir para tu futuro profesional. Descarté la universidad y decanté por la formación profesional de grado superior Pues bien, con estas dos cosas en mente, descarté la universidad. ¿Por qué? Porque, para empezar, mirando el temario de la carrera de informática, realmente no me llamaba para nada la atención; miraba los primeros cursos y veía “matemáticas”, “física” y no sé qué… no había nada que yo dijera “Esto me suena». Me tenía que ir a cursos de tercer o cuarto año para realmente empezar a ver palabras que me sonaban. Eso me echaba mucho para atrás. Asimismo, el hecho de tener que estudiar 4 años más, hasta poder trabajar en lo que me gustara, tampoco era algo que me apasionara mucho, la verdad. Quería hacer algo más “útil”, podríamos decir; quería empezar a trabajar cuanto antes. Por último, mirando la formación de grado profesional superior, que ya conté en el capítulo anterior, me llamó mucho la atención. Esto, porque en el temario, a diferencia de la universidad, venían cosas que, sí que me “sonaban”, que podía ver que eran útiles. Al año siguiente, ya empezaría a ver cosas que veía “útiles”. Además, eran solo 2 años, no los 4 de la universidad, y muy prácticos. De hecho, en el segundo año, ya haces prácticas en una empresa, lo cual motiva bastante. Por este motivo, me decanté por la formación profesional de grado superior. Reitero, sin saber nada de programación; lo hice simplemente por el interés en la informática en general. Y, ¿Qué pasó durante este curso? Entre las típicas asignaturas como “sistemas operativos”, “redes” y otras parecidas en el ámbito de la informática en general, había otra llamada “introducción a la programación” (creo que era algo así, ahora no recuerdo). Pues bien, en esta asignatura, descubrí lo que era, y vi lo mucho que me gustaba; mucho más que temas como la “administración de sistemas” o “redes”. Así que, a medida que iba las asignaturas de programación del curso, me interesé por ampliar mucho más los conocimientos de programación, comprándome libros y mirando otros cursos por internet. En el segundo año, había una asignatura sobre programación en Android y después de haber estado haciendo otro tipo de programación como aquella para aplicaciones de escritorio para Windows, o programación web (la cual trabajé durante las prácticas del curso), vi que Android era lo que más me llamaba la atención. Así que, al acabar el curso, tenía un conocimiento bastante general de lo que era la programación, lo que había, y lo que se podía hacer. Esto es lo que dije en el capítulo anterior: la formación de grado superior, no te va volver un crack ni a hacer saber absolutamente todo de la programación, ni mucho menos. Pero, lo que sí te va a dar, es esta visión general, este conocimiento básico. Así mismo, te va a dar esta base para que puedas volar tu solo e ir hacia donde quieres, sabiendo que vas a tener que aprender muchísimo más. Y, ¿Qué pasó al acabar el curso? Durante esos dos años que duró el curso, sobre todo a partir del último, me había dedicado con un amigo, a hacer pequeñas aplicaciones de entretenimiento en Android, incluso algunos juegos. Lo que hacíamos era colocar publicidad a través de una plataforma llamada Admob, subíamos esas aplicaciones a Google Play y ganábamos algo de dinero a través de estos ingresos publicitarios. Resultó que, lo que empezó siendo un hobby, se acabó convirtiendo en una pequeña empresa de dos amigos. Simplemente nos dedicábamos a hacer aplicaciones y juegos que nos apetecían. Colocábamos publicidad y la subíamos. Todo esto fue por tres años, hasta que al final empecé como freelance, que es como estoy ahora. Ser autodidacta es esencial Durante todos estos años, no he parado de formarme tanto en Android como en otras tecnologías que ido necesitando para distintos proyectos. Como digo, es un camino sin fin. Cada día tienes que ir aprendiendo algo nuevo a medida que lo necesitas, pero, la formación que necesitas cuando ya tienes este conocimiento base (en mi caso, después de acabar la FP) es mucho más autodidacta: libros, tutoriales, vídeos, cursos en línea, documentación oficial….  Tienes que ser capaz de coger todo ello tú solito y, sin ayuda de nadie, entenderlo y aplicarlo. Después de lo que opiné sobre la universidad, tengo que comentar que también tuve una experiencia en la universidad. El tema, es que empecé al mismo tiempo que empezaba la empresa con mi amigo. Decidí apuntarme en la universidad después de acabar el curso para seguir ampliando conocimientos. Lo que no quería, era lo que ya pensaba antes del curso de la FP: no quería estar 4 años únicamente dedicándome a estudiar la carrera sin hacer nada más. Así que, como había empezado esta empresa, pensé que era una buena manera hacer la carrera en una universidad a distancia a medida que ya estaba trabajando. Problemas de estudiar una carrera: mi opinión Y eso fue lo que hice. Hubo varios problemas. En primer lugar, si quieres hacer una carrera, tienes que dedicarte casi plenamente a ella. No es sencillo sacarte una carrera, y mucho menos una ingeniería. De hecho, valoro mucho a la gente que lo ha hecho porque requiere un gran esfuerzo. Dejando de lado el hecho de que piense si el debate es más o menos útil el temario o de que haya mejores alternativas, yo valoro mucho la carrera. No niego que sea difícil. Mi gran problema es que no tenía tiempo para hacerla. De hecho, estudiaba dos asignaturas al año y a ese ritmo, hubiera tardado unos 20 años en sacarla y, la verdad es que eso me desmotivaba bastante. En segundo lugar, el hecho de estar metido de lleno en el mundo de la programación, poco a poco me hizo ver que realmente me era más útil y productivo, estudiar aquello que necesitara en determinado momento, y no el temario de la asignatura de la universidad que, alguien había colocado ahí y ni me iba ni me venía. En conclusión, duré un año (creo que sí me matricule en el segundo año y no hice nada directamente) y me presenté a dos asignaturas. Una de ellas creo que era “lógica”, que aprobé; y la segunda, que era “programación”, la suspendí… sí, ¡programación!, aunque ya sabía programar, la suspendí. Tengo que decir que lo hice, no por no saber programar; resulta que ni abrí el libro de la asignatura y me presenté al examen un poco de sobrado. Desgraciadamente, me di cuenta que el 80% del examen era de un ejercicio que se había hecho durante el curso; obviamente yo no lo había hecho y no sabía ni de qué hablaban. Eran preguntas del ejercicio en sí, y no tenía idea directamente. El resultado, es que en ese examen saqué un 2 … así que, esa fue mi experiencia en la universidad. Como veis, estaba bastante marcada por el hecho de que yo ya estaba trabajando y que ya sabía programar. No tenía ni el tiempo ni la motivación para hacer la carrera. Dicho esto, y con la perspectiva de ahora, la carrera está bien si no tienes muy claro por dónde quieres ir; si tienes el tiempo, la paciencia, las ganas y obviamente la capacidad para hacerla. En mi opinión, como ya dije, obviamente existen mejores alternativas si sabes que realmente quieres dedicarte a la programación. El 95% de los trabajos de programación, no requieren de una carrera universitaria; y, en caso de que requieran un conocimiento específico que solo se da en la carrera, siempre vas a poder aprenderlo por tu cuenta. Esa es mi conclusión, pero no quiero ni desprestigiar las carreras ni decir que me parezcan fáciles. En el capítulo anterior, pudo parecer que las desprestigiaba un poco pero simplemente quiero decir que quizás no son la mejor alternativa para alguien que tiene muy claro lo que quiere hacer y que tiene el tiempo limitado para hacerlo. ¿Qué hago actualmente? Al día de hoy, sigo formándome. Suelo dedicar una hora diaria de mi tiempo a formación, ya sea leyendo un libro, ver videos o cursos en línea o escuchar podcasts sobre lo que yo utilizo. Además, hay que decir que cuando estás trabajando en programación, estas continuamente aprendiendo y formándote porque siempre hay un proyecto que requiere de algo que no sabes y no has probado; en ese caso tienes que ir, coger, aprenderlo rápido y aplicarlo. The post 17. Mi camino en la programación appeared first on Diego Laballós.

Empecemos por mis estudios previos a la programación. Yo hice toda la educación obligatoria aquí en España. Al acabar la ESO, vino mi primera elección: continuar hacia el bachillerato o hacer una FP de grado medio o entrar a trabajar directamente. Como tampoco sabía claramente qué quería hacer ni qué quería estudiar, me decante por hacer el bachillerato que, después te abre más puertas como ir a la universidad o una FP de grado superior. Hasta aquí, todo bien. Complete el bachillerato y llegó la segunda decisión: una vez acabas los dos años del bachillerato, te toca elegir entre ir a la universidad u otras alternativas. <h3>Dos cosas que influyeron en mi decisión</h3> En este punto, quiero aclarar yo no sabía nada de la programación. Cuando digo nada, es nada; no sabía ni que existía casi. No me llamaba la atención; sabía que había algo, pero tampoco le prestaba mucha atención realmente. Lo que sé me pasaba eran dos cosas. En este punto, ya sabía que me gustaba la informática, pero me interesaba a niveles de usuario en general, como arreglar ordenadores. Me gustaba trastear más allá de usar el internet u Office. Era la típica persona que tenía mil programas instalados como los de rendimiento (que al final lo que hacen, es que el ordenador vaya peor); eso era lo que me gustaba. El otro punto que me influyó bastante en esta decisión, es que estaba muy cansado de estudiar cosas que veía, en cierta manera, poco útiles. Volvemos a lo que dije en el capítulo anterior: casi cualquier cosa que aprendas, nunca va a estar de más (el saber no ocupa lugar), pero llega un momento en que toca ser más práctico y empezar a estudiar cosas que realmente te vayan a servir para tu futuro profesional. <h3>Descarté la universidad y decanté por la formación profesional de grado superior</h3> Pues bien, con estas dos cosas en mente, descarté la universidad. ¿Por qué? Porque, para empezar, mirando el temario de la carrera de informática, realmente no me llamaba para nada la atención; miraba los primeros cursos y veía “matemáticas”, “física” y no sé qué… no había nada que yo dijera “Esto me suena». Me tenía que ir a cursos de tercer o cuarto año para realmente empezar a ver palabras que me sonaban. Eso me echaba mucho para atrás. Asimismo, el hecho de tener que estudiar 4 años más, hasta poder trabajar en lo que me gustara, tampoco era algo que me apasionara mucho, la verdad. Quería hacer algo más “útil”, podríamos decir; quería empezar a trabajar cuanto antes. Por último, mirando la formación de grado profesional superior, que ya conté en el capítulo anterior, me llamó mucho la atención. Esto, porque en el temario, a diferencia de la universidad, venían cosas que, sí que me “sonaban”, que podía ver que eran útiles. Al año siguiente, ya empezaría a ver cosas que veía “útiles”. Además, eran solo 2 años, no los 4 de la universidad, y muy prácticos. De hecho, en el segundo año, ya haces prácticas en una empresa, lo cual motiva bastante. Por este motivo, me decanté por la formación profesional de grado superior. Reitero, sin saber nada de programación; lo hice simplemente por el interés en la informática en general. Y, ¿Qué pasó durante este curso? Entre las típicas asignaturas como “sistemas operativos”, “redes” y otras parecidas en el ámbito de la informática en general, había otra llamada “introducción a la programación” (creo que era algo así, ahora no recuerdo). Pues bien, en esta asignatura, descubrí lo que era, y vi lo mucho que me gustaba; mucho más que temas como la “administración de sistemas” o “redes”. Así que, a medida que iba las asignaturas de programación del curso, me interesé por ampliar mucho más los conocimientos de programación, comprándome libros y mirando otros cursos por internet. En el segundo año, había una asignatura sobre programación en Android y después de haber estado haciendo otro tipo de programación como aquella para aplicaciones de escritorio para Windows, o programación web (la cual trabajé durante las prácticas del curso), vi que Android era lo que más me llamaba la atención. Así que, al acabar el curso, tenía un conocimiento bastante general de lo que era la programación, lo que había, y lo que se podía hacer. Esto es lo que dije en el capítulo anterior: la formación de grado superior, no te va volver un crack ni a hacer saber absolutamente todo de la programación, ni mucho menos. Pero, lo que sí te va a dar, es esta visión general, este conocimiento básico. Así mismo, te va a dar esta base para que puedas volar tu solo e ir hacia donde quieres, sabiendo que vas a tener que aprender muchísimo más. Y, ¿Qué pasó al acabar el curso? Durante esos dos años que duró el curso, sobre todo a partir del último, me había dedicado con un amigo, a hacer pequeñas aplicaciones de entretenimiento en Android, incluso algunos juegos. Lo que hacíamos era colocar publicidad a través de una plataforma llamada Admob, subíamos esas aplicaciones a Google Play y ganábamos algo de dinero a través de estos ingresos publicitarios. Resultó que, lo que empezó siendo un hobby, se acabó convirtiendo en una pequeña empresa de dos amigos. Simplemente nos dedicábamos a hacer aplicaciones y juegos que nos apetecían. Colocábamos publicidad y la subíamos. Todo esto fue por tres años, hasta que al final empecé como freelance, que es como estoy ahora. <h3>Ser autodidacta es esencial</h3> Durante todos estos años, no he parado de formarme tanto en Android como en otras tecnologías que ido necesitando para distintos proyectos. Como digo, es un camino sin fin. Cada día tienes que ir aprendiendo algo nuevo a medida que lo necesitas, pero, la formación que necesitas cuando ya tienes este conocimiento base (en mi caso, después de acabar la FP) es mucho más autodidacta: libros, tutoriales, vídeos, cursos en línea, documentación oficial…. Tienes que ser capaz de coger todo ello tú solito y, sin ayuda de nadie, entenderlo y aplicarlo. Después de lo que opiné sobre la universidad, tengo que comentar que también tuve una experiencia en la universidad. El tema, es que empecé al mismo tiempo que empezaba la empresa con mi amigo. Decidí apuntarme en la universidad después de acabar el curso para seguir ampliando conocimientos. Lo que no quería, era lo que ya pensaba antes del curso de la FP: no quería estar 4 años únicamente dedicándome a estudiar la carrera sin hacer nada más. Así que, como había empezado esta empresa, pensé que era una buena manera hacer la carrera en una universidad a distancia a medida que ya estaba trabajando. <h3>Problemas de estudiar una carrera: mi opinión</h3> Y eso fue lo que hice. Hubo varios problemas. En primer lugar, si quieres hacer una carrera, tienes que dedicarte casi plenamente a ella. No es sencillo sacarte una carrera, y mucho menos una ingeniería. De hecho, valoro mucho a la gente que lo ha hecho porque requiere un gran esfuerzo. Dejando de lado el hecho de que piense si el debate es más o menos útil el temario o de que haya mejores alternativas, yo valoro mucho la carrera. No niego que sea difícil. Mi gran problema es que no tenía tiempo para hacerla. De hecho, estudiaba dos asignaturas al año y a ese ritmo, hubiera tardado unos 20 años en sacarla y, la verdad es que eso me desmotivaba bastante. En segundo lugar, el hecho de estar metido de lleno en el mundo de la programación, poco a poco me hizo ver que realmente me era más útil y productivo, estudiar aquello que necesitara en determinado momento, y no el temario de la asignatura de la universidad que, alguien había colocado ahí y ni me iba ni me venía. En conclusión, duré un año (creo que sí me matricule en el segundo año y no hice nada directamente) y me presenté a dos asignaturas. Una de ellas creo que era “lógica”, que aprobé; y la segunda, que era “programación”, la suspendí… sí, ¡programación!, aunque ya sabía programar, la suspendí. Tengo que decir que lo hice, no por no saber programar; resulta que ni abrí el libro de la asignatura y me presenté al examen un poco de sobrado. Desgraciadamente, me di cuenta que el 80% del examen era de un ejercicio que se había hecho durante el curso; obviamente yo no lo había hecho y no sabía ni de qué hablaban. Eran preguntas del ejercicio en sí, y no tenía idea directamente. El resultado, es que en ese examen saqué un 2 … así que, esa fue mi experiencia en la universidad. Como veis, estaba bastante marcada por el hecho de que yo ya estaba trabajando y que ya sabía programar. No tenía ni el tiempo ni la motivación para hacer la carrera. Dicho esto, y con la perspectiva de ahora, la carrera está bien si no tienes muy claro por dónde quieres ir; si tienes el tiempo, la paciencia, las ganas y obviamente la capacidad para hacerla. En mi opinión, como ya dije, obviamente existen mejores alternativas si sabes que realmente quieres dedicarte a la programación. El 95% de los trabajos de programación, no requieren de una carrera universitaria; y, en caso de que requieran un conocimiento específico que solo se da en la carrera, siempre vas a poder aprenderlo por tu cuenta. Esa es mi conclusión, pero no quiero ni desprestigiar las carreras ni decir que me parezcan fáciles. En el capítulo anterior, pudo parecer que las desprestigiaba un poco pero simplemente quiero decir que quizás no son la mejor alternativa para alguien que tiene muy claro lo que quiere hacer y que tiene el tiempo limitado para hacerlo. <h3>¿Qué hago actualmente?</h3> Al día de hoy, sigo formándome. Suelo dedicar una hora diaria de mi tiempo a formación, ya sea leyendo un libro, ver videos o cursos en línea o escuchar podcasts sobre lo que yo utilizo. Además, hay que decir que cuando estás trabajando en programación, estas continuamente aprendiendo y formándote porque siempre hay un proyecto que requiere de algo que no sabes y no has probado; en ese caso tienes que ir, coger, aprenderlo rápido y aplicarlo. The post <a href="https://diegolaballos.com/podcast/17-mi-camino-en-la-programacion/" rel="nofollow" target="_blank">17. Mi camino en la programación</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

17. Mi camino en la programación

Si me preguntaran qué es lo más difícil de la programación (hasta donde yo sé y he hecho), diría que sin duda, es el comienzo o los primeros pasos. Personalmente, he hecho programación web y de juegos, y actualmente, desde hace ya unos años, hago programación de aplicaciones móviles. Nada de lo que he dicho anteriormente, me ha parecido más difícil que empezar de cero, que aquellos primeros días en que no tenía ni idea de nada. A priori, tú cuando empiezas a estudiar cualquier tema, cosa o concepto -llámale como quieras-, empiezas aprendiendo conceptos fáciles y poco a poco vas subiendo de nivel. Por ejemplo, cuando empiezas con las matemáticas, empiezas a sumar y restar, y es bastante fácil. Luego elevas un poco el nivel y aprendes a multiplicar y dividir; ya se complica un poco más la cosa. Dependiendo de hasta donde llegues, harás integrales, derivadas, etc. A mi parecer, cada nivel que vas subiendo, va complicando más la cosa; es más difícil entender el concepto. Empezar desde 0 en la programación En la programación, también es así. Obviamente no puedes empezar la casa por el tejado, pero lo que quiero decir es que, a mí, y a muchas otras personas que conozco, los primeros pasos en la programación, las primeras “sumas y restas”, (haciendo la analogía con la programación), fueron los más complicados de entender. ¿Por qué digo esto?, ¿Por qué me enrollo tanto con esta noción de que el principio es difícil? Pues la verdad, tendrá mucho más sentido cuando hayáis escuchado todo el capítulo, pero, mi opinión es que hay dos puntos muy distintos en cuanto a aprender programación o algo.  El primero, es empezar completamente desde cero; no sabiendo nada. Ni que es un “if”, una variable, un “bucle”, nada, cero. El segundo punto, es teniendo ya unos conocimientos básicos. A partir de estos dos puntos de partida, hay dos caminos distintos o, por lo menos, dos caminos recomendables. Hablo de caminos para aprender algo nuevo. Obviamente, en este capítulo, nos vamos a situar en el punto uno, empezar de cero. Alguien que no sabe nada, pero nada de programación, aunque también hablaremos del segundo punto para dejar clara esta división. Universidad o formación alternativa Dicho esto, vamos al título del capítulo. “Quiero aprender programación, quiero ser programador” La pregunta principal es: ¿Universidad o formación alternativa? Son los dos caminos que yo dividiría para aprender algo nuevo.  Digamos que la universidad sería el camino de toda la vida y la formación alternativa sería buscar otras opciones.  Dentro de esta última, como veremos, hay muchísimos caminos. ¿Por qué separo universidad de formación alternativa? La universidad, es lo que nos han enseñado desde pequeños que tenemos que hacer: “Estudia la educación obligatoria, el bachillerato, vete a la universidad y buscar un trabajo”. Sin embargo, hoy en día, y sobre todo con la aparición de internet, esto queda, en mi opinión, un poco desfasado. Ojo, estoy hablando de programación, no de otras profesiones. Obviamente, a un médico no le diría que se formara con educación alternativa; principalmente porque no conozco nada del tema, pero yo creo que tampoco es el mejor camino.  Estoy hablando únicamente de la programación, de lo que yo conozco y he estudiado y, por lo tanto, de lo que puedo hablar. ¿Por qué no elegir la universidad para aprender programación? ¿Por qué digo que está un poco desfasado el camino de la universidad? No voy a recurrir al tópico de que muchas mentes brillantes no tienen universidad, como Bill Gates, Steve Job, Mark Zuckerberg, entre otros. No, las universidades tienen la gran desventaja de que tienes temarios muy cerrados y poco cambiantes. Es una formación que tiene que seguir unas pautas y no es tan sencillo cambiar y actualizar el contenido. Otra cosa que tampoco me convence de las carreras, es que, aun siendo vendidas como especializaciones, realmente no lo son. Si tienes claro que quieres y vas a ser programador, siento decirte que vas a tener muchas asignaturas que no van a tener nada que ver; hay mucho relleno en esos temarios. Obviamente, el saber no ocupa lugar; está bien tener cultura general de tu profesión, pero, este tiempo en el que aprendes cosas que no vas acabar utilizando, puedes invertirlo mucho mejor en otras cosas si sabes cómo hacerlo. Ten en cuenta que, de toda la carrera, podrás aprovechar un 20%. ¿Recuerdas lo que estudiaste cuando tenías 14, 15 o 16 años? Es lo mismo. ¿Cuántas integrales has hecho desde que hiciste la última en el colegio? Sí, está bien, es cultura general pero bueno, llega un punto en el que toca ser más pragmático; de elegir qué es lo que quieres hacer y dejar de hacer lo que te dicen. Otro punto, es que las carreras duran 4 años como mínimo y depende del momento que tú quieras aprender programación, no todo el mundo tiene tiempo para dedicarlo. Si, son 4 años ¿Sabes lo que da tiempo en 4 años con otro tipo de formación?  Mucho. Por último, y antes de que se me eche encima la gente de las universidades o la que haya estudiado alguna carrera y esté orgulloso de ello, las carreras no dejan de ser un gran negocio; la formación es un gran negocio y como todo gran negocio, tiene su competencia: alternativas que, en el caso de la programación, son mejores. La formación alternativa Otra pregunta que quizás te haces y dices “no quiero elegir una carrera universitaria” es ¿Puedo aspirar a un buen futuro laboral sin tener una carrera? Pues yo te digo que sí, sí y sí. Olvídate de la “titulitis”.  En el mundo de la programación importan mucho más los conocimientos actuales o los trabajos hechos, que un simple papel firmado por el Rey de España, en este caso. Cualquier persona que vaya a seleccionar un programador para un equipo, sabe que lo que realmente importa, no es un título, sino algo que demuestre realmente lo que sabe. Ejemplos de formación alternativa Vista la universidad, vamos a ver que tenemos en el lado del “mal”, en la formación alternativa. Para alguien que dice Yo no quiero estudiar una carrera, porque no tengo el tiempo, dinero o me parece que hay más opciones, en primer lugar, decirle que, por educación alternativa, no me refiero únicamente a internet; esto tiene que quedar bastante claro. Con formación alternativa me refiero obviamente a cursos en línea (videos, tutoriales, etc.), cursos presenciales que pueden impartir empresas, libros, o formación reglada que no sea de la universidad.  En España, para los que me escuchan de fuera, existe el concepto de formación profesional que son cursos de 2 años, especializados, mucho más prácticos que la universidad, y que se hacen después de la formación obligatoria. Vistos los ejemplos de formación alternativa, para este capítulo me gustaría separarlos en dos grupos. Uno serían los métodos que conllevan un autoaprendizaje (que tú tienes que coger ese recurso, y sin ayuda de nadie, aprenderlo todo).  El otro sería el aprendizaje tutelado que, no sé si este es el antónimo de autoaprendizaje, pero yo creo que se entiende: un método que implica acudir a alguien para que te explique y te resuelva cualquier duda; normalmente será un profesor. Esto, marca una gran diferencia, sobre todo a la hora de aprender programación desde cero ¿Por qué hago la separación? Considero que, si no sabes absolutamente nada, es mejor elegir un método tutelado para acudir a alguien para que te resuelva tus dudas, más allá de lo que ya se está explicando. De esta manera, si hace falta, que te lo repita mil veces. Sin embargo, si sabes algo, esto ya es totalmente diferente. Una persona que ya sabe programación, que ya tiene los conceptos básicos y que ya ha hecho algo, tiene que buscarse la vida. Tiene que coger información y aprender por su cuenta; a la larga, es lo que vas a tener que hacer como programador: si te encargan un proyecto y tienes que utilizar una tecnología que no sabes, tendrás que aprenderla por tu cuenta; no puedes ir a hacer un curso y que te lo expliquen ya que es totalmente inviable. Aprender a pensar como una máquina Si ya sabes programación, tienes que ser mucho más pragmático; si no, estás muerto directamente. Además, cuando sabes de programación, tu mente cambia un poco. La forma en que afrontas nuevos conocimientos de programación, es distinta. No me refiero a que sabes más o menos listo; me refiero a que, en la programación, hay que cambiar un poco la mentalidad con la que miras las cosas. La programación trata de comunicarse con las máquinas. Pues bien, la mente humana y la de las máquinas son totalmente distintas. Aunque no me creas, nuestra mente es más avanzada que la de las máquinas; para aprender programación, tienes que aprender a pensar como una máquina y eso solo lo puedes hacer a base de práctica y de aprender conceptos nuevos.  Esta mentalidad no la tienes cuando empiezas, de ahí que haga esta gran diferencia. Una vez tu vas aprendiendo conceptos nuevos de programación y tienes una base, pasar a otro concepto nuevo y aprenderlo es mucho más fácil. ¿Qué tipo formación elegir? Dicho esto, ¿qué formación elijo para empezar? Como he dicho, yo me decantaría por cursos impartidos por alguien a quien puedas preguntar y resolver tus dudas una y otra vez; que te explique todos los conceptos desde el inicio. Con esto, no digo que tenga que ser ya sea presencial u online; es indiferente, me da igual. Por ejemplo, el caso de la FP en España, considero que es uno de los mejores recursos para aprender a programar. Es lo primero que le recomendaría a alguien y estoy hablando de la FP de grado superior, porque en la de grado medio no te van a enseñar lo suficiente para poder salir y defenderte. Sin embargo, en la superior sí. No vas a salir siendo un crack, pero vas a salir con una base con la cual vas a seguir tu camino. Es como el niño que aprende a ir en bici y le ponen las ruedecillas pequeñas atrás. Primero aprendes con estas ruedas, después te quitan una y luego la otra, para después ir únicamente con las dos ruedas principales de la bici (por lo menos así me lo enseñaron a mí). Podríamos decir que con la FP te ponen las dos ruedas pequeñas y te ponen a andar. Cuando salgas, te habrán quitado una de ellas y tendrás solo una. Tú mismo tendrás que quitarte esa rueda auxiliar y aprender a andar únicamente con las dos principales, a base de esfuerzo y seguramente más de una caída; pero, es la manera que hay. Si tuviera que recomendar otro método además de la FP, diría que los cursos online o presenciales con un profesor encargado, siempre son una buena idea. En todo momento hablo de una persona a la que tu puedas recurrir a preguntar tus dudas. Por ejemplo, un curso online en el que solamente se ofrezca el temario, pero no puedas acceder a nadie, no me parece lo más ideal para empezar a programar. O, también, un libro que básicamente te lo tienes que leer y estudiar tu porque no creo que el autor te vaya a resolver tus dudas, tampoco creo que sea el mejor método. No hablo de cursos de uno o dos meses; hablo de por lo menos 1-2 años, porque hay muchísimo contenido para iniciarse en la programación y muchos conceptos que hay que aprender. ¿Qué tipo de cursos? Pues aquellos de iniciación a la programación. Tampoco te diría que, si tienes muy claro que quieres hacer Android, vayas directamente a un curso especializado en Android, porque antes de meterte en este, tienes que tener muchísimos conceptos básicos aprendidos. SI hay un curso de Android de 1-2 años y si realmente vas a empezar desde cero, no creo que sea lo mejor porque seguramente te perderás. Como digo, hay muchos conceptos básicos que necesitan aprender y que tienen que quedar claro para poder empezar a volar solo. Una vez que tu tengas estos conceptos básicos, a base de autoaprendizaje, podrías aprender Android, iOS, Web, lo que quieras, da igual. The post 16. Empezar desde 0 en la programación appeared first on Diego Laballós.

Si me preguntaran qué es lo más difícil de la programación (hasta donde yo sé y he hecho), diría que sin duda, es el comienzo o los primeros pasos. Personalmente, he hecho programación web y de juegos, y actualmente, desde hace ya unos años, hago programación de aplicaciones móviles. Nada de lo que he dicho anteriormente, me ha parecido más difícil que empezar de cero, que aquellos primeros días en que no tenía ni idea de nada. A priori, tú cuando empiezas a estudiar cualquier tema, cosa o concepto -llámale como quieras-, empiezas aprendiendo conceptos fáciles y poco a poco vas subiendo de nivel. Por ejemplo, cuando empiezas con las matemáticas, empiezas a sumar y restar, y es bastante fácil. Luego elevas un poco el nivel y aprendes a multiplicar y dividir; ya se complica un poco más la cosa. Dependiendo de hasta donde llegues, harás integrales, derivadas, etc. A mi parecer, cada nivel que vas subiendo, va complicando más la cosa; es más difícil entender el concepto. <h3>Empezar desde 0 en la programación</h3> En la programación, también es así. Obviamente no puedes empezar la casa por el tejado, pero lo que quiero decir es que, a mí, y a muchas otras personas que conozco, los primeros pasos en la programación, las primeras “sumas y restas”, (haciendo la analogía con la programación), fueron los más complicados de entender. ¿Por qué digo esto?, ¿Por qué me enrollo tanto con esta noción de que el principio es difícil? Pues la verdad, tendrá mucho más sentido cuando hayáis escuchado todo el capítulo, pero, mi opinión es que hay dos puntos muy distintos en cuanto a aprender programación o algo. El primero, es empezar completamente desde cero; no sabiendo nada. Ni que es un “if”, una variable, un “bucle”, nada, cero. El segundo punto, es teniendo ya unos conocimientos básicos. A partir de estos dos puntos de partida, hay dos caminos distintos o, por lo menos, dos caminos recomendables. Hablo de caminos para aprender algo nuevo. Obviamente, en este capítulo, nos vamos a situar en el punto uno, empezar de cero. Alguien que no sabe nada, pero nada de programación, aunque también hablaremos del segundo punto para dejar clara esta división. <h3>Universidad o formación alternativa</h3> Dicho esto, vamos al título del capítulo. “Quiero aprender programación, quiero ser programador” La pregunta principal es: ¿Universidad o formación alternativa? Son los dos caminos que yo dividiría para aprender algo nuevo. Digamos que la universidad sería el camino de toda la vida y la formación alternativa sería buscar otras opciones. Dentro de esta última, como veremos, hay muchísimos caminos. ¿Por qué separo universidad de formación alternativa? La universidad, es lo que nos han enseñado desde pequeños que tenemos que hacer: “Estudia la educación obligatoria, el bachillerato, vete a la universidad y buscar un trabajo”. Sin embargo, hoy en día, y sobre todo con la aparición de internet, esto queda, en mi opinión, un poco desfasado. Ojo, estoy hablando de programación, no de otras profesiones. Obviamente, a un médico no le diría que se formara con educación alternativa; principalmente porque no conozco nada del tema, pero yo creo que tampoco es el mejor camino. Estoy hablando únicamente de la programación, de lo que yo conozco y he estudiado y, por lo tanto, de lo que puedo hablar. <h3>¿Por qué no elegir la universidad para aprender programación?</h3> ¿Por qué digo que está un poco desfasado el camino de la universidad? No voy a recurrir al tópico de que muchas mentes brillantes no tienen universidad, como Bill Gates, Steve Job, Mark Zuckerberg, entre otros. No, las universidades tienen la gran desventaja de que tienes temarios muy cerrados y poco cambiantes. Es una formación que tiene que seguir unas pautas y no es tan sencillo cambiar y actualizar el contenido. Otra cosa que tampoco me convence de las carreras, es que, aun siendo vendidas como especializaciones, realmente no lo son. Si tienes claro que quieres y vas a ser programador, siento decirte que vas a tener muchas asignaturas que no van a tener nada que ver; hay mucho relleno en esos temarios. Obviamente, el saber no ocupa lugar; está bien tener cultura general de tu profesión, pero, este tiempo en el que aprendes cosas que no vas acabar utilizando, puedes invertirlo mucho mejor en otras cosas si sabes cómo hacerlo. Ten en cuenta que, de toda la carrera, podrás aprovechar un 20%. ¿Recuerdas lo que estudiaste cuando tenías 14, 15 o 16 años? Es lo mismo. ¿Cuántas integrales has hecho desde que hiciste la última en el colegio? Sí, está bien, es cultura general pero bueno, llega un punto en el que toca ser más pragmático; de elegir qué es lo que quieres hacer y dejar de hacer lo que te dicen. Otro punto, es que las carreras duran 4 años como mínimo y depende del momento que tú quieras aprender programación, no todo el mundo tiene tiempo para dedicarlo. Si, son 4 años ¿Sabes lo que da tiempo en 4 años con otro tipo de formación? Mucho. Por último, y antes de que se me eche encima la gente de las universidades o la que haya estudiado alguna carrera y esté orgulloso de ello, las carreras no dejan de ser un gran negocio; la formación es un gran negocio y como todo gran negocio, tiene su competencia: alternativas que, en el caso de la programación, son mejores. <h3>La formación alternativa</h3> Otra pregunta que quizás te haces y dices “no quiero elegir una carrera universitaria” es ¿Puedo aspirar a un buen futuro laboral sin tener una carrera? Pues yo te digo que sí, sí y sí. Olvídate de la “titulitis”. En el mundo de la programación importan mucho más los conocimientos actuales o los trabajos hechos, que un simple papel firmado por el Rey de España, en este caso. Cualquier persona que vaya a seleccionar un programador para un equipo, sabe que lo que realmente importa, no es un título, sino algo que demuestre realmente lo que sabe. <h3>Ejemplos de formación alternativa</h3> Vista la universidad, vamos a ver que tenemos en el lado del “mal”, en la formación alternativa. Para alguien que dice Yo no quiero estudiar una carrera, porque no tengo el tiempo, dinero o me parece que hay más opciones, en primer lugar, decirle que, por educación alternativa, no me refiero únicamente a internet; esto tiene que quedar bastante claro. Con formación alternativa me refiero obviamente a cursos en línea (videos, tutoriales, etc.), cursos presenciales que pueden impartir empresas, libros, o formación reglada que no sea de la universidad. En España, para los que me escuchan de fuera, existe el concepto de formación profesional que son cursos de 2 años, especializados, mucho más prácticos que la universidad, y que se hacen después de la formación obligatoria. Vistos los ejemplos de formación alternativa, para este capítulo me gustaría separarlos en dos grupos. Uno serían los métodos que conllevan un autoaprendizaje (que tú tienes que coger ese recurso, y sin ayuda de nadie, aprenderlo todo). El otro sería el aprendizaje tutelado que, no sé si este es el antónimo de autoaprendizaje, pero yo creo que se entiende: un método que implica acudir a alguien para que te explique y te resuelva cualquier duda; normalmente será un profesor. Esto, marca una gran diferencia, sobre todo a la hora de aprender programación desde cero ¿Por qué hago la separación? Considero que, si no sabes absolutamente nada, es mejor elegir un método tutelado para acudir a alguien para que te resuelva tus dudas, más allá de lo que ya se está explicando. De esta manera, si hace falta, que te lo repita mil veces. Sin embargo, si sabes algo, esto ya es totalmente diferente. Una persona que ya sabe programación, que ya tiene los conceptos básicos y que ya ha hecho algo, tiene que buscarse la vida. Tiene que coger información y aprender por su cuenta; a la larga, es lo que vas a tener que hacer como programador: si te encargan un proyecto y tienes que utilizar una tecnología que no sabes, tendrás que aprenderla por tu cuenta; no puedes ir a hacer un curso y que te lo expliquen ya que es totalmente inviable. <h3>Aprender a pensar como una máquina</h3> Si ya sabes programación, tienes que ser mucho más pragmático; si no, estás muerto directamente. Además, cuando sabes de programación, tu mente cambia un poco. La forma en que afrontas nuevos conocimientos de programación, es distinta. No me refiero a que sabes más o menos listo; me refiero a que, en la programación, hay que cambiar un poco la mentalidad con la que miras las cosas. La programación trata de comunicarse con las máquinas. Pues bien, la mente humana y la de las máquinas son totalmente distintas. Aunque no me creas, nuestra mente es más avanzada que la de las máquinas; para aprender programación, tienes que aprender a pensar como una máquina y eso solo lo puedes hacer a base de práctica y de aprender conceptos nuevos. Esta mentalidad no la tienes cuando empiezas, de ahí que haga esta gran diferencia. Una vez tu vas aprendiendo conceptos nuevos de programación y tienes una base, pasar a otro concepto nuevo y aprenderlo es mucho más fácil. <h3>¿Qué tipo formación elegir?</h3> Dicho esto, ¿qué formación elijo para empezar? Como he dicho, yo me decantaría por cursos impartidos por alguien a quien puedas preguntar y resolver tus dudas una y otra vez; que te explique todos los conceptos desde el inicio. Con esto, no digo que tenga que ser ya sea presencial u online; es indiferente, me da igual. Por ejemplo, el caso de la FP en España, considero que es uno de los mejores recursos para aprender a programar. Es lo primero que le recomendaría a alguien y estoy hablando de la FP de grado superior, porque en la de grado medio no te van a enseñar lo suficiente para poder salir y defenderte. Sin embargo, en la superior sí. No vas a salir siendo un crack, pero vas a salir con una base con la cual vas a seguir tu camino. Es como el niño que aprende a ir en bici y le ponen las ruedecillas pequeñas atrás. Primero aprendes con estas ruedas, después te quitan una y luego la otra, para después ir únicamente con las dos ruedas principales de la bici (por lo menos así me lo enseñaron a mí). Podríamos decir que con la FP te ponen las dos ruedas pequeñas y te ponen a andar. Cuando salgas, te habrán quitado una de ellas y tendrás solo una. Tú mismo tendrás que quitarte esa rueda auxiliar y aprender a andar únicamente con las dos principales, a base de esfuerzo y seguramente más de una caída; pero, es la manera que hay. Si tuviera que recomendar otro método además de la FP, diría que los cursos online o presenciales con un profesor encargado, siempre son una buena idea. En todo momento hablo de una persona a la que tu puedas recurrir a preguntar tus dudas. Por ejemplo, un curso online en el que solamente se ofrezca el temario, pero no puedas acceder a nadie, no me parece lo más ideal para empezar a programar. O, también, un libro que básicamente te lo tienes que leer y estudiar tu porque no creo que el autor te vaya a resolver tus dudas, tampoco creo que sea el mejor método. No hablo de cursos de uno o dos meses; hablo de por lo menos 1-2 años, porque hay muchísimo contenido para iniciarse en la programación y muchos conceptos que hay que aprender. ¿Qué tipo de cursos? Pues aquellos de iniciación a la programación. Tampoco te diría que, si tienes muy claro que quieres hacer Android, vayas directamente a un curso especializado en Android, porque antes de meterte en este, tienes que tener muchísimos conceptos básicos aprendidos. SI hay un curso de Android de 1-2 años y si realmente vas a empezar desde cero, no creo que sea lo mejor porque seguramente te perderás. Como digo, hay muchos conceptos básicos que necesitan aprender y que tienen que quedar claro para poder empezar a volar solo. Una vez que tu tengas estos conceptos básicos, a base de autoaprendizaje, podrías aprender Android, iOS, Web, lo que quieras, da igual. The post <a href="https://diegolaballos.com/podcast/16-empezar-desde-0-en-la-programacion/" rel="nofollow" target="_blank">16. Empezar desde 0 en la programación</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

16. Empezar desde 0 en la programación

Antes que nada, vamos a ver el concepto de GPS. Yo creo que la mayoría de gente sabrá de qué se trata, pero vamos a aclararlo bien antes de empezar.  ¿Qué es un GPS? Es un sensor que nos permite obtener las coordenadas del dispositivo. En pocas palabras nos permite ubicar el dispositivo dentro del mundo y saber dónde está, y la gran mayoría de móviles hoy en día, lo llevan. ¿Cómo funciona el GPS de un móvil? ¿Cómo lo hacen? A través del sistema de coordenadas geográficas, basado en latitud y longitud. Explicado de forma rápida, si dividiéramos la tierra en líneas verticales y horizontales, la latitud haría referencia a la línea horizontal, es decir “más arriba (norte) o más abajo (sur)”. Por su parte, la longitud haría referencia a la línea vertical, es decir “si está más a la derecha (este) o más a la izquierda (oeste)”. En resumen, el GPS nos va a dar una latitud y una longitud, que son dos números, los cuales representan la posición exacta dentro de nuestro planeta. Es decir, donde se cruzan el punto vertical y el punto horizontal, es donde está el dispositivo; como si fuera el juego de “hundir la flota”. ¿Qué ofrece el GPS para el desarrollo de aplicaciones? ¿Qué posibilidades nos ofrece esto para el desarrollo de aplicaciones? La verdad, las posibilidades son casi infinitas como veremos a continuación. El sensor GPS es posiblemente, junto con la cámara, uno de los sensores que hacen realmente interesante y diferentes los móviles, sobre todo para desarrollar ideas con respecto a los tradicionales ordenadores que son dispositivos estáticos. El hecho de ser un dispositivo móvil y sumarle un GPS, es decir, que se puede seguir su posición, da un montón de posibilidades. Tras aclarar brevemente qué es el GPS y ver qué obtenemos de él, vamos a ver qué posibilidades nos da. La verdad es que son muchas, pero vamos a ver unos cuantos ejemplos para que os hagáis una idea de las muchas ideas y proyectos que se pueden llevar a cabo.  He tratado de dividir las posibilidades del GPS en tres grandes categorías, explicando la funcionalidad y algunos ejemplos concretos de cosas que se pueden hacer o incluso, aplicaciones que ya lo hacen. Utilizar el GPS del móvil para seguimiento y trazado de rutas La primera de ellas es usar el GPS para mostrar un seguimiento para trazar un camino a seguir. Este es el caso más obvio y típico de un GPS. Al igual que un GPS de un coche sirve para trazar rutas y guiarnos, se pueden hacer apps que hagan exactamente lo mismo y, de hecho, las hay. Google Maps y Apple Maps traen GPS integrados que también podemos utilizar para ir en bici, coche o lo que sea. Incluso, los propios fabricantes de GPS como TomTom tienen sus propias versiones de aplicaciones móviles. La verdad que los GPS en versión aplicación, tienen muchas posibilidades ya que pueden combinar el poder del acceso a internet que tiene el móvil para mostrar cosas como el tráfico en tiempo real o precios de las gasolineras (no sé si hay alguno que lo haga, pero se podría hacer seguramente). En el caso del coche, prefiero un GPS dedicado como un TomTom porque yendo a velocidad con el coche, resulta más preciso el GPS dedicado. Sobre todo, en rotondas o sitios conflictivos donde hay muchos caminos, pareciera que el GPS del móvil va un poco atrasado; le lleva más tiempo actualizar la posición real. Al fin y al cabo, estamos hablando de dos dispositivos, quizás del mismo tamaño (aunque el GPS normalmente es más grande). Uno sirve exclusivamente para geolocalizar y el otro para mil y una cosas. Así que, veo normal que un GPS dedicado a la navegación en coche, sea mejor que una aplicación móvil. Utilizar el GPS del móvil para aplicaciones tipo “running” Ahora bien, dejando el coche a un lado, cuando se trata de otro tipo de actividades como correr, ir en bici, etc., el GPS es genial para hacer una app para ello. Aplicaciones como Runtastic, o muchas otras para correr o hacer deporte, aprovechan tanto el sensor del móvil como las demás funciones que tiene el dispositivo. Por ejemplo, algunas aplicaciones de running, además de mostrar la ruta que vas haciendo, te ofrecen otras posibilidades como publicar tu ruta en redes sociales; incluso tus amigos pueden enviarte mensajes de audio de ánimo. En fin, las posibilidades para este tipo de aplicaciones son ilimitadas. Eso lo demuestra la gran variedad de aplicaciones que hay de este tipo. Utilizar el GPS del móvil para seguir a terceras personas Otra manera de explotar esta función de trazar rutas, es el seguimiento a terceros. Me explico: tal como podemos ver nuestra posición (porque una aplicación accede a nuestra posición), también podemos ver la ruta de otra persona, ya que la aplicación registra sus posiciones y nos la puede mostrar a nosotros. Por ejemplo, las aplicaciones de comida a domicilio o reparto en general. Una de las que yo uso bastante es Amazon Prime Now que básicamente es una aplicación en donde te traen la compra del supermercado en unas dos horas a casa. Abres la aplicación y eliges de entre todos los productos que hay (no solo de supermercado, también hay cosas de tecnología). Cuando acabas tu compra y pagas, en dos horas te lo entregan. Cuando el mensajero sale del almacén y viene a tu casa, tú puedes ver en un mapa dentro de la app, por donde viene ese mensajero; te muestra exactamente el camino que sigue desde el almacén de Amazon hasta tu casa. Probablemente no sea una función vital sin la que no puedan vivir estas aplicaciones, pero, a mí me encantan personalmente; me gusta el concepto. ¿Esto cómo funciona?, ¿Cómo puedes llegar a saber exactamente la posición del mensajero si tu móvil únicamente registra tus posiciones? Pues porque el mensajero tiene una aplicación en su teléfono y no es la misma versión que tú tienes instalada.  Su versión, además de gestionar los pedidos que hace, se encarga de enviar al servidor, sus posiciones GPS, es decir, “por dónde está yendo”. No te lo está diciendo directamente a ti; se lo está diciendo al servidor que como vimos en su día, es el corazón de toda aplicación. Tu versión de aplicación pública que tienes instalada, lo que hace es pedirle al servidor las posiciones del mensajero. De esta manera es como tu puedes ver su posición; no tiene más misterio.  Como decía, esto también lo aprovechan muchas veces aplicaciones de comida a domicilio para hacer exactamente lo mismo. Aunque, también se podría aplicar a trabajos de limpieza a domicilio o, imagina por ejemplo una aplicación de limpieza de coches en donde, en vez de ir al túnel de lavado, tú, a través de tu aplicación, pides que un trabajador de la empresa te venga a lavar el coche, sin necesidad de que tu estés ahí. Con un sistema de estos, tu podrías ver como el repartidor va hacia el coche, y cuando está lavándolo. Utilizar el GPS para medir distancias La segunda de las categorías de funciones que nos deja hacer el GPS, es la localización de elementos y mostrar la distancia entre ellos; esta es otra de las típicas: guardar las localizaciones de cosas para luego hacer búsquedas con base en una posición.  Por ejemplo, un buscador de hoteles en donde, teniendo la ubicación de todos los hoteles y la tuya en el momento en que entras a la aplicación, puede calcular las distancias y permitirte hacer búsquedas alrededor de un radio de distancia. Otro típico: compra-venta de productos de segunda mano. Por ejemplo, el caso Wallapop. Obteniendo la posición del vendedor cuando la coloca en su perfil, pueden ubicar sus productos en una zona concreta. Entonces, en el momento en el que tu vas a buscar un producto, obtienen tu posición y pueden ofrecerte resultados de los productos que están cerca de ti. Esto, entre cosas, ha sido uno de los elementos que ha permitido triunfar tanto a Wallapop: buscar y encontrar productos casi a lado de tu casa, sin tener que hacer la típica búsqueda en la web, poniendo “localidad”, “ciudad”, “país”, etc. Simplemente entras con el móvil, automáticamente encuentra tu posición y ya está, encuentras todos los productos que están a tu alrededor. Utilizar el GPS del móvil para detectar que alguien está cerca La última categoría es detectar que alguien está cerca de algún sitio. Está función, quizás no es tan común, pero también es posible con el GPS.  Se trata de que en segundo plano y sin estar el usuario presente, la aplicación avisa al usuario cuando está cerca de algo en forma de notificación. Por ejemplo, una aplicación de ofertas de un barrio. El típico de folleto de antes de descuentos, de las tiendas del barrio, pero en versión 2.0: cada vez que pases delante de una tienda donde haya una oferta, el móvil te avisa. O incluso, tú puedes elegir que te avise cuando ciertos productos o servicios tengan descuento y tu estés cerca de ellos. ¿Cómo funciona eso? La aplicación del móvil va estar cogiendo tu posición GPS en un segundo plano cada cierto tiempo; esto lo va a enviar a un servidor, el cual va a mirar si tiene productos u ofertas cerca de tu posición que acabas de enviar. En el caso de que los haya, el servidor le dice al móvil “Si hay”, y le manda el resultado. En ese momento, a ti te llega una notificación, sin tu tener que haber hecho nada. Otro ejemplo: puedes saber la gente con la que te has cruzado. Esto lo hacen esas aplicaciones de moda para ligar y conocer gente que se llama Happn. Es el concepto de siempre, de aplicaciones para conocer gente, que llevan apareciendo. Pero, la gran diferencia, es que solo te aparecen personas con las que tu te has cruzado, por ejemplo, en el autobús o en la calle. A partir de ahí, tu ya puedes decir si te gustan o no, chatear, etc. La diferencia es esa: que te aparece gente con la que te has cruzado. ¿Cómo lo hacen? Pues lo mismo, a través de las posiciones de cada persona. Comparando tus posiciones y las de la gente, van a mostrarte aquellas personas que entran dentro de tus filtros, pero comprobando la coincidencia de posiciones en el tiempo. En resumen, si estabas a la misma hora en unas coordenadas muy cercanas; quizás no es que os hayáis cruzado exactamente, pero estabais a unos metros. De esta manera es como lo pueden hacer. Otro ejemplo muy parecido: avisos relativos al lugar donde estás. Por ejemplo, un periódico podría tener una sección dedicada a las noticias que están a tu alrededor; únicamente te saldrían las noticias de interés en la localidad o lugar donde estés. Sin ir más lejos, yo tengo una app hecha por mí, muy simple, para ver alertas del tiempo del lugar en que estás. ¿Cómo lo hago? En primer lugar, accedo al GPS del móvil cada cierto tiempo. Luego transformo estas coordenadas en una localidad exacta, como Barcelona. Posteriormente consulto en internet si hay posibilidad de lluvia para las próximas horas y, en caso de que la posibilidad sea alta, aviso al usuario con una notificación. Algo que también podemos hacer es algo en función de si el usuario está cerca de algo. Por ejemplo, bancos. Hay bancos en donde se puede sacar dinero con tu móvil, sin tener que sacar la tarjeta. ¿Cómo lo puedes hacer? A través del móvil, pueden verificar que tu estás a lado o delante del cajero; a través de esto, funciona como una tarjeta: introduces el PIN y sacas dinero. Otro ejemplo de app, que aquí en Barcelona funciona bastante bien es Cooltra, que permite coger una moto de alquiler, pero sin necesidad de ir a una oficina. Las motos están aparcadas por la ciudad y tú, con tan solo acercar tu móvil, te permiten abrirla y encenderla. Obviamente tienes que tener un usuario, pero, la forma de encender la moto es esa: te acercas con el móvil y ya está. Evidentemente, estas cosas ya conllevan la interacción con otro tipo de sistemas como la apertura de la moto o sacar dinero del banco, pero el punto, es que funcionan gracias la localización del dispositivo. The post 15. ¿Qué posibilidades nos ofrece el GPS del móvil? appeared first on Diego Laballós.

Antes que nada, vamos a ver el concepto de GPS. Yo creo que la mayoría de gente sabrá de qué se trata, pero vamos a aclararlo bien antes de empezar. ¿Qué es un GPS? Es un sensor que nos permite obtener las coordenadas del dispositivo. En pocas palabras nos permite ubicar el dispositivo dentro del mundo y saber dónde está, y la gran mayoría de móviles hoy en día, lo llevan. <h3>¿Cómo funciona el GPS de un móvil?</h3> ¿Cómo lo hacen? A través del sistema de coordenadas geográficas, basado en latitud y longitud. Explicado de forma rápida, si dividiéramos la tierra en líneas verticales y horizontales, la latitud haría referencia a la línea horizontal, es decir “más arriba (norte) o más abajo (sur)”. Por su parte, la longitud haría referencia a la línea vertical, es decir “si está más a la derecha (este) o más a la izquierda (oeste)”. En resumen, el GPS nos va a dar una latitud y una longitud, que son dos números, los cuales representan la posición exacta dentro de nuestro planeta. Es decir, donde se cruzan el punto vertical y el punto horizontal, es donde está el dispositivo; como si fuera el juego de “hundir la flota”. <h3>¿Qué ofrece el GPS para el desarrollo de aplicaciones?</h3> ¿Qué posibilidades nos ofrece esto para el desarrollo de aplicaciones? La verdad, las posibilidades son casi infinitas como veremos a continuación. El sensor GPS es posiblemente, junto con la cámara, uno de los sensores que hacen realmente interesante y diferentes los móviles, sobre todo para desarrollar ideas con respecto a los tradicionales ordenadores que son dispositivos estáticos. El hecho de ser un dispositivo móvil y sumarle un GPS, es decir, que se puede seguir su posición, da un montón de posibilidades. Tras aclarar brevemente qué es el GPS y ver qué obtenemos de él, vamos a ver qué posibilidades nos da. La verdad es que son muchas, pero vamos a ver unos cuantos ejemplos para que os hagáis una idea de las muchas ideas y proyectos que se pueden llevar a cabo. He tratado de dividir las posibilidades del GPS en tres grandes categorías, explicando la funcionalidad y algunos ejemplos concretos de cosas que se pueden hacer o incluso, aplicaciones que ya lo hacen. <h3>Utilizar el GPS del móvil para seguimiento y trazado de rutas</h3> La primera de ellas es usar el GPS para mostrar un seguimiento para trazar un camino a seguir. Este es el caso más obvio y típico de un GPS. Al igual que un GPS de un coche sirve para trazar rutas y guiarnos, se pueden hacer apps que hagan exactamente lo mismo y, de hecho, las hay. Google Maps y Apple Maps traen GPS integrados que también podemos utilizar para ir en bici, coche o lo que sea. Incluso, los propios fabricantes de GPS como TomTom tienen sus propias versiones de aplicaciones móviles. La verdad que los GPS en versión aplicación, tienen muchas posibilidades ya que pueden combinar el poder del acceso a internet que tiene el móvil para mostrar cosas como el tráfico en tiempo real o precios de las gasolineras (no sé si hay alguno que lo haga, pero se podría hacer seguramente). En el caso del coche, prefiero un GPS dedicado como un TomTom porque yendo a velocidad con el coche, resulta más preciso el GPS dedicado. Sobre todo, en rotondas o sitios conflictivos donde hay muchos caminos, pareciera que el GPS del móvil va un poco atrasado; le lleva más tiempo actualizar la posición real. Al fin y al cabo, estamos hablando de dos dispositivos, quizás del mismo tamaño (aunque el GPS normalmente es más grande). Uno sirve exclusivamente para geolocalizar y el otro para mil y una cosas. Así que, veo normal que un GPS dedicado a la navegación en coche, sea mejor que una aplicación móvil. <h3>Utilizar el GPS del móvil para aplicaciones tipo “running”</h3> Ahora bien, dejando el coche a un lado, cuando se trata de otro tipo de actividades como correr, ir en bici, etc., el GPS es genial para hacer una app para ello. Aplicaciones como Runtastic, o muchas otras para correr o hacer deporte, aprovechan tanto el sensor del móvil como las demás funciones que tiene el dispositivo. Por ejemplo, algunas aplicaciones de running, además de mostrar la ruta que vas haciendo, te ofrecen otras posibilidades como publicar tu ruta en redes sociales; incluso tus amigos pueden enviarte mensajes de audio de ánimo. En fin, las posibilidades para este tipo de aplicaciones son ilimitadas. Eso lo demuestra la gran variedad de aplicaciones que hay de este tipo. <h3>Utilizar el GPS del móvil para seguir a terceras personas</h3> Otra manera de explotar esta función de trazar rutas, es el seguimiento a terceros. Me explico: tal como podemos ver nuestra posición (porque una aplicación accede a nuestra posición), también podemos ver la ruta de otra persona, ya que la aplicación registra sus posiciones y nos la puede mostrar a nosotros. Por ejemplo, las aplicaciones de comida a domicilio o reparto en general. Una de las que yo uso bastante es Amazon Prime Now que básicamente es una aplicación en donde te traen la compra del supermercado en unas dos horas a casa. Abres la aplicación y eliges de entre todos los productos que hay (no solo de supermercado, también hay cosas de tecnología). Cuando acabas tu compra y pagas, en dos horas te lo entregan. Cuando el mensajero sale del almacén y viene a tu casa, tú puedes ver en un mapa dentro de la app, por donde viene ese mensajero; te muestra exactamente el camino que sigue desde el almacén de Amazon hasta tu casa. Probablemente no sea una función vital sin la que no puedan vivir estas aplicaciones, pero, a mí me encantan personalmente; me gusta el concepto. ¿Esto cómo funciona?, ¿Cómo puedes llegar a saber exactamente la posición del mensajero si tu móvil únicamente registra tus posiciones? Pues porque el mensajero tiene una aplicación en su teléfono y no es la misma versión que tú tienes instalada. Su versión, además de gestionar los pedidos que hace, se encarga de enviar al servidor, sus posiciones GPS, es decir, “por dónde está yendo”. No te lo está diciendo directamente a ti; se lo está diciendo al servidor que como vimos en su día, es el corazón de toda aplicación. Tu versión de aplicación pública que tienes instalada, lo que hace es pedirle al servidor las posiciones del mensajero. De esta manera es como tu puedes ver su posición; no tiene más misterio. Como decía, esto también lo aprovechan muchas veces aplicaciones de comida a domicilio para hacer exactamente lo mismo. Aunque, también se podría aplicar a trabajos de limpieza a domicilio o, imagina por ejemplo una aplicación de limpieza de coches en donde, en vez de ir al túnel de lavado, tú, a través de tu aplicación, pides que un trabajador de la empresa te venga a lavar el coche, sin necesidad de que tu estés ahí. Con un sistema de estos, tu podrías ver como el repartidor va hacia el coche, y cuando está lavándolo. <h3>Utilizar el GPS para medir distancias</h3> La segunda de las categorías de funciones que nos deja hacer el GPS, es la localización de elementos y mostrar la distancia entre ellos; esta es otra de las típicas: guardar las localizaciones de cosas para luego hacer búsquedas con base en una posición. Por ejemplo, un buscador de hoteles en donde, teniendo la ubicación de todos los hoteles y la tuya en el momento en que entras a la aplicación, puede calcular las distancias y permitirte hacer búsquedas alrededor de un radio de distancia. Otro típico: compra-venta de productos de segunda mano. Por ejemplo, el caso Wallapop. Obteniendo la posición del vendedor cuando la coloca en su perfil, pueden ubicar sus productos en una zona concreta. Entonces, en el momento en el que tu vas a buscar un producto, obtienen tu posición y pueden ofrecerte resultados de los productos que están cerca de ti. Esto, entre cosas, ha sido uno de los elementos que ha permitido triunfar tanto a Wallapop: buscar y encontrar productos casi a lado de tu casa, sin tener que hacer la típica búsqueda en la web, poniendo “localidad”, “ciudad”, “país”, etc. Simplemente entras con el móvil, automáticamente encuentra tu posición y ya está, encuentras todos los productos que están a tu alrededor. <h3>Utilizar el GPS del móvil para detectar que alguien está cerca</h3> La última categoría es detectar que alguien está cerca de algún sitio. Está función, quizás no es tan común, pero también es posible con el GPS. Se trata de que en segundo plano y sin estar el usuario presente, la aplicación avisa al usuario cuando está cerca de algo en forma de notificación. Por ejemplo, una aplicación de ofertas de un barrio. El típico de folleto de antes de descuentos, de las tiendas del barrio, pero en versión 2.0: cada vez que pases delante de una tienda donde haya una oferta, el móvil te avisa. O incluso, tú puedes elegir que te avise cuando ciertos productos o servicios tengan descuento y tu estés cerca de ellos. ¿Cómo funciona eso? La aplicación del móvil va estar cogiendo tu posición GPS en un segundo plano cada cierto tiempo; esto lo va a enviar a un servidor, el cual va a mirar si tiene productos u ofertas cerca de tu posición que acabas de enviar. En el caso de que los haya, el servidor le dice al móvil “Si hay”, y le manda el resultado. En ese momento, a ti te llega una notificación, sin tu tener que haber hecho nada. Otro ejemplo: puedes saber la gente con la que te has cruzado. Esto lo hacen esas aplicaciones de moda para ligar y conocer gente que se llama Happn. Es el concepto de siempre, de aplicaciones para conocer gente, que llevan apareciendo. Pero, la gran diferencia, es que solo te aparecen personas con las que tu te has cruzado, por ejemplo, en el autobús o en la calle. A partir de ahí, tu ya puedes decir si te gustan o no, chatear, etc. La diferencia es esa: que te aparece gente con la que te has cruzado. ¿Cómo lo hacen? Pues lo mismo, a través de las posiciones de cada persona. Comparando tus posiciones y las de la gente, van a mostrarte aquellas personas que entran dentro de tus filtros, pero comprobando la coincidencia de posiciones en el tiempo. En resumen, si estabas a la misma hora en unas coordenadas muy cercanas; quizás no es que os hayáis cruzado exactamente, pero estabais a unos metros. De esta manera es como lo pueden hacer. Otro ejemplo muy parecido: avisos relativos al lugar donde estás. Por ejemplo, un periódico podría tener una sección dedicada a las noticias que están a tu alrededor; únicamente te saldrían las noticias de interés en la localidad o lugar donde estés. Sin ir más lejos, yo tengo una app hecha por mí, muy simple, para ver alertas del tiempo del lugar en que estás. ¿Cómo lo hago? En primer lugar, accedo al GPS del móvil cada cierto tiempo. Luego transformo estas coordenadas en una localidad exacta, como Barcelona. Posteriormente consulto en internet si hay posibilidad de lluvia para las próximas horas y, en caso de que la posibilidad sea alta, aviso al usuario con una notificación. Algo que también podemos hacer es algo en función de si el usuario está cerca de algo. Por ejemplo, bancos. Hay bancos en donde se puede sacar dinero con tu móvil, sin tener que sacar la tarjeta. ¿Cómo lo puedes hacer? A través del móvil, pueden verificar que tu estás a lado o delante del cajero; a través de esto, funciona como una tarjeta: introduces el PIN y sacas dinero. Otro ejemplo de app, que aquí en Barcelona funciona bastante bien es Cooltra, que permite coger una moto de alquiler, pero sin necesidad de ir a una oficina. Las motos están aparcadas por la ciudad y tú, con tan solo acercar tu móvil, te permiten abrirla y encenderla. Obviamente tienes que tener un usuario, pero, la forma de encender la moto es esa: te acercas con el móvil y ya está. Evidentemente, estas cosas ya conllevan la interacción con otro tipo de sistemas como la apertura de la moto o sacar dinero del banco, pero el punto, es que funcionan gracias la localización del dispositivo. The post <a href="https://diegolaballos.com/podcast/15-que-posibilidades-nos-ofrece-el-gps-del-movil/" rel="nofollow" target="_blank">15. ¿Qué posibilidades nos ofrece el GPS del móvil?</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

15. ¿Qué posibilidades nos ofrece el GPS del móvil?

En primer lugar, tenemos que decir que sí, sí existen tiendas alternativas a Google Play y App Store. De no ser así, este capítulo acabaría aquí. La verdad es que, aunque este podcast no sea especialmente largo, de momento, no tengo pensado acortarlo aún más. Así que, empecemos por responder a ¿Qué es una tienda alternativa?  ¿Qué son las tiendas alternativas a Google Play y AppStore? Es una aplicación que permite instalar otras aplicaciones. Así como Google Play y App Store, permiten instalar otras aplicaciones en Android y iOS, respectivamente; no dejan de ser en sí mismas aplicaciones normales y corrientes. Así que, una tienda alternativa es eso mismo, una tienda alternativa a Google Play y App Store, donde la funcionalidad y el objetivo son los mismos: una aplicación de aplicaciones. Antes de empezar a ver las ventajas o, si realmente vale la pena estar en otras tiendas alternativas, hay que comentar una gran diferencia entre iOS y Android. Diferencias entre iOS y Android: permisos y seguridad iOS es un sistema bastante cerrado, como ya le comentamos en su día y, únicamente puedes descargar aplicaciones de la App Store. Si que hay otras tiendas como Cydia y otras más por ahí, pero es realmente difícil acceder a ella porque para esto, tienes que hacer el jailbreak, que es modificar el iPhone, IPad o el dispositivo de Apple que sea, para permitirte saltar algunos controles de seguridad que tiene Apple. Por ejemplo, instalar aplicaciones que no provengan de la App Store. Esto hace que realmente haya muchos menos usuarios porque, dado que el jailbreak también supone un agujero de seguridad bastante importante, no es algo que sea fácil de hacer, con lo cual muy pocos usuarios lo tienen. Sin embargo, en Android, aunque por defecto no podamos instalar aplicaciones que no provengan de Google Play, simplemente lo podemos activar en una opción en los ajustes (creo recordar que está en seguridad) que se llama orígenes desconocidos. ¿Qué es lo que nos permite esto? Básicamente instalar aplicaciones que no provengan de Google Play, ya sea de la web o de tiendas alternativas. Tiendas alternativas para Android En estas tiendas alternativas de Android, al ser más fácil poder acceder a ellas, hay muchos más usuarios. Dicho esto, el presente capítulo va ir centrado en las alternativas a Google Play ya que podríamos decir que App Store no tiene una alternativa que realmente sea viable. Algunas de las muchas tiendas alternativas que existen en Android, son slideME que es la que más usuarios tiene; Amazon App store que es la tienda oficial para los dispositivos de Amazon que, realmente no traen el sistema Android, sino el FireOS. Pero, el tema aquí no es que tengamos que hacer una aplicación específica para FireOS porque éste, está basado en Android, y su tienda principal es Amazon App store. Con tan solo unos pequeños cambios a la aplicación, incluso a veces sin ningún cambio, podemos tenerla lista para poderla subir en esta tienda de Amazon. Lo bueno es que todos los dispositivos de Amazon, traen esta tienda instalada. Después, también tenemos Samsung Galaxy Apps que, como su nombre lo indica, es la tienda de aplicaciones para Android de Samsung. ¿Por qué? Pues porque Samsung es el principal fabricante de dispositivos Android y, por lo tanto, creyó conveniente que podían hacer ellos mismos, una tienda. La parte buena es que viene preinstalada en estos móviles. En cuanto a dispositivos Android, Samsung es el que más dispositivos vende. Luego tenemos alguna otra como GetJar que, es otra tienda con bastantes usuarios activos. ¿Por qué subir aplicaciones a estas tiendas alternativas? ¿Por qué una tienda alternativa puede ser interesante para alguien que ha desarrollado una aplicación?, ¿Por qué tendría que subirla a estas tiendas alternativas, además de Google Play?, ¿Por qué podría ser interesante? En primer lugar, tenemos que decir que obviamente, la primera opción, siempre tiene que ser Google Play. Es la tienda principal y la que tiene más usuarios, pero, es precisamente por este motivo, que es la que tiene más competencia. Hay infinitas aplicaciones en Google Play, hay millones de aplicaciones concretamente. Cada vez es más difícil posicionarse y ser descubierto por nuevos usuarios y encima, no digamos lo difícil que es tener la suerte de que el propio Google Play te destaque en su página principal. De todas maneras, siempre tiene que ser nuestro principal objetivo: estar bien situados en Google Play. Ventajas de situarse en tiendas alternativas Ahora bien, dejado claro esto, vamos a ver qué beneficios puede aportarnos estar en otras tiendas alternativas, en estas tiendas que hemos comentado antes. Una de las ventajas que pueden tener, es tener más opciones de ser promocionado por las propias tiendas. Muchas de estas, tienen diferentes categorías para promocionar aplicaciones. Por ejemplo, “la aplicación del día” o una selección de aplicaciones del mes; juegan más con estas clasificaciones y al haber menos aplicaciones, quiere decir que tenemos más oportunidades de ser destacados. Otra ventaja pueden ser categorías más específicas. Estas tiendas suelen tener categorías más segmentadas, podríamos decir más segmentadas, donde nuestra aplicación podría encajar mejor para ese público a quién le interesa esa categoría. Por lo tanto, puede sernos más fácil estar bien posicionados en ese ranking y ser más visibles a más usuarios. También tenemos más opciones de obtener un mejor posicionamiento global. Al haber menos aplicaciones, en una búsqueda genérica que tenga que ver con lo que hace nuestra aplicación como, por ejemplo, reservar hoteles; podemos tener más posibilidades de salir más arriba en esa búsqueda. Al haber menos aplicaciones, puede sernos más fácil. Una de las cosas que tenemos que tener en cuenta, es la dificultad casi nula de entrar a estas tiendas. ¿Por qué? Porque estas tiendas no dejan de ser de aplicaciones de Android. Pese a que algunas pueden requerir algunos cambios en según que partes de la aplicación, no tendría que ser un gran trabajo el tener la aplicación lista para poderla subir a esa tienda. Por lo tanto, para el beneficio que podríamos obtener, puede valer la pena probar suerte. No tenemos que invertir demasiado trabajo y tiempo en tener la aplicación lista. China como excepción Una cosa que no me quiero olvidar de comentar es que hay excepciones en ciertos países, concretamente en China. Todo lo que hemos comentado hasta aquí no es válido para China; nada vale. ¿Por qué? Porque Google Play no existe, ¿Y por qué no existe? Bueno, ese es otro tema, pero resumiendo, debido a la censura del gobierno por el acceso a la información y también (creo yo) para favorecer a las empresas locales, desde el 2014, Google y cualquier de sus productos no están disponibles en ese país. Google está vetado y es persona non grata. ¿Qué quiere decir esto? Que, si quieres tener usuarios en China, traducir tu aplicación no será lo único que tendrás que hacer. Tendrás que buscar una tienda alternativa a la fuerza; no te queda de otra. ¿Y por qué te debe interesar China? Esto ya dependerá de tu proyecto, pero en el caso de que te pueda interesar, básicamente la gran ventaja son los millones de usuarios móviles que tiene China. Además, de estos, más del 70% utilizan Android. Para hacernos una idea, las dos principales tiendas alternativas de Android sumaron más de 500 millones de descargas el pasado mes de marzo. Entonces, si no está Google Play, ¿Quién manda? Pues aquí está todo más repartido; dejaré un enlace a un gráfico donde se puede ver el número de descargas de cada tienda alternativa en China para que se vea que está muy repartido. Las dos tiendas más grandes en China: Tencent App store y Baidu Apps store Básicamente, tenemos dos grandes jugadores: Tencent App store, propiedad de Tencent, una gran empresa tecnológica de ahí; podríamos decir que es el “Facebook chino”, por lo que he visto. Son los propietarios de la aplicación de mensajería WeChat que, ahí es algo más que una aplicación de mensajería; tiene muchas más cosas. El otro gran jugador es Baidu, que sería el “Google chino”; es el buscador de referencia y también tiene su tienda de aplicaciones que es Baidu App store. Hay muchas otras tiendas, pero, si entráis en el gráfico ya veréis que son las dos principales. The post 14. Tiendas alternativas a Google Play y AppStore appeared first on Diego Laballós.

En primer lugar, tenemos que decir que sí, sí existen tiendas alternativas a Google Play y App Store. De no ser así, este capítulo acabaría aquí. La verdad es que, aunque este podcast no sea especialmente largo, de momento, no tengo pensado acortarlo aún más. Así que, empecemos por responder a ¿Qué es una tienda alternativa? <h3>¿Qué son las tiendas alternativas a Google Play y AppStore?</h3> Es una aplicación que permite instalar otras aplicaciones. Así como Google Play y App Store, permiten instalar otras aplicaciones en Android y iOS, respectivamente; no dejan de ser en sí mismas aplicaciones normales y corrientes. Así que, una tienda alternativa es eso mismo, una tienda alternativa a Google Play y App Store, donde la funcionalidad y el objetivo son los mismos: una aplicación de aplicaciones. Antes de empezar a ver las ventajas o, si realmente vale la pena estar en otras tiendas alternativas, hay que comentar una gran diferencia entre iOS y Android. <h3>Diferencias entre iOS y Android: permisos y seguridad</h3> iOS es un sistema bastante cerrado, como ya le comentamos en su día y, únicamente puedes descargar aplicaciones de la App Store. Si que hay otras tiendas como Cydia y otras más por ahí, pero es realmente difícil acceder a ella porque para esto, tienes que hacer el jailbreak, que es modificar el iPhone, IPad o el dispositivo de Apple que sea, para permitirte saltar algunos controles de seguridad que tiene Apple. Por ejemplo, instalar aplicaciones que no provengan de la App Store. Esto hace que realmente haya muchos menos usuarios porque, dado que el jailbreak también supone un agujero de seguridad bastante importante, no es algo que sea fácil de hacer, con lo cual muy pocos usuarios lo tienen. Sin embargo, en Android, aunque por defecto no podamos instalar aplicaciones que no provengan de Google Play, simplemente lo podemos activar en una opción en los ajustes (creo recordar que está en seguridad) que se llama orígenes desconocidos. ¿Qué es lo que nos permite esto? Básicamente instalar aplicaciones que no provengan de Google Play, ya sea de la web o de tiendas alternativas. <h3>Tiendas alternativas para Android</h3> En estas tiendas alternativas de Android, al ser más fácil poder acceder a ellas, hay muchos más usuarios. Dicho esto, el presente capítulo va ir centrado en las alternativas a Google Play ya que podríamos decir que App Store no tiene una alternativa que realmente sea viable. Algunas de las muchas tiendas alternativas que existen en Android, son slideME que es la que más usuarios tiene; Amazon App store que es la tienda oficial para los dispositivos de Amazon que, realmente no traen el sistema Android, sino el FireOS. Pero, el tema aquí no es que tengamos que hacer una aplicación específica para FireOS porque éste, está basado en Android, y su tienda principal es Amazon App store. Con tan solo unos pequeños cambios a la aplicación, incluso a veces sin ningún cambio, podemos tenerla lista para poderla subir en esta tienda de Amazon. Lo bueno es que todos los dispositivos de Amazon, traen esta tienda instalada. Después, también tenemos Samsung Galaxy Apps que, como su nombre lo indica, es la tienda de aplicaciones para Android de Samsung. ¿Por qué? Pues porque Samsung es el principal fabricante de dispositivos Android y, por lo tanto, creyó conveniente que podían hacer ellos mismos, una tienda. La parte buena es que viene preinstalada en estos móviles. En cuanto a dispositivos Android, Samsung es el que más dispositivos vende. Luego tenemos alguna otra como GetJar que, es otra tienda con bastantes usuarios activos. <h3>¿Por qué subir aplicaciones a estas tiendas alternativas?</h3> ¿Por qué una tienda alternativa puede ser interesante para alguien que ha desarrollado una aplicación?, ¿Por qué tendría que subirla a estas tiendas alternativas, además de Google Play?, ¿Por qué podría ser interesante? En primer lugar, tenemos que decir que obviamente, la primera opción, siempre tiene que ser Google Play. Es la tienda principal y la que tiene más usuarios, pero, es precisamente por este motivo, que es la que tiene más competencia. Hay infinitas aplicaciones en Google Play, hay millones de aplicaciones concretamente. Cada vez es más difícil posicionarse y ser descubierto por nuevos usuarios y encima, no digamos lo difícil que es tener la suerte de que el propio Google Play te destaque en su página principal. De todas maneras, siempre tiene que ser nuestro principal objetivo: estar bien situados en Google Play. <h3>Ventajas de situarse en tiendas alternativas</h3> Ahora bien, dejado claro esto, vamos a ver qué beneficios puede aportarnos estar en otras tiendas alternativas, en estas tiendas que hemos comentado antes. Una de las ventajas que pueden tener, es tener más opciones de ser promocionado por las propias tiendas. Muchas de estas, tienen diferentes categorías para promocionar aplicaciones. Por ejemplo, “la aplicación del día” o una selección de aplicaciones del mes; juegan más con estas clasificaciones y al haber menos aplicaciones, quiere decir que tenemos más oportunidades de ser destacados. Otra ventaja pueden ser categorías más específicas. Estas tiendas suelen tener categorías más segmentadas, podríamos decir más segmentadas, donde nuestra aplicación podría encajar mejor para ese público a quién le interesa esa categoría. Por lo tanto, puede sernos más fácil estar bien posicionados en ese ranking y ser más visibles a más usuarios. También tenemos más opciones de obtener un mejor posicionamiento global. Al haber menos aplicaciones, en una búsqueda genérica que tenga que ver con lo que hace nuestra aplicación como, por ejemplo, reservar hoteles; podemos tener más posibilidades de salir más arriba en esa búsqueda. Al haber menos aplicaciones, puede sernos más fácil. Una de las cosas que tenemos que tener en cuenta, es la dificultad casi nula de entrar a estas tiendas. ¿Por qué? Porque estas tiendas no dejan de ser de aplicaciones de Android. Pese a que algunas pueden requerir algunos cambios en según que partes de la aplicación, no tendría que ser un gran trabajo el tener la aplicación lista para poderla subir a esa tienda. Por lo tanto, para el beneficio que podríamos obtener, puede valer la pena probar suerte. No tenemos que invertir demasiado trabajo y tiempo en tener la aplicación lista. <h3>China como excepción</h3> Una cosa que no me quiero olvidar de comentar es que hay excepciones en ciertos países, concretamente en China. Todo lo que hemos comentado hasta aquí no es válido para China; nada vale. ¿Por qué? Porque Google Play no existe, ¿Y por qué no existe? Bueno, ese es otro tema, pero resumiendo, debido a la censura del gobierno por el acceso a la información y también (creo yo) para favorecer a las empresas locales, desde el 2014, Google y cualquier de sus productos no están disponibles en ese país. Google está vetado y es persona non grata. ¿Qué quiere decir esto? Que, si quieres tener usuarios en China, traducir tu aplicación no será lo único que tendrás que hacer. Tendrás que buscar una tienda alternativa a la fuerza; no te queda de otra. ¿Y por qué te debe interesar China? Esto ya dependerá de tu proyecto, pero en el caso de que te pueda interesar, básicamente la gran ventaja son los millones de usuarios móviles que tiene China. Además, de estos, más del 70% utilizan Android. Para hacernos una idea, las dos principales tiendas alternativas de Android sumaron más de 500 millones de descargas el pasado mes de marzo. Entonces, si no está Google Play, ¿Quién manda? Pues aquí está todo más repartido; dejaré un enlace a un gráfico donde se puede ver el número de descargas de cada tienda alternativa en China para que se vea que está muy repartido. <h3>Las dos tiendas más grandes en China: Tencent App store y Baidu Apps store</h3> Básicamente, tenemos dos grandes jugadores: Tencent App store, propiedad de Tencent, una gran empresa tecnológica de ahí; podríamos decir que es el “Facebook chino”, por lo que he visto. Son los propietarios de la aplicación de mensajería WeChat que, ahí es algo más que una aplicación de mensajería; tiene muchas más cosas. El otro gran jugador es Baidu, que sería el “Google chino”; es el buscador de referencia y también tiene su tienda de aplicaciones que es Baidu App store. Hay muchas otras tiendas, pero, si entráis en el gráfico ya veréis que son las dos principales. The post <a href="https://diegolaballos.com/podcast/14-tiendas-alternativas-a-google-play-y-appstore/" rel="nofollow" target="_blank">14. Tiendas alternativas a Google Play y AppStore</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

14. Tiendas alternativas a Google Play y AppStore

¿Qué es esto del síndrome del impostor? Si nos vamos a Wikipedia, donde normalmente no vamos a encontrar definiciones muy formales (este también es el caso) encontramos lo siguiente: fenómeno psicológico en el que la gente es incapaz de interiorizar sus logros. A pesar de las evidencias externas de su competencia, aquellos con el síndrome permanecen convencidos de que son un fraude y no merecen el éxito que han conseguido. ¿Qué es el síndrome del impostor? ¿Qué quiere decir esto en lenguaje coloquial o en otras palabras? Que te crees menos bueno, de lo que realmente eres en tu profesión. Es decir, tú tienes unos conocimientos, pero tú no los valoras. Por algún motivo, crees que no eres lo suficientemente bueno para dedicarte a eso. El caso opuesto: el efecto Dunning-Kruger Para entenderlo mejor, el caso totalmente contrario sería, creerse más bueno de lo que realmente eres. Es decir, sin saber nada, creerte que eres el mejor. Esto también tiene un nombre y es el efecto Dunning-Kruger que, si volvemos a Wikipedia nos dice que es un sesgo cognitivo según el cual los individuos, con escasa habilidad o conocimientos sufren de un sentimiento de superioridad ilusorio, considerándose más inteligentes que otras personas más preparadas. Ambos síndromes, lo que hacen, es distorsionar la realidad de los conocimientos que tu tienes. En el caso del síndrome del impostor, tu tienes unos conocimientos buenos o normales, y tú crees que estás por debajo de eso y que no eres lo suficientemente bueno; que eres peor de lo que realmente tú eres. Y, en el caso del síndrome Dunning-Kruger, es exactamente el síndrome contrario: tú tienes unos conocimientos muy escasos, pero te crees que estás muy por encima. ¿A quién afecta el síndrome del impostor? Entonces, ¿Quién y cuándo puede sentir el síndrome del impostor? La verdad puede ser en casi cualquier profesión y en distintos ámbitos. De todas maneras, como he dicho, en este capítulo lo vamos a enfocar dentro de los programadores. Por ejemplo, un freelance, alguien que se dedica de forma autónoma a desarrollar para otras personas o empresas. Puede sentir este síndrome del impostor en el momento que empieza a cobrar por sus servicios; en el momento en el que dice “Vale, voy a dedicarme a esto”.  ¿Por qué? Porque se puede hacer preguntas como: ¿Realmente se lo suficiente para cobrar por ello? o ¿no estaré cobrando demasiado por lo que sé? Es decir, se siente inseguro de lo que él sabe. O, por ejemplo, cuando colabora con otros programadores, puede sentir miedo de no dar la talla ante las expectativas que haya podido generar. De la misma manera, esto también no tiene por qué ser únicamente en un freelance. También, se puede dar con un programador en una empresa. Por ejemplo, sentir que pregunta demasiado a los compañeros, sentirse inferior a ellos, que pueda tardar más en hacer según que cosas… ese complejo de inferioridad, es exactamente lo mismo que antes. En resumen, casi cualquier profesional, en casi cualquier ámbito puede sentir este síndrome del impostor, pero, ¿sabéis qué? Es completamente normal. Hasta una persona que lleve 5 años programando, en la profesión, y que se esté dedicando a una tecnología, puede sentir ese síndrome del impostor en uno u otro nivel. Es una cosa que la puedes sentir tanto cuando empiezas como cuando ya llevas años. El síndrome del impostor: reflejo de algo bueno También hay que decir que, hasta cierto punto, es bueno. Es decir, mejor pensar que no sabes tanto, a pensar que lo sabes todo (el síndrome contrario que contábamos anteriormente). Sobre todo en el mundo de la programación porque eso quiere decir que te preocupas por tus conocimientos y que, por lo tanto, vas a querer seguir mejorando. Es decir, mejor sentir que no sabes tanto, a sentir que lo sabes todo, no sé si me explico. Si tu sientes que ya lo sabes todo, no te vas a esforzar por seguir mejorando. En cambio, si tu sientes que sabes menos de lo que realmente sabes, lo que vas a hacer, es seguir mejorando. De todas maneras, obviamente, tenemos que encontrar un equilibrio entre lo que sabemos y lo que nosotros pensamos que sabemos. Además, en la programación es algo, como digo, completamente normal, porque es un mundo cambiante, en el que lo que vale hoy, no vale mañana. Existen cientos de tecnologías y lenguajes. Incluso, si estás especializado en una sola tecnología, a veces son inacabables de por sí.  Por ejemplo, en mi caso, en Android yo no sé, ni sabré nunca, absolutamente todo lo que hay en Android; es directamente imposible. Y como Android, hay muchas otras como iOS o tecnologías web; es lo mismo para todas. Es imposible acabárselas de arriba abajo. Lo mismo pasa con la tecnología, no habrá nadie que sepa absolutamente de todo. Los habrá quienes sepan más; los habrá quienes sepan menos pero no somos máquinas y no lo podemos saber todos. Somos humanos y la magia de la programación reside ahí, en experimentar problemas nuevos día a día y solucionarlos. Si lo supiéramos exactamente todo y responderíamos como robots pues la verdad, perdería un poco su gracia. Minimizar el síndrome del impostor Ahora que ya hemos visto qué es el síndrome del impostor y lo hemos situado un poco (quién y cuándo lo puede sentir), vamos a ver cómo se puede evitar o minimizarlo por lo menos.  En primer lugar, debemos asumir lo que hemos comentado justo ahora: el mundo de la programación es un mundo enorme y cambiante y, absolutamente nadie lo sabe todo. Lo único que podemos hacer es esforzarnos y mejorar día a día en lo que hacemos. Por ejemplo, a la hora de cobrar, que es un momento en el que el síndrome del impostor puede salir a flote (ya sea como freelance o como trabajador de una empresa), lo que tenemos que hacer es pedir un sueldo acorde con nuestros conocimientos. Cobrando un precio apropiado Por ejemplo, en el caso que seas un freelance, si llevas un año programando en Android, obviamente no puedes pedir 100 euros la hora; está desproporcionado, no vas a dar la talla ante las expectativas que estás generando. Puedes empezar pidiendo 15, 20 o 30 euros (ya va a depender de muchas cosas). A partir de ahí, va a ir subiendo año tras año, a medida que tus conocimientos van mejorando. Si pones un precio demasiado alto en un inicio y, tus conocimientos no son los suficientes como para justificarlo, entonces no es que se esté dando el síndrome del impostor, sino que realmente estás siendo un impostor. Otra de las cosas que podemos hacer, es rodearnos de personas mejores que nosotros. Por ejemplo, en este caso de programadores de más experiencia en la tecnología que estamos utilizando; que llevan más años y, por lo tanto, saben más. Lo que sabremos seguro es que somos las personas con menos experiencia y ya no nos tendremos que preocupar si somos mejores o no. Por otro lado, vas a aprender más que nadie y, sobre todo, tienes que ser curioso y preguntar ante cualquier duda. Ya sabes, si quieres ser grande, rodéate de gigantes. La especialización como medio para evitar el síndrome del impostor Otro de los puntos que tenemos que tener en cuenta, es la especialización. La mejor manera de no sentirse un intruso en la programación, es especializarte. Por ejemplo, una persona (que yo he visto) que se anuncia como desarrollador freelance y dice hacer PHP, JavaScript, Android, iOS … no digo que no sepa hacerlo todo, pero, pongo en duda que sea un experto en todos ellos. Y si lo fuera, la verdad me quito el sombrero. En mi opinión, mejor elegir una tecnología y aprenderla bien. Con eso que vas a hacer te vas a sentir más seguro y te vas a hacer experto en esa tecnología. De esta manera, vas a reducir ese síndrome del impostor porque realmente tú vas a estar especializado en esa tecnología. Es imposible dominar muchas tecnologías: el que mucho abarca, poco aprieta y, mucho más en la programación. Además, la especialización se valora mucho. Imagina que tienes que contratar a alguien para hacer una aplicación de Android, ¿a quién escogerías antes?, ¿a una persona que únicamente se dedica al desarrollo de Android, o a una persona que dice dedicarse a Android, iOS, PHP, JavaScript, Python, etc.? En mi caso, me decantaría por una persona que únicamente esté especializada en Android. Sobre todo, cuando sientas este síndrome del impostor, cuanto te atasques en algo o cuando te sientas inferior a alguien, recuerda todo lo que sabes hoy y que no sabias el año pasado. Recuerda que, si estás progresando año tras año, solo es cuestión de tiempo para ser mejor. Claro, si no estás progresando año tras año; si de un año a otro, no has aprendido nada nuevo y sigues teniendo lo mismos conocimientos, entonces preocúpate. The post 13. El síndrome del impostor en los programadores appeared first on Diego Laballós.

¿Qué es esto del síndrome del impostor? Si nos vamos a Wikipedia, donde normalmente no vamos a encontrar definiciones muy formales (este también es el caso) encontramos lo siguiente: fenómeno psicológico en el que la gente es incapaz de interiorizar sus logros. A pesar de las evidencias externas de su competencia, aquellos con el síndrome permanecen convencidos de que son un fraude y no merecen el éxito que han conseguido. <h3>¿Qué es el síndrome del impostor?</h3> ¿Qué quiere decir esto en lenguaje coloquial o en otras palabras? Que te crees menos bueno, de lo que realmente eres en tu profesión. Es decir, tú tienes unos conocimientos, pero tú no los valoras. Por algún motivo, crees que no eres lo suficientemente bueno para dedicarte a eso. <h3>El caso opuesto: el efecto Dunning-Kruger</h3> Para entenderlo mejor, el caso totalmente contrario sería, creerse más bueno de lo que realmente eres. Es decir, sin saber nada, creerte que eres el mejor. Esto también tiene un nombre y es el efecto Dunning-Kruger que, si volvemos a Wikipedia nos dice que es un sesgo cognitivo según el cual los individuos, con escasa habilidad o conocimientos sufren de un sentimiento de superioridad ilusorio, considerándose más inteligentes que otras personas más preparadas. Ambos síndromes, lo que hacen, es distorsionar la realidad de los conocimientos que tu tienes. En el caso del síndrome del impostor, tu tienes unos conocimientos buenos o normales, y tú crees que estás por debajo de eso y que no eres lo suficientemente bueno; que eres peor de lo que realmente tú eres. Y, en el caso del síndrome Dunning-Kruger, es exactamente el síndrome contrario: tú tienes unos conocimientos muy escasos, pero te crees que estás muy por encima. <h3>¿A quién afecta el síndrome del impostor?</h3> Entonces, ¿Quién y cuándo puede sentir el síndrome del impostor? La verdad puede ser en casi cualquier profesión y en distintos ámbitos. De todas maneras, como he dicho, en este capítulo lo vamos a enfocar dentro de los programadores. Por ejemplo, un freelance, alguien que se dedica de forma autónoma a desarrollar para otras personas o empresas. Puede sentir este síndrome del impostor en el momento que empieza a cobrar por sus servicios; en el momento en el que dice “Vale, voy a dedicarme a esto”. ¿Por qué? Porque se puede hacer preguntas como: ¿Realmente se lo suficiente para cobrar por ello? o ¿no estaré cobrando demasiado por lo que sé? Es decir, se siente inseguro de lo que él sabe. O, por ejemplo, cuando colabora con otros programadores, puede sentir miedo de no dar la talla ante las expectativas que haya podido generar. De la misma manera, esto también no tiene por qué ser únicamente en un freelance. También, se puede dar con un programador en una empresa. Por ejemplo, sentir que pregunta demasiado a los compañeros, sentirse inferior a ellos, que pueda tardar más en hacer según que cosas… ese complejo de inferioridad, es exactamente lo mismo que antes. En resumen, casi cualquier profesional, en casi cualquier ámbito puede sentir este síndrome del impostor, pero, ¿sabéis qué? Es completamente normal. Hasta una persona que lleve 5 años programando, en la profesión, y que se esté dedicando a una tecnología, puede sentir ese síndrome del impostor en uno u otro nivel. Es una cosa que la puedes sentir tanto cuando empiezas como cuando ya llevas años. <h3>El síndrome del impostor: reflejo de algo bueno</h3> También hay que decir que, hasta cierto punto, es bueno. Es decir, mejor pensar que no sabes tanto, a pensar que lo sabes todo (el síndrome contrario que contábamos anteriormente). Sobre todo en el mundo de la programación porque eso quiere decir que te preocupas por tus conocimientos y que, por lo tanto, vas a querer seguir mejorando. Es decir, mejor sentir que no sabes tanto, a sentir que lo sabes todo, no sé si me explico. Si tu sientes que ya lo sabes todo, no te vas a esforzar por seguir mejorando. En cambio, si tu sientes que sabes menos de lo que realmente sabes, lo que vas a hacer, es seguir mejorando. De todas maneras, obviamente, tenemos que encontrar un equilibrio entre lo que sabemos y lo que nosotros pensamos que sabemos. Además, en la programación es algo, como digo, completamente normal, porque es un mundo cambiante, en el que lo que vale hoy, no vale mañana. Existen cientos de tecnologías y lenguajes. Incluso, si estás especializado en una sola tecnología, a veces son inacabables de por sí. Por ejemplo, en mi caso, en Android yo no sé, ni sabré nunca, absolutamente todo lo que hay en Android; es directamente imposible. Y como Android, hay muchas otras como iOS o tecnologías web; es lo mismo para todas. Es imposible acabárselas de arriba abajo. Lo mismo pasa con la tecnología, no habrá nadie que sepa absolutamente de todo. Los habrá quienes sepan más; los habrá quienes sepan menos pero no somos máquinas y no lo podemos saber todos. Somos humanos y la magia de la programación reside ahí, en experimentar problemas nuevos día a día y solucionarlos. Si lo supiéramos exactamente todo y responderíamos como robots pues la verdad, perdería un poco su gracia. <h3>Minimizar el síndrome del impostor</h3> Ahora que ya hemos visto qué es el síndrome del impostor y lo hemos situado un poco (quién y cuándo lo puede sentir), vamos a ver cómo se puede evitar o minimizarlo por lo menos. En primer lugar, debemos asumir lo que hemos comentado justo ahora: el mundo de la programación es un mundo enorme y cambiante y, absolutamente nadie lo sabe todo. Lo único que podemos hacer es esforzarnos y mejorar día a día en lo que hacemos. Por ejemplo, a la hora de cobrar, que es un momento en el que el síndrome del impostor puede salir a flote (ya sea como freelance o como trabajador de una empresa), lo que tenemos que hacer es pedir un sueldo acorde con nuestros conocimientos. <h3>Cobrando un precio apropiado</h3> Por ejemplo, en el caso que seas un freelance, si llevas un año programando en Android, obviamente no puedes pedir 100 euros la hora; está desproporcionado, no vas a dar la talla ante las expectativas que estás generando. Puedes empezar pidiendo 15, 20 o 30 euros (ya va a depender de muchas cosas). A partir de ahí, va a ir subiendo año tras año, a medida que tus conocimientos van mejorando. Si pones un precio demasiado alto en un inicio y, tus conocimientos no son los suficientes como para justificarlo, entonces no es que se esté dando el síndrome del impostor, sino que realmente estás siendo un impostor. Otra de las cosas que podemos hacer, es rodearnos de personas mejores que nosotros. Por ejemplo, en este caso de programadores de más experiencia en la tecnología que estamos utilizando; que llevan más años y, por lo tanto, saben más. Lo que sabremos seguro es que somos las personas con menos experiencia y ya no nos tendremos que preocupar si somos mejores o no. Por otro lado, vas a aprender más que nadie y, sobre todo, tienes que ser curioso y preguntar ante cualquier duda. Ya sabes, si quieres ser grande, rodéate de gigantes. <h3>La especialización como medio para evitar el síndrome del impostor</h3> Otro de los puntos que tenemos que tener en cuenta, es la especialización. La mejor manera de no sentirse un intruso en la programación, es especializarte. Por ejemplo, una persona (que yo he visto) que se anuncia como desarrollador freelance y dice hacer PHP, JavaScript, Android, iOS … no digo que no sepa hacerlo todo, pero, pongo en duda que sea un experto en todos ellos. Y si lo fuera, la verdad me quito el sombrero. En mi opinión, mejor elegir una tecnología y aprenderla bien. Con eso que vas a hacer te vas a sentir más seguro y te vas a hacer experto en esa tecnología. De esta manera, vas a reducir ese síndrome del impostor porque realmente tú vas a estar especializado en esa tecnología. Es imposible dominar muchas tecnologías: el que mucho abarca, poco aprieta y, mucho más en la programación. Además, la especialización se valora mucho. Imagina que tienes que contratar a alguien para hacer una aplicación de Android, ¿a quién escogerías antes?, ¿a una persona que únicamente se dedica al desarrollo de Android, o a una persona que dice dedicarse a Android, iOS, PHP, JavaScript, Python, etc.? En mi caso, me decantaría por una persona que únicamente esté especializada en Android. Sobre todo, cuando sientas este síndrome del impostor, cuanto te atasques en algo o cuando te sientas inferior a alguien, recuerda todo lo que sabes hoy y que no sabias el año pasado. Recuerda que, si estás progresando año tras año, solo es cuestión de tiempo para ser mejor. Claro, si no estás progresando año tras año; si de un año a otro, no has aprendido nada nuevo y sigues teniendo lo mismos conocimientos, entonces preocúpate. The post <a href="https://diegolaballos.com/podcast/13-el-sindrome-del-impostor-en-los-programadores/" rel="nofollow" target="_blank">13. El síndrome del impostor en los programadores</a> appeared first on <a href="https://diegolaballos.com" rel="nofollow" target="_blank">Diego Laballós</a>.

13. El síndrome del impostor en los programadores

The best podcast episodes on Startups. For anyone working in a startup, or anyone interested in the incredible stories behind how people built companies like Instagram, and Facebook. Offering both practical advice and insights, as well as the stories for how many of the biggest startups got to where they are today. Add episodes you're interested into your queue below!

OwlTail

Best Startups Podcasts

The best podcast episodes on non-current politics. Covering topics such as universal basic income, democracy, poverty & justice and more. For anyone interested in learning more about politics that affect that world, not just now, but in the longer term. Add episodes you're interested into your queue below!