В статье рассмотрим четыре способа создания собственного VPN. Начнем с самого простого варианта, что под силу даже начинающим пользователям ПК.

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

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

Когда спрашиваю у людей на собесах, или когда в команде решаем, как клепать очередной проект, такое порой слышу, что становится страшновато. Мне кажется, лет через 5 все компании будут обитать в мультивселенной безумия из “микросервисов”, которую они себе радостно построили, уходя от этих ваших страшных “монолитов”.

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

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

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

Так при чем тут "культурный контракт"? Все просто, при приеме каждого сотрудника моя первая беседа с ним была на основе тезисов:

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

В статье разберем особенности аутентификации применительно к протоколу WebSocket и технологии Server-Sent Events, обсудим, какие нюансы могут быть, когда клиентская часть находится в браузере, и на что еще стоит обратить внимание, чтобы избежать неочевидных проблем.

А еще заодно поговорим про уязвимость Cross-Site WebSocket Hijacking (CSWSH) и в целом посмотрим на многие вопросы через призму информационной безопасности.

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

Всю прошлую неделю проходила квалификация на Yandex Cup 2023. Я решил тряхнуть стариной и вспомнить что такое спортивное программирование.

Яндекс представил 8 задачек разной сложности, которые необходимо сделать за пять часов. Я принял участие. На старте был уверен в себе. Однако, получил плохие результаты. Следующие пол дня я чувствовал уныние и разочарование. Потом пришла идея, как это использовать.

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

Завариваем чаек, я начинаю.

В одном из своих предыдущих постов под названием "Эйлер, Чёрч и Мандельброт — этюд о красоте и математике" я немного затронул тему рассмотрения функционального программирования в качестве основы реальности. Под тем постом было оставлено множество интересных комментариев, один из которых, написанный @nickolaym, вдохновил меня на развитие мысли в данном направлении. Так появился этот пост, в котором прямо как во времена пифагорейской школы и платоновской академии философия переплелась с математикой, а математика с философией.

Мы так привыкли к типам, что редко задаёмся вопросом, что же они такое на самом деле? А главное - почему возникла необходимость в их использовании? Этот поверхностный обзор сделан для того, чтобы продемонстрировать, как типы и другие связанные абстракции являются следствием из обобщения условий различных задач.

Если вы не специалист по REST, то, вероятно, в своих ответах постоянно используете одни и те же HTTP-коды, в основном 200, 404 и 500. Если применяется аутентификация, то, возможно, добавляются 401 и 403; если есть переадресации, то 301 и 302, но на этом, скорее всего, список заканчивается. Но спектр возможных кодов состояний гораздо шире и он может сильно улучшить семантику. Хотя во многих обсуждениях REST упор делается на сущностях и методах, применение подходящих кодов ответов о состояниях может повысить удобство вашего API.

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

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

Привет, человек, %хабраюзер%, %юзернейм%, программист.

Этот пост является оплотом ненависти. Так уж вышло. Но тебе, как программисту пора перестать оправдываться.

Представляю вашему вниманию перевод статьи The Magical Methods in C# автора CEZARY PIĄTEK.

Есть определенный набор сигнатур методов в C#, имеющих поддержку на уровне языка. Методы с такими сигнатурами позволяют использовать специальный синтаксис со всеми его преимуществами. Например, с их помощью можно упростить наш код или создать DSL для того, чтобы выразить решение проблемы более красивым образом. Я встречаюсь с такими методами повсеместно, так что я решил написать пост и обобщить все мои находки по этой теме, а именно:

• Синтаксис инициализации коллекций
• Синтаксис инициализации словарей
• Деконструкторы
• Пользовательские awaitable типы
• Паттерн query expression

Всем привет!

Меня зовут Коля, и я периодически собеседую кандидатов на позицию системного аналитика. За последние два месяца провёл порядка 20 десятков собеседований. В основном были кандидаты с опытом 1.5-3 года, на пути к уровню Middle и с зарплатными ожиданиями 150-200 тысяч рублей в месяц.

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

Фрейморк Scrum в представлении не нуждается, и его преимущества многократно описаны. Однако о недостатках подхода говорят реже, и успешно применять его получается далеко не у всех. Зачастую после первых неудач команда разочаровывается в подходе и начинает считать его полностью бесполезной пустышкой. Но может быть дело не в самом Скраме, а в том, где и как его применили?

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

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

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

Подобная статья должна была появиться раньше, лет десять или пятнадцать назад, когда Agile только начинал внедряться в ИТ-компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, , если бы менеджеры сразу подходили к вопросу правильно, не отвлекаясь на лишние действия …

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