Тук е мястото да питате, ако има нещо неясно по условието на втора задача. Примерният тест е тук.
Прочетете внимателно как да (не) си изпращате задачите :)
Тук е мястото да питате, ако има нещо неясно по условието на втора задача. Примерният тест е тук.
Прочетете внимателно как да (не) си изпращате задачите :)
faculty_number? course_identifier?
Иване, не те разбирам. Използвай повечко думички и даже цели изречения.
Предполагам не му харесва че са snake_case
, но реално това са елементи от JSON обект, а не Go код. И да кажем, че си имаме причина да ви ги дадем snake_case
:)
Мисля, че на Иван проблемът не му е, че ще получаваме 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 код
И аз съм на мнение като Иван, че не би трябвало да използваме такива имена на променливи, независимо откъде идват данните.
Ако все пак продължавате да сте на мнение, че променливите ни трябва да са с такива имена ни кажете.
И ако е проблем да ни обясните сега, то когато мине крайният срок ще искаме подробно обяснение за това.
@Илия, разбирам ви проблема.
Няма значение как ще си кръстите аргументите, които получавате. В крайна сметка нас ни интересува да спазвате типовете и реда. Грешката там е наша.
Нека да са facultyNumber
и courseIdentifier
, ще ги поправим в условието (скоро). Това няма по никакъв начин да промени задачата. Няма никаква разлика от гледна точка на тестовете между:
func f(some_variable int, other_variable string) int
func f(someVariable int, otherVariable string) int
Понеже в езика нямаме именувани аргументи.
Просто при писането на условието autocompletion-на е изневерил ;)
А защо в json-а са snake_case
може да ни питаш след края на срока за предаване.
Навсякъде ли се очаква да връщам SusiError, дори когато не мога да сложа нито студент нито курс към него.
Май и друго ви е изневерило :)
...Ние няма да се интересуваме как съхранявате елементите в този тип и единственно ще неговите методи...
Там където може - да.
Мисля че единствения случай в който не трябва да връщате SusiError
е грешка в json
-а.
Но дори и да нямате Course
или Student
или и двете пак можете да върнете SusiError
със двете бъдещи nil
.
Здравейте, имам въпрос относно тестовете които сте качили. След като си пусна тетовете, виждам грешка:
homework_test.go:31: undefined: NewSusi
FAIL homework1 [build failed]
Въпроса ми е дали в мен е проблема или не ?
@Йосиф, най-вероятно проблема е в теб, не си дефинирал функцията NewSusi
.
@Илия @Иван, поправено, може да го прегледате, ако имате и други критики. :)
Недовършени тестове. Някой ако има желание да храни е добре дошъл https://github.com/Bo0mer/golang-fmi/tree/master/homework/two За да ги пуснете ви трябва Ginkgo и Gomega. Повече инфо тук: https://github.com/onsi/ginkgo
И още нещо - трябва ли да намалявам с 1 броя на местата за курс, след като запиша студент? :)
@Иван, в тестовете ти не ми харесва, че за да си набавиш json, просто marshal-ваш текущата си структура. Това означава, че те ще вървят, дори и да не приемаш json-а, който ние сме казали, че ще подаваме.
Относно въпроса ти - Да, нормално е след като студент се запише, местата да са с едно по-малко.
В контекства си казвам Context("when the data is proper"...
. Това, че липсва тест който проверява точно че полетата се мапват както трябва е факт обаче. :)
Edit:
И като цяло, поправи ме ако греша, но всичките тия курсове и студенти би трябвало да са в отделен пакет (напр. model
) и теста за Susi
не би трябвало да се интересува те дали са коректно имплементирани (т.е. те ако имат някакви неща дето може да се счупят, е редно да си имат друг тест), защото аз искам да тествам поведението на Susi
дали е правилно, а не на нещата на които то разчита. :)
@Иван, не грешиш, че нещата може да са в различни пакети (специално за това дали да са в пакет model
е под въпрос). Домашните се предават в един пакет и това е ограничение, с което условията трябва да се съобразят. Идеята на конкретното задание е да направите няколко типа, да се използват най-базовите интерфейси и да върнете подобаващи съобщения за грешка в определени ситуации.
Нито са покрити всички възможни ситуации за грешка (можеше да има много повече валидации), нито работите с някакви бази от данни, където да се записва информацията.
Грешката, за която аз говорих е, че ако аз си имплементирам типа Course по един начин, то Marshal -> json -> Unmarshal
е нормално да ми въведе същият този курс, но в домашното ние тестваме срещу json
данни, които ние предоставяме (дори сме ви дали една част от тях в примерните тестове), и нямаш никаква гаранция, че решение, което минава твоите тестове ще е реално вярно спрямо условието на домашното(и че ще мине нашите тестове).
Написах малко тестове за валидациите. Нали са правилни?
EDIT: Смених спейсовете с табове
@Цветелина, изглеждат наред, но пусни едно fmt на тестовете. Струва ми се, че използваш спейсове, вместо табове.
Глупав въпрос, но имам объркване относно връщането на грешки.
" Трябва да използвате съобщенията за грешка от примерите в предишната секция - "Валидация"
В тестовете си ще проверяваме за точно тези стрингове и ако върнатите от вас се различават дори с един байт теста няма да бъде успешен. "
Как очаквате да се използва SusiError (който съдържа студент и курс), когато просто искате да връщаме стринг като грешка?
@Стоян, виж интерфейса error
. Нормално е да имате съобщение за грешка, което да го пазите в друг елемент от SusiError. Student и Course ги искаме ако примерно връщате грешка, че вече има такъв студент - да закачите студента към обекта за грешката, съответно за наличието на курс (закачате курса) или при наличието на enrollment (тогава може да ги закачите и двете).
@Недялко, мерси :) прекалено много бях задълбал в буквалното четене на условието. Мислех че SusiError трябва да има единствено и само споменатите 2 полета
Имахме Pull request за промяна на един тест, понеже не сме написали същото съобщение в теста, каквото е в условието. Моля, хората с качени решения да обърнат внимание, другите да си pull
-нат промените и да си оправят съобщението за грешка.
Update: Още един Pull request -> pull
-> go test
.
С най-последния 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: Май си разбрах грешката
Махнах тези парчета от теста. Проблема е с различните reciever-и и reflect
.
За повече информация: http://golang.org/ref/spec#Method_sets
оправих се ..
...
Оправих се и аз :)
Оставяйте си въпросите (ако решите и самите отговори, щом сте се оправили), може на някой друг да му е полезно.
Имам въпрос във връзка с AvailablePlaces
в курсовете. Трябва ли да ги мутираме или това може да доведе до race condition-и и е по-добре да не разчитаме на проверка там, а да имаме нещо по-сигурно като механика (forgiveness > permission)?
To clarify:
course.AvailablePlaces
?@Цветелина - много благодарим за тестовете - само след съответния pull request си забравила да си ъпдейтнеш теста (не че е проблем).
mutex на Enroll мисля че ще ти свърши работа и ще ти реши главоболието но все пак ме съмнява че някой иска да го направим асинхроно все пак цялото нещо е Суси идеята му е да е бавно и от време на време да крашва така че ..
@Илия не сме ви говорили за нишки и не очакваме нещата ви да са thread safe (все още). Скоро ще имате възможност да си играете и с такива задачи.
Да трябва да се промени стойността на AvailablePlaces
, когато студент бъде записан.
Няма значение как ще го имплементираш, стига да работи. Всичко ще е в една нишка.
Супер, благодаря.
Просто имах някаква алтернатива теория за условието.
Now that that's out of the way ще мога да спя спокойно.
@Илия, махнах нещата от примерния тест след най-последния pull request. Благодаря, че ме подсети :)
Трябва да сте влезли в системата, за да може да отговаряте на теми.