Официальный релиз Go 1.18 состоится только через пару месяцев. Это первый предварительный выпуск Go 1.18, чтобы вы могли попробовать его и сообщить о проблемах. Go 1.18 Beta 1 — это огромный объём работы всей команды разработчиков Go в Google и участников проекта Go по всему миру. Нам очень хочется узнать ваше мнение.

Привет, Хабр! Я работаю старшим Go-разработчиком в «Лаборатории Касперского». Сегодня хочу поговорить о том, как искать узкие места и оптимизировать код на Go. Разберу процесс профилирования и оптимизации на примере простого веб-сервиса — покажу, с помощью каких встроенных инструментов искать функции, активнее всего использующие CPU и память. Расскажу, какие можно применять подходы, чтобы повысить производительность. Хотя речь пойдет о микрооптимизации, в моем примере шаг за шагом производительность удалось поднять в 5 раз!

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

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

Эта статья является переводом материала «Tackling Complexity in CQRS».

Шаблон CQRS может творить чудеса: он может максимизировать масштабируемость, производительность, безопасность и даже «превзойти» теорему CAP. Тем не менее, например, в своей статье о CQRS Мартин Фаулер утверждает, что шаблон следует применять умеренно и даже осторожно:

«...для большинства систем CQRS добавляет риски»;

«...вы должны быть очень осторожны при использовании CQRS»;

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

С моей точки зрения, сложность, вызванная CQRS, в значительной степени случайна, и поэтому ее можно избежать. Чтобы проиллюстрировать свою точку зрения, я хочу обсудить цель CQRS, а затем проанализировать 3 распространенных источника случайной сложности в системах, использующие CQRS.

Как ранее было отмечено в предыдущем посте концепция рабочего каталога Angular закономерно эволюционировала до поддержки полноценных workspace - проверенный и понятный способ управления сложностью при масштабировании процесса разработки (Visual Studio Solution , SBT Multi-Project builds , Gradle Multi-Project Builds , RushJS , Lerna и др. ).

Для каждого, кто практически сталкивался с Angular проектом средней руки, не будет секретом, что angular.json может легко содержать тысячи строк убористого JSON, с невероятным, даже нарочито избыточным количеством дублирующейся информации. Проблема отнюдь не новая и дающая о себе знать при eмасштабировании процесса разработки сложного продукта. Компактность и человеко-читаемость формата явно не была в приоритетах, и как-бы намекает, что человеку тут и нечего делать. Из этого и будем исходить.

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

Всякая сложная инфраструктура, поступательно развивавшаяся на протяжении длительного времени, содержит в себе набор разных архитектурных неоптимальностей, а то и откровенных недостатков. Порой эти недостатки становятся неожиданным препятствием для внедрения новых сервисов. Инфраструктура М.Видео-Эльдорадо в этом отношении не является исключением, в чем мы признаемся без излишней рефлексии. Но что с этим делать? Как сделать систему надежной и пригодной для дальнейшего развития? За ответами мы пришли к Александру Алехину, директору по развитию ИТ архитектуры.

Эта статья берет за основу Go 1.12.

Go радует нас легким и умным управлением горутинами. Легким, поскольку стек горутин изначально весит всего 2 КБ, а умным, потому что горутины могут автоматически увеличиваться/уменьшаться в соответствии с нашими потребностями.

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

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

Видео моего выступления на конференции Golang Live 2020 можно посмотреть здесь.

Проработав много лет в IT, я тем не менее имею довольно небольшой опыт работы в компаниях производящих программное обеспечение на продажу. В основном доводилось разрабатывать софт для использования только в своей-же организации. А это создаёт определенную специфику. Программист в этом случае оказывается даже не full stack разработчиком, а вообще всем - аналитиком, постановщиком задачи, менеджером проекта, разработчиком, администратором, поддержкой, писателем инструкций и Бог знает кем ещё. Что позволяет руководствоваться только здравым смыслом и своим пониманием задачи без оглядки на общепринятую практику и стандарты компании. Именно такой опыт отступления от норм и правил я и хочу суммировать в этой статье, потому она и называется "вредные советы". Так что, если Вы собираетесь сдавать экзамен по программированию или устраиваетесь на работу в Microsoft, лучше это не читать.

Сегодня рассмотрю архитектурный паттерн CQRS и его возможное место в вашей архитектуре. Также осуществим его реализацию на языке golang.

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

• немного затронем основы клиент-серверного протокола MySQL, его базовое устройство и принципы работы;

• дальше перейдем к Go части и разберем реализацию пула соединений;

• будем двигаться от конфигурирования соединений к выполнению запросов, параллельно заглядывая в код драйвера.

Надеюсь каждый для себя найдет что-то полезное.

Предисловие.

HR-ы в последнее время активизировались и активно долбят своими предложениями.

Во-первых, господа, какого рожна лешего моё старое резюме с hh оказалось у вас? Мои данные видимо слили на huntflow или еще куда-то.

Во-вторых, вы умеете читать? Я middle! middle! Или вы думаете, что у меня низкая самооценка? я скромный senior с всего-то 5-летним опытом? Да у меня в резюме написано 2 года на golang. 2 года, Карл!

Вы думаете я ведущий, потому что вам так захотелось? Я могу быть ведущим ну разве что свадеб!

Легко ли разработать новый API? На что обратить внимание, чтобы не ошибиться при реализации, и к каким компромиссам стоит быть готовым?

Привет, Хабр! Меня зовут Иван Ивашковский. Я руковожу группой разработки международных проектов в Яндекс Go. Этот пост — продолжение цикла историй о вымышленном стажёре Васе. Предыдущий материал, про идемпотентность, можно почитать здесь. В посте я расскажу, как Вася разрабатывал API для новой фичи и с какими проблемами он столкнулся в процессе. В конце приведу чеклист с советами, как проверить себя на каждом этапе разработки, если вы решаете похожую задачу.