« first day (1897 days earlier)      last day (1197 days later) » 
00:00 - 18:0019:00 - 23:00

12:58 AM
en javascript existe alguna forma de saber que elemento al hacerle click es el que dispara un evento que desconosco XD
 
1:32 AM
compañeros ustedes en sus trabajos aplican scrum? o eso es solo en las series de programadores?
resuelvanme la dudita porfavor
escucho mucho ese tema por alli
 
1:55 AM
es el pan de cada dia para monetizar el trabajo es como el watchdog en asembler XD
 
 
2 hours later…
3:49 AM
0
Q: como aplicar ComboBox con DropDownList sin afectar apariencia?

GaninoxTengo un Combobox CmbUserel cual le active la propiedad DropDownList, pero afecta el estilo visual y desentona con mi Login como puedo después de haber aplicado esta propiedad cambiar el Fondo??? PD: estoy usando VisualStudio19

 
 
1 hour later…
4:50 AM
@mauricio de los 5 trabajos que he tenido profesionalmente en estos lares del mundo, en 3 he utilizado Scrum, los otros 2 era más fresh, una lista de tareas para hacer y ya
 
 
2 hours later…
6:34 AM
@FranciscoNúñez claro: event.currentTarget
Buenos días
 
7:13 AM
A las güenas :-)
 
7:33 AM
@Trauma eeeey :D
 
@lois6b eeeey tú ;-p
 
8:07 AM
buenos nevados dias
hoy la vuelta a casa puede ser una gran odisea :)
 
Hoy es viernes. Motivación extra :-)
 
Segun pone en el tiempo puede empezar a nevar de nuevo en una hora y no para hasta el domingo
si es asi madrid colapsa
 
Madrid está colapsa siempre
tampoco se notará demasiado
 
@Trauma Al borde del lo veo mejor
 
Vale, te lo compro. Al borde de :-)
Vamos, poca diferencia
 
8:14 AM
@Trauma creeme que si cae la que esta prevista puede ser de locos
pero no hoy ni mañana
cuando se vaya
 
jejeje ... nada, lo disfrutaré viendolo por la tele :-)
pensare en tí ;-p
 
con una caña de azucar jajajaj
 
jejeje
 
jelou and japy niu yia
 
また
Bloques totales: 4
Bloques completos: 1431654399
Bloques parciales: 1
Creo que algo está fallando ahí ...
Bloques totales: 4
Bloques completos: 3
Bloques parciales: 1
Esto ya es otra cosa :-)
 
8:42 AM
¿recordais esa falsa cita que se hizo viral hace unos años de "los fascistas del futuro se llamarán así mismos antifascistas"?
well, how the tables have turned...
 
9:03 AM
@mauricio Cuando no es scrum es alguna otra metodología similar, pero toda la gente que conozco por estos lares y está en empresas un poco grandes, siempre usan alguna metodología de desarrollo agile
 
Huy, amanecí pensando que hoy era jueves. Que triste. Se me fue un día completo y no me di cuenta.
 
Por supuesto, en una empresa pequeñita donde estuve un mes de prácticas lo único que usábamos era una pizarra con tareas por hacer xD Era un poco caótico porque cualquier podía hacer cualquier cosa y muchos ni se levantaban a marcar lo que estaban haciendo
@Trauma Las buenas matemáticas, oh yeah
 
@Trauma Lo que te decía ayer, no veo cómo el parámetro "min" puede jugar ningún papel en el problema. Mira mi solución
from math import ceil

