Como alguien que por azares de la vida terminó asentándose como ingeniero de build de apps Android, si dejara una opinión...
> Build: gradle
Aunque sea muy grande o muy complejo, hay que usar gradle... (mirando al horizonte)
Como se están llevando adelante los siguientes proyectos para mejorar el rendimiento de build de gradle en proyectos muy grandes o complejos, si usan gradle en un proyecto grande conviene ir preparando la migración con anticipación.
> Configuración de módulos: separación por feature
Personalmente, no veo razón para exponer innecesariamente las capas de arquitectura al sistema de build.
En el caso de la app que administro, hacemos que el sistema de build exponga los módulos como feature-api / feature-impl.
feature-app :
Modelo de datos, o interfaces vinculadas con otros módulos
feature-impl:
Implementación real de la feature
Si se configura así, los cambios de código en feature-impl no afectan a otros módulos que referencian feature-api (aislamiento de dependencias), así que ayuda mucho a mejorar el incremental build y la tasa de aciertos del build cache.
> Pruebas unitarias - junit 4
Creo que aquí la decisión de Google tuvo un papel importante.
Parece que últimamente se están poniendo de moda otra vez los servicios que limitan la cantidad de veces o el tiempo de uso, pero me pregunto si no terminará apagándose después del boom inicial, como esa app de hace un tiempo cuyo nombre no recuerdo bien, donde la gente hablaba como si fuera una especie de transmisión.
Que la carga del CPU de una computadora esté al 100% no es normal,
pero cuando la carga de trabajo de las personas está al 100%, la conclusión es que hay que esforzarse más..
Mmm... como comentario al margen, en los últimos años se ha observado un fenómeno curioso: la mayoría de las startups usan Flutter, mientras que las grandes empresas como META y OpenAI optan por nativo..
¡Es una noticia muy bienvenida! Curiosamente, el lenguaje TypeScript de MS parece tomar muchas decisiones realmente inesperadas, más de lo que uno imaginaría. Desde la perspectiva de MS, al ser casi su primer proyecto de código abierto, también se sintió muy acertada la decisión de complementar JavaScript, a diferencia de Dart de Google, que intentaba reemplazar JS; y ahora también sorprende que, aunque seguramente tenían varios lenguajes propios para elegir en este port nativo, hayan optado por Go de Google.
He usado tipos genéricos construidos con recursión y se volvían lentos, así que terminé usando alternativas. Si realmente es 10 veces más rápido, me ilusiona pensar que también podrían mejorar esas partes.
Como alguien que por azares de la vida terminó asentándose como ingeniero de build de apps Android, si dejara una opinión...
> Build: gradle
Aunque sea muy grande o muy complejo, hay que usar gradle... (mirando al horizonte)
Como se están llevando adelante los siguientes proyectos para mejorar el rendimiento de build de gradle en proyectos muy grandes o complejos, si usan gradle en un proyecto grande conviene ir preparando la migración con anticipación.
> Configuración de módulos: separación por feature
Personalmente, no veo razón para exponer innecesariamente las capas de arquitectura al sistema de build.
En el caso de la app que administro, hacemos que el sistema de build exponga los módulos como feature-api / feature-impl.
Si se configura así, los cambios de código en feature-impl no afectan a otros módulos que referencian feature-api (aislamiento de dependencias), así que ayuda mucho a mejorar el incremental build y la tasa de aciertos del build cache.
> Pruebas unitarias - junit 4
Creo que aquí la decisión de Google tuvo un papel importante.
Sin embargo, el plugin de screenshot testing lanzado recientemente está basado en JUnit5.
Parece Clubhouse; de hecho, eso mismo fue lo primero que se me vino a la mente.
Parece que últimamente se están poniendo de moda otra vez los servicios que limitan la cantidad de veces o el tiempo de uso, pero me pregunto si no terminará apagándose después del boom inicial, como esa app de hace un tiempo cuyo nombre no recuerdo bien, donde la gente hablaba como si fuera una especie de transmisión.
Vaya, qué honor para la familia Hutt.
Parece que el tráfico se va a concentrar muchísimo solo en ese horario, así que hará falta manejarlo de forma eficiente.
Me preocupa que más adelante se descuide el mantenimiento de la base de código existente de TypeScript.
No es que el desarrollo del lenguaje C# se haya detenido, pero siento demasiado que los frameworks que usan C# están siendo descuidados.
Lo estoy probando, y se siente como una especie de paquete surtido de todo.
Se repiten textos parecidos, pero la ambición humana no tiene fin y seguimos repitiendo los mismos errores
Que la carga del CPU de una computadora esté al 100% no es normal,
pero cuando la carga de trabajo de las personas está al 100%, la conclusión es que hay que esforzarse más..
Mmm... como comentario al margen, en los últimos años se ha observado un fenómeno curioso: la mayoría de las startups usan Flutter, mientras que las grandes empresas como META y OpenAI optan por nativo..
Claro, también entiendo cómo se sienten los desarrolladores de .NET...
¡Es una noticia muy bienvenida! Curiosamente, el lenguaje TypeScript de MS parece tomar muchas decisiones realmente inesperadas, más de lo que uno imaginaría. Desde la perspectiva de MS, al ser casi su primer proyecto de código abierto, también se sintió muy acertada la decisión de complementar JavaScript, a diferencia de Dart de Google, que intentaba reemplazar JS; y ahora también sorprende que, aunque seguramente tenían varios lenguajes propios para elegir en este port nativo, hayan optado por Go de Google.
Los desarrolladores de .NET y Rust están bastante enojados.
Brother, actualización de firmware forzada que impide usar cartuchos de tinta de impresora de terceros
Vaya, pero ya debía haber algo del lado de deno que hizo un toolchain basado en Rust... ¿de repente ahora es Go?
He usado tipos genéricos construidos con recursión y se volvían lentos, así que terminé usando alternativas. Si realmente es 10 veces más rápido, me ilusiona pensar que también podrían mejorar esas partes.
Está interesante el hilo de discusión sobre por qué Go.
https://github.com/microsoft/typescript-go/discussions/411
Y también hay muchas cosas que pensar...
Veo que muchas personas terminan cayendo en la opción 4, y es muy lamentable.
Escribe en Go~
Justo este año estoy pensando en intentar hacer una app para Android, así que fue una guía muy útil. Jaja