Irek w sieci

Zaczynamy pierwszy samouczek Lightswitch. Wprowadzenie możecie przeczytać tutaj. Bazuje na samouczku Beth Massi.

Pamiętając, że podstawą aplikacji Lightswitch są dane zgromadzone w bazie danych, których struktury możemy tworzyć podczas prac nad nową aplikacją lub możemy skorzystać z istniejących w bazie danych struktur. Dla osób raczkujących w bazach danych analogią zbiorów danych niech będzie tabelka w Excelu, kolumny i wiersze z danymi. Dane w bazie danych przechowywane są w jednej lub wielu takich tabelach. Pomiędzy nimi mogą występować relacje np. wartość w tabeli A musi występować w tabeli B.

W Lightswitch możemy sięgnąć także do innych źródeł danych, nie koniecznie baz danych, np list Sharepoint, dlatego dla danych użyto terminu encji (entities). Podobnie kolumna w tabeli lub liście jest traktowana jako właściwość (property) encji. Jeśli nie korzystamy z istniejących baz danych, tworzymy nowe tabele we wbudowanej podręcznej bazie danych Lightswitch (intrinsic). Gdy tworzymy tabele i relacje między nimi, tworzymy model danych (lub schemat). Wymaga to pewnego doświadczenia ale interfejs Lightswitch bardzo ułatwia ten proces. Praca włożona w dokładne zdefiniowanie modelu pozwala na zaoszczędzenie wysiłku po stronie ekranów aplikacji.

Czytaj dalej …

Tym razem zaciekawiło mnie kolejne rozwiązanie Microsoftu – Lightswitch. W skrócie jest to podejście do szybkiego tworzenia aplikacji biznesowych, opartych na bazach danych. Podstawą jest zestaw tabel, relacji między nimi do której tworzymy interfejs użytkownika, reguły biznesowe, walidacje. Ciekawy wstęp po polsku możecie przeczytać tutaj.

Rozwiązanie w Lightswitch może sięgać do wielu źródeł danych i stworzyć aplikacje dostępne na wielu urządzeniach. Działamy na istniejącej bazie danych lub tworzymy ja automatycznie w ramach pracy nad projektem. Nie wymagana jest znajomość obsługi bazy danych i manualnego tworzenia tabel. Ciekawą opcją jest automatyczne utworzenie za pomocą Lightswitch usługi sieciowej do wymiany danych w protokole OData.

Interfejs aplikacji tworzony jest na bazie szablonów, które łatwo dostosowywać. Wizualizujemy dane wskazując, które elementy wyświetlać. Dla dużych ilości danych i nawigacji za pomocą myszki i klawiatury, możemy utworzyć klasyczną aplikację instalowaną na komputerach. Z drugiej strony mamy możliwość stworzenia aplikacji na urządzenia przenośne w technologi HTML5 z wykorzystaniem ekranów dotykowych. Lightswitch pozwala na tworzenie i używanie rozszerzeń, które wzbogacają interfejs funkcjonalnością niedostępną w standardzie.

Czytaj dalej …

Skoro wiemy już co to jest SLA i SLM, poznajmy kilka realnych przykładów takich umów.

Odnoszę się do środowiska IT, skąd pochodzi moja wiedza. Podobne przykłady można przytoczyć ze obszaru produkcji, rekrutacji, zarządzania. Generalnie, każda umowa niesie w sobie jakieś elementy zarządzania usługami. Np. umowa najmu lokalu zawiera terminy płatności, postepowanie przy zaleganiu, kary. Firmy rekrutacyjne zobowiązują się do przedstawienia określonej ilości kandydatów, w przeciwnym razie są kary, obniżone płatności.

Czytaj dalej …

W sieci jest mnóstwo mądrych artykułów o SLM. Pisze się o ITIL, używa wielu porad co do zarządzania incydentami, problemami. Brakuje mi prostego wytłumaczenia tego w zasadzie dosyć prostego mechanizmu. Jako, że mam spore doświadczenie w tym temacie, postanowiłem spróbować przedstawić SLM za pomocą prostych analogii.

Czytaj dalej …

Ogóły znajdziecie w poprzednim wpisie. Teraz czas na szczegóły. Opieram się na oficjalnej specyfikacji ORACLE.

Zapoznaliśmy się z architekturą, synergiami, trybem PaaS i bezpieczeństwem. Poznaliśmy detale tworzenia aplikacji bazodanowych i w stylu arkusza kalkulacyjnego. Wiemy jak wygląda interfejs dewelopera przy użyciu SQL, a teraz poznamy metody wdrażania stworzonych aplikacji oraz jak można sobie radzić z błędami.

