16-17 июля в 95 км от Москвы пройдёт конференция для python-разработчиков PYCON RUSSIA. Традиционно мы делаем серию интервью с докладчиками и организаторами.

В первом посте мы спросили тимлидов четырёх разных компаний, на что они обращают внимание во время собеседований, какие ошибки допускают кандидаты, как понять, что человек подходит в команду, и чего никогда нельзя делать во время интервью. На вопросы ответили: CTO в компании «Точка» Данила Штань, руководитель разработки в ЦИАН Михаил Юматов, руководитель группы Python-проектов в Rambler&Co Олег Чуркин и руководитель PyCharm Community в JetBrains Андрей Власовских.

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

select; без указания полей, таблицы и условий возвращает одну строку. Но у этой строки нет полей:

=> select;
--
(1 row)

Для сравнения:

=> select null;
 ?column? 
----------

(1 row)
=> select null where 0=1;
 ?column? 
----------
(0 rows)

А сможем ли мы создать таблицу из такого "пустого" запроса? Таблицу без полей.

Всем привет. На самом деле решил написать этот пост по двум причинам.

Первая — обсудить проблему обновления до последнего билда 1703 известной ОС. Это — основная причина в преддверии повального начала обновлений до этого билда.

Вторая — обсудить то, как нам в этом помогает поддержка. Не рассматривайте это как жалобу, а просто как ответ на комментарий «ну так обратись в поддержку!»

Итак…

Не так давно при разработке фильтра файловых систем возникла проблема, которая приводила к подвисанию всей системы. Казалось бы, фильтр выполнял очень простые действия и сам был очень примитивным. Чтобы выяснить причину, пришлось спуститься до отладки и реверс-инжиниринга драйвера NTFS. Анализ выявил очень интересный эффект. Если скомпилировать и выполнить очень простую программу, изображенную на рисунке ниже, то доступ к соответствующему тому подвиснет.

Т.е. в данном примере, если попытаться открыть любой файл относительно файла $mft, доступ ко всему тому «С» повиснет, а так как этот том является системным, подвиснет и вся система. При этом не нужно иметь каких-либо прав. Если же том был не системным, то повиснет только доступ к этому тому, но если выполнить перезагрузку, то система повиснет на ней.

Привет, хабр! 17-20 мая 2017 года в Маунтин Вью, Калифорния, пройдет одиннадцатая по счету, конференция Google I/O, посвященная самым актуальным передовым трендам в технологиях и программном обеспечении от Google.
Желающих побывать там пруд пруди, но не у всех есть такая возможность, взять и слетать в Калифорнию. Поэтому, как и в прошлом году, практически все желающие смогут побывать на Google I/O не покидая своего города!

Google I/O Extended — уникальная возможность стать участником одного из самых крупных слётов любителей Google-технологий. Всё будет происходить в онлайн-режиме, так что вы сможете вместе с представителями GDG в Маунтин Вью наблюдать за ежегодной презентацией самых крутых новинок в IT мире! В прошлом году было одновременно проведено 600+ ивентов I/O Extended по всей планете, в этом году будет больше!

На работе я исследую безопасность ОС или программ. Ниже я расскажу об одном из таких исследований, результатом которого стал полнофункциональный эксплоит типа UAC bypass (да-да, с source-code и гифками).


Ах, да, в Майкрософт сообщили, они сделали вид, что им не интересно.
Алярм! Под катом около 4 мегабайт трафика – картинок и гифок.

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

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

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

Я сейчас не говорю про «Административный кодекс», куда я как раз и отношу неправильное применение шаблонов, неиспользование тестов, неоптимизированный код, даже харкодинг каких-нибудь настроек и «магические числа» (хотя уже на грани). В этих случаях разная правоприменительная практика. Например оптимизированный код часто сложнее для понимания, чем неоптимизированный. Неоптимальный алгоритм зачастую легче воспринимается при чтении кода, а ведь разработчик 95% времени читает свой или чужой код и только 5% пишет. Или если вы пишите скрипт для друга забесплатно, побыстрее и заходкодили пару настроек, вы скорее всего правильно поступили. Решив, что интеграция туда логики извлечения настроек (и ее тестирования) из отдельных конфигов потребует намного большего времени, чем хардкод.

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