def trocear(lista, t_max):
  t_lista = len(lista)
  num_trozos = int(ceil(t_lista/t_max))        # Numero de trozos a crear (y es el mínimo posible)
  tam = int(ceil(t_lista/num_trozos))          # Tamaño de cada bloque "grande" (cumple tam <= t_max)
  n_peq = tam * num_trozos - t_lista           # Numero de bloques "pequeños" (tendrían tamaño tam-1)
  n_grand = num_trozos - n_peq                 # Numero de bloques "grandes" (de tamaño tam)
  return ( [ lista[i:i + tam] for i in range(0, n_grand*tam, tam) ]
 
@abulafia Pues si lo juego. El objetivo es crear el mayor número posible de grupos de MAX size, y garantizar que los grupos restantes son como mínimo de MIN size
 
Le he pasado una batería de tests para asegurar que la lista siempre es troceada correctamente (en el sentido de que todos los elementos de la lista original aparecen en algún trozo sin que falte ni se repita ninguno), y que los tamaños de cada trozo son siempre inferiores al t_max dado
 
9:14 AM
no no
 
@Trauma MAYOR número posible? No era MENOR?
 
Alguno con conocimientos de css?
 
creo que me expliqué mal entonces
MAX es el tamaño optimo
MIN es el tamaño mínimo aceptado
 
Espera que no terminé. Y que los tamaños de cada trozo son todos iguales entre sí con una diferencia de 0 ó 1
 
cuantos mas bloques de MAX, mejor
split( 10, 3, 2 ) -> dividir 10 elementos en bloques de 3 máximo, mínimo 2
cuantos mas bloques de 3, mejor
Estoy viendo que me expliqué como el culo, sorry :-(
Por estadística, sabemos que el grupo de tareas a ejecutar en un L3 es de 3
 
9:16 AM
Ya, pero aún así, creo que sigo en mis trece
 
Oye, si funciona, funciona :-)
 
por ejemplo, tu caso (10, 3, 2) produce con mi algoritmo los tamaños [3, 3, 2, 2]
 
Es correcto
 
y eso que no tengo en cuenta el valor minimo 2. Sale automáticamente
debido a que en mi solución todos los trozos son "casi" iguales
con una diferencia de 1
 
¿ crearas menos trozos MAX de los posibles ?
 
9:17 AM
ahora mira a ver si encuentras un contraejemplo en que mi algoritmo saque un troceado malo
 
mal momento ahora mismo
 
a ver, mira te pongo yo un posible contraejemplo
split(10, 6, 4) ¿qué debería producir según tú eso?
[6, 4] ?
 
sip
 
mi método produce [5,5] ¿no es eso mejor?
o quieres "forzar" a que haya grupos de tamaño 6
 
es subóptimo
@abulafia Eso es. Cuantos mas de MAX, mejor
a ver, no quiero forzar. Si no es posible, no es posible
pero si me interesa el mayor numero de grupos de MAX tamaño
 
9:20 AM
Hmm... pero por ejemplo split(10, 8, 5) no tendría solución en tu caso
a menos que rebajes min hasta 2
 
@abulafia Por cierto, peaso de código t'as currao :-O
 
y entonces produciría [8, 2]
es eso preferible a [5,5] ?
 
En principio, si, [ 8, 2 ] es preferible
si hay que levantar un nodo para 2, va a tardar igual que levantar un nodo para 5
 
vale, entonces ya tengo más claro lo que buscas. Aunque no sé si estoy de acuerdo con el criterio de "preferibilidad", pero ahi no me meto
 
pero el nodo que ya esta lenvantado, que ejecute lo máximo posible
 
9:22 AM
si se trata de un reparto de carga yo tendería a creer que cuanto más equilibrada esté sería mejor. No veo mucho sentido en saturar ciertos nodos dejando otros más ociosos
 
@abulafia jeje ... ese creterio lo he puesto a ojimetro. Para lo que es, me parece la mejor solución
 
pero tú sabrás
 
el tema no es que estén ociosos, es que podemos tener que levantarlos
 
de lo que se trata según yo lo veo es de levantar el mínimo posible de nodos, y de que todos los levantados tengan una carga similar
 
la carga ya les llega sola, no te preocupes
pero tengo otros nodos que dependen de los resultados de esos
cuanto mas tareas termine, antes libero los nodos que est'an esperando
 
9:24 AM
dicho de otra forma. una vez se ha garantizado que el número de nodos levantados es óptimo (el mínimo posible), qué más te da si hay varios con el valor max y otro con mucho menos, o si todos tienen un valor cercano a max (lo más cercano posible de modo que todos queden similares)
 
por los que estan esperando
esto va en 3 niveles, cado uno de los niveles espera a tareas del siguiente nivel
los de L1 esperan a L2
y los de L2 esperan a L3
agrupamos los trabajos de L3
cuanto antes acaben, antes se libera L2
que se puede poner a otras cosas
 
si, pero el nivel que espera por el siguiente esperará a que terminen ciertas tareas que no tendrían por qué ir necesariamente mapeadas a un mismo nodo, no?
 
correcto
 
a lo mejor es que no entiendo qué representan los grupos que haces
creía que los grupos eran los trabajos que recibiría cada nodo
 
corrrecto, eso son
grupos que se envian al nivel L3
 
9:26 AM
pues entonces no veo por qué el meterlos todos a un mismo nodo va a hacer que terminen antes
 
el último
 
si una tarea de nivel 2 tiene que esperar a que terminen 10 trabajos de nivel 3...
qué más le da que esos 10 trabajos los ejecute un solo nodo o estén repartidos entre dos?
de hecho yo diría que a mayor reparto más paralelismo
y que probablemente terminarán antes
 
pero es que hay mas L2
que están esperando por otros grupos
 
bueno, no sé. No te voy a discutir el criterio porque no entiendo del todo el escenario
 
no es secuencial. Puede haber 50 L1, cada uno de ellos con 100 L2, y cada uno con 1000L3
 
9:28 AM
a ver entonces si se me ocurre otro algoritmo para lo que pides
 
jejeje
Como te gusta procrastinar xDD
 
bueno, la tarea importante que tenía que hacer ayer ya la quité de enmedio
 
Yo he estado haciendo algunas pruebas, pero aun no di con la tecla
 
asi que esto no es procrastinar, es una nueva tarea
 
jejeje
 
9:29 AM
Hmm... creo que la voy a procrastinar
 
me gusta esa filosofía
 
me estais recordando el trabajo que me mandaron hacer en la asignatura de sistemas operativos (hacer un scheduler para las tareas)
 
bueno, continuo. Que esto es urgentisimo para la semana pasada
Oye @abulafia creo que ya lo tienes
Lo que tu has hecho es para MIN = MAX - 1
Ya casi tienes el caso genérico buscado :-O
 
Si se trata de levantar el minimo número de nodos, te sobre lo del mínimo
 
No, no es eso
Un pod tarda 2 minutos en arrancar
no quiero arrancar un pod para ejecutar menos de MIN tareas
 
9:38 AM
las pones en espera?
 
hay una cola general, sip
pero la ejecución es independiente de levantar o no los pods
cada pod va a la cola a por tareas y listo
 
@Trauma Si pero no, porque mi algoritmo puede producir un troceado en el que ningún trozo tenga el valor MAX
 
@abulafia ummmm ... vale
pero insisto en que ya casi lo tienes
Luego hay que pasarlo a C++ ... tu veras que panzá de reir me pego :-)
 
