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

Навряд ли кто-то из читателей хотя бы раз в жизни не арендовал виртуальный выделенный сервер (VPS). Это просто и весьма дёшево: для личного блога, игрового сервера, учебных целей и так далее.

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

Привет, Хабр. Меня зовут Ольга, я работаю в тестировании с 2013 года, специализируюсь на тест-анализе и тест-дизайне. Сегодня хочу рассказать, как при планировании тестирования сохранить фокус на пользователях и их потребностях.

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

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

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

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

В рамках статьи я постараюсь просто рассмотреть и дать ответы на следующие темы:

• что такое архитектура и почему она должна быть чистая;

• как написать архитектуру, которая основана на сервисах;

• пример построения архитектуры для приложения заметок;

• интеграция архитектуры с реактом.

Одни умные люди говорят: "эксепшены - это зло, используйте монады!", другие кричат: "коды ошибок ещё никто не отменял!", а третьи включают механизм исключений в языки программирования.. Однако, у большинства статей, который попадались мне на глаза есть две относительные проблемы (при всём уважении к авторам!):

Некоторая... академичность. Разобрано множество идей и концепций, но заканчивается всё стандартным: "ваш выбор зависит от вашей ситуации".

Абсолютно отсутствуют упоминания о бюджете. Никто же не будет спорить, что теоретически мерседес лучше, чем восьмёрка по всем показателям... если не считать цены.

Цель этого поста - поделиться выработанным практическим рецептом. В конкретном фреймворке и с конкретными границами применимости. Без претензий на уникальность, универсальность, идеальность и, тем более, академическую "правильность".

Кому интересно, прошу под кат.

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

В PropellerAds решили пойти по принципу «нет человека — нет проблемы» и отказались от роли тимлидов. Как компании удалось это провернуть, не только не потеряв ни одного руководителя, но и успешно привлекая тимлидов из других компаний, в своем докладе на конференции TeamLead Conf 2020 рассказал глава продуктового отдела PropellerAds Яков Беккер.

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

Основной материал подготовлен и составлен на основе требований стандарта PCI DSS.  Данные требования также могут быть применены к обработке и хранению персональных данных в части выполнения требований GDPR.

Мой 12 летний опыт подготовки и успешного прохождения аудитов в разных странах мира показывает, что многие компании, которые занимаются разработкой ПО имеют самописные системы и решения, которые обрабатывают карточные (и персональные) данные. А со стороны PCI Council есть даже отдельный стандарт PA DSS, который регламентирует требования к тиражируемому программному обеспечению. Вот только большинство компаний в моей практике, будь то США, Британия или Китай, которые проходили аудит PCI DSS не имели планов по тиражированию и продаже ПО. Более того, компании специально вносят ряд изменений в ПО используемое в рамках определенного проекта, чтобы не проходить аудит PA DSS, если это ПО внедряется на заказ. Потому не всегда выполнение требований стандарта и прохождение сертификации желанно и оправдано.

Общие разделы стандарта PCI DSS.

Будучи разработчиком, я выработал в себе привычку читать доки и мануалы систематически и в большом объеме. Сейчас я руковожу отделом iOS разработки в Cardsmobile и практически не пишу код, но привычка осталась. Статей про менеджмент написано не меньше, чем по программированию. И начитавшись публикаций на очередную такую тему, я кое-что понял: зря я не читал их, пока активно кодил. Ведь в моей команде всегда есть как минимум один менеджер и хорошо было бы разбираться в том, что он делает. Хотя бы немного. Ведь если он делает свою работу плохо, то лучше подыскать нового?       

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

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

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

Когда ты молод, ты «бессмертен» и не задумываешься о старости. Есть просто уверенность, что если много и хорошо работать, то твоя карьера и доходы будут неуклонно расти. Следуя этой стратегии, ты развиваешься в профессии уже 15, 20, 30 лет. За эти годы уже получил огромный опыт и, наверное, он обязательно поможет безбедно и интересно прожить остаток дней. Но все не так просто. Да, ты уже давно работаешь в хорошей компании, занимаешься интересными проектами, получаешь за это достойную зарплату, но в будущем уже не так уверен, как раньше. Профессиональный возраст приходит с массой вопросов, на которые нужно ответь стратегически.

 Эта статья родилась на основе обсуждения горячей темы «Олды в ИТ», которую 4 января 2021 г. мы записали для подкаста Linkmeup. Обязательно послушайте запись здесь или в любимом подкаст-приложении.

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

