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



Конфигурация под катом.

GPON шагает по Москве. Распространяются и связанные с ним проблемы. В данной заметке я хочу поделиться опытом по лечению несовместимости МГТСовксого роутера с имеющимся телефонным аппаратом, проявляющуюся в случайных ошибках при наборе номера.

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

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

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

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

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

Не так давно, я заинтересовался трудами идеологов программирования, таких как Кент Бэк, Роберт Мартин, Мартин Фаулер, Пол Дюваль.

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

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

Теория

Continuous Integration (далее CI) — это практика разработки программного обеспечения, в которой члены команды проводят интеграцию не реже чем раз в день. Результаты интеграции проверяются автоматически, используя автотесты и статический анализ кода.

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

Фактически, CI позволяет избавиться от предположений, при процессе разработки ПО. Менеджер предполагает, что продукт готов и стабилен, программист — что в коде нет ошибок и т. д. Избавиться от вопросов, таких как: «стабильна ли последняя сборка, какие фичи готовы, соответствует ли код стандартам компании» и т.д.

Всех, кому интересна тема CI прошу под кат.

Давно хотел сделать демку VSDCT на мобильном телефоне. VSDCT (Virtual Shadow Depth Cubemap Texture) это представление cubemap текстуры, когда вместо 6 отдельных граней используется одна обычная 2D текстура-атлас, в которой исходные грани кубической карты помещены в виде плотно упакованных тайлов. Посмотрим, как сделать тени от точечного источника света, использую эту технику.

Добрый день, дорогие читатели Хабра!

Итак представляю вашему вниманию, — сетевую систему хранения данных LenovoEMC PX4-300r, на первый взгляд вы скажете, что в ней такого особенного чего нет в других. Да я думаю, дам вам дорогие хабровчане простой, но исчерпывающий ответ в виде обзора.

В последнее время на Хабре появилось множество статей о нейронных сетях. Из них очень интересными показались статьи о Перцептроне Розенблатта: Перцептрон Розенблатта — что забыто и придумано историей? и Какова роль первого «случайного» слоя в перцептроне Розенблатта. В них, как и во многих других очень много написано о том, что сети справляются с решением задач, и обобщают до некоторой степени свои знания. Но хотелось бы как-то визуализировать эти обобщения и процесс решения. Увидеть на практике, чему там научился перцептрон, и почувствовать, насколько успешно ему это удалось. Возможно, испытать горькую иронию относительно достижения человечества в области ИИ.
Языком у нас будет С#, только потому что я недавно решил его выучить. Я разобрал два наиболее простых примера: однослойный перцептрон Розенблатта, обучаемый коррекцией ошибки, и многослойный перцептрон Румельхарта, обучаемый методом обратного распространения ошибки. Для тех, кому, как и мне, стало интересно, чему они там на самом деле обучились, и насколько они на самом деле способны обобщать – добро пожаловать под кат.

ОСТОРОЖНО! Много картинок. Куски кода.

На этот раз мы решили рассказать о замечательном продукте, который мы используем в нашей работе. Речь пойдет о Celery — «distributed task queue». Это распределенная асинхронная очередь заданий, которая обладает широким функционалом. В нашем конструкторе сайтов нам часто приходиться запускать асинхронные с точки зрения ответа пользователю задачи. На хабре, к сожалению, не много информации по данному продукту, а он заслуживает отдельного упоминания, это мы и хотим исправить.

Итак, что же умеет Celery:

