Почти все знают что такое GPG. Многие им пользуются. Некоторые даже в курсе, что есть возможность хранить секретные ключи на внешнем носителе типа смарт-карты. Я-же хочу описать как это все выглядит на практике.

Несколько дней назад ко мне приехала пара «OpenPGP SmartCard v2». Заказаны они были у официального их распространителя — shop.kernelconcepts.de/index.php?language=en. Цена одной карты на данный момент составляет 17.14 евро. Две заказанные карты были отправлены чем-то вроде заказного письма и пересылка обошлась мне в 5 евро, что очень даже неплохо. Еще порадовало что карты без проблем прошли через таможню. Не уверен что так будет с большим количеством, но для личного использования, думаю, можно заказывать достаточно безопасно.

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

IP-адрес (v4) состоит из 32-бит. Любой уважающий себя админ, да и вообще айтишник (про сетевых инженеров молчу) должен уметь, будучи разбуженным среди ночи или находясь в состоянии сильного алкогольного опьянения, правильно отвечать на вопрос «из скольки бит состоит IP-адрес». Желательно вообще-то и про IPv6 тоже: 128 бит.

Обстоятельство первое. Всего теоретически IPv4-адресов может быть:
2³² = 2¹⁰*2¹⁰*2¹⁰*2² = 1024*1024*1024*4 ≈ 1000*1000*1000*4 = 4 млрд.
Ниже мы увидим, что довольно много из них «съедается» под всякую фигню.

Записывают IPv4-адрес, думаю, все знают, как. Четыре октета (то же, что байта, но если вы хотите блеснуть, то говорите «октет» — сразу сойдете за своего) в десятичном представлении без начальных нулей, разделенные точками: «192.168.11.10».

В заголовке IP-пакета есть поля source IP и destination IP: адреса источника (кто посылает) и назначения (кому). Как на почтовом конверте. Внутри пакетов у IP-адресов нет никаких масок. Разделителей между октетами тоже нет. Просто 32-бита на адрес назначения и еще 32 на адрес источника.

Пару недель назад разработчики tornado добавили нативный модуль по созданию inline callback (аналог inlineCallbacks в Twisted, Seq в Node.js, Fibers в Ruby).
Ниже примеры использования и примеры с участием asyncmongo (асинхронным драйвером для mongoDB)

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

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

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

Холивары о том, кто из них лучше, не утихают уже лет десять, авторитетное издательство Bärenreiter (музыканты его очень любят, хоть и ругаются на дорогие ноты) тем временем используют написанную на Фортране SCORE, а музыканты — любители свободных программ смотрят на LilyPond и ужасаются, потому что как же обычному человеку жить без WYSIWYG'а?

Если бы не TeX-подобный синтаксис, я уверен, многие бы использовали этот engraver. Именно engraver — переводы «гравировщик» и «наборщик» не подходят здесь, потому что этими словами обозначаются профессии. LilyPond лучше других коммерческих и бесплатных программ располагает нотный текст равномерно по странице.

Сравнение с популярными программами

Это мелодия небезызвестной темы, набранная в трёх разных программах (LilyPond, Finale, Sibelius)


В LilyPond не делалось ничего кроме набора, в Сибелиусе и Finale удалены лишние такты, также в последней ноты принудительно автоматически расставлены по горизонтали.

При попытке отредактировать этот старый пост слетело всё форматирование. Может быть я его когда-нибудь исправлю.

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

Основные преимущества:

• Делая push из удалённой копии мы автоматически обновляем live-копию сайта
• Правки файлов на сервере не будут разрушать историю коммитов
• Простота, не нужны особые правила выполнения коммитов
• Можно применить к уже запущенному сайту, без повторного деплоя или перемещения файлов

Доброго времени суток читатель.

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

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

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

Для тех кому интересны подробности — прошу под кат.

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

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

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

Одним из незамеченных героев вселенной HTML5 является XMLHttpRequest 2. Строго говоря XHR2 не является частью HTML5 и не является самостоятельным объектом. XHR2 это тот же XMLHttpRequest, но с некоторыми изменениями. XHR2 является неотъемлемой частью сложных веб-приложений, поэтому ему стоит уделить большее внимание.

Наш старый друг XMLHttpRequest сильно изменился, но не многие знают о его изменениях. XMLHttpRequest Level 2 включает в себя новые возможности, которые положат конец нашим безумным хакам и пляскам с бубном вокруг XMLHttpRequest: кросс-доменные запросы, процесс загрузки файлов, загрузка и отправка двоичных данных. Эти возможности позволяют AJAX уверенно работать без каких-либо хаков с новейшими технологиями HTML5: File System API, Web Audio API, и WebGL.

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

Как и было обещано, мы выпускаем под LGPL нашу библиотеку эмуляции эмулятора терминала linux, которую мы используем для показа консолей виртуальных машин в облаке. Называется она, соответственно, pyte (PYthon Terminal Emulator).

По нашим собственным оценкам, покрытие «текстового» функционала console_codes приближается к 100% (от 80 до 90%, как подсказывают пессимисты из числа оппортунистов среди разработчиков).

