В Laravel все из коробки. В Symfony нужно знать, как минимум, о существовании скелетонов с пресетами бандлов. Если в процессе разработки на Symfony нужно докинуть какой-нибудь бандл, то добро пожаловать в yaml конфиг. В Laravel конфигурирование более очевидное.
В Symfony по умолчанию запрещен доступ к сервис контейнеру. Фреймворк прямо говорит, что дергать сервисы в любом месте приложения — плохо. В то время как у Laravel противоположная концепция — «фасады» доступны всегда и везде.
В Symfony многое работает на рефлексии (аннотации, атрибуты) — разработчик должен понимать, что это такое, дабы не воспринимать происходящее как магию. У Symfony жизненный цикл построен на событиях, в то время как весь Laravel — это цепочка мидлварей.
Элоквент — active record. Доктрина — data mapping. То есть, в Laravel модель содержит в себе все, что угодно для построения запросов в БД. В Symfony из коробки есть слой репо, концептуально это сложнее.
То есть Laravel в какой-то степени более прямолинейный и менее требовательный к архитектуре. И коммьюнити у него больше. Преимуществ у Symfony не меньше, чем в Laravel, но чтобы ими пользоваться, разработчик должен точно знать, что ему нужно и где это найти.
Flutter действительно не самый сложный фреймворк, но месяц с нуля — все-таки громкое заявление. Если у разработчика уже есть опыт (с тем же RN, например), то да, возможно)
MySQL у нас служит базой, так как большая часть проектов не требует иных решений. Если требования бизнеса будут диктовать иные требования, решения будут другими)
Стек тоже важен. Потому что если гипотезы стартапа оправдаются, скорее всего, понадобятся разработчики для развития и поддержки этого продукта/проекта. А для этого очень важен правильный стек. Если в нем будут плохо поддерживаемые технологии, продукт далеко не уедет. Другой вопрос в том, что не все об этом задумываются на старте, потому что волнует другое.
Итоговый продукт зависит больше от общих процессов, а не от стека. Но и если в стек напихать плохо поддерживаемые технологии, ничего хорошего не выйдет. Продукт может быть взлетит, но на длинной дистанции проиграет аналогичному решению, но с хорошо подобранным стеком)
Скачать как раз-таки может, это мы дали некорректную инфу. Спасибо, что зацепили на этом глаз, поправим!)
Ситуация такая. Например, арендатору нужны документы, которые системой не генерируются (это доп. соглашение на парковочное место, соглашение о пролонгации или расторжении договора и акт приема-передачи) или уже подписанные документы.
Арендатор может попросить арендодателя сформировать эти документы и загрузить их в его личный кабинет. После этого арендатор сможет выгрузить их себе самостоятельно.
Это субъективно, на самом деле — кому-то ярко и вырвиглазно, кому-то ок. Зависит в том числе и от цветопередачи монитора. Но вообще белый на горчичном следует воспринимать без отрыва от контекста с брендбуком клиента. Изначально мы предлагали белый на зеленом, клиент настоял на своем видении.
Разработкой сцены занимался дизайнер, который ранее не имел дело с UE. А разработчик помогал доработать логику и устранял проблемы с тенями. Если брать процентное соотношение, то работа Алексея занимала 30% от всего объема.
Попробовали — все работает. Возможно, просто соединение слабое. Рекомендуем все-таки попробовать открыть через ПК, там и поиграться с машинкой можно. На Android этого не сделать)
1. Если рассматривать базовые возможности локализации, то они покрывают стандартные сценарии. Нам на основе этого удалось сделать локализацию по городам. Но отсюда вытекают минусы — из коробки нельзя добавлять новые локали динамически из условной админки т.к. нужно добавлять локаль в next.config и пересобирать после этого фронт. Беглый поиск решения проблемы ничего не дал. В дискуссиях репозитория на Гитхабе был неплохой тред, который предлагал интересное решение (сейчас не смогли найти этот тред). В текущих реалиях проекта проблема неприятна, но не смертельна. Если найдем решение, обязательно напишем об этом!
2. Да, у DaData и Яндекс Карт действительно есть проблемы с совпадением адресов. И в принципе их наличием в одном из сервисов. Больше всего актуально для номеров домов, поэтому мы в какой-то момент отказались от подсказки дома, так как возникали конфликтные ситуации.
Помимо этого, адрес, который мы отправляли с фронта, также попадал в iiko, где использовался другой сервис для работы с адресами, с которым тоже возникали проблемы. В конечном итоге мы выбрали DaData, т.к. у него наиболее точная база. Поэтому с фронта мы отправляли адрес из DaData. Яндекс.Карты в нашем случае используется только для получения координат.
Да, вы правы. Микрофреймворк на то и микрофреймворк, что из него можно сделать все, что душе угодно. Если среди больших фреймворков по какой-то причине нет подходящей технологии, то ее можно сделать на базе микрофреймворка. Просто это дольше и дороже.
Спорное утверждение. Иметь каркас, подходящий под основные задачи, на наш взгляд, все-таки лучше, чем не иметь ничего и тратить огромное количество времени на создание велосипедов. А дальше уже обкладывать микросервисами с интересующими нюансами. Хоть на Rust, хоть на Python. Либо это должен быть настолько крупный и уникальный проект, для которого вообще нет решений. Что маловероятно, но возможно (но процент крайне мал).
В Laravel все из коробки. В Symfony нужно знать, как минимум, о существовании скелетонов с пресетами бандлов. Если в процессе разработки на Symfony нужно докинуть какой-нибудь бандл, то добро пожаловать в yaml конфиг. В Laravel конфигурирование более очевидное.
В Symfony по умолчанию запрещен доступ к сервис контейнеру. Фреймворк прямо говорит, что дергать сервисы в любом месте приложения — плохо. В то время как у Laravel противоположная концепция — «фасады» доступны всегда и везде.
В Symfony многое работает на рефлексии (аннотации, атрибуты) — разработчик должен понимать, что это такое, дабы не воспринимать происходящее как магию. У Symfony жизненный цикл построен на событиях, в то время как весь Laravel — это цепочка мидлварей.
Элоквент — active record. Доктрина — data mapping. То есть, в Laravel модель содержит в себе все, что угодно для построения запросов в БД. В Symfony из коробки есть слой репо, концептуально это сложнее.
То есть Laravel в какой-то степени более прямолинейный и менее требовательный к архитектуре. И коммьюнити у него больше. Преимуществ у Symfony не меньше, чем в Laravel, но чтобы ими пользоваться, разработчик должен точно знать, что ему нужно и где это найти.
Flutter действительно не самый сложный фреймворк, но месяц с нуля — все-таки громкое заявление. Если у разработчика уже есть опыт (с тем же RN, например), то да, возможно)
MySQL у нас служит базой, так как большая часть проектов не требует иных решений. Если требования бизнеса будут диктовать иные требования, решения будут другими)
Стек тоже важен. Потому что если гипотезы стартапа оправдаются, скорее всего, понадобятся разработчики для развития и поддержки этого продукта/проекта. А для этого очень важен правильный стек. Если в нем будут плохо поддерживаемые технологии, продукт далеко не уедет. Другой вопрос в том, что не все об этом задумываются на старте, потому что волнует другое.
Обычно наоборот — команда подбирается под выбранный стек, если не брать частности и прочие «но»
Все верно. В превью так и написали: рассказываем, с чем работаем, чтобы продукт жил и процветал.
Спасибо за обратную связь!
Итоговый продукт зависит больше от общих процессов, а не от стека. Но и если в стек напихать плохо поддерживаемые технологии, ничего хорошего не выйдет. Продукт может быть взлетит, но на длинной дистанции проиграет аналогичному решению, но с хорошо подобранным стеком)
Скачать как раз-таки может, это мы дали некорректную инфу. Спасибо, что зацепили на этом глаз, поправим!)
Ситуация такая. Например, арендатору нужны документы, которые системой не генерируются (это доп. соглашение на парковочное место, соглашение о пролонгации или расторжении договора и акт приема-передачи) или уже подписанные документы.
Арендатор может попросить арендодателя сформировать эти документы и загрузить их в его личный кабинет. После этого арендатор сможет выгрузить их себе самостоятельно.
Это субъективно, на самом деле — кому-то ярко и вырвиглазно, кому-то ок. Зависит в том числе и от цветопередачи монитора. Но вообще белый на горчичном следует воспринимать без отрыва от контекста с брендбуком клиента. Изначально мы предлагали белый на зеленом, клиент настоял на своем видении.
Не совсем поняли вопроса. Пример, когда такое происходит? Или раскрыть с технической точки зрения?
Поделитесь, если не трудно :)
Здравствуйте. Хорошо, подумаем, как эту тему лучше преподнести. Может есть какие-то тезисы, о которых стоит рассказать отдельно?
Разработкой сцены занимался дизайнер, который ранее не имел дело с UE. А разработчик помогал доработать логику и устранял проблемы с тенями. Если брать процентное соотношение, то работа Алексея занимала 30% от всего объема.
Попробовали — все работает. Возможно, просто соединение слабое. Рекомендуем все-таки попробовать открыть через ПК, там и поиграться с машинкой можно. На Android этого не сделать)
Да, F5 — это для рестарта. В остальном учтем пожелания для дальнейших проектов. Спасибо :)
Здравствуйте! Просто висит, без ошибок? Попробуйте перезагрузить. Мы перепроверили — все работает.
Вам спасибо за коммент!
1. Если рассматривать базовые возможности локализации, то они покрывают стандартные сценарии. Нам на основе этого удалось сделать локализацию по городам. Но отсюда вытекают минусы — из коробки нельзя добавлять новые локали динамически из условной админки т.к. нужно добавлять локаль в
next.configи пересобирать после этого фронт. Беглый поиск решения проблемы ничего не дал. В дискуссиях репозитория на Гитхабе был неплохой тред, который предлагал интересное решение (сейчас не смогли найти этот тред). В текущих реалиях проекта проблема неприятна, но не смертельна. Если найдем решение, обязательно напишем об этом!2. Да, у DaData и Яндекс Карт действительно есть проблемы с совпадением адресов. И в принципе их наличием в одном из сервисов. Больше всего актуально для номеров домов, поэтому мы в какой-то момент отказались от подсказки дома, так как возникали конфликтные ситуации.
Помимо этого, адрес, который мы отправляли с фронта, также попадал в iiko, где использовался другой сервис для работы с адресами, с которым тоже возникали проблемы. В конечном итоге мы выбрали DaData, т.к. у него наиболее точная база. Поэтому с фронта мы отправляли адрес из DaData. Яндекс.Карты в нашем случае используется только для получения координат.
Да, вы правы. Микрофреймворк на то и микрофреймворк, что из него можно сделать все, что душе угодно. Если среди больших фреймворков по какой-то причине нет подходящей технологии, то ее можно сделать на базе микрофреймворка. Просто это дольше и дороже.
Вот здесь можно посмотреть — https://kinsta.com/blog/php-benchmarks/. И вот здесь — https://www.techempower.com/benchmarks/#hw=ph&test=fortune§ion=data-r22&l=zik073-cn3, но тут не уверены за их неангажированность.
Спорное утверждение. Иметь каркас, подходящий под основные задачи, на наш взгляд, все-таки лучше, чем не иметь ничего и тратить огромное количество времени на создание велосипедов. А дальше уже обкладывать микросервисами с интересующими нюансами. Хоть на Rust, хоть на Python. Либо это должен быть настолько крупный и уникальный проект, для которого вообще нет решений. Что маловероятно, но возможно (но процент крайне мал).