Михаил Р.

@d00mko видимо не потрудился прочитать статью, прежде чем посоветовать ее Вам. В статье как раз пытаются избавиться от мифов вокруг ноды.
По сути вопроса - нода вполне подходит для проекта любого размера и сложности (как и пхп, раби, питон, ява и т.п.) Никогда в жизни не сталкивался с ситуацией, что язык становился узким местом в веб приложении. Если Вы с этим столкнетесь, то значит Ваша архитектура уже идеальна, у вас миллионы пользователей и у Вас миллиарды денег, чтобы взять и переписать все с нуля где-нибудь на побережье океана попивая мохито, принесенное личным барменом.
Ява - готовьтесь к тому, что Вам надо МНОГО оперативной памяти. Разработка будет вестись долго, но большинство глупых ошибок Вы избежите в силу особенностей языка.
ПХП - готовьтесь к тому, что в Вашем коде будут появляться какашки, так как из всех пхп кодеров лишь доли процента могут написать хороший код. Это действительно очень трудно, когда язык сам манит писать все больше и больше какашек ) Лишь просветленные могут удержаться )
Нода - Вас ждет мир непонятного асинхронного кода, но как только наступит просветление, то Вы будете писать намного более эффективные приложения, чем Ваши товарищи пхпщники ) Наилучшее применение - чаты, кометы и т.п. Но и в качестве веб-сервера чувствует себя замечательно.
Питон - можно использовать и асинхронный подход и синхронный. Памяти жрет намного меньше, чем Java (личный опыт. разница была почти в 7 раз). По скорости работы практически не уступает яве. По скорости разработки разрывает ее в клочья
Раби - ничего не могу сказать дельного, но синтаксис мне не нравится.
Эрланг - если Вы действительно суровы и Вам нужна максимальная производительность - это Ваш выбор. Столько боли и страдания Вам не доставит ни один язык. Вы можете часами сидеть и тупить над одной строчкой кода, но каждый раз после написания такой строчки Вы будете впадать в экстаз ) Да и пока вы часами тупили над одной строчкой в эрланге на другом языке вам бы пришлось написать 200 строчек. Хардкор вариант, есть много тестов, уроков и примеров, но сам бы я не рискнул начинать проект на нем, так как моих знаний не достаточно, а найти разработчика - нереально.
Вообще, не пишите серьезные проекты на том, что хотите изучить или то, что модно. Пишите на языке, который лучше всего знаете.

Принцип KISS не означает что надо использовать самые примитивные инструменты.
Он означает, что не надо переусложнять систему без нужды.
Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

Для того, чтобы упростить управление системой, её надо усложнить.
Этот принцип относится к любой области человеческой деятельности, от постройки ракет до управления государствами.
Чем сложнее система, тем больше накладные расходы на ее управление. Хоумпейдж с котиками можно и нужно делать примитивными средствами. В большом проекте надо сразу закладываться на будущую расширяемость. То есть, заранее делить ответственность между "леерами".

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

Давайте предположим, что вы еще не определились с контентной областью и возьмем стандартные для сетки Boostrap - 1170px, при таком раскладе, дизайн будет делаться в разрешении 1920 px (Чтобы сразу было видно картину на весь экран), при этом все не резиновые элементы и контентная область будет влезать в 1170px.

В бустрапе 12 колонок, поэтому адаптировать под следующие экраны будет легче для разрешений: 768 и 320 соответственно.

В итоге мы получаем следующие разрешения:
1920 (контентная область 1170) - FullHD мониторы
768 (контентная область 690) - Планшеты
320 (контентная область 290) - Телефоны

Это минимум, далее зависит от задач и сценария. Если контентная область выше 1170px, а сейчас такое часто бывает, то адаптацию нужно будет делать и под ноутбук, тогда контентную область следует высчитывает в кастомном режиме.

Зависит от совести дизайнера и от сетки которую он и вы будете использовать.
Я бы попросил 992px, 320px и 1200px(так как использую бутстраповскую)

используй эту библиотеку для работы о звуком
https://howlerjs.com/

1) создаешь объект звука и указываешь путь к аудио-файлу
2) запускаешь этот звук

Для миддла надо подтянуть только п. 3. У Светы Смирновой есть несколько отличных презентаций по работе с explain, они легко находятся гуглом.

Еще желательно различать транзакции и блокировки, когда что использовать.

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

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

@mixin test($arg) {
  @if(not $arg) {
    @error $arg;
   }
}

Является ли желтая квадратная форма в конце анимации видоизмененной кнопкой или же это совершенно другой элемент разметки?

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


С такими анимациями можно долго играться, самое главное - проверить в конечном итоге кроссбраузерность. А то в хроме и FF работает, а в каком-нибудь IE всякое может случиться.

P.S.: Но в целом - я голосую за реализацию таких вещей целиком на JS. Практика показывает, что в проектах с такими анимациями очень быстро собирается большое количество одновременно анимирующихся значений у большого количества элементов, которые нужно синхронизировать между собой. На CSS голова лопнет все это делать. И да, чем больше всего меняется в CSS-анимациях в единицу времени, тем выше шанс найти какой-нибудь редкий баг и долго ломать себе голову в поисках проблемы. Лучше уж взять какую-нибудь библиотеку вроде anime.js или любимый многими GSAP и использовать их.

Скорее что-то вылезает за пределы body. Напишите селектор

* {
   outline: 1px solid rebeccapurple;
}

и по рамкам сможете понять, какой элемент выпирает.

>1) Видит ли фрилансер мое имя и фамилию, когда я создал предложение о работе, опубликовал и оно висит в объявлениях?

Нет. Показывается название компании.

>2) Видит ли фрилансер мое имя и фамилию, когда я обратился к выбранному мною фрилансеру напрямую с предложение о работе?

В чате видно имя и фамилию, да :)

>3) Можно ли мне как заказчику указывать не настоящую фамилию? Знаю что фрилансерам необходимо указывать реальные данные. А вот что насчет заказчиков?

Официально конечно нет. Но по факту, вас ничто не ограничивает. У меня есть заказчики под полностью вымышленными именами и это им абсолютно не мешает работать. Фрилансер в случае бана теряет деньги. А заказчик особо ничего не теряет.

БП - ноунейм какой-то на 500 ватт.

Поздравляю, вы выиграли в лотерею!