Feda /dev/ - No Javascript allowed | Página 1938

Konishi #58111 21 Ago :psyduck:

#58108 sin mirarlo en detalle, ¿no te serviría algo basado en los Either de la programación funcional?

Wei-Yu #58112 21 Ago

#58111 el either es mi Result básicamente. De todas formas me he dado cuenta que puedo jugar al tetris con los tipos y no me queda tan ñapas.

Si esto es lo que estaba pensando:

spoiler

public class MediavidaHttpClient
{

  // ...

  public Result<JsonObject> PostWittyComment()
  {
    Func<JsonObject> func = () => new JsonObject();
    return Invoke(func);
  }
  
  Result<TResponse> Invoke(Func<T> func)
  {
    try
    {

        if (T is EmptyValue)
        {
          func();
          return Result<T>.Ok();
        }
        else
        {
          T value = func();
          return Result<T>.Ok(value);
        }
    }
    catch (Exception ex)
    {
      // super complex error handling
    }
  }

}

También puedo hacer algo así, delegando la construcción del either/result en la lambda:

spoiler

public class MediavidaHttpClient
{

  // ...

  public Result<JsonObject> PostWittyComment()
  {
    Func<Result<JsonObject>> func = () => Result<JsonObject>.Ok(new JsonObject());
    return Invoke(func);
  }
  
  Result<TResponse> Invoke(Func<Result<TResponse>> func)
  {
    try
    {

        return func()
    }
    catch (Exception ex)
    {
      // super complex error handling
    }
  }

}

No está mal definido a nivel semántico y es sencillo de entender (si tienes todo el contexto que ninguno de aquí tenéis por motivos obvios jeje).

Y creo que ya estaría, seguidme para más esquizofrenia y no olvidéis de darle me gusta.

1 respuesta

Konishi #58113 21 Ago :psyduck:

Pasando a contenido de calidad, previamente le había echado el ojo a ByteByteGo y acabo de ver que tienen una oferta en la newsletter.

¿Alguien que tenga acceso puede opinar sobre lo que tienen disponible en el archivo?

1 respuesta

Wei-Yu #58114 21 Ago

#58113 lo de bytebytego es prácticamente que los libros que tiene de system design interview sólo que con alguna infografía y escrito más corto. Yo creo que los libros cunden y de la newsletter me acabé desuscribiendo (aunque sólo tengo el primer libro y sólo lo he ojeado por encima así que no te puedes fiar de mí supongo).

Leagrove #58115 21 Ago

#58094 Si es que es lo que hablamos, saca video Moure y ahora Midu saca otro XDDD

1 respuesta

D

demorador #58116 21 Ago

#58115 Yo despues de ver muchos videos de esta gente y desde mi ignorancia, lo que veo es que siempre sacan lo mismo (obviamente para tener mas números), pero no enseñan realmente que es programar, y más aun me he dado cuenta esta tarde viendo uno de los videos de george hotz donde explicaba qué es la programación y que a la gente no le interesa saber que es realmente, que a la gente le interesa saber lo tipico, que es un CRUD, que es MVC, bueno lo de siempre pero que no quieren o no les interesa saber como funciona realmente la programación y hablaba y ponia ejemplos muy interesantes, yo la verdad es que me he saturado de ver siempre los mismos videos, 'como aprender a programar, como mejorar tu logica, como programar mas rapido, etc, etc..' y yo que soy un fpero en proyecto me he dado cuenta que parecen videos ''para dummies'', pero que no enseñan nada.

1

JuAn4k4 #58117 21 Ago

#58112 Y no puedes hacer un Either<Optional<T>, Error> ?

Es decir, el valor del resultado es opcional.

He vuelto de vacaciones ya, y me resulta curioso que en ningún puto país existan las persianas, creo que montarse una empresa de persianas internacional empieza a sonar buena idea.

2 1 respuesta

Konishi #58118 21 Ago :psyduck:

Yo empiezo a pensar que los influencers de programación de habla hispana son una CoverOp de alguna cárnica grande para que no les falte la mano de obra barata.

laZAr0 #58119 21 Ago Cofarde

#58117 ¿no las usan porque no existen o no existen porque no las usan?

2 respuestas

Kaledros #58120 21 Ago

#58119 Lo primero, Instagram está petado de americanos reaccionando a las persianas como los primates de 2001 ante el monolito.

4 1 respuesta

GaN2 #58121 22 Ago Inocente

#58120 confirmo que las casas aquí no tienen persianas, usamos los ‘blinds’ como se llaman aquí y cortinas opacas.

Cuando te mudas aquí te das cuenta de lo mierderas que son las casas y los hoteles para dormir. En la gran mayoría de sitios no tienen ni para tapar la luz de las ventanas y encima tienes los putos aires acondicionados dando por culo toda la noche como si tuvieras un camión en tu habitación

1 1 respuesta

Farmijo #58122 22 Ago

#58121 Y la manía de los aires acondicionados a 16 grados. Manda huevos resfriarse en verano en Nueva York y lo conseguí.

