Эра фулстэк фрэймворков в прошлом. Современные разработчики фрэймворков разделяют свои монолитные репозитории на компоненты с помощью ответвлений в Git, позволяя разработчику выбрать то, что действительно необходимо его проекту. Это означает, что вы можете построить свое приложение на топовых Zend Service Manager, Aura Router, Doctrine ORM, Laravel (Illuminate) Eloquent, Plates, Monolog, Symfony Cache или любых других компонентах, которые можно установить через Composer.
Рубрика «структура проекта»
Построение гибких PHP приложений
2017-05-02 в 11:14, admin, рубрики: composer, php, автозагрузка, архитектура web приложений, архитектура приложений, компоненты, модульная архитектура, модульное программирование, ооп, Программирование, Проектирование и рефакторинг, Разработка веб-сайтов, структура кода, структура приложения, структура проекта, файловая структура
Структура проектной папки дизайнера
2017-01-12 в 20:36, admin, рубрики: веб-дизайн, дизайнеру, интерфейсы, структура проекта, хранение данных
Заказчику понадобилось изображение, созданное 3 года назад или закончился тираж визиток двухгодичной давности? Внести коррективы в макет сайта которому уже 5 лет или откатиться на версию, которая была отклонена на прошлой неделе? Для всех вышеперечисленных вопросов полезно хранить и быстро находить файлы. Делюсь наработками и структурой папок, которые облегчают задачу.
Проектирование сложных приложений в Flask
2016-01-14 в 10:53, admin, рубрики: flask, python, веб-приложения, Веб-разработка, программирование для начинающих, структура проектаДанная статья, размещенная в репозитории Flask на GitHub, является плодом коллективного творчества небезразличных программистов, а изначальный её автор — Brice Leroy. Она представляет собой достаточно полезный для начинающих материал по Flask. Лично для меня он стал ответом на многие простые вопросы, основным из которых был «как структурировать проект».
Для хоть сколько-то опытных программистов она вряд ли будет полезна, многие могут вовсе не согласиться с описанными принципами, однако для находящихся на ранней стадии обучения она может стать толчком к развитию, как стала для меня. Именно поэтому я сделал перевод на русский язык — у этой статьи очень низкий порог вхождения и стоит сделать его еще ниже.
Описанный пример протестирован на Python 3.5, Flask 0.10, Flask-SQLAlchemy 2.1, Flask-WTG 0.9.
Читать полностью »
Пишем первое REST API приложение на NodeJS (Express + Mongoose)
2014-02-26 в 8:16, admin, рубрики: javascript, node.js, первый проект, Проектирование и рефакторинг, структура проекта, метки: первый проект, структура проектаДанный топик ориентирован больше на начинающих NodeJS разработчиков. Когда я говорю о начинающем разработчике, то понимаю под этим, что некоторые знания о NodeJS у вас уже имеются. Иначе настоятельно рекомендую сначала ознакомиться с основами (например, здесь) и лишь потом вернуться к этой статье.
Так зачем же нужен этот топик, ведь в сети огромное множество материалов о том, как построить MVC приложения на основе Express? Например, вот эта статья и многие другие. Весь их недостаток для нас в том, что они описывают MVC приложения, которые по архитектуре отличаются от REST приложений. И вот тут у начинающего разработчика возникает ряд вопросов:
Читать полностью »
Вариант организации контроля версий ПО для аппаратов с множеством сетевых устройств на борту
2013-04-23 в 11:11, admin, рубрики: Песочница, Проектирование и рефакторинг, система контроля версий, структура проекта, управление проектами, хранилище, метки: система контроля версий, структура проекта, хранилищеХочу поделиться некоторыми идеями по поводу организации хранилищ в системе контроля версий. Для определенности: мы используем Меркуриал, но это не столь важно.
В двух словах о задаче. Одновременно ведется несколько проектов. Под проектами понимаются аппараты с цифровыми устройствами на борту (десятки устройств), объединенными в сеть. Речь идет о программном обеспечении бортовых устройств, которое нужно отслеживать с помощью системы контроля версий.
Есть бортовые устройства, одинаковые для разных аппаратов, а есть и специфические. Устройства могут программироваться разными разработчиками, а некоторые из устройств программируют контрагенты. Марки процессоров (контроллеров) бортовых устройств различаются. В разных устройствах могут использоваться одинаковые библиотеки: драйверов, математики и пр.
Разработчики много времени проводят в командировках (на испытаниях), где оперативно нужно менять код и обмениваться обновлениями по Интернету.
Сейчас представляется удивительным, что такая работа проводилась без системы контроля версий. Возможно это удавалось потому, что проектов было не так много, а разработчиков всего двое. Но дальше так продолжаться дело уже не может.
Мы сформировали концепцию контроля версий и потихоньку начинаем рефакторинг проектов в русле данной концепции. Пока мы в начале пути, найденные решения нам нравятся, но возможно не видим всех подводных камней и можем поплатиться за это в будущем. Надеемся, что рекомендации читателей помогут исправить ошибки, пока мы не зашли очень далеко.