por ejemplo, imagina split(100, 30, 10). Daría según tú [30, 30, 30 10]
 
sip
 
9:41 AM
pero si pides split(100, 30, 20) entonces debería ser [30, 30, 20, 20] no?
este es el caso que me está ayudando a verlo
 
sip, correcto
 
mi algoritmo daría [25, 25, 25, 25] en ambos
como ves también produce cuatro trozos. Eso te lo garantiza, que levantas el mínimo de máquinas
 
vale. Pues vaya churro de algoritmo ;-p
 
pero en mi caso quedan las cuatro con la misma "carga"
 
sip, pero las estoy infrautilizando
 
9:42 AM
y en tu caso quedan dos saturadas a "MAX" y el resto a "MIN"
 
correcto
 
estás infrautilizando de todas formas dos en tu caso
 
creo que es el mejor de los peores escenarios
si hay que levantar un pod, nunca para menos de MIN
 
y si de lo que se trata es de minimizar el tiempo total para terminar las 100 tareas, yo creo que el reparto [25, 25, 25, 25] sería mejor
 
si es posible, siempre a MAX
 
9:43 AM
pero bueno, no me meto
 
tu idea es válida, salvo porque el número de pod no es fijo
si ya est'á'levantado, que ejecute el MAX de tareas
si hay que levantarlo, nunca se levanta para ejecutar menos de MIN
 
bueno, creo que ya tengo otra implementación. Parece funcionar bien con un par de casos. Ahora escribiré algunos test por si acaso
def trocear(lista, t_max, t_min):
  t_lista = len(lista)
  num_trozos = int(ceil(t_lista/t_max))        # Numero de trozos a crear (y es el mínimo posible)
  a_quitar = num_trozos * t_max - t_lista      # Espacio sobrante a quitar de algunos trozos
  n_peq = int(a_quitar / (t_max - t_min))      # Numero de trozos que tendrán un tamaño menor
  if n_peq == 0:
    t_peq = t_max
  else:
    t_peq = t_max - int(a_quitar/n_peq)          # Tamaño de cada trozo pequeño
  n_grand = num_trozos - n_peq                 # Numero de bloques "grandes" (de tamaño tam)
 
@abulafia ¡¡ Máquina !! 😱😱😱😱
 