• Выполнять задания асинхронно или синхронно
• Выполнять периодические задания(умная замена crond)
• Выполнять отложенные задания
• Распределенное выполнение (может быть запущен на N серверах)
• В пределах одного worker'а возможно конкурентное выполнение нескольких задач(одновременно)
• Выполнять задание повторно, если вылез exception
• Ограничивать количество заданий в единицу времени (rate limit, для задания или глобально)
• Routing заданий (какому worker'у что делать)
• Несложно мониторить выполнение заданий
• Выполнять подзадания
• Присылать отчеты об exception'ах на email
• Проверять выполнилось ли задание (удобно для построения Ajax приложений, где юзер ждет факта завершения)

Заинтересовало? Просим под кат.

Всем привет!

Друзья, не мне вам рассказывать, да и сами вы знаете о том, как делается backend для серверных/клиент-серверных приложений. В нашем идеальном мире всё начинается с проектирования архитектуры, затем выбираем площадку, затем прикидываем нужное количество машин, как виртуальных, так и нет. Затем происходит сам процесс поднятия архитектуры для разработки/тестирования. Всё готово? Ну поехали писать код, делать первый коммит, обновлять код на сервере из репозитория. Открыли консоль/браузер проверили и поехало. Пока всё просто, а что дальше?

Меня зовут Сергей Кубасов, я заместитель технического директора Mail.Ru Group. Недавно на форуме DCDE я рассказывал о нашем опыте создания и организации собственного центра обработки данных. Теперь я решил поделиться нашими открытиями с читателями Хабра.

Как это было

В начале истории нашего собственного ЦОДа мы сотрудничали с пятью сервисными организациями, которые обслуживали кондиционирование и вентиляцию, дизель-генераторные установки, источники бесперебойного питания, автоматику по электричеству и систему газового пожаротушения. На тот момент казалось, что это лучшее решение, т.к. «одни и те же люди» строят и эксплуатируют — то есть знают систему от и до.

При написании любого достаточно крупного проекта всегда встают более-менее похожие проблемы. Одна из них — проблема скорости получения обновлений системы. Относительно легко можно наладить быстрое получение небольших обновлений. Довольно просто изредка получать обновления большого объема. Но что если надо быстро обновлять большой массив данных?

Для Таргета Mail.Ru, как и для всякой рекламной системы, быстрый учет изменений важен по следующим причинам:
• возможность быстрого отключения показа кампании, если рекламодатель остановил ее в интерфейсе или если у него кончились деньги, а значит, мы не будем показывать ее бесплатно;
• удобство для рекламодателя: он может поменять цену баннера в интерфейсе, и уже через несколько секунд его баннеры начнут показываться по новой стоимости;
• быстрое реагирование на изменение ситуации: изменение CTR, поступление новых данных для обучения математических моделей. Все это позволяет корректировать стратегию показа рекламы, чутко реагируя на внешние факторы.

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

Предыстория

Существует красивое решение для создания надёжного недорогого кластера основанное на DRBD + Proxmox VE. Страница в Wiki проекта Proxmox появилась 11 сентября 2009-го года и создана она была CEO компании Martin-ом Maurer-ом.



С тех самых пор это решение стало очень популярным, и никто не подозревал, что у этого решения есть скрытый подводный камень. В документации про это не пишут, а те, кто сталкивался с последствиями этой проблемы (например, зависание машины при онлайн миграции с одного хоста на другой), списывали всё на «случай». Кто-то грешил на железо, кто-то на Proxmox, а кто-то на драйверы внутри виртуальной машины. Конечно, хотелось бы, чтобы DRBD сам сообщал о своих проблемах, и, как-то подсознательно веришь в то, что он так и делает. Проверяешь /proc/drbd, видишь строку «cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate» и продолжаешь верить что DRBD не причём.

Залез я минут 15 назад в замечательный каталог Яндекса. И вот что обнаружил:



Ссылки ведут на совершенно левые сайты!

^{Изображение: Chris Liverani — Unsplash}

Рассказываем о книге Майкла Льюиса «Быстрые мальчики» или «Высокочастотная революция на Уолл-стрит», приводим ключевые моменты, адаптированные из точечного отрывка материала, и обсуждаем тему HFT-трейдинга в целом, в том числе и в комментариях к этому хабратопику.

Введение

Использование радиосвязи стандартов Bluetooth и WiFi для сопряжения различной аппаратуры с вычислительной мощностью и пользовательским интерфейсом смартфонов позволяет снизить стоимость продукта и повысить его привлекательность для потребителя. Но у новой технологии Bluetooth low energy есть и еще одна черта, которая открывает возможность ее использования в малогабаритных автономных датчиках.

Подвиды и перспективы привычных SSD накопителей были рассмотрены в предыдущем материале, а до него рассмотрели жесткие диски.

Традиционные SAS/SATA интерфейсы привычны, отработаны и удобны в быту. Есть большая инфраструктура — диски, контроллеры, совместимость с экспандерами, отработанное кабельное хозяйство. К ним прилагается работа стека SCSI и SATA, задержки контроллеров интерфейсов. Постоянно идущая борьба за рост IOPS и снижение задержек требует избавляться от лишних звеньев и помещать накопители как можно ближе к процессору. Поэтому что делать, если производительность SAS/SATA SSD не устраивает и хочется еще быстрее?

Выбирать PCIe!

Тенденции, как обычно, разделились.

Продолжаем разговор от 07.04.2014 (Particles System в моделировании толпы).

В этой части добавляю:

1. медленные персонажи (это будут крупные стрЕлки)
2. огибание в пути медленных стрелок быстрыми
3. взрывы (с разбрасыванием тел)

Буквально пару часов назад в Санкт-Петербурге завершился открытый чемпионат по программированию Яндекс.Алгоритм 2013. Состязания состояли из нескольких онлайн-раундов по 100 минут, за победу боролись более 3000 программистов из 84 стран. По результатам трёх отборочных раундов в финал вышли 25 лучших.



Финалисты должны были решить шесть алгоритмических задач за 100 минут. Первое место занял недавний победитель ACM ICPC 2013 в составе команды НИУ ИТМО Геннадий Короткевич (tourist), который набрал меньше всего штрафного времени. Второе место досталось выпускнику НИУ ИТМО Евгению Капуну (eatmore). Третье место занял представитель Тайваня Ши Бисюнь.

В подготовке заданий для чемпионата участвовали специалисты из нескольких стран: России, Беларуси, Польши и Японии. Главными составителями задач стали разработчики минского офиса Яндекса (как и все сотрудники компании, к участию в состязаниях они не допускались). Мы попросили всех авторов разобрать задания, которые они подготовили для участников Яндекс.Алгоритма. Кстати, все задачи не удалось решить никому, лучший результат — три решённые задачи — показали только три участника.

Однажды, разглядывая очередную демку с эффектом, возник вопрос: а можно ли сделать SSAO на мобильном девайсе так, чтобы и выглядело хорошо и не тормозило?
В качестве устройства был взят Galaxy Note 3 n9000 (mali T62), цель — фпс не ниже 30, а качество должно быть как на картинке выше.