Втора задача

  1. Мисля, че на Иван проблемът не му е, че ще получаваме json в който ще има ключове във snake_case, а по скоро това, че сте казали имплементацията на методите на Susi да използва такива променливи.

    func (s *Susi) AddStudent(request []byte) error
    func (s *Susi) FindStudent(faculty_number int) (*Student, error)
    func (s *Susi) AddCourse(request []byte) error
    func (s *Susi) FindCourse(course_identifier string) (*Course, error)
    func (s *Susi) Enroll(request []byte)  error
    func (s *Susi) FindEnrollment(faculty_number int, course_identifier string) (*Enrollment, error)
    // това е Go код
    

    И аз съм на мнение като Иван, че не би трябвало да използваме такива имена на променливи, независимо откъде идват данните.

    Ако все пак продължавате да сте на мнение, че променливите ни трябва да са с такива имена ни кажете.

    И ако е проблем да ни обясните сега, то когато мине крайният срок ще искаме подробно обяснение за това.

  2. @Илия, разбирам ви проблема.

    Няма значение как ще си кръстите аргументите, които получавате. В крайна сметка нас ни интересува да спазвате типовете и реда. Грешката там е наша.

    Нека да са facultyNumber и courseIdentifier, ще ги поправим в условието (скоро). Това няма по никакъв начин да промени задачата. Няма никаква разлика от гледна точка на тестовете между:

    func f(some_variable int, other_variable string) int
    func f(someVariable int, otherVariable string) int
    

    Понеже в езика нямаме именувани аргументи.

    Просто при писането на условието autocompletion-на е изневерил ;)

    А защо в json-а са snake_case може да ни питаш след края на срока за предаване.

  3. Навсякъде ли се очаква да връщам SusiError, дори когато не мога да сложа нито студент нито курс към него.

    Май и друго ви е изневерило :)

    ...Ние няма да се интересуваме как съхранявате елементите в този тип и единственно ще неговите методи...

  4. Там където може - да.

    Мисля че единствения случай в който не трябва да връщате SusiError е грешка в json-а.

    Но дори и да нямате Course или Student или и двете пак можете да върнете SusiError със двете бъдещи nil.

  5. Здравейте, имам въпрос относно тестовете които сте качили. След като си пусна тетовете, виждам грешка:

    homework_test.go:31: undefined: NewSusi

    FAIL homework1 [build failed]

    Въпроса ми е дали в мен е проблема или не ?

  6. Недовършени тестове. Някой ако има желание да храни е добре дошъл https://github.com/Bo0mer/golang-fmi/tree/master/homework/two За да ги пуснете ви трябва Ginkgo и Gomega. Повече инфо тук: https://github.com/onsi/ginkgo

    И още нещо - трябва ли да намалявам с 1 броя на местата за курс, след като запиша студент? :)

  7. @Иван, в тестовете ти не ми харесва, че за да си набавиш json, просто marshal-ваш текущата си структура. Това означава, че те ще вървят, дори и да не приемаш json-а, който ние сме казали, че ще подаваме.

    Относно въпроса ти - Да, нормално е след като студент се запише, местата да са с едно по-малко.

  8. В контекства си казвам Context("when the data is proper".... Това, че липсва тест който проверява точно че полетата се мапват както трябва е факт обаче. :)

    Edit: И като цяло, поправи ме ако греша, но всичките тия курсове и студенти би трябвало да са в отделен пакет (напр. model) и теста за Susi не би трябвало да се интересува те дали са коректно имплементирани (т.е. те ако имат някакви неща дето може да се счупят, е редно да си имат друг тест), защото аз искам да тествам поведението на Susi дали е правилно, а не на нещата на които то разчита. :)

  9. @Иван, не грешиш, че нещата може да са в различни пакети (специално за това дали да са в пакет model е под въпрос). Домашните се предават в един пакет и това е ограничение, с което условията трябва да се съобразят. Идеята на конкретното задание е да направите няколко типа, да се използват най-базовите интерфейси и да върнете подобаващи съобщения за грешка в определени ситуации.

    Нито са покрити всички възможни ситуации за грешка (можеше да има много повече валидации), нито работите с някакви бази от данни, където да се записва информацията.

    Грешката, за която аз говорих е, че ако аз си имплементирам типа Course по един начин, то Marshal -> json -> Unmarshal е нормално да ми въведе същият този курс, но в домашното ние тестваме срещу json данни, които ние предоставяме (дори сме ви дали една част от тях в примерните тестове), и нямаш никаква гаранция, че решение, което минава твоите тестове ще е реално вярно спрямо условието на домашното(и че ще мине нашите тестове).

  10. Глупав въпрос, но имам объркване относно връщането на грешки.

    " Трябва да използвате съобщенията за грешка от примерите в предишната секция - "Валидация"

    В тестовете си ще проверяваме за точно тези стрингове и ако върнатите от вас се различават дори с един байт теста няма да бъде успешен. "

    Как очаквате да се използва SusiError (който съдържа студент и курс), когато просто искате да връщаме стринг като грешка?

  11. @Стоян, виж интерфейса error. Нормално е да имате съобщение за грешка, което да го пазите в друг елемент от SusiError. Student и Course ги искаме ако примерно връщате грешка, че вече има такъв студент - да закачите студента към обекта за грешката, съответно за наличието на курс (закачате курса) или при наличието на enrollment (тогава може да ги закачите и двете).

  12. Имахме Pull request за промяна на един тест, понеже не сме написали същото съобщение в теста, каквото е в условието. Моля, хората с качени решения да обърнат внимание, другите да си pull-нат промените и да си оправят съобщението за грешка.

    Update: Още един Pull request -> pull -> go test.

  13. С най-последния pull request, това при мен пада:

    
    if !reflect.TypeOf(student).Elem().Implements(reflect.TypeOf((*fmt.Stringer)(nil)).Elem()) {
        t.Error("Student doesn't implement Stringer!")
     } 
    

    а редовете след горния (като го коментирам) минават:

    
      got := student.String()
      expected := "11111 Test One"
      if got != expected {
        t.Errorf("Student#String failed! Expected: %s, got: %s", expected, got)
      }
    

    Това не ми се струва нормално и не мисля, че проблемът е в кода ми :)

    Edit: Май си разбрах грешката

  14. Имам въпрос във връзка с AvailablePlaces в курсовете. Трябва ли да ги мутираме или това може да доведе до race condition-и и е по-добре да не разчитаме на проверка там, а да имаме нещо по-сигурно като механика (forgiveness > permission)?

    To clarify:

    1. При записване на студент трябва ли да се мутира course.AvailablePlaces?
    2. Ако отговорът е да, то ок ли е проверка и декрементиране или е добре да имаме и нещо по-thread safe?

    @Цветелина - много благодарим за тестовете - само след съответния pull request си забравила да си ъпдейтнеш теста (не че е проблем).

  15. mutex на Enroll мисля че ще ти свърши работа и ще ти реши главоболието но все пак ме съмнява че някой иска да го направим асинхроно все пак цялото нещо е Суси идеята му е да е бавно и от време на време да крашва така че ..

  16. @Илия не сме ви говорили за нишки и не очакваме нещата ви да са thread safe (все още). Скоро ще имате възможност да си играете и с такива задачи.

    Да трябва да се промени стойността на AvailablePlaces, когато студент бъде записан.

    Няма значение как ще го имплементираш, стига да работи. Всичко ще е в една нишка.

Трябва да сте влезли в системата, за да може да отговаряте на теми.