Рубрика «Блог компании NIX Solutions» - 6

Предлагаем вашему вниманию перевод статьи, посвящённой рассмотрению используемых в программировании моделей памяти.

Сегодня в программировании доминируют шесть основных моделей памяти (не путать с моделями памяти Intel 8086). Три из них проистекают из трех исторически наиболее важных языков программирования 1950-х годов — COBOL, LISP и FORTRAN, а остальные связаны с тремя исторически важными системами хранения данных: магнитная лента, иерархическая файловая система в Unix-стиле и реляционная база данных.

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

Промисы на примере бургер-вечеринки - 1

Это перевод статьи, которую Марико Косака написала в качестве альтернативного введения в промисы JavaScript. Наброски иллюстраций она делала в своём блокноте во время чтения разных статей, посвящённых промисам. Если хотите изучить более подробно, в конце вы найдёте список полезных ссылок.

Недавно Марико участвовала в обсуждении того, как можно с помощью JavaScript сделать фичу, которая давала бы доступ к внешним данным (должна была быть асинхронной). Она сказала: «Ну, давайте используем fetch()… так что в коде… эээ...», и пока силилась вспомнить fetch API, собеседник сказал: «Будет возвращаться промис». По словам Марико, её мозг впал в ступор, и она сказала: «Честно говоря, не знаю, что ты имеешь в виду…»

Ей приходилось много раз писать код, основанный на промисах, но для полной картины нужные пазлы в её голове почему-то не соединились. Она поняла, что на самом деле не «въезжает» в суть.
Читать полностью »

Разработка транзакционных микросервисов с помощью Агрегатов, Event Sourcing и CQRS (Часть 2) - 1

Это завершение переводной статьи о разработке транзакционных приложений с использованием микросервисной архитектуры. Начало.

В первой части статьи мы говорили, что основным препятствием при использовании микросервисной архитектуры является то, что модели предметной области (domain model), транзакции и запросы удивительно устойчивы к разделению по функциональному признаку. Было показано, что решение заключается в реализации бизнес-логики каждого сервиса в виде набора DDD-агрегатов. Каждая транзакция обновляет или создает один единственный агрегат. События используются для поддержания целостности данных между агрегатами (и сервисами).

Во второй части статьи мы увидим, что ключевой задачей при использовании событий является атомарное изменение состояния агрегата и одновременная публикация события. Посмотрим, как решить эту проблему с помощью Event Sourcing — используя событийно-ориентированный подход к проектированию бизнес-логики и системы сохранения состояния. После этого опишем, как микросервисная архитектура затрудняет реализацию запросов к базе данных, и как подход, называемый Command Query Responsibility Segregation (CQRS), помогает реализовывать масштабируемые и производительные запросы.
Читать полностью »

Разработка транзакционных микросервисов с помощью агрегатов, Event Sourcing и CQRS (Часть 1) - 1
Предлагаем вашему вниманию перевод первой части полезной статьи о том, как разрабатывать транзакционные бизнес-приложения, используя микросервисную архитектуру.

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

Однако микросервисы являются не таким уж простым и универсальным решением. В частности, модели предметной области, транзакции и запросы удивительно устойчивы к разделению по функциональному признаку. В результате разработка транзакционных бизнес-приложений с использованием микросервисной архитектуры является довольно сложной задачей. В этой статье мы рассмотрим способ разработки микросервисов, при котором эти проблемы решаются с помощью паттерна проектирования на основе предметной области (Domain Driven Design), Event Sourcing и CQRS.
Читать полностью »

Анонс встречи ThinkJava #4 (Харьков) - 1Приглашаем вас на очередную встречу Java-разработчиков ThinkJava #4. Спикеры нашего ThinkJava-сообщества переплыли моря и океаны, чтобы побывать на SpringOne Platform в Лас-Вегасе, и теперь готовы поделиться привезёнными знаниями и своим опытом со всеми гостями ThinkJava #4. Мы посвящаем эту встречу вопросам облачных вычислений.
Читать полностью »

Анонс митапа ThinkPHP #13 - 1

Друзья, приглашаем вас на очередную встречу PHP-разработчиков ThinkPHP #13. Вас ждут интересные доклады, живое общение с экспертами, сладкие кофе-брейки в компании постоянных участников ивента и новых гостей, и много вдохновения!
Читать полностью »

Анонс Kharkiv WordPress Meetup #3 - 1

Приглашаем на третью встречу Kharkiv WordPress Meetup, где вас ждут интересные доклады, новые знания и порция вдохновения, а также живое общение с нашими экспертами.
Читать полностью »

Анонс митапа Sync.NET #3 - 1

Друзья, в пятницу 4 ноября мы приглашаем всех желающих посетить встречу харьковского .NET-сообщества. Вас ждут интересные доклады, блок вопросов и ответов, а также традиционные кофе с печеньками.
Читать полностью »

В двух словах о NEXUS - 1

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

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

Яркие примеры нечитаемого кода встречаются на соревнованиях JS1k, цель которых заключается в написании лучших JS-приложений, состоящих из 1024 символов или того меньше. То же самое можно сказать и про JSF*ck, крайне своеобразный стиль программирования, использующий только шесть разных символов для написания JS-кода. Глядя на выложенный на этих сайтах код, вы будете ломать голову, пытаясь понять, что здесь происходит. А представьте, каково это: написать подобный код и спустя месяц пытаться исправить баг.

Если вы регулярно сёрфите по сети или создаёте интерфейсы, то, вероятно, знаете, что для заполнения большой формы нужно много времени и терпения, которых хватает не всем пользователям. То же самое можно сказать и о коде. Чем легче его читать, тем приятнее долго работать с ним. Или как минимум не возникнет желания выкинуть компьютер в окно.

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

Оригинал статьи: https://www.sitepoint.com/importance-of-code-that-humans-can-read/
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js