Python-сообщество

Rodegast
Выложи шаблоны для этих настроек на github

Да не хочу GitHub-аккаунт с форумом связывать. Какой-нибудь минусовщик с форума может пойти туда из мести кучу накладывать и, наоборот, оттуда какой-нибудь придурок может сюда прийти, если всё связано. Мудачья всякого хватает в инете. Естественно, что оно всё на GitHub'е лежит уже. Можно будет попозжа показать принцип, сделав типичный пример такой сборки.

Rodegast
Не забывай что тебе ещё атрибуты все прописывать надо

Не, можно только внешний интерфейс класса описать. То есть степень детальности описания контролируется тобой до той степени, пока тебе нужно прояснить картину взаимодействия этих сущностей в программе.

Отредактировано py.user.next (Май 4, 2018 19:15:34)

Rodegast
Не забывай что тебе ещё атрибуты все прописывать надо, а т.к.

ну так-то если спланированно, прям спланированно, то старые аттрибуты меняются вяло, а для нововведений опять плас is first

Чет я все не могу финально засеть разрисовать, так, перед сном сижу… Работы много

> Да не хочу GitHub-аккаунт с форумом связывать

Ну можешь просто сюда в файл прикрепить.

> Не, можно только внешний интерфейс класса описать.

А можно и вообще ничего не описывать. ИХМО при индивидуальной разработки UML это последнее о чём стоит думать.

Rodegast
Ну можешь просто сюда в файл прикрепить.

Поставишь себе cunit и gcov. Потом делаешь
Он всё соберёт и запустит тесты, а потом в директории src_build/tests/build_cover будут лежать покрытия.
Для очистки проекта делаешь

Всё самодельное, даже ./configure

Отредактировано py.user.next (Май 5, 2018 04:41:45)

Прикреплённый файлы:
proxima-2018-05-05-122927.tar.bz2 (47,4 KБ)

> Поставишь себе cunit и gcov. Потом делаешь

Тю… оно же всё сишное! Ты мне для python проекта шаблон выложи.

Rodegast
Тю… оно же всё сишное! Ты мне для python проекта шаблон выложи.

Оно, главным образом, линуксовое. То есть под винду я это не готовил. Это не сложно, просто нафиг не нужно. Поэтому питоновские проекты точно такие же - make, m4, coverage3. Почему они такие - потому что make легко управляется не только со сборкой самого проекта, но и с установкой в систему, постановкой прав скриптам и так далее. Она вообще же разрабатывалась для unix-подобных операционных систем, поэтому она родная для линя и я её активно там юзаю. Web-приложение тоже есть на Flask'е, точно такое же всё, но там с тестами попроще, потому что питоновских тестов практически нет, есть только JavaScript-тесты, а в JavaScript-тестах я до покрывальщика так и не добрался, максимум смог получить моки. Покрывальщик там есть, но я его не догнал пока что. Просто в сишном проекте более забубённая компиляция, там два режима: можно просто скомпилировать программу; можно скомпилировать программу для просмотра через gdb. Вообще, первоначальная идея была сделать так, чтобы тесты можно было сделать просто и можно было сделать для просмотра в gdb (это разные опции при компиляции тестов нужно ставить). Но потом я посмотрел и оставил для тестов только вариант с просмотром в gdb, так как это дело не сильно отличается по объёму скомпилированных бинарников. В сишнике тесты - это программы, поэтому, если вдруг в тесте непонятная ошибка и неясно, в чём её причина, то тест надо дебажить в дебаггере. Естественно, чтобы дебажить тест, он уже должен быть скомпилирован с опцией дебага, иначе будешь тратить время, отвлекаться. В питоне такого нет, конечно, там всё проще из-за интерпретируемости.

Вот метод сборки для просмотра самой программы в gdb
То есть программа теперь может быть отлажена в gdb, а тесты всегда могут быть отлажены в gdb (такое решение было просто принято по мере использования проекта, хотя тесты изначально тоже можно было делить на два режима сборки).
Опция debug у ./configure заставляет при конфигурировании общего Makefile-файла пропустить его через другой файл для m4, который проставляет опцию -g в командах компиляции, записанных в Makefile-файле. Там возможностей куча в смысле путей достижения результата. Можно так параметризовать конфигурирование, а можно и по-другому. Есть широкий размах для творчества. Я все эти вещи долго продумывал разными путями. Это прямо как программу писать, составляя постепенно алгоритм, - почему и говорю, что это похоже на детектив.

Там ничего автоматически созданного нет, всё вручную написано методом проб и ошибок. Так что можешь ковырять, чтобы понять, как оно организовано.