Всем известно, что преждевременная оптимизация — это плохо и надо себя одёргивать когда, возникает желание пооптимизировать не вовремя. Однако на практике чаще бывает ситуация когда естественное (и, возможно, интуитивно правильное) желание пооптимизировать подавляется по принципу «если вообще не оптимизировать — это не будет преждевременно». Либо так:



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

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

В течение следующих 12-24 месяцев — другими словами, между 2018 и 2019 годом – метод приема на работу разработчиков программного обеспечения радикально поменяется.


С 2004 по 2014 я работал в Red Hat — крупнейшей в мире компании по выпуску программного обеспечения с открытым исходным кодом. В первый же день, в июле 2004 года, мой босс Марти Мессер сказал мне: «Вся работа, которую ты будешь выполнять здесь, будет открытой, как на ладони. В будущем тебе не понадобится резюме — люди просто будут получать информацию о тебе в Google».

Abstract: описание видов ребута, рассказ про sysrq, ipt_SYSRQ, ipmi, psu.

Как перезагрузить сервер? — Это вопрос, который обычно задают ну очень начинающим пользователям, которые путаются между halt, shutdown -r, reboot, init 6 и т.д.

Опытный администратор уточнит вопрос: «а что с сервером не так?» Разные виды отказов серверов требуют разных видов ребута — и неверно выбранный вариант приведёт к тяжелейшим последствиям, из которых визит в веб-морду IPMI/DRAC/iLO с целью «доперезагрузить» будет самым лёгким. Самым тяжёлым в моей личной практике была командировка эникейщика в соседний город. С целью «нажать ребут» на одиноко стоящем сервере.

В этой статье: что мешает серверу перезагрузиться и как ему помочь.

Начнём с теории ребута.

При выключении или перезагрузке сервера менеджер инициализации (в большинстве современных дистрибутивов — systemd, в эксцентричной Ubuntu 14.04 до сих пор upstart, в архаичном хламе — sysv-init) в определённом порядке посылает всем демонам команду «выключись». И большинство демонов (например, СУБД, вроде mysql) знают, как выключаться правильно. Например, закончить все транзакции, сохранить все несохранённые данные на диск и т.д. Для in-memory СУБД, наподобие redis, это и вовсе может быть критичным: не сохранил — потерял.

Старые системы иницализации ждали неограниченно долго каждый из инит-скриптов. Например, если «шутник» добавил вам в «stop» веточку «sleep 3600», то ваш сервер будет перезагружаться час с хвостиком. А если там цифра поболе, или просто программа, которая не хочет завершаться, то и ребут никогда не закончится.

Понадобилось мне переустановить сервер, который как бы хостился у знакомых знакомых. Там был сильно устаревший Debian, а, самое главное, система стояла на обычных разделах без lvm и пространство было распределено очень не оптимально. Физический доступ получить к нему было практически нереально, местного админа попросить что-то сделать было можно, но занять это могло неделю. Виртуальный KVM у сервера был, но извне на него попасть было нельзя; у как бы хостера не было лишних IP-адресов, а внутрь его сети попасть было невозможно. Надо было переустановить сервер из-под работающей системы по ssh. Ага, давайте поменяем ротор у турбины не выключая, потом её перезапустим и будет она с новым ротором работать!

Мне действительно повезло – когда я впервые трудоустроился по профилю в 2010 году, я попал в хорошую компанию и работал рядом с профессионалами высокого уровня и просто хорошими людьми. Рядом с ними я быстро рос. Мне всегда показывали хорошие практики и действительно уделяли мне время.

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

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

