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

Первая часть – организационно-управленческая – должна быть полезна в первую очередь тем, кто отвечает за автоматизацию тестирования и создает такие системы в целом. Руководители проектов, лидеры групп и владельцы сервисов функционального и автоматического тестирования, все, кого волнует вопрос «как построить экономически эффективное end-2-end тестирование своей ИТ системы», найдут здесь конкретный план и методику.

Источник

На дворе осень и сын все чаще остается дома, уткнувшись в телефон или планшет, слабо реагируя на внешние раздражители. Меня это огорчает. Сам я начал программировать, как мне кажется, с того, что к моему первому компьютеру БК 0010-01 игры то на кассетах в комплекте шли, а вот магнитофон не шел. Пока добывали магнитофон с подходящим линейным выходом, я успел попробовать Бейсик, спасибо отцу за первые уроки. Так что, когда смог со скрипом загрузить первую графическую игру, то смотрел на нее уже не как на то, во что наконец буду играть, а очарованно думал, как бы сделать свою не хуже. Сына же, в его 8 лет, давно поглотил мир видеоигр и ютуба, так что начинать программирование с трели на встроенном динамике, похоже, впечатления не произведет.

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

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



Меня зовут Катя Гаврилова, я основатель рекрутингового агентства DigitalHR. Однажды я выступала на Saint TeamLead Conf в 2018 году, и мой доклад «Роль тимлида в рекрутинге» попал в топ-5 лучших. А уже на Moscow TeamLead Conf доклад «Мало опыта — много собеседований: как проводить интервью, чтобы от вас не скрывали правду» не прошел в топ, но я до сих пор получаю на него хорошие отзывы от разработчиков, поэтому решила поделиться его версией в текстовом варианте. Целевая аудитория — тимлиды и CTO, которые недавно стали подбирать сотрудников к себе в команду.

Всем привет! Команда TestMace публикует очередной перевод статьи из мира web-разработки. На этот раз для новичков! Приятного чтения.

Развеем пелену таинственности и недопонимания над синтаксисом <T> и наконец подружимся с ним

Наверное, только матёрые разработчики Java или других строго типизированных языков не хлопают глазами, увидев дженерик в TypeScript. Его синтаксис коренным образом отличается от всего того, что мы привыкли видеть в JavaScript, поэтому так непросто сходу догадаться, что он вообще делает.

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

В комментариях к моей статье Docker: вредные советы было много просьб объяснить, чем так ужасен описанный в ней Dockerfile.

Краткое содержание предыдущей серии: два разработчика в жестком дедлайне составляют Dockerfile. В процессе к ним заходит Ops Игорь Иванович. Итоговый Dockerfile плох настолько, что ИИ оказывается на грани инфаркта.

Сейчас разберемся, что не так с этим Dockerfile.

Итак, прошла неделя.

Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?

Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.

В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?

Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?

Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»

Так что изменилось? — Всё изменилось!

Эта памятка писалась для внутренних нужд (открыть глаза менее опытным в вебе коллегам). Но, т.к. я насмотрелся велосипедов от довольно уважаемых, казалось бы, контор, — выкладываю на хабр. Мне кажется, многим будет полезно.

Зачем

Надеюсь, читающий уже понимает, зачем ему вообще нужен именно REST api, а не какой-нибудь монстр типа SOAP. Вопрос в том, зачем соблюдать какие-то стандарты и практики, если браузеры вроде бы позволяют делать что хочешь.

• Стандарт HTTP это стандарт. Его несоблюдение вредно для кармы и ведёт к постоянным проблемам с безопасностью, кэшированием и прочими "закидонами" браузеров, которые совсем не закидоны, а просто следование стандарту.
• Велосипеды со всякими {error: "message","result":...} невозможно нормально тестировать и отлаживать
• Поддержка большим количеством готовых клиентских библиотек на все случаи жизни. Те, кто будет вашим api пользоваться, скажут большое человеческое спасибо.
• Поддержка автоматизированного интеграционного тестирования. Когда сервер на любые запросы отдаёт 200 ОК — ну, это такое себе развлечение.

Итак, вы решили сделать новый проект. И проект этот — веб-приложение. Сколько времени уйдёт на создание базового прототипа? Насколько это сложно? Что должен уже со старта уметь современный веб-сайт?

В этой статье мы попробуем набросать boilerplate простейшего веб-приложения со следующей архитектурой:

Что мы покроем:

• настройка dev-окружения в docker-compose.
• создание бэкенда на Flask.
• создание фронтенда на Express.
• сборка JS с помощью Webpack.
• React, Redux и server side rendering.
• очереди задач с RQ.

От переводчика: перевели для вас статью Брета Кэмерона о хитростях в работе с CSS. Многие моменты пригодятся не только новичкам, но и опытным разработчикам.

Эта статья о приемах работы в CSS, узнав о которых, я восклицал: «Агаааа!». Надеюсь, вы тоже сделаете пару открытий.

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

Я покажу несколько приемов и расскажу о принципах их использования в CSS. Сама по себе статья не о сложностях. Наоборот, она призвана сделать вашу работу более комфортной.

Геннадий — middle-разработчик в большой IT-компании. Он интересуется джавой, кодит с 11 до 20, ездит на работу на самокате, ходит в бар с коллегами по пятницам и скучает на эджайл-митингах. Геннадий участвует в код-ревью и легко даёт советы младшим товарищам, когда дело касается прямых рабочих обязанностей. Проблема в том, что прямыми рабочими обязанностями работа не ограничивается, и тогда начинается адок.

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

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

