Перейти до основного вмісту

Публікації

Показано дописи з січень, 2011

CSS фреймворк. Що це, і кому воно потрібно?

Що таке фреймворк і навіщо воно потрібно? На сьогодні існує велика кількість фреймворків для всього-всього-всього. Це стосується веб-програмування серверної частини, javascript-фреймворків клієнтської частини, а також в багатьох інших сферах. В загальному, можемо розуміти фреймворк як деяку кодовую базу, що вирішує набір стандартних задач, і яка задає архітектуру та стиль створення додатку. Ну, зі всім цим зрозуміло. Наприклад, javascript-фреймворки дозволяють не паритись з крос-браузерністю і вирішувати задачі на порядок швидше. Що ж із CSS? Крос-браузерність в CSS - це також наболіла проблема. Але, наскільки мені відомо, кожен досвідчений CSS майстер має свій набір правил верстки, що допомагає йому практично безпомилково писати крос-браузерний код, тим більше для сучасних браузерів, де аналіз CSS-стилів не так вже й сильно відрізняється, як було, наприклад, 2-3 роки тому. Розглянемо CSS фреймворк на прикладі  blueprint CSS . Є й багато інших фреймворків, які вирішують схожі задачі,

Як перейти з PHP на Python

Вступ Останнім часом на форумах часто почали з'являтись теми про те, як перейти з php на python. Звісно ж, тут я буду розглядати лише веб-розробку. В цій статті я хотів би роз'яснити деякі моменти, щоб php-розробникам, які, все-таки, вирішили починати розробляти веб-додатки на python було зрозуміло, що тут та як. Як працює php? Для початку візьмемо до уваги, що PHP з самого початку задумувався і розроблявся виключно як мова для веб-розробки, і в 99.9% випадків для цього і використовується (можна, звичайно, писати і GUI-додатки, наприклад, для цього є GTK-біндінги). Говорячи про те, як працює PHP, я маю на увазі те, як прийнято в більшості випадків розробляти веб-додатки на PHP. Я не буду заглиблюватись в організацію інтерпретатора, розширення, MINT, та ін.. Для максимальної простоти приймемо інтерпретатор PHP за деяку окрему сутність. В загальному випадку, все відбувається приблизно так: Тобто, в найпростішому випадку, ми створюємо html-сторінку, всередині якої знаходяться б

Python xrange і OverflowError

sic! Дана проблема присутня в Python версій 2.х. Тим, їто працює на Python версій 3.х можна далі не читати. Простий приклад Уявіть собі, буває і таке. Залишилось вияснити, чому. Давайте глянемо на приклад коду, який призводить до такої помилки. Приклад досить простий: for i in xrange(100000000000):     print i Приводить цей приклад до наступної помилки: OverflowError: long int too large to convert to int Поекспериментуємо Добре, не хоче Python так, спробуємо по-іншому - замінити xrange на range : for i in range(100000000000): В результаті отримаємо ще одну цікаву (як і варто було очікувати) помилку: OverflowError: range() result has too many items Не хоче, падлюка, він створювати такий довгий список. Виходячи з наявних помилок, ми дізнаємось декілька цікавих (для когось, може і нецікавих) фактів про Python: Максимальна довжина списку в Python = sys.maxint, тобто - 2147483647. xrange для створення ітератора приймає числа <= sys.maxint. Якщо ви подумали, що зможете створити список

Девелоперський Django сервер працює повільно на Windows 7

Зіткнувся з такою проблемою: девелоперський сервер Django дуже довго опрацьовує запити в операційній системі Windows 7. Ситуація приблизно така. Запускаємо сервер: python ./manage.py runserver 127.0.0.1:3333 Заходимо на сайт: http://localhost:3333/ Після цього отримуємо контент тільки після довгої затримки, що не дуже приємно в процесі активної розробки чи тестування сайту. Виявляється, проблема виникає через, хто б подумав, IPv6, оскільки поняття localhost в контексті наявності різних протоколів уже не таке однозначне.  Тому робимо 2 кроки: Розкоментовуємо рядки (у кого вони не розкоментовані в C:/Windows/System32/drivers/etc/hosts ) 127.0.0.1 localhost #::1 localhost Заходимо на сайт не через localhost, а по 127.0.0.1. Вдалого джангування!

Статика і девелоперський сервер на великому Django-проекті

Що таке девелоперський сервер? Хотів би поділитись одним своїм спостереженням на рахунок роботи зі статикою сервера django, який "з коробки", і, власне, не є рекомендованим для використання в реальному середовищі. Для простоти використання статичних файлів, тобто всяких там стилів, зображень і клієнтських скриптів, розробники django-фреймворка втулили наступну view'ху: django.views.static.serve Напевно, більшість django-програмістів використовують цю річ в роботі, як і девелоперський сервер: python ./manage.py runserver : Більше того, згідно із статистикою djangosites 1.2% користувачів не паряться зі всякими там nginx, apache, і публікують свої додатки таким ось нехитрим способом. Проблемка При цьому, мабуть, мало хто стикався з тим, навіть в досить крупних проєктах, що девелоперський сервер зависає на кожному другому-третьому запиті, що не просто бісить, а робить розробку практично неможливою. З однією з причин такого зависання я нещодавно стикнувся. А діло було в стат