честно говоря уже на первый вопрос ответ в корне не верный — Если вы случайно вдруг обнаружили, что tomcat стал есть 80%, то надо разбираться почему он стал их есть,
а не поднимать новые сервера.
Причина в 90% случаев в архитектуре и балансинг тут ничем не поможет.
За знанием названий технологий и их назначения часто скрывается белая пелена их практического применения.
Потому подобные общие вопросы на собеседовании — пальцем в небо.
Лучше спросить меньше но глубже.
Это уже немного смешно.
Именно в твиттере придумали многие интерфейсы, которые потом тот же Google
уже использовал в своих Android (при чем в разное время разные),
да и не только в Android (всеми любимый Pull To Refresh)
Да и вообще
Гайды Google за время жизни Android скачут то туда то сюда.
Это не священный грааль.
Используем на сервере github.com/Atmosphere/atmosphere + Jetty
(она поддерживает сразу и вебсокеты и longpolling)
на веб клиенте jquery.atmosphere.js
на Android клиенте de.tavendo.autobahn.WebSocket
Вообще то определение по Wifi реализует сам телефон/Android, а сторонние программы, типа этой, это просто используют.
DeviceManager соответственно точно также определяет местоположение как по GPS, так и по Wifi и GSM
Но как замечено выше производитель платформы лучше знает как пользоваться своим же API.
Проверьте ради интереса
Вопрос не в железе, а в том, что позиционирование внутри зданий по вайфай само по себе по большому счету мало кому нужно.
Интересует позиционирование не внутри зданий, а внутри города.
С GPS включенным в здании будет облом (если он до этого не был запущен на улице),
объект потерян напрочь, пока не выйдет на улицу.
Здесь спасает только примерное GSM позиционирование
По WiFi методу же можно определить позицию с точностью до дома.
Но и про позиционирование внутри зданий: если бы это было ни кому не нужно, то
Apple и Google не занимались этим так плотно, как последние годы.
да я прекрасно знаю как это работает.
У yandex есть бесплатное API получения координат по WiFi списку MAC, у Google — платное
задача железки — передать видимые MAC, также как сейчас большинство трекеров передают список CID-ов GSM вышек.
Ровно так работает определение местоположения в iPhone, Android
Но железок таких вменяемых нет, жду когда появится образец знакомых разработчиков (нужен для нашего проекта)
Попробовали бы лучше WiFi Трекер
GPS трекеров пруд пруди. И у всех один минус — в зданиях они не работают.
Даже на подоконнике (как у вас) — может долго стартовать и убивать батерею.
Заметьте наши iPhone и Android ловят местоположение в 99% случаев по Wifi, а по GPS только на улице.
Знакомые инженеры разрабатывают подобный серийный трекер с WiFi+GPS+GSM, но жду уже год его.
Если у кого-то есть подобные наработки — напишите в личку.
Не уверен, но вроде apple патентовал технологию экрана, под которым маленькие иголочки могут создавать объем под пальцем, что позволит эмулировать кнопки.
Мода, мода, мода… Ради бога.
Плохо что уже из-за этой моды не можешь отличить в интерфейсе текст от кнопки,
а шрифты такие тонкие, что скоро просто испарятся.
Но, блядь, так красиво и минималистично…
да, я про такие случаи, как ваш пример с комментариями.
Это уже немного хак получается, что при получении объекта товара передваются еще зачем-то комментарии,
которые не всегда нужны в другом случае использования API.
Значит нужен доп. параметр (когда их передавать, когда нет), потом параметр лимит на число комментариев и т.д.
И в добавок к этому может, например, потребоваться вывести еще 3 похожих товара (если продолжить пример с магазином).
Однако на практике часто красота жертвуется в пользу оптимизации запросов.
Стандартный кейс:
есть красивое REST API по сущностям.
но для приложения работающего через хреновый GPRS каждый лишний запрос — это замедление времени работы приложения.
И часто нужно, чтобы одним запросом можно было вернуть все нужные данные и никакой умный кеш этой задачи не решит.
Как уложить в архитектуру такие запросы сразу нескольких объектов?
Авторизовавшись с мобильного можно постить и писать сообщения с сервера
без ограничений (permission offline_access снимающий ограничение по ip)
Потому причина другая, а не как таковой запрет запросов к API с сервера.
Да. И очень советую посмотреть весь сериал.
Это 6 независимых сюжетов по теме этого топика:
«Сквозная тема — влияние информационных технологий на человеческие отношения»
Совсем недавно смотрел сериал Черное зеркало
В одной из серий как раз был сюжет про то, что у каждого человека встроена камера
и любой момент жизни можно за секунды отмотать и пересмотреть.
Ну и как следствие — хрен чего скроешь, каждый горазд тебя запалить. Ссылка на серию
а не поднимать новые сервера.
Причина в 90% случаев в архитектуре и балансинг тут ничем не поможет.
За знанием названий технологий и их назначения часто скрывается белая пелена их практического применения.
Потому подобные общие вопросы на собеседовании — пальцем в небо.
Лучше спросить меньше но глубже.
Именно в твиттере придумали многие интерфейсы, которые потом тот же Google
уже использовал в своих Android (при чем в разное время разные),
да и не только в Android (всеми любимый Pull To Refresh)
Да и вообще
Гайды Google за время жизни Android скачут то туда то сюда.
Это не священный грааль.
github.com/Atmosphere/atmosphere + Jetty
(она поддерживает сразу и вебсокеты и longpolling)
на веб клиенте jquery.atmosphere.js
на Android клиенте de.tavendo.autobahn.WebSocket
DeviceManager соответственно точно также определяет местоположение как по GPS, так и по Wifi и GSM
Но как замечено выше производитель платформы лучше знает как пользоваться своим же API.
Проверьте ради интереса
В этом основная проблема — подвисание сообщений при GPRS соединении
Интересует позиционирование не внутри зданий, а внутри города.
С GPS включенным в здании будет облом (если он до этого не был запущен на улице),
объект потерян напрочь, пока не выйдет на улицу.
Здесь спасает только примерное GSM позиционирование
По WiFi методу же можно определить позицию с точностью до дома.
Но и про позиционирование внутри зданий: если бы это было ни кому не нужно, то
Apple и Google не занимались этим так плотно, как последние годы.
У yandex есть бесплатное API получения координат по WiFi списку MAC, у Google — платное
задача железки — передать видимые MAC, также как сейчас большинство трекеров передают список CID-ов GSM вышек.
Ровно так работает определение местоположения в iPhone, Android
Но железок таких вменяемых нет, жду когда появится образец знакомых разработчиков (нужен для нашего проекта)
GPS трекеров пруд пруди. И у всех один минус — в зданиях они не работают.
Даже на подоконнике (как у вас) — может долго стартовать и убивать батерею.
Заметьте наши iPhone и Android ловят местоположение в 99% случаев по Wifi, а по GPS только на улице.
Знакомые инженеры разрабатывают подобный серийный трекер с WiFi+GPS+GSM, но жду уже год его.
Если у кого-то есть подобные наработки — напишите в личку.
Если в телефонах впаривают моду и потом подстраивают под это эволюцию.
То в автомобиле не наебешь — сделаешь хуево получи труп.
Плохо что уже из-за этой моды не можешь отличить в интерфейсе текст от кнопки,
а шрифты такие тонкие, что скоро просто испарятся.
Но, блядь, так красиво и минималистично…
Не отвечают и активности нет никакой с 2012
и время в пути с учетом пробок?
Или это только в каком то премиум аккаунте возможно.
(последнее обновление год назад github.com/yandexmobile/yandexmapkit-android)
Это уже немного хак получается, что при получении объекта товара передваются еще зачем-то комментарии,
которые не всегда нужны в другом случае использования API.
Значит нужен доп. параметр (когда их передавать, когда нет), потом параметр лимит на число комментариев и т.д.
И в добавок к этому может, например, потребоваться вывести еще 3 похожих товара (если продолжить пример с магазином).
Однако на практике часто красота жертвуется в пользу оптимизации запросов.
Стандартный кейс:
есть красивое REST API по сущностям.
но для приложения работающего через хреновый GPRS каждый лишний запрос — это замедление времени работы приложения.
И часто нужно, чтобы одним запросом можно было вернуть все нужные данные и никакой умный кеш этой задачи не решит.
Как уложить в архитектуру такие запросы сразу нескольких объектов?
без ограничений (permission offline_access снимающий ограничение по ip)
Потому причина другая, а не как таковой запрет запросов к API с сервера.
Это 6 независимых сюжетов по теме этого топика:
«Сквозная тема — влияние информационных технологий на человеческие отношения»
В одной из серий как раз был сюжет про то, что у каждого человека встроена камера
и любой момент жизни можно за секунды отмотать и пересмотреть.
Ну и как следствие — хрен чего скроешь, каждый горазд тебя запалить.
Ссылка на серию