Po stworzeniu i przetestowaniu aplikacji nadchodzi czas wdrożenia / aktualizacji i przeniesienia jej do środowiska produkcyjnego. APEX dostarcza kilka metod kontrolowania kodu źródłowego i dystrybucji aplikacji.

Czytaj dalej …

Ogóły znajdziecie w poprzednim wpisie. Teraz czas na szczegóły. Opieram się na oficjalnej specyfikacji ORACLE.

Zapoznaliśmy się z architekturą, synergiami, trybem PaaS i bezpieczeństwem. Poznaliśmy detale tworzenia aplikacji bazodanowych i w stylu arkusza kalkulacyjnego. Zajmiemy się teraz interfejsem dewelopera i użyciem SQL.

Rozbudowane aplikacje APEX wymagają użycia języka SQL i PL/SQL. Do dyspozycji mamy warsztat SQL, który ma kilka funkcjonalności.

Czytaj dalej …

Ogóły znajdziecie w poprzednim wpisie. Teraz czas na szczegóły. Opieram się na oficjalnej specyfikacji ORACLE.

Zapoznaliśmy się z architekturą, synergiami, trybem PaaS i bezpieczeństwem. Poznaliśmy detale tworzenia aplikacji bazodanowych. Zajmiemy się aplikacjami w stylu arkusza kalkulacyjnego (websheets), które użytkownik może tworzyć bez pomocy dewelopera aplikacji.

Ten typ aplikacji pozwala zarządzać uporządkowanymi lub nieuporządkowanymi danymi.  W szczególności możemy:

Czytaj dalej …

Ogóły znajdziecie w poprzednim wpisie. Teraz czas na szczegóły. Opieram się na oficjalnej specyfikacji ORACLE.

Po zapoznaniu się z architekturą, synergiami, trybem PaaS i bezpieczeństwem, przyjrzyjmy się tworzeniu aplikacji.

Standardowo w APEX, po instalacji mamy dostęp do przykładowej aplikacji.

Aplikacja bazodanowa jest kolekcją stron/ekranów połączonych ze sobą poprzez zakładki, przyciski lub odnośniki. Deweloper aplikacji ma

Czytaj dalej …

Ogóły znajdziecie w poprzednim wpisie. Teraz czas na szczegóły. Opieram się na oficjalnej specyfikacji ORACLE.

Po zapoznaniu się z architekturą, synergiami i trybem PaaS, przyjrzyjmy się bezpieczeństwu aplikacji stworzonych przy użyciu tego narzędzia.

Instancja APEX oraz wszystkie tworzone w niej aplikacje mogą zostać skonfigurowane do używania protokołu HTTPS (SSL). Hasła dostępu mogą zostać poddane wymaganiom zawartości oraz zasadom okresu ważności i zmian.

Twórcy aplikacji mogą uaktywnić zabezpieczenia stanu sesji (SSP – Session State Protection), które dodają sumę kontrolna do adresu URL, zapobiegając podszywaniu się i nieuprawnionemu dostępowi. Definiują również jakie dane są przechowywane w stanie sesji. Dane wymagające szczególnej troski mogą zostać zaszyfrowane.

Autentykacja

Weryfikuje dostęp użytkownika do aplikacji (chyba, że aplikacja jest publiczna). Zazwyczaj użytkownik podaje nazwę użytkownika i hasło. APEX dostarcza kilka mechanizmów autentykacji:

Czytaj dalej …

Ogóły znajdziecie w poprzednim wpisie. Teraz czas na szczegóły. Opieram się na oficjalnej specyfikacji ORACLE.

Po zapoznaniu się z architekturą i synergiami, pomyślmy o APEX jako platformie usługowej (a nawet samoobsługowej).

PaaS (Platform as a Service) ? platforma jako usługa, umożliwia deweloperom zażądania w trybie on-line własnego środowiska deweloperskiego. Pozwala na natychmiastowe rozpoczęcie tworzenia aplikacji. Oczywiście można manualnie tworzyć środowiska.

Samoobsługa

Dajemy użytkownikom możliwość żądania własnej przestrzeni. Automatycznie udostępniamy środowisko deweloperskie, dostęp do jednego ze schematów bazy danych. W ten sposób wiele projektów można automatycznie inicjować i realizować używając pojedynczej instancji bazy danych.

Inne opcje tworzenia środowisk

• Ręczny ? administrator ręcznie tworzy każdą przestrzeń deweloperską

Czytaj dalej …