Понимаю, английский очень важен, но большая проблема — контент. Потому что идут в приложение за контентом.
Интерфейс уже более-менее готов к анг версии, как и код. А написать хотя бы 200-400 текстов на ангийском сложная задача
окей, понял, спасибо
В контексте статьи выше это не очень применимая штука. Потому что статья не о том, как правильно сделать архитектуру для прод решения, а о том, что такое вообще микросервисы и как переписать на них домашний проект без кучи новых библиотек.
Проще говоря, наверное, сначала нужно такое, а потом уже углубляться во всякие библиотеки и правильные решения для микросервисов.
Я не знаю что такое Eureka.
Каждый сервис запускается отдельно и имеет свой адрес, а в zuul они просто прописываются, чтобы он понимал куда слать запросы.
По-моему им нужно показать что язык это инструмент для конкретной задачи, а не твой выбор на десятилетия вперёд. И что нет хороших или плохих языков, как и не нужно пытаться становиться разработчиком на языке X.
Возможно, если так учить, будет меньше потом бурчания "язык X — говно, не то что Y".
Нажатие на точку начала или конца — удаляет точку. После этого можно её поставить в другом месте.
Ещё их можно просто двигать, зажав)
Если ввести адрес — выбранный адрес преобразуется в точку. Там отдельные поля и для начала, и для конца.
Думаю в партнёрстве с какими-нибудь туристическими агентами возможно покрыть всё крупное сразу.
Я думал что стандарт — длинное нажатие. Поэтому там установка точки это длинное нажатие на карту
В целом же по дефолту маршрут строится от текущей точки, но её можно удалить.
Или адреса вводить в поля.
Но то что я тут объясняю интерфейс, означает что нужно над ним ещё поработать)
ещё, что кажется важным, просто данных в OSM не достаточно — никому не нужны просто названия. Ты приезжаешь в незнакомый город, видишь точку "Собор имени Ивана Иванова", и ты знать не знаешь что это за фигня и стоит ли тратить время чтобы туда дойти.
Нужна своя база с картинками, текстами и всем-всем-всем.
У меня похожий проект давно развивается. Уже есть версия в Google Play. Но меньше акцента на алгоритмах, больше на интерфейсе. Потому что какие бы хорошие маршруты не выходили — они мало кому нужны, если ими неудобно пользоваться.
Сложно сказать, не засекал, но вроде как не сильно много, за исключением авторизации, с которой были проблемы. Сначала там смотрел на Redis сессии, потом уже JWT. Даже чисто по статье, на которую я ссылаюсь, сходу не вышло потому что AbstractAuthenticationProcessingFilter не подходит для моих целей.
Без авторизации статья вышла бы на пол года раньше, никак не мог найти время чтобы разобраться до конца.
Понял, спасибо, подумаем об этом
А как вы искали? Всё же ищут не по названию, а по запросам типа "Путеводитель по Санкт-Петербургу" Wander на первой странице выдачи.
Но в целом про ранжирование в сторе и про то как правильно заполнять всякие там поля я не очень знаю, буду рад советам.
Всё же название не главная проблема продвижения приложения)
Рынок есть, да, потенциальная аудитория большая (особенно если брать не только Питер). А вот как к этой аудитории прийти — не до конца понятно.
Да, тонкая настройка очень полезная штука, но сложная и технически, и для интерфейса
Понимаю, английский очень важен, но большая проблема — контент. Потому что идут в приложение за контентом.
Интерфейс уже более-менее готов к анг версии, как и код. А написать хотя бы 200-400 текстов на ангийском сложная задача
Спасибо!
Пока ещё нет, сложно влетать во всё сразу.
в статье есть на него ссылка
У вас какой-то научный грант на разработку?
окей, понял, спасибо
В контексте статьи выше это не очень применимая штука. Потому что статья не о том, как правильно сделать архитектуру для прод решения, а о том, что такое вообще микросервисы и как переписать на них домашний проект без кучи новых библиотек.
Проще говоря, наверное, сначала нужно такое, а потом уже углубляться во всякие библиотеки и правильные решения для микросервисов.
Я не знаю что такое Eureka.
Каждый сервис запускается отдельно и имеет свой адрес, а в zuul они просто прописываются, чтобы он понимал куда слать запросы.
По-моему им нужно показать что язык это инструмент для конкретной задачи, а не твой выбор на десятилетия вперёд. И что нет хороших или плохих языков, как и не нужно пытаться становиться разработчиком на языке X.
Возможно, если так учить, будет меньше потом бурчания "язык X — говно, не то что Y".
хм, не знал, спасибо! Судя по всему, можно напарсить, ссылаясь на источник
Авторские права, всё такое. Это проблема, если мы говорим о полноценном продукте, а не о поделке на коленке.
Нажатие на точку начала или конца — удаляет точку. После этого можно её поставить в другом месте.
Ещё их можно просто двигать, зажав)
Если ввести адрес — выбранный адрес преобразуется в точку. Там отдельные поля и для начала, и для конца.
Думаю в партнёрстве с какими-нибудь туристическими агентами возможно покрыть всё крупное сразу.
Я думал что стандарт — длинное нажатие. Поэтому там установка точки это длинное нажатие на карту
В целом же по дефолту маршрут строится от текущей точки, но её можно удалить.
Или адреса вводить в поля.
Но то что я тут объясняю интерфейс, означает что нужно над ним ещё поработать)
именно) https://play.google.com/store/apps/details?id=ru.travelpath
ещё, что кажется важным, просто данных в OSM не достаточно — никому не нужны просто названия. Ты приезжаешь в незнакомый город, видишь точку "Собор имени Ивана Иванова", и ты знать не знаешь что это за фигня и стоит ли тратить время чтобы туда дойти.
Нужна своя база с картинками, текстами и всем-всем-всем.
Очень круто!
У меня похожий проект давно развивается. Уже есть версия в Google Play. Но меньше акцента на алгоритмах, больше на интерфейсе. Потому что какие бы хорошие маршруты не выходили — они мало кому нужны, если ими неудобно пользоваться.
Заголовок "Как настроить принтер" для технического ресурса очень забавный
Сложно сказать, не засекал, но вроде как не сильно много, за исключением авторизации, с которой были проблемы. Сначала там смотрел на Redis сессии, потом уже JWT. Даже чисто по статье, на которую я ссылаюсь, сходу не вышло потому что
AbstractAuthenticationProcessingFilterне подходит для моих целей.Без авторизации статья вышла бы на пол года раньше, никак не мог найти время чтобы разобраться до конца.