Feda /dev/ - No Javascript allowed | Página 1177

eondev #35281 May '22

#35279 si vamos, un reto técnico de la ostia desarrollar una UI sobre Linux xD. Llevo esperandolo desde que existe Mono, y cuando leí sobre MAUI pensé que por fin darían el paso.
Qué cojones tienen la base ya hecha para Android.

2 respuestas

B

[Borrado] #35282 May '22

#35281 hola, instala windows, tendrás menos problemas

salu2 y buen foro

2 1 respuesta

eondev #35283 May '22

#35282 nah yo uso windows, el desktop de Linux me da sida

1 respuesta

B

[Borrado] #35284 May '22

#35283 entonces a qué viene tanta historia? Cada día entiendo más a desu

Soltrac #35285 May '22 MV Wizard

#35281 Nah pero con Android tenian toda la herencia de xamarin forms. Lo de linux, es que es lo que dicen por atrás, no se van a complicar la vida para un uso marginal.

Y que conste que yo habría hecho un wrap oficial de QT para maui o incluso mi propio set de controles nativos, pero vamos, no les ha apetecido y listo.

1 respuesta

eondev #35286 May '22

#35285 bueno pues flutter le termina comiéndose toda la tostada ggwp bien jugado.

1 respuesta

r2d2rigo #35287 May '22 Inocente

#35286 jaja flutter solo tiene que sacar un lenguaje, framework y runtime que no de asco.

2 1 respuesta

JuAn4k4 #35288 May '22

#35262 Tengo una lista en Notion de restaurantes, si quieres te lo paso por MP. Mi top son: Gente rara, Gamberro, La senda.
El Casa Pedro está bien pero para lo que es es carente, muy poco moderno, es clásico. El Goralai y el Urola son muy parecidos a muy buen precio.
Luego tienes otros como La Bamba que están muy bien, mas modernos y bien de precio.

A la Quema tengo pendiente ir que estuvo cerrado mucho tiempo.

eondev #35289 May '22

#35287 las stats hablan por sí mismas, a mí me da igual flutter, no lo voy a usar ni aprender. Pero estaría bien una alternativa seria y buena para hacer UI en Linux

1 respuesta

r2d2rigo #35290 May '22 Inocente

#35289 segun las stats del mundo chupipandero startuperil, si, Flutter es la polla con cebolla y ya nadie usa otra cosa para desarrollo movil.

Segun las stats del mundo enterprise, nadie toca Flutter ni con un palo y Xamarin tiene una cuota de mercado bastante alta.

Todo es segun del color del cristal con el que se mire

PiradoIV #35291 May '22 Brongster

El tema este de "hay que usar X porque todo el mundo lo usa"... no lo he pillado nunca, desde el punto de vista del programador (a nivel de empresa, sí que es entendible, hay más masillas disponibles). Es como el chiste ese de Millones de moscas no pueden estar equivocadas. Come mierda.

Si quieres entrar en una empresa donde usen X o Y tecnología concreta, te cuesta una semanilla aprender lo suficiente como para pasar una entrevista técnica. Si aprendes las bases y entiendes los motivos, en vez de las modas y el framework de turno, pues mejor.

BTW, ahora mismo la GUI de elementaryOS le da mil vueltas a la de Windows, que parece que sigue sin saber encontrar su propio camino. Las apps de elementaryOS son nativas, bonitas, consistentes, accesibles y ligeras. Linux ya no es lo que era, ha mejorado muchísimo.

Echadle un ojo a Xojo si queréis hacer apps nativas en Windows, macOS, Linux y iOS (y Web, claro). Se puede usar gratis para aprender, indefinidamente, nada más que hay que pagar si al final quieres pulsar en "Build". Si eres estudiante, tienes acceso gratis a la licencia Desktop, como parte del GitHub Student Developer Pack.

2 respuestas

Wei-Yu #35292 May '22

me río de los de .net por estar acoplados a un tooling concreto pero lo de xojo es next level

prefiero embarcadero

1 1 respuesta

PiradoIV #35293 May '22 Brongster

#35292 Evidentemente no estás poniendo tu boca donde tu cartera xD

desu #35294 May '22

#35291PiradoIV:
El tema este de "hay que usar X porque todo el mundo lo usa"... no lo he pillado nunca, desde el punto de vista del programador (a nivel de empresa, sí que es entendible, hay más masillas disponibles). Es como el chiste ese de Millones de moscas no pueden estar equivocadas. Come mierda.

Me parece un buen tema de debate para hoy fperoIV, expande. Que te ha pasado? Cuentanos mas.

1 1 respuesta

B

[Borrado] #35295 May '22

