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

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

— А хочешь, я для тебя звезду зажгу… гляди вон туда… Profit. )

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

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

Играющему на Аудитории («в Аудиторию» как-то язык не поворачивается сказать, пардон) предлагается управлять Потоком (the flow) для того, чтобы заполнять им Контейнеры (the containers) с использованием Контролов (the controls). По мере заполнения Контейнера Потоком, он начинает проигрывать свою мелодию. Больше потока — больше звука. Когда все контейнеры на сцене заполнены, она считается пройденной.

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



Стоит ли говорить, что творение это требует некоторых процессорных мощностей и хорошего канала связи?

Итак, покоритель всевозможных конкурсов и призов — Auditorium.

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

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

Как известно, механизм активации Windows 7 был взломан ещё до официального выхода этой системы. Но старый метод требовал изменений в BIOS, что является весьма нетривиальной задачей.

Сейчас хакеры нашли вариант полного обхода механизма Windows Activation Technologies (WAT) без манипуляций с BIOS'ом и вообще без использования ключа активации.

Systemd – менеджер системы и сервисов в операционной системе Linux. При разработке eго стремились спроектировать обратно совместимым со скриптами инициализации SysV init и предоставить полезные функции, такие, как параллельный запуск системных сервисов во время загрузки, активацию демонов по требованию, поддержку снепшотов состояния системы и логику управления сервисами, основанную на зависимостях. В CentOS 7 systemd заменяет Upstart как систему инициализации по умолчанию.

В этой статье мы рассмотрим процесс управления сервисами в systemd для пользователя CentOS 7. Эти знания будут полезны и в других дистрибутивах, ведь systemd уже давно используется в Fedora и планируется в Ubuntu 14.10 и Debian 8. Хорошо это или нет — оставим за кадром.



В процессе чтения статьи вы можете попробовать systemd на классических VPS и облачных VPS от Infobox. Мы стремимся своевременно добавлять поддержку современных ОС, чтобы вы могли использовать последние технологии для более эффективной работы. Сама идея написания статьи родилась после очередного вопроса пользователей об использовании сервисов в CentOS 7.

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

Не секрет, что многие Java-программисты, начиная свой путь в индустрии, уделяют большое внимание «тяжелым» технологиям — OpenJPA, Spring, JAX-RS, EJB, WS-*,… Это дает возможность как скорее влиться в современные корпоративные проекты, так и максимизировать скорость роста зарплаты.

Многие из них в конце концов «спускаются» до технологий лежащих в основе указанных фреймворков — JDBC, Servlet API, NIO/NIO.2. Однако прискорбно, что зачастую не остается время на детальное изучение самого языка и возможностей платформы.

Речь идет не о тонкостях или экзотике, а о том, что составляет существенную часть работы фреймворка: Servlet-контейнер использует множественные ClassLoader-ы, JPA2-провайдер использует манипулирование байткодом, абсолютное большинство библиотек используют Reflection API, всеобщее использование Generics только «усугубилось» с появлением функциональных интерфейсов (java.lang.function.*) и лямбд.

На недопонимание изначальной платформы (ClassLoader, Reflection API) накладываются «новвоведения» Java 5 (Generics), а теперь еще и Java 8 (методы в интерфейсах, ссылки на методы, лямбды, Stream API, JSR 308: Pluggable Type Systems). Надо обратить внимание на то, что Generics + Java 8 — это не просто языковые фичи, это частично переход к функциональному стилю программирования.

Также я веду курс «Scala for Java Developers» на платформе для онлайн-образования udemy.com (аналог Coursera/EdX).

Я собрал определенное количество полезных (на мой взгляд) ссылок по следующим темам

1. Методы в интерфейсах, ссылки на методы, множественное наследование
2. Лямбды (Project Lambda)
3. Stream API
4. Функциональные алгоритмы
5. Аннотации
6. Генерики
7. Reflection API
8. Загрузка классов

Надеюсь кто-то сочтет их полезными.

Рад сообщить, что вышел перевод отличнейшего учебника Дасгупты, Пападимитриу, Вазирани «Алгоритмы», над которым я работал последние несколько лет. В книге многие алгоритмы объяснены гораздо короче и проще, чем в других учебниках: с одной стороны, без излишнего формализа, с другой — без потери математической строгости. Откройте книгу на каком-нибудь известном вам алгоритме и убедитесь в этом. =)

В общем, угощайтесь: печатный вариант перевода, электронный вариант перевода (PDF), печатный вариант оригинала, электронный вариант оригинала (PDF).

