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

Почитайте 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 же позволяет коммитить без пушей, либо пользоваться бренчами, и настраивать сборку не на просто коммит, а на мерж в девелоперский или мастер бренч.

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

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

Chrome 50.0.2661.94 (64-bit) - все работает.

Наиболее вероятным кажется то, что ваш хром или отдает не свой user agent - вследствие чего ему от Google прилетает какой-нибудь eot, он не может воспринять этот формат и

Chrome renders the rest of the page, but until the font has loaded, it displays a blank space in place of the text that uses the font

или вы давно его не обновляли - был баг, который решался вот таким хаком:

body {
    -webkit-animation-duration: 0.1s;
    -webkit-animation-name: fontfix;
    -webkit-animation-iteration-count: 1;
    -webkit-animation-timing-function: linear;
    -webkit-animation-delay: 0.1s;
}

@-webkit-keyframes fontfix {
    from { opacity: 1; }
    to { opacity: 1; }
}

Как говорят на w3cschools,

The Browser Object Model (BOM) allows JavaScript to "talk to" the browser.

Это такой мягкий намек на то, что вообще-то говоря Javascript может жить и вне браузера - на ум сразу приходит nodejs: там у вас изначально есть только консоль - ни о какой работе с HTML или браузером речи не идет. Можно сказать, что браузер предоставляет нам эдакое "дополнение" к тому, что знает интерпретатор о языке на момент исполнения кода. Реализаций интерпретаторов, разумеется, больше одной - если интересно какие сейчас в моде - можно посмотреть на википедии. Собственно в самом интерпретаторе и заложено то, что вы назвали "местом, где язык описан". А "описан" он там в соответствии со стандартом языка.

Сам по себе Javascript (диалект ECMAScript) - достаточно сложный язык, его врят ли получится исполнять "читая строки по порядку" (вспомним хотя бы "поднятие" переменных), поэтому интерпретируется он несколько сложнее, чем кажется. Очень не лишним будет посмотреть вот такой парсер. И вдвойне не лишним будет познакомиться с LISP перед тем как погружаться в дебри интерпретации (это покажется странным, по практически все идеи, которые сейчас используются в Javascript, были уже очень и очень давно и там, где вы их меньше всего ожидали увидеть. Да и мозг заметно вправляет такое знакомство). На хабре люди не раз уже писали свои интерпретаторы для разных языков, так что начало для понимания внутренней кухни там можно получить.

Возвращаясь к теме - если после ознакомления с вышеупомянутым парсером (который строит синтаксическое дерево) вы посмотрите на ваши BOM/DOM свежим взглядом, то заметите, что в то самое "дерево всего, что есть" браузер добавляет "дерево DOM" и "дерево BOM" с которыми вы, разумеется, можете работать - в коде они будут соответствовать объектам document и window. (звучит, конечно, немного грубо - но вы сами просили на пальцах). Для того, чтобы в этом убедиться, можно воспользоваться инструкцией по построению синтаксического дерева для Javascript