Эта статья – описание моих экспериментов по сборке модулей для Python. Мне понадобился высокоуровневый интерфейс к библиотеке LibRaw, притом в первую очередь под Windows.

Последний раз модуль для питона на C++ я писал в 2004 году. Модуль к мертворожденной (к счастью не мной) библиотеке ( я тупо продавал свои умения за зарплату). Естественно, навыки не закрепились. Помню, что SWIG сильно облегчил мне работу, поскольку нужен был объектный интерфейс, а «ручками» его писать ломало. Память у меня профессиональная – то есть избирательная и короткая, поэтому пришлось прыгать сначала.

Это статья только про настройку SWIG для Python под Windows. Писать же модули на C/C++ с использованием SWIG гораздо проще, чем всё настроить (кстати, у меня такое впечатление, что это парадигма современного программирования).

Введение

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

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

Портирование на Android

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

Движок

Движок (хобби) находится в разработке уже 10 лет.
Движок полностью написан на C/C++, до начала портации на Android поддерживал iOS и Windows.
Логика, рендеринг, звук — все на C/C++.

Нет никакой необходимости устанавливать Qt заранее на целевую систему, не нужно тянуть предварительно скомпилированные библиотеки для Windows.

Я проделал данный трюк на двух платформах, на Gentoo x86_64 установленной на VitualBox c оболочкой KDE 4.8 и соответвующими библиотеками Qt, и на домашнем сервере Gentoo x86_64 (Intel® Core(TM) i5 CPU 760 @ 2.80GHz) без какой либо графической оболочки и без предустановленных библиотек Qt.

Бойтесь Тьюринговской трясины, в которой всё возможно, но ничего конкретного нельзя сделать просто.
Алан Перлис

Что такое Тьюринговская трясина? Это состояние, в котором программа становится столь могущественной, столь обобщенной, что усилия по решению с её помощью какой-либо конкретной задачи равны или превосходят затраты на написание с нуля программы, которая решает только данную задачу.

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

Зачем это нужно

В текущем моем проекте возникла необходимость применить объектный подход при работе с данными, физически хранящимися в реляционной БД. Стало быть, ORM. Так уж вышло, что данный проект корпоративного сегмента разрабатывается на Qt. Да, хоть это и прекраснейший фреймворк, но не вполне подходящий под задачи программирования сложных корпоративных приложений. Тем не менее, выбор в пользу Qt был сделан по ряду весьма веских причин.
Итак, есть небольшая реляционная БД из примерно 100 таблиц. Необходимо написать тонкий пока слой бизнес-логики, который в перспективе будет обрастать жирком. Имеется описание структуры БД в XML.
Можно засучить рукава и за неделю написать 100 однотипных классов бизнес-логики. Написать многочисленные тесты, сравнивающие эти классы, XML-описание метаданных и саму структуру БД. Но, это не подход настоящего джедая! Действительно, ведь у нас уже есть все необходимое для описания прототипов классов бизнес-логики, просто нужно превратить .xml в .h.

Моя любимая тема в программировании — копаться в негативных эффектах, которые преподносят нам самые, на наш взгляд, тривиальные операции.

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

Вот о такой проблеме в Apache CouchDB мы и поговорим далее.
Картинка в тему:

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

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

Игровой цикл — это пульс каждой игры. Ни одна игра не будет работать без этого. Однако, к несчастью каждого нового разработчика игр, в сети нет хороших статей, в которых уделено достаточное внимание этой теме. Но не печальтесь, потому как только что вы получили возможность прочитать единственную в своем роде статью, уделяющую вопросу игровых циклов заслуженное внимание. По долгу службы мне часто приходится иметь дело с большим количеством кода мелких мобильных игр. И я каждый раз удивляюсь сколь много существует реализаций игрового цикла. Вы тоже можете удивиться как можно для такой, казалось бы простой, вещи можно придумать множество имплементаций. А ведь можно! И в статье я постараюсь рассказать о достоинствах и недостатках наиболее популярных вариантов игровых циклов. Также я постараюсь описать наилучший на мой взгляд вариант реализации игрового цикла.
(Thanks to Kao Cardoso Félix this article is also available in Brazilian Portuguese) (Thanks for me, in Russian also, прим. перев.)

