DATA API для Amazon Aurora Serverless

Как работает подключение к традиционной базе данных? Вы открываете соединение, используете его для обработки одного или нескольких запросов SQL или других операторов, а затем закрываете соединение. Вы, вероятно, использовали клиентскую библиотеку, специфичную для вашей операционной системы, языка программирования и базы данных. В какой-то момент вы поняли, что создание соединений занимало много времени и занимало память на ядре базы данных.

Виталий Брагилевский (@_bravit) пока что еще преподает в ЮФУ курсы по Haskell и теории алгоритмов. Также, дает выездные курсы в других городах, является редактором и переводчиком множества книг о Haskell и функциональном программировании, состоит в комитетах Haskell 2020 и компилятора GHC и активно выступает на конференциях. К примеру, он прочитает краткий курс компиляторостроения на Haskell на функциональной конференции FPURE в Казани.

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

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

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

Я даже не знаю, как ответить на более простые вопросы. Несмотря на то, что пишу на Scala больше 3 лет, я не могу на пальцах объяснить преимущества языка для человека извне. Например, пару месяцев назад мне довелось провести не лучшую дискуссию.

Привет! Меня зовут Миша, и я Senior QА с коммерческим опытом более 6 лет. Сейчас я работаю в Provectus, но начинал я свой путь тестировщика еще в студенческие годы с участия в альфа- и бета-тестах различных игр. В какой-то момент подумал: «Почему бы не начать заниматься этим профессионально?». И пошло-поехало. За это время я успел поучаствовать в разных проектах: от стартапов до энтерпрайзов, от небольших обучающих юнити-игр до огромных приложений с сильнейшей бизнес-логикой.

Но зачастую меня внедряли в небольшие команды, в которых было от 5 разработчиков на 1-2 тестировщика и, как правило, большая жара в проекте. Собственно, о том, как научиться понимать, где вы очутились и как начинать продвигаться в постановке QA-процессов, я и хочу поделиться с вами.

Первым делом вам стоит понять, на каком вы проекте

Накопив опыт от участия в проектах, я бы условно разделил их на 3 вида:

• проекты без тестирования;
• проекты с недобросовестным тестированием;
• проекты с тестированием.