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

PHP — это скриптовый язык, который по умолчанию компилирует те файлы, которые вам нужно запустить. Во время компилирования он извлекает опкоды, исполняет их, а затем немедленно уничтожает. PHP был так разработан: когда он переходит к выполнению запроса R, то «забывает» всё, что было выполнено в ходе запроса R-1.

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

Как устроена MySQL-репликация

Андрей Аксенов (Sphinx), shodan

Мой доклад предназначен для тех людей, которые знают слово «репликация», даже знают, что в MySQL она есть, и, возможно, один раз ее настроили, 15 минут потратили и забыли. Больше про нее они не знают ничего.

Мы немного пройдемся по теории, попытаемся объяснить, как это все работает внутри, а после этого вы с утроенными силами сможете сами нырнуть в документацию.

Что такое репликация, в принципе? Это копирование изменений. У нас есть одна копия БД, мы хотим с какой-то целью еще одну копию.

Репликация бывает разных видов. Разные оси сравнения:

• степень синхронизации изменений (sync, async, semisync);
• количество серверов записи (M/S, M/M);
• формат изменений (statement-based (SBR), row-based (RBR), mixed);
• теоретически, модель передачи изменений (push, pull).

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

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

Ошибка № 1 — Заблуждение

У вас есть идея мобильного приложения? И, конечно же, она просто “гениальна” и принесет вам сотни миллионов долларов. У меня в голове появилась именно такая идея и я решил действовать. До этого у нас в компании никто не занимался мобильными приложениями. Мы разрабатывали сайты и ничего не знали о мобильной разработке и рынке мобильных приложений. Все наши знания ограничивались одной информацией — Facebook купил WhatsApp за 18 миллиардов долларов. И на основании этого мы сделали вывод, что мобильная разработка — это круто.

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

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

В 2008 году у нас родилась идея максимально упростить процесс поиска в архивах видеосистем. Представьте среднего размера систему из 100 видеокамер и примерно 1000 часов видеозаписей, которые они оставили за сутки (обычно запись видео производится только когда есть активность в кадре). И вам нужно найти что-то в этих записях, но вы не знаете, где и когда это происходило. Вы будете просматривать записи час, второй, третий, и к моменту, когда найдете то, что нужно, проклянете все на свете.

Мы решили создать инструмент, который позволит искать по видео так же, как Google ищет по тексту:

Пролог

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

Большинство создают внешние ссылки через target="_blank" и не знают одного интересного нюанса — страница, на которую мы попадем таким образом, получит частичный контроль над ссылающейся на нее страницей через js свойство window.opener.

Через window.opener.location мы сможем сделать редирект на, к примеру, фишинговую страницу. Это своего рода tabnabbing, только более продвинутый. Так как жертва меньше всего ожидает подмены страницы, в открытой ранее, доверенной вкладке браузера.

В этом небольшом посте я постараюсь рассказать с чего начать разрабатывать приложения для Android на языке Scala с помощью SBT и IntelliJ Idea, а так же плюсы и минусы этого подхода. Все будет довольно просто, стоит только запастись терпением. Весь процесс описывается для unix like систем, на Windows не проверялось, но если очень хочется, то можно попробовать провернуть то же самое через cygwin. Итак…

Существующие решения

При беглом гуглении можно наткнуться на эти три (раз, два, три) замечательные статьи, которые в красках поэтапно описывают долгий и тернистый путь к просветлению, а именно как поднять SBT проект для Android в Idea. Этот метод устарел, потому как в статье описывается процесс для SBT 0.7.4, а так же многие ненужные шаги, которые только отталкивают от дальнейшего изучения материала. Не смотря на это, я рекомендую их к прочтению, чтобы иметь базовое представление с чем вы имеете дело.

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

Инструменты

