Алексей Уколов

Почему не сделать это всё одним шейпом?

нужно обязательно знак вопроса

Почитайте dev.mysql.com/doc/refman/5.7/en/innodb-auto-increm... там много нюансов.

Тут сложный вопрос.
Вообще, что такое "Лид" должен трактовать заказчик, так как это напрямую зависит от его сферы.
Например для одного "Лид" - может означать просто оставленный номер телефона или заполненная форма.
В то же время, для другого, "Лид" - должен сделать какие-то дополнительные действия.

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

"качественные звонки с продолжением" - это уже сконвертированный лид, и собственно в конвертации "Лид -> Клиент" и состоит основная работа.
Т.е по-сути ваш заказчик хочет оплачивать не Лидов, а уже сконвертированных клиентов, так что это наглость и развод.

df для btrfs показывает среднюю температуру сферического коня в вакууме.

Собственно с учетом использования сжатия/снепшотов/под-томов/дедубликации - для btrfs очень трудно сказать сколько занято, а сколько свободно/сколько можно записать....

+ не забываем что любая FS создает служебные структуры для хранения данных (метаданные в виде каталогов и трибутов файлов + всякого рода служебные индексы и контейнеры). И в этом плане BTRFS умеет под свои/накладные нужды выедать довольно много. Те-же метаданные по умолчанию на HDD пишутся в двух экземплярах (на ssd - в одном).

Вам бы посмотреть вот эту статью и посмотреть usage и возможно сделать балансировку не помешает.

Другое дело нужно не забывать о разнице между K/M/G и KiB/MiB/GiB
Собственно за *iB хочется вырвать все конечности маркетологам производителей HDD, которые внедрили K=1000 в информационных системах когда изначально K было 1024 для IT и 1000 для физиков.

Офис в центре Москвы, удаленная работа (95% времени). Зарплата 100 тыс. р. в белую. Полная ставка, оформление по ТД.

Это нужно писать жирным.

У нас есть небольшой сайт, который нужно развивать + создавать новые сайты + (в перспективе) руководить внешней командой при создании портала. Я прекрасно понимаю, что разработка требует много времени, поэтому стараемся грамотно ставить и распределять задачи. Более того, программист будет принимать непосредственное участи в выборе способа и технологии решения задач по своему опыту.

Это тоже нужно писать

Интересные и крупные проекты

- звучит очень казенно. Напишите что за проекты.

То что вы написали в этом вопросе и должно быть в вакансии.

В идеале второй вариант, если это возможно.

Скажем я на своих проектах пытаюсь делать так насколько это возможно. Перед началом разработки какой-то фичи разработчики просто договариваются между собой как будет организовано взаимодействие с сервером (по сути пишется описание API на каком api blueprint, сейчас будем переходить на raml).

После чего из этого описания разработчик серверной части может спокойно генерить себе тесты, json схемы респонсов и т.д. что бы быть уверенным что он делает так как договаривались, а мобильщики могут поднять себе из описания mock сервер.

Таким образом какие-то проблемы с серверным взаимодействием можно отловить задолго до того как разработчики в принципе реализуют эту часть api. Хотя если разработчики не используют какие-то средства для валидации реализации на предмет соответствию описанию, то в итоге на интеграцию может уйти больше времени.

p.s. этот подход я форсирую еще и потому, что при таком варианте можно легко наладить кодогенерацию как для клиента так и для бэкэнда. Скажем валидация запросов, маршрутизация, мэппинги и т.д. - все можно сгенерировать. RAML в этом плане дает из всех форматов максимальную гибкость, и поэтому я и планирую на него переходить. В очень простых случаях можно сгенерировать код хоть всего бэкэнда, но и так в целом скорость разработки неслабо увеличивается.

1. Берём какой-нибудь наиболее полный список mime типов:
svn.apache.org/repos/asf/httpd/httpd/trunk/docs/co...

2. Любой большой набор иконок для mime типов:
github.com/eagerterrier/MimeTypes-Link-Icons/tree/...

3. Пишем небольшой скрипт на любом известном вам языке и база готова.

...Это на случай, если никто вам так и не скинет готовую базу.

"словарь – неупорядоченное множество и можно на этом остановиться и не думать об этом" - да, тем более даже если вы постигнете то, как это сейчас устроено, не факт что в след версии это не поменяется. имхо, эти знание никак не применить на практике.

А чего это он у вас в мир смотрит? Ставьте nginx наружу, а в нем уже ssl, кеширование, балансировка и пр. штучки.
Понимаю, что не ответ, но имхо так правильнее.

Варианты могут быть такие:
а) На каждый коммит сразу идет сборка продукта и прогоняются интеграционные тесты.

Плюсы такие - на рабочем месте вам нужен только GIT и IDE, все компиляторы, окружение для запуска приложения - на нодах билдсервера. В результате вы можете кодить откуда угодно, и сразу проверять целостность сборки с каждым коммитом.

б) сборка может быть ночной. Например потому что билд идет 5 часов на толстом сервере, и на рабочей машине он будет идти 10-15 часов, а то и не идти вообще. Тогда конечно, желательно не ломать билд недоделанными коммитами. Но git же позволяет коммитить без пушей, либо пользоваться бренчами, и настраивать сборку не на просто коммит, а на мерж в девелоперский или мастер бренч.

в) Билдов может быть много, разных, под билдами вообще не обязательно подразумевается компиляция, а например прогон исходников через какой-нить анализатор кода, с репортом, могут гоняться тесты для отдельных компонентов.

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