1 respuesta

GaN2 #58123 22 Ago Inocente

#58122 depende de la parte del país, en la zona oeste y donde yo vivo (PNW) no es tan exagerado. Ahora bien, vete a NYC o Texas y prepárate para llevar una rebeca y estar todo el puto rato poniéndotela o quitándotela

JuAn4k4 #58124 22 Ago

#58119 Un poco de ambas, creo que las necesidades van cambiando, están más acostumbrados a dormir con luz, pero claro eso se les pasa descubriendo cómo se duerme con poca luz.

B

[Borrado] #58125 22 Ago

Haciendo revisiones de CD-s viejunos... me he topado con mi super mod mIRC .... Lo más gracioso es un archivo llamado "Lo_Plagiado.txt":

---------------------------------------------------------------------

MëTâ£ Kî££ v1.0 - Lo plagiado de otros scripts....

**** Killer Zombie: Maqueta del script, Ventanas de: Sugerencias, Menus. Tb, algunos programas de
estadisticas, guerra, protección, bromas y Complementos como por ejemplo el "KZ Active X".

** X-Cript: La calculadora, Programas de guerra y protección
** MScript: Programas de guerra y protección
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niveles de plagiado...:

- Nada
** - Casi nada
*** - algo
**** - Bastante
***** - Casi todo

Como era eso... Los buenos artistas copian, los grandes roban :B

1 respuesta

Lecherito #58126 22 Ago A toda leche

#58125 pon el codigo fuente que el mitico $gettok era top xD

1

Jastro #58127 23 Ago Moderador

6 2 respuestas

Wei-Yu #58128 23 Ago

#58127 si tanto le echas de menos usa tus influencias de directivo de la cúpula de mv para que vuelva, que está baneado hasta 2025 xd

1 respuesta

Jastro #58129 23 Ago Moderador

ojala ser tan poderoso, me han quitado mi bot de contenido que me generaba 100k

1

pantocreitor #58130 23 Ago

Tengo la maravillosa tarea de documentar una API para tontos, cuando hacer un get o cuando conectarse por websocket para rcibir datos en vivo.
Me lo han echado para atrás 3 veces por ser demasiada compleja mi explicación, que quieren mas ejemplos y que una persona sin background técnico sea capaz de entenderlo, pero para que qres hacer una guía de integración para terceros que no tengan background técnico???

Estas tareas me tocan los cojones ni os lo imagináis...

3 respuestas

PhDfailer #58131 23 Ago

#58130 puta burocracia, nuestros proyectos con la administracion nos piden documentos hasta para cagar que luego ni se los leen

Asqueadisimo de colaborar con sector publico

1 respuesta

vincen #58132 23 Ago Inocente

#58130 Copia y pega el texto que ya has hecho a chatgpt y dile que lo resuma para tontos.

2 1 respuesta

eXtreM3 #58133 23 Ago

#58130 #58132 que básicamente viene a ser esto

Guía para Integración con nuestra API

Esta guía está diseñada para ayudarte a conectarte con nuestra API, ya sea para obtener datos o recibir actualizaciones en tiempo real. Vamos a explicarlo con ejemplos simples para que cualquiera pueda seguir los pasos.

1. Obtener Datos con una Petición GET

¿Qué es una petición GET?

Una petición GET es como pedir información a un sitio web. Por ejemplo, si entras a una tienda en línea y buscas "zapatos", estás haciendo una petición GET para obtener una lista de zapatos.

Cómo hacer una petición GET a nuestra API

Supongamos que quieres obtener la lista de todos los productos disponibles en nuestra tienda. Esto es lo que necesitas hacer:

URL: https://api.mitienda.com/productos
Método: GET

Ejemplo en lenguaje humano:

Abre tu navegador web o una herramienta como Postman.
Escribe esta dirección: https://api.mitienda.com/productos
Haz clic en "Enter" o en el botón de enviar (depende de la herramienta que uses).
La API te devolverá una lista de productos como si fuera una página web que muestra todos los productos disponibles.

Respuesta esperada:

[
    {"id": 1, "nombre": "Zapato Deportivo", "precio": 50},
    {"id": 2, "nombre": "Camisa Casual", "precio": 30}
]

1 respuesta

Seyriuu #58134 23 Ago

Chics, a ver qué opináis de una cosa de mi curro:

spoiler

Estamos haciendo un proceso nuevo que yo he segmentado así (a groso modo)
Paso 1 - Validamos los datos que nos llegan (que pueden ser 20, pueden ser 200, no está definido aún).
Paso 2 - Ponemos en la arquitectura de base de datos del producto en el que trabajamos los datos, en un estado, inicial. (Es un contrato, guardaríamos el contrato con los campos determinados en entrada, los cálculos que ya se hayan podido hacer, etc).
Paso 3 - Mostramos pantalla donde el cliente define una serie de datos
Paso 4 - Validamos estos nuevos datos
Paso 5 - Actualizamos en tablas los nuevos datos.
Paso 6 - El resto de la operativa que aquí no aplica.

