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

Я начал программировать на Rust несколько лет назад, и это постепенно изменило мой подход к разработке программ на других языках программирования, особенно на Python. До того, как я начал использовать Rust, я обычно писал код на Python очень динамично, без подсказок типов, повсюду передавая и возвращая словари и время от времени возвращаясь к интерфейсам со «строковой типизацией». Однако, испытав на себе строгость системы типов Rust и заметив все проблемы, которые она предотвращает, я внезапно стал сильно беспокоиться всякий раз, когда возвращался к Python и не получал тех же гарантий.

От переводчика: мне понравился подход к объяснению декораторов, описанный в этой статье, а так как других вариантов перевода я не нашёл, я решил поделиться этим с аудиторией Хабра. Надеюсь что этот текст будет полезен как новичкам, так и опытным программистам.

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

Цель этого краткого руководства — развеять мифы, которые вы слышали о декораторах, и показать вам другие их стороны, о которых вы и не подозревали.

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

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

Вы сталкивались с тем, что ноутбук случайно включается, хотя вы уверены, что отправляли его в сон?

Бывало, что батарея оказывалась пустой, хотя вы точно-точно помните, как убирали в сумку заряженный на 100% ноутбук?

Тогда вам сюда:

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

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

Недавно я сделал опрометчивый твит, в котором намекнул на то, что у меня имеется глубоко продуманное мнение по одному важному вопросу. Я написал, что пакет pytest-subtests достоин того, чтобы им пользовалось бы больше программистов. Я даже дошёл до того, что, говоря о подтестах (subtests), сказал, что они были единственным, что мне по-настоящему нравилось в unittest до появления их поддержки в pytest. И, как на грех, Брайан Оккен предложил мне поучаствовать в подкасте Test and Code, чтобы подробнее обсудить подтесты. Я могу лишь догадываться о том, что он это сделал, дабы преподнести мне урок, показать мне, что я не должен, накачавшись продуктами Splenda и травяным чаем, выдавать скороспелые мнения о тестировании кода.Но, тем не менее, когда Брайан взглянет на меня со своей хитрой улыбкой и скажет: «Итак, ты готов поговорить о подтестах?», я планировал ответить: «Да, я готов — сделал обширные заметки и набрал справочных материалов». А когда мы вместе будем стоять на сцене, получая Дневную премию «Эмми» за лучший подкаст о тестировании, я шепну ему: «Я раскрыл твою хитрость, и хотя я тебя обыграл, ты реально показал мне — что такое скромность», а по его щеке скатится одинокая слеза.

Или, что скорее всего так и есть, ему просто хотелось пригласить кого-то, с кем можно поговорить об этом конкретном аспекте Python-тестирования, а я оказался одним из тех немногих, встретившихся ему, кто высказывал по этому поводу своё мнение. В любом случае, этот пост будет играть роль моих заметок по механизму подтестов из unittest, который появился в Python 3.4. Здесь же пойдёт речь о сильных и слабых сторонах подтестов, о сценариях их использования. Этот материал можно считать дополнением к подкасту Test and Code Episode 111.

Да, действительно, в этом посте не будет гайда, как поднять Celery в Django. Это статья для тех, кто уже пощупал Celery и хочет погрузиться в детали.

Мотивацией перевести эту статью были следующие вопросы, на которые я не знал ответа: при запуске создается процесс или поток? В какую очередь попадают отложенные задачи с ETA? А какие бывают очереди (спойлер: она не одна)? А в какой момент задача удаляется из очереди? Если я создам задачу с ETA=завтра_в_12:00, она ровно в этот момент и выполнится (спойлер: нет)?

Ответы на все эти вопросы в статье, велком!

В какой-то момент времени я превратился в педанта брюзгу. В фильмах малейшие нестыковки и провалы в логике портят мне весь просмотр. В чатах меня бесит it's вместо its. А в статьях про программирование... Всё плохо. За меня всё уже сказал @AlexanderAstafiev, я лишь процитирую:

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

Самое забавное, что, по моим ощущениям, везде я вижу одни и те же классы проблем. Я даже запилил сервис, где можно закинуть код и получить код ревью, и, собрав немного статистики, понял, что 50 типов ошибок достаточно, чтобы покрыть большую часть проблем в чужом коде. Но выборка у меня была небольшая, и я подумал: а что, если проверить много кода?

В этой подборке представлены полезные малоизвестные консольные Linux утилиты. В списке не представлены Pentest утилиты, так как у них есть своя подборка.

Осторожно много скриншотов. Добавил до ката утилиту binenv.

binenv — cамая интересная утилита для установки новых популярных программ в linux, но которых нет в пакетном менеджере.

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

Ранее Cloud4Y рассказал про уязвимости веб-серверов Nginx, балансировщиков нагрузки и прокси-серверов. Что-то из этого вы могли знать, а что-то, надеемся, стало полезной информацией.

Но история не закончилась. Многочисленные программы bug bounties позволяют проводить широкомасштабные исследования, благодаря которым удаётся найти реально действующие уязвимости. Проект Gixy помог найти множество неправильных конфигураций промежуточного ПО, но далеко не все. Что ещё удалось обнаружить:

Меня зовут Илона, я Senior Experience Designer в EPAM. Я проектирую сложные интерфейсы для зарубежных заказчиков, выступаю с докладами, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и веду Телеграм-канал о UX-дизайне.

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

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

Как вообще устроены боты? Как они взаимодействуют с пользователями? Что с их помощью можно реализовать, а что нельзя?

Подробный гайд о том, как работать с ботами — под катом.

Использование journald как замена syslog'у для приложений с большим числом логов.Давным-давно, когда были дебаты о том, стоит ли принимать в качестве init-системы systemd (с одной стороны удобно, с другой стороны, довольно токсичный автор...), вместе с systemd приехал и journald. В целом, он ощущался как аппендикс к systemd, и вместе с ForwardToSyslog, он мирно жил на серверах. Дефолтная конфигурация в целом устраивала, а всё нужное можно было по-старинке накрутить в syslog'е.

В одном из проектов у нас образовалась потребность в обработке большого числа логов, и мы решили попробовать journald вместо (r)syslog(d|-ng). Оказалось, что:

journald решает все наши проблемы

документации по нему подозрительно мало (особенно, в сравнении с systemd)

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

Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для злоумышленников. Detectify Crowdsource подготовил список наиболее часто встречающихся ошибок, делающих сайт уязвимым для атак.

Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.

Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных нам удалось выяснить,  какие ошибки в конфигурациях встречаются чаще всего.

Задача

Предыстория

/target   // скрипты для сборки ядер
/toolchain   // скрипты для сборки gcc, musl и прочих инструментов сборки 
/feeds   // дополнительные репозитории с приложениями
/package   // скрипты для сборки приложений
...