Grzegorz Fałda grzegorzfalda@gmail.com 602-44-59-81 03.06.2014 Narzędzia Rapid Application Development (RAD) dla bazodanowych aplikacji www czyli: co.

Prezentacja na temat: "Grzegorz Fałda grzegorzfalda@gmail.com 602-44-59-81 03.06.2014 Narzędzia Rapid Application Development (RAD) dla bazodanowych aplikacji www czyli: co."— Zapis prezentacji:

1 Grzegorz Fałda grzegorzfalda@gmail.com 602-44-59-81 03.06.2014
Narzędzia Rapid Application Development (RAD) dla bazodanowych aplikacji www czyli: co nam zostało z tamtych RAD? (tych z lat 90-tych) Grzegorz Fałda

2 Pomysł Stworzyć prototyp narzędzia programistycznego do
tworzenia aplikacji webowych, które by w znacznym stopniu wykorzystywało podejście RAD (Rapid Application Develpoment) Myślę, że jest tu wiele do zrobienia. Co to jest RAD? Wikipedia: Szybkie tworzenie aplikacji. Jest to ideologia i technologia polegająca na udostępnieniu programiście dużych możliwości prototypowania oraz dużego zestawu gotowych komponentów (np. zapewniających dostęp do bazy danych).

3 RAD, 4GL Aplikacje desktop: Od lat 80-tych.
Przykład: Clarion – od roku DOS, potem Windows. 1) Struktura bazy danych jest fundamentem dla aplikacji. 2) Używa szblonów (templates). Szablony są pisane w specjalnym, dedykowanym języku (template language), który jest również dostępny dla bardziej zaawansowanych programistów. 3) Typowa funkcjonalność jest specyfikowana przez programistę interakcyjnie (formatki). 4) Dalsza funcjonalność jest pisana w finalnym języku programowania (tu: język 4GL Clarion) w postaci wstawek (embeds) – szablony definiują miejsca, gdzie można dodać kod. 5) Kod szablonu nadzoruje generację finalnego kodu (na podstawie 3) i 4) ), który jest potem kompilowany. 6) Dodatkową pomoc stanowią min:. Wizardy – do tworzenia typowych kontrolek, list przewijalnych, menu, formatek, a nawet całych aplikacji. Adnotacje przy strukturze bazy danych.

4 Podstawowa cecha Clariona
Napisany przez programistę kod nigdy nie ginie, nie jest przykrywany podczas kolejnych iteracji automatycznej generacji kodu. Doświadczenia programisty – praktyka: To naprawdę działa (w określonym obszarze zastosowań – typowe aplikacje biznesowe) Jak to jest możliwe: Szablony są umiejętnie napisane i oferują wiele miejsc w których można wpisać kod ręcznie.

5 Istnieją inne podejścia do RAD
Na przykładzie narzędzia Magic Developer (obecnie uniPaaS) Inna technologia, podobne efekty. Magic posiada silnik uruchamiany na różnych platformach i działający z różnymi bazami danych. Programista określa logikę biznesową parametryzując ten silnik (wypełniając specyficzne tabele). Kodu się nie pisze i „program” w Magicu w ogóle nie ma postaci podobnej do tekstowego kodu. Inne narzędzia RAD: Oracle Forms, Delphi, Power Builder…

6 Lawina nowych technologii albo: Co nam zostało z tamtych RAD?
Od połowy lat 90-tych World Wide Web: HTML, CSS … W nowym tysiącleciu Technologie mobilne Oferują przede wszystkim zupełnie inną filozofię interfejsów użytkownika. Skutek: Kryzys narzędzi RAD. RAD jest dalej potrzebny, ale chyba nie nadąża za nowymi, powstającymi i ewoluującymi technologiami.

7 Jakie cechy powinno mieć współczesne narzędzie RAD
Jakie cechy powinno mieć współczesne narzędzie RAD? Oto niektóre typowe oczekiwania użytkowników końcowych i programistów Programiści Narzędzie powinno być łatwe do nauczenia. Powinno być wydajne. Powinno adresować wiele platform z poziomu tego samego kodu. Chciałbym używać mojego preferowanego języka programowania. A ostatecznie – jakiegoś popularnego języka programowania. Narzędzie powinno być zgodne ze standardami. Zdobywając wiedzę o nowych narzędziach, programiści Używają przede wszystkim Internetu. Są ciekawi. Są niecierpliwi (przecież jest tyle innych narzędzi…). A więc: Ewaluacja narzędzia powinna być szybka i łatwa. A więc najchętniej: Bez rejestracji. Bez instalacji. Z dobrym samouczkiem. Możliwość stworzenia szybkiego prototypu aplikacji o którą mi chodzi. Użytkownicy Aplikacje powinny powstawać szybko. Powinny być wieloplatformowe, działać na różnych urządzeniach. Powinny mieć intuicyjny interfejs. Powinny być stabilne. Powinny działać szybko. Opóźnienia typowe przy działaniu aplikacji przeglądarkowych są do zaakceptowania. Więcej …

8 Proponuję, aby przedsięwzięcie koncentrowało się na
Aplikacjach bazodanowych dla platformy Web z rozbudowanym ale typowym interfejsem użytkownika (domena RAD). Duża ilość potencjalnych użytkowników końcowych i zainteresowanych programistów. Duży potencjał automatyzacji tworzenia aplikacji: Typowe powtarzające się zadania (CRUD). Typowe powtarzające się elementy: (formularze, listy, drzewa, raporty itd.). Wskazane byłby (w miarę możliwości) Wspomaganie różnych języków programowania. Wspomaganie różnych baz danych. Dlaczego aplikacje webowe? Web ma pewną przyszłość (przeglądarki nie wyginą). Ta sama aplikacja będzie działać (powinna działać) na różnych przeglądarkach, co umożliwia uruchomienie tej samej aplikacji na różnych platformach przy względnie niewielkim wysiłku. Aby przedsięzwzięcie uczynić bardziej realnym proponuję wziąć jakiś popularny framework i dodać do niego cechy RAD (może to się dziać stopniowo!). W dalszej przyszłości można by było wspierać więcej jak jeden framework w zunifikowany sposób.

