Как считать хиты страницы google.com? А как хранить счётчик лайков очень популярных пользователей? В этой статье предлагается рассмотреть решение этих задач с помощью CRDT (Conflict-free Replicated Data Types, что по-русски переводится примерно как Бесконфликтные реплицированные типы данных), а в более общем случае — задачи синхронизации реплик в распределённой системе с несколькими ведущими узлами.

Представляем вам перевод статьи Simon Holdorf, опубликованной на сайте medium.com. В ней вы найдете ссылки на полезные репозитории, с помощью которых можно прокачать навык разработки ПО.


Фото с ресурса Unsplash. Автор: Vishnu R Nair

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

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

Государства вмешиваются в некогда гиковскую информационную область всё больше и устанавливают там правила. Один из институтов государственного регулирования в информационном пространстве — механизм «квалифицированной электронной подписи», условно неподделываемого доверенного идентификатора субъекта, которым он может заверять различного рода сделки в электронном виде от своего имени в инфопространстве. На самом деле, идея ЭП не нова и развивается давно, но в России в какой-то момент что-то пошло немного не так. Эта статья — субъективное пространное рассуждение на тему института электронной подписи в России без излишнего погружения в технологическую матчасть. Ну и немного хейта, как же без этого.


CC-BY-SA, Vadim Rybalko

Я уже 12 лет создаю различные веб-сервисы и мобильные приложения. И миллион раз я советовал людям делать MVP. Но я чувствую, что нужно быть очень осторожным с этим советом, нужно допускать множество оговорок, когда даешь этот совет и объяснять, что же такое "M" и "V" в этой аббревиатуре.

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

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

Недавно я натолкнулся на интересную работу итальянских учёных о сильно недооценённой роли удачи и случайности в нашей жизни. К сожалению, не нашёл полной версии на русском языке (может, плохо искал?), но очень уж хотелось поделиться прочитанным со своими не владеющими английским товарищами. Поэтому, засучив рукава, принялся за свой кустарный перевод. Авторы, Алессандро, Алессио и Андреа, любезно разрешили опубликовать его в общем доступе, поэтому, если заинтересовались, добро пожаловать под кат.

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

Каждый в IT-индустрии знает, насколько сложно оценить срок выполнения проекта. Трудно объективно оценить, сколько времени займёт решение трудной задачи. Одна из моих любимых теорий заключается в том, что здесь имеет место просто статистический артефакт.

Предположим, вы оцениваете проект в 1 неделю. Предположим, есть три одинаково вероятных результата: либо он займёт 1/2 недели, либо 1 неделю, либо 2 недели. Медианный результат фактически такой же, как и оценка: 1 неделя, но среднее значение (aka average, aka expected value) составляет 7/6 = 1,17 недель. Оценка фактически откалибрована (беспристрастна) для медианы (которая равна 1), но не для среднего.

Некоторое время назад на Quora я отвечал на вопрос: как успевать записывать за лектором конспект по математике на LaTeX. Там я объяснил свой рабочий процесс по конспектированию в LaTeX с помощью Vim и Inkscape (для рисунков). Но с тех пор многое изменилось, так что я хочу опубликовать несколько постов в блоге с описанием нового процесса. Это первая из статей.

Я начал использовать LaTeX для конспектирования во втором семестре курса математики, и с тех пор написал более 1700 страниц. Вот несколько примеров, как выглядит конспект:

Мысленный эксперимент

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

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

Вот это устройство UNIX FIT MX-450V, или кратко – *ЮНИКС, на котором и осуществляется процесс программирования.

Вообще, всё вместе это 1001-е выступление на тему «о правильном рабочем месте программиста». Все составные части девайса многократно описаны в литературе, никаких революционных свершений не предлагается, зато приведен в целом успешный опыт инсталляции и использования. Устройство классическое – подъёмный стол и под ним беговая дорожка. Фотки – частично из сети, частично из моей рабочей берлоги, заранее прошу прощения за невысокое качество – условия тотальной захламленности + убогое освещение + я, увы, не фотограф совсем. Под катом – множество подробностей, включающих вивисекцию невинных железочек с элементами колхоза.

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

Введение

Алгоритм был написан как часть работы на получение степени бакалавра и основан на статье Ma et al (2014). Целью работы было ускорение алгоритма и дополнение его новыми функциями. Я вполне доволен результатом, потому что мы сделали алгоритм достаточно быстрым, чтобы использовать его во время выполнения игры. После завершения бакалаврской работы мы решили превратить её в статью и отправить на конференцию Game-ON 2018.

Алгоритм