• ItelliJ Idea community edition с поддержкой Android — самая дружественная к Scala IDE на сегодняшний день (есть еще ensime, но это из другой оперы).
• JDK 6 для linux/mac os. Путь до JDK необходимо прописать в глобальной переменной JAVA_HOME (можно в ~/.bashrc).
• Android SDK для linux/mac os. Путь до SDK должен быть также задан через глобальную переменную ANDROID_SDK_HOME, но, внимание, для видимости всей системой, поэтому прописывать переменную нужно строго в /etc/environment. Может потребоваться перезагрузка.
• Simple Build Tool (SBT) 0.10.1 — инструмент для генерации и сборки Scala проектов. Недавно проект сменил имя на XSBT и переехал на github, что весьма удобно.
• Android плагин для SBT — для ознакомления, потому как данный плагин ставится автоматически.
• giter8 (g8) — утилита для генерации проектов из шаблонов, опубликованных на github.
• Мой шаблон g8 для генерации Idea проектов.
• Настроенный Android Emulator или напрямую подключенный андроид смартфон с включенной USB отладкой.

Это вторая часть цикла «Масштабирование Wix до 100 миллионов пользователей». Вступление читайте тут.

Когда мы только запускали Wix, был использован стек Tomcat, Hibernate и Ehcache c базой данных MySQL и фронтендом на Flash. Почему мы выбрали этот стек? Да просто потому, что у нашего первого бэкенд-разработчика уже был опыт работы с ним. Частью этой архитектуры был Ehcache – отличная кэш-библиотека для Hibernate и JVM, которая создавала абстракцию в виде карты для кэша памяти и которая могла также быть сконфигурирована как распределенный кэш. Ehcache, в отличие от Memcached, запускается как процесс в JVM и в точности реплицирует состояние кэша для всех узлов кластера. Обратим внимание, что в то время (около 2006–2008 гг.) Encache все еще был независимым open source проектом и не был частью Terracotta (в рамках Terracotta модель репликации и дистрибуции может быть иной, но для данной статьи это не столь важно).

Аспекты использования кэша

Поскольку у нас уже были реальные клиенты, мы установили два сервера Tomcat для обеспечения дополнительной надежности. Следуя правилам выстраивания архитектуры, мы установили распределенный Ehcache-кластер между серверами. Мы исходили из того, что MySQL работает медленно (как и любая другая SQL-система), а значит кэш оперативной памяти обеспечит гораздо более высокую скорость чтения и снизит нагрузку на базу данных.

Выход на азиатский рынок для европейского разработчика сродни выходу в открытый космос, только на 30 мегабайт тяжелее. Локализация на японский, китайский и корейский – это титанический труд. Он требует учета особых технических требований, скрупулезных исследований рынка и менталитета целевой аудитории. Но если именно об этом вы мечтаете, читайте дальше – вам пригодится наш опыт.

Предлагаю вам перевод статьи Gary Willoughby «Interesting ways of using Go channels».

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

Интересные способы использования Go каналов

Я написал этот пост, чтобы задокументировать доклад про Go каналы Джона Грэм-Камминга на конференции GopherCon 2014. Доклад назывался «Краткое руководство по каналам» и он доступен для просмотра на youtube.com.

На протяжении доклада нам представляют интересные способы использования Go каналов и раскрывают возможности и преимущества конкурентного программирования. Лично мне этот доклад открыл глаза на несколько новых способов структурирования программ и новых техник для синхронизации по нескольким ядрам процессора.

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

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



Уже давно появилось желание изучить сверточные сети и узнать что-то новое, к тому же под рукой есть несколько последних Tesla K40 с 12Гб памяти, Tesla c2050, обычные видеокарты, Jetson TK1 и ноутбук с мобильной GT525M, интереснее всего конечно попробовать на TK1, так как его можно использовать практически везде, хоть на столб фонарный повесить. Самое первое с чего начал, это распознавание цифр, тут конечно удивить нечем, цифры уже давно неплохо распознаются сетями, но при этом постоянно возникает потребность в новых приложениях, которые должны что-то распознавать: номера домов, номера автомобилей, номера вагонов и т.д. Все бы хорошо, но задача распознавания цифр является лишь частью более общих задач.

Мы в Relap.io распространяем контент брендов на российских медиаплощадках. Например, к нам приходит Тинькофф или Aviasales с материалами и мы приводим аудиторию в их блоги и на спецпроекты.

Многие бренды тоже хотят создавать контент, но сомневаются.

• Как найти аудиторию,
• окупятся ли усилия на производство,
• как посчитать возврат инвестиций,
• какой именно контент подойдет их бизнесу,
• как вовлечь пользователя, чтобы он читал материалы компании.

