Пользователь
Ключевой идеей микросервисов является возможность независимого изменения и развертывания отдельно взятой функциональности. Фактически, микросервисы - это еще одна форма модульной декомпозиции. Навыки правильного выделения границ модулей являются ключом к построению успешной микросервисной архитектуры. Выделяют три ключевые концепции, определяющих качество границ микросервисов.
Всем привет! Меня зовут Илья Денисов, я занимаюсь backend разработкой уже более пяти лет и сейчас пишу на языке go. Сегодня я предлагаю вам поговорить о кэшировании. Постараюсь рассказать о базовых концепциях, а также затронуть ряд особенностей, неочевидных на первый взгляд.
Архитектор – это звучит… Звучит как-то не понятно. Наверное, поэтому всегда добавляют что-то. Ну типа «системный архитектор» или там «программный архитектор». Не то чтоб так стало понятно, что он делает, но точно кто-то важный. Я вообще пишу «архитектор информационных систем и программного обеспечения». Это ж как назовёшься -так и поплывешь! С архитекторами тут вообще такое дело – это как бы и не профессия. Ведь архитектором как стать? Либо тебя назовут таковым, либо сам назовёшься. Другого пути нет. Ни школы, ни спец. образования, никаких то там универсальных сертификатов нету. Только название и есть.
А раз оно есть – значит зачем-нибудь нужно! А нужно чтоб как-то указать на необходимость главного элемента мозаики – архитектуры. А раз нужен элемент, то за него, конечно, должен кто-то да отвечать. А раз должен, то вот и появляется такая должность.
Появляется, кстати, не всегда и не везде. Ведь не в каждой луже можно встретить кораблик. В самых больших - есть шанс. В такие лужи обычно и заплывают корабли из стартрека. Enterprise. Что же ищут эти корабли в корпоративных болотах? Чтоб вода не иссыхала, ветер только попутный и кругом гавани с блекджеком… Проще говоря им нужен сервис на много лет и так, чтоб исполнялись все их капризы за обещанные деньги.
Чтоб избежать проверенного классического сценария «много, дорого, бестолково» нужны ориентиры. Пунктир намеченного пути на карте требований и функционала. Это не красота и элегантность рисунков Леонардо, и не лабиринты цвета Поллока. Архитектура вообще не про искусство. Нет, все любят, когда красиво. Вот я бы строил дом, тоже бы хотел не бетонную коробку, а чтоб в вечность. Но у вечности, однако свои расценки. Так что даже Джи-мэн с кейсом полным золота хочет хайп и тренды, но строго в бюджет. Архитектура даёт парадигму.
Инструменты покрытия кода помогают понять, какая часть кодовой базы выполняется (или, как еще говорят, покрывается) при выполнении данного набора тестов. Какое-то время Go поддерживал измерение покрытия кода на уровне пакета, введенное в Go 1.2, она включалась флагом команды go test -cover.
Это хорошо работает в большинстве случаев, но при разработке больших приложений обнаруживаются недостатки. Для больших приложений разработчики часто пишут интеграционные тесты, которые проверяют поведение всей программы (в дополнение к модульным тестам на уровне пакета).
В отличие от тестирования пакетов по отдельности, этот тип тестирования обычно включает создание полноценного двоичного файла приложения, его запуск на наборе репрезентативных входных данных (или под рабочей нагрузкой, если это сервер), чтобы убедиться, что все пакеты компонентов корректно работают вместе.
Двоичные файлы интеграционных тестов создаются командой go build, а не go test, поэтому инструментарий Go до сих пор не предоставлял простого способа сбора профиля покрытия этих тестов.
С версии Go 1.20 программы с инструментированием покрытия можно создавать командой go build -cover, а затем, чтобы расширить область покрытия, передавать эти инструментированные двоичные файлы в интеграционный тест.
Ниже приводим пример того, как работают эти новые функции, расскажем о вариантах применения и рабочем процессе сбора профилей покрытия из интеграционных тестов.
Самое простое представление двумерного клеточного автомата основано на двух характеристиках: клетки имеют всего 2 состояния; правила изменения состояния зависят только от количества живых соседей из окрестности Мура первого порядка (8 окружающих).
Такая категория КА называется «Life-like», по названию самого известного автомата с такими характеристиками – «Conway's Game of Life». Игра «Жизнь» Конвея работает на правиле B3/S23, т.е. для рождения клетки требуется ровно 3 живых соседа, для выживания – 2 или 3. Во всех других случаях клетка умирает (или же остаётся пустой).
Всего в данной категории у нас существует 218 вариантов правил. Очень немногая часть из них получила в сообществе собственные названия, сверх обычного именования нотацией.
Сегодня взглянем на самых интересных представителей.
Есть несколько охватывающих всё принципов, которые резюмируют представления о том, как писать читаемый код на языке Go. Ниже перечислены признаки читаемого кода в порядке их важности:
Подробности — к старту курса по Backend-разработке на Go.
В эпоху быстрорастущих приложений важно иметь возможность контролировать состояние системы в любой момент времени. Одними из требований для достижения этого являются логи и метрики, которые помогают нам следить за многими параметрами, такими как количество запросов в секунду (RPS), потребление памяти, cache git и т.д. Однако, есть ещё один полезный инструмент - трейсинг. В этой статье мы ознакомимся со стандартом OpenTelemetry в языке Go и инструментом Jaeger
Наступил Апокалипсис.
Нет, не стоит бежать запасаться банками с консервами и крышками отечественной бай-колы! Апокалипсис произошёл только в нашей фантазии и с определённой целью — чтобы проверить, а может ли человек, обладающий только книгами по теме и стандартной библиотекой языка, воссоздать инструмент, который будет служить ему верой и правдой?
Так родился учебный проект SicQL, реляционная СУБД, чей символ — сова — это олицетворение силы знаний и мудрости. Олицетворение тех знаний и той мудрости, которые мы получим, создав с нуля то, чем мы пользуемся каждый день, может, не осознавая всей сложности таких инструментов.
Приглашаю присоединиться к увлекательному путешествию!
Привет! Меня зовут Виталий, я фронтенд-тимлид в KTS. Рассказываю, что входит в нашей компании в обязанности тимлида, а что — нет. Спойлер: это не расставление задач в таск-трекере.
Зоны ответственности тимлида отличаются от компании к компании и от проекта к проекту. Иногда позиция включает в себя менеджерскую работу, иногда нет. Бывает так, что должность тимлида совсем отсутствует в компании — есть только менеджеры.
Мы выстроили свою схему разделения обязанностей между тимлидами, менеджерами и аналитиками. Она позволяет снять с тимлидов менеджерскую работу, для которой не нужно обладать глубокими техническими знаниями, но нужно часто переключаться между разными задачами и сотрудниками. Это даёт возможность тимлидам работать над теми задачами, которые и отличают их от менеджеров, — с технической частью проекта. Рассказываем, как мы реализовали эту схему для компании из 80 сотрудников.
Это первая статья из серии из двух частей, в которой мы в форме туториала изучаем компилятор Go. Компилятор большой, и для его корректного описания потребовалась бы целая книга, поэтому идея этих постов заключается в том, чтобы вместо этого обеспечить быстрое погружение в тему. В будущем я планирую написать ряд более описательных статей о конкретных областях компилятора.
Мы собираемся изменить компилятор Go, добавив новую (условно) языковую фичу, и собрать модифицированный компилятор, чтобы ее опробовать.
Приветствую тебя, дорогой читатель! Мне 21, я студент и младший Go-разработчик, а это - мой первый пост на Хабре. Недавно в компании с одногруппником мы решили взяться за амбициозный проект и я решил, что он, как никакой другой, подходит под первую статью. Проект заключается в создании библиотеки, содержащей основные алгоритмы на графах.
Есть много способов приготовить картошку. Вот тут написано больше 100 способов. Рецептов кофе существует множество. Лично я предпочитаю черный, без сахара. Кто-то любит с молоком, кто-то предпочитает холодный. Бессмысленно спорить, какой из них лучше.
Способов организовать разработку программного обеспечения наверняка существует не меньше, есть куча нюансов и разных методов, подходящих на любой вкус и кошелек.
Я не готов спорить и говорить, что какой-то из них лучше других, естественно, у каждого есть свои предпочтения. Я всего лишь хочу поделиться своим любимым рецептом приготовления программного обеспечения. Может быть вам тоже понравится.
Да, Angular запускает 14-ю версию, что уже является традицией в его экосистеме, поскольку каждые шесть месяцев выпускается новая версия с усовершенствованиями, обновлениями и новыми возможностями для разработки более мощных приложений.
Это не должно повлиять на другие проекты Angular. Запомните — "Angular". Неважно, какую версию вы используете, главное, что вы применяете Angular. Каждый год вы получаете новую версию Ubuntu, обновляете свой мобильный телефон, или каждые восемь месяцев NodeJS публикует новую версию.
Статей о работе с PostgreSQL и её преимуществах достаточно много, но не всегда из них понятно, как следить за состоянием базы и метриками, влияющими на её оптимальную работу. В статье подробно рассмотрим SQL-запросы, которые помогут вам отслеживать эти показатели и просто могут быть полезны как пользователю.
Много раз при обсуждении преимуществ и прелестей Go, как языка разработки, мне приходилось слышать что-то вроде «у вас даже нет дженериков» или «вот завезут дженерики, тогда и поговорим». Так вот, дженерики завезли, давайте посмотрим что из этого вышло.
Меня зовут Павел Грязнов. Я уже несколько лет пишу на Go в прод, хотя знакомство с языком начал с самых ранних версий. Видел как Garbage Collector мог сделать stop the world на пару секунд, страдал от отсутствия системы зависимостей и других проблем. В этой статье я расскажу о дженериках в Go. Начнём с самых основ, продолжим более продвинутыми примерами и закончим бенчмарками.
Чтобы лучше показать работу дженериков на контрасте, я сравню примеры их использования на двух языках — Python и Go. C Python последний раз работал слишком давно, поэтому вторую часть доклада мне помогли сделать коллеги из Evrone. Пойдем по порядку: разберем, для чего нужны дженерики и какие задачи они решают. Посмотрим, как выглядит мир без дженериков, на их синтаксис, ограничения, бенчмарки и немного затронем функциональное программирование.
Это сложная тема, которая периодически всплывает в среде IT-специалистов, об этом сказано уже немало, а вот для «неайтишников» многое может оказаться новостью. Как для тех, кто хочет «войти в IT», так и для тех, кто по роду своей деятельности вынужден работать вместе с IT-службами. Некоторые вещи будут очевидны для IT-специалистов, но не очевидными для других. Иногда из-за их непонимания люди допускают болезненные ошибки. Не только и не столько со своей карьерой, сколько в своём бизнесе делают ставку не на тех людей. Поэтому, давайте разберём этот вопрос без эмоций и на понятном для неспециалистов языке.
Здесь описан путь, которым мы шли, проблемы, с которыми столкнулись, и обзор наших решений. Здесь не пересказ книги дяди Боба, и мы полагаем, что вы знакомы с трудом Роберта Мартина “Чистая архитектура. Искусство разработки программного обеспечения”. Это скорее интерпретация с различными дополнениями в контексте разработки нашего клиентского приложения.
Хочу рассказать о том, как мы избавились от дублирования кода, повысили тестируемость и отвязали UI. Почему мы сделали такой выбор, как разделили функционал и что нам это дало. Помимо этого хотелось бы показать, что отхождение от правил бывает уместным.