Ярослав Сиваков

Вероятно, бандлы станут чуть менее актуальными (т.к. да - в одном запросе клиент (браузер) сможет запросить сразу кучу картинок, например, или кучу отдельных js-файлов). Но вебпак уйдёт очень не скоро - он же не только пакует код в бандлы - он ещё исправляет код (babel-ы всякие там работают), оптимизирует css (всякие там препроцессоры запускает - less, scss), готовит svg (иконки) и другие процессы производит.

Можно. Есть ли смысл? Зависит от ваших способностей. В любом случае - попробовать никто не мешает!

Чтобы всё сложилось в голове, нужно поработать со средним/крупным проектом. Тогда всё сложится. Как иначе? Если вы хотите до устройства на работу уже получить опыт - сделайте что-то для себя. Например, простенькую социальную сеть. Представьте, что фотографии закачиваются пользователями рекой. Вам их нужно хранить, масштабировать, временами выводить сервера из обращения для обслуживания и при этом, в идеале, чтобы всё продолжало работать как ни в чём не бывало. Как это сделать? Вот тут вам пригодится и Mongo с его схемой данных, появляющейся "на лету", и микросервисы и вообще - придётся подумать как это всё будет друг с другом взаимодействовать так, чтобы [почти] на нарушалась целостность данных и [почти] всё было доступно 24/7.

Из забугорных активно пользую для себя и на работе Asana - https://app.asana.com/ - по сути это простой список задач с метками, исполнителями, подзадачами, комментариями и пр. Бесплатен для небольшого кол-ва разрабов.

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

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

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

>Брать тестера? Менять разработчиков?
Оба варианта возможны.

Если разрабы получают много денег и сроки жёстко на них не давят - вы вправе ожидать высокого качества кода. В этом случае, неплохо было бы их направить в правильное русло: например, попросить их составлять план тестирования (в виде простенькой доки) после выполнения задачи и присылать вам его "на проверку", после чего вы бы отправляли "утверждённый" план им назад с просьбой выполнить его. Если люди саботируют это - вы вправе с ними попрощаться (либо же они уйдут сами :))).

Если же разрабы получают не сильно много (либо у них жёсткие сроки) - то либо нанимать новых, подороже, либо брать тестера. Лично я сторонник первого пути в случае небольших команд (5-6 разрабов) - найми правильных людей и у тебя, как руководителя, сразу исчезнет проблема "нужно всё перепроверять, а местами и переделывать". А вот для команд побольше, как мне кажется, нужен системный подход - отдельные тестировщики.

https://stackoverflow.com/questions/11532636/how-t...

Кажется, эти вопросы задаёт себе каждый человек в своей жизни. Есть хорошее правило по этому поводу: не хочешь ничего делать - ничего не делай! :) Ибо зачем вам какая-то мотивация? Вам что - обязательно нужно делать сайты? Если бы это было так - вы бы не задавали этот вопрос. Так что хватит уже красноглазить - займитесь тем, что вам по-настоящему хочется делать!

Для большинства сайтов, на мой взгляд, делать какую-то мегаадаптивную вёрстку - слишком дорогое удовольствие.

Поэтому, обычно, берётся монитор минимального размера по ширине (в смысле кол-ва пикселей, конечно) и от этого размера пляшется. Т.е. если минимальный монитор, который вы хотите поддерживать - 1280px, то размер сайта по ширине - это обычно 1280px минус размер полоски скролла (~1200px).

Понятно, что чем меньше взять "минимальный размер" тем у большего кол-ва пользователей будет видно всё так, как вы задумали, но тем меньше контента влезет на экран. Так что выбирайте в зависимости от аудитории и контента.

Обычно, это называют overlay или shadow.

Чуток разбираюсь в теме и меня смущает ваше "Коэффициенты на матчи меня не интересуют, они будут формироваться в режиме реального времени в зависимости от суммы поставленной на ту или иную команду". На сколько я знаю, сейчас букмейкерки очень развитые - событий, на которые можно поставить - много, а не только исход матча. Данные для событий и коэффициенты покупать - это порядка нескольких тысяч $ в месяц. Плюс заложиться на расходы в первые месяцы, потому что есть тут подводные камни. Самому - нужно нанимать хотя бы нескольких человек под это дело.
Т.е. сделать простой сайт со ставками на исходы - это, по моим меркам, очень просто. А вот привлечь туда людей будет очень трудно, т.к. у ваших конкурентов всё будет куда интереснее, чего без денег не добиться. Да и есть ли у вас хотя бы ~50 тыс. руб. на рекламу в месяц (а прибыль вы увидите, в лучшем случае, через год)? Готовы ли вы идти на такой риск?

https://github.com/akveo/ng2-admin - шаблон админки - есть и на 1.x и на 2.x версиях.

Если у вас проект, где реально все объекты одинаковые с точки зрения обработки сервером - то можно и универсально сделать. Но обычно так не бывает - обычно для каждого объекта нужно проверять взаимосвязи, права доступа, чего-нибудь вычислять, что клиент не прислал и т.п. Поэтому, в реальном проекте - однозначно более простой, но более длинный вариант с 3 контроллерами.

Либо какой-то нехороший плагин в браузере, либо вирус в системе.

К сожалению, в Angular 2+ не предусмотрено механизма наследования компонентов. Поэтому - либо универсальные компоненты, которые "могут всё" и настраиваются через параметры, либо бейте ваши компоненты на более мелкие и делайте много разных компонентов из этих маленьких (т.е. решайте вопрос через агрегацию).

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