Новая подборка советов про Python и программирование из моего авторского канала @pythonetc.

← Предыдущие публикации


Очевидно, что разные asyncio-задачи используют разные стеки. Можно в любой момент просмотреть их все, получив с помощью asyncio.all_tasks() все выполняемые сейчас задачи, а с помощью task.get_stack() получив стеки для всех задач.

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

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

Недавно посмотрела выступление одного scrum-мастера и stand up комика по совместительству. Выступление оказалось эмоциональное, с большим количеством непечатных слов и долей здравого смысла.

В каждой шутке только доля шутки, но все же прошу не относиться к этому материалу слишком серьезно. Предлагаю для ознакомления свое изложение в «очищенном» формате. Увидеть полное выступление Ильи Якямсева «Эффективность не работает» на конференция FrontDays 2018 можно по ссылке.

Эффективность не работает

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

Я работаю менеджером проекта. Начинал я в Тольятти, в 96 году, на должности «эй, пацан, принеси пиво». С 99 года я начал программировать front, тогда это называлось «верстак». Потом я открыл контору, закрыл ее, многое произошло, и сейчас я менеджер проектов.

Мой доклад называется «Эффективность не работает». И я объясню почему.

Жизнь после 30

Дело в том, что мне сорокет в этом году. Я работаю в основном с людьми помоложе себя, и они у меня часто спрашивают: «Илья, как она жизнь в IT после 30? Ну, то есть, что с ней происходит?». Я отшучиваюсь: как говорится, баб поменьше, детей побольше. 



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

Я всегда думал, что я – тупой. Точнее, что я — тугодум.

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

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

А я, выйдя с совещания, продолжал думать над задачей. И, как говорит устойчивое идиоматическое выражение, хорошая мысля приходит опосля. Находил нормальное, иногда интересное, а бывало – что и офигенное решение. Но оно уже никому не было нужно. Типа после драки кулаками не машут.

Просто культура в тех компаниях, где я начинал работать, была модерновая. Ну, как там это бывает – «совещание должно закончиться принятием решения». Вот чего придумали на совещании, то и принимается. Даже если решение — полная фигня.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Introduction to ASGI: Emergence of an Async Python Web Ecosystem" автора Florimond Manca.

"Черепахи рядом с водоемом", Ricard Baraham на unsplash.com

Python не замыкается только на Data Science, веб-разработка на Python вернулась с новым асинхронным витком в развитии языка!

Сейчас происходит много важных событий в экосистеме веб-разработки на Python. Одним из основных драйверов этих изменений является ASGI — Asynchronous Server Gateway Interface.

Я уже несколько раз упоминал ASGI в моем блоге, в частности, когда анонсировал Bocadillo (асинхронный open-source веб-фреймворк на Python — прим.пер.) и tartiflette-starlette (библиотека для построения GraphQL API поверх HTTP через ASGI — прим.пер.), но я никогда не писал подробное введение о нем. Теперь я это сделаю.

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

Прежде чем мы начнем, я хотел бы рассказать, что недавно создал awesome-asgi — отличный список для отслеживания постоянно расширяющейся экосистемы ASGI.

Normal Mapping

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

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

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

Под катом попробуем разобраться чем отличаются «высокотехнологичные» компании от «низкотехнологичных», что нужно, чтобы высокотехнологичные компании могли рождаться и выживать, почему с софтом у нас лучше, чем с хардом, с чего начиналась кремниевая долина в США и можно ли её «скопировать», почему Китай всех рвет, а также — окинем взором все, что происходит в Сколково, Роснано, фонде перспективных исследований и приведут ли они к расцвету российских инноваций. Безусловно, я где-то могу ошибаться — буду рад дополнениям в комментариях.

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

В WinAPI есть функция CreateRemoteThread, позволяющая запустить новый поток в адресном пространстве другого процесса. Её можно использовать для разнообразных DLL-инъекций как с нехорошими целями (читы в играх, кража паролей, и т. д.), так и для того, чтобы на лету исправить баг в работающей программе, или добавить плагины туда, где они не были предусмотрены.

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

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

Для понимания текста потребуются базовые знания о системном программировании под Linux: язык Си, написание и отладка программ на нём, осознание роли машинного кода и памяти в работе компьютера, понятие системных вызовов, знакомство с основными библиотеками, навык чтения документации.

Большая часть людей, так или иначе причастных к верстке сайтов, проходят через… Назовем это “путь бутстрапа”. Это такая философская позиция, когда у тебя есть 12 колонок и ничего больше. Ты берешь элементы, кладешь их в определенные колонки и все у тебя хорошо. Можно выключить мозг, погрузиться в нирвану и руки будут сами расставлять элементы. Красота… Но тут появляется современный дизайнер, который рисует что-то, что ну совсем не сходится с этой замечательной концепцией. Колонок явно больше, они все разной ширины, да еще и по высоте что-то нужно выравнивать. Жуть. А встречается такое все чаще, особенно если сделать шаг в сторону от магазинов или админок. Сегодня мы поговорим о том, что же это за чудо такое там используется и как его можно готовить в современном CSS. Кода будет совсем немного, в основном – размышления и картинки.

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

