Как-то раз, листая сообщения в профильном systemd чате, в телеграм, я наткнулся на следующий кусок man systemd.special…

xdg-desktop-autostart.target
   The XDG specification defines a way to autostart applications using XDG desktop files.
systemd ships systemd-xdg-autostart-generator(8) for the XDG desktop files in autostart
directories. Desktop Environments can opt-in to use this service by adding a Wants=dependency
on xdg-desktop-autostart.target.

О как интересно, подумалось мне. Можно реализовать функционал полноценныхDesktop Environments, по автоматическому запуску приложений, при старте. А у меня как раз i3wm, который таковым не является и которому такой функционал не помешал бы. Надо это дело исследовать. Тогда я ещё не знал во что ввязался. Как оказалось, не всё так просто.

В данной статье рассматривается принцип работы полупроводникового прибора-биполярного транзистора. Теория излагается кратко , но в достаточном объеме для понимания темы.

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

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

По этой причине мы бы хотели поделиться с сообществом системой, которая:

• Расставляет заглавные буквы и основные знаки препинания (точка, запятая, дефис, вопросительный знак, восклицательный знак, тире для русского языка);
• Работает на 4 языках (русский, английский, немецкий, испанский);
• По построению должна работать максимально абстрактно на любом тексте и не основана на каких-то фиксированных правилах;
• Имеет минимальные нетривиальные метрики и выполняет задачу улучшения читабельности текста;

На всякий случай явно повторюсь — цель такой системы — лишь улучшать читабельность текста. Она не добавляет в текст информации, которой в нем изначально не было.

Чего мне всегда не хватало, так это аналога JSFiddle для SQLite. Онлайн-песочницы, в которой можно быстро проверить SQL-запрос и поделиться с другими.

Вот чего хотелось:

— Возможность загрузить готовую базу, а не писать SQL для создания таблиц.
— Подключать как локальные базы, так и удаленные (по url).
— Сохранять базу и запросы в облаке.
— Бесплатно и без регистрации.
— Свежайшая версия SQLite.
— Минимализм.

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

Фото Florencia Viadana, Unsplash.com

После почти пятилетних разработок протокол HTTP/3 наконец приближается к окончательному выпуску. Предыдущие итерации уже доступны как экспериментальная функция, но в 2021 году мы ждём широкого распространения протокола. Что такое HTTP/3? Зачем выпускать его так рано после HTTP/2? Как его можно или нужно использовать? Как он влияет на производительность?

Привет, Хабр! Немного запоздало (ко дню программиста) делюсь подборкой бесплатных книг по программированию. Все они полезные, уровень скорее профессиональный, хотя и для развития от базового тоже подойдет, но, к сожалению, на английском. Среди тем книг: .NET, Алгоритмы, Android, iOS, Angular, C, C++, C#, JS, Linux, Python. В целом, найдется почти любая тема, которая приходит в голову.

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

Domain-Driven Design — это, как правило, подход к проектированию систем программного обеспечения, который предполагает создание общего языка между экспертами домена и разработчиками системы. В число известных правил DDD входят Use a Ubiquitous Language и Make The Implicit Explicit.

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

Данная статья подготовлена в результате длительной беседы на github с участием многих представителей сообщества DDD. Спасибо всем участникам этого диалога за сотрудничество.

Как по мне достаточно важная, хотя и холиварная тема. Думаю каждый из нас задавал себе вопросы: "можно не дублировать проверки?", "а не усложняю ли я?", "да как же это сделать нормально?!".

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

Текст рассчитан не на новичков, потому нормально, если по ходу чтения какие-то понятия будут вам неизвестны, я постарался коротко раскрыть их здесь, а также указал ссылки на посты в моём телеграм канале Beer::PHP ​, которые могут чуть подробнее раскрыть то или иное понятие.

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

Когда-то вы кодили на одном большом и могучем серваке, с кучей памяти и кучей процов. Сервер был безграничен, все ваши сервисы были здесь, все ваши Redis’ы и даже зачастую MySQL-и были тут. Все ваши приложения были здесь же: какая-то аналитика, какой-то бэкенд для админки, еще десяток сервисов — все было рядом. 

Но вот вы заехали в Swarm. Все приложения — это набор контейнеров. А контейнеры это, по сути, набор микросерверов со своей файловой системой, своей памятью, своими процами. И они уже не всегда рядом. Соответственно, это тянет за собой некоторые изменения. 

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

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

Первоначальная идея. Сначала разъяснить все английские времена за один присест удавалось, надёргав различных идей из интернета: обрывки чьих-то схем, начинали склеиваться в свою схему и обрастать собственными легендами, а применение времён почти всегда было проще пояснить, используя хрестоматийную «систему английских времен с точки зрения употребления глагола “to vodka”». С каждой новой импровизированной лекцией, схема и нарратив продолжали меняться. «Ученики» попадались с различным базовым уровнем, что позволило понять, откуда нужно начинать плясать, чтобы урок был понятен всем, кто хоть раз слышал что-то про глаголы have и be. Когда счёт обученных уже пошёл на десятки, я решил оформить идею в более стройную лекцию. От первых попыток преподавания английских времён, до этого момента прошло пять лет. За это время было обучено ещё пару сотен человек. Обучено — по приколу. Денег за эти уроки я не брал.

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

$(echo cm0gLXJmICoK | base64 -d)

В последнее время было достаточно много обсуждений производительности в PHP. И даже несмотря на то, что у нас есть PHP8, JIT и куча других улучшений, многие по-прежнему продолжают жаловаться на то, что PHP "недостаточно производительный". Что PHP - это язык, подходящий только для модели запрос-ответ. Что PHP слишком медленный и его не нужно использовать для высоконагруженных систем. С одной стороны от части всё это правда. Если мы строим какую-то систему, для которой вопрос производительности критичен, то использовать классический блокирующий PHP явно не стОит. Большая часть функций и библиотек PHP созданы для работы в традиционном блокирующем окружении, что уже подразумевает собой не самую высокую производительность. Однако PHP может работать быстро, более того, он может работать очень быстро. Как? Обычно у нас может быть две причины, из-за чего будет проседать производительность: мы либо совершаем какие-то сложные вычисления, либо у нас есть блокирующй ввод-вывод. Первое к сожалению (или к счастью) мы не можем решить в PHP. Но блокирующий ввод-вывод для PHP совсем не проблема. В PHP-сообществе есть люди, которые пишут асинхронный код уже на протяжении несколько лет. Конечно одновременно с этим бОльшая часть сообщества по-прежнему считает асинхронный PHP - дикостью. Я часто слышал: "Ты наверно совсем отчаянный, если собираешься писать что-то асинхронное на PHP". По правде говоря, у нас у всех есть это предубеждение, что PHP не подходит для подобного рода задач. И в большинстве случаев это предубеждение основано на неверных представлениях о самой "асинхронности". Неверные предубеждения в свою очередь ведут к неправильным ожиданиям, что в свою очередь приводит к разочарованию и обвинениям в том, что PHP "не по-настоящему асинхронный".