Странно, что про этот крайне популярный и полезный чип до сих пор не было статьи на Хабре. Считаю необходимым восполнить этот пробел. В статье будет описано несколько интересных способов применения чипа FTDI FT232H и его аналогов для различных прикладных целей.
Пару слов о нем: относительно дешевый, простой в разводке и программировании, распространенный конвертер USB 2.0 <-> последовательные протоколы (USART, SPI, I2C, JTAG TAP и просто GPIO bit-bang), хорошо подходящий как для изготовления собственных устройств с подключением к ПК по USB, так и для тестирования и отладки других устройств.
Из простой breakout-платы на этом чипе легко и непринужденно можно сделать UART-конвертер, SPI-программатор, JTAG-отладчик, I2C-master, конвертер GPIO bit-bang (а с ним и остальных протоколов, не требующих запредельных частот и стойких к возможным задержкам, вносимым USB-стеком, к примеру, Dallas 1-wire).
Если вышеуказанные возможности сумели вас заинтересовать — прошу под кат.

Wireshark — это достаточно известный инструмент для захвата и анализа сетевого трафика, фактически стандарт как для образования, так и для траблшутинга.
Wireshark работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс на основе GTK+ и мощнейшую систему фильтров.
Кроссплатформенный, работает в таких ОС как Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Mac OS X, и, естественно, Windows. Распространяется под лицензией GNU GPL v2. Доступен бесплатно на сайте wireshark.org.
Установка в системе Windows тривиальна — next, next, next.
Самая свежая на момент написания статьи версия – 1.10.3, она и будет участвовать в обзоре.

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

Начинаем плаванье

Для начала захвата достаточно выбрать свой сетевой интерфейс и нажать Start.

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

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

Много лет location.hash был способом в AJAX-приложении заставить работать кнопки «Назад» / «Вперёд» и, например, добавить определенное состояние страницы в избранное и вернуться к нему позже.

