Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




desu

Una ciudad de 30M de personas, sin delincuencia ni inmigración ni drogadictos por las calles, los niños van a la escuela por la mañana y vuelven por la noche solos sin miedo, transporte público barato y de calidad, servicios de todo tipo para todo el mundo...

Mientras tanto, en New York, tierra de libertad, capital de occidente:


U S A!
U S A!
U S A!

2
r2d2rigo

Sin inmigración? Entonces tu eres un expat? 🌚

1
Kaledros

¿Alguien más trabaja con frontends que son completamente inútiles?

No hablo de hacer mal su trabajo, de hecho es imposible hacer mal su trabajo (cambiar colores, textos, apuntar a otros endpoints, etc). Hablo de lo demás.

¿Me devuelve un error una llamada que no debería devolver error? Procedo a cagarme encima y voy corriendo a preguntar a los de backend, que seguramente no tengan nada que hacer, porque soy incapaz de irme al Kibana a mirar el log. No saben entrar en la DB para mirar (no cambiar: mirar) un dato de un usuario o de un objeto de dominio. ¿Estoy viendo algo raro en una respuesta? Para qué mirar primero a ver si veo algo, mejor doy por culo y pregunto cada cinco minutos como va esto.

No entendería como esta mierda se tolera en mi equipo si no fuese porque mi EM es un completo inútil a su vez, la verdad.

2 respuestas
Wei-Yu

Sí, yo la gente de frontend que me he encontrado la he visto más floja que el resto por un cacho. Ni siquiera aportan a nivel de diseño más allá de cuatro cositas básicas o "de su gusto personal".

Justo la semana pasada en una conversación con uno se vio que no entendía la diferencia entre el local storage y el header que mandas en la petición (?). Hay muchas veces que parece que no se enteran de gran cosa más allá de pegar con cola los 300 componentes distintos del stack de frontend y más o menos entender su lib de gestión de estado.

1 respuesta
Fyn4r

#55143 si, y yo si hablo de hacer mal su trabajo. Tipo tener que colocar un select en un formulario y que no se puedan ver todas las opciones porque no hay scroll

1 respuesta
Kaledros
#55144Wei-Yu:

no entendía la diferencia entre el local storage y el header que mandas en la petición

Es comprensible, a veces también es difícil entender la diferencia entre un coche y una pizza carbonara. Cristo.

#55145 Sí, bueno, no he querido hacer demasiada sangre, pero hay veces que me pregunto qué coño hacen para cagar cosas tan sencillas.

Wei-Yu

otra que me dijeron la semana pasada también

como querían ahorrar queries al backend querían traerse no sé si 20k items al frontend en una query con paginación infinita para buscar ahí y que sea más responsivo

que si se podía quitar el límite en el tamaño de página

1 respuesta
Kaledros

"¿Cómo que eso no performa? Pues lo tendréis que optimizar, ¿no?"

desu

#55143 Justo hoy he hablado de ellos en mi nuevo diario:

#4desu:

Recordad que un fpero, siempre va a resolver un problema que requiere pensar poniendo más código! El fpero nunca usará el cerebro para pensar o Codely no podrian vender videos en su trabajo.

Los alinea divs son incapaces de pensar.

Runig666

#55147 A mi sabes cuando eso me la ponen como el cigüeñal de un Land Rover? Cuando son selects.

Lo gracioso es que saben de sobra que todas las apis que hecho son exactamente iguales. Pueden filtrar por lo que les salga del mingo y con la cantidad de ands y ors que se les antoje...pero claro, hasta que la tabla no va por 850 y pico no se les ocurre y luego entonces a intentar filtrarlo por Js como si el problema fuera el pintarlo...

Menos mal que los dos que tengo más cerca ya lo primero que preguntan es el número de resultados previstos...

PD: Obviamente la Api de serie página y tiene limitador. Como en algunos casos si que necesitamos que devuelva todos, activamos que se pueda poner el parámetro de página a -1 que devuelve todo...y lo usan como gilipollas y ya lo miran después...que es nunca porque ahora les toca programar el auto completado

W0rd

Hay historias para contar en ambos lados, es muy normal ver gente que lleva años sin actualizarse moverlos a hacer CRUDs sin tener una minima idea de un frontend a dia de hoy, quedandose con lo que era php y html hace 10 años.
En mi experencia lo mejor si es posible es tener a la misma persona haciendo ambas cosas, el trabajo va salir mas rapido, mejor y mas economico para la empresa.
Si no queda otra lo suyo es definir responsabilidades, dividir una funcionalidad en tareas con sus requisitos, e2e tests etc. Uno de frontend no tendria que ir a mirar la base de datos ya que ese no es su trabajo. Aqui es muy importante el detallar los requisitos.

2 respuestas
Kaledros
#55151W0rd:

Uno de frontend no tendria que ir a mirar la base de datos

Un developer debería ser capaz de entrar en la BD de un servicio propiedad de su equipo, que una cosa es que un front no toque nada de back y otra que sean compartimentos estancos. En mi experiencia hay mucho front que se ha acostumbrado a depender completamente de back para todo lo que no sea alinear divs y llega un punto en que para eso alineo yo el puto div.

1 respuesta
W0rd

#55152 Que sea capaz no significa que deba, ademas que tu trabajo no es mas importante que el resto. Esto funciona igual que una API de terceros, uno se espera que funcione de x manera y eso es lo que el trabajador de frontend va a esperar. No tiene porque hacer el trabajo del otro

1 1 respuesta
Zoko

La superioridad moral de los backend es algo digno de estudio.

4 1 respuesta
Wei-Yu

creo que kaledros habla de formas de no bloquearte y no depender de otros

si dependo de un servicio de otro equipo y hay una serie de known issues o hay cosas que puedo saber/aprender para no depender de ellos para el troubleshooting tampoco es ninguna locura saber hacerlo

que mi PO se hace queries en elastic para los logs y se va a hacer selects a la db con nuestra ayuda, por qué el frontend no puede? porque no le sale de los cojones xd

1 1 respuesta
Seal67

#55153 Una cosa es deber o no, si tú paras tu trabajo y le paras el trabajo a otro para que te responda una tontería perdéis el tiempo los dos y el trabajo se hace mucho menos eficiente.

No es back o front, o lo que debas o no, hacerle perder el tiempo a un compañero y a ti mismo por una tontería es peor para todos, es mal trabajo en equipo

Vedrfolnir

Me llama la atención que muchos habláis como si uno de front pudiera y tuviera accesos y tal para irse a mirar cosas a la base de datos. Y me choca porque desde que pasé de fullstack a front, nunca he tenido ese acceso porque no es nuestra competencia.

Sí que tenemos herramientas para lanzar peticiones sin necesidad de picar código ni adulterar, véase swagger o similares. Pero ni acceso al código de back, ni a la base de datos como tal.

Yo imagino que es porque siempre he currado en proyectos grandes, somos 25 fronts divididos en 3 equipos ahora mismo para la aplicación en la que estamos. De back habrá otros tantos o más. Tenemos un canal de slack para notificar errores al back (errores de verdad, la mayoría 500 cuando se caen servicios), o si de verdad la llamada no devuelve las cosas esperadas (ni por web ni por swagger).

También tenemos movidas cuando el back modifica clases, comportamientos, o directamente los objetos de respuesta y de repente las responses nos llegan vacías y cosas así. Pero se habla con ellos, te pasan el nuevo modelo, se arregla y a correr.

Además, claro, no todo lo que a veces falla es error del back, la mayoría de las veces ellos mismos nos dicen que X o Y error viene de aplicaciones y servicios externos a las que ellos tampoco tienen acceso, y que lo trasladan.

Imagino que todos los casos que habéis puesto son de empresas con menos gente, aplicaciones no tan grandes, o lo que sea. O simplemente yo he tenido suerte y nunca me he visto en una de esas.

3 respuestas
pantocreitor

#55157 los de front que conozco todos tienen acceso a base de datos en entornos de desarrollo o UAT para poder hacer pruebas desde el front

1 respuesta
Vedrfolnir

#55158 nosotros nunca. Tenemos nuestros endpoints, bien definidos (que no siempre funcionales xD), con su get, post, put, options, etc. Llamamos y mandamos request, recibimos la response, y a partir de ahí ya procesamos y mostramos lo que necesitemos.

Pero ni base de datos ni nada, jamás. Es totalmente opaco para nosotros, ni nos hace falta siempre que el back funcione bien.

