Pull to refresh
30
0.2
Maxim W @maximw

backend developer

Send message

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

Никто не мешает сделать прокси на серверах в любом месте, даже в Европе или США.

Добавляет возможность решать ребусы в чужом коде.

Демократия штука хорошая. Но не везде применима. QA и пргораммист не должны принимать решения по поводу фичей. Они могут предложить фичу, геймдизайнеру надо попросить обоснования, чем эта фича сделает игру лучше, внимательно выслушать, и агрументированно отказать. Ну или согласиться. Но решение за геймдизайнером, это его работа. Как и программист не должен собрать консилиум из QA и уборщицы по поводу SQL-запроса. Но если уборщица шарит в этой теме, хорошо дать ей возможность высказаться и выслушать.

А я to использую для функций преобразования типа toArray, toString

Anime.js - довольно тормознутая. По крайней мере таймлайн. При добавлении новой анимации - пересчитывает все с нуля. У меня за раз загружается 1000-1500 анимаций, и пришлось разбить и скармливать почастям в setInterval(), чтоб библиотека не вешала браузер на 20 секунд. Получилось немного дольше, но не виснет все.

Если это не публичное API, то пусть решает пользователь API, например, фронтэнд. Как им легче обрабатывать ошибки.

Да, но самое главное в искусственном интеллекте не просто поиск экстремума, а создание самой функции, нахождение нужных коэффициентов.

Распределенная база данных и блокчейн - разные вещи.

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

То, что вы говорите это распределенная БД, где тоже используется криптография для валидации и аутентификации данных. Но решается как раз ваша задача.

А зачем для этого блокчейн? Какие он свойства системе добавляет?

Мне кажется, фокус в том, что в статье есть бездоказательный переход в том месте, что длина траектории точки B кратна числу оборотов окружности b, примерно как хитрое извлечение корня в доказательстве, что 2 + 2 = 5. По-моему это неправильно. Ну и в конце путается процесс вращения и обращения (в терминах астрономии)

К моменту когда окружность a вернется в начальную позицию, как много оборотов она совершит?

Наверно, опечатка, имеется в виду откружность b?

Да. Вообще, не упомянуть Multi-Edit в статье про текстовые IDE это какое-то лютейшее упущение. По-мне, он должен был бы быть на первом месте.

Взаимодействие множества команд - административная задача. Конечно, она влияет на архитектуру разработки и ахритектуру системы.

Интерфейсов и тестов с документацией мало? Вы о чём вообще?

Вы про интерфейсы в рамках одного ЯП? А что если для разных частей системы нужны разные технологические стеки. Я намеренно не использовал термин "интерфейс", а писал про контракты, чтоб не путать с интерфейсами в ЯП.

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

Микро/немикро - это вопрос терминологии. Я лично не могу сказать, где проходит граница между ними. "Микросервисы" просто устоявшийся термин и все примерно понимают о чем реь.

Я не знаю, где вы в моих словаях увидели распил бюждетов. Но если вы работали в команде хотя бы 20 разрабочиков, то знаете, как в случае монолита сложно поддерживать контракты (интерфейсы) между различными частями продука. Хорошо, если можно поощаться с коллегой когда он за соседним столом или хотя бы в соседнем кабинете. А если это десяток офисов в разных часовых поясах, начинается геморр. И это уже именно административная проблема. Которую позволяет решить разделение на микросервисы (или сервисы, если хотите) и дает возможность довольно четко поддерживать контракты, минимизируя общение и количество согласований между командами, т.е. ускорять разработку. И кроме кодинга есть еще куча вопросов - тесты (не юниты, а итеграционные или е2е), QA, CI/CD, который у каждой команды может быть свой.

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

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

1
23 ...

Information

Rating
2,327-th
Location
Россия
Registered
Activity

Specialization

Specialist
Lead