Егор Скороходов

Можно сделать цепочку преследования: к случайной точке тянется одна, к ней другая, и т.д., а последняя – муха.

Очередную точку ставить на плоскости случайно, в любом месте внутри допустимой области. Эта точка – цель, к которой стремится следующая, невидимая точка: каждый следующий кадр её координаты изменяются на k * векторИзТекущегоПоложения-в-Цель:

x = x + k * (xTarget - x);
y = y + k * (yTarget - y);

Так «преследователь» замедляется, по мере приближения к цели, никогда её не достигая.

Эта невидимая точка – не одна. К ней, как к цели, стремится следующая. К той ещё одна. Наконец, сама муха по этому закону стремится к хвосту этой цепи - очередной точке.

Чем больше звеньев в такой цепи, тем плавнее получается кривая. При приближении мухи к цели ближе, чем на D, генерится следующая случайная цель.

Сделал рабочий пример.

Можно поменять алгоритм и сделать, скажем, линейную скорость постоянной. Или случайно варьировать параметры k и D – от этого поменяется скорость и траектория от плавной ближе к ломаной.

reCAPTCHA

В html ссылки на скомпилированные js и css будут относительные.
В зависимости от браузеров и операционной системы, поведение будет разное, на линуксе например браузер пытается открыть их как file:///main.4cc3c8d8152162fe9b99.bundle.js, например, т.е. вместо локального каталога ищет мой js файл в корне файловой системы, где его конечно же нет.
Естественно ничего не открывается.
Чтобы нормально посмотреть, нужно всю dist положить в распоряжение какого-нибудь веб-сервера, например http-server, как выше посоветовали (и тоже самое делает вебпак, запускаемый по ng serve). Подойдет и nginx или apach или lighttpd, или даже IIS, если конечно сможете их настроить.
Ну или на хостинг.

Какой выбрать монитор для верстальщика в 2019 году?

широкоформатный или 2 вместо одного

Если ли смысл в 4k?

нет

Не раздражают ли верстальщиков изогнутые формы?

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

Как вы считаете?

программно или в уме

linux

Ну, это и фрондендеру нужно часто знать.

ЯП

Я сомневаюсь, что он сейчас сильно проще питона или php, JS очень довольно быстро развивается. А если взять в расчет TypeScript, то тем более.

В целом, если его очень хорошо протестировать, то разработчик уверен на 99.9%

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

то в случае с frontend все гораздо проще

Ну вот просто вообще не правда. Я также могу сказать, что в бэке учить нечего, изучил язык, изучил laravel, а sql даже учить не надо, используй ORM. Справедливое высказывание?

Теперь в общем. Во front-end много чего можно изучить
1) Верстка. Хороший front-end'ер должен хорошо верстать, вопреки частому мнению, что этим должен заниматься верстальщик. А верстка это отдельная широкая тема.
2) SVG, для многих интерактивных приложений, очень полезно использовать svg, а там куча своих особенностей, хаков и.т.д.
3) Webgl - довольно сложная тема, не знаю, есть ли в бэке что-то аналогичное по сложности.
4) Canvas - не просто знать, а уметь рисовать то, что желаешь.
5) Фрейморки, а там тебе для каждого свое разветвление.
6) Асинхронное программирование, которое для многих php-шников кажется непонятным.
7) ООП, т.к. в JS завезли классы, да и TypeScript часто нужно использовать.
8) Шаблоны проектирования - не только для бэкенда.
9) Webpack+gulp - ну это было.

Буду дополнять, если что-то еще в голову придет.

То что описано в пункте про "атомарные операции" больше всего похоже на методы в entity repository в Doctrine.

• Если эти операции специфичны для каких-то конкретных entity - можно реализовывать прямо в методах соответствующих репозиториев
  
• Если они общие для всех entities - то проще всего вынести их в промежуточный абстрактный repository и наследовать остальные custom repositories от него
  
• Если они общие для части entities - можно, к примеру, определить дополнительные интерфейсы, показывающие какие операции применимы к каким entities (у меня, например, зачастую используется ActivitableInterface для entities для которых есть флаг isActive) и дальше либо реализовать промежуточный абстрактный класс репозитория и наследовать custom repositories от него либо вынести эти операции в traits и подключать по мере необходимости.
  
  

Про "команды" не очень понятно, это про класс Command из symfony/command? Если да - то там есть раздельная инициализация через initialize(), туда передаётся OutputInterface и если сильно нужно - можно там вызвать некий отдельный сервис. Если не хочется прокидывать сервис вручную в каждую команду - можно автоматизировать это через setter + compiler pass либо через аннотицию @required

Сохраняйте в БД не возраст, а дату рождения.
Возраст можно вычислить в любой момент.

Просто не храните возраст отдельно, а вычисляйте динамически

Каким образом оно заполнено? Если программно, то имеет смысл сделать инпут с типом hidden и заполнять это значение у него.

1) Лучше SSR, если больше одной страницы. С Next.js SSR из коробки плюс можно использовать React-Native-Web.
2) Можно и сложные, так как любой нативный модуль можно дописать при потребности и кинуть бридж в JS слой. За 3 года работы с ним не встречал не решаемых задач. React Native лучшее решение на рынке, так как большинство нативных модулей уже написаны и доступны в open source. А хейтят React Native обычно нативщики, которые отстали от жизни и технологичных трендов.
3) Я понял что лучше не тратить время на сайты, а если и делать, то на react-native-web или еще лучше, но еще не пробывал react-native-dom

1) У SPA приложений проблема с SEO присутствует, так как приложение строится не на сервере, а на клиенте. Т.е все приложение, как ты писал выше, находится в js скриптах и сервер - отдает пустую html страницу со скриптами и т.д. Но само содержимое приложения в этой странице нет, так как оно формируется, после того как загрузились скрипты.
Получается, что поисковики видят пустую страницу без содержимого самого приложения.
Единственно, пока что google поисковик научился ждать, пока загрузятся скрипты и соответственно пока не построится приложение. Но есть очень много других поисковиков, которые это делать не умеют (Яндекс поисковик, к примеру).
Также плюс SSR в том, что страница быстрее появляется у клиента, так как оно строится как на клиенте так и на сервере. А без SSR, сначала отобразится пустая страница, потом загрузится скрипт и только потом отобразится само приложение. Но также рендеринг средних React приложений - это много вычислений, что на ноде очень плохо. (Но там можно делать свои хаки чтобы все работало шикарно)

Поэтому ты должен сравнить плюсы и минусы!

Если тебе хватает google поисковик и особо не нужно чтобы страница быстрее отображалась у клиента, то да можешь обойтись без SSR. (Конечно можешь использовать платные сервисы или какой либо виртуальный браузер, но это все гавно по сравнению с SSR. В этих решениях очень много минусов)

Если этого всего необходимо, то придется реализовать SSR. Это не сложно. Главное понять суть React и некоторых его сопутствующих библиотек если они используются (styled-components, redux). (Я реализовал SSR за 60 средних строк. Там много чего предусмотрено)

2) На нем можно создавать приложения, но я не использовал React Native и точно тебе сказать не могу. Но знаю что там, нету всего из коробки, если нужно будет что-то сложное, которого нет в React Native, то придется писать нативные модули под React Native. А так конечно можно его изучать и использовать.

3) SPA - тренд, поэтому надо. Также это очень хорошая концепция в перспективе, убедился на практике

Добро пожаловать в ООП

https://learn.javascript.ru/