В отличие от распространенной "клиент-серверной" архитектуры, для децентрализованных приложений характерно:

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

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

Учитывая все это, мы захотели сделать максимально безопасное расширение, которое упрощает разработку децентрализованных приложений, предоставляя простой API для работы с транзакциями и подписями.
Об этом опыте мы вам и расскажем ниже.

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

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

Добро пожаловать!

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

Статьи цикла:

1. Обзор материалов и литературы по NAS. По предложениям пользователей ссылки на материалы будут сведены в отдельную статью.
2. Выбор железа. Описан один из вариантов выбора железа и дан краткий обзор рынка домашних и офисных NAS систем.
3. Установка ОС, на которой будет строиться NAS. В отдельной статье описано дополнение, позволяющее отказаться ото всех файловых систем, кроме ZFS.
4. Проектирование поддерживающей инфраструктуры, которая будет лежать в основе всех сервисов NAS.
5. Реализация поддерживающей инфраструктуры.
6. Механизм аварийной удалённой разблокировки. Требуется для того, чтобы разблокировать систему, не имея к ней физического доступа.
7. Повышение защищённости NAS. Исправление ошибок, допущенных в предыдущих статьях и описание Hardening процесса.
8. Система контроля версий на базе Git. Установка Gitlab в контейнере.
9. Система резервного копирования. От регламента до установки ПО, где в качестве примера используется UrBackup.
10. Персональное облако. Обеспечивает хранение персональных файлов пользователя, обмен файлами между пользователями, а также интеграцию различных сервисов между собой.
11. Сквозная аутентификация контейнеров.
12. Управление файлами.
13. Библиотека.
14. Мультимедийная система 1: музыка.
15. Мультимедийная система 2: медиа сервер.
16. Фронтенд. Интерфейс, позволяющий быстро обращаться к сервисам.
17. Заметки про управление контейнерами.

Зачем всё это?

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

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

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

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

• Низкочастотные (Low Frequency: 125 кГц) — имеют большую дальность чтения. Небезопасные и тупые. Используются в примитивных системах контроля доступа: домофонах, офисных пропусках, абонементах в спортзал.
• Высокочастотные (High Frequency: 13,56 МГц) — имеют меньшую дальность работы по сравнению с низкочастотными, и могут иметь сложные протоколы, средства шифрования, аутентификации, криптографии. Используются в бесконтактных банковских картах, проездных билетах, безопасных пропусках.

В первой части я попытался показать, что черная кошка ООП в темной комнате графических языков существует, даже если это не кошка, а полудохлый кот живодера Шредингера, который то есть, то его нет. Был показан пример реализации методологии объектно-ориентированного программирования, когда программа – это не код на языке С++ или Java, а диаграмма Simulink, SimInTech, SimulationX или SCADE Esterel, — любая графическая нотация описания алгоритма.

В рекламных материалах Мatlab Simulink часто используют термин МОП — Модельно Ориентированное Проектирование (Model-based design). Во многих текстах они подчёркивают, что графическая схема алгоритма это модель, что, конечно, верно. Однако в первоначальном определении МОП, модель – это прежде всего модель объекта, к которому разрабатывают систему управления, включая управляющее программное обеспечение. Подробнее методолгия МОП описана здесь. Таким образом, разрабатывая систему управления по методологии МОП можно и нужно использовать методологию ООП для разработки управляющего ПО. И что бы окончательно закрыть вопрос с моделями, вот вам картинка с отличиями одного от другого. Если все понятно, то можно дальше не читать.

Очень давно я занимался проектами внедрения ЕРП-систем, в роли техлида (тогда это называлось «технический руководитель проекта»). В Челябинской области много производственных предприятий, и часто приходилось ездить на переговоры в сопровождении очень опытной женщины-менеджера.

Однажды она сказала: приходя на предприятие, надо первым делом идти в туалет. Именно по туалету можно очень многое понять о руководстве и его отношении к бизнесу. В первую очередь – о том, мыслит ли оно долгосрочными перспективами, видит ли себя тут надолго, или просто рубит бабло по-быстрому. В те, ещё немножко бешеные годы, пожалуй, доля истины в «туалетном знакомстве» была.

Ритуал соблюдался строго. Менеджер приезжала на встречу и говорила, что сначала надо «припудрить носик». Посещала туалет, осматривала, формировала первичное мнение и шла на переговоры.

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

И он меня поразил.

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

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

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

Карьерные советы - почти бесполезная вещь. С учетом 160 миллионов американцев, занимающих должности в тысячах организаций в сотнях индустрий, высказать что-то, что будет иметь практическую полезность для них всех, - невозможно на практике. Даже самые базовые советы зачастую оказываются слишком личными, чтобы получить повсеместное признание. Мне становится неловко, когда я слышу от успешных людей что-то вроде: "Просто последуйте моему примеру и сделайте эти три вещи". Автобиография - не совет. Учитывая, насколько плохо большинство людей понимает себя, все это даже нельзя назвать автобиографией.

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

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

1. Это офигеть как сложно!

Я работаю удалёнщиком с 2019 года, когда о предстоящем пандемийном безумии ещё никто не подозревал. «Ха» - скажете Вы, глядя свысока событий, произошедших совсем недавно. Да, тогдашние мои проблемы не идут ни в какое сравнение с нынешней ситуацией, но именно тогда всё для меня и началось.

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

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

* Определить свою мотивацию, нишу и специализацию

* Нужно ли профильное высшее образование.

И еще больше десятка пунктов личного рецепта, не только для Java разработчиков... Надеюсь, что эти советы помогут вам стать востребованным и хорошо оплачиваемым специалистом!

Сейчас я расскажу, сколько будет стоить разработать и произвести пластиковый корпус для устройства, от 1 до 200 000 штук. Все максимально по делу — в сад лирику, только слайды цифры.