#35291PiradoIV:
BTW, ahora mismo la GUI de elementaryOS le da mil vueltas a la de Windows

he estado mirando y me dan ganas de instalarlo joder

#35291PiradoIV:
Si quieres entrar en una empresa donde usen X o Y tecnología concreta, te cuesta una semanilla aprender lo suficiente como para pasar una entrevista técnica

no estoy de acuerdo, mi prueba técnica la pasé porque ya tenía conocimientos de más de una semana y porque me ayudó a estructurar el proyecto gente de aquí

1 respuesta

PiradoIV #35296 May '22 Brongster

#35294 ¿Cuál es la pregunta?, ¿qué quieres debatir? xD. Cuento más.

Desde el punto de vista del programador, no usar Ruby on Rails o Django, por ejemplo, porque ya no estén de moda, me parece una tontería. Son frameworks súper válidos hoy en día y que te permiten hacer aplicaciones web sin problemas, acabar el proyecto y cobrar la factura cuanto antes. Me acuerdo cuando "todo el mundo" empezó a soltar que Ruby on Rails ya no era guay, que era mejor usar MEAN porque potato... no han parado de cambiarle las siglas a ese stack, mientras que los otros frameworks no han parado de mejorar progresivamente.

Desde el punto de vista de un líder técnico en una cárnica o empresaurio, donde puedes tener mucha rotación de personal, sí que te interesa que tu stack sea algo muy popular, para poder seguir echándole carne fresca a los proyectos.

2 respuestas

PiradoIV #35297 May '22 Brongster

#35295 A mí me ha pasado con React dos veces. En una empresa pedían React, trasteé una semana y pasé la prueba, pero en esa empresa nunca llegué a usarlo, picaba backend . Años más tarde tuve que volver a aprender React para otra entrevista (porque claro, JavaScript, tus conocimientos son efímeros), lo mismo, pasé la entrevista técnica, pair programming, pero no cuajó el salario.

Al final nunca he tenido que picar en React en mi trabajo. Sí en Vue y Angular.

Edit: Antes de entrar en Xojo tampoco tenía experiencia profesional con TypeScript (lo usamos para el framework web), cero dramas también.

desu #35298 May '22

#35296
Has dicho fpero.

El tema este de "hay que usar X porque todo el mundo lo usa"... no lo he pillado nunca, desde el punto de vista del programador

Pues por ejemplo si tienes que hacer algo basico el usar una libreria o framework muy utilizado hara que puedas copy pastear el 99% del codigo. Aunque esto si se lleva al extremo terminas con cosas como Spring. Donde ningun titutoral (ni muchos oficiales funcionan).

Django no se usa porque tiene un rendimiento de mierda, es de lo peor que puedes usar. ahora mismo no se. pero no era un webserver async como fastAPI y tenia un rendimiento horrible. por eso se popularizo fastAPI.

Ruby on rails no se usa porque los programadores de python, javascript y ruby, interpritados dinamicos, son putos monos que hacen mierdas (muchas orientadas a objetos) que ni ellos mismos se queiren comer. por eso se van a otros lenguajes.

no esta de moda por un motivo y el principal motivo es: los programadores son muy malos, hacen mierdas muy gordas, y no quieren mantenerlas.

el mayor ejemplo es el programador de collar azul de C# o Java. que se la pasa haciendo patrones de dise;os exhuberantes e innecesarios en todos los lenguajes que toca. y que a mi por desgracia, me toca echarles la bronca y re hacer todo.

Por otro lado si vas a hacer algo a bajo nivel deberias usar Rust porque todo el mundo BUENO lo usa. (C si no estas en embeded.) C y CPP solo son para malos programadores deprecated que no saben lo que hacen. sobretodo los de CPP son pateticos. son como los de java.

Si dudas entre erlang o elixir, deberias usar elixir porque es lo popular.
Si dudas entre haskell o ocaml, deberias usar haskell porque es lo popular.
Si dudas entre django o fastapi, deberias usar fastapi porque es lo popular.

Esa popularidad suele tener un motivo.

El unico motivo negativo es legacy reasons. Java, C#, cosas antiguas de python o ruby, CPP, eso no es popular porque es bueno. Es popular porque hay muchos malos programadores y hay mucho codigo legacy que alguien tiene que mantener. La opcion mas inteligente es ALEJARTE de esta gente.

Decir que programas en java o C# es mala experiencia en tu CV.

1 respuesta

Kartalon #35299 May '22 Veterano

#35296PiradoIV:
Desde el punto de vista del programador, no usar Ruby on Rails

