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?

pantocreitor

#3089 piensa que estás con 2 lenguajes muy diferentes y con un framework para cada uno, por una leo front y por otro back.
Elige un lado y aprende. Cuando estés más o menos bien ve por el otro.
Poco a poco y con perseverancia.

Edit: llegará un punto que te cueste muy poco, pero de momento te toca darte cabezazos como todos xD

1 1 respuesta
D

#3091 Lo logico es entre comillas, que siguiera con java y javascript que es lo que toca en el temario, y tambien con spring que es lo que toca en desarrollo web en el entorno servidor, no se si tocaremos react o algun framework de front, pero como se suele decir de tocar ambos lados tanto front como back por eso voi de lado a lado.

1 respuesta
Konishi

#3092 céntrate en hacer proyectos específicos pequeños más que en ver lo que haces como 4 cosas distintas. Tampoco tienes que llevar todo de golpe, si dices que estáis con java y spring amplia sobre eso y busca como crear un backend que se pueda consumir, y luego ya le harás un front cuando toques JS.

Wallcroft

Una duda que me surge, cuando haces API con spring por ejemplo para consumirlas en el front, por ejemplo en Angular, hay que seguir creando el servicio y el modelo? o como va esto?

porque yo cuando he hecho el crud con api ej angular, tenia un servicio levantado para dar el JSON, y consumirlo por angular, con su servicio modelo y demás

2 respuestas
Yechezk

#3094 No se si entendi bien tu pregunta, disculpa.

¿El servicio ya está creado en Spring no? En el front debes de consumir este servicio y mapearlo si es necesario a un modelo que sea el utilizado en tu front. ¿Van por ahí los tiros?

Hay un patrón llamado Repository Patttern muy facilito ya veras. Pues lo puedes trasladar al front y organizar tus llamadas a tu API siguiendo el patrón, es útil. Aqui tienes un poco de código que te da una idea (paso 5 y 6).

Entendí bien lo que preguntas?

1 respuesta
uvelongboard

#3094 Si he entendido bien, la idea desde Front es:
1.Crear modelo para mapear.
2.Crear servicio que consuma la url de tu API. Pasarle un Observable con tu modelo para mapearlo.

  1. Ese servicio consumirlo en tu componente.
1 respuesta
Wallcroft

#3095 #3096 es así como siempre lo he hecho, pero entonces mi pregunta ha cambiado, en el back-end ( Spring ) entonces que es lo que hay que hacer aquí? crear un @service @repository para coger las peticiones del front-end? estoy hablando desde el desconocimiento, no he hecho esto con spring, solo con angular y un servicio json para acceder a las API

3 respuestas
Yechezk

#3097 Va al contrario, el front le reclama al backend lo que el backend expone al exterior. De otra manera, en el front puedes realizar acciones que pueden o no transferirse al backend y hacer lo que tenga que hacer.

En tu backend haces servicios, repositorios, etc... que tienen un objetivo. Cuando esten hechas puedes consumir esos servicios desde el frontend, ya sea pasandole informacion o simplemente obteniendo lo que te devuelve el backend.

El backend no consume el front, el front consume el backend.
El backend no consume el front, el front le pasa datos al backend.

Mejor?

uvelongboard

#3097 No te entiendo del todo, pero en ese caso tienes que coger la url de tu API y tenerlo levantado el backend si es desde local.

Kaledros

#3097 Normalmente, en Spring tendrás un @Controller, que le pasará la petición a un @Service, que usará un @Repository para acceder a la capa de datos. Como te veo más perdido que un pulpo en un garaje, busca documentación sobre crear endpoints REST en Spring.

2 1 respuesta
Wallcroft

#3100
Si, estoy haciendo la lista de Spring de OpenWebinars, acabé core 5, entonces teniendo esto en Spring, en Angular, debería de tener el servicio y el modelo/interfaz?

Todo esto para tener el concepto claro

muchas gracias

1 respuesta
Kaledros

#3101 Estás volviendo a confundir términos. Esa pregunta no tiene ningún sentido, la expresión "modelo/interfaz" no tiene sentido, y desde el front (en Angular, React o lo que quieras) no accedes a servicios, haces peticiones a endpoints.

Estás perdidísimo. He mirado ese webinar y no te enseña lo que buscas, mírate tutoriales o cursos de Spring Boot.

1 respuesta
Wallcroft

#3102
En Angular tengo esto por ejemplo:

spoiler

entonces aqui con Observable accedes a un endpoint ( spring APi rest )

y con lo poco que se, supongo que un endpoints es en spring lo que me acabas de decir antes (@controller @Service @Repository ) => endpoint

