Всем доброго времени суток!

Недавно при прототипировании одной из частей разрабатываемого нами продукта возникла одна интересная задача: нужно было проверить склейку Python и C++. Связано это было с тем, что основной код был написан на плюсах, и необходимо было подключить внешнюю библиотеку Websockets, написанную на Python (на тот момент не было соответствующей библиотеки на C++). Схема взаимодействия при такой задаче достаточно простая. Из C++ вызывается функция подключения к серверу (на python), в качестве параметра передается его адрес. Соответственно, при получении сообщния Python передавает его обратно в метод C++.

Лень двигатель прогресса

Иногда, создавая модели в django, я себя начинаю чувствовать мартышкой. Постоянно создаю атрибут enable, который принимает по умолчанию то значение True, то False. Меняю менеджер objects на свой простой EnableManager. А хочется иметь механизм, который эти монотонные операции делал за меня. Раз хочется, то можно сделать.

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

В 2011 году за дело взялась ФНС, которая начала разрабатывать новую единую базу Федеральной информационной адресной системы (ФИАС) для того, что бы покончить с адресным бардаком, царящим среди различных ведомств.

Привет. Полезная штука экшены в админке! Хочу поделиться как можно сделать экшен который после выбора элементов будет отправлять пользователя на промежуточную страницу чтобы с этими элементами можно было сделать что то особенное. Пример? Например у вас есть интернет магазин, таблица товаров. Вы хотите перенести часть товаров из одного раздела (книги) в другой (книги технические). Выбираем нужные книги, выбираем действие «Перенести в другой раздел», жмем применить, переходим на промежуточную страницу, выбираем нужный раздел и жмем сохранить. Здорово? Давайте попробуем.

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

Здесь приводится пример создания в QGraphicsScene своей рисованной кнопки с помощью QGraphicsWidget.

Рекомендуется к прочтению людям, имеющим опыт работы с PyQt4.

Исходные данные — вы строите некий сервис, и узнаете, что будете получать данные из вне в определенном формате.
Предположим что это будет JSON, структуру его определяете не вы, и вообще вот она:

Итак, у нас есть свежеустановленная по инструкции Beginners' Guide система ArchLinux с окружением Gnome 3. Логинимся, осматриваемся. Мое и не только мое мнение — очень непривычно и неудобно. Столкнувшись с рядом проблем подумывал о бегстве на KDE, но посидев на форумах и арчивики пару дней довел все до удобного мне вида. Вот только на доработку системы требуется от силы пол часа, а те почти два дня ушли на поиск способов решения появившихся проблем. Сейчас я постараюсь сделать краткий и емкий список решений для популярных проблем, без лишних картинок и слов, дабы сэкономить другим и себе из будущего (который забудет как это все делается) время. Посмотреть «большую картинку» можно тут.

Всем известны проблемы работы с революционной средой рабочего стола Unity в Linux Ubuntu. В пользовательском интерфейсе происходят значительные изменения и эксперименты, приводящие к очередным «волнам эмиграции» на другие системы и сборки. После некоторого периода работы в среде Unity в Ubuntu 10.04 LTS (Long Time Support) и вполне успешного привыкания к реалиям Unity, пришлось вернуться в среду новой сборки — 11.10. Тут ожидал сюрприз, поскольку число поддерживаемых тем рабочего стола уменьшилось и настройки системы стали как-то более обрубленными. В перечне тем отсутствовали виды окон с правым расположением кнопок закрывания, что привело к поиску других оболочек, каким бы прогрессивным ни выглядело существование в среде Unity. Более года назад вышла версия рабочей среды Xfce 4.8 со стабильными положительными отзывами, поэтому логично было попробовать её вместо Unity. Как альтернатива, опробовалась среда LXDE, сравнимая по легковесности с Xfce и весьма похожая на неё по организации работы со столом.

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

> SELECT avg(amount) FROM transfer;
65.125965782378
generated in 3850 seconds

А теперь представим, что показатель должен быть свежайшим, а записи в таблицу делаются каждую секунду, и за месяц их набираются миллионы. Или другие требования, но суть та же — агрегировать те же данные каждый раз очень затратно. Обычные базы данных не предлагают таких оптимизаций. Как быть?

Здравствуй хабрхабр!

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

Создавая новый проект на Django, ты в очередной раз лезешь изменять конфигурации своего web-сервера. И вроде бы ничего страшного, да только конфигурации ты меняешь уже чаще, чем выгуливаешь свою собаку. Как-то не правильно? Согласен (собака, думаю, тоже не возражает). Выход – виртуальный хостинг. Изучив пару статей в Интернете, ты забиваешь конфигурации своих сайтов в httpd-vhosts.conf. И какое-то время даже радуешься этому. Проходит время и на локальном хосте у тебя уже не два с половиной сайта, а десятки проектов (пусть даже небольших). И, открывая в очередной раз httpd-vhosts.conf, чтобы добавить какую-нибудь опцию, ты начинаешь думать «А был ли мальчик?», действительно ли ты создавал этот сайт? Ведь в такой окрошке из проектов уже нелегко что-либо отыскать. А если еще учесть, что половина проектов взаимодействует с web-сервером при помощи модуля mod_python, а другая – при помощи модуля mod_wsgi, например, тогда вообще становится грустно работать. Да и жить тоже становится грустно (а уж как ваша собака то у дверей грустит).

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

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

Существует множество способов разворачивания Django-приложений в *nix-среде. Не буду претендовать на оригинальность, просто поделюсь самым-самым-самым-самым своим.

Вводные условия

Предпосылки:

• Один клиент (заказчик) — один юзер в системе на сервере.
• Все проекты клиента — в одной файловой иерархии.
• Virtualenv — это хорошо и must use.
• Ftp — зло, используем современные средства (sftp).
• Количество файлов для управления проектами должно быть сведено к минимуму.

