Plataforma de desarrolladores/programadores junior

¿Qué tengo que aprender para llegar a trabajar de X?

Cuando tengas claro que es la X busca tu roadmap aquí y empieza en ello https://roadmap.sh. No es obligatorio ni recomendable acabarlo todo antes de empezar a buscar, pero ya sabes cuales son las cosas que se te suele pedir.

¿Algún recurso para empezar?

DaLmAu

#1498 muy buena respuesta

Glumyglu

Bueno, pues tengo otra entrevista, espero que no me tiren del proceso cuando me pregunten si acabo con los estudios este año o no puede empezar "ASAP" (a pesar de que en la oferta pongan que la fecha de inicio es flexible).

LR

Algun alma caritativa tiene algo de tiempo para hacerme un poco de code review? Sobre todo para el tema de organizar el codigo y demas, que estoy bastante oxidado, aunque si hay algo que cante mucho en el codigo, cualquier critica constructiva es bienvenida

1 respuesta
B

#1503 postea en público, así te contestarán en público y otros podrán hacer challenge de la review

1
LR

Dejo por aqui el repo.

Disclaimer no es una excusa, bueno que coño, si, si lo es xD

Como puse por ahi arriba, necesito un poco de guia en cuanto a organizar el codigo, y si veis algun fallo gordo, toda critica es bienvenida :grinning:

1 3 respuestas
B

#1505 empiezo yo, ojo con la mezcla de inglés y español, preferiblemente todo en inglés.

Y no veo los tests por ningún lado, se te ha olvidado pushearlos no? No?

3 respuestas
Vedrfolnir

#1506 los test se hacen directamente en prod de toda la vida de dios

Soltrac

#1506 preferiblemente todo en inglés, fixed

1 respuesta
B

#1508 hostias, se me ha ido la olla muchísimo, eso me pasa por escribir mientras veo una serie xDD ahora edito

LR

#1506 Tests? eso se come?

Fuera coñas, todo el backend estaba con tests unitarios y de integracion. El problema vino cuando pase de gestionar yo la creacion de usuario y gestion de tokens a usar auth0, ahi no conseguia recuperar el token ya que se generan desde el front, por lo que tenia que hacer e2e (o eso creo)

En la parte del front hice algunos pero no le he dado suficiente caña a cypress por lo que al meter auth0 volvemos al mismo problema, asi que los deje de lado.

Como ya puse por arriba, se que tengo que refactorizar los nombres y dejarlos todos en ingles con esa mezcla de espanglish que hay.

En tema organizacion de codigo, que tal lo veis? Algun fallo gordo a arreglar en lo que es el codigo o esta medio decente?

1 respuesta
Wallcroft

Veo que es muy necesario tener un portfolio, estáis de acuerdo?

Lolth

#1492 Aparte de estas, Manfred (tienen un canal de telegram que cada dia hay ofertas nuevas), Otta y Wellfound (antes angellist)

1
Wei-Yu

#1510

El problema vino cuando pase de gestionar yo la creacion de usuario y gestion de tokens a usar auth0, ahi no conseguia recuperar el token ya que se generan desde el front, por lo que tenia que hacer e2e (o eso creo)

eso lo arreglas desacoplando las capas; en el controller tienes acceso a datos metido, así que es muy difícil testear cualquier cosa (también hay que decir que tienes poquito código "tuyo"; casi todo es pegando frameworks)

ej este método de agregar pagos