Я живу Великобритании больше двух лет. Изначально, я сюда переехал по рабочей визе, которая накладывает на держателя определенные ограничения: можно работать только на ту компанию, которая вас пригласила, а для того чтобы получить постоянный вид на жительство, нужно прожить по рабочей визе пять лет. Так как страна в целом мне нравится, я решил попробовать повысить свой иммиграционный статус быстрее и получить “визу таланта” (Tier 1 Exceptional Talent). На мой взгляд эта виза — самая лучшая британская виза, про которую как ни странно далеко не все люди, рассматривающие возможность переезда сюда, знают.

Привет, Хабр! Представляю Вашему вниманию перевод статьи «JavaScript in 3D: an Introduction to Three.js» автора Брета Кемерона (Bret Cameron).

Введение

Three.js это мощный инструмент. Он помогает использовать 3D дизайн в браузере с приемлемой производительностью. По началу Three.js может быть сложным, особенно если вы никогда не погружались в мир 3D программирования ранее.

У меня есть базовый опыт работы с игровым движком Unity и C#, но все равно многие концепции оказались новыми для меня. Я пришел к выводу, что сейчас совсем мало ресурсов для начинающих разработчиков, поэтому я и решил написать эту статью. В ней мы рассмотрим основные элементы Three.js сцены от полигональных сеток и материалов до геометрии, загрузчиков и много другого.

Прим. перев.: В этом замечательном материале компании Okta просто и наглядно рассказывается о принципах работы OAuth и OIDC (OpenID Connect). Эти знания будут полезны разработчикам, системным администраторам и даже «обычным пользователям» популярных веб-приложений, которые скорее всего тоже обмениваются конфиденциальными данными с другими сервисами.

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


«Предоставьте свою банковскую учётку». — «Обещаем, что с паролем и деньгами все будет в порядке. Вот прям честно-пречестно!» *хи-хи*

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

Сегодня имеется единый стандарт, позволяющий одному сервису безопасно воспользоваться данными другого. К сожалению, подобные стандарты используют массу жаргонизмов и терминов, что усложняет их понимание. Цель этого материала — с помощью простых иллюстраций объяснить, как они работают (Думаете, что мои рисунки напоминают детскую мазню? Ну и ладно!).

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

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

Для решения подобных проблем прекрасно подойдёт файловая система NILFS2.

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

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

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

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

Примечание: полный исходный код этого проекта можно найти [здесь]. Так как он является частью более масштабного проекта, я рекомендую смотреть коммит на момент выпуска этой статьи, или файл /source/helpers/arraymath.h, а также /source/world/blueprint.cpp.

В этой статье я хочу подробно рассказать о принципах использования цепей Маркова и статистики для процедурной генерации 3D-зданий и других систем.

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

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

Код Хромиума весьма обширен, там каждому найдётся что-то по вкусу. А я вот решил рассказать о своём любимом файле в нём (а у вас есть такой?). Этот файл отражает всё: боль, разочарование, надежду, упорство, силу воли, ответственность за чужие провалы и самопожертвование. Я иногда читаю его и плачу и проникаюсь пониманием, какая же огромная часть айсберга скрыта под водой. Это, в общем, даже не файл с кодом. Это файл с конфигом, описывающим баги видеокарт, которые Хромиуму приходится обходить для нормального отображения своих страниц на разных платформах. Вот он: https://cs.chromium.org/chromium/src/gpu/config/gpu_driver_bug_list.json

О чём вообще идёт речь? Давайте вспомним, как работает браузер: вы набираете какой-то адрес в адресной строке, браузер загружает контент и отображает его. Чуть детальнее об этом рассказывает хорошая статья «What happens when you type google.com into your browser and press enter?» (и сразу несколько её переводов на Хабре). В ней одним из последних пунктов упоминается, мол, «а теперь, когда всё готово, отрисовываем картинку на экране». Ага, вот так берём и отрисовываем, конечно.

Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.

И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.

Итак, поехали

Любой технически сложный hardware-проект — всегда уравнение с множеством неизвестных: платформа, компоненты, технологии, производство, функциональность, реализуемость. «Пощупать», что получается, можно, когда пройдены дорогостоящие этапы: R&D, выбор комплектующих, разработка программ и поиск фабрики для производства.



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

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

Но мы — на Хабре, и можно попытаться понять проблемы космической отрасли через восприятие и интересы гика. И более того, возможно это принципиально более правильно — смотреть на вещи и проблемы глазами тех, кто хочет выйти на результат.

Кому это интересно, прошу под кат (много букв и никаких картинок).

В общем, небольшая оговорка: выступление будет всего 20 минут.

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



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



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