Milestone 1

  1. Дойде време за първия milestone по вашите проекти. Имате срок до идния понеделник.

    Ние от наша страна в коментарите към вашето "решение" ще имаме свободата да ви усложняваме/опростяваме идеите. Тези от вас, които пропуснат и двата milestone-а, ще оставим за септември.

  2. Когато се избере лиценз при създаване на хранилище, какво точно прави git? Тъй като вече съм си създал хранилище отдавна, но не съм му сложил лиценз, а когато си направих ново, видях просто 1 файл LICENSE. Т.е. достатъчно ли е просто да копирам този файл и да си го commit-на към старото хранилище или се случва и нещо друго, когато се избере лиценз при самото създаване, и съответно трябва да си правя ново хранилище?

  3. Мога ли да премина всички Milestones, а основното представяне да го направя през септември. Защото така като гледам, ако го оставя направо за септември ще изгубя доста точки от тези домашни... И евентуално ако може трябва ли някъде (примерно във readme-то) да поясня изрично, че ще представям проекта си септември

  4. @Йончо Йончев

    от заданието : "втория milestone, който ще бъде ~две седмици след края на първия." Означава, че втория milestone ще е приблизително две седмици след края на първия milestone

    П.П Някой друг има ли проблем подобен на моя ? Аз ли не праа нещо като хората ?

  5. Това е така, защото нямаме подобно изискване. Ако проектът ви стане готов за релийзване, то няма как да минете без описание и документация на английски. До тогава сме ок README-то ви да е на български.

    А сметнахме, че е излишно да се споменем, че docstring-овете (казвам docstring-ове, а не коментари, защото искрено вярвам, че не трябва да имате коментари) във вашия код трябва да са на английски.

  6. Проблемът е, че ако там има коментар, то:

    1. Очевидно е какво прави това парче код, което сме коментирали. В такъв случай коментарът е напълно излишен. Решението : Изтриваме коментара.
    2. Кодът е написан по такъв начин, че изглежда объркващ. Имаме нужда от коментар, който да предотврати това объркване. Решението: Пренаписваме кода до момент, в който вече не е объркващ. Тогава изпадаме в случай 1.

    Един docstring на функцията/метода/класа, обясняващ какво върши въпросната единица (а не как е имплементирана) е напълно достатъчен. Като всяко правило и това си има изключения. Просто не вярвам, че в някой от вашите проекти ще изпаднете в него.

    Това е твърдение изцяло в контекста "Python-ски код". Не всички езици са толкова самоописателни и не бива да го прилагате навсякъде.

  7. Жокер: за тези които имат проблем с markdown-a в описанието ползвайте github wiki editor-a.

    След това искам да попитам за темата на проектите, предадох 2 теми за проект като получих следния отговор от Кирил: "Склонен съм да се съглася на идея 2."

    Върнах му имейл с въпроса какво не достига на първия проект, но още не ми е отговорил, затова предадената документация е само по 2рия проект.

    Нямам нищо против да работя по 2рия проект, просто е доста трудоемък и ще ми трябва 3 пъти повече време за довършване, та въпроса ми е простичък - "Трябва ли проекта в края да е изцяло довършен или просто написани няколко работещи функционалности и ще се гледа кода?". Питам, защото цитирам:

    50% от точките, за вeрен и отговарящ на условието код. Трябва като минимум да покриете условието на проекта (по ваш избор можете да го разширите, но не и да променяте/пропускате части от него)
    
  8. Причината да не ти приемам идея 1 е именно, че беше твърде елементарна и нямах добра идея как да я усложня.

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

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