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

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

Автор статьи – irintus (имя изменено), в подробностях рассказала, зачем и как она убила процесс разработки, куда и какие зонды вставила, но забыла написать, чего этим добивалась. Давайте я это исправлю.

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

Однажды отделу тестирования понадобился инструмент для постоянного измерения скорости загрузки страниц, с помощью которого можно узнавать о проблемах на сайте в режиме реального времени.
В статье я расскажу о том, как силами QA-отдела REG.RU мы сделали мониторинг страниц на основе Jmeter. 

Периодически меня на начальном курсе просят дать "список всех-всех команд с кратким описанием что делает"... Ну прям "всех-всех". И ведь если искать в интернете "такие" справочники существуют - либо про "20-30 команд, но самых важных", либо с неточностями и устаревшей информацией. Так что предлагаю вашему вниманию свою версию такого "краткого" справочника (на 300, 515, 612, 716, 842, 1005, 1110 команд) с ссылками на wiki-описание и на cheat.sh-примеры наиболее важных команд.

Больше функционала для минималистичного прототипа игры: объекты уровня, враги, апгрейд управления, глобальный скрипт и статичные выстрелы.

Избегаем повторений, не используем слова с субъективной оценкой, — и еще 9 рекомендаций по проверке качества требований.

Привет всем тем, кто использует миникс — Я делаю (свободную) операционную систему (это только хобби, не столь большое и профессиональное, как GNU) для 386(486)AT клонов. Эта система пишется с апреля и скоро будет готова. Я хочу получить любой отзыв, касающийся вещей, которые нравятся/не нравятся людям в миникс, так как моя ОС похожа на неё (такое же устройство файловой системы (по практическим соображениям), среди прочего).

В настоящее время я портировал bash (1.08) и gcc (1.40), и, похоже, эти программы работают. Это значит, что я получу что-то практичное в ближайшие несколько месяцев, и я хочу узнать, какие возможности хотят большинство людей. Любые предложения принимаются, но я не обещаю, что я осуществлю их:-)

Линус (torvalds@kruuna.helsinki.fi)

PS. Да — в ней нет кода миникс, и будет мультипотоковая ФС. Система НЕПЕРЕНОСИМА (использует команды Intel 386 и т. д.) и, вероятно, будет поддерживать только жесткие диски AT, так как это всё, что у меня есть 🙁

Найм профессионального программиста — это слишком дорого, да и программирование — совсем не быстрый процесс. А бизнесу всегда нужно "вчера" и желательно бесплатно. Поэтому всё более популярным становится no-code подход: вы не пишете код, а просто, используя кнопки в интерфейсе и мышку, компонуете своё приложение. Звучит красиво. Так можно создать типовое приложение, накидав туда компоненты. Вот пример рекламной статьи no-code системы Bubble, в которой, по сути, говорят, что для стартапа программисты уже не нужны, по крайней мере — на начальном этапе.

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

Но что же будет, если этот подход разовьётся до небес? Можно ли будет его использовать для всё более и более сложных систем? Можно ли выкинуть программистов на улицу?

Вопрос некорректен

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

Накопить за 7 лет терабайты данных в монолите и решить, что пора оптимизировать систему и разбивать её на микросервисы — страшный сон для айтишника. Добавим сюда ещё база на решениях от 1С и необходимость обеспечить непрерывность процесса. Стало страшно? А для нас — возможность показать экспертность и решить нетривиальную задачу. О том, как «кролик» помог сдвинуть гору рассказал архитектор 1С компании «Автомакон» Виталий Осиповский.

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

Любые сбои и простои были неадекватно затратны и влияли на все компоненты системы в целом. А сама система не годилась для быстрого масштабирования бизнеса. Поэтому уже в 2020 году приняли решение о поэтапном разделении монолита на отдельные программные компоненты.  

Машина

В этой статье рассмотрим особенности тестирования мобильных приложений с помощью эмуляторов/симуляторов и на реальных устройствах.

Содержание:

Что такое мобильные эмуляторы и симуляторы;

Типы мобильных тестов;

Инструменты/фреймворки автоматизации мобильного тестирования;

Когда можно использовать эмуляторы/симуляторы, а а когда — стоит тестировать на реальных устройствах.

