W javie sporo się zmieniło. Od wydania najpopularniejszej jej wersji, czyli ósemki minęło już kilka dobrych lat. Według ostatniej ankiety przeprowadzonej przez firmę Jetbrains ( https://www.jetbrains.com/lp/devecosystem-2019/java/) ciągle wersja 8 jest tą, z której najczęściej korzystają developerzy. Czym jest to spowodowane? Mamy już przecież za sobą premierę Javy 13. Powodów może być kilka:
Źródło: https://www.jetbrains.com/lp/devecosystem-2019/java/ Wszystko to może zmienić się, kiedy skończy się oficjalne darmowe wsparcie dla Javy 8, czyli pod koniec 2020 roku.
Jakiś czas temu świat obeszła wiadomość o płatnej wersji Javy. Ostatecznie okazało się, że nie taki diabeł straszny jak mówią, i że nie ma się czego obawiać. Java od Oracle pozostaje dalej darmowa. Różnica występuje w magicznym słowie – support. Oracle rozwija język w dwóch dystrybucjach – Oracle JDK oraz OpenJDK. OracleJDK można używać bezpłatnie w celach niekomercyjnych. Do użytku komercyjnego trzeba mieć wykupioną licencję. Natomiast nic nie stoi na przeszkodzie, żeby używać OpenJDK, który jest całkowicie darmowy dla użytku komercyjnego. Jednakże w przypadku OpenJDK wparcie wynosi tylko 6 miesięcy. 
Źródło: https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
Za każdy procesor na serwerze i instancjach chmurowych koszt wyniesie 25$. Natomiast za Javę zainstalowaną na komputerze użytkownika 2.5$ miesięcznie za użytkownika. Do wyboru są subskrypcje: jedno-, dwu- lub trzy- roczne.
Dla niektórych nowości w Javie są równoznaczne z lambdami i streamami dodanymi w Javie 8. Nie zaprzeczam, że był to duży skok w rozwoju języka, ale od tamtego momentu zdążyło się już wiele wydarzyć, a zmiany z ósemki to już chleb powszedni. W artykule chciałbym, więc pokazać najważniejsze zmiany od Javy 9 do Javy 13, oraz te planowane w kolejnych wersjach. Oczywiście skupię się na najważniejszych aktualizacjach z punktu widzenia developera.
Przed tą wersją, rozróżnialiśmy JDK (Java Development Kit) oraz JRE (Java Runtime Environment). JDK zawierało w sobie JRE, ale również kompilator (javac) oraz różne narzędzia, takie jak: javadoc. Od Javy 9, otrzymujemy jedną paczkę – JDK – ze zmodyfikowaną, można powiedzieć “zmergowaną” strukturą katalogów wcześniejszych JRE i JDK. Najistotniejszą modyfikacją jest przeniesienie skompilowanego JDK (rt.jar) oraz narzędzi (tools.jar) w nieco zmienionej formie do katalogu lib.
Została rozszerzona funkcjonalność adnotacji @Deprecated, dając nam więcej informacji o oznaczonym w ten sposób API (tj. polu, klasie czy metodzie). Możemy ustawić teraz dwa parametry, since – mówiący od które wersji Javy byt jest zdeprecjonowany oraz forRemoval – przyjmujący wartość logiczną true lub false (wartość domyślna). Jeśli API zostało oznaczone jako forRemoval=true, możemy się spodziewać, że kompletnie zniknie w kolejnym lub jednym z kolejnych wydań bez kompatybilności wstecznej! Dodatkowo otrzymaliśmy nowe narzędzie – jdeprscan – do analizowania naszego codebasu (pojedyńczych klas lub całych plików jar) pod kątem używania przestarzałego API. Z flagą jdeprscan –for-removal, polecenie zwróci tylko API oznaczone do usunięcia. Ciekawostka na temat tego narzędzia jest taka, że mając je (od JDK 9), jesteśmy w stanie przeskanować pliki skompilowane z wcześniejszymi wersjami Javy, a konkretnie od wersji 6+.
Java 9 wprowadziła nowy poziom abstrakcji powyżej pakietów. Moduł to kolejny stopień enkapsulacji. Można go postrzegać jako zbiór ściśle związanych ze sobą pakietów. Prace nad modułowością trwały wiele lat pod nazwą Projekt Jigsaw. Głównym założeniem było umożliwienie szybszego rozwoju języka. Dzięki podziałowi całego JDK na wiele modułów, stało się to możliwe (prawdopodobnie to Jigsaw był jednym z powodów nowego, szybszego cyklu wydań).
Co daje nam moduł? Moduł jako pojemnik na pakiety, jest warstwą umożliwiającą kontrolę dostępu do swojej zawartości. W uproszczeniu, ukrywa całe zawarte API przed innymi modułami. Dopiero jawne zadeklarowanie w tzw. deskryptorze modułu pozwala udostępnić nam wybrane API na zewnątrz.
Subiektywnie najważniejszą rzeczą dla developera z całej wiedzy o modularyzacji powinna być nowa drabinka poziomów dostępu do API.
JLink jak na obrazku, pozwala skurczyć naszą Javę. 
Jest to narzędzie za pomocą którego można “uszyć” customowe JRE pod wybrany program. Zamiast wykorzystywania całego JDK, składane jest środowisko uruchomieniowe tylko z modułów, które faktycznie są używane w naszej aplikacji. Stworzone i dostarczone w ten sposób JRE jest w stanie wykonać naszą aplikację bez preinstalowania całego JDK. Utworzone w ten sposób customowe JRE do prostego HellowWorlda, ważą ~40MB zamiast 300MB (waga ostatniego JDK).
Tak to możliwe dzięki JShellowi. Jest to mechanizm znany w wielu innych językach pod nazwą REPL (Read-Eval-Print Loop – proste, interaktywne środowisko programowania. Użytkownik może wprowadzić polecenie, które natychmiast zostaje wykonane a jego wynik wyświetlony na ekranie.
Istnieje kilka dziedzin w których JShell może się sprawdzić. Moim numerem jeden jest nauka osób początkujących podstaw programowania. Dzięki prostemu jshell -> enter, nie musimy rozpoczynać od uruchamiania ciężkiego IDE z wieloma ikonkami, kilkoma oknami i pewnie setkami zbędnych na początku funkcji. Jedynie zaciemniałoby to całokształt. Poza tym spróbujcie zupełnie nowej w świecie programowania osobie wytłumaczyć, co to jest to public static void main czy public class. Zaczynanie od obiektywności nie jest najlepszym pomysłem.
Dzięki REPL-owi, możemy zacząć od prawdziwych podstaw. 2+2 -> enter przypisuje nam wynik wyrażenia do automatycznie generowanych zmiennych $1, $2 itd. Oczywiście możemy deklarować własne zmienne int i = 2+2 -> enter. A podgląd wszystkich do tej pory wygenerowanych zmiennych uzyskały za pomocą komendy vars. W podobny sposób, lecz jednak z pełna sygnaturą, możemy generować metody i klasy. I tutaj ciekawostka, możemy deklarować elementy korzystające z nieistniejących jeszcze typów. Tak utworzona metoda lub klasa po prostu nie może zostać użyta do momentu zdefiniowania wszystkich zależności.
Podobne rozwiązania pojawiły się już w innych językach, np. auto z C++. Zmiana ta umożliwia pisanie kodu z “ukryciem” jego typu w kodzie źródłowym, np. 
Nasza zmienna exampleVariable ciągle będzie miała typ String i nie możemy w kolejnych linijkach kodu przypisać do takiej zmiennej innego typu danych np. Integera’a.
Takich zmiennych “varowych” należy jednak używać z rozwagą. Uważam, że nie należy zaciemniać kodu niepotrzebnym skracaniem nazwy typu – tzn. lepiej zapisać standardowego “Stringa” niż ciągle używać “vara”. Jest natomiast kilka przypadków, w których śmiało można wykorzystać zalety nowej funkcjonalności:
W przypadku zagnieżdżonych kolekcji var sprawdza się to znakomicie – skraca nam kod oraz pozbywa się ciężkiej do rozczytania (na pierwszy rzut oka) konstrukcji. Var niesie ze sobą również pewne ograniczenia. Oto kilka z nich:
Oprócz ograniczeń dostajemy również nowe możliwości. Var otwiera nam drogę do jednej sztuczki, której nie dało się wykonać wcześniej. Jest to sztuczka, której lepiej nie używać na swoim projekcie, ponieważ delikatnie zaciemnia nam czytelność kodu. Aczkolwiek warto wiedzieć, że taka możliwość istnieje. Mowa tutaj o dodawaniu pól i metod w sposób ad hoc do istniejącej klasy. Nie musimy tworzyć nowych plików źródłowych z klasami, które dziedziczyłyby celem rozszerzenia istniejącej. Można do tego celu użyć klas anonimowych i naszego “vara”:
Pierwszy LTS w nowym cyklu wydań umożliwia bezpośrednie wykonywanie kodu źródłowego za pomocą interpretera. Kod źródłowy jest kompilowany do pamięci, a następnie wykonywany przez interpeter. Ograniczeniem jest to, że wszystkie klasy muszą być zdefiniowane w tym samym pliku. Tym samym nie powinniśmy zostawać tego rozwiązania przy obszerniejszych programach.
Funkcjonalność ta jest szczególnie przydatna dla osób początkujących, które chcą wypróbować napisane przez siebie proste aplikacje. Wraz z jshell’em będzie to doskonały zestaw narzędzi dla osób zaczynających naukę języka Java.
Przykład “Witaj Świecie”.
Umieszczamy swój kod w pliku z rozszerzeniem .java.
Następnie uruchamiamy nasz program za pomocą komendy:
Dodatkowo możemy użyć tego polecenia w konfiguracji z flagą –source. Umożliwia ona uruchomienie naszego kodu w zgodności z konkretną wersją Javy (Java 7 i nowsze). Dodatkowo można użyć tej flagi w sytuacji kiedy plik źródłowy ma inne rozszerzenie niż .java (lub nie ma żadnego).
Jeśli zapisalibyśmy nasz kod w pliku WitajSwiecie.app, to komenda wyglądała by następująco:
Do momenty wydania Javy 11 mieliśmy w JDK bardzo słabe API do zapytań http. Z klasą
HttpURLConnection było bardzo wiele problemów. Miedzy innymi nie wspierała protokołu http/2, miała wiele nieudokumentowanych zachowań, działała blokująco (jedno zapytanie na jeden wątek), istniała w Javie od wersji JDK 1.1, a jej utrzymanie stało się bardzo ciężkie. Jako alternatywę mogliśmy wykorzystać jedną z wielu zewnętrznych bibliotek.
Ze względu na słabe standardowe API i częstą potrzebę dodawania zewnętrznych zależności (w końcu ile większych aplikacji nie potrzebuje wysłać zapytania http?) postanowiono ustandaryzować i wprowadzić nowego HTTP Client’a prosto do JDK.
Jego API jest naprawdę przejrzyste, a wykonanie pełnoprawnego zapytania http sprowadza się do kilku linijek kodu:
Dostaliśmy również zestaw nowych metod w klasie java.lang.String:
Pojawiły się również dwie bardzo praktyczne statyczne metody w klasie FIles:
Wydana w marcu 2019 wprowadza jedną bardzo ciekawą zmianę – switch expressions. Czyli małą rewolucję na istniejącej konstrukcji switch-case. Funkcjonalność ta jest dostępna jako tzw. preview feature.
Są to takie funkcjonalności języka które musimy “odblokować”. Preview feature może zostać zmienione lub wycofane w następnych wersjach języka, więc należy uważać z używaniem takich funkcjonalności w kodzie produkcyjnym. Odblokować preview feature można poprzez dodanie flagi -enable-preview przy kompilacji i uruchamianiu programu.
IntelliJ może nas w tym wyręczyć, ponieważ w project structure znajdują się gotowe konfiguracje z różnymi poziomami języka, uwzględniającymi też preview features.
W switch expressions dostajemy nową składnie dla starego i poczciwego switch-case’a. Dla wstecznej kompatybilności obie formy składni są poprawne, z tym że jeśli zdecydujemy się na jeden sposób zapisu to musimy go kontynuować w obrębie jednego switch case’a. 
To co rzuca się w oczy to składnia przypominająca trochę składnie lambd. Można również zauważyć, że nie ma break’ów po każdym case. Nowa składnia zapewnia nam brak tzw. fall through – kod z następnych case’ów nie zostanie wykonany pomimo braku słowa kluczowego break.
Poza zmianą składni i konstrukcji. Switch ze “statement” stał się “expression”. Jaka jest różnica pomiędzy takimi tworami? Najprościej – “statement nie zwraca wartości a expression zwraca.
Statement jest na przykład konstrukcją if-else. Skoro nowy switch zwraca nam jakąś wartość to można taką wartość przypisać do zmiennej. Jeśli case jest jednolinijkowy to ze switcha zostanie zwrócona wartość zwracana przez to wyrażenie. Jeżeli chcielibyśmy wynik z wykonania “starego” switch’a przypisać do zmiennej, to musielibyśmy stworzyć zmienną przed switch’em, a następnie przypisywać do niej wartość w każdym case. Wygląda to tak:
Z użyciem nowej konstrukcji można to znacząco skrócić oraz uczynić o wiele bardziej czytelnym:
Wspominałem już o tym, że jeśli wyrażenie w case ma jedną linijkę to jego wynik zostanie zwrócony. Jeśli natomiast chcielibyśmy zawrzeć jakąś dłuższą logikę, to podobnie do lambd musimy nasz blok kodu obtoczyć nawiasami klamrowymi. Na samym końcu użyjemy słowa kluczowego break ze zwracaną wartością. Jest to dość niecodzienne rozwiązanie i może wyglądać trochę dziwnie. Dlaczego nie słowo kluczowe return? Return jest używany do zwrócenia wartości z całej metody, więc takie rozwiązanie byłoby nieintuicyjne.
Zmieniło się również pod kątem sprawdzenia czy wszystkie możliwe wartości w case zostały obsłużone. W poprzednich wersjach Javy kompilator nie dbał o to czy w kodzie źródłowym były sprawdzone wszystkie ścieżki. Jedynie IDE i narzędzia typu sonar lint podpowiadały, że czegoś nam może w danym miejscu brakować. Kompilator generował jedynie ostrzeżenie. W Javie 12 taka sytuacja wygeneruje nam błąd kompilacji.
Bloki tekstu są kolejnym preview feature’m. Stanowią one ułatwienie dla dużych bloków tekstu, które musimy wkleić do kodu i przypisać do String’a. Aktualnie aby wkleić taki duży blok musimy każdą linijkę konkatenować lub zapisać cały blok w jednej linijce, używając co jakiś czas znaku nowej linii – “\n”. Z pomocą przychodzi nam oczywiście IDE, które potrafi wygenerować konkatenacje i znaki nowej linii, lecz ciągle taki zapis może być bardzo nieczytelny i po prostu nieelegancki.
Czym są i co dają nam bloki tekstu w Javie?
Poniżej kilka przykładów bloków tekstu:
HTML
SQL
JSON
Razem z text blocks dodano do klasy string nowe metody. Warto zaznaczyć, że wszystkie są oznaczone jako deprecated for removal. Spowodowane jest to tym, że text blocks zostało wprowadzone jako preview feature.
Więcej można znaleźć w oficjalnym opisie JEP’a – https://openjdk.java.net/jeps/355
W Javie 13 mamy po raz kolejny do czynienia ze switch expressions, które ciągle jest preview feature. Ta wersja Javy wprowadza do jedną małą zmianę do jej funkcjonalności. Jak wcześniej wspominałem do zwrócenia wartości z case’a musieliśmy użyć słowa kluczowego break. Natomiast teraz mamy nieco czytelniejsze i mniej zaskakujące rozwiązanie. Twórcy języka wprowadzili nowe słowo kluczowe – yield izastępuje ono poprzedniego break’a.
Zmianą raczej mało widoczną z perspektywy programisty lecz bardzo istotną z kilku innych powodów jest przepisanie i odmłodzenie API Socketów. Zaimplementowane od nowa zostały klasy z pakietu java.net, a w szczególności klasa java.net.ServerSocket. Nowa implementacja jest całkowicie kompatybilna z poprzednim API. Dlaczego postanowiono na przepisanie socketów? Jest kilka powodów, a oto niektóre z nich:
Postanowiono w końcu wziąć na warsztat źródło większości problemów generowanych przez aplikacje napisane w Javie – czyli null pointer exception. Nowa wersja najpopularniejszego wyjątku została trochę podrasowana. Nowy NPE pokazuje nam w swoim stack trace dokładną lokalizację wyjątku. W porównaniu do dobrze znanego NPE pokazuje on jaki obiekt wywołał nasz NPE, a nie tylko linijkę kodu, w którym wystąpił wyjątek. Jest to dosyć spore ułatwienie dla początkujących programistów, którzy mogą mieć problemy ze zrozumieniem NPE. Funkcjonalność ta znajduje swoje duże zastosowanie podczas długiego ciągu wywołań metod. Na pierwszy rzut oka nie za bardzo widać co spowodowało wyjątek, a żeby się tego dowiedzieć potrzebny byłby debuger. Nowy NullPointerException wygląda mniej więcej tak:
Oczywiście opisane tutaj zmiany nie są wszystkimi, nad którymi aktualnie pracują twórcy języka. Jest mnóstwo funkcjonalności, które są w fazie rozwoju, a nie zostały jeszcze zapowiedziane na konkretną wersję Javy.
Po przekalkulowaniu kosztów kupna rozszerzonego wsparcia dla Javy 8 klient zdecydował się na migrację dużego systemu PLM do kolejnej wersji LTS – Javy 11. Aktualizacja tak wielkiego produktu nie jest łatwym przedsięwzięciem, ze względu na milionową ilość linijek kodu oraz długi rozwój (kilkanaście lat) aplikacji. Z powodu ogromnej złożoności aplikacji, natknęliśmy się na kilka ciekawych i niecodziennych przypadków, które można wziąć pod uwagę pod kątem aktualizacji tak dużego produktu.
Nasz zespół był w głównej mierze odpowiedzialny za aktualizacje i sprawdzenie wsparcia oraz kompatybilności bibliotek używanych przez system. Naszą pracę rozpoczęliśmy od skatalogowania wszystkich bibliotek, sprawdzenia ich ostatnich dat aktualizacji oraz tego czy są kompatybilne z nową wersją Javy. Niektóre z tych informacji wymagały kontaktu z twórcami bibliotek. Okazało się, że kilka bibliotek sprawiło nam problem swoim brakiem kompatybilności. W takim wypadku konieczna była aktualizacja do najnowszej wersji biblioteki (o ile istniała). Jeśli nie to należało znaleźć jakiś zamiennik.
Cała analiza bibliotek byłaby bardzo trudna bez odpowiednich narzędzi. Na szczęście istnieje kilka gotowych rozwiązań które okazują się być bardzo przydatne.
Na początek wystarczą narzędzia, które są dostępne razem z JDK. Jdeps służy nam do analizy zależności naszych klas. Szczególnie przydatna w ramach nowej Javy przydaje się flaga -jdkinternals. Efektem wykonania komendy jdeps -jdkinternals jararchive.jar będzie lista wszystkich klas, które używają wewnętrznego API Javy. Generalnie żadna biblioteka nie powinna używać kodu przeznaczonego tylko do użytku wewnątrz Javy. Niestety tak kolorowo nie jest i przez lata wiele bibliotek śmiało korzystało z pakietów takich jak np. sun.misc.* Jeśli taka komenda nie zwróci nam żadnego wyniku oznacza to, że archiwum jar jest “czyste” pod względem używania wewnętrznego API Javy.
W przypadku biblioteki jmockit okazuje się, że jedna klasa korzysta z pakietu sun.reflect. Jdeps zwraca nam dosyć szczegółowy opis zależności oraz otrzymujemy link z sugerowanym zamiennikiem.
Kolejną użyteczną komendą jest jdeprscan. Szczególnie użyteczny w połączeniu z przełącznikiem -for-removal. Narzędzie to pokazuje nam wszystkie użycia zdeprecjonowanego API przez dane archiwum JAR. Pokazywane są jedyne zdeprecjonowane użycia metod z JDK. Nie możemy tego użyć do sprawdzenia pod względem zdeprecjonowania w 3rd party jar. Taką funkcjonalność zapewniają nam inne narzędzia, o których później. Ciekawym pomysłem jest również przełącznik –release, który pozwala nam na wybranie wersji Javy pod kątem, której będziemy sprawdzać zdeprecjonowane API, więc używając w jednym terminalu np. Javy 13, ciągle mamy możliwość sprawdzenia zdeprecjonowanie pod kątem Javy 11.
Czyli Java API compliance checker jest to opensourcowy projekt napisany w języku Perl. który służy do porównywania API dwóch różnych wersji bibliotek. Narzędzie generuje nam raport w HTML’u, który pozwala na łatwe przeglądanie zmian.
Aby zainstalować narzędzie należy zrobić clone oficjalnego repozytorium i uruchomić program make.
Natomiast przykładowe użycie narzędzia wygląda w taki sposób:
Więcej o JAPICC’u można się dowiedzieć na githubie: https://github.com/lvc/japi-compliance-checker
Narzędzie z którego raczej nie korzystaliśmy, ale natknęliśmy się podczas trwania projektu. Zapewnia podobną funkcjonalność co JAPICC. Przykładowe raporty z JDiff’a można znaleźć w repozytorium Guavy – https://guava.dev/releases/28.1-jre/api/diffs/
Jeśli nie mamy ochoty instalować żadnego nowego oprogramowania to zawsze możemy skorzystać z aplikacji webowej. ABI Laboratory (https://abi-laboratory.pro/) jest ciekawym rozwiązaniem, które agreguje w sobie rozwiązanie poprzednie. Jedną dużą wadą jest to, że znajdziemy tam najpopularniejszebiblioteki open source. Celem sprawdzenia tych mniej popularnych należy skorzystać z dedykowanego oprogramowania.
Z racji, że projekt zakładał migracje, to nie mieliśmy za wielkiego pola manewru, jeśli chodzi o nowe funkcje języka. Bardziej należało się skupić na kompatybilności API oraz wsparcia dla bibliotek 3rd party. Nowości w javie miały wpływ na pisanie szybkich aplikacji do automatyzacji pewnych czynności. Bardzo użyteczne okazały się nowe metody na klasie String i Files.
Jednoplikowe programy są funkcjonalnością do napisania aplikacji generujacej szybkie raporty, które można następnie podpiąć do pipeline. Jesteśmy przekonani, że migracja takich systemów jest bardzo dobrym rozwiązaniem. Im mniejszy dług technologiczny jest zaciągany tym łatwiej później jest utrzymać system.
Zatrudnianie zewnętrznych zespołów QA do weryfikacji produktu stało się powszechną praktyką – dowiedz się czym jest usługa Third Party QA Testing i jak Transition Technologies PSC podchodzi do jej realizacji wykorzystując do tego narzędzie Xray.
Eksperci Transition Technologies PSC opowiadają o inicjatywie "Akademia Go" i korzyściach z nauki języka programowania Go w dostarczaniu wydajnych rozwiązań klientom. Dowiedz się, dlaczego Go staje się językiem przyszłości w branży IT.
Outsourcing zewnętrznego programisty zwiększa możliwości Twojego zespołu. Dodatkowy specjalista jest wsparciem w realizacji codzienny zadań i dotrzymywaniu deadline’ów. Jego obecność pozwala zwiększyć produktywność w momencie pojawienia się nowych i wymagający możliwości biznesowych.
Żyjemy w epoce danych, co oznacza, że w świecie, w którym funkcjonujemy, są one cenniejsze niż pieniądze. Kradzież tożsamości i utrata istotnych danych jest problematyczna dla każdego użytkownika, jednak z tym zagrożeniem powinni liczyć się szczególnie przedsiębiorcy.
Serverless cmputing nadal budzi sporo wątpliwości, szczególnie wśród tych środowisk, które właśnie zaczynają korzystanie z usług chmurowych lub dopiero planują migrację do chmury swoich systemów. Na najważniejsze pytania dotyczące tego rozwiązania spróbujemy odpowiedzieć w niniejszym artykule.
6 najczęstszych mitów i błędnych przekonań dotyczących scruma. Liczymy, że ich poznanie sprawi, że skutecznie ich unikniesz.
Najnowsza aktualizacja wytycznych najpopularniejszego frameworka agile czyli Scrum Guide. Najważniejsze zmiany wprowadzone przez aktualizację Scrum Guide 2020 oraz ocena ich wpływu na codzienną pracę zespołów.
Czym właściwie jest agile? Jak to się wszystko zaczęło? Jakie zasady charakteryzują tę metodykę działania, czym różni się ona od podejścia tradycyjnego i w jaki sposób efektywnie (i zwinnie) prowadzić projekty? Przedstawiamy zbiór informacji, który każda osoba związana w jakikolwiek sposób z technologiami, powinna poznać. Mamy nadzieję, że uznacie je za wartościowe oraz godne polecenia. Zapraszamy do komentowania, a w przypadku pytać szczegółowych – do kontaktu
Wyobraź sobie, że jesteś osobą niewidomą lub słabowidzącą i chciałbyś/chciałabyś zalogować się do własnego konta bankowego poprzez stronę internetową lub aplikacje mobilną. Wpisujesz hasło, wybierasz kolejne opcję, przechodzisz na następną stronę, ale w pewnym momencie nie możesz zrobić nic więcej... Nie masz dostępu do pełnej funkcjonalności aplikacji. Dlaczego?
Coraz więcej aktywności z zakresu PR i marketingu przenosi sie obecnie do internetu. To zatem dobry moment na dokładną analizę działań prowadzonych w sieci i spojrzenie na nie w szerszej niż dotychczas perspektywie. Pomocne może okazać się wdrożenie standardów dostępności WCAG.
Zastanawiałeś się kiedyś, jak korzystają ze stron internetowych osoby niewidome i niepełnosprawne? Standardowe czynności, które wykonujemy na co dzień w Internecie, są dla osób niepełnosprawnych utrudnione lub nawet niedostępne. Właśnie dlatego tak istotne są kryteria WCAG dla serwisów cyfrowych. Wykonanie przelewu bankowego, znalezienie informacji na stronach urzędowych czy zarezerwowanie online wizyty lekarskiej zajmuje chwilę, ale tylko wtedy, gdy strona jest dostępna. Co to oznacza w praktyce? To, że strona posiada odpowiednie funkcje umożliwiające poruszenie się po niej każdemu użytkowników, również osobom z niepełnosprawnością.
Dzisiejsze społeczeństwo jest mocno zinformatyzowane. Chcemy mieć dostęp do muzyki, książek, czy filmów gdziekolwiek jesteśmy, niezależnie od tego czy czekamy w poczekalni u dentysty, czy jedziemy autobusem. Wychodząc naprzeciw takiemu zapotrzebowaniu, coraz więcej przedsiębiorstw oferuje dostęp do swoich usług przez Internet.
Branża IT to jedna z najszybciej ewoluujących gałęzi biznesu. Nie tylko dzięki technologii, którą oferuje, ale też dzięki szerokiemu obszarowi usług, które jest w stanie dostarczyć na potrzeby innych przedsiębiorstw.
Obecne trendy w tworzeniu i dostarczaniu dedykowanego oprogramowania dla firm mocno poszły w kierunku modelu opartego o outsourcing. Jest to bardzo wygodne rozwiązanie, gdyż klient (firma zamawiająca) nie musi utrzymywać całego działu programistów.
Od dawna intensywnie pracujemy nad stworzeniem skuteczniejszych oraz bezpieczniejszych sposobów identyfikacji użytkownika niż login i hasło. Wraz z rozwojem takich technologii jak czytniki linii papilarnych czy skanery siatkówki, jesteśmy w stanie zweryfikować tożsamość równie dobrze jak za pomocą loginu i hasła.
Jeszcze parę lat temu code review było bardziej postrzegane jako pewnego rodzaju ciekawostka czy idealistyczny praktyka programistyczna niż element wnoszący widoczną wartość projektów komercyjnych. Choć termin ten od dawana jest jasny
W rozwijającym się technologicznie świecie branża IT cierpi na niedobór wykwalifikowanych pracowników. I choć, według niektórych źródeł takich jak Forbes, problem tkwi raczej w niechęci pracodawców do spełnienia wymagań finansowych dostępnych zasobów ludzkich, co otwiera często wiele możliwości specjalistom z zagranicy, jest to niewątpliwie świetna okazja dla firm i platform umożliwiających outsourcing, z korzyścią dla […]
Zostańmy w kontakcie
Skontaktuj się