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

    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? Гляньте дану пропозицію: