debugging - programacion - ¿Qué haces si no puedes resolver un error?

manual de programacion android pdf (30)

¿Alguna vez has tenido un error en tu código que no pudiste resolver? Espero no ser el único que hizo esta experiencia ...

Existen algunas clases de errores, que son muy difíciles de rastrear:

errores relacionados con el tiempo (que ocurren durante la comunicación entre procesos, por ejemplo)
errores relacionados con la memoria (¡la mayoría de ustedes saben ejemplos apropiados, supongo!)
errores relacionados con eventos (difíciles de depurar, porque cada punto de quiebre que se encuentra hace que su IDE sea el objetivo para los eventos de lanzamiento / enfoque del mouse ...)
Errores dependientes del sistema operativo
errores dependientes del hardware (se produce en la máquina de lanzamiento, pero no en la máquina del desarrollador)
...

Para ser sincero, de vez en cuando no puedo solucionar un error así ... Después de depurar durante horas (o incluso días) me siento muy desmoralizado.

¿Qué haces en esta situación (aparte de pedir ayuda a otros que no siempre es posible)?

Vos si

usa lápiz y papel en lugar de un depurador
enfrentar otra cosa y volver a este error más tarde
...

¡Por favor hagamelo saber!

"¿Qué haces en esta situación (aparte de pedir ayuda a otros que no siempre es posible)?"

¿Cuándo no es posible pedir ayuda?

Siempre hay otros a los que puede acudir en busca de ayuda: sus compañeros de trabajo, su jefe, amigos aquí en , etc.

Comprender cuándo buscar ayuda no debe ser desmoralizador.

¿Seriamente? Hago las cosas en este orden

Acostarse
Pregunta a un colega
Reescribe para que el área no se vea afectada.
Preguntar SO
Levante un ticket de soporte con su proveedor de biblioteca de terceros.

A veces se necesita un poco de pensamiento lateral, pero cada error es reparable. A veces es necesario que se vaya y se quede dormido, a veces es bueno pedirle a alguien que lo mire rápidamente (es posible que vea algo que no haya visto), pero sobre todo trata de probar cosas diferentes, llamando a la experiencia previa. Puede ser frustrante, pero el rumor que obtienes cuando lo arreglas, ¡es como ningún otro!

Además del depurador, también utilicé el registro y el papel y el lápiz anticuados. En ocasiones he encontrado errores realmente difíciles, como el código que funciona bien en el modo de depuración, pero se rompe en el modo de lanzamiento. Incluso ocasionalmente reescribí un código perfectamente bueno que, por la razón que sea, no funciona de manera confiable, pensando que es mejor ser confiable que elegante.

A veces trato de redefinir lo que otros llaman un error como realmente una característica, ¡pero que rara vez funciona!

Agrego tanta depuración como sea posible (escriba en el archivo de registro, cuadros de mensaje, etc.) y pruebo.

No creo que este sea el peor error que puedas encontrar. Los peores son aquellos que no se pueden reproducir de manera determinista o en el entorno de prueba.

Algunas cosas que ayudan:

1) Tómate un descanso, acércate al error desde un ángulo diferente.

2) Hazte más agresivo con el seguimiento y el registro.

3) Haz que otro par de ojos lo mire.

4) Un último recurso habitual es encontrar una manera de hacer que el error sea irrelevante al cambiar las condiciones fundamentales en las que ocurre.

5) Aplastar y romper cosas. (¡Alivio de estrés solamente!)

Cita tomada de " The Cryptonomicon ":

"La intuición, como un relámpago, dura solo un segundo. Generalmente viene cuando uno se atormenta con un desciframiento difícil y cuando uno revisa en su mente los experimentos infructuosos ya probados. De repente, la luz se abre paso y se encuentra después de unos pocos minutos que los días de trabajo anteriores no pudieron revelar ".

Crea una forma automatizada para causar el error. El peor error para arreglar es uno que tarda horas en reproducirse.

Definitivamente he tenido errores en los que trabajé durante 4-5 días seguidos antes de encontrar una solución. Otros errores se han quedado en el rastreador de errores durante meses, ya que pongo unas pocas horas repartidas durante un largo período de tiempo. Creo que este tipo de error es inevitable en cualquier proyecto de software complejo.

Algunas cosas que me funcionan bien:

