#30 Pero de que hablas de pinchatarjetas? XDDDD
Pero entiendes como se despliegan los servicios en 2021?
#31 Que pereza me da vuestra chupipandi, paso de perder tiempo con juniors
Ale, ya podeis ir a vuestra cueva a seguir insultandome, que estais obsesionados
este chaval vive en los 90. seguro que entra a una sala de sevidores ahí fumando puros
ningún arquitecto software va a decidir qué pieza se compra o se monta en un server, a no ser que estés en una empresa de 5 personas
ontopic: va a depender un poco de la empresa en la que entres y del proyecto. mi consejo personal sería que intentes tocar muchas cosas al principio aunque sea un marrón. si acabas, como ya han comentado, haciendo excels de mierda te vas a quemar y vas a perder los años iniciales que es cuando más ganas tienes
He tenido que comprobar la fecha del hilo, porque pensaba que estaba leyendo algo de los 90s/00s
Menudo silos en los que vivís y que orgullos estáis de ellos, increíble... Que yo no digo que la cultura DevOps sea la panacea, pero desde luego que es mil veces mejor que vivir en Devs vs Ops/Sistemas/Infra
#33 No, que eres un "clasista" de mierda está más que claro, eso es lo que aprendéis en las cárnicas?
Veo que el tema ha hecho un derail importante... igualmente gracias a todos los que habéis contestado.
#38 la verdad que lo de perder tiempo con juniors ha sido un comentario bastante lamentable jaja reitero que tiene que entrar en una empresa random, porque hay mucho "junior" como él dice que depende de dónde salga sale con muchas tecnologías nuevas más mamadas que nada
Yo además de elegir pieza a pieza el hardware de los servidores, elijo hasta el modelo de camion que los transportara de la fabrica a su sitio, no me fio de que lo lleven en un fiat multipla
#42 Y no te preocupa la carretera por donde lo transportan? el más mínimo bache en el firme puede hacer que un procesador se estropee. Luego te llegan piezas defectuosas y los juniors dirán que es culpa de DHL. Un buen jefe de proyecto sabe donde focalizar su atención.
#44 Cierto, también tendré que supervisar la creación del alquitrán de la carretera por donde vaya a ir el transporte
#17 Lógico, no todas las empresas tienen la misma capacidad para tener todo ese despliegue de personal, en la gran mayoría, las medianas/pequeñas, muchas veces el desarrollador se tiene que poner varios sobreros con distintos roles.
#45 Pero que vives en el siglo XX? Piensa en el futuro. La gasolina está muy cara. Que te traigan los envíos en Drones.
Así sólo te tienes que preocupar de: Licencia de vuelo de Dron, Condiciones medioambientales, peso y carga. De quienes pilotarán los drones.
Yo si no me traen las cosas en dron ni molesto al Junior para que las recoja
#48 No no, estas cosas modernas las carga el diablo, mejor que me lo traigan a caballo, y supervisaré el caballo desde el nacimiento, alimentación incluida
#49 Yo si que soy partidario de que el caballo viaje encima de un dron por el espacio aéreo. Pero supervisando la creación del dron y la educación del piloto desde sus inicios.
#42 el fiat multipla es un cochazo puto hater:
https://www.hotcars.com/fiat-multipla-review-worlds-ugliest-car-is-actually-an-enthusiasts-dream/
De la parte de programación.
Si un servidor se cae en producción es responsabilidad de sistemas detectarlo y arreglarlo, si me entero yo antes que ellos de entrada ya va mal la cosa, y en cualquier caso yo les aviso a ellos, no me pongo a arreglarlo.
Tu equipo de desarrollo pushea el código y se olvida, no? Si algo falla que se apañen en sistemas, aunque el problema pueda (y suele) estar causado por algún cambio en la aplicación, de la cual seguramente en sistemas tengan 0 contexto.
Yo creo que funcionan mucho mejor los equipos en los que tanto desarrolladores como "peña de sistemas" son responsables de las aplicaciones en producción...
Me estas hablando de otra situación distinta, si algo se cae después de hacer un despligue o el servidor lo tira la propia aplicación por algo que hace mal entonces si es cosa mía, yo te hablo de problemas de infraestructura.
Pero es que además me hace gracia que lo pongas como si para hablar con sistemas tuviese que coger un envase de yogurt con un hilo atado y hablar por él, cuándo es ir a su sitio y si hace falta quedarme sentado viéndolo con ellos.
#54Artoo-Detoo:Si algo falla que se apañen en sistemas
Si lo que falla es literalmente el sistema (se cae el server, le entra malware, despliega mal un .jar, se va la luz en Amazon, lo que sea) es cosa de sistemas. Si lo que falla es mi software porque he subido un bug sin saberlo y peta la aplicación o no hace lo que tiene que hacer lo tengo que arreglar yo. Quién se entera antes es casi que un tecnicismo si me apuras y depende más de temas de organización y de alertas.
Darse de bruces contra las biblias de espagueti de otras 70.000 personas y echar tu propia pasta como puedas sin que nada se rompa.
Arreglar un botón de no se donde, ajustar porcentajes que no devuelven la divisa correcta o añadir una nueva de algún lado (estas eran las peores porque habían variables por absolutamente todos lados que lo cambiaban todo, además a veces se aplicaban para algunos clientes y para otros no), otro día un cliente chino pide que les des soporte para sus DNIs y el mandarín...
Un poco de todo, otras veces eran incidencias más jodidas que otras, pero vaya, al final era mucho más debugar que escribir y mucho hablar (no me esperaba que tuviera que hablar tanto una vez fuera del insti) con consultores para saber qué mierda querían, así como con los compañeros/as para que te echen un cable.
Lo más mierda era estar haciendo tus cosas y tener que hacer 180 tras otro porque los jefes van haciendo sus asuntos burocráticos de mientras, así que en algunas ocasiones había que apretar para tener resueltas tus cosas, en otras se descartaban directamente o se ponían on hold hasta el infinito y así. Para esto tampoco había que programar mucho, sino ubicarse tras tanto cambio al día y de nuevo comunicarse.
Hablo de mi puesto de junior de hace un tiempo en una empresa grande, así que esta es mi experiencia personal, como se ve en otros posts cada cual se encuentra cosas distintas.
Al hilo del derail, creo que llevo sin tocar un VPS/maquina virtual desde 2011.
El cloud esta para usarse.
La verdad es q sois un poco flipados.
No todo el mundo trabaja en empresas de 350.000 personas. Muchos trabajamos como autónomos o en pymes con un equipo pequeñito de desarrollo y no pasa nada.
Parece q si no trabajas en un gigante eres un don nadie. La mayoría q trabaja en grandes no deja de ser un número fácilmente reemplazable.