Kolejna recenzja kolejnej książki…od tego samego autora 😊! Po kupieniu sobie poprzednio zrecenzowanej książki, wziąłem od razu drugą stanowiącą w pewnym sensie kontynuację nauki o "Microsoft Excel" 🧨. Mianowicie, "Makra i VBA w tydzień. Odkryj potęgę programowania!"! Jak interesujesz się jej zakupem, to zapraszam Cię do przeczytania artykułu, bo właśnie temu tytułowi jest on poświęcony w całości 🌟!
"MAKRA I VBA W TYDZIEŃ. ODKRYJ POTĘGĘ PROGRAMOWANIA!", CZYLI O PRACY W EXCELU "W PODZIEMIU"
"[...] w programowaniu nie ma nic z magii." (fragment z blurba książki). Sprzeciw 😆! Dla mnie, programowanie jest jak najbardziej zajęciem polegającym na wywoływaniu magii 🪄 na ekranie komputera przy pomocy znaków w pliku 🙂. To jest fach, który zawsze będę lubić ❤️🔥.
Kiedy dowiedziałem się, że w Excelu można normalnie pisać kod i tym sposobem jeszcze bardziej podnieść swoją efektywność w kierunku analizy danych, byłem ciekaw co można zrobić, czego nie dałoby się osiągnąć samym klikaniem czy rejestrowaniem makra 💡. Usiadłem, przeczytałem, dowiedziałem się 🙂. Czas przejść do tego, co warto wspomnieć na temat książki ✍️!
Profilaktycznie, ta sama formułka:
Recenzując książkę autorstwa Pana Mateusza Borygi i prezentując swoje zdanie na jej temat, nie leżało w mojej intencji żadne złośliwe wytykanie błędów. Jedynym celem publikacji recenzji było przedstawienie swojej opinii oraz sprostowanie pewnych przytoczonych treści, aby ewentualne ponowne wydanie książki było pozbawione wskazanych błędów, jeśli faktycznie takimi są (bo sam mogę się mylić!).
Przechodzę do meritum ⚠️.
Kilkanaście zdań o całokształcie
Drugi raz książkę Pana Borygi oceniam pozytywnie, choć mam do niej więcej zastrzeżeń w porównaniu do poprzedniej (więcej zostawiam w sekcji z uwagami). Na plus wychodzi na pewno duża liczba cennych przykładów wziętych z życia zawodowego. Autor zebrał w całość różne przypadki biorąc pod uwagę te, które przyniosły jakąkolwiek wartość biznesową (po prostu były przydatne w praktyce 😉) 💲. Główna część książki właśnie na tym się skupia.
Sam początek książki "Makra i VBA w tydzień. Odkryj potęgę programowania!" przynosi dużo ciekawych informacji ✔️. Jest ukazanie co kryje się za rejestrowaniem makra, zestawienie podstawowych instrukcji, proponowane podejście do uczynienia kodu reużywalnym, a na deser 🍨, utworzenie prościutkiej aplikacji graficznej w postaci wyskakującego okna 🎉! Można rzec, sama słodycz 🍬!
Najdłuższy rozdział (ponad połowa książki 😯) dotyczy przedstawienia wielu konkretnych przykładów w kategorii "najczęściej rutynowe czynności" ⚙️. Podejście składa się z kilku etapów:
- przedstawienie problemu/czynności,
- ukazanie efektu przed i po zastosowaniu makra,
- seria pytań (albo nie),
- rozwiązanie słowne,
- kod źródłowy.
Bywają wyjątki np. nie każdy przykład posiada jakiekolwiek pytanie zadane w stronę Czytelnika albo jest inna kolejność treści, niż ta na liście u góry. Tutaj głównym "aktorem" są kody źródłowe. Sposób przedstawienia każdego z przykładów jest super ❤️, trochę gorzej z samym kodem na wielu płaszczyznach (o czym piszę więcej w uwagach do tytułu). Na pewno fajnie zostało zademonstrowane to, że w pewnych sytuacjach koniec końców jednak trzeba zajrzeć do kodu i dostosować go pod swoje potrzeby tam, gdzie nie sięgnie rejestrowanie makra 🙂.
Ostatni chudziutki rozdział dotyczy ukazania kolejnych drobniejszych trików, tylko już w formie krótkich fragmentów, a nawet pojedynczych instrukcji, które nie zostały poruszone wcześniej 🔥.
Jedno muszę przyznać: ta książka pokazała mi jak bardzo potężny jest Excel 💪. Nigdy człowiek nie korzystał z makr, bo nie było to konieczne i to trochę przykre, że dowiaduję się dopiero po latach o czymś takim, jak programowanie makr i tworzenie formularzy w Excelu (de facto takich małych aplikacji graficznych). W którymś momencie zacząłem myśleć: "Cholera, dlaczego nie pokazano mi tego w szkołach?!" 🙂. Po przeczytaniu tej książki, na pewno czuję się "bogatszy" o nową wiedzę, zatem tytuł spełnia podstawowy wymóg literatury mającej na celu nauczyć 🧠. Super 🌟! To tak tytułem wstępu, jak brzmi mój ogólny odbiór 🏁.
Uwagi do książki
Teraz podzielę się swoimi zastrzeżeniami co do treści, które niestety troszkę psują przyjemność z czytania ⛔. Jak zawsze, zaczynamy od najbardziej priorytetowych 👇.
Przyczyna użycia instrukcji: nieznana
Poważna rzecz, która mnie zmartwiła to pokazanie jakiejś nazwy, instrukcji, zapisu i po prostu pójście dalej bez uwypuklenia do czego to służy albo dlaczego zostało tak napisane, tak jakby tego nie było. Zdarzyło się tak (niestety) wiele razy:
- kiedy wywołania procedur NIE potrzebują wstawiania parametrów wewnątrz nawiasów np. "Sheets(>>Dane<<).Copy" (str. 16),
- rodzaje wartości dla poszczególnych parametrów procedury (np. str. 93),
- znak ampersandu (&) do konkatenacji łańcuchów (str. 23),
- Label (str. 25),
- TextBox (str. 25),
- CommandButton (str. 25),
- Set (str. 37) + kiedy tego NIE trzeba wstawiać,
- "#,##" (łańcuch znaków w odpowiednim formacie, str. 63),
- ActiveSheet.ListObjects.Add (str. 66),
- ActiveWorkbook.PivotCaches.Create (str. 69),
- With (str. 70),
- ActiveCell.PivotCell.PivotTable.PivotCache.Refresh (str. 70),
- <> (operator "różny od", str. 81),
- Exit Sub (str. 83),
- Dim (str. 87),
- CreateObject (str. 87),
- CreateItem (str. 87),
- Type:=8 (parametr procedury "Application.InputBox", str. 92),
- For (str. 94),
- ForEach (str. 94).
Żeby nie było - nie jestem leniem i umiem sobie wpisać w wyszukiwarkę słowo kluczowe, które mnie interesuje, jeśli nie mogę się domyślić zastosowania 😊. Nie chodzi mi o żadne referaty. Krótkie jednozdaniowe wtrącenie co dana instrukcja przynosi i o co w niej chodzi, wystarczyłoby w zupełności ✅. Mnie przydałoby się zawrzeć taką informację (szczególnie, że to książka o programowaniu i dla początkujących ‼️), abym nie musiał zgadywać.
Potrzebna wizyta u "refaktoryzatora"
Ujmę to krótko: zaprezentowane kody źródłowe w książce "Makra i VBA w tydzień. Odkryj potęgę programowania!" wymagają przeróbki. Nie wszystkie, większość. Jestem programistą, który bardzo lubi porządek w kodzie 🙂 i zauważyłem, że wiele rzeczy można było napisać lepiej, schludniej, czytelniej. Stąd mój komentarz w tej sprawie 🗣️.
Nie ma sensu wypisywać wszystkiego jak leci, więc wypunktowałem konkretnie co moim zdaniem wymaga poprawki opierając się na konkretnym przykładzie, jeśli to było konieczne. Najpierw małe rzeczy, potem ważniejsze ℹ️.
Nazwy makr
Nie wiem jaka jest konwencja w biznesowych etatach dot. obsługi Excela (teraz to ciężko się zatrudnić gdziekolwiek 😐), natomiast w programowaniu przyjmuje się, że nazwy procedur/funkcji/metod (terminologia zależy od języka) powinny być w trybie rozkazującym. Tutaj nie są.
Niewłaściwe nazwy parametrów formalnych
Chodzi o niewystarczające sprecyzowanie czego dotyczy parametr. Widać to chociażby na str. 23, na przykładzie z kodu jednego z makr znajdującego się w plikach do książki, które są dostępne do pobrania na stronie Helion (źródło: https://ftp.helion.pl/przyklady/janipr.zip, dostęp: 11.07.2025):
NazwaKolumnyStart"Start" dopisane na końcu nie brzmi w mojej ocenie informująco w sposób jednoznaczny co to robi, do czego to jest itd. Zdecydowanie lepiej byłoby to nazwać:
NazwaKolumnyOdKtorejZaczynamyDla mnie tak jest lepiej, bo ten skrót myślowy został rozwinięty 👍. Jeżeli jako programista, miałbym wybierać czy nazwę uczynić krótszą, czy bardziej precyzyjną, wybieram precyzyjność 🎯, natomiast rozumiem, że to może być kwestia gustu. Jest wiele takich nazw w wielu fragmentach, jednak nie ma potrzeby (ani sensu) wymieniać.
Fakt, że wszystko pisane po polsku to odrębna kwestia, na którą można by zwrócić uwagę, jednak w przypadku książki jest zrozumiałe, że tu chodzi o przedstawienie tematu w sposób przyjazny dla początkujących.
Powtarzanie się tych samych wyrażeń
Kolejna zła praktyka 🚫. Jest wiele takich instrukcji, poleceń czy fragmentów kodu, które niepotrzebnie się powtarzają. Dam przykład tego samego kodu zaprezentowanego w nagłówku powyżej:
NazwaKolumnyStart & "2"Piszę się to samo dwa razy i to nie jest poprawne z dwóch przyczyn:
- pogarsza czytelność kodu,
- wymusza na procesorze wielokrotne wykonanie tego samego niepotrzebnie.
Podpunkt drugi jest jeszcze istotniejszy o tyle, że przy większych makrach może to stać się pośrednią przyczyną znacznego spowolnienia działania 📉!
Pewne instrukcje można było napisać prościej
Istotniejsza sprawa, jeśli chodzi o refaktoryzację, to fakt, iż niektóre fragmenty kodu można było po prostu skrócić do jeszcze mniejszych postaci. Za przykład podam kod makra dot. wyboru folderu z listy ze str. 82, z tych samych materiałów do pobrania ze strony Helion (źródło: https://ftp.helion.pl/przyklady/janipr.zip, dostęp: 11.07.2025):
Sub MatkaWyborFolderuZListy()
On Error GoTo Blad
With Application.FileDialog(msoFileDialogFolderPicker)
.Show
WybranyFolder = .SelectedItems(1) & "\"
End With
MsgBox WybranyFolder
Exit Sub
Blad:
MsgBox "Nie wybrano folderu."
End SubOd razu co przykuło moją uwagę, to powtarzanie się wywołania "MsgBox". Jeżeli uzależniamy jedynie samą treść komunikatu od tego, czy użytkownikowi uda się wybrać jakiś folder, czy też nie, to można po prostu stworzyć sobie zmienną łańcuchową, przypisać domyślną wartość (założenie braku wybranego folderu) i wywołać jedno "MsgBox" na samym końcu:
Sub MatkaWyborFolderuZListy()
WybranyFolder = "Nie wybrano folderu."
On Error Resume Next
With Application.FileDialog(msoFileDialogFolderPicker)
.Show
WybranyFolder = .SelectedItems(1) & "\"
End With
MsgBox WybranyFolder
End SubWtedy ten cały ciąg z instrukcją skoku ("GoTo") i "End Sub" nie jest w ogóle potrzebny ✔️! To samo dotyczy przykładu z wyborem pliku z listy (str. 84) 🙂.
Brak zabezpieczenia przed skrajnymi przypadkami
Doszliśmy do ostatniego: nieuwzględnianie przez makra innych ścieżek decyzyjnych, niż ta standardowa, czy może inaczej, super optymistyczna. Czyli zawsze jest wstawiana wartość do parametru, zawsze jest oczekiwanego typu, dany arkusz zawsze posiada tę i tę komórkę o tej wartości. Przypadek pt: "Wszystko jest cacy" 😁.
Pozwoliłem sobie zmienić parę rzeczy w przykładach i sprawdzić co się stanie jak NIE sprawdzi się scenariusz, w którym instrukcje mogą spokojnie funkcjonować na samych założeniach. I niestety makra wykładały się jak na wrotkach 🛼. Fragmenty kodów nie obejmują sytuacji niepożądanych, które także mogą mieć miejsce.
Weźmy sobie kod makra tym razem ze str. 60 książki "Makra i VBA w tydzień. Odkryj potęgę programowania!" dot. zmiany wielkości zaznaczenia (to samo źródło: https://ftp.helion.pl/przyklady/janipr.zip, dostęp: 11.07.2025):
Sub MatkaZmianaWielkosciZaznaczenia()
Range("A2:C4").Select
LiczbaWierszy = Selection.Rows.Count
LiczbaKolumn = Selection.Columns.Count
Selection.Resize(LiczbaWierszy - 1, LiczbaKolumn - 1).Select
End SubOd razu zadałem sobie pytanie: a co, jeżeli zakres będzie obejmował tylko jedną komórkę? Zamieniłem na samo "A2", odpaliłem i obawy były słuszne - błąd ❌! Odrębna sprawa to to, że makro działa na sztywno ustalonych wartościach i nie ma możliwości wstawiania parametrów, przez co kod nie jest uniwersalny 🛑.
Napisałem sobie taką wersję 👇:
Sub MatkaZmianaWielkosciZaznaczenia()
Call ZmianaWielkosciZaznaczenia("A2:C4", -1, -1)
End Sub
Sub ZmianaWielkosciZaznaczenia(Zakres, ZmianaWWierszach, ZmianaWKolumnach)
Range(Zakres).Select
AktualnaLiczbaWierszy = Selection.Rows.Count
AktualnaLiczbaKolumn = Selection.Columns.Count
OstatecznaLiczbaWierszy = WorksheetFunction.Max(AktualnaLiczbaWierszy + ZmianaWWierszach, 1)
OstatecznaLiczbaKolumn = WorksheetFunction.Max(AktualnaLiczbaKolumn + ZmianaWKolumnach, 1)
Selection.Resize(OstatecznaLiczbaWierszy, OstatecznaLiczbaKolumn).Select
End SubSprawdziłem i działa ✔️. To naturalnie nie pokrywa wszystkich przypadków np. w miejsce zakresu może pojawić się liczba albo wstawimy łańcuch w miejsce zmiany wielkości (choć podejrzewam, że wystarczy wtedy dać instrukcje warunkowe sprawdzające typ), natomiast ta postać pozwala na bezpieczne modyfikowanie wielkości zaznaczenia w sytuacji, gdyby miało wejść na zakresy ujemne albo zero 🔒. Ponadto, możemy dać w obie strony i ile chcemy 👑.
Żebym nie został źle zrozumiany! Nie chodzi mi o branie pod uwagę każdego mikroskopijnego przypadku 🔬, tylko raczej o pokazanie, że autor bierze pod uwagę taką okoliczność, demonstruje ją przynajmniej na jednym przykładzie (albo nawet wstawić to jako odrębny temat do któregoś z rozdziałów) i krótko tłumaczy dlaczego należy mieć tego świadomość 🔍. To jest moim zdaniem o tyle ważne, że takie podejście raz po raz może spowodować, że ktoś nauczy się pisać kod w taki sposób i nie będzie wiedział, że czyni to nie do końca właściwie ⚠️! A jedną z cech dobrego programowania jest odporność na wszystkie przypadki 🛡️.
Na końcu dopiszę, że cały czas mam na uwadze, że to są tylko przykłady przedstawione na konkretnych sytuacjach i one miały być z założenia proste (wzięcie tego wszystkiego pod uwagę mogłoby mocno "pogrubić" książkę 😀), a sam tytuł nie jest dla "orłów z Excela" 🦅. Znając jednak ten zawód, to takie podejście nie przeszłoby na żadnym etacie i góra kazałaby to poprawić, być może według powyższych wytycznych.
Jak to mam rozumieć?
Zdarzyło się już w samej treści poza kodem źródłowym, że nie mogłem zrozumieć pewnych określeń czy sformułowań. Albo zostało coś napisane w sposób niezrozumiały, albo nie było wytłumaczenia. Oto one:
- "[...] w Twojej wersji Excela" 👉 jest jakieś zróżnicowanie zależne od wersji? (str. 19),
- "[...] do adresu tego zakresu [...]" 👉 co to jest adres i dlaczego trzeba się odwoływać w taki sposób? (str. 92).
Byłoby dobrze umieścić wyjaśnienie, nawet w formie jednego zdania ✍️.
A co, gdyby było ustawione inaczej?
Podpunkt podobny do poprzedniego, z tym że teraz dotyczy ukazania jakichś ustawień, konfiguracji czy parametrów i nie ma ani słowa o tym, czym wynik różniłby się od drugiego, gdyby zmieniono wartość parametru lub instrukcję. Podaję konkretne przykłady:
- "Przechowuj makro w: Ten skoroszyt" 👉 brak informacji kiedy mogłaby się przydać zmiana domyślnego ustawienia (str. 30),
- "On Error GoTo Etykieta" 👉 brak informacji kiedy instrukcja wyświetlania okna dialogowego zwraca wartość jako błąd i w jaki sposób to działa, że instrukcja "On Error" to "przechwytuje" (str. 83),
- "On Error GoTo 0" 👉 co daje wstawienie zera?; dlaczego napisane w taki sposób? (str. 87),
- "Nothing"👉 dlaczego jest przypisanie do "Nothing"?; czy można było to napisać inaczej?; co by się stało, gdyby tego nie było? (str. 87),
- "Application.DisplayAlerts" 👉 jeżeli miałbym niezapisane zmiany, to rozumiem, że wtedy by przepadły? (str. 90).
Mój komentarz: patrz wyżej 😄!
Trzeba sprostować
Tu będzie grubiej, bo to się tyczy wielu miejsc w książce "Makra i VBA w tydzień. Odkryj potęgę programowania!" 😅. Kody źródłowe, na jakie się powołuję, pochodzą cały czas z tego samego źródła (https://ftp.helion.pl/przyklady/janipr.zip, dostęp: 11.07.2025).
Strona 53
Na początek str. 53. Fragment treści:
"[...] będziemy potrzebować wstawienia formuły na końcu arkusza."Gdy pierwszy raz przeczytałem to zdanie, w pierwszej chwili myślałem o...końcu arkusza, czyli o ostatniej komórce hen daleko od danych 😀. Zrozumiałem o co biega dopiero, jak spojrzałem na rysunek na kolejnej stronie. Stąd moja propozycja, aby dopisać, że chodzi o pierwszą kolumnę poza tabelą.
Strona 78
Na str. 78 znajdziesz nagłówek, który brzmi "Wybór pliku". Dopiero po wypróbowaniu kodu zrozumiałem, że to jest błędne określenie! Oto konkretny kod:
Sub MatkaWyborPliku()
Call WyborPliku("Nazwa pliku.xlsx")
End Sub
Sub WyborPliku(NazwaPliku)
Windows(NazwaPliku).Activate
End SubTo NIE JEST wybranie pliku, tylko przejście do jednego z już otwartych plików, a to jest różnica ⛔! Wybór pliku kojarzy mi się z wyskakującym oknem, w którym faktycznie wybieramy plik np. do otwarcia 📂. Co ciekawe, zaledwie stronę dalej już zostało to dużo lepiej określone jako "przejście na wybrany plik" 👍.
Strona 81
Strona 81 jest kolejnym z przykładów zawierających błędne określenie. Konkretnie, to ten fragment:
Do While NazwaPliku <> ""i takie opisanie powyższej instrukcji:
"[...] szukanie kolejnego pliku będzie się odbywać, dopóki (Do While) istnieją kolejne pliki spełniające ustalone warunki."Dopóki łańcuch znaków "NazwaPliku" nie będzie łańcuchem pustym, to jest prawdziwe uwarunkowanie ℹ️. To powinno być dopisane w tym zdaniu albo zaraz po nim!
Galimatias ma po części związek z uwagą dot. niewyjaśnienia pewnych instrukcji i tak jest ze słowem "Dir", o którym nie napisano, że za pierwszym razem musi mieć zdefiniowane kryterium (a potem już nie!) i zwraca pusty łańcuch znaków, gdy nie znajdzie żadnego nowego pliku zgodnie z podanymi filtrami. Tego już dowiedziałem się stąd 😛.
To nie wszystko co do tej strony 😅! Linijkę z "MsgBox":
MsgBox NazwaPlikuokreślono jako "wyświetlenie nazwy". Ja bym napisał: "komunikat w postaci wyskakującego okna wyświetlającego nazwę". Znowu - doprecyzowanie 🎯!
Zbędne nagłówki
Następny punkt: nagłówki, które w mojej ocenie powodują więcej zamieszania, niż pożytku. Konkretnie, to dwa:
- "Po" 👉 nie ma tu rysunku do porównania, więc to jest bezcelowe (str. 83 i 84),
- "Rozwiązanie" 👉 nie było pytania, więc nie ma sensu rozdzielać (str. 83, 85 i 87).
Tabela byłaby o wiele lepsza
Na str. 19 jest wypisanie przez autora książki "Makra i VBA w tydzień. Odkryj potęgę programowania!" podstawowych instrukcji czy pojęć z jakimi można spotkać się w kodzie. Sęk w tym, że w mojej ocenie użyto nieodpowiedniego formatowania i powinno się to zrobić przy użyciu tabeli. W jednej kolumnie dać instrukcję, w drugiej krótkie wyjaśnienie i tyle. Napisanie tego w formie kodu źródłowego jest chaotyczne, bo wiersze robią dużo nieregularności i nie ma miejsca na taki format strony 📄. Raczej to nie kwalifikuje się jako errata, więc piszę o tym tutaj.
Mały "remont" listy wypunktowanej
Na str. 30 znajduje się lista wypunktowana, która ma dwie rzeczy do poprawienia 2️⃣.
Po pierwsze, można było spróbować scalić ze sobą punkty ("Testowanie" i "Testowanie makra-matki"), jako że w treści różnią się tylko jednym słowem 😉. Po drugie, dorzuciłbym do punktu "Przekształcenie zarejestrowanego makra na wzorzec matka-córki" jeszcze jeden podpunkt na końcu: "Edycja kodu" lub "Refaktoryzacja kodu". Kroki do edycji makra i przerobienia go na uniwersalną wersję nie kończą się przecież na samym przejściu do "Module1" 🙂.
O jedno zdanie za mało
Na str. 40, w sekcji "Rozwiązanie" spodziewałem się, że jak są 3 kolumny z danymi do edycji, to będą pokazane podejścia dla wszystkich 3 kolumn. I wszystko OK, bo wyszło dużo mniej rysunków 😄, tylko dopisałbym jedno malutkie zdanie do treści przed sekcją "Kod":
"Postępujemy analogicznie dla pozostałych kolumn."Wtedy byłoby spójnie z kodem źródłowym, który już uwzględnia wszystkie 3 kolumny, zamiast tylko pierwszej 👍.
Miejsce na odpowiedzi lepiej zrobić daleko od pytań
To przedostatnia ze wszystkich moich uwag 😜. Moim zdaniem, stawianie odpowiedzi tuż pod pytaniem wywołuje pokusę i odruch, żeby zajrzeć od razu do odpowiedzi, zanim człowiek pomyśli sam. Natomiast wiem, że w przypadku tej książki byłoby trudno wyjaśniać przykład jeden po drugim przenosząc wszystko na sam koniec, aby musieć co chwilę tam przechodzić i wracać 🙂.
Kopiuj, wklej!
I ostatnia najdrobniejsza uwaga 🙂. Zauważyłem, że zdanie z następującym fragmentem:
"[...] Excel nie umożliwia [...]"jest napisane słowo w słowo, zarówno na str. 47, jak i na str. 51 😛.
Czy książka jest warta zakupu?
W końcu najważniejsze pytanie 😁. Tylko, jeżeli Ci zależy na poznaniu możliwości Excela od strony programistycznej, czyli automatyzacja pewnych czynności przy użyciu kodu, bo jednak większa część wymaga szperania w kodzie i nie wystarczy rejestrowanie makr 🔴. Także gdy chcesz dowiedzieć się o makrach w stopniu bardziej zaawansowanym, to bez dwóch zdań będą to dobrze wydane pieniądze, bo ta książka zawiera w sobie wiedzę opatrzoną etykietą "o tym nie powiedzą Ci w szkole". Natomiast to nie jest książka ucząca stricte tego, jak poruszać się po interfejsie Microsoft Excel!
 |
Książka "Makra i VBA w tydzień. Odkryj potęgę programowania!" składa się z cennej treści jak zacząć programowanie makr oraz zawiera zbiór gotowych patentów na postawione problemy, aczkolwiek kody źródłowe wymagają poprawek.
To wszystko! Teraz decyzja należy do Ciebie czy sobie to kupić, czy nie 😀!