búsqueda binaria a través del flujo de programa con registro
utilice declaraciones de Trace junto con DbgView para buscar errores que aparecen en modo de lanzamiento
encuentra una forma alternativa de reproducir el error sin cambiar el código
(funciona en contra de la lógica, pero ...) cambie el código para que el error sea más fácilmente reproducible (la condición de falla se logra más fácilmente)
duerme en él y vuelve a intentarlo mañana con un par de ojos frescos :)

El peor tipo de error en mi opinión es un error de concurrencia que desaparece cuando se inserta el registro.

Doy más tiempo. Una vez tuve un error (en un proyecto personal) que no pude entender. Probé todos los métodos de depuración que pude pensar, incluido Google, sin éxito. Seis meses después, volví y encontré el error en una hora más o menos. No era algo simple (algo aparentemente indocumentado estaba pasando en el interior de Swing), pero lo miré de una manera que nunca antes había visto.

En primer lugar, ¿es reproducible? Eso es un GRAN plus si es así. Quiero que los errores de siempre / nunca sucedan ... son los intermitentes que son los problemáticos.

Y va a depender del problema, pero en mi tienda, por lo general, identificaremos un problema de ese tipo suponiendo que 2 cabezas (o 3 o 4) es mejor que 1.

Ocasionalmente, el error ni siquiera estará en mi código, pero generalmente lo es. Hubo problemas en los que una biblioteca de terceros fue el culpable o una implementación en particular en una plataforma en particular fue la causa, esos apestan.

Utilizaré cualquier cosa para localizarla: depuradores, salida de rastreo, lo que sea.

Normalmente, si puedo aislarlo en una clase o módulo, escribiré un arnés de prueba para duplicar el mundo real y trataré de duplicarlo allí. Generalmente escribo mi código de prueba primero, pero a veces existe código heredado (u otro código de desarrollador) que ya no tiene pruebas.

Generalmente hablaré el diseño y el problema, en voz alta con el equipo y la pizarra todo lo que no esté claro. A menudo, la solución saldrá a la superficie una vez que hablemos de ella como un grupo.

Eso es lo que hago.

Hay muchos buenos consejos aquí.

Uno con el que no estoy de acuerdo es el concepto de cambiar el código con la esperanza de que desaparezca. En primer lugar, probablemente va a introducir nuevos errores. Segundos, puede cambiar fácilmente las cosas lo suficiente como para ocultar el error solo para que resurja nuevamente con el siguiente parche.

Los errores de corrupción en la memoria son especialmente propensos a desaparecer tan mágicamente como aparecen. Sin embargo, el error de corrupción de memoria no es correcto, es solo que las áreas de memoria no fatales están siendo destruidas.

1) Pruebe con un depurador diferente. Por ejemplo, uso WinDbg cada vez más a menudo. Cuando carga un programa en un depurador, el diseño de la memoria de su aplicación cambiará ligeramente. Tal vez un depurador diferente haga que el error se manifieste de forma ligeramente diferente.

2) Si recurres a cambiar el código sin saber exactamente cuál es el problema, entonces si el error desaparece, DEBES volver y entender por qué el cambio solucionó el error. De lo contrario, probablemente solo estés ocultando el error.

3) Hable con otros sobre el error, tal vez hayan visto diferentes versiones del mismo problema (es decir, otras formas de recrearlo)

4) Logging.

He tenido errores que tomaron semanas o meses antes de que se encontrara una solución, pero finalmente todos los errores se arreglan. Además de las técnicas clásicas de depuración de errores que no son de depuración, como la desactivación de partes del sistema hasta que se obtiene un caso de prueba mínimo, he usado estas técnicas:

Buscando mejores herramientas de depuración. Una nueva perspectiva recorre un largo camino. Xdebug es algo que comencé a usar en PHP solo debido a un error de rendimiento que no estaba avanzando.
Estudiar la tecnología en la que se encuentra el error. Esto ha ayudado a depurar un complemento de Outlook. Tenía errores aleatorios que no tenían sentido y que las búsquedas de Google no daban vueltas. Al investigar las mejores prácticas de addlook complementarias, la programación COM y MAPI, obtuvimos una idea más clara de lo que podía salir mal, y pensamos en cosas nuevas para tratar de corregir los errores, lo que eventualmente los solucionó.
Intentando agravar el problema. Si hay un problema que solo ocurre ocasionalmente, intentaré encontrar la forma de hacerlo realidad constantemente. Esto ha ayudado a rastrear los errores en las aplicaciones web en IE y también a reducir un error de bloqueo en el complemento flash.
Cuando todo lo demás falló, reescribí el subsistema que causaba problemas desde cero. Esto puede tomar algunos días, o incluso semanas, pero si está atascado en un error y no puede resolverlo, y los clientes no aceptarán un no por respuesta, ¿qué más puede hacer? Esto no siempre soluciona las cosas, pero si no lo hace, generalmente obtiene una imagen más clara de lo que está pasando mal.

