База данных в оперативной памяти — понятие не новое. Но оно слишком плотно ассоциируется со словами «кэш» и «не персистентный». Сегодня я расскажу, почему это не обязательно так. Решения в памяти имеют гораздо более широкое поле применения и гораздо более высокий уровень надежности, чем кажется на первый взгляд.

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

Этот рассказ сжимает 10 лет опыта работы с in-memory решениями в один текст. Порог входа максимально низкий. Чтобы получить пользу от прочтения, вам не нужно иметь столько же лет опыта, достаточно базового понимания IT.

Всем привет. Уже в этом месяце в ОТУС стартует курс "Python QA Engineer". В преддверии старта данного курса делимся с вами переводом интересного материала.

Почти все основные языки программирования имеют фреймворки для BDD тестирования, и Python не исключение. И по факту, у него их несколько! Итак, как их сравнить и какой из них лучший? Попробуем разобраться.

Здравствуйте, Хабр!

В ближайшее время читайте пост о русском переводе долгожданной книги "Создание Микросервисов" Сэма Ньюмена, которая уже отправилась в магазины. Пока же мы предлагаем почитать перевод статьи Аруна Гупты, автор которой описывает самые интересные паттерны проектирования, применимые в микросервисной архитектуре

От переводчика: некоторые скорее всего уже читали этот титанический труд от Мартина Фаулера и его коллеги Джеймса Льюиса, но я все же решил сделать перевод этой статьи. Тренд микросервисов набирает обороты в мире enterprise разработки, и эта статья является ценнейшим источником знаний, по сути выжимкой существующего опыта работы с ними.

Термин «Microservice Architecture» получил распространение в последние несколько лет как описание способа дизайна приложений в виде набора независимо развертываемых сервисов. В то время как нет точного описания этого архитектурного стиля, существует некий общий набор характеристик: организация сервисов вокруг бизнес-потребностей, автоматическое развертывание, перенос логики от шины сообщений к приемникам (endpoints) и децентрализованный контроль над языками и данными.

Привет, Хабр!

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

Приятного чтения!

Введение

Здравствуйте уважаемые читатели, в сегодняшней статье я хотел бы остановиться на таком феномене в разработке приложений на Unity3d, как визуальная разработка или если бы точнее, разработка с применением визуального представления кода и логики. И, прежде чем продолжить хочу сразу уточнить, речь не идет о визуальном программировании, от слова “совсем”, никаких Blueprint вариаций в мире Unity и никаких генераций C# кода. Так что же тогда подразумевается под визуальным редактором логики? Если вам интересен ответ на данный вопрос добро пожаловать под кат.

Статьи в серии:
→ Визуальный редактор логики для Unity3d. Часть 2
→ Визуальный редактор логики для Unity3d. Часть 3

Салют, хабровчане. Прямо сейчас в OTUS открыт набор на курс «Machine Learning», в связи с этим мы перевели для вас одну очень интересную «сказочку». Поехали.

---

Давным-давно, в далекой-далекой галактике…

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

Предлагаю ознакомиться с расшифровкой доклада начала 2019 года Андрея Сальникова "Управление нагрузкой на PostgreSQL, когда одного сервера уже мало"

Основные тезисы:
1) Стандартные практики распределения нагрузки в PostgreSQL. Сначала мы обсудим причины возникновения высокой нагрузки на базу данных. Следующим этапом рассмотрим те методы распределения нагрузки.
2) Будут рассмотрены вопросы того, как устроена репликация в PostgreSQL, какие есть различия между синхронными и асинхронными репликами, как правильно настраивать реплики.

В статье речь пойдет об одном очень не новом проекте, который создавался совсем в другое время и совсем в других условиях. Это моя старенькая RTS под названием Земля онимодов (Onimod land). Чтобы было сразу понятно, что она собой представляет, можно посмотреть коротенькое видео:

Прим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции.



Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).

За последние десять лет бесчисленное множество команд пали жертвой этого громкого названия и оказались — не побоюсь этого слова — откровенно облапошены. В своей заметке автор утверждает, что они успешно внедрили эту модель в проекты, но умышленно не раскрывает подробности проектов, которые привели к этой «успешности».

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

На этом можно заканчивать, так? Ну, не совсем. Наверняка некоторые из вас скептически отнеслись к моей цепочке рассуждений, поэтому давайте копнем поглубже и попытаемся понять, почему модель ветвления Git-flow должна поджариться на медленном огне.

Здравствуйте. Меня зовут Ник, я фронтенд разработчик (жидкие аплодисменты). Кроме того, что я пишу код, я преподаю в Школе программистов hh.ru.

