Всем привет!
Это моя первая публикация, надеюсь, что в дальнейшем буду писать часто.
Если что-то неправильно оформил, поправьте, я исправлю как надо.

В работе пришлось столкнуться с интересной особенностью работы DFS Replication. И хотя сам рассматриваемый вопрос не нов, набить на нем шишки могут многие.

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

Для примера я сделал тестовую среду, в которой всего два сервера — LAB-DC1 и LAB-FS1. На каждом из них есть папка C:\DFSR, между которыми и должна проходить репликация.

Копируем в эту папку на LAB-DC1 два тестовых файла и видим, что на второй сервер отреплицировался только один.



Почему?

Однажды я зашел на rememberthemilk.com и понял, что хочу такое же контекстное autocomplete меню в свой проект. В результате получился небольшой jquery плагин, который хочу презентовать в этом посте. Работает в ie6+, opera, safari, firefox, chrome (тестировал в последних версиях). В кратце расскажу в чем суть «контекстного» меню в RTM-стиле.

Это меню присоединяется к input-элементу, но, в отличие от обычных autocomplete меню, оно «всплывает» не для ввода всего значения элемента, а для какой-то логической части поля ввода. При этом меню позиционируется непосредственно под автодополняемым текстом. Вот как это выглядит:



Лицензия проекта — MIT / beerware.
Скачать библиотеку с примерами можно тут: js-context-autocomplete.googlecode.com/files/js-autocomplete-v5.tar
Последнюю ревизию забираем тут: svn checkout js-context-autocomplete.googlecode.com/svn/trunk js-context-autocomplete-read-only
Кому интересно поучаствовать в проекте — пишите в личку.
Временное online-demo (upd)

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

Предлагаю краткий обзор свежего UI-фреймворка от Telerik под названием Kendo UI.

Предыстория

Совсем недавно я размещал тикет в поддержке Telerik и спрашивал у них, можно ли использовать компоненты (в частности MVC) в приложении, написанном на Classic ASP.

Конечно, ответ огорчил.

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

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

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

Здравствуй, читатель! Как и обещал, продолжаю тестировать различные форматы документов в MS Office 2010 и LibreOffice 3.5. За время написания этого поста я успел проверить в работе форматы odt и docx — к сожалению, остался разочарован. Но не будем забегать вперед; под катом о том, как эти форматы обрабатываются в MSO и LO, а также небольшой сюрприз тестировщикам: как автоматизировать процесс генерации тестов для такой необычной области, как форматы документов.

Здравствуй, читатель! Ты когда-нибудь занимался переводом своего офиса/школы/института/друзей на Linux? Помнишь, как долго и упорно ты доказывал, что это — путь добра и света? А помнишь первую проблему, из-за которой пришлось все вернуть назад? Дай угадаю. Первый документ созданный в LibreOffice или OpenOffice отказался корректно открываться в MS Office? Слезы, сопли и мольбы оставить Linux ни к чему не привели? Утри нос, читатель! Под катом — о том, как подружить LibreOffice 3.5 и MS Office 2010 так, чтобы все везде открывалось одинаково.

Всем привет!

Вчера мне понадобилось скачать все фотографии из диалога с одним человеком в vk.com. Фотографий было больше 1000 штук. Понятное дело, что ручками это все делать было бы утомительно и… Стыдно. Не для того программированием занимаюсь, чтобы такую грязную работу делать не автоматизированно. Поэтому было решено написать скрипт.

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

Сам скрипт получился небольшой, но было бы интересно описать процесс создания. Буду стараться писать побольше комментариев в коде, чтобы те, кто не знает python, тоже смогли понять процесс. А от знатоков очень приветствуются советы и указания. Итак, приступим.

Предистория

Однажды на проекте, написанном на GAE Django, понадобилось реализовать тестирование с помощью Selenium. К сожалению, найти готовый инструмента для этого не удалось. Поиски по просторам интернета не дали положительных результатов.

Когда у меня встала необходимость разобраться, как сделать failover или load balancing, имея два и более каналов в мир, я нашел множество статей и инструкций, в которых описывались рабочие конфигурации. Но почти нигде не нашел разъяснения, как все работает, и описания отличий разных вариантов. Хочу исправить эту несправедливость и собрать простейшие варианты построения failover и load balancing конфигураций в одной статье.

Итак, у нас есть роутер, который соединяет нашу локальную сеть и два канала в интернет (основной ISP1 и резервный ISP2).

