Чого не варто робити в робочому середовищі при розробці на Django фреймворку?

Зараз я активно працюю над книгою Веб-розробка з Python та Django для Початківців, а також організацією людей та закритої платформи для підтримки тих, хто буде освоювати матеріал даної книги та пробувати себе у веб програмуванні.

Після оголошення даної книги регулярно отримую питання про вміст книги та чи увійдуть туди такі теми як Юніт Тести, Безпека у веб та Django фреймворку, розробка фільтрів та тегів, і масу інших топіків, які, я вважаю, є складнішими та необо’язковими як для початку освоєння веб програмування.

Саме тому вирішив почати ще одну серію невеличких статей (завтравочок :-), кожна з яких стосуватиметься того чи іншого аспекту фреймворку Django та веб розробки і які не увійдуть у першу книгу. Матеріал буде наведено на основі особистих практик, а також вичитаного із розумних книжок по Django і як наслідок, впровадженого у власній розробці. Думаю це буде свого роду продовженням книги для початківців, а також думаю буде корисним і для тих, хто уже добряче розбирається у веб програмуванні та Django – непогана вижимка та шпаргалка по кращих практиках та порадах при розробці під Django.

В сьогоднішній статті оглянемо кілька порад стосовно робочого середовища веб розробника на Django.

Отже,

Почнемо із серця будь-якої веб-аплікації – ДАНІ та бази даних:

Використовуйте одну і ту ж базу даних на усіх машинах

Досить проста та очевидна порада. Але через те, що є велика спокуса на початку скористатись вбудованою в Python базою даних sqlite3, ми часто починаємо створювати нашу аплікацію з нею, а вже потім маємо проблеми із переїздом на базу даних, що використовується на продакшині. Це може бути MySQL, PostgreSQL, Oracle, і т.д.

Я сам так часто робив. Але воно того не варта. Чому?

• так, ви можете мати так звані заготовки (демо дані, fixtures) ваших даних, які потім імпортувати у кожну із ваших баз даних і спробувати налаштувати таким чином одинакові дані усюди; проте fixtures більше годяться для юніт тестів, створення демо контенту, але аж ніяк не призначенні для міграції великих об’ємів даних; за кілька років після наповнення бази продакшин даними fixtures вам, швидше за все, не допоможуть;
• якщо сталась проблема на продакшині з базою, ви не обов’язково зможете відтворити проблему локально, якщо локально розробляєте використовуючи іншу базу даних;
• різні бази даних мають різні типи полів та обмежень; незважаючи на те, що Django ORM (Object Relational Mapping – “місток” між даними в базі та об’єктами в Пітоні) забирає від вас більшість проблем при роботі з базою даних, все ж таки різниця в базах даних може легко призвести до неправильного функціоналу у ваших формах, втрачених даних, некоретних даних; наприклад PostgreSQL має досить жорстку валідацію по типах полів, в той час як sqlite3 тихенько пропустить невалідні дані, які виявите лише на продакшині; неприємний сюрприз, так?;

Тому рекомендовано одразу використовувати для розробки ту ж базу, яку плануєте використовувати на усіх продакшин машинах. Не лінуйтесь локально заінсталити потрібну базу даних та потрібної версії. Воно окупиться!

Яку базу використовувати з Django?

Не принципово, яку базу використовувати. Обирайте відповідно до потреб проекту. Django дозволяє працювати з більшістю популярних SQL баз даних.

Точно не знаю чому, але в Django склалась тенденція частіше використовувати базу даних PostgreSQL. Відповідно, думаю, Django ORM найкраще працює з даним типом бази. Тому, якщо немає протипоказань в конкретному проекті, зазвичай обираю PostgreSQL при роботі з Django.

Тепер кілька рекомендацій по софту та інсталяційних інструментах:

Користуйтесь virtualenv та pip

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

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

virtualenv – це інструмент, який дозволяє вам встановлювати ізольовані пітон середовища і працювати над різними проектами маючи заінстальований лише один Пітон. З його допомогою ваші пакети в різних проектах не перетинаються.

Для зовсім “просунутих” також рекомендую інструмент virtualenvwrapper – ця невеличка утиліта полегшить вам навігацію між проектами.

Тепер про pip. Це по суті інсталятор пакетів, або ще можна сказати менеджер пакетів в пітоні. Він швидко дозволяє знайти та заінсталювати пакет потрібної версії з віддалених пітон індексів.

Інсталюйте фреймворк Django та інші пакети виключно з допомогою даного інструменту. Це пришвидшить вам збірку робочого середовища та зменшить головний біль.

І остання порада:

Використовуйте репозиторій коду!

Якщо ви ще цього не робите, тоді ось тут є класна стаття, яка не лише розкаже вам як користуватися репозиторієм коду, але й пояснить навіщо він потрібен взагалі: Що таке репозиторій коду або ЛікБез по Git.

Ось і все на сьогодні. Коротко і ясно 😉

В наступній статті розкажу як я структурую свої файли та папочки в Django проекті та Django аплікації.

А які фішки, інструменти та поради ви можете підказати стосовно вашого робочого середовища?

Хочете більше дізнатись про веб-розробку та навчитись створювати веб-сайти використовуючи мову Python та веб-фреймворк Django? Гляньте дану пропозицію:

Веб-розробка з Python i Django для початківців



Практичний посібник по веб-розробці з допомогою Python та Django для початківців. Постійна підтримка та швидкі результати гарантовано.



Детальніше...