MV Coders on fire

elkaoD

#210 olvídate de patrones. Como una primera "aproximación" intenta separar el programa en módulos. Por ejemplo, para este caso, en el servidor hay dos módulos claramente diferenciados:

  1. Servidor central
  2. Conexiones con cada cliente

Cada uno de ellos es una clase/módulo/loquesea (depende de cómo abstraiga tu lenguaje.) Yo además los separaría aún más:

  1. Servidor central
    1.1. Aceptador de conexiones
    1.2. Manejo de lista de clientes (nicks)
    1.3. Reenvío de mensajes a todos los clientes (canal)
  2. Conexiones con cada cliente
    2.1. Manejo de la conexión
    2.2. Manejo de mensajes

Cada una de estas sub-separaciones serían métodos concretos en este caso. Si quieres separar aún más la lógica puedes organizarlos como submódulos (o lo que sea), es decir, ahora ya te puedes plantear aplicar patrones para separar algo más la lógica del programa.

Yo lo que haría sería no ligar el manejo de mensajes en un sólo módulo si no separar cada mensaje en un manejador diferente, es decir, crearía una nueva clase manejador. La idea es la siguiente: en el momento en el que llega un mensaje, la clase ConexionCliente NO es la que se encarga de responder (2.2) si no que simplemente reenvía el mensaje al manejador. Este puede decidir realizar alguna acción (o no) y posteriormente consumir el mensaje (ya no lo tocan más manejadores) o reenviarlo (independientemente de si ha hecho algo o no.) Esto da un montón de flexibilidad porque desligas los mensajes de la conexión y permite crear diferentes tipos de conexión sin montarte películas. Ppor ejemplo, un admin podría tener manejadores para kickear y demás mientras que un usuario no, sin necesidad de añadir un "isAdmin" por todos lados.

La estructura quedaría algo así:

  1. Servidor central
    1.1. Aceptador de conexiones
    1.2. Manejo de lista de clientes (nicks)
    1.3. Reenvío de mensajes a todos los clientes (canal)
  2. Conexiones con cada cliente
    2.1. Manejo de la conexión y mensajes (crear conexión y reenviar a manejadores cada mensaje)
  3. Manejo de mensajes
    3.1. Acción

Así en el momento en el que el servidor (1) crea una conexión (2) le asocia a esa conexión ciertos manejadores (3)

Toda la separación "física" ya es cosa del lenguaje. Por ejemplo, en Java el manejo de mensajes lo implementaría como un interfaz (que cada manejador implementaría) mientras que en Scala cada manejador sería una simple función.

Ojo, esto es sólo una de las múltiples estructuras que puedes crear, pero creo que muestro bien el proceso que hay detrás de la separación y encapsulación.

Vaya, ya me he marcado otro tocho.

1 respuesta
B

Yo no lo he hecho, estoy saturado de entregas para la universidad y esto más que un kata era un puñetero maratón xdd (para mi nivel, claro).

Nucklear

#211 Gracias por la ayuda. Es que son cosas que suelen pasar al principio, que te lias con cosas y al final parece todo complicadísimo. Por ejemplo al ver la entrega de oip pienso que son obvias las separaciones, pero al empezarlo yo desde cero me lio un huevo.

Yo estoy con python, porque me parece uno de los mejores lenguajes para coger soltura y tocar diferentes "disciplinas", pero al no dominarlo al 100% hay veces que me encuentro con lagunas que se me hacen complicadas. Es lo que tiene salir del ciclo, que te pongan a hacer soporte de servidores y verme obligado a ser autodidacta para no estancarme...

Khanser

Esta kata no se si va a acabar siendo un fail de cuidado xD Yo entre pitos y flautas no me he podido poner, quería haberlo hecho en Dart, pero despues de tener más de la mitad me actualicé y la API IO me la cambiaron, no solo los nombres de los eventos, ahora habia fallos random que en la documentación no salia, así que me ha salido el tiro por la culata :D

1 respuesta
Nucklear

Yo visto lo visto voy a subir lo que tengo, es funcional pero no tiene todas las funcionalidades implementadas, pero viendo que lo que he hecho es una "trapallada" podéis lanzarme tomates xD

MVCoders Server
eisenfaust

Yo propondría katas cuya solución no implique más que una creación de un script de max 100 LOC. De lo contrario no contéis con gente que esté currando o con exámenes y además estos tochos luego no se los lee ni el tato.

1 2 respuestas
B

#214, #216: Cuando empecé a hacerlo me di cuenta la verdad. Pero bueno, animaos los que podáis por lo menos y luego adecuamos mejor los problemas.

elkaoD

#216 hombre, se puede hacer en menos de 100 lineas* (76 en concreto)

Está CASI todo, sólo falta evitar colisión de nicks, cambio de nick y mensajes privados.

https://gist.github.com/250536

EPIC

*vale, no tiene todas las "features" de la kata pero sí implementa canales, y aún así sigue siendo impresionante...

1 respuesta
B

#218: Pues sí. Pero ese código es muy poco legible a no ser que controles del tema concreto.

Un código en C/Java/Python lo lee cualquiera :P

#220: Pues si se los enseño yo (a la mía), al menos Java se le parecerá a la mierda asquerosa de Visual Basic que dio ella xDDD

1 respuesta
elkaoD

#219 le enseño los dos a mi novia y ve lo mismo: letritas y simbolitos xD

1 respuesta
B

En serio va a quedar así la cosa? <.<

Khanser

Parece que sí, vamos a tener que ir pensando en otra Kata, hemos ido demasiado rapido creo xD

1 respuesta
B

#222: Ok, pero yo ya que hice el server, pienso hacerme el cliente xDDDD Ya lo pondré cuando me de por ahí.

zoeshadow

Yo me he puesto hoy aprovechando que tenia un rato libre, pero me da a mi que hasta que no me den las vacaciones no le voy a poder dedicar mas tiempo xDD

Me toca mirarme todo el tema de sockets y eso desde 0, por que todavía no habia tocado nada, y estoy viendo que mejor ir poco a poco...

Una preguntilla básica ( estoy haciéndolo en java ), hay que crear un thread por cliente, ok, pero ¿cada cliente tiene que estar en un puerto distinto?

1 respuesta
EnZo

Yo tambien haré mi kata en php en cuanto me libere un poco, no me he olvidado :P

elkaoD

#224 lo del puerto... sí y no.

Cada cliente debe estar en un socket distinto, pero la clase ServerSocket se encarga de quedar escuchando en un único puerto e instanciar los sockets clientes cuando acepta sus conexiones.

Metaza

¿No se va a hacer otra?

B

Yo estoy esperando a ver si la gente vuelve a animarse.

Khanser

Bueno pues vamos a pensar en algo sencillo, y si hay movimiento la gente se irá animando.

15 días después
B

¿Qué os parece si retomamos el tema haciendo katas sacados de www.solveet.com o http://12meses12katas.com .

1 respuesta
Lecherito

http://www.mircscripts.org/challenge/ Estos los hacía yo hace como 5 o 6 años y era bastante divertido pero claro, molaba más cuando era un solo lenguaje y se debatían entre las distintas soluciones, como la eficiencia del código, en cuantos bits está escrita la solución...

Yo a los sencillitos sí que me apunto, a cosas como un "irc" pues... como que mola menos, pero sí que se podría hacer un "irc" como el que queríais por partes. Pero bueno eso ya es cosa de todos xD

B

#230 a mí me parece bien, cuando acabe los exámenes el 26 de junio.

Por cierto, algún buen lenguaje que se programe rápido para procesado de strings? (Es para estudiar la asignatura de criptografía xD)

edit: Ok, he visto que en MATLAB se pueden hacer cosas xD

1 respuesta
Nucklear

#232 ¿PERL no te sirve?

1 respuesta
B

#233 es que para lo que quiero hacer que es ir haciendo cálculos y pruebas no tengo suficiente experiencia con PERL. Pero MATLAB me va de PERLas j3j3j3j

2 1 respuesta
B

#234: Eres mi puto ídolo

1 respuesta
B

#235 espero que no lo digas por mi refinado sentido del humor xD.

eisenfaust

Se dice Perl, no PERL. Patanes.

Por cierto, buena suerte a la hora de encontrar algo mejor que éste para procesar texto xD

1 respuesta
B

#237 en serio, a mí me tenéis desquiciado ya todo el mundo, a quien le digo que uso Perl para algunas cosas me dice que menuda mierda de lenguaje y que solo sirve para prácticas de tiro, ahora pido por otro y me dices que no hay mejor para procesar texto... :P

De todas formas como ya digo Matlab me ha servido más para lo que quería hacer por el intérprete de comandos, que ahora me dirás que Perl también lo tiene, pero tengo 4 días para practicar y no domino tanto Perl.

1 respuesta
B

#238: Me consta que Perl es uno de los lenguajes más potentes en procesado de strings con todo el tema de regexp. De oídas, nunca lo he utilizado.

1 respuesta
Lecherito

Para el procesado de strings MSL también mola, aunque parezca una trolleada :p