Максим Федоров

https://cloudcannon.com/deconstructions/2014/11/15...

Смысл в том что рисуется такая заглушка, а потом ее заменяет контент при загрузке

А про https://bitbucket.org/ забыли?
Насоздавал себе проекты, поставил задачки, отметил важное не важное, документацию написал сам себе))

Я юзаю YouTrack - его можно поставить в рамках локальной сети бесплатно. Отличная штука, мне лично по функционалу (простоте), нравится в разы больше Jira.

Изучите промисы

function do() {
  return new Promise((res, rej) => {
      getUrl(() => {
          const a = 5;
          res(a);
      })
  })
}

do().then(res => console.log(res));

Слышал различные мнения по этому поводу, от "маркетинг важнее производства", до "50/50" и ниже.

Зависит от того - что именно вы производите:

Если вы производите простые зубные щетки - маркетинг не важен. Важна минимизация цены на производстве, дешевая логистика и тп.
Если вы решите производить "премиальные" зубные щетки, то вам нужно будет объяснить потенциальным покупателям как именно щетина ваших щеток позволит им выигрывать в лотерею, например.
Если же ваша щетка - это самолет, и ваше имя Боинг, то конкурентов у вас по всему миру - ну 2-3-4 фирмы. Маркетинг тут чисто условный.
Если же вы собрались представить миру новый супер проект, вложили миллиард (ну что то вроде первых iPhone) - разумеется вы не захотите рисковать весь вложенный миллиард просрать. И весь проект будет хорошо согласован с маркетингом.

То есть ситуации с важностью маркетинга в каждом конкретном случае есть разные - вплоть до противоположенных.

Понимаю что бывает по разному, много факторов, но предлагаю взять за реальный или выдуманный пример компанию веб-разработки до 10 человек.

С маркетингом все как раз просто.
Нужна ли кому-то ваша фирма сама по себе, обеспечена ли она заказами на 2 года вперед, или вам приходится, мягко говоря, навязываться?

По поводу менджмента не все так просто.

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

Приходилось работать на обеспечении Олимпиады в Сочи. Так вот там принята эта схема, западная (несмотря на то, что конечные спецы были высоковалифицированными админами, но масштабность проектов - обязывала) - число менеджеров всех уровней, думается, превышало число конечных специалистов раза в три. И это тоже отлично работает.

Если же вы полагаетесь на специалиста-разработчика. Если его квалификация высока, если он достаточно обязателен, а вы не боитесь получить от него полную зависимость (bus factor) - можно минимизировать менеджерскую составляющую. Что уменьшит и себестомость вашу. Но поднимет риски.

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

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

У вас немного не в ту степь вопрос. Вы пытаетесь спросить что-то типа: зачем за 100к мне пилить человеку сайт на yii если я могу отдать фрилансерам за 30к и 70к положить себе в карман?

Ответ простой: если вы предлагаете два варианта человеку: фреймворк или, условный, вордпресс и человек выбирает фреймворк, на это есть причина. Сайт на фреймворке скорее будет поддерживаться и развиваться либо вами же, либо без вашего участия.

Если речь идет о каком-то простеньком сайте на 5 страниц, то человек выберет вордпресс, потом зайдет в админку и поймет что это вордпресс.

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

Обратите внимание на ответ Максим Федоров , который вам дали в комментариях, примерно об этом и идет речь. Дело не в том, сколько и за что вам заплатят, а в том, что человек знает какие задачи должен выполнять проект и делает выбор в пользу того или иного инструмента.

DECIMAL(X,Y)
X - общее количество знаков в числе (с учетом дробной части)
Y - количество знаков в дробной части

выведите эти 14 баксов на пейпал, купите две бутылки пива и выпейте одну за здравие Валютного Контроля, а вторую за Апворк

https://codepen.io/sakamies/pen/qOEGLJ

Итак, корректный ответ на поставленный вопрос:

Для начала, стоит понимать, что задача компилятора - взять сырец на X языке и перегнать его на Y язык. В современной жизни устоялась терминология "транслятора" и процесс "транслитерации", дабы не путать перегон в машинный код и на другой язык.

В классическом варианте этапы следующие:
1) Лексический анализ: Используя правила разбивает сырец на набор токенов (терминалов)
2) Синтаксический анализ: Используя правила и набор токенов структурирует их в AST
3) Семантический анализ: Проверяет корректность данных внутри AST (какого фига семантический анализ на этом этапе, а не позже, я, признаться хз).
4) Генерация промежуточного кода: В частности, трёхадресного и этот этап имеет смысл при реализации императивных языков. Трёхадресный код так же можно заменить на опкод, байткод или прочие "заменители" промежуточного кода.
5) Оптимизатор кода.
6) Результат (генерация в конечный код)
Во время всех процессов активно используется "таблица символов", грубо говоря "словарь".

Ориентируясь на эти данные я сделал несколько выводов и перестроил архитектуру следующим образом:
1) Парсинг (лексер + синтаксис)
2) Построение таблицы символов в немного фривольном формате: Имя + Тип + Адрес/Позиция в исходном документе + Метаданные (AST и проч.)
3) Билдер промежуточного кода (Reflection API)
4) Приведение типов
5) Валидация (вместо проверки корректности семантики из AST мне показалось удобнее оперировать высокоуровневым API, применяя некий паттерн матчинг, т.к. каждый тип проходит эту стадию сборки от 1 до 8).
6) Экстенды (есть спец.тип в GralphQL, который занимается манкипатчингом) -> после него переход к п.3
7) Рантайм (вызовы функций и проч) -> после него переход к п.3
8) Выходной результат (Reflection API)

Ключевым моментом становится метод а-ля рекурсивного спуска по этапам сборки от 1 до 8. Таким образом в самом рантайме (т.е. во время прохода по фазам их выполнению) можно дополнять данные в любую другую фазу. Пока хз как будет выглядеть на практике, но идея мне нравится.

Крайне рекомендую к прочтению:
1) Тут много инфы человеческим языком https://ps-group.github.io/compilers/ особенно вот эта статья понравилась: https://ps-group.github.io/compilers/fsm которая рассказывает о построении таблицы переходов в синтаксическом анализаторе.
2) И вот эта книжеца: https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D... Довольно сложная для понимания для неподготовленного читателя, но позволяет уточнить некоторые нюансы и ответить на вопросы.

Я бы сделал упор на базы данных. Дополняет не только пхп, и на зп положительно сказывается.