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

Дабы исчерпать до дна тему сокетов в Python я решил изучить все возможные способы их использования в данном языке. Чтобы всех их можно было испытать и попробовать на зуб, были созданы 19 версий простого эхо-сервера: от примитивного использования класса socket до asyncio. Блокирующие и неблокирующие сокеты, процессы и потоки, select'ы и selector'ы, коллбеки и сопрограммы — все эти темы расположены в эволюционном порядке, чтобы один пример плавно перетекал в другой.

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

Пишу подробно, чтобы случайно чего не пропустить. Поэтому понятно должно быть всем.

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

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

Программист пишет интересную статью. Холст, масло, ruDALL-E.

Что самое сложное в написании статьи для Хабра? Конечно же сесть и начать писать! А потом вовремя остановиться. Ну а на третьем месте — во всяком случае для меня — стоит загрузка уже готовой статьи на Хабр. Про новый редактор я тактично промолчу, а старый в принципе весьма неплох: статью в markdown можно скопировать в него почти без изменений. Но вот с добавлением картинок есть пара нюансов.

Во-первых, форматирование: markdown не поддерживает ширину-высоту-выравнивание картинок, поэтому если вам захочется красоты, то все теги придется переписать в html. А во-вторых, когда вы зальете картинки на Habrastorage (или в любое другое облако), адреса локальных картинок по всему тексту придется вручную перебивать на ссылки в облаке. Как-то вечером я дописывал статью с ~50 картинками, ужаснулся количеству предстоящей работы, и решил написать простенький скрипт для автоматизации всего этого.

В комментариях к статье об отладке bash скриптов я высказал предположение, что предложенный подход отладки может быть расширен добавлением поддержки точек останова. После некоторых размышлений я немного дополнил код, предложенный в комментариях к статье и получилось вот что:

Мне всегда хотелось иметь возможность отлаживать bash-scripts так же, как и любой другой код, т.е. по шагам, и bash такую возможность предусмотрел, но о ней не все знают. Несмотря на довольно большой опыт использования Linux, я дошёл до неё только недавно.

В этой статье я хочу поделиться практическими методами отладки, модификации и устранения багов в 32-х и 64-х разрядных приложениях под ОС Windows, разработанных на языке C/C++, исходные коды которых по тем или иным причинам не стали достоянием общественности.

Этот пробел отчасти можно попытаться устранить, например, с помощью плагина Hex-Rays для IDA Pro, и зачастую удаётся довольно качественно восстановить нужный участок исходного кода, обнаружив в нём проблемное место. Но после этого всегда возникает вопрос - что с этим исправленным кодом делать дальше, как и где его можно использовать? На данном этапе мне всегда хотелось взять этот отдельно декомпилированный фрагмент программы, поменять в нём что-нибудь и затем каким-то чудесным образом «поместить обратно» в программу.

Далее будет описан один из возможных способов реализации этой идеи на практике.

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

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

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

С 2005 года спрос на удаленную занятость вырос на 140%. Очевидно, что эта тенденция будет продолжаться. Сегодня вакансии на удаленку можно найти и на job-бордах, и в социальных сетях, но мне ближе Телеграм-каналы. Делюсь с вами своей подборкой. Дополнения в комментариях приветствуются)

Я довольно часто сталкивался с тем, что разработчики на Delphi (можно сказать традиционно) компилируют свои приложения "ручками", что далеко не production-решение, а со стороны выглядит кустарщиной и "делаем на-коленке", хотя продукты бывают весьма серьёзными и продаваемыми. Вероятно, это пошло ещё с тех пор, когда для автоматизации нужно было придумывать свои батнички, которые запускали компилятор командной строки dcc32 с нужными параметрами. Некоторые даже сделали свой "Публикатор" — Delphi-expert, который делает работу сервера сборок: компилирует (правда, открытый в IDE) проект, выставляя ему взятый из какой-то БД инкрементированный номер версии, записывает некий changelog и копирует это куда-то в сетевой каталог.

Я не буду вдаваться в исторический экскурс как было раньше. Я расскажу как есть/можно сейчас, и как это использовать для повышения эффективности своей работы.

Файл проекта современной версии Delphi — это .dproj-файл (здесь и далее я буду ориентироваться на Delphi 10 Rio, но с небольшими отличиями это верно для всех более ранних версий Delphi, начиная с 2007). В нём хранятся все настройки проекта, которые обычно изменяют в IDE (меню Project - Options (Ctrl+Shift+F11)). В рамках данной статьи я сконцентрируюсь на "основных", которые понадобятся для демонстрации общих принципов: это Config — конфигурация, Platform — платформа, OutputDirectory — путь выходного файла и ConditionalDefines (директивы условной компиляции). Остальные настройки, если таковые нужно менять при сборке, я предлагаю выявить самостоятельно. Этот же .dproj-файл, если в него заглянуть обычным текстовым редактором, является ничем иным как скриптом сборки MSBuild (давайте создадим простое консольное приложение и назовём его DelphiAutomatedBuild):

Продолжаем вкусно готовить asyncio

Теперь мы уже знаем достаточно, чтобы написать модный асинхронный микросервис, реализующий паттерн "API-шлюз". И попутно познакомимся с асинхронным логгированием и доступом к базе данных.

Почему так сложно понять asyncio?

Асинхронное программирование традиционно относят к темам для "продвинутых". Действительно, у новичков часто возникают сложности с практическим освоением асинхронности.

Но будь я автором самого толстого в мире учебника по python, я бы рассказывал читателям про асинхронное программирование уже с первых страниц. Вот только написали "Hello, world!" и тут же приступили к созданию "Hello, asynchronous world!". А уже потом циклы, условия и все такое.

Написано довольно много хороших материалов о свободных лицензиях, в том числе тут, на Habr. Почему стоит прочитать еще и эту статью: 

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

• эмуляторы
• библиотеки для разбора форматов файлов
• интерактивные дизассемблеры
• документация
• динамическая инструментация

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

В данной статье я постараюсь подробно рассказать о том, как написать небольшую игру, используя в качестве инструментов язык программирования Rust и библиотеку macroquad.

Добрый день Хабр. Сегодня, мы с вами окунемся в «О дивный мир» форензики. В данной статье Мы решили собрать программы, которые помогут Вам в проведении расследований и, что немаловажно, будут при этом бесплатными.

DISCLAIMER: Данная статья написана в ознакомительных целях и не является руководством к неправомерным действиям или обучающим материалом для сокрытия правонарушений.

Привет, Хабр!

Меня зовут Юрий Шабалин, я один из основателей компании "Стингрей Технолоджиз" (входит в группу компаний Swordfish Security), мы разрабатываем платформу анализа защищенности мобильных приложений iOS и Android.

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

Разновидностей алгоритмов генерации "плазм" столько же, сколько, наверное, звезд на небе. Но связывает их вместе принцип плавного формирования перехода цветов.

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

Я попробую рассмотреть один из вариантов, который использует функции синуса и косинуса.

Простая сортировка массива очень простая задача, в то время как эффективная сортировка очень сложная, во многом из-за простоты задачи.

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