Не сравнивайте Microsoft и ИП Иванов И.И. Немного разные весовые категории. На словах все то правильно, на практике картина может быть иной.

Еще не встречал в договорах ограничение об убытках. В практике такого не было. И, думаю, если включать такие пункты в договора, клиенты могут начать сомневаться в ваших проф. качествах.

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

Можно. Кто спорит.

Суть того, что писал как раз в том, чтобы быть готовым к сюрпризам. Про максимальные штрафы ничего не говорилось. Озвучивались суммы о которых слышал лично. По поводу банка говорить не буду, чтобы не было рекламы. На банка.ру выбирайте по рейтингам и отзывам. Мой входит топ 10.

Да нет такого понятия как ограничение ответственности в договоре. ИП как организационно правовая форма в отличии от ООО отвечает своим имуществом. Если вы сделали работу и в следствии этого по вашей вене клиент получил убыток. Он может подать на вас в суд и потребовать возмещение. На практике это редкость. Но вероятность есть.

ИП штука хорошая и дает некоторую свободу и удобство. Бюрократия не сложная. Но нужно всегда перестраховываться и быть готовым к так называемым «нежданчикам» от налоговой и государства в целом.

Например, при вселенском факапе в обмене данными между ФНС и ПФР 2017-2018 года, выдрали почти 30 тыс с расчетного счета, при том что все было уже оплачено. ПФР посылало в налоговую, налоговая в ПФР. Времени и нервов потрачено куча. В процессе разбирательства встречал людей у кого больше 100к сняли.

Или вполне норма, что с расчетного счета снимут пени. За что? Да фиг его знает. Благо не сильно много.

Пару советов:
1. Правильно выбирайте банк для расчетного счета. В нормальных банках блокируют часть счета, в не очень — весь счет. Хотя может это зависит от налоговой. Встречал человека в ПФР, которому заблокировали р\с из 1 рубля.
2. Будьте внимательны с корреспонденцией от налоговой. Особенно если живете не по прописке. Так придет уведомление с требованием в течении 5 дней предоставить пояснения или еще что, а вы и не в курсе. А потом разгребать придется.

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

Ответ тут

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

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

А как вообще синхронизируются данные (базы, файлы) между дата центрами? Ведь, например, знать о определенном юзере (его аватарке, настройках и.т.д) порой нужно в обоих центрах. Да и запись в них тоже по идее может быть из любого места. Что будет при одновременной записи в двух местах.

заменив его хорошо зарекомендовавшей себя “master-master” репликацией между площадками

Меня интересуют два вопроса:
1. как вы делаете «master-master» репликацию между mysql базами?
2. как синхронизируются дынные между территориально удаленными серверами?

Можно об этом рассказать или хотя бы дать источники. Сколько я этим не интересовался. Везде говорили, что «master-master» в mysql дает кашу в данных. А на территориально удаленных серверах есть задержка.

Ок. Спасибо!

Было бы очень удобно добавить следующие функции:

• Настройка репликации. Например, не реплицировать определенный папки в дереве. К примеру папку кэша. Или файлы по маске. К примеру, svn/git.
• Синхранизация с сервером. Единовременное скачивание с сервера всего дерева файлов на клиент по запросу пользователя. Т.е. репликация в обратную сторону с сохранением фильтров репликации. К примеру, программист ведет разработку с разных компов. Дома и с работы. Поработав на работе, он приходит домой, нажимает кнопку синхранизации и получает у себя на компе свежее дерево файлов с которым можно работать

Статья как раз во время! Хотел потеснить облачный хостинг.
Ловите виртуальный плюс в карму.

Да. Обычно Varnish учат игнорировать куки.
Например так.

sub vcl_recv {
  unset req.http.cookie;
}

Или делают это более хитрее. Для примера можно посмотреть посмотреть конфиги Varnish, когда его ставят перед Drupal или Wordpress. В любом случае без модификации самого приложения не обойтись.

1. Varnish по-умолчанию не кэширует страницы при наличии куки.

2. Кука создается всегда при старте сессии. Не стартовать сессию для не авторизованных пользователей в Symfony нельзя, пользуясь стандартным механизмом Security Component.

3. Научить Varnish игнорировать конкретную куку можно, но как по ней различить авторизованного пользователя(кэшировать нельзя) и не авторизованного(кэшировать можно) я пока не придумал и не нашел.

4. уникальная кука — имелось ввиду значение.

Правильно. И на уровне Symfony это работает. Но Varnish видя куку не авторизованного пользователя это дело не кэширует. Как различить в Varnish авторизованного и не авторизованного пользователя я пока не нашел.

Вы правы, переименовал.