Feda /dev/ - No Javascript allowed

Normas
spoiler
Personas non gratas
Memes feda dev




Frave

Personalmente eeuu ni con un palo, viví allí un año, yo creo que estan mejor canada o australia por ejemplo.

Fyn4r

#38608 hace unos años que vayas en barco, pero ahora lo controlan, así que prueba la frontera con México a ver

_Rpv

#38608 vente a Irlanda conmigo

Zoko

#38608

Yo en Zürich desde hace dos años. Si necesitas algo avisa

1 respuesta
Kaledros

¿No había alguien por aquí que vivía en EEUU o lo he soñado?

2 respuestas
SupermaN_CK

#38615 @GaN2 creo.

1 respuesta
Amazon

#38614 Algun truco para evitar 6 euros al hacer escala ahi? Fui a Italia hace unos meses y no lo sabía y bueno, son 6 euros pero habría molado ahorrarlos

B

Telescopio James Webb... ejecutando JavaScript:

The primary command source in normal operations is the Script Processor Task (SP), which runs scripts written in
JavaScript upon receiving a command to do so. The script execution is performed by a JavaScript engine running as
separate task that supports ten concurrent JavaScripts running independently of each other. A set of extensions to the
JavaScript language have been implemented that provide the interface to SP, which in turn can access ISIM FSW
services through the standard task interface ports. Also, to provide communication between independently running
JavaScripts, there are extensions that can set and retrieve the values of shared parameters.

Signos evidentes del declive mundial...

GaN2

#38615 #38616 yep servidor vive en Seattle y @GlitterSpark vive en San Antonio. Creo que hay algún otro florero que también vive en USA

LR

Pregunta tonta pero... Como hacéis deploy de vuestras cosas en casa a vuestros propios vps? Docker? Git?

Estoy trasteando con node y he hecho un par de mierdas que quiero subir y probar y la semana que viene tocará laravel y un par de cosillas más. Como nunca he usado docker pues eso, no se que veis más útil. Si fuera por mí, seguía tirando de FTP...xD

2 respuestas
B

#38620 Para mis historias... si es algo privado tiro de gitlab, si es algo público tiro de github (en principio github deja o dejaba crear repos privados también... pero llegaron tarde, se siente).

Yo básicamente lo que tengo es un par de llaves creadas para la comunicación, en este caso, github <-> servidor ... entonces en el action de despliegue del repo lo que hago es configurar en el servidor del action el servicio ssh (tengo como secreto la llave privada generada) y establezco mi servidor como de confianza.
Con eso ya puedo lanzar un "ssh -c" desde el action... y hago lo que sea oportuno en mi servidor. Como por ejemplo.. actualizar el repo local y reiniciar el servicio.

Si lo quieres hacer manual... para mover cosas entre máquinas tiro de "scp"... o lo monto como disco con sshfs

En ámbitos profesionales ya se usan cosas como ansible...

1 3 respuestas
Wei-Yu

#38621 hasta yo que sé lo que quieres decir no tengo ni puta idea de qué estás diciendo, no me quiero imaginar el que no sepa de qué hablas xd

#38620 hace poco lo monté todo con vercel+heroku, que se enganchan directamente al repo de github y te van desplegando solos.