9 Proponowane technologie 1/3
Popularne języki programowania: Java, JVM (inne języki?), C#, Visual Basic, PHP, Ruby, Python, inne … Proponuję: Generator kodu (choć to nie jedyne podejście do RAD) Specyfikacja aplikacji jest przechowywana w repozytorium, które zawiera: strukturę bazy danych, specyfikację UI, kod wstawek (code embeds), wszystko inne. Repozytorium jest edytowane przez programistę za pomocą interakcyjnego (prawdopodobnie okienkowego) środowiska. Typowa funkcjonalność (UI, być może więcej) jest tworzona interakcyjne za pomocą szablonów (programista wypełnia formularze). Kod jest generowany automatycznie. Mniej typowa funkcjonalność jest kodowana ręcznie we wstawkach. Są one możliwe w wielu miejscach. OMG wspiera inicjatywę „Code generation”.

10 Proponowane technologie 2/3 Zalety generatora kodu
Wydaje się być dobry do celów edukacyjnych – tworzenie działających prototypów bez kodowania. Debugowanie może odbywać się w sposób jednolity, ponieważ cały kod (ten generowany i ten pisany ręcznie) jest w tym samym języku programowania, nie ma niewidocznych dla debuggera fragmentów kodu Szablony są (do pewnego stopnia) wytestowane. W przypadku braku dalszego rozwoju narzędzia cały kod jest dalej dostępny i może być dalej rozwijany. Podejście to (razem z „podłączeniem się” pod jakiś popularny framework) wydaje się być adekwatne do stworzenia małego, ale już przydatnego w praktyce prototypu. Na początku można by było skoncentrować się tylko na jednej typowej funkcjonalności, a potem dodawać nowe. Narzędzie powstałoby na razie dla jednego języka docelowego, ale miałoby potencjał rozszerzenia do innych języków/frameworków już z użyciem tego samego środowiska programistycznego.

11 W dalszej perspektywie
Nasze narzędzie Java ASP.Net Python Nowa technolo-gia X 2018 Nowa technolo-gia Y 2022

12 Proponowane technologie 3/3
Inne możliwe rozwiązania – mam wątpliwości: Ukryte biblioteki – niepełny debugging. Generacja bytecode – co z debuggingiem? Generacja finalnego kodu z kodu tekstowego wydaje się być trudniejsza do implementacji – parser, edytor kontekstowy, wydaje się być trudniejsza i mniej intuicyjna w użyciu niż praca z formatkami, wymaga nauczenia się nowego języka (nie tylko nowego środowiska). Stworzyć nowy język programowania? – myślę, że nie Potencjalnie daje największe możliwości, ale: Trudne i czasochłonne do implementacji. Trudności z wypromowaniem nowego języka. Wymaga od użytkowników nauczenia się nowego języka (nie tylko nowego środowiska). Platformy uruchomieniowe (jak np. Microsoft Silverlight) – raczej nie – kłopotliwe dla użytkowników. Rich Internet Apps (RIA) – tak! Scaffolding – tak! To (typowa dla dawnych narzędzi RAD), pochodząca z Ruby on Rails technika automatycznego tworzenia typowej funkcjonalności – głównie CRUD. Odpowiedź: To nam zostało z tamtych RAD.

13 Na jakim frameworku się oprzeć?
Oczywiście open source Jeśli Java, to jest duży wybór: GWT - Google Web Toolkit Vaadin (!) – rozszerzenie GWT Eclipse RAP – Remote Application Platform Spring MVC Grails – język Groovy, podobny do Java, bazuje na Ruby on Rails Dobre porównanie: Inne języki (…)

14 Pomysł na prezentację w sieci Jak najprostszy i jak najszybszy dostęp dla ewaluatora
Interfejs Web Nasz serwer Strona Web (używana przez przeglądarkę na dużym ekranie) Interfejs typu „wizard” 1) Samouczek – przykładowa aplikacja 2) Możliwość stworzenia własnego prototypu Repozytorium, narzędzie Programista, oceniający 1. Bez rejestracji Bez instalacji Bez płatności Aplikacje Web o tej samej funkcjonalności, optymalizowane dla różnych urządzeń i wielkości ekranów 2. linki 3. Urządzenia Idea: Można by było niewielkim nakładem pracy stworzyć stronę www, która symuluje powyższą koncepcję – w celu prezentacji dla potencjalnych partnerów, uczestników.

15 Jak to ma działać? Użytkownik / programista edytuje repozytorium na naszym serwerze. Następnie uruchamia generator na serwerze, który generuje kod Java (?). Następuje automatyczna kompilacja. Następuje generacja powstałych w ten sposób stron www, zostaną utworzone puste bazy danych wg. żądanej struktury itd. Odpowiednie linki są tworzone i wyświetlane użytkownikowi. Łatwo można uzyskać cechy wersji demo: Linki mogą przestać działać po pewnym czasie. Natomiast pełne narzędzie byłoby raczej typu desktop.

16 Dziękuję za uwagę zapraszam do dyskusji
Grzegorz Fałda