Choinka programisty Ruby
Czy programiści Ruby 💎 programują swoje choinki 🎄 święteczne?
Wszystkich programistów i programistki, miłośników i sceptyków, profesjonalistów i hobbistów języka Ruby zapraszamy we wtorek (11.02.2020) o 18:00 na Rubiowe spotkanie w Gliwicach. Tym razem spotkanie odbędzie się w Beer Brothers na Górnych Wałów 30.
Tradycyjnie już spotkanie programistów Ruby w Gliwicach będzie składało się z trzech prezentacji oraz networkingu. Poniżej programistyczne tematy, przydatne dla każdego, kto choć trochę liznął branżę:
Jeśli tematy Wam się podobają (w co nie wątpimy), to przybywajcie na jedyne takie spotkanie programistów Ruby w Gliwicach, a nawet na całym Śląsku. Zachęcamy do aktywnego uczestnictwa w spotkaniu i zawsze z miłą chęcią witamy nowe twarze. 🎤
Kilkanaście osób (programistki i programiści) z niecierpliwością czekało na rozpoczęcie spotkania. Przy okrągłych stolikach trwały jeszcze ostatnie rozmowy o Ruby, Railsach, JavaScript, Elixirze, Postgresie i innych technologiach. Niektórych programistów nie widzieliśmy kilka miesięcy, a niektórych nawet kilka lat. Zawsze jednak miło jest powspominać stare czasy oraz uaktualnić informacje kto się czym zajmuje. Czasem jest to zmiana projektu albo firmy, a czasem nawet używanych technologii. Najważniejsze jednak, że nawet jak ktoś przesiadł się na inną technologię to prędzej czy później wraca na nasze rubiowe spotkania do Gliwic.
Meetup rozpoczęła prezentacja o PostgreSQL-u. Temat może nie jest bezpośrednio związany z językiem Ruby, ale większość aplikacji pisanych w Ruby on Rails korzysta z bazy danych PostgreSQL. W pierwszych minutach była mowa o nowej funkcjonalności, która pojawiła się w PostgreSQL 12, czyli o generowanych kolumnach (ang. generated columns). Przykład użycia generated columns poniżej:
CREATE TABLE people (
...,
height_cm NUMERIC,
height_in NUMERIC GENERATED ALWAYS AS ( height_cm / 2.54 ) STORED
);
Omówione zostały też ograniczenia (ang. constraint) nakładane na kolumny oraz porównanie ich do walidacji występujących w Ruby on Rails.
CREATE TABLE products (
product_no integer,
name text,
price numeric CONSTRAINT positive_price CHECK (price >= 0)
);
Kolejne rady polegały na stosowaniu “CONSTRAINT TRIGGER”, które umożliwiają uruchamianie funkcji w odpowiednich warunkach. W wielu przypadkach pozwala to uniknąć wywołań typu Active Record Callbacks.
CREATE FUNCTION update_position()
RETURNS trigger AS
$func$
BEGIN
NEW.position := NEW.position + 1;
RETURN NEW;
END
$func$ LANGUAGE plpgsql;
CREATE CONSTRAINT TRIGGER update_product_positions
AFTER INSERT OR UPDATE ON products
DEFERRABLE
FOR EACH ROW EXECUTE PROCEDURE update_position();
Oczywiście nie obyło się na spotkaniu bez dyskusji wśród programistów rubiego na temat praktycznych zastosowań przedstawionych trików. To właśnie ta część wymiany wiedzy oraz doświadczeń jest najcenniejsza. Na koniec poruszona została sprawa czytelności i zrozumienia przez resztę zespołu tego typu zapisów. Okazało się, że można w łatwy sposób tworzyć testy na bazę danych, co w efekcie zwiększa czytelność i gwarantuje działanie wprowadzonych rozwiązań. Polecane do tego narzędzie to pgTAP. Poniżej prosta asercja (ang. assertion) w SQL-u:
-- Is the ultimate answer 42?
SELECT is( ultimate_answer(), 42, 'Meaning of Life' );
Po krótkiej przerwie kolejna prezentacja dotyczyła procesu budowania aplikacji. W przedstawionym przykładzie zespół deweloperski nie uczestniczył podczas określania wymagań (ang. requirements) klienta. Dodatkowo designerzy przygotowywali projekty graficzne przedstawiające jedynie podstawowe widoki i nie określali szczegółowych zachowań aplikacji. Powodowało to, że programiści często musieli dopytywać się jak powinien wyglądać projekt, ponieważ mieli zdefiniowaną tylko “zieloną ścieżkę” (ang. happy path). Wielu programistów Ruby w Gliwicach była zaskoczona tym, że w dzisiejszych czasach (rok 2020) nadal można trafić na firmy / korporacje, które w tak toporny sposób podchodzą do tworzenia oprogramowania. I nie chodzi tu wcale o to, aby wszyscy stosowali metodyki Agile, ale o zdroworozsądkowe podejście i planowanie. Uważamy, że w określaniu wymagań aplikacji powinny uczestniczyć nie tylko osoby powiązane z biznesem, ale również osoby mocno techniczne, które będą w stanie pomóc biznesowi i zadać odpowiednie pytania. Wspomniano również o narzędziu Zeplin.io, które ma służyć do współpracy pomiędzy designerami a developerami. Poza tym jest wiele aplikacji pozwalających prototypować i tworzyć UI mockupy (Balsamiq, MockFlow, InVision czy open source’owy Pencil Project).
Ostatnia prezentacja poruszyła wszystkich. Tuż przed rozpoczęciem kilku Ruby developerów z Gliwic i okolic zgłaszało się, że “to” mają. Oczywiście “To” nie oznaczało powieści Stephena Kinga, którą aktualnie kojarzyć można, przez adaptacje filmową, z czerwonym balonikiem. 🎈 W tym przypadku programiści Ruby poprzez “to” mieli na myśli wypalenie zawodowe i jego symptomy. Zaskoczeniem dla większości było to, że syndrom wypalenia zawodowego nie jest uznawany za jednostkę chorobową. Przedstawione zostały symptomy różnego typu (fizjologiczne, społeczne, intelektualne, emocjonalne, duchowe) po których można rozpoznać wypalenie u siebie. Agnieszka omówiła krzywą stresu oraz czynniki zewnętrzne i wewnętrzne, które wpływają na poziom stresu. Na koniec zaproponowanych zostało kilka sposobów na radzenie sobie ze stresem. Temat ten wywołał dyskusję, w którą włączali się doświadczeni programiści jak i programiści z krótszym stażem zawodowym. Prezentację można obejrzeć na stronie womanonrails.com/presentations, a link do artykułu w tym temacie podany został już powyżej w sekcji z tematami.
Starym zwyczajem, po zakończeniu wszystkich prezentacji rozpoczął się upragniony networking. Każdy programista 👨💻 lub programistka 👩💻, a w szczególności programiści Ruby potrafią docenić ten moment. Można na spokojnie wymieniać się doświadczeniami i zadać pytania prelegentom, jeśli wcześniej nie miało się na to odwagi lub pomysłu. Wszystkim, którzy byli na SRUG-u jeszcze raz dziękujemy i zapraszamy w imieniu całej społeczności Ruby w Gliwicach na kolejne spotkanie.
Zostaw komentarz