Entonces por la parte Angular ( front ) tenemos un componente que accede a la interfaz para hacer peticiones al endPoint a través de un servicio

Y en la parte de backend spring, tenemos un controlador que hace peticiones a un servicio que usa un repositorio

es este : https://openwebinars.net/academia/carrera/desarrollador-spring/

1 respuesta
B

#3103 Modelos/Entidades(Acceso a BD/API externa/CSV/Excel de palo) <-> Repositorios(Infraestructura) usan los Modelos <-> Servicios(Aplicación/Lógica de negocio) aplican la lógica de turno y mapean los Modelos a DTOs y viceversa para desacoplar la infraestructura de la presentación. Por ponerte un ejemplo, una entidad/modelo Usuario que tenga un atributo/propiedad Password, su UsuarioDTO no lo tendrá (por el amor de Paquirrín) <-> Controladores(Presentación) controlan acceso, proporcionan un contexto para calzarle los middlewares, etc. y devuelven respuestas, ya sea con o sin DTOs y códigos de estado ::::::: Modelos(DTOs) para mapear las respuestas (los modelos en el frontend no son lo mismo que en el backend. Siendo purista los modelos aquí serían los DTOs del back, no las entidades de acceso a infraestructura. <-> Servicios que aplican la lógica que corresponda y devuelven los datos al DOM <-> Eventos/Listeners/Hooks/Componentes/DOM. Esto son abstracciones, realmente podrías coger todo y meterlo en 50 líneas en un sólo archivo, pero es la arquitectura mainstream que te van a pedir para un curro.

Ten en cuenta que el frontend forma parte de la capa Presentación, pero en una arquitectura de API + Frontend, esta se desanexiona y tiene identidad propia, de ahí la confusión con los modelos y derivados supongo. Igualmente, las interfaces en Typescript son un poco de su padre y de su madre; Entiendo por qué estás llamando interfaz a todo, pero si te fijas Typescript usa interfaces para definir de qué tipo será el objeto, mientras que Java usa moldes (clases) para definir como serán sus instancias (los objetos). Igualmente en Java también hay interfaces, pero están más enfocadas a definir contratos, a qué ha de tener más que cómo lo ha de tener (implementación) y a su vez, para propiciar el polimorfismo para la famosa inyección de dependencia, facilitar el mockeo en el testing, aplicar patrones que adapten otras interfaces a las tuyas, etc. El concepto de interface en Typescript es mucho más trivial. Estaríamos hablando de interfaz/interface siempre desde un punto de vista funcional, realmente puedes utilizar el término interface para referirte a lo que te salga del pito. El monitor del PC es una interfaz para mí, de su implementación no tengo ni zorra, cada fabricante la implementará como crea oportuno.

2
sasher

Buenas. A ver si alguien me puede orientar un poco con "mi problema".

Llevo en mi actual empresa más de 7 años (trabajo X) mientras lo he compaginado con otro trabajo (trabajo Y), el cual considero más crítico a largo plazo. Hasta ahí bien, y con los dos trabajos, no me quejo del sueldo. El problema son las horas que le echo y el trabajo que hago en X: suele ser muy variado y exige formarte en cosas nuevas cada dos por tres aunque luego no se usen para nada (pero al CEO le apetecía investigarlas para posibles ideas de negocio). No tengo un perfil bien definido: he hecho cosas a bajo nivel en C++, apps/juegos con Unity y UE4, Python, entrenamiento de modelos de IA, desarrollo móvil nativo e híbrido, desarrollo web front y back (con typescript, siempre que puedo), IaC sobre AWS con Terraform, despliegue de contenedores en ECS, bases de datos, CICD con pipelines de bitbucket, impartir cursos a una semana vista sobre algo que desconozco (y todo lo que conlleva de formación previa)... y eso es solo lo que me viene a la mente ahora mismo.

Y estoy ya un poco quemado de dar tantas vueltas y no poder especializarme en algo. El tema es que no puedo deshacerme de este trabajo X y quedarme solo con el Y porque el primero me paga más. No sé, ¿qué haríais vosotros? He pensado directamente en dejarlo y montar mi propia empresa, pero ahora mismo con el trabajo Y tampoco tendría disponible esa dedicación que hace falta al principio para levantarla. Idealmente me gustaría buscar otro trabajo, que fuera full remote (como hasta ahora con el X) y que me deje algunas mañanas libres para poder ejercer mi trabajo en Y (obviamente esos días dedicaría las tardes, claro). ¿Creéis que es factible? ¿Qué opináis?

Muchas gracias, os leo.