Распространенное мнение о появлении панка, состоит в том, что панк был реакцией на крайности современного рока, в частности прогрессивного рока того времени. Реальность, безусловно, намного сложнее, но я подозреваю, что доля правды в этом есть. Рок-н-ролл в поздние 60-е и 70-е, похоже, был областью “Золотых Богов”, недоступной простому смертному. Контраст между группами типа Rush и Black Flag был огромен.

Мне очень хочется показать, что в многопоточности С++ «очень быстро» не исключает «очень безопасно». А значит можно писать эффективные и стабильные программы со сколь угодно большим количеством потоков и при этом избегать траты кучи времени на отладку многопоточности. Если Вам интересно, как мне удаётся не выстрелить себе в ногу, и чем я за это плачу, добро пожаловать

Здравствуйте!

Это вторая из трех статей о техниках анализа проблем и принятия решений (первая здесь).

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

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

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

Всех заинтересовавшихся прошу под кат.

Я нашел еще один (очень простой) график, отражающий рейтинг языков программирования. Всё элементарно: по горизонтали — количество проектов на Github, по вертикали — количество вопросов на Stackoverflow.



Я позволил себе провести на этом графике две красные диагональные линии, чтобы показать как наглядно отделены друг от друга мейнстрим (C++, C#, Java, PHP, Javascript и т.д.), группа «альтернативного мировозрения» (Scala, Haskell, Erlang, Prolog, Lisp) и откровенный трэш (всё, что ниже). По-моему, проще некуда. Никаких там годовых колебаний в полтора процента, высчитанных по непонятным формулам.
Взято тут.

UPD: сорри за мини-троллинг со словом «трэш» — зато он породил весьма интересную дискуссию в комментариях. Всем высказавшимся — спасибо.

Библиотека DynLib предоставляет удобные средства для разработчиков, использующих межмодульное взаимодействие (EXE<->DLL, DLL<->DLL) в своих проектах, и значительно сокращает время и количество кода.
DynLib стала неотъемлемым инструментом разработки. Под катом делимся результатами.

Profile-guided optimization (далее PGO) — техника оптимизации программы компилятором, нацеленная на увеличение производительности выполнения программы. В отличии от традиционных способов оптимизации анализирующих исключительно исходные коды, PGO использует результаты измерений тестовых запусков оптимизируемой программы для генерации оптимального кода.

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

Если оглядеться вокруг, то может сложиться впечатление, что отрасль разработки ПО шагает такими громадными шагами, что угнаться за ней нет никакой возможности. И если рассматривать всю отрасль в целом, то действительно это так и есть. Как-то сразу вспоминается старина Брукс со своим «Мифическим человеко-месяцем», когда он в заключении к своей книге пишет о том, как изменилась индустрия ПО в середине 90-х по сравнению с 50-ми годами. В те далекие годы (да, 90-е тоже уже далеки, так что уж говорить за эпоху зарождения индустрии сорока годами ранее) можно было прочитать все журналы (!), компьютерной тематики, которые выходили в свет. Сейчас же ежемесячно появляется десятки книг только по одной из популярных технологий, а количество статей просто не поддается счету.

Доброго вам дня, коллеги. Предлагаю вам прочитать статью о базовом аспекте вычислительной геометрии — точном вычислении предикатов.

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

В этой статье я расскажу, как избавиться от недостатков вычислений с плавающей точкой практически без ущерба для эффективности. План статьи:

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

Итак, если вы хотите знать, почему вычислительная геометрия не является «наукой о подборе эпсилонов» и как можно корректно и эффективно реализовать геометрический алгоритм, жмите

Что такое?

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

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

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

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

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

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

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