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

Сергей Семёнов считает, что это происходит в основном по двум причинам.

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

И предлагает подход к оценке и контролю процессов на основе объективных данных.

Ниже видео и текстовая версия доклада Сергея, который по результатам зрительского голосования занял второе место на Saint TeamLead Conf.

Введение

Angular предоставляет удобный декларативный способ подписки на события в шаблоне, с помощью синтаксиса (eventName)="onEventName($event)". Вместе с политикой проверки изменений ChangeDetectionStrategy.OnPush подобный подход автоматически запускает цикл проверки изменений только по интересующему нас пользовательскому вводу. Иными словами, если мы слушаем (input) событие на <input> элементе, то проверка изменений не будет запускаться, если пользователь просто кликает по полю ввода. Это значительно улучшает
производительность, по сравнению с политикой по умолчанию (ChangeDetectionStrategy.Default). В директивах мы также можем подписаться на события на хост-элементе через декоратор @HostListener('eventName').

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

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

Несколько десятилетий назад профессор Университета Эссекса Ричард Алан Бартл придумал модель сегментации игроков по психологическим типам. Сегодня её используют разработчики игр во всем мире, в том числе и в Mail.Ru Group. Например, психотипы Бартла применяются в социальных сетях для оптимизации каталога игр под каждого пользователя. Так что же придумал этот замечательный человек?

30 лет назад Бартл написал одну из первых многопользовательских игр — MUD (Multi-User Dungeon), по имени которой теперь называют целый жанр. Фактически, это прародитель всех современных ММО. Вот такая замечательная консольная текстовая игра:



То, на что опирается Бартл, — это программный код игры, распечатанный для защиты научной работы.

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

Этой осенью Яндекс.Маркету исполняется 18 лет. Все это время развивается партнерский интерфейс Маркета. Если кратко, то это админка, с помощью которой магазины могут загружать каталоги, работать с ассортиментом, следить за статистикой, отвечать на отзывы и т.д. Специфика проекта такова, что приходится очень много взаимодействовать с различными бэкендами. При этом данные не всегда можно получить в одном месте, из одного конкретного бэкенда.

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

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

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

Привет! Я хотел бы поделиться опытом написания шейдеров в Unity. Начнем с шейдера искажения пространства (Displacement/Refraction) в 2D, рассмотрим функционал, используемый для его написания (GrabPass, PerRendererData), а также уделим внимание проблемам, которые обязательно возникнут.

Информация пригодится тем, кто имеет общее представление о шейдерах и пробовал их создавать, но мало знаком с возможностями, которые предоставляет Unity, и не знает с какой стороны подступиться. Загляните, возможно, мой опыт поможет вам разобраться.

Прошло уже достаточно времени с выхода обновленного Angular. В настоящее время множество проектов завершено. От "getting started" множество разработчиков уже перешло к осмысленному использованию этого фреймворка, его возможностей, научились обходить подводные камни. Каждый разработчик и/или команда либо уже сформировали свои style guides и best practice либо используют чужие. Но в тоже время часто приходится сталкиваться с большим количеством кода на Angular, в котором не используются многие возможности этого фреймворка и/или написанного в стиле AngularJS.

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

Не так давно в тематической группе инди-разработчиков игр я встретил интересное сообщение:

Ладно, ребята, у меня есть идея… И нет, Я НЕ ИДЕЯ-ПАРЕНЬ… Большинство из вас используют разный набор информационных ресурсов, таких как Ludum Dare, Gamedev.net, Indie Game Developers (и другие группы Facebook), Unity Connect, IndieDb, Itch.io, Game Jolt и т.д. Что, если бы мы могли объединиться, чтобы создать централизованное место, где вы могли бы остаться, чтобы обмениваться информацией о геймдеве или быть перенаправленным на внешний ресурс, упомянутый выше?

НЕТ, я не хочу по типу 50-на-50, а вы делаете всю работу. Я уже делаю это! Совершенно точно! С вами или без вас, ребята. Я мог бы лишь использовать некоторую помощь сообщества разработчиков игр.

Так в чем же суть IndieVisible?

О чем исследование


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

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

ХАБРО-WARNING !!! Уважаемые хабровчане, это не развлекательный пост.
Спрятанные под катом 40+ страниц материалов призваны помочь в работе или учебе людям, специализирующимся на банковском деле или обеспечении информационной безопасности. Данные материалы являются конечным продуктом исследования и написаны в сухом официальном тоне. По сути это заготовки для внутренних документов по ИБ.

Ну и традиционное — «применение сведений из статьи в противоправных целях преследуется по закону». Продуктивного чтения!

Алексей Бородкин, product lead и глава Гильдии вольных проектировщиков, рассказал на открытом занятии Нетологии, как разобраться в дизайнерских направлениях и распределить роли в дизайн-команде.

Дизайнерские тусовки

Когда-то — в буйные 90-е — никаких веб-дизайнеров не было, и сайты создавали вебмастера — отважные люди с программистским бэкграундом, которые все делали сами: собирали требования, кодили, рисовали, делали контент и развивали сайт.

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

Я работаю с контекстной рекламой достаточно давно. И ещё веду курсы для новичков по работе с Я.Директ. Некоторым из них повседневные приёмы кажутся крутыми «фишками». Возникла идея поделиться некоторыми из них в этой короткой статье.

В наши дни веб-сервисы постоянно подвергаются самым разным атакам. Поэтому безопасность — это то, о чём стоит помнить на всех этапах жизненного цикла проектов. Авторы материала, перевод которого мы сегодня публикуем, поддерживают репозиторий на GitHub, содержащий около 80 рекомендаций по обеспечению безопасности приложений, работающих на платформе Node.js. В этом материале, базой для которого послужило множество публикаций, посвящённых безопасности, собрано более двух десятков рекомендаций, касающихся Node.js, и некоторые советы общего характера. При этом данный материал покрывает топ-10 уязвимостей из списка проекта OWASP.