PYTHON: Jak zniechęcić głodnych do jedzenia, a słuchaczy do słuchania — wpadki z prezentacji na temat przetwarzania obrazów

W Hiszpanii bardzo popularnym posiłkiem jest Tapas, czyli niewielkie przekąski serwowane do piwa. Małe porcje jedzenia z różnymi składnikami znaczniej lepiej sycą głód niż paluszki i czipsy albo ogórki, poza tym są bardzo smaczne.

W pewnych okolicznościach mogą doprowadzić do przeciwnego, niż zamierzony, skutku. Głodny człowiek przestaje odczuwać głód.

W zeszłym roku uczestniczyłem w konferencji w Madrycie. Wydarzenie organizowane było przy udziale dużych organizacji, więc wyszedłem z założenia, że czeka na mnie pyszny obiad. Nie zjadłem wcześniej nic, jak zresztą większość uczestników konferencji. Niestety srodze się zawiedliśmy i obiadu nie było, a pojawiła się również plotka, że wieczornego poczęstunku również nie będzie! Plotka na szczęście okazała się nieprawdziwa i ulotniła się wraz z pierwszymi kelnerami serwującymi wspomniane wcześniej tapas.

Samotni kelnerzy i kelnerki, z płytami pełnymi malutkich kromeczek (wielkości piętki od chleba), ruszyli niepewnym krokiem w tłum wygłodniałych naukowców, pracowników biznesowych i programistów. Wtem zmaterializowały się problemy:

  1. Czy przy skończonej powierzchni tacy możliwe jest wykarmienie wszystkich osób na sali?
  2. Czy przy prędkości pochłaniania tapas przez jednego uczestnika konferencji równej w przybliżeniu c możliwe jest szybkie przejście przez tłum do wygłodniałych osób znajdujących się na obrzeżach grupy z prędkością v znacznie mniejszą niż c: v << c?

Odpowiedź na oba pytania brzmi: nie. Dodatkowo kelnerzy mieli skończoną prędkość nabierania kolejnych porcji na zapleczu i było ich zbyt mało na tak wielu gości, więc kolejne dostawy pojawiały się z dużymi opóźnieniami. Teraz wyobraźcie sobie, że jecie obiad i widelcem sięgacie po danie co pięć minut. Jak szacujecie, po ilu machnięciach odechce się wam jeść zupełnie? Spędzicie tak godzinę? Dwie? No właśnie, dlatego nigdy więcej tapas!

Powiedziałbym: fajna anegdotka, ale mi się to nigdy nie przytrafi. Jestem programistą i nie obsługuję żadnych wydarzeń. Rzeczywistość zweryfikowała moje podejście, boleśnie dla mojego ego i empatii. Nadszedł ten dzień, kiedy to ja serwowałem tapas wygłodniałym osobom i popełniłem dokładnie ten sam błąd, co organizatorzy konferencji w Madrycie: serwowałem zbyt małe porcje, pozwalając sobie na zbyt długie przerwy między kolejnymi dawkami.

W ten sposób, przez żołądek do głowy, trafiamy na problem prezentowania kodu i wyników kodowania w prelekcjach na temat przetwarzania obrazów i wizualizacji danych. Co najistotniejsze, ma to związek z czystością kodu!

Analiza przypadku

Na 23 spotkanie Trójmiejskiej grupy programistów Pythona przygotowałem prezentację na temat analizy obrazów w dziedzinie częstotliwości. Temat jest bardzo ciekawy i znacznie wykracza poza podstawy serwowane na studiach, (gdzie co najwyżej rozkłada się obraz na widmo częstotliwościowe i bada się amplitudę i fazę sygnałów), więc pomyślałem, że przygotuję sporo przykładów użycia cyfrowej transformaty Fouriera które na pewno zaskoczą uczestników.

Bezmyślnie zacząłem przygotowywać przykłady.

Jak bezmyślnie? Bardzo bezmyślnie. Znalazłem dziewięć różnych zastosowań transformaty i każde z nich zaimplementowałem w Pythonie i OpenCV. Wyniki i wyniki przejściowe prezentowałem za pomocą Pythonowego matplotlib-a. I tutaj popełniłem poważny błąd: każdy z prezentowanych przykładów, będący oddzielnym skryptem, miał powtarzające się fragmenty kodu związane z wyświetlaniem danych.

Drugi błąd polegał na przeskakiwaniu między kodem a wyświetlanymi obrazami (alt + tab) a trzeci błąd na zakopaniu istotnych zmiennych i funkcji mających wpływ na wyniki wewnątrz długiego kodu. Nie stworzyłem odpowiednich klas, które ułatwiłyby… analizę algorytmów do przetwarzania obrazów (co nie jest równoznaczne z analizą kodu). Algorytm mojego “występu” prezentował się następująco:

Jak zniechęcić do słuchania prezentacji?

Spójrzmy na to z perspektywy czasu z pominięciem głównej treści prezentacji:

10 sekund potrzebne na uruchomienie terminala, 5 sekund na wpisanie ścieżki do pliku, 10–30 sekund na wykonanie procesu. To już łącznie około 50 sekund, będę zaokrąglał w górę dla wygody. Następnie przejście między oknami do okna przetworzonych obrazów. Pięć sekund, w zależności od ilości okienek do “poukładania”, przechodzenie między oknami (na pewno wolniejsze niż 60 klatek na sekundę) i zmiana okna na edytor w celu zmiany parametrów algorytmu, bo zaczynałem od złych albo niepełnych implementacji. Te poszukiwania mogły trwać nawet 30 sekund. W tej chwili mamy już łącznie minutę i trzydzieści sekund. Następnie uruchomienie terminala, który przez przypadek wcześniej zamknąłem… (i nie przygotowałem skryptów do szybkiego uruchamiania procesów), wizualizacja nowych wyników i przejście do następnego przykładu.

W najlepszym wypadku przechodzenie między oknami trwało łącznie około dwie i pół minuty na jeden cykl.

A wątpię, że ten mityczny najlepszy wypadek zdarzył się właśnie mnie. Ładowałem informacje seriami, robiłem przerwę,

(Wczytywanie… Wczytywanie… Wczytywanie… … … …),

po czym znowu zalewałem publiczność ciekawym ale trudnym materiałem. Podejrzewam, że już w trakcie pierwszych przerw wynikających z braku organizacji kodu pod kątem wystąpienia publicznego, osoby na sali, nawet te zainteresowane i kulturalne, odpłynęły myślami do innego, lepszego świata.

Nauka z tego taka, że prezentacji o kodzie nie prowadzi się metodyką zwinną. I o kod trzeba dbać, tak samo jak o słuchaczy.

A to madryckie tapas:

Wolisz jeden posiłek w czasie T, czy [jedną dwudziestą posiłku mnożoną przez (20*T + 19*przerwa)]? Credits: Szymon Moliński