Сегодня, 27 апреля, могло бы исполниться 90 лет Джан-Карло Рота* — итальянскому математику и философу, выдающемуся специалисту в области комбинаторики и основателю ежегодного издания Advances in Mathematics. Имя Рота и результаты его трудов (главным из них стали «Основы комбинаторики» — серия из десяти работ) хорошо знакомы не только в академических кругах, но и многим ИТ-специалистам. В том числе сотрудникам департамента разработки МойОфис.

Вместе с коллегами мы перевели лекцию, которую Джан-Карло Рота прочитал в апреле 1996 года в Кембридже. Позже лекция была опубликована в виде статьи и перепечатана с разрешения издательства Birkhauser Boston в 1997 году журналом Notices of the American Mathematical Society. Под катом вы найдете ее полный текст. Изложенные в ней советы ориентированы не только на математиков и будут полезны всем, кто время от времени участвует в обмене специальными знаниями. А именно: читает лекции, проводит мастер-классы, публикует доклады и исследования.

*Обращаем ваше внимание, что позиция автора не всегда может совпадать с мнением МойОфис.

Я подустал от мрачных текстов и вспомнил о своей давней мечте. За 20 с хвостиком лет работы в Интел у меня развеселых историй накопилось на целую книгу. Хотелось в ретроспективе посмотреть на некоторые события, участником которых мне довелось быть. И еще хотелось отдать дань уважения компании и людям, с которыми мне посчастливилось работать. Я уже даже название придумал – Made at Intel. Понятно, что пока я был внутри конторы, речь о публикации этих баек идти не могла. Я сам подшучивал, что для публикации нужно правильно выбрать время. В смысле сначала уволиться, а потом публиковать, а не быть уволенным вследствие публикации. :) Однако примерно 2 года назад я Интел покинул, и казалось бы меня уже ничего не сдерживало. Но тут, как всегда – то перо поломается, то струна порвется, то еще какая бяда приключится. К тому же на то чтобы писать книжку – это же рeшимости набраться надо... И вот – вчера я решил, что большое надо начинать с малого. Буду писать по главке и выкладывать сюда - собирать фидбек. Так мало –помалу и наберется.

Итак, сегодня вашему вниманию представляется первая глава, в которой эволюция архитектур Intel рассматривается с точки зрения ... истории религиозных течений. Да –да, не удивляйтесь, архитектура вычислительных устройств –это одна из самых религиозных вещей. Не думайте, что все решения по Instruction Set Architecture принимаются исключительно на основе анализа данных – это совсем не так. Скорее похоже на средневековое государство – тут есть немного бизнеса, побольше политики и очень много религии. Все просто – почти любой эксперимент в этой области растягивается на годы и обходится в миллиарды долларов. Хуже всего, что в процессе дизайна можно давать лишь приблизительные оценки ключевых характеристик – частоты, производительности, энергопотребления, температурной карты. То, как все оно будет на самом деле становится понятным уже только тогда, когда чип выходит из печки. Да сейчас в этой области уже накоплен определенный опыт и наши оценки становятся несколько точнее, но и только. А 20 лет назад этих знаний было куда меньше. И пионеры, подобные Интел двигались в темноте на собственный страх и риск. Разумеется, в таких условиях на первый план выходит кто во что ВЕРИТ. Ну да – еще кто лучше говорить умеет. Поэтому лучшие архитекторы приходят из школ с углубленным изучением богословия. :)

Как вы могли заметить, я давно работаю с процессором STM32 ARM при помощи Mbed. Были времена, когда Mbed был весьма прост, но многое изменилось с тех пор, как он превратился в Mbed OS. К сожалению, это означает, что многие примеры и библиотеки, которые вы могли бы найти, с относительно новой системой работать не будут.

Мне нужен был поворотный энкодер — и я вытянул дешевый экземпляр из одного набора «49 плат для Arduino», какие продаются повсюду. Уверен, это не самый филигранный поворотный шифратор из имеющихся в природе, но для поставленной задачи его должно было хватить. К сожалению, в Mbed OS нет драйвера для такого датчика, а первые несколько сторонних библиотек, которые я нашел, либо работали по принципу опроса, либо не компилировались под последнюю версию Mbed. Разумеется, для чтения поворотного энкодера никакой магии не требуется. Но насколько сложно самостоятельно написать для него код? В самом деле, довольно сложно. Подумал, поделюсь моим кодом и расскажу, как к этому коду пришел.

Хотелось бы поделиться "граблями", на которые успел наступить при работе с docker, интересными фишками и вообще рассказать про эту замечательную технологию.

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

Петр Алексеевич — руководитель нового отдела продаж. У него в команде уже 10 сотрудников и есть первые результаты.

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

Петр Алексеевич, обеспокоен тоном общения, но не решается нарушить диалог. Он приветствует сотрудника и руководителя, и… идет к своему рабочему месту»

Сокращаем логистические пути

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

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

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

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

Это гифка, которую я сделал, чтобы показать вступление и как началась история путешествия птички. У меня есть друг, который не боится рисовать, даже если он не обучался рисованию профессионально. Я общаясь с ним как то вдохновился желанием рисовать и не бояться. В google play у меня есть старая игра, которую я делал на unity, когда только начинал работать с движком.

https://play.google.com/store/apps/details?id=com.xverizex.fly_bird&hl=ru&gl=US

Два комментария к старой игре дали мне желание сделать новую версию, но уже на C++ + SDL2 + OPENGL ES 3.2 + OPENSLES + glm. То есть я даже рад хотя бы двум комментариям о том что людям нравиться моё творчество, чтобы чувствовать себя прекрасно и продолжать делать игры.