split(100, 30, 10) produce [30, 30, 30, 10]
 
huy :-)
 
9:46 AM
split(100, 30, 20) produce [30, 30, 20, 20]
 
ah no no, esta bien
Perfectísimo :-D
 
pero aqui ya la caga: split(100, 30, 21) produce [30, 30, 20, 20]
creo que me faltó un ceil() por algún sitio :-)
 
Tiene toda la pinta :-)
 
A ver, ahora para el caso split(100, 30, 21) produce [30, 24, 24, 22]
pinta bien
y si le pedimos un imposible?
split(100, 30, 24) --> [25, 25, 25, 25]
split(100, 30, 30) --> Exception division por cero
Hey. Caso defectuoso. split(100, 30, 23) --> [30, 24, 24, 22]
ese 22 final está mal, grr...
 
@abulafia Yo compruebo que MIN < MAX siempre
 
9:58 AM
Ese no es el problema aqui
salvo el caso 30, 30
Bueno, ya le he pasado una batería de 4851 test. Ha producido resultados malos en un 28% de los casos. En todos ellos es que aparece un último grupo con un elemento menos del minimo permitido
típico off-by-one
 
10:14 AM
@abulafia En este caso la única solución sería levantar aun más pods, no?
 
no, es un caso como [30, 24, 24, 22] en el que el mínimo era 23. Es un bug del algoritmo porque podría haber hecho [30, 24, 23, 23]
 
10:46 AM
Ahh, cierto
 
@Trauma Ya casi lo tengo. Tengo una implementación a la que he pasado una lista de tamaño 100 y le he pedido que la trocee para todos los posibles valores de t_max y t_min con t_min<t_max
eso genera 4851 casos, de los cuales resuelve correctamente 3516
los otros 1335 los marca como "irresolubles"
pero no estoy seguro de que sean irresolubles, depende de lo que estés dispuesto a admitir como solución
Por ejempo uno de esos casos es split(100, 24, 21)
Se pueden hacer 5 grupos, de los cuales si pones cuatro a MAX (24) te causa un grupo sobrante de solo 2 (ya que 24*4=98).
 
... ummm ... vale, lo veo
 
No hay forma de hacer que esos 5 grupos tengan todos un mínimo de 21, pues eso produciría 21*5 = 105 elementos, más de los que hay
asi que se podría aumentar a un grupo más
pero eso tampoco lo arregla
cada grupo tendría menos aún
asi que ¿es imposible este caso?
 
No deber'ia serlo ... hay que pensar que hacer en ese tipo de casos
supongo que generar el último solo con 2
 
es preferible entonces [24, 24, 24, 24, 2] a, por ejemplo [20, 20, 20, 20, 20] ?
 
11:01 AM
nope
pero entonces quiere decir que te has pegado una panz'a para nada, y por culpa mía
 
:-)
Bueno, supongo que se puede tener una combinación de ambos algoritmos
el ultimo que acabo de hacer hace lo que pedías (mínimo de grupos, dentro de ellos hacer que el mayor número posible tenga MAX garantizando que el resto tenga al menos MIN). Si no puede hacerlo levanta una excepción de "Imposible"
ante esa excepción se podría invocar al otro algoritmo que equilibraba la carga en ese número de trozos
 
Por eso opino que si la idea es levantar el mínimo número de pods, basta con dividir por el máximo para encontrar el número de pods (más uno si el resto es distinto de cero), y luego repartir las tareas equitativamente (mejor 5 con 20 que 4 con 24 y uno con 4)
el resto me parece un poco over-engineering
 
No es levantar el mínimo
Estadisticamente, hay un número optimo de tareas a agrupar
 
split(100, 30, 10) -->  [30, 30, 30, 10]
split(100, 30, 11) -->  [30, 30, 20, 20]
split(100, 30, 15) -->  [30, 30, 20, 20]
split(100, 30, 20) -->  [30, 30, 20, 20]
split(100, 30, 22) -->  [30, 23, 23, 24]
split(100, 30, 25) -->  [25, 25, 25, 25]
split(100, 30, 29) -->  [25, 25, 25, 25]
los dos últimos casos serían "imposibles" y por tanto pasa a usar lo que dice Pablo
 
@PabloLozano no quiere levantar el mínimo. Quiere levantar el máximo de ellos con la máxima carga, respetando un mínimo de tareas por pod levantado
 
11:13 AM
@Trauma Entiendo que ese número óptimo está en el rango MAX, MIN
 
