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

Опыт использования новых маков с М1 начинает расставлять точки над i. Эти чипы быстрые. Очень быстрые. Но почему? В чем магия?

Я смотрел видео на Youtube, где автор купил iMac в прошлом году максимальной конфигурации. Машина с 40+ Gb ОЗУ стоила ему около 4000$. Он смотрел с недоверием, как его гипердорогой iMac был разнесен в пух и прах новеньким Mac mini с М1 на борту, который стоил около 700$.

В реальном мире, тест за тестом, макбуки с М1 не просто превосходят топовые компьютеры Intel прошлых поколений. Компьютеры Mac просто уничтожают их. С недоверием люди стали спрашивать, как такое возможно?

Выявляем очевидное

В последние 4.5 года я много рассказывал на Хабре про такие OpenSource проекты, как SObjectizer и RESTinio. Но вот об использовании SObjectizer и/или RESTinio в реальных проектах пока еще ни разу не удавалось поговорить (была лишь одна статья от стороннего автора).

Причина простая: мы не можем обсуждать те проекты, в которых мы сами применяли SObjectizer/RESTinio, ибо NDA. Равно как и не можем рассказывать о тех чужих проектах, о которых узнали в частном общении. Так что с наглядными примерами использования SObjectizer/RESTinio в реальной жизни всегда была напряженка.

Дабы как-то улучшить ситуацию пару лет назад мы даже сделали небольшой демо-проект Shrimp и опубликовали здесь серию статей о нем (раз, два, три). Но все-таки это было не более чем демонстрация.

К счастью или к несчастью, но далеко не самый удачный 2020-й год предоставил нам возможность показать как же выглядит реальный проект, в разработке которого SObjectizer и RESTinio активно используются. И в данной статье я попробую рассказать о том, как и для чего SObjectizer и RESTinio применяются в arataga, исходники которого можно найти на GitHub.

С каждым годом выходит всё больше инструментов, которые помогают автоматизировать часть рутинной работы программиста, — генераторы тестов, автодополнение кода, генераторы шаблонного кода. Мы воспринимаем как само собой разумеющееся, что условная IntelliJ IDEA предлагает нам после введения буквы метод, который мы и хотели.

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

Исследование этой проблемы провёл Тагир Валеев lany из JetBrains в докладе на Joker 2020. И результаты вышли весьма неоднозначными. Подробности — под катом, повествование далее будет от лица спикера.

Заход Солнца как нелинейный процесс, непредсказуемые сумерки, и другие неожиданные свойства повседневных явлений

Когда я сказал своим друзьям, что делаю прибор для определения долготы дня, они очень удивились: а погуглить не судьба? Но меня интересовало кое-что другое. Люди говорят, «какой темный день», или «утром, оказывается, уже в пять часов светло», имея в виду вроде бы субъективный, а на самом деле очень конкретный параметр: освещенность здесь и сейчас. На этой широте, в этот день года, с этими облаками, с этим горизонтом, застроенным домами или вечно мутным из-за городского смога, с окнами, выходящими на восток или на юг. Сумерки могут быть светлыми или яркими, на это влияет вулканическая, космическая или антропогенная пыль. Мощные облака и смог сокращают день на десятки минут: Солнце взошло, но по-прежнему темно. А рефракция атмосферы в состоянии задержать заход Солнца или ускорить его восход минут на десять. Почему бы просто не измерить – в минутах и часах – промежуток времени от одного порогового уровня освещенности до другого? Прибор получился копеечным, но в этой истории интересен скорее не он сам, а явления природы, которые влияют на освещенность. С них и начнем.

Долой диктатуру 55-й параллели

24 декабря 2020 года сервис Яндекс.Погода сообщил, что в моем городе Солнце взошло в 8 часов 58 минут, село в 15 часов 59 минут, и долгота дня составила, стало быть (простое вычитание) 7 часов 1 минуту. Вроде бы все понятно. Но 24 декабря там, где я живу, было ясно. А 25 декабря (долгота дня – те же 7 часов 1 минута, солнцестояние, однако) – мела метель, и пасмурно. Конечно, день 24 декабря показался мне «длиннее», чем 25-го. Инструментальные измерения (о них ниже) подтверждают субъективное ощущение: 24 декабря там, где я живу, было на 42 минуты темнее, чем 25-го.

