Ростислав Дзінько

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

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

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

Довелось мені зустрітись з системою контроля версій Mercurial. Причиною зустрічі стала моя цікавість до мови Google Go. Пішев, значить, в мануал, як же його встановити на мою Ubuntu. Ну, встановив prerequisites, потім мені запропонували стягнути найсвіжішу версію з репозиторія. Цей репозиторій, як ви вже здогадались, знаходиться на гуглокоді під керуванням mercurial. Команда клонування репозиторія виглядає так: $ hg clone -r release https://go.googlecode.com/hg/ go При клонуванні помітив одну таку дуже недружню для користувача фічу, як відсутність будь-якої нотифікації про процес завантаження змін по файлах (раніше працював з svn і git, і там такої проблеми не виникало). При невеликому розмірі репозиторія, та ще при хорошій пропускній здатності Інтернету проблему, мабуть, можна і не помітити. Але мій 2Гбіт на цьому проекті дуже надолво задумався =(. Ось таке якесь негарне перше враження.

Е-е-ех, де ж ти, крос-платформовість? Клас wx.MessageDialog має різну реалізацію на різних операційних системах. Власне, на ОС GNU/Linux цієї проблеми зовсім немає, оскільки це діалогове вікно реалізоване засобами wxWidgets, а переклад кнопок відбувається через стандартный механізм інтернаціоналізації wxPython . Зовсім по-іншому все виглядає ОС Windows. wx.MessageDialog на ОС Windows Для ОС Windows це діалогове віккно реалізоване засобами операційної системи (лінь, мабуть, було зробити по-іншому). Власне, маємо виклик функції  MessageBox  з  Windows API . А тому вся інтернаціоналізація відбувається також засобами операційної системи, і влізти в цей процес ми ніяк не можемо, а вікна, які відображаються наполовину однією мовою, наполовину іншою, - зовсім не прикрашають додаток і його автора. Світло в кінці тунелю Так, воно є. Вихід очевидний - написати власний діалог на базі wx.Dialog . Приклад можна глянути в wxDemo . Добре те, що при заміні старого діалогу новим не ...