Обновить
-8
0

Пользователь

Отправить сообщение

Serverless, это когда на каждый запрос, создаётся выделяется сервер и запускается код, а вы платите за время работы этого кода. Если к бэку никто обращается вы не платите ничего, а если резкий наплыв пользователей, то оно само масштабируеься, а вы платите ту же цену за запрос. Готовность под Serverless, это быстрый холодный старт, и низкое время работы без кэшей. Примеры:

https://aws.amazon.com/ru/lambda/

https://selectel.ru/services/cloud/serverless/

https://azure.microsoft.com/ru-ru/products/functions/#overview

Введение к статье написали. Теперь дайте знать как выбирать язык программирования.

Из "статьи" можно вынести только, что если хотите в веб-разработку, то надо учить JS. Так а как начать карьеру? Какими навыками нужно обладать, что бы взяли на Junior-позицию?

Питон популярен? Хорошо. Питон-разработчик, это back-end на django? Я вас удивлю, но на тот же Node JS вакансий гораздо больше. DS, ML? Ну так на это отдельно нужно учиться и порог вхождения гораздо выше, чем на тот же Front-end.

Очередная статья с водичкой, опытом найма даже и не пахнет.

Тема не раскрыта. Хотя и очень интересная. Так как большому количеству проектов походит вариант глупого бэка, и оптимизации некоторых процессов в далёком будущем когда бизнес вырастет.

Дайте больше конкретики по strapi. Есть ли поддержка:

  • Авторизации/аутентификации

  • Разграничения доступа к данным, админу можно видеть данные всех клиентов, не админу только свои

  • Хранения схемы БД под git, а не только UI редактор

  • Миграций БД (захотели переименовать поле, или превратить айдишник из числа в строку)

  • Деплоя в Serverless

Сколько кода нужно писать? Как сложно добавить новую сущность или изменить старую (сколько кода и кликов мышкой)?

Как по мне война между разработчиками и девопсами возникает из-за низкой квалификации последних. Хорошие девопсы, это программисты, которые постигли SDLC, CI/CD, Cloud, IaaC практики. Плохие девопсы, это неучи после курсов, либо сисадмины не имеющие никакого представления о разработке ПО.

Виртуальные окружения, инфраструктура как код (императивный код высокого уровня, а не yml или скрипты на баше), удобные и стандартизированные на всю компанию инструменты для логгирования, конфигурирования и отладки -- вот секрет успеха и быстрой разработки.

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

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

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

No Code - это негибко. Зачастую, проще написать какую-нибудь библиотеку, покрыть её тестами. а потом реализовывать бизнес требования в пару строк кода. Бизнес пользователи генерирующие бизнес правила, должны четко ставить задачу. А программист быстро превращать это в код.

А ещё можно обучить непрограммистов формату json (некоторым конструкциям js, markdown в зависимости от задачи) и писать конфиги на нем. Можно даже написать инструмент который визуализирует эту json-конфигурацию (проще чем писать визуальный редактор). Главное, что бы ядром был исходный текст.

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

Это киллер фича, которая обязывает инициализировать указанные свойства в DTO.

Казалось бы есть конструктор для этого, но систаксис с инициализатором свойств намного удобнее. Это ещё один шаг в борьбе с NullReferreceException.

https://github.com/dotnet/csharplang/blob/main/proposals/required-members.md

https://github.com/dotnet/csharplang/issues/3630

И в догонку Simplified parameters null validation. Которое гарантирует null-безапасность и пишет бойлерплейт за вас.

// Before
void Insert(string s) {
  if (s is null)
    throw new ArgumentNullException(nameof(s));
  ...
}

// After
void Insert(string s!) {
  ...
}

https://github.com/dotnet/csharplang/issues/2145

Required properties не добавили, расходимся.

Идея и реализация замечательная. Однако не работает на Android Firefox с тачем. Наверняка нужно подписать на какие-то touch-события вдобавок к событиям мыши.

Я рекомендую ShareX

12 ...
12

Информация

В рейтинге
6 268-й
Зарегистрирован
Активность