P.S.

Rodegast
Тю… оно же всё сишное!

Ты ещё не видел, что я недавно написал для проекта на C++/Qt - это был вообще полный капец, там же тоже юнит-тесты есть собственные, Qt-шные. Как написать сборку бинарника так, чтобы не надо было открывать QtCreator для сборки проекта? Но написал и сборку бинарника, и сборку юнит-тестов для него, и установку программы в систему с красивым значком в главном меню (значок ещё в Inkscape делал, тоже подучиться пришлось, хотя Gimp'ом владею давно; просто тут значки векторные и Inkscape сама по себе классной штукой оказалась). Вообще, все эти системные дела не такие страшные, как кажутся на первый взгляд. То есть вот есть у меня служба systemd своя в виде web-приложения, так я даже не думал, что установка собственной службы при “make install” с динамическим заданием имени программы будет проходить так просто, как получилось в итоге. Думал, будет сложнее все это.

Отредактировано py.user.next (Май 6, 2018 00:57:08)

> Поэтому питоновские проекты точно такие же - make, m4, coverage3.

Если мне склероз не изменяет, то для python-а надо отдельными приблудами пользоваться.

> Ты ещё не видел, что я недавно написал для проекта на C++/Qt - это был вообще полный капец

А можно было бы ничего не писать и всё прекрасно и без этого существовало бы.

Rodegast
Если мне склероз не изменяет, то для python-а надо отдельными приблудами пользоваться.

Я знаю несколько языков (C, Python, Shell, - основные; С++, JavaScript, Erlang, Go, - дополнительные; дополнительные не так хорошо знаю и они могут стать основными потом, при большем погружении в них) и на всех на них что-то пишу. Поэтому решил выработать свою систему для решения любых задач в проекте. Чем больше я проектов делаю, выстраивая в них собственные системы обслуживания проектов, тем проще мне делать новые проекты. Я могу сделать проект на Shell'е, а потом конфигурацию из него скопировать в проект на Python'е и наборот. Многие вещи, которые я вчера делал с нуля, тратя на это кучу времени, сейчас я просто копирую напрямую и их уже писать с нуля не надо. Какие-то вещи я усложняю, рассмотрев их сначала на простом уровне (принцип макетирования). Сразу сложную вещь не построишь, сначала нужно собрать её более примитивный прообраз (макет) и посмотреть на него, отлавливая нужные детали и отбрасывая ненужные. Где-то что-то просто не приживается, хотя изначально логически кажется очень подходящим; это тоже играет роль в формировании этих систем. Многие вещи потом кажутся простыми и элементарными, но нигде при этом не видно, что до этой простоты они были обвешаны многими ненужными слоями, которые в итоге были выброшены, так как на практике потом не использовались ни разу.

Rodegast
А можно было бы ничего не писать и всё прекрасно и без этого существовало бы.

Ага, существовало бы, у меня там был баг небольшой, так из-за него весь проект встал просто. Баг такой, что требовалось исправить функции, переписав их по-другому, а функции были такими сложными, что новые версии надо было бы заново отлаживать хрен знает сколько времени. Не было юнит-тестов в проекте. А потом стал делать юнит-тест, на него ушло кучу времени, потому что юнит-тесты на C++ не такие простые, как в питоне. Теперь оно всё быстро делается. Проект разморозился и готов к дальнейшей разработке. И теперь оно во всех будущих проектах будет быстро делаться, потому что систему можно скопировать в них. Это моя система, я меняю её и дальше, совершенствуя по мере требований. Мне нужно, например, чтобы оно собиралось определённым образом, я этот пункт просто добавляю. Мне нужно, чтобы оно куда-то выкачивалось само, я это просто добавляю туда. Конечно, не просто это делается всё, надо проламывать себе путь. Проломил - получил именно то, что тебе нужно. А прогнулся - потом того нет, этого нет.

Что касается QtCreator'а, так в нём только с самим графическим интерфейсом делаешь что-то, а весь вычислительный функционал к GUI уже никак не относится. То есть большую часть времени при разработке пишется код вычислений. То есть я могу добавить фичу в программу, ни разу не открыв при этом QtCreator. Он же просто автоматически добавляет информацию в файлы, которые потом собираются через qmake. Так я эту информацию и сам добавить могу, без него В нём потом откроешь проект и выглядеть всё будет так, будто в нём всё это делал. То есть он становится просто не нужен.


tags: project management

Отредактировано py.user.next (Май 7, 2018 02:22:09)

Я на проектик один поглядываю, - может он сойдёт за пример.