FRiMN

https://docs.python.org/3/library/threading.html#t...

def hello():
    print("hello, world")

t = Timer(30.0, hello)
t.start()  # after 30 seconds, "hello, world" will be printed

Использовал nagios для мониторинга примерно 300+ машин
1) простота установки и поддержки — есть в пакетах во многих дистрибутивах, настраивается достаточно просто
2) расширяемость — много плагинов, в том числа для сетевого оборудования, можно писать свои, достаточно будет написать шелл-скрипт, который пишет данные в определенном формате.
3) производительность — для 300+ машин серверу хватало 256 Мб, при этом там еще работал OCS Inventory
4) надежность — как кирпич, очень надежно.
5) визуализация данных — присутствует, красота на любителя.
6) распределенный мониторинг — не совсем понял, что имеется ввиду. Если это то, о чем я подумал, то существует NRPE, который выполняет удаленно плагины на хосте и отдает ответ плагина серверу мониторинга. Если имеется ввиду использование нескольких серверов мониторинга в связке, то не уверен, что на предприятии в 50-70 машин это нужно.
7) эскалация инцидентов — не готов сказать что-то конкретное, не представляю, какая у вас на предприятии с этим ситуация, какова иерархия управления инцидентами. Исходя из размера компании, один технический специалист и пара-тройка человек руководства.
8) широкий набор оповещений — можно разделять пользователей на группы, указывать, на какие группы высылать оповещения, стандартно используется три состояния сервиса или параметра — OK, WARNING, CRITICAL. Есть еще статус UNKNOWN, возникающий в случае некорректной работы плагина.
9) цена — бесплатно
Плюс есть возможность выполнения скриптов удаленно в случае возникновения критической ситуации. Например, передернуть сервис.
Кроме того, можно использовать координатную отрисовку на карте. Задаешь координаты для всех машин и на схеме наблюдаешь где это находится. Правда, придется немного озаботиться с заданием координат.

Cacti больше подходит для мониторинга по SNMP, соответственно, удобнее им мониторить сетевое оборудование, я лично для этого использовал плагины для nagios'а.

В общем, из своего опыта советую nagios.

Обычно все начинается с критики в адрес дизайнера...это единственное отличие моей методики от вышеуказанных способов)

У меня есть уже своя html+css заготовка.

1) Копирую заготовку в новый проект
2) Долго и нудно пишу html, ненавижу когда много мелких элементов на макете
3) Режу картинки, спрайты
4) пишу css, попутно иногда правлю html

Но у меня уже опыта много, лет 9 уже как. Поэтому я заранее знаю что где и как будет, не гадаю, этот опыт позволяет мне не писать css вместе с html. Получается очень быстро. И я использую всякие бутстрапы только по требованию. Считаю излишними во многих случаях.

1. Настраиваю gulp на основные таски (конкатенация, минимизация, удаление неиспользуемого, кросс-браузерность, sass и т.д.)
2. Подключаю через bower необходимые "модули", например, normalize.css или фрэймворк
3. Выстраиваю архитектуру кода (просто независимые блоки в отдельную директорию, например, "modules", или "pages" для стилей особенностей отдельных страниц), в корне css главный файл стилей, в котором осуществляется импорт всех модулей (например, файл с переменными цветовой палитры или файл с mixin-ами).
4. Подключаю необходимые шрифты, в основном, через специальный миксин.
5. В главном файле стилей описываю основные стили для типографики, в общем всё, что связано с селекторами типа.
6. Если дизайнер предоставляет styleguide, то начинаю верстать страницу именно с него, а именно, по независимым блокам (где это возможно, от меньшего к большему) используя БЭМ методологию.
7. По ходу дописываю задачи для менеджера задач, например, для скриптов или картинок, собираю необходимый package.json, bower.json.
8. Собственно этап по-блочной верстки.
9. Собираю конструктор из готовых блоков и элементов соответственно макету.
10. Проверяю кроссбраузерность, pixel perfect.
11. Этап исправления деталей

