Excel Forum - Porady, Pomoc, Excel Help, Excel FAQ - Low Code - przemyślenia i kontynuacja wątku z PQ

master_mix

Ten wątek ewidentnie mnie "uruchomił", tym bardziej że obraża moje koleżanki i kolegów, specjalistów w VBA .

W dzisiejszych czasach , gdzie polityka firmy wiodących w wypuszczaniu na rynek platform programistycznych idzie w kierunku Low Code i wydawałoby się w celu ""wyeliminowania"" wykwalifikowanych programistów, nie do końca taki cel ma. Należy spojrzeć trochę inaczej na te narzędzia a także na sam cel który tej polityce przyświeca.
Od dłuższego czasu technologia cyfrowa stała się wszechobecna i opanowała już każdy najmniejszy aspekt naszego życia , można by powiedzieć że nasz byt jest uzależniony od tej technologii i jej rozwoju.
A już najbardziej dotyczy to dużych przedsiębiorstw, które bez cyfrowego świata nie zbudowałyby swojej wysokiej pozycji na rynku.
Co za tym idzie, popyt na specjalistów jest tak duży że brakuje rąk i głów do pracy,
A przedsiębiorstwa chcą jeszcze więcej aplikacji i to w krótkim czasie .
Odpowiedzią na tą sytuację jest właśnie platforma nisko kodowA. Jest ich sporo i liczba ta cały czas rośnie .
Doszło do tego że powstał nowy rodzaj programistów zwany "Citizen deweloper"
Programowanie przez "drag and drop". Podobno (jak czytamy w necie) w 2024r 65% aplikacji na być stworzona właśnie w tej technologii. W mojej prywatnej opinii będzie ich około 25-30%. A funkcjonujących w przedsiębiorstwach może z 5-10%.
Efekt, tego ma być taki że :
1. Programistom może być każdy i szybko się tego rodzaju programowania nauczyć - więc rozwiązuje to problem braku specjalistów .
2. Popyt na szybko tworzone aplikacje będzie zaspokojony.
3. Specjaliści-Programiści zajmą inną pozycję w strukturach IT, bardziej staną się Software Architects - i nie będzie potrzebna ich aż taka duża liczba - Bez obawy, pracy będzie opór :)
Myślę że mocny rozwój tej technologii nisko kodowej jest nieunikniony i też niezbędny.
Jednak slogany marketingowe mówiące o efektywności i elastyczności tych platform są oczywiście "marketingowym chwytem".
Prawdziwym celem jest Biznes.
O ile elastyczność z czasem będzie się zwiększać , to efektywność nie będzie szła z nią w parze. Najważniejszy ich cel to zaspokoić w/w popyt i zarobić większą kasę.

Należy pamiętać o tym, że nisko kodowe technologie (nie mówiąc już o platformach no-code) to kolejne przejście na wyższy poziom abstrakcji w programowaniu .
Co za tym idzie nie ma możliwości aby ich wydajność była wyższa a wręcz przeciwnie, niższa.
Im niższy poziom programowania tym szybciej.
Assembler , C++ , zawsze będą żywe , ekstremalnie wydajne i niezbędne do funkcjonowania technologii na wyższych poziomach programowania .
W przypadku Microsoft taką platformą nisko kodową jest Power Platforms. Piękne narzędzia , ale zakup licencji elementów składowych i zasobów pogania kolejny zakup licencji i tak w kółko aż do wyczerpania budżetu :)

Samo PQ o którym mowa we wspomnianym na początku wątku jest wynikiem zaspokojenia 3 potrzeb :
Następcy Microsoft Query i nowy trend Low Code a też wymóg "dobrego silnika" dla PowerBI.
Co nie zmienia faktu że PQ jest narzędziem dla Citizen Deweloper'ów , a o wydajności w Excelu jaką ma VBA może pomarzyć , no i przydatne w wąskim określonym celu.

bodek · Wersja: Win Office 2019 **Pomógł:** 1083 razy Posty: 3195

master_mix, bardzo ciekawy punkt widzenia a zwłaszcza ocena potrzeb rynkowych biznesu.
Zatem popisze co wiem, czuję i mi się subiektywnie wydaje, od innej strony
("Biurwa" - nie gniewaj się, też nią bywam :-P

)

Mi baaaardzo, wręcz nieskończenie daleko, to tego, co masz w stopce :tak

ale swoje za uszami we współpracy z firmami w zakresie szeroko rozumianego Excela to już mam. Zatem kilka nudnych i paskudnych uwag z mojej strony:
- Excela ma każda "biurwa" na desku, fakt
- Excela każda biurwa "dobrze lub nawet b. dobrze zna" -> nie, nie ma o nim nawet mglistego pojęcia :mrgreen:

