Тригонометрия то была. Но как то нам так преподавали, что мы вообще никто не понимал, зачем эти синусы, косинусы и тангенсы. Для чего они были придуманы кроме как осложнить жизнь школьника. И уже только в институте стало понятно зачем, там получше объяснили и на каких-то примерах показали. А в школе это был сферический конь в вакууме, в которого мы должны были верить, что так надо и всё. Не помню чтобы в школе мы вычисляли расстояния между точками на шаре или что-то подобное, даже знания о меридианах и параллелях возникло из георгафии, а не из геометрии. Не помню чтобы мы когда либо изображали шар и что-то считали. Может в качестве чисто формул и рассчитывали, но без изображений шаров, это все просто вылетело из головы как страшный сон
Ну, здесь все такие великие математики сидят, которые еще в школе такие вещи вычисляли. Я не из таких, вообще ничего подобного не помню, чтобы в школе нас учили. Самое обидное то, что когда я искал информацию для решения своей задачи, я не нашел ничего, даже вот такой статьи как эта в которой большие погрешности. Я не нашел ровным счетом ничего, что могло бы помочь, поэтому я и пошел гуглить и на википедию. Раз я ничего не нашел по своей задаче, значит материала об этом крайне мало и найти сложно. Если все такие великие математики, почему не напишут более крутую, углубленную статью да еще и на ресурсе типа Хабра чтобы ее можно было найти, а не в личном блоге, где 3 посещения в месяц и найти его не реально.
Заминусовали, спасибо! Буду знать, что есть способы лучше, но по честному 31 закладка на момент написания этого комментария говорит о том, что полезная эта статья гораздо больше, чем хейта под ней, просто те кто делает закладки, не все могут ставить плюсы и минусы. Но я для себя понимаю, что статья все-таки полезная, пусть в ней и много недочетов
Когда я искал решение своей задачи, пришлось собирать по кусочку с разных мест.
Судя по количеству закладок, которые читатели добавили на эту статью, - она все же полезная, потому что собирает те крупицы информации в одном месте для решения конкретной задачи. Пусть решение не лучшее, но есть явный показатель того, что кому то оно кажется полезным
А вообще не всегда можно взять какую то более подходящую базу на живом проекте. Да это может быть и изначальный архитектурный просчет, однако базу сменить нельзя а задачу решить надо, какая бы глупая она не была или не казалась таковой.
Я не в коем случае и не говорил, что это лучшее решение моей задачи, но это было лучшее из того, что я нашел
Да, так и получились большинство фреймоворков, возможно)))
Ну я например видел такой подход. Берут бибилиотеки готовые, например для маршрутизации и ORM для БД, и создают собственную архитектуру где это и как должно лежать. По сути да получается собственный фреймворк, при грамотной архитектуре лучше чем любой публичный, в том плане, что хорошо подходит под текущий проект, а минусы как правило в том, что не очень универсальный и документации мало)
Вот зря вы так. На чистом PHP можно сделать хорошую архитектуру, без всяких фреймворков, просто время разработки будет существенно увеличено. Да, это не самая тривиальная задача, целая куча книг об архитектуре, и порой сложно выбрать или создать подходящую под конкретный проект, но тем не менее! На чистом можно делать красиво и без говнокода. Я в этом убедился поработав в Roistat
Не обязательно. Я не показываю, что у меня в дата. А там может быть отметка времени например. Это уже от реализации. И если на беке данные по метке новее, чем в присылаешь запросе, значит даём положительный ответ на запрос, Т. Е. Код 200, можно даже с сообщением, о том, что на сервере данные новее и не перезаписываем их.
Спасибо, это очень дельное замечание. У меня не так уж и страшно конечно, что что то пойдёт не так, но для такого проекта как кассы это действительно критично. Подумаю, что можно сделать
Не совсем понял о чем речь, но если это про обработчик ошибки, то он не относится к самому «Брокеру», ошибки мы можем обрабатывать как угодно, а я делаю упор на описание функционала именно брокера. Но если интересно, есть такой вариант. Можно передать в качестве аргумента, обхект текущего контекста в котором мы работаем, например VueObject или подобное. Тогда в нем будет работать все то, что работает в конкретном Vue-компоненте, и можно сделать что-то подобное:
VueObject.$store.commit('AlertError', 'Ошибка получения данных с сервера');
Я проверял такое работает, но как то архитектурно не красиво, имхо. В своем проекте пока сам не придумал, как сделать лучше. Но нужно учитывать, что у меня есть компоненты Vue, есть Vuex (Vue-store) и т.п. поэтому это подходит моему проекту, а другому уже не пойдет, поэтому и не подходит в рамках общей статьи об идее создания такого брокера, который должен работать не зависимо от библиотеки или фреймворка. Я привожу лишь примеры использования в рамках Vue, потому что очень схоже будет и в React и возможно в Angular( это не точно, я не знаю ангуляр)
Привет elenk_r, я думаю, что я не в праве давать в данном случае какие-либо советы, по той причине, что я не знаю ни ваш действующий ресурс, ни доработок, которые требуются сделать. Yii2 можно мастабировать, но есть определенные нюансы связывающие руки в некотором смысле, но они есть и у других фреймов. Тут надо рассматривать позадачно и по трудозатратам. Если текущий проект не сложно переложить на Laravel и он решает другие проблемы, то смысл конечно есть. Если же планируется масштабирование еще в будущем, помимо ЛК и оплат, я бы посоветовал смотреть в сторону микросервисной архитектуры, где вообще каждый сервис может работать на своем фреймворке, но это тоже несет существенные минусы, зато хорошо подходит в качестве временных переходных решений, позволяет параллельно переписывать старые сервисы на новый движок. А если текущий проект не очень большой и нужно только добавить личный кабинет с небольшим количеством настроек и оплат, тут и Yii2 с легкостью справится с этой задачей. Если в ближайшем будущем не требуется серьезных расширений, я бы оставил старый движок, так как и команде с ним привычней работать и сделать будет быстрее чем переписывать с нуля. Однако нужно еще понимать, насколько «загажен» в коде ваш текущий проект. Если там он так сделан, что масштабирование настолько сложное, что почти невозможное, то пора писать новый проект, на чем то новом.
Ну и еще. Если планируется серьезное масштабное расширение с кучей фич и переход на микросервисную, я бы предложил смотреть в сторону минималистичных фреймворков, типа Silex (сейчас устарел) или Symfony 4, где все лишнее из коробочной сборки выпилино, даже doctrine. Все можно установить, но уже по раздельности. Для крупных растущих проектов самое оно, есть контроллеры и все, модели и остальную архитектуру организуй как хочешь!
Компоненты решают эту проблему. Некоторые компоненты работают так, что можно с сервера получить, например json, собрать в объект, и объект отдать компоненту, он сам отрендерид гриды. В том же Vuetify, о котором я говорил выше, есть data-tables — компонент, который это делает. А компоненты реально удобные, сравнимы с реактовскими
Хорошая очень штука Vuetify. Очень много компонентов, удобно делать полноценное веб-приложение. Есть проблемы со встроенной версткой правда, кастомизировать сложно, но если к дизайну приложения придирок особых нет, то быстро и удобно. На Ларе, кстати, собирается на раз два mix'ом
Потому что если сравнивать. То возможности самих фреймов. А если говорить о различных надстройках, то вообще можно придти к выводу что все имеют одинаковые возможности с разной реализацией просто.
Тригонометрия то была. Но как то нам так преподавали, что мы вообще никто не понимал, зачем эти синусы, косинусы и тангенсы. Для чего они были придуманы кроме как осложнить жизнь школьника. И уже только в институте стало понятно зачем, там получше объяснили и на каких-то примерах показали. А в школе это был сферический конь в вакууме, в которого мы должны были верить, что так надо и всё. Не помню чтобы в школе мы вычисляли расстояния между точками на шаре или что-то подобное, даже знания о меридианах и параллелях возникло из георгафии, а не из геометрии. Не помню чтобы мы когда либо изображали шар и что-то считали. Может в качестве чисто формул и рассчитывали, но без изображений шаров, это все просто вылетело из головы как страшный сон
Ну, здесь все такие великие математики сидят, которые еще в школе такие вещи вычисляли. Я не из таких, вообще ничего подобного не помню, чтобы в школе нас учили. Самое обидное то, что когда я искал информацию для решения своей задачи, я не нашел ничего, даже вот такой статьи как эта в которой большие погрешности. Я не нашел ровным счетом ничего, что могло бы помочь, поэтому я и пошел гуглить и на википедию. Раз я ничего не нашел по своей задаче, значит материала об этом крайне мало и найти сложно. Если все такие великие математики, почему не напишут более крутую, углубленную статью да еще и на ресурсе типа Хабра чтобы ее можно было найти, а не в личном блоге, где 3 посещения в месяц и найти его не реально.
Заминусовали, спасибо! Буду знать, что есть способы лучше, но по честному 31 закладка на момент написания этого комментария говорит о том, что полезная эта статья гораздо больше, чем хейта под ней, просто те кто делает закладки, не все могут ставить плюсы и минусы. Но я для себя понимаю, что статья все-таки полезная, пусть в ней и много недочетов
ЕГЭ я никогда не сдавал
С геометрией у меня реально все плохо
Когда я искал решение своей задачи, пришлось собирать по кусочку с разных мест.
Судя по количеству закладок, которые читатели добавили на эту статью, - она все же полезная, потому что собирает те крупицы информации в одном месте для решения конкретной задачи. Пусть решение не лучшее, но есть явный показатель того, что кому то оно кажется полезным
Да, вы правы увидел на википедии https://en.wikipedia.org/wiki/Latitude#Meridian_distance. Не обратил внимание!
А вообще не всегда можно взять какую то более подходящую базу на живом проекте. Да это может быть и изначальный архитектурный просчет, однако базу сменить нельзя а задачу решить надо, какая бы глупая она не была или не казалась таковой.
Я не в коем случае и не говорил, что это лучшее решение моей задачи, но это было лучшее из того, что я нашел
Это НЛО боты) Они всех минусуют, чтобы рекламу не мог отключить)
Прочитайте статью. Там и написано, что посчитать расстояние между двумя точками это не подходящее решение, когда нам нужна выборка объектов.
Да об этом написано!
Исправил картинку и квадрат
Вообще впервые услышал о нем. Теперь почитал, да интересная штука, на будущее буду иметь ввиду. Вот это конструктивно и по делу, спасибо!
Ну я например видел такой подход. Берут бибилиотеки готовые, например для маршрутизации и ORM для БД, и создают собственную архитектуру где это и как должно лежать. По сути да получается собственный фреймворк, при грамотной архитектуре лучше чем любой публичный, в том плане, что хорошо подходит под текущий проект, а минусы как правило в том, что не очень универсальный и документации мало)
Не обязательно. Я не показываю, что у меня в дата. А там может быть отметка времени например. Это уже от реализации. И если на беке данные по метке новее, чем в присылаешь запросе, значит даём положительный ответ на запрос, Т. Е. Код 200, можно даже с сообщением, о том, что на сервере данные новее и не перезаписываем их.
Слышал про него. Но что-то не подумал. Изучу подробнее, спасибо!
Спасибо, это очень дельное замечание. У меня не так уж и страшно конечно, что что то пойдёт не так, но для такого проекта как кассы это действительно критично. Подумаю, что можно сделать
Я проверял такое работает, но как то архитектурно не красиво, имхо. В своем проекте пока сам не придумал, как сделать лучше. Но нужно учитывать, что у меня есть компоненты Vue, есть Vuex (Vue-store) и т.п. поэтому это подходит моему проекту, а другому уже не пойдет, поэтому и не подходит в рамках общей статьи об идее создания такого брокера, который должен работать не зависимо от библиотеки или фреймворка. Я привожу лишь примеры использования в рамках Vue, потому что очень схоже будет и в React и возможно в Angular( это не точно, я не знаю ангуляр)
Ну и еще. Если планируется серьезное масштабное расширение с кучей фич и переход на микросервисную, я бы предложил смотреть в сторону минималистичных фреймворков, типа Silex (сейчас устарел) или Symfony 4, где все лишнее из коробочной сборки выпилино, даже doctrine. Все можно установить, но уже по раздельности. Для крупных растущих проектов самое оно, есть контроллеры и все, модели и остальную архитектуру организуй как хочешь!
Потому что если сравнивать. То возможности самих фреймов. А если говорить о различных надстройках, то вообще можно придти к выводу что все имеют одинаковые возможности с разной реализацией просто.