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

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

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

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

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



В наши дни чаще всего заражению подвергается веб-сервер: устанавливаются вредоносные модули, внедряются вредоносные shared objects, либо же исполняемый файл перекомпилируется с вредоносной функциональностью. Для внедрения вредоносного JavaScript активно используется, например, Flash.

Недавно мы уже знакомили наших читателей с серией подходящих для «Умного дома» электроустановочных изделий. Хабр силён. После публикации поста у нас случилось неожиданное знакомство с представителем производства. В итоге мигом решилась проблема покупки подходящих пружинок и появилась возможность ближе приглядеться к продукции компании. Много фото ждет вас под катом.

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

Для обработки данных в Hadoop используется технология MapReduce.

Доброго времени суток, уважаемые хабравчане. Недавно Hugo Giraudel, он же CSS гоблин, SASS хакер и Margin псих опубликовал в своем блоге очень интересную CSS задачку на смышленость.



Сможете заверстать подобное учитывая следующие правила?

• Круг в центре должен быть прозрачным, чтобы был виден background
• Расстояние между левыми и правыми блоками, как между верхними и нижними должно быть одинаковое
• При наличии потомков в блоке, содержимое должно отображаться
• DOM должен выглядеть следующим образом: ul > li > section > header + footer
• Нельзя использовать JavaScript и изображения
• Дополню еще от себя: нельзя использовать CSS Shape и Clip Path

Чтобы не было очень лень — каркас уже есть.

Сделали?

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

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

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

От переводчика: Это перевод третьей статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.
Первая статья — http://habrahabr.ru/post/209144/
Вторая статья — http://habrahabr.ru/post/209524/

---

Виртуальные соединения поверх UDP

Введение

Привет. Меня зовут Гленн Фидлер и я приветствую вас в третьей статье из цикла “Сетевое программирование для разработчиков игр”.

В предыдущей статье мы разобрались, как отправлять и принимать пакеты, используя протокол UDP.

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


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

Но сначала, нам нужно более плотно разобраться, как работает интернет.

Прим.пер.: Я в курсе, что на момент перевода актуальная версия PHP — 5.5, а также что есть мудрая книга мануал. Но мне показалось интересным, то как автор преподносит namespace функционал, возможно кому-то из тех, кто только постигает азы (да и не только, есть немало бородатых разработчиков, остановившихся на PHP 5.2), статья поможет проникнуться. Ходор.

В PHP, начиная с версии 5.3 появились пространства имен. Большинство современных языков уже давно заимели себе такой функционал, но PHP немного опаздывал. Тем не менее, у каждой новой функции есть свое предназначение, давайте выясним, какие выгоды мы можем извлечь, используя namespace.

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

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

25 и 26 января Лаборатория данных провела первый учебный курс «Визуализация данных». Мы чувствовали себя первопроходцами, аналогов нашей программы в России пока нет. Я расскажу, как мы построили учебный план, как организовали процесс и каких результатов достигли.



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

Начиная с версии 5.1 в MySQL реализована поддержка динамически подключаемых плагинов. А дистрибутив содержит примерный скелет кода под названием – example. Он описывает интерфейс и структуру базового обработчика – handler, копия которого создается отдельно для каждого соединения с БД. Также ему передаётся указатель на дескриптор таблицы TABLE *table и вспомогательный вектор TABLE_SHARE *share, используемый для синхронизации с другими обработчиками. Разработку плагина можно осуществлять по модульному принципу, реализуя только необходимые функции в первую очередь и закрывая заглушками более сложные операции.
Поскольку шаблон example описывает только интерфейс и не выполняет никаких операций, то в этом примере мы добавим в него реализацию CRUD-операций на основе одно-связного списка.

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

К началу главного зимнего спортивного события последнего десятилетия «МегаФон» спроектировал и создал в Сочи мощную общегородскую цифровую систему сбора и обработки информации под названием «Безопасный город». В состав этой системы вошли:
• Цифровая сеть связи «МегаФона»
• Система видеонаблюдения/ собственно HD-камеры с высокой четкостью изображения и возможностью распознавания объектов
• Городской ситуационный центр
• Интеллектуальная платформа PSIM

