Озон большой, продукты (и команды у них) разные. Но думаю, что озвучить здесь свою боль будет не лишним — наверняка тут есть и товарищи из нужной команды)
Если коммит не синхронный, то реплики могут отставать. Если синхронный, то скорость записи сильно падает. С этим можно жить, но см. пункт 2.
Если коммит несинхронный, то может возникнуть ситуация, когда WAL копится и не применяется на репликах из-за постоянных запросов. В итоге WAL забьется, и упадёт запись.
Статистика хранится на мастере и реплицируется на реплики, то есть читать только с реплик нельзя, нужно чтение и на мастере
Рано или поздно размер данных превысит какой-то порог, индекс перестанет попадать в кеш целиком, поедет статистика, pg начнет ошибаться в планах
Это из тех проблем, что я навскидку видел при отсутствии шардинга на условно больших Postgres базах
Брать на себя важные таски, когда есть много других активностей (встречи, «синки») — верный путь потерять все полимеры.
Я для себя сделал вывод, что нужно учиться доверять ответственность команде. Да, они сделают задачу медленнее, чем «я в вакуууме». Но проблема в том, что вакуума нет, вокруг воздух и другие активности, которые отвлекают лида. Поэтому задача либо не будет сделана, либо будет сделана в выходные. Что является путём в выгорание.
В таких компаниях надо противиться такой политике. Ну, или менять компанию, если изменить ничего нельзя
У меня опыт скорее положительный, чем отрицательный.
Код-ревью позволяет шарить знания («а что происходит в другом куске кода большого проекта»).
Код-ревью позволяет подтягивать общий уровень разработчиков. Если сениор ревьюит джуниора/миддла — он подскажет, как сделать лучше или направит в нужное русло. Если джуниор ревьюит сениора — он подмечает лучшие практики. Иногда он видит сильно усложненный код — и просит его упростить/снабдить комментариями. И в таком случае надо идти навстречу — код ведь чаще читают, чем пишут.
Код-ревью позволяет выработать общий стандарт кодирования не на бумаге. А если он есть на бумаге — закрепить его практикой.
В конце концов, код-ревью отлавливает баги, когда кто-то по незнанию меняет участок кода, который может что-то поломать, и это не покрыто тестами и комментариями по ряду причин.
Код-ревью держит качество кода и позволяет не скатываться до уровня «ну тут все понятно, комментарии не нужны, а тут можно и бизнес-валидацию прямо в контроллере сделать».
Код-ревью (а точнее мерж-реквесты) прекрасно сочетаются с всякими прогонами тестов, статическим анализом и прочими фишками.
Ну, это опыт с моей текущей колокольни: аутсорс в энтерпрайзе, команды по 6-25 человек разработчиков на проект.
Недавно был опыт фриланса, где код-ревью ограничивалось принципом «оно работает — вливай в девелоп». Качество кода было плавающим, очень много вещей разработчики изобретали заново в проекте, размером в 5-7 тысяч строк кода.
В .Net ничего этого нет. Зато есть изобретение велосипедов “в каждом проекте по-своему”. Вплоть до выбора нужного DI/IoC-контейнера на вкус разработчика (если разработчик вообще в курсе про существование контейнеров) и решение как управлять транзакциями (если разработчик опять же знает, что такое транзакции и кто-то догадался отключить автокоммит на Sql Server-е). Разве что ASP.NET MVC немного похож на Spring MVC (который лишь малая часть Spring Framework).
.Net Core принес встроенный DI, который покрывает 95% нужд. И что вообще плохого в выборе DI/IoC-контейнера самостоятельно из существующих? Лучше иметь одну прибитую гвоздями реализацию?
Про транзакции немного не понял, их управление строится через конфигурацию ORM, как и в мире Java. Или речь о распределенных?
Опять-таки .Net Core предлагает многое, из того, что есть в Spring Framework (если, конечно, описание его состава на википедии не врет). Не все, но многое. Остальные вещи можно найти, установить и «подружить».
И был IIS един и монолитен. И поняли Микрософт, что System.Web это плохо. И придумали OWIN.
OWIN дал возможность более гибко и прозрачно конфигурировать пайплайн http-запроса через middleware.
К нам обратился крупный российский перевозчик, владеющий внушительным автопарком. Его клиентами являются десятки логистических компаний и предприятий.
Аккаунт принадлежал одному из сотрудников логистической компании
То есть сотрудник логистической компании (а не перевозчика и владельца БД) имел доступ не только к данным своей компании, но и к чужим? При условии что:
Все запросы АСУ клиентов к базе данных (БД) перевозчика реализованы посредством набора Хранимых Процедур. Для управления доступом каждому клиенту выделяется его собственный аккаунт с набором необходимых ему полномочий и прав.
Database Project можно натравить на уже созданную базу и он заскриптует все ее объекты, разложив их по схемам и типам в виде sql-скриптов.Все дальнейшие действия идут над файлами проекта, а не на целевой базе, а значит любая VCS подойдет для контроля изменений.
Есть встроенный дизайнер, как в SSMS, который по сути генерирует скрипт, который также можно править ручками.
Есть встроенное сравнение схем между проектом и базой, базой и базой и т.д. Результаты сравнения видны по объектам, а также в виде diff-а sql-кода этих объектов, на одном экране.
Можно автоматом накатить изменения (не рекомендую), но лучше сгенерировать скрипт, внимательно его просмотреть (поправить при необходимости) и накатить.
Можно выбрать, какие объекты игнорировать при генерации скрипта.
Есть возможность деплоя базы разными способами.
Можно использовать отдельно сравнение схем баз, без ведения Database Project. Тогда теряется возможность контролировать изменения, но если у вас есть базы dev и prod и нет желания менять существующую схему работы — вполне годный вариант.
Invoke медленный, так как использует рефлексию, имя метода задается строкой, что чревато проблемами при рефакторинге. А так — вполне себе нормальное решение. Корутины чуть получше будут, хотя не уверен, что и это достаточно производительное решение. Впрочем, я не настолько хорош в Unity, поэтому нужны более компетентные люди
Если вы предпочли 2D вместо 3D, потому что испугались количества треугольников, то не думайте, что при использовании спрайтов с альфа-каналом треугольников будет сильно меньше. Спрайты с альфа-каналом, то есть с неровным контуром, тоже могут использовать множество треугольников и вершин.
Потому что при сложной альфа-маске спрайта гораздо производительнее будет триангулировать его видимую часть, оставив альфатесту только самые сложные места. Отрисовать сотню другую лишних треугольников и отсечь невидимое/видимое по z-тесту намного лучше, чем альфа-тест, ломающий параллелизм шейдеров.
Всегда используйте только атласы спрайтов PoT (Power of Two)
Unity здесь не причем. Иногда полезно узнать азы программирования компьютерной графики до знакомства с высокоуровневыми движками.
Естественно, вы хотите, чтобы игровая логика выполнялась в FixedUpdate (потому что в таком случае она будет надёжной и детерминированной), но анимации выполняются в простом Update. Уже замечаете грядущую проблему?
Если это такая проблема, она решается как минимум двумя способами: Update + Time.deltaTime. Либо переносом логики из события анимации в FixedUpdate, в этом случае в событии просто выставляем нужное состояние, а обрабатываем его в FixedUpdate.
Создавайте пулы объектов. Если вы стараетесь снизить нагрузку на процессор, куча вызовов Instantiate и Destroy НЕ будет вашими лучшими друзьями!
И опять же Unity не при чем. Даже в случае с ЯП без сборщика мусора new/delete слишком затратно в игровом цикле. В NASA, например, программа должна аллоцировать всю требуемую память на старте и не требовать аллокации во время работы.
Вам ведь нравится физика Unity? Жаль, что гравитация не согласована и её невозможно согласовать с симулированной вертикальной осью вашего игрового мира
Рисовать изометрию с пререндеренными спрайтами и хотеть 3d-физику? Месье знает толк…
Озон большой, продукты (и команды у них) разные. Но думаю, что озвучить здесь свою боль будет не лишним — наверняка тут есть и товарищи из нужной команды)
Chief Technical Officer.
Наиболее близкий перевод — Технический директор.
Если коммит не синхронный, то реплики могут отставать. Если синхронный, то скорость записи сильно падает. С этим можно жить, но см. пункт 2.
Если коммит несинхронный, то может возникнуть ситуация, когда WAL копится и не применяется на репликах из-за постоянных запросов. В итоге WAL забьется, и упадёт запись.
Статистика хранится на мастере и реплицируется на реплики, то есть читать только с реплик нельзя, нужно чтение и на мастере
Рано или поздно размер данных превысит какой-то порог, индекс перестанет попадать в кеш целиком, поедет статистика, pg начнет ошибаться в планах
Это из тех проблем, что я навскидку видел при отсутствии шардинга на условно больших Postgres базах
Думаю, можно, как минимум, заменьшенить Тимура в тексте новости — @XProger
Как максимум — попросить написать статью об этом проекте :)
Понять, что к такому привело:
Хорошо ли была поставлена задача?
Было ли промежуточное код-ревью? (Или классический MR на +10000 строк в 1 коммит в конце)
Были ли донесены до команды/человека сроки?
Что говорила команда/человек на дейликах (если они были)?
Ну, то есть можно сразу приступать к сжиганию ведьм (исполнитель нехороший и любит овер-инжиниринг), но лучше исходить из презумпции невиновности :)
Брать на себя важные таски, когда есть много других активностей (встречи, «синки») — верный путь потерять все полимеры.
Я для себя сделал вывод, что нужно учиться доверять ответственность команде. Да, они сделают задачу медленнее, чем «я в вакуууме». Но проблема в том, что вакуума нет, вокруг воздух и другие активности, которые отвлекают лида. Поэтому задача либо не будет сделана, либо будет сделана в выходные. Что является путём в выгорание.
В таких компаниях надо противиться такой политике. Ну, или менять компанию, если изменить ничего нельзя
Звучит слишком хорошо, должен же быть где-то подвох?
Ну, это опыт с моей текущей колокольни: аутсорс в энтерпрайзе, команды по 6-25 человек разработчиков на проект.
Недавно был опыт фриланса, где код-ревью ограничивалось принципом «оно работает — вливай в девелоп». Качество кода было плавающим, очень много вещей разработчики изобретали заново в проекте, размером в 5-7 тысяч строк кода.
На RHEL есть поддержка .net core: пруф.
холиварнаяпятничная статья :).Net Core принес встроенный DI, который покрывает 95% нужд. И что вообще плохого в выборе DI/IoC-контейнера самостоятельно из существующих? Лучше иметь одну прибитую гвоздями реализацию?
Про транзакции немного не понял, их управление строится через конфигурацию ORM, как и в мире Java. Или речь о распределенных?
Опять-таки .Net Core предлагает многое, из того, что есть в Spring Framework (если, конечно, описание его состава на википедии не врет). Не все, но многое. Остальные вещи можно найти, установить и «подружить».
OWIN дал возможность более гибко и прозрачно конфигурировать пайплайн http-запроса через middleware.
В общем, на вкус и цвет — фломастеры разные.
То есть сотрудник логистической компании (а не перевозчика и владельца БД) имел доступ не только к данным своей компании, но и к чужим? При условии что:
Есть встроенный дизайнер, как в SSMS, который по сути генерирует скрипт, который также можно править ручками.
Есть встроенное сравнение схем между проектом и базой, базой и базой и т.д. Результаты сравнения видны по объектам, а также в виде diff-а sql-кода этих объектов, на одном экране.
Можно автоматом накатить изменения (не рекомендую), но лучше сгенерировать скрипт, внимательно его просмотреть (поправить при необходимости) и накатить.
Можно выбрать, какие объекты игнорировать при генерации скрипта.
Есть возможность деплоя базы разными способами.
Можно использовать отдельно сравнение схем баз, без ведения Database Project. Тогда теряется возможность контролировать изменения, но если у вас есть базы dev и prod и нет желания менять существующую схему работы — вполне годный вариант.
Скриншот
Потому что при сложной альфа-маске спрайта гораздо производительнее будет триангулировать его видимую часть, оставив альфатесту только самые сложные места. Отрисовать сотню другую лишних треугольников и отсечь невидимое/видимое по z-тесту намного лучше, чем альфа-тест, ломающий параллелизм шейдеров.
Unity здесь не причем. Иногда полезно узнать азы программирования компьютерной графики до знакомства с высокоуровневыми движками.
Если это такая проблема, она решается как минимум двумя способами: Update + Time.deltaTime. Либо переносом логики из события анимации в FixedUpdate, в этом случае в событии просто выставляем нужное состояние, а обрабатываем его в FixedUpdate.
И опять же Unity не при чем. Даже в случае с ЯП без сборщика мусора new/delete слишком затратно в игровом цикле. В NASA, например, программа должна аллоцировать всю требуемую память на старте и не требовать аллокации во время работы.
Рисовать изометрию с пререндеренными спрайтами и хотеть 3d-физику? Месье знает толк…