Excel Forum - Porady, Pomoc,  Excel Help, Excel FAQ Strona Główna
 FAQ  RegulaminRegulamin  Szukaj   Użytkownicy   Grupy   Rejestracja   Profil   Twoje wiadomości   Zaloguj 


Poprzedni temat «» Następny temat
ID tematu: 75247 Skopiuj do schowka Low Code - przemyślenia i kontynuacja wątku z PQ
Autor Wiadomość
master_mix 
Excel Expert



Wersja: Win Office 365
Pomógł: 1292 razy
Posty: 2625
Wysłany: 21-11-2023, 16:46   Low Code - przemyślenia i kontynuacja wątku z PQ

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.
_________________

Podejmę współpracę (pracę)
Programowanie C#, Android, iOS, VB.NET, VBA, ASP.NET Core, WPF, Xamarin, Power Platforms, XAML, MVC, LINQ, Entity Framework. Bazy danych SQL Server, Oracle, MySQL, Firebird
Wrocław i okolice …lub zdalnie.
ID posta: 431402 Skopiuj do schowka
 
 
bodek 


Wersja: Win Office 2019
Pomógł: 1078 razy
Posty: 3183
Wysłany: 21-11-2023, 21:44   

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
ID posta: 431417 Skopiuj do schowka
 
 
master_mix 
Excel Expert



Wersja: Win Office 365
Pomógł: 1292 razy
Posty: 2625
Wysłany: 21-11-2023, 23:34   

bodek napisał/a:
Excela każda biurwa "dobrze lub nawet b. dobrze zna" -> nie, nie ma o nim nawet mglistego pojęcia

Smutna prawda, która nic a nic się od lat nie zmienia a nawet nie wiem czy nie pogłębia.
Spotkałem się nawet z przypadkami, że ktoś w organizacji posiadał umiejętność nagrywania makr i starał się mnie przekonać że programuje w VBA.
I wlaśnie w tym kierunku zmierza Low Code.

bodek napisał/a:
To może ktoś, coś w tym Excelu za pół darmo nam zrobi?

No własnie i tu jak dobrze wszyscy wiemy bez wsparcia (jak pisał bodek) VBA się raczej nie obejdzie :)

A chęć "pół darmo" często wynika z faktu że działy IT są mocno okrojone w organizacjach i brakuje specjalistów.
Dodatkowo działy IT, nie chcą się bawić w zaspakajanie potrzeb użytkowników i spuszczają ich na drzewo jak przychodzą z jakimś problemem czy prośbą usprawnienia czegokolwiek.
Z jednej strony ich rozumiem, sam jestem szefem takiego zespołu i wiem że przy okrojonym składzie osobowym nie jest to możliwe - szybko, na już i każdemu coś innego.
A cała wina w polityce potęg Microsoft, Google, Oracle itp , które marketingiem przekonują managerów, prezesów, że specjaliści nie są potrzebni,
że użytkownicy sami mogą wszystko zrobić narzędziami jakie można od nich kupić, narzędzia są łatwe i proste, a utrzymywanie działów IT,
lokalnych serwerów, wirtualizacji nie ma sensu, bo po co płacić specjalistą, przecież można im zapłacić, oni o wszystko zadbają, no i wciskają kit że duuużo taniej :D
I jak wdrażamy czy próbujemy rozwijać jakieś rozwiazania z omawianych firm, oświadczamy że jeszcze trzeba co jakiś czas dokupić jakieś dodatkowe licencje, zasoby, za niemało $
to management team wielkie oczy robi.

bodek napisał/a:
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.

Smutna prawda, a Low Code też to pogłębi.

Tak czy siak, wykorzystując omawiane narzędzia, wiedza, umiejętności są potrzebne a nikt z userów nie jest zainteresowany,
żeby zgłębić i zrozumieć cokolwiek bardziej niż pasek z wypłaty.Dodatkowo niepowodzenia najlepiej zrzucić na IT, a na koniec podsunąć myśl o zatrudnieniu na zlecenie bodka
który za pomocą VBA, PP i uroku osobistego oczaruje Panie ;-) I tak jak piszesz, dodatkowo za "frajer", bo się ponoć nie napracujesz :niee ... :D

Zgadzam się z bodkiem i wyraźnie to wcześniej pisałem że silnik PQ, powerBI i PP, i nterfejs tych narzędzi jest genialną sprawą, ułatwiającą i przyśpieszającą pracę z raportowaniem.
Ale wydajność NIE będzie rosła. A elastyczność uzyskają jak zdobędą interakcję ze żródłem danych (chodź nie sądzę) i ułatwiony dostęp do zasobów na lokalnych serwerach organizacji,
bo teraz to tragedia z konfiguracją i wydajnością bram.

p.s.
bodek napisał/a:
p.s. kilku zdań autora nie "kumam" , ale to już mój skromny przywilej dziadka

czego nie kumasz? :) no i sobie dziadki pogadały :mrgreen:
_________________

Podejmę współpracę (pracę)
Programowanie C#, Android, iOS, VB.NET, VBA, ASP.NET Core, WPF, Xamarin, Power Platforms, XAML, MVC, LINQ, Entity Framework. Bazy danych SQL Server, Oracle, MySQL, Firebird
Wrocław i okolice …lub zdalnie.
ID posta: 431424 Skopiuj do schowka
 
 
Quasi 
Excel Expert


Wersja: Win Office 365
Pomógł: 144 razy
Posty: 1116
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!
ID posta: 433196 Skopiuj do schowka
 
 
master_mix 
Excel Expert



Wersja: Win Office 365
Pomógł: 1292 razy
Posty: 2625
Wysłany: 03-02-2024, 02:11   

Quasi napisał/a:
Największe wrażenie zrobił na mnie sposób pobierania kursów walut z tego filmu


Mariusz, NBP ma pięknie udokumentowane i szybkie web api
https://api.nbp.pl/
I tu masz elastyczność we wszystkich kierunkach, no i szybkość
_________________

Podejmę współpracę (pracę)
Programowanie C#, Android, iOS, VB.NET, VBA, ASP.NET Core, WPF, Xamarin, Power Platforms, XAML, MVC, LINQ, Entity Framework. Bazy danych SQL Server, Oracle, MySQL, Firebird
Wrocław i okolice …lub zdalnie.
ID posta: 433255 Skopiuj do schowka
 
 
DwaNiedźwiedzie 
Excel Expert



Wersja: Win Office 2016
Pomógł: 328 razy
Posty: 827
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
ID posta: 434019 Skopiuj do schowka
 
 
master_mix 
Excel Expert



Wersja: Win Office 365
Pomógł: 1292 razy
Posty: 2625
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ć.

DwaNiedźwiedzie napisał/a:
W najmniejszym stopniu nie sugerowałem nawet (bo to chyba do mnie kierujesz te zarzuty), że VBA jest do bani

W tamtym wątku to było bardziej do B.SZ:
Bill Szysz napisał/a:
no ale z tą elastycznością i wydajnością to już "ciut" jednak przesadziłeś chyba

Z czym się nie zgadzam i w tamtym wątku zaprotestowałem ;)

DwaNiedźwiedzie napisał/a:
zagłębiając się nieco bardziej w strukturę jego języka, da się w nim zdziałać cuda.

Co do samego języka M:
Powiedziałbym-> można zdziałać więcej, ale nie cuda. Nie twierdzę że w VBA mamy cuda, ale na pewno więcej możliwości.
Język M, to taka pochodna wersja języka F# z platformy .Net , który raczej się nie przyjął,
choć gdzieś czytałem że programowanie funkcyjne wraca do łask i mody.
Zresztą sam język M to tylko komunikacja z serwisem ETL poprzez warstwę architektury mashupu, który to PQ ma własny.
Nie sądzę żeby był tak dopracowany (chodź mogę się mylić) jak ETL który ma np SQL Server czy Apache.

Nie porównywałbym M do SQL, bo to inne środowiska są i inne poziomy działania. No i SQL to nie tylko język zapytań jak M.
SQL pozwala na bezpośrednią interakcję z bazą , nie korzysta z ETL, ETL korzysta z SQL i później przetwarza dane.
To co napiszesz w M, później PQ tłumaczy na SQL -> o ile to baza danych, a następnie
działanie ETL (w skrócie, bo sam mechanizm jest rozbudowany):
-pobiera dane (korzysta z sql)
-transformacja danych (agregacja, modyfikowanie itp)
-ładowanie w systemie docelowym
Stąd też i ETL są pamięciożerne i wolniejsze od bezpośredniej komunikacji z bazą przez SQL,
bo gromadzą dane, przetwarzają, partycjonują, mieszają itp.
A że ETL w PQ korzysta z zasobów klienta a nie tylko serwera jak w przypadku Apache czy SQL Server,
przy bardziej skomplikowanym projekcie muli jak mnie po dobrej imprezie ;)

p.s.
Ten przykład "Frankensteina", to tylko było skierowane do Darka, tak jak napisałem:
"Rozważanie czysto teoretyczne" - zabawa w translator, nie mająca na celu umniejszanie zalet językowych M.
_________________

Podejmę współpracę (pracę)
Programowanie C#, Android, iOS, VB.NET, VBA, ASP.NET Core, WPF, Xamarin, Power Platforms, XAML, MVC, LINQ, Entity Framework. Bazy danych SQL Server, Oracle, MySQL, Firebird
Wrocław i okolice …lub zdalnie.
ID posta: 434023 Skopiuj do schowka
 
 
Wyświetl posty z ostatnich:   
Odpowiedz do tematu
Nie możesz pisać nowych tematów
Nie możesz odpowiadać w tematach
Nie możesz zmieniać swoich postów
Nie możesz usuwać swoich postów
Nie możesz głosować w ankietach
Nie możesz załączać plików na tym forum
Możesz ściągać załączniki na tym forum
Dodaj temat do Ulubionych
Wersja do druku

Skocz do:  

Powered by phpBB modified by Przemo © 2003 phpBB Group
Theme xandgreen created by spleen& Programosy modified v0.3 by warna
Opieka techniczna www.wip.pl

Archiwum

Strona uĹźywa plikĂłw cookies.

Kliknij tutaj, żeby dowiedzieć się jaki jest cel używania cookies oraz jak zmienić ustawienia cookie w przegl�darce.
Korzystając ze strony użytkownik wyraża zgodę na używanie plików cookies, zgodnie z bieżącymi ustawieniami przeglądarki.
SprawdĹş, w jaki sposĂłb przetwarzamy dane osobowe