Не реализованы: коды загрузки шрифтов в знакогенератор VGA-адаптера, управление энергосбережением VESA, звуковая сигнализация (коды управления частотой и длительностью звука), управление палитрой, собственные чарсеты; в общем всё то, что не имеет отношения к тексту.

Зато реализованы все остальные сложные функции, такие, как блокировка регионов экрана для записи, скроллинга, управление режимами переноса строк, правильная обработка атрибутов при различных видов удаления текста и т.д. — всё то, что нужно существующим приложениям, таким как nano, adom (на картинке фрагмент ESC-кодов и получающегося изображения как раз из ADOM'а), vim, emacs, mc, aptitude, dialog, yast2 и т.д. для полноценной отрисовки.

Библиотека написана на питоне и заточена под удобство манипуляций над экраном, абстрагируясь от графического представления изображения, что позволяет её использовать в коде, осуществляющим дальнейшие преобразования (например, передачи экрана в JS или сериализации в БД).

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

История создания

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

Я уже некоторое время ковыряю TDD и задача постоянного контроля качества для меня становится всё актуальней. Особенно при пополнении команды новыми разработчиками.

Сначала я запускал тесты руками: save, switch, $ nosetests. Потом к тестам добавились проверялки качества кода и пришлось всё засунуть в скрипт:
pyflakes *.py
pep8 *.py
pylint *.py
nosetests

Скрипт запускать каждый раз ужасно лениво, поэтому небольшая оболочка на inotifywait стала запускать тесты и проверки после каждого сохранения:
while true; do
inotifywait -e modify project/*.py -qq; clear
./do_tests
done

Тут я стал более-менее доволен происходящим и даже на некоторое время расслабился. Но ведь программист кроме того, что ленив ещё и горд, поэтому результаты хочется кому-нибудь показать. Чтобы вести историю происходящего (которая очень помогает когда заходит начальник начальника и спрашивает: «ну-с, чем вы занимались последний месяц?») уже есть система контроля версий. Но она показывает только, что сделано и не даёт обзора успешности каждой ревизии. Получается что код лежит, но непонятно в каком он состоянии и что где ещё надо сделать.

Кроме того довольно тяжело следить за коллегами, которые тоже могут что-то сделать и забыть прогнать тесты, в результате в репозитории лежит битый код, не прошедший code review и при очередном pull может внезапно начаться clusterfuck.

И тут очень вовремя kmmbvnr@lj выпустил скринкаст, в котором он демонстрировал интеграцию тестирования для django-проектов с сабжем Jenkins (бывш. Hudson). Посмотрел я на все эти красоты, графики и отчёты и тоже захотел чтобы всё само пело и играло. Но у него django-jenkins, как и следует из названия, встраивается в джангу и генерит отчёты используя хитрую систему. Мой проект до джанги не дорос и скорее всего не дорастёт — это достаточно тривиальное WSGI-приложение, которое правда стремительно разрастается. Пришлось поднимать всё с нуля.

Воскресенье я на это убил, но в целом всё довольно прямолинейно и теперь у меня есть симпатичные отчёты:



Что внутри?

В первой части я рассказал как настроить Android смартфон для работы с SL4A (Scripting Layer for Android), показал как вызывать системные всплывающие окна, получать из них введенную пользователем информацию и выводить в них результат работы. В этой же части я расскажу о построении интерфейса к приложению с помощью WebViews. Если коротко, то WebViews это способ построить интерфейс приложения с помощью HTML, JavaScript и CSS. Если учесть, что в Android смартфонах полнофункциональный webkit, то построение интерфейса не такая уж и проблемная задача.

Это продолжение статьи про основы LibCanvas. Если первая часть затрагивала теоретические засады, то в этой части мы перейдём к практике и постараемся реализовать совсем базовые и простые вещи. Цель статьи — осилить самые основы LibCanvas, мы напишем очень простые скрипты, малопригодные для использования в реальной жизни, но вы их можете развить во что-то великое.

Добрый день. Один из самых частых вопросов про LibCanvas сейчас — «С чего начать?». Согласен, порог вхождения в эту библиотеку чуть выше, чем в более простые canvas-библиотеки, потому в этом топике я раскрою основы LibCanvas — базовые понятия и принципы, отрисовка примитивных фигур, события мыши, клавиатуры, анимация, расширенный контекст, поведения. Постараюсь описать всё это с множеством примеров и максимально доступным языком.

Надеюсь, статья даст ответы на вопросы: Что такое LibCanvas? Зачем он нужен и какие его преимущества? С чего начать?

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

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

Эмулятор который идет в комплекте с Android SDK, не очень шустрый.
Основная идея использовать VirtualBox + Android X86, для преодоления проблем с производительностью.

Что нам необходимо:
Среда разработки Eclipse + Android SDK тут,
а также VirtualBox.

Под катом много картинок, и процесс установки, а также некоторые полезные советы.

Посмотрел видеозаписи с конференции Mongo Moscow.
Вот тезисы о возможностях, оставшиеся от просмотренного.
Перевод был не ахти, смотрел на английском, мог что-нибудь напутать.
Старался быть объективным, если не получилось — пишите :)