Основным камнем преткновения для повсеместного внедрения электронного документооборота в России до сих пор являлось отсутствие единых правил формирования документов для передачи из одной СЭД в другую. Таким образом, не было никакой гарантии, что электронный документ одной организации смогут правильно прочесть и тем более использовать в другой. Теперь ситуация изменилась: принят ГОСТ с длинным названием «Системы электронного документооборота. Взаимодействие систем управления документами. Требования к электронному сообщению».

О том, почему этот ГОСТ так нужен и что он может изменить – под катом.

Несмотря на то, что распределенные системы контроля версий (Git, Mercurial, Bazaar) набирают все большую популярность, старый добрый Subversion по-прежнему широко используется. В данной статье я рассмотрю плюсы и минусы использования на практике внешних зависимостей (svn:externals) в SVN репозиториях.

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

За этот год (а ведь и вправду прошло больше года) я поменял место работы и занимаюсь совершенно другими вещами и давно уже не программирую (много не программирую, если быть точным) на PHP. Новый проект обязал меня совершенствоваться в python'е (и ощутить его силу), поэтому однажды воскресным вечером было решено переписать и, главное, улучшить некоторые из своих библиотек для чтения текста. Сегодня я представлю на суд публики молодой opensource-проект Miette («вкусняшка», если переводить с французского), который призван (в каком-никаком будущем) читать файлы пакета Microsoft Office.

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

Естественно python во многом отличается от PHP и, на мой взгляд, имеет несколько больший функционал, поэтому и принцип построения библиотек в проекте несколько другой, нежели старая «поделка» на PHP. В данном случае было решено запретить себе, как разработчику и заказчику в одном лице, загружать какие-либо большие блоки в память. Мьетт читает данные постепенно, по требованию, как это делает сам Word. Это делает его легковесным и нетребовательным к оперативной памяти. В будущем, я постараюсь пройти исходные profiler'ем и найти узкие горлышка, которые стоит оптимизировать дальше.

Идём дальше?

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

В прошлом году (апрель 2009) я писал о питерском проекте «Бабушка-ОнЛайн», в котором я и сам участвую. Проект посвящен бесплатному обучению пенсионеров, ветеранов, блокадников и инвалидов основам компьютерной грамотности. Кто ещё не знаком с ним, может послушать интервью радио «Эхо Москвы» и посмотреть видеорепортаж телеканала «Вести». Давно я не делился новостями и информацией о нём, и вот исправляю это упущение. Проект жив и движется. Благодаря и читателям хабра, и многим другим откликнувшимся людям и организациям, к концу 2009 года мы довели количество классов до 12 штук, к ноябрю 2010 года – до 21, и постараемся к концу декабря довести до 30, а обучить к данному моменту мы успели более тысячи пенсионеров и ветеранов. Более подробную статистику можно посмотреть на нашем сайте в разделе «Новости / Новости проекта / Годовой отчёт за 2010 год». Спасибо огромное всем, кто нам помогал!

Но мы стараемся развивать проект не только экстенсивно, и в связи с этим решили провести форум-выставку инновационных технологий для людей пожилого возраста и людей с особым социальным статусом. Там и мы, и другие специализирующиеся на разных, в том числе и компьютерных, технологиях фирмы поделимся нашими наработками. Если кто хочет увидеться с нами в оффлайне, поспрашивать, записаться в команду – добро пожаловать 2 и 3 декабря 2010 года с 10:00 до 18:00 в «Центральный музей связи» в Санкт-Петербурге. Выставка, как и весь наш проект, бесплатна. Надеюсь, что получится сделать обзорную экскурсию по ней, и поделиться с хабровчанами информацией об интересных разработках. Всю необходимую информацию можно посмотреть на сайте socialnyforum.ru, узнать в офисе по телефону +7 (812) 317-85-53, ну и спросить в комментариях. Приглашаем всех желающих!

UPD: подумал ночь, и решил перенести топик в «Стартапы» — ведь в нём о нас и написали в прошлом году.

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

Так уж получилось, что мы, работая в компании ГдеЭтотДом (я и anei), относительно часто ходим обедать в МуМу. Остаток от обеда обычно представляет собой фирменную конфетку. Которую мы не едим — вот такое несоответствие типов.

Но мы нашли выход, скармливая их Валерке.
Я, честно говоря, не знаю, причем тут программирование, Валерка и конфетки, но, в общем, однажды…
Подходит Александреску к Валерке и говорит:

Предположим, что у нас есть 100 млн. долларов, которые нужно вложить в несколько возможных инвестиций. Каждое из этих вложений имеет различную стоимость и различный ожидаемый доход. Мы должны решить, как потратить деньги, чтобы получить максимальную прибыль.
Задачи такого типа называются задачами формирования портфеля. У нас есть несколько позиций (инвестиций), которые должны поместиться в портфель фиксированного размера (100 млн. долларов). Каждая позиция имеет свою прибыльность. Необходимо найти набор позиций, которые помещаются в портфель и дают максимальную прибыль.
Многие из вас скажут, что никакие эвристики тут не нужны, и что вполне можно обойтись полным перебором. Другие заявят, что и полный перебор не нужен, ведь существует метод ветвей и границ. Но как быть, если количество возможных инвестиций 65? Полное дерево решений содержит более 7*10^19 узлов. Предположим, что метод ветвей и границ перебирает десятую часть процента этих узлов, а компьютер проверяет миллион узлов в секунду. В этих условиях для решения задачи потребовалось бы более 2 млн. лет. Именно для таких сложных задач и используются эвристики. Если вам интересно, милости прошу под кат.

Данная статья давно назревала в моей голове, но совсем в ином формате.
Прочитав последние несколько неуклюжих статей на тему WEB-сервисов (например: http://habrahabr.ru/blogs/development/108973/) и применения в них REST технологии, решил что настало время все-таки откинуть лень, выделить время и написать «переформатированную» в своей голове статью.
Итак, кратко, что Вы найдете в статье и кому она будет полезна:

— новичкам, которые интересуются или планируют написать WEB-сервис для проекта
— профи вряд ли найдут что-то новое для себя
— общая идеология REST
— применение CRUD в WEB-сервисах
— принципы KISS при построении раутеров
— лучшие практики
— немного пиара ;)
— ссылки, литература

С 14 по 18 июня 2011 года в Санкт-Петербурге пройдёт 6-я Международная конференция Computer Science Symposium in Russia (CSR 2011). Темы конференции включают в себя алгоритмы и структуры данных, комбинаторную оптимизацию, теорию сложности вычислений, криптографию, комбинаторику, формальные языки и автоматы и др. Крайний срок подачи статей — 6 декабря 2010 года. Подробности на сайте конференции: http://logic.pdmi.ras.ru/csr2011
Ниже приведён список приглашённых докладчиков конференции.

Есть javascript код:

1. var A = function () {};
2. A.prototype.b = 100;
3. var a = new A();
4. A.prototype.c = 101;
5. a.c = -100;
6. A.prototype = {};
7. A.prototype.b = 536;
8. /* 1 */ console.log(a.__proto__.constructor.prototype.b === 536);
9. var b = new A();
10. /* 2 */ console.log(a.__proto__.__proto__.constructor === a.__proto__.constructor.prototype.constructor);
11. /* 3 */ console.log(b instanceof A);
12. /* 4 */ console.log(!(a instanceof Object));

Вопрос. Что возвратят выражения 1-4 и почему?

Затрудняетесь ответить?
Тогда вам стоит пройти под кат ;-) (Далее 600 Кб больших изображений)

При разработке одного проекта встала задача – определить по IP-адресу посетителя его страну и город, на русском языке. Поиск готового решения оказался безуспешным – русскоязычные базы стран можно найти (например, wipmania.com), но баз городов нет. Помощь пришла из-за границы, в лице англоязычного maxmind.com. База была приведена к нормальному состоянию (MySQL) и частично переведена на русский язык с помощью нескольких справочников (~6,000 названий, с учетом городов-тезок ~15,500).   Результат этой работы доступен для свободного скачивания.

Задача

Допустим вы хотите выполнить два или более AJAX запроса на сервер и вызвать функцию после того, как все они будут закончены.

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

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

Собственно, этим и занимается мой небольшой класс WaitSync =)

WaitSync.js

Пользоваться элементарно просто:

1. Создаем объект типа WaitSync, передав в конструктор callback функцию, которая будет вызвана после того, как отработают нужные задачи.

	var vulture = new WaitSync(function () {
		console.debug('Start eating: ', arguments);
	});

2. Вместо простого

	$.getJSON(
		'savannah/get_prey', 
		function (data) {
			console.log('... prey found: ' + data);
		}
	);
	
	$.getJSON(
		'savannah/get_other_predators', 
		function () {
			console.log('... predators are done eating');
		}
	);

«заворачиваем» задачи в метод .wrap

	$.getJSON(
		'savannah/get_prey', 
		vulture.wrap( 
			function (data) {
				console.log('... prey found: ' + data);
			}
		)
	);
	
	$.getJSON(
		'savannah/get_other_predators', 
		vulture.wrap(
			function () {
				console.log('... predators are done eating');
			}
		)
	);

3. Все =) Как только будут выполнены оба AJAX запроса, стервятник начнет есть.

На форуме на 3DNews некто, представившийся как инженер Новосибирского Завода ХимКонцентратов («РосАтом») описывает устройсво произодства. Позволил себе копи-пэйст, не обессудьте…

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

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

Так как большинство авторов не удосуживается хотя бы залезть в документацию, то обычно в таких статьях вся информация базируется на неких слухах и пересказах слухов. Эти слухи бродят по сети и поражают википедию, хабрахабр и другие уважаемые ресурсы. В результате получаются опусы вроде "Вы наверное шутите, мистер Дал, или почему Node.js" (пунктуация автора сохранена): она, в основном, верная по сути, но изобилует неточностями, содержит ряд фактических ошибок и изображает предмет с какого-то непонятного ракурса.

Мне было сложно пройти мимо статьи, изобилующей фразами вроде «эффективные реализации polling'а на сегодняшний день имеются лишь в *nix-системах» (как будто poll() есть где-то, кроме некоторых *nix). Этот пост начинался как комментарий, разъясняющий уважаемому inikulin ошибки в его статье. В процессе написания оказалось, что проще изложить предмет с самого начала, что я собственно и делаю отдельным постом.
В моем очерке нет срыва покровов или каких-то неизвестных трюков, здесь просто описываются преимущества и недостатки разных подходов человеком, который проверял, как всё это работает на практике в разных операционных системах.
Для желающих просветиться — добро пожаловать под кат.

Javascript — очень изящный язык с кучей интересных возможностей. Большинство из этих возможностей скрыты одним неприятным фактором — Internet Explorer'ом и другим дерьмом, с которым нам приходится работать. Тем не менее, с приходом мобильных телефонов с актуальными браузерами и серверного JavaScript с нормальными движками эти возможности уже можно и нужно использовать прям сейчас. Но по привычке, даже при программировании для node.js мы стараемся писать так, чтобы оно работало в IE6+.

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

function Foo(bar){
    this._bar = bar;
}

Foo.prototype = {
    get bar () {
        return this._bar;
    },
    set bar (bar) {
        this._bar = bar;
    }
};

OpenDPI — библиотека для классификации трафика на основе технологии глубокого анализа пакетов (DPI — Deep Packet Inspection). Проект IPP2P более не поддерживается, и, в качестве замены, предлагает использовать именно OpenDPI. В отличие от IPP2P, основной целью которого является определение именно p2p трафика, OpenDPI поддерживает широкий набор различных протоколов. OpenDPI изначально спроектирован для очень низкого уровня ложных положительных срабатываний. В отличие от L7-filter не требует наложения патчей на iptables и ядро; работает в виде модуля ядра и библиотеки xtables. Также определения протоколов представляют собой не список регэкспов, а модули на C, что повышает быстродействие. Недавно для этой библиотеки была реализована поддержка iptables.
А теперь давайте попробуем использовать OpenDPI на практике.

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

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

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

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

В своей предыдущей статье я вкратце коснулся темы создания High Availability решения на основе демона heartbeat. Однако, как выяснилось, что-то сложнее чем 2-х узловой кластер на нем делать не так уж удобно. Изучение проблемы вывело меня на след проекта Pacemaker. Его-то мы сейчас в кратце и рассмотрим.

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

ID	1
Summary	Никто не знает про открытые проекты Яндекса
Description	У наших разработчиков уже довольно много опубликованных компонентов, библиотек и готовых решений. Их никто особенно не скрывает, но также про них никто и не рассказывает. Надо рассказать!