Me he dado cuenta de algunos puntos en común en estos errores que me atoran durante semanas:

Pedir ayuda a terceros no suele ser de ayuda y, en general, no es una buena idea esperar a que alguien más salga a salvar el día.
Casi siempre la falla está dentro de una tecnología de fuente cerrada de un tercero, especialmente cuando se usan partes oscuras. IE tenía errores desagradables al tratar de usar certificados de clientes. Flash no funcionó bien con las instrucciones de dibujo generadas al azar (algunas de las cuales no tenían sentido). A Outlook no le gusta cuando intenta cambiar el diseño del formulario de forma dinámica desde el código. En estos días he aprendido a respetar las "zonas de confort" de la tecnología patentada.

He tenido este problema antes, creo que todos lo han hecho, me he dado por vencido antes, era simplemente imposible de encontrar, pero seguía fallando, cuando hay algún tipo de error en el código, lo que hago es solo sentarme y concentrarse en cada bit del código poco a poco hasta que lo encuentre, es difícil y se necesita paciencia, pero es todo lo que se puede hacer en esa situación.

Espero que esto ayude.

Honestamente, no puedo recordar un error que no pude solucionar. Puede causar muchas refacciones, o puede tomar un tiempo, pero nunca he tenido uno que no pueda eliminar. Si me lleva más de una hora rastrearlo, casi siempre es algo realmente estúpido y pequeño como mirar más allá de eso : debería haber sido un ; , etc.

En Python, si estoy usando un editor que no es mío, o tal vez es el código de otra persona, ¡uso retab! en vim, o pegar en algo como pastie para comprobar la sangría (si no tengo vim disponible).

Si no es un bloqueador de transacciones / acuerdos, entonces sigo y vuelvo con un par de ojos nuevos.

Ah, y nunca podrás tener demasiada registración.

Muchas buenas respuestas aquí. Una cosa que me ha funcionado en el pasado es preguntar "¿qué puedo hacer para que sea totalmente obvio cuando se ha producido este problema?".

Por ejemplo, si el problema es un valor dañado en una estructura de datos, intente crear una rutina de comprobación de coherencia que pueda ejecutar periódicamente. También considere implementar todo el acceso a los datos compartidos a través de un conjunto de funciones que registran cada cambio.

O bien, si el problema es una sobrescritura de memoria "aleatoria", utilice una implementación malloc () / free () de reemplazo que atrape la escritura en la memoria "libre" (como cerca eléctrica o dmalloc).

Alguien más mencionó la automatización del proceso de activación del error. Esto es bueno si puedes hacerlo. Incluso tener una rutina que ejerza al azar el programa podría ayudar en estos casos.

Normalmente le pido a otra persona que eche un vistazo al código. Mientras explico lo que se supone que debe hacer el código, a veces veo el error justo cuando hablo.

Cuando un error es difícil, me siento y trabajo hasta que lo resuelvo y resuelvo el problema. Curiosamente, hay momentos en que la captura de un error misterioso es más agradable que todo lo que funciona sin problemas. Y el alivio y la sensación cuando se resuelve un error, bueno, no muchas otras cosas pueden superar eso (excepto las obvias).

Para los errores relacionados con la memoria, he encontrado que las opciones de perfil de memoria de Ants Profiler me han ayudado bastante a encontrar errores.

Por lo general, trato de resolverlo. Pero, si eso no es posible para ventanas de tiempo razonables, lo dejo durante algún tiempo a las células cerebrales para resolverlo mientras duermo;) A veces funciona ...

Salir por un tiempo y luego volver a un problema es un enfoque común que hago y he escuchado.

La facilidad con la que se reproduce el error también puede ser un factor, ya que si el error solo ocurre en uno en un trillón de ejecuciones de un programa que podría considerarse una ganancia insignificante para solucionarlo al romper algo más.

