Ah, no estoy intentando menospreciar la visión futura de OpenAI ni la innovación mejorada de Browser+AI.
Lo que quiero decir es que, si OpenAI intentara avanzar en esa dirección, dado que navegadores importantes como Chromium o Firefox están disponibles públicamente, no creo que sea una situación en la que una adquisición aparte sea necesaria para el desarrollo.
El punto es que una adquisición no es indispensable para crear un foso tecnológico.
Por eso, si consideraran una adquisición, creo que estaría impulsada más por la expansión a través de la cuota de mercado que por el aspecto técnico.
Si simplemente lanzaran un nuevo navegador basado en Chromium, no habría un gran atractivo para los usuarios que no se cambiarían desde Chrome, pero si adquirieran Chrome, podrían permitir oficialmente, mediante actualizaciones, que los usuarios que representan el 70% del mercado de navegadores prueben sus servicios de modelos de IA. La barrera de expansión de un servicio nuevo se reduciría de forma drástica.
Como dijiste, el hecho de que Edge no se esté expandiendo parece verse en un contexto similar. El mercado de los navegadores es realmente conservador. Creo que OpenAI también considera este punto al contemplar la adquisición de Chrome. Por eso, cuando se habla de que OpenAI abriría una "navegación web impulsada por IA", creo que pesa más la influencia del mercado de Chrome que las capacidades de OpenAI.
Supabase se caracteriza por ser adecuado para sistemas basados en CRUD, y como permite implementar CRUD desde el frontend sin necesidad de desarrollar ni operar un servidor de API, la carga de desarrollo de backend es menor. Los desarrolladores de frontend y backend se comunican mediante la definición de tablas en lugar de contratos de API, y las funciones que más se usan son la consola web, la autenticación y el almacenamiento de objetos.
Como el frontend depende de las definiciones de tablas, vistas y funciones de la base de datos, hay que poner algo de atención al seguimiento de cambios en los datos. Si necesitan lógica del lado del servidor, creo que es mejor construir por separado un WAS o una REST API.
Es un servicio que me gusta muchísimo. Puedes crear un servicio solo con el frontend, sin configuraciones complejas de backend/DB.
De hecho, lo estoy usando bastante porque quiero aplicarlo en un servicio real, y para mí la experiencia de desarrollo fue incluso mejor que con Firebase.
También tiene región en Corea y ofrece un free tier bastante generoso, lo cual está muy bien. Además, se puede hacer self-hosting.
¡Qué buena noticia que haya conseguido una Serie D! Aunque, como se sigue mencionando en las opiniones, sí me preocupa si es un negocio sostenible.
En mi opinión personal, usar servicios serverless de un proveedor es arriesgado, pero ofrecer internamente un entorno serverless en la propia empresa usando contenedores me parece una buena idea. Creo que sería bueno aprovechar lo serverless no como un servicio, sino como un concepto.
Hay muchas personas que trabajan con pasión por la tecnología informática. No generalices a partir de tus propias ideas y experiencias. Es ofensivo para ellas.
Hay problemas que surgen porque, a diferencia del pasado, el alcance del que una sola persona tiene que hacerse cargo se ha ampliado.
•Es cierto que, en comparación con antes, lo que se espera de un solo ingeniero se ha vuelto más amplio y mayor. Y, comparado con el pasado, una porción muchísimo más grande del mundo real ha entrado en los sistemas informáticos, y en esa misma medida la dificultad de abstraer e implementar también está aumentando rápidamente. No creo que haya necesidad de enumerar trabajos más difíciles en el mundo real para afirmar que este no es un trabajo duro...
•Aunque el título está traducido como que es una locura, creo que más bien expresa la situación actual, que simplemente te deja sin energías. Y yo empatizo hasta cierto punto con el texto principal. Es cierto que, en comparación con el pasado, lo que se espera de un solo ingeniero se ha vuelto más amplio y mayor. Además, en comparación con antes, muchísimas más partes del mundo real han entrado en los sistemas informáticos, y en esa misma medida la abstracción y la dificultad de implementación están aumentando rápidamente. Aunque se enumeren tareas más difíciles en la vida real, no creo que haya necesidad de afirmar que este trabajo no es difícil...
Pero ese es un ejemplo completamente distinto, ¿no? ¿Dicen que con hacer rollback ya está? La experiencia de una sola persona no lo es todo. ¿No han trabajado en tareas de gran escala?
•Creo que hay un malentendido de que el desarrollo de software consiste simplemente en generar código o crear APIs. La esencia del desarrollo de software está en abstraer la realidad para crear protocolos e interfaces, y encajar las cosas dentro de eso. Se trata de conectar elementos que funcionan de maneras distintas para que operen como si fueran uno solo. Esta es una actividad intelectual más compleja de lo que parece, y por eso es más difícil de lo que se piensa formar ingenieros de software. Dicen que ahora hay mucha gente, pero ¿cuántos de ellos son realmente capaces de trabajar bien? La mayoría apenas ha usado alguna herramienta una vez, pero eso no es el núcleo de lo que hace un ingeniero de software.
•¿Realmente tiene sentido compararlo directamente con la manufactura? Desde la perspectiva de que la industria no ha alcanzado un nivel suficiente de sofisticación, parece que el punto de comparación es la manufactura. Si se intenta entender la industria del software con el paradigma de la manufactura, puede verse como artesanía o desarrollo por hobby, pero por otro lado creo que justamente estos aspectos crean una cultura flexible y creativa propia del desarrollo de software, y que esta crece apoyándose en ello.
•Es cierto que, en comparación con el pasado, lo que se espera de un solo ingeniero se ha vuelto más amplio y mayor. Y también, en comparación con antes, una porción mucho más grande del mundo real ha entrado en los sistemas computacionales, y con ello la dificultad de abstracción e implementación está aumentando rápidamente. No creo que sea necesario enumerar tareas más difíciles del mundo real para afirmar que este trabajo no es difícil...
•El entorno ha cambiado. No creo que la razón por la que las expectativas y la compensación hacia los desarrolladores han aumentado en el mercado, frente al pasado, sea solo su tecnología, experiencia o especialización. Cuanto más profundamente se integra la TI en la vida humana, más importante se vuelve el software, y este sostiene mucha infraestructura. No creo que la compensación haya aumentado porque las capacidades de cada desarrollador hayan crecido, sino porque simplemente el trabajo en sí se ha vuelto más caro. Porque se ha vuelto más importante que antes.
Hay críticas válidas aquí abajo. Que la tecnología de la computación sea accesible también se debe en gran parte a la contribución de los ingenieros de software. Y que sea accesible no significa que sea fácil volverse profesional. ¿Acaso porque la cocina es accesible es fácil convertirse en experto culinario?
•Es fácil de aprender. Lo reconozco, pero que la barrera de entrada sea baja no significa que la especialización también lo sea. Creo que, en comparación con otras industrias, especialmente con otros puestos técnicos de manufactura, la razón por la que es más fácil aprenderlo no es porque desarrollar sea fácil en sí, sino más bien por la cultura open source o por el bajo riesgo. Como dije antes sobre la diversidad de los desarrolladores, hay trabajos que puedes aprender rápido y hacer, y hay trabajos que deben basarse en la especialización.
•¿Porque aprendiste un poco de dibujo y entraste como asistente de un dibujante de cómics vas a andar diciendo que eres profesional? ¿O porque fuiste un poco a una escuela de cocina y conseguiste trabajo en una cocina vas a decir que eres experto culinario o chef? Es un nivel parecido a eso, lo que estás diciendo. Si fuera tan simple, no le dirían profesional.
Creo que una de las cosas más difíciles al desarrollar con Spring era la dependencia circular..
Esa frustración de que se inicialicen mutuamente de forma infinita y terminen colapsando por una fuga de memoria...
Estás criticando fuera de contexto. La persona que escribió la publicación original no está menospreciando a nadie, así que más bien, ¿no eres tú quien está degradando y restándole valor al puesto de ingeniero de software?
Hace 5 años, cuando empezó la beta pública, lo publiqué como noticia y hasta uno de los cofundadores vino a dejar un comentario; la verdad es que ha crecido muchísimo desde entonces jaja.
Inicio de la beta pública de Supabase - una alternativa open source a Firebase
Ah, no estoy intentando menospreciar la visión futura de OpenAI ni la innovación mejorada de Browser+AI.
Lo que quiero decir es que, si OpenAI intentara avanzar en esa dirección, dado que navegadores importantes como Chromium o Firefox están disponibles públicamente, no creo que sea una situación en la que una adquisición aparte sea necesaria para el desarrollo.
El punto es que una adquisición no es indispensable para crear un foso tecnológico.
Por eso, si consideraran una adquisición, creo que estaría impulsada más por la expansión a través de la cuota de mercado que por el aspecto técnico.
Si simplemente lanzaran un nuevo navegador basado en Chromium, no habría un gran atractivo para los usuarios que no se cambiarían desde Chrome, pero si adquirieran Chrome, podrían permitir oficialmente, mediante actualizaciones, que los usuarios que representan el 70% del mercado de navegadores prueben sus servicios de modelos de IA. La barrera de expansión de un servicio nuevo se reduciría de forma drástica.
Como dijiste, el hecho de que Edge no se esté expandiendo parece verse en un contexto similar. El mercado de los navegadores es realmente conservador. Creo que OpenAI también considera este punto al contemplar la adquisición de Chrome. Por eso, cuando se habla de que OpenAI abriría una "navegación web impulsada por IA", creo que pesa más la influencia del mercado de Chrome que las capacidades de OpenAI.
Lo estoy usando muchísimo para proyectos personales.
¿De repente Godot...?!
Supabase se caracteriza por ser adecuado para sistemas basados en CRUD, y como permite implementar CRUD desde el frontend sin necesidad de desarrollar ni operar un servidor de API, la carga de desarrollo de backend es menor. Los desarrolladores de frontend y backend se comunican mediante la definición de tablas en lugar de contratos de API, y las funciones que más se usan son la consola web, la autenticación y el almacenamiento de objetos.
Como el frontend depende de las definiciones de tablas, vistas y funciones de la base de datos, hay que poner algo de atención al seguimiento de cambios en los datos. Si necesitan lógica del lado del servidor, creo que es mejor construir por separado un WAS o una REST API.
A quienes quieren hacer proyectos paralelos, siempre les recomiendo Supabase como la primera opción. ¡Ojalá a Supabase le siga yendo aún mejor!
Es un servicio que me gusta muchísimo. Puedes crear un servicio solo con el frontend, sin configuraciones complejas de backend/DB.
De hecho, lo estoy usando bastante porque quiero aplicarlo en un servicio real, y para mí la experiencia de desarrollo fue incluso mejor que con Firebase.
También tiene región en Corea y ofrece un free tier bastante generoso, lo cual está muy bien. Además, se puede hacer self-hosting.
¡Qué buena noticia que haya conseguido una Serie D! Aunque, como se sigue mencionando en las opiniones, sí me preocupa si es un negocio sostenible.
En mi opinión personal, usar servicios serverless de un proveedor es arriesgado, pero ofrecer internamente un entorno serverless en la propia empresa usando contenedores me parece una buena idea. Creo que sería bueno aprovechar lo serverless no como un servicio, sino como un concepto.
La frase "quería una banana, pero trajo toda la jungla" está buenísima.
Piensa bien por qué otras personas lo critican tanto y deja de andar diciendo tonterías así con arrogancia, tú ahora o en el futuro.
Hay muchas personas que trabajan con pasión por la tecnología informática. No generalices a partir de tus propias ideas y experiencias. Es ofensivo para ellas.
Hay problemas que surgen porque, a diferencia del pasado, el alcance del que una sola persona tiene que hacerse cargo se ha ampliado.
•Es cierto que, en comparación con antes, lo que se espera de un solo ingeniero se ha vuelto más amplio y mayor. Y, comparado con el pasado, una porción muchísimo más grande del mundo real ha entrado en los sistemas informáticos, y en esa misma medida la dificultad de abstraer e implementar también está aumentando rápidamente. No creo que haya necesidad de enumerar trabajos más difíciles en el mundo real para afirmar que este no es un trabajo duro...
No hace falta compararlo.
•Aunque el título está traducido como que es una locura, creo que más bien expresa la situación actual, que simplemente te deja sin energías. Y yo empatizo hasta cierto punto con el texto principal. Es cierto que, en comparación con el pasado, lo que se espera de un solo ingeniero se ha vuelto más amplio y mayor. Además, en comparación con antes, muchísimas más partes del mundo real han entrado en los sistemas informáticos, y en esa misma medida la abstracción y la dificultad de implementación están aumentando rápidamente. Aunque se enumeren tareas más difíciles en la vida real, no creo que haya necesidad de afirmar que este trabajo no es difícil...
Pero ese es un ejemplo completamente distinto, ¿no? ¿Dicen que con hacer rollback ya está? La experiencia de una sola persona no lo es todo. ¿No han trabajado en tareas de gran escala?
•Creo que hay un malentendido de que el desarrollo de software consiste simplemente en generar código o crear APIs. La esencia del desarrollo de software está en abstraer la realidad para crear protocolos e interfaces, y encajar las cosas dentro de eso. Se trata de conectar elementos que funcionan de maneras distintas para que operen como si fueran uno solo. Esta es una actividad intelectual más compleja de lo que parece, y por eso es más difícil de lo que se piensa formar ingenieros de software. Dicen que ahora hay mucha gente, pero ¿cuántos de ellos son realmente capaces de trabajar bien? La mayoría apenas ha usado alguna herramienta una vez, pero eso no es el núcleo de lo que hace un ingeniero de software.
•¿Realmente tiene sentido compararlo directamente con la manufactura? Desde la perspectiva de que la industria no ha alcanzado un nivel suficiente de sofisticación, parece que el punto de comparación es la manufactura. Si se intenta entender la industria del software con el paradigma de la manufactura, puede verse como artesanía o desarrollo por hobby, pero por otro lado creo que justamente estos aspectos crean una cultura flexible y creativa propia del desarrollo de software, y que esta crece apoyándose en ello.
•Es cierto que, en comparación con el pasado, lo que se espera de un solo ingeniero se ha vuelto más amplio y mayor. Y también, en comparación con antes, una porción mucho más grande del mundo real ha entrado en los sistemas computacionales, y con ello la dificultad de abstracción e implementación está aumentando rápidamente. No creo que sea necesario enumerar tareas más difíciles del mundo real para afirmar que este trabajo no es difícil...
•El entorno ha cambiado. No creo que la razón por la que las expectativas y la compensación hacia los desarrolladores han aumentado en el mercado, frente al pasado, sea solo su tecnología, experiencia o especialización. Cuanto más profundamente se integra la TI en la vida humana, más importante se vuelve el software, y este sostiene mucha infraestructura. No creo que la compensación haya aumentado porque las capacidades de cada desarrollador hayan crecido, sino porque simplemente el trabajo en sí se ha vuelto más caro. Porque se ha vuelto más importante que antes.
Hay críticas válidas aquí abajo. Que la tecnología de la computación sea accesible también se debe en gran parte a la contribución de los ingenieros de software. Y que sea accesible no significa que sea fácil volverse profesional. ¿Acaso porque la cocina es accesible es fácil convertirse en experto culinario?
•Es fácil de aprender. Lo reconozco, pero que la barrera de entrada sea baja no significa que la especialización también lo sea. Creo que, en comparación con otras industrias, especialmente con otros puestos técnicos de manufactura, la razón por la que es más fácil aprenderlo no es porque desarrollar sea fácil en sí, sino más bien por la cultura open source o por el bajo riesgo. Como dije antes sobre la diversidad de los desarrolladores, hay trabajos que puedes aprender rápido y hacer, y hay trabajos que deben basarse en la especialización.
•¿Porque aprendiste un poco de dibujo y entraste como asistente de un dibujante de cómics vas a andar diciendo que eres profesional? ¿O porque fuiste un poco a una escuela de cocina y conseguiste trabajo en una cocina vas a decir que eres experto culinario o chef? Es un nivel parecido a eso, lo que estás diciendo. Si fuera tan simple, no le dirían profesional.
Creo que una de las cosas más difíciles al desarrollar con Spring era la dependencia circular..
Esa frustración de que se inicialicen mutuamente de forma infinita y terminen colapsando por una fuga de memoria...
Estás criticando fuera de contexto. La persona que escribió la publicación original no está menospreciando a nadie, así que más bien, ¿no eres tú quien está degradando y restándole valor al puesto de ingeniero de software?
+11111