Привет, Хабр!

По моим наблюдениям, всех людей можно разделить на три категории: счастливчиков с нормальным телосложением, худых, кто не знает как бы поправиться, и полных, кто не знает как бы похудеть. Мне угораздило попасть в третью категорию, и всю взрослую жизнь мой вес колебался в районе 95кг при росте 1.74м, что соответствует BMI=31.4 или ожирению. И хотя в принципе, это ничуть не мешало, но все же лишний вес накладывает определенные ограничения, как в перспективе состояния здоровья, так и в плане личной жизни. Наконец, в один прекрасный день я решил что «пора», и занялся этим вопросом более серьезно.



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

2,4 ГГц — это плохо. 5 ГГц — это хорошо. 6 ГГц — это ещё лучше, но послезавтра. Все это знают, кого я тут учу, в самом деле. Всё это хорошо, только делать-то что, когда ты такой, как умный, открываешь какой-нибудь Wi-Fi Explorer, а там сатанизм и этажерки, как на скриншоте?



Шаг первый — поплакать. Шаг второй — нырнуть под кат. Вопрос простой, а ответ — нет.

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

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

• В Hellblade предупреждение перед игрой было тщательно продумано, чтобы заставить игроков поверить, будто в игре срабатывает система permadeath в случае, если игрок умирает слишком часто, хотя на самом деле ее там нет.
• Pacman может огибать углы более резко, чем это делают призраки, тем самым наделяя игрока небольшим преимуществом.
• Во многих шутерах последние очки здоровья стоят больше всей остальной шкалы, чтобы усилить чувство «выживания на грани». С той же целью в System Shock последняя пуля нанесет урон в 4 раза более сильный, чем остальные.
• И, напротив, Shadow of Mordor слегка увеличивает здоровье некоторых врагов, чтобы бои длились дольше.
• В Bioshock и Devil May Cry, находясь за спиной игрока, противники замедляют свою атаку.
• В Xcom, если промахнуться много раз подряд, игрок получит скрытый бонус для последующих выстрелов. Кроме того, если игроки остаются пассивными слишком долго, враги усиливают свою агрессивность.
• Похоже, что в Heartstone есть pity timers ― таймеры жалости. Многие другие игры позорно использовали их в более ранние годы.
• В Resident Evil 4 после слишком большого количества смертей заспавнится меньше врагов, чтобы дать игроку больше шансов пройти трудный для него эпизод.
• В любой гоночной игре реализован адаптивный ИИ, чтобы сделать соревнование более жестким.

Список можно продолжать и продолжать. Это настоящий кладезь подсказок от успешных геймдизайнеров.

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

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

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

Дело в том, что все их (по крайней мере те что я читал) можно поделить условно на две категории: с одной стороны это статьи где вам объяснят что монада это моноид в категории эндофункторов, и что если монада T над неким топосом имеет правый сопряжённый, то категория T-алгебр над этой монадой — топос. На другой стороне располагаются статьи, где вам рассказывают, что монады — это коробки, в которых живут собачки, кошечки, и вот они из одних коробок перепрыгивают в другие, размножаются, исчезают… В итоге за горой аналогий понять что-то содержательное решительно невозможно.

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

Я же хотел бы занять промежуточную позицию, и рассказать про монады без заумных терминов, но и без котиков, используя понятные ООП разработчикам термины: интерфейсы, паттерны, копипаста, инкапсуляция сложности, бойлерплейт, и так далее. В процессе работы над статьёй ни один термин теории категории использован не был.

«Какой толк в книге, — подумала Алиса, — если в ней нет ни картинок, ни разговоров?»
Льюис Кэрролл, «Алиса в Стране чудес»

Всем привет!

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

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

Я работаю преподавателем и руководителем группы разработки учебных материалов в учебном центре «Сетевая Академия ЛАНИТ» более 10 лет и, когда провожу разработанный нами курс по инфографике, то обычно начинаю так: «Наш курс не для дизайнеров, а для тех сотрудников, которым нужно научиться правильно применять доступные средства для быстрого и качественного представления данных».

И в статье будет не про космические корабли, бороздящие просторы вселенной, а про кастрюли…

Источник

Невозможно полноценно тестировать и отлаживать мобильные приложения без тестовых устройств. Таких устройств должно быть много, потому что один и тот же код на разных моделях ведёт себя по-разному. Но как организовать учёт устройств? Как сделать так, чтобы разработчики и тестировщики быстро и без волокиты получали конкретный смартфон в необходимой конфигурации?

Меня зовут Алексей Лавренюк. Вы можете знать меня как одного из авторов Яндекс.Танка и докладчика на тему нагрузочного тестирования. Потом я измерял энергопотребление мобильных телефонов. Теперь я делаю Яндекс.Ровер в команде беспилотных автомобилей (и иногда подрабатываю Дедом Морозом). А между телефонами и Ровером был Гиперкуб.

Пару лет назад в наш отдел нагрузочного тестирования зашёл руководитель мобильной разработки и пожаловался на ситуацию с тестовыми устройствами. Телефоны кочевали из рук в руки, выбрать и быстро найти телефон было проблемой. У нас уже был опыт работы с мобильными устройствами: мы строили цифровой амперметр, чтобы измерять их энергопотребление. Поэтому мы решили помочь коллегам и быстро сделать классную штуку: казалось, работы всего на три месяца. Смеюсь над собой, наивным, из 2020 года и рассказываю, что нас ждало на самом деле.

Привет, Хабр!

Я потихоньку перевожу статьи Маркуса Винанда из блога use the index luke.

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

