En mi opinión, en las apps híbridas la forma común de comunicación entre web y app es mediante APIs proporcionadas por el SO y el navegador, también llamadas bridges. No creo que un servidor web local sea indispensable.
Creo que el problema de usar un servidor web local ahí es que, por ejemplo, se pueden dar vulnerabilidades como acceder a un puerto de localhost desde Chrome en modo incógnito y romper el anonimato del usuario. Si esta tecnología fuera indispensable en las apps híbridas... entonces las apps híbridas deberían desaparecer.
Es un artículo muy sustancioso. No solo hacen falta herramientas potentes, también hay que estar dispuesto a crear las herramientas necesarias cuando haga falta. Por eso, si todo funciona bien, también se obtienen muchos beneficios.
Parece que en Corea la situación también es similar. Me da la impresión de que, para conseguir empleo, más bien conviene combinar otra carrera con habilidades de programación, como biología + programación. Con el desarrollo de todo tipo de frameworks y la nube, y la aparición de herramientas de LLM, la barrera de entrada para programar ha bajado, así que (como antes pasó de ensamblador -> lenguaje C -> Python) parece que, además de saber programar, hay que saber hacer otras cosas para poder entrar al mercado laboral.
Definitivamente es útil cuando quieres escribir un script simple de un solo uso. Ahorra muchísimo tiempo.
También sirve en casos que hay que resolver, pero en los que no puedes invertir mucho tiempo. Eso sí, aunque por ahora en general es útil, todavía no puede reemplazar por completo a una persona. No sé cuánto vaya a avanzar en el futuro, pero por ahora, como asistente, está más o menos en un nivel bastante usable.
Cuando estaba en la maestría, una vez mi asesor volvió de una comida con un ingeniero que había trabajado en Google y, no sé si porque escuchó hablar de monorepos, propuso que nosotros también los administráramos así en adelante; me costó bastante convencerlo de que no lo hiciéramos...
Aunque los monorepos tienen muchas ventajas, en nuestro laboratorio, por su naturaleza, era frecuente tener que compartir los resultados con personas externas, y si hubiéramos gestionado esos resultados en un monorepo, creo que habríamos sufrido bastante justo por eso. Con un multirepo, en cambio, simplemente puedes ajustar el alcance de publicación para cada resultado.
Creo que la mayoría de las veces que uno sufre con un monorepo es porque ya fragmentó demasiado el proyecto desde antes. Tomas un proyecto que originalmente pudo haber sido uno o dos y lo divides en unos 10; luego intentas integrarlo y gestionarlo con un monorepo, así que terminas necesitando también herramientas de gestión de monorepos y la complejidad sube. Es mejor simplemente integrar el proyecto en uno o dos, y aunque sean dos o más proyectos, en vez de usar una herramienta de gestión aparte, pensar solo en separarlos por directorios y ponerlos en un solo repositorio hace que sea mucho más fácil de administrar.
Qué raro, consumía mucha batería, así que había borrado todas las apps de Meta, y resulta que estaba pasando algo así... Creo que también voy a tener que borrar con adb todas las demás apps del sistema integradas en mi Galaxy.
¡Qué va a saber la gente!
Conseguir trabajo está brutal. Viéndolo desde otra perspectiva, también es ideal para crear un servicio unipersonal...
Por más que les ruegues que no lo hagan así, 1 de cada 10 tipos igual lo hace -_-
Muchas gracias por el buen artículo.
Yo también quiero vivir así como desarrollador independiente.
En mi opinión, en las apps híbridas la forma común de comunicación entre web y app es mediante APIs proporcionadas por el SO y el navegador, también llamadas bridges. No creo que un servidor web local sea indispensable.
Creo que el problema de usar un servidor web local ahí es que, por ejemplo, se pueden dar vulnerabilidades como acceder a un puerto de localhost desde Chrome en modo incógnito y romper el anonimato del usuario. Si esta tecnología fuera indispensable en las apps híbridas... entonces las apps híbridas deberían desaparecer.
¡Gracias por la rápida retroalimentación~
Es un artículo muy sustancioso. No solo hacen falta herramientas potentes, también hay que estar dispuesto a crear las herramientas necesarias cuando haga falta. Por eso, si todo funciona bien, también se obtienen muchos beneficios.
Parece que en Corea la situación también es similar. Me da la impresión de que, para conseguir empleo, más bien conviene combinar otra carrera con habilidades de programación, como biología + programación. Con el desarrollo de todo tipo de frameworks y la nube, y la aparición de herramientas de LLM, la barrera de entrada para programar ha bajado, así que (como antes pasó de ensamblador -> lenguaje C -> Python) parece que, además de saber programar, hay que saber hacer otras cosas para poder entrar al mercado laboral.
¡Mis aplausos!
Definitivamente es útil cuando quieres escribir un script simple de un solo uso. Ahorra muchísimo tiempo.
También sirve en casos que hay que resolver, pero en los que no puedes invertir mucho tiempo. Eso sí, aunque por ahora en general es útil, todavía no puede reemplazar por completo a una persona. No sé cuánto vaya a avanzar en el futuro, pero por ahora, como asistente, está más o menos en un nivel bastante usable.
Cuando estaba en la maestría, una vez mi asesor volvió de una comida con un ingeniero que había trabajado en Google y, no sé si porque escuchó hablar de monorepos, propuso que nosotros también los administráramos así en adelante; me costó bastante convencerlo de que no lo hiciéramos...
Aunque los monorepos tienen muchas ventajas, en nuestro laboratorio, por su naturaleza, era frecuente tener que compartir los resultados con personas externas, y si hubiéramos gestionado esos resultados en un monorepo, creo que habríamos sufrido bastante justo por eso. Con un multirepo, en cambio, simplemente puedes ajustar el alcance de publicación para cada resultado.
Es un buen artículo ~
Ah, lo resolví de otra manera. ¡Gracias!
Creo que la mayoría de las veces que uno sufre con un monorepo es porque ya fragmentó demasiado el proyecto desde antes. Tomas un proyecto que originalmente pudo haber sido uno o dos y lo divides en unos 10; luego intentas integrarlo y gestionarlo con un monorepo, así que terminas necesitando también herramientas de gestión de monorepos y la complejidad sube. Es mejor simplemente integrar el proyecto en uno o dos, y aunque sean dos o más proyectos, en vez de usar una herramienta de gestión aparte, pensar solo en separarlos por directorios y ponerlos en un solo repositorio hace que sea mucho más fácil de administrar.
Se arregla dándole
min-width: 0a.topic_contents.min-widthrealmente da muchos dolores de cabeza...Parece que, por la tabla, el diseño en móvil se rompe.
Una historia con la que conecté por completo
La parte de “haz lo que te gusta” es algo en lo que siempre había pensado mucho, así que leí asintiendo totalmente.
¿Cómo se supera esa dura etapa inicial sin motivación intrínseca?
Qué raro, consumía mucha batería, así que había borrado todas las apps de Meta, y resulta que estaba pasando algo así... Creo que también voy a tener que borrar con
adbtodas las demás apps del sistema integradas en mi Galaxy.Cada vez que los veo gritando "la singularidad se acerca", de verdad es agotador.
¿Esto no es una vulnerabilidad de seguridad? -_-??