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

Mark Seeman расскажет о функциональном программировании просто и быстро. Для этого он начал писать цикл статей, посвященных связи между паттернами проектирования и теорией категорий. Любой ООПшник, у которого есть 15 минут свободного времени, сможет заполучить в свои руки принципиально новый набор идей и инсайтов, касающихся не только функциональщины, но и правильного объектно-ориентированного дизайна. Решающим фактором является то, что все примеры — это реальный код на C#, F# и Haskell. Этот хабрапост — перевод самого начала цикла, первых трех статей, слитых воедино для удобства понимания.

Кроме того, с Марком можно пообщаться вживую, посетив конференцию DotNext 2017 Moscow, которая состоится 12-13 ноября 2017 г. в Москве, в «Славянская Рэдиссон». Марк прочитает доклад на тему «From dependency injection to dependency rejection». Билеты можно взять здесь.

До релиза Firefox Quantum остаётся всё меньше времени. Он принесёт множество улучшений в производительности, в том числе сверхбыстрый движок CSS, который мы позаимствовали у Servo.

Но есть ещё одна большая часть технологии Servo, которая пока не вошла в состав Firefox Quantum, но скоро войдёт. Это WebRender, часть проекта Quantum Render.



WebRender известен своей исключительной скоростью. Но главная задача — не ускорить рендеринг, а сделать его более плавным.

При разработке WebRender мы поставили задачу, чтобы все приложения работали на 60 кадрах в секунду (FPS) или лучше, независимо от размера дисплея или от размера анимации. И это сработало. Страницы, которые пыхтят на 15 FPS в Chrome или нынешнем Firefox, летают на 60 FPS при запуске WebRender.

Как WebRender делает это? Он фундаментальным образом меняет принцип работы движка рендеринга, делая его более похожим на движок 3D-игры.

Привет, Хабр! Хочу поделиться историей о том, как я браузерный 3D-футбол писала. Началось всё с того, что мой муж любит футбол. Смотрит трансляции, ходит на игры, играет на телефоне. И вот, чтобы сделать ему сюрприз, а также, чтобы хоть ненадолго оторвать от девайса с игрой, решила написать свою игру.



Под катом я расскажу как дружила TypeScript и Three.js и что из этого получилось.

У моих игр довольно много загрузок на Google Play (больше 20 млн.), наверное поэтому, меня часто спрашивают про продвижение. Если кто-то из разработчиков пишет мне в личку или почту, готов поспорить, все сведется к вопросу: «Как ты продвигаешь свои игры, чувак?». Все думают, что у меня есть какой-то секрет (нет). Ладно, давайте я попробую сформулировать то, что знаю и будем надеяться, что это будет кому-то полезно. По крайней мере, я смогу давать ссылку на этот пост.

Гипертекстовая игра про «Терминатора 4». Я сделал это just for fun, как говорил Линус Торвальдс. Немного графики из постеров, немного скринов из тизеров и щепотку дерзости.

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

Технические характеристики:
— движок: HTML
— объем кода и графики: менее 1 мб
— общий объем чистого текста (не кода) — около 60 кб
— число узлов (страниц) — 132
— концовок: хороших три, остальных более десятка
— локаций: как минимум пять
— присутствуют перестрелки, погони, драки на ножах с терминаторами и битва с харвестером
И все это — в текстовой игре!

Зацени и обругай, предложи идею или напиши о замеченном баге.
Не жди, пока наступит будущее. Стань Джоном Коннором уже сегодня! :)

Как я написал игру на bash'е.



Нетерпеливые могут посмотреть\поиграть, скачав игру тут, а пользователи Ubuntu 18.04 могут установить игру apt'ом:

sudo apt install -y piu-piu

Далее небольшой рассказ о процессе создания и разбор интересных (по моему мнению) мест.

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

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

Здравствуйте все.

Мы продолжаем знакомить вас с нашим издательским поиском, и хотели прозондировать общественное мнение на тему RxJava.



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

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

До создания серьезных приложения со сложной структурой View и Layout'ов мы особо не задумывались над тем, как простые и логичные действия в стиле «смотрите, я набросал дизайн из лэйаутов» могут серьезно замедлить работу всей программы.

Помимо прочего, задача с «Короной Эмбера» осложнялась еще и тем, что игра, которую мы задумали перенести на Андроид платформу, была сама по себе достаточно насыщенной различными компонентами, которые как-то надо было умещать на игровом поле или рядом с ним.

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

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

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

Не секрет, что многих (как и меня) очень увлекла мысль о том, что-бы поработать в Тайланде, в коворкинг центре, о котором недавно писали на Хабре.

Но буквально сегодня, в Google Reader мне на глаза случайно попался следующий пост.

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

Культовые игры не всегда бывают успешными. И живой пример тому история Fallout I и Fallout II. Эти игры рассказали нам про жизнь в постъядерной пустыне. Но ирония в том, что они сами разошлись таким тиражом, будто их в этой самой пустыне и продавали. Будущие легенды, только появившись, оказались никому не нужны. Возможно, это судьба всех легенд.

Впервые я услышал о финансовом провале первых двух Fallout несколько лет назад. Я не задумывался над этим, пока недавно один мой знакомый не заявил: «Провал Fallout — это миф» и указал ссылку на Википедии про компанию Interplay, где говорилось, что игра была successful.

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

Возможно, я не гений Гугла, но поиск не дал мне особых результатов, кроме невнятного бормотания на форуме фанатов, что игра была НЕ очень успешна и продалась тиражом в 200-300 тыс копий (для 1998 года это был фактически провал).