Привет, Хабр! Относительно недавно после пары лет перерыва в айти, потраченных на изучение японского языка, мне пришлось срочно обновлять свои знания на работе. Ну знаете, искать возможности исполнить все хотелки начальника, как и положено эникею. Меня ждало много увлекательных открытий, но при этом, как водится, и немало боли и борьбы с непонятками. Docker, контейнеры, реверс DNS и реверс прокси, получение TLS сертификатов. В какой-то момент я наконец дошёл до удобного решения, которым я теперь хочу поделиться.

В своё время домашний сервер очень облегчил бы мне понимание Docker’а, да и удобство работы с ним неслабо бы повысил. Поэтому возникла идея написать эту статью, после прочтения которой любой человек даже с поверхностными знаниями в информационных технологиях сможет поставить себе постоянно доступный домашний сервер на базе Docker Swarm с удобной веб-мордой, простым получением TLS-сертификатов и Heroku-подобным функционалом (для чего будем использовать PaaS CapRover). 

Статья, в общем-то, рассчитана на новичков, обладающих какими-то техническими знаниями — школьников старших классов, студентов и просто любителей — а потому вряд ли будет интересна серьёзным профессионалам.

Настройка "с нуля"

Пошаговая настройка миниАТС FreePBX с GSM модемом на Raspberry Pi для себя или небольшого офиса.

Хочешь войти в айти? А насколько оно надо?

История вайтишника, взятая не с отзыва на обучающем сайте.

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

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

В настоящее время в связи с обстановкой в мире во многих отраслях производства наблюдается проблема с поставкой запасных частей для оборудования и не только. В ситуации, когда поставка оригинальных деталей невозможна или занимает слишком длительный срок, например, поставка какого-либо кронштейна, критически необходимого для работы МРТ-аппарата, необходимо иметь возможность изготовить деталь самостоятельно. Зачастую, к деталям выставляются дополнительные требования, например: работа в сложных климатических условиях (с большой амплитудой температур, с низкими / высокими температурными минимумами и максимумами), работа в средах с сильными магнитными полями и прочее.

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

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

Мною был выбран один из наиболее доступных на рынке пластиков для FDM-печати материал – PET-G-пластик компании Bestfilament (Производство: Россия).

1.5 годовое исследование IT‑курсов открыло мне глаза на 3 вещи:

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

2. Есть огромный, почти в 10 раз, разрыв в статистике трудоустройства выпускников между худшими и лучшими QA-курсами.

3. У худших по трудоустройству курсов зачастую лучшие отзывы.

При этом IT‑компании, как и прежде, ищут квалифицированных джунов и редко находят.

Привет, Хабр!

Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.

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

Каждый, кто сталкивался с внедрением новых подходов, испытывал весь спектр эмоций. Особенно, если дело касается государственного сектора. РТЛабс использует практики SAFe® с 2022 года. Как мы провели продуктовую трансформацию — подробно в другой статье. 

Здесь расскажем про важную часть SAFe® — PI-планирование: как мы готовимся к нему, проводим и как управляем планом в течение квартала. С какими ограничениями сталкиваемся и как обеспечиваем работу 1 500 человек в квартальном цикле.

Будет полезно тем, кто хочет изменить подходы к производству ПО, начинает или уже работает с государственным сектором. Мы — самый большой кейс внедрения практик SAFe® в России.

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

В этом посте мы при помощи наших коллег, Антона Масленникова и Антона Горбунова, попробуем наметить возможные векторы развития для QA-специалиста. Под катом — путь тестировщика, вертикальный и горизонтальный рост, переходы из тестирования в разработку или менеджмент и многое другое.

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

Зачем я это делал

Результаты

Кто отвечал на вопросы?

Привет, меня зовут Денис Свиридов, я занимаюсь автоматизацией тестирования в Hoff Tech. Мы активно разрабатываем микросервисы для сети мебельных гипермаркетов Hoff и естественным образом пришли к необходимости проведения нагрузочного тестирования по ним. В таком тестировании мы видим один из обязательных шагов для улучшения качества создаваемых IT-решений.

У нас сложилась следующая ситуация. С одной стороны, в компании много аналитиков и ручных тестировщиков, которым требуется проверять свои IT-решения на прочность. Они ищут ответы на вопросы: отказоустойчив ли наш сервис платежей, не просаживается ли веб-страница корзины товаров во время распродаж из-за сервиса скидок, каков предел масштабирования текущего сервиса уведомлений клиентов? 

С другой стороны, в штате совсем немного тестировщиков-автоматизаторов, которые могут разрабатывать нагрузочные тесты.

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

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