Новий Движок Блогу

22 Листопада 2010

Сьогодні дописав базовий код движку для веб-блогу. І відразу ж переніс TutaMC з Друпалу на новий двиг. Тому цей пост пишу вже в Джангі. Движок звичайно ще треба допилювати й допилювати, але початок є.

Десь на тижні напишу статтю про все те що було зроблено, бо виявилось що дивитися відео-трансляцію програмування занадто тяжко, тому вертаємося до старого методу статтей.

Якщо побачете якісь глюки - пишіть.

Django і Підписка

26 Квітня 2010

За вчорашній вечер написав маленький модуль до Django. Мені потрібно було розіслати по всім користувачам розсилку емайлів. З однії сторони звичайна задача, але облазивши весь інтернет не знайшов простого модуля. Тож засучив рукава, включив Ангіну на повну гучність, і вже за декілька годин мав результат ).

Тож press_subscription вміє:

  • створювати листи
  • відсилати листи адмінам, щоб перевірити як вони виглядають
  • відсилати всім користувачам листи
  • в листі можна використовувати змінні, такі як емайл користувача, і лінк щоб відписатися на розсилку
  • можливість відписатися від розсилки

Для роботи press_subscription потрібні модулі:

Хоча система буде працювати і без mailer, а щоб відмовитися від dblogging потрібно закоментувати лише два рядки.

Систему вже затестив на продакшині в себе, і помилок немає. Хоча я через те що спішив трішки подурному поназивав поля в моделях. Та й код непогано б відрефакторити, та то вже якось пізніше ).

Саме за цю модульнісь я люблю Джанго, бо тепер якщо мені в наступних проектах буде потрібна розсилка, то її вже імплентую за хвилину.

Весь модуль знаходиться на bitbucket - http://bitbucket.org/presidentua/django-subscribe/wiki/Home

Можливо він буде корисний не лише мені )

Супершвидкий Redis

1 Квітня 2010

Хоча сьогодні 1 квітня, але цей пост не жартівливий. Чесне слово.

Півроку назад я спробував юзати базу даних Redis і написав на ній простенький блог - http://tutamc.com/node/201. По тих тестах я бачив що Redis швидка база, але так на практиці ніразу й не доводилося її заюзати.

Та тут мене як фрілансера знайшов один замовник і за "їжу" я написав скриптик, що використовував MySQL. Цей скрипт повинен був брати дані з різних сайтів і заносити їх в базу. Скрипт вийшов на декілька десятків рядків і в тестах нормально себе зарекомендував. Але на продакшин сервері я побачив таку сумну статистику:

MYSQL: count SQL query - 125984, time - 14606.3

Хоча запити були й прості, але через те що їх було більше 100 тисяч скрипт працював як бачимо 4 години. Спочатку думав над оптимізацією всієї роботи, та щось мені ліньки стало думати. І я просто заюзав Redis - змінивши в скрипті декілька рядків отримав таку стату:

REDIS: query - 125984, time - 109.3

Redis працював більше ніж в 100 раз швидше! При цьому не грузив проц навіть на 1 відсоток, і займав в оперативі лишень 30 Мб. Я просто в шоці! Гадав прискорення буде хай в 5 чи 10 раз, але не в 100. До того ж Redis запущений під Віндою і він там ще не оптимально працює, гадаю під Лінохом швидкість була б ще швидша.

Тож якщо в вас якийсь високонавантажений проект, то придивіться до Redis'а - http://code.google.com/p/redis/ 

PS: зборки Redis під Windows знаходяться тут - http://code.google.com/p/servicestack/wiki/RedisWindowsDownload

Коли виникають великі навантаження на базу данних то ставлять більший сервер, потім ставлять два крутих сервера, далі може ще трішки їх додають, але чим далі - тим все складніше, бо маштабування в звичайних базах данних майже відсутнє. І сьогодні хочу розповісти про key-value бази даних і про приклад їх використання на прикладі блогу зробленого в Django і в якості бази даних використовую Redis. Але зараз вже 6-та година ранку і писати мені лінь, тому дальше буде скрінкаст:

Django and Redis from presidentua on Vimeo.

А знявши скрінкаст побачив, що трішки ранковий голос мене підкачав та й занадто тихо говорю, тому потрібно б розповісти і словами.

Отдже Redis це представник key-value бази даних, тобто такої бази де немає sql, а є лише дві команди set і get, тобто по суті звичайний масив, але через таку простоту база даних працює надзвичайно швидко і дуже легко маштабується і нові сервера доставляються за декілька хвилин. Хоча ці ж обмеження заставляють думати над архітектурою БД набагато більше чим зі звичайною.

Далі...

Сегодня продолжим знакомство с Django и наконец то рассмотрим базовый кирпич, а именно приложение(application) на примере создания приложения contact, для отсылки каких-то сообщений администрации. Причем напомню что этот цикл практический, в нем я почти не рассказываю почему, лишь говорю как, потому что я все равно не напишу лучше чем в документации: http://docs.djangoproject.com/en/dev/