- "Biurwy" jakoś tam mielą tony Gigabjatów danych z SAP-ów i to pod ciągła presją tych co wyżej,
- Podstawowa operacja "biurwy" to Ctrl+C -> Ctrl+v -> Power Point -> Share Point
- Programy dedykowane do analizy problemu X,Y,Z -> kosztują mnóstwo $, są nieelastyczne do potrzeb, działają online, nie mozna sobie "czegoś tam poprawić, bo ..." itd
- To może ktoś, coś w tym Excelu za pół darmo nam zrobi? Bo biurwa nie potrafi, albo inaczej, w okolicach końca miesiaca, mieli przez kilka dni Ctrl+C->Ctrl+V itd i całkiem słusznie szlag ją trafia, że ..., ..., ... jak długo jeszcze?
- Pojawia sie Expert :shock:

, dam radę, zrobię, dopasuję

I tutaj mój ogródek: korzystam ze wszystkiego co bogactwo Excela nam zaoferowało, czyli: VBA (prawie zawsze), PQ (bardzo często), PPivot (często)
I tak naprawdę, bez nawet czasami minimum, ale jednak skorzystanie z VBA, nie ma jak, nie ma mowy o napisaniu nawet prostej aplikacji, po prostu wymogi klienta, zasady bezpieczeństwa, sens działania całości, bez VBA, jak bez ręki :tak

Ale, ale -> jak już to cholerne VBA to, qwa -> qpa extra pracy, której nikt nie widzi, nie doceni, nie chce za to zapłacić, "człek" zostaje frejerem, bo pisze, pisze i nikt, nic z tego niby nie ma.
I tutaj jest miejsce na moje uwagi odnośnie tematu "VBA vs Power Query". Współpracy praktycznie nie ma. To jest dramat.
VBA jedzie kodem w mikrosekundach "komenda za komendą", a tymczasem PQ sobie w tym czasie swoje "mieli" i robi to na ogół dłuuuuugo, w całych sekundach i to w sposób, nie do oszacowania. Wystarczy, że PQ odwołuje się dodanych w jakiejś tam chmurze i mamy "słaby internet" -> koniec aplikacji! Dramat.
Z drugiej strony PQ daje takie możliwości, zwłaszcza dla prostego programisty (czyli dla mnie), że jestem w stanie wyklikać z jego pomocą małe cuda :clap

I będe z tego korzystał, bo to działa i co ważne, jest dla mnie proste do napisania (jak napisał mm -> drag and drop).
Jestem gorącym zwolennikiem stosowania PQ, ale na potrzeby rozwiązywania lekko wiekszych problemów -> no way, VBA musi być

No i jeszcze na koniec uwag -> Power Pivot -> jak dla mnie fantazja, pole do popisu, praktycznie niemal nikt z tego nie korzysta, co w miarę zrozumiałe, bo to trudne, unikalne, nauka DAX to duże wyzwanie, ale na koniec raporty, to już poezja.
To już jest prawdziwy segment Power BI, ale jak się napisze w tym "aplikację", dostępną "na biurku biurwy", to pojawia się petarda. W pełni interaktywne raportowanie z wielomilionowych (rekordów) baz danych, ale w Excelu.
Reasumując
- Kocham PQ za system dla prostego programisty -> drag-drop :shock:

, jakby coś nie działało, to koledzy z forum w języku M pomogą
- Bez VBA niemal nie ma mowy o aplikacjach "na zlecenie"
- raportowanie, czyli efekt analizy danych -> jak zleceniodawca korzysta z SAP-a (itp), bez tego co powyżej + Power Pivot może być słabe

Czyli potwierdzam i zgadzam się z opinią autorem wątka o Power Query i rolą VBA w programowaniu Excela.

Uff
p.s. kilku zdań autora nie "kumam" :mrgreen:

, ale to już mój skromny przywilej dziadka

master_mix · Wysłany: 21-11-2023, 23:34

Quasi · Wysłany: 31-01-2024, 15:10

Ja też dodam kilka przemyśleń z własnego podwórka :-)

.

Z nauką PQ zwlekałem dość długo, dopiero pod koniec 2022r. ogarnąłem temat - głównie dzięki świetnemu kursowi Piotra Czujaka. PQ bardzo mnie wciągnęło, wiedziałem, że usprawni ono proces ETL w moich aplikacjach. Ale....

W lutym 2023r. podbiła do mnie duża fundacja z prośbą o utworzenie narzędzia do rozksięgowania wpłat z 1.5% podatku. Robótka typowo techniczna - obróbka danych z wieloma pułapkami. Plik CSV z Urzędu Skarbowego (9 kolumn i ... 315 000 wierszy, bo tyle było wpłat)... Te wpłaty trzeba zawsze przypisać na odpowiednie subkonta dzieci (ok. 4 000 Podopiecznych).

Pierwszą rzeczą, za którą się wziąłem było opracowanie mechanizmu, który oczyści mi oryginalne dane (kolumnę gdzie powinien być numer, imię i nazwisko dziecka). Potrzebowałem podmienić ok. 5 000 fraz w tych wszystkich 315 000 celach... Najpierw spróbowałem rozwiązania PQ, ale .... muliło to tak strasznie, że szybko odpuściłem. Potem napisałem funkcję VBA, ale jej przeliczanie w arkuszu to znowu był koszmar. Temat ogarnąłem przetwarzając dane w tablicach VBA, co zajęło niecałe 2min....