polkit – это системный сервис, по умолчанию устанавливаемый во многих дистрибутивах Linux. Он используется демоном systemd, поэтому в любом дистрибутиве Linux, где применяется system, также используется polkit. Автор этой статьи, входя в состав a GitHub Security Lab, работает над улучшением безопасности опенсорсного софта; он ищет уязвимости и докладывает о них. Именно он однажды нашел уязвимость в polkit, позволяющую злоумышленнику увеличить его привилегии. Раскрытие уязвимости было скоординировано с командой по поддержке polkit, а также с командой по обеспечению безопасности в компании Red Hat. О раскрытии этой уязвимости было объявлено публично, патч для нее был выпущен 3 июня 2021 года, и ей был присвоен код CVE-2021-3560.

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

История уязвимости CVE-2021-3560 и какие дистрибутивы она затронула

Рассматриваемый баг достаточно старый. Он вкрался в код более восьми лет назад в коммите bfa5036 и впервые мог использоваться в версии 0.113 программы polkit. Однако, во многих популярных дистрибутивах Linux эта уязвимая версия не использовалась до относительно недавнего времени.

Немного специфической историей этот баг обладает в Debian и его производных (например, в Ubuntu), так как Debian использует форк polkit, в котором есть своя особенная схема нумерации версий. В форке Debian этот баг появился в коммите f81d021 и впервые попал в дистрибутив в версии 0.105-26. В стабильном релизе Debian 10 (“buster”) используется версия 0.105-25, таким образом, уязвимости в нем нет. Но некоторые производные Debian, в том числе, Ubuntu, основаны на нестабильной версии Debian, а она уязвима.

В этой статье подробно разбирается алгоритм обучения архитектуры CBOW (Continuous Bag of Words), которая появилась в 2013 году и дала сильный толчок в решении задачи векторного представления слов, т.к. в первый раз на практике использовался подход на основе нейронных сетей. Архитектура CBOW не столь требовательна к наличию GPU и вполне может обучаться на ЦП (хотя и более медленно). Большие готовые модели, обученные на википедии или новостных сводках, вполне могут работать на 4-х ядерном процессоре, показывая приемлемое время отклика.

После весны 2020 года слово “тестирование” приобрело некоторые неожиданные значения и неоднозначные коннотации — пожалуй, везде, кроме IT. В нашей сфере без него никуда — и так было всегда.

Видов тестирования ПО — множество: модульное, функциональное, А/В-тестирование, интеграционное, нагрузочное и т д. И на наш взгляд, как раз последнее является как самым важным, так и наиболее сложным. Ведь если ошибки, которые могут быть выявлены с помощью A/B-тестов, модульных, функциональных и интеграционных тестов, проявляются практически сразу после “выкатки” новой версии приложения, то проблемы, на выявление которых нацелено нагрузочное тестирование, — “спящие”. И обнаруживаются они только тогда, когда на новую версию вашего сайта или приложения придет реальный пользовательский трафик, с которым не справится “софтверная” часть проекта (база данных, application-сервер) или “железно-инфраструктурная” (нехватка оперативной памяти в кластере, большая нагрузка на дисковую подсистему при операциях чтения-записи).

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

Давайте представим ситуацию, когда вам нужно установить на все виртуальные машины (агенты сервера сборки) определенный пакет Python. Но вы не можете изменить образ агента, а загрузка, к примеру из pypi.org или github.com непроверенных пакетов, ограничена. Как тут не вспомнить последние новости про вредоносные изменения в пакете nmp или более свежую информацию про PyPi.

Python использует подход под названием EAFP — Easier to ask for forgiveness, than permission (легче попросить прощения, чем разрешения). Это значит, что проще предположить, что что-то существует (к примеру, словарь в словаре, или в нашем случае модуль в системе) или получить ошибку в противном случае.

Этот подход, развитый в PEP-0302, позволяет делать хук импорта модулей, что в итоге приводит нас к возможности написания следующего кода:

Привет

Сегодня мы создадим небольшое приложение .py и загрузим его в Azure.

Требования: учетная запись Azure + желание узнавать новое и экспериментировать. Также нужен VSCode (бесплатная IDE).

Когда мы закончим, мы получим...

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