También está la cuestión de identificar dónde está el error, ¿está en alguna configuración para que ocurra en un servidor pero no en mi máquina XP Pro local que ejecuta IIS 5.0? Algunos otros errores pueden implicar tener que cambiar la resolución de mi máquina que puede ser molesto para tratar de reproducir un error que otros han informado.

Dejó fuera la categoría de errores "ocurre en otra O / S", por lo que una página web que está bien en IE y Firefox para PC puede parecer una mierda en Safari en una Mac. ¿Tengo mis manos sucias tratando de arreglar un problema de CSS usando mi máquina como servidor y la Mac que está más de una fila o dos en los cubículos del piso para ver este problema o es una prioridad tan baja que se vuelve barrido debajo de la alfombra? Alternativamente, si hay un error en Linux y no hay máquinas Linux cerca de mí, ¿qué debo hacer?

Lamento haberme quedado con algunas preguntas, pero estas parecen ser preguntas difíciles para mí a veces.

Si el error es tan sutil que lleva más de tres días averiguarlo, entonces generalmente cambio el diseño, porque el punto principal de entregar el software no se llama tres años después para depurarlo, por lo que es más fácil la interacción entre los componentes, el mejor.

Si no es crítico, no lo arregles, ¡pasarás demasiado tiempo!

Mantenga el error abierto. comente / trabaje en eso cuando pueda. ¡Puede ser arreglado por accidente (o por alguien más) más tarde!

Si todo lo demás falla, no lo abordes directamente. Reescribe el código de área problemático de una manera más refactorizada.

También me desmoralizo un poco cuando no puedo resolver un error. Por lo general, cuando toco una pared con un error, simplemente tomo nota de mis hallazgos y dejo de trabajar en él. Me gustaría saltar sobre otro error que es más fácil de resolver y luego volví al error. Al hacer esto, tendría una mente fresca y actitud para enfrentar el error. A veces puede tener tendencia a complicar demasiado las cosas cuando pasa demasiadas veces en un error. Tener un descanso, ayuda a romper la pared.

RWendi

Tengo un error que aparece cada pocos meses en el sitio de un cliente. Por lo general, ocurre a las 3 de la mañana y no se descubre hasta la mañana del día siguiente cuando el cliente llega a su sitio. Y generalmente cuando lo descubren, quieren que todo funcione inmediatamente, por lo que nuestro personal de soporte generalmente solo reinicia la computadora. Me ha estado volviendo loco durante años. Nunca sucede en mi máquina de prueba o en el laboratorio de QA, solo en ciertos sitios de clientes. Con el tiempo, he

refactoré algunos de los códigos que pensé que lo estaban causando
agregó más impresiones de depuración alrededor de donde parece estar fallando
stdout redirigido para que la próxima vez que lo vea pueda " kill -3 " el proceso
dado soporte algunas nuevas herramientas para volcar el estado actual de los bloqueos de bases de datos y similares.
diagnósticos adicionales para hacerlo más obvio cuando sucede

No ha sucedido en unos pocos meses, y he cruzado los dedos para que lo haya arreglado esta vez, pero no cuento con eso.

Una vez trabajé para una empresa que vendió una aplicación cliente-servidor que básicamente era una herramienta de transferencia de archivos y sincronización. Tanto el cliente como el servidor eran aplicaciones personalizadas que habíamos diseñado.

Tuvimos un error persistente que fue muy difícil de duplicar en el laboratorio. Nuestro servidor solo podía manejar una cierta cantidad de conexiones de clientes entrantes por caja, por lo que muchos de nuestros clientes agruparían varios servidores para manejar grandes poblaciones de usuarios. Los datos de back-end para el clúster estaban en un servidor de archivos que todos compartieron. En esta configuración de clúster había un error que ocurriría bajo carga en el que obtendríamos un código de error de sistema de archivos de bajo nivel en una llamada de uso compartido de archivos que involucra uno de los archivos de fondo. Nadie podía hacer que esto se repitiera de manera confiable en el laboratorio, e incluso cuando podían no podían reducir lo que estaba sucediendo.