1 respuesta
pantocreitor

#3105 por organizar las cosas un poco, no te renta buscar un curro en el que te paguen bien y puedas currar en algo más “centrado” y tranquilo y con esto ir montándote tu empresa con calma?

Porque si no puedes parar de cobrar pero tampoco quieres seguir con lo que tienes, pocas salidas veo que no sean la que te comento.

A ver que pueden decir por aquí loh shavaleh

1 respuesta
sasher

#3106 gracias. Sí, es la única salida me parece. Creo que iré actualizando el CV e iré echando a distintas empresas por Linkedin a ver si suena la flauta y encuentro algo compatible con el otro trabajo. Si no, pues tendré que quedarme como estoy de momento.

Pizzelio

Qué os parecen las webs tipo educative.io?

squ4r3

Continuación de #3079

24 horas antes de la entrevista técnica me mandaron un documento en pdf para prepararla: El objetivo es hacer un plan para gestionar la infraestructura y deployments de un frontend en Angular y un backend en Java, con BBDD Postgres.

Objetivos: simplicidad de uso, 99% SLA y high availability.

Debía dedicarle 1-2 horas al plan y la idea era debatirlo en la oficina con el que sería mi jefe y compañero de equipo.

Llegué a la ofi, todos majetes y jóvenes, nos sentamos y empezamos:

Primero repasé los requisitos para no dejarnos nada, luego les hice preguntas generales sobre el proyecto, el backend, el frontend, perspectivas de crecimiento en el futuro, etc.

Empecé con buen pie porque mi primera pregunta era que dónde íbamos a guardar las sesiones, porque el documento mencionaba una BBDD pero nada de redis o algo dedicado a session storage. Ahí se miraron y sonrieron y dijeron que bien visto (luego me confesó uno de ellos que es una parte que acaban de quitar del enunciado, para ver si los entrevistados se pispan).

A partir de ahí, se me pasaron las dos horas volando, les conté cómo lo gestionaría con terraform y terragrunt, la estructura de la red que plantearía, medidas de seguridad, la forma de deployearlo, cómo hacer el CI/CD con github actions y codedeploy...

mi plan A era desplegarlo directamente sobre un EC2 porque el backend era un solo servicio, pero durante el discovery me dijeron que igual en el próximo año habría 10 servicios más independientes, así que como alternativa estuve hablando sobre ECS y desplegarlo todo en contenedores.

Durante toda la conversación me iban haciendo preguntas, algunas de las que recuerdo:

  • Qué ventajas tiene dividir los entornos en distintas cuentas de AWS
  • Cómo se comunica GitHub con AWS para iniciar el deployment?
  • Mejor triggerear deployment al acabar la build automáticamente o hacerlo manual?
  • Qué ventajas tendría el frontend si fuese server-side rendered en vez de una SPA que llama a una API en cliente
  • Qué diferencia hay entre un Application Load Balancer y un Network Load Balancer
  • En el contexto de ECS, cómo se comunican los contenedores? Qué modelo de networking plantearías?

Luego si me acuerdo pongo más, pero en resumen los tíos parecían bastante contentos con mis respuestas, al salir yo estaba contento también, pero no me dijeron nada específico, solo que la recruiter ya me diría algo. A la hora me llamó y me dijo que solo necesitan dos referencias de trabajos anteriores y me hacen oferta.

No quiero vender la piel del oso antes de cazarlo pero la verdad es que estoy muy contento :D ya casi lo tengo!!

11 2 respuestas
Don_Correcto

#3109 Enhorabuena, parece que lo tienes casi hecho. Por lo que comentas ibas bien preparado y eso al final se nota. Solo con lo de que te llamaran a la hora dice mucho, les has gustado. Lo que no me gusta a mí personalmente es lo de las referencias. Supongo que igual eso es más de USA, aunque aquí también se haga de vez en cuando.

1 respuesta
squ4r3

#3110 a mí tampoco me mola un pelo lo de las referencias, sobre todo porque es en call y no simplemente por email... pero bueno, cosa de yankis y espero que no suponga un problema

La verdad es que me lo preparé bastante bien, y también me vino dios a ver porque había preguntas que me había preparado literalmente tal y como me las formularon, y otras que me fueron haciendo sobre la marcha eran sobre servicios con los que por fortuna tengo bastante experiencia, así que aunque no fuese algo preparado pude desenvolverme bien y se notaba que sabía de lo que estaba hablando. Me sentí cómodo y con autoridad y creo que eso se nota también. Si algo no lo tenía 100% claro, lo decía tal cual.

pelusilla6

