Si usas TYPESCRIPT, DEBERÍAS tener MENOS TESTS

แชร์
ฝัง
  • เผยแพร่เมื่อ 23 ส.ค. 2023
  • Usa mi código cambly-betta-50 y haz clic aquí: 🔗 cambly.biz/cambly-betta-50 para acceder a Cambly con un 50% de descuento!
    Conviértete en miembro de este canal para disfrutar de ventajas:
    / @bettatech
    👾 Redes sociales 👾
    ► Twitter: / bettatech
    ► Instagram: / betta_tech
    ► Canal Secundario: / @forkdebettatech
    ► Discord: / discord
    👨🏼‍🏫 MIS CURSOS 👨🏼‍🏫
    👽 Curso de iniciación a la programación con JavaScript:
    ► bit.ly/3kr4bTc
    👽 Curso de desarrollo backend con NodeJS y Express:
    ► bit.ly/3n4sirS
    👕 MERCHANDISING DEL CANAL:
    ► Tienda TH-cam: / bettatech
    ► Tienda Teespring: teespring.com/stores/bettatec...
    ⭐️ AFILIADOS ⭐️
    🎵 TODA la música es de EpidemicSound:
    ► www.epidemicsound.com/referra...
    ✉️ CONTACTO PROFESIONAL:
    ► Respuesta no garantizada:
    bettatechyt@gmail.com
    📚 LIBROS 📚
    Design Patterns
    ► amzn.to/39XuQlq
    Head First Design Patterns
    ► amzn.to/2uq6XUq
    Refactoring
    ► amzn.to/2SQnf2c
    Clean Architecture
    ► amzn.to/3bZVonJ
    Clean Code
    ► amzn.to/32WVKq3
    Introduction to Algorithms
    ► amzn.to/34SyVFP
    Cracking the Coding Interview
    ► amzn.to/2QkdwC6
  • วิทยาศาสตร์และเทคโนโลยี

