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

Создавая кнопки в уведомлении нельзя просто назначить им слушатели, как мы привыкли делать редактируя интерфейс пользователя. Основным способом назначения действий в уведомлении являются интенты (Intent) — намерения.

И если для того, чтобы назначить кнопке действия перехода в какую-либо Activity достаточно просто создать соответствующий интент, внутри которого и будет описано необходимое действие, а именно — откуда и куда переходим, то в нашем случае необходимо будет сделать следующее: назначить кнопке намерение, передать ему Action для работы с интент фильтром, создать BroadcastReciver, который будет вылавливать наш Intent и уже тогда выполнять необходимый нам метод.

Первые эксперименты с жидкостным дыханием, 1987 год, личный фотоархив А. В. Филиппенко.

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

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

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

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

Статья будет короткой и сумбурной — я пишу ее с целью скоротать пару часов перед тем как начать откатывать сайт к предыдущему «нормальному» состоянию.

Эта история началась пять часов назад. Ко мне обратился владелец одного тематического новостного сайта. Тематика — спортивные соревнования. У сайта есть две проблемы. Во-первых, в моменты крупных и сильно ожидаемых состязаний количество посетителей на сайте увеличивается на порядок. Вторая проблема — он сделан на WordPress, причем довольно небрежно. Думаю, что изначально это был обычный WP-сайт. Но потом он многократно «дорабатывался»: куда ни попадя втыкались разные рекламные блоки, вводились новые «решения», ставились всякие плагины для «оптимизации» и расширения возможностей. Кроме того, каждый день, на протяжении нескольких лет, появлялось около десятка постов. Размер БД — несколько гигабайт, ‘upload’ идет на десятки гигабайт. Со временем сайт превратился во что-то похожее на это:

Желание что-нибудь автоматизировать — один из главных двигателей прогресса на протяжении всего XX века. От крупных производств этот процесс плавно перекинулся на повседневную жизнь и принялся штурмовать новые рубежи: в 60-е годы на волне создания мощных серийных ЭВМ и развития кибернетики стали появляться идеи масштабных автоматизированных систем управления. Особенно они казались привлекательным для социалистических государств с плановой экономикой.

И пока в капиталистической Америке граждан пугали властью машин, в Чили подобный проект почти реализовали.

Адъюнкт-профессора США сталкиваются с низкой зарплатой и удлинённым рабочим днём, не получают страховок и полноценных зарплат. Некоторые из них, опасаясь оказаться на улице, прибегают к отчаянным мерам



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

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

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



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

Перед вами четвёртая часть серии материалов, посвящённых внутренним особенностям работы JavaScript. Эти материалы, с одной стороны, направлены на изучение базовых элементов языка и экосистемы JS, с другой, содержат рекомендации, основанные на практике разработки ПО в компании SessionStack. Конкурентоспособное JS-приложение должно быть быстрым и надёжным. Создание таких приложений — та цель, к которой, в конечном счёте, стремится любой, интересующийся механизмами JavaScript.

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

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 года это был фактически провал).