MV Coders on fire

Nucklear #181 Abr '12 BugHunter

#180 A ver es que tal y como yo lo tengo planteado cuando alguien se conecta habla en el canal general donde el servidor escribe.

Como si al conectarte al IRC en vez de necesitar abrir un canal pudieses escribir en el de status del servidor.

El tema es como obligar al cliente a elegir un nuevo nick en caso de que el usuario tenga un nick en uso, yo tampoco estoy controlando registros con password.

Algo como esto es mi idea:

C=Client S=Server

C: Se conecta al servidor con nick "Nucklear"
S: Comprueba que "Nucklear" está en uso y envía mensaje "Nick already in use"
C: Recibe el mensaje y llama a la función "cambiarNick"
C: Envía N:Nucklear2
S: Valida nuevo nick y le permite el acceso

3 respuestas

B

[Borrado] #182 Abr '12

#181 no te vale con http://www.rfc-es.org/rfc/rfc1459-es.txt ?

B

[Borrado] #183 Abr '12

#181: Yo lo que hago es que si el nick está en uso, mando un código de error de nick en uso.

Entonces el cliente tendrá que decirle al usuario: "Oiga, este nick está ocupado, seleccione otro".

3 respuestas

EnZo #184 Abr '12

#181 Yo tambien tenia pensado hacerlo así pero con el codigo de error que dice #183

1 respuesta

Nucklear #185 Abr '12 BugHunter

#183 #184 Cierto, olvidé los errorcodes, pero bueno es la misma idea.

EDIT: ¿Sabeis esa sensación de que a medida de que codeas mas parece que la vas liando mas? Eso es lo que siento xD

Nucklear #186 Abr '12 BugHunter

Continuo la ronda de preguntas xD

Según lo tengo implementado por ahora el usuario siempre debe introducir un comando antes de escribir nada:

L: Listar usuarios
N: Cambiar Nick (N: OldNick:NewNick)
J: Entrar (J:Nick)
X: Desconectar
M: Enviar un mensaje
P: Enviar un privado (P:NickUser: [Texto])

De lo contrario devuelve un código de error que se le muestra al usuario como la lista de comandos disponibles.

El problema que le veo es que a cada palabra que escriba un usuario haya que poner M:[texto] en lugar de no poner nada, como en IRC por ejemplo.

¿Lo estais implementando así o yo he entendido mal los comandos? Es que estan las especificaciones un poco liadas y si la idea es que todos los clientes sean compatibles entre sí creo que vamos a tener un problema...

1 respuesta

zoeshadow #187 Abr '12

La cosa es que eso es la cadena que le.tiene que llegar al servidor, tú puedes darle un menú de opciones al usuario (hablar, ver costa de usuarios etc), y sí acaso pedirle que introduzca algo ( nuevo nick, mensaje ) y ya con eso formas la cadena que le mandase al servidor. O también puedes hacer que el usuario tenga comandos como has hecho, pero quizás de manera más elegante (/say /list )

1 respuesta

Nucklear #188 Abr '12 BugHunter

#187 Si bueno, lo del menu es una opción y con respecto a lo de los comandos fueron los que se pactaron en #146, no es por capricho xD

Khanser #189 Abr '12 :psyduck:

#186 Eso debería ser transparente para el usuario tio, el usuario en el cliente no debe saber qué comando se envía ni cómo, al servidor. El usuario tendrá una cajita o por consola o lo que sea, entonces cuando tu CLIENTE inicie la ejecución te pedirá usuario, tu se lo pondrás y el hará String query = "J:"+text.getText(); pillará el texto de tu caja, o leerá por consola, construirá la 'consulta' y se lo enviará al server. Éste te dirá OK o NOK, esto ya será cosa del cliente decirte ESTAS DENTRO o decirte FAIL.

En caso de decirte que estás dentro, te irá mostrando los mensajes segun le lleguen del server, o temporalmente se los irá preguntando o como quieras hacerlo, y cuando tu escribas en la cajita, el cliente ya sabrá que estas enviando un texto.

Otra cosa diferente de las consultas al servidor es si tu quieres añadir parámetros en cliente para hacer ciertas cosas, pero esque esos comandos no tienen que coincidir con los de servidor.

1 respuesta

Nucklear #190 Abr '12 BugHunter

#189 Vale ahora es cuando me pegas xD

1 respuesta

Khanser #191 Abr '12 :psyduck:

#190

2

elkaoD #192 Abr '12

Joder, a ver si saco tiempo y me meto con esta kata y aprovecho para hacerme a sockets+concurrencia en Clojure. Me están dando ganicas.

#167 hombre cada lenguaje tiene su idiosincrasia.

C, Perl y demás tratan más de usar los constructos del lenguaje de forma extraña y hacer sopas de caracteres. Aquí pueden competir Python y demás de la misma forma (de hecho suelen ganar, menos a Perl, que se funde a todo xD)

Lisp y derivados no pueden competir con ellos porque son muy "verbose", dependen mucho del espacio en blanco y las funciones tienen nombres muy largos (interleave, p.ej...) Sin embargo sí que pueden competir contra sí mismos. Code Golf Clojure vs. Clojure no va de quién junta más símbolos en menos espacio si no de quién se saca de la manga el algoritmo más corto y de usar el lenguaje a tu favor (p.ej. en lugar de map + remove nil, usar keep)

A mí me ha ayudado mucho a aprender porque me obliga a mirarme TODA la referencia varias veces en busca de "magia" y además porque te abre los ojos a nuevas formas de hacer las cosas (que son sorprendemente aplicables en ámbitos no-codegolfianos.)

