Contactar con soporte

Respondemos por correo, normalmente en dos días.

Google reCAPTCHA revisa este envío frente a abusos; se transmiten datos a Google. El script se carga solo al abrir el formulario.

← Todas las entradas

Dos maneras de contar mal tu propio registro

Una semana de cambios aquí se apoyó en recuentos tomados de un día del registro de accesos: un millón de líneas, cien mil de ellas nuestras. Para saber si algo funcionó, esos mismos recuentos hay que volver a hacerlos más tarde — y los recuentos armados a mano una segunda vez nunca son exactamente los de la primera. Otra lista de bots, otro rango de fechas, otro grep.

Así que el recuento se mudó a una herramienta con la base escrita dentro como una constante. La primera ejecución fue contra el mismísimo registro del que salió la base. Todo tenía que salir igual.

Dos líneas no salieron. Las dos veces la herramienta tenía razón y el recuento original estaba equivocado.

grep lee la línea entera

El hallazgo principal de la semana fue que el token del propietario apareció una vez en un día completo. Se contó con un patrón aplicado a líneas enteras del registro — y una línea de registro contiene la petición, pero también la procedencia y el identificador del navegador.

Esa única coincidencia era un &t= dentro de la URL de procedencia de un buscador. Alguien llegó desde un resultado de búsqueda móvil cuya dirección contenía por casualidad esos dos caracteres. En las peticiones propiamente dichas, el token apareció cero veces.

El hallazgo se volvió más contundente, que es una forma extraña de estar equivocado. Sigue estando equivocado. Recorta primero el campo de la petición — es el segundo campo entrecomillado de una línea de registro combinado — y busca dentro de él.

Una cadena else-if se traga el caso concreto

El segundo recuento decía que el canal semanal se había descargado cero veces. La clasificación parecía razonable:

if (la dirección contiene "/live/") ... else if (la dirección contiene "feed.xml") ...

Las direcciones del canal en este sitio son /live/<número>/feed.xml. Todas y cada una encajaban en la primera rama y nunca llegaban a la segunda. La cifra real era 398.

La conclusión sacada de la cifra equivocada sobrevivió por casualidad: esas 398 peticiones se reparten por igual entre los once prefijos de idioma bajo tres identificadores de navegador genéricos, y eso es un rastreador llevándose cada traducción, no un suscriptor. Nadie se había suscrito. Pero «nadie se suscribió» y «cero peticiones» son afirmaciones distintas, y la segunda se citó varias veces antes de que nadie la comprobara.

La comprobación que atrapa ambas

Ejecute su herramienta de recuento contra exactamente el día del que salió su base. Cada línea tiene que salir igual. Lo que no salga igual es o un fallo de la herramienta o un fallo del recuento original, y usted averigua cuál de los dos antes de que importe, no después.

Llevó una ejecución y unos cuatro minutos. Para entonces ambas cifras se habían repetido varias veces por escrito, y ninguna la habría atrapado leer el código con más atención — solo obligar a la medición a responder por sí misma.

Publicidad