Ruby

'Konwencja ponad Konfigurację' to fundamentalna zasada, na której opiera się Ruby on Rails. Oznacza ona, że framework podejmuje za programistę wiele domyślnych, sensownych decyzji konfiguracyjnych w oparciu o zestaw przyjętych konwencji. Przykłady w praktyce: • Jeśli stworzymy model o nazwie `User`, Rails automatycznie założy, że odpowiadająca mu tabela w bazie danych nazywa się `users`. • Kontroler o nazwie `UsersController` będzie automatycznie powiązany z widokami w katalogu `app/views/users/`. • Nazwa metody w kontrolerze, np. `index`, będzie domyślnie renderować widok `index.html.erb`. Główne korzyści: 1. Szybkość rozwoju: Programista nie musi tracić czasu na pisanie obszernej konfiguracji, która w 90% przypadków wyglądałaby tak samo. Może od razu skupić się na pisaniu logiki biznesowej. 2. Czytelność i łatwość utrzymania: Dzięki konwencjom, kod jest bardziej przewidywalny. Każdy deweloper znający Rails wie, gdzie szukać poszczególnych elementów aplikacji. Programista musi pisać kod konfiguracyjny tylko wtedy, gdy chce świadomie złamać konwencję i zrobić coś w niestandardowy sposób.

Choć wyglądają podobnie, symbole i stringi to dwa różne typy obiektów o odmiennym przeznaczeniu i zachowaniu w pamięci. • Stringi (`'string'` lub `"string"`): - Są mutowalne, co oznacza, że ich zawartość można modyfikować w miejscu. - Każdy literał stringa w kodzie tworzy nowy, osobny obiekt w pamięci, nawet jeśli mają tę samą treść. • Symbole (`:symbol`): - Są niemutowalne – nie można ich zmienić po utworzeniu. - Co najważniejsze, są unikalne i internalizowane. Oznacza to, że dla danej nazwy (np. `:name`) istnieje tylko jeden obiekt symbolu w całej aplikacji. Każde użycie `:name` odwołuje się do tego samego obiektu w pamięci. Kiedy używać symboli? Ze względu na ich wydajność, symbole są standardowym i preferowanym sposobem na używanie kluczy w hashach (odpowiednikach słowników). ```ruby user = { name: 'Jan', email: 'jan@example.com' } // Użycie symboli jako kluczy ``` Porównywanie symboli jest znacznie szybsze niż porównywanie stringów (porównywane są tylko referencje, a nie zawartość), a ich użycie jako kluczy zużywa mniej pamięci.

Wszystkie trzy są formą domknięć (closures) w Ruby – obiektami, które opakowują fragment kodu i mogą być wykonywane później. Różnią się jednak składnią i zachowaniem. • Bloki: - To fragmenty kodu (`do ... end` lub `{...}`), które można przekazać do metody jako 'niejawny' argument. Nie są one obiektami i nie można ich przypisać do zmiennej. • Proc (procedury): - To obiekt, który opakowuje blok, co pozwala na przypisanie go do zmiennej i wielokrotne użycie. Tworzy się go za pomocą `Proc.new { ... }`. - Proc ma 'luźne' podejście do argumentów – nie rzuci błędem, jeśli przekażemy mu złą liczbę argumentów. • Lambda: - To również obiekt, specjalny rodzaj Proc-a. Tworzy się go za pomocą `lambda { ... }` lub `-> { ... }`. - Lambda zachowuje się bardziej jak 'zwykła' metoda. Jest rygorystyczna co do liczby argumentów – rzuci błędem, jeśli przekażemy ich za mało lub za dużo. Najważniejsza różnica w zachowaniu dotyczy słowa `return`: - `return` wewnątrz lambdy powoduje powrót tylko z tej lambdy. - `return` wewnątrz Proc-a powoduje powrót z metody, w której ten Proc został wywołany, co może prowadzić do nieoczekiwanych rezultatów.

ActiveRecord to fundament modelu w architekturze MVC frameworka Ruby on Rails. Jest to biblioteka, która implementuje wzorzec projektowy ORM (Object-Relational Mapping), a konkretnie jego wariant zwany Active Record. Jego głównym zadaniem jest działanie jako tłumacz między obiektowym światem Ruby a relacyjnym światem bazy danych SQL. Dzięki ActiveRecord: • Każda tabela w bazie danych jest mapowana na klasę Ruby (model). Na przykład, tabela `users` jest reprezentowana przez model `User`. • Każdy wiersz w tabeli jest reprezentowany przez instancję tej klasy. • Kolumny w tabeli odpowiadają atrybutom obiektu. ActiveRecord dostarcza bogaty i intuicyjny interfejs do interakcji z bazą danych w sposób obiektowy, bez potrzeby pisania surowego kodu SQL. Pozwala na łatwe wykonywanie operacji CRUD (Create, Read, Update, Delete), definiowanie relacji między modelami, przeprowadzanie walidacji danych i wykonywanie złożonych zapytań za pomocą czytelnego API. ```ruby // Zamiast pisać 'SELECT * FROM users WHERE active = true;' active_users = User.where(active: true) ```

Migracje to mechanizm w Ruby on Rails, który pozwala na ewolucyjne i wersjonowane zarządzanie schematem bazy danych za pomocą kodu Ruby, a nie surowego SQL. Każda migracja to mały plik w katalogu `db/migrate/`, który opisuje jedną, konkretną zmianę w strukturze bazy, np. utworzenie nowej tabeli, dodanie kolumny, czy stworzenie indeksu. Każdy plik ma unikalny znacznik czasu, co zapewnia ich wykonywanie w odpowiedniej kolejności. ```ruby class CreateProducts < ActiveRecord::Migration[7.0] def change create_table :products do |t| t.string :name t.decimal :price t.timestamps end end end ``` Dlaczego są tak ważne? 1. Kontrola wersji bazy danych: Migracje są przechowywane w systemie kontroli wersji (np. Git) razem z resztą kodu. Dzięki temu historia zmian w bazie jest udokumentowana i łatwa do prześledzenia. 2. Spójność środowisk: Zapewniają, że struktura bazy danych jest identyczna na maszynie każdego dewelopera oraz na serwerach deweloperskich, stagingowych i produkcyjnych. Wystarczy uruchomić polecenie `rails db:migrate`, aby doprowadzić bazę do aktualnego stanu. 3. Niezależność od bazy danych: Kod migracji jest abstrakcyjny, a Rails sam tłumaczy go na odpowiedni dialekt SQL dla używanej bazy danych (PostgreSQL, MySQL, SQLite).

Bundler to menedżer zależności dla aplikacji Ruby. Jest to kluczowe narzędzie, które zapewnia, że każda aplikacja ma spójny i odtwarzalny zestaw bibliotek (gemów). Jego działanie opiera się na dwóch plikach: • `Gemfile`: To plik, w którym deklarujemy, jakich gemów potrzebuje nasza aplikacja. Określamy w nim nazwy gemów i, opcjonalnie, wymagane wersje (np. `gem 'rails', '~> 7.0'`). Jest to nasza 'lista życzeń'. • `Gemfile.lock`: To plik generowany automatycznie przez Bundlera po uruchomieniu polecenia `bundle install`. Zapisuje on dokładne wersje wszystkich zainstalowanych gemów – zarówno tych, które zadeklarowaliśmy w `Gemfile`, jak i wszystkich ich zależności. Ten plik jest 'zamrożonym' stanem naszego środowiska. Dlaczego `Gemfile.lock` jest tak ważny? Zapewnia on odtwarzalność i spójność. Gdy inny deweloper pobierze projekt i uruchomi `bundle install`, Bundler zainstaluje dokładnie te same wersje gemów, które są zapisane w `Gemfile.lock`, a nie najnowsze dostępne. Eliminuje to problemy typu 'u mnie działa, a u ciebie nie' i gwarantuje, że środowisko na serwerze produkcyjnym jest identyczne jak na maszynie deweloperskiej.