Предисловие

Всем привет! Меня зовут Саша, и я больше шести лет занимаюсь тестированием бэкенда (сервисы Linux и API). Мысль о статье у меня появилась после очередной просьбы знакомого тестировщика подсказать ему, что можно почитать по командам Linux перед собеседованием. Обычно от кандидата на позицию QA инженера требуют знание основных команд (если, конечно, подразумевается работа с Linux), но как понять, про какие команды стоит почитать во время подготовки к собеседованию, если опыта работы с Linux мало или вовсе нет?

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

Cucumber – это инфраструктура тестирования, позволяющая преодолеть разрыв между разработчиками ПО и бизнес-менеджерами. Тесты пишутся на простом языке управляемой поведением разработки (BDD) в стиле Given, When, Then (условия, операция, результат), которой понятен любому пользователю. Затем контрольные тесты записываются в файлы функций, охватывающие один или несколько сценариев тестирования. Cucumber интерпретирует тесты на указанном языке программирования и использует Selenium для управления тестами в браузере.

Selenoid представляет собой альтернативное решение Selenium Server, хотя суть та же — организация работы драйверов.

В этом посте будет запуск простого браузерного теста с помощью Cucumber и Selenoid в Gitlab CI c Allure отчетом в конце.

Друзья и коллеги, в последнее время на Хабре участились статьи с хейтом в адрес 1С, как платформы для разработки, и выступлениями ее защитников. Эти статьи обозначили одну серьезную проблему: чаще всего, критики 1С критикуют ее с позиции "не осиливших", ругая проблемы, которые де-факто, легко решаются, и, напротив, не задевая проблемы, которые действительно важны, стоят обсуждения и не решаются вендором. Полагаю, что имеет смысл провести трезвый и взвешенный обзор платформы 1С. Того, что она умеет, того что она не умеет, того что она должна бы делать, но не делает и, на сладкое — то, что она делает на ура, а ваши разработчики на %technology_name% будут делать стопицот лет, выкинув на ветер не один годовой бюджет.

В результате, вы, как руководитель или архитектор сможете получить четкое понимание — для какой задачи вам будет выгодно взять 1С, и где ее надо выжигать каленым железом. Как разработчик мира "не 1С" вы сможете посмотреть, а что же там такого в 1С есть из-за чего сыр-бор. А как разработчик 1С — сможете сравнить свою систему с экосистемами других языков и понять свое расположение в системе координат софтверной разработки.

Под катом — масса толстых набросов на 1С, на критиков 1С, на Java, .NET и вообще… Вентилятор заправлен, добро пожаловать!

Недавно я разбирался с API Web Workers. Очень жаль, что я не уделил время этому отлично поддерживаемому инструменту раньше. Современные веб-приложения очень требовательны к возможностям главного потока выполнения JavaScript. Это воздействует на производительность проектов и на их возможности по обеспечению удобной работы пользователей. Веб-воркеры — это именно то, что в наши дни способно помочь разработчику в деле создания быстрых и удобных веб-проектов.

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

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

Задачка 1 — «BANANA»

Всем привет, меня зовут Сергей. Я занимаюсь тестированием фронтенда Яндекс.Маркета. Знаю, что среди читателей Хабра много IT-специалистов, которые как-то связаны с релизным процессом и тестированием. У меня к вам вопрос. Бывало ли в вашей практике так, что фичи долго не катятся в продакшн? Знакомы ли вам раздутые релизы и их объёмные проверки?

Думаю, такое было у каждого. Я пришёл в Яндекс 3 года назад, наша команда была совсем молодой, процессы были налажены не полностью. И я столкнулся с этими проблемами лицом к лицу.

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

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



Автор статьи, перевод которой мы сегодня публикуем, отобрал 9 таких инструментов.

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

Здравствуйте. На написание этой статьи меня побудил наметившийся апгрейд домашней системы и недавняя статья Настольный. Металлический. Бесшумный. Твой?. Чтобы найти приемлемый вариант мне пришлось перелопатить кучу моделей корпусов и сейчас я хочу поделиться своей болью с вами.

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

Типичный компьютерный корпус с точки зрения термодинамики

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

Введение

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

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

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

Привет, меня зовут Евгений. Я работаю в инфраструктуре поиска Яндекс.Маркета. Хочу рассказать сообществу Хабра о внутренней кухне Маркета – а рассказать есть что. Прежде всего, как устроен поиск Маркета, процессы и архитектура. Как мы справляемся с внештатными ситуациями: что случится, если упадёт один сервер? А если таких серверов будет 100?

А ещё вы узнаете, как мы внедряем новую функциональность на куче серверов сразу. И как тестируем сложные сервисы прямо в production, не доставляя пользователям никаких неудобств. В общем, как устроен поиск Маркета, чтобы всем было хорошо.

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

Перевод статьи подготовлен специально для студентов курса «DevOps практики и инструменты».

---

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

Этот обзор (или, если хотите, руководство для сравнения) я написал, когда мне поручили сравнить между собой несколько устройств разных вендоров. К тому же эти устройства принадлежали к разным классам. Пришлось разбираться в архитектуре и характеристиках всех этих устройств и составлять «систему координат» для сравнения. Я буду рад, если мой обзор поможет кому-то:

• Разобраться в описаниях и спецификациях устройств шифрования
• Отличить «бумажные» характеристики от действительно важных в реальной жизни
• Выйти за рамки привычного набора вендоров и включить в рассмотрение любые продукты, подходящие для решения поставленной задачи
• Задать правильные вопросы на переговорах
• Составить тендерные требования (RFP)
• Понять, какими характеристиками придется пожертвовать, если будет выбрана какая-то модель устройства

В книге ”Masters of Doom” о компании id Software и её влиянии на массовую культуру Дэвид Кушнер размышлял о необычном стиле работы ведущего программиста Джона Кармака.

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

Гибкий суррогат

Словом «Scrum» называются, как минимум, две сущности: философия и фреймворк.
Философия, или подход к работе, описан в книге Джеффа Сазерленда.
Фреймворк, т.е. алгоритм действий, описан в документе под названием Scrum Guide.
Философия превратилась в фреймворк, потому что авторы философии хотели заработать на ней денег (по их собственным словам).

Фреймворк сильно упрощен, по сравнению с философией. Главное — упрощена, а точнее выкинута, цель.

Цель философии: ускорение достижения результата. Причем, в разы. В книге есть примеры ускорения в 8 раз.

Цель фреймворка: чтобы у вас был Scrum. Там так и написано: делаете по инструкции — у вас Scrum, нарушаете инструкцию — у вас не Scrum.

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

Люди, преподающие или внедряющие Scrum, работают с фреймворком. Рассказывают и внедряют алгоритм, не приводящий ни к каким результатам, кроме «у нас теперь Scrum».

Суть понятна. Философию продавать очень сложно. Фреймворк — проще.

Фреймворк — это продукт. Он, как положено, прошел «упаковку». Он прост, понятен, есть поддержка и много специалистов. Ничего не напоминает?

Всё хорошо, кроме результата — его нет.

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

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

Эта статья основана на моём выступлении на конференции ITSubbotnik, прошедшем 2 ноября 2019 года в Москве.

Вообще я бэкенд программист, но меня заинтересовала эта технология, она позволяет использовать мои знания бэкенда на фронте.

Проблема

Начнём с проблемы, которая решается этой (относительно новой) технологией. Проблема эта — быстро исполнять код в браузере. Быстро — это значит, «быстрее чем JavaScript», в идеале настолько быстро, насколько позволяет имеющийся у нас процессор.