Мы в Badoo постоянно мониторим свежие технологии и оцениваем, стоит ли использовать их в нашей системе. Одним из таких исследований и хотим поделиться с сообществом. Оно посвящено Loki — системе агрегирования логов.

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

Предисловие

Я несколько раз в своих комментариях ссылался на книгу Эндрю Таненбаума «Operating Systems Design and Implementation» на ее первое издание и на то, как в ней представлен язык Си. И эти комментарии всегда вызывали интерес. Я решил, что пришло время опубликовать перевод этого введения в язык Си. Оно по-прежнему актуально. Хотя наверняка найдутся и те, кто не слышал о языке программировании PL/1, а может даже и об операционной системе Minix.

Это описание интересно также и с исторической точки зрения и для понимания того, как далеко ушел язык Си с момента своего рождения и IT-отрасль в целом.

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



→ Часть 1: обзор курса, причины популярности React, ReactDOM и JSX
→ Часть 2: функциональные компоненты
→ Часть 3: файлы компонентов, структура проектов
→ Часть 4: родительские и дочерние компоненты
→ Часть 5: начало работы над TODO-приложением, основы стилизации
→ Часть 6: о некоторых особенностях курса, JSX и JavaScript
→ Часть 7: встроенные стили
→ Часть 8: продолжение работы над TODO-приложением, знакомство со свойствами компонентов
→ Часть 9: свойства компонентов
→ Часть 10: практикум по работе со свойствами компонентов и стилизации
→ Часть 11: динамическое формирование разметки и метод массивов map
→ Часть 12: практикум, третий этап работы над TODO-приложением
→ Часть 13: компоненты, основанные на классах
→ Часть 14: практикум по компонентам, основанным на классах, состояние компонентов
→ Часть 15: практикумы по работе с состоянием компонентов
→ Часть 16: четвёртый этап работы над TODO-приложением, обработка событий
→ Часть 17: пятый этап работы над TODO-приложением, модификация состояния компонентов
→ Часть 18: шестой этап работы над TODO-приложением
→ Часть 19: методы жизненного цикла компонентов
→ Часть 20: первое занятие по условному рендерингу
→ Часть 21: второе занятие и практикум по условному рендерингу
→ Часть 22: седьмой этап работы над TODO-приложением, загрузка данных из внешних источников
→ Часть 23: первое занятие по работе с формами
→ Часть 24: второе занятие по работе с формами
→ Часть 25: практикум по работе с формами
→ Часть 26: архитектура приложений, паттерн Container/Component
→ Часть 27: курсовой проект

Привет, Хабр! Несколько месяцев назад у меня остро встал вопрос смены профиля деятельности и я обнаружил, что для претендента на вакансию web-разработчика сейчас недостаточно навыков десятилетней давности (какая неожиданность!). Пришлось срочно актуализировать свои знания. Заодно я решил составить шпаргалку с описанием большинства современных технологий, чтобы в случае чего кидать жаждущим новых знаний линк на эту статью, да и самому не забывать.

Швейцарцы принимают участие в референдуме о введении гарантированного базового дохода. Источник: Ruben Sprich / Reuters

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

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

Так повелось, что в процессе работы в МегаФоне, приходится сталкиваться с однотипными задачами при работе с RabbitMQ. Закономерно возникает вопрос: «Как упростить и автоматизировать выполнение таких задач?»

Первое решение, которое приходит в голову, использовать интерфейс HTTP, и, безусловно, из коробки RabbitMQ обладает хорошим веб-интерфейсом и HTTP API. Тем не менее, использование HTTP API не всегда удобно, а иногда и вообще невозможно (допустим у вас недостаточно прав доступа, а опубликовать сообщение ну очень хочется) в такие моменты возникает необходимость работы именно по протоколу AMQP

Не найдя подходящих мне готовых решений на просторах сети, было решено написать небольшое приложение для работы с RabbitMQ по протоколу AMQP

Привет всем!

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

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



Поисковики соответствующий запрос с упорной настойчивостью вопрос «где» конвертируют в ответ «как...», предлагая ноль информации. Результат дал запрос «markets for publishing mobile apps» на английском языке и, среди прочего, выдал отличную актуальную статью, которую, дабы не потерять и каждый раз не прыгать в Google translator, решил перевести и опубликовать основное здесь. Кроме всего, в статье довольно много интересной и полезной другой информации.

Итак «App Stores List 2018» с сайта businessofapps.com. Ну, то есть,

Список магазинов мобильных приложений 2018

Предположим, что заказчик попросил вас помочь с переносом скрипта для развертывания централизованного файла sudoers на серверах RHEL и AIX.



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

Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.