(Olvidé el error exacto, probablemente fue 59 ERROR_UNEXP_NET_ERR o quizás 65 ERROR_NETWORK_ACCESS_DENIED . Como recuerdo, ni siquiera era uno de los códigos de error documentados que se suponía que podía obtener de la API que estábamos llamando, que generalmente era un bloqueo o desbloquear la llamada en una sección de archivo).

Como se trataba de la comunicación entre el servidor y la tienda de archivos de back-end, y yo era el tipo de "transporte de red", me dieron la tarea de mirarlo. Muchos otros lo habían mirado sin suerte.

La única cosa sólida que tenía era saber en qué parte del código se estaba detectando el error, pero no qué hacer al respecto. Así que necesitaba encontrar la causa raíz. Así que configuré un entorno de hardware apropiado para duplicarlo, y puse una compilación personalizada del software del servidor que instrumentaba la sección del código en cuestión.

La instrumentación fue la siguiente: agregué una prueba para el código de error problemático e hice que llamara a un trozo de código para enviar un paquete UDP a una dirección de red predeterminada cuando ocurrió el error. El paquete UDP contenía una cadena única para activar.

Luego configuré una herramienta para olfatear paquetes en la red. (En el momento en que estaba usando Microsoft Network Monitor ). Lo coloqué donde podría "ver" este paquete UDP cuando se envió, así como toda la comunicación entre los servidores del clúster y el servidor de archivos.

La mayoría de los rastreadores buenos tienen un modo en el que puedes capturarlo hasta que ve un trozo de tráfico en particular y luego detenerlo. Encendí ese modo y lo configuré para buscar el paquete UDP que mi código enviaría. El objetivo era terminar con una captura de paquetes de todo el tráfico del servidor de archivos justo antes de que se produjera el error. Los últimos paquetes de red hacia y desde el sistema donde se originó el paquete UDP serían presumiblemente una gran pista de lo que estaba sucediendo.

Establecí la configuración de "prueba de estrés" y me fui a casa durante el fin de semana.

Cuando volví el lunes, he aquí que tenía mis datos. El sniffer se había detenido tal como se esperaba después de muchas horas de funcionamiento y contenía una captura. Después de estudiar la captura, descubrí que el bloque del mensaje del servidor o la conexión SMB (también conocida como CIFS, alias SAMBA ) entre nuestro servidor y el servidor de archivos en realidad se estaba agotando en el nivel TCP debido a la carga extrema en el servidor. Debido a que todo el material de Microsoft tiene muchas capas, se filtraría a través de la pila de intercambio de archivos como un error "inesperado" en lugar de devolver un código de error más inteligible que dijera "hey, perdiste tu conexión en el nivel TCP".

Hice un poco más de investigación sobre la configuración de TCP para Windows , y he aquí que los valores predeterminados para la versión de Windows que estábamos usando (probablemente NT 4 en esa época) no fueron muy generosos. Solo permitía un número muy pequeño de fallas en la conexión TCP y en el boom, estabas muerto. Una vez que perdió su conexión SMB con el servidor de archivos, todos los bloqueos de archivos fueron tostados y no había forma de recuperarse.

Así que terminé escribiendo un apéndice al manual del usuario que explicaba cómo alterar la configuración de TCP en Windows para hacer que el servidor de clúster sea un poco más tolerante con situaciones de carga elevada. Y eso fue todo. La solución al error era cero cambio en el código , simplemente alguna documentación adicional sobre cómo configurar correctamente el sistema operativo para su uso por este producto.

¿Qué hemos aprendido?

Prepárese para ejecutar versiones alteradas de su código para investigar el problema
Considere usar herramientas no tradicionales para resolver el problema (sniffers)
No todas las correcciones de errores requieren cambios de código
A veces puedes diagnosticar un error mientras estás en casa tomando una cerveza

Yo hago una serie de cosas diferentes:

descarta todas mis suposiciones y comienza desde cero. Recuerde, existe un error porque algo que parece correcto es realmente incorrecto. Incluso esas líneas o funciones o clases que está absolutamente seguro que son correctas pueden ser incorrectas. Hasta que puedas convencerte de lo correcto, no puedes asumir que nada está bien.
sigo publicando declaraciones y afirmaciones para eliminar cosas y permitirme reformar nuevas suposiciones.
paso a través del código en el depurador si el problema es un problema de flujo de control. No te limites a las funciones. Métete en ellos y repasa todos los detalles de su ejecución para confirmar que están funcionando bien. Confirma los argumentos y devuelve los valores.
Si una línea o función o clase es sospechosa pero no puedo probarla in situ, escriba un pequeño caso de prueba que haga lo que usted cree que hace la construcción del problema. Esto puede ubicar el problema o brindar algunas ideas sobre dónde mirar a continuación.
parar por el día. Es sorprendente qué tipo de procesamiento fuera de línea hará tu cerebro de la noche a la mañana. A menudo, la respuesta o una idea clave aparecerá al día siguiente mientras estoy haciendo algo sin sentido como ducharme o conducir.