Создание и управление средами разработки расстраивает вас, замедляет работу или отвлекать вас от разработки? У вас возникают трудности из-за того, что ваше локальное окружение и окружение при деплое отличаются? Если это так, у меня есть для вас решение — PuPHPet!

Введение

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

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

Иногда я проверяю свою рабочую почту и вижу там сообщение «Анонс доклада: Вершиннная эллиптическая криптография в N-сторонних Бананотряховых[1] пространствах». Я смотрю аннотацию и там говорится что-нибудь типа «Хорошо известно, что 5-сторонний обмен секретами нелегален со времён Протестантской Реформации [Лютер1517]. Однако, используя новые результаты в области исполняющихся за полиномиальное время Бананотряховых проекций, мы показываем, как множество корреспондентов, притворяющихся друзьями (но являющихся противниками)[2], могут послать друг другу вплоть до 5 ехидных язвительных замечаний, устойчивых к атакам с использованием выбранным по Бананотряху открытого текста сообщения». Такое чувство, что началась середина трагичной, но вряд ли интересной оперы. По какой именно причине нас только что засунули в эллиптический мир? Кто именно такой этот Бананотрях, и почему нам не пофигу, какой он там открытый текст выберет? Если потому, что он похитил наши семьи, можно мне хотя бы обменяться сообщениями с похищенной роднёй, и если да, обязательно ли сообщения должны быть ехидными и язвительными?

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

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

Правила организации высокоскоростного взаимодействия пользователя с приложением можно сформулировать следующим образом:

1. Вычисления не должны блокировать взаимодействие с интерфейсом и его рендеринг — пользователь всегда должен иметь возможность указать на фокус своих интересов.
2. Страница объекта, к которому обратился пользователь, должна отображаться мгновенно, не дожидаясь загрузки данных, в которых нуждается объект.
3. Запросы в сеть не должны уходить одной большой группой, не должны отправляться сразу; должны откладываться на небольшое время, складываться и приоритезироваться в случае необходимости.

Изложенная в этой заметке информация — это мой практический опыт проектирования и разработки интерфейса моего приложения для поиска и прослушивания музыки seesu.me. Приложения, в котором гармонично комбинируются огромные пласты данных из разрозненных сервисов, таких как last.fm, вконтакте, ex.fm, hypem.com, soundcloud.com, discogs.com, youtube.com

Мы начали работать над Облаком Mail.Ru в июне 2012. За полтора года мы прошли долгий и тернистый путь от первого прототипа до публичного сервиса, выдерживающего нагрузки свыше 60 Гбит/с. Сегодня мы хотим поделиться с вами рассказом о том, как это было.

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

Участники:
Александр Матросов (@matrosov)
Дмитрий Недоспасов (@nedos)
Олег Купреев (@090h)
Александр Бажанюк (@ABazhaniuk)
Дмитрий Олексюк (@d_olex)

MP3 файл
Официальный сайт подкаста
Github c Show Notes

Проект Street View компании Google стартовал 25 мая 2007 года — тогда в нем было лишь пять городов США. Постепенно начали добавляться другие города США и мира, в том числе России. В начале февраля вышло масштабное обновление сервиса и в него добавили еще 300 городов России. На сегодняшний момент функция просмотра улиц доступна в 500-ах городах России.

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

«60% лучших профессий ближайшего десятилетия ещё даже не изобретены». — Томас Фрей (Thomas Frey), футурист.

Исследовательское агентство Sparks&Honey предложило своё видение недалёкого будущего. Точнее, видение 20 профессий, которые, по мнению авторов, будут очень востребованы в ближайшее десятилетие.

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

В результате у нас нередки споры споры о том, должен ли код быть красивым. Причём оказывается, что понятие красоты здесь, как и везде, субъективно: «Предпочтение в коде у программистов — это как предпочтение в женщинах. Кому-то нравятся брюнетки, кому-то — блондинки».

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



В опросе участвуют bobuk, anatolix, anton, Андрей yafinder Плахов, Антон Самохвалов, Андрей Гулин, Владимир Иванов и другие. Суммарный опыт программирования всех участников этого микроинтервью на восьмерых составляет 198 лет.

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

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

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