Привет Хабр! Меня зовут Оксана Селендеева. Я считаю, что лучше начинать программировать с юного возраста — 4-5 лет, потому что кодинг активно развивает у детей когнитивные функции мозга, и это впоследствии помогает им отлично усваивать точные науки. А попробовать себя в программированию можно через обучающие игры. Мы с преподавателями школы программирования для детей CODDY составили такую подборку.

Для дошкольников

Box Island — мобильная 3D-игра, которая обучает основам кодирования через увлекательное приключение. Игроки путешествуют по острову Box и помогают персонажу собирать звезды, разбросанные по пустыне. Через игровой квест дети изучают основы алгоритмов, последовательностей, циклов и условных выражений, а ещё игра развивает алгоритмическое мышление и распознавание образов.

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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

Краткое знакомство с kubernetes для разработчиков на примере разворачивания простого шаблонного сайта, с постановкой его на мониторинг, выполнением джобов по расписанию и health checks (все исходники прилагаются)

— Установка Kubernetes
— Установка UI
— Запуск своего приложения в кластере
— Добавление кастомных метрик в приложение
— Сбор метрик через Prometheus
— Отображение метрик в Grafana
— Выполнение задач по расписанию
— Отказоустойчивость
— Выводы
— Заметки
— Список литературы

В июле 2010 года я написала статью «Как использовать CSS3 медиа-запросы для создания мобильной версии вашего сайта» для журнала Smashing. Спустя почти восемь лет эта статья по-прежнему очень популярна. Я решила вернуться к этой теме, поскольку теперь у нас есть такие методы компоновки, как Flexbox и CSS Grid. В этой статье мы рассмотрим современные методы использования медиа-запросов в адаптивном дизайне, а также рассмотрим, что может произойти в будущем.

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


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

Поэтому, если вы хотите лучше понять промисы, мы предлагаем вашему вниманию перевод очередной статьи, посвящённой этой теме. Её автор говорит, что он последние 10 лет занимался разработкой на Java и PHP, но всё это время с интересом поглядывал на JavaScript. Недавно он решил всерьёз заняться JS и первой заинтересовавшей его темой стали промисы.



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

Почему bash?

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

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

Предисловие

Данное руководство сопровождает ShellHarden, но автор также рекомендует ShellCheck, чтобы правила ShellHarden не расходились с ShellCheck.

Bash — не тот язык, где самый правильный способ решить проблему одновременно является самым простым. Если принимать экзамен по безопасному программированию в bash, то первое правило BashPitfalls звучало бы так: всегда используй кавычки.

Главное, что нужно знать о программировании в bash

Маниакально ставить кавычки! Незакавыченная переменная должна расцениваться как взведённая бомба: она взрывается при контакте с пробелом. Да, «взрывается» в смысле разделения строки на массив. В частности, расширения переменных вроде $var и подстановки команд вроде $(cmd) подвергаются расщеплению слов, когда внутренняя строка расширяется в массив из-за расщепления в специальной переменной $IFS с пробелом по умолчанию. Это обычно незаметно, потому что чаще всего результатом становится массив из 1 элемента, неотличимый от ожидаемой строки.

Привет Всем! Я недавно запустил на GitHub проект JavaScript Algorithms and Data Structures, который содержит примеры классических алгоритмов и структур данных написанных на JavaScript с объяснениями, примерами и ссылками для дальнейшего изучения (в частности на соответствующие YouTube видео).

Основная задача проекта — помочь программистам в изучении и применении алгоритмов и сделать это на JavaScript-е.

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


Что вы найдете в этой статье:

• Кое-что из моей биографии
• Рассказ о том, как меня пригласили на собеседования топовые IT компании мира: Facebook Google, Amazon, LinkedIn, Microsoft, Twitter, Pinterest, Snapchat и другие
• Рассказ о том, как я получил несколько предложений о работе на должности программиста
• Уроки, которые я вынес из этого опыта

(С)

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

• кэширование страниц сайта для офлайн доступа;
• ведение учета страниц, доступных офлайн, проброс необходимых данных;
• мониторинг статуса сети, онлайн или офлайн;
• общение сервис-воркера со страницами и вкладками, которые он обслуживает;
• перехват сервис-воркером запроса на открытие адреса /offline/ и генерирование новой страницы прямо на устройстве, без запроса к серверу.

Если тема сервис-воркеров и Progressive Web Apps (PWA) для вас новая, то перед чтением этой статьи необходимо познакомиться с ними поближе.

Меня зовут Рыбин Павел, я работаю во фронтенд-разработке Медиапроектов Mail.Ru Group. Это руководство мне помогали писать грабли, набитые шишки и подводные камни, попавшиеся мне при реализации PWA для мобильной версии Авто Mail.Ru.

В тексте будут встречаться небольшие примеры кода, иллюстрирующие рассказ. Расширенную же демо-версию можно посмотреть на GitHub.

Представьте что в Роскосмосе решили собрать новую ракету не имея при этом чертежей и четкого понимания как ракета должна быть устроена. Отдельный завод занимается корпусом ракеты, отдельный выпускает двигатели, еще один — сопла. Главный менеджер Роскосмоса сказал что он доверяет профессионалам, и мастерски сделегировал всю работу заводам.



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

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

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

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

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

В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.