@PabloLozano Es el MAX
El MIN sale de lo que tarda en levantarse un pod
un pod tarda 2minutos
no quiero levantarlo para solo 1 tarea
de hecho, prefiero no tener que levantar ninguno, por eso ajustarnos lo máximo a MAX
 
el MAX entonces es usar un pod al 100%, pero sin causar esperas, no? Es decir, ¿MAX-1 deja el pod ligeramente infrautilizado pero tarda lo mismo?
 
no, tardará algo menos
el MAX es el número de tareas
cada tarea individual tarda X milisegundos
se agrupan por paquetes
porque en leer/escribir los datos de 1 sola tarea, tarda mas que en ejecutarla
 
entonces, si MAX es 30 y MIN 10, [30, 30, 30, 10] y [30, 30, 20, 20] son peores que [25, 25, 25, 25]
 
depende
si no hay que levantar ningún pod, no
en condiciones normales, no hay que levantar mas pods, estaremos ya usando el máximo de ellos
cuando un pod coge un grupo de tareas, no está garantizado que sea de las que a mi me interesa
cuanto antes quede libre, antes cojera mas tareas
En realidad, son 4 niveles: L0 son los usuarios finales, L1, L2, y L3
L0 est'a fuera del grid
L1 L2 y L3 se ejecutan en el grid
 
11:27 AM
Bueno, aquí está el algoritmo que has pedido. Si al final vale para algo o no, es cosa tuya :-)
 
Buenas tardes
alguien con un poco de nocion de Python ? :/
 
@PabloLozano Para el criterio de Trauma (que no acabo de entender) de esas tres soluciones la mejor sería [30, 30, 30, 10] porque además de respetar max y min, maximiza la cantidad de pods que tienen 30 (el máximo)
 
@abulafia claro, pero si el que está esperando a que todas las tareas terminen, tiene a un pod parado (el de 10) mientras los otros siguen trabajando, veo más lógico repartir las tareas más equitativamente, por eso preguntaba
 
@PabloLozano Sí, eso mismo es lo que yo no entiendo
 
@Anthonyeca qué necesitas??
 
11:34 AM
Salvo que quieras minimizar también el tiempo que tienes encendido el pod extra
o sea, que se apague en cuanto termine con sus 10
 
Por lo que ha dicho @Trauma, es posible que cuando un pod acabe con sus tareas empiece con otras
 
@PabloLozano Ese pod no esta parado. Está ejecutando otras tareas, de otro L2, o de otro L1
Son muchos clientes con muchas tareas cada uno
 
Estoy intentando realizar un "inventario" el cual puede conseguir nuevos items (sumar).

Mi inventaio es un diccionario EJ: inv = {'gold coin':42,'rope':1} y lo q puedo conseguir es: dragonLoot = ['gold coin','dagger','gold coin'] El cual es una lista.

Lo he logrado realizar pero con : from collections import Counter , queria lograrlo de forma "nativa"
Basicamente, "no se" como sumar 2 diccionarios
def addToInventory(inventory, addItems):
loot={}

for v in addItems:
loot.setdefault(v,0)
loot[v] = loot[v] + 1

Con esto he logrado que mi lista se vuelva un Diccionario
 
@Trauma Ahh, eso complica tanto el asunto que no voy a meterme más en el análisis
 
En donde vivo ha comenzado el apocalipsis blanco
 
11:41 AM
Pinta bien esta segunda temporada del 2020
 
@abulafia Si cerro un poco floja pero el primer capitulo de la segunda esta siendo bastante epico
 
Al carajo. El abrir/cerrar el interprete de python en cada tarea se cepilla las mejoras de tiempo :-(
De hecho, tarda mas que con tareas individuales
A ver si con grupos mas grandes ... ¿ 500 ?
 
12:17 PM
Hay alguna manera de añadir recompensa a una pregunta que ya tiene recompensa ofrecida?
 
Cuando se termine la que ya tiene
nada ti impide volver a ponerle otra
pero a la vez ... creo que no
El calefactor este (el típico de 2 barras) que me compré ayer, ha sido una de las mejores compras de mi vida :-O
 
@Trauma, te hacía un macho del norte, de esos que no pasan frío
 
Yo estoy empezando a flipar, la nieve que ya hay supera el maximo en años y aun falta todo hoy y mañana
 
Te atreves a usar C++ con librerías de python que corren librerías de C... y luego te quejas del frío!
(Estoy de broma, no pretendo ofender a nadie :))
 