#3109 Con un año de exp?
Todo eso no suena a junior 🥵

Congrats!

1 respuesta
squ4r3

#3112 Gracias! Creo que el hecho de llevar un año y medio en cárnica hace que haya aprendido un poco de todo a marchas forzadas. Pasados los 3-4 primeros meses de toma de contacto, ha sido totalmente "sink or swim". Te empiezan a caer proyectos, tickets de jira en los que no sabes ni de qué cojones te están hablando, alertas de prod down de entornos que ni sabías que existían... lo bueno es que he aprendido un montón, lo malo es que es un estrés de cojones.

Quiero pensar que en este año y medio he cumplido, he conseguido una competencia base decente y que a partir de aquí todo debería ser un poquitito más fácil.

Si al final consigo el curro, sin carrera de ingenieria, en EEUU, cuando hace año y medio no sabía ni hacer un cat | grep, de verdad que me va a costar creermelo...

Edit 13/11: Tengo call para oferta esta noche. Estoy dando volteretas.

6
squ4r3

Me vais a perdonar el doble post, pero update a #3109 cerrando el círculo

Acabo de salir de la call para la oferta:

  • 135k base
  • 10k bonus
  • stock options (que al ser una startup, no creo que valgan nada)

Firmo mañana y empiezo a mediados de diciembre. Paso de negociar.

El viaje ha sido de aúpa, literalmente multiplico x6 mi actual salario. Todavía no me lo creo. Gracias a todos los que dais ánimos en este hilo, consejos sobre cagadas, entrevistas, etc.

Estaba bastante depre últimamente tirando cvs por todos lados y no recibiendo respuesta, incluso empezando a pensar si debería replantearme el futuro, y esta oferta ha sido caída del cielo. Ronda tras ronda he ido haciéndolo bien y todo el "plan" se ha cumplido. Como dato curioso, en esta call han mencionado el homelab que les comenté en una de las entrevistas, como muestra de mi pasión y blablabla. Así que sabed que esos detalles también cuentan!

42 2 respuestas
smarquezp

#3114 Enhorabuena tío! Te has currado una carrera en año y medio, con sufrimiento y agobios, para que te llegase esto.

1
PhDfailer

#3114 y el tema del visado? He visto que muchas empresas de USA no quieren ni empezar la entrevista si no tienes permiso de trabajo americano. Muchisima enhorabuena! Te vas a hacer autonomo?

1 respuesta
squ4r3

#3116 Tengo greencard gracias a mi señora esposa, así que estoy en igualdad de condiciones, digamos, que cualquier americano.

Tengo clarísimo que si no tuviese greencard todo este proceso habría sido imposible. Piensa que si no tienes permiso de trabajo, te toca competir con todo el planeta, y los americanos tienen que hacer piruetas para justificar tu contratación como extranjero. Los únicos casos en los que es más fácil es si vas a trabajar en temas de sanidad u ONGs, que están menos restringidos para contratar gente de fuera.

No me tengo que hacer autónomo, tengo contrato (aquí no hay indefinido, es "at-will", lo cual quiere decir que en cualquier momento te pueden peinar), plan de pensiones y otras movidas más que todavía no me he enterado de cómo funcionan.

Las vacaciones son "ilimitadas", lo cual no me gustaba nada, pero les he preguntado y me han dicho que esperan que la gente se coja 4 semanas al año, que es la media, así que sin problema.

Ya he firmado la oferta y me han mandado mil movidas de onboarding, así que ale, a disfrutar.

Ahora me siento un poco vacío por las tardes al no estar estudiando AWS lol

1 2 respuestas
PhDfailer

#3117 enhorabuena! Suena muy bien. Te mudas alli entonces?

Para que luego digan que hay igualdad de oportunidades, tener green card multiplica tu sueldo x3😂

1 respuesta
squ4r3

#3118 Llevo varios años viviendo en USA. Actualmente trabajo en una empresa europea, porque cuando me moví para buscar curro por última vez no tenía todavía la green card, solo tenía permiso de residencia, no de trabajo.

Al sacarme la green card, obviamente empecé a mirar curros locales, ya que lo que pagan no tiene nada que ver con lo que pagan en europa. Así que digamos que mi caso es muy muy concreto. Pero vamos, he echado cientos de cvs y solo me han salido... 2 entrevistas.

Tengo amigos que se han ido de España con curro en USA pero para empresas de sanidad, que ponen menos pegas.

Y el salario este obviamente es buenísimo y me cambia la vida, pero donde vivo tampoco es que te haga millonario, que un alquiler de un sitio decente te puede costar $4k.

3
Zh3RoX
3 respuestas