Так как у меня нормального опыта не было делать игры полноценные на sdl2, то я использовал разные виды кода, которые как я думал, что они правильные. Но поработав на работе и изучая код, я увидел что есть помимо того что я знаю (я про очереди сообщений), есть ещё mqueue. И только потом я додумался, что можно с помощью очередей сообщений отправлять из одного потока в другой что-нибудь. Вот пример как выглядела реализация.

Речь идёт о игре Speebot, которая была выпущена в Steam в 2017 году.

Я разрабатывал эту игру с января 2016 года в своё свободное время в одиночку. Мною выполнено всё программирование, дизайн игрового процесса, создание графики и музыки. Кроме того, я написал собственный игровой движок с нуля.

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

Сегодня мы изготовим простой и бюджетный DIY-дозиметр на базе wifi-контроллера ESP32 и платы RadSens. В качестве сенсора будет использована популярная трубка СБМ20. 

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

_{Эта статья была опубликована на SQL.RU Другие опубликованные там статьи на тему MS SQL Server можно найти в блоге https://mssqlforever.blogspot.com/ Telegram-канал блога тут: https://t.me/mssqlhelp}

По материалам статьи Craig Freedman: Repeatable Read Isolation Level

В двух предыдущих статьях (1, 2) было продемонстрировано как запросы с уровнем изоляции «read committed» могли порождать неожиданные результаты. Это становилось возможным из-за выполняющихся в одно и то же время изменений затронутых запросом строк. Чтобы недопустить подобных неожиданностей (но не всех), следует использовать для выборки уровень изоляции «repeatable read». В этой статье мы как раз и рассмотрим как одновременные изменения ведут себя с уровнем изоляции «repeatable read» (повторяемое чтение).
В отличие от просмотра с «read committed», просмотр с «repeatable read» удерживает блокировки каждой затронутой строки до окончания транзакции. На всём протяжении транзакции заблокированными могут оказаться даже некоторые строки, которые не соответствуют выборке в результате запроса. Такое блокирование гарантирует, что затронутые запросом строки не будут изменены или удалены в параллельном сеансе, пока текущая транзакция не будет завершена (независимо от того, будет ли она зафиксирована или произойдёт её откат). Эти блокировки не защищают от изменения или удаления те строки, которые еще не были охвачены просмотром, и не препятствуют вставке новых строк межу уже заблокированными строками.

Demo | GitHub

Статья про редактор текста как на рисунке. Исходный код прилагается.

Помогая пользователям NGINX с разрешением проблемных ситуаций, мы поняли, что большинство из них часто совершает одни и те же ошибки конфигурации. Более того, подобные ситуации вполне могут возникнуть даже у самих инженеров NGINX! В этой статье рассмотрим 10 наиболее распространенных ошибок и объясним как их исправить.

1. Недостаточное количество файловых дескрипторов;
2. Директива error_log off;
3. Отсутствие keepalive-соединения с вышестоящими серверами;
4. Упущение механизмов наследования директив;
5. Директива proxy_buffering;
6. Неправильное использование директивы if;
7. Чрезмерные проверки работоспособности;
8. Незащищенный доступ к метрикам;
9. Использование ip_hash, когда весь трафик поступает из одного и того же блока /24 CIDR;
10. Игнорирование преимуществ вышестоящих групп.

Как уже было сказано в предыдущей публикации, метод дифференциального криптоанализа заключается в последовательном сравнении исходных пар открытый/закрытый текст до и после преобразования. Учитывая, что все сообщения кодируются в бинарном виде, под разностью мы будем понимать их сумму по модулю два (XOR), где наличие нулевых значений будет указывать на то, что исходные бита в этих позициях были между собою равны. В отличие от линейного криптоанализа, метод ДК легче реализуем на программном уровне, а количество рассматриваемых пар одинаково. Более того, за счет исключения невозможных дифференциалов можно добиться снижения количества операций на поиск ключа практически в четыре раза.

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

Адрес TCP/IP поддерживает только 65000 подключений, поэтому придётся назначить этому серверу примерно 30000 IP-адресов.

Существует 65535 номеров TCP-портов, значит ли это, что к TCP-серверу может подключиться не более 65535 клиентов? Можно решить, что это накладывает строгое ограничение на количество клиентов, которые может поддерживать один компьютер/приложение.

Если есть ограничение на количество портов, которые может иметь одна машина, а сокет можно привязать только к неиспользуемому номеру порта, как с этим справляются серверы, имеющие чрезвычайно большое количество запросов (больше, чем максимальное количество портов)? Эта проблема решается распределением системы, то есть кучей серверов на множестве машин?

1. Мессенджер WhatsApp и веб-фреймворк Phoenix, построенный на основе Elixir, уже продемонстрировали миллионы подключений, прослушивающих один порт.
2. Теоретические возможности на основе протокола TCP/IP.
3. Простой эксперимент с Java, который может провести на своей машине любой, если его всё ещё не убедили мои слова.

Давайте сначала представимся. Мы - команда управления тестирования и контроля качества в БКС Мир Инвестиций. Наш продукт - это приложения и сайты, созданные для удобства всех желающих окунуться в мир ценных бумаг и инвестиций. Конкретно в нашем “ведомстве” приложения на IOS  и Android, сайт личного кабинета, инвест стратегии Fintarget, новостной портал BCS-Express, сайт ФГ БКС и прочее.

В прошлом году мы начали трансформацию и преображение всех ключевых процессов в разрезе тестирования и контроля качества. 

Конечно же, автоматизация наших процессов важна, ведь без этого невозможно построение действительно сильного QA отдела. Безусловно, мы встретились с множеством разнообразных проблем.

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

Начать эти рассказы мы решили с повести о становлении мобильного автотестирования. Первым “попался под руку” Android, про него и начнем.