Czy jest szansa na udostępnianie rozwiązań zadań do przeanalizowania na spokojnie bez rozbieganych oczek? :)

Mam pytanie czy prezentacje z zajęć będą gdzieś dostępne?

Mam problem z instalacją ( a właściwie uruchomieniem ) railsów.
Ogólnie dotyczy to problemu z sqlite3.
Przeczytałem ze dwa wątki na stacku, znalazłem coś co miało być pożądanym plikiem sqlite3.h jednak nadal coś jest nie tak, czy ktoś może miał podobny problem?

Issue: Domyślna ścieżka renderu widoku dla bestiary_controller jest błędna.

Z tego co widzę to przy generowaniu kontrolera za pomocą cli
rails g controller bestiary
Otrzymamy w app/controllers/bestiary_controller.rb i to się zgadza.
Aczkolwiek z nieznanego mi powodu
app/views również posiada bestiary_controller, gdzie powinno być samo bestiary (przynajmniej tak domyślnie jest tworzone przez cli: app/views/bestiary). Konsekwencją błędnej ścieżki jest niewyrenderowany widok.

Solution:
Jedyną poprawką do wykonania, aby domyślnie wszystko się spieło to poprawa nazwy folderu we views z bestiary_controller na samo bestiary.

Co prawda jest to błąd nieprzeszkadzający w rozwiązaniu zadania domowego, ale jednak błąd.

Po wysłaniu formularza dla nowego utworu (po zdefiniowaniu walidacji) input dla artysty zmienia się z select na input typu number.

Dzieje się tak, dlatego że zmienna @artists po render 'new' ma wartość nil, ponieważ jest przekazana callbackiem before_action, a przy błędzie w formularzu akcja new nie jest wywoływana ponownie. Tak samo dzieje się dla edit.

Fix:

Ponowne wywołanie metody set_artists_collection przed akcjami create/update naprawia błąd, ale nie wiem czy to najlepsze wyjście z sytuacji.

  before_action :set_artists_collection, only: %i[new create edit update]

Chciałbym zwrócić uwagę na problem podnoszenia poziomu postaci. Odpowiem w tym issue na pytanie gdzie powinna być zlokalizowania jego logika.

Większość z was rozwiązała problem następująco:

class Character; end

class Monster < Character; end

class Warrior < Character
  def level_up(param)
     do_sth(param)
  end
end

class BattleArena
  def battle!
     ...
     winner.level_up if winner.is_a?(Warior)
  end
end

Jest okej, jednak logika jest w tej chwili mocno podzielona między dwie klasy. Co jeśli dojdą później inne klasy mogące podnosić poziom? Będziemy musieli robić coś takiego [Klass1, Klass2, Klass3].any?{ |klass| winner.is_a?(Warrior) }. Część z was użyła też winner.respond_to?(level_up) co pozwoliłoby uniknąć takiej sytuacji.
Jednak tak naprawdę klasę BattleArena nie powinno interesować czy ma doczynienia z ghoulem czy paladynem - ona pozwala zorganizować spotkanie dwóch postaci i ustalić wynik - nic więcej. To czy wygrany wyciągnie z niej lekcje i zwiększy mu się poziom - to już jego problem.

Propozycja z mojej strony:

• definiujemy podstawowe zachowanie level_up w klasie Character
• nadpisujemy to zachowanie w klasie Monster lub Warrior (w tym przypadku Warrior brzmi sensowniej, ale z reguły takie wybory zależą od danego kontekstu, oceny sytuacji, w której domyślne zachowanie wykona się przez przypadek czy stosowania metody DRY)

class Character
  def level_up(param); end # do nothing - default behaviour
end

class Monster < Character; end

class Warrior < Character
  def level_up(param)
     do_sth(param)
  end
end

class BattleArena
  def battle!
     ...
     winner.level_up(param)
  end
end

Przy podaniu w konsoli komendy
player_manager = FootballPlayerManager.new(player)
wyskakuje mi błąd : Unable to autoload constant FootballPlayerManager, expected E:/Rails/Exercise/App/services/football_player_manager.rb to define it.
Póki co w pliku football_player_manager.rb jest jego oryginalna zawartość a ścieżki są właściwe (nawet jeżeli teraz zrobiłem literówki przepisując je). Ścieżki są takie jakie są, gdyż pliki u mnie są tak właśnie zlokalizowane. Czy to jest jakaś kwestia związana z traktowaniem plików z katalogu services – a jeżeli tak, to gdzie o tym przeczytać, czy chodzi o coś innego ( a jeżeli tak, gdzie szukać wskazówek)? Zakładam że plik nawet w postaci pierwotnej powinien tworzyć instancję swojej klasy. 'player' jest zdefiniowany i ma wartości.

Dlaczego w TracksController przy próbie wywołania

obiekt @playlist_tracks jest typu nil w widoku Tracks? W routes.rb nie dodawałem żadnej ścieżki, czy problem leży w tym, że w danym kontrolerze nie możemy korzystać z innych modelów?

Mam mały problem, zdefiniowałem sobie cały model, stworzyłem tabelę w bazie danych, ale za każdym razem gdy chcę utworzyć instancję modelu, rails wywala mi to:

Tak jakby gubi wszystkie wartości atrybutów.

Właściwie miałbym pytanie o wyprowadzenie danych 'na widok'. O ile wszystko dobrze zrozumiałem nie należy łączyć logiki i prezencji. W takim razie nie bardzo rozumiem jak wyświetlić wielokrotnie te dane potworów między parą odpowiednich tagów. Nie ma problemu z wygenerowaniem tabeli czy czegokolwiek, ale ta tabela będzie między jedną parą tagów HTML w całości. Chyba że rozwiązaniem OK jest wypisaniem w widoku 20 czy tam ilu powtarzalnych sekwencji ale to nie jest DRY. Na pewno przeoczyłem coś oczywistego, ktoś mnie naprowadzi?

Literówka w modelu Track powoduje błąd przy wywołaniu metody playlists.

ActiveRecord::HasManyThroughAssociationNotFoundError:
Could not find the association :playlist_track in model Track

Brakuje 's' w :playlist_tracks

  has_many :playlists, through: :playlist_track

attr_reader :foo tworzy metodę getter w klasie:

def foo
  @foo
end

attr_writer :foo tworzy metodę setter w klasie:

def foo=(value)
  @foo = value
end

attr_accessor :foo tworzy metody setter i getter w klasie:

def foo
  @foo
end

def foo=(value)
  @foo = value
end

Kiedy w klasie mamy gettera możemy odczytywać zmienną instancji @foo przez metodę foo, czyli nie musimy pamiętać o @ wewnątrz klasy i możemy odczytywać ją z innego obiektu:

class Test
  attr_reader :foo
  
  def initialize(number)
    @foo = number * 2 
  end

  def result
    "result = #{foo}"  # foo bez @
  end
end

test = Test.new(10)
test.result #=> "result = 20"
test.foo #=> 20
test.foo = 50 #=> NoMethodError (undefined method `foo=' for <Test:...>)

Ostatnia linijka zwraca błąd ponieważ nie użyliśmyattr_writer :foo lub attr_accessor :foo do zdefiniowania settera.

Kiedy warto korzystać z getterów / setterów?

Poniżej zamieszczono przykłady z zadania nr 2, jednak użyłem ich tylko dlatego, aby przybliżyć problem. Nie stanowią one "poprawnego sposobu" wykonania zadania.
Do parametrów initializerów dodałem suffix _param, aby odróżnić parametry od definiowanych atrybutów.

1. Jeśli chcemy odczytywać level postaci poza klasą Warrior / Monster musimy ustawić attr_reader :level jako metoda publiczna - czyli nie pod keywordem protected czy private. Pamiętaj, że możesz po przecinku dodać więcej atrybutów

class Monster < Character
  attr_reader :level, :name

  def initialize(name_param:, level_param:)
    @name = name_param
    @level = level_param
  end
end

andariel = Monster.new(name_param: 'Andariel', level_param: 5)
andariel.name # => Andariel
andariel.level # => 5

2. Jeśli chcemy zmienić wartość levelu postaci poza jego klasą, np w klasie BattleArena, powinniśmy zdefiniować attr_writer :level(przypominajka: attr_writer + attr_reader = attr_accessor ) także jako metoda publiczna

class Warrior < Character
  attr_reader :name
  attr_accessor :level

  def initialize(name_param:, level_param:)
    @name = name_param
    @level = level_param
  end
end

barbarian = Warrior.new(name_param: 'Barbarian', level_param: 5)
barbarian.name # => Barbarian
barbarian.level = 10
barbarian.level # => 10

3. Jeśli w klasie BattleArena mamy dwie zmienne instancji, np first_character i second_character i nigdzie poza klasą ich nie używamy możemy użyć attr_reader :first_character, :second_character w sekcji prywatnej. Dlaczego nie używać po prostu @first_character i @second_character do odczytu zmiennych instancji? Zauważ, że kiedy zrobisz literówkę i wpiszesz first_chararter ruby zareaguję odrazu krzycząc - undefined method first_chararter, kiedy jednak wpiszesz @first_chararter, ruby zwróci nil i przy niepoprawnie działającej aplikacji może nie zwrócić błędu wcale. 😨

class BattleArena
  def initialize(first_character_param:, second_character_param:)
    @first_character = first_character_param
    @second_character = second_character_param
  end

  def battle!
    first_character # access to first character
    second_character # access to second character
  end

  private

  attr_reader :first_character, :second_character
end

battle = BattleArena.new(first_character_param: character1, second_character_param: character2)
battle.first_character # => NoMethodError (private method `first_character' called for #<BattleArena:...>)