Програмиране с Python

Курс във Факултета по Математика и Информатика към СУ

Курсови работи

  1. Здравейте,

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

    Например гледам, че предишни години са давани около четири теми, по които е било препоръчително да се работи.
    - Тази година пак ли ще е така? Какви биха били темите?
    - Какви горе-долу са изискванията към обем, сложност, смисленост към теми, които евентуално ние предложим.
    - Каква е политиката относно разработването на проекта в публично (примерно git) хранилище и евентуално получаване на мнения и препоръки в процеса на работа, вместо чак при защитата, когато е късно.
    - Предполагам, че проектите се очаква да бъдат персонални, но все пак за яснота ми се иска да получим становище относно групови разработки.
    - Каква част от точките се дават за различните части: Тестове, Чист код, защита ...

    Ако съм изпуснал нещо важно, което ви вълнува може да пишете :)

  2. Идеално време подбра за да повдигнеш въпроса. Директни отговори на въпросите ти:

    • Да и тази година ще има няколко предефинирани от нас теми, с подобна сложност(в близките дни ще предоставим примерни)
    • Относно обем: ако очакваш изискване от типа поне 8192 реда код - няма. Определено очакваме смислени теми, реално приложими със сложност близка или по-голяма от примерните
    • Насърчаваме идеята публично да разработвате проекта си, САМО ако е избрана от вас тема, а не някоя от нашите. След като я одобрим, ако получим линк към репо-то в GitHub, с радост ще го следя и ще коментирам развитието на проекта(и не само аз).
    • Проектите са персонални, освен ако не получим идея за проект, който може да бъде разбит на два големи раздела(не бих казал модули), които са годни да бъдат преизползвани. Ще се радвам ако двама успеят да предоставят наистина добра идея.

    Най-баналният пример: Приложение със сървър-клиент. Единият да работи по сървъра - другия по клиента. Оценката обаче ще е обща и ако случайно се окаже, че единият е писал код като за двама(а това си личи) и двамата го отнасяте.

    • Както и минали години:

      • 50% - изпълнение на функционалните изисквания
      • 30% - стил, красив и четим код, PEP 8, ефективни алгоритми, документиран код
      • 20% - тестове. Но при пълната им липса ще бъдете яко посечени

    Тук е моментът и мястото да блеснете с впечатляваща идея.

  4. Тук имам следния въпрос относно PEP 8 и допълнителните библиотеки.

    Понеже някои библиотеки имат свое виждане за стилен и качествен код, като използваме нещо допълнително(например PyQt) в какъв стил да пишем проектът? По принцип PEP 8 препоръчва да се пише в стила на фреймуъркът, ще има ли проблем накрая на курса с това?
    Интересно ми е също, как се процедира ако имаме повече от една допълнителна библиотека с различен стил?

  5. @Светльо, проектите дават 60 точки. Което е около/почти 1/2 от оценката :)

    @Петър, точно обратното. Задължително е да спазвате стила, на библиотеката на която пишете.

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

    Относно различните библиотеки - можеш ли да дадеш подобоващ пример. Защото нямам случай да използвам две библиотеки на едно място, с различен стил. То в общия случай е PEP 8 с някои допълнителни изисквания. Изключения правят някои графични библиотеки(PyQt, Pyside, PyGTK), които блъскат camelCase имена на методи.

  9. @Николай, държим на unit тестове, но наличието и на интеграционни ще бъде плюс.

    Иначе както ти е показал Орлин, всеки framework за пайтън си дефинира свой coding style и всеки път той би трябвало да започва с:

    Unless otherwise specified, follow PEP 8.

  10. Здравейте,

    Относно: "Проектите са персонални, освен ако не получим идея за проект, който може да бъде разбит на два големи раздела..."

    Аз и Борис Величков решихме да направим симулация на билярд - двама играчи без AI. Рендерът ще е през pyOpenGL и ще направим малък опростен Physics симулатор за топките. Одобрявате ли идеята ни ?

  13. @Никола, идеята ми изглежда интересна. Направете го двамата, но надявам се сте прочели това:

    Оценката обаче ще е обща и ако случайно се окаже, че единият е писал код като за двама(а това си личи) и двамата го отнасяте.

    Ще се радваме най-сетне да видим успешен съвместен проект в курса :)

  14. Здравейте, ще има ли някакъв начин да получим "feedback" относно развитието на проекта си, ако той е по някоя от общите теми?
    Очевидно качването във github като публичен проект не е приемливо, от друга страна се съмнявам, че много хора имат платен акаунт и могат да добавят "private collaborators".

  16. Изобщо не ми се иска да препоръчвам нещо различно от GitHub, но - съм напълно сългасен с @Николай. Има няколко проекта с подобна(да не кажа същата) идея като тази на GitHub и някои от тях го превъзхождат с някой и друг feature. Било то повече от една опция за това какво бъде хранилището(git, mercurial, svn...) или безплатни хранилища, които да бъдат private.

    Далеч не са по-добри от към използваемост, community и прочее, но все пак можете да използвате тези алтернативи и да ни казвате за това по мейл(ако не се лъжа, не става само с линк, а се изисква и регистриран акаунт...ще правя, ако нямам).

    След края на проекта нищо не ви пречи да добавите и GitHub като remote(без да губите историята). Та това ми се струва като удачен вариант.

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