В большинстве случаев вся enterprise разработка сводится к выполнению одних и тех же требований: создается заявка, в зависимости от типа заявки у нее есть какой-то жизненный цикл, по завершению жизни заявки мы получаем (…или не получаем) желаемое. Под заявкой мы можем подразумевать все что угодно, начиная с покупки в интернет-магазине товара, денежного перевода или расчета траектории баллистической ракеты. У каждой заявки есть свой жизненный путь и что важно отметить - время жизни, и чем меньше это время, тем лучше. Иными словами, чем быстрее мой банковский перевод осуществится, тем лучше. Требования тоже схожи, побольше RPC operations per second, поменьше Latency, система должна быть отказоустойчивой, масштабируемой и должна быть готова вчера. Есть миллион инструментов, сотни баз данных, различные подходы и паттерны. И все уже давно написано, нам остается лишь правильно использовать готовые технологии в наших проектах. 

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

Эта статья не является ответом на множество вопросов по базам данных (БД) и системам управлениям базами данных (СУБД). Я как автор выражаю своё собственное мнение о  трендах, стараясь опираться на беспристрастные показатели, статистики и т.д., но для примера приводя собственный опыт. Я не являюсь ангажированным представителем какой-либо компании и выражаю точку зрения опираясь на опыт более 25 лет работы с разными СУБД, в том числе, которую создавал своими руками. Не так много даже опытных программистов и архитекторов, которые знают все термины, технологии, какие подводные камни и куда идёт движение. Тема поистине огромная, поэтому в рамках одной статьи не раскрыть даже верхний уровень информации. Если кто-то не встретит свою любимую СУБД или её невероятный плюс, который стоит упомянуть, то прошу в комментариях указать и этим дополнить общую картину, что поможет другим разобраться и понять лучше предметную область. Поехали!

Open Source DBMS vs Commercial DBMS

 Для начала приведён график с сайта, db-engines.com, по моим ощущениям, неплохо отслеживающим тренды БД. Именно этот график добавил желания написать статью о текущем положении дел.

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

Я второй десяток лет участвую в разработке приложений для бизнеса на .NET и каждый раз вижу одни и те же проблемы — быдлокод и беспорядок. Месиво из сервисов, UoW, DTO-шек, классов-хелперов. В иных местах и прямой доступ в базу данных руками, логика в статических классах, километровые портянки конфигурации IoC.

Когда я был молодым и резвым мидлом — я тоже так писал. Потом бил кулаком в стену с криками: "Хватит! В следующий раз сделаю по-другому". Следующий раз действительно начинался "по-другому" — с холодной головой и строгим подходом к архитектуре — а на выходе все равно получалась та же субстанция, лучше на пару миллиметров.

Однако, эволюция — беспощадная штука: моя последняя система показалась мне более-менее близкой к идеалу. Сложность не сильно росла, скорость разработки не падала довольно долго, в систему худо-бедно въезжают новые сотрудники. Эти результаты я взял за основу, улучшил и теперь анонсирую вам свою новую разработку: Reinforced.Tecture.

В этой статья я хочу поделиться опытом использования open source систем Zabbix и Grafana для визуализации работы производственных линий. Информация может быть полезна тем, кто ищет быстрый способ визуального отображения или аналитики собранных данных в проектах промышленной автоматизации или IoT. Статья не является подробным руководством, это скорее концепция системы мониторинга, основанная на открытом программном обеспечении для производственного предприятия.

Повторяться, но каждый раз по-новому – разве не это есть искусство?

Станислав Ежи Лец, из книги «Непричёсанные мысли»

• поддержку резервной базы данных на случай потери основной;
• снижение нагрузки на базу за счёт переноса части запросов на реплики;
• перенос данных в архивные или аналитические системы.

^{Примечание переводчика. Никита Попов внёс и продолжает вносить огромный вклад в развитие языка PHP. Он очень хорошо понимает внутренности движка PHP и в данной статье он объясняет некоторые особенности работы PHP в плане порядка вычисления выражений, которые, пожалуй, особо нигде и не найти. Этой статье около 7 лет и она практически не потеряла актуальность, однако найти её довольно сложно, потому что её нет в блоге Никиты Попова, а она опубликована в его gist-ах на гитхабе. Думаю полезно будет представить её сообществу на русском языке.}

В своём любимом сообществе lolphp на реддит я наткнулся на пост, где люди удивляются результату следующего кода:

<?php

$a = 1;
$c = $a + $a++;
var_dump($c); // int(3)

$a = 1;
$c = $a + $a + $a++;
var_dump($c); // int(3)

Как вы видите, выражения ($a + $a++) и ($a + $a + $a++) дают одинаковый результат, что довольно неожиданно. Что же здесь происходит?