Przy przetwarzaniu dużej liczby danych, zaczynamy już widzieć mankamenty PQ (szybkość!). Swego czasu Wojciech Gardziński nawet dowodził, że MS Query w wielu przypadkach jest 10x szybsze od PQ.

Z drugiej strony istnieje ogrom dobrodziejstw - odczytywanie danych z PDF, łatwa konsolidacja danych z wielu folderów/plików, odpiwotowanie danych itp. Największe wrażenie zrobił na mnie sposób pobierania kursów walut z tego filmu :danke

-> https://www.youtube.com/watch?v=lsE5BQNeG3E

Reasumując. Każdy będzie bronił swojej technologii, na której zarabia. To jest OK. Mi się nie podoba, że sporo firm buduje swój marketing negując inne narzędzia. Musi być wróg (zwykle EXCEL lub VBA) i wybawiciel (nasz produkt LOW CODE). Ja dość mocno walczę z takimi krzywdzącymi stereotypami na LinkedInie i pisząc artykuły na swojej stronie ;-)

.

Pozdrawiam!

master_mix · Wysłany: 03-02-2024, 02:11

DwaNiedźwiedzie · Wysłany: 04-03-2024, 19:32

@master_mix

W najmniejszym stopniu nie sugerowałem nawet (bo to chyba do mnie kierujesz te zarzuty), że VBA jest do bani. Stwierdziłem jedynie fakt, że jest NIEPRZYSTOSOWANY do przetwarzania danych strukturalnych. Nie, że nie potrafi, nie, że nie zrobi tego szybko, tylko że natywnie nie wspiera takiej obróbki. Sortowanie, filtrowanie, łączenie? Owszem, ale wyłącznie pętlami, przerzucaniem danych przez tablice tymczasowe czy korzystając z funkcji arkuszowych (!) - czyli w dość specyficzny i nierzadko zagmatwany sposób.

Zarzucanie językowi M "low code'owości" jest równie chybionym argumentem, co twierdzenie, że SQL jest prostacki, bo większość rzeczy robi się przez "select * from tabela" plus jakieś ewentualne where. Jak najbardziej w PQ da się zrobić proste rzeczy prostym klikaniem po menu, ale - do czego chyba sam powoli dochodzisz - zagłębiając się nieco bardziej w strukturę jego języka, da się w nim zdziałać cuda. Tak, daleko mu do wydajnego działania, nad czym sam głęboko ubolewam, ale pamiętajmy o jednym: to nie jest narzędzie bazodanowe, tylko mały kombajnik do końcowej obróbki danych. To jak z thermomixem - w domu uprości gotowanie, ale restauracji na tym nie zbudujesz.

Moim jedynym przytykiem w rzeczonym wątku było to, że stworzyłeś przekombinowane zapytanie, w którym próbowałeś odtworzyć algorytm z VBA, zupełnie nieprzystający do standardów PQ. To jakby robić to zadanie w VBA, ale z poziomu arkusza, przeciągając dane ręcznie między komórkami, nagrywając z tego makro i narzekać, że jest skomplikowanie, wolno i w dodatku obraz miga. Rozumiem i pochwalam chęć eksperymentowania, ale wrzucanie takiego - wybacz - Frankensteina i sugerowanie, że PQ ssie, moim skromnym zdaniem jest ciosem poniżej pasa. To narzędzie ma w zanadrzu sporo sztuczek optymalizacyjnych, które potrafią mocno ograniczyć zajmujący proces wpatrywania się w pasek postępu. I tak, VBA w większości przypadków pewnie będzie wydajniejszy (choć kilka takich pojedynków wykazało, że często ocieramy się o ułamki sekund), ale nawet do prostych przekształceń potrzebujemy tu już nieco wyższej znajomości tego języka, podczas gdy w PQ zadanie może wymagać jedynie poklikania po menu. I nie, nie jest to objaw złego low code, tylko tego, że to narzędzie wąskiej specjalizacji, a co za tym idzie ma spory wachlarz funkcji dedykowanych jego domenie. Ot, cała filozofia.

PS: VBA to ten język do odświeżania zapytań PQ? :D

master_mix · Wysłany: 04-03-2024, 23:25

Nie odbieraj tego tak personalnie ;-)

Postawisz w maju flaszkę, albo ja Tobie i będzie git :-D

No cóż, ten wątek akurat miał na celu bardziej dywagacje na temat platform Low Code,
czego jak najbardziej przykładem jest między innymi samo narzędzie PQ. W pakiecie o365 mamy też PowerApps z językiem FX,
czy PowerAutomate ze swoimi łącznikami które komunikują się ze swoimi środowiskami na zasadzie wiadomości
- takie programowanie obiektowe (z gotowymi obiektami) w dużym stopniu oparte na zasadzie przeciągnij upuść -
i językiem funkcyjnym dla Azure Logic Apps.
Same narzędzia są niskokodowe, ale i tak naprawdę trzeba bawić się "ich tworami językowymi" żeby jakiś większy sensowny projekt zbudować.