Немного предыстории: я начала свой путь в QA в частности (и в IT в целом) 7 лет назад, когда "войти в IT" было не так мейнстримно, как сейчас. Курсы, если и были, то не на слуху. Чтобы устроиться QA Junior, я самостоятельно выискивала информацию в интернете, готовясь к собеседованию. Не помню как (видимо, память вытеснила травматичные воспоминания :) ), но собеседование я прошла и приступила к началу тестерской работы.
К чему я это всё?
Привет, Хаброжители!
Ольга Назина — признанный автор книг и учебных курсов по тестированию ПО. Удивительный мультяшный стиль изложения с сотнями картинок‑комиксов помогает легко воспринимать сложные темы, постигать азы и развиваться в профессии специалиста по QA. Новая книга, вышедшая в 2024 году, знакомит с тонкостями регистрации и отслеживания статуса багов в процессе разработки приложений. Будет безусловно полезна начинающим тестерам, слушателям ИТ‑курсов, а также всем, кто интересуется системным подходом к тестированию ПО.
На днях узнал, что вышла русскоязычная версия третьего оригинального издания книги «Искусство схемотехники» (статья на Хабре). Новость заинтриговала. Так как достаточно давно увлекаюсь этой книгой и не понаслышке знаю, что отечественные читатели ее очень ждали. Точнее даже, заждались. Авторы оригинальной книги еще в 2015 году сделали рекламу своему произведению, разместив в свободном доступе, на сайте, посвященному книге, предисловие к третьему изданию. Но это не только реклама, но и достаточно детальное описание книги, а также декларация концепций и идей в ней заложенных. Надеюсь, мой скромный любительский перевод не будет воспринят издательством «Бином» в штыки: целей что-либо нарушать у меня нет. Если что, ко мне можно обратиться на почту. Я всегда рад конструктивному диалогу и считаю, что давно сложились условия, когда отечественная версия оригинальной книги просто обязана превзойти оригинал. Кроме того, реклама от самих авторов-корифеев еще никому не вредила.
Я заказал себе «первый том» от «Бинома». Скоро должна книжечка прийти. Я ее внимательно изучу, и по результатам будет рецензия. Надеюсь, книга оправдает мои ожидания. Даже интересно сравнить свои навыки в переводе с профессионалами. А пока, предлагаю приступить к чтению предисловия.
Здравствуйте, уважаемые читатели!
Сегодня я хотел бы поговорить о том, какие пищевые добавки, а если говорить точнее, эргогенные средства, действительно работают и дают результат, даже учитывая факт того, что, по сути, между эргогенными средствами и пищевыми добавками нельзя напрямую поставить знак “=”.
В силу того, что тема БАДов популярна в СМИ, о ней регулярно говорят различного рода эксперты, и она неоднократно рассматривалась в том числе на Хабре (см. Рисунок 1 ниже), я хотел бы поставить точку в данном вопросе, при этом, что самое важное, предоставив читателям методологию, которая позволит отделить зёрна от плевел, или, другими словами, истинное от, в лучшем случае, бесполезного, а в худшем – вредоносного.
“Электронщики, как учит нас Парацельс, самозарождаются среди паяльников, радиодеталей, универсальных плат и проводов” (@teap0t)
Возможно, это действительно так, но без хорошей книги - учебника или справочника, которые служат катализатором, этот процесс может так и не завершиться. А лучшей книгой для начинающих разработчиков электронных схем и практически библией электронщиков последние сорок лет, считается "Искусство схемотехники" (англ. - The Art of Electronics) Пауля Хоровица и Уинфилда Хилла.
Привет, Хаброжители!
Привет, Хаброжители!
Привет, Хаброжители!
Привет, Хаброжители!
Пожалуй, нет более популярной темы для обсуждения, чем применение Agile в проектах SAP. Несмотря на то, что принципы гибкой разработки были сформулированы ещё в 2001 году [1], их использование в настоящее время становится как никогда востребованным. Связано это в первую очередь с тем, что последнее десятилетие знаменуется массовым использованием информационных технологий (далее – ИТ) в повседневной жизни: порталы государственные услуг, интернет-магазины, электронное правительство и многое другое. Вышесказанное требует как грамотной разработки программного обеспечения (далее – ПО), так и не менее искусного его внедрения.
В мире инструментов веб‑разработки особое место занимают технологии, объединенные аббревиатурой MERN (MongoDB, Express, React, Node.js), представляющие собой комплексное решение для разработки современных веб‑приложений. Книга Владимира Дронова «Node.js, Express, MongoDB и React. 23 урока для начинающих» представляет собой полезный ресурс для тех, кто хочет освоить этот стек технологий. И еще важно — это мощная книга на 600+ страниц, а не проходная брошюрка.
Внедрение практически любой ERP-системы требует как ее донастройки, так и доработки. Важное место в ходе имплементации имеют именно программные доработки, занимающие львиную долю проекта по сравнению с активностями кастомизации. От того, как правильно вы подойдете к вопросу планирования и реализации доработок, зависит успех ERP-проекта. Согласно статистике проектов внедрения, более 40% бизнес-потребностей пользователей требуют программной доработки, следовательно качественное планирование работ на проекте немыслимо без унифицированного подхода к оценке плановых трудозатрат на реализацию [1]. В связи с этим, в этой статье хотелось бы затронуть вопрос плановой оценки трудозатрат доработок и донастроек корпоративной информационной системы.
Начнем с основ: потребности заказчика в информационной системе покрываются или ее доработкой, или ее донастройкой, или уже реализованы и не требуют дополнительных усилий. Первые два исхода задают Gap-область, последняя – Fit (рис. 1). Все доделки Gap-области можно классифицировать согласно RICEFS подходу [2], что представляет собой сокращение от англоязычных слов: Report, Interface, Conversion, Enhancement, Form и S (отчет, интерфейс, программа обработки данных, расширение, печатная форма и настройка). Введя термин сложности (низкая, средняя, высокая и очень высокая), можно построить элементарный Оценщик (от английского Estimate, оценивать) [3]. В нем для каждой пары «Тип разработки – сложность» эмпирически задаются плановые трудозатраты для этапов проектирования и разработки, то есть ресурсы функциональных консультантов на фазе дизайна и разработчиков для этапа разработки (табл. 2). Более сложные формы оценщика включают дополнительные параметры: новая разработка или модификация имеющейся, %-переиспользования, а также оценку трудозатрат не только для фаз проектирования и реализации, но и этапов анализа, теста и перехода.
Для меня было полной неожиданностью то, что моя первая и пока единственная статья сразу набрала столько положительных откликов. Спасибо всем, кто столь высокого оценил мой первый опыт.
Я не планировал продолжать эту тему, но сейчас вижу, что кое в чем, статью надо дополнить. Это дополнение не будет повторять или расширять статью очередными мыслями и наблюдениями; все это в ней уже есть и добавить мне нечего. Просто, читая комментарии, я понял, что об одной детали я упомянул, но толком не рассказал. Из‑за чего у части комментаторов возникли сомнения в сегодняшней ценности книг, доступных мне в то время, когда я начинал карьеру программиста. Мне кажется, это не очень справедливо и хотя я, бесспорно, не объективен, но, тем не менее, решил немного об этом рассказать.
Я расскажу о тех книгах, что были мне доступны в 1987–1993 гг., т. е. тогда, когда я совмещал работу инженера с программированием. Конечно, я упомяну только те книги, что мне действительно помогли; полный список литературы слишком обширен и упоминание их всех больше походило бы библиотечный каталог, чего я делать не намерен. Условно эти книги можно отнести к одной из нижеследующих категорий. Итак — вот мой «золотой фонд».
Привет, Хабр! Мы с почином — в блоге SSP SOFT стартует новая рубрика с анонсами выхода книг по программированию и операционным системам от издательства «БХВ-Петербург». Узнав об этой инициативе, издатель подарил всем читателям Хабра специальную скидку по промокоду, который вы найдете в тексте. Начнем рубрику, пожалуй, с пары новых книг про Python, которые вышли за последний месяц. Ревью книг — не копия текста с сайта издательства, а сугубо наше мнение, после прочтения.
Несколько недель назад я занимался хаком языковых серверов в Zed, пытаясь заставить Zed определять, когда заданный бинарник языкового сервера, например gopls, уже присутствует в $PATH. Если так, вместо загрузки нового бинарника Zed должен использовать его.
Трудность: часто $PATH динамически изменяется такими инструментами, как direnv, asdf, mise и другими, которые позволяют в данной папке установить определённый $PATH. Почему эти инструменты так делают? Потому что это даёт возможность, скажем, в начале $PATH добавить ./my_custom_binaries, пока вы находитесь в my-cool-project. Поэтому нельзя просто использовать $PATH, связанный с процессом Zed, нужен $PATH, как он есть, когда выполняется cd в каталог проекта.
Легко, подумал я. Просто запусти $SHELL, выполни cd в проект, чтобы запустить direnv и всё такое, запусти env, сохрани окружение, выбери $PATH, найди в нём бинарники. И это было легко. Вот часть кода, та часть, которая запускает $SHELL, cd и получает env:
fn load_shell_environment(dir: &Path) -> Result<HashMap<String, String>> {
// Получает $SHELL
let shell = std::env::var("SHELL")?;
// Конструирует команду, которую хочется выполнить в $SHELL
let command = format!("cd {:?}; /usr/bin/env -0;", dir);
// Запускает $SHELL как интерактивную оболочку (чтобы использовались файлы пользователя rc).
// и выполняет `command`:
let output = std::process::Command::new(&shell)
.args(["-i", "-c", &command])
.output()?;
// [... проверка кода выхода, получение stdout, превращение stdout в HashMap и т. д. ...]
}За исключением одного: после запуска экземпляра Zed в терминале, который выполнял эту функцию, я больше не мог убить Zed, нажав Ctrl-C.
Одной из важных стадий формирования UX (User experience) диджитал-продукта является релиз MVP (Minimal Viable Product, он же минимально жизнеспособный продукт). Эта такая версия вашего приложения или программы, которая подразумевает минимальное количество реализованных в продукте функций, достаточное при этом для формирования пользовательского опыта и фидбека. Это помогает понять, устраивают ли пользователей имеющиеся функции и как его улучшить.
Однако даже после выделения MVP оставшиеся функции могут оказаться многосоставными - раскладывающимися на более мелкие. Отличный метод декомпозиции функциональности — картирование пользовательских историй (User Story Mapping).