Существует два распространенных типа подключения DPI: пассивный и активный.

Пассивный DPI

Пассивный DPI — DPI, подключенный в провайдерскую сеть параллельно (не в разрез) либо через пассивный оптический сплиттер, либо с использованием зеркалирования исходящего от пользователей трафика. Такое подключение не замедляет скорость работы сети провайдера в случае недостаточной производительности DPI, из-за чего применяется у крупных провайдеров. DPI с таким типом подключения технически может только выявлять попытку запроса запрещенного контента, но не пресекать ее. Чтобы обойти это ограничение и заблокировать доступ на запрещенный сайт, DPI отправляет пользователю, запрашивающему заблокированный URL, специально сформированный HTTP-пакет с перенаправлением на страницу-заглушку провайдера, словно такой ответ прислал сам запрашиваемый ресурс (подделывается IP-адрес отправителя и TCP sequence). Из-за того, что DPI физически расположен ближе к пользователю, чем запрашиваемый сайт, подделанный ответ доходит до устройства пользователя быстрее, чем настоящий ответ от сайта.

Предупреждение: возможно уменьшение удовольствия от игр и фильмов, так как появится осознание и понимание как они устроены.

Как-то захотелось мне сделать игру и у меня возникли вопросы.
Почему мы играем? Из-за каких элементов игры мы получаем фан?

Далее, под словом «фан», имеется ввиду положительные эмоции.

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

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

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

Проделав этот эксперимент с играми в которые я играл, получился такой набор базовых элементов:

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

Источник: 1877 Harpers Weekly November 24-MA barely saves GOP [1]

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

Мы занимаемся поиском, а не итерациями

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

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

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

Такие «итерации» совсем непохожи на линейные изменения, которые обычно происходят в «итерациях» компьютерного кода; гораздо больше они напоминают поиск в лабиринте со множеством резких поворотов и вынужденных возвратов назад. Часто они приближают нас к цели, но часто оказывается непонятно, улучшилась ли от них игра. Иногда обнаруживается, что изменения дизайна, которые, по нашему мнению, должны были улучшить игру, имеют непредвиденные изъяны и нам нужно откатить них или попробовать заново.

Цикл статей “ монстропедия “ ч.2

Зачастую разработчики прибегают к простым решениям для создания иллюзии разнообразия противников в игре. Перекрасить монстра, поменять цвет пламени, натянуть новую шкурку на старую тварь и добавить шипов/рогов/зубов/лап, но известная фраза гласит “старого пса не научишь новым трюкам”

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

Вы разработчик, что делать?

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

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3
Лекция 2: «Контроль хакерских атак» Часть 1 / Часть 2 / Часть 3
Лекция 3: «Переполнение буфера: эксплойты и защита» Часть 1 / Часть 2 / Часть 3
Лекция 4: «Разделение привилегий» Часть 1 / Часть 2 / Часть 3
Лекция 5: «Откуда берутся ошибки систем безопасности» Часть 1 / Часть 2
Лекция 6: «Возможности» Часть 1 / Часть 2 / Часть 3
Лекция 7: «Песочница Native Client» Часть 1 / Часть 2 / Часть 3
Лекция 8: «Модель сетевой безопасности» Часть 1 / Часть 2 / Часть 3

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

Еще в далеком 1976 швейцарский ученый Никлаус Вирт написал книгу Алгоритмы + структуры данных = программы.

40+ лет спустя это уравнение все еще верно. И если вы самоучка и надолго в программировании пробегитесь по статье, можно по диагонали. Можно код кофе.

Доброго всем! Мы тут потихоньку начали исследовать новое совсем для нас направление для обучения — блокчейны и нашли то, что оказалось интересным в рамках нашего курса по Python, в том числе. Чем, собственно, и хотим поделиться с вами.

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

Для кого предназначена эта книга

«Apache Kafka. Потоковая обработка и анализ данных» написана для разработчиков, использующих в своей работе API Kafka, а также инженеров-технологов (именуемых также SRE, DevOps или системными администраторами), занимающихся установкой, конфигурацией, настройкой и мониторингом ее работы при промышленной эксплуатации. Мы не забывали также об архитекторах данных и инженерах-аналитиках — тех, кто отвечает за проектирование и создание всей инфраструктуры данных компании. Некоторые главы, в частности 3, 4 и 11, ориентированы на Java-разработчиков. Для их усвоения важно, чтобы читатель был знаком с основами языка программирования Java, включая такие вопросы, как обработка исключений и конкурентность.

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