ความคิดเห็น • 62

  • @fabianromero1660
    @fabianromero1660 10 หลายเดือนก่อน +24

    nunca me imagine que las maquinas de estado se pudieran usar asi, que buen trabajo Betta ! Como que una luz se me ilumino jaja

    • @BettaTech
      @BettaTech  10 หลายเดือนก่อน +3

      Gracias!!!!!!

  • @full-music
    @full-music 10 หลายเดือนก่อน +14

    Por un momento pensé que mi pantalla estaba rota, que susto jaja

    • @ciltocruz
      @ciltocruz 10 หลายเดือนก่อน +1

      +1

  • @alberteinstein7412
    @alberteinstein7412 10 หลายเดือนก่อน +5

    Es curiosa la forma que se aplica. Conocia las máquinas de estados desde que las usé en el desarrollo de sistemas en chip (en FPGA), cómo verás son sistemas críticos donde no se toleran los fallos. Es una forma curiosa que no conocía y que voy a profundizar más.
    En este caso se usan máquinas de tipo moore, para una mealy sería necesario separar las tareas del software en dos partes que serían la que gestiona los estados y la que gestiona las salidas. Esto se usa en lenguajes concurrentes como Erlang.
    También cabe recalcar que tiene el inconveniente de que acompleja demasiado el código siendo poco viable para proyectos que no necesitan tanta robustez y que en su lugar necesitan ser facilmente mantenibles.

  • @francogames107
    @francogames107 10 หลายเดือนก่อน +1

    BettaTech, desde el punto de vista profesional sos EL MEJOR o DE LOS MEJORES canales de programación, todas cosas útiles y cero humo, deberías tener muchísimas más views...

    • @BettaTech
      @BettaTech  10 หลายเดือนก่อน +1

      Muchisimas gracias!!!!!!!

  • @SoyFYDev
    @SoyFYDev 10 หลายเดือนก่อน +3

    Me encanta que haya gente como tú haciendo contenido más técnico. ¡Muy interesante!

  • @sionramosmaquinola6195
    @sionramosmaquinola6195 10 หลายเดือนก่อน +7

    2 cosas primero banco tu contenido un montón me gustan tus vídeos el tema es que el ejemplo que das no tiene una comparación sin tipado. Básicamente lo mismo es aplicable en js(este caso en concreto), hubiese estado interesante que muestres como se manejaría el error a la hora de instanciar ConnectedSocket. Y ejemplos de los test que se ahorrarían. El concepto esta bueno pero la resolución no la senti clara.

  • @glaze4629
    @glaze4629 10 หลายเดือนก่อน +4

    Como concepto esta interesante, pero y si la coneccion se pierde mientras tienes el objeto ConnectedSocket? Ahi que haces? no me quedo claro o si ConnectSocket no se logra conectar que? Entiendo el punto de que te ahorras los tests del unhappy path, pero sigue sin quedarme claro como seria el manejo de errores, porque al final pues tendrias que testear que se conecte o no, que hacer cuando se pierda la connecion tambien. Teoricamente los unhappy path siguen ahi por la naturaleza misma de los websockets.

  • @replicante8226
    @replicante8226 10 หลายเดือนก่อน +3

    Enhorabuena por el vídeo, ya que es muy interesante.Este tipo de vídeos son los mejores que haces Martín, no dejes de hacerlos a pesar de tu nuevo proyecto con The Commit Show.

    • @BettaTech
      @BettaTech  10 หลายเดือนก่อน

      Muchisimas gracias!!! Ahi seguiran😁

  • @Jquint3ro
    @Jquint3ro 10 หลายเดือนก่อน +1

    La velocidad de tus explicaciones es la justa y necesaria.

  • @terry-
    @terry- 7 หลายเดือนก่อน

    Genial! Muy interesante ver como aplicar patrones de diseño en el mundo real y derivados de estos.

  • @3a8o
    @3a8o 10 หลายเดือนก่อน

    Gracias!! Justo estoy estudiando estos temas en la universidad y ahora se me han aclarado algunas dudas que tenía

  • @manuel-rubio
    @manuel-rubio 10 หลายเดือนก่อน +4

    No creo que sea buena idea hacer un objeto por estado de conexión porque no es algo que nosotros controlemos. Si tienes una copia del objeto SocketConnected pero la conexión fue cerrada desde el otro extremo o te quedaste sin Internet, el código no lanzó el evento a tiempo y tú estás usando un objeto incorrecto y te dará un error de ejecución difícil de anticipar porque te confiaste mucho en que los tipos te resolverían el problema.

    • @luismenv
      @luismenv 10 หลายเดือนก่อน +1

      Intentan simplificar un problema generando muchos más

  • @jrag-dev
    @jrag-dev 10 หลายเดือนก่อน

    Esta explicación me gusto mucho porque justo estoy estudiando patrones de diseño usando Java

  • @Sebastian_Desu
    @Sebastian_Desu 10 หลายเดือนก่อน +1

    Excelente video me gusta cuando se habla de tecnología de manera un poco mas técnica

  • @rastersoft
    @rastersoft 10 หลายเดือนก่อน +3

    Como idea no está mal, pero... ¿Y si falla la conexión del socket?

  • @CicloKubits
    @CicloKubits 10 หลายเดือนก่อน

    Excelente contenido me gustó mucho y aprendí algo nuevo gracias nunca parés

  • @joelmartinez7326
    @joelmartinez7326 10 หลายเดือนก่อน

    Una pregunta BettaTech. Quiero ser backend y sabes que para uno resolver problemas en un lenguaje específico, se necesita aprender estructura de datos y algoritmos, pero ¿puedo aprender las funciones que traen los lenguajes para esas estructuras de datos o aprenderla tal y como hacen los tutoriales?

  • @jp_pineda
    @jp_pineda 10 หลายเดือนก่อน

    ¡Gran video! Como aporte, con Rust se puede usar PhantomData para manejar estados, lo cual permite que una estructura (las "clases" de Rust) implemente métodos distintos dependiendo de su estado, ya que para Rust son tipos diferentes.
    Lo mejor de todo es que en este lenguaje el tamaño de las estructuras es igual a la suma del tamaño de sus atributos, por lo que si nuestros estados son estructuras sin atributos, da como resultado que el uso de estados es una abstracción a costo 0.

    • @BettaTech
      @BettaTech  10 หลายเดือนก่อน +1

      Increible!! Me encantaria poder trabajar con Rust 😂

  • @carlosdev000
    @carlosdev000 10 หลายเดือนก่อน +2

    ¿Una solución al problema de la creación de múltiples objetos no sería extraer el comportamiento de cada estado a una interfaz y en los métodos de transición de estado retornar `this` y en la signatura del método especificar que se está retornando un objeto del tipo de la interfaz? Además, para estar completamente seguro de que se usará el estado retornado y no la referencia al objeto original, se podría tener una variable con estado interno. Sería una comprobación en tiempo de ejecución, pero idealmente la gente usará la referencia retornada en el método de transición para sacarle el máximo provecho al sistema de tipos. No sé si haya alguna forma de invalidar una variable, como por ejemplo en Rust consumiéndola. No soy muy experimentado en TypeScript. 😅

    • @luisoncpp
      @luisoncpp 10 หลายเดือนก่อน

      Me gusta bastante la idea de reutilizar el mismo objeto y usar cada estado como una interfaz, me sorprende que se te haya ocurrido si no tienes experiencia en Typescript (a mi me confundió bastante el _ducktyping_ de TypeScript, porque yo vengo de C++).

    • @danisales2105
      @danisales2105 10 หลายเดือนก่อน

      Si te he entendido bien (puede que no), sugieres utilizar una especie de SuperState con la implementación de todas las posibilidades de la máquina de estados, y tener las ventajas de validación estática. Esa idea tiene muchos problemas a la hora de mantener el código:
      En la gestión de cada acción o de las transiciones, tendrías que discriminar la acción a realizar en función del estado interno. Creo que no existe ninguna forma de verificar que lo que si el tipo/interfaz dice que se puede realizar una determinada acción o transición, realmente sea así y al final necesites hacer exactamente los mismos tests que si no tuvieras tipado.
      Posibilidades para gestionar las ramas de ejecución según la variable de estado dentro de cada método:
      - Hacer múltiples if-else según el estado. Si añades un nuevo estado, no hay nada que te obligue a implementar esa rama. Si lanzas un else genérico que no haga nada o lance un error, es una comprobación en ejecución. Si quitas un estado, tampoco te avisa directamente de que el estado no existe, tendrías que borrar el identificador del estado primero. Tampoco creo que haya forma de vincular estáticamente la existencia de un estado con la existencia de su identificador (lo cual puede derivar en identificadores que no se usen o en ramas de estados que ya no existen).
      - Hacer un switch soluciona algunos problemas, porque se puede obligar a que existan los 'case' para todos los identificadores poniendo en el caso default un check con un tipo 'never'. Pero mantiene el resto de problemas de if-else. Añade también otro problema de error humano, y es el olvido de break/return de algún caso.
      En ambos casos, hay que tener en cuenta que tanto para añadir comportamiento como para modificarlo, hay que tocar código existente (sí, añadir un case o un if-else es modificar código existente). Con esto básicamente te estás saltando el principio de Open-Closed. No quiere decir que la solución no vaya a funcionar, sino que probablemente más pronto que tarde va a dar problemas de mantenibilidad por errores humanos. Por lo que la mejor idea que se me ocurre es hacer la implementación de cada estado por separado y añadirla al SuperState, de modo que con polimorfismo, se llame simplemente al método del estado actual y no haya que hacer esta comprobación con identificadores.
      El problema es que aún así, hay que gestionar los casos en los que no exista la acción o el cambio de estado (lanzando un error, no haciendo nada...) para cada estado, teniendo también en cuenta que esto puede cambiar a futuro y quieras que métodos que no debían funcionar funcionen y al revés, y no haya forma estática de comprobar que efectivamente estén implementadas. Esto dice a gritos que estamos incumpliendo el Principio de sustitución de Liskov (LSP). O sea, que tenemos el problema que básicamente te he descrito. Si se puede solucionar de alguna manera, no se me ocurre. Si a ti se te ocurre, te invito a compartirlo.
      Estoy implementando una solución propia para la Máquina de Estados en TypeScript basado en lo que BettaTech menciona en el vídeo, y que gestiona la invalidación de instancias de estados anteriores. Si te interesa, dímelo y pongo aquí el repo cuando la haya terminado.
      Y perdón por la parrafada. Estas cosas son más complejas de lo que a veces parecen xD

  • @darioerazo2125
    @darioerazo2125 10 หลายเดือนก่อน

    que video tan espectacular, gracias

  • @luisoncpp
    @luisoncpp 10 หลายเดือนก่อน

    Muy interesante video, sin embargo de inmediato se me ocurrió una forma de poder extender este patrón de diseño, y que creo que habría sido interesante mencionar:
    class InternalSocket {
    // Aquí puede poner información compartida que no se quiera duplicar en cada cambio de estado.
    // es posible poner todos los miembros publicos y evitar los problemas de encapsulamiento dejando la clase
    // sin exportar
    ....
    }
    export class ConnectedSocket {
    constructor(private internal : InternalSocket) {}
    disconnect() : DisconnectedSocket {
    ....
    }
    ....
    }
    export class DisconnectedSocket {
    constructor(private internal : InternalSocket) {}
    connect() : ConnectedSocket {
    .....
    }
    }

  • @__renesan
    @__renesan 10 หลายเดือนก่อน

    Gracias 🇲🇽

  • @josesevilla1539
    @josesevilla1539 10 หลายเดือนก่อน

    Me ha encantado el video!! Super interesante y muy útil. Un 10!!

    • @BettaTech
      @BettaTech  10 หลายเดือนก่อน

      Muchisimas gracias!!!!

  • @Elias-gk4nu
    @Elias-gk4nu 10 หลายเดือนก่อน

    Muy bien video

  • @pabloartero1155
    @pabloartero1155 10 หลายเดือนก่อน

    Cómo bien se ve en el minuto 1:11, python no es un lenguaje de tipado estático, lo que según leí, lo inhabilita para hacer TyDD (type-driven development). Sin embargo me pregunto si no se podrá hacer algo parecido de todas formas con bibliotecas como pytyped o pytype. 🤔

  • @jassencastilloespinoza4780
    @jassencastilloespinoza4780 10 หลายเดือนก่อน

    hola! excelente video! consulta, en el minuto @11:39, se muestra la definicion de la clase websocket con el atributo #state, que hace el numeral o gato antes de un atributo en typescript?

    • @luisoncpp
      @luisoncpp 10 หลายเดือนก่อน

      En Javascript sirve para denotar miembros privados (en TypeScript se pueden denotar de ésa manera o añadiendo el modificador "private" antes).

  • @julian_handpan
    @julian_handpan 10 หลายเดือนก่อน

    Python y ruby también hay un paso previo antes la ejecución de un binario…

  • @pedrogabriellopezjuez6352
    @pedrogabriellopezjuez6352 10 หลายเดือนก่อน

    Gracias Betta, fue una explicación muy buena .

    • @BettaTech
      @BettaTech  10 หลายเดือนก่อน +1

      Gracias a ti por ver el video!!

  • @vanstanian
    @vanstanian 10 หลายเดือนก่อน

    Con el patrón state puedes encapsular la implementación interna de las clases en una interfaz execute siempre que el lenguaje permita polimorfismo. ¿No? Y así te evitas que se conozca la implementación de todo quisqui. Quizá aquí habla un programador java de más, ¿Eh?

  • @oscar-gx4lt
    @oscar-gx4lt 10 หลายเดือนก่อน

    me mato el meme de de la función sort() de javascript jajajajajaja

  • @franciscoalbertomm7768
    @franciscoalbertomm7768 10 หลายเดือนก่อน

    Buen video, este consepto se usa en flutter con BLoC para manejar el estado de la aplicacion.

    • @BettaTech
      @BettaTech  10 หลายเดือนก่อน +1

      Ostias, no lo sabia!

  • @SkillTrailMalefiahs
    @SkillTrailMalefiahs 10 หลายเดือนก่อน

    Excelente, que calidad. Cada video es mejor que el anterior en cuanto a calidad de producción... Y los conocimientos bueno tu sabes qu eso es variado pero al final no hay desperdicio en ello!

  • @luismibm
    @luismibm 10 หลายเดือนก่อน

    Muy buen vídeo Martín! Pero no seas tan duro contigo mismo y enciende el aire acondicionado hombre que estás chorreando...😘😂

    • @BettaTech
      @BettaTech  10 หลายเดือนก่อน

      Sabes lo peor? Estaba encendido xdddd

  • @matiturock
    @matiturock 10 หลายเดือนก่อน +1

    moy lendo el filtro CTR, la verdá

  • @julian_handpan
    @julian_handpan 10 หลายเดือนก่อน

    El Type Driven Design no es más que el pateo de diseño Prototype. No es una cosa, Uni testing cubre los types por eso Type Drive Design no es un tema…

  • @nadadenadanada888
    @nadadenadanada888 10 หลายเดือนก่อน

    me recuerda a value object pero mas completo

  • @RosembergPorras
    @RosembergPorras 10 หลายเดือนก่อน

    La parte que no entiendo es porque esto nos hace tener menos test? ahora tenemos 2 componentes que probar, y ademas tenemos que modificar la logica que use a este sockets para que tenga que gestionar estos dos tipos de objetos a menos que usemos un orquestador de "estados" que gestionaria estos dos tipos de objetos (ya que ahora cada objeto es la representación de un estado) y tendriamos que hacerle test tambien enfocado en comprobar que el orquestador funcione de manera correcta, entonces no se si para este ejemplo sea el mejor de los casos, ya que si, se fuerza al flujo a que los metodos esten mas segregados aun (un objeto se encarga de gestionar la creacion y otro la conexion) pero pues a la larga estamos es escalando la complejidad y quien use esto, debe incluir el test del manejo de estos "estados"

    • @BettaTech
      @BettaTech  10 หลายเดือนก่อน +5

      La cosa está en que te ahorras todos los test tipo: "Debe dar error si se intenta emitir un evento sin haber conectado", porque de eso se encarga el sistema de tipos. Directamente no te compila porque es imposible ese estado.
      Ningun test podra testear que eso sucede (que se emite un error) porque es un estado imposible. No digo que elimine TODOS los test, pero si los que son inútiles (nunca deberias poder hacer eso que estás testeando para que no pase)

  • @SukunaRyomen-lo8wu
    @SukunaRyomen-lo8wu 10 หลายเดือนก่อน

    👍

  • @javiergarciafillol4454
    @javiergarciafillol4454 10 หลายเดือนก่อน +1

    Yo me negaba a aprender typescript y ahora no puedo programar sin el xD

  • @raw8319
    @raw8319 10 หลายเดือนก่อน

    No he entendido nada pero espero poder entenderlo algun dia ❤

  • @miguelandresa.m106
    @miguelandresa.m106 10 หลายเดือนก่อน

    "ConnectedSocket"... *Se va el internet*

  • @diearmor19
    @diearmor19 10 หลายเดือนก่อน

    Suscrito de una 😂

  • @pellax
    @pellax 10 หลายเดือนก่อน

    Hacer cinco céntimos es un catalanismo que no creo que tenga traducción al castellano estándar y no sé qué entenderán los del resto del territorio español

    • @BettaTech
      @BettaTech  10 หลายเดือนก่อน +1

      Jajaja ni me di cuenta 😅

  • @pieroasd
    @pieroasd 10 หลายเดือนก่อน

    TypeScript destruye a los programadores novatos y es inútil para los
    Programadores expertos

    • @luisoncpp
      @luisoncpp 10 หลายเดือนก่อน

      ...pues yo soy experto y me es bastante útil, no entiendo por qué ésa aseveración
      Tampoco sé si entiendo por qué "destruye a los programadores novatos", no me parece que sea más complejo que Java, que muchas veces es el primer lenguaje que se les enseña a los novatos.

  • @robertov2554
    @robertov2554 10 หลายเดือนก่อน

    y porque no en java?¿ es lo mismo, o en C#¿