Кто первый научит читалку внятно и выразительно читать — озолотится. Сейчас аудио-версии есть только у книг с большим тиражом, а так можно будет в дороге слушать все что угодно.
То что покроют хуки, скорее всего покроет и lint обычный. А как гайдлайнами проверить паттерны? Или пять раз вызов одной функции, где можно было сохранить ее результат работы. Или пять раз копирование куска кода, который мог бы быть одной функцией. Или не использование каких-то базовых паттернов.
Тайлы свободны. Но OSMF оставляют за собой право забанить слишком активных пользователей. И при разработке платного приложения этот сценарий надо учитывать до запуска, а не после, когда приложение уже забанили, как это было с Pokemon GO.
К слову последнее время регулярно тормозят тайл-рендер сервера. И чтобы удержать эту нагрузку в разумных пределах было предложено банить самых активных пользователей.
OpenStreetMap не бесплатный. Ну или бесплатный только для маленьких приложений. Как только приложение начнет создавать ощутимую нагрузку на тайл-сервера — его могут забанить. Так банили Pokemon GO, что вынудило их искать другого провайдера тайлов уже после запуска.
Карты OpenStreetMap построены на базе картографической JS-библиотеки Leaflet.
Это совсем не правда. Leaflet очень популярная JS-библиотека для интерактивных карт. Но OpenStreetMap на ней не основан и к мобильным приложениям она отношения не имеет ну совсем.
В описании цен Mapbox написано, что вы должны переходить на Commercial план, если у вас платное приложение и вы платите за запросы данных. А в мобильных приложениях (речь в статье ведь именно о них) стоимость зависит от montly active users и платным приложениям не обязательно переходить на Commercial тарифный план.
Еще сведенная таблица говорит, что провайдер карт OSM поддерживает работу офлайн. Опять не совсем верно. OpenStreetMap только про данные. Вокруг него создаются проекты основанные на этих данных. В вики есть большой список разных фреймворков.
Мы разрабатываем приложение Galileo Офлайн Карты и фреймворк GLMap — компонент карт для мобильных приложений, который работает офлайн. По своему опыту могу сказать, что для того чтобы OSM работал офлайн надо пройти длинный путь начиная от сырых данных node, way, relation. Отфильтровать лишнее и сжать данные в бинарный формат, который можно будет удобно парсить. Где-то эти данные хостить. И как-то давать пользователям их скачивать. Потом к этим бинарным данным надо применить стиль, чтобы на выходе получились полигоны, линии, точки, текст с определенными параметрами прорисовки. И затем в нужном порядке все нарисовать и расставить текст. OpenStreetMap заканчивается на node, way, relation + теги описывающие данные.
Кроме отображения карт часто нужно решать еще две задачи, связанные с гео-данными. Это роутинг и адресный поиск. Было бы здорово, чтобы в статье была информация о том, какие сервисы адресного поиска и навигации доступны для мобильных приложений.
Прочитал с удовольствием. Следующий раз разгребая чужой код и бубня «твою-мать-ну-кто-так-пишет», буду думать еще «а не написать ли мне об этом на хабре».
Для рендера текста из sdf нам тоже пришлось в свое время выбирать все глифы из шрифта, которые встречались в наших текстах. Пошли по следующему пути. Свой рендер текста разбирал юникод буквы на глифы (порой один глиф на несколько букв, как в случае с straße, где ß = ss). При генерации sdf текстур мы пробегались по всем текстам, из них собирали всю информацию о глифах и шрифтах из которых брались глифы (Для китайского например система рендера текста уходит искать глифы в китайские ширфты). И по этому набору шрифтов генерились SDF текстуры. Текстуры и бинарной информации из GPOS, GSUB таблиц шрифта хватает, чтобы из глифов собрать обратно буквы. Правильно выбрать расстояния между ними и их вертикальную позицию. Самые веселые буквы у тибетского языка, потому как у них отдельные юникод символы управляют количеством и порядком крышечек сверху и снизу.
Т.е. через год покупателю становится все равно на все плюшки и хочется дешевле?
Идея самого сервиса — найти лучший автомобиль за меньшие деньги. Каждая дополнительная плюшка чего-то стоит. Если продавец недооценил плюшки — надо помочь покупателю найти эту выгоду.
Идея хорошая, но не различает комплектации авто. Т.е. про вариант где порный фарш алгоритм будет говорить цена завышена, а про базовую версию — выгодное предложение. Т.е. кроме указанных переменных есть же еще и наличие парктроника, подогрева сидений, камеры заднего вида, ходовых светодиодных огней, климат контроля, панорамной крыши и прочих-прочих радостей жизни. Они влияют на цену, а алгоритм их отбрасывает как ненужный шлак.
Стеб стебом, но какая была задача у интервьюера? Проверить адекватность кандидата. Какая была задача у кандидата. Получить работу? Я сомневаюсь. Повеселиться? Возможно. Фарс этот закончился бы много быстрее, т.к. тест на адекватность был бы провален и незачем тратить лишнее время на уточняющие вопросы.
Чтобы задание на собеседовании было корректным надо описать входные параметры (имя файла для чтения, имя файла для записи). Выходные параметры (объем скопированных данных или код ошибки). + Желательно контекст задачи. Зачем происходит это действие. Формализовали по максимуму — программист доволен. Интервьюер доволен.
Здорово, но судя по всему без понимания контекста и смысла сказанного тяжело как-то осмысленно вести беседу. Т.е. бот не помнит, что он сам сказал минуту назад и не сможет понять что 2 одинаковых вопроса с разным порядком слов — это по сути одно и то же. В английском с этим немного проще, там грамматика определят порядок слов.
Ваши тесты показывают большую разницу между чистым запуском go fast http и go через nginx. Именно поэтому я и посоветовал посмотреть в сторону настроек nginx, чтобы сократить этот разрыв. Хотя общей картины, конечно, это не изменит.
Сам недавно сталкивался с вопросом оптимизации nginx перед сервисом на Go. Без оптимизации Go напрямую показывал 39k rps, через nginx пролазило только 13k rps. После настройки как в статье по ссылке — nginx увеличил скорость до 32k rps.
А зачем нужно такое строгое соответствие между именем файла и названием фильма? Ведь имя файла это просто идентификатор для базы фильмов и именем может быть любой уникальный идентификатор, чтобы сделать связь один-к-одному.
Тестирование – главная парадигма сообщества Ruby, поэтому неудивительно, что большинство рубистов не трогают многопоточность, поскольку её практически невозможно тестировать, а её баги очень сложно воспроизводить.
К слову последнее время регулярно тормозят тайл-рендер сервера. И чтобы удержать эту нагрузку в разумных пределах было предложено банить самых активных пользователей.
Это совсем не правда. Leaflet очень популярная JS-библиотека для интерактивных карт. Но OpenStreetMap на ней не основан и к мобильным приложениям она отношения не имеет ну совсем.
В описании цен Mapbox написано, что вы должны переходить на Commercial план, если у вас платное приложение и вы платите за запросы данных. А в мобильных приложениях (речь в статье ведь именно о них) стоимость зависит от montly active users и платным приложениям не обязательно переходить на Commercial тарифный план.
Еще сведенная таблица говорит, что провайдер карт OSM поддерживает работу офлайн. Опять не совсем верно. OpenStreetMap только про данные. Вокруг него создаются проекты основанные на этих данных. В вики есть большой список разных фреймворков.
Мы разрабатываем приложение Galileo Офлайн Карты и фреймворк GLMap — компонент карт для мобильных приложений, который работает офлайн. По своему опыту могу сказать, что для того чтобы OSM работал офлайн надо пройти длинный путь начиная от сырых данных node, way, relation. Отфильтровать лишнее и сжать данные в бинарный формат, который можно будет удобно парсить. Где-то эти данные хостить. И как-то давать пользователям их скачивать. Потом к этим бинарным данным надо применить стиль, чтобы на выходе получились полигоны, линии, точки, текст с определенными параметрами прорисовки. И затем в нужном порядке все нарисовать и расставить текст. OpenStreetMap заканчивается на node, way, relation + теги описывающие данные.
Кроме отображения карт часто нужно решать еще две задачи, связанные с гео-данными. Это роутинг и адресный поиск. Было бы здорово, чтобы в статье была информация о том, какие сервисы адресного поиска и навигации доступны для мобильных приложений.
Идея самого сервиса — найти лучший автомобиль за меньшие деньги. Каждая дополнительная плюшка чего-то стоит. Если продавец недооценил плюшки — надо помочь покупателю найти эту выгоду.
Чтобы задание на собеседовании было корректным надо описать входные параметры (имя файла для чтения, имя файла для записи). Выходные параметры (объем скопированных данных или код ошибки). + Желательно контекст задачи. Зачем происходит это действие. Формализовали по максимуму — программист доволен. Интервьюер доволен.
Сам недавно сталкивался с вопросом оптимизации nginx перед сервисом на Go. Без оптимизации Go напрямую показывал 39k rps, через nginx пролазило только 13k rps. После настройки как в статье по ссылке — nginx увеличил скорость до 32k rps.
После этих строк, перестал читать.