Antes de eso el mapa mental que tenía era tener el repo en github con github actions y un droplet (vps) en digital ocean. En el vps instalas algo para tener webhooks (esto por ejemplo: https://github.com/adnanh/webhook). Con el github action le pegas al webhook de tu VPS para que dispare un script shell que redespliegue las cosas (ya sea via docker o simple git clone/pull o lo que sea).

4 1 respuesta
LR

#38622 miraré lo de vercel+heroku

En mi cabeza tenía pensado algo como lo que has puesto de github actions o mirar a ver cómo va jenkins, que entre otras cosas viene a ser lo mismo pero con extras por lo que vi en su momento.
Lo que no sabía hasta que punto era mejor tirar de ahí y ya organizarlo como vea, o tenerlo todo compartimentado con docker, el cual, nunca he usado y así tenía excusa para darle un poco.

Lo que entiendo de #38621 viene a ser lo mismo que has puesto en tu pero tirando de las opciones ssh que ya trae github + levantarte el ssh con el cifrado que veas y dejarlo a la espera de archivo con opciones que le metas desde el mismo github para ver que montar/modificar o hacer después del deploy (o eso he querido entender xD, que me corrija o lo explique para tontos si le apetece xD)

JuAn4k4

#38621 ¿ Pero no para desplegar cosas no ? Ansible / Chef y demás se usan más para configurar la máquina antes de meterle el software concreto (aunque si lleva software de plataforma). Se suele usar ArgoCD o Spinnaker en entornos profesionales, en casa puedes tirar hasta de github actions o cualquier ñapa que quieras hacer.

1 1 respuesta
B

#38624 Ansible lo he visto usándose para preparar el entorno de test y el deploy en producción... Si te saltas un poquillo la "idempotencia" y no te cargas volúmenes y tal... es factible.

** Un pipeline o un Action disparaban las acciones de Ansible.

Fyn4r

Fun fact, estoy en el slack de ansible y no se ni como se usa

2 respuestas
Kaledros

#38626 Ya sabes, fake it til you make it.

aren-pulid0

Nosotros hacemos provision y deploy con Ansible

1 respuesta
GaN2

#38626 yaml goes brrrr

De todos Ansible es súper simple, luego hacer cosas chulas es algo más complicado

JuAn4k4

#38628 Y como hacéis los rollouts ? Hacéis alguna estrategia o algo ? Red/Black o Blue/Green, canaries y demás ? Eso se puede hacer con Ansible ?

1 respuesta
neil90

Ansible solo ejecuta scripts, se puede hacer lo que quieras si te montas el playbook, aunque es probable que la mayoría de casos básicos los haya publicado alguien ya

wdaoajw

#38630 el tema de los rollouts es bastante más complejo de lo que parece, me refiero a llevarlo a prod y usarlo a través del cicd porque hay mil opciones. Usar loadbalancer externo y configurarlo al vuelo? Usar servicemesh? ALBs y confirmar al vuelo?

Al final es definir una estrategia y palante, la herramienta en si da igual. Pero resumiendo:

  • ansible: de usa para aprovisionar con las tools los nodos. Puede hacer más cosas, pero normalmente no se hacen con esto.
  • Jenkins/Tekton/etc: Son los encargados a alto nivel del pipeline, si hace falta llaman a ansible/herramienta que toque.
  • ArgoCD: se usa para hacer los despliegues
Wei-Yu

cómo funciona eso de que todo el mundo busca seniors para mentorizar a los juniors pero nadie busca juniors? Es como cuando te pidén el inglés en una empresa española "por si hace falta"?

2 respuestas
TheBrotha

#38633 dada mi dilatada experiencia como Junior (en un mes hago un año exacto trabajando de esto), si que hay empresas que buscan juniors, pero muy pocos quieren juniors que no hayan sido ya juniors para otros

Supongo que cosas de RRHH

1 respuesta
wdaoajw

Las empresas buscan "Juniors", que significa gente con experiencia y poco amor propio como para cobrar una puta mierda cuando debería cobrar el doble

5 1 respuesta
PaCoX

se ve que en agosto han caido varios por ransomware xD dep a los afectados

Kaledros

#38633 Porque no son juniors de los que no saben ni qué es git, sino juniors como #38634 de los que sólo hay que enseñarles cómo funciona el proyecto y poco a poco temas de diseño, arquitectura, buenas prácticas, etc.

1
JuAn4k4

No entiendo por qué no se buscan juniors si acaban haciendo las mismas ñapas que los seniors

6
privet

#38635 bueno, hay que matizar eso bastante

B

Duda rápida: ¿Es usar SessionStorage una mala práctica para almacenar el id de usuario?

3 respuestas

Usuarios habituales