Grzegorz Fałda grzegorzfalda@gmail 602-44-59-81 03.06.2014

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

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 1986. 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? Oto niektóre typowe oczekiwaniaużytkowników końcowychi 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/3Zalety 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: http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/ Inne języki (…)

14. Pomysł na prezentację w sieciJak 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 grzegorzfalda@gmail.com 602-44-59-81