require 'glimmer-dsl-libui'
include Glimmer
window('hello world').show
О паттерне «Спецификация», который позволяет улучшить структуру приложения, и, следовательно, увеличить гибкость, уменьшив при этом объем кода, а значит — сократить количество ошибок, но это не точно. Почему? - читаем ниже.
TL;DR: DDD неизбежно ведёт к избыточному (на порядки больше минимально необходимого) количеству саг в проекте, которые, в свою очередь, неизбежно ведут к нарушению целостности данных в БД.
DDD вполне успешно решает поставленную задачу: дать разработчикам инструменты, которые позволят им справиться (корректно реализовать и поддерживать) со сложной предметной областью. Но эта победа оказалась пирровой: инструменты, обеспечивающие корректность данных в памяти, оказались неспособны гарантировать корректность данных в БД. А что толку от изначально корректных данных в памяти, если со временем (после их сохранения в БД и последующего чтения) они перестают быть корректными? По сути, у DDD есть фатальный недостаток: DDD неизбежно приводит к нарушению целостности данных (инварианта бизнес-логики) в БД.
Нам всегда хотелось найти идеальный язык программирования, но суровая реальность заставляет отвергать даже стабильные идеи. Рассказ одного новичка в программировании, который попытался раскопать идеальный язык программирования и проиграл.
Всем привет! Я Виктор Кугай, руководитель команды разработки спецпроектов в Тинькофф. Мы создаем геймификационные проекты, основанные на данных, чтобы познакомить пользователей с экосистемой компании и повысить узнаваемость бренда.
Расскажу, как с помощью Node.js Streams и механизма Back Pressure протокола TCP реализовать пакетную обработку сотен гигабайтов данных на машинах с жестким лимитом памяти.
System.Collections.Concurrent настолько, насколько это возможно, включая примеры и сценарии использования. Также будет затронута тема сравнения с неизменяемыми (immutable) и замороженными (frozen) коллекциями.
Про микросервисную архитектуру и переход на неё написаны сотни статей, однако почти все они больше теоретические и описывают ситуацию лишь верхнеуровнево. Редко где прочтёшь про то, как люди бесшовно вынесли высоконагруженный кусок монолита в отдельный сервис без даунтайма и факапов или даже с ними. Интересно узнать, какими же инструментами они пользовались, как подготавливались, каких подходов придерживались и какие выводы на будущее сделали. Всё это — полезный опыт, который может помочь избежать проблем. Вот я и подумал, что стоит им поделиться.
Вероятно, вы уже слышали о соревновании под названием "The One Billion Row Challenge" (1brc), если же нет, то предлагаю ознакомиться с репозиторием 1brc Гуннара Морлинга.
Моё участие в проекте было мотивировано присутствием в нём двух моих коллег, которые достигли лидирующих позиций.
PHP не известен своими выдающимися скоростными показателями. Тем не менее, учитывая, что я работаю над профайлером PHP, я решил исследовать его производительность на примере этого вызова.
В статье расскажу и покажу, как сверстать письмо, чтобы оно наверняка правильно отображалось во всех почтовых клиентах — особенно в Outlook, который до сих пор возглавляет подборки по популярности в РФ.
В конце — пример целого письма в HTML.
Руслан Гнатовский aka @Number55 в свой статье Когда ни туда, ни сюда, или в поисках оптимальной границы Domain слоя описал известную проблему протекания бизнес-логики из агрегата, в случае если эта логика зависит от данных которые находятся вне агрегата, и предложил несколько решений этой проблемы, каждое из которых не лишено недостатков. Многие из этих недостатков были описаны в статье а также в комментариях поэтому я не буду здесь дублировать эту информацию а попытаюсь предложить решение которое этих недостатков лишено.
Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.
Пятница. Вечер. Алерт. Прод и я. Приглашаю вместе со мной помочь проду пережить выходные, а может быть и несколько лет. Ведь всего за одну пятницу крупный проект получил право жить и развиваться, а не лёг под нож «рефакторинга».
Некоторые паттерны стало возможно использовать на практике только благодаря безопасности Rust по памяти, а на C++ они слишком опасны. В статье приведён один такой пример.
Работая над внутренней библиотекой, написанной на Rust, я создал тип ошибок для парсера, у которых должна быть возможность сделать Clone без дублирования внутренних данных. В Rust для этого требуется указатель с подсчётом ссылок (reference-counted pointer) наподобие Rc.
Поэтому я написал свой тип ошибок, использовал его как вариант ошибок fallible-функций, и продолжил двигаться дальше.
Специальная теория относительности - удивительная теория, которая опровергла многие представления о мире, в которых человечество не сомневалось всю историю своего существования.
Многие слышали про волшебства вроде замедления времени, сокращения длины, относительности одновременности, парадокса близнецов и т.д., но мало кто понимает почему так происходит.
В этой статье я хочу наглядно показать, что все это проще, чем кажется на первый взгляд.
Для иллюстраций я написал интерактивный визуализатор СТО, работающий в браузере. Ссылка на него и исходники проекта в конце статьи.
Мы продолжаем рассказывать о внутренней кухне Wiren Board. В предыдущей статье мы заставили работать китайский паяльный робот, который выполняет рутинную часть работы монтажников на нашем производстве.
Все наши «железки» должны поступать клиентам в рабочем состоянии и служить максимально долго. Именно по этой причине после производства все устройства проходят тестирование.
Расскажем, как разрабатывали фирменный тестовый пакет test-suite, с какими проблемами столкнулись и как мы их решили. Также покажем наши стенды, на которых тестируем все выпускаемые продукты.
Интересно? Ныряйте под кат.