Для создания уровня игры алгоритм получает в качестве входных данных набор полигональных строительных блоков и граф связности уровня (топологию уровня). Узлы графа обозначают комнаты, а рёбра определяют связи между ними. Цель алгоритма — назначить каждому узлу графа форму и расположение комнаты таким образом, чтобы никакие две формы комнат не пересекались, и каждая пара соседних комнат могла соединяться дверьми.

Многие слышали о мультиклеточной архитектуре, процессорах и даже первых устройствах на них. Особенно продвинутые пользователи опробовали свои алгоритмы. Были проведены первые простые тесты производительности, а также пользователь Barsmonster, вытравил кристалл процессора Р1. Сейчас уже проходит первые проверки процессор R1 и скоро будет доступен всем. Но ответ на вопрос о том, как работает мультиклеточная архитектура и в чём её отличие, знают не все. Попытаемся сейчас ввести в курс дела.

Хранение паролей всегда было головной болью. В классическом варианте у вас есть пользователь, который очень старается не забыть жутко секретный «qwerty123» и информационная система, которая хранит хеш от этого пароля. Хорошая система еще и заботливо солит хеши, чтобы отравить жизнь нехорошим людям, которые могут украсть базу с хешированными паролями. Тут все понятно. Какие-то пароли храним в голове, а какие-то засовываем в зашифрованном виде в keepass.

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

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

Есть много обстоятельств, которые могут быть катализаторами создания плохого ПО: используемые инструменты, качество коммуникаций в команде, персональные качества разработчиков, методологии и т.д. И есть среди них одна вещь, которая является корнем почти всех остальных: воображаемые проблемы.

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

История о подкастах

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

И вот вы решаете нанять людей, которые сделают для вас этот сайт. Вы пишете для них абсолютно чёткие требования:

• Быстрая загрузка сайта в Северной Америке
• Поддержка загрузки прошлых выпусков подкастов и трансляции в реальном времени текущих
• Трансляция не должна падать или замирать в течении первых 15 минут для 99.99% пользователей. Желательно вообще никогда, но хотя бы так.
• Интеграция с Google Adwords (а в будущем, возможно, и с аналогами)
• Интеграция с трансляциями Facebook, поскольку там вы проводите свои передачи. Если можно создать альтернативное решение, которое будет позволять стримить более удобно — ещё лучше.

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

Сеть Ethereum, широко известная в узком кругу блокчейн-разработчиков, уже зарекомендовала себя как удобная и стабильная платформа для разработки смарт-контрактов. Мы стараемся сделать смарт-контракты доступными для неподготовленных пользователей, предлагая простые, но практически полезные контракты. Недавно мы разработали смарт-контракт спора Bet Me. В основе контракта лежит пари (спор) двух оппонентов. Они подкрепляют уверенность в собственной правоте денежной ставкой. Проигравший теряет деньги, а победитель забирает всё. Подробнее о нём я расскажу в этой статье.

(для понимания того, о чём говорится в этой статье, необходимо и достаточно хотя бы в общих чертах представлять, что такое асимметричная криптография и как работает электронная подпись)

Сценарий использования одноразового секретного ключа:

1. Создаётся ключевая пара, состоящая из секретного (secret key, SK) и открытого (public key, PK) ключей.
2. При помощи секретного ключа выполняется ряд операций. Первая из них, создание открытого ключа, уже выполнена на первом шаге.
3. Выполняется на первый взгляд противологичное действие – секретный ключ уничтожается без возможности восстановления.

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

Идея управляемых токенами реестров (TCR) зародилась в блокчейн-сообществе не менее года назад. По крайней мере, эта статья была опубликована автором еще в сентябре 2017 года. А недавно я был на конференции DappCon 2018 в Берлине и увидел большой интерес к этой теме, а также несколько ранних набросков на основе TCR. Поэтому предполагаю, что пик интереса еще впереди.

Мне TCR-контракты представляются крайне интересными, поскольку они являют собой пример наиболее простой замкнутой системы, управляемой децентрализованно и на основе экономических стимулов. Если немного пофантазировать, становится понятно, что на основе этой идеи можно децентрализовать очень многое, возможно даже всё в нашей социально-экономической жизни. И это уже не просто галлюцинации сумасшедших криптанов, а вполне неплохо сформулированный протокол. Более подробно читайте под катом.

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

— Саш, очевидно, работа не приносит тебе удовольствия, — Слава проговаривал бесспорные вещи. Четвертую неделю вместо работы я мчался на очередной детский турнир по футболу. Когда у тебя трое детей, можно 120% своего времени занять их увлечениями. — У меня есть к тебе предложение. Давай отправим тебя в отпуск на год? Я за это время закрою собой бизнес. Доходы, по-прежнему, пополам. Потом ты вернешься с новыми силами, и, может быть, я на год в отпуск схожу.

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