Разработка каждого приложения начинается с команды: manage.py startapp contact Где contact - названия приложения. В результате будет создана папка contact со следующими файлами: - models.py - views.py - __init___.py

Далі...

Сьогодні порівняємо швидкість розробки між ZF і Django на прикладі невеликого блогу. Представимо, що нам потрібно зробити блог, де були б записи, розділення на стріки і теги.

Розпочнем з ZF:

  1. Спочатку ми б створили в базі таблиці, при чому для тегів прийшлося б додаткову таблицю створювати, щоб був зв'язок багато-до-багатьох. А ще б створили таблицю для авторізації.
  2. Після цього розпочали писати б моделі, які містили б інформацію про зв'язки між таблицями.
  3. Далі пишем код для авторизації.
  4. Пишемо код форми для створення постів.
  5. Пишем код що буде формувати вивід на головній сторінці.
  6. Пишем код для перегляду постів посторінково(pagination).
  7. Пишемо код для перегляду кожного поста окремо.
  8. Пишем код для тегів, тобто їх парсинг, занесення в базу, відображення хмарки тегів.
Ви помітили, що постійно нам потрібно щось писати, робити вручну все. На ZF надзвичайно важко робити модулі, які б з легкістю можна добавляти в аплікейшн. На Django ж це все по іншому, там ми беремо готові компоненти і поєднуємо їх. А коли компонента немає, то пишемо самі, але один раз, далі будемо його з легкістю використовувати.
Але давайте подивимося, як вищеперечислені пункти ми б робили на Django
  1. Створюємо лише одну модель, де все опишем. Ніяких таблиць вручну не створюємо, додаткової таблиці не потрібно. Для поля з Тегом нам потрібно лише вказати, що це буде поле з тегом і все. Робота по створенню ції моделі займе лише декілька хвилин.
  2. ... це все зробили в пункті 1.
  3. Для авторизації використовуємо влаштований модуль, тому цей этап знову займає 0 хвилин.
  4. Для створення постів потрібно створити лише один файл з 3 строчками. 1 хв.
  5. Вивід на головній сторінці пишеться за декілька хвилин разом з сторікновістю(pagination), буде строчок 5 займати.
  6. це вже написали вище в п.5.
  7. Для окремого перегляду використовуємо стандартний views. Тому все це займає одну строчку і час 30 с.
  8. Для тегів вже все написано ;). 0 с.
Час на створення блогу хвилин 10 і це максимум(звичайно без дизайну). В найближчий час зніму окремий скрінкаст, щоб довести це.

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

Итак, имеем SSH доступ к серверу Ubuntu 8.04. Сперва перейдем в root и обновим все пакеты

su root apt-get update apt-get upgrade
Далі...

[Django] Debug Toolbar

6 Серпня 2009

Django Debug Toolbar very nice thing, but it has some limits the functionality. One of them is lack of EXLUDE_URL. But I fix it. And now you can add to config next thing:

DEBUG_TOOLBAR_CONFIG = { 'EXCLUDE_URLS': (r'/admin.*',), }

After this you must download this component from my github project - http://github.com/presidentua/gread/.

Yet I added in file debug_tollbar/middleware.py only some lines:

def _show_toolbar(self, request): if not settings.DEBUG: return False if request.is_ajax() and not \ request.path.startswith(os.path.join('/', debug_toolbar.urls._PREFIX)): # Allow ajax requests from the debug toolbar return False if not request.META.get('REMOTE_ADDR') in settings.INTERNAL_IPS: return False #next lines I added if hasattr(settings, 'DEBUG_TOOLBAR_CONFIG'): exlude_urls = settings.DEBUG_TOOLBAR_CONFIG.get( 'EXCLUDE_URLS', None) for url in exlude_urls: if re.match(url,request.path): return False return True

If U don't use django_toolbar, try. I think, U will like it ;)

При відладці Django і запуску влаштованого сервера - він часто видає забагато інформації, наприклад про запити до медіа файлів. А це ж нас мало цікавить, тому давайте розглянемо частину веб-сервера влаштованого, що розміщується в файлі django/core/servers/basehttp.py:

def log_message(self, format, *args): # Don't bother logging requests for admin images or the favicon. if self.path.startswith(self.admin_media_prefix) or self.path == '/favicon.ico': return sys.stderr.write("[%s] %s\n" % (self.log_date_time_string(), format % args))

Де в коментах пишиться, що не буде показувати адмінські картинки і фавікон, тож можем цей кусок модифікувати так:

def log_message(self, format, *args): # Don't bother logging requests for admin images or the favicon. if self.path.startswith(self.admin_media_prefix) or self.path == '/favicon.ico': return if self.path.startswith('/media/') or self.path.startswith('/__debug__/'): return sys.stderr.write("[%s] %s\n" % (self.log_date_time_string(), format % args))

Лише одна маленька умова, яка не універсальна і досить не красива, але ж скільки користі там!

PS: щось я взагалі помішався на Пітоні і Джанго, але ж це добре )

 
 
 
Роман Хоменко aka PresidentUA
mail/jabber: spirt40@gmail.com