es imposible no ofender a nadie
en este chat hay un historico que lo prueba
 
12:27 PM
Estoy de acuerdo, por eso me disculpo
 
hahah na, tranqui
 
Uno nunca sabe, con tanta nieve que cae hoy, es imposible no encontrarse algún snowflake
 
No no, si no me ofendo. Ofende quien puede, no quien quiere xD
Macho del norte ... pero están cayendo copos de nieve ... ¡¡ En Málaga !!
En cota 0
En otras palabras: hace un frio que escalda, que dicen en mi pueblo
INFO:Recovered 0 task(s) result OK
./pruebaExec: line 51: 25744 Segmentation fault
jejeje
creo que aun quedan algunos flecos por pulir :-)
 
@Trauma Ahi tambien?
 
Sip
Pocos ... pero se ven caer
 
12:32 PM
estamos apañados
 
no cuajará, el viento no la deja
En el bar donde tomo café por las mañana, hay una foto de Málaga nevada
del año 1930 o así
Pero lleva lloviendo desde ayer sin parar
Esto si que es promocionar un comic:
Sex Report es una extensa y exhaustiva visita guiada al submundo del negocio del sexo tokiota, realizada de la mano de uno de sus mejores clientes, el periodista, actor porno y mangaka, Hiromi Hiraguchi.

Sin complejos, el autor nos describe una detrás de otra sus experiencias, en forma de reportajes cortos que profundizan en las mil y una posibilidades que el mercado del sexo japonés ofrece a sus numerosos, variados y siempre exigentes consumidores.
 
Aqui nevo unas horas y se ha mantenido y sobre las 11 ha empezado a nevar de nuevo y no para
 
Título completo: Sex Report. Diario de un Putero en Japón
@NicolasOñate Aquí ha parado de llover
Pero se ha levantado un vientecito ... grasioso
 
 
1 hour later…
2:05 PM
Hola a todos
@FranciscoNúñez Hola, trabajo en una api con php y symfony estoy en un controlador, la única manera para probar es Postman pero solo tiene una cache de 100MB y no me muestra nada
 
2:25 PM
en serio no se puede hacer var_dump en symfony esta malo ese framework ... todo desarrollador necesita hacer pruebas y verificacion de ejecucion y trasado de datos
 
2:56 PM
Buenas, estoy tratando de consumir un wsdl pero me esta arrojando este error
 
pero eso es un error del servidor no?
 
vuelvo a preguntar, pero el que te devuelve el error es el servicio no?
 
Si cuando ejecuto el xml en soapui
 
@JuanPerez y entonces, como esperas arreglar vos un error que viene de un servicio que no haces vos?
 
3:08 PM
Dale, voy a contactar al proveedor
 
no entendi tu pregunta entonces :( tu idea era arreglarlo vos?
o no entendiste el error que te devolvia?
 
Pense que era un error mio pero ahora lo entendi y es problema del servidor
 
@Benito-B :) gracias
Muchas gracias @fredyfx :)
 
@JuanPerez oki
 
4:08 PM
aloha~
 
@fredyfx buenas...
 
buenas :D
saludos @gbianchi
 
@fredyfx :)
 
4:23 PM
¿Cómo vas?
 
todo bien y vos?
 
re contento :D
 
@fredyfx buenisimo
 
encontré un bug ninja
encontré cómo reproducirlo
y es un alivio tremendo~
 
weeeee genial
 
4:31 PM
yeah~
 
5:11 PM
Hello
 
0
Q: Propuesta para nuevas medallas

Japven el perfil de cada uno de nosotros hay un campo que se llama personas alcanzadas Mi propuesta es sencilla crear un trio de medallas(oro, plata y bronce) cuando alguien alcance determinado numero de personas alcanzadas Ej: Bronce:10K Plata:25K Oro:50K

 
Don Mauricio, buen día :D
 
5:40 PM
-2
Q: Respuestas aceptadas que dejan de ser aceptadas por el usuario

JapvComo bien sabemos cuando a un usuario le satisface una respuesta este puede marcarla como aceptada, pero posteriormente podria aparecer una respuesta mejor a la que el acepto y logicamente va a marcar esta nueva respuesta y el usuario que respondio anteriormente va a perder 15 ptos de su reputaci...

 
00:00 - 18:0019:00 - 23:00

« first day (1897 days earlier)      last day (1197 days later) »