Геймификация становится всё более и более популярным явлением. В этом посте я расскажу вам, как была реализована система геймификации в агентстве интернет-маркетинга Netpeak несколько лет назад, и во что выросла эта система к текущему моменту.



Сначала очень кратко о компании, в которой внедрялась система: в Netpeak работают около 110 человек. Агентство сфокусированно на SEO и PPC. Им скоро будет 8 лет, два из которых они работают над системой геймификации, о чём и будет идти речь далее в статье.

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

Итак, началось всё с обзвона условно-доступных магазинов: их нашлось около десятка.

Дыра 8-800

У нескольких магазинов стоит автоответчик на 8-800 — это хорошая дыра для атаки на переполнение бюджета. Уязвимость давно описана – конкуренты могут делать ботом четырёхсекундные звонки на номер 8-800, и, не дожидаясь живого оператора, класть трубку. За 800 платит владелец (магазин), поэтому в конце месяца при таком раскладе может приехать большой счёт. Я почти уверен, что грамотный админ отследит такие ситуации – но не уверен, он есть у маленьких магазинов. Собственно, мы сами узнали об этом из топика на Хабре и сразу закрыли дыру.
Проверьте, как у вас.

Первая часть, введение

В первой части статьи я рассказал о прекрасном фреймворке Omega для Drupal, который позволяет создавать собственные темы оформления, основанные на сетке (grid), произвольно настраивать и менять расположение и размеры регионов без каких-либо модификаций HTML-кода шаблонов. На этом можно было бы и остановиться, но существует прекрасный мощный CSS-фреймворк Bootstrap, имеющий собственную реализацию сетки, большое количество готовых CSS и JS компонентов, которые очень легко стилизовать, а также огромное сообщество, благодаря которому мы получаем наиболее качественный и «вылизанный» код по сравнению с конкурентами.

В этой части статьи я расскажу, как привязать Bootstrap к Omega. Но если вас по какой-либо причине не устраивает Bootstrap, то подобным образом можно прикрутить к Omega любой другой фреймворк на ваш вкус. Как и в первой части статьи, я не претендую на какую-то уникальность, просто описываю те вещи, которые можно почерпнуть из документации. Здесь будет много кода и мало картинок.

Drupal 7 на сегодняшний день развился настолько, что позволяет создавать темы оформления для сайтов любой сложности, практически не прибегая к HTML-верстке. Процесс создания таких тем напоминает использование конструктора, вся основная работа по переносу эскиза макета в жизнь заключается только в задании необходимых стилей в CSS. Дополнительных ограничений при этом никаких не возникает, можно создавать темы любой сложности, причем полностью настраиваемые; и разве что натыкаешься на ограничения самой платформы (Drupal) или выбранного фреймворка (Bootstrap).

Мой опыт разработки под Drupal более 7 лет, начинал в 2005 году с Drupal 4.6, с тех пор использую и восхищаюсь тем, как он развивается и становится лучше и удобнее от версии к версии. В этой статье я поделюсь своим опытом создания и использования сабжевой связки. Подразумевается, что вы знакомы с Drupal, умеете устанавливать модули и создавать темы оформления, но по каким-то причинам еще не используете фреймворк Omega для разработки своих тем. Первая часть статьи представляет собой простую инструкцию о том, как создать и настроить субтему на базе Omega. Также надеюсь, что идея этой статьи будет интересна пользователям альтернативных платформ, и немного прорекламирует мощь, простоту и гибкость Drupal в этом вопросе.

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

Хочу поделиться опытом настройки сервера для django-проектов. Так вышло, что мне часто приходится настраивать с нуля VPS-сервера для запуска на них django-сайтов. Как-то мне в голову пришла идея записать пошагово процесс настройки. Оказалось, что “по бумажке” выполнять эти рутинные операции гораздо проще и быстрее — все нюансы записаны, трудно что-то упустить. Дальше больше — я превратил инструкцию в самостоятельный shell-скрипт — запустил и сервер готов. Я думаю, некоторым python-разработчикам, особенно начинающим, будет полезно ознакомиться с содержимым скрипта. С некоторыми доработками вы, возможно, захотите использовать его в своей практике.

Здравствуйте уважаемое сообщество,

Выбрав фреймворк Django для разработки корпоративного сайта, я столкнулся с проблемой тестирования его работы по протоколу HTTPS при использовании встроенного веб-сервера. Несмотря на поддержку работы с безопасными соединениями в Django, поставляемый в комплекте веб-сервер не обслуживает запросы по HTTPS.

Первое, что пришло в голову, поднять полноценный веб-сервер (например, Apache) для разработки и тестирования, но что если не хочется отказываться от удобств и простоты использования встроенного веб-сервера Django?

Поиск в Интернете по запросу «django + https» выдал несколько статей датированных 2009 и 2012 годами, в которых для тестирования HTTPS предлагается использовать stunnel.

Данная статья является инструкцией полученной в результате настройки stunnel под среду разработки Django на Ubuntu 12.04.1 LTS x64.

