Słowniczek programisty

API — ang. appli­ca­tion pro­gram­ming inter­face — jest to sposób, w jaki może­my sko­rzys­tać z danej bib­liote­ki, frame­wor­ka lub sys­te­mu zewnętrznego. API to w uproszcze­niu zbiór pub­licznych inter­fe­jsów, które może­my wyko­rzys­tać real­izu­jąc naszą aplikację

aplikac­ja webowa — aplikac­ja (lub zbiór aplikacji), których moż­na uży­wać za pomocą przeglą­dar­ki inter­ne­towej — oznacza to, że jest ona zain­stalowana na ser­w­erze i dostęp­na pod adresem URL. W przy­pad­ku aplikacji webowych napisanych w języku Java, są one uruchami­ane w ser­w­erze aplikacji

arte­fakt — o arte­fak­tach mówimy głównie w kon­tekś­cie mave­na, ale może­my też uży­wać tego określe­nia poza tym środowiskiem. Arte­fakt to pacz­ka (najczęś­ciej archi­wum zip z rozsz­erze­niem jar albo war) która zaw­iera gotowy kom­po­nent (np. mod­uł naszej aplikacji, bib­liotekę zewnętrzną, wydzieloną część aplikacji itp)

bib­liote­ka (zależność, depen­den­cy) — jest to jak­iś mod­uł dostar­czany przez kogoś innego (lub np. będą­cy inną częś­cią tego samego pro­jek­tu) z którego korzys­tamy. W przy­pad­ku pro­jek­tu, który pisze­my w ramach kur­su, bib­lioteką (zależnoś­cią) jest np. Spring Framework

budowanie — budowanie to pro­ces, który obe­j­mu­je m.in. kom­pi­lac­je (patrz poniżej) — ogól­nie rzecz ujmu­jąc budowanie to pro­ces przek­sz­tał­ca­nia wszys­t­kich kodów źródłowych i innych plików w pro­jek­cie (mod­ule) w arte­fakt — postać gotową do uży­cia w innym projekcie/module (lub w ser­w­erze aplikacji)

bug — błąd, który powodu­je niepraw­idłowe dzi­ałanie aplikacji (np. pewne dane się nie zapisu­ją albo obliczane są z błę­dem). Bugi najczęś­ciej zgłaszane są przez użytkown­ików lub testerów w postaci tick­etów lub sami pro­gramiś­ci je znajdują

CI (con­tin­u­ous inte­gra­tion) — ciągła inte­grac­ja to poję­cie nie tyle związane z samym pro­gramowaniem co z pro­jek­tem infor­maty­cznym ogól­nie. Ciągła inte­grac­ja pole­ga na tym, że za każdym razem gdy ktoś z pro­gramistów umieś­ci na repozy­to­ri­um zmi­any w kodzie, cały pro­jekt jest ponown­ie budowany i w przy­pad­ku pojaw­ienia się błędów wysyłana jest stosow­na infor­ma­c­ja mailem. W tym sen­sie jest narzędziem do kon­troli jakoś­ci. Poza tym może dodatkowo real­i­zować inne funkc­je, np. po zbu­dowa­niu pro­jek­tu po zmi­an­ie umieś­cić jego najnowszą wer­sję na ser­w­erze (stąd nazwa — ciągła integracja)

deploy­ment — potocznie uży­wa się także sfor­mułowa­nia ‘wrzu­cać na ser­w­er’. Deploy­ment to nic innego jak uru­chomie­nie arte­fak­tu (zbu­dowanego pro­jek­tu) na ser­w­erze aplikacji (czyli uru­chomie­nie np. aplikacji webowej tak, żeby była dostęp­na pod określonym URLem)

devel­op­ment — potocznie utożsamia się z pro­gramowaniem. ale for­mal­nie devel­op­ment odnosi się do wszys­t­kich czyn­noś­ci związanych z real­iza­cją pro­jek­tu od początku do koń­ca (pro­jek­towanie, pro­gramowanie, testowanie, wdrażanie)