На самом деле сервисы, привязанные к вашей геолокации, уже сотворили чудо: в эпоху бумажных отрывных календарей восходы-заходы публиковались для широты Москвы, 55 градусов, и по этим цифрам приходилось ориентироваться гражданам огромной страны. Насколько это неточно? В календаре за 1 декабря 1986 года (скан этой странички просто попался мне в Сети) сказано, что долгота дня – 7 часов 25 минут. Возьмем программу-планетарий (самая распространенная - Stellarium, но мне полюбилась древняя программка Starcalc) и убедимся, что в Москве так и есть. А вот в Сочи (широта 43 градуса) – уже 9 часов 13 минут. На Крайнем Севере 1 декабря дня не было вообще. Вот такое «среднее по больничке».

import java.util.Random;

class WTF {
    public static void main(String[] args) {
        Random r = new Random(76880392499L<<11);
        String alphabet = " abcdefghijklmnopqrstuvwxyz";
        int n;
        while ((n = r.nextInt(alphabet.length())) > 0)
        	System.out.print(alphabet.charAt(n));
    }
}

Эта статья не является ответом на множество вопросов по базам данных (БД) и системам управлениям базами данных (СУБД). Я как автор выражаю своё собственное мнение о  трендах, стараясь опираться на беспристрастные показатели, статистики и т.д., но для примера приводя собственный опыт. Я не являюсь ангажированным представителем какой-либо компании и выражаю точку зрения опираясь на опыт более 25 лет работы с разными СУБД, в том числе, которую создавал своими руками. Не так много даже опытных программистов и архитекторов, которые знают все термины, технологии, какие подводные камни и куда идёт движение. Тема поистине огромная, поэтому в рамках одной статьи не раскрыть даже верхний уровень информации. Если кто-то не встретит свою любимую СУБД или её невероятный плюс, который стоит упомянуть, то прошу в комментариях указать и этим дополнить общую картину, что поможет другим разобраться и понять лучше предметную область. Поехали!

Open Source DBMS vs Commercial DBMS

 Для начала приведён график с сайта, db-engines.com, по моим ощущениям, неплохо отслеживающим тренды БД. Именно этот график добавил желания написать статью о текущем положении дел.

В статье приводится описание того:

- Как создать посетитель не привязанный к предметной области.

- Как получать настоящий тип объекта и передавать его в шаблон функции имея на руках лишь указатель на абстрактный базовый класс.

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

[...] Не надо размышлять, почему здесь нет оператора if. Важно посмотреть на задачу с другой стороны и переписать её так, чтобы особый случай исчез и стал обычным случаем, и это хороший код. — Л. Торвальдс

• std::stacktrace,
• z и uz,
• 61 с половиной багфикс в ядре языка,
• string::contains,
• Executors & Networking,
• и прочие новости.

SObjectizer — это небольшой фреймворк для C++, который дает возможность разработчику использовать такие подходы, как Actor Model, Communicating Sequential Processes и Publish/Subscribe.

Одной из ключевых концепций в SObjectizer являются диспетчеры. Диспетчеры определяют, где и как акторы (агенты в терминологии SObjectizer-а) обрабатывают свои события. Диспетчеры в SObjectizer бывают разных типов, и пользователь может создавать в своем приложении столько разнообразных диспетчеров, сколько ему потребуется.

При этом у пользователя есть возможность написать свой собственный тип диспетчера, если ничего из стандартных диспетчеров ему не подходит. Два с половиной года назад уже рассказывалось о том, как можно сделать диспетчер для SObjectizer-а со специфическими свойствами.

Сегодня мы еще раз поговорим об этом. На примере уже другой задачи. Да и реализация будет отличаться, поскольку за прошедшее время SObjectizer успел обновиться сперва до версии 5.6, а затем и 5.7. И в этих версиях много отличий от версии 5.5, про которую в основном и рассказывалось в прошлом. В том числе и в механизме диспетчеров.

О решаемой задаче в двух словах

Предположим, что у нас есть агент, который ожидает два сообщения: msg_result с финальным результатом ранее начатой агентом операции и msg_status с промежуточной информацией о том, как протекает начатая операция.

Сообщения msg_status могут идти большим потоком. Например, на одно msg_result может приходиться до 1000 msg_status. И нам бы хотелось, чтобы когда в очереди уже стоит 900 сообщений msg_status, новое сообщение msg_result вставало не в конец очереди, а в самое ее начало. Чтобы msg_result не ждало, пока разгребутся 900 старых msg_status.

Небольшие, но важные функции

Начиная с C++20 в несколько стандартных контейнеров, включая std::map, std::set и std::string, были добавлены некоторые очень полезные функции для поиска. Необходимость в них существовала уже в течении достаточно долгого времени, и мне приятно видеть, что комитет наконец признал их важность. Надеюсь, это только начало серии замечательных дополнений.