Artwork

תוכן מסופק על ידי Nilo Vélez. כל תוכן הפודקאסטים כולל פרקים, גרפיקה ותיאורי פודקאסטים מועלים ומסופקים ישירות על ידי Nilo Vélez או שותף פלטפורמת הפודקאסט שלהם. אם אתה מאמין שמישהו משתמש ביצירה שלך המוגנת בזכויות יוצרים ללא רשותך, אתה יכול לעקוב אחר התהליך המתואר כאן https://he.player.fm/legal.
Player FM - אפליקציית פודקאסט
התחל במצב לא מקוון עם האפליקציה Player FM !

13. Programando con aves de corral

12:00
 
שתפו
 

Manage episode 216511593 series 2350559
תוכן מסופק על ידי Nilo Vélez. כל תוכן הפודקאסטים כולל פרקים, גרפיקה ותיאורי פודקאסטים מועלים ומסופקים ישירות על ידי Nilo Vélez או שותף פלטפורמת הפודקאסט שלהם. אם אתה מאמין שמישהו משתמש ביצירה שלך המוגנת בזכויות יוצרים ללא רשותך, אתה יכול לעקוב אחר התהליך המתואר כאן https://he.player.fm/legal.

En el capítulo de hoy toca hablar de programación, y en concreto de depuración de código. No os asustéis, que ya sabéis que este podcast siempre procuro hacerlo digerible tirando más por la divulgación.

La depuración de código no es otra cosa que identificar errores tus programas, analizar las causas y arreglarlos. Esto puede ser desde un error catastrófico que hace que tu aplicación o tu web no haga nada, los errores 500 que vimos en el capítulo cinco, hasta problemas que simplemente hace que tu código no haga lo que tiene que hacer.

Rubber Chicken Debugging, una alternativa al Rubber Duck Debugging

En español se utiliza la palabra «depurar», que tiene que connotaciones de que estás limpiando, quitando impurezas. En inglés se llama «debugging», que tomado al pie de la letra sería «quitar bugs» y los «bugs» son literalmente «bichos», así que el debugging se podría interpretar como «desparasitar el código».

A mi me gusta este planteamiento de «desparasitar». Primero porque suena más funcional y menos esotérico que «depurar», que da la impresión de que vas a usar Reiki y Flores de Bach, y segundo y más importante, porque el término debugging tiene una etimología maravillosa.

El término es mucho más antiguo de lo que parece y se utilizaba en ingeniería mecánica mucho antes de que aparecieran los primeros ordenadores.

Ya en 1878 Thomas Edison le enviaba esta carta a un colaborador:

«Ha ocurrido así en todos mis inventos. El primer paso es la intuición, que llega como una ráfaga, pero luego aparecen dificultades- y es entonces cuando los «bugs», que es como se llaman estos pequeños fallos y dificultades, dan la cara y hacen falta meses de intensa observación, estudio y trabajo antes de poder alcanzar el éxito o el fracaso comercial»

En «Atrapa esa liebre» 1944, los robots de Asimov ya tenían bugs:

«U.S. Robots tenía que quitarle los bugs al robot múltiple, y habñia gran cantidad de bug y siempre quedaba al menos una docena pendientes para la prueba de campo»

En 1947, Grace Hopper encuentra un bug de verdad, una polilla en un relé del ordenador Mark II en el que estaba trabajando y lo documenta así de maravillosamente:

De los métodos de depuración, uno de los más sencillo es la depuración con patito de goma. Esta técnica fue descrita formalmente por primera vez en el libro de 1999 «The Pragmatic Programmer», de Andrew Hunt y David Thomas:

A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else. The other person should look over your shoulder at the screen, and nod his or her head constantly (like a rubber duck bobbing up and down in a bathtub). They do not need to say a word; the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself.

Aunque lo que verdad lo hizo popular fue este mensaje de mensaje de Andrew Errington en 2002 en la lista de correo lists.ethernal.org (http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html)

We called it the Rubber Duck method of debugging. It goes like this:

1) Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety)
2) Place rubber duck on desk and inform it you are just going to go over some code with it, if that’s all right.
3) Explain to the duck what you code is supposed to do, and then go into detail and explain things line by line
4) At some point you will tell the duck what you are doing next and then realise that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.

Works every time. Actually, if you don’t have a rubber duck you could at a pinch ask a fellow programmer or engineer to sit in.

Si quieres más información, tienes toda una web dedicada al Rubber Duck Debugging: https://rubberduckdebugging.com/

Fuentes

  • Computerworld: Moth in the machine: Debugging the origins of ‘bug’
    https://www.computerworld.com/article/2515435/app-development/moth-in-the-machine–debugging-the-origins-of–bug-.html
  • Atlas Obscura: Grace Hopper’s Bug – A computer bug so primitive it was an actual insect.
    https://www.atlasobscura.com/places/grace-hoppers-bug
  • Wikipedia: Rubber duck debugging
    https://en.wikipedia.org/wiki/Rubber_duck_debugging
  continue reading

21 פרקים

Artwork
iconשתפו
 