Исходя из формулировки вопроса ответ:
поэтапно, сначала описываю структуру одного блока, пишу ему стили, перехожу к следующему.

Разбиваю макет по модулям (элемент списка + список, шапка, навигация, форма, кнопка). Определяю пересечения модулей (например два блока на разных страницах очень похожи - для них один модуль и просто у одного из них в HTML будет указан дополнительный класс .module.module-supermodule).

Завожу несколько файлов:
app.css - только импорты для модулей.

@import "base.css";
@import "icon.css";
@import "btn.css";
/* ... */
@import "some-module.css";

base.css - любые базовые стили не привязанные к классам, обычно стили для тегов, никаких намеков на классы или id.

Верстаю сначала помодульно. Модуль обычно включает в себя только классы ограниченные определенным префиксом, например .nav- или .sidebar-.

Распространенные модули, которые кочуют из проекта в проект .btn-, .icon-, .form-, .nav-. Принцип организации модуля прост: внутри строго использовать классы с определенным префиксом. Искать такой модуль в списке CSS файлов очень просто - префикс и есть название файла, в верстке понять что элемент принадлежит к определенному модулю тоже достаточно просто - у всех классов этого модуля есть этот префикс. Если модуль - это список, допустим .list: в модуле сначала будет идти .list-item, а затем .list .list-item - для того чтобы можно было использовать .list-item отдельно от родителя .list, иногда бывает очень полезно.

В целом по структуре организации проекта все. Дальше - выбор определенного шага сетки (отступы, размеры элементов) должны быть кратны выбранному значению шага.

Для сборки модулей в один файл использую конкатенатор, умеющий смотреть импорты и вытаскивать CSS файлы по ним. Если использовать LESS или SASS задача вообще элементарная. Я просто знаю, что люди которым я отдаю верстку не часто знакомы с LESS и SASS, чтобы отдавать стили в таком виде.

По сути премудрости старта заканчиваются. Дальше все зависит сугубо от вашего профессионализма.

P.S.: Кстати, почему то все сбрасывают стили - я этого никогда не делаю. Достаточно знать особенности стандартных стилей, тщательное тестирование в разных браузерах. Получается на деле стандартные отступы заданные браузером наоборот помогают. Тем более прошли те времена, когда был ощутимый разброс в стандартных значениях. В общем странно.

В первую очередь делаю сброс css-стилей.
Затем делаю вёрстку общих блоков - просто структура из div'ов с нужными ширинами, высотами согласно макету, залитых разными цветами. Стараюсь все div'ы(когда что-то в строчку) делать inline-block'ами. Получается цветная такая структура будущего сайта. Каркас готов.


Начинаю углубляться в каждый блок - располагать в нём нужные элементы. В зависимости от сложности их расположения делаю какие-то блоки position:relative, но чаще всего всё упирается просто в отступы.

Создаю минимальную разметку с базовыми элементами и пишу для них CSS.
Потом добавляю в разметку остальные элементы и пишу CSS.
И так далее.

при безумных количествах могут возникать некоторые неудобства в работе, некоторые из которых повергают неопытных пользователей в панику (:
например, df -h показывает что места еще 20 гигов, а файло не создается, рапортуя, что закончилось место (бывает только, если иноды закончились) или не работают rm * и многие маски (шелл ругается на большое количество аргументов).
а так, чтобы это на производительности сказывал, что-то не наблюдал.

Если ответить коротко — зависит от ограничений файловой системы.

Это, пожалуй, индивидуальная мера для выбранной системы, на каком количестве файлов начнутся тормоза.
На практике, чем больше файлов в папке — тем медленнее листинг. Индивидуальный доступ к одному файлу из 30 тыс. может не отличаться по скорости(если в директорию никогда не заходить через терминал), но листинг может занять несколько минут и загрузить процессор.

Лично я распределяю по удобству копирования и архивации, примерно по несколько сотен файлов(до тысячи) в одной папке.