Un compañero mío, persona que entiende bastante, comenta que él no haría los Pasos 1 y 2, si no que directamente mostraría la pantalla, y una vez obtenidos los datos con los que nos invocan y los datos introducidos por cliente, haría todas las validaciones, los cálculos, y demás, y en ese punto es cuando lo grabaría por primera vez en base de datos.

Mi perspectiva es que, sabiendo que el proceso actual que hace esto tiene miles de líneas de código confusas, si yo aislo los datos de entrada en un único punto y los paso a base de datos ya bien, de donde los recuperaré si los necesito (fuck rendimiento) y luego, valido los datos que me lleguen de cliente también de forma aislada y los actualizo en tabla, tendré un proceso mucho más fácil de desarrollar, de mantener, de leer y comprender, y de modificar.
Su perspectiva es que al final vas a hacer lo mismo separado en varias partes y que no le ve el sentido, sobre todo porque si mañana cliente nos pide que un dato que llega en el punto A ahora llegue en el B, tendrás que tratarlo dos veces (yo considero que no, lo quitaré del punto A y lo añadiré al B, en vez de añadirlo en el B y mantenerlo en el A).

Ya sé que la explicación es muy abstracta pero creo que más o menos se entiende. ¿Cómo creéis vosotros que es más adecuado? ¿Hacerlo todo de una o ir separando en partes?

Para darle un poco de idea, los datos que llegarían en el punto A son datos calculados de riesgo, seguros, bienes, tipos de contrato, etc, y los datos que vendrían en el punto B son calendario de pagos, interés a aplicar variable o fijo, etc, etc.

#58128 no, por favor, no.

2 respuestas

B

[Borrado] #58135 23 Ago

#58127 Tranquilo, la interacción con desu puede alterar la química del cerebro y llegar a crear una dependencia muy fuerte... se debería de ir pasando con el paso del tiempo ¿cuanto? es dificil de dar un valor exacto e incluso aproximado.

Cuando dejes de tener el mono, verás que te has quitado un componente tóxico del cuerpo... estarás más activo y con ganas de aportar contenido de calidad y no chorradas que realmente no interesan a nadie.

fehnd #58136 23 Ago

#58134 MI única pregunta es, si el paso 3 por alguna razón tiene un error, o no se acaban de definir esos datos, que pasa con el paso 1 y 2? lo digo porque la solución de tu compañero evita fallos, y la solución que propones ( en el caso de que haya un fallo ) puede necesitar un rollback de las operaciones del paso 1 y 2.

También hablo siendo más DevOps que dev, pero espero que ayude

1 respuesta

pantocreitor #58137 23 Ago

#58133 Algo así estoy haciendo ahora. Este es el url del servicio, le mandas esto y recibes y esto. Con estos datos, si necesitas actualizaciones constantes, una vez sepas que evento o grupo de eventos quieres en tiempo real te conectas de esta manera y esto es lo que vas a recibir encada caso.

Tengo que obviar palabras "técnicas" como polling, websocket, payload, suscripción, API, endpoint...

Pero sigo pensando que no tiene sentido hacer documentación de integración para alguien sin conocimientos, incluso si son de QA el postman lo tendrán bien mamado xD

#58131 Esta actualización de la documentación es gracias a un cliente que cada 2x3 se queja de que tiene petado los servidores y el 100% de los casos es por utilizar mal la plataforma y hacer polling a la API pidiendo grandes cantidades de datos en vez de suscribirse y recibir solo los cambios, por lo que quieren que hagamos algo para tontos y que cuando la líen plantarle el documento en la cara para qu eno se quejen.

#58134 que tiempo están los datos RAW en DB??? No te renta meterlos en una DB KV tipo redis o similar y procesarlos desde ahí??? Incluso si la retención va a ser muy corta meterlo en una cola,array,variable/whatever interna para procesarlo cuando toque.
Otra duda, tienes que validar datos manualmente? No puedes mapearlos tal cual???

2 respuestas

B

[Borrado] #58138 23 Ago

#58137 Haz una leyenda donde cada palabra es un color... Websocket es Amarillo, API es azul, etc... y hablas de colores... todo muy chupi chuli...

Hablemos de tecnologías punteras...

1 1 respuesta

pantocreitor #58139 23 Ago

#58138 Me acabo de acordar del hilo creo que de HDA de la tía ligando con él y el diciendo que vivía en un faro con su famila, que si el dinero eran elefantes rosas y los nudes eran no se que xD

PD: me falta la banda sonora de prometheus de fondo

B

[Borrado] #58140 24 Ago

2

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

MëTâ£ Kî££ v1.0 - Lo plagiado de otros scripts....

Guía para Integración con nuestra API

1. Obtener Datos con una Petición GET

¿Qué es una petición GET?

Cómo hacer una petición GET a nuestra API

Ejemplo en lenguaje humano:

Respuesta esperada:

Usuarios habituales