Buena suerte construyendo una buena arquitectura distribuida de dominios en Ruby. En mi empresa lo intentaron y aquí estamos, migrando de Ruby a .NET Core. No sé los detalles porque no toco Ruby o Rails hace eones pero supongo que los compromisos de Rails como frameworks no están bien orientados a DDD y .NET Core tiene muchas más librerías y utilidades orientadas a este tipo de arquitecturas.

Pero vamos, que lo de "desde punto de vista del programador" lo veo absurdo. Entender el programador en pleno siglo XXI como un ente aislado que mira webs y aprende cosas random para hacerse aplicaciones a su bola no tiene sentido. El programador, como profesional, trabaja en equipos que forman empresas. Y para esa empresa el comprometerse con determinada tecnología es algo en lo que es crítico el soporte que tenga dicha tecnología, y obvio el que sea usada incrementa el soporte y la disponibilidad de recursos (tanto humanos como no humanos).

¿Tienes la comida asegurada, te aburres y quieres aprender por aprender? Usa la tecnología que te de la gana y bichea y elige las decisiones de diseño detrás de esa tecnología.

¿Tienes la comida asegurada pero quieres/necesitas mejorar como profesional en tu empresa? Usa la tecnología a la que se ha comprometido tu empresa, que probablemente sea una que esté ampliamente adoptada.

¿Necesitas comer y quieres aprender para aterrizar un buen curro? Usa una tecnología que esté ampliamente adoptada.

Vamos, que en la mayoría de casos de uso lo mejor es picar código para tecnologías con buena penetración

en el mercado.

3 2 respuestas

desu #35300 May '22

#35299 Estoy de acuerdo contigo.

Dos comentarios, aunque coincido yo lo veo desde otro punto de vista:

Hay dos tipos de programadores: buenos y malos. 1s y 0s.
Si eres malo, da igual el stack que la va a liar.
Si eres bueno, vas a ser pragmatico y usar lo mejor posible considerando los trade offs de tiempo de desarrollo, deadlines, recursos disponibles, etc...

Segundo: si la empresa elige el stack en lugar de los enginieros. cambia de empresa. es una mala empresa. si un programador elige un stack y no sabe justificarlo mas alla de es popular o no sabe decir los cons. cambia de empresa. mal equipo.

2 respuestas

Soltrac #35301 May '22 MV Wizard

Bait bait bait bait

5

PiradoIV #35302 May '22 Brongster

#35298desu:

¿?

#35298desu:

Si la documentación es buena, no necesitas Stack Overflow. No puedes tener documentación buena si creas un framework desde cero cada vez que pestañeas, al final los stacks "modernos" son pruebas de concepto que se han venido arriba.

#35298desu:

He llevado webs con 120k peticiones por minuto en lenguajes interpretados, sin problema. En el mundo web es fácil tener un rendimiento más que decente hasta con Ruby. Por un lado dices que hay que ser jardineros, al día siguiente quieres que hagamos optimización prematura... no sé, decídete. Si puedo plantar mis lechugas más cómodo con Django que con ensamblador, pues eso que me llevo.

#35298desu:

Pues eso, come mierda. No pueden estar equivocadas todas las moscas.

Si dudas entre una cosa u otra, para no ser fpero como tú, pruebas las dos y decides por ti mismo qué es lo que más te conviene.

#35298desu:

Chorrada. PHP me ha dado de comer muchísimo tiempo, si alguna vez alguien rechazase mi CV por mencionarlo, sería una bala esquivada... imagínate currar en una empresa con un equipo así.

Edit: No sé hacer quotes ¯\_(ツ)_/¯

2 respuestas

Soltrac #35303 May '22 MV Wizard

#35302

#35302PiradoIV:
He llevado webs con 120k peticiones por minuto en lenguajes interpretados, sin problema. En el mundo web es fácil tener un rendimiento más que decente hasta con Ruby

Sacrílego, hazlo en ensamblador, fpero.

2

desu #35304 May '22

#35302PiradoIV:

Por un lado dices que hay que ser jardineros, al día siguiente quieres que hagamos optimización prematura..

No. Existe una diferencia entre ser un buen jardinero que prepara la tierra y planta con cuidado. A un vato que no sabe lo que hace.

Un buen jardinero precisamente tiene cuidado en no eligir un stack demasiado arriesgado ni tomar decisiones dificiles de revertir.

Hay decisiones reversibles y decisiones que no lo son.

Un buen jardinero (ingeniero) se preocupa mucho en no cometer errores en las decisiones dificiles de revertir. En cambio no pierde el tiempo en decisiones que son faciles de cambiar.

#35302PiradoIV:
Pues eso, come mierda. No pueden estar equivocadas todas las moscas.

El 99.999% de los programadores sois malos.

