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

grzegorzfalda@gmail.com

602-44-59-81

03.06.2014 1

PomysłStworzyć prototyp narzędzia programistycznego do tworzenia aplikacji webowych, które by w znacznymstopniu 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).

2

RAD, 4GLAplikacje 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.

3

Podstawowa cecha Clariona

Napisany przez programistę kod nigdy nie ginie, niejest przykrywany podczas kolejnych iteracjiautomatycznej 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.

4

Istnieją inne podejścia do RADNa 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ącten 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…

5

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.

6

Jakie cechy powinno mieć współczesne narzędzie RAD?

Oto niektóre typowe oczekiwania

użytkowników końcowychi programistów

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 …

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:

1. Bez rejestracji.2. Bez instalacji.3. Z dobrym samouczkiem.4. Możliwość stworzenia szybkiego prototypu

aplikacji o którą mi chodzi. 7

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

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”.9

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.

10

W dalszej perspektywie

11

Nasze narzędzie

Java ASP.Net PythonNowa

technolo-gia X 2018

Nowa technolo-gia Y 2022

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.

12

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 (…)

13

Pomysł na prezentację w sieciJak najprostszy i jak najszybszy dostęp dla ewaluatora

Programista,oceniający

Interfejs WebNasz serwer

Repozytorium, narzędzie

1.

2.

3.

Aplikacje Webo tej samejfunkcjonalności,optymalizowanedla różnych urządzeńi wielkości ekranów

Strona Web(używana przez przeglądarkę na dużym ekranie)

Interfejs typu „wizard”

1) Samouczek – przykładowaaplikacja

2) Możliwość stworzenia własnego prototypu

Urządzenia

linki

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.

Bez rejestracjiBez instalacjiBez płatności

14

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.

15

Dziękuję za uwagęzapraszam do dyskusji

16

Grzegorz Fałda

grzegorzfalda@gmail.com

602-44-59-81