Используемый софт:

• nginx
• uwsgi
• cron
• virtualenv
• openssh

Недавно google анонсировал Cloud SQL для своего облака. Но вначале подержки django не было, и вот в начале февраля выходит App Engine 1.6.2 с поддержкой запуска приложений на django. Теперь можно забыть про скакания вокруг app-engine-patch и django-nonre, и пытаться эмулировать реляционную базу данных поверх bigtable.

Около двух лет назад поисковый гигант запустил инструмент Google App Inventor, позволяющий «людям, не знакомым с программированием», писать программы для Android при помощи системы визуального проектирования интерфейса приложения и логики его работы. Другими словами, интерфейс можно было создать «как в Delphi», а логику работы кода надо было описывать, размещая визуальные блоки приблизительно следующим образом:



Здесь по клику на кнопке экран приложения меняется на синий.

Однако, ввиду отсутствия интереса к Google App Inventor компания закрыла проект немногим спустя более года, выпустила его код под Apache-лицензией и передала в ведение Массачусетского технологического института с целью создания полноценного сервера App Inventor для публичного использования. Эта инициатива теперь входит в рамки Центра мобильного изучения МИТ для цели обучения компьютерной грамотности нетехническими методами.

МИТ не заставил себя долго ждать и вернул проект к жизни, запустив его публичную бета-версию, попробовать которую можно здесь — для доступа к системе требуется учётная запись Google.

Взглянуть на работу Google App Inventor можно на видео:

Я ранее уже рассказывал на хабре о Grab — библиотеке для парсинга сайтов и о Spider — асинхронном модуле для парсинга. Рад сообщить, что я наконец-то дописал документацию по Grab. Я решил писать всё на русском языке т.к. на английском языке мне труднее выражать мысли. На деле писанины получилось гораздо больше, чем представлялось в начале, но я таки описал практически все функции библиотеки. Я решил просто вставить сюда, оглавление, кликайте на интересный раздел и читайте о возможностях Grab:

Навеяно долгими поисками различных систем прототипирования и желанием поделиться этим опытом. В данном посте отсутсвуют сложные системы типа iRise или IBM Rational Rose, ввиду того что они являются не столько и далеко не только системами простого прототипирования, да и стоимость этих решений подходит предприятиям немалого маштаба. Этот пост о чем-то более земном.

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

То описание технического задания, о котором речь пойдет ниже, не является пересказом ГОСТа, но скорее является его творческой переработкой, хорошо сдобренной горьким опытом. Описанный ниже подход к ТЗ не охватывает все аспекты сайтостроения, но задает общее направление.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так:

Американская компания Imperva, которая занимается разработкой решений для защиты данных, опубликовала свой 17-страничный отчёт, посвященный исследованию работы известной группы хактивистов Anonymous. Нельзя сказать, что отчёт вскрывает страшные тайны подпольной организации злоумышленников, но, тем не менее, в качестве систематизированной картины он весьма удобен.

Итак, согласно отчёту, Anonymous — это не группа сверхгениальных хакеров, способных в считанные часы или дни взломать любой сервер и украсть любую информацию. Хотя и имели место прецеденты с успешными атаками на столь солидные организации как StratFor и ряд других, успешность атаки объясняется скорее безалаберностью администраторов ресурсов, а не какой-либо сверхизобретательной технике злоумышленников. Так исследователи считают, что хотя у Anonymous и имеются некоторые специфические приёмы, тем не менее, группа предпочитает широко известные методы — прежде всего, это SQL-инъекции и DDOS-атаки, причём, Anonymous, как правило, сначала пробуют украсть данные, а потом, если это не увенчивается успехом, организуют DDOS на ресурс жертвы.

Что такое?

Выполнение действий над элементами графического интерфейса в случайном порядке.

Для чего нужно?

Человек, выполняющий тестирование, это Homo sapiens, т.е. он обладает неким интеллектом. Этот самый интеллект, мешает (очень редко, но мешает) ему находить «нелепости поведения» приложения связанные с непредвиденными ситуациями. Он просто не может представить себе настолько нелогичную ситуацию.
Пользователь же, намного превосходит QA в количестве и может значительно уступать ему в IQ. Отсюда, вероятность непредвиденного поведения пользователя отнюдь не крайне мала.
Итак, что нам, обладая свободными ресурсами и желанием, мешает принять меры по предотвращению подобных ситуаций? — Ничего.
Теперь сформулируем конкретные задачи, в которых «бессмысленное клацанье» по кнопкам может быть полезно:

• Дополнить существующее тестирование стабильности приложения путем введения модели нелинейного поведения пользователя в GUI.
• Исследовать потребление ресурсов при всех возможных вариантах работы приложения (инициированные из GUI).

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

Как делать будем?

Дальнейшее описание предназначено для тестирования приложений на платформе Windows.
Предлагаю воспользоваться связкой python + pywinauto. Хотя pywinauto и имеет некоторые ограничения в плане доступа к элементам окна, для большинства случаев этого должно быть достаточно.
Честно говоря, альтернативы я не вижу. Все знакомые мне средства автоматизации тестирования GUI не обладают динамичностью, показанной ниже – уже во время выполнения теста получать список контролов, определять их тип и выполнять допустимое действие.
Также не стоит недооценивать возможностей самого Питона и его модулей. Тут вам можно и видео снять, CPU замерить и сообщение, куда надо, в случае чего отправить…

При сортирование в Python 2 есть как минимум два способа это сортирование «настроить»: это параметры key и cmp. Первый был добавлен только в Python 2.4, а второй был удален в Python 3.0. Эти факты как-бы наводят на мысль что key действительно лучше. Кто с этим не согласен или не уверен — прошу под кат.