MV Coders on fire

elkaoD #211 May '12

#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:

Servidor central
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:

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)
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í:

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)
Conexiones con cada cliente
2.1. Manejo de la conexión y mensajes (crear conexión y reenviar a manejadores cada mensaje)
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

[Borrado] #212 May '12

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 #213 May '12 BugHunter

#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 #214 May '12 :psyduck:

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

1 respuesta

Nucklear #215 May '12 BugHunter

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

#!/usr/bin/python
# -*- coding: utf-8 -*-

import socket
import re

# COMMAND LIST: L: UserList N: Nickname J: Join X: Disconnect M: Message P: Private Message


userlist = {}

#Funciones

def join():
    if userlist.get(parser[1]):
        print "User already in use"
        sc.send("0")
    else:
        userlist[parser[1]] = parser[1]

#_________

conexion = socket.socket()
conexion.bind(("127.0.0.1", 9999))
conexion.listen(10) 

sc, dir = conexion.accept()

print "Soy el servidor y he recibido una conexion de " + str(dir[0]) + ":" + str(dir[1])

while True:
    #Creamos el buffer con un tamano maximo de 1024 bytes
    buffer = sc.recv(1024)
    

print "Recibido:" + buffer

parser = re.split(":", buffer)

if parser[0] == "L":
    pass
elif parser[0] == "N":
    pass
elif parser[0] == "J":
    join()            
elif parser[0] == "X":
    pass
elif parser[0] == "M":
    pass
elif parser[0] == "P":
    pass
else: 
    print "El comando introducido no es valido. L: UserList N: Nickname J: Join X: Disconnect M: Message P: Private Message "

#Enviamos la respuesta al cliente 
sc.send("Test completado, tu servidor funciona correctamente")

sc.close()
conexion.close()

eisenfaust #216 May '12

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

[Borrado] #217 May '12

#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 #218 May '12

#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

[Borrado] #219 May '12

#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

#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 #220 May '12

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

1 respuesta

B

[Borrado] #221 May '12

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

Khanser #222 May '12 :psyduck:

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

1 respuesta

B

[Borrado] #223 May '12

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

zoeshadow #224 May '12

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 #225 May '12

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

elkaoD #226 May '12

#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 #227 May '12

¿No se va a hacer otra?

B

[Borrado] #228 May '12

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

Khanser #229 May '12 :psyduck:

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

B

[Borrado] #230 Jun '12

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

1 respuesta

Lecherito #231 Jun '12 A toda leche

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

[Borrado] #232 Jun '12

#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 #233 Jun '12 BugHunter

#232 ¿PERL no te sirve?

1 respuesta

B

[Borrado] #234 Jun '12

#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

[Borrado] #235 Jun '12

#234: Eres mi puto ídolo

1 respuesta

B

[Borrado] #236 Jun '12

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

eisenfaust #237 Jun '12

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

[Borrado] #238 Jun '12

#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...

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

[Borrado] #239 Jun '12

#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 #240 Jun '12 A toda leche

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

Usuarios habituales

Tags