Y voy a ser sincero, entre fullstack/"front" teniendo acceso a todo, y front estando completamente aislado de lo demás, soy más feliz estando aislado xD

Kaledros

#55154 Si yo sé buscar un error en Kibana y tú (segunda persona genérica, no a ti personalmente) no, es obvio que profesionalmente estoy por encima de ti.

#55157Vedrfolnir:

como si uno de front pudiera y tuviera accesos y tal para irse a mirar cosas a la base de datos

En mi equipo sí, de ahí mi queja. Obviamente si les capan el acceso a herramientas de monitoring o a la DB y es mi trabajo conseguirles la información ya es otro tema, pero en mi equipo todo el mundo tiene acceso a todo.

Y sí, es lo que dice #55155 es ser vago por ser vago y que me lo miren otros. Además en lo particular me jode que me vengan con un "esto no va" sin darme ni una sola pista de lo que puede estar pasando. Además de vago, poco respeto por el tiempo de los demás. Coño, es que muchas veces ni darle al F12 para ver qué ha pasado saben.

1 1 respuesta
Vedrfolnir

#55160 a ver, si resulta que tiene acceso entonces sí, tiene delito la cosa xD

Hablaba de mi experiencia, en los dos curros que he estado estos últimos años, nunca he tenido acceso a nada que no fuera el front como tal, y pensaba que se habia vuelto "la norma" de un tiempo a esta parte.

Hace 10 años en mis primeros trabajos, pues sí, eso era un despiporre y la podías liar pardisima. Una compañera una vez se cargó una tabla gorda en BBDD por no ponerle el where al delete from xD
Afortunadamente había backups y se quedó en un susto, pero... Eso.

Wei-Yu

#55157 en mi curro para dev y test tiene acceso cualquiera del equipo, en staging y prod ya cambia, pero si lo pides te lo van a dar probablemente porque... eres dev.

Al final depende de la topología de los equipos claro, pero creo que en términos generales es un tema de salir de tu zona de comfort. Ya sea saber leer los logs del backend como front o estar on the loop con el figma de ux como backend, saber ser autónomo y poder anticiparte siempre es positivo.

Además, siendo sincero, saber hacer cuatro cosas con sql es útil en términos generales. Igual que es útil saber tirar cuatro divs y tener una tabla fea con un botón. Que no es "necesario" porque eres "react engineer" y si no es react no lo tocas? Supongo que es ok, pero a mí no me importa mancharme las manos y sé que estoy más a gusto rodeado de gente que tiene la misma visión.

2
desu
#55151W0rd:

Hay historias para contar en ambos lados, es muy normal ver gente que lleva años sin actualizarse moverlos a hacer CRUDs sin tener una minima idea de un frontend a dia de hoy, quedandose con lo que era php y html hace 10 años.

Tienes razón en eso, yo por ejemplo ahora estoy haciendo React, que no me gusta, y tiene mil cosas malas, pero es lo que usa el 90% de la industria y es bueno que lo conozca.

Que de vez en cuando toco React en el curro, pero es bueno por tu cuenta mantenerte al día también.

Zireael

Los que sois backeros (no de pasteles), qué mostráis en entrevistas? Tipo de proyectos?

1 respuesta
Kaledros

#55164 Somos más de que nos manden deberes o nos hagan entrevistas técnicas.

2 1 respuesta
Zireael

#55165 Y a nivel de portfolio? Más que para entrevistas, para destacar.

2 respuestas
pantocreitor

#55166 yo tengo pruebas de otrs empresas xD

Kaledros

#55166 Si acaso una API CRUD que demuestre que sabes:

  • Acabar un proyecto propio (nada de tutoriales a medias).
  • Testear (unitario, integración, etc).
  • Dockerizar y usar docker para la BD.

Y ya lo que le quieras meter: Kafka, Rabbit, Github Actions, etc.

1 respuesta
Wei-Yu

yo tengo un cementerio de cosas sin acabar en distintos stacks y sobre distintos temas, el que no sepa apreciarlo que la chupe

como me de por abrir todos los repos que tengo al público lo de neon genesis evangelion se queda corto

3 1 respuesta
Zireael

#55168 Me tengo que poner las pilas pues con un proyecto que me falta dejarlo listo para hacerlo público porque creo que lo estoy infravalorando.

1 respuesta