Wpis z mikrobloga

@buntuubuntu: robisz tabele Day ktory ma jedno pole i to jeszcze datetime zamiast date. w profilu dales pole m2m do day przez drinkingday, troche bez sensu. tabela day nie powinna istniec, drinkingday powinien miec klucz obcy do User a Profil nie powinien miec pola days.

zalogowany uzytkownik powinien miec mozliwosc edycji tylko wlasnego profilu, jestes pewny, ze nie mozna edytowac czyjegos profilu? ;-)

zapytanie o profil ( w api) tez powinno
  • Odpowiedz
@filozof900: dzięki, zupełnie nie koncentrowałem się na modelach (w domyśle chce zrobić sobie kalendarz gdzie można będzie robić zapiski i tworzyć eventy.

Idea tego jest taka, żeby spisać od początku do końca jak skonfigurować projekt, zrobić CI/CD (deployment na heroku albo jakieś AWS/Azure), napisać i odpalać testy, a na końcu wrzucić to do dockera.

Większość API które tworzymy nie ma dokumentacji, endpointy są nazywane z dupy, CI/CD kuleje, a autoryzacje są
  • Odpowiedz
@buntuubuntu: idea jest taka, ze na kazdym etapie program ma dzialac poprawnie i z czasem dodajac nowe funkcjonalnosci masz go tylko rozszerzac, a nie naprawiac. tworzenie nowych tabel to jest ogolnie duza sprawa, bo pozniej migracja to jest na prawde duza sprawa.

niestety widzialem wiele takich projektow (z wyciekiem danych wlasnie bo ktos dodal email do serializera do odczytu, z miksem kluczy do profilu i do usera bo wlasnie ktos chcial
  • Odpowiedz
1. Przy tworzeniu requirementsów możnaby napisać że to rozwiązanie tymczasowe, lecz dość ryzykowne ( ͡° ͜ʖ ͡°)
2. Serio nie rozumiem tendencji rozbijania uzytkownika na "uzytkownika" i "profil". Przecież Djagno oferuje mozliwosc używania wlasnego modelu to uwierzytelniania, dlaczego by nie skorzystać? Czemu ma służyć na struktura?
3. Sygnały to surprise driven development ( ͡° ͜ʖ ͡°)
4. Jeżeli piszesz po angielsku to użyj czegoś
  • Odpowiedz