usa métodos más creativos para rastrear el error.

utilizando la depuración remota en la máquina donde es reproducible.

usando herramientas de perfilado

introducir más logging a la aplicación.

Esto es lo que hice hoy ...

Depuro la interacción HW / SW y a menudo el registro de casos (instrumentación) cambia u oculta el error. Por lo tanto, las pruebas se realizan "a la velocidad". Llamo a estos insectos "cucarachas" ya que huyen de cualquier luz que pueda brillar sobre ellos.

Entonces tengo que:

Encuentra la transacción que causa el error. Enumere la interacción HW a través del registro (esta prueba pasa, pero ilustra el flujo).

Instrumento antes y después del error para imprimir cambios de estado.

El error que estoy resolviendo ahora, por supuesto, es el peor de los casos, ya que el HW se bloquea. El HW incluye la CPU por lo que es como estar en una habitación bien iluminada, luego la energía falla y su tono negro.

Tengo una vista de puerta trasera especial en la memoria, pero por supuesto esto también está bloqueado. Probé el ciclo de encendido con la esperanza de que la memoria permanezca no volátil el tiempo suficiente para volver a habilitar la puerta trasera. No tal suerte. Esto es posible sin embargo.

Escribí muy cuidadosamente todos los pasos que pasé para caracterizar este error (qué funciona, qué falla, etc.). Envié esto a los desarrolladores con HW similar para verificar que no era yo o mi HW.

Me tomé unas horas de descanso para dejar que esta información se estableciera y ver si había bombillas encendidas en otra parte.

Sin respuestas, este error es mío para resolver ...

Esta interacción HW SW es un bucle que realiza cierta configuración y luego ingresa en un ciclo de sondeo que se lee cuando finaliza la transacción. Muchas transacciones deberían ocurrir. ¿Qué transacción falla? ¿Es el primero? (Lo que indica que puedo depurar la transacción y no algo de ruido en el HW). ¿Es la siempre la nona transacción? Lo que hace que la N sea diferente que la primera o la (N-1) th. El SW tiene un solo hilo y está construido para ser predecible. Sin preferencia, sin interrupciones habilitadas.

Este SW ya funcionó antes, ¿qué hay de nuevo? Todo el HW es nuevo. En este caso, todo el silicio es nuevo, ya que es un ASIC. Incluso la CPU integrada es nueva y personalizada, por lo que ISA es nueva.

Entonces sospecho todo y estoy ciego. Tendré que acercarme furtivamente a esta cucaracha.

Solo habilité el registro que informa cuántas veces el SW encuestó al HW para completarlo. De esta manera, la primera transacción se ejecuta a gran velocidad, me hago una idea de la frecuencia con la que toco el HW en un circuito cerrado de votación. La prueba pasa. Sé que es la enésima transacción y registré el número máximo de encuestas para todas las transacciones (tal vez datos sin sentido).

Después de modificar anythin, tengo que volver a ponerlo como estaba para verificar que el error todavía existe. Después de que toda la tierra haya girado y los vientos solares no sean tan fuertes;)

Al observar todos los registros, vi que un contratista había cambiado algunos parámetros importantes de configuración sin explicación. Estas personas (subcontratadas) aún están en evaluación. Esto no ayudará.

Encontré que no había spinwait en el ciclo de votación. Malo para el tiempo de espera de bucle ya que sin él, el tiempo de espera depende de la velocidad de la CPU. Se agregó spinwait, todavía no hay felicidad.

Limitó el número de transacciones para ver dónde falla, en algún lugar antes de 1000.

Configure el HW para que funcione más lento, aún cuelga.

Odio dejar a alguien leyendo esto también, pero esta diatriba tendrá que esperar hasta mañana.

Consideré pedir ayuda en este sitio web llamado que he estado frecuentando últimamente ...