Сейчас, когда HTML5 считается нормой, пора обратить свое внимание на History API и забыть про location.hash. HTML5 History API проще для понимания и позволяет сделать URL чуточку красивее (без кракозябры # или #! если вы имеете дело с индексированием ajax приложения).

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



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

Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

Хочу отметить, что эта инструкция родилась в процессе миграции web-систем компании Acronis в высокодоступный кластер. Надеюсь мои заметки будут полезны и для Вас!.

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

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

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

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Встроенный Perl.

Привет, Хабр!
Аккурат к инициативе поддержки стартапов, озвученной deniskin, мы в ФРИИ продолжаем знакомить сообщество с темой бизнес-инкубаторов и акселераторов. В прошлой статье мы детально разобрали, в чём различие между бизнес-инкубаторами и акселераторами. Сегодня — расскажем о том, куда же, собственно, идти.

От переводчика: Это вторая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья написана по мотивам выступления Ллойда Хилайеля на конференции Node Philly 2012 в Филадельфии.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

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

Кроме того, мы представим модуль compute-cluster — маленькую библиотеку, которая облегчает управление коллекцией процессов для выполнения распределённых вычислений.

Постановка задачи

Для Persona нам было необходимо создать сервер, который справился бы с обработкой множества запросов со смешанными характеристиками. Мы выбрали для этой цели Node.js. Нам надо было обрабатывать два основных типа запросов: «интерактивные», которые не требовали сложных вычислений и должны были выполняться быстро, чтобы интерфейс приложения был отзывчивым, и «пакетные», которые отнимали примерно пол-секунды процессорного времени и могли быть ненадолго отложены без ущерба для удобства пользователя.

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

• Насыщение. Наше решение должно было использовать все доступные ядра процессора.
• Отзывчивость. Пользовательский интерфейс должен оставаться отзывчивым. Всегда.
• Отказоустойчивость. Когда нагрузка зашкаливает, мы должны нормально обслужить столько клиентов, сколько сможем, а остальным показать сообщение об ошибке.
• Простота. Решение должно легко и постепенно интегрироваться в уже работающий сервер.

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

Введение

В один прекрасный день я получил по почте извещение о долге за горячую воду, по причине несвоевременного оповещения коммунальных служб о показаниях водомеров. К этому моменту я, праздного любопытства ради, осваивал WiFi радиомодуль от “Roving Networks” с целью «обучить» его дистанционно включать/отключать электрический водонагреватель для экономии электроэнергии при долгом отсутствии пользователей. И так все сошлось, что решил я свести эти задачи и еще некоторые задумки «умного дома» к практической реализации. Ну и конечно, было бы не интересно, если бы я использовал знакомые мне технологии, поэтому я решил использовать как можно больше нового и интересного.

Доброго времени суток, уважаемые хабравчане. С прошедшим вас днем программиста. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

Cloudconvert

Великолепный онлайн конвертер файлов, который поддерживает в общей сложности 140 форматов следующих типов: archive, audio, cad, document, ebook, image, presentation, spreadsheet, video. Синхронизируется с Dropbox и Google Drive, благодаря чему возможно использование на всех смартфонах. А самое приятное это то, что для данного сервиса существует функциональное и простое API.

Я, будучи разработчиком мобильных приложений, часто нуждаюсь в backend-сервисах для хранения пользовательских данных, авторизации и прочего. Конечно, для подобных задач можно использовать BaaS (Parse, Backendless, etc…). Но свое решение — это всегда более удобно и практично.

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

В данной статье будет рассмотрено построение REST API для мобильного приложения на Node.js с использованием фреймворка Express.js и модуля Mongoose.js для работы с MongoDB. Для контроля доступа прибегнем к технологии OAuth 2.0 с помощью модулей OAuth2orize и Passport.js.

Пишу с позиции абсолютного новичка. Рад любым отзывам и поправкам по коду и логике!

Содержание

1. Node.js + Express.js, простой web-сервер
2. Error handling
3. RESTful API endpoints, CRUD
4. MongoDB & Mongoose.js
5. Access control — OAuth 2.0, Passport.js

Сайт моего друга недавно был взломан, на нем была запущена старая версия IP.Board, в которой есть уязвимость локального внедрения кода (local file inclusion). Этот пост не будет посвящен IP.Board или другому php коду, он покажет, как найти потенциально вредоносный php код на ваших серверах. Наконец, покажу пример того, что злоумышленники могут загрузить на взломанный сайт.

Проверьте логи доступа

Что бы с чего-то начать, я бы хотел поделиться некоторыми записями из журнала доступа (access log) взломанного сайта моего друга.

IpreMOVED - - [01/Mar/2013:06:16:48 -0600] "POST /uploads/monthly_10_2012/view.php HTTP/1.1" 200 36 "-" "Mozilla/5.0"
IpreMOVED - - [01/Mar/2013:06:12:58 -0600] "POST /public/style_images/master/profile/blog.php HTTP/1.1" 200 36 "-" "Mozilla/5.0"

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

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

Рассмотрим подробнее приведенные выше строки журнала, ничего не цепляет вас?

Обратите внимание, что в журнале доступа POST запросы, а не GET запросы.
Скорее всего, злоумышленники хотели сделать журнал доступа более неприметным, так как большинство журналов не сохраняют post данные.

Приветствую, хаброжители!
В этой статье я хочу поделиться опытом развертывания кластера Master-slave на СУБД PostgreSQL. Отказоустойчивость достигается с помощью возможностей pgpool-II (failover, online recovery).
pgpool — это прекрасное средство для масштабирования и распределения нагрузки между серверами и, думаю, немногие знают о возможностях автоматического создания failover на ведомом сервере при отказе ведущего и как добавить новые мощности в уже работающий кластер без отключения всего кластера.

Некоторое время назад зам.главы московского офиса разработки Badoo Алексей Рыбак и ведущие IT-Компот записали выпуск подкаста «Архитектура высоконагруженных приложений. Масштабирование распределенных систем".

Сейчас мы сделали расшифровку подкаста, привели ее в удобный для чтения вид и разбили на 2 части.

О чем говорили в первой части:

• Общая информация о проекте Badoo: стек технологий, характер и объем нагрузки, посещаемость.
• Горизонтальное масштабирование проекта:

— веб-сервера, кеширование, мониторинг etc;
— подводные камни при масштабировании проекта;
— масштабирование баз данных, как правильно делать шардинг.

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

Благодаря новому проекту Google и журнала Time появилась возможность увидеть, как изменялась поверхность Земли последние 30 лет. В сотрудничестве с Геологической службой США (USGS) и НАСА они собрали вместе изображения планеты, сделанные из космоса за более четверть века, и составили из них интерактивную покадровую карту.

Эту карту, которая, как пишут в блоге Google, состоит из миллионов спутниковых снимков и триллионов пикселей, можно посмотреть на сайте Timelapse. Кроме истории расширения родного города, можете увидеть, как строились искусственные Пальмовые острова в Дубае, как отступает ледник Колумбия на Аляске, как вырубались леса Амазонки и как рос Лас-Вегас с 1984 по 2012 год.

update: Мы ещё живы и наконец-то открыли продажи!готовим первую партию к продаже конце сентября.
Новая версия стала куда лучше и выглядит теперь вот так:


Подробности в нашем блоге.
/update

TL;DR (Abstract)

Мы сделали маленький «одноплатный» встраиваемый компьютер с хорошим набором периферии, в основном беспроводной (GSM/GPRS, NFC, Wi-Fi, GPS, Ethernet, etc). Рабочее название — Wiren Board (от Wireless Enabled)

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

Первая версия уже готова, открыт предзаказ.

Что привело нас к разработке встраиваемого компьютера, через какие этапы мы прошли, и что в итоге получилось — читайте дальше.

Хочу предоставить вашему вниманию библиотеку Vow, которую написал мой коллега Дмитрий Филатов dfilatov.

Библиотека реализует Promises/A+, работает очень быстро и требует малого объема памяти. По тестам производительности сильно опережает Q, но при этом сохраняет асинхронную манеру работы.

Работа с Vow выглядит так же просто, как работа с Q. Из недостатков (по сравнению с Q) можно лишь выделить отсутствие progress.

Пример кода с использованием Vow:

function readFile(filename, encoding) {
    var promise = Vow.promise();
    fs.readFile(filename, encoding, function(err, data) {
        if (err) return promise.reject(err);
        promise.fulfill(data);
    });
    return promise;
}
Vow.all([readFile('test1.txt', 'utf8'), readFile('test2.txt', 'utf8')]).then(function(results) {
    console.log(results.join('\n'));
});

Буквально недавно мы с товарищами запустили наш первый проект под iOS — игрушку про змейку Shadow Snake. Хотелось опробовать разработку под iPad, поэтому решили перенести уже готовый проект, сделанный на Flash, тем более, что механика позволила очень гармонично использовать возможности сенсорного управления.

Конечно, первой идеей было попробовать AIR SDK — проект запустился, но из динамичной аркады он превратился в аркаду “походовую”. FPS был ужасно низким отчасти из-за того, что практически вся графика во флешке была векторной, а мобильный AIR с ней не очень дружит. Я уже не помню точно, какой AIR на тот момент был доступен (2.x или первые версии 3.x), но мы проводили эксперименты как с векторной графикой, так и с другим проектом, сделанным в растре на Flixel. Результаты не очень нас обрадовали. Сейчас, я смотрю, прогресс сдвинулся, Adobe даже выпустила какой-то новый компилятор. В любом случае, в то время было решено использовать Unity 3D.

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

Встала задача, как перенести графику и анимации (в том числе составные) в новый проект.

Всем привет!

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

Мы столкнулись с необходимостью автоматизировать сборку и деплоймент на тестовые устройства, когда размер парка устройств превысил два десятка, а количество проектов, одновременно находящихся в QA достигло 30+. При таких объемах деплоймент билда на тестовые устройства с помощью “Build & Run” в XCode начал заметно затормаживать процесс прохождения QA. Было принято решение об автоматизации процесса сборки и заливки билдов на устройства.

Наша обновленная билд-система состоит из трех основных компонентов:

• Репозитории с исходными кодами проектов;
• Сервер сборки;
• Сервер раздачи билдов на устройства.

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

• Разработчик делает коммит версии в репозиторий;
• Билд-сервер запускает сборку соответствующего проекта;
• В случае успешной сборки, билд выкладывается на сервер раздачи;
• Итоговый IPA устанавливается на устройства “по воздуху”.