Manage episode 216511593 series 2350559
תוכן מסופק על ידי Nilo Vélez. כל תוכן הפודקאסטים כולל פרקים, גרפיקה ותיאורי פודקאסטים מועלים ומסופקים ישירות על ידי Nilo Vélez או שותף פלטפורמת הפודקאסט שלהם. אם אתה מאמין שמישהו משתמש ביצירה שלך המוגנת בזכויות יוצרים ללא רשותך, אתה יכול לעקוב אחר התהליך המתואר כאן https://he.player.fm/legal.

En el capítulo de hoy toca hablar de programación, y en concreto de depuración de código. No os asustéis, que ya sabéis que este podcast siempre procuro hacerlo digerible tirando más por la divulgación.

La depuración de código no es otra cosa que identificar errores tus programas, analizar las causas y arreglarlos. Esto puede ser desde un error catastrófico que hace que tu aplicación o tu web no haga nada, los errores 500 que vimos en el capítulo cinco, hasta problemas que simplemente hace que tu código no haga lo que tiene que hacer.

Rubber Chicken Debugging, una alternativa al Rubber Duck Debugging

En español se utiliza la palabra «depurar», que tiene que connotaciones de que estás limpiando, quitando impurezas. En inglés se llama «debugging», que tomado al pie de la letra sería «quitar bugs» y los «bugs» son literalmente «bichos», así que el debugging se podría interpretar como «desparasitar el código».

A mi me gusta este planteamiento de «desparasitar». Primero porque suena más funcional y menos esotérico que «depurar», que da la impresión de que vas a usar Reiki y Flores de Bach, y segundo y más importante, porque el término debugging tiene una etimología maravillosa.

El término es mucho más antiguo de lo que parece y se utilizaba en ingeniería mecánica mucho antes de que aparecieran los primeros ordenadores.

Ya en 1878 Thomas Edison le enviaba esta carta a un colaborador:

«Ha ocurrido así en todos mis inventos. El primer paso es la intuición, que llega como una ráfaga, pero luego aparecen dificultades- y es entonces cuando los «bugs», que es como se llaman estos pequeños fallos y dificultades, dan la cara y hacen falta meses de intensa observación, estudio y trabajo antes de poder alcanzar el éxito o el fracaso comercial»

En «Atrapa esa liebre» 1944, los robots de Asimov ya tenían bugs:

«U.S. Robots tenía que quitarle los bugs al robot múltiple, y habñia gran cantidad de bug y siempre quedaba al menos una docena pendientes para la prueba de campo»

En 1947, Grace Hopper encuentra un bug de verdad, una polilla en un relé del ordenador Mark II en el que estaba trabajando y lo documenta así de maravillosamente:

De los métodos de depuración, uno de los más sencillo es la depuración con patito de goma. Esta técnica fue descrita formalmente por primera vez en el libro de 1999 «The Pragmatic Programmer», de Andrew Hunt y David Thomas:

A very simple but particularly useful technique for finding the cause of a problem is simply to explain it to someone else. The other person should look over your shoulder at the screen, and nod his or her head constantly (like a rubber duck bobbing up and down in a bathtub). They do not need to say a word; the simple act of explaining, step by step, what the code is supposed to do often causes the problem to leap off the screen and announce itself.

Aunque lo que verdad lo hizo popular fue este mensaje de mensaje de Andrew Errington en 2002 en la lista de correo lists.ethernal.org (http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html)

We called it the Rubber Duck method of debugging. It goes like this:

1) Beg, borrow, steal, buy, fabricate or otherwise obtain a rubber duck (bathtub variety)
2) Place rubber duck on desk and inform it you are just going to go over some code with it, if that’s all right.
3) Explain to the duck what you code is supposed to do, and then go into detail and explain things line by line
4) At some point you will tell the duck what you are doing next and then realise that that is not in fact what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.

Works every time. Actually, if you don’t have a rubber duck you could at a pinch ask a fellow programmer or engineer to sit in.

Si quieres más información, tienes toda una web dedicada al Rubber Duck Debugging: https://rubberduckdebugging.com/

Fuentes

  • Computerworld: Moth in the machine: Debugging the origins of ‘bug’
    https://www.computerworld.com/article/2515435/app-development/moth-in-the-machine–debugging-the-origins-of–bug-.html
  • Atlas Obscura: Grace Hopper’s Bug – A computer bug so primitive it was an actual insect.
    https://www.atlasobscura.com/places/grace-hoppers-bug
  • Wikipedia: Rubber duck debugging
    https://en.wikipedia.org/wiki/Rubber_duck_debugging
  continue reading

21 פרקים

כל הפרקים

×
 
Loading …

ברוכים הבאים אל Player FM!

Player FM סורק את האינטרנט עבור פודקאסטים באיכות גבוהה בשבילכם כדי שתהנו מהם כרגע. זה יישום הפודקאסט הטוב ביותר והוא עובד על אנדרואיד, iPhone ואינטרנט. הירשמו לסנכרון מנויים במכשירים שונים.

 

מדריך עזר מהיר