• История, которую я слышал
• Что в ней не так
• Как это было со мной
• Краткий вывод

Если вопросов нет, то поехали.

Вступление

Наверняка первый вопрос, который возник у вас при взгляде на заголовок, был "Шта?". На самом деле я просто перевел фразу "Инверсия управления, внедрение зависимости" в Google Translate на китайский, а затем обратно. Зачем? Затем, что на мой взгляд, это хорошая иллюстрация того, что происходит на самом деле. Люди вокруг путают, коверкают и извращают эти понятия. По долгу службы я провожу много интервью, и 90% того, что я слышу, когда задаю вопрос про DI — честно говоря, откровенный бред. Я сделал поиск по Хабру и нашел несколько статей, которые пытаются раскрыть эту тему, но не могу сказать, что они мне сильно понравились (ладно, ладно, я проглядел только три первых страницы, каюсь). Здесь же на Хабре я встречал в комментариях такую расшифровку IoC, как Injection of Container. Кто-то всерьез предполагает, что есть некий механизм инъекции контейнеров, который сосуществует где-то рядом с DI, и, видимо, даже делает нечто похожее. Только с контейнерами. Мда. На самом деле понять внедрение зависимости очень просто, надо всего лишь…

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

Аркадий и Борис Стругацкие

31 января 2017 года произошло важное для мира OpenSource событие: один из админов GitLab.com, пытаясь починить репликацию, перепутал консоли и удалил основную базу PostgreSQL, в результате чего было потеряно большое количество пользовательских данных и сам сервис ушел в офлайн. При этом все 5 различных способов бэкапа/репликации оказались нерабочими. Восстановились же с LVM-снимка, случайно сделанного за 6 часов до удаления базы. It, как говорится, happens. Но надо отдать должное команде проекта: они нашли в себе силы отнестись ко всему с юмором, не потеряли голову и проявили удивительную открытость, написав обо всем в твиттере и выложив в общий доступ, по сути, внутренний документ, в котором команда в реальном времени вела описание разворачивающихся событий.

Во время его чтения буквально ощущаешь себя на месте бедного YP, который в 11 часов вечера после тяжелого трудового дня и безрезультатной борьбы с Постгресом, устало щурясь, вбивает в консоль боевого сервера роковое sudo rm -rf и жмет Enter. Через секунду он понимает, что натворил, отменяет удаление, но уже поздно — базы больше нет...

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

Highload++ в Москве, ноябрь 2016

Мы сделали для вас подборку лучших (по нашему мнению) выступлений с IT-конференций, на которые собираемся поехать в первой половине 2017 года (как и обещали).

Всё это будет полезно web-программистам (PHP, Go, JS), QA и DevOps. Да, в списке довольно мало конференций, проводящихся на территории России и стран СНГ, но на сегодняшний день их, увы, в принципе не так много. Так что, если вдруг вы знаете о каком-нибудь стоящем мероприятии, дополняйте наш список в комментариях.

Вчера, 31 января, сервис Gitlab случайно уничтожил свою продакшн базу данных (сами гит-репозитории не пострадали).

Дело было примерно так.

Буквально на днях Эрик Стромберг, бывший совладелец книжного сервиса Oyster, чуть более года назад проданного Google, рассказал о матрице, которая поможет вам найти идею для нового стартапа. Сама задумка создания подобной матрицы многим показалась чрезвычайно интересной. Пост Эрика, размещенный в его блоге на Medium, спровоцировал обширную дискуссию и вызвал интерес у мировых СМИ. Тем, кто еще не слышал об этой концепции, мы предлагаем ознакомиться с переводом резонансной публикации.

Всё просто. Тут можно найти «Основы разбора запросов для чайников» в случае PostgreSQL и замечательные невыдуманные примеры из продакшена о том, как не надо писать запросы на PostgreSQL и MySQL и что бывает, если их так всё-таки писать.

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

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