На хабре не нашлось обзоров «более быстрой альтернативы Redis» — KeyDB. Получив достаточно свежий опыт его использования, хочется восполнить этот пробел.



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

Избегаем оценочных суждений! Дробим предложения. Выкидываем ненужное. Не льем воду.
Факты. Цифры. И без эмоций.

«Информационный» стиль, прилизанный и гладкий, накрыл технические порталы с головой.
Привет постмодерн, теперь наш автор мертв. Уже взаправду.

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

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

Если один тест не может выразить эту идею, то тест плохой.

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

Что такое магия в PHP? Обычно под этим подразумевают методы вроде _construct() или __get(). Магические методы в PHP — это лазейки, которые помогают разработчикам выполнять удивительные вещи. В сети полно инструкций по их использованию, с которыми вы наверняка знакомы. Но что если мы скажем, что вы даже не видели настоящую магию? Ведь, чем больше вам кажется, что вы знаете все, тем больше магии ускользает от вас.



Давайте отбросим установленные рамки правил ООП и сделаем невозможное возможным в школе магии PHP. Главный и первый волшебный преподаватель школы — Александр Лисаченко (NightTiger). Он научит магическому мышлению и, возможно, вы полюбите магические методы, нестандартные способы доступа к свойствам, изменение контекстов, аспектно-ориентированное программирование и потоковые фильтры.

Как изменилась структура российского (постсоветского) общества с середины XX века. Спойлер: она изменилась кардинально.

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

Введение

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

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

Прошёлся недавно по поисковой выдаче гугла и выяснил, что регистрация прав на программу для ЭВМ стоит около 15 тыс. рублей. 15 тыс. рублей! И это ещё без пошлины.

Я удивился, потому что подготовка документов занимает минут тридцать. Чёрт с ним, пускай даже один час, но 15 тыс. рублей за час — это более чем достойное вознаграждение.

Зашёл на сайт Роспатента: инструкции там есть, но четкой картины не дают. На месте руководителя маленького IT-проекта я бы не стал подавать заявление сам — вдруг что-то сделаю не так.

Но я же юрист, и процедуру эту проходил не раз. Так почему бы мне не помочь стартаперам? Подумал-подумал, и не нашёл аргументов против. Так что давайте вместе попробуем подготовить документы и направить их в Роспатент, сэкономив при этом в среднем 15 тыс. рублей.

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

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

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

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

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

В прошлой статье мы рассмотрели кластеризацию RabbitMQ для обеспечения отказоустойчивости и высокой доступности. Теперь глубоко покопаемся в Apache Kafka.

Здесь единицей репликации является раздел (partition). У каждого топика один или несколько разделов. В каждом разделе есть лидер с фолловерами или без них. При создании топика указывается количество разделов и коэффициент репликации. Обычное значение 3, это означает три реплики: один лидер и два фолловера.

Основное событие года, это, конечно, Windows 95. Пока ещё не очевидная победа — по прежнему сильны DOS (не только MS) и Windows 3.xx, IBM выкатывает русскую OS/2 Warp, где-то ещё шевелится Alpha и даже есть Windows NT под неё. Игры всё ещё делают для DOS, а те, что выходят под Windows, обычно нормально работают и под 3.х. Гики во всю ругают 95, хвалят OS/2, иногда NT. Самые умные уже знают слово Linux. Народ не особо спешит апгрейдиться — хоть формально 95 и запускается на 386/4MB, но работать на таком железе очень тяжко.

Потому все посмотрели, впечатлились и пошли дальше заниматься своими делами. Ну или играми. Пока всё ешё под DOS.



Содержание:
Деревянные игрушки — эпилог, что осталось прибитым к потолку
Деревянные игрушки, часть последняя — 1997
Деревянные игрушки, часть десятая — 1996
Деревянные игрушки — неписи
Деревянные игрушки, часть девятая — 1995
Деревянные игрушки, часть восьмая — 1994
Деревянные игрушки, часть седьмая — 1993
Деревянные игрушки, часть шестая — 1992
Деревянные игрушки, часть пятая — 1991
Деревянные игрушки, часть четвертая — 1990
Деревянные игрушки, часть третья — 1989
Деревянные игрушки, часть вторая — 1986-1988
Деревянные игрушки, часть первая — 1982-1985

В 1991 году всё больше игр выходило с поддержкой VGA, хотя за EGA ещё держались и не так много игр именно требовали VGA. Для меня же в 1991 начинался период отлучения от РС. Регулярному доступу приходил на смену эпизодический, гораздо больше времени начал проводить за MSX в школе. На РС же, к которым был доступ, был паскаль, а не игрушки. Это тоже было интересно, но всё же проходило по другому ведомству.



Содержание:
Деревянные игрушки — эпилог, что осталось прибитым к потолку
Деревянные игрушки, часть последняя — 1997
Деревянные игрушки, часть десятая — 1996
Деревянные игрушки — неписи
Деревянные игрушки, часть девятая — 1995
Деревянные игрушки, часть восьмая — 1994
Деревянные игрушки, часть седьмая — 1993
Деревянные игрушки, часть шестая — 1992
Деревянные игрушки, часть пятая — 1991
Деревянные игрушки, часть четвертая — 1990
Деревянные игрушки, часть третья — 1989
Деревянные игрушки, часть вторая — 1986-1988
Деревянные игрушки, часть первая — 1982-1985

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

И хотелось бы рассказать о различных паттернах и антипаттернах разделении ответственностей на микросервисы.