Давайте рассмотрим что же мы можем сделать:

Сразу предупрежу: несмотря на то, что в этой статье буду все описывать для mikrotik, не буду касаться темы скриптов

Рассмотрены примеры таких конструкций + некоторые очевидные, но не менее опасные конструкции, которых в коде желательно избегать. Статья рассчитана на python программистов с опытом 0 — 1,5 года. Опытные разработчики могут в коментах покритиковать или дополнить своими примерами.

От переводчика:

Я только начал изучать Python. С самого первого знакомства язык порадовал симпатичными конструкциями и синтаксически-гарантированной удобностью к чтению и пониманию кода.
В процессе освоения, при написании своего кода, бывает, сомневаюсь в правильности выбранных способов с точки зрения Python-way ( PEP 8 — Style Guide for Python Code, если угодно). Для вникания в идеологию программирования, в Python-сообществе кроме исчерпывающей документации, ко всеобщей радости, накоплено уже немало вспомогательных материалов, таких как статья Python Tips, Tricks, and Hacks, перевод которой недавно появился на Хабре
Мне понравилась статья Дэвида Гуджера «Пиши код, как настоящий Питонист: идиоматика Python» (David Goodger «Code Like a Pythonista: Idiomatic Python»). Для лучшего её усвоения решил оформить (в силу умения) полноценный перевод, потом показалось здравой идеей поделиться с Хабром.
Пока работал над переводом, пришло понимание, что статья существенно больше, чем показалась при прочтении ее в оригинале, поэтому постить буду частями, чтобы не выпасть из формата Хабра-статьи.
Продолжение и окончание перевода.

Введение

В статье хотелось бы поднять вопросы отличия использования Python для web-разработки по сравнению с оной на PHP. Надеюсь, статья не приведет к холиварам, так как она вовсе не о том, какой язык лучше или хуже, а исключительно о технических особенностях Python.

Это перевод 1.17 версии руководства от Rafe Kettler.

Содержание

1. Вступление
2. Конструирование и инициализация
3. Переопределение операторов на произвольных классах
   • Магические методы сравнения
   • Числовые магический методы
4. Представление своих классов
5. Контроль доступа к атрибутам
6. Создание произвольных последовательностей
7. Отражение
8. Вызываемые объекты
9. Менеджеры контекста
10. Абстрактные базовые классы
11. Построение дескрипторов
12. Копирование
13. Использование модуля pickle на своих объектах
14. Заключение
15. Приложение 1: Как вызывать магические методы
16. Приложение 2: Изменения в Питоне 3

Вступление

Что такое магические методы? Они всё в объектно-ориентированном Питоне. Это специальные методы, с помощью которых вы можете добавить в ваши классы «магию». Они всегда обрамлены двумя нижними подчеркиваниями (например, __init__ или __lt__). Ещё, они не так хорошо документированны, как хотелось бы. Все магические методы описаны в документации, но весьма беспорядочно и почти безо всякой организации. Поэтому, чтобы исправить то, что я воспринимаю как недостаток документации Питона, я собираюсь предоставить больше информации о магических методах, написанной на понятном языке и обильно снабжённой примерами. Надеюсь, это руководство вам понравится. Используйте его как обучающий материал, памятку или полное описание. Я просто постарался как можно понятнее описать магические методы.

Идея вводного курса по работе с Linux возникла у нас с коллегами довольно давно. Я с 2011 года занимаюсь биоинформатикой в Лаборатории алгоритмической биологии СПбАУ РАН (тут и тут мой напарник писал про то, чем мы занимаемся). Сразу нужно сказать, что работа биоинформатика без Linux практически невозможна, поскольку большинство биоинформатических программ созданы именно под эту операционную систему и работают только на ней.



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

На основе нашего опыта я и мой коллега Андрей Пржибельский (@andrewprzh) изначально собирались провести несколько занятий для биологов по компьютерной грамотности. А потом эта идея выросла в трехнедельный открытый онлайн-курс (MOOC) Института биоинформатики на русском языке, который позже был сужен до именно введения в Linux, как отправной точки, — поскольку вместить все в три недели оказалось очень и очень трудно. Курс уже начался и оказался достаточно популярен (на данный момент на него записалось более пяти тысяч человек), но первый дедлайн по заданиям — 24 ноября, поэтому еще можно присоединиться без потери баллов или просто изучать курс в свободном режиме (все материалы останутся открытыми).