DI (depen­den­cy injec­tion) — inaczej wstrzyki­wanie zależnoś­ci, czyli zami­ast samodziel­nie zaj­mować się inicjowaniem kom­po­nen­tów, obiek­tów i innych które potrze­bu­je­my, robi to za nas kon­tener IoC, a następ­nie ustaw­ia odpowied­nie pola w naszej klasie (stąd nazwa wstrzyki­wanie). Przykła­dem jest adno­tac­ja @Autowired, o której możesz poczy­tać w lekcji #09

frame­work — bib­liote­ka, która dostar­cza duży zbiór funkcjon­al­noś­ci i na której opier­amy swo­ją aplikację. Różni­ca pomiędzy frame­workiem a bib­lioteką jest taka, że bib­liote­ka najczęś­ciej dostar­cza funkcjon­al­noś­ci, które moż­na pod­mienić przy sto­sunkowo małej iloś­ci zmi­an w samym kodzie czy plikach kon­fig­u­racji (np. jeśli nasz pro­jekt uży­wa JPA to może­my użyć bib­liote­ki Hiber­nate, ale może­my też innej), frame­work z kolei narzu­ca pewien styl lub kon­wencję a jego pod­mi­ana w pro­jek­cie wiąże się z dużym nakła­dem pra­cy (np. Spring jest frame­workiem, aplikac­je webowe z jego uży­ciem piszę się w pewien unikalny sposób, który nie jest obsługi­wany przez inne frameworki)

inte­grac­ja — łącze­nie wielu ele­men­tów; ma ono miejsce w więk­szych pro­jek­tach, które składa­ją się z wielu mod­ułów lub korzys­ta­ją z zewnętrznych sys­temów. Inte­grac­ja to upewnie­nie się, że oba te kom­po­nen­ty dzi­ała­ją wspól­nie tak jak zakładano oraz tego, że nie ma prob­lemów np. z komu­nikacją pomiędzy nimi

Jenk­ins (alt. Hud­son) — jeden z najpop­u­larniejszych sys­temów CI. Ma dwie nazwy, ponieważ pro­jekt podzielił się na dwa rozwi­jane równole­gle przez poli­tykę firmy Ora­cle (zain­tere­sowanych odsyłam do np. wikipedii). Jenk­ins jest obec­nie szy­b­ciej rozwi­jany i częś­ciej używany.

kom­pi­lac­ja — zami­ana kodu źródłowego na taki, który da się uruchami­ać (np. w ramach JVM lub bezpośred­nio na komputerze)

kom­po­nent — log­icz­na część całej aplikacji/systemu. Kom­po­nent może się ograniczać do klasy, zbioru klas lub nawet kilku mod­ułów czy sys­temów, wszys­tko zależy od tego co chce­my pokazać (np. opisu­jąc sys­te­my infor­maty­czne banku, kom­po­nen­tem może być sys­tem do obsłu­gi kart. Z kolei omaw­ia­jąc zabez­pieczenia banku kom­po­nen­ta­mi mogą być sys­tem wykry­wa­nia pode­jrzanych transakcji oraz sys­tem odrzu­ca­nia transakcji wyko­nanych zablokowany­mi kar­ta­mi — oba wcześniej były objęte kom­po­nen­tem obsłu­gi kart)

kon­tener — w zależnoś­ci od kon­tek­stu może mieć różne znacze­nie. Ogól­nie rzecz biorąc kon­tener to jakaś funkcjon­al­ność ‘zapewniona’, tzn. dostar­c­zona do naszej aplikacji z której może­my korzys­tać. Może­my wyszczegól­nić kil­ka kontenerów:

• kon­tener servletów — jest to środowisko, w którym może­my uruchami­ać Servle­ty (np. każdy ser­w­er aplikacji nim jest lub posi­a­da go jako kom­po­nent), czyli obsługu­je zapy­ta­nia HTTP i zamienia je na obiek­ty, które następ­nie przekazu­je do konkret­nych Servletów
• konen­er IoC — bib­liote­ka lub frame­work, która zapew­nia funkcjon­al­ność IoC (np. DI) — przykła­dem takiego frame­worku jest Spring, który uruchamia włas­ny kon­tener IoC, w którym z kolei uruchamia beany

