Хорошо известно, что PHP — это мёртвый язык программирования и его 22-летняя экосистема фактически стала бесполезна, когда появился Node и новые асинхронные фреймворки на его основе. Превосходство Node очевидно, потому что все знают, что однопоточные асинхронные программы более лучше по умолчанию. И быстрее.

«Но Саймон! Почему?!", вы, вероятно, прокричите увидев этот текст на экране. И вот почему:

Перспективы трудоустройства

PHP-разработчики не пользуются спросом. По прошествии 22 лет, все компании, использующие PHP, сразу же отказались от него, как только был выпущен Node v0.0.1, потому что этот стек разработки мгновенно стал лучшим. Кроме того, всем известно, что для успешного запуска (забудем про Slack) вам нужно создавать веб-интерфейсы на Node, а данные сохранять в MongoDB.

Иначе просто невозможно добиться успеха.

Приведем немного научных™ фактов, чтобы доказать эти утверждения:

$заголовок = ‘PHP-разработчики не могут найти работу чтобы содержать свои семьи’;

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



Сначала, как водится, стоит сказать несколько общих слов. Что такое scheduler (планировщик, или, для простоты, «шедулер»)? Это такая компонента системы, которая занимается распределением ресурса или ресурсов системы по потребителям. Разделение ресурса может происходить в двух измерениях: в пространстве и времени. Планировщики чаще всего фокусируются на втором измерении. Обычно под ресурсом подразумевают процессор, диск, память и сеть. Но, что греха таить, шедулить можно и любую виртуальную ерунду. Конец общих слов.

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

Аналитика

Fullstory

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

Впервые о теории близости я прочитал в 2007 году. Она была сформулирована так: «объекты, расположенные близко друг к другу, воспринимаются связанно». Тогда я подумал: «спасибо, Кэп! Я как-то и сам догадался, что букву “М” нужно вешать ближе к мужскому туалету, а не к женскому». Тогда я не осознал, что это одно из главных правил дизайна, которое помогает подбирать расстояния между элементами, размеры полей, расположение кнопок, размер логотипов и многое другое. А главное, теория позволяет быстро понять, хороший перед вами дизайн или нет, даже если вы не дизайнер.

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

К сожалению, большая часть информации на эту тему, которую можно найти на хабре или stackoverflow — уже устарела, поэтому я постарался превратить этот в пост в актуальный мега-гайд по шерингу страниц в соц сетях. Я рассмотрел 5 наиболее популярных в России социальных сетей: контакт, facebook, твиттер, одноклассники и мой мир. Для каждой социальной сети приведен актуальный URL для шаринга, небольшие советы и рекомендации по использованию, а также JS код, позволяющий узнать количество шеров конкретного URL в каждой из соц. сетей.

В конце статьи есть сводная таблица со всеми ссылками и кратким описанием возможностей каждой из сетей.

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

В далекие времена, до фейсбука и гугла, когда 32 мегабайта RAM было дофига как много, security была тоже… немножко наивной. Вирусы выдвигали лоток CD-ROM-а и играли Янки Дудль. Статья «Smashing the stack for fun and profit» уже была задумана, но еще не написана. Все пользовались telnet и ftp, и только особо продвинутые параноики знали про ssh.

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

Michael Widenius (или просто Monty) явно был знаком с параноидальными безопасниками не понаслышке, чего стоит один такой момент (из исходников, global.h):

/* Paranoid settings. Define I_AM_PARANOID if you are paranoid */
#ifdef I_AM_PARANOID
#define DONT_ALLOW_USER_CHANGE 1
#define DONT_USE_MYSQL_PWD 1
#endif

Так что неудивительно, что пароли в MySQL открытым текстом не передавались никогда. Передавались случайные строки на основе хешей. А конкретно, первый протокол аутентификации (цитируется по mysql-3.20, 1996) работал так:

И вновь мы публикуем расшифровки выступлений с конференции HighLoad++, которая прошла в подмосковном Сколково 7—8 ноября 2016 года. Сегодня Евгений Пивень знакомит нас с решениями балансировки в облаках.



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

