Я бы решил эту задачу средствами API Bitrix, не сделав ни одного sql запроса, не делая этих перезаливов. А с другого сайта нашел и скачал бы картинки стандартными средствами php.
Но если бы я был питонистом и впервые столкнулся с битриксом, то наверное поинтересовался у битриксоводов, на форум бы зашел, на тостере задал пару вопросов, погуглил бы для начала как следует, почитал бы документацию по диагонали :)
1. Заказчик может сказать, что им нужен надежный фреймворк, т.е. не битрикс, а symfony или ZendFramework, остальное их не особо волнует. Или что-то модное- современное.
2. На основе ZendFramework сделали своё для корп.сектора, где сделали отличную админку, кучу интересных вещей, использовали на многих проектах, но на версии php выше 5.6 — все наработки стали legacy, вышел новый ZF, с новым подходом. В итоге отложили на полку, т.к. делать update некому и нет ресурсов.
3. Пришел изначально простой проект, который должен со временем масштабироваться до сложного. Решил попробовать сделать без фреймворка. Собрал из разных библиотек(маршрутизация, ORM, ...), накидал свои классы. Никаких особых сложностей при разработке не возникло, т.к. двигался от простого к сложному и знал как будет развиваться приложение. Но, есть одно но — мне всё понятно и просто, т.к. написал всё я. Как потом будет ориентироваться другой разработчик — вот тут возникает жирный вопрос, потому как сейчас там много всего. А документации нет. Есть только комментарии в коде, phpDoc и readme. Получается, следующий разраб будет дописывать по-своему, и так далее. Плюс я ограничен уровнем своей компетенции и могу какие-то вещи не учесть, где во фреймворке это было бы из коробки.
Такой подход имеет какой-то процент покрытия по сравнению с чистым JS?
Манипуляция с DOM, работа с файлами, drag&drop, какие-то специфичные js библиотеки.
Ситуации, когда проще написать на js. Ситуация, когда сторонний проект не с нуля и там js.
Это очень здоровский ход(конём): «Упрощается процесс отслеживания совместимости API между клиентом и сервером». Сам столкнулся с подобным, используются вычисления как на клиенте, так и на сервере, в итоге нужно изменения применять в 2х местах. А данный подход мог бы упростить работу.
Мне, кажется, что прямоугольник, что квадрат не должны иметь метод нарисуй. Этим должен заниматься Художник. А наследовать квадрат от прямоугольника тоже не очень, нужен базовый класс — геометрическаяФигура, от которого всё происходит. У Художника метод нарисоватьПрямоугольник принимает один или 2 параметра, и, если один параметр на входе, то рисуем квадрат. Хотя, наверно, входным парметром должен быть сам объект… хм
новый Квадрат(сторона)
новый Прямоугольник(ширина, длина)
новый Художник(какие-то параметры, диплом, опыт...)
Художник->нарисуй(Квадрат) //возможно так
Третья полка должна быть более вместительной.
Чтобы залезть на вторую полку в старом плацкарте я всегда использую третью полку — хватаюсь за неё. В новом дизайне залезать будет крайне неудобно, должна быть какая-то ручка выше второй полки, чтобы схватиться и втянуть себя на вторую полку.
Шкаф в купе — сомнительное удовольствие. Например, как заправлять постель? куда девать матрас — чтобы разложить столик? как свесить ноги в поездке? как запихнуть багаж под сиденье?
Думаю, третью полку можно оставить как в новом дизайне в области головы, чтобы можно было сидеть на второй полке, а в области ног довести до конца третью полку(как в старом плацкарте). Получится такая буква Г.
Окошечко между стен — круто придумали.
В остальном вроде всё ок, но это уже выяснится в процессе эксплуатации.
Также, считаю, надо избавляться от привычки жрать в поезде. Что, дома или в другом месте поесть нельзя? В чем удовольствие тащить с собой еду, и есть ее на грязном столе? И потому столько столиков не нужно. А ноутбук можно и на колени положить.
Я против избавляться от такой привычки, особенно когда ехать надо двое суток!
Бойся не ножа, а вилки. Один удар - четыре дырки.
Я бы решил эту задачу средствами API Bitrix, не сделав ни одного sql запроса, не делая этих перезаливов. А с другого сайта нашел и скачал бы картинки стандартными средствами php.
Но если бы я был питонистом и впервые столкнулся с битриксом, то наверное поинтересовался у битриксоводов, на форум бы зашел, на тостере задал пару вопросов, погуглил бы для начала как следует, почитал бы документацию по диагонали :)
Сделал бы наверное за вечер.
А как отключение JIT сказывается на безопасности?
2. На основе ZendFramework сделали своё для корп.сектора, где сделали отличную админку, кучу интересных вещей, использовали на многих проектах, но на версии php выше 5.6 — все наработки стали legacy, вышел новый ZF, с новым подходом. В итоге отложили на полку, т.к. делать update некому и нет ресурсов.
3. Пришел изначально простой проект, который должен со временем масштабироваться до сложного. Решил попробовать сделать без фреймворка. Собрал из разных библиотек(маршрутизация, ORM, ...), накидал свои классы. Никаких особых сложностей при разработке не возникло, т.к. двигался от простого к сложному и знал как будет развиваться приложение. Но, есть одно но — мне всё понятно и просто, т.к. написал всё я. Как потом будет ориентироваться другой разработчик — вот тут возникает жирный вопрос, потому как сейчас там много всего. А документации нет. Есть только комментарии в коде, phpDoc и readme. Получается, следующий разраб будет дописывать по-своему, и так далее. Плюс я ограничен уровнем своей компетенции и могу какие-то вещи не учесть, где во фреймворке это было бы из коробки.
Манипуляция с DOM, работа с файлами, drag&drop, какие-то специфичные js библиотеки.
Ситуации, когда проще написать на js. Ситуация, когда сторонний проект не с нуля и там js.
Это очень здоровский ход(конём): «Упрощается процесс отслеживания совместимости API между клиентом и сервером». Сам столкнулся с подобным, используются вычисления как на клиенте, так и на сервере, в итоге нужно изменения применять в 2х местах. А данный подход мог бы упростить работу.
новый Квадрат(сторона)
новый Прямоугольник(ширина, длина)
новый Художник(какие-то параметры, диплом, опыт...)
Художник->нарисуй(Квадрат) //возможно так
Чтобы залезть на вторую полку в старом плацкарте я всегда использую третью полку — хватаюсь за неё. В новом дизайне залезать будет крайне неудобно, должна быть какая-то ручка выше второй полки, чтобы схватиться и втянуть себя на вторую полку.
Шкаф в купе — сомнительное удовольствие. Например, как заправлять постель? куда девать матрас — чтобы разложить столик? как свесить ноги в поездке? как запихнуть багаж под сиденье?
Думаю, третью полку можно оставить как в новом дизайне в области головы, чтобы можно было сидеть на второй полке, а в области ног довести до конца третью полку(как в старом плацкарте). Получится такая буква Г.
Окошечко между стен — круто придумали.
В остальном вроде всё ок, но это уже выяснится в процессе эксплуатации.