pagosRouter.post('/', validateToken, handleLogin, async (request, response, next) => {

// some code here
}

aquí dentro meterías para validar la request, formar el usuario con lo que ya hiciste en el middleware y luego se lo pasarías a un ficticio addNewPayment(newPaymentRequest, user)

y ahora para testear eso sólo tendrías como input dos objetos puros y te daría igual si quien llama a esa función usa auth0 o no o siquiera si es un servicio http o un cli porque sólo tienes tu contrato de la api (nwPaymentRequest) y tu usuario, que tú mismo defines tb

dentro de ese addNewPayment ahora tendrías el problema de una dependencia para fuera (mongoose) y para eso tienes el tema de mockear cosas

al margen de eso cuidado con usar objetos dinámicos que en js es muy fácil añadir propiedades y cosas a lo loco y luego se hace muy complejo de seguir

*edits random que toy con el móvil

1 respuesta
LR

#1513 A que te refieres con lo de codigo "mio"?

Lo de validar la request, en su momento lo tenia hecho pero al meter el validateToken para que haga los checks de que el token llega desde auth (lo comprueba con su propia libreria), se me jodia todo. Por lo que la unica opcion era o seguir igual y confiar en que el token llegaba directamente desde auth0 sin usar la libreria, o usarlo pero ya me perdia con los tests =/

Pero si, ahora que lo pones, es mas facil desacoplarlo, y testear simplemente el metodo que trata con la bbdd y pista. Aun asi, no podria hacer realmente un e2e sin saltarme validateToken no?

Edit, no tenia puesto el link en el repo para probarla, si alguien quiere echarle un ojo aqui os lo dejo

NSFW
1 respuesta
B

#1514 con Cypress puedes tener interceptors https://docs.cypress.io/guides/guides/network-requests

Por lo que entiendo, le puedes poner una la URL de auth0 o la que estés definiendo en las variables de entorno y definir una respuesta directamente:

cy.intercept(
  {
    method: 'GET', 
    url: '/auth0/login',
  },
  { token: "token"}
).as('getToken')

Me he inventado los nombres hulio, pero algo así.

1 respuesta
LR

#1515 Thx, me lo apunto como tarea, que como digo, en tema picar codigo ando oxidado, pero en tema testing ando muy muy perdido

1 respuesta
B

#1516 solo por comentarlo, en js para el backend tienes algo parecido Wiremock, así haces solo e2e tests y mockeas los servicios que no dependen de ti, así puedes testear también cuando te devuelven errores y cosas así

Wei-Yu

A que te refieres con lo de codigo "mio"?

LR:1514

Tampoco miré mucho pero me dio la sensación de que casi todo era pillar la request http y enchufársela a mongo; eso se suele llamar "glue code" porque básicamente tiras cuatro líneas de código par pegar componentes (lo que te da el framework http con lo que te da la lib de persistencia de mongodb).

Esto que te digo para desacoplar sería para los unitarios más que e2e. E2E y unitarios ambos testean "componentes", pero en el caso de los unitarios tu "componente" es una función o un método de una clase, en el caso de E2E tu componente es una ruta http.

El token cuando llega al controler debería estar bien formado siempre. En el middleware, en vez de

  if (!authorization.toLowerCase().startsWith('bearer ')) {
    console.log('nope')
  }

Tendrías que devolver un 401. Y después de eso comprobar también que el token es correcto y está bien firmado, y si no, otro 401 de vuelta.

Luego en el controller puedes llamar a otra función que sea, por ejemplo buildUser(token) y el resultado de eso sería lo que le pasas a tu "servcio de domino". Así también te quitarías de inyectar datos en la request dentro del middleware, que es algo bastante feo con bastantes peligros.

2 respuestas
B

#1518 todo correcto lo que dice, pero ahora eso si, en este proyecto no metería ni medio test unitario

1 respuesta
LR

#1518 si, tampoco hago demasiado en cada endpoint más allá de llamadas a la BBDD y manejar/transformar lo que me devuelve. No deja de ser una lista de tareas un poco glorificada.

El comprobar que esté bien firmado lo hace la librería de auth0 en el primer middleware, en el segundo es verdad que me queda mucha mierda por quitar, que es donde hacia las comprobaciones cuando era yo el que firmaba y creaba el token.

Tendré en cuenta lo de modificar la request y tengo que repasar bien el back, que al final sí que es verdad que lo metí todo a mogollón y me despreocupe una vez que vi que funcionaba.

#1519 por algo en concreto o por ser solo llamadas a mongo?

1 respuesta
B

#1520 Yo lo que veo es que al final como te dicen el código solo está pegando librerías entre sí, no tienes nada de lógica propia entonces no les veo demasiado valor.

Yo centraría el testing en que la app “globalmente” haga lo que se espera y ya.

Ejemplos:

  • Cuando llamó a Auth0 me devuelve un token y puedo acceder al recurso.
  • Cuando Auth0 me devuelve un error de X tipo pasa Y cosa.

Con mongo igual:

  • Cuando creo un recurso, si luego lo pido veo los datos en el formato adecuado.
  • Cuando creó un recurso sin seguir el contrato me da un error de X tipo.
1 respuesta
LR

#1521 más o menos lo que tenía antes de meter todo el tema de login, que tenía tests por un lado y requests por otro para probar todo eso.

Thx a todos

desu

#1505 falta docker-compose, un dockerfile para api y otro para app

1 respuesta
LR

#1523 Tambien lo pense y asi usar docker que nunca lo he mirado, pero realmente vale la pena ternerlo en contenedores? La app es simplemente la build de react, y la api, supongo que seria crear el contenedor y listo, ya que ahora mismo lo gestiono con pm2

1 respuesta
desu

#1524 el que te revise el codigo puede hacer git clone y docker-compose up para probar tu app.

de esta manera tambien compartes las dependencias de development de alguna manera...

2
Konishi

#1505 Sin haber visto bien el por qué lo usas (estoy desde móvil y mi CSS es justísimo), la función setAllButtonsWidth me da un poco de cosa. Si quieres profundizar el front diría que te replanteases cómo hacerlo con las herramientas que te da React. Y ya de paso, los comentarios no muerden, en este caso por ejemplo dejaría comentado o en la función o donde la usas el por qué la usas.

R

#1496 Pues he hecho los cursos de OpenBootcamp y me saqué las certificaciones. También algunas certificaciones de Linkedin. Tengo el B1 de inglés pero tengo poca fluidez al hablar así que me tendré que poner a practicar. He pensado en ser freelance y hacer webs para gente pero veo que me falta el backend, estaba pensando en aprender PHP (también Laravel), SQL y desarrollo en Wordpress para empezar a ofrecerme como freelance pero, por otro lado, no se si PHP tiene tanta demanda laboral como Java o Python, estoy meditándolo. Gracias por contestarme :+1:

2 respuestas
LR

Tenía varios botones con textos que no podía controlar y no quería meterme en tema grid, así que lo hice así rápido para que pillase el ancho del botón más grande y los dejase todos del mismo tamaño.

Al final el proyecto es un mvp, ahora me queda pulirlo, dejar bien los estilos y demás y no usar cosillas como esa función.

DaLmAu

#1527 si lo que quieres es practicar y aprender no me acercaría a WordPress. Llevo años con WordPress y clientes que te piden webs sencillotas, siempre tiene alguna cosita que has de tocar PHP, algo del front pero css y poco más sin complejidad.

1
arnaupool

#1483 Update:
Pues la verdad es que ha ido muy bien, ha pasado lo que me temía: me han hecho hablar inglés y hacer una prueba técnica.
Con lo primero realmente no tengo problema, más que nada es porque soy bastante inseguro hablando, pero me he sabido defender.
Lo segundo tenía un poco más de miedo porque, aunque no tenga experiencia, por x o por y he estado un par de años alejado del mundo de la informática, y temía no acordarme de algunas cosas. La prueba técnica ha sido relativamente fácil, en papel y boli, bases de datos, un programa muy facilito de hacer y una presentación formal en inglés. De las cosas que no me acordaba o no sabía la cosa precisa lo anotaba con mis propias palabras, para que igualmente viera que tenía algo de idea.
Hemos estado charlando sobre mi CV y expediente académico, y la verdad es que las vibras son buenas. La de RRHH me ha dicho que, para bien o para mal, tendré respuesta dentro de una semana o así, pero no he notado nada que indicara que no me quisieran contratar, la verdad.

Ya os contaré la oferta que me den, si me la dan. :clint:

8