Записи наших лекций от 2018-2019 учебного года можно посмотреть на youtube

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

Вот презентация для тех, кому неохота читать лонгрид, но при этом хочется иметь базовое представление о контенте.

Лонгридом можно пользоваться как справочником, чтобы не читать за один присест. Вот список тем, которые мы затронем:

1. Зачем думать о производительности
2. FMP, TTI + подробнее в докладе
3. Critical render path, DOM, CSSOM, RenderTree
4. Шаги по улучшению производительности первой загрузки + подробнее в докладе

Понимайте свою программу без ущерба для производительности

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

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

Сегодня, в 10 уроке курса по Vue, мы поговорим о том, как работать с формами. Формы позволяют собирать данные, вводимые пользователем. Кроме того, здесь мы обсудим валидацию форм, то есть — проверку того, что в них вводят.

Появилась задача написать веб интерфейс управления устройством. Управлять устройством будет Raspberry Pi. Логика управления — python, соответственно и интерфейс хотелось бы python. Хочу поделится своим опытом.

• 1. lighttpd mod_cgi и простой скрипт
• 2. web.py на порту 8080
• 3. WCGI интерфейс
• 4. Простой сервер WSGI
• 5. WSGI с использованием wsgiref
• 6. WSGI c помощью flup
• 7. web.py приложение с использованием flup
• 8. Немного особенностей

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

Всем привет! В данной статье рассмотрим разработку фронта простенького блога на Vue с использованием всех прелестей Vue включая Vuex и Router. А также поговорим про структуру приложения и работу с контейнером и роутером.

В 2019 году популярность фреймворка Vue невероятно сильно выросла. Количество еженедельных загрузок Vue удвоилось: в прошлом году это было 600 тысяч, а теперь это 1.2 миллиона. Долгожданная третья версия Vue, следующая итерация фреймворка, должна выйти где-то в первом квартале 2020 года.

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



Здесь я собрал некоторые советы, которые пригодятся тем, кто хочет подготовиться к появлению Vue 3.0. Надеюсь, что тот, кто последует этим советам, сможет очень быстро освоиться в новых условиях.

Пятый и завершающий пост о моём знакомстве с Vue Storefront. IMHO, самым современным с технической точки зрения решением в сфере e-commerce на данный момент. Ссылки на предыдущие посты:

• Vue Storefront: Второй подход к снаряду
• Vue Storefront: Поднимаем backend
• Vue Storefront: Заливаем данные в ES
• Vue Storefront: Импорт каталога из Magento 2

Под катом краткое описание особенностей этого этапа и итоговое резюме.

JavaScript — это душа современных веб-приложений. Это — главный ингредиент фронтенд-разработки. Существуют различные JavaScript-фреймворки для создания интерфейсов веб-проектов. Vue.js — это один из таких фреймворков, который можно отнести к довольно популярным решениям.

Vue.js — это прогрессивный фреймворк, предназначенный для создания пользовательских интерфейсов. Его базовая библиотека направлена, в основном, на создание видимой части интерфейсов. В проект, основанный на Vue, при необходимости легко интегрировать и другие библиотеки. Кроме того, с помощью Vue.js и с привлечением современных инструментов и вспомогательных библиотек, можно создавать сложные одностраничные приложения.



В этом материале будет описан процесс создания простого Vue.js-приложения, предназначенного для работы с заметками о неких задачах. Вот репозиторий фронтенда проекта. Вот — репозиторий его бэкенда. Мы, по ходу дела, разберём некоторые мощные возможности Vue.js и вспомогательных инструментов.

… или знакомство с плагинами Vue JS на примере интегрированной шины событий

Пара слов о…

Всем привет! Сразу оговорюсь. Я очень люблю VueJS, активно пишу на нем уже больше 2-х лет и не считаю, что разработка на нем может причинить боль хоть в какой-то значимой степени :)
С другой стороны, мы всегда пытаемся найти универсальные решения, которые помогут тратить меньше времени на механическую работу и больше – на то, что действительно интересно. Иногда решение оказывается особенно удачным. Одним из таких я хочу поделиться с вами. 10 строк, о которых пойдет речь (спойлер: в конце их окажется немного больше), родились в процессе работы над проектом Cloud Blue – Connect, который представляет собой достаточно крупное приложение на 400+ компонентов. Найденное нами решение уже интегрировано в самые разные точки системы и вот уже более полугода ни разу не требовало правок, поэтому его смело можно считать успешно проверенным на устойчивость.