Недавно на рынке появилось достаточно много боксов на свежей SoC от Amlogic — S905X2. Все они дешёвые, «холодные» прямо из коробки, имеют неплохие технические характеристики, но все проблемные в той или иной степени. Те, кто читает мои обзоры боксов, знает, что если ваши требования выше «включается и как-то показывает видео», а бюджет существенно ограничен, то к выбору бокса нужно подходить очень аккуратно. Скоро у меня будет единый детальный обзор нескольких актуальных боксов на S905X2 (не все ещё прилетели). Ну, а сегодня я расскажу вам детально об одном боксе — Mecool KM9. Самое важное отличие от своих собратьев состоит в том, что он поставляется с системой Android TV 8.1 и Bluetooth-пультом.

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

День добрый,
Меня зовут Владимир Ерёмин, я работаю в компании Veeam Software на позиции product manager. Одной из вверенных мне областей является PowerShell оснастка к нашему продукту Veeam Backup and Replication, и именно о работе с оной и пойдет речь далее.

Вопрос ограничения доступа к данным встает при разработке многопользовательских систем почти всегда. Основные сценарии следующие:

1. ограничение доступа к данным для пользователей не прошедших аутентификацию
2. ограничение доступа к данным для аутентифицированных, но не обладающих необходимыми привелегиями пользователей
3. предотвращение несанкционированного доступа с помощью прямых обращений к API
4. фильтрация данных в поисковых запросах и списковых элементах UI (таблицы, списки)
5. предотвращение изменения данных, принадлежащих одному пользователю другими пользователями

Сценарии 1-3 хорошо описаны и обычно решаются с помощью встроенных средств фреймворков, например role-based или claim-based авторизации. А вот ситуации, когда авторизованный пользователь может по прямому url получить доступ к данным «соседа» или совершить действие в его аккаунте случаются сплошь и рядом. Происходит это чаще всего из-за того что программист забывает добавить необходимую проверку. Можно понадеяться на код-ревью, а можно предотвратить такие ситуации применив глобальные правила фильтрации данных. О них и пойдет речь в статье.

Продолжаю цикл статей по анализу продукта (начало)

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

Теперь общая схема анализа выглядит так:

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

Здравствуй (Это важно!) уважаемый читатель.

Если, читая эту статью, ты приложил руку к лицу и согнул спину – то в этой статье ты можешь взглянуть на свое возможное будущее. Моя болезнь развивалась скорее по травматическому сценарию, за 3-4 месяца сильно деформировалась поясница, а далее, как карточный домик деформировался весь позвоночник, за год, я познакомился с проблемами в каждом суставе: от коленки до 1-ой кости позвоночника после которой спинной мозг переходит в головной.
Патологии позвоночника имеют одну уникальную особенность, которой нет ни у одной другой болезни. Любая патология позвоночника – очень тяжелая… В прямом смысле – масса костей человека около 15 кг., и любая проблема в суставе имеет большой физический размер и очень часто проблему в суставе можно пощупать пальцами, а современные средства диагностики, позволяют даже заглянуть внутрь (МРТ, Рентген). Поэтому вряд ли у человека есть такой же орган, с настолько же понятными функциями и простотой наблюдения как позвоночник.

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

«Чего-то здесь не хватает». Спорим, такая мысль первой придёт в вашу голову, если увидите моё рабочее место в офисе. Здесь нет монитора и мыши. Есть только парень, который молотит по клавиатуре, глядя словно в пустоту.



Это всего лишь я, и мои коллеги гарантируют вам, что я обычно не опасен. Я программист в офисе компании Vincit в Тампере (Финляндия). И ещё я слепой. В этой статье хочу немного рассказать, как я работаю.

Продолжаем переводить крутые статьи с сайта Bytecoin.org. Сегодня — «Alternatives for Proof of Work, Part 1: Proof Of Stake» Рэя Паттерсона (Ray Patterson).
Также читайте перевод «Краткой истории эволюции proof-of-work в криптовалютах»: часть 1 и часть 2.

Критика Proof of Work

Как мы все помним, Proof of Work родился в далеком 1993 году в семье криптографов; родители прочили ему карьеру защитника от DoS и спама. Однако в 2008 году ему поступило заманчивое предложение от некоего анонима с япоским акцентом: стать основой для распределенного сервера меток времени. Схема представлялась простой: узлы сети «голосуют» за свою версию истории транзакций, вкладывая свои мощности в вычисление «редких» хешей. Версия, получившая большинство голосов, принимается другими узлами в качестве эталонной.

Важным моментом было обеспечение большой суммарной мощности сети: для защиты от потенциального злоумышленника с его потенциальными 51% ресурсов. Однако изначальная концепция PoW подразумевала небольшие задания, которые должен выполнить клиент, чтобы получить доступ к ресурсам сервера. В рамках такой модели защиты от DoS даже небольшие мощности клиента не помешают добропорядочному использованию ресурса, а большие просто не требовались. Поэтому мотивация для работы майнеров была реализована просто: «натурой», биткоинами, т.е. фактически деньгами.

И это все изменило.

Автор: Вячеслав Михайлов, Solutions Architect

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

Мы разберемся с процессом аутентификации пользователя, работой технологии единого входа (Single sign-on/SSO), дадим общее представлении о технологии OAuth2 и принципах ее работы, не углубляясь в особенности конкретной технической реализации. В следующей статье в качестве примера удачной реализации мы рассмотрим библиотеку Thinktecture Identity Server v3, подробнее остановимся на ее функциональных возможностях, поговорим, как собрать минимальный набор компонент, необходимый для работы в микросервисной архитектуре и достойный использования в боевой системе. В третьей части мы покажем, как расширять эту библиотеку, подстраиваясь под нужды вашей системы, а завершит цикл статей разбор различных сценариев, встречавшихся в жизни многих разработчиков с рекомендациями для каждого случая.

День добрый, коллеги!

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

GCTD — Getting Creative Things Done.

Началось это несколько недель назад. Мне нужно было написать исследовательский отчет, предстояла важная, неоднозначная, трудная задача. В первую неделю я повторял себе, что на данный момент это моя наиважнейшая задача и обращался к ней при первой же возможности. Я постоянно чувствовал вину за то, что недостаточно времени уделяю написанию отчета. В одну из ночей в конце недели я заперся в офисе до 9 утра, уже совсем отчаявшись привести дела в порядок. Результат работы оказался практически бесполезным. У меня получилось 15 страниц беспорядочного текста (исследовательский отчет должен быть максимум 3-5 страниц), и охватить предстояло еще многое. Работа была запутанная и «тонула» в прилагательных.