Не так давно мне предложили вести курс основ теории алгоритмов в одном московском лицее. Я, конечно, с удовольствием согласился. В понедельник была первая лекция на которой я постарался объяснить ребятам методы оценки сложности алгоритмов. Я думаю, что некоторым читателям Хабра эта информация тоже может оказаться полезной, или по крайней мере интересной.

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

Вступление

    Столкнувшись с задачей замониторить большое кол-во метрик в RabbitMQ кластере, появилось желание создать универсальный парсер для JSON данных. Задача усложнялась тем, что появляются и пропадают метрики динамически во время работы кластера, плюс к этому разработчики постоянно хотят собрать/посчитать что-то новое. К сожалению, в Zabbix нет возможности собирать данные в таком виде из коробки. Но есть такая удобная фича как zabbix_trapper, позволяющая делать гибкую кастомизацию. В статье пойдет речь о не сосвем стандартном способе использовании айтемов zabbix_trapper. Мне не хотелось каждый раз, когда разработчики попросят добавить новых метрик, изменять скрипт, который собирает данные и засылает в заббикс. Отсюда появилась идея использовать собственно сам zabbix key как инструкцию по сбору новой метрики. Суть в следующем, мы используем zabbix key как команду, с заранее заданным синтакисом. То есть zabbix key в этом случае будет служить инструкцией, подобной ключам типа zabbix_agent.

Везде, где используется LIMIT offset для больших таблиц, рано или поздно начинаются тормоза. Запросы вида

SELECT * FROM test_table ORDER BY id LIMIT 100000, 30

могут выполнятся очень долго. Например, в моем случае, на одном из сайтов кол-во комментариев перевалило за 200к и постраничная навигация по комментариям начала ощутимо тормозить, а в mysql-slow.log все чаще стали попадать запросы с временем выполнения 3-5сек.

Как скоро я смогу вас заинтересовать, если скажу, что в этой статье речь пойдет о VPN-сервере, который может поднимать L2TP/IPsec, OpenVPN, MS-SSTP, L2TPv3, EtherIP-серверы, а также имеет свой собственный протокол «SSL-VPN», который неотличим от обычного HTTPS-трафика (чего не скажешь про OpenVPN handshake, например), может работать не только через TCP/UDP, но и через ICMP (подобно pingtunnel, hanstunnel) и DNS (подобно iodine), работает быстрее (по заверению разработчиков) текущих имплементаций, строит L2 и L3 туннели, имеет встроенный DHCP-сервер, поддерживает как kernel-mode, так и user-mode NAT, IPv6, шейпинг, QoS, кластеризацию, load balancing и fault tolerance, может быть запущен под Windows, Linux, Mac OS, FreeBSD и Solaris и является Open-Source проектом под GPLv2?

То-то и оно. Такое пропустить нельзя.

Некоторое время назад, в силу определенных причин, мне пришла в голову мысль о том, чтобы начать изучать какой-нибудь новый язык программирования. В качестве альтернатив для этого начинания я определил два языка: Java и Python. После продолжительного метания между ними и сопутствующих нытья и долбежки головой о стену (у меня с новыми языками всегда так — сомнения, раздумья, проблема выбора и т.д.), я все-таки остановился на Python. Окей, выбор сделан. Что дальше? А дальше я стал искать материал для изучения…

Для обеспечения работы всех наших внешних продуктов мы используем популярный nginx. Это быстро и это надежно. Проблем с ним почти нет. Наши продукты также постоянно развиваются, появляются новые сервисы, добавляется новый функционал, расширяется старый. Аудитория и нагрузка только растет. Сейчас мы хотим рассказать о том, как мы ускорили разработку, неплохо увеличили производительность и упростили добавление в наши сервисы этого нового функционала, при этом сохранив доступность и отказоустойчивость затронутых приложений. Речь пойдет о концепции “nginx as web application”.
А именно, о сторонних модулях (в основном LUA), позволяющих делать совершенно магические вещи быстро и надежно.

• Мой опыт: 4ре рабочих месяца (реально это растянулось на полтора года)
• Уровень подготовки читателя: новичок
• Темы о которых я попытаюсь рассказать в этой статье: как я к этому пришёл, мотивация, как сделать простой дизайн самому, немного про SEO в Google Play и одна затерявшаяся среди этого всего мысль про локализацию.