#35302PiradoIV:
Si dudas entre una cosa u otra, para no ser fpero como tú, pruebas las dos y decides por ti mismo qué es lo que más te conviene.

Prototipar es bueno.

#35302PiradoIV:
PHP me ha dado de comer muchísimo tiempo, si alguna vez alguien rechazase mi CV por mencionarlo, sería una bala esquivada... imagínate currar en una empresa con un equipo así.

De nuevo, al igual que el 99.999% de programadores son malos. El 99.999% de trabajos de software no requieren skill.

Yo hablo desde el punto de vista del top.

Existen otros puntos de vista. Y para esa gente yo creo que no hace falta pensar en nada. Con no cagarte en los pantalones es suficiente.

Si tuvieses que hacer algo que tiene cientos de milllones de request por second, y escala a cientos de miles de otros programadores que usan tu infra, y que cuesta millones de euros mensuales, lo harias en php o ruby o python? ya esta. yo es que estoy en ese top. depende del dia, no todos los dias hago cosas super dificiles, al contrario, la mayoria de mi trabajo es irrelevante como el tuyo.

hay dias en que hago un crud y hago una peticion 2 for loops y a otra cosa.

hay dias en que tengo que re escribir cosas mirando el profiler porque eso esta escalando a niveles que no veras en tu vida y gastamos cientos de miles de euros al mes olo en ello.

despues de tocarlo pasar de 100k al mes a 1k al mes es algo inexplicable. puro toque.

Wei-Yu #35305 May '22

#35300desu:
si la empresa elige el stack en lugar de los enginieros. cambia de empresa

Algo así lo dice un junior; la gente adulta forma parte de la empresa. La empresa es como hacienda, somos todos.

PiradoIV #35306 May '22 Brongster

#35299 No todo el mundo necesita "construir una buena arquitectura distribuída de dominios". Rails no es peor porque no esté bien orientado a DDD, menuda broma xD

En la mayoría de los casos, lo que tienes que usar es la herramienta apropiada para el trabajo, aunque no sea la que use todo el mundo.

2 respuestas

desu #35307 May '22

#35306PiradoIV:
En la mayoría de los casos, lo que tienes que usar es la herramienta apropiada para el trabajo, aunque no sea la que use todo el mundo.

El 99.999% de la gente, da igual la herramienta que uses. No tendras problemas de escalabilidad ni rendimiento reales.

Pero si quieres ser bueno, tienes que aprender a estar en el 0.0001%

Lo he dicho muchas veces. La mayor parte de nuestro trabajo da igual. Da igual el stack. Da igual si es OOP o FP. Da igual si es HTTP Rest o son cuatro llamadas mal acopladas. Da igual si es DDD o hexagonal. Da igual si es un monolito o no. Da igual de verdad.

Empieza a importar cuando todo esta a un nivel altisimo y estas optimizando cosas dificies.

2 respuestas

Kartalon #35308 May '22 Veterano

#35300desu:
si un programador elige un stack y no sabe justificarlo mas alla de es popular

Sí, claro, el ingeniero/arquitecto en su ADR no debe poner "es popular" y listo. Yo espero en el ADR argumentos como el soporte que tiene, las librerías que pueden soportar lo que queremos hacer, lo mantenidas que están esas librerías, el tooling, etc... Todo ello consecuencia directa de la popularidad de la tecnología, pero no basta con decir "es popular" y desfilar porque a mí si soy el decision maker eso no me dice gran cosa.

Luego ya el management se encargará de sopesar los argumentos técnicos del ADR, con argumentos no técnicos (costes, recursos disponibles, facilidad de obtener recursos) para tomar una decisión. Y los argumentos no técnicos a veces pueden pesar más que los técnicos (más en 2022 donde encontrar recursos humanos es jodidísimo) pero eso ya no es cuestión del ingeniero/arquitecto.

Escribir un buen ADR (sucinto, claro, sin complejidad innecesaria, bien referenciado, etc) es un arte.

#35306 Es obvio. Simplemente decía que Ruby on Rails puede no ser la mejor herramienta para un montón de soluciones "enterprise grade", y es comprensible que haya perdido popularidad por ello.

Y ya digo, a veces la herramienta puede no ser la mejor para el trabajo, pero es lo suficientemente buena y por decisiones de gestión no técnicas (eg tienes ya infraestructura que se adecua mejor, recursos con experiencia, etc) pues el compromiso es perfectamente asumible.

PaCoX #35309 May '22 Ant queen

#35307 cosas dificiles? para los que estamos en el top 0.0000001 no hay nada dificil

2 1 respuesta

B

[Borrado] #35310 May '22

#35309 exacto, mi día a día es un picnic en la pradera

1 respuesta

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales