eDziennik (Ruby on Rails)

0

Póki co bez jakiejkolwiek autoryzacji. Co nieco już jednak działa :)
Github: https://github.com/baartoszsobczynski/e-school-reg
Live: https://e-school-reg.herokuapp.com/

Bardzo chętnie przeczytałbym krytykę @Shalom'a, ale wiem, że nie siedzi w Railsach :(

Są tutaj jacyś Railsowcy?

0

Póki co to stronka na razie to sam CRUD, który ma walidację w modelach + layout bootstrapowy. Szkoda, że walidacja nie jest opisana na stronie, bo użytkownik nie będzie zaglądał do kodu, aby poprawnie dodać przedmiot itp. ;) Ćwicz dalej- do rejestracji zrób samemu kontroler albo użyj Devise. Fajnie, że masz testy w SPECu.

0

Właśnie zamierzam to zrobić używając Devise. Staram się jak rozwiązać problem, aby jako uzytkownika uzywać modelu User, a pod tym trzymać sobie dopiero student czy teacher. Nie chcę mieć nulli w bazie, a nauczyciel nie będzie miał zadnych ocen. Jakaś porada? :)

0

Pytanie czy jedna tabela w bazie ma sens dla dwóch odmiennych rodzajów użytkownika, bo np. teacher będzie mógł podać dane kontaktowe, nazwę wydziału, przedmiot, który prowadzi itp. a uczeń ma zupełnie inne pola. Pomyślałbym o Userze jako o modelu abstrakcyjnym. Wtedy i teacher i student dziedziczą po nim.

0
Pipes napisał(a):

Pytanie czy jedna tabela w bazie ma sens dla dwóch odmiennych rodzajów użytkownika, bo np. teacher będzie mógł podać dane kontaktowe, nazwę wydziału, przedmiot, który prowadzi itp. a uczeń ma zupełnie inne pola. Pomyślałbym o Userze jako o modelu abstrakcyjnym. Wtedy i teacher i student dziedziczą po nim.

Będę wtedy miał 2 oddzielne login formy dla teachera i studenta, czego własnie chcę uniknąć. Czy coś źle rozumuję?

0

od razu możesz przejść na jasną stronę mocy i nie robić DHH way - czyli wyciągać logike z kontrolerów https://www.netguru.co/blog/service-objects-in-rails-will-help
bo teraz tworzyć np: usera w kontrolerze, to jest brzydkie, szczególnie w railsach
https://github.com/baartoszso[...]ollers/students_controller.rb
np:

 def update
    @school_class = SchoolClass.find(params[:id])
    if @school_class.update_attributes(school_class_params)
      flash[:success] = "School class updated"
      redirect_to @school_class
    else
      render 'edit'
    end
  end

nie od tego jest kontroler.

albo tutaj

  def link_to_school_class_if_available(student_id)
    student = Student.find(student_id)
    school_class_available = !student.school_class.nil?
    if school_class_available
      link_to "#{student.school_class.level}#{student.school_class.indication}", school_class_path(student.school_class.id)
    else
      "No class"
    end
  end

ja wiem że to jest active record, ale ... szukać studenta powinien serwis :D

0

Tak się nauczyłem od Hartl'a. Dzięki za odpowiedź, jutro się przyjrzę, przeanalizuję i spróbuję zrefaktoryzować.

1

Parę porad:

  • zamiast Devise użyj Sorcery - lżejsze i mniej zagmatwane
  • ffaker jest znacznie szybszy niż faker
  • używaj tego samego RDBMS przy testach i produkcji (przy developmencie najlepiej też), gdyż potrafi to czasem ukryć naprawdę paskudne bugi
  • dodaj .byebug_history do .gitignore, nikogo nie interesuje historia debuggera
  • zamiast StaticPagesController użyj gotowca jak high_voltage
  • czemu to jest w osobnej linii https://github.com/baartoszso[...]pp/models/school_class.rb#L14? Nie lepiej było zgrupować z resztą?
  • od siebie polecam Curly zamiast domyślnych widoków ERb, dzięki temu ograniczysz ilość logiki w widokach
  • dodaj
    config.generators do |g|
      g.helper              false
      g.stylesheets         false
      g.javascripts         false
    end

    do config/application.rb dzięki czemu nie będzie Ci generować zbędnych plików

  • ocenę składuj jako liczbę a nie ciąg znaków, to nie ma sensu składowanie tego jako stringa
  • używaj SimpleCov by mieć wgląd w pokrycie kodu
  • używaj brakeman by mieć listę issues w zależnościach i znajdować proste luki bezpieczeństwa
  • używaj rubocopa jeśli jeszcze tego nie robisz
  • używaj bullet by wykrywać N+1 queries
  • rack-mini-profiler + stackprof + flamegraph potrafią znacznie pomóc w benchmarkingu
  • database_cleaner to must have
  • Unicorn!/Puma/Passenger 5
  • Rolify + Pundit to fajne gemy do zarządzania uprawnieniami (jeszcze tego nie masz, ale się przyda w przyszłości)
  • escape_utils powinno poprawić wydajność
  • oceny powinny mieć wg. mnie historię, do tego jest fajny gem audited
  • annotate pomaga przy pisaniu walidacji w modelach
  • quiet_assets - STFU dla assetów w WebBrick
  • jest już RC do Railsów 5, co mogłoby Cię zainteresować
  • bundle outdated to jest fajna rzecz
  • faker raczej nie przyda się na produkcji
  • autoprefixer-rails!

To chyba było by na tyle.

0

Wohoho, dziękuję bardzo za ten post!
Połowa rzeczy które napisałeś to dla mnie czarna magia i nawet o nich nie słyszałem, ale.. już wiem za co powinienem się zabrać.
Gem'u Devise chciałbym użyć, gdyż uzywają go w tasku rekrutacyjnym do warsztatów w Netguru, a jest to firma do której bardzo chciałbym uderzyć.
Jeszcze raz dziękuję.

1

Poza tym jeszcze logi i tracking jeśli chcesz to udostępniać bardziej niż jako aplikację na Heroku. Jeśli chcesz to dystrybuować to polecam stworzyć kontener Dockera, który będzie zawierał Twoją aplikację (bazę danych miej osobno) razem z zależnościami. Dzięki temu znacznie łatwiej jest rozpowszechniać tą aplikację.

Co do Netguru to mam tam paru znajomych i są zadowoleni.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0