Nie jestem typowym programistą, obecnie zajmuję się Mulesoftem(jako architekt, który także dewlopuje), który jest własnie trochę takim low-codem, siedze w korpo i pewnie dalej będę siedzieć, bo korpo tak ryje banie, przyzwyczaja do wygody, że do inngo typu roboty już raczej nie podejde :)
Ostatnio dostałem propozycje rozwijania sie w Outsystems. Co o tym myslicie i czy low-code to jest coś, co ma przyszłośc? Na pierwszy rzut oka, przypomina mi to koncepcje Mula, gdzie można być architektem, deweloperem i analitykiem bo sam Mulesoft upraszcza mocno życie i proste API, można ogarnąć w jeden dzień, jak już znamy wymagania.
0
7
Nie widzę tego. Wszystkie low code jakie widziałem polegały na tym, że proste rzeczy robi się prosto a trudne jeszcze trudniej i musi przyjść developer, który zrobi tak jak trzeba
Oczywiście sam pomysł będzie się pojawiał, bo menagment chce oszczędzić koszty nie wiedząć na czym polega software development t, że problem nie jest w pisaniu logiki tylko jej utrzymywaniu
1
No to teraz zaproponowałbym pomyśleć, jak by wyglądała migracja tego wszystkiego na inną platformę. No i żeby dwa razy nie pisać, co się stanie z takim kontraktorem, gdy firma decyduje się na zmianę platformy, a kontraktor zna tylko, gdzie klikać w tej starej.
3
DarkoZZZ napisał(a):
Co o tym myslicie i czy low-code to jest coś, co ma przyszłośc?
Myślę, że błędem jest myślenie o low-code jako o "przyszłości". To pewna nisza istniejąca od dekad i apki low code (i no code) mają swoje specyficzne zastosowania. Ludzie chcą zrobić grę, to sięgają po Unity, chcą coś wyliczyć, to sięgają po Excela. Jak chcą zrobić stronkę internetową to mają Wix itp. i jeszcze trochę innych popularnych i masa mniej popularnych.
Myślę, że jak ktoś chce zajmować się tym na etacie, to warto uderzać w popularne rozwiązania, żeby móc przenieść tę wiedzę, zamiast uczyć się czegoś, co jest używane w jednej firmie.
Chociaż niektórzy to raczej robią tak, że się uczą tych apek low-code, a potem idą na freelance (więc sami mogą wybrać, że używają tego narzędzia, w którym są dobrzy). Ew. używają narzędzi low-code, żeby szybko zrobić swój startup. Albo robią szkolenia/kursy z low-code. Albo tworzą własne narzędzie low-code. Tak się chyba na tym zarabia.
5
Low-code to jest mit, nigdzie to nie działa tak jakie to ma założenia. Choć przyznam ładnie to wygląda na slajdach prezentowanych przez marketing.
1
Ciężko powiedzieć, trochę zależy jak sie bedzie rozwijać Ai w tym obszarze. Coś w rodzaju no code mocno się rozpycha w obszarze data od lat.
3
Pracowałem w low code swojego czasu, jakoś okolice 2019r. Na tamten moment miał być to wielki przełom w ówczesnej przyszłości. Miało być mnóstwo pracy i pieniędzy. Pomijam już fakt, że bardziej ambitne rzeczy wymagały i tak dopisania ręcznej wtyczki używając języka programowania (js, python, c#). A tutaj nie ma ani przełomu, ani pracy a tym bardziej pieniędzy :)
5
Low code i no code powstały po to, żeby wydrenować pieniądze z korporacji, pod przykyrwką oszczędności. (change my mind)
Czyli masz szansę trafić w niszę, mieć w niej doświadczenie i zarabiać świetne pięniądze, nooooooo, albo żadne, jak utrzymanie potworka już się skończy.
4
Też, ale przede wszystkim założenie miało być takie, że byle cymbał bez wiedzy technicznej miał tworzyć względnie sensowną automatyzacje we względnie sensownym czasie. W praktyce, taka pani z banku miała sobie zautomatyzować proces przeklikiwania wniosków kredytowych, które wcześniej musiała przerabiać manualnie. Jakież to było zdziwienie, kiedy nawet przesuwanie bloczków w subskrybowanym narzędziu (Drogim) wymagało tej mitycznej wiedzy technicznej + tak jak napisałem wyżej - Dopisanie czegoś sensownego i tak wymagało customowych wtyczek.
W moim przypadku była to właśnie praca w banku i automatyzowanie takich procesów. W krótkim czasie większość rzeczy i tak oyebywałem js'em, bo było to znacznie szybsze niż te gotowe bloczki. Mam też info, że krótko po moim odejściu, bank zrezygnował z tych narzędzi low code, bo jak się finalnie okazało, zatrudnienie programisty + napisanie automatyzacji w chociażby takim selenium, jest tańsze i pewniejsze w utrzymaniu.
1
A to nie jest tak, że w low-code jesteś “gwiazdą jednego toola”? Średnia dywersyfikacja, nie mówiąc już o rozwoju
1
DarkoZZZ napisał(a):
Nie jestem typowym programistą, obecnie zajmuję się Mulesoftem(jako architekt, który także dewlopuje), który jest własnie trochę takim low-codem, siedze w korpo i pewnie dalej będę siedzieć, bo korpo tak ryje banie, przyzwyczaja do wygody, że do inngo typu roboty już raczej nie podejde :)
jakim cudem jesteś architektem nie wiedząc nic o programowania? Bo jak byś wiedział to byś nie pisał takich głupot o low-code
Ostatnio dostałem propozycje rozwijania sie w Outsystems. Co o tym myslicie i czy low-code to jest coś, co ma przyszłośc? Na pierwszy rzut oka, przypomina mi to koncepcje Mula, gdzie można być architektem, deweloperem i analitykiem bo sam Mulesoft upraszcza mocno życie i proste API, można ogarnąć w jeden dzień, jak już znamy wymagania.
jedno słowo :Delphi
0
Miang napisał(a):
DarkoZZZ napisał(a):
Nie jestem typowym programistą, obecnie zajmuję się Mulesoftem(jako architekt, który także dewlopuje), który jest własnie trochę takim low-codem, siedze w korpo i pewnie dalej będę siedzieć, bo korpo tak ryje banie, przyzwyczaja do wygody, że do inngo typu roboty już raczej nie podejde :)
jakim cudem jesteś architektem nie wiedząc nic o programowania? Bo jak byś wiedział to byś nie pisał takich głupot o low-code
Architekt architektowi architektem :)
Prawda jest taka że im lepszy (droższy) architekt tym mniej musi wiedzieć o kodzie.
Główna robota to kwadraciki, strzałki, ppt i spotkania z zarządem :D
Myślę że w Mule może być podobnie: mało kodu, dużo klikania, a grunt to pilnować co z czym się łączy ;P
Jasne że im większa wiedza, tym lepiej.
Natomiast 99% pracy to pewnie łączenie przez konektory SAP, Salesforce i co tam jeszcze firma ma.
3
W teorii do Mule nie potrzeba wiedzy z programowania, ale z mojego doświadczenia najlepiej pracowało mi się z ludźmi, którzy też posiadali wiedzę o tym jak napisać logikę w Apexie po stronie Salesforce, czy chociaż znali podstawy ABAPa w SAPie, bez tego było za dużo przepychanek.
Salesforcowy no-code to też straszna kupa, bo problemem moim zdaniem nie jest konieczność poznania składni języka, ale umiejętne połączenie swojego rozwiązania z tym co już istnieje (zarządzanie złożonością logiki biznesowej, utrzymywalność itd) i nie widzę tu jakiegokolwiek "uproszczenia", takie dajmy na to Flow pozwala adminowi wyklikanie klocków, które nawet prostym procesem są w stanie położyć istniejącą logikę, bo taki admin nie zawsze pomyśli, czy jego "prosty" update na rekordach nie spowoduje kaskadowych/zapętlonych zmian w innych miejscach i weź potem debuguj takie g**no bez jakiejkolwiek standaryzacji czy testów.
0
Akurat jeśli chodzi o Mule, to ludzie bez backgroundu programistycznego lepiej się sprawdzają nawet jako deweloperzy Mula. Sporo projektów zostało spie...nych przez deweloperów Javy po przeszkoleniu, którzy doświadczenie z Javy chcieli przełożyć na Mula. Mi zawsze w Mule lepiej się pracowało z ludzmi którzy wcześniej byli analitykami integracji, analitykami biznesowymi, niż hardcorowymi devami :)
3
TheBirthus napisał(a):
Myślę że w Mule może być podobnie: mało kodu, dużo klikania, a grunt to pilnować co z czym się łączy ;P
Akurat to nie jest prawda. Robiliśmy proste PoC z Mulesoftem w roli głównej, żeby udowodnić enterprajs architektom że Mulesoft i te całe ich connectory to g**no i bez programowania w DataWeave (język programowania w Mulesoft) za wiele nie da się zrobić.
Case był teoretycznie prosty - zrobić dump danych i jego schematu z zewnętrznej aplikacji typu SaaS do lokalnej bazy relacyjnej po API i udostępnić te dane dalej w różnych formatach. Żeby było łatwiej SaaS udostępniał endpoint z opisem każdego obiektu (pola, typy) na podstawie którego można było utworzyć tabele w lokalnej bazie danych i do nich załadować konkretne dane.
To co wydawało się dla EA prostym case'm (dump danych) okazało się być praktycznie niemożliwe do zrealizowania za pomocą domyślnego connectora do API wspomnianego SaaS (brak obsługi większości endpointów w tym tego z metadanymi każdego obiektu). Do tego logika której wyklikanie w GUI trwało dłużej niż napisanie prostego joba w Pythonie który zrobi to samo.
Konkluzja jest taka, że jak ktoś potrzebuje prostej integracji to drag&drop Mulesofta da radę. W przypadku bardziej złożonej logiki biznesowej trzeba pisać g**no kod w ich egzotycznym języku w środowisku którego IDE zamula niczym pierwsze wersje Eclipse czy NetBeans. A te ich connectory do Salesforce, SAP czy innych 3rd party to się nie nadają do niczego więcej niż prosty przykład typu hello world albo todo list
0
Nie uważam ze Mulesoft jest najlpeszym narzędziem na swiecie i do wszytkiego sie nadaje. Ale nie jest tez zły i dla wielu firm mógł być najlpeszym wyborem, szczególnie dla duzych korpo. na pewno nie sprawdziłby się w małych firmach, albo firmach softwerowych które Mula chaiłby wykorzystywac dla siebie, a nie jako usługę dla klienta. Obecnie przyszłosc Mule stoii tochę pod znakiem zapytania, bo Muelsoft/Salesforce, mocno chce zmienić ceny, zmieniając jednocześnie model licencyjny.
@markone_dev o co piszesz to jest zaleta. Datawave jest bardzo dobrym językiem do mappowania danych. Problememm może być dla kogos kto go nie zna i szególnie w Mule 3, wiele firm robiło kaszanę uzywając Javy, Grooviego zamiast DW. Główny problem Mule, jest to ze wydaje się prosty, ludzie go nie doceniają i zaczynając cos robić nie majac wiedzy, bo teoretycznie wszytko mozna wyklikać, ale tak nie jest. Każdy kto uważa, ze Mule jest narzedziem drag&drop, na pewno zawali projekt. Dla mnie Mule to jest wizualizacja procesu, wiec mogę szybko zrobić szkielet aplikacji a potem kończy się klikanie i trzeba skorzystać z klawiatury.
Dlaczego napisałem, ze jest dobry dla korpo? Ponieważ można łatwo oddzielic zespół supportowy od projektowego, łatwo mozna wejsć tez do starego projektu i prześledzić proces dzieki jego wizualizacji, nawet jak jakosc dokumentacji jest kiepska.
Czego nie lubię w Mule:
- na siłę promowanej filozofii trzech warstw, czesto potrzebne sa tylko dwie, a w niektórych wypadkach nawet jedna, jeżeli robimy cos nie-reuzywalnego
- nowy model licencyjny
- wysoki koszt vCora w starym modelu
Co do mojego pytania, to myślałem o platformach low-code i no-code jako takich odnośnikach Mula w integracji, ale po przeanalizowaniu tematu, stwierdziłem, że to będzie dla mnie strata czasu. Zamiast tego pójdę bardziej w jeden z cloudów - GCP albo Azure, bo tez takie propozyce dostałem w firmie.
2
DarkoZZZ napisał(a):
dla wielu firm mógł być najlpeszym wyborem, szczególnie dla duzych korpo.
Bo na koszt wdrożenia i utrzymania takiego kloca mogą sobie pozwolić tylko duże firmy.
DarkoZZZ napisał(a):
Datawave jest bardzo dobrym językiem do mappowania danych. Problememm może być dla kogos kto go nie zna i szególnie w Mule 3, wiele firm robiło kaszanę uzywając Javy, Grooviego zamiast DW
I to jest kolejny problem bo ludzi znających Dataweave jak i całą platformę jest garstka w porównaniu do ilości programistów Java czy Python.
DarkoZZZ napisał(a):
Dlaczego napisałem, ze jest dobry dla korpo? Ponieważ można łatwo oddzielic zespół supportowy od projektowego, łatwo mozna wejsć tez do starego projektu i prześledzić proces dzieki jego wizualizacji, nawet jak jakosc dokumentacji jest kiepska.
W teorii. W praktyce słyszałem te same argumenty przy wdrażaniu Talend lata temu i przy migracji z Talend do Mulesoft dwa lata temu i fiasku i zamknięciem tego projektu w tym roku bo Mulesoft się też nie sprawdził.
Co do wizualizacji procesu to nie jest to największym problemem. Największym problemem jest zrozumienie zaimplementowanej logiki biznesowej. Bez tej wiedzy dlaczego ktoś zrobił coś w ten a nie inny sposób nie ma możliwości na bezpieczną modyfikację kodu. A tu nie ma znaczenia czy piszemy w Java, Pythonie czy Mulesoftcie. Wszędzie jest tak samo.
DarkoZZZ napisał(a):
Co do mojego pytania, to myślałem o platformach low-code i no-code jako takich odnośnikach Mula w integracji, ale po przeanalizowaniu tematu, stwierdziłem, że to będzie dla mnie strata czasu. Zamiast tego pójdę bardziej w jeden z cloudów - GCP albo Azure, bo tez takie propozyce dostałem w firmie.
To jest słuszna droga.
1
Wpakowałem się 'przypadkiem' w LowCode więc się wypowiem :D
Jak dla mnie ma to narzędzie przyszłość i jest jakieś pole do popisu. Pracuje w korpo jest sporo projektów, coraz więcej innych działów zgłasza się, że potrzebują coś zautomatyzować. Prace mamy na +-3/4 lata. (O ile nie przyjdzie nowy szef i nie zaora tego narzędzia). Z racji, że jest spore parcie ludzi biorą z ulicy - 3 miesięczne szkolenie z lowcode i wchodzisz na projekt. Skutek jest taki, że muszę tłumaczyć jak działa pętla, tablica xD
Dodałem ostatnio info o platformie low-code na LinkedIn oferty jakie dostaje to widełki: 800-1200 zł/dzień.
Obecne zarobki to 18k brutto + KUP + premia roczna.
Ogólnie duża większość tego co robimy da się wyklinać przez bloczki. Do jakiś bardziej niestandardowych rzeczy piszemy logike w C# natomiast nie jest ona też zwykle skomplikowana, proste ify/warunki/pętle.
Jak to w korpo bywa tworzymy szybko procesy i wpuszczamy szybko na prod, PO ogłasza sukces wdrożenia a potem jest wyprowadzanie błędów.
Jak dla mnie jest i będzie to wdrażane ze względu na szybkość tworzenia w takich typu platformach - biznes zadowolony dostali szybko co chcieli, koszty mniejsze, ze względu na wykluczenie typowych programistów, a zatrudnieniu ludzi z ulicy którzy zadowoleni, że robią coś w IT. O utrzymanie to raczej na razie się nikt nie martwi ale tu już nie jest tak kolorowo, chociaż to już nie moje zmartwienie jak skończą się nowe projekty zawijasz się do innego pracodawcy/projektu aby nie robić utrzymania ;)