Сначала я пробегусь по понятиям, которыми буду оперировать. Начнём с того чем мы занимается: RTB, Real Time Bidding — показ рекламы с аукционом в реальном времени. Очень упрощенная схема того, что происходит, когда вы заходите на сайт:

На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.

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

Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?

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

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



На его примере подробно: о терминологии, чем интерактивный прототип лучше традиционного (10 моментов), как его использовать + несколько выводов.

На конференции HighLoad++ 2016 Иван Круглов рассказал про то, как сервис Booking.com развивал свой поиск — одну из центральных функций системы интернет-бронирования отелей.

Всем привет! Я Ваня, пишу на Perl — можете мне посочувствовать. [Лёгкий смех в зале и со сцены.]

Ладно. По-серьёзному, меня зовут Иван Круглов, я из компании Booking.com, из города Амстердам. Там я работаю последние 4 года, где последние года полтора я работал в команде, которая делает наш поиск лучше.

Начать я хочу немного издалека. Вот с этой фразы:

Сергей Туленцев (TextMaster)

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

Кому будет полезен этот доклад? Это обзорный доклад с претензией на структурированность. Если вы что-то где-то когда-то слышали про NoSQL, то через 40 минут вы будете знать гораздо больше, вы будете легче ориентироваться в терминах и более уверенно выбирать базы данных для своего проекта.

Поговорим также про типичные примеры применения и как не надо применять NoSQL базы данных.

Здравствуйте, меня зовут Александр Зеленин, и я на дуде игрец веб-разработчик. Полтора года назад я рассказывал о разработке онлайн игры. Так вот, она немного разрослась… Суммарный объём исходного кода превысил «Войну и мир» вдвое. Однако в данной статье я хочу рассказать не о коде, а об организации инфраструктуры проекта.

Алексей Акулович объясняет жизненный путь высоконагруженного проекта на PHP. Это — расшифровка Highload ++ 2016.

Меня зовут Лёша, я пишу на PHP.

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

Начнём.

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

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

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

Затем 4 года назад я взялся за трудное дело, основав стартап — 5-дневные курсы обучения программированию в Лондоне под названием Steer. Через два года я оставил Steer, запустив SuperHi.

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

Автор статьи Гвидо Хенкель (Guido Henkel) — профессиональный разработчик игр с 1983 года; участвовал в создании Jagged Alliance: Deadly Games, Fallout 2, был продюсером Planescape: Torment.

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

Но ситуация изменилась. Несмотря на мрачные пророчества, жанр выжил, благодаря адаптации и упрощению игровых особенностей. Компьютерные ролевые игры (CRPG) стали более понятными широкой аудитории, и сегодня можно смело сказать, что современные CRPG — это мейнстрим, имеющий мало общего с предшественниками из 80-х и 90-х. Фактически, можно заявить, что они почти не походят на ролевые игры. (Разумеется, я не имею в виду игры, выросшие в последние годы на основе возрождённых ретро-RPG: очевидно, что они представляют собой намеренный возврат к парадигмам классического дизайна.)

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

Фото Emilio Küffer (Flickr)

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

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

Candy Crush — одна из тех игр, которые лучше всего понимают своих игроков

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

(Прим. пер.: 1. Spine — это проприетарный кроссплатформенный пакет для создания двухмерных скелетных анимаций с поддержкой различных игровых тулкитов.
2. Осторожно, в посте есть около 38 МБ gif'ок, все они спрятаны под кат.)

Как создать плавное переключение или поворот спрайтов?

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

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

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

— Это теперь называется Front-End инженер, но да, я — именно он. Я работаю с вебом в 2016. Визуализации, музыкальные плееры, летающие дроны, которые играют в футбол, все что угодно. Я только что вернулся из JsConf и ReactConf, так что я знаю новейшие технологии для создания веб-приложений.

— Круто. Мне нужно создать страницу, которая отображает последние действия со стороны пользователей, так что мне просто нужно получить данные от REST и отобразить их в какой-то фильтруемой таблице, ну и обновлять её, если что-то изменится на сервере. Я думал, может быть, использовать JQuery для извлечения и отображения данных?

— О, Мой Бог! Нет! Никто больше не использует JQuery. Ты должен попробовать React: это — 2016!