Сегодня я расскажу о том, как мы валидируем формы с использованием технологии Ajax. На стороне сервера будет использоваться Django.
Ничего нового в этом способе нет, в интернете есть несколько статей на эту тему, главное же отличие от этих статей заключается в том, что всю логику валидации формы через Ajax мы вынесем в отдельное представление (view). Это позволит нам писать все остальные представления без какой-либо дополнительной логики. При написании функционала будет использоваться Class Based Views подход.

При валидации форм с использованием Ajax мы получаем следующие преимущества:

• страница пользователя не перезагружается пока данные не валидны;
• форма не отрисовывается заново;
• логика валидации формы описывается в одном месте.

Если заинтересовались, добро пожаловать под кат.

В больших проектах уже довольно давно привык к плюшкам ci: прогону тестов, отчётам и автоматическому деплою. При разработке небольших проектов этого не хватает. 1 и 3 покрывает travis-ci (ну или drone.io), но вот визуализации результата нет никакой.

И сразу придумалось простое решение:

• прогонять анализаторы на стороне ci;
• отправлять их себе;
• парсить результат и красиво отображать.

И это всё вылилось в небольшое приложение — coviolations.io (исходники сервера и приложения), сейчас оно

• работает с публичными и приватными репозиториями на github;
• работает с travis-ci, drone.io и при желании с jenkins;
• умеет парсить результат pep8, sloccount, python unittest, pip-review и testem;
• умеет рисовать статус-плашку ;
• умеет комментировать пул реквесты в публичные проекты, использующие travis-ci;
• не умеет работать с репозиториями организаций.

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

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

Ну а чтобы не быть голословным — перейдём к примерам. Нас ждут:

1. Неудаляемые модели, которые мы удалим
2. Валидируемые поля, которые не валидируются
3. Два админа, которые портят данные

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


В последнее время, я пишу на django.

Возникла необходимость вывода в списках достаточно большого количества опций.
Если оставлять просто поле типа models.ForeignKey со стандартным виджетом (Select, SelectMultiple),
нагружаем и базу данных и сервер приложений.
Давайте попробуем обращатся к этим данным только тогда, когда это нужно.

На просторах интернета, не обнаружил готового решения (чтобы просто установить и это заработало).
Есть наборы комментарий типа «наверное, вам нужно вот то-то» или «вот это»
В связи с этим, решил выложить то, что получилось.

Выкладываю небольшой application под django, содержащий

• Составные числовые поля и поля с датами
• TreeWidget для модели, основанной на MPTT
• Виджет SelectAutocomplete
• Виджет SelectMultipleAutocomplete

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

Добрый день, хабраюзер.

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

Поздравляю всех с прошедшим Праздником и предлагаю очередную сводку «мобильных» новостей! На этой неделе Fiksu выпустила очередной отчет с индексом конкурентоспособности и данными о CPI и CPAL за март, товарищ Mikhail_dev более подробно рассказал о работе с Dalvik Debug Monitor Server, сведен единый «Кодекс Фримиум», бывший менеджер App Store рассказал немного о том, как добиться фичеринга Apple.

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

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

Итак, суть статьи заключается в том, чтобы понять: можно ли в РФ физическому лицу законно получать прибыль от продаж программ в App Store? Просмотр тематических форумов с подобными вопросами привел к выводу: мнения людей на этот счет расходятся. Одни считают, что можно, другие — что такая деятельность будет квалифицироваться как незаконная предпринимательская деятельность, т.к. договор от Apple — это агентский договор и в нем нет ни слова про авторские вознаграждения, и, как следствие, нужно регистрироваться в качестве индивидуального предпринимателя (ИП).

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

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


Изображение №1: поиск игр (Find a game в меню приложения)

На этой неделе нам наконец-то рассказали о правомерности работы физического лица с App Store, описали как лучше использовать Auto Layout и строить интерфейсы мобильных приложений, любимый PapaBubaDiop поделился очередной порцией статистики о своих доходах с casual игр, Apple выложила iOS Human Interface Guidelines и начала тестировать промо-коды для IAP. В целом, интересная неделя выдалась на мобильной сцене!

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

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

Ошибка #1 — Идея

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

Вывод: в следующий раз сначала очень серьезный анализ рынка, потом поиск людей готовых купить идею, и только потом продукт.

Приятного времени суток!

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

*много букв, местами неполиткорректно, текст лежал в столе 5 лет

Первое знакомство с представителями Китая на Сцене произошло через 2 дня после моего «входа» в ту самую Сцену. Мне понадобился доступ к популярному в то время варез-FTP “Typhoon Epicenter” (о том, что он располагался в Гонг Конге я узнал позже). Из всех друзей и знакомых организовать доступ мог только один человек – «приятель знакомого моего друга». Он оказался китайцем по вере и паспорту, и мы некоторое время плотно общались. Именно после знакомства с ним, я стал относиться к китайцам с пассивным интересом.

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

Чаще всего китайцы вызывали у нас 3 вида эмоций: уважение, зависть и раздражение. В годах 1997-2004 любой пират, катающий болванки «Лучший Soft 200x», отдал бы почку за доступ к паре варезных серверов Китая.