Abstract: Рассказ про некоторые возможности IPv6 на примере конфигурации сложной домашней IPv6-сети. Включает в себя описания мультикаста, подробности настройки и отладки router advertisement, stateless DHCP и т.д. Описано для linux-системы. Помимо самой конфигурации мы внимательно обсудим некоторые понятия IPv6 в теоретическом плане, а так же некоторые приёмы при работе с IPv6.

Зачем IPv6?

Вполне понятный вопрос: почему я ношусь с IPv6 сейчас, когда от него сейчас нет практически никакой пользы?

Сейчас с IPv6 можно возиться совершенно безопасно, без каких-либо негативных последствий. Можно мирно разбираться в граблях и особенностях, иметь его неработающим месяцами и nobody cares. Я не планирую в свои старшие годы становиться зашоренным коболистом-консерватором, который всю жизнь писал кобол и больше ничего, и все новинки для него «чушь и ерунда». А вот мой досточтимый воображаемый конкурент, когда IPv6 станет продакт-реальностью, будет либо мне не конкурентом, либо мучительно и в состоянии дистресса разбираться с DAD, RA, temporary dynamic addresses и прочими странными вещами, которым посвящено 30+ RFC. А что IPv6 станет основным протоколом ещё при моей жизни — это очевидно, так как альтернатив нет (даже если бы они были, их внедрение — это количество усилий бОльшее, чем завершение внедрения IPv6, то есть любая альтернатива всегда будет отставать). И что адреса таки заканчиваются видно, по тому, как процесс управления ими перешёл во вторую стадию — стадию вторичного рынка. Когда свободные резервы спекуляций и хомячаяния адресов закончится, начнётся этап суровой консолидации — то есть выкидывание всего неважного с адресов, перенос всех «на один адрес» и т.д. Примерно в это время IPv6 начнёт использоваться для реальной работы.

Впрочем, рассказ не про будущее IPv6, а про практику работы с ним. В Санкт-Петербурге есть такой провайдер — Tierа. И я их домашний пользователь. Это один из немногих провайдеров, или, может быть, единственный в городе, кто предоставляет IPv6 домашним пользователям. Пользователю выделяется один IPv6 адрес (для маршрутизатора или компьютера), плюс /64 сетка для всего остального (то есть в четыре миллиарда раз больше адресов, чем всего IPv4 адресов быть может — и всё это в одни руки). Я попробую не просто описать «как настроить IPv6», но разобрать базовые понятия протокола на практических примерах с теоретическими вставками.

Структура сети:

(Оригиналы картинок: github.com/amarao/dia_schemes)

• 1, 2, 3 — устройства в локальной сети, работают по WiFi
• 4 — WiFi-роутер, принужденный к работе в роле access point (bridge), то есть коммутатора между WiFi и LAN
• 5 — eth3 сетевой интерфейс, который раздаёт интернет в локальной сети
• 6 — мой домашний компьютер (основной) — desunote.ru, который раздачей интернета и занимается, то есть работает маршрутизатором
• 7 — eth2, интерфейс подключения к сети Tiera

Попытайтесь повторить это сами

Как правило, настроенный должным образом сервер Nginx на Linux, может обрабатывать 500,000 — 600,000 запросов в секунду. Но этот показатель можно весьма ощутимо увеличить. Хотел бы обратить внимание на тот факт, что настройки описанные ниже, применялись в тестовой среде и, возможно, для ваших боевых серверов они не подойдут.

Минутка банальности.

yum -y install nginx

На всякий пожарный, создадим бэкап исходного конфига.

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig
vim /etc/nginx/nginx.conf

А теперь можно и похимичить!

Мне всегда интересно читать посты от PVS-Studio о том, как они ищут баги в каком-нибудь опенсорсном проекте. Я решил, что я тоже смогу написать такой пост, только про Java. Существует совершенно замечательный бесплатный статический анализатор Java-кода FindBugs. О нём на удивление мало писали на Хабре.

Помимо анализатора кода для такой статьи требуется подопытный кролик. Нужен довольно большой проект, но при этом не настолько распространённый, чтобы разработчики идеально вылизывали код. Я выбрал проект Chemistry Development Kit (версия 1.4.19), которым доводилось пользоваться. FindBugs я установил как плагин к Eclipse, потому что мне так привычнее.

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

Обычной практикой является обработка данных мониторинга посредством RDBMS (таких как Oracle Database). Но способны ли традиционные реляционные базы данных справиться с такой нагрузкой? Попробуем в этом разобраться.