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

В данной статье я хотел бы рассказать, сформулировать свои мысли по поводу такой замечательной библиотеки как 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 действительно лучше. Кто с этим не согласен или не уверен — прошу под кат.

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

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

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

Это шпаргалка раскрывающая раздел «Интеграция Selenium тестов» статьи Настройка Jenkins для django проекта с нуля. А именно как запускать Selenium тесты на удалённом сервере Jenkins у которого нет монитора и форточек.

Компания Apple приглашает новичков начать разработку своих приложений под iOS, и в помощь опубликовала руководство "Start Developing iOS Apps Today", где указаны все необходимые действия на каждом этапе, даются советы по выбору языка программирования, дизайну интерфейса приложения и максимизации прибыли в App Store.



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

Для курса по программированию MIT разработан интерактивный инструмент Online Python Tutor, он в графическом виде показывает изменение стека и кучи на каждом шаге выполнения кода. Таким образом, онлайновый «наставник» как бы наглядно объясняет студенту работу программы.



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

Рано или поздно все python-разработчики стают перед выбором: отдать заказчику приложение в исходниках или скрыть их. И вот во втором случае у многих (особенно недавно знакомых с этим прелестным языком) начинаются проблемы: поиск по гуглу, как правило, ничего не дает, идей никаких (или все бредовые).

Надоело отправлять пользователям подтверждения аккаунта и сброса пароля по утере на почту?
Пользователи уходят, устав заполнять вашу форму регистрации?
Вы точно уверены, что у посетителей вашего сайта есть аккаунт на Facebook или Вконтакте?
Не хотите хранить никакие персональные данные?
Ваши пользователи устали вводить логин и пароль?
Вашим пользователям лень даже нажать на кнопку «Войти»?
Видели, как это сделано на stackoverflow и хотите так же, и даже лучше?

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

LESS — это популярный препроцессор для языка CSS, добавляющий возможности использовать константы, наследование, вложенные стили и много другое, чего так не хватает в CSS. Как только я познакомился с LESS я понял что это то, что мне нужно. Единственное, что омрачило мою радость — разработчики предлагают всего два варианта его использования: встраивать JavaScript файл, который занимается препроцессингом прямо в браузере или использовать специальный скрипт (который должен исполняться на node.js) который процессирует LESS файлы.

Вариант c процессингом LESS файлов на клиенте мне не понравился тем, что для больших LESS файлов это вызывает ощутимые паузы при загрузке страницы. Если использовать LESS версию твиттерного bootstrap-a — загрузка увеличивается на несколько секунд, что абсолютно недопустимо.
Вариант с предварительной компиляцией меня не устраивал тем, что приходится «вручуную» запускать препроцессор. Я видел программу, которая автоматически перегенерирует LESS файлы при их изменении, но она оказалась платной и только под МакОСь.

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

Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.