Woman on Rails

Alek Od czasu do czasu programując w języku Ruby, a nawet częściej używając frameworka Ruby on Rails, potrzebuję stworzyć plik konfiguracyjny zawierający na przykład prywatne klucze do API. Oczywiście nie chcę tych danych śledzić w systemie kontroli wersji. Natomiast na dodanie ich do bazy danych jest jeszcze za wcześnie. W takiej sytuacji mogą pomóc zmienne środowiskowe zapisane w pliku .env. W tym przypadku jest jeszcze jeden mały haczyk. Chciałam by wszystkie dane były ustrukturyzowane w jednym pliku. Dlatego też użyłam kombinacji pliku YAML (akronim rekurencyjny od ang. YAML Ain’t Markup Language) ze zmiennymi środowiskowymi i ERB (Embedded Ruby). Oto jak wygląda to rozwiązanie.

W czasach łatwego dostępu do Internetu i ciągłych powiadomień mamy duży problem z utrzymaniem skupienia. Skupienie jest nam potrzebne by efektywnie wykonywać swoją pracę, ale też by osiągnąć flow. Jeden z najistotniejszych stanów, jakich możemy doświadczyć podczas pracy. Flow to stan umysłu, w którym jesteśmy w pełni zanurzeni i zaangażowani w bieżącą czynność. To bardzo pozytywne zjawisko, które nie tylko dodaje nam energii, ale też dostarcza satysfakcji z tego co robimy. Jest tylko jeden problem. Jak doświadczyć flow w świecie pełnym wszelkiego rodzaju “rozpraszaczy”. Dodatkowo w czasach gdy duża część z nas pracuje z domów. Chciałabym się podzielić z Tobą kilkoma trikami, które pomagają mi się skupić i częściej korzystać z flow.

Gdy pojawiają się nowości w naszym języku programowania czasami jesteśmy z tego powodu zadowolone, a czasami nie. Dziś chciałabym porozmawiać o zmianach, z których ja osobiście bardzo się cieszę. Mam na myśli dopasowanie do wzorca w języku Ruby, czyli pattern matching. Jakiś czas temu napisałam artykuł na temat Pattern Matching-u w języku Ruby. Zachęcam do zapoznania się z nim, ponieważ będę odwoływała się do omawianych tam przykładów. A teraz zanurzmy się jeszcze bardziej w świat dopasowania do wzorca w języku Ruby. Zaczynamy!

Kiedy tworzysz aplikację internetową od czasu do czasu potrzebujesz zapisać aktualny wygląd strony, nad którą właśnie pracujesz. W większości przypadków pewnie korzystasz z klawisza Print Screen na klawiaturze. Później, oczywiście jeżeli korzystasz z systemu operacyjnego Linux, wystarczy tylko otworzyć zapisany zrzut ekranu w edytorze graficznym takim jak GIMP i wyciąć interesujący Cię fragment. Możesz też spotkać się z trochę inna sytuacją. Chciałabyś zapisać aktualny stan całej strony, a nie tylko wybranego fragmentu. Wtedy albo robisz kilka zrzutów z ekranu i próbujesz je połączyć w programie graficznym albo korzystasz z dodatku, który zapisze Ci wygląd całej strony. Na szczęście jest też prostsze rozwiązanie. Można skorzystać z wbudowanej w przeglądarkę funkcji robienia zrzutów ekranu. Sprawdźmy jak to działa.

W jednym z moich ostatnich artykułów pisałam na temat poprawiania czytelności nazw w projekcie. Jednym ze sposobów, o którym pisałam było powiedz jakiego wzorca używasz. Jakiś czas później przeczytałam newsletter od Sandi Metz > “Don’t Name Classes After Patterns. Mostly”. Sandi przedstawia tam inny punkt widzenia na używanie nazw wzorców w nazwach klas, z małym wyjątkiem. Myślę, że to dobry temat by na chwilę się nad tym zastanowić. W programowaniu nie ma jednej złotej zasady, jak tworzyć nazwy. Są wskazówki, jak to robić, ale one maja nam tylko pokazać drogę. Nie są jedynym źródłem prawdy. Każde rozwiązanie ma swoje wady i zalety, dlatego dobrze mieć szerszą perspektywę na problem z jakim się mierzymy.

Jakiś czas temu uczestniczyłam w Instagramowym wyzwaniu #30devstories. Podczas tego wyzwania ja i inni twórcy przygotowaliśmy mnóstwo przydatnych materiałów. Dzieliliśmy się swoją wiedzą na przeróżne tematy. Bardziej lub mniej programistyczne. Ponieważ treści te były tworzone w takim dość ulotnym formacie jakim jest Instagram Story, postanowiłam, że podzielę się nimi z Tobą w bardziej trwałej wersji. Rozpoczniemy od TDD, czyli Test Driven Development. Szczegółowo o tym jak wygląda praca z TDD pisałam w artykule TDD - Wprowadzenie. Dziś jednak chciałabym się podzielić krótką notatką o podstawach TDD.

Jako programiści często rozmawiamy o wysokopoziomowej architekturze. Mam tu na myśli DDD, architekturę heksagonalną i tym podobne. Chcemy wprowadzić choć część tych koncepcji do naszego projektu. I to najlepiej, teraz! Nowa architektura, nowy język programowania, nowy framework. Wpadamy w taką pułapkę nowinek technologicznych. Są one jak narkotyk. Chcemy więcej i więcej. Trochę nie myśląc przy tym o konsekwencjach. Cel jest szczytny. Chcemy mieć nowoczesny, dobrej jakości projekt, który łatwo da się dalej rozwijać. Niestety, trochę gubimy się w tym jak to osiągnąć. Nasz projekt potrzebuje ewolucji, a nie rewolucji. Dążenia małymi kroczkami do dobrej architektury. Jest to istotne, ale trudne do osiągnięcia. Potrzeba tu przede wszystkim cierpliwości i jasnego celu. Dziś zajmę się tematem, który jest właśnie takim małym kroczkiem do zbudowania dobrej architektury. Jest to odpowiednie nazywanie rzeczy

Do zarządzania pakietami JavaScript używam w projekcie yarn-a. Kilka dni temu potrzebowałam dodać bardzo konkretną wersję pakietu z repozytorium znajdującego się na GitHub-ie. Tą krótką notatkę tworzę przede wszystkim by nie zapomnieć jak dodać pakiet z GitHub-a przy pomocy yarn-a. Mam nadzieję, że dla Ciebie też okaże się użyteczna. W przyszłości planuje więcej takich krótkich wpisów z cylku “Today I learned”.