test.sh
response=$(curl http://localhost:8080/api/method)
if echo $response | grep 'foo'; then echo OK; else echo FAIL; fi;
la autentica salud para probar endpoints
os veo cada dia desde el teletexto
Enviado desde mi centro de planchado Rowenta
#27754 pfff vaya noob
HTTP_STATUS="$(curl -IL --silent http://example.com | grep -o XXX )";
if [ "$HTTP_STATUS" == "XXX" ]
#27762 en mi empresa es más fácil salir limpio del tribunal de Estrasburgo que de un pull request.
#27763 yo hago las review de mis propios pull request, ser solo un 1 programador en un proyecto grande es como jugar solo a un juego de mesa para 4 personas.
A veces finjo tener varias personalidades para darle más vida a mi trabajo.
#27750 Cuando quieras te enseño un poco de programación funcional, sé lo justo y necesario, un paso más que tu.
Me está gustando Javascript vanilla, Typescript y hacer cositas con PixiJs
Ale, que tengáis una buena noche
Los que hacéis code reviews a menudo con las webs de Github/Gitlab, ¿cuales son vuestros principales problemas con ellas? ¿Usais alguna otra herramienta?
En la empresa usamos GitLab y la vista de los cambios de un merge request me resulta horrible de usar. He empezado a hacer for fun una app nativa (mac) y necesito ideas sobre que desarrollar más o menos.
#27778 Para mi el principal pain point es con aquellas PRs un poquito más grandes, que muchas veces dividir en 2 PRs hace que el reviewer pierda contexto y dejándolo en una sola puede ser difícil de revisar.
Para ese tipo de casos había pensado en algún tipo de extensión de GitHub en la que el que abra la PR pudiera añadir contexto a los diferentes cambios, haciéndolos más fáciles de revisar.
Otra cosa interesante también sería la posibilidad de "apilar" cambios en distintos subgrupos, pero formando todos parte de la misma PR. Esto agilizaría mucho mi trabajo que a veces consiste en 1 PR de refactor + 1 PR añadiendo la nueva feature, que supone 2 procesos de revisión distintos + tiempo de corregir lo que te propongan etc...
#27779 Lo de apilar cambios, tanto GitLab como GitHub soportan revisar commits específicos y cambios desde tu ultima review. GitLab permite revisar "versiones" que son grupos de commits pusheados juntos a una PR abierta. E.g. abro pull request vacia, trabajo en feature 1 y pusheo, luego en feature 2 y pusheo, en GitLab puedo revisar version 1 y version 2 ¿No tiene GitHub algo equivalente?
Lo que creo que no soportan ninguna de las dos, es seleccionar varios commits consecutivos. ¿Aportaría algo extra? (Juntar commits no consecutivos no tiene sentido)
Con lo de añadir "contexto" te refieres a comentarios? Otros archivos? A priori solo puedo hacer cosas que sean posibles con las APIs de GitLab/GitHub, no se exacto que tienes en mente.