maven — to narzędzie do zarządza­nia zależnoś­ci­a­mi w pro­jek­cie. Znaczą­co upraszcza kon­fig­u­rac­je pro­jek­tu (np. samodziel­nie pobiera potrzeb­ne zależnoś­ci z inter­ne­tu, zarządza tym, jak pro­jekt jest budowany itp), cen­tral­na kon­fig­u­rac­ja pro­jek­tu zna­j­du­je się w pliku pom.xml

repozy­to­ri­um (scm, svn, git) — (ang. source code man­age­ment) jest to cen­tralne miejsce, w którym prze­chowywany jest kod pro­jek­tu. Repozy­to­ri­um prze­chowu­je też wszys­tkie zmi­any, dzię­ki czemu moż­na pode­jrzeć kto zmienił co i kiedy (prze­chowu­je więc his­torię). Dodatkowo prze­chowu­je także tzw. rewiz­je — czyli w pewnym sen­sie ‘wer­sję’ kodu — dzię­ki czemu nie nad­pisze­my (przy­pad­kowo) czyichś zmi­an w kodzie

ser­w­er aplikacji — środowisko, w którym uruchami­amy aplikac­je webowe, które dostar­cza m.in. kon­tener servletów oraz inne funkc­je. Przykłada­mi ser­w­erów aplikacji są np. JBoss AS czy Tomcat

servlet — pod­sta­wowy obiekt w specy­fikacji Java EE, servlet odpowia­da na zapy­ta­nia HTTP wysłane pod wskazany adres (lub wzór adresu — tzw. servlet-mapping)

tick­et (issue) — zgłosze­nie zare­je­strowane w sys­temie (issue track­er), najczęś­ciej jest to prob­lem do rozwiąza­nia (bug) lub zadanie do wyko­na­nia. Tick­et powinien zaw­ier­ać opis tego, co powin­niśmy zro­bić, osobę odpowiedzial­ną oraz inne infor­ma­c­je użyteczne przy pracy

ui — user inter­face, czyli to co widzi użytkown­ik. W przy­pad­ku aplikacji webowych jest to wygen­erowana strona HTML, ogól­nie część ‘graficz­na’ naszej aplikacji

ux — user expe­ri­ence, jest to ściśle pow­iązane z UI, ale różnicą jest że na UX wpły­wa także sama funkcjon­al­ność — np. czy użytkown­ik nie musi wykon­ać za dużo oper­acji żeby osiągnąć założony cel, czy aplikac­ja jest intu­icyj­na i pros­ta w uży­ciu, czy zaw­iera pomoc kon­tek­stową itp

unit testy (testy jed­nos­tkowe) — są to automaty­czne testy pisane przez samych pro­gramistów, które sprawdza­ją bard­zo wąs­ki wycinek sys­te­mu. Testy te są twor­zone najczęś­ciej w momen­cie pisa­nia kodu określonej funkcjon­al­noś­ci (od razu tworzymy wtedy unit testy które tą funkcjon­al­ność wery­fiku­ją). Są one uruchami­ane najczęś­ciej w momen­cie budowa­nia a ich celem jest wery­fikac­ja, czy wprowad­zone zmi­any nie zep­suły niczego, co dzi­ałało wcześniej w systemie

wdrażanie — o wdraża­niu mówimy najczęś­ciej w przy­pad­ku gotowych aplikacji sprzedawanych wielu klien­tom. W takiej sytu­acji opro­gramowanie to jest instalowane u klien­ta, cza­sa­mi także kopi­u­je się dane z ist­nieją­cych sys­temów. Pod poję­ciem ‘wdrażanie’ cza­sa­mi zaw­iera się także szkole­nie użytkown­ików w zakre­sie uży­wa­nia opro­gramowa­nia oraz dos­tosowanie pro­ce­dur fir­mowych do jego używania

 

Jeśli nie znalazłaś powyżej określe­nia które Cię ciekawi lub nie wiesz co oznacza, napisz w komen­tarzu — uzu­pełn­imy ten słowniczek!