1

Nucklear #193 Abr '12 BugHunter

¿Alguien me ayuda con las expresiones regulares?

De un string de este tipo:

/join blablabla blablabla blabla
/nick blablabla blablabla blabla
/list blablabla blablabla blabla

quiero sacar solo el comando para procesarlo en el caso del /list por ejemplo pasar del resto del texto y enseñar el user list.

Yo lo estoy haciendo de una forma muy sencilla pero que me parece poco eficiente:


import re 

msg = "/nick Nucklear2"

commands = re.split(" ", msg)

print commands[0]

/nick

1 respuesta

Metaza #194 Abr '12

A la próxima le doy a full.

Por cierto teóricamente estas katas se hacen con test para mejorar el TDD.

1 respuesta

EnZo #195 Abr '12

#193 No te compliques con regexp para eso. Un split debe estar muy bien optimizado, ya que es una funcion nativa de phyton.

Las regexp se usan para sacar datos que no siguen un patron simple. Pero en tu caso si el patron es tan simple un split viene cojonudo... No creo que una regexp te vaya a aportar mas rendimiento.

1 respuesta

B

[Borrado] #196 Abr '12

#194: Podemos hacerlo para la próxima, pero estaría bien añadir unos links para los que no sepan qué es el TDD o cómo llevarlo a cabo. Porque muchos no sabrán.

1 1 respuesta

Metaza #197 Abr '12

#196 Estaría bien sí, ya se irá proponiendo algo,supongo.

Nucklear #198 Abr '12 BugHunter

#195 Pues es cierto, no sabía que la función split() estaba disponible para los strings, ahora queda reducido a:

msg = "/nick Nucklear2"

commands = msg.split()

print commands[0]

/nick

Nucklear #199 May '12 BugHunter

¿Como vais con esto? Hace días que nadie comenta nada, yo tengo el cliente casi listo, aunque creo que me faltan cosas pero no se que xD

1 respuesta

B

[Borrado] #200 May '12

#199: xDDDDDDDDDDDD

El cliente es para la próxima tío. Yo el servidor lo tengo desde hace días, cuando tenga un poco de tiempo comentaré bien todo y lo subiré.

1 respuesta

Nucklear #201 May '12 BugHunter

#200 ¡No me jodas! lol vaya empanada...pues tengo suerte porque fui haciendo en paralelo el servidor pero tengo solo lo basico xDD

Joder pues menos mal que pregunté hoy y no el ultimo dia para llevarme un owned

#1 Para la proxima escribe bien la kata y no dejes solo el quote xD

1 respuesta

Khanser #202 May '12 :psyduck:

#201 Si lees bien en #1 al final lo explica.

1 respuesta

Nucklear #203 May '12 BugHunter

#202 Si, lo se, pero coño xDDD

B

[Borrado] #204 May '12

Por cierto, no va aquí pero tampoco se merece un tema aparte, y aquí es donde seguro habrá aquellos a quienes les interese más: http://www.kaggle.com/ tienen premios bastante suculentos.

B

[Borrado] #205 May '12

Bueno yo subo el mío.

Al principio quería hacerle una UI sencilla para mostrar los mensajes salientes y entrantes, además de la lista de los usuarios pero por falta de tiempo (y ganas, la verdad), nada.

https://github.com/SantiMunin/MV-Coders-on-fire/tree/master/2_chat_server

Teneis que tener "ant" instalado en el sistema si queréis usarlo (facilmente).

Un saludo!

PD: Podría haberse hecho muchísimo mejor, pero últimamente estoy cansado de las filigranas de Java con cuarenta mil interfaces y demás. Así que he hecho una implementación sencilla.

En Codes.java podéis ver los códigos que he utilizado.

3 respuestas

Nucklear #206 May '12 BugHunter

#205 Viendo tu código me dan ganas de tirar el mío...

Tengo todo en un mismo script sin separación de capas ni nada...

1 respuesta

elkaoD #207 May '12

#205 mola, aunque yo no pondría Codes en una clase abstracta si no en un enum (que pa eso están.)

1 respuesta

B

[Borrado] #208 May '12

#207: La verdad es que lo hacía así antes pero como digo este desarrollo no fue propio de mí, sino que por alguna razón me cansé de hacer lo de siempre y decidí variar.

De hecho el diseño está hecho sobre la marcha (suelo hacer bastante mejor las cosas, no me gusta demasiado el concepto que llevé). Pero bueno! Esto es para pasarlo bien y no quería rallarme.

#206: No te desanimes, estoy muy acostumbrado a programar en Java y ya he hecho varios proyectos "grandes", donde sí que tuve que estructurar todo muy bien.

En tu caso, es tan sencillo como dedicarle una horita a reestructurar todo. Al fin y al cabo no es demasiado código.

Animaros los demás, quiero ver el servidor.

PD: #207, me encantaría verlo en funcional

2 respuestas

elkaoD #209 May '12

#208 a mí también me encantaría verlo pero estoy en plenos exámenes (y no conozco muy bien el modelo de concurrencia de Clojure como para hacerlo rápido)

Nucklear #210 May '12 BugHunter

#208 Es que es algo que tengo que mejorar muchisimo. No se como estructurar los programas y cada vez que intento estudiar como serían unos patrones básicos no encuentro documentación al respecto, entonces hago los programas improvisando completamente y sale lo que sale.

A ver si este finde consigo terminar el server y lo subo que ando justo de tiempo estos días.

1 respuesta

Usuarios habituales

Tags