Мы собрали СМИ и блоги о контент-маркетинге и нативной рекламе, где вы найдете ответы на эти вопросы. Сами их читаем, потому что нам тоже нужны советы.

Шифрование. Мы все его любим и хотим использовать везде. Но почему оно до сих пор не применяется повсеместно?

Проблема в сертификатах?

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

Большинство предложений перехода на повсеместное шифрование звучат примерно так: «NSA записывает весь наш трафик, почему бы не шифровать его?». Целью подобных предложений является повышение стоимости пассивного слежения за всем трафиком, а не более сложные и целевые атаки, которые применяются злоумышленниками.

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

Приветствую, уважаемое Хабрасообщество!

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

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

Кому интересно — добро пожаловать под кат.

Так уж получилось, что 2015 год стал первым годом коммерческой жизни нашего ещё совсем молодого проекта Бонджойн. Несмотря на то, что мы набрали около 85 0000 партнёров, которые выполнили большинство заказов, понятно, что нам расти и расти. Мы уже рассказывали о некоторых муках разработки, а сегодня решили сделать староновогодний пост про шишки web-разработчиков: столь же популярные и неизбежные, как оливье на наших новогодних столах. Какие-то из них мы набивали сами, какие-то заботливо собрали у знакомых и не совсем знакомых разработчиков. В лучших традициях приготовления ещё не до конца ушедшего новогоднего настроения расскажем обо всём подряд, вразнобой, сдобрив комиксами, которые мы перевели специально по случаю. В общем, угощайтесь!

А ваше приложение — RESTful? Чтобы ответить на этот вопрос нужно сначала разобраться что такое RESTful. Бытует мнение, что отдавать правильные коды ответов в HTTP — это уже RESTful. Или делать правильные идемпотентные HTTP-запросы — это вообще очень RESTful. Мы в Хекслете сделали практический курс по протоколу HTTP (отличия версий, отправка форм, аутентификация, куки и пр.), и в нем мы стараемся рассказать о правильном использовании запросов, но нужно понимать, что RESTful это не про HTTP, это вообще не про протоколы интернета. Современный веб и взаимодействие между браузером и сервером с помощью HTTP и URI могут удовлетворять принципам RESTful, а могут и не удовлетворять.

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

Спешим поделится радостной новостью, в 2015-м году общая емкость сетей LeaseWeb в дата-центре премиум-класса EvoSwitch, в котором мы предлагаем выделенные серверы в аренду, достигла значения 5 Тбит / с. Много это или мало? Почему свыше 60 000 абонентов выбрало именно этот дата-центр для своих проектов, несмотря на то, что существуют более выгодные по цене предложения лоу-костеров в других странах? Причин множество, в частности — мы, хостинг-провайдер, который применяет индивидуальный подход к каждому абоненту, но все же, помимо нас, это:

— лояльное законодательство Нидерландов;
— дата-центр премиум-класса EvoSwitch;
— LeaseWeb — провайдер, с которым мы и наши абоненты успешно сотрудничаем много лет, мы являемся их премиальными партнерами и благодаря многолетнему сотрудничеству можем предлагать условия лучше, чем в дата-центре напрямую, при этом всячески заботясь о Вас в индивидуальном порядке (на площадке всегда доступен выделенный инженер, запросы наших абонентов рассматриваются приоритетно, в 90% случаев техническую поддержку оказывают наши администраторы удаленно без необходимости проведения физических работ с сервером);
— cеть доставки трафика к Вашим посетителям с невероятной связностью (минимальные пинги и максимальная скорость на поток);
— общая емкость сети 5 Тбит / с;
— 2,5 Тбит / с трафика генерируется абонентами дата-центра;
— 58 точек присутствия по всему миру;
— включения в 36 точек обмена трафиком в более, чем 20 странах;
— 4213 пиринговых подключений к Интернет-провайдерам различного уровня.

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



Анализ запросов в данном сервисе — не является заменой команде EXPLAIN, которая ориентирована на анализ производительности запроса, а является скорее дополнением, которое анализирует запрос с точки зрения его синтаксиса.