Привет Хабравчанам!

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

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

В предыдущей статье мы рассмотрели простое взаимодействие клиентов SIP без использования Proxy-сервера. Такое взаимодействие на практике встречается чрезвычайно редко, но отлично подходит для того, чтобы понять основы SIP.

Теперь, когда мы разобрались с базовыми вещами, предлагаю перейти к реальной работе протокола.

Какие key-value хранилища вы используете в бою?

Позаимствовал список с сайта db-engines.com (кстати, очень любопытный сайт, рекомендую), включил все базы с ненулевой «популярностью» оттуда. Не отмечайте базы которые просто пробовали/интересно, а только те, что крутятся и приносят деньги вашей компании прямо сейчас.

Обратите внимание: MongoDB это НЕ key-value хранилище, однако за нее можно проголосовать, см. пункт «Хранилище документов в качестве key-value».

Пишите, если забыл какую-то популярную базу (т. е. забыли авторы сайта db-engines.com), добавлю в опрос.

Какие свойства key-value хранилища вам важны?

Наиболее распространенным методом аутентификации является аутентификация с использованием cookie файлов. Более современный метод аутентификации основан на использовании JSON Web Token (дословно: вэб маркер в формате JSON) и он быстро набирает популярность. В этой статье мы сосредоточимся на нем.

Что такое JSON Web Token?

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

JSON Web Token – это простой маркер в специальном формате. Пока формат не стандартизован, но многие уже используют одну из его реализаций (JWT).

JWT (произносится как jot) состоит из трех частей:

• Заголовок
• Полезная нагрузка
• Подпись

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

Сегодня довольно мало информации о протоколе AMQP (Advanced Message Queueing Protocol) и его применении, особенно на русском языке. А вообще это — замечательный, уже достаточно широко поддерживаемый открытый протокол для передачи сообщений между компонентами системы с низкой задержкой и на высокой скорости. При этом семантика обмена сообщениями настраивается под нужды конкретного проекта. Такие решения существовали и ранее, но это первый стандарт, для которого существует большое количество свободных реализаций.

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

Сегодня тема доставки информации в реальном времени является крайне актуальной (достаточно вспомнить хотя бы Twitter, Google Wave). И здесь системы передачи сообщений могут служить внутренним механизмом обмена данными, который обеспечивает доставку данных (изменений данных) клиентам.

Я не ставлю своей целью сегодня рассказать о том, как писать приложения для AMQP. Хочу лишь немного рассказать о том, что это совсем не страшно, не очень сложно, и действительно работает, хотя стандарт находится еще в развитии, выходят новые версии протокола, брокеров и т.п. Но это уже вполне production-quality. Расскажу лишь базовые советы, чтобы помочь “въехать” в протокол.

Пару недель назад разработчики Google Chromium опубликовали новость о поддержке технологии WebSocket. В айтишном буржунете новость произвела эффект разорвавшейся бомбы. В тот же день различные очень известные айтишники опробовали новинку и оставили восторженные отзывы в своих блогах. Моментально разработчики самых разных серверов/библиотек/фреймворков (в их числе Apache, EventMachine, Twisted, MochiWeb и т.д.) объявили о том, что поддержка ВебСокетов будет реализована в их продуктах в ближайшее время.
Что же такого интересного сулит нам технология? На мой взгляд, WebSocket — это самое кардинальное расширение протокола HTTP с его появления. Это не финтифлюшки, это сдвиг  парадигмы HTTP. Изначально синхронный протокол, построенный по модели «запрос — ответ», становится полностью асинхронным и симметричным. Теперь уже нет клиента и сервера с фиксированными ролями, а есть два равноправных участника обмена данными. Каждый работает сам по себе, и когда надо отправляет данные другому. Отправил — и пошел дальше, ничего ждать не надо. Вторая сторона ответит, когда захочет — может не сразу, а может и вообще не ответит. Протокол дает полную свободу в обмене данными, вам решать как это использовать.

Я считаю, что веб сокеты придутся ко двору, если вы разрабатываете:
— веб-приложения с интенсивным обменом данными, требовательные к скорости обмена и каналу;
— приложения, следующие стандартам;
— «долгоиграющие» веб-приложения;
— комплексные приложения со множеством различных асинхронных блоков на странице;
— кросс-доменные приложения.