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
